Принцип сквозного соединения — это структура проектирования компьютерных сетей . В сетях, спроектированных в соответствии с этим принципом, обеспечение определенных функций, специфичных для приложений, таких как надежность и безопасность, требует, чтобы они находились в конечных узлах связи сети. Промежуточные узлы, такие как шлюзы и маршрутизаторы , которые существуют для установления сети, могут реализовывать их для повышения эффективности, но не могут гарантировать корректность сквозного соединения.
Суть того, что позже назовут принципом «от конца до конца», содержалась в работе Дональда Дэвиса по сетям с коммутацией пакетов в 1960-х годах. Луи Пузен был пионером использования стратегии «от конца до конца» в сети CYCLADES в 1970-х годах. [1] Принцип был впервые четко сформулирован в 1981 году Солцером , Ридом и Кларком . [2] [a] Значение принципа «от конца до конца» постоянно переосмысливалось с момента его первоначальной формулировки. Кроме того, заслуживающие внимания формулировки принципа «от конца до конца» можно найти до основополагающей статьи Солцера, Рида и Кларка 1981 года. [3]
Основная предпосылка принципа заключается в том, что выигрыши от добавления определенных функций, требуемых конечным приложением, в подсистему связи быстро уменьшаются. Конечные хосты должны реализовать эти функции для корректности. [b] Реализация определенной функции влечет за собой некоторые штрафы за ресурсы независимо от того, используется функция или нет, а реализация определенной функции в сети добавляет эти штрафы всем клиентам, независимо от того, нужна им эта функция или нет.
Концепция
Фундаментальное понятие принципа сквозной связи заключается в том, что для двух процессов , взаимодействующих друг с другом посредством некоторых средств связи, нельзя ожидать, что надежность, полученная от этих средств, будет идеально соответствовать требованиям надежности процессов. В частности, выполнение или превышение очень высоких требований надежности взаимодействующих процессов, разделенных сетями нетривиального размера, обходится дороже, чем получение требуемой степени надежности с помощью положительных сквозных подтверждений и повторных передач (называемых PAR или ARQ ). [c] Иными словами, гораздо проще получить надежность сверх определенного предела с помощью механизмов в конечных узлах сети, а не в промежуточных узлах , [d] особенно когда последние находятся вне контроля и не подотчетны первым. [e] Положительные сквозные подтверждения с бесконечными повторными попытками могут обеспечить произвольно высокую надежность из любой сети с вероятностью успешной передачи данных с одного конца на другой выше нуля. [f]
Принцип сквозного соединения не распространяется на функции, выходящие за рамки контроля и исправления ошибок сквозного соединения и безопасности. Например, нельзя привести прямые аргументы сквозного соединения для таких параметров связи, как задержка и пропускная способность . В статье 2001 года Блюменталь и Кларк отмечают: «С самого начала аргументы сквозного соединения вращались вокруг требований, которые могли быть правильно реализованы в конечных точках; если реализация внутри сети является единственным способом выполнения требования, то аргумент сквозного соединения изначально не подходит». [7] : 80
Принцип «от конца к концу» тесно связан с принципом сетевой нейтральности и иногда рассматривается как его прямой предшественник . [8]
История
В 1960-х годах Пол Баран и Дональд Дэвис в своих пред- ARPANET разработках сетей высказали замечания о надежности. В статье Барана 1964 года говорится: «Надежность и частота ошибок являются вторичными. Сеть должна быть построена с учетом ожидаемого серьезного ущерба в любом случае. Существуют эффективные методы устранения ошибок». [9] : 5 Идя дальше, Дэвис уловил суть принципа «от конца к концу»; в своей статье 1967 года он заявил, что пользователи сети обеспечат себя контролем ошибок: «Считается, что все пользователи сети обеспечат себя каким-то контролем ошибок, и что без труда это можно сделать, чтобы обнаружить отсутствующий пакет. Из-за этого потеря пакетов, если она достаточно редка, может быть терпима». [10] : 2.3
ARPANET была первой крупномасштабной сетью с коммутацией пакетов общего назначения, реализующей несколько концепций, ранее сформулированных Бараном и Дэвисом. [11] [12]
Дэвис построил локальную сеть с одним пакетным коммутатором и работал над моделированием глобальных сетей датаграмм . [13] [14] [15] Основываясь на этих идеях и стремясь улучшить реализацию в ARPANET, [15] сеть CYCLADES Луи Пузена была первой, которая реализовала датаграммы в глобальной сети и сделала хосты ответственными за надежную доставку данных, а не за централизованную службу самой сети. [1] Концепции, реализованные в этой сетевой функции в архитектуре TCP/IP . [16]
Приложения
ARPANET
ARPANET продемонстрировал несколько важных аспектов принципа сквозной связи.
Пакетная коммутация переносит некоторые логические функции в конечные точки связи.
Если базовая предпосылка распределенной сети — коммутация пакетов, то такие функции, как переупорядочение и обнаружение дубликатов, неизбежно должны быть реализованы в логических конечных точках такой сети. Следовательно, ARPANET отличался двумя различными уровнями функциональности:
более низкий уровень, отвечающий за транспортировку пакетов данных между соседними сетевыми узлами (называемые процессорами интерфейсных сообщений или IMP), и
более высокий уровень, связанный с различными сквозными аспектами передачи данных. [g]
Дэйв Кларк, один из авторов статьи о принципе сквозной связи, заключает: «Обнаружение пакетов не является следствием аргумента сквозной связи. Именно успех пакетов делает аргумент сквозной связи актуальным». [19] : слайд 31
Невозможность произвольно надежной передачи данных без механизмов сквозного подтверждения и повторной передачи.
ARPANET был разработан для обеспечения надежной передачи данных между любыми двумя конечными точками сети — во многом подобно простому каналу ввода-вывода между компьютером и близлежащим периферийным устройством. [h] Для устранения любых потенциальных сбоев пакетной передачи обычные сообщения ARPANET передавались от одного узла к другому с положительным подтверждением и схемой повторной передачи; после успешной передачи они затем отбрасывались, [i] повторная передача от источника к месту назначения в случае потери пакета не предусматривалась. Однако, несмотря на значительные усилия, идеальную надежность, предусмотренную в первоначальной спецификации ARPANET, оказалось невозможно обеспечить — реальность, которая стала все более очевидной, когда ARPANET значительно вышла за пределы своей первоначальной четырехузловой топологии. [j] Таким образом, ARPANET предоставила веские аргументы в пользу неотъемлемых ограничений сетевых механизмов надежности «скачк-скачком» в стремлении к истинной сквозной надежности. [k]
Компромисс между надежностью, задержкой и пропускной способностью
Стремление к идеальной надежности может нанести ущерб другим важным параметрам передачи данных – наиболее важным задержкам и пропускной способности. Это особенно важно для приложений, которые ценят предсказуемую пропускную способность и низкую задержку больше, чем надежность – классический пример – интерактивные голосовые приложения в реальном времени. Этот вариант использования был реализован в ARPANET путем предоставления службы необработанных сообщений, которая обходилась без различных мер надежности, чтобы обеспечить более быструю и низкую задержку передачи данных конечным хостам. [l]
TCP/IP
Интернет-протокол (IP) — это служба датаграмм без установления соединения без гарантий доставки . В Интернете IP используется практически для всех коммуникаций. Сквозное подтверждение и повторная передача данных являются обязанностью ориентированного на соединение протокола управления передачей (TCP), который находится поверх IP. Функциональное разделение между IP и TCP является примером правильного применения принципа сквозного соединения к проектированию транспортного протокола.
Передача файлов
Примером принципа end-to-end является принцип произвольно надежной передачи файлов между двумя конечными точками в распределенной сети переменного, нетривиального размера: [3] Единственный способ, которым две конечные точки могут получить полностью надежную передачу, — это передача и подтверждение контрольной суммы для всего потока данных; в такой обстановке меньшие протоколы контрольной суммы и подтверждения ( ACK /NACK) оправданы только в целях оптимизации производительности — они полезны для подавляющего большинства клиентов, но недостаточны для выполнения требования надежности этого конкретного приложения. Поэтому тщательная контрольная сумма лучше всего выполняется в конечных точках, и сеть поддерживает относительно низкий уровень сложности и разумную производительность для всех клиентов. [3]
Ограничения
Самым важным ограничением принципа «от конца к концу» является то, что его базовая предпосылка — размещение функций в конечных точках приложения, а не в промежуточных узлах — не является тривиальной для реализации.
Пример ограничений принципа «от конца к концу» существует в мобильных устройствах, например, с мобильным IPv6 . [27] Передача сложности, специфичной для сервиса, конечным точкам может вызвать проблемы с мобильными устройствами, если устройство имеет ненадежный доступ к сетевым каналам. [28]
Дальнейшие проблемы можно увидеть с уменьшением прозрачности сети из-за добавления трансляции сетевых адресов (NAT), на которую IPv4 полагается для борьбы с исчерпанием адресов . [29] С введением IPv6 пользователи снова имеют уникальные идентификаторы, что позволяет обеспечить настоящую сквозную связь. Уникальные идентификаторы могут быть основаны на физическом адресе или могут быть сгенерированы хостом случайным образом. [30]
Принцип «от начала до конца» выступает за продвижение функциональности, связанной с координацией, все выше, в конечном счете, на уровень приложений. Предпосылка заключается в том, что информация на уровне приложений обеспечивает гибкую координацию между конечными точками приложений и обеспечивает лучшую производительность, поскольку координация будет именно такой, какая нужна. Это приводит к идее моделирования каждого приложения с помощью его собственного протокола, специфичного для приложения, который поддерживает желаемую координацию между его конечными точками, предполагая при этом только простую службу связи нижнего уровня. В широком смысле эта идея известна как семантика приложения (смысл).
Многоагентные системы предлагают подходы, основанные на семантике приложений, которые позволяют удобно реализовывать распределенные приложения, не требуя упорядочивания сообщений и гарантий доставки от базовых служб связи. Основная идея этих подходов заключается в моделировании координации между конечными точками приложений через информационный протокол [31] и последующей реализации конечных точек (агентов) на основе протокола. Информационные протоколы могут быть реализованы через неупорядоченные службы связи с потерями. Промежуточное программное обеспечение, основанное на информационных протоколах и связанной модели программирования, абстрагирует прием сообщений от базовой сети и позволяет программистам конечных точек сосредоточиться на бизнес-логике для отправки сообщений.
^ Статья 1981 года [2] была опубликована в TOCS ACM в обновленной версии в 1984 году. [3] [4]
^ Полная цитата из статьи Солцера, Рида, Кларка гласит: [3] «В системе, которая включает коммуникации, обычно проводится модульная граница вокруг подсистемы коммуникации и определяется жесткий интерфейс между ней и остальной частью системы. При этом становится очевидным, что существует список функций, каждая из которых может быть реализована любым из нескольких способов: подсистемой коммуникации, ее клиентом, как совместное предприятие или, возможно, избыточно, каждая из которых выполняет свою собственную версию. При рассуждении об этом выборе требования приложения дают основу для следующего класса аргументов: Рассматриваемая функция может быть полностью и правильно реализована только с учетом и помощью приложения, находящегося в конечных точках системы коммуникации. Следовательно, предоставление этой сомнительной функции как функции самой системы коммуникации невозможно и, более того, приводит к снижению производительности для всех клиентов системы коммуникации. (Иногда неполная версия функции, предоставляемая системой коммуникации, может быть полезна для повышения производительности.) Мы называем эту линию рассуждений против реализации низкоуровневой функции сквозной аргумент." (стр. 278).
^ Фактически, даже в локальных сетях существует ненулевая вероятность сбоя связи – «независимо от стратегии управления сетью требуется уделять внимание надежности на более высоких уровнях». [5]
^ Говоря экономическим языком, предельная стоимость дополнительной надежности в сети превышает предельную стоимость получения той же дополнительной надежности мерами в конечных хостах. Экономически эффективный уровень повышения надежности внутри сети зависит от конкретных обстоятельств; однако он, безусловно, далек от нуля: [3] «Очевидно, что некоторые усилия на нижних уровнях по повышению надежности сети могут оказать существенное влияние на производительность приложений. (стр. 281)».
^ Несмотря на возможность принудительного исполнения договорных мер, невозможно для любой сети, в которой промежуточные ресурсы распределяются недетерминированным образом, гарантировать идеальную надежность. В лучшем случае она может ссылаться на статистические средние показатели производительности.
^ Точнее: [6] «THM 1: Правильно функционирующий протокол PAR с бесконечным числом повторов никогда не допускает сбоев при доставке, потери или дублирования сообщений. COR 1A: Правильно функционирующий протокол PAR с конечным числом повторов никогда не допускает потерь или дублирования сообщений, а вероятность сбоя доставки сообщения может быть сделана отправителем сколь угодно малой» (стр. 3).
^ В соответствии с запросом предложений ARPANET [17] (стр. 47 и далее) ARPANET концептуально разделила некоторые функции. Как указывает BBN в статье 1977 года: [18] «[Реализация] сети ARPA использует технику разбиения сообщений на пакеты, чтобы минимизировать задержку, наблюдаемую при длительных передачах через множество переходов. Реализация сети ARPA также позволяет нескольким сообщениям одновременно передаваться между заданной парой хостов. Однако несколько сообщений и пакеты внутри сообщений могут прибывать в IMP назначения не по порядку, а в случае поломки IMP или линии могут быть дубликаты. Задача процедуры передачи от источника к месту назначения в сети ARPA заключается в переупорядочивании пакетов и сообщений в месте назначения, отбраковке дубликатов и после того, как все пакеты сообщения прибыли, передаче сообщения на хост назначения и возврате сквозного подтверждения. (стр. 284)».
^ Это требование было изложено в запросе предложений ARPANET : «С точки зрения подрядчиков ARPA как пользователей сети, коммуникационная подсеть является автономным объектом, программное обеспечение и оборудование которого обслуживаются сетевым подрядчиком. При проектировании программного обеспечения для взаимодействия нам нужно будет использовать только соглашения ввода-вывода для перемещения данных в подсеть и из нее и не вмешиваться в детали работы подсети. В частности, проверка ошибок, обнаружение неисправностей, коммутация сообщений, восстановление после неисправностей, коммутация линий, сбои несущей и оценка качества несущей, необходимые для гарантии надежной работы сети, являются исключительной ответственностью сетевого подрядчика». [17] : 25
↑ В статье 1972 года Уолден отмечает: «Каждый IMP удерживает пакет до тех пор, пока не получит положительное подтверждение от следующего IMP по линии, что пакет был правильно получен. Если он получает подтверждение, все в порядке; IMP знает, что следующий IMP теперь несет ответственность за пакет, и передающий IMP может отбросить свою копию пакета». [20] : 11
^ К 1973 году BBN признала, что первоначальная цель идеальной надежности внутри ARPANET была недостижима: «Изначально считалось, что единственными компонентами в сетевом проекте, которые были подвержены ошибкам, были коммуникационные цепи, а интерфейсы модемов в IMP оснащены контрольной суммой CRC для обнаружения «почти всех» таких ошибок. Остальная часть системы, включая интерфейсы хоста, процессоры IMP, память и интерфейсы, считались безошибочными. Нам пришлось пересмотреть эту позицию в свете нашего опыта. [21] : 1 Фактически, как резюмирует Меткалф в 1973 году, «в ARPANET было достаточно битов с ошибками, чтобы заполнить эту квоту [одна необнаруженная ошибка бита передачи в год] на века». [22] : 7–28 См. также BBN Report 2816 [23] : 10 и далее для дополнительной информации о опыт, накопленный в первые годы эксплуатации ARPANET.
^ Кстати, ARPANET также предоставляет хороший пример компромиссов между стоимостью механизмов сквозной надежности и выгодами, которые можно было бы получить таким образом. Обратите внимание, что настоящие механизмы сквозной надежности были бы в то время непомерно дорогими, учитывая, что спецификация гласила, что между двумя конечными точками может быть до 8 сообщений на уровне хоста в полете одновременно, каждое из которых имеет максимум более 8000 бит. Объем памяти, который потребовался бы для хранения копий всех этих данных для возможной повторной передачи в случае, если бы не пришло подтверждение от IMP назначения, был слишком дорогим, чтобы быть оправданным. Что касается механизмов сквозной надежности на основе хоста, то они значительно усложнили бы общий протокол уровня хоста ( протокол хост-хост ). Хотя желательность механизмов надежности хост-хост была сформулирована в RFC 1, после некоторого обсуждения от них отказались (хотя протоколы или приложения более высокого уровня, конечно, могли свободно реализовывать такие механизмы самостоятельно). Для пересказа дебатов того времени см. Bärwolff 2010, [24] стр. 56-58 и примечания к ним, особенно примечания 151 и 163.
^ Ранние эксперименты с пакетной передачей голоса относятся к 1971 году, а к 1972 году началось более формальное исследование ARPA по этой теме. Как задокументировано в RFC 660 (стр. 2), [25] в 1974 году BBN представила службу необработанных сообщений (Raw Message Interface, RMI) в ARPANET, в первую очередь для того, чтобы позволить хостам экспериментировать с приложениями пакетной передачи голоса, но также признавая использование такой возможности ввиду возможной межсетевой связи (ср. отчет BBN 2913 [26] на стр. 55 и далее). См. также Bärwolff 2010, [24] стр. 80-84 и обширные примечания в нем.
Ссылки
^ ab Bennett, Richard (сентябрь 2009 г.). «Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate» (PDF) . Фонд информационных технологий и инноваций. стр. 7, 11. Получено 11 сентября 2017 г.
^ ab Saltzer, JH, DP Reed и DD Clark (1981) «Сквозные аргументы в проектировании систем». В: Труды Второй международной конференции по распределенным вычислительным системам. Париж, Франция. 8–10 апреля 1981 г. IEEE Computer Society, стр. 509–512.
^ Saltzer, JH (1980). Сквозные аргументы в проектировании систем. Запрос на комментарии № 185, Лаборатория компьютерных наук Массачусетского технологического института, Отдел исследований компьютерных систем. (Электронная копия).
^ Кларк, Д.Д., К.Т. Погран и Д.П. Рид (1978). «Введение в локальные сети». В: Труды IEEE 66.11, стр. 1497–1517.
^ Саншайн, Калифорния (1975). Вопросы проектирования протоколов связи – формальная корректность. Проект. Примечание к протоколу INWG 5. IFIP WG 6.1 (INWG). (Копия из CBI).
^ Блюменталь, М. С. и Д. Д. Кларк (2001). «Переосмысление дизайна Интернета: сквозные аргументы против смелого мира». В: ACM Transactions on Internet Technology 1.1, стр. 70–109. (Онлайн-версия до публикации).
^ Алексис С. Мадригал и Адриенна ЛаФранс (25 апреля 2014 г.). «Нейтральность сети: руководство по (и история) спорной идеи». The Atlantic . Получено 5 июня 2014 г. Эта идея нейтралитета сети... [Лоуренс Лессиг] называл принцип e2e, от конца к концу
^ Баран, П. (1964). «О распределенных сетях связи». В: IEEE Transactions on Communications 12.1, стр. 1–9.
^ Дэвис, Д.У., К.А. Бартлетт, Р.А. Скэнтлбери и П.Т. Уилкинсон (1967). «Цифровая коммуникационная сеть для компьютеров, обеспечивающая быстрый ответ на удаленных терминалах». В: SOSP '67: Труды первого симпозиума ACM по принципам операционных систем. Гатлинбург, Теннесси. 1–4 октября 1967 г. Нью-Йорк, Нью-Йорк: ACM, стр. 2.1–2.17.
^ "Реальная история того, как Интернет стал таким уязвимым". Washington Post . Архивировано из оригинала 2015-05-30 . Получено 2020-02-18 . Историки приписывают основополагающие идеи валлийскому ученому Дональду У. Дэвису и американскому инженеру Полу Барану.
^ История ARPANET: Первое десятилетие (PDF) (Отчет). Bolt, Beranek & Newman Inc. 1 апреля 1981 г. стр. 13, 53 из 183. Архивировано из оригинала 1 декабря 2012 г. Помимо технических проблем соединения компьютеров с помощью коммуникационных цепей, понятие компьютерных сетей рассматривалось в ряде мест с теоретической точки зрения. Особо следует отметить работу, проделанную Полом Бараном и другими в Rand Corporation в исследовании «О распределенных коммуникациях» в начале 1960-х годов. Также следует отметить работу, проделанную Дональдом Дэвисом и другими в Национальной физической лаборатории в Англии в середине 1960-х годов. ... Еще одна ранняя крупная разработка сети, которая повлияла на разработку ARPANET, была предпринята в Национальной физической лаборатории в Миддлсексе, Англия, под руководством Д. У. Дэвиса.
^ C. Hempstead; W. Worthington (2005). Энциклопедия технологий 20-го века. Routledge . ISBN9781135455514Группой NPL также была проведена работа по моделированию пакетных сетей .
^ Кларк, Питер (1982). Пакетные и коммутируемые сети передачи данных (PDF) (диссертация на соискание ученой степени доктора философии). Кафедра электротехники, Имперский колледж науки и технологий, Лондонский университет.«Помимо сети с коммутацией пакетов, фактически построенной в NPL для связи между локальными вычислительными мощностями, некоторые эксперименты по моделированию были проведены на более крупных сетях. Краткое изложение этой работы приводится в [69]. Работа была проведена для исследования сетей такого размера, который мог бы обеспечить средства передачи данных для большей части Великобритании... Затем были проведены эксперименты с использованием метода управления потоком, разработанного Дэвисом [70], который называется «изоарифмическим» управлением потоком. ... Работа по моделированию, проведенная в NPL, во многих отношениях оказалась более реалистичной, чем большинство теоретических исследований сетей ARPA».
^ ab Pelkey, James. "8.3 CYCLADES Network и Луи Пузен 1971-1972". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988. Архивировано из оригинала 2021-06-17 . Получено 2021-11-21 . Пузен вернулся к своей задаче по проектированию более простой сети с коммутацией пакетов, чем Arpanet. ... [Дэвис] провел некоторое моделирование [глобальных] сетей дейтаграмм, хотя он не построил ни одной, и это выглядело технически жизнеспособным.
^ "Пятый человек интернета". Economist . 13 декабря 2013 г. . Получено 11 сентября 2017 г. . В начале 1970-х годов г-н Пузен создал инновационную сеть передачи данных, которая связала местоположения во Франции, Италии и Великобритании. Ее простота и эффективность указали путь к сети, которая могла бы соединять не просто десятки машин, а миллионы из них. Она захватила воображение доктора Серфа и доктора Кана, которые включили аспекты ее дизайна в протоколы, которые теперь питают интернет.
^ ab Scheblik, TJ, DB Dawkins и Advanced Research Projects Agency (1968). RFQ для компьютерной сети ARPA. Запрос котировок. Advanced Research Projects Agency (ARPA), Министерство обороны (DoD). (Электронная копия, архив 2011-08-15 на Wayback Machine ).
^ McQuillan, JM и DC Walden (1977). «Решения по проектированию сетей ARPA». В: Computer Networks 1.5, стр. 243–289. (Электронная копия). На основе статьи Crowther et al. (1975), которая основана на отчете BBN Report 2918, который, в свою очередь, является выдержкой из отчета BBN Report 2913, оба от 1974 года.
^ Кларк, Д.Д. (2007). Application Design and the End-to-End Arguments. Двухгодичное совещание программы MIT Communications Futures. Филадельфия, Пенсильвания. 30–31 мая 2007 г. Слайды презентации. (Электронная копия).
^ Уолден, округ Колумбия (1972). «Процессор интерфейсных сообщений, его алгоритмы и их реализация». В: AFCET Journées d'Etudes: Réseaux de Calculateurs (Семинар AFCET по компьютерным сетям). Париж, Франция. 25–26 мая 1972 г. Французская ассоциация кибернетической экономики и техники (AFCET). (Онлайн-копия).
^ МакКуиллан, Дж. М. (1973). Контрольное суммирование программного обеспечения в IMP и надежность сети. RFC 528. Исторический. NWG.
^ Меткалф, Р. М. (1973). «Пакетная связь». Кандидатская диссертация. Кембридж, Массачусетс: Гарвардский университет. Электронная копия (пересмотренное издание, опубликовано как MIT Laboratory for Computer Science Technical Report 114). В основном написано в MIT Project MAC и Xerox PARC.
^ Bolt, Beranek and Newman Inc. (1974). Интерфейсные процессоры сообщений для компьютерной сети Arpa. Отчет BBN 2816. Ежеквартальный технический отчет № 5, 1 января 1974 г. — 31 марта 1974 г. Bolt, Beranek and Newman Inc. (BBN). (Частная копия, любезно предоставлена BBN).
^ ab Bärwolff, M. (2010). «Сквозные аргументы в Интернете: принципы, практики и теория». Самостоятельно опубликовано онлайн и через Createspace/Amazon (PDF, исправления и т. д.)
^ Уолден, Д.К. (1974) Некоторые изменения в IMP и интерфейсе IMP/Host. RFC 660. Исторический. NWG.
^ BBN (1974). Интерфейсные процессоры сообщений для компьютерной сети Arpa. Отчет BBN 2913. Ежеквартальный технический отчет № 7, 1 июля 1974 г. — 30 сентября 1974 г. Bolt, Beranek and Newman Inc. (BBN).
^ J. Kempf; R. Austein (март 2004 г.). Подъем среднего уровня и будущее сквозной связи: размышления об эволюции архитектуры Интернета. Сетевая рабочая группа, IETF . doi : 10.17487/RFC3724 . RFC 3724.
^ "Архитектура протокола CNF". Focus Projects . Winlab, Ратгерский университет. Архивировано из оригинала 23 июня 2016 г. Получено 23 мая 2016 г.
^ Уорд, Марк (14.09.2012). «Европа достигает старых ограничений интернет-адресов». BBC News . Получено 28.02.2017 .
^ Стив Диринг и Боб Хинден, сопредседатели рабочей группы IETF по IP Next Generation (6 ноября 1999 г.). "Заявление о конфиденциальности адресов IPv6" . Получено 28.02.2017 .
^ "Информационно-ориентированное интерактивное программирование: BSPL, ослепительно простой язык протоколов" (PDF) . Получено 24 апреля 2013 г.