Датаграмма
Дейтаграмма сетью — это базовая единица передачи, связанная с с коммутацией пакетов . Дейтаграммы обычно структурируются по разделам заголовка и полезной нагрузки . Дейтаграммы предоставляют услугу связи без установления соединения в сети с коммутацией пакетов. Доставка, время прибытия и порядок прибытия дейтаграмм не должны гарантироваться сетью.
История
[ редактировать ]В начале 1970-х годов термин «дейтаграмма» был создан путем объединения слов «данные» и «телеграмма» докладчиком CCITT по коммутации пакетов. [1] Халвор Ботнер-Бай . [2] [3] Хотя это слово было новым, концепция уже имела долгую историю.
В 1964 году Пол Бэран описал в отчете корпорации RAND гипотетическую военную сеть, которая должна противостоять ядерной атаке. Небольшие стандартизированные блоки сообщений , содержащие адреса источника и назначения, хранились и пересылались в компьютерных узлах ячеистой компьютерной сети с высокой избыточностью. [4] «Пользователь сети, который установил виртуальное соединение с конечной станцией и передал сообщения... может также рассматривать систему как черный ящик, обеспечивающий видимое соединение по цепи».
В 1967 году Дональд Дэвис опубликовал плодотворную статью, в которой представил пакет и коммутацию пакетов . [5] Предложенная им базовая сеть аналогична сети, предложенной Полом Бараном, хотя и разработана независимо. Он предполагает, что «все пользователи сети обеспечат себе некоторую защиту от ошибок». Его цель - «сеть связи с общей несущей». Для поддержки удаленного доступа пользовательских терминалов к компьютерным сервисам, которые в то время передавались посимвольно, он включил на периферию сети интерфейсные компьютеры, преобразующие потоки символов в потоки пакетов и наоборот.
В 1970 году Лоуренс Робертс и Барри Д. Весслер опубликовали статью об ARPANET , первой многоузловой сети с коммутацией пакетов. [6] В сопроводительном документе описаны узлы коммутации ( IMP ) и форматы пакетов. [7] Ядро сети осуществляло коммутацию датаграмм, как в модели Бэрана и Дэвиса, но услуги, предлагаемые хостам в сети, были ориентированы на соединение . [8] [9] Таким образом, пользовательским компьютерам была предложена надежная служба передачи сообщений, что значительно упростило проект сети. В результате ARPANET стала называться сетью виртуальных каналов . [10]
Робертс представил идею коммутации пакетов профессионалам в области связи и столкнулся с гневом и враждебностью. До того, как ARPANET заработала, они утверждали, что буферы маршрутизатора быстро закончатся. После того, как ARPANET заработала, они утверждали, что коммутация пакетов никогда не будет экономически выгодной без государственных субсидий. Бэран столкнулся с таким же отказом и поэтому не смог убедить военных построить сеть с коммутацией пакетов. [11]
В 1973 году Луи Пузен представил свой проект CYCLADES , первой крупномасштабной сети, реализующей чистую модель дейтаграмм Дэвиса. [12] Таким образом, команда CYCLADES первой решила очень сложную проблему предоставления пользовательским приложениям надежного виртуальных каналов . сервиса [13] при использовании сквозного принципа в сетевой службе, которая, как известно, может привести к значительным потерям и переупорядочению датаграмм. [14] Хотя Пузен заботится «на первом этапе не о прорыве [sic] в технологии коммутации пакетов, а о создании надежного средства связи для Киклад», [12] два члена его команды, Юбер Циммерман и Жерар Ле Ланн , внесли значительный вклад в разработку протокола TCP Интернета, что признал Винт Серф , его главный разработчик. [15]
В 1981 году Агентство передовых оборонных исследовательских проектов ( DARPA ) выпустило первую спецификацию Интернет-протокола (IP). Он представил значительную эволюцию концепции дейтаграмм: фрагментацию . [16] При фрагментации некоторые части глобальной сети могут использовать пакеты большого размера (обычно локальные сети для минимизации накладных расходов на обработку), тогда как некоторые другие могут использовать меньшие размеры пакетов (обычно глобальные сети для минимизации времени ответа). Сетевые узлы могут фрагментировать дейтаграмму на несколько более мелких пакетов.
В 1999 году Инженерная группа Интернета (IETF) санкционировала использование уже широко распространенной трансляции сетевых адресов (NAT), при которой каждый публичный адрес может использоваться несколькими частными устройствами. [17] Благодаря этому предстоящее исчерпание интернет-адресов было отложено, оставив достаточно времени для внедрения IPv6 , нового поколения интернет-протокола, поддерживающего более длинные адреса. Первоначальный принцип полной сквозной прозрачности сети для дейтаграмм был для этого смягчен: узлы NAT должны были управлять состояниями каждого соединения, что делало их частично ориентированными на соединения .
В 2015 году IETF обновил свою информационную базу 1998 года. RFC 2309 , согласно которому узлы коммутации дейтаграмм выполняют активное управление очередями (AQM), чтобы сделать его более сильной и подробной рекомендацией по лучшей текущей практике посредством публикации РФК 7567 . Хотя первоначальная модель организации очередей дейтаграмм была проста в реализации и требовала не более настройки, чем длина очередей, поддержка более сложных и параметризованных механизмов оказалась необходимой «для улучшения и сохранения производительности Интернета» ( RED , ECN и т. д.). Также требовалось провести дальнейшие исследования по этому вопросу с составлением списка выявленных предметов. [18]
Определение
[ редактировать ]Термин «дейтаграмма» определяется следующим образом: [19]
«Автономный, независимый объект данных, несущий достаточную информацию для маршрутизации от источника к компьютеру назначения без зависимости от более раннего обмена между этим источником и компьютером назначения и транспортной сетью».
— RFC 1594
Дейтаграмма должна быть автономной, не полагаясь на более ранние обмены, поскольку между двумя точками связи нет соединения фиксированной продолжительности, как, например, в большинстве голосовых телефонных разговоров. [20]
Службу дейтаграмм часто сравнивают со службой доставки почты; пользователь предоставляет только адрес назначения, но не получает никаких гарантий доставки и подтверждения при успешном получении. Поэтому служба дейтаграмм считается ненадежной . Служба дейтаграмм маршрутизирует дейтаграммы без предварительного создания заранее определенного пути. Поэтому служба дейтаграмм считается не требующей установления соединения . Также не учитывается порядок отправки и получения этой и других дейтаграмм. Фактически, многие дейтаграммы в одной группе могут путешествовать по разным путям, прежде чем достигнут одного и того же пункта назначения в разном порядке . [21]
Структура
[ редактировать ]Каждая дейтаграмма состоит из двух компонентов: заголовка данных и полезных . Заголовок содержит всю информацию, достаточную для маршрутизации от исходного оборудования к месту назначения без необходимости предварительного обмена между оборудованием и сетью. Заголовки могут включать адреса источника и назначения, а также поля типа и длины . Полезная нагрузка — это данные, которые необходимо передать. Этот процесс вложения полезных данных в тегированный заголовок называется инкапсуляцией .
Примеры
[ редактировать ]| Уровень OSI | Имя |
|---|---|
| Слой 4 | TCP-сегмент |
| Слой 3 | Сетевой пакет |
| Слой 2 | Кадр Ethernet (IEEE 802.3) Кадр беспроводной локальной сети (IEEE 802.11) |
| Слой 1 | Чип (CDMA) |
Интернет-протокол
[ редактировать ]Интернет -протокол (IP) определяет стандарты для нескольких типов дейтаграмм. Интернет -уровень — это служба дейтаграмм, предоставляемая IP. Например, UDP запускается службой датаграмм на интернет-уровне. IP — это ненадежная служба доставки сообщений, не требующая установления соединения. TCP — это протокол более высокого уровня, работающий поверх IP и обеспечивающий надежный сервис, ориентированный на соединение.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «CCITT изучает коммутацию пакетов как часть развития сети передачи данных общего пользования» .
- ^ Реми Депре (ноябрь 2010 г.). «Виртуальные каналы X.25 — Transpac во Франции — сети передачи данных до Интернета» . Журнал коммуникаций IEEE . 48 (10). дои : 10.1109/MCOM.2010.5621965 .
- ^ «Comment j'ai inventé le Datagramme» (на французском языке). Архивировано из оригинала 28 февраля 2019 г.
- ^ «О распределенных сетях связи» (PDF) . Архивировано из оригинала (PDF) 26 октября 2016 г.
- ^ «Цифровая сеть связи для компьютеров, обеспечивающая быстрое реагирование на удаленных терминалах» (PDF) . Архивировано (PDF) из оригинала 9 октября 2022 г.
- ^ Лоуренс Робертс; Барри Д. Весслер (1970). «Развитие компьютерной сети для достижения совместного использования ресурсов» . Материалы весенней совместной компьютерной конференции AFIPS '70 (весна) , состоявшейся 5–7 мая 1970 г. п. 543. дои : 10.1145/1476936.1477020 . S2CID 9343511 .
- ^ Фрэнк Э. Харт; Р.Э. Кан; Северо М. Орнштейн; Уильям Р. Кроутер; Дэвид С. Уолден (1970). «Процессор интерфейсных сообщений компьютерной сети ARPA» . Материалы весенней совместной компьютерной конференции AFIPS '70 (весна) , состоявшейся 5–7 мая 1970 г. п. 551. дои : 10.1145/1476936.1477021 . S2CID 9647377 .
- ^ «Характеристики ПРОЦЕССОРА ИНТЕРФЕЙСНЫХ СООБЩЕНИЙ для межсетевого соединения хоста» (PDF) . Январь 2014 г.
три параметра однозначно определяют соединение между исходным и конечным хостами.» «Конечный IMP возвращает положительное подтверждение получения сообщения исходному IMP, который, в свою очередь, передает это подтверждение исходному хосту». «Каждая ссылка однонаправленный и контролируется сетью, поэтому по нему может быть отправлено не более одного сообщения за раз.
- ^ Пелки, Джеймс. «8.4 Протокол управления передачей (TCP) 1973-1976» . Предпринимательский капитализм и инновации: история компьютерных коммуникаций 1968–1988 гг .
Однако у Arpanet были свои недостатки, поскольку она не была настоящей дейтаграммной сетью и не обеспечивала сквозного исправления ошибок.
- ^ «Интервью с ЛУИ ПУЗЕНОМ, проведенное Эндрю Л. Расселом» (PDF) . Апрель 2012.
Arpanet представлял собой виртуальный канал. «По сути, это служба виртуальных каналов, использующая внутренние дейтаграммы.
- ^ Робертс, Л. (1988-01-01), «Арпанет и компьютерные сети» , История персональных рабочих станций , Нью-Йорк, Нью-Йорк, США: Ассоциация вычислительной техники, стр. 141–172, doi : 10.1145/61975.66916 , ISBN 978-0-201-11259-7 , получено 30 ноября 2023 г.
- ^ Jump up to: а б Пузен, Луи. «Презентация и основные аспекты проектирования сети Киклад» . Архивировано из оригинала 27 сентября 2007 года.
- ^ Расширение TCP для транзакций – Концепции . дои : 10.17487/RFC1379 . РФК 1379 .
- ^ Беннетт, Ричард (сентябрь 2009 г.). «Создан для перемен: сквозные аргументы, интернет-инновации и дебаты о сетевом нейтралитете» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11 . Проверено 11 сентября 2017 г.
- ^ В. Серф ; Ю. Далал ; К. Саншайн (декабрь 1974 г.). СПЕЦИФИКАЦИЯ ПРОГРАММЫ УПРАВЛЕНИЯ ИНТЕРНЕТ-ПЕРЕДАЧЕЙ . Сетевая рабочая группа. дои : 10.17487/RFC0675 . РФК 675 . Устаревший. Устарело РФК 7805 . NIC 2. INWG 72.
- ^ Дж. Постель , изд. (сентябрь 1981 г.). ИНТЕРНЕТ-ПРОТОКОЛ — СПЕЦИФИКАЦИЯ ПРОТОКОЛА ИНТЕРНЕТ-ПРОГРАММЫ DARPA . IETF . дои : 10.17487/RFC0791 . СТД 5. RFC 791 . IEN 128, 123, 111, 80, 54, 44, 41, 28, 26. Интернет-стандарт 5. Устарело . RFC 760. Updated by RFC 1349 , 2474 и 6864 .
- ^ П. Шрисуреш; М. Холдредж (август 1999 г.). Терминология и соображения по транслятору сетевых адресов IP (NAT) . Сетевая рабочая группа. дои : 10.17487/RFC2663 . РФК 2663 . Информационный.
- ^ Ф. Бейкер ; Г. Фэйрхерст, ред. (июль 2015 г.). Рекомендации IETF относительно активного управления очередями . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC7567 . ISSN 2070-1721 . BCP 197. RFC 7567 . Лучшая современная практика. Устаревшие РФК 2309 .
- ^ А. Марин; Дж. Рейнольдс ; Г. Малкин (март 1994 г.). К вашему сведению, вопросы и ответы — ответы на часто задаваемые вопросы «новых пользователей Интернета» . Сетевая рабочая группа. дои : 10.17487/RFC1594 . К вашему сведению 4. RFC 1594 . Устаревший. Устарело RFC 2664. Obsoletes РФК 1325 .
- ^ Таненбаум, Эндрю С.; Уэтералл, Дэвид Дж. (2011). Компьютерные сети, пятое издание . Пирсон. п. 59. ИСБН 978-0-13-255317-9 .
- ^ Метрики переупорядочения пакетов . Ноябрь 2006 г. doi : 10.17487/RFC4737 . РФК 4737 .