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

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

Суть того, что позже будет называться принципом сквозного соединения, содержалась в работе Пола Бэрана и Дональда Дэвиса о сетях с коммутацией пакетов в 1960-х годах. Луи Пузен впервые применил сквозную стратегию в сети CYCLADES в 1970-х годах. [1] Принцип был впервые четко сформулирован в 1981 году Зальцером , Ридом и Кларком . [2] [№ 1]Смысл принципа непрерывности непрерывно переосмыслялся с момента его первоначальной формулировки. Кроме того, заслуживающие внимания формулировки принципа непрерывности можно найти до основополагающей работы Зальцера, Рида и Кларка 1981 года. [3]

Основная предпосылка принципа заключается в том, что выгоды от добавления функций в простую сеть быстро уменьшаются, особенно в случаях, когда конечные хосты должны реализовывать эти функции только по причинам соответствия, то есть полноты и правильности на основе спецификации. [nb 2] Реализация определенной функции влечет за собой некоторые штрафы за ресурсы независимо от того, используется эта функция или нет, а реализация определенной функции в сети распределяет эти штрафы между всеми клиентами.

Концепция [ править ]

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

Фундаментальное понятие, лежащее в основе сквозного принципа, заключается в том, что для двух процессов, взаимодействующих друг с другом через некоторые средства связи, нельзя ожидать , что надежность, полученная с помощью этих средств, будет идеально согласована с требованиями надежности процессов. В частности, выполнение или превышение требований очень высокой надежности процессов связи, разделенных сетями нетривиального размера, обходится дороже, чем получение требуемой степени надежности с помощью положительных сквозных подтверждений и повторных передач (называемых PAR или ARQ ). [nb 3] Иными словами, гораздо легче получить надежность сверх определенного запаса с помощью механизмов на конечных хостах.сети, а не в промежуточных узлах , [nb 4] особенно, когда последние не контролируются и не подотчетны первым. [nb 5] Положительные сквозные подтверждения с бесконечным числом повторных попыток могут получить произвольно высокую надежность от любой сети с более высокой вероятностью успешной передачи данных от одного конца к другому. [№ 6]

Сквозной принцип нетривиально распространяется на функции, выходящие за рамки сквозного контроля и исправления ошибок. Например, нельзя привести прямые сквозные аргументы для параметров связи, таких как задержка и пропускная способность . В статье 2001 года Блюменталь и Кларк отмечают: «[С самого начала] сквозные аргументы вращались вокруг требований, которые могут быть правильно реализованы на конечных точках; если реализация внутри сети является единственным способом выполнить требование , то сквозной аргумент вообще не подходит ". [7] : 80

Принцип непрерывности тесно связан с принципом сетевого нейтралитета и иногда рассматривается как прямой предшественник . [8]

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

В 1960-х годах Пол Баран и Дональд Дэвис в своих разработках сетей до ARPANET сделали краткие комментарии о надежности, которые отражают суть более позднего принципа сквозной связи. Цитируя статью Барана 1964 года: «Надежность и необработанная частота ошибок вторичны. Сеть в любом случае должна быть построена с расчетом на серьезный ущерб. Существуют мощные методы устранения ошибок». [9] : 5 Точно так же Дэвис замечает о сквозном контроле ошибок: «Считается, что все пользователи сети обеспечат себя каким-либо средством контроля ошибок, и что без труда это можно сделать, чтобы выявить отсутствующие пакет. Из-за этого можно допустить потерю пакетов, если она достаточно редка ". [10]: 2.3

ARPANET была первой крупномасштабной сетью с коммутацией пакетов общего назначения, в которой реализованы несколько основных понятий, ранее затронутых Бараном и Дэвисом.

Дэвис работал над моделированием сетей дейтаграмм . [11] [12] Основываясь на этой идее, сеть CYCLADES Луи Пузена была первой, в которой хосты были ответственны за надежную доставку данных, а не являлись централизованной службой самой сети. [1] Концепции этой сети повлияли на более позднюю архитектуру ARPANET.

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

ARPANET [ править ]

ARPANET продемонстрировал несколько важных аспектов принципа сквозной связи.

Коммутация пакетов подталкивает некоторые логические функции к конечным точкам связи
Если основной предпосылкой распределенной сети является коммутация пакетов, то такие функции, как переупорядочение и обнаружение дубликатов, неизбежно должны быть реализованы в логических конечных точках такой сети. Следовательно, ARPANET имеет два различных уровня функциональности:
  1. нижний уровень, связанный с транспортировкой пакетов данных между соседними сетевыми узлами (называемый процессорами интерфейсных сообщений или IMP), и
  2. более высокий уровень связан с различными аспектами сквозной передачи данных. [№ 7]
