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

Эта статья о протоколах, составляющих архитектуру Интернета. Только для сетевого протокола IP см. протокол Интернета.
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

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

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

История

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

Схема первого межсетевого соединения
An SRI International Пакетное Радио Ван, используется для первого трехходового объединенный в сеть коробка передач.

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

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

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

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

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

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

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

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

Принятие

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

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

IBM, AT&T и DEC были первыми крупными корпорациями, принявшими TCP / IP, несмотря на то, что проприетарные протоколы. В IBM с 1984 г. Барри Аппельман Группа разработчиков TCP / IP. Они руководствовались корпоративной политикой, чтобы получить поток продуктов TCP / IP для различных систем IBM, включая MVS, ВМ, и OS / 2. В то же время несколько небольших компаний, таких как Программное обеспечение FTP и Wollongong Group, начали предлагать стеки TCP / IP для ДОС и Майкрософт Виндоус.[21] Первый ВМ / CMS Стек TCP / IP поступил из Висконсинского университета.[22]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транспортный уровень и уровни нижнего уровня не заботятся о специфике протоколов прикладного уровня. Маршрутизаторы и переключатели обычно не исследуют инкапсулированный трафик, а просто предоставляют для него канал. Однако некоторые брандмауэр и регулирование полосы пропускания приложения должны интерпретировать данные приложения. Примером может служить Протокол резервирования ресурсов (ПРОСЬБА ОТВЕТИТЬ). Иногда это необходимо для транслятор сетевых адресов (NAT), чтобы учесть полезную нагрузку приложения.

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

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

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

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

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

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

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

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

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

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

Конфликты очевидны также в исходной модели OSI, ISO 7498, если не рассматривать приложения к этой модели, например, ISO 7498/4 Management Framework или ISO 8648 Internal Organization of the Network Layer (IONL). Когда рассматриваются документы IONL и Management Framework, ICMP и IGMP определяются как протоколы управления уровнем для сетевого уровня. Аналогичным образом IONL обеспечивает структуру для «средств конвергенции, зависящих от подсети», таких как ARP и RARP.

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

Реализации

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

Прикладных программистов обычно интересуют только интерфейсы на прикладном уровне, а часто и на транспортном уровне, в то время как нижележащие уровни представляют собой службы, предоставляемые стеком TCP / IP в операционной системе. Большинство реализаций IP доступны программистам через Розетки и API.

Уникальные реализации включают Легкий TCP / IP, Открытый исходный код стек предназначен для встроенные системы, и KA9Q NOS, стек и связанные протоколы для любительских пакетное радио системы и персональные компьютеры подключен через последовательные линии.

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

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

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

Рекомендации

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

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