Датаграмма
Дейтаграмма сетью — это базовая единица передачи, связанная с с коммутацией пакетов . Дейтаграммы обычно структурируются по разделам заголовка и полезной нагрузки . Дейтаграммы предоставляют услугу связи без установления соединения в сети с коммутацией пакетов. Доставка, время прибытия и порядок прибытия дейтаграмм не должны гарантироваться сетью.
История [ править ]
В начале 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 г.
- ↑ Перейти обратно: Перейти обратно: а б Пузен, Луи. «Презентация и основные аспекты проектирования сети Киклад» . Архивировано из оригинала 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 . RFC 4737 .