Набор интернет-протоколов
Из Википедии, свободной энциклопедии
  (Перенаправлено из IP-сети )
Перейти к навигации Перейти к поиску

Эта статья о протоколах, составляющих архитектуру Интернета. Только сетевой протокол IP см. в разделе Интернет-протокол .
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-уровень
Связующий слой
  • ARP [1] [ неудачная проверка ]
  • НДП
  • Туннели
  • ГЧП
  • МАК
  • более...
  • в
  • т
  • е

Набор протоколов Интернета, широко известный как TCP/IP, представляет собой набор протоколов связи, используемых в Интернете и аналогичных компьютерных сетях . Текущие основные протоколы в наборе — это протокол управления передачей (TCP) и интернет-протокол (IP).

Во время его разработки его версии были известны как модель Министерства обороны ( DoD ) , потому что разработка сетевого метода финансировалась Министерством обороны США через DARPA . Его реализация представляет собой стек протоколов . [2]

Набор интернет-протоколов обеспечивает сквозную передачу данных , определяя, как данные должны быть упакованы, адресованы, переданы, маршрутизированы и получены. Эта функциональность организована в четыре уровня абстракции , которые классифицируют все связанные протоколы в соответствии с областью действия каждого протокола в сети. [3] [4] Уровни от низшего к высшему представляют собой канальный уровень , содержащий методы передачи данных, которые остаются в пределах одного сегмента сети (канала); интернет - уровень , обеспечивающий межсетевое взаимодействие между независимыми сетями; транспортный уровень , обеспечивающий связь между хостами; иприкладной уровень , обеспечивающий обмен данными между процессами для приложений.

Технические стандарты, лежащие в основе набора интернет-протоколов и составляющих его протоколов, поддерживаются Инженерной группой Интернета (IETF). Набор интернет-протоколов предшествует модели OSI , более полной эталонной структуре для общих сетевых систем.

История

Дополнительная информация: История Интернета.

Ранние исследования

Схема первого межсетевого соединения
SRI International Packet Radio Van , использовавшийся для первой трехсторонней объединенной передачи .

Набор интернет-протоколов появился в результате исследований и разработок, проведенных Агентством перспективных исследовательских проектов Министерства обороны США ( DARPA ) в конце 1960-х годов. [2] После запуска новаторской сети ARPANET в 1969 году DARPA приступило к работе над рядом других технологий передачи данных. В 1972 году Роберт Э. Кан присоединился к Управлению технологий обработки информации DARPA , где он работал как над спутниковыми пакетными сетями, так и над наземными пакетными радиосетями, и осознал ценность возможности общаться в обоих случаях. Весной 1973 года Винтон Серф , помогавший разработать существующий протокол ARPANET Network Control Program (NCP), присоединился к Кану для работы надмодели межсоединений с открытой архитектурой с целью разработки протоколов следующего поколения для ARPANET. [ править ] Они опирались на опыт исследовательского сообщества ARPANET и Международной рабочей группы по созданию сетей , которую возглавлял Серф. [5]

К лету 1973 года Кан и Серф разработали фундаментальную переформулировку, в которой различия между локальными сетевыми протоколами были скрыты за счет использования общего межсетевого протокола , и вместо того, чтобы сеть отвечала за надежность, как в существующих протоколах ARPANET , эта функция была делегирована хостам. Серф считает , что Хьюберт Циммерманн и Луи Пузен , дизайнер сети CYCLADES , оказали большое влияние на этот дизайн. [6] [7] Новый протокол был реализован как Программа управления передачей в 1974 году. [8]

Первоначально программа управления передачей управляла как передачей дейтаграмм , так и маршрутизацией, но по мере роста опыта работы с протоколом сотрудники рекомендовали разделить функциональность на уровни отдельных протоколов. Среди защитников были Джонатан Постел из Института информационных наук Университета Южной Калифорнии , который редактировал Запрос на комментарии (RFC), серию технических и стратегических документов, которые документировали и катализировали развитие Интернета, [9] и исследовательская группа Роберта Меткалфа в Ксерокс ПАРК . [10] [11]Постел заявил: «Мы ошибаемся в разработке интернет-протоколов, нарушая принцип многоуровневости». [12] Инкапсуляция различных механизмов предназначалась для создания среды, в которой верхние уровни могли получить доступ только к тому, что было необходимо из нижних слоев. Монолитный дизайн был бы негибким и привел бы к проблемам с масштабируемостью. В версии 3 TCP, написанной в 1978 году, программа управления передачей была разделена на два отдельных протокола: Интернет-протокол как уровень без установления соединения и протокол управления передачей как надежный сервис, ориентированный на установление соединения . [13]

При проектировании сети учитывалось, что она должна обеспечивать только функции эффективной передачи и маршрутизации трафика между конечными узлами, а все остальные интеллектуальные функции должны располагаться на границе сети, в конечных узлах. Эта конструкция известна как сквозной принцип . Используя этот дизайн, стало возможным подключать другие сети к ARPANET, которые использовали тот же принцип, независимо от других местных характеристик, тем самым решая первоначальную проблему межсетевого взаимодействия Кана. Популярным выражением является то, что TCP/IP, окончательный продукт работы Серфа и Кана, может работать по «двум жестяным банкам и веревке». [ цитировать ] Годы спустя, в шутку, IP над Avian Carriers была создана и успешно протестирована формальная спецификация протокола.

