DUMP-2012 - Только хардкор! - Дизайн сетевых протоколов передачи данных" Марк Коренберг (Ideco)
•Als ODP, PDF herunterladen•
0 gefällt mir•574 views
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie DUMP-2012 - Только хардкор! - Дизайн сетевых протоколов передачи данных" Марк Коренберг (Ideco)
Ähnlich wie DUMP-2012 - Только хардкор! - Дизайн сетевых протоколов передачи данных" Марк Коренберг (Ideco) (11)
Mehr von it-people
Mehr von it-people (20)
DUMP-2012 - Только хардкор! - Дизайн сетевых протоколов передачи данных" Марк Коренберг (Ideco)
- 1. Дизайн сетевых протоколов Коренберг Марк, ведущий разработчик «Айдеко»
- 2. С чего начать? Определитесь: Latency vs Throughput Нужна надёжность? Будет Human-oriented? Нужна ли будет передача BLOB?
- 3. Предостережение Если вы решили сделать свой протокол — НЕ ДЕЛАЙТЕ ЭТОГО!
- 4. Границы сообщений Content-length Размер нужно знать заранее Потребление памяти Вынужденные задержки Разделитель Необходимо экранирование Низкая производительность Невозможность блочных операций Угроза безопасности
- 5. BLOB отдельно FTP, AIM, BitTorrent, SIP, PPTP — используют отдельный поток (соединение) Более сложная реализация клиента/сервера Для Stateful firewall корректное отслеживание RELATED соединений затруднено Для NAT — модификация служебных данных
- 6. Head-of-line blocking Одно соединение — значит последовательная передача BLOBов В какой последовательности? Использовать несколько соединений — тоже плохо Google изобрёл SPDY!
- 7. Метаданные Представимы в виде комбинации скаляров, словарей, списков, наборов Текстовый вид JSON, YAML, XML Медленно Большая избыточность Двоичный вид Protobuf, BSON, ASN1, pickle Быстро, но не human-oriented
- 8. Latency Буферизация или повторная отправка Экономить Round-trip (особенно на спутниковых каналах) Шифрование и сжатие Решения Pipelining
- 9. Современные решения SPDY (Уровень приложения) Несколько независимых потоков в одном TCP- соединении Сжатие заголовков HTTP SCTP (Транспортный уровень) Несколько потоков в одном соединении Сохранение границ сообщений
- 10. Вопросы?
- 11. Вопросы?
Hinweis der Redaktion
- 10:01 Рассматривая дизайн сетевых протоколов, я не буду рассказывать про то что написано в RFC, а расскажу про проблемы и способы их решения. Множество проблем возникло из-за того что во время разработки протоколов современные проблемы не считались тогда важными или вообще не учитывались, да и скорости, цели и задачи были совсем иные. Да, я буду рассказывать о протоколах уровня приложений
- 10:04 Итак, предположим вам нужно выбрать протокол для вашей задачи. В зависимости от конкретного случая, требования будут разные. Голос, датчики, файлы, RPC - какими свойствами должен обладать протокол? Вам нужно чтобы протокол передавал как можно больше данных или нужно минимизировать задержки? Критичны ли искажения данных? - перестановка, потеря и дублирование? голос или архивы Будет ли протокол человекочитаем? - избыточнее, но проще в отладке. Однако скорости современных компьютеров такие, что (bash и xinetd или nc) Есть ли необходимость передавать произвольное количество произвольных данных — т. е. Данных, не интерпретируемых протоколом
- 10:06 Если вы решили сделать свой протокол уровня приложений — НЕ ДЕЛАЙТЕ ЭТОГО! Скорее всего, нужный протокол уже существует. И скорее всего, это — HTTP. Он хорошо отлажен и хорошо поддерживается. Если очень нужно — реализуйте свои задумки поверх HTTP. Конечно, HTTP подходит не всегда — его дизайн не идеален. Его проблемы на самом деле существуют и в других протоколах. А какие именно — сейчас рассмотрим.
- 10:10 При дизайне сетевого протокола возникает задача кодирования признака конца BLOBа. В HTTP/1.0 - это конец соединения. Это ненадёжно. Исправили в HTTP/1.1. Очевидно, что в метаданных необходимо явно указывать признак конца BLOBа. Распространены 2 способа: Явное указание количества байт и использование разделителя. … ... Что же делать с блобами? Есть ещё одно решение
- 10:14 При передаче BLOB в отдельном соединении проблема с границей сообщений уже решена на транспортном уровне. Однако, реализация протоколов затруднена, так как требует либо event-loop либо потоки или др. средства. Например в FTP команда ABOR может быть послана в процессе загрузки файла. Кроме того, использование двух соединений затрудняет работу stateful firewall т. к. отслеживание RELATED соединений требует анализа данных основного соединения. Если протокол построен так что внутри передаётся идентификатор второго потока (IP-адрес+порт) то реализация NAT сильно усложняется, особенно когда протокол текстовый Иногда, жёсткие рамки возможностей TCP сильно нас ограничивают и мы вынуждены исп. 2 потока (PPTP, VOIP — данные и потери) … Независимо от выбора способа передачи BLOBа, есть ещё другая проблема:
- 10:17 Рассмотрим HTTP. Если браузер загружает сайт используя одно TCP-соединение, то необходимо загружать BLOBы последовательно. А в какой последовательности? Может оказаться так, что самый нужный для отображения BLOB окажется в конце очереди. Поэтому современные браузеры открывают несколько соединений для параллельной загрузки BLOBов. Однако каждое соединение проходит процедуру TCP SLOW START, handshake и другие. Таким образом одна проблема заменяется на другую. Изобретённый гуглом протокол SPDY решает обе эти проблемы, мультиплексируя несколько виртуальных соединений в одном TCP.
- 10:22 В любом случае, вам потребуется передавать сопутствующие данные, или, данные, имеющие чёткую структуру. Можно передавать в текстовом виде и в двоичном. Текстовый — он избыточен и его анализ более медленный и трудный, зато он человекочитаем. Бинарные — быстры, компактны, но сложны и глючны Вообще говоря, метаданные почти всегда представимы в виде комбинации скаляров, словарей, списков и наборов. Например, заголовки HTTP — это словарь. Byte-ranges — это список и т. д. Список файлов в FTP — словарь. Для сериализации давно придуманы стандарты, но почему-то разработчики всегда придумывают свой. (читай слайд) ---- Бинарные DNS, LDAP, SNMP. Текстовые — HTTP, SMTP, FTP, IMAP, POP3. … . Ещё одна ситуация это задержки при передаче данных
- 10:26 Причин для появления дополнительных задержек множество — на всех уровнях протоколов — от канального до уровня приложений. Общими словами — это буферизация, повтор отправки. Например, в TCP — это вынужденная буферизация для учёт порядка пакетов. Или алгоритм Нагла (для увеличения проп. Способности) Таким образом, если задержки для вас критически важны — не используйте TCP! (SIP, PPTP) Если же всё-таки используется TCP то несколько простых правил позволит уменьшить задержки (RTT) Предположим, у нас TCP и в нашем протоколе нужно передавать несколько последовательностей команда/ответ. (читай слайд) … Я рассказал лишь распространённые проблемы, везде какие-то рамки и ограничения. Что делать?
- 10:30 Как я уже говорил, Google изобрёл SPDY как замену HTTP. Основная фича SPDY — несколько виртуальных каналов внутри одного TCP-соединения. Реализовано это путём разбиения данных потоков на кусочки и передачи их последовательно, организуя псевдо-параллельность. Но SPDY подоходит не всем — в частности, голос слать через него нежелательно из-за возможных задержек. Специально для телефонии был изобретён протокол SCTP как замена TCP. Протокол получился столь удачным, что он подходит для реализации большинства протоколов уровня приложений. Как и SPDY он позволяет мультиплексировать несколько потоков внутри. Это позволяет освободить протокол уровня приложений от многих ухищрений (вроде IMAP, SPDY или PPTP) Кроме того, некоторые потоки могут не сохранять порядок сообщений (для передачи голоса) SPDY можно рассматривать как SCTP+HTTP SCTP + DNS, SPDY + DNS = FAIL
- 10:30