Одним из аспектов производительности Интернета является сокращение задержек, связанных с взаимодействием с пользователем; получите готовую страницу максимально быстро.
Применительно к протоколу HTTP это означает, что идеальный протокол связи выглядит примерно так: 
Клиент отправляет минимально необходимый объем данных для описания своего запроса, а сервер передает ему минимально необходимый объем данных для отображения страницы, и все это происходит за минимально возможное количество раундов связи.
Дополнительные данные, отправленные на сервер или полученные от него, означают более длительное время загрузки и повышенную вероятность потери пакетов и перегрузки канала связи.
Лишние циклы отправки/получения данных из-за болтливости протокола и задержки (особенно в мобильных сетях, где 100мс - максимально возможное время ответа ) тоже ухудшают ситуацию.
Итак, если мы описали идеальный случай, соответствует ли ему протокол HTTP? И есть ли другой способ улучшить его? HTTP/1.1 HTTP/1.1 — хороший протокол по ряду причин, но, к сожалению, производительность не входит в их число из-за того, как его используют современные веб-приложения.
И сегодня они используют это так: 
Не очень хорошо.
Использование протокола HTTP/1 веб-приложениями довольно разговорчиво, поскольку клиент снова и снова обращается к серверу, чтобы загрузить необходимые ему файлы; Сначала загружается HTML, затем CSS и Javascript. Загрузка каждого последующего файла добавляет новую главу в наш «разговор» с сервером, увеличивает общую задержку загрузки страницы, нарушая наше правило «минимального необходимого количества раундов связи».
Более того, даже сами запросы к ресурсам уже добавляют много ненужных данных, нарушая правило «минимально необходимых данных».
Это связано с наличием заголовков вроде Referer, User-Agent и, конечно же, Cookie, которые повторяются в каждом запросе, иногда умножая в сто раз минимально необходимое количество (по количеству ресурсов, требуемых средней страницей).
современной сети).
И, наконец, из-за свойственного протоколу HTTP/1 явления.
замки HOL , стало обычной практикой объединять несколько отдельных ресурсов в один (например, CSS-спрайтинг ).
Однако за все эти изящные взломы протокола HTTP/1 приходится платить; они заставляют клиента загружать больше данных, чем ему необходимо в данный момент для отображения конкретной страницы, что нарушает описанный нами идеальный случай, а значит, мы не будем показывать страницу максимально быстро.
Несмотря на все сказанное, HTTP/1.1 по-прежнему не так уж и плох, даже с точки зрения производительности.
Например, у него есть кэширование , что избавляет вас от повторной загрузки неизмененных ресурсов, а также условные запросы , который сообщит вам, нужно ли загрузить новую версию файла.
HTTP/2 Протокол HTTP/2 пытается решить проблемы версии 1.1 несколькими способами:
- Полное мультиплексирование означает решение проблемы блокировки HOL. Вы можете загружать все ресурсы на своей странице через одно HTTP-соединение и не беспокоиться о том, сколько запросов для этого потребуется.
«Оптимизации», предполагающие объединение файлов в один, можно оставить в прошлом.
- Сжатие заголовков решает проблему избыточности заголовков.
Теперь вы можете уместить десятки (или даже сотни) запросов всего в несколько IP-пакетов.
Это серьезно приближает нас к «минимально необходимому набору данных» нашего идеального протокола.
- HTTP/2 позволяет серверу отправлять данные клиенту до того, как клиент их запросит, исходя из предположения, что они ему скоро понадобятся.
Это уменьшает количество раундов связи между клиентом и сервером.
Здесь вы можете увидеть, как сервер начинает отправлять CSS и Javascript клиенту еще до того, как клиент об этом запросил.
Сервер знает, что клиент, запрашивающий HTML, скорее всего, запросит связанные с ним файлы CSS и Javascript, а значит, сможет отправить их, не дожидаясь самого запроса.
Таким образом, мы тратим меньше времени на ожидание и более эффективно используем сеть.
Следует отметить, что все это работает не так просто.
В HTTP/2 до сих пор остаются открытые вопросы относительно того, что и когда серверу следует рассмотреть возможность отправки без запроса клиента.
HTTP/2 + дайджесты кэша Хороший вопрос относительно передачи файлов, инициируемой сервером: «Что, если у клиента уже есть его копия в кешеЭ» Действительно, было бы глупо принудительно отправлять клиенту то, что у него уже есть.
В этом случае HTTP/2 позволяет клиенту преждевременно прекратить загрузку такого ресурса, используя сообщение RESET_STREAM. Но даже в этом случае мы носимся с ненужными данными, добавляя еще один раунд общения, которого нам хотелось бы избежать.
Вы помните правило из первого абзаца статьи: «отправлять только минимально необходимое количество данных для отображения страницы».
Предлагаемое решение проблемы – дать клиенту возможность сформировать компактную дайджест кэша и отправить его на сервер, чтобы он знал, какие ресурсы клиенту точно не нужны.
Поскольку дайджесты кэша используют Коды Голомба , вполне реально предположить, что для страницы среднего размера браузеру потребуется менее 1000 байт, чтобы объяснить серверу, какие ресурсы он имеет в своем кеше.
Теперь мы действительно избегаем ненужных циклов общения клиента и сервера, передачи ненужных данных, слияния нескольких файлов в один и тому подобных хаков, а также неэффективной передачи ненужных нам данных.
Это очень приближает нас к идеалу! Дайджесты кэша — это пока всего лишь предложение по расширению протокола, но среди HTTP-сообщества к ним имеется большой интерес.
Мы обязательно увидим и оценим их использование в самом ближайшем будущем.
TCP Давайте поговорим о влиянии на общую производительность других протоколов, используемых браузером для загрузки страниц.
И это также может быть важно: TCP использует трехкратное рукопожатие еще до отправки первого байта HTTP-байта: 
Это добавляет ощущение «болтливости» каждому сеансу общения.
TCP быстрое открытие позволяет приложениям отправлять данные непосредственно в пакетах SYN и SYN+ACK. К сожалению, в настоящее время это поддерживается только в Linux и OSX, и более того, существуют некоторые особенности использования TCP Fast Open специально с протоколом HTTP, над которыми сообщество сейчас работает. Например, не гарантируется, что данные, прикрепленные к пакету SYN, будут отправлены только один раз.
Это открывает потенциальную уязвимость воспроизведения, которую можно использовать для атак.
Таким образом, запрос POST не является хорошим кандидатом для TCP Fast Open. Более того, некоторые GET-запросы также имеют заметные побочные эффекты, и у браузеров нет средств отличить такие запросы от тех, которые не имеют таких эффектов.
ТЛС TLS добавляет еще один уровень взаимодействия между клиентом и сервером после установки TCP-соединения.
Это выглядит так: 
Это два полных раунда обмена сообщениями, прежде чем протокол HTTP отправит свой первый запрос; Довольно разговорчиво, не так ли? Если клиент и сервер уже общались ранее, мы можем несколько сократить общение: 
Скоро ТЛС 1.3 позволит добиться «нулевого» рукопожатия для случая, когда клиент и сервер уже общались ранее — иными словами, протокол HTTP сможет добавить полезную нагрузку к первому пакету данных, отправленному на сервер.
Но, как и в случае с TCP Fast Open, необходимо какое-то решение, позволяющее избежать дублирования запросов.
HTTP/следующий TCP Fast Open и TLS 1.3 сокращают количество обращений между клиентом и сервером при открытии соединения.
Другой способ добиться того же — повторно использовать ранее открытое соединение.
В настоящее время ведутся споры о том, как более агрессивно объединять соединения HTTP/2; это позволит не только избежать затрат на открытие новых соединений, но и позволит более эффективно использовать существующие — протокол TCP наиболее эффективен в долгоживущих соединениях, плотно заполненных данными.
Оно включает отправка сертификатов клиенту , доказывая, что соединение можно безопасно повторно использовать для работы с другими источниками.
Сейчас обсуждаются еще более радикальные эксперименты: замена TCP на UDP, кажется QUIC .
Здесь много спорных вопросов, но сама перспектива свести первоначальный обмен данными практически к нулю очень привлекательна.
Более того, возможность доступа к данным вне того порядка, в котором они были отправлены, также может быть очень полезной.
Это еще один способ избежать блокировки HOL в TCP (протокол доставки упорядоченных пакетов).
Мы можем выбрать из потока пакетов нужные нам, понять, что некоторые потеряны, запросить их снова — и продолжить обработку следующих, не дожидаясь результатов повторного запроса.
QUIC только начинается, поэтому мы не увидим его хорошей реализации в ближайшее время (или, возможно, никогда).
Один из возможных вариантов — изучить плюсы и минусы подхода на примере QUIC, чтобы понять, как мы можем улучшить производительность TCP без необходимости внесения столь радикальных изменений в веб-архитектуру.
Теги: #http #Высокая производительность #ИТ-стандарты #браузеры
-
Подробнее О Смартфонах Blackberry
19 Oct, 24 -
Пауки
19 Oct, 24 -
Злые И Бедные Российские Интернет-Магазины
19 Oct, 24 -
Анонс Ноды 0.4 - Второй Стабильной Ветки
19 Oct, 24
