stringtranslate.com

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

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

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

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

История

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

Схема первого межсетевого соединения
Пакетная радиостанция SRI International , использовавшаяся для первой трехсторонней межсетевой передачи

Первоначально именуемый Моделью архитектуры Интернета Министерства обороны США , набор протоколов Интернета берет свое начало в исследованиях и разработках, спонсируемых Агентством перспективных исследовательских проектов Министерства обороны США ( 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] Несколько версий были разработаны в рамках серии Internet Experiment Note . [14] По мере накопления опыта работы с протоколом соавторы рекомендовали разделить функциональность на уровни отдельных протоколов, что позволило бы пользователям получать прямой доступ к службе датаграмм. Сторонниками были Боб Меткалф и Йоген Далал из Xerox PARC; [15] [16] Дэнни Коэн , которому это было нужно для его работы с пакетной голосовой связью ; и Джонатан Постел из Института информационных наук Университета Южной Калифорнии , который редактировал Запрос на комментарии (RFC), техническую и стратегическую серию документов, которая документировала и катализировала развитие Интернета. [17] Постел заявил: «Мы портим нашу конструкцию Интернет-протоколов, нарушая принцип многослойности». [18] Инкапсуляция различных механизмов была предназначена для создания среды, в которой верхние уровни могли бы получить доступ только к тому, что было необходимо из нижних уровней. Монолитная конструкция была бы негибкой и привела бы к проблемам масштабируемости. В версии 4 , написанной в 1978 году, Постел разделил программу управления передачей на два отдельных протокола, протокол Интернета как уровень без установления соединения и протокол управления передачей как надежный сервис, ориентированный на соединение . [19] [20] [21] [nb 1]

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

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

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

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

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

Принятие

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

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

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

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

Распространение TCP/IP еще больше усилилось в июне 1989 года, когда Калифорнийский университет в Беркли согласился разместить код TCP/IP, разработанный для BSD UNIX, в открытом доступе. Различные корпоративные поставщики, включая IBM, включили этот код в коммерческие выпуски программного обеспечения TCP/IP. Для Windows 3.1, доминирующей операционной системы ПК среди потребителей в первой половине 1990-х годов, выпуск Питером Таттамом стека TCP/IP Trumpet Winsock стал ключом к предоставлению Интернета домашним пользователям. Trumpet Winsock позволял выполнять операции TCP/IP через последовательное соединение ( SLIP или PPP ). Типичный домашний ПК того времени имел внешний модем, совместимый с Hayes, подключенный через порт RS-232 с UART 8250 или 16550 , для которого требовался этот тип стека. Позднее Microsoft выпустила собственный дополнительный стек TCP/IP для Windows for Workgroups 3.11 и собственный стек в Windows 95. Эти события помогли закрепить доминирование TCP/IP над другими протоколами в сетях на базе Microsoft, включая Systems Network Architecture (SNA) компании IBM, а также на других платформах, таких как DECnet компании Digital Equipment Corporation , Open Systems Interconnection (OSI) и Xerox Network Systems (XNS).

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

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

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

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

Основные архитектурные принципы

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

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

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

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

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

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

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

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

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

Интернет-слой

Для межсетевого взаимодействия требуется отправка данных из исходной сети в сеть назначения. Этот процесс называется маршрутизацией и поддерживается адресацией и идентификацией хостов с использованием иерархической системы 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 обычно используется для таких приложений, как потоковое мультимедиа (аудио, видео, Voice over IP и т. д.), где своевременное прибытие важнее надежности, или для простых приложений запросов/ответов, таких как поиск в DNS , где накладные расходы на настройку надежного соединения непропорционально велики. Протокол передачи данных в реальном времени (RTP) — это протокол дейтаграмм, который используется поверх UDP и разработан для данных в реальном времени, таких как потоковое мультимедиа .

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

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

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

