[Перевод] Некоторые мысли о HTTP/3

сервер HTTP Программа перевода самородков Google
[Перевод] Некоторые мысли о HTTP/3

Некоторые мысли о HTTP/3

HTTP/3 вот-вот станет стандартом будущего. Как старый пользователь протокола, я чувствую, что должен что-то написать.

Google (pbuh) имеет самый популярный браузер (Chrome) и два самых популярных веб-сайта (#1Google.com #2 Youtube.com). Таким образом, Google имеет право разрабатывать будущие веб-протоколы. Они назвали первый протокол обновления SPDY (произносится как «быстрый»), вторую версию HTTP, которая позже была стандартизирована, HTTP/2. Они назвали второе обновление QUIC (произносится как «быстрый») — HTTP/3, который скоро будет стандартизирован.

В настоящее время основные веб-браузеры (chrome, Firefox, Edge, Safari) и основные веб-серверы (Apache, Nginx, IIS, CloudFlare) уже поддерживают SPDY (HTTP/2). Многие популярные сайты также поддерживают его (даже сайты, не принадлежащие Google), хотя вы вряд ли увидите его в Интернете (проверьте с помощью wireshark или tcpdump), поскольку он всегда зашифрован с помощью SSL. Хотя стандарт позволяет HTTP/2 работать через TCP, практически все приложения работают через SSL.

Вотстандартныйочки знаний. За пределами Интернета стандарты часто подчиняются законам и управляются правительствами. Все ключевые заинтересованные стороны делают формулировку в конференц-зале, а затем используют закон, чтобы заставить людей согласиться с ним и использовать его. Однако в Интернете все по-другому, люди сначала внедряют стандарт, а затем принятие пользователем определяет, начинать ли его использовать. Стандарты обычно являются фактами, RFC-документы пишутся для того, что уже работает в Интернете, для документирования того, что люди уже используют. SPDY был принят браузерами/серверами не только потому, что он был стандартизирован, но и потому, что основные поставщики Интернета начали добавлять его поддержку. То же самое верно и для QUIC: он стандартизируется, поскольку HTTP/3 отражает его использование, и это не просто веха, так как большинство людей уже начинают использовать протокол на практике.

QUIC больше похож на новую версию TCP (TCP/2), чем на новую версию HTTP (HTTP/3). Поскольку на самом деле это не меняет того, что делает HTTP/2, это меняет то, как работают транспорты. Поэтому мои комментарии ниже сосредоточены на проблемах с транспортом, а не на проблемах с HTTP.

Основными функциями являются более быстрая установка соединения и более короткийЗадерживать. TCP должен отправить несколько пакетов туда и обратно, прежде чем соединение будет установлено. SSL запрашивает несколько пакетов туда и обратно между шифровальными учреждениями. Если есть большая задержка в сети, скажем, люди, использующие полсекунды пинга спутникового интернета за раз, для установления соединения может потребоваться много времени. Сокращая количество круговых поездок, соединения могут устанавливаться быстрее, поэтому, когда вы нажимаете на ссылку, связанный ресурс немедленно отвечает обратной связью.

Следующей важной особенностью являетсяпропускная способность. Из-за наличия ограничения пропускной способности, если две стороны в сетевой связи находятся в случае неравного ограничения пропускной способности, сторона с медленным приемом пакетов данных потеряет пакеты, потому что уже слишком поздно для приема, что заставит отправителя повторно передать данные и потребляют больше сетевых ресурсов, поэтому максимальное использование сети может быть достигнуто только тогда, когда пропускная способность обеих сторон одинакова.

Почему традиционный HTTP так плохо работает в этом отношении? Взаимодействие с веб-сайтом требует одновременной передачи нескольких материалов, чего HTTP не может достичь с помощью отдельного TCP, поэтому браузер устанавливает несколько подключений к веб-серверу (Обычно 6). Но это снова разрушает оценку пропускной способности, поэтому каждое TCP-соединение пытается выполняться независимо, как если бы других соединений не существовало. SPDY пройденомультиплексированиеФункция решает эту проблему, объединяя несколько взаимодействий браузера/сервера с одним расчетом пропускной способности.

QUIC расширяет это мультиплексирование, чтобы упростить обработку нескольких взаимодействий между браузерами/серверами, не блокируя друг друга, что требует общей оценки пропускной способности. С точки зрения пользователя, это сделает взаимодействие более плавным и уменьшит перегрузку маршрутизации.

Теперь давайте обсудимuser-mode stacks. Это проблема TCP, особенно на серверах, где TCP-соединения обрабатываются операционной системой.ядрообработки, в то время как сама служба работает напользовательский режим. Манипулирование ресурсами за пределами ядра/пользовательского режима может вызвать проблемы с производительностью. Отслеживание большого количества TCP-подключений может вызвать проблемы с масштабируемостью. Некоторые люди пытаются поместить сервер в ядро, чтобы избежать чрезмерной нагрузки, что, очевидно, не является хорошей идеей. Потому что это дестабилизирует операционную систему. Мое решение состояло в том, чтобы использовать BlackICE IPS и масскан, которыйдрайвер пользовательского режимааппаратное обеспечение. Передавайте пакеты напрямую из сетевого чипа в процесс пользовательского режима, минуя ядро ​​(см. PoC||GTFO #15), используя пользовательский стек TCP. эти годы вDPDKстал популярным в комплектах.

Но при отсутствии драйвера пользовательского режима переход с TCP на UDP даст тот же прирост производительности. знакомый с призывомrecv()В отличие от функций, которые получают один пакет за раз, вы можете вызватьrecvmmsg()для получения группы пакетов UDP одновременно. Это все еще случай перевода ядра/пользовательского режима, но гораздо лучше амортизировать сто пакетов, полученных одновременно, чем переводить каждый.

В моих тестах, используя типичныйrecv()Функция ограничена 500 000 пакетов UDP в секунду, но используетrecvmmsg()И некоторые другие оптимизации (многоядерность с использованием RSS), вы можете получить 5 миллионов пакетов UDP в секунду на низкоуровневом четырехъядерном сервере. Это связано с хорошей масштабируемостью на ядро, и переход на мощный сервер с 64 ядрами должен еще больше улучшить результаты.

Кстати, «RSS» — это функция сетевого оборудования, которая разделяет входящие пакеты на несколько очередей приема. Самая большая проблема многоядерной масштабируемости заключается в том, что совместное использование одной и той же очереди пакетов UDP становится самым большим узким местом, когда двум ядрам ЦП необходимо одновременно читать/изменять одно и то же. Поэтому Intel и другие поставщики Ethernet первыми добавили RSS, чтобы каждое ядро ​​имело собственную неразделяемую очередь пакетов. Linux и другие операционные системы обновили UDP для поддержки нескольких файловых дескрипторов для одного сокета (SO_REUSEPORT) для обработки нескольких очередей. Теперь QUIC использует преимущества этих достижений, позволяя каждому ядру управлять своим собственным потоком пакетов UDP без проблем с масштабируемостью, связанных с совместным использованием данных с другими ядрами ЦП. Я упоминаю об этом, потому что в 2000 году у меня была дискуссия с инженерами Intel по аппаратному обеспечению о построении множественных групповых очередей. Это распространенная проблема и очевидное решение, и было интересно наблюдать за его прогрессом за последние два десятилетия, зная, что он лидирует как HTTP/3. QUIC также вряд ли станет стандартом без RSS в сетевом оборудовании.

Еще одно классное решение для QUIC —переехатьслужба поддержки. Ваш компьютер или мобильный телефон изменит свой IP-адрес при переходе в другую сетевую среду WIFI. Операционные системы и протоколы не корректно закрывают старые соединения и открывают новые. Затем в протоколе QUIC идентификатор соединения больше не является традиционной концепцией «сокета» (комбинация исходного/целевого порта/протокола адреса), а представляет собой 64-битный идентификатор, назначенный соединению.

Это означает, что пока вы находитесь в пути, вы можете продолжать получать поток данных с YouTube или продолжать видеозвонок без перерыва, в то время как ваш IP-адрес постоянно меняется. Интернет-инженеры десятилетиями боролись с «мобильным IP», пытаясь найти работающее решение. Они сосредоточены на сквозном принципе сохранения фиксированного IP-адреса при перемещении, но это непрактичное решение. Для нас большая честь видеть QUIC/HTTP/3 в качестве жизнеспособного решения в реальном мире, которое, наконец, решает эту проблему.

Как использовать эти новые инструменты передачи? На протяжении десятилетий стандартом сетевого программирования былAPI транспортного уровня, "розетка". То есть вызов чего-то вродеrecv()Такая функция для приема пакетов в коде. В QUIC/HTTP/3 у нас больше нет API-интерфейсов транспортного уровня ОС. На его месте находится функция более высокого уровня, которую вы намеренно вставляете в что-то вродеGOИспользуйте его в своем языке программирования или используйте Lua на веб-сервере OpenResty Nginx.

Я упоминаю об этом, потому что одна вещь, которую вы упустили в своем образовательном изучении модели OSI, заключается в том, что изначально предполагалось, что все будут писать в API прикладного уровня (7), а не в API транспортного уровня (4). должно быть что-то вродеЭлемент службы приложенийи т. д. могут обрабатывать такие операции, как передача файлов и обмен сообщениями, стандартным способом для различных приложений. особенно в том числеGo, QUIC, протобафыС драйвом Google люди будут все больше и больше склоняться к этой модели.

Я упоминаю об этом из-за резкого контраста между Google и Microsoft. Microsoft владеет популярной операционной системой, поэтому ее инновации основаны на том, что она может делать в этой операционной системе. Инновации в Google основаны на том, что можно установить в операционную систему. Кроме того, есть сами Facebook и Amazon, которые должны внедрять инновации поверх (или вне) стека, который им предоставляет Google. В первую пятерку компаний мира входят Apple, Google, Microsoft, Amazon, Facebook, поэтому каждая компания занимается инновациями.

в заключении

Когда TCP был создан в 1970-х, это было здорово. Он справляется с такими операциями, как перегрузка, намного лучше, чем конкурирующие протоколы. Несмотря на заявления о том, что IPv4 не предполагал ничего, кроме 4 миллиардов адресов, он был намного лучше, чем конкурирующие разработки 70-х и 80-х годов. Переход с IPv4 на IPv6 во многом поддерживает эволюцию IP. Точно так же апгрейд TCP до QUIC продолжает развитие TCP, разница в том, что это расширение для удовлетворения современных потребностей. Удивительно, но TCP может так долго использоваться без обновления.

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

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллекти другие поля, если вы хотите видеть больше качественных переводов, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории