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

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

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

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

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

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

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

Пакет Интернет-протокола явился результатом исследований и разработок, проведенных Агентством перспективных исследовательских проектов Министерства обороны США ( DARPA ) в конце 1960-х годов. [3] После создания новаторской 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, который в общих чертах описывает четыре уровня абстракции . [1] Они выдержали испытание временем, поскольку IETF никогда не изменяла эту структуру. Как такая модель сети, Internet Protocol Suite предшествует модели OSI, более всеобъемлющей эталонной структуре для общих сетевых систем.

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

Концептуальный поток данных в простой сетевой топологии из двух хостов ( 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.

Уровень Интернета [ править ]

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 по надежному протоколу передачи данных, например, высокоуровневому управлению каналом передачи данных (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 и других первичных источников IETF . [43]

Сравнение уровней TCP / IP и OSI [ править ]

Три верхних уровня в модели 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 и протокол инициации сеанса (SIP). Функциональность сеансового уровня также реализована с помощью нумерации портов протоколов TCP и UDP, которые покрывают транспортный уровень в пакете TCP / IP. Функции уровня представления реализованы в приложениях TCP / IP со стандартом MIME при обмене данными.

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

Протоколы IETF могут быть рекурсивно инкапсулированы, что демонстрируется протоколами туннелирования, такими как Generic Routing Encapsulation (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) для каждого сетевого интерфейса или другого физического стандарта. Высокопроизводительные маршрутизаторы в значительной степени основаны на быстрой непрограммируемой цифровой электронике, выполняющей переключение на уровне каналов.

См. Также [ править ]

  • BBN Report 1822 , ранняя многоуровневая сетевая модель
  • FLIP (протокол) (стек быстрых локальных интернет-протоколов)
  • Список протоколов автоматизации
  • Список сокращений информационных технологий
  • Список номеров IP-протоколов
  • Список сетевых протоколов
  • Список номеров портов TCP и UDP

Библиография [ править ]

  • Дуглас Э. Комер . Межсетевое взаимодействие с TCP / IP - принципы, протоколы и архитектура . ISBN 86-7991-142-9 
  • Джозеф Г. Дэвис и Томас Ф. Ли. Протоколы и службы TCP / IP Microsoft Windows Server 2003 . ISBN 0-7356-1291-9 
  • Форузан, Бехруз А. (2003). Пакет протоколов TCP / IP (2-е изд.). Макгроу-Хилл. ISBN 978-0-07-246060-5.
  • Крейг Хант Сетевое администрирование TCP / IP . О'Рейли (1998) ISBN 1-56592-322-7 
  • Мафер, Томас А. (1999). Основы интеллектуальной собственности . Прентис Холл. ISBN 978-0-13-975483-8.
  • Ян Маклин. Windows (R) 2000 TCP / IP Черная книга . ISBN 1-57610-687-X 
  • Ajit Mungale Pro .NET 1.1 Сетевое программирование . ISBN 1-59059-345-6 
  • В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 1: Протоколы . ISBN 0-201-63346-9 
  • В. Ричард Стивенс и Гэри Р. Райт. Иллюстрированный TCP / IP, Том 2: Реализация . ISBN 0-201-63354-X 
  • В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 3: TCP для транзакций , HTTP , NNTP и протоколы домена UNIX . ISBN 0-201-63495-3 
  • Эндрю С. Таненбаум . Компьютерные сети . ISBN 0-13-066102-3 
  • Кларк, Д. (1988). "Философия проектирования Интернет-протоколов DARPA". Материалы симпозиума по коммуникационным архитектурам и протоколам - SIGCOMM '88 (PDF) . Материалы симпозиума SIGCOMM '88 по архитектурам и протоколам связи . ACM . С. 106–114. DOI : 10.1145 / 52324.52336 . ISBN 978-0897912792. S2CID  6156615 . Проверено 16 октября 2011 года .

Ссылки [ править ]

  1. ^ a b RFC 1122, Требования к Интернет-хостам - Уровни связи , Р. Брейден (ред.), октябрь 1989 г.
  2. ^ RFC 1123, Требования к Интернет-хостам - Применение и поддержка , Р. Брейден (редактор), октябрь 1989 г.
  3. ^ Серф, Винтон Г. и Каин, Эдвард (1983), «Модель архитектуры Интернета Министерства обороны США», Компьютерные сети , 7, Северная Голландия, стр. 307–318, CiteSeerX 10.1.1.88.7505 
  4. ^ Аббат, Janet (2000). Изобретая Интернет . MIT Press. С. 123–4. ISBN 978-0-262-51115-5.
  5. ^ Cerf, V .; Кан Р. (1974). «Протокол межсетевого взаимодействия в пакетной сети» (PDF) . Транзакции IEEE по коммуникациям . 22 (5): 637–648. DOI : 10.1109 / TCOM.1974.1092259 . ISSN 1558-0857 . Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузин, конструктивно прокомментировавшие проблемы фрагментации и учета; и С. Крокер, который прокомментировал создание и разрушение ассоциаций.  
  6. ^ "Пятый человек Интернета" . Экономист . 13 декабря 2013 . Проверено 11 сентября 2017 года . В начале 1970-х годов г-н Пузен создал инновационную сеть передачи данных, которая связала места во Франции, Италии и Великобритании. Его простота и эффективность указали путь к сети, которая могла бы соединить не просто десятки машин, а миллионы из них. Он захватил воображение доктора Серфа и доктора Кана, которые включили аспекты его конструкции в протоколы, которые теперь используются в Интернете.
  7. ^ Винтон Серф , Йоген Далал , Карл Саншайн (декабрь 1974 г.), RFC 675 , Спецификация протокола управления передачей через Интернет (декабрь 1974 г.) 
  8. ^ Интернет-зал славы
  9. ^ Panzaris Георгиос (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. ^ a b Винтоном Серфом, как сказал Бернар Абоба (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" . Архивировано из оригинала на 1 января 2018 года . Проверено 31 декабря 2017 года .
  20. ^ Leiner, Барри М .; и другие. (1997), Краткая история Интернета (PDF) , Internet Society , стр. 15
  21. ^ Вуллонгонг
  22. ^ "Краткая история Интернет-протоколов в ЦЕРНе" . Архивировано из оригинального 10 ноября 2016 года . Проверено 12 сентября 2016 года .
  23. ^ Бейкер, Стивен; Гиллис, Дональд В. «Настольный TCP / IP в среднем возрасте» .
  24. ^ Romkey, Джон (17 февраля 2011). «О» . Проверено 12 сентября 2016 года .
  25. ^ Фил Карн, веб-сайт загрузки TCP KA9Q
  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. DOI : 10,17487 / RFC0791 . RFC 791 .
  31. ^ Р. Брейден, изд. (Октябрь 1989 г.). Требования к Интернет-хостам - Уровни связи . п. 13. DOI : 10,17487 / RFC1122 . RFC 1122 .
  32. ^ Б. Карпентер, изд. (Июнь 1996 г.). Архитектурные принципы Интернета . DOI : 10,17487 / RFC1958 . RFC 1958 .
  33. ^ Хант, Крейг (2002). Сетевое администрирование TCP / IP (3-е изд.). О'Рейли. С. 9–10. ISBN 9781449390785.
  34. ^ TCP / IP Illustrated: протоколы , ISBN 0-201-63346-9 , W. Ричард Стивенс, февраль 1994 г. 
  35. ^ RFC 1122 , Требования к Интернет-хостам - Уровни связи , 1.1.3 Internet Protocol Suite , 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 г.). Передача данных и создание сетей . Макгроу-Хилл Высшее образование. ISBN 9780072923544. Проверено 12 сентября 2016 г. - через Google Книги.
  39. ^ Comer, Douglas (1 января 2006). Межсетевое взаимодействие с TCP / IP: принципы, протоколы и архитектура . Прентис Холл. ISBN 0-13-187671-6. Проверено 12 сентября 2016 г. - через Google Книги.
  40. ^ Kozierok, Чарльз М. (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.

Внешние ссылки [ править ]

  • История Интернета - страницы Роберта Кана, Винтона Серфа и TCP / IP (обзор Серф и Кан).
  • RFC 675 - Спецификация программы управления передачей через Интернет, версия от декабря 1974 г.
  • RFC 1180 A TCP / IP Tutorial - from the Internet Engineering Task Force (январь 1991 г.)
  • TCP / IP часто задаваемые вопросы
  • Руководство по TCP / IP - всесторонний обзор протоколов и задействованных процедур / процессов
  • Исследование ARPANET TCP / IP Digest
  • Диаграммы последовательности TCP / IP
  • Учебник по TCP / IP Дэрила - Введение в администрирование TCP / IP LAN, разговорный стиль
  • Введение в TCP / IP
  • Протокол для межсетевого взаимодействия в пакетной сети, Cerf & Kahn, IEEE Trans on Comms, Vol Com-22, No 5 мая 1974 г.