DARPA заключило контракт с BBN Technologies , Стэнфордским университетом и Университетским колледжем Лондона на разработку операционных версий протокола на нескольких аппаратных платформах. [14] Во время разработки протокола номер версии уровня маршрутизации пакетов изменился с версии 1 на версию 4, последняя из которых была установлена ​​в сети ARPANET в 1983 году . который до сих пор используется в Интернете, наряду с его текущим преемником, Интернет-протоколом версии 6 (IPv6).

Ранняя реализация

В 1975 году между Стэнфордом и Университетским колледжем Лондона было проведено испытание IP-коммуникаций с двумя сетями. В ноябре 1977 г. было проведено тестирование IP трех сетей между сайтами в США, Великобритании и Норвегии. Несколько других прототипов IP были разработаны в нескольких исследовательских центрах в период с 1978 по 1983 год. До «Дня флага» 1 января 1983 года Интернет использовал NCP вместо TCP в качестве протокола транспортного уровня.

Компьютер, называемый маршрутизатором , снабжен интерфейсом к каждой сети. Он пересылает сетевые пакеты туда и обратно между ними. [15] Первоначально маршрутизатор назывался шлюзом , но этот термин был изменен, чтобы избежать путаницы с другими типами шлюзов . [16]

Принятие

В марте 1982 года Министерство обороны США объявило TCP/IP стандартом для всех военных компьютерных сетей. [17] В том же году протокол был принят NORSAR и исследовательской группой Питера Кирштейна из Университетского колледжа Лондона. [14] [18] [19] Миграция ARPANET на TCP/IP была официально завершена 1 января 1983 года, когда новые протоколы были окончательно активированы . [20]

В 1985 году Консультативный совет Интернета (позже Совет по архитектуре Интернета ) провел трехдневный семинар по TCP/IP для компьютерной индустрии, на котором присутствовало 250 представителей поставщиков, продвигая протокол и приводя к его более широкому коммерческому использованию. В 1985 году первая конференция Interop была посвящена сетевому взаимодействию за счет более широкого внедрения TCP/IP. Конференция была основана Дэном Линчем, одним из первых интернет-активистов. С самого начала на встрече присутствовали крупные корпорации, такие как IBM и DEC. [21]

IBM, AT&T и DEC были первыми крупными корпорациями, внедрившими TCP/IP, несмотря на наличие конкурирующих проприетарных протоколов . В IBM с 1984 года группа Барри Аппельмана занималась разработкой TCP/IP. Они использовали корпоративную политику, чтобы получить поток продуктов TCP/IP для различных систем IBM, включая MVS , VM и OS/2 . В то же время несколько более мелких компаний, таких как FTP Software и Wollongong Group , начали предлагать стеки TCP/IP для DOS и Microsoft Windows . [22] Первый стек VM/CMS TCP/IP появился в Университете Висконсина. [23]

Некоторые из первых стеков TCP/IP были написаны единолично несколькими программистами. Джей Елински и Олег Вишнепольский  [ ru ] из IBM Research написали стеки TCP/IP для VM/CMS и OS/2 соответственно. [ нужна цитата ] В 1984 году Дональд Гиллис из Массачусетского технологического института написал TCP с несколькими соединениями ntcp , который работал поверх уровня IP/PacketDriver, поддерживаемого Джоном Ромки из Массачусетского технологического института в 1983–1984 годах. Ромки использовал этот TCP в 1986 году, когда была основана FTP Software. [24] [25] Начиная с 1985 года Фил Карн создал TCP-приложение с несколькими соединениями для радиолюбительских систем (KA9Q TCP). [26]

Распространение TCP/IP еще больше ускорилось в июне 1989 года, когда Калифорнийский университет в Беркли согласился разместить код TCP/IP, разработанный для BSD UNIX , в общественное достояние. Различные корпоративные поставщики, включая IBM, включили этот код в коммерческие выпуски программного обеспечения TCP/IP. Microsoft выпустила собственный стек TCP/IP в Windows 95. Это событие помогло закрепить доминирование TCP/IP над другими протоколами в сетях на базе Microsoft, включая системную сетевую архитектуру IBM (SNA), и на других платформах, таких как Digital Equipment Corporation . DECnet , Open Systems Interconnection (OSI) и Xerox Network Systems (XNS).

Тем не менее, в конце 1980-х и начале 1990-х инженеры, организации и страны были поляризованы по вопросу о том, какой стандарт , модель OSI или набор интернет-протоколов приведет к созданию лучших и наиболее надежных компьютерных сетей. [27] [28] [29]

Формальные спецификации и стандарты

Технические стандарты, лежащие в основе набора интернет-протоколов и составляющих его протоколов, были делегированы Инженерной группе Интернета (IETF).

Характерной архитектурой набора протоколов Интернета является широкое разделение операционных областей для протоколов, составляющих его основные функции. Определяющей спецификацией пакета является RFC 1122, который в общих чертах описывает четыре уровня абстракции . [3] Они выдержали испытание временем, поскольку IETF никогда не изменяла эту структуру. Как такая модель сети, Internet Protocol Suite предшествует модели OSI, более полной эталонной структуре для общих сетевых систем. [29]

Ключевые архитектурные принципы

