✖


Jump to content

Набор интернет-протоколов

(Перенаправлено из стека IP )
Эта статья о протоколах, составляющих архитектуру Интернета. Только для сетевого протокола IP см. Интернет-протокол .

Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

Набор протоколов Интернета , широко известный как TCP/IP , представляет собой основу для организации набора протоколов связи, используемых в Интернете и аналогичных компьютерных сетях, в соответствии с функциональными критериями. Основными протоколами пакета являются протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и интернет-протокол (IP). Ранние версии этой сетевой модели были известны как Министерства обороны ( DoD ) модель , поскольку исследования и разработки финансировались Министерством обороны США через DARPA .

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

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

История

[ редактировать ]
Дополнительная информация: История Интернета.

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

[ редактировать ]
Схема первого межсетевого соединения
Международный SRI пакетный радиофургон , используемый для первой трехсторонней межсетевой передачи.

Первоначально названный моделью интернет-архитектуры Министерства обороны США , набор интернет-протоколов берет свое начало в исследованиях и разработках, спонсируемых Агентством перспективных исследовательских проектов Министерства обороны ( DARPA ) в конце 1960-х годов. [3] После того, как DARPA инициировало новаторскую ARPANET в 1969 году, Стив Крокер основал «Сетевую рабочую группу», которая разработала протокол хост-хост, Программу управления сетью (NCP). [4] В начале 1970-х годов DARPA начало работу над несколькими другими технологиями передачи данных, включая мобильную пакетную радиосвязь, пакетную спутниковую службу, локальные сети и другие сети передачи данных в публичном и частном доменах. В 1972 году Боб Кан DARPA присоединился к отделу технологий обработки информации , где работал как над спутниковыми пакетными сетями, так и над наземными пакетными радиосетями, и осознал ценность возможности общаться между ними. Весной 1973 года Винтон Серф присоединился к Кану с целью разработать следующее поколение протоколов для ARPANET, обеспечивающее межсетевое взаимодействие . [5] [6] Они опирались на опыт исследовательского сообщества ARPANET, Международной сетевой рабочей группы , которую возглавлял Серф, и исследователей Xerox PARC . [7] [8] [9]

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

Первоначально Программа управления передачей ( Интернет-протокол тогда не существовал как отдельный протокол) предоставляла только надежный сервис байтовых потоков своим пользователям , а не дейтаграмм . [13] По мере роста опыта работы с протоколом сотрудники рекомендовали разделить функциональность на уровни отдельных протоколов, предоставляя пользователям прямой доступ к службе дейтаграмм. В число защитников входили Дэнни Коэн , которому это было нужно для работы с пакетной голосовой связью ; Джонатан Постел Университета Южной Калифорнии из Института информационных наук , который редактировал Запрос на комментарии (RFC), серию технических и стратегических документов, которые документировали и стимулировали развитие Интернета; [14] и Боб Меткалф и Йоген Далал из Xerox PARC. [15] [16] Постел заявил: «Мы ошибаемся в разработке интернет-протоколов, нарушая принцип многоуровневого представления». [17] Инкапсуляция различных механизмов была призвана создать среду, в которой верхние уровни могли бы получить доступ только к тому, что необходимо от нижних уровней. Монолитная конструкция будет негибкой и приведет к проблемам с масштабируемостью. В версии 4 , написанной в 1978 году, Постел разделил программу управления передачей на два отдельных протокола: Интернет-протокол как уровень без установления соединения и протокол управления передачей как надежную службу, ориентированную на соединение . [18] [19] [20] [номер 1]

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

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

Раннее внедрение

[ редактировать ]

В 1975 году было проведено испытание IP-связи между двумя сетями между Стэнфордом и Университетским колледжем Лондона. В ноябре 1977 года было проведено тестирование IP в трех сетях между объектами в США, Великобритании и Норвегии . Несколько других прототипов IP были разработаны в нескольких исследовательских центрах в период с 1978 по 1983 год. [22]

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

Принятие

[ редактировать ]

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

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

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 . [32] Первый стек TCP/IP для VM/CMS появился в Университете Висконсина. [33]

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

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

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

Официальные спецификации и стандарты

[ редактировать ]

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

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

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

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

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

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

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

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

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

Протоколы канального уровня действуют в рамках локального сетевого соединения, к которому подключен хост. Этот режим на языке 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 через надежный протокол канала передачи данных, такой как управление каналом передачи данных высокого уровня (HDLC).

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

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

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

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

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