Дэйв Кларк, один из авторов статьи о принципах сквозной связи, заключает: «Обнаружение пакетов не является следствием аргументации сквозной связи. конец аргумента релевантен ". [15] : слайд 31
Отсутствие произвольно надежной передачи данных без механизмов сквозного подтверждения и повторной передачи.
ARPANET был разработан для обеспечения надежной передачи данных между любыми двумя конечными точками сети - во многом как простой канал ввода-вывода между компьютером и ближайшим периферийным устройством. [nb 8] Чтобы исправить любые потенциальные сбои при передаче пакетов, обычные сообщения ARPANET были переданы от одного узла к следующему узлу с положительным подтверждением и схемой повторной передачи; после успешного хэндовера они были затем отброшены, [nb 9] никакой повторной передачи от источника к месту назначения в случае потери пакета не выполнялось. Однако, несмотря на значительные усилия, идеальную надежность, предусмотренную в первоначальной спецификации ARPANET, оказалось невозможно обеспечить - реальность, которая становилась все более очевидной, когда ARPANET вырастала далеко за пределы своей первоначальной четырехузловой топологии.[nb 10] Таким образом, ARPANET является убедительным аргументом в пользу внутренних ограничений сетевых механизмов пошаговой надежности в стремлении к истинной сквозной надежности. [№ 11]
Компромисс между надежностью, задержкой и пропускной способностью
Стремление к безупречной надежности может повредить другим важным параметрам передачи данных, в первую очередь задержке и пропускной способности. Это особенно важно для приложений, которые ценят предсказуемую пропускную способность и низкую задержку над надежностью - классическим примером являются интерактивные голосовые приложения в реальном времени. Этот вариант использования был учтен в ARPANET за счет предоставления услуги необработанных сообщений, в которой не использовались различные меры надежности, чтобы обеспечить более быструю и меньшую задержку передачи данных для конечных хостов. [№ 12]

TCP / IP [ править ]

Интернет-протокол (IP) - это служба дейтаграмм без установления соединения без гарантий доставки . В Интернете IP используется практически для всех коммуникаций. Сквозное подтверждение и повторная передача - это ответственность протокола управления передачей (TCP), ориентированного на соединение, который находится поверх IP. Функциональное разделение между IP и TCP иллюстрирует правильное применение принципа сквозного соединения для проектирования транспортных протоколов.

Передача файлов [ править ]

Примером сквозного принципа является случай произвольно надежной передачи файлов между двумя конечными точками в распределенной сети переменного нетривиального размера: [3] Единственный способ, которым две конечные точки могут получить полностью надежную передачу, - это передача и подтверждение контрольной суммы для всего потока данных; в такой настройке протоколы с меньшей контрольной суммой и подтверждением ( ACK / NACK) оправданы только с целью оптимизации производительности - они полезны для подавляющего большинства клиентов, но недостаточны для выполнения требований надежности этого конкретного приложения. Следовательно, точная контрольная сумма лучше всего выполняется на конечных точках, а сеть поддерживает относительно низкий уровень сложности и приемлемую производительность для всех клиентов.[3]

Ограничения [ править ]

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

Пример ограничений сквозного принципа существует в мобильных устройствах, например, с мобильным IPv6 . [23] Распространение специфической для услуги сложности на конечные точки может вызвать проблемы с мобильными устройствами, если устройство имеет ненадежный доступ к сетевым каналам. [24]

Дальнейшие проблемы можно увидеть в снижении прозрачности сети из-за добавления трансляции сетевых адресов (NAT), на которую IPv4 полагается для борьбы с исчерпанием адресов . [25] С введением IPv6 у пользователей снова появились уникальные идентификаторы, обеспечивающие истинное сквозное соединение. Уникальные идентификаторы могут быть основаны на физическом адресе или могут быть произвольно сгенерированы хостом. [26]

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

  • Пиринговый

