Чем меньше веб-сайт, тем быстрее он грузится, и это неудивительно.
Удивительно то, что страница на 14 КБ может грузиться гораздо быстрее, чем страница на 15 КБ, даже на 612 мс быстрее, хотя разница между страницами на 15 КБ и 16 КБ минимальна.
Так происходит из-за алгоритма медленного старта TCP. В этой статье я расскажу, что это такое, как оно работает и почему это важно. Но сначала мы вкратце расскажем об основах.
Что такое TCP?
Transmission Control Protocol (TCP) — это способ использования Internet Protocol (IP) для надёжной передачи пакетов данных; иногда его также называют TCP/IP.
Когда браузер запрашивает ваш веб-сайт (или изображение, или таблицу стилей), он выполняет запрос при помощи HTTP.
HTTP построен поверх TCP, один HTTP-запрос обычно состоит из множества пакетов TCP.
Сам по себе IP — это просто система отправки пакетов данных из одной точки Интернета в другую. IP не имеет возможности проверить, добрался ли пакет до пункта назначения.
Когда мы работаем с веб-сайтами, важно знать, прибыли ли все данные, в противном случае фрагменты веб-страницы будут потеряны. Существуют и другие способы применения веба, например, стриминг видео, но в данном случае это неважно.
TCP — это расширение IP, позволяющее браузеру и серверу веб-сайта сказать друг другу, какие пакеты успешно получены.
Сервер отправляет несколько пакетов, затем ожидает ответа от браузера, сообщающего, что он получил пакеты (это называется подтверждением приёма, acknowledgement, или ACK), затем отправляет ещё несколько пакетов, а если он не получил ACK, то может отправить пакеты повторно.
Что такое медленный старт TCP?
Медленный старт TCP (TCP slow start) — это алгоритм, используемый серверами для определения того, сколько пакетов можно отправить за раз.
Когда браузер выполняет подключение к серверу, сервер никак не может узнать ширину канала между ними.
Ширина канала (bandwidth) — это объём данных, который можно передать по сети за единицу времени. Обычно она измеряется в битах в секунду (бит/с). В качестве аналогии можно привести задачу про воду и трубы: ширина канала — это количество воды, которое может выливаться из трубы в секунду.
Ваш сервер не знает, с каким объёмом данных может справиться соединение, поэтому сначала он отправляет небольшое надёжное количество данных, обычно 10 пакетов TCP.
Если эти пакеты успешно добираются до посетителя сайта, то его компьютер передаёт подтверждение приёма (ACK), сообщающее об успешном получении пакетов.
Затем сервер отправляет новые данные, на этот раз удваивая количество пакетов.
Этот процесс повторяется до утери пакетов, когда сервер не получит ACK. (После этого сервер продолжает отправлять пакеты, но с меньшей частотой.)
Вот краткое описание медленного старта TCP. В реальной ситуации реализация алгоритма варьируется, но в целом он работает так.
Откуда же взялась величина 14 КБ?
Медленный старт TCP большинства веб-серверов начинает с отправки 10 пакетов TCP.
Максимальный размер пакета TCP составляет 1500 байтов.
Этот максимум определяется не спецификацией TCP, а стандартом Ethernet.
В каждом пакете TCP 40 байтов используются под заголовок — 16 байтов для IP и дополнительные 24 байта для TCP.
То есть на каждый пакет TCP остаётся 1460 байтов. 10 x 1460 = 14600 байтов, или приблизительно 14 КБ!
То есть если вы сможете уместить свой веб-сайт (или хотя бы его критически важные части) в 14 КБ, то сэкономите посетителям кучу времени, необходимого для передачи данных туда и обратно между ними и сервером веб-сайта.
Насколько долгим может быть путь туда и обратно?
Люди очень нетерпеливы, а один путь туда и обратно на удивление длителен. Его длительность зависит от задержки…
Задержка (latency) — это время, необходимое пакету данных для перемещения от его источника к конечной точке. Если ширина канала — это количество воды, проходящее через трубу за секунду, то задержка — это время, необходимое капле воды, чтобы попасть в трубу и выйти с другого конца.
Вот любопытный пример того, насколько плохой может быть задержка:
Спутниковый Интернет
Спутниковый Интернет предоставляется спутником на орбите Земли. Он используется в местах с очень низкой плотностью населения, на нефтяных платформах, круизных судах и для WiFi в самолётах на время полёта.
Чтобы проиллюстрировать этот пример ужасной задержки, представим, что компания нефтяников забыла свои кубики дома и хочет использовать замечательный сайт missingdice.com (меньше 14 КБ), чтобы сыграть в Dungeons & Dragons.
Сначала один из нефтяников через свой телефон выполняет запрос к веб-странице…
Телефон отправляет запрос WiFi-маршрутизатору платформы, передающему эти данные на спутниковую тарелку буровой платформы. Давайте будем щедрыми, пусть это занимает 1 мс.
Затем спутниковая тарелка должна отправить эти данные на спутник, летающий по орбите вокруг Земли.
Обычно для этого спутник выводят на геостационарную орбиту в 35786 км над поверхностью Земли. Радиоволны (и свет) движутся со скоростью 299792458 м/с, поэтому отправленное с Земли на спутник сообщение будет передано за 120 мс. Затем спутник отправляет сообщение на земную станцию, для чего требуется ещё 120 мс.
Затем земная станция должна отправить запрос в ту точку Земли, где находится сервер (перемещаясь по оптоволоконному кабелю, свет замедляется до двухсот миллионов м/с). Если расстояние между земной станцией и сервером такое же, как расстояние между Нью-Йорком и Лондоном, то он будет передан примерно за 28 мс, но если оно ближе к расстоянию между Нью-Йорком и Сиднеем, то это займёт 80 мс, так что остановимся на 60 мс (удобное для наших расчётов значение).
Затем сервер должен обработать запрос, что может занять, наверное, около 10 мс, после чего сервер отправляет его обратно.
Снова на земную станцию, в космос, обратно на спутниковую тарелку, затем на WiFi-маршрутизатор, и, наконец, в телефон нефтяника.
телефон -> WiFi-маршрутизатор -> спутниковая тарелка -> спутник -> земная станция -> сервер -> земная станция -> спутник -> спутниковая тарелка -> WiFi-маршрутизатор -> телефон
Если мы выполним расчёт, то получим 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 мс.
Это дополнительные 612 мс на каждый путь туда и обратно. Возможно покажется, что это не очень долго, но ваш веб-сайт лишь для получения первого ресурса запросто может выполнить множество таких передач туда и обратно.
Кроме того, до выполнения первого пути протоколу HTTPS требуется две дополнительных передачи, что даёт нам 1836 мс!
А какой задержка будет для людей, живущих на суше?
Может показаться, что мы намеренно выбрали плохой пример со спутниковым Интернетом. Я выбрал его потому, что он иллюстрирует моё утверждение, но он странный. Впрочем, для живущих на суше задержка по множеству причин может быть ещё хуже:
- Мобильная связь 2G обычно имеет задержку от
300 мсдо1000 мс - Сети 3G могут иметь задержку от
100 мсдо500 мс - «Шумные» мобильные сети, допустим, в необычно переполненном месте наподобие музыкального фестиваля
- Серверы, которым приходится справляться с большими объёмами трафика
- Различные неприятности
Прерывистые соединения тоже могут вызывать утерю пакетов, из-за чего может потребоваться ещё один путь туда-обратно для получения утерянных пакетов.
Что вы можете сделать, узнав о правиле 14 КБ?
Разумеется, вы можете сделать ваш веб-сайт как можно меньше — вы же любите своих посетителей и хотите, чтобы они были довольны. Стремление к тому, чтобы каждая страница умещалась менее чем в 14 КБ — хорошая цель.
Эти 14 КБ включают в себя сжатие, то есть на самом деле распакованных данных может быть примерно 50 КБ, что довольно щедро. Напомню, что управляющие ЭВМ «Аполлона-11» имели всего 72 КБ памяти.
Как только вы избавитесь от видео с автоматическим воспроизведением, всплывающих окон, куки, разрешающих куки баннеров, кнопок социальных сетей, скриптов слежения, фреймворков Javascript и CSS и от всего остального мусора, который никому не нравится, то, скорее всего, достигнете желаемого.
И даже если вы изо всех сил пытались уместить всё в 14 КБ, но не смогли, правило 14 КБ всё равно остаётся полезным.
Постарайтесь сделать так, чтобы первые 14 КБ передаваемых посетителям данных можно было использовать для рендеринга чего-то полезного, например, это могут быть какие-то критически важные CSS, JS и первые несколько параграфов текста, объясняющие, как пользоваться вашим приложением.
Примечание: в правило 14 КБ включаются и HTTP-заголовки, которые не упаковываются (даже с использованием HTTP/2 в первом ответе), а также изображения, поэтому загружайте только то, что находится наверху, и делайте их очень маленькими, или используйте заглушки, чтобы посетители знали, что их ждёт что-то хорошее.
Некоторые особенности этого правила
Правило 14 КБ — это эмпирическое правило, а не фундаментальный закон:
- Некоторые серверы увеличили окно медленного старта TCP с 10 до 30 пакетов
- Иногда сервер знает, что он может начать с большего количества пакетов, потому что использовал TLS handshake для определения того, что можно использовать большее окно.
- Серверы могут кэшировать количество пакетов, которое может выдержать соединение, и отправлять в следующий раз большее количество.
- Есть и другие особенности: вот более глубокая статья о том, что правило 14 КБ применимо не всегда
HTTP/2 и правило 14 КБ
Кто-то считает, что правило 14 КБ неактуально при использовании HTTP/2. Я прочитал по этой теме всё возможное, пока мне это не наскучило, но не встретил никаких свидетельств того, что серверы, использующие HTTP/2, больше не применяют в начале медленный старт TCP с 10 пакетами.
HTTP/3 и QUIC
Аналогично существует мнение, что HTTP/3 и QUIC отменяют правило 14 КБ, но на самом деле это не так. QUIC рекомендует использовать то же правило 14 КБ.
Дополнительные источники
Основная часть содержимого этого поста взята из следующих ресурсов:
Автор:
PatientZero
