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

Эта статья о протоколах, составляющих архитектуру Интернета. Только для сетевого протокола IP см. Протокол Интернета .
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой
  • ARP
  • Пнр
  • OSPF
  • Туннели
    • L2TP
  • PPP
  • MAC
    • Ethernet
    • Вай-фай
    • DSL
    • ISDN
    • FDDI
  • более...
  • v
  • т
  • е

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

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

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

История [ править ]

Ранние исследования [ править ]

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

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

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

Первоначально программа управления передачей управляла как передачей дейтаграмм, так и маршрутизацией, но по мере роста опыта работы с протоколом сотрудники рекомендовали разделить функциональность на уровни отдельных протоколов. Среди защитников были Джонатан Постел из Института информационных наук Университета Южной Калифорнии , который редактировал Request for Comments (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). который все еще используется в Интернете вместе с его нынешним преемником, Internet Protocol версии 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 году первая конференция Interop была посвящена сетевой совместимости за счет более широкого внедрения TCP / IP. Конференция была основана Дэном Линчем, одним из первых интернет-активистов. С самого начала на встрече присутствовали крупные корпорации, такие как IBM и DEC. [20]

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 . [21] Первый стек TCP / IP VM / CMS был разработан Университетом Висконсина. [22]

Некоторые из ранних стеков TCP / IP были написаны в одиночку несколькими программистами. Джей Элински и Олег Вишнепольский  [ ru ] из IBM Research написали стеки TCP / IP для VM / CMS и OS / 2 соответственно. [ необходима цитата ] В 1984 году Дональд Гиллис из Массачусетского технологического института написал протокол TCP с несколькими соединениями ntcp, который работал поверх уровня 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 Systems Network Architecture (SNA), так и на других платформах , таких как Digital Equipment Corporation «с DECnet , взаимодействие открытых систем (OSI) и Xerox Network Systems (XNS).

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

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

В технические стандарты , лежащие в основе набора протоколов Internet и его составляющие протоколы были делегированы Engineering Task Force Интернет (IETF).

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

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

См. Также: Протокол связи § Уровни программного обеспечения
Концептуальный поток данных в простой топологии сети из двух хостов ( A и 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровень приложения [ править ]

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

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

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

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

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

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

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

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

RFC 1122, Internet STD 3 (1989)Академия Cisco [36]Куросе, [37] Форузан [38]Комер, [39] Козерок [40]Ловушки [41]Таненбаум [42]Arpanet Reference Model (RFC 871)OSI model
Four layersFour layersFive layersFour+one layersFive layersFive layersThree layersSeven layers
"Internet model""Internet model""Five-layer Internet model" or "TCP/IP protocol suite""TCP/IP 5-layer reference model""TCP/IP model""TCP/IP 5-layer reference model""Arpanet reference model"OSI model
ApplicationApplicationApplicationApplicationApplicationApplicationApplication/ProcessApplication
Presentation
Session
TransportTransportTransportTransportHost-to-host or transportTransportHost-to-hostTransport
InternetInternetworkNetworkInternetInternetInternetNetwork
LinkNetwork interfaceData linkData link (Network interface)Network accessData linkNetwork interfaceData link
Physical(Hardware)PhysicalPhysicalPhysical

Some of the networking models are from textbooks, which are secondary sources that may conflict with the intent of RFC 1122 and other IETF primary sources.[43]

Comparison of TCP/IP and OSI layering[edit]

See also: OSI model § Comparison with TCP/IP model

The three top layers in the OSI model, i.e. the application layer, the presentation layer and the session layer, are not distinguished separately in the TCP/IP model which only has an application layer above the transport layer. While some pure OSI protocol applications, such as X.400, also combined them, there is no requirement that a TCP/IP protocol stack must impose monolithic architecture above the transport layer. For example, the NFS application protocol runs over the eXternal Data Representation (XDR) presentation protocol, which, in turn, runs over a protocol called Remote Procedure Call (RPC). RPC provides reliable record transmission, so it can safely use the best-effort UDP transport.

Different authors have interpreted the TCP/IP model differently, and disagree whether the link layer, or the entire TCP/IP model, covers OSI layer 1 (physical layer) issues, or whether a hardware layer is assumed below the link layer.

Several authors have attempted to incorporate the OSI model's layers 1 and 2 into the TCP/IP model, since these are commonly referred to in modern standards (for example, by IEEE and ITU). This often results in a model with five layers, where the link layer or network access layer is split into the OSI model's layers 1 and 2.

The IETF protocol development effort is not concerned with strict layering. Some of its protocols may not fit cleanly into the OSI model, although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated[citation needed] that Internet protocol and architecture development is not intended to be OSI-compliant. RFC 3439, referring to the Internet architecture, contains a section entitled: "Layering Considered Harmful".

For example, the session and presentation layers of the OSI suite are considered to be included to the application layer of the TCP/IP suite. The functionality of the session layer can be found in protocols like HTTP and SMTP and is more evident in protocols like Telnet and the Session Initiation Protocol (SIP). Session layer functionality is also realized with the port numbering of the TCP and UDP protocols, which cover the transport layer in the TCP/IP suite. Functions of the presentation layer are realized in the TCP/IP applications with the MIME standard in data exchange.

Conflicts are apparent also in the original OSI model, ISO 7498, when not considering the annexes to this model, e.g., the ISO 7498/4 Management Framework, or the ISO 8648 Internal Organization of the Network layer (IONL). When the IONL and Management Framework documents are considered, the ICMP and IGMP are defined as layer management protocols for the network layer. In like manner, the IONL provides a structure for "subnetwork dependent convergence facilities" such as ARP and RARP.

IETF protocols can be encapsulated recursively, as demonstrated by tunneling protocols such as Generic Routing Encapsulation (GRE). GRE uses the same mechanism that OSI uses for tunneling at the network layer.

Implementations[edit]

The Internet protocol suite does not presume any specific hardware or software environment. It only requires that hardware and a software layer exists that is capable of sending and receiving packets on a computer network. As a result, the suite has been implemented on essentially every computing platform. A minimal implementation of TCP/IP includes the following: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Group Management Protocol (IGMP). In addition to IP, ICMP, TCP, UDP, Internet Protocol version 6 requires Neighbor Discovery Protocol (NDP), ICMPv6, and IGMPv6 and is often accompanied by an integrated IPSec security layer.

Application programmers are typically concerned only with interfaces in the application layer and often also in the transport layer, while the layers below are services provided by the TCP/IP stack in the operating system. Most IP implementations are accessible to programmers through sockets and APIs.

Unique implementations include Lightweight TCP/IP, an open source stack designed for embedded systems, and KA9Q NOS, a stack and associated protocols for amateur packet radio systems and personal computers connected via serial lines.

Microcontroller firmware in the network adapter typically handles link issues, supported by driver software in the operating system. Non-programmable analog and digital electronics are normally in charge of the physical components below the link layer, typically using an application-specific integrated circuit (ASIC) chipset for each network interface or other physical standard. High-performance routers are to a large extent based on fast non-programmable digital electronics, carrying out link level switching.

See also[edit]

  • BBN Report 1822, an early layered network model
  • FLIP (protocol) (fast local Internet protocol stack)
  • List of automation protocols
  • List of information technology acronyms
  • List of IP protocol numbers
  • List of network protocols
  • List of TCP and UDP port numbers

Bibliography[edit]

  • Douglas E. Comer. Internetworking with TCP/IP – Principles, Protocols and Architecture. ISBN 86-7991-142-9
  • Joseph G. Davies and Thomas F. Lee. Microsoft Windows Server 2003 TCP/IP Protocols and Services. ISBN 0-7356-1291-9
  • Forouzan, Behrouz A. (2003). TCP/IP Protocol Suite (2nd ed.). McGraw-Hill. ISBN 978-0-07-246060-5.
  • Craig Hunt TCP/IP Network Administration. O'Reilly (1998) ISBN 1-56592-322-7
  • Maufer, Thomas A. (1999). IP Fundamentals. Prentice Hall. ISBN 978-0-13-975483-8.
  • Ian McLean. Windows(R) 2000 TCP/IP Black Book. ISBN 1-57610-687-X
  • Ajit Mungale Pro .NET 1.1 Network Programming. ISBN 1-59059-345-6
  • W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. ISBN 0-201-63346-9
  • W. Richard Stevens and Gary R. Wright. TCP/IP Illustrated, Volume 2: The Implementation. ISBN 0-201-63354-X
  • W. Richard Stevens. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. ISBN 0-201-63495-3
  • Andrew S. Tanenbaum. Computer Networks. ISBN 0-13-066102-3
  • Clark, D. (1988). "The Design Philosophy of the DARPA Internet Protocols". Symposium proceedings on Communications architectures and protocols - SIGCOMM '88 (PDF). SIGCOMM '88 Symposium Proceedings on Communications Architectures and Protocols. ACM. pp. 106–114. doi:10.1145/52324.52336. ISBN 978-0897912792. S2CID 6156615. Retrieved October 16, 2011.

References[edit]

  1. ^ a b Cerf, Vinton G. & Cain, Edward (1983), "The DoD Internet Architecture Model", Computer Networks, 7, North-Holland, pp. 307–318, CiteSeerX 10.1.1.88.7505
  2. ^ a b RFC 1122, Requirements for Internet Hosts – Communication Layers, R. Braden (ed.), October 1989.
  3. ^ RFC 1123, Requirements for Internet Hosts – Application and Support, R. Braden (ed.), October 1989
  4. ^ Abbate, Janet (2000). Inventing the Internet. MIT Press. pp. 123–4. ISBN 978-0-262-51115-5.
  5. ^ Cerf, V.; Kahn, R. (1974). "A Protocol for Packet Network Intercommunication" (PDF). IEEE Transactions on Communications. 22 (5): 637–648. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations.
  6. ^ "The internet's fifth man". Economist. December 13, 2013. Retrieved September 11, 2017. In the early 1970s Mr Pouzin created an innovative data network that linked locations in France, Italy and Britain. Its simplicity and efficiency pointed the way to a network that could connect not just dozens of machines, but millions of them. It captured the imagination of Dr Cerf and Dr Kahn, who included aspects of its design in the protocols that now power the internet.
  7. ^ Vinton Cerf, Yogen Dalal, Carl Sunshine (December 1974), RFC 675, Specification of Internet Transmission Control Protocol (December 1974)
  8. ^ Internet Hall of Fame
  9. ^ Panzaris, Georgios (2008). Machines and romances: the technical and narrative construction of networked computing as a general-purpose platform, 1960-1995. Stanford University. p. 128.
  10. ^ Pelkey, James L. (2007). "Yogen Dalal". Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968-1988. Retrieved September 5, 2019.
  11. ^ Postel, Jon (1977), "Section 3.3.3.2", Comments on Internet Protocol and TCP
  12. ^ "The TCP/IP Guide - TCP/IP Overview and History". www.tcpipguide.com. Retrieved February 11, 2020.
  13. ^ a b by Vinton Cerf, as told to Bernard Aboba (1993). "How the Internet Came to Be". Archived from the original on September 26, 2017. Retrieved September 25, 2017. We began doing concurrent implementations at Stanford, BBN, and University College London. So effort at developing the Internet protocols was international from the beginning. ... Mar '82 - Norway leaves the ARPANET and become an Internet connection via TCP/IP over SATNET. Nov '82 - UCL leaves the ARPANET and becomes an Internet connection.
  14. ^ RFC 1812, Requirements for IP Version 4 Routers, F. Baker (June 1995)
  15. ^ Crowell, William; Contos, Brian; DeRodeff, Colby (2011). Physical and Logical Security Convergence: Powered By Enterprise Security Management. Syngress. p. 99. ISBN 9780080558783.
  16. ^ Ronda Hauben. "From the ARPANET to the Internet". TCP Digest (UUCP). Retrieved July 5, 2007.
  17. ^ Martin, Olivier (2012). The "Hidden" Prehistory of European Research Networking. Trafford Publishing. ISBN 978-1466938724.
  18. ^ Kirstein, Peter T. "Early experiences with the ARPANET and Internet in the UK". Department of Computer Science, Systems and Networks Research Group, University College London. Retrieved April 13, 2016.
  19. ^ "TCP/IP Internet Protocol". Archived from the original on January 1, 2018. Retrieved December 31, 2017.
  20. ^ Leiner, Barry M.; et al. (1997), Brief History of the Internet (PDF), Internet Society, p. 15
  21. ^ Wollongong
  22. ^ "A Short History of Internet Protocols at CERN". Archived from the original on November 10, 2016. Retrieved September 12, 2016.
  23. ^ Baker, Steven; Gillies, Donald W. "Desktop TCP/IP at middle age".
  24. ^ Romkey, John (February 17, 2011). "About". Retrieved September 12, 2016.
  25. ^ Phil Karn, KA9Q TCP Download Website
  26. ^ Andrew L. Russell (July 30, 2013). "OSI: The Internet That Wasn't". IEEE Spectrum. Vol. 50 no. 8.
  27. ^ Russell, Andrew L. "Rough Consensus and Running Code' and the Internet-OSI Standards War" (PDF). IEEE Annals of the History of Computing. Archived from the original (PDF) on November 17, 2019.
  28. ^ a b Davies, Howard; Bressan, Beatrice (April 26, 2010). A History of International Research Networking: The People who Made it Happen. John Wiley & Sons. ISBN 978-3-527-32710-2.
  29. ^ Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world, Marjory S. Blumenthal, David D. Clark, August 2001
  30. ^ Jon Postel, ed. (September 1981). Internet Protocol DARPA Internet Program Protocol Specification. p. 23. doi:10.17487/RFC0791. RFC 791.
  31. ^ R. Braden, ed. (October 1989). Requirements for Internet Hosts – Communication Layers. p. 13. doi:10.17487/RFC1122. RFC 1122.
  32. ^ B. Carpenter, ed. (June 1996). Architectural Principles of the Internet. doi:10.17487/RFC1958. RFC 1958.
  33. ^ Hunt, Craig (2002). TCP/IP Network Administration (3rd ed.). O'Reilly. pp. 9–10. ISBN 9781449390785.
  34. ^ TCP/IP Illustrated: the protocols, ISBN 0-201-63346-9, W. Richard Stevens, February 1994
  35. ^ RFC 1122, Requirements for Internet Hosts – Communication Layers, 1.1.3 Internet Protocol Suite, 1989
  36. ^ Dye, Mark; McDonald, Rick; Rufi, Antoon (October 29, 2007). Network Fundamentals, CCNA Exploration Companion Guide. Cisco Press. ISBN 9780132877435. Retrieved September 12, 2016 – via Google Books.
  37. ^ James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 2008 ISBN 0-321-49770-8
  38. ^ Forouzan, Behrouz A.; Fegan, Sophia Chung (August 1, 2003). Data Communications and Networking. McGraw-Hill Higher Education. ISBN 9780072923544. Retrieved September 12, 2016 – via Google Books.
  39. ^ Comer, Douglas (January 1, 2006). Internetworking with TCP/IP: Principles, protocols, and architecture. Prentice Hall. ISBN 0-13-187671-6. Retrieved September 12, 2016 – via Google Books.
  40. ^ Kozierok, Charles M. (January 1, 2005). The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference. No Starch Press. ISBN 9781593270476. Retrieved September 12, 2016 – via Google Books.
  41. ^ Stallings, William (January 1, 2007). Data and Computer Communications. Prentice Hall. ISBN 978-0-13-243310-5. Retrieved September 12, 2016 – via Google Books.
  42. ^ Tanenbaum, Andrew S. (January 1, 2003). Computer Networks. Prentice Hall PTR. p. 42. ISBN 0-13-066102-3. Retrieved September 12, 2016 – via Internet Archive. networks.
  43. ^ RFC 3439, Some Internet Architectural Guidelines and Philosophy, R. Bush, D. Meyer (eds.), December 2002.

External links[edit]

  • Internet History – Pages on Robert Kahn, Vinton Cerf, and TCP/IP (reviewed by Cerf and Kahn).
  • RFC 675 – Specification of Internet Transmission Control Program, December 1974 Version
  • RFC 1180 A TCP/IP Tutorial – from the Internet Engineering Task Force (January 1991)
  • TCP/IP FAQ
  • The TCP/IP Guide – A comprehensive look at the protocols and the procedures/processes involved
  • A Study of the ARPANET TCP/IP Digest
  • TCP/IP Sequence Diagrams
  • Daryl's TCP/IP Primer – Intro to TCP/IP LAN administration, conversational style
  • Introduction to TCP/IP
  • A Protocol for Packet Network Intercommunication, Cerf & Kahn, IEEE Trans on Comms, Vol Com-22, No 5 May 1974