См. Также: Протокол связи § Многоуровневое программное обеспечение .
Концептуальный поток данных в простой сетевой топологии двух хостов ( A и B ), соединенных каналом между их соответствующими маршрутизаторами. Приложение на каждом хосте выполняет операции чтения и записи, как если бы процессы были напрямую связаны друг с другом каким-то конвейером данных. После создания этого канала большая часть деталей связи скрыта от каждого процесса, поскольку основные принципы связи реализуются на нижних уровнях протокола. По аналогии, на транспортном уровне связь выглядит как хост-хост, без знания структур данных приложения и подключающихся маршрутизаторов, в то время как на межсетевом уровне границы отдельных сетей пересекаются на каждом маршрутизаторе.
Инкапсуляция данных приложения, спускающихся по уровням, описанным в RFC 1122.

Принцип end-to-end эволюционировал с течением времени. Его первоначальное выражение поместило поддержание состояния и общего интеллекта на края и предполагало, что Интернет, соединяющий края, не сохраняет состояние и концентрируется на скорости и простоте. Реальные потребности в брандмауэрах, трансляторах сетевых адресов, кэшировании веб-контента и т.п. заставили изменить этот принцип. [30]

Принцип надежности гласит: «В общем, реализация должна быть консервативной в своем поведении при отправке и либеральной в поведении при приеме. То есть она должна быть осторожной при отправке правильно сформированных дейтаграмм, но должна принимать любые дейтаграммы, которые она может интерпретировать ( например, не возражать против технических ошибок, когда смысл еще ясен)». [31] «Вторая часть принципа почти так же важна: программное обеспечение на других хостах может содержать недостатки, из-за которых неразумно использовать законные, но малоизвестные функции протокола». [32]

Инкапсуляция используется для обеспечения абстракции протоколов и сервисов. Инкапсуляция обычно связана с разделением набора протоколов на уровни общей функциональности. Как правило, приложение (самый высокий уровень модели) использует набор протоколов для отправки своих данных вниз по уровням. Данные дополнительно инкапсулируются на каждом уровне.

Ранний архитектурный документ, RFC  1122 , делает упор на архитектурные принципы, а не на уровни. [33] RFC 1122, озаглавленный Требования к хосту , состоит из параграфов, относящихся к уровням, но документ ссылается на многие другие архитектурные принципы и не делает акцента на многоуровневости. Он свободно определяет четырехслойную модель, в которой слои имеют имена, а не номера, следующим образом:

  • Прикладной уровень — это область, в которой приложения или процессы создают пользовательские данные и передают эти данные другим приложениям на другом или том же хосте. Приложения используют службы, предоставляемые нижележащими нижними уровнями, особенно транспортным уровнем, который предоставляет надежные или ненадежные каналы для других процессов. Коммуникационные партнеры характеризуются архитектурой приложения, такой как модель клиент-сервер и одноранговая сеть. Это уровень, на котором работают все прикладные протоколы, такие как SMTP, FTP, SSH, HTTP. Процессы адресуются через порты, которые, по сути, представляют службы .
  • Транспортный уровень выполняет обмен данными между хостами либо в локальной сети, либо в удаленных сетях, разделенных маршрутизаторами. [34] Он обеспечивает канал для коммуникационных потребностей приложений. UDP — это базовый протокол транспортного уровня, предоставляющий ненадежную службу дейтаграмм без установления соединения . Протокол управления передачей обеспечивает управление потоком, установление соединения и надежную передачу данных.
  • Интернет-уровень обменивается дейтаграммами через границы сети. Он предоставляет единый сетевой интерфейс, который скрывает фактическую топологию (схему) базовых сетевых подключений. Следовательно, это также уровень, который устанавливает межсетевое взаимодействие. Действительно, он определяет и устанавливает Интернет. Этот уровень определяет структуры адресации и маршрутизации, используемые для набора протоколов TCP/IP. Основным протоколом в этой области является Интернет-протокол, который определяет IP-адреса . Его функция в маршрутизации заключается в транспортировке дейтаграмм к следующему хосту, функционирующему как IP-маршрутизатор, который имеет возможность подключения к сети ближе к конечному получателю данных.
  • Уровень канала определяет сетевые методы в рамках канала локальной сети, по которому узлы взаимодействуют без промежуточных маршрутизаторов. Этот уровень включает в себя протоколы, используемые для описания топологии локальной сети, и интерфейсы, необходимые для передачи дейтаграмм интернет-уровня узлам следующего соседа.

Связующий слой

Протоколы канального уровня работают в рамках локального сетевого соединения, к которому подключен хост. Этот режим называется каналом на языке TCP/IP и является самым нижним компонентным уровнем пакета. Ссылка включает в себя все хосты, доступные без прохождения маршрутизатора. Таким образом, размер канала определяется конструкцией сетевого оборудования. В принципе, TCP/IP спроектирован так, чтобы быть независимым от оборудования и может быть реализован практически поверх любой технологии канального уровня. Сюда входят не только аппаратные реализации, но и уровни виртуальных каналов, такие как виртуальные частные сети и сетевые туннели .

Канальный уровень используется для перемещения пакетов между интерфейсами интернет-уровня двух разных хостов по одному и тому же каналу. Процессами передачи и приема пакетов по каналу можно управлять в драйвере устройства для сетевой карты , а также в прошивке или с помощью специализированных чипсетов . Они выполняют такие функции, как кадрирование, для подготовки пакетов интернет-уровня к передаче и, наконец, передают кадры на физический уровень и через среду передачи . Модель TCP/IP включает спецификации для преобразования методов сетевой адресации, используемых в Интернет-протоколе, в адреса канального уровня, такие как управление доступом к среде .(MAC) адреса. Однако все другие аспекты ниже этого уровня неявно предполагаются и не определены явно в модели TCP/IP.