Заметки [ править ]

  1. ^ Статья 1981 г. [2] была опубликована в TOCS ACM в обновленной версии в 1984 г. [3] [4]
  2. Полная цитата из статьи Зальцера, Рида, Кларка гласит: [3]«В системе, которая включает в себя коммуникации, каждый обычно проводит модульную границу вокруг коммуникационной подсистемы и определяет прочный интерфейс между ней и остальной системой. При этом становится очевидным, что существует список функций, каждая из которых может может быть реализован любым из нескольких способов: подсистемой связи, ее клиентом, в качестве совместного предприятия или, возможно, дублирующим образом, каждый из которых выполняет свою собственную версию. Обдумывая этот выбор, требования приложения обеспечивают основу для следующего класса аргументов: Рассматриваемая функция может быть полностью и правильно реализована только при наличии знаний и помощи приложения, стоящего на конечных точках системы связи. Следовательно, предоставление этой функции, вызывающей сомнения, в качестве функции самой системы связи невозможно, и более того,приводит к снижению производительности для всех клиентов системы связи. (Иногда неполная версия функции, предоставляемой системой связи, может быть полезна для повышения производительности.) Мы называем эту аргументацию против реализации функции низкого уровня сквозным аргументом »(стр. 278).
  3. ^ Фактически, даже в локальных сетях существует ненулевая вероятность отказа связи - «внимание к надежности на более высоких уровнях требуется независимо от стратегии управления сетью». [5]
  4. ^ С экономической точки зрения предельные затраты на дополнительную надежность в сети превышают предельные затраты на получение такой же дополнительной надежности с помощью мер на конечных узлах. Экономически эффективный уровень повышения надежности внутри сети зависит от конкретных обстоятельств; тем не менее, она, конечно, далека от нуля: [3] «Очевидно, что некоторые усилия на нижних уровнях по повышению надежности сети могут иметь существенное влияние на производительность приложений (стр. 281)».
  5. ^ Несмотря на возможность принудительного исполнения договорных средств защиты, невозможно гарантировать безупречную надежность любой сети, в которой промежуточные ресурсы совместно используются недетерминированным образом. В лучшем случае он может указывать средние статистические показатели.
  6. ^ Точнее: [6] «THM 1: правильно функционирующий протокол PAR с бесконечным счетчиком повторов никогда не перестает доставлять, терять или дублировать сообщения. COR 1A: правильно функционирующий протокол PAR с конечным счетчиком повторов никогда не теряет и не дублирует сообщения, и вероятность не доставить сообщение отправитель может сделать сколь угодно малой ". (стр. 3).
  7. ^ В соответствии с ARPANET RFQ [13] (стр. 47 f.) ARPANET концептуально разделил определенные функции. Как отмечает BBN в статье 1977 года: [14]«[T] Реализация сети ARPA использует технику разбиения сообщений на пакеты, чтобы минимизировать задержку, наблюдаемую при длительных передачах по множеству переходов. Реализация сети ARPA также позволяет нескольким сообщениям проходить одновременно между заданной парой хостов. Однако, несколько сообщений и пакеты в сообщениях могут прибыть в IMP назначения не по порядку, а в случае поломки IMP или линии могут быть дубликаты. Задача процедуры передачи сети ARPA от источника к месту назначения состоит в том, чтобы переупорядочить пакеты и сообщения в месте назначения, чтобы отсеять дубликаты, и после того, как все пакеты сообщения будут доставлены, передать сообщение хосту назначения и вернуть сквозное подтверждение (стр. 284) ».
  8. ^ Это требование было сформулировано в ARPANET RFQ : «С точки зрения подрядчиков ARPA как пользователей сети, подсеть связи является автономным объектом, программное и аппаратное обеспечение которого обслуживается сетевым подрядчиком. Программное обеспечение, которое нам нужно только использовать соглашения о вводе / выводе для перемещения данных в подсеть и из нее, и не участвовать иным образом в деталях работы подсети. В частности, проверка ошибок, обнаружение ошибок, переключение сообщений, восстановление после сбоев, переключение линий и т. Д. сбои операторов связи и оценка их качества, необходимые для обеспечения надежной работы сети, являются исключительной ответственностью сетевого подрядчика ". [13] : 25
  9. ^ Замечает Уолден в статье 1972 года: «Каждый IMP удерживает пакет до тех пор, пока он не получит положительное подтверждение от следующего IMP по строке о том, что пакет был правильно принят. Если он получает подтверждение, все в порядке; IMP знает что следующий IMP теперь несет ответственность за пакет, а передающий IMP может отбросить свою копию пакета ». [16] : 11
  10. ^ К 1973 г. BBN признала, что первоначальная цель идеальной надежности внутри ARPANET недостижима: «Первоначально считалось, что единственными компонентами в конструкции сети, подверженными ошибкам, были цепи связи и модемные интерфейсы в сети. IMP снабжены контрольной суммой CRC для обнаружения «почти всех» таких ошибок. Остальная часть системы, включая интерфейсы хоста, процессоры IMP, память и интерфейсы, считалась безошибочной. Нам пришлось пересмотреть это положение в свете нашего опыта. [17] : 1 Фактически, как резюмирует Меткалф к 1973 г., «в ARPANET было достаточно битов с ошибками, чтобы заполнить эту квоту [одна необнаруженная ошибка передачи бита в год] на протяжении столетий. "[18]: 7–28 См. Также BBN Report 2816 [19] : 10 ff для дополнительной информации об опыте, полученном в первые годы эксплуатации ARPANET.
  11. ^ Между прочим, ARPANET также представляет собой хороший случай для компромисса между стоимостью механизмов сквозной надежности и преимуществами, которые должны быть получены таким образом. Обратите внимание, что настоящие механизмы сквозной надежности были бы непомерно дорогими в то время, учитывая, что спецификация утверждала, что может быть до 8 сообщений уровня хоста одновременно между двумя конечными точками, каждая из которых имеет максимум более 8000 бит. Объем памяти, который потребовался бы для хранения копий всех этих данных для возможной повторной передачи в случае отсутствия подтверждения от IMP назначения, был слишком дорогим, чтобы иметь смысл. Что касается механизмов сквозной надежности на основе хоста - они значительно усложнили бы общий протокол уровня хоста (протокол хост-хост). Хотя желательность механизмов надежности хост-хост была сформулирована в RFC  1 , после некоторого обсуждения от них отказались (хотя протоколы или приложения более высокого уровня, конечно, могли свободно реализовывать такие механизмы самостоятельно). Для пересчета дебатов того времени см. Bärwolff 2010, [20] pp. 56-58 и примечания к ним, особенно примечания 151 и 163.
  12. ^ Ранние эксперименты с пакетной голосовой связью относятся к 1971 году, а к 1972 году начались более формальные исследования ARPA по этому вопросу. Как описано в RFC 660 (стр. 2), [21] в 1974 г. BBN представила службу необработанных сообщений (Raw Message Interface, RMI) в ARPANET, в первую очередь для того, чтобы позволить хостам экспериментировать с пакетными голосовыми приложениями, но также признав использование такого средства ввиду возможной межсетевой связи (см. BBN Report 2913 [22] на стр. 55 и далее). См. Также Bärwolff 2010, [20] pp. 80–84 и многочисленные примечания к ним. 

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

  1. ^ а б Беннет, Ричард (сентябрь 2009 г.). «Создан для перемен: сквозные аргументы, Интернет-инновации и дебаты о сетевом нейтралитете» (PDF) . Фонд информационных технологий и инноваций. С. 7, 11 . Проверено 11 сентября 2017 года .
  2. ^ a b Зальцер, Дж. Х., Д. П. Рид и Д. Д. Кларк (1981) «Сквозные аргументы в проектировании систем». В: Материалы Второй Международной конференции по распределенным вычислительным системам. Париж, Франция. 8–10 апреля 1981 г., IEEE Computer Society, стр. 509-512.
  3. ^ Б с д е е Saltzer, JH, Д. Рид и Д. Кларк (1984) «Аргументы впритык в System Design». В: Транзакции ACM в компьютерных системах 2.4, стр. 277-288. (Смотрите также здесь версию с домашней страницы Saltzer MIT.)
  4. ^ Saltzer, JH (1980). Сквозные аргументы в проектировании систем. Запрос комментариев № 185, Лаборатория компьютерных наук Массачусетского технологического института, Отдел исследований компьютерных систем. ( Интернет-копия ).
  5. ^ Кларк, Д. Д., KT Погран и Д. П. Рид (1978). «Введение в локальные сети». В: Proceedings of the IEEE 66.11, pp. 1497–1517.
  6. Перейти ↑ Sunshine, CA (1975). Проблемы проектирования коммуникационного протокола - формальная корректность. Проект. Протокол INWG Примечание 5. РГ 6.1 IFIP (INWG). ( Копия из CBI ).
  7. ^ Блюменталь, MS и Д.Д. Кларк (2001). «Переосмысление дизайна Интернета: сквозные аргументы против« Отважного мира »». В: Транзакции ACM по Интернет-технологиям 1.1, стр. 70–109. ( Предварительная онлайн-версия ).
  8. ^ Алексис Мадригал С. & Адриенн LaFrance (25 апреля 2014). «Сетевой нейтралитет: руководство по (и истории) оспариваемой идеи» . Атлантика . Дата обращения 5 июн 2014 . Эта идея сетевого нейтралитета ... [Лоуренс Лессиг] называл принцип e2e, от конца до конца
  9. ^ Баран, П. (1964). «О распределенных сетях связи». В: IEEE Transactions on Communications 12.1, pp. 1–9.
  10. ^ Дэвис, DW, К. А. Бартлетт, Р. А. Скантлбери и П. Т. Уилкинсон (1967). «Цифровая сеть связи для компьютеров, обеспечивающих быстрое реагирование на удаленных терминалах». В: SOSP '67: Материалы первого симпозиума ACM по принципам операционных систем. Гатлинбург, Теннесси. 1–4 октября 1967 г. Нью-Йорк, штат Нью-Йорк: ACM, стр. 2.1–2.17.
  11. ^ К. Хемпстед; У. Уортингтон (2005). Энциклопедия технологий 20-го века . Рутледж . ISBN 9781135455514. Группа NPL также провела моделирование пакетных сетей.
  12. ^ Pelkey, Джеймс. "6.3 Сеть CYCLADES и Луи Пузен 1971-1972". Предпринимательский капитализм и инновации: история компьютерных коммуникаций 1968-1988 . Он провел некоторое моделирование сетей дейтаграмм, хотя он не построил их, и это выглядело технически жизнеспособным.
  13. ^ a b Scheblik, TJ, DB Dawkins, and Advanced Research Projects Agency (1968). Запрос предложений на компьютерную сеть ARPA. Запрос цен. Агентство перспективных исследовательских проектов (ARPA), Министерство обороны (DoD). ( Интернет-копия, заархивированная 15 августа 2011 г. на Wayback Machine ).
  14. ^ McQuillan, JM и DC Уолден (1977). «Решения по проектированию сети ARPA». В кн .: Компьютерные сети 1.5, стр. 243–289. ( Интернет-копия ). На основе Crowther et al. (1975), который основан на отчете BBN 2918, который, в свою очередь, является выдержкой из отчета BBN 2913, оба за 1974 год.
  15. Перейти ↑ Clark, DD (2007). Дизайн приложения и сквозные аргументы. Двухгодичное собрание MIT Communications Futures Program. Филадельфия, Пенсильвания. 30–31 мая 2007 г. Презентационные слайды. ( Интернет-копия ).
  16. Перейти ↑ Walden, DC (1972). «Процессор интерфейсных сообщений, его алгоритмы и их реализация». В: AFCET Journées d'Études: Réseaux de Calculateurs (Семинар AFCET по компьютерным сетям). Париж, Франция. 25–26 мая 1972 года. Французская ассоциация кибернетической экономики и техники (AFCET). ( Интернет-копия ).
  17. ^ McQuillan, JM (1973). Программная контрольная сумма в IMP и надежности сети. RFC 528 . Исторический. NWG. 
  18. Перейти ↑ Metcalfe, RM (1973). «Пакетная коммуникация». Кандидатская диссертация. Кембридж, Массачусетс: Гарвардский университет. Электронная копия (пересмотренное издание, опубликовано как MIT Laboratory for Computer Science Technical Report 114). В основном написано в MIT Project MAC и Xerox PARC.
  19. ^ Bolt, Beranek и Newman Inc. (1974). Процессоры интерфейсных сообщений для компьютерной сети Arpa. BBN Report 2816. Квартальный технический отчет № 5, с 1 января 1974 г. по 31 марта 1974 г. Bolt, Beranek and Newman Inc. (BBN). ( Частная копия, любезно предоставлена ​​BBN ).
  20. ^ а б Барвольф, М. (2010). «Сквозные аргументы в Интернете: принципы, практика и теория». Самостоятельная публикация в Интернете и через Createspace / Amazon ( PDF, исправления и т. Д. )
  21. ^ Уолден, округ Колумбия (1974) Некоторые изменения IMP и интерфейса IMP / хоста. RFC 660 . Исторический. NWG. 
  22. ^ BBN (1974). Процессоры интерфейсных сообщений для компьютерной сети Arpa. BBN Report 2913. Ежеквартальный технический отчет № 7, с 1 июля 1974 г. по 30 сентября 1974 г. Bolt, Beranek and Newman Inc. (BBN).
  23. ^ Дж. Кемпф; Р. Остейн (март 2004 г.). Возвышение середины и будущее сквозной связи: размышления об эволюции Интернет-архихектуры . Сетевая рабочая группа, IETF . DOI : 10,17487 / RFC3724 . RFC 3724 .
  24. ^ "Архитектура протокола CNF" . Фокусные проекты . Winlab, Университет Рутгерса . Проверено 23 мая 2016 года .
  25. ^ Уорд, Марк (2012-09-14). «Европа достигла старых лимитов интернет-адресов» . BBC News . Проверено 28 февраля 2017 .
  26. ^ Стив Диринг и Боб Хинден, сопредседатели рабочей группы IETF IP Next Generation (6 ноября 1999 г.). «Заявление о конфиденциальности IPv6-адресов» . Проверено 28 февраля 2017 .