Набор протоколов Интернета , широко известный как TCP/IP , представляет собой основу для организации набора протоколов связи , используемых в Интернете и аналогичных компьютерных сетях, в соответствии с функциональными критериями. Основными протоколами пакета являются протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и интернет-протокол (IP). Ранние версии этой сетевой модели были известны как модель Министерства обороны ( DoD ) , поскольку исследования и разработки финансировались Министерством обороны США через DARPA .
Набор интернет-протоколов обеспечивает сквозную передачу данных , определяя, как данные должны быть пакетированы, адресованы, переданы, маршрутизированы и получены. Эта функциональность организована в четыре уровня абстракции , которые классифицируют все связанные протоколы в соответствии с областью действия каждого протокола в сети. [1] [2] Реализация уровней для конкретного приложения образует стек протоколов . Уровни от самого низкого до самого высокого представляют собой канальный уровень , содержащий методы передачи данных, которые остаются в пределах одного сегмента сети (канала); интернет -уровень , обеспечивающий взаимодействие между независимыми сетями; транспортный уровень , обеспечивающий связь между хостами; и уровень приложений , обеспечивающий обмен данными между процессами для приложений.
Технические стандарты , лежащие в основе набора протоколов Интернета и входящих в него протоколов, поддерживаются Инженерной группой Интернета (IETF). Набор интернет-протоколов предшествует модели OSI , более полной эталонной структуре для общих сетевых систем.
Первоначально названный моделью интернет-архитектуры Министерства обороны США , набор интернет-протоколов берет свое начало в исследованиях и разработках, спонсируемых Агентством перспективных исследовательских проектов Министерства обороны ( 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] Инкапсуляция различных механизмов была призвана создать среду, в которой верхние уровни могли бы получить доступ только к тому, что необходимо от нижних уровней. Монолитная конструкция будет негибкой и приведет к проблемам с масштабируемостью. В версии 3 TCP, написанной в 1978 году, Серф, Коэн и Постел разделили программу управления передачей данных на два отдельных протокола: Интернет- протокол как уровень без установления соединения и протокол управления передачей как надежную службу, ориентированную на соединение . [№ 1] [18]
При проектировании сети учитывалось, что она должна обеспечивать только функции эффективной передачи и маршрутизации трафика между конечными узлами, а весь остальной интеллект должен располагаться на границе сети, в конечных узлах. Эта конструкция известна как сквозной принцип . Используя эту конструкцию, стало возможным подключать к ARPANET другие сети, которые использовали тот же принцип, независимо от других локальных характеристик, тем самым решая первоначальную проблему межсетевого взаимодействия Кана. Популярное выражение гласит, что TCP/IP, окончательный продукт работы Серфа и Кана, может работать на «двух консервных банках и веревке». [ нужна цитата ] Спустя годы, в шутку, была создана и успешно протестирована формальная спецификация протокола IP over Avian Carriers .
DARPA заключило контракт с BBN Technologies , Стэнфордским университетом и Университетским колледжем Лондона на разработку рабочих версий протокола на нескольких аппаратных платформах. [19] В ходе разработки протокола номер версии уровня маршрутизации пакетов увеличился с версии 1 до версии 4, последняя из которых была установлена в ARPANET в 1983 году. Он стал известен как Интернет-протокол версии 4 (IPv4) в качестве протокола. он до сих пор используется в Интернете вместе со своим нынешним преемником, Интернет-протоколом версии 6 (IPv6).
В 1975 году было проведено испытание IP-связи между двумя сетями между Стэнфордом и Университетским колледжем Лондона. В ноябре 1977 года было проведено тестирование IP в трех сетях между объектами в США, Великобритании и Норвегии . Несколько других прототипов IP были разработаны в нескольких исследовательских центрах в период с 1978 по 1983 год.
Компьютер, называемый маршрутизатором , имеет интерфейс для каждой сети. Он пересылает сетевые пакеты туда и обратно между ними. [20] Первоначально маршрутизатор назывался шлюзом , но этот термин был изменен, чтобы избежать путаницы с другими типами шлюзов . [21]
В марте 1982 года Министерство обороны США объявило TCP/IP стандартом для всех военных компьютерных сетей. [22] [23] В том же году NORSAR / NDRE и исследовательская группа Питера Кирстейна в Университетском колледже Лондона приняли протокол. [24] Переход ARPANET от NCP к TCP/IP был официально завершен в день флага 1 января 1983 года, когда новые протоколы были окончательно активированы. [22] [25]
В 1985 году Консультативный совет Интернета (позже Совет по архитектуре Интернета ) провел трехдневный семинар по TCP/IP для компьютерной индустрии, на котором присутствовали 250 представителей поставщиков, продвигая протокол и приводя к его более широкому коммерческому использованию. В 1985 году первая конференция Interop сосредоточилась на совместимости сетей за счет более широкого внедрения TCP/IP. Конференцию основал Дэн Линч, один из первых интернет-активистов. С самого начала на встрече присутствовали крупные корпорации, такие как IBM и DEC. [26]
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 . [27] Первый стек TCP/IP для VM/CMS появился в Университете Висконсина. [28]
Некоторые из ранних стеков TCP/IP были написаны в одиночку несколькими программистами. Джей Елинский и Олег Вишнепольский из IBM Research написали стеки TCP/IP для VM/CMS и OS/2 соответственно. [ нужна цитата ] В 1984 году Дональд Гиллис из Массачусетского технологического института написал TCP с несколькими соединениями ntcp , который работает поверх уровня IP/PacketDriver, поддерживаемого Джоном Ромки в Массачусетском технологическом институте в 1983–84 годах. Ромки использовал этот TCP в 1986 году, когда было основано FTP Software. [29] [30] Начиная с 1985 года Фил Карн создал TCP-приложение с несколькими соединениями для радиолюбительских систем (KA9Q TCP). [31]
Распространение 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 или набор интернет-протоколов — приведет к созданию лучших и наиболее надежных компьютерных сетей. [32] [33] [34]
Технические стандарты , лежащие в основе набора протоколов Интернета и входящих в него протоколов, были переданы Инженерной группе Интернета (IETF).
Характерной архитектурой набора протоколов Интернета является его широкое разделение на функциональные области протоколов, которые составляют его основную функциональность. Определяющей спецификацией пакета является RFC 1122, в котором в общих чертах описываются четыре уровня абстракции . [1] Они выдержали испытание временем, поскольку IETF никогда не изменял эту структуру. В качестве такой модели сети набор протоколов Интернета предшествует модели OSI, более полной эталонной структуре для общих сетевых систем. [34]
Принцип сквозной передачи эволюционировал с течением времени. Его первоначальное выражение отводило поддержание состояния и общего интеллекта на периферию и предполагало, что Интернет, соединяющий края, не сохраняет состояния и концентрируется на скорости и простоте. Реальные потребности в брандмауэрах, трансляторах сетевых адресов, кэшах веб-контента и т.п. вынудили внести изменения в этот принцип. [35]
Принцип устойчивости гласит: «В общем, реализация должна быть консервативной в поведении отправки и либеральной в поведении приема. То есть она должна быть осторожной при отправке правильно сформированных дейтаграмм, но должна принимать любую дейтаграмму, которую она может интерпретировать ( например, не возражать против технических ошибок, смысл которых ясен)». [36] «Вторая часть принципа почти столь же важна: программное обеспечение на других хостах может содержать недостатки, из-за которых неразумно использовать законные, но неясные особенности протокола». [37]
Инкапсуляция используется для обеспечения абстракции протоколов и сервисов. Инкапсуляция обычно связана с разделением набора протоколов на уровни общей функциональности. В общем, приложение (самый высокий уровень модели) использует набор протоколов для отправки своих данных вниз по уровням. Данные дополнительно инкапсулируются на каждом уровне.
Ранний архитектурный документ RFC 1122, озаглавленный «Требования к хосту» , подчеркивает архитектурные принципы, а не многоуровневость. [38] RFC 1122 состоит из разделов, относящихся к уровням, но документ ссылается на многие другие архитектурные принципы и не уделяет особого внимания многоуровневости. Он в общих чертах определяет четырехслойную модель, в которой слои имеют имена, а не номера, следующим образом:
Протоколы канального уровня действуют в рамках локального сетевого соединения, к которому подключен хост. Этот режим на языке 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 обычно используется для таких приложений, как потоковая передача мультимедиа (аудио, видео, передача голоса по IP и т. д.), где своевременное прибытие важнее надежности, или для простых приложений запросов/ответов, таких как поиск DNS , где накладные расходы на настройку надежное соединение непропорционально велико. Транспортный протокол реального времени (RTP) — это протокол дейтаграмм, который используется поверх UDP и предназначен для данных в реальном времени, таких как потоковые мультимедиа .
Приложения по любому сетевому адресу различаются портом TCP или UDP. По соглашению некоторые известные порты связаны с конкретными приложениями.
Транспортный уровень модели TCP/IP, или уровень «хост-хост», примерно соответствует четвертому уровню модели OSI, также называемому транспортным уровнем.
QUIC быстро становится альтернативным транспортным протоколом. Хотя технически он передается через пакеты UDP, он стремится предложить улучшенную транспортную связь по сравнению с TCP. HTTP/3 работает исключительно через QUIC.
Уровень приложений включает протоколы, используемые большинством приложений для предоставления пользовательских услуг или обмена данными приложений через сетевые соединения, установленные протоколами более низкого уровня. Сюда могут входить некоторые базовые услуги поддержки сети, такие как протоколы маршрутизации и настройка хоста. Примеры протоколов прикладного уровня включают протокол передачи гипертекста (HTTP), протокол передачи файлов (FTP), простой протокол передачи почты (SMTP) и протокол динамической конфигурации хоста (DHCP). [40] Данные, закодированные в соответствии с протоколами прикладного уровня, инкапсулируются в блоки протоколов транспортного уровня (такие как потоки TCP или дейтаграммы UDP), которые, в свою очередь, используют протоколы нижнего уровня для осуществления фактической передачи данных.
Модель TCP/IP не учитывает особенности форматирования и представления данных и не определяет дополнительные уровни между прикладным и транспортным уровнями, как в модели OSI (уровни представления и сеансы). Согласно модели TCP/IP, такие функции относятся к сфере библиотек и интерфейсов прикладного программирования . Прикладной уровень в модели TCP/IP часто сравнивают с комбинацией пятого (сеансового), шестого (представления) и седьмого (прикладного) уровней модели OSI.
Протоколы прикладного уровня часто связаны с конкретными клиент-серверными приложениями, а общие службы имеют хорошо известные номера портов, зарезервированные Управлением по присвоению номеров Интернета (IANA). Например, протокол передачи гипертекста использует порт сервера 80, а Telnet использует порт сервера 23. Клиенты , подключающиеся к службе, обычно используют эфемерные порты , т. е. номера портов, назначаемые только на время транзакции случайным образом или из определенного диапазона, настроенного в приложение.
На уровне приложений модель TCP/IP различает пользовательские протоколы и протоколы поддержки . [41] Протоколы поддержки предоставляют услуги системе сетевой инфраструктуры. Пользовательские протоколы используются для реальных пользовательских приложений. Например, FTP — это пользовательский протокол, а DNS — протокол поддержки.
Хотя приложения обычно знают о ключевых качествах соединения транспортного уровня, таких как IP-адреса конечных точек и номера портов, протоколы прикладного уровня обычно рассматривают протоколы транспортного уровня (и ниже) как черные ящики , которые обеспечивают стабильное сетевое соединение, через которое можно обмениваться данными. . Транспортный уровень и уровни нижнего уровня не интересуются спецификой протоколов прикладного уровня. Маршрутизаторы и коммутаторы обычно не проверяют инкапсулированный трафик, а просто обеспечивают его канал. Однако некоторые брандмауэры и приложения регулирования пропускной способности используют глубокую проверку пакетов для интерпретации данных приложения. Примером является протокол резервирования ресурсов (RSVP). [ нужна цитата ] Приложениям, на которые влияет NAT, также иногда необходимо учитывать полезную нагрузку приложения.
Набор интернет-протоколов развивался благодаря исследованиям и разработкам, финансируемым в течение определенного периода времени. В этом процессе изменилась специфика компонентов протокола и их иерархия. Кроме того, за конструктивные особенности конкурировали параллельные исследования и коммерческие интересы отраслевых ассоциаций. В частности, усилия Международной организации по стандартизации привели к аналогичной цели, но в целом с более широким охватом сетей. Попытки консолидировать две основные школы многоуровневого образования, которые внешне были похожи, но резко расходились в деталях, побудили независимых авторов учебников сформулировать сокращенные инструменты обучения.
В следующей таблице показаны различные такие сетевые модели. Количество слоев варьируется от трех до семи.
Некоторые сетевые модели взяты из учебников, которые являются вторичными источниками и могут противоречить намерениям RFC 1122 и других первичных источников IETF . [50]
Три верхних уровня модели OSI, т.е. уровень приложений, уровень представления и сеансовый уровень, не выделяются отдельно в модели TCP/IP, в которой над транспортным уровнем имеется только уровень приложений. Хотя некоторые приложения чистого протокола OSI, такие как X.400 , также объединяют их, нет требования, чтобы стек протоколов TCP/IP навязывал монолитную архитектуру над транспортным уровнем. Например, протокол приложения NFS работает на основе протокола представления внешних данных (XDR), который, в свою очередь, работает на основе протокола, называемого удаленным вызовом процедур (RPC). RPC обеспечивает надежную передачу записей, поэтому он может безопасно использовать наиболее удобный транспорт UDP.
Разные авторы по-разному интерпретировали модель TCP/IP и не согласны с тем, охватывает ли канальный уровень или какой-либо аспект модели TCP/IP проблемы уровня 1 OSI ( физического уровня ) или же TCP/IP предполагает, что аппаратный уровень существует ниже уровня. слой связи.
Некоторые авторы пытались включить уровни 1 и 2 модели OSI в модель TCP/IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU ) . Это часто приводит к созданию модели с пятью уровнями, где канальный уровень или уровень доступа к сети разделен на уровни 1 и 2 модели OSI.
Усилия по разработке протокола IETF не связаны со строгим многоуровневым разделением. Некоторые из его протоколов могут не полностью вписываться в модель OSI, хотя RFC иногда ссылаются на них и часто используют старые номера уровней OSI. IETF неоднократно заявлял [ необходима ссылка ] , что разработка интернет-протокола и архитектуры не предназначена для обеспечения совместимости с OSI. RFC 3439, посвященный архитектуре Интернета, содержит раздел, озаглавленный: «Многослойность считается вредной».
Например, сеансовый уровень и уровень представления пакета OSI считаются включенными в прикладной уровень пакета TCP/IP. Функциональность сеансового уровня можно найти в таких протоколах, как HTTP и SMTP , и более очевидна в таких протоколах, как Telnet и протокол инициации сеанса (SIP). Функциональность сеансового уровня также реализуется с помощью нумерации портов протоколов TCP и UDP, которые включены в транспортный уровень пакета TCP/IP. Функции уровня представления реализованы в приложениях TCP/IP со стандартом MIME при обмене данными.
Другое отличие заключается в обработке протоколов маршрутизации . Протокол маршрутизации OSI IS-IS относится к сетевому уровню и не зависит от CLNS при доставке пакетов от одного маршрутизатора к другому, а определяет собственную инкапсуляцию уровня 3. Напротив, OSPF , RIP , BGP и другие протоколы маршрутизации, определенные IETF, передаются по IP, и с целью отправки и получения пакетов протокола маршрутизации маршрутизаторы действуют как хосты. Как следствие, RFC 1812 включает протоколы маршрутизации на прикладном уровне. Некоторые авторы, такие как Таненбаум в «Компьютерных сетях» , описывают протоколы маршрутизации на том же уровне, что и IP, мотивируя это тем, что протоколы маршрутизации определяют решения, принимаемые в процессе пересылки маршрутизаторов.
Протоколы IETF можно инкапсулировать рекурсивно, о чем свидетельствуют протоколы туннелирования, такие как Generic Routing Encapsulation (GRE). GRE использует тот же механизм, который OSI использует для туннелирования на сетевом уровне.
Набор интернет-протоколов не предполагает какой-либо конкретной аппаратной или программной среды. Для этого требуется только наличие аппаратного и программного уровня, способного отправлять и получать пакеты в компьютерной сети. В результате пакет был реализован практически на каждой вычислительной платформе. Минимальная реализация TCP/IP включает в себя следующее: Интернет-протокол (IP), протокол разрешения адресов (ARP), протокол управляющих сообщений Интернета (ICMP), протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и управление группами Интернета. Протокол (IGMP). В дополнение к IP, ICMP, TCP, UDP, Интернет-протокол версии 6 требует протокола обнаружения соседей (NDP), ICMPv6 и обнаружения прослушивателя многоадресной рассылки (MLD) и часто сопровождается встроенным уровнем безопасности IPSec .
Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана;
Д. Дэвис и Л. Пузен, конструктивно прокомментировавшие вопросы фрагментации и учета;
и С. Крокер, комментировавшие создание и разрушение ассоциаций.
В начале 1970-х годов Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании.
Ее простота и эффективность указали путь к сети, которая могла бы соединить не только десятки машин, но и миллионы из них.
Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые сейчас поддерживают Интернет.
Мы начали параллельное внедрение в Стэнфорде, BBN и Университетском колледже Лондона.
Таким образом, усилия по разработке интернет-протоколов с самого начала были международными.
Март '82 – Норвегия выходит из ARPANET и переходит в Интернет через TCP/IP через SATNET.
Ноябрь 2082 г. — UCL покидает ARPANET и становится подключением к Интернету.
сети.