Уровень приложений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другое отличие заключается в обработке протоколов маршрутизации . Протокол маршрутизации OSI IS-IS принадлежит сетевому уровню и не зависит от CLNS для доставки пакетов от одного маршрутизатора к другому, но определяет свою собственную инкапсуляцию уровня 3. Напротив, OSPF , RIP , BGP и другие протоколы маршрутизации, определенные IETF, транспортируются по IP, и для отправки и получения пакетов протоколов маршрутизации маршрутизаторы действуют как хосты. Как следствие, протоколы маршрутизации включены в прикладной уровень. [28] Некоторые авторы, такие как Таненбаум в Computer Networks , описывают протоколы маршрутизации на том же уровне, что и 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. ^ abcde R. Braden , ред. (октябрь 1989 г.). Требования к интернет-хостам — коммуникационные уровни. Сетевая рабочая группа. doi : 10.17487/RFC1122 . STD 3. RFC 1122. Интернет-стандарт 3. Обновлен RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 и 9293.
  2. ^ abc R. Braden , ed. (октябрь 1989). Требования к интернет-хостам — применение и поддержка. Сетевая рабочая группа. doi : 10.17487/RFC1123 . STD 3. RFC 1123. Интернет-стандарт 3. Обновлен RFC 1349, 2181, 5321, 5966 и 7766.
  3. ^ Серф, Винтон Г. и Кейн, Эдвард (октябрь 1983 г.). «Модель архитектуры Интернета Министерства обороны». Компьютерные сети . 7 (5). Северная Голландия: 307–318. doi :10.1016/0376-5075(83)90042-9.
  4. ^ J. Reynolds ; J. Postel (ноябрь 1987 г.). СПРАВОЧНОЕ РУКОВОДСТВО ПО ЗАПРОСУ НА КОММЕНТАРИИ. Сетевая рабочая группа. doi : 10.17487/RFC1000 . RFC 1000. Статус неизвестен. Устаревшие RFC 84, 100, 160, 170, 200, 598, 699, 800, 899 и 999.
  5. ^ Хафнер, Кэти; Лион, Мэтью (1996). Где волшебники не спят допоздна: истоки Интернета. Архив Интернета. Нью-Йорк: Simon & Schuster. С. 263. ISBN 978-0-684-81201-4.
  6. ^ ab Russell, Andrew L. (2014). Открытые стандарты и цифровая эпоха: история, идеология и сети. Нью-Йорк: Cambridge Univ Press. стр. 196. ISBN 978-1107039193. Архивировано из оригинала 28 декабря 2022 г. . Получено 20 декабря 2022 г. .
  7. ^ Эббейт, Джанет (2000). Изобретение Интернета. MIT Press. С. 123–4. ISBN 978-0-262-51115-5. Архивировано из оригинала 17 января 2023 г. . Получено 15 мая 2020 г. .
  8. ^ Тейлор, Боб (11 октября 2008 г.), «Устная история Роберта (Боба) У. Тейлора» (PDF) , Архив Музея компьютерной истории , CHM Номер ссылки: X5059.2009: 28
  9. ^ Айзексон, Уолтер (2014). Новаторы: как группа хакеров, гениев и гиков создала цифровую революцию. Архив Интернета. Нью-Йорк: Simon & Schuster. ISBN 978-1-4767-0869-0.
  10. ^ Cerf, V.; Kahn, R. (1974). "Протокол для пакетной сетевой интеркоммуникации" (PDF) . IEEE Transactions on Communications . 22 (5): 637–648. doi :10.1109/TCOM.1974.1092259. ISSN  1558-0857. Архивировано (PDF) из оригинала 10 октября 2022 г. . Получено 18 октября 2015 г. Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно R. Metcalfe, R. Scantlebury, D. Walden и H. Zimmerman; D. Davies и L. Pouzin, которые конструктивно прокомментировали вопросы фрагментации и учета; и S. Crocker, который прокомментировал создание и разрушение ассоциаций.
  11. ^ "Пятый человек интернета". Economist . 13 декабря 2013 г. Архивировано из оригинала 19 апреля 2020 г. Получено 11 сентября 2017 г. В начале 1970-х годов г-н Пузен создал инновационную сеть передачи данных, которая связала местоположения во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединять не только десятки машин, но и миллионы из них. Она захватила воображение доктора Серфа и доктора Кана, которые включили аспекты ее дизайна в протоколы, которые теперь питают интернет.
  12. ^ V. Cerf ; Y. Dalal ; C. Sunshine (декабрь 1974 г.). СПЕЦИФИКАЦИЯ ПРОГРАММЫ УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ В ИНТЕРНЕТЕ. Сетевая рабочая группа. doi : 10.17487/RFC0675 . RFC 675. Устарело. Устарело по RFC 7805. NIC 2. INWG 72.
  13. ^ Серф, Винтон (март 1977 г.). «Спецификация протокола управления передачей данных в Интернете TCP (версия 2)» (PDF) . Архивировано (PDF) из оригинала 25 мая 2022 г. . Получено 4 августа 2022 г. .
  14. ^ ab Cerf, Vinton G. (1 апреля 1980 г.). «Заключительный отчет проекта TCP Стэнфордского университета».
  15. ^ Панзарис, Георгиос (2008). Машины и романы: техническое и повествовательное построение сетевых вычислений как универсальной платформы, 1960–1995. Стэнфордский университет . стр. 128. Архивировано из оригинала 17 января 2023 г. Получено 5 сентября 2019 г.
  16. ^ Pelkey, James L. (2007). «Yogen Dalal». Предпринимательский капитализм и инновации: история компьютерных коммуникаций, 1968–1988. Архивировано из оригинала 8 октября 2022 г. Получено 8 октября 2020 г.
  17. ^ Зал славы Интернета
  18. ↑ Постел, Джон (15 августа 1977 г.), 2.3.3.2 Комментарии к Интернет-протоколу и TCP, IEN 2, заархивировано из оригинала 16 мая 2019 г. , извлечено 11 июня 2016 г.
  19. ↑ Аббат, Изобретение Интернета , 129–30.
  20. ^ Винтон Г. Серф (октябрь 1980 г.). «Протоколы для взаимосвязанных пакетных сетей». Обзор компьютерной связи ACM SIGCOMM . 10 (4): 10–11.
  21. ^ Рассел, Эндрю Л. (2007). «Промышленные законодательные органы»: стандартизация консенсуса во Второй и Третьей промышленных революциях (PDF) (диссертация). Университет Джонса Хопкинса. Архивировано (PDF) из оригинала 28 декабря 2022 г. . Получено 28 декабря 2022 г. .
  22. ^ Беннетт, Ричард (сентябрь 2009 г.). «Создано для перемен: сквозные аргументы, инновации в Интернете и дебаты о сетевом нейтралитете» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11. Получено 11 сентября 2017 г.
  23. ^ Pelkey, James. "8.3 CYCLADES Network и Louis Pouzin 1971-1972". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988. Архивировано из оригинала 17 июня 2021 г. Получено 21 ноября 2021 г. Вдохновение для дейтаграмм имело два источника. Одним из них были исследования Дональда Дэвиса. Он провел некоторое моделирование сетей дейтаграмм, хотя и не построил ни одной, и это выглядело технически жизнеспособным. Вторым вдохновением было то, что мне нравятся простые вещи. Я не видел никакой реальной технической мотивации для наложения двух уровней сквозных протоколов. Я думал, что одного будет достаточно.
  24. ^ Дэвис, Дональд; Бартлетт, Кейт; Скэнтлбери, Роджер; Уилкинсон, Питер (октябрь 1967 г.). Цифровая коммуникационная сеть для компьютеров, обеспечивающая быстрый ответ на удаленных терминалах (PDF) . Симпозиум ACM по принципам операционных систем. Архивировано (PDF) из оригинала 10 октября 2022 г. Получено 15 сентября 2020 г. все пользователи сети предоставят себе некоторый контроль ошибок
  25. ^ Д. Вайцман (1 апреля 1990 г.). Стандарт передачи IP-дейтаграмм на авианосцах. Сетевая рабочая группа. doi : 10.17487/RFC1149 . RFC 1149. Экспериментальный. Это первоапрельская просьба о комментариях .
  26. ^ B. Carpenter ; R. Hinden (1 апреля 2011 г.). Адаптация RFC 1149 для IPv6. Internet Engineering Task Force . doi : 10.17487/RFC6214 . ISSN  2070-1721. RFC 6214. Информационное. Это первоапрельская просьба о комментариях .
  27. ^ Винтон Серф, как рассказал Бернарду Абобе (1993). «Как появился Интернет». Архивировано из оригинала 26 сентября 2017 г. . Получено 25 сентября 2017 г. Мы начали делать параллельные внедрения в Стэнфорде, BBN и Университетском колледже Лондона. Поэтому усилия по разработке интернет-протоколов были международными с самого начала.
  28. ^ ab F. Baker , ed. (июнь 1995 г.). Требования к маршрутизаторам IP версии 4. Сетевая рабочая группа. doi : 10.17487/RFC1812 . RFC 1812. Предложенный стандарт. Отменяет RFC 1716 и 1009. Обновлен RFC 2644 и 6633.
  29. ^ Кроуэлл, Уильям; Контос, Брайан; ДеРодефф, Колби (2011). Физическая и логическая конвергенция безопасности: на основе управления безопасностью предприятия . Syngress. стр. 99. ISBN 9780080558783.
  30. ^ ab Ronda Hauben. "From the ARPANET to the Internet". TCP Digest (UUCP). Архивировано из оригинала 21 июля 2009 г. Получено 5 июля 2007 г.
  31. ^ ИЕН 207.
  32. ^ ИЕН 152.
  33. ^ Хаубен, Ронда (2004). «Интернет: о его международных истоках и совместном видении». Amateur Computerist . 12 (2) . Получено 29 мая 2009 г. Март 1982 г. — Норвегия выходит из ARPANET и становится интернет-подключением через TCP/IP через SATNET. Ноябрь 1982 г. — UCL выходит из ARPANET и становится интернет-подключением.
  34. ^ "TCP/IP Internet Protocol". Архивировано из оригинала 1 января 2018 года . Получено 31 декабря 2017 года .
  35. ^ Leiner, Barry M.; et al. (1997), Краткая история Интернета (PDF) , Internet Society , стр. 15, заархивировано (PDF) из оригинала 18 января 2018 г. , извлечено 17 января 2018 г.
  36. ^ "Vinton G. Cerf: An Oral History". Stanford Oral History Collections - Spotlight at Stanford . 2020. стр. 113, 129, 145. Получено 29 июня 2024 г.
  37. ^ "Использование Wollongong TCP/IP с Windows для рабочих групп 3.11". Поддержка Microsoft . Архивировано из оригинала 12 января 2012 г.
  38. ^ "Краткая история интернет-протоколов в ЦЕРНе". Архивировано из оригинала 10 ноября 2016 г. Получено 12 сентября 2016 г.
  39. ^ Бейкер, Стивен; Джиллис, Дональд В. "Desktop TCP/IP at middle age". Архивировано из оригинала 21 августа 2015 г. Получено 9 сентября 2016 г.
  40. ↑ Romkey, John (17 февраля 2011 г.). "About". Архивировано из оригинала 5 ноября 2011 г. Получено 12 сентября 2016 г.
  41. ^ Фил Карн, KA9Q TCP Загрузить веб-сайт
  42. ↑ Эндрю Л. Рассел (30 июля 2013 г.). «OSI: Интернет, которого не было». IEEE Spectrum . Том 50, № 8. Архивировано из оригинала 1 августа 2017 г. Получено 6 февраля 2020 г.
  43. ^ Рассел, Эндрю Л. «Грубый консенсус и работающий код и война стандартов Интернет-OSI» (PDF) . Анналы истории вычислений IEEE. Архивировано из оригинала (PDF) 17 ноября 2019 г.
  44. ^ ab Дэвис, Ховард; Брессан, Беатрис (26 апреля 2010 г.). История международных исследовательских сетей: люди, которые сделали это возможным. John Wiley & Sons. ISBN 978-3-527-32710-2. Архивировано из оригинала 17 января 2023 г. . Получено 7 ноября 2020 г. .
  45. ^ ab "Введение в IETF". IETF . Получено 27 февраля 2024 г. .
  46. ^ Морабито, Роберто; Хименес, Хайме (июнь 2020 г.). «Набор протоколов IETF для Интернета вещей: обзор и последние достижения». Журнал стандартов связи IEEE . 4 (2): 41–49. arXiv : 2003.10279 . doi : 10.1109/mcomstd.001.1900014. ISSN  2471-2825.
  47. ^ Блюменталь, Марджори С.; Кларк, Дэвид Д. (август 2001 г.). «Переосмысление дизайна Интернета: сквозные аргументы против смелого нового мира» (PDF) . Архивировано (PDF) из оригинала 8 октября 2022 г. . Получено 8 октября 2022 г. .
  48. ^ J. Postel , ред. (сентябрь 1981 г.). ПРОТОКОЛ ИНТЕРНЕТА - СПЕЦИФИКАЦИЯ ПРОТОКОЛА ПРОГРАММЫ ИНТЕРНЕТА DARPA. IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Интернет-стандарт 5. Отменяет действие RFC 760. Обновлен RFC 1349, 2474 и 6864.
  49. ^ Б. Карпентер , ред. (июнь 1996 г.). Архитектурные принципы Интернета. Сетевая рабочая группа. doi : 10.17487/RFC1958 . RFC 1958. Информационное. Обновлено RFC 3439.
  50. ^ Хант, Крейг (2002). Администрирование сетей TCP/IP (3-е изд.). O'Reilly. стр. 9–10. ISBN 9781449390785.
  51. ^ Гуттман, Э. (1999). «Протокол определения местоположения сервисов: автоматическое обнаружение сетевых сервисов IP». IEEE Internet Computing . 3 (4): 71–80. doi :10.1109/4236.780963. ISSN  1089-7801.
  52. ^ ab Zheng, Kai (июль 2017 г.). «Включение «маршрутизации протоколов»: пересмотр проектирования протоколов транспортного уровня в интернет-коммуникациях». IEEE Internet Computing . 21 (6): 52–57. doi :10.1109/mic.2017.4180845. ISSN  1089-7801.
  53. ^ Хуан, Цзин-лянь (7 апреля 2009 г.). «Схема адаптации кросс-уровневой связи в беспроводной локальной сети». Journal of Computer Applications . 29 (2): 518–520. doi :10.3724/sp.j.1087.2009.00518 (неактивен 13 мая 2024 г.). ISSN  1001-9081.{{cite journal}}: CS1 maint: DOI inactive as of May 2024 (link)
  54. ^ Стивенс, В. Ричард (февраль 1994). TCP/IP Illustrated: протоколы. Addison-Wesley. ISBN 0-201-63346-9. Архивировано из оригинала 22 апреля 2012 г. . Получено 25 апреля 2012 г. .
  55. ^ Дай, Марк; Макдональд, Рик; Руфи, Антун (29 октября 2007 г.). Основы сетей, CCNA Exploration Companion Guide. Cisco Press. ISBN 9780132877435. Получено 12 сентября 2016 г. – через Google Books.
  56. ^ Козиерок, Чарльз М. (1 января 2005 г.). Руководство по TCP/IP: всеобъемлющий иллюстрированный справочник по протоколам Интернета. No Starch Press. ISBN 9781593270476. Получено 12 сентября 2016 г. – через Google Books.
  57. ^ Комер, Дуглас (1 января 2006 г.). Сетевое взаимодействие с TCP/IP: принципы, протоколы и архитектура. Prentice Hall. ISBN 0-13-187671-6. Получено 12 сентября 2016 г. – через Google Books.
  58. ^ Таненбаум, Эндрю С. (1 января 2003 г.). Компьютерные сети . Prentice Hall PTR. стр. 42. ISBN 0-13-066102-3. Получено 12 сентября 2016 г. – через Интернет-архив. сети.
  59. ^ Форузан, Бехруз А.; Феган, София Чунг (1 августа 2003 г.). Передача данных и сетевое взаимодействие. McGraw-Hill Higher Education. ISBN 9780072923544. Получено 12 сентября 2016 г. – через Google Books.
  60. ^ Куроуз, Джеймс Ф.; Росс, Кит В. (2008). Компьютерные сети: подход сверху вниз. Pearson/Addison Wesley. ISBN 978-0-321-49770-3. Архивировано из оригинала 23 января 2016 г. . Получено 16 июля 2008 г. .
  61. ↑ Столлингс, Уильям (1 января 2007 г.). Данные и компьютерные коммуникации. Prentice Hall. ISBN 978-0-13-243310-5. Получено 12 сентября 2016 г. – через Google Books.
  62. ^ ISO/IEC 7498-1:1994 Информационные технологии — Взаимосвязь открытых систем — Базовая эталонная модель: Базовая модель.
  63. ^ ab R. Bush; D. Meyer (декабрь 2002 г.). Некоторые принципы и философия архитектуры Интернета. Сетевая рабочая группа. doi : 10.17487/RFC3439 . RFC 3439. Информационный. Обновления RFC 1958.

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

Внешние ссылки

Викиверситет содержит обучающие ресурсы о наборе протоколов Интернета