В одной из последних статей мы представили и отладили HTTP / 2. Однако в этой статье мы рассмотрим другие альтернативы протоколу HTTP. Эти альтернативные протоколы весьма интересны, когда мы начинаем их исследовать, поскольку они позволяют нам понять, как развивается Интернет; В этом посте мы также надеемся предоставить хорошее резюме об этих протоколах вместе с соответствующими ресурсами для дальнейшего изучения.

WebRTC

WebRTC расшифровывается как Web Real-Time Communication, и его цель - упростить одноранговое (P2P) соединение, позволяя обмениваться мультимедийными данными (а именно, аудио и видео) и данными приложений. Для достижения этой цели он работает с несколькими протоколами, которые указаны в правой части следующего изображения:

(источник изображения: книга https://hpbn.co/http2/)

Одно из основных отличий заключается в том, что WebRTC работает по протоколу пользовательских дейтаграмм (UDP), а не по TCP, который не гарантирует доставку сообщений.

Для запуска соединения необходимо согласовать параметры между одноранговыми узлами, что называется сигнализацией. Для этого требуется, чтобы сервер находился между одноранговыми узлами, и один из одноранговых узлов начинает делать «предложение», на которое другой собирается «ответить», и сразу после этого оба одноранговых узла начинают говорить P2P (см. Рисунок ниже - «Сигнализация - Базовый концепция").

Утилиты обхода сеанса для NAT (STUN) и обхода с использованием реле вокруг NAT (TURN) играют здесь важную роль, потому что найти однорангового узла может быть не так просто. Таким образом, STUN дает возможность найти ваш общедоступный IP-адрес, а TURN действует как резервный вариант для STUN, когда с одноранговым узлом невозможно связаться. TURN - это сервер ретрансляции, который будет получать эти данные и передавать их другому человеку. (см. рисунок ниже - «Сигнализация - Реальность»). Этой логикой занимается Interactive Connectivity Establishment (ICE).

WebRTC шифрует все данные с помощью протокола Datagram Transport Layer Protocol (DTLS). Подводя итог, это похоже на TLS, но для дейтаграмм (UDP). Он делает что-то похожее на рукопожатие TLS, когда одноранговые узлы имеют собственные сертификаты и обмениваются ключами. После рукопожатия все данные приложения шифруются при отправке другому партнеру. Рукопожатие DTLS должно гарантировать доставку пакетов в порядке, а также TCP, но после него пакеты не нужно заказывать.

Существует два протокола для доставки пакетов в WebRTC: безопасный транспортный протокол в реальном времени (SRTP) и транспортный протокол управления потоком (SCTP). SRTP - это протокол, который используется для доставки аудио и видео, а SCTP используется для данных приложений. SCTP достоин узла, поскольку он похож на уровень кадрирования HTTP / 2: сообщения с данными отправляются по потокам и, как и HTTP / 2, они могут быть разделены на разные части и переупорядочены и собраны на другом узле. Выбор метода доставки зависит от разработчика, поскольку в SRTP блоки могут отправляться в порядке или вне очереди надежным или частично надежным способом.

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

Talky.io, jitsi и Google Hangouts - примеры сервисов, построенных с использованием WebRTC. Однако не все браузеры это поддерживают. Если вы хотите глубоко понять, как работает WebRTC, и протестировать его, воспользуйтесь одним из упомянутых сервисов и посмотрите chrome: // webrtc-internals /.

QUIC

Quick UDP Internet Connections (QUIC) - это протокол, очень похожий на HTTP / 2 (с TLS и TCP), но созданный поверх UDP. Цель QUIC такая же, как и у HTTP / 2, для уменьшения задержки. Однако он также пытается решить некоторые проблемы, которые есть в HTTP / 2. Мы рассмотрим следующий снимок Wireshark, чтобы понять, как работает установка соединения в QUIC:

  • [№215] Клиент запускается с сообщения Client Hello (CHLO), которое будет первым из (как минимум) двух сообщений Client Hello для первого соединения. В этом первом сообщении клиент создает идентификатор соединения (CID на изображении) и отправляет его клиенту вместе с некоторой другой соответствующей информацией, такой как поддерживаемая версия протокола или максимальные размеры окна соединения и потока.
  • [№218] Учитывая, что это первое взаимодействие между сервером и клиентом, сервер отправляет Rejection (REJ). Сообщение об отклонении содержит информацию о конфигурации сервера (которая имеет общедоступное значение сервера), токен (токен адреса источника, который будет использоваться в будущих запросах), а также подтверждение подлинности сервера и продолжительность конфигурации сервера.
  • [№222] Клиент отправляет второе сообщение Client Hello, которое содержит подтверждение и информацию о конфигурации сервера (а именно, идентификатор конфигурации сервера). Если все правильно, оба конца могут обмениваться данными, в противном случае сервер может отправить еще один REJ, и нужно отправить новое приветствие клиента, пока все не будет настроено должным образом. Использование как конфигурации сервера, так и общедоступного значения клиента позволяет клиенту получить начальные ключи для выполнения следующих запросов. Если у клиента уже есть конфигурация сервера, он может превзойти часть процесса рукопожатия и просто отправить это Client Hello, достигнув 0-RTT (нулевое время приема-передачи), что является одной из основных функций QUIC.
  • [№228] Вероятно, это сообщение Server Hello (SHLO), которое теперь зашифровано с помощью начальных ключей. Он также отправляет другой открытый ключ, который будет использоваться для создания окончательных ключей прямой безопасности, которые будут использоваться обеими сторонами в дальнейших запросах, как только клиент получит SHLO. Учтите, что Wireshark еще не может расшифровать сообщения с полезной нагрузкой QUIC.

Проект RFC для QUIC и Криптофайл QUIC могут предоставить нам более подробную информацию о протоколе, который поддерживается только Google Chrome для веб-приложений Google (например, Gmail).

Протоколы QUIC и HTTP / 2 были созданы Google. Однако есть некоторые различия между подходом QUIC и TCP + TLS + HTTP / 2:

  • QUIC использует UDP вместо TCP;
  • QUIC обеспечивает повторное использование ключей 0-RTT. QUIC не использует STCP поверх DTLS (например, WebRTC), потому что это было бы слишком дорого: для установления соединения потребуется 4-RTT, что далеко от целей QUIC.
  • Оба используют нечетные числа для потоков, инициированных клиентом, и даже для потоков, инициированных сервером, несмотря на то, что QUIC резервирует поток 1 (для начального рукопожатия) и 3 (для заголовков потока) для определенных целей.
  • QUIC устраняет блокировку начала линии TCP. Важно отметить, что мультиплексирование потоков в QUIC работает по-другому: если пакет из потока потерян, затрагивается только этот поток, а не все соединение (см. Рисунок ниже - «QUIC Streams over связь"). Однако в потоке 3, куда отправляются пакеты заголовков, все еще может существовать блокировка заголовка строки.

  • Заголовки сжимаются как в QUIC, так и в HTTP / 2 (с использованием HPACK);
  • QUIC использует идентификатор соединения (CID), который является случайным значением, генерируемым клиентом. Это значение можно использовать повторно, если срок его действия еще не истек. Это огромное улучшение по сравнению с TCP, где соединения зависят от IP. Более того, при использовании QUIC идентификатор соединения будет одинаковым, независимо от того, использует ли пользователь Wi-Fi или мобильные данные.
  • QUIC реализует пакеты прямого исправления ошибок (FEC), которые позволяют определять содержимое пакета без повторной передачи потерянного пакета.

IPFS

Межпланетная файловая система (IPFS) - это совершенно новый протокол (созданный в 2014 году), в котором используются некоторые зрелые концепции. Гипотеза, лежащая в основе IPFS, заключается в том, что HTTP слишком централизован, и сегодня Интернет работает в основном с подключениями клиент-сервер, в которых серверы являются вероятной точкой отказа. Более того, в ситуациях с плохим доступом к Интернету мы можем даже не получить доступ к нужному нам контенту.

(источник изображения: https://speakerdeck.com/jbenet/ipfs-hands-on-intro, слева показан централизованный пример - один сервер и много клиентов; посередине - децентрализованный пример - несколько источников, предоставляющих данные; справа - распределенный пример - несколько одноранговых узлов предоставляют и получают данные)

IPFS нацелена на создание распределенной сети P2P, в которой Интернет работает как Git! А именно, это означает, что для каждого объекта существуют коммиты и деревья, и все организовано, как в Git: с использованием DAG Меркла (направленного ациклического графа). У каждого объекта есть хеш, и, очевидно, разные объекты имеют разные хеши (объекты адресуются по содержимому).

IPFS имеет систему маршрутизации, в которой одноранговые узлы находят сетевые адреса других одноранговых узлов с помощью распределенной хеш-таблицы (DHT). Одним из важных свойств является то, что вы можете торговать объектами через IPFS, не требуя проверки однорангового узла. Это происходит потому, что хэши объектов могут быть подписаны с использованием открытого ключа владельца, и в этих обстоятельствах вы можете подтвердить личность. Когда соединение установлено правильно (и заслуживает доверия) между двумя одноранговыми узлами, каждый одноранговый узел отправляет информацию о том, какие данные ему нужны (want_list). После получения любого блока получатель проверяет его подлинность и подтверждает. Протокол, отвечающий за обмен данными между одноранговыми узлами, называется BitSwap.

Что касается сети, IPFS не ограничивается TCP или QUIC, это зависит от реализации. В документе IPFS упоминается, что его рекомендуется использовать поверх WebRTC DataChannels. Что касается подключения, IPFS также использует обход ICE NAT, упомянутый ранее в этом блоге.

Более подробную информацию о протоколе IPFS вы можете найти на веб-сайте IPFS или в репозитории github. Существует три серверных реализации протокола IPFS, go-ipfs более стабильная, но вы также можете внести свой вклад в JavaScript: js-ipfs. IPFS помогает нам еще раз взглянуть на Интернет и его сегодняшнее состояние, и это основная причина, по которой некоторые проекты создаются поверх IPFS.

Выводы

Эта статья была о:

  • изучение альтернатив HTTP;
  • понимать, что сеть, которая у нас есть сегодня, может измениться, и это может потребовать некоторых усилий с нашей стороны;
  • подумайте о важности P2P в будущем, поскольку все больше и больше людей получают доступ к Интернету, а низкая задержка не гарантируется;
  • пересмотреть некоторые представления о транспортном и сеансовом уровнях, потому что TCP + TLS не может быть святым Граалем.

Автор Даниэла Матос де Карвалью - консультант YLD.

Заинтересованы в HTTP? Подробнее об этом:



QUIC (k) HTTP / 3
Действительно ли это« новый протокол? medium.com»





Оптимизируйте с помощью HTTP / 2 Server Push и Service Workers!
medium.com