|
HTTP/2, HTTP/3, QUIC и т.д.
|
|
---|---|
#18+
Решил почитать, заодно тут повыкладывать какие-то материалы по HTTP/3 и QUIC, а то эти понятия всплыли в связи с тормозами ютюба. Ну и HTTP это такая вещь, с которой все IT-шники и просто люди, кто интернетом пользуются, сталкиваются. Так, для собственного образования и может кто-нибудь ещё решит почитать. Приглашаю тоже поучаствовать, насчёт каких-то материалов по теме, если кто захочет. ... |
|
:
|
|
03.08.2024, 12:38 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|||
---|---|---|---|
#18+
Наверное стоит начать с напоминания о том, что такое HTTP вообще. Сам я веб-разработкой занимался немного и это было какое-то время назад, так что наверное многие на форуме знают больше меня об этом. Но всё равно что-то напишу. HTTP (HyperText Transfer Protocol) - это протокол, по которому веб-браузеры общаются (обмениваются данными) с сайтами (точнее - с веб-серверами). Также HTTP используют программы, которые работают c веб-сервисами, веб-службами. Вроде в этом случае может использоваться не только HTTP, но в частности используется и он. Рабочая версия HTTP (если не считать позднейшие 2 и 3) - 1.1 HTTP/1.1 - это текстовый протокол поверх TCP-IP. Клиент (браузер или другое ПО) устанавливает TCP соединение с сервером и затем отправляет серверу запрос, на который сервер отвечает. Запрос состоит из нескольких строк, разделенных символами (CR) LF - собственно строка запроса, затем строки с т.н. заголовками, потом может присутствовать "тело" запроса. После обмена информацией TCP-соединение закрывается сервером. Но может продолжаться, для того, чтобы по нему послать ещё запросы, для этого браузер должен указать соответствующий параметр в заголовках (keep-alive) и время ожидания. Далее. HTTPS - HyperText Transfer Protocol Secure, защищенный HTTP. Запросы и ответы HTTP идут по интернету, проходя различные шлюзы и могут быть перехвачены, прочитаны третьей стороной, и также вероятно подменены. В протоколе HTTPS передаваемые данные шифруются, а также подписываются цифровой подписью, что предотвращает как возможность чтения третьей стороной, так и возможность подмены. Сначала HTTPS использовался в некоторых случаях, но постепенно он стал широко применяться на обычных сайтах. Из Википедии: Цитата [игнорируется] As of December 2022, 58.4% of the Internet's 135,422 most popular websites have a secure implementation of HTTPS, На декабрь 2022, 58.4% из самых популярных 135 422 сайтов в интернете имеют HTTPS. Цитата [игнорируется] Although the standard itself does not require usage of encryption,[49] all major client implementations (Firefox,[50] Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.[51] ... |
|||
:
Изменено: 03.08.2024, 17:38 - s62
Нравится:
Не нравится:
|
|||
03.08.2024, 17:35 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|||
---|---|---|---|
#18+
Теперь про HTTP/2 Сначала коротко, как бы декларативно, дальше не знаю, будет тут что-то детальней или нет. HTTP/1.1 был принят в 1999 году. С тех пор веб развивался, страницы становились тяжелее - картинки, мультимедиа, скрипты и т.д. По некоторой статистике при загрузке типовой страницы сегодня объем данных порядка 2 Мб, кол-во запросов - порядка 70. https://httparchive.org/reports/state-of-the-web?start=2020_06_01&end=latest&view=list Чтобы всё это работало быстрее, в 2015 был принят HTTP/2. Отличия такие (может не всё): - протокол бинарный, а не текстовый - обмен так же идет по одному TCP соединению, но по нему может идти параллельно передача нескольких данных в разных "потоках". Я так понимаю, что идут поочередно пакеты из этих разных "потоков". Это решает проблему, что пока с сервера грузится какой-то один ресурс, все остальные ждут в очереди окончания его загрузки. - Для нормальной работы предыдущего пункта есть приоритизация запросов. - Есть пуши (push) от сервера. Если раньше клиент запрашивает страницу, видит, что там есть ссылки и запрашивает ещё что-то, то сейчас сервер может сразу отправить нужное. Если сформулировать более в общем, то сервер может отправлять клиенту какие-то ресурсы без запроса (до запроса) клиента. Пишут, что это может приводить к ухудшению скорости, ширины канала, т.к. сервер не знает, какие ресурсы клиент уже получил, а какие нет и может отпрваить то, что уже у клиента есть. Эта фича опционная, клиент может запросить, чтобы сервер пуши не присылал. Хром в 2022 году вышел с отключенными по-умолчанию пушами. Тут про пуши например. Понятно, что для того, чтобы это работало, HTTP/2 должен быть реализован как на сервере, так и на клиенте (в браузере). Современные браузеры HTTP/2 поддерживают. Цитата [игнорируется] IIS поддерживает HTTP/2 в Windows 10[24] и Windows Server 2016. Apache 2.4.17 поддерживает HTTP/2 через модуль mod_http2 module[25]. nginx 1.9.5 поддерживает HTTP/2[26]. Цитата [игнорируется] 19 декабря 2016 года Google объявила, что Googlebot теперь поддерживает HTTP/2[27]. ... |
|||
:
Изменено: 05.08.2024, 00:33 - s62
Нравится:
Не нравится:
|
|||
05.08.2024, 00:23 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|||
---|---|---|---|
#18+
HTTP/3, как я понял, это тоже про скорость, также про безопасность. Семантика в HTTP/1.1, HTTP/2 и HTTP/3 - одинаковая. У них - одни и те же методы, коды статусов и большинство заголовков. Отличается транспортный протокол, по которому происходит обмен данными. В HTTP/1.1 и HTTP/2 - это TCP. В HTTP/3 - новый протокол поверх UDP: QUIC. Изначально это вроде был акроним: Quick UDP Internet Connections, но сейчас он вроде используется как просто название. Разработан в Гугле. Когда речь шла о HTTP/2, то затрагивали такой тормоз. По одному соединению может идти несколько запросов, а потом ответов (pipelining). И когда какой-то ответ идет долго, остальные ждут в очереди. В HTTP/2 это решено мультиплексированием - когда несколько ответов идут по одному TCP-соединению, писал об этом выше. Но есть ещё один тормоз, который остается и в HTTP/2 - на уровне TCP. TCP - это надежный протокол, обеспечивающий доставку данных. Я когда-то читал, не помню детали, наверное кто-то тут на форуме лучше знает, но в общем, при получении пакета данных получатель отправляет отправителю уведомление, что всё ок. Если нет - то сообщает, что не ок и тогда отправитель пытается послать пакет ещё раз, пока тот не дойдёт благополучно (наверное есть какие-то нюансы). Т.е. пакеты после него ждут, пока TCP разберется с ним. Это называется head-of-line blocking. В UDP такого механизма нет, там просто отправляется пакет и он либо принимается адресатом, либо нет. В QUIC восстановление потерянных пакетов происходит на уровне этого протокола в отдельном потоке данных. Т.к. тут тоже есть мультиплексирование, то остальным потокам, в которых передаются другие ресурсы, в таком варианте не приходится ждать. В QUIC интегрирован TLS1.3. Т.е. нет QUIC без TLS. Также эта интегрированность позволяет уменьшить количество запросов-ответов (roundtrip) при установлении соединения. Также, если я правильно понял, зашифрованы отдельные пакеты, поэтому для расшифровки не надо ждать, пока подойдут другие, как это в TCP - для TCP данные - это поток байтов и он не знает о границах пакетов на более высоком уровне. QUIC может быть реализован не в ядре ОС, а на пользовательском уровне (QUIC can be implemented in the application space, as opposed to being in the operating system kernel.) и, если не ошибаюсь, в каких-то реализациях так и есть. QUIC - это не UDP, это протокол поверх UDP и он реализует ряд функций, которые есть в TCP, но по-своему, например ту же повторную отправку недошедших пакетов данных. Пока что всё. ... |
|||
:
Изменено: 06.08.2024, 21:40 - s62
Нравится:
Не нравится:
|
|||
06.08.2024, 21:37 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|||
---|---|---|---|
#18+
UDP - протокол без установки соединения и пересчёта контрольной суммы, чем и хорош для видео и голоса. Гарантированная передача данных не нужна, ты не заметишь, если пиксель потеряешь. А вот слушает он вряд-ли, слушает скорее TCP и далее труба открывается, куда всё льётся ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2024, 21:51 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|
---|---|
#18+
UDP - протокол без установки соединения и пересчёта контрольной суммы, чем и хорош для видео и голоса. Гарантированная передача данных не нужна, ты не заметишь, если пиксель потеряешь. А вот слушает он вряд-ли, слушает скорее TCP и далее труба открывается, куда всё льётся В NGINX обмен по HTTP/3 идёт через 443 UDP порт. https://www.catchpoint.com/http2-vs-http3/nginx-http3 ... |
|
:
|
|
06.08.2024, 22:02 |
|
HTTP/2, HTTP/3, QUIC и т.д.
|
|
---|---|
#18+
UDP - протокол без установки соединения и пересчёта контрольной суммы, чем и хорош для видео и голоса. Гарантированная передача данных не нужна, ты не заметишь, если пиксель потеряешь. А вот слушает он вряд-ли, слушает скорее TCP и далее труба открывается, куда всё льётся В NGINX обмен по HTTP/3 идёт через 443 UDP порт. https://www.catchpoint.com/http2-vs-http3/nginx-http3 ... |
|
:
|
|
06.08.2024, 22:13 |
|
|
start [/forum/topic.php?fid=34&msg=842644&tid=18444]: |
0ms |
get settings: |
19ms |
get forum list: |
7ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
37ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
573ms |
get tp. blocked users: |
3ms |
others: | 11ms |
total: | 665ms |
0 / 0 |