Уровень канала в модели TCP/IP имеет соответствующие функции на уровне 2 модели OSI.

Интернет-уровень

См. также: IP-заголовок

Межсетевое взаимодействие требует отправки данных из исходной сети в целевую сеть. Этот процесс называется маршрутизацией и поддерживается адресацией и идентификацией узлов с использованием иерархической системы IP-адресации . Интернет-уровень обеспечивает ненадежную передачу дейтаграмм между хостами, расположенными в потенциально разных IP-сетях, пересылая дейтаграммы на соответствующий маршрутизатор следующего перехода для дальнейшей ретрансляции к месту назначения. Интернет-уровень отвечает за отправку пакетов по потенциально нескольким сетям. Благодаря этой функциональности интернет-уровень делает возможным межсетевое взаимодействие, взаимодействие различных IP-сетей и, по сути, устанавливает Интернет.

Интернет-уровень не делает различий между различными протоколами транспортного уровня. IP переносит данные для различных протоколов верхнего уровня . Каждый из этих протоколов идентифицируется уникальным номером протокола : например, протокол управляющих сообщений Интернета (ICMP) и протокол управления группами Интернета (IGMP) — это протоколы 1 и 2 соответственно.

Интернет-протокол является основным компонентом интернет-уровня и определяет две системы адресации для идентификации сетевых узлов и их обнаружения в сети. Первоначальная адресная система ARPANET и ее преемника, Интернета, представляет собой Интернет-протокол версии 4 (IPv4). Он использует 32-битный IP-адрес и поэтому способен идентифицировать примерно четыре миллиарда хостов. Это ограничение было устранено в 1998 году путем стандартизации Интернет-протокола версии 6 (IPv6), в котором используются 128-битные адреса. Производственные реализации IPv6 появились примерно в 2006 году.

Транспортный уровень

См. Также: Транспортный уровень

Транспортный уровень устанавливает основные каналы данных, которые приложения используют для обмена данными для конкретных задач. Уровень устанавливает связь между хостами в форме сквозных сервисов передачи сообщений, которые не зависят от базовой сети и структуры пользовательских данных и логистики обмена информацией. Связность на транспортном уровне может быть классифицирована как ориентированная на соединение , реализованная в TCP, или без установления соединения , реализованная в UDP. Протоколы на этом уровне могут обеспечивать контроль ошибок , сегментацию , управление потоком , контроль перегрузки и адресацию приложений ( номера портов ).

В целях обеспечения каналов передачи для конкретных процессов для приложений уровень устанавливает концепцию сетевого порта . Это пронумерованная логическая конструкция, выделенная специально для каждого из необходимых приложению каналов связи. Для многих типов служб эти номера портов стандартизированы, чтобы клиентские компьютеры могли обращаться к определенным службам сервера без участия служб обнаружения служб или служб каталогов .

Поскольку IP обеспечивает доставку только с максимальной эффективностью , некоторые протоколы транспортного уровня обеспечивают надежность.

TCP — это протокол, ориентированный на соединение, который решает многочисленные проблемы надежности при обеспечении надежного потока байтов :

  • данные приходят по порядку
  • данные имеют минимальную ошибку (т.е. правильность)
  • повторяющиеся данные удаляются
  • потерянные или отброшенные пакеты повторно отправляются
  • включает контроль пробок на дорогах

Более новый протокол передачи управления потоком (SCTP) также является надежным транспортным механизмом, ориентированным на соединение. Он ориентирован на поток сообщений, а не на поток байтов, как TCP, и обеспечивает мультиплексирование нескольких потоков по одному соединению. Он также обеспечивает поддержку множественной адресации, при которой конец соединения может быть представлен несколькими IP-адресами (представляющими несколько физических интерфейсов), так что в случае сбоя одного из них соединение не прерывается. Первоначально он был разработан для приложений телефонии (для передачи SS7 по IP).

Надежность также может быть достигнута путем запуска IP по надежному протоколу канала передачи данных, такому как High-Level Data Link Control (HDLC).

Протокол пользовательских дейтаграмм (UDP) — это протокол дейтаграмм без установления соединения . Как и IP, это ненадежный протокол, работающий с максимальной эффективностью. Надежность достигается за счет обнаружения ошибок с использованием алгоритма контрольной суммы. UDP обычно используется для таких приложений, как потоковое мультимедиа (аудио, видео, передача голоса по IP и т. д .), где своевременность получения важнее, чем надежность, или для простых приложений запроса/ответа, таких как поиск DNS , где накладные расходы на настройку надежное соединение непропорционально велико. Транспортный протокол реального времени (RTP) — это протокол дейтаграмм, который используется поверх UDP и предназначен для данных в реальном времени, таких как потоковое мультимедиа .

Приложения с любым заданным сетевым адресом различаются портом TCP или UDP. По соглашению некоторые хорошо известные порты связаны с конкретными приложениями.

Транспортный или межхостовой уровень модели TCP/IP примерно соответствует четвертому уровню модели OSI, также называемому транспортным уровнем.

QUIC быстро становится альтернативным транспортным протоколом. Хотя технически он передается через пакеты UDP, он стремится предложить улучшенную транспортную связь по сравнению с TCP. HTTP/3 работает исключительно через QUIC.

Прикладной уровень

Прикладной уровень включает в себя протоколы, используемые большинством приложений для предоставления пользовательских услуг или обмена данными приложений по сетевым соединениям, установленным протоколами более низкого уровня. Это может включать в себя некоторые основные службы поддержки сети, такие как протоколы маршрутизации и конфигурация хоста. Примеры протоколов прикладного уровня включают протокол передачи гипертекста (HTTP), протокол передачи файлов (FTP), простой протокол передачи почты (SMTP) и протокол динамической конфигурации хоста (DHCP). [35] Данные, закодированные в соответствии с протоколами прикладного уровня, инкапсулируются.в единицы протокола транспортного уровня (такие как потоки TCP или дейтаграммы UDP), которые, в свою очередь, используют протоколы нижнего уровня для фактической передачи данных.

Модель TCP/IP не учитывает особенности форматирования и представления данных и не определяет дополнительные уровни между прикладным и транспортным уровнями, как в модели OSI (уровни представления и сеанс). Согласно модели TCP/IP, такие функции относятся к области библиотек и интерфейсов прикладного программирования . Прикладной уровень в модели TCP/IP часто сравнивают с комбинацией пятого (сеансового), шестого (представления) и седьмого (прикладного) уровней модели OSI.

Протоколы прикладного уровня часто связаны с конкретными клиент-серверными приложениями, а общие службы имеют хорошо известные номера портов, зарезервированные Управлением по присвоению номеров в Интернете (IANA). Например, протокол передачи гипертекста использует серверный порт 80, а Telnet использует серверный порт 23. Клиенты , подключающиеся к службе, обычно используют эфемерные порты , т. е. номера портов, назначенные только на время транзакции случайным образом или из определенного диапазона, настроенного в применение.

На прикладном уровне модель TCP/IP различает пользовательские протоколы и протоколы поддержки . [36] Протоколы поддержки предоставляют услуги системе сетевой инфраструктуры. Пользовательские протоколы используются для реальных пользовательских приложений. Например, FTP — это пользовательский протокол, а DNS — вспомогательный протокол.

Хотя приложения обычно осведомлены о ключевых качествах соединения транспортного уровня, таких как IP-адреса конечных точек и номера портов, протоколы прикладного уровня обычно рассматривают протоколы транспортного уровня (и ниже) как черные ящики , которые обеспечивают стабильное сетевое соединение, через которое можно обмениваться данными. . Транспортный уровень и более низкие уровни не связаны со спецификой протоколов прикладного уровня. Маршрутизаторы и коммутаторы обычно не проверяют инкапсулированный трафик, а просто обеспечивают его канал. Однако некоторые брандмауэры и приложения для регулирования полосы пропускания используют глубокую проверку пакетов для интерпретации данных приложения. Примером являетсяПротокол резервирования ресурсов (RSVP). [ править ] Также иногда необходимо, чтобы приложения, затронутые NAT , учитывали полезную нагрузку приложения.

Названия слоев и количество слоев в литературе

В следующей таблице показаны различные сетевые модели. Количество слоев варьируется от трех до семи.

RFC 1122, Интернет STD 3 (1989)Академия Сиско [37]Курозе, [38] Форузан [39]Комер, [40] Козерок [41]Сталлингс [42]Таненбаум [43]Эталонная модель Arpanet (RFC 871)Модель OSI
Четыре слояЧетыре слояПять слоевЧетыре+один слойПять слоевПять слоевТри слояСемь слоев
«Интернет-модель»«Интернет-модель»«Пятиуровневая модель Интернета» или «набор протоколов TCP/IP»."5-уровневая эталонная модель TCP/IP""Модель TCP/IP""5-уровневая эталонная модель TCP/IP""Эталонная модель Арпанет"Модель OSI
ПрименениеПрименениеПрименениеПрименениеПрименениеПрименениеПрикладной процессПрименение
Презентация
Сессия
ТранспортТранспортТранспортТранспортХост-хост или транспортТранспортХост-хостТранспорт
Интернетмежсетевое взаимодействиеСетьИнтернетИнтернетИнтернетСеть
Ссылка на сайтСетевой интерфейсКанал передачи данныхКанал передачи данных (сетевой интерфейс)Доступ к сетиКанал передачи данныхСетевой интерфейсКанал передачи данных
Физический(Аппаратное обеспечение)ФизическийФизическийФизический

Некоторые сетевые модели взяты из учебников, являющихся вторичными источниками, которые могут противоречить назначению RFC 1122 и других первичных источников IETF . [44]

Сравнение уровней TCP/IP и OSI

См. Также: Модель OSI § Сравнение с моделью TCP/IP .

Три верхних уровня модели OSI, т. е. прикладной уровень, уровень представления и сеансовый уровень, не выделяются отдельно в модели TCP/IP, в которой над транспортным уровнем имеется только прикладной уровень. Хотя некоторые приложения чистого протокола OSI, такие как X.400 , также объединяют их, нет требования, чтобы стек протоколов TCP/IP навязывал монолитную архитектуру над транспортным уровнем. Например, протокол приложения NFS работает поверх протокола представления внешних данных (XDR), который, в свою очередь, работает поверх протокола, называемого удаленным вызовом процедур (RPC). RPC обеспечивает надежную передачу записей, поэтому он может безопасно использовать максимально возможный транспорт UDP.

