Suicide
11.06.2020, 20:37
Компания NGINX объявила (https://www.nginx.com/blog/introducing-technology-preview-nginx-support-for-quic-http-3/) о начале тестирования реализации (https://quic.nginx.org/) протоколов QUIC и HTTP/3 в HTTP-сервере и прокси nginx. Реализация основана на 27 черновике (https://datatracker.ietf.org/doc/draft-ietf-quic-transport/) спецификации IETF-QUIC и доступна через отдельный репозиторий (https://hg.nginx.org/nginx-quic/shortlog/quic), ответвлённый от выпуска 1.19.0. Код распространяется под лицензией BSD и не пересекается с предложенной ранее (https://www.opennet.ru/opennews/art.shtml?num=51695) реализацией HTTP/3 для nginx от компании Cloudflare, которая является отдельным проектом.
Поддержка HTTP/3 в nginx помечена как экспериментальная, так как не все возможности (https://quic.nginx.org/readme.html) протокола реализованы. При этом nginx уже может применяться для отправки ответов на простые запросы HTTP/3 поверх QUIC и загрузки/отдачи больших файлов. Из пока отсутствующих возможностей протокола отмечаются средства согласования версии протокола, ECN и контроль перегрузки, структурированные логи, режим восстановления (QUIC recovery, управление потоком и перегрузкой), NAT Rebinding, мобильные адреса, Server push, присоединение данных (trailer). Также предложена только базовая поддержка обработки ACK-пакетов и управления потоком, которая требует доработки. Не все требования стандарта учтены.
Для активации HTTP/3 требуется собрать nginx с модулем http_v3_module и добавить дополнительную директиву "listen" с флагом "http3" для создания слушающего UDP-сокета. Например:
server {
listen 443 ssl; # TCP-сокет для HTTP/1.1
listen 443 http3 reuseport; # UDP-сокет для QUIC+HTTP/3
ssl_protocols TLSv1.3; # в QUIC обязателен TLS 1.3
ssl_certificate ssl/www.example.com.crt; (http://www.example.com.crt;)
ssl_certificate_key ssl/www.example.com.key; (http://www.example.com.key;)
add_header Alt-Svc 'quic=":443"'; # признак доступности QUIC
add_header QUIC-Status $quic; # Заголовок со статусом использования QUIC
}
Напомним, что HTTP/3 стандартизирует использование протокола QUIC в качестве транспорта для HTTP/2. Протокол QUIC (https://www.chromium.org/quic/) (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. На стороне клиентского ПО экспериментальная поддержка HTTP/3 уже добавлена в Curl (https://www.opennet.ru/opennews/art.shtml?num=51540), Firefox (https://www.opennet.ru/opennews/art.shtml?num=51807) и Chromium (https://www.opennet.ru/opennews/art.shtml?num=51526).
https://www.opennet.ru/opennews/pics_base/0_1591867151.png (https://www.nginx.com/wp-content/uploads/2020/06/HTTP-v1-v2-v3-stacks.png)
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#) QUIC:
Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS 1.3 поверх UDP);
Контроль за целостностью потока, предотвращающий потерю пакетов;
Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);https://www.opennet.ru/opennews/pics_base/0_1429374296.png (https://lh3.googleusercontent.com/o62Ohn1Ppxna6zz0NtavqRyetjryOj-81Sz4bRt3U8lURVblk5RKOaCcf57i6BkmprremePJpq_sQcxfJ iuA4wJBmRp3pR4BS1P-yiT6UNUPvnBeP_rLz9bvHxFE15kuNBM2hpE?a.png)
Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
Отсутствие проблем с блокировкой очереди TCP;
Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
Возможность подключения расширенных механизмов контроля перегрузки соединения;
Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
Заметный прирост (http://web.cs.wpi.edu/~claypool/ms/quic/quic-thesis.pdf) производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
11.06.2020
https://www.opennet.ru/opennews/art.shtml?num=53137
Поддержка HTTP/3 в nginx помечена как экспериментальная, так как не все возможности (https://quic.nginx.org/readme.html) протокола реализованы. При этом nginx уже может применяться для отправки ответов на простые запросы HTTP/3 поверх QUIC и загрузки/отдачи больших файлов. Из пока отсутствующих возможностей протокола отмечаются средства согласования версии протокола, ECN и контроль перегрузки, структурированные логи, режим восстановления (QUIC recovery, управление потоком и перегрузкой), NAT Rebinding, мобильные адреса, Server push, присоединение данных (trailer). Также предложена только базовая поддержка обработки ACK-пакетов и управления потоком, которая требует доработки. Не все требования стандарта учтены.
Для активации HTTP/3 требуется собрать nginx с модулем http_v3_module и добавить дополнительную директиву "listen" с флагом "http3" для создания слушающего UDP-сокета. Например:
server {
listen 443 ssl; # TCP-сокет для HTTP/1.1
listen 443 http3 reuseport; # UDP-сокет для QUIC+HTTP/3
ssl_protocols TLSv1.3; # в QUIC обязателен TLS 1.3
ssl_certificate ssl/www.example.com.crt; (http://www.example.com.crt;)
ssl_certificate_key ssl/www.example.com.key; (http://www.example.com.key;)
add_header Alt-Svc 'quic=":443"'; # признак доступности QUIC
add_header QUIC-Status $quic; # Заголовок со статусом использования QUIC
}
Напомним, что HTTP/3 стандартизирует использование протокола QUIC в качестве транспорта для HTTP/2. Протокол QUIC (https://www.chromium.org/quic/) (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL. На стороне клиентского ПО экспериментальная поддержка HTTP/3 уже добавлена в Curl (https://www.opennet.ru/opennews/art.shtml?num=51540), Firefox (https://www.opennet.ru/opennews/art.shtml?num=51807) и Chromium (https://www.opennet.ru/opennews/art.shtml?num=51526).
https://www.opennet.ru/opennews/pics_base/0_1591867151.png (https://www.nginx.com/wp-content/uploads/2020/06/HTTP-v1-v2-v3-stacks.png)
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/preview?sle=true#) QUIC:
Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS 1.3 поверх UDP);
Контроль за целостностью потока, предотвращающий потерю пакетов;
Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);https://www.opennet.ru/opennews/pics_base/0_1429374296.png (https://lh3.googleusercontent.com/o62Ohn1Ppxna6zz0NtavqRyetjryOj-81Sz4bRt3U8lURVblk5RKOaCcf57i6BkmprremePJpq_sQcxfJ iuA4wJBmRp3pR4BS1P-yiT6UNUPvnBeP_rLz9bvHxFE15kuNBM2hpE?a.png)
Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
Отсутствие проблем с блокировкой очереди TCP;
Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
Возможность подключения расширенных механизмов контроля перегрузки соединения;
Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
Заметный прирост (http://web.cs.wpi.edu/~claypool/ms/quic/quic-thesis.pdf) производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
11.06.2020
https://www.opennet.ru/opennews/art.shtml?num=53137