[ редактировать ]

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

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

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

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

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

Многоуровневая эволюция и представления в литературе

[ редактировать ]

Набор интернет-протоколов развивался благодаря исследованиям и разработкам, финансируемым в течение определенного периода времени. В этом процессе изменилась специфика компонентов протокола и их иерархия. Кроме того, за конструктивные особенности конкурировали параллельные исследования и коммерческие интересы отраслевых ассоциаций. В частности, усилия Международной организации по стандартизации привели к аналогичной цели, но в целом с более широким охватом сетей. Попытки консолидировать две основные школы многоуровневого обучения, которые внешне были похожи, но резко расходились в деталях, побудили независимых авторов учебников сформулировать сокращенные инструменты обучения.

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

Эталонная модель Arpanet
(RFC 871) 		Интернет-стандарт
(RFC 1122) 		Интернет-модель
(Академия Cisco [52] ) 		5-уровневая эталонная модель TCP/IP
(Козерок, [53] Есть [54] ) 		5-уровневая эталонная модель TCP/IP
(Таненбаум [55] ) 		Набор протоколов TCP/IP или пятиуровневая модель Интернета
(Форузан, [56] Куросе [57] ) 		Модель TCP/IP
(Столлинги [58] ) 		Модель OSI
(ИСО/МЭК 7498-1:1994). [59] )
Три слоя Четыре слоя Четыре слоя Четыре+один слой Пять слоев Пять слоев Пять слоев Семь слоев
Приложение/Процесс Приложение Приложение Приложение Приложение Приложение Приложение Приложение
Презентация
Сессия
Хост-хост Транспорт Транспорт Транспорт Транспорт Транспорт Хост-хост или транспорт Транспорт
Интернет Межсетевые сети Интернет Интернет Сеть Интернет Сеть
Сетевой интерфейс Связь Сетевой интерфейс Канал передачи данных (сетевой интерфейс) Ссылка на данные Ссылка на данные Доступ к сети Ссылка на данные
— — — (Аппаратное обеспечение) Физический Физический Физический Физический

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

Сравнение уровней 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 предполагает, что аппаратный уровень существует ниже уровня OSI. слой связи.

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

Усилия по разработке протокола IETF не связаны со строгим многоуровневым разделением. Некоторые из его протоколов могут не полностью вписываться в модель OSI, хотя RFC иногда ссылаются на них и часто используют старые номера уровней OSI. IETF неоднократно заявлял [40] [ не удалось пройти проверку ] что разработка интернет-протокола и архитектуры не предназначена для обеспечения совместимости с 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 можно инкапсулировать рекурсивно, о чем свидетельствуют протоколы туннелирования, такие как Generic Routing Encapsulation (GRE). GRE использует тот же механизм, который OSI использует для туннелирования на сетевом уровне.

Реализации

[ редактировать ]

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

См. также

[ редактировать ]

Примечания

[ редактировать ]
  1. ^ Записи обсуждений, приведших к разделению TCP/IP, см. в серии заметок об экспериментах в Интернете в Указатель заметок об экспериментах в Интернете .

Ссылки

[ редактировать ]
  1. ^ Jump up to: а б Брейден, Р. , изд. (октябрь 1989 г.). Требования к интернет-хостам – коммуникационные уровни . дои : 10.17487/RFC1122 . РФК 1122 .
  2. ^ Брейден, Р. , изд. (октябрь 1989 г.). Требования к интернет-хостам – применение и поддержка . дои : 10.17487/RFC1123 . РФК 1123 .
  3. ^ Серф, Винтон Г. и Каин, Эдвард (октябрь 1983 г.). «Модель интернет-архитектуры Министерства обороны США». Компьютерные сети . 7 (5). Северная Голландия: 307–318. дои : 10.1016/0376-5075(83)90042-9 .
  4. ^ Рейнольдс, Дж.; Постел, Дж. (1987). Справочное руководство по запросу комментариев . дои : 10.17487/RFC1000 . РФК 1000 .
  5. ^ Хафнер, Кэти; Лион, Мэтью (1996). Где волшебники засиживаются допоздна: истоки Интернета . Интернет-архив. Нью-Йорк: Саймон и Шустер. п. 263. ИСБН  978-0-684-81201-4 .
  6. ^ Рассел, Эндрю Л. (2014). Открытые стандарты и цифровая эпоха: история, идеология и сети . Нью-Йорк: Cambridge Univ Press. п. 196. ИСБН  978-1107039193 . Архивировано из оригинала 28 декабря 2022 года . Проверено 20 декабря 2022 г.
  7. ^ Аббате, Джанет (2000). Изобретение Интернета . МТИ Пресс. стр. 123–4. ISBN  978-0-262-51115-5 . Архивировано из оригинала 17 января 2023 года . Проверено 15 мая 2020 г.
  8. ^ Тейлор, Боб (11 октября 2008 г.), «Устная история Роберта (Боба) В. Тейлора» (PDF) , Архив Музея компьютерной истории , CHM Справочный номер: X5059.2009: 28
  9. ^ Исааксон, Уолтер (2014). Новаторы: как группа хакеров, гениев и гиков сотворила цифровую революцию . Интернет-архив. Нью-Йорк: Саймон и Шустер. ISBN  978-1-4767-0869-0 .
  10. ^ Серф, В.; Кан, Р. (1974). «Протокол пакетной сетевой связи» (PDF) . Транзакции IEEE в области коммуникаций . 22 (5): 637–648. дои : 10.1109/TCOM.1974.1092259 . ISSN   1558-0857 . Архивировано (PDF) из оригинала 10 октября 2022 г. Проверено 18 октября 2015 г. Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузен, конструктивно прокомментировавшие вопросы фрагментации и учета; и С. Крокер, комментировавшие создание и разрушение ассоциаций.
  11. ^ «Пятый человек Интернета» . Экономист . 13 декабря 2013 года. Архивировано из оригинала 19 апреля 2020 года . Проверено 11 сентября 2017 г. В начале 1970-х годов Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединить не только десятки машин, но и миллионы из них. Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые сейчас поддерживают Интернет.
  12. ^ Серф, Винтон ; Далал, Йоген ; Саншайн, Карл (декабрь 1974 г.). Спецификация протокола управления передачей данных через Интернет . дои : 10.17487/RFC0675 . РФК 675 .
  13. ^ Серф, Винтон (март 1977 г.). «Спецификация протокола управления передачей данных в Интернете TCP (версия 2)» (PDF) . Архивировано (PDF) из оригинала 25 мая 2022 г. Проверено 4 августа 2022 г.
  14. ^ Интернет-Зал славы
  15. ^ Панзарис, Георгиос (2008). Машины и романтика: техническая и повествовательная конструкция сетевых вычислений как платформы общего назначения, 1960–1995 гг . Стэнфордский университет . п. 128. Архивировано из оригинала 17 января 2023 года . Проверено 5 сентября 2019 г.
  16. ^ Пелки, Джеймс Л. (2007). «Йоген Далал» . Предпринимательский капитализм и инновации: история компьютерных коммуникаций, 1968–1988 гг . Архивировано из оригинала 8 октября 2022 года . Проверено 8 октября 2020 г.
  17. ^ Постел, Джон (15 августа 1977 г.), 2.3.3.2 Комментарии к протоколу Интернета и TCP , IEN 2, заархивировано из оригинала 16 мая 2019 г. , получено 11 июня 2016 г.
  18. ^ Аббате, Изобретая Интернет , 129–30.
  19. ^ Винтон Г. Серф (октябрь 1980 г.). «Протоколы для взаимосвязанных пакетных сетей». Обзор компьютерных коммуникаций ACM SIGCOMM . 10 (4): 10–11.
  20. ^ Рассел, Эндрю Л. (2007). «Промышленные законодательные органы»: консенсусная стандартизация во второй и третьей промышленных революциях (PDF) (докторская диссертация). Университет Джонса Хопкинса. Архивировано (PDF) из оригинала 28 декабря 2022 г. Проверено 28 декабря 2022 г.
  21. ^ Винтона Серфа, как рассказал Бернарду Абобе (1993). «Как появился Интернет» . Архивировано из оригинала 26 сентября 2017 года . Проверено 25 сентября 2017 г. Мы начали параллельное внедрение в Стэнфорде, BBN и Университетском колледже Лондона. Таким образом, усилия по разработке интернет-протоколов с самого начала были международными.
  22. ^ Серф, Винтон Г. (1 апреля 1980 г.). «Итоговый отчет проекта TCP Стэнфордского университета» .
  23. ^ Бейкер, Ф. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4 . дои : 10.17487/RFC1812 . РФК 1812 .
  24. ^ Кроуэлл, Уильям; Контос, Брайан; ДеРодефф, Колби (2011). Конвергенция физической и логической безопасности: на основе управления безопасностью предприятия . Сингресс. п. 99. ИСБН  9780080558783 .
  25. ^ Jump up to: а б Ронда Хаубен. «Из ARPANET в Интернет» . TCP-дайджест (UUCP). Архивировано из оригинала 21 июля 2009 года . Проверено 5 июля 2007 г.
  26. ^ ОДИН 207 .
  27. ^ ОДИН 152 .
  28. ^ Хаубен, Ронда (2004). «Интернет: его международное происхождение и совместное видение» . Компьютерщик-любитель . 12 (2) . Проверено 29 мая 2009 г. Март '82 – Норвегия выходит из ARPANET и переходит в Интернет через TCP/IP через SATNET. Ноябрь 2082 г. — UCL покидает ARPANET и становится подключением к Интернету.
  29. ^ «Интернет-протокол TCP/IP» . Архивировано из оригинала 1 января 2018 года . Проверено 31 декабря 2017 г.
  30. ^ Лейнер, Барри М.; и др. (1997), Краткая история Интернета (PDF) , Интернет-сообщество , стр. 15, заархивировано (PDF) из оригинала 18 января 2018 г. , получено 17 января 2018 г.
  31. ^ «Винтон Г. Серф: Устная история» . Стэнфордские коллекции устной истории — в центре внимания Стэнфорда . 2020. с. 113, 129, 145 . Проверено 29 июня 2024 г.
  32. ^ «Использование Wollongong TCP/IP с Windows для рабочих групп 3.11» . Поддержка Майкрософт . Архивировано из оригинала 12 января 2012 года.
  33. ^ «Краткая история интернет-протоколов в ЦЕРНе» . Архивировано из оригинала 10 ноября 2016 года . Проверено 12 сентября 2016 г.
  34. ^ Бейкер, Стивен; Гиллис, Дональд В. «TCP/IP настольного компьютера в среднем возрасте» . Архивировано из оригинала 21 августа 2015 года . Проверено 9 сентября 2016 г.
  35. ^ Ромки, Джон (17 февраля 2011 г.). "О" . Архивировано из оригинала 5 ноября 2011 года . Проверено 12 сентября 2016 г.
  36. ^ Фил Карн, Веб-сайт загрузки KA9Q TCP
  37. ^ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было» . IEEE-спектр . Том. 50, нет. 8. Архивировано из оригинала 1 августа 2017 года . Проверено 6 февраля 2020 г.
  38. ^ Рассел, Эндрю Л. «Приблизительный консенсус и работающий код и война стандартов Интернет-OSI» (PDF) . IEEE Анналы истории вычислений. Архивировано из оригинала (PDF) 17 ноября 2019 г.
  39. ^ Jump up to: а б Дэвис, Ховард; Брессан, Беатрис (26 апреля 2010 г.). История международных исследовательских сетей: люди, которые сделали это возможным . Джон Уайли и сыновья. ISBN  978-3-527-32710-2 . Архивировано из оригинала 17 января 2023 года . Проверено 7 ноября 2020 г.
  40. ^ Jump up to: а б «Введение в IETF» . IETF . Проверено 27 февраля 2024 г.
  41. ^ Морабито, Роберто; Хименес, Хайме (июнь 2020 г.). «Набор протоколов IETF для Интернета вещей: обзор и последние достижения» . Журнал стандартов связи IEEE . 4 (2): 41–49. arXiv : 2003.10279 . дои : 10.1109/mcomstd.001.1900014 . ISSN   2471-2825 .
  42. ^ Блюменталь, Марджори С.; Кларк, Дэвид Д. (август 2001 г.). «Переосмысление дизайна Интернета: сквозные аргументы против дивного нового мира» (PDF) . Архивировано (PDF) из оригинала 8 октября 2022 г. Проверено 8 октября 2022 г.
  43. ^ Джон Постел, изд. (сентябрь 1981 г.). Интернет-протокол DARPA Спецификация протокола интернет-программы . п. 23. дои : 10.17487/RFC0791 . РФК 791 .
  44. ^ Р. Брейден , изд. (октябрь 1989 г.). Требования к интернет-хостам – коммуникационные уровни . п. 13. дои : 10.17487/RFC1122 . РФК 1122 .
  45. ^ Б. Карпентер, изд. (июнь 1996 г.). Архитектурные принципы Интернета . дои : 10.17487/RFC1958 . РФК 1958 .
  46. ^ Хант, Крейг (2002). Администрирование сети TCP/IP (3-е изд.). О'Рейли. стр. 9–10. ISBN  9781449390785 .
  47. ^ Гутман, Э. (1999). «Протокол определения местоположения службы: автоматическое обнаружение сетевых служб IP» . IEEE Интернет-вычисления . 3 (4): 71–80. дои : 10.1109/4236.780963 . ISSN   1089-7801 .
  48. ^ Jump up to: а б Чжэн, Кай (июль 2017 г.). «Включение маршрутизации протоколов: новый взгляд на проектирование протоколов транспортного уровня в интернет-коммуникациях» . IEEE Интернет-вычисления . 21 (6): 52–57. дои : 10.1109/mic.2017.4180845 . ISSN   1089-7801 .
  49. ^ Хуан, Цзин-лянь (7 апреля 2009 г.). «Схема межуровневой адаптации каналов связи в беспроводной локальной сети» . Журнал компьютерных приложений . 29 (2): 518–520. doi : 10.3724/sp.j.1087.2009.00518 (неактивен 13 мая 2024 г.). ISSN   1001-9081 . {{cite journal}}: CS1 maint: DOI неактивен по состоянию на май 2024 г. ( ссылка )
  50. ^ Стивенс, В. Ричард (февраль 1994 г.). TCP/IP в иллюстрациях: протоколы . Аддисон-Уэсли. ISBN  0-201-63346-9 . Архивировано из оригинала 22 апреля 2012 года . Проверено 25 апреля 2012 г.
  51. ^ «1.1.3 Набор интернет-протоколов» . Требования к интернет-хостам – коммуникационные уровни . 1989. с. 9. дои : 10.17487/RFC1122 . РФК 1122 .
  52. ^ Дай, Марк; Макдональд, Рик; Руфи, Антон (29 октября 2007 г.). Основы сети, Дополнительное руководство CCNA Exploration . Сиско Пресс. ISBN  9780132877435 . Проверено 12 сентября 2016 г. - через Google Книги.
  53. ^ Козерок, Чарльз М. (1 января 2005 г.). Руководство TCP/IP: полный иллюстрированный справочник по интернет-протоколам . Нет крахмального пресса. ISBN  9781593270476 . Проверено 12 сентября 2016 г. - через Google Книги.
  54. ^ Комер, Дуглас (1 января 2006 г.). Межсетевое взаимодействие с TCP/IP: принципы, протоколы и архитектура . Прентис Холл. ISBN  0-13-187671-6 . Проверено 12 сентября 2016 г. - через Google Книги.
  55. ^ Таненбаум, Эндрю С. (1 января 2003 г.). Компьютерные сети . Прентис Холл PTR. п. 42 . ISBN  0-13-066102-3 . Проверено 12 сентября 2016 г. - из Интернет-архива. сети.
  56. ^ Форузан, Бехруз А.; Феган, София Чанг (1 августа 2003 г.). Передача данных и сети . Высшее образование МакГроу-Хилл. ISBN  9780072923544 . Проверено 12 сентября 2016 г. - через Google Книги.
  57. ^ Куросе, Джеймс Ф.; Росс, Кейт В. (2008). Компьютерные сети: нисходящий подход . Пирсон/Эддисон Уэсли. ISBN  978-0-321-49770-3 . Архивировано из оригинала 23 января 2016 года . Проверено 16 июля 2008 г.
  58. ^ Столлингс, Уильям (1 января 2007 г.). Данные и компьютерные коммуникации . Прентис Холл. ISBN  978-0-13-243310-5 . Проверено 12 сентября 2016 г. - через Google Книги.
  59. ^ ISO/IEC 7498-1:1994 Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель: Базовая модель .
  60. ^ Буш, Р.; Мейер, Д., ред. (декабрь 2002 г.). Некоторые рекомендации по архитектуре Интернета и философия . дои : 10.17487/RFC3439 . РФК 3439 .

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

[ редактировать ]
[ редактировать ]
В Викиверситете есть учебные ресурсы по набору интернет-протоколов.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_protocol_suite&oldid=1237711897"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 7f2a8cf51be8dec67b7cccdbe85d10d9__1722387480
URL1:https://arc.ask3.ru/arc/aa/7f/d9/7f2a8cf51be8dec67b7cccdbe85d10d9.html
Заголовок, (Title) документа по адресу, URL1:
Internet protocol suite - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)