Разные авторы интерпретируют модель TCP/IP по-разному и расходятся во мнениях относительно того, охватывает ли канальный уровень или какой-либо аспект модели TCP/IP проблемы уровня 1 OSI ( физический уровень ) или TCP/IP предполагает существование аппаратного уровня ниже связующий слой.

Несколько авторов пытались включить уровни 1 и 2 модели OSI в модель TCP/IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU ). Это часто приводит к модели с пятью уровнями, где канальный уровень или уровень доступа к сети разделены на уровни 1 и 2 модели OSI.

Усилия по разработке протокола IETF не связаны со строгим разделением по уровням. Некоторые из его протоколов могут не полностью вписываться в модель OSI, хотя RFC иногда ссылаются на нее и часто используют старые номера уровней OSI. IETF неоднократно заявляла , что разработка интернет-протокола и архитектуры не предназначена для совместимости с OSI . RFC 3439, относящийся к архитектуре Интернета, содержит раздел, озаглавленный: «Расслоение считается вредным».

Например, уровни сеанса и уровня представления пакета OSI считаются включенными в прикладной уровень пакета TCP/IP. Функциональность сеансового уровня можно найти в таких протоколах, как HTTP и SMTP , и более очевидна в таких протоколах, как Telnet и протокол инициации сеанса (SIP). Функциональность сеансового уровня также реализована с помощью нумерации портов протоколов TCP и UDP, которые включены в транспортный уровень пакета TCP/IP. Функции уровня представления реализованы в приложениях TCP/IP со стандартом MIME при обмене данными.

Еще одно отличие заключается в трактовке протоколов маршрутизации . Протокол маршрутизации OSI IS-IS относится к сетевому уровню и не зависит от CLNS для доставки пакетов от одного маршрутизатора к другому, а определяет собственную инкапсуляцию уровня 3. Напротив, OSPF , RIP , BGP и другие протоколы маршрутизации, определенные IETF, передаются по IP, и для отправки и получения пакетов протокола маршрутизации маршрутизаторы действуют как хосты. Как следствие, RFC 1812 включает протоколы маршрутизации на прикладном уровне. Некоторые авторы, такие как Таненбаум в « Компьютерных сетях ». , описывают протоколы маршрутизации на том же уровне, что и IP, аргументируя это тем, что протоколы маршрутизации информируют о решениях, принимаемых в процессе пересылки маршрутизаторов.

Протоколы IETF можно рекурсивно инкапсулировать, как это демонстрируют протоколы туннелирования, такие как универсальная инкапсуляция маршрутизации (GRE). GRE использует тот же механизм, что и OSI для туннелирования на сетевом уровне.

Реализации

Набор интернет-протоколов не предполагает какой-либо конкретной аппаратной или программной среды. Для этого требуется только наличие аппаратного и программного уровня, способного отправлять и получать пакеты в компьютерной сети. В результате пакет был реализован практически на каждой вычислительной платформе. Минимальная реализация TCP/IP включает следующее: Интернет-протокол (IP), Протокол разрешения адресов (ARP), Интернет-протокол управляющих сообщений (ICMP), Протокол управления передачей (TCP), Протокол пользовательских дейтаграмм (UDP) и Управление группами Интернета. протокол (IGMP). В дополнение к IP, ICMP, TCP, UDP, Интернет-протокол версии 6 требуетПротокол обнаружения соседей (NDP), ICMPv6 и обнаружение прослушивателя многоадресной рассылки (MLD) и часто сопровождается интегрированным уровнем безопасности IPSec .

Смотрите также

  • BBN Report 1822 , ранняя модель многоуровневой сети.
  • FLIP (протокол) (быстрый локальный стек протоколов Интернета)
  • Список протоколов автоматизации
  • Список сокращений информационных технологий
  • Список номеров IP-протокола
  • Список сетевых протоколов
  • Список номеров портов TCP и UDP

использованная литература

  1. ^ В. Ричард Стивенс, TCP/IP Illustrated, Volume 1: The Protocols , Addison Wesley, 1994, ISBN 0-201-63346-9.
  2. ^ a b Серф, Винтон Г. и Каин, Эдвард (1983), «Модель архитектуры Интернета Министерства обороны» , Компьютерные сети , 7, Северная Голландия, стр. 307–318, CiteSeerX 10.1.1.88.7505 
  3. ^ a b RFC 1122, Требования к интернет-хостам - уровни связи , Р. Брейден (ред.), Октябрь 1989 г.
  4. ↑ RFC 1123, Требования к интернет-хостам — применение и поддержка , Р. Брейден (редактор), октябрь 1989 г.
  5. ^ Аббате, Джанет (2000). Изобретение Интернета . Массачусетский технологический институт Пресс. стр. 123–4. ISBN 978-0-262-51115-5.
  6. ^ Серф, В .; Кан, Р. (1974). «Протокол для взаимодействия в пакетной сети» (PDF) . Транзакции IEEE в коммуникациях . 22 (5): 637–648. doi : 10.1109/TCOM.1974.1092259 . ISSN 1558-0857 . Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время раннего обсуждения международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузен, которые конструктивно высказались по вопросам фрагментации и учета; и С. Крокер, который прокомментировал создание и разрушение ассоциаций.  
  7. ^ "Пятый человек в Интернете" . Экономист . 13 декабря 2013 г. . Проверено 11 сентября 2017 г. В начале 1970-х г-н Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании. Его простота и эффективность указывали путь к сети, которая могла бы соединить не просто десятки, а миллионы машин. Он поразил воображение доктора Серфа и доктора Кана, которые включили аспекты его дизайна в протоколы, которые сейчас используются в Интернете.
  8. ^ Винтон Серф , Йоген Далал , Карл Саншайн (декабрь 1974 г.), RFC 675 , Спецификация протокола управления передачей через Интернет (декабрь 1974 г.) 
  9. ^ Интернет-зал славы
  10. ^ Панзарис, Георгиос (2008). Машины и романсы: техническое и повествовательное построение сетевых вычислений как универсальной платформы, 1960–1995 гг . Стэнфордский университет . п. 128.
  11. ^ Пелки, Джеймс Л. (2007). «Йоген Далал». Предпринимательский капитализм и инновации: история компьютерных коммуникаций, 1968–1988 гг . Проверено 5 сентября 2019 г. .
  12. ^ Постел, Джон (1977), «Раздел 3.3.3.2» , Комментарии об интернет-протоколе и TCP .
  13. ^ «Руководство по TCP/IP — Обзор и история TCP/IP» . www.tcpipguide.com . Проверено 11 февраля 2020 г. .
  14. ^ a b Винтона Серфа, как сказал Бернард Абоба (1993). «Как появился Интернет» . Архивировано из оригинала 26 сентября 2017 года . Проверено 25 сентября 2017 г. . Мы начали параллельные реализации в Стэнфорде, BBN и Университетском колледже Лондона. Поэтому усилия по разработке интернет-протоколов с самого начала носили международный характер. ... Март 82 - Норвегия выходит из ARPANET и становится Интернет-соединением через TCP/IP через SATNET. Ноябрь 1982 г. — UCL покидает ARPANET и становится интернет-соединением.
  15. ^ RFC 1812, Требования к маршрутизаторам IP версии 4 , Ф. Бейкер (июнь 1995 г.)
  16. ^ Кроуэлл, Уильям; Контос, Брайан; ДеРодефф, Колби (2011). Конвергенция физической и логической безопасности: на базе управления корпоративной безопасностью . Сингресс. п. 99. ИСБН 9780080558783.
  17. ^ Ронда Хаубен. «От ARPANET к Интернету» . Дайджест TCP (UUCP) . Проверено 5 июля 2007 г.
  18. ^ Мартин, Оливье (2012). «Скрытая» предыстория европейской исследовательской сети . Издательство Траффорд. ISBN 978-1466938724.
  19. ^ Кирштейн, Питер Т. «Ранний опыт работы с ARPANET и Интернетом в Великобритании» . Департамент компьютерных наук, исследовательская группа систем и сетей Университетского колледжа Лондона . Проверено 13 апреля 2016 г.
  20. ^ «Интернет-протокол TCP / IP» . Архивировано из оригинала 1 января 2018 года . Проверено 31 декабря 2017 г. .
  21. ^ Лейнер, Барри М.; и другие. (1997), Краткая история Интернета (PDF) , Internet Society , с. 15
  22. ^ «Использование Wollongong TCP/IP с Windows для рабочих групп 3.11» . Поддержка Майкрософт . Архивировано из оригинала 12 января 2012 года.
  23. ^ «Краткая история интернет-протоколов в ЦЕРНе» . Архивировано из оригинала 10 ноября 2016 года . Проверено 12 сентября 2016 г.
  24. ^ Бейкер, Стивен; Гиллис, Дональд В. «Настольный TCP/IP в среднем возрасте» .
  25. ↑ Ромки , Джон (17 февраля 2011 г.). "О" . Проверено 12 сентября 2016 г.
  26. ^ Фил Карн, веб-сайт загрузки KA9Q TCP
  27. ↑ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было» . IEEE Спектр . Том. 50 нет. 8.
  28. ^ Рассел, Эндрю Л. «Грубый консенсус и рабочий код и война стандартов OSI для Интернета» (PDF) . IEEE Annals of the History of Computing. Архивировано из оригинала (PDF) 17 ноября 2019 г.
  29. ^ б Дэвис, Ховард ; Брессан, Беатрис (26 апреля 2010 г.). История международных исследовательских сетей: люди, благодаря которым это произошло . Джон Уайли и сыновья. ISBN 978-3-527-32710-2.
  30. ↑ Переосмысление дизайна Интернета: сквозные аргументы против дивного нового мира , Марджори С. Блюменталь, Дэвид Д. Кларк, август 2001 г.
  31. ^ Джон Постел, изд. (сентябрь 1981 г.). Интернет-протокол Спецификация интернет-протокола программы DARPA . п. 23. Дои : 10.17487 /RFC0791 . RFC 791 .
  32. ^ Р. Брейден, изд. (октябрь 1989 г.). Требования к интернет-хостам — коммуникационные уровни . п. 13. doi : 10.17487/RFC1122 . RFC 1122 .
  33. ^ Б. Карпентер, изд. (июнь 1996 г.). Архитектурные принципы Интернета . дои : 10.17487/RFC1958 . RFC 1958 .
  34. ^ Хант, Крейг (2002). Сетевое администрирование TCP/IP (3-е изд.). О'Райли. стр. 9–10. ISBN 9781449390785.
  35. ↑ TCP/IP Illustrated: the protocols , ISBN 0-201-63346-9 , У. Ричард Стивенс, февраль 1994 г. 
  36. ^ RFC 1122 , Требования к интернет-хостам — уровни связи , 1.1.3 Комплект протоколов Интернета , 1989 г.
  37. ^ Дай, Марк; Макдональд, Рик; Руфи, Антун (29 октября 2007 г.). Основы сети, вспомогательное руководство CCNA Exploration Companion Guide . Сиско Пресс. ISBN 9780132877435. Проверено 12 сентября 2016 г. - через Google Книги.
  38. ↑ Джеймс Ф. Куросе , Кейт В. Росс, Компьютерные сети: нисходящий подход, 2008 ISBN 0-321-49770-8 
  39. ^ Форузан, Бехруз А .; Феган, София Чанг (1 августа 2003 г.). Передача данных и сеть . McGraw-Hill Высшее образование. ISBN 9780072923544. Проверено 12 сентября 2016 г. - через Google Книги.
  40. ↑ Комер, Дуглас (1 января 2006 г.). Межсетевое взаимодействие с TCP/IP: принципы, протоколы и архитектура . Прентис Холл. ISBN 0-13-187671-6. Проверено 12 сентября 2016 г. - через Google Книги.
  41. ↑ Козерок , Чарльз М. (1 января 2005 г.). Руководство по TCP/IP: исчерпывающий иллюстрированный справочник по интернет-протоколам . Без Крахмального Пресса. ISBN 9781593270476. Проверено 12 сентября 2016 г. - через Google Книги.
  42. ↑ Столлингс, Уильям (1 января 2007 г.). Данные и компьютерные коммуникации . Прентис Холл. ISBN 978-0-13-243310-5. Проверено 12 сентября 2016 г. - через Google Книги.
  43. ^ Таненбаум, Эндрю С. (1 января 2003 г.). Компьютерные сети . Prentice Hall PTR. п. 42 . ISBN 0-13-066102-3. Проверено 12 сентября 2016 г. - из Интернет-архива. сети.
  44. ^ RFC 3439, Некоторые принципы и философия архитектуры Интернета , Р. Буш, Д. Мейер (ред.), Декабрь 2002 г.

Библиография

  • Дуглас Э. Комер . Межсетевое взаимодействие с TCP/IP – Принципы, протоколы и архитектура . ISBN 86-7991-142-9.
  • Джозеф Г. Дэвис; Томас Ф. Ли. Протоколы и службы TCP/IP Microsoft Windows Server 2003. ISBN 0-7356-1291-9.
  • Форузан, Бехруз А. (2003). Набор протоколов TCP/IP (2-е изд.). Макгроу-Хилл. ISBN 978-0-07-246060-5.
  • Крейг Хант (1998). Администрирование сети TCP/IP . О'Райли. ISBN 1-56592-322-7.
  • Мауфер, Томас А. (1999). Основы ИП . Прентис Холл. ISBN 978-0-13-975483-8.
  • Ян Маклин. Черная книга Windows 2000 TCP/IP . ISBN 1-57610-687-Х.
  • Аджит Мангале. Pro .NET 1.1 Сетевое программирование . ISBN 1-59059-345-6.
  • В. Ричард Стивенс . Иллюстрированный протокол TCP/IP, том 1: протоколы . ISBN 0-201-63346-9.
  • В. Ричард Стивенс ; Гэри Р. Райт. Иллюстрированный протокол TCP/IP, том 2: Реализация . ISBN 0-201-63354-Х.
  • В. Ричард Стивенс . TCP/IP в иллюстрациях, том 3: TCP для транзакций , HTTP , NNTP и доменные протоколы UNIX . ISBN 0-201-63495-3.
  • Эндрю С. Таненбаум . Компьютерные сети . ISBN 0-13-066102-3.
  • Кларк, Д. (1988). «Философия дизайна интернет-протоколов DARPA». Материалы симпозиума по коммуникационным архитектурам и протоколам - SIGCOMM '88 (PDF) . Материалы симпозиума SIGCOMM '88 по коммуникационным архитектурам и протоколам . АКМ . стр. 106–114. дои : 10.1145/52324.52336 . ISBN 978-0897912792. S2CID  6156615 . Проверено 16 октября 2011 г.
  • Протокол для пакетной сетевой связи , Серф и Кан, IEEE Trans on Comms, Vol Com-22, № 5, май 1974 г.

внешняя ссылка

  • История Интернета - страницы о Роберте Кане, Винтоне Серфе и TCP/IP (просмотр Серфом и Каном).
  • RFC  1180 Учебное пособие по TCP / IP - от Инженерной группы Интернета (январь 1991 г.)
  • Полное руководство по TCP/IP
  • Руководство по TCP/IP — всесторонний обзор протоколов, а также соответствующих процедур и процессов.
  • Исследование дайджеста ARPANET TCP/IP , заархивировано из оригинала 4 декабря 2021 г.
  • Диаграммы последовательности TCP/IP
  • Учебник Daryl's TCP/IP Primer — введение в администрирование локальной сети TCP/IP, диалоговый стиль
Получено с https://en.wikipedia.org/w/index.php?title=Internet_protocol_suite&oldid=1065717357 "
Contribute a better translation