Чим менший розмір веб-сайту, тим швидше він завантажується, і це не дивно.
Дивує те, що сторінка розміром 14 КБ може завантажуватися набагато швидше, ніж сторінка розміром 15 КБ - можливо, на 612 мс швидше - в той час як різниця між сторінками розміром 15 КБ і 16 КБ є незначною.
Це пов'язано з алгоритмом повільного запуску TCP. У цій статті ми розповімо, що це таке, як воно працює і чому вас це повинно хвилювати. Але спочатку ми швидко пройдемося по деяким основам.
Що таке TCP?
Протокол управління передачею (Transmission Control Protocol, TCP) - це спосіб використання Інтернет-протоколу (IP) для надійної передачі пакетів даних - іноді його називають TCP/IP.
Коли браузер запитує ваш веб-сайт (або зображення чи таблицю стилів), він робить цей запит за допомогою HTTP.
HTTP побудований на основі TCP, і один HTTP-запит зазвичай складається з багатьох TCP-пакетів.
Власне кажучи, IP - це просто система для надсилання пакетів даних з одного місця в Інтернеті в інше. IP не має способу перевірки того, чи пакет успішно прибув до місця призначення.
Коли мова йде про веб-сайти, важливо знати, що всі дані надійшли - інакше ми можемо отримати пропущені фрагменти веб-сторінки. Є й інші способи використання, де це не так важливо - наприклад, потокове відео в реальному часі.
TCP - це розширення IP, яке дозволяє браузеру і серверу вашого веб-сайту повідомляти один одному, які пакети були успішно доставлені.
Сервер надсилає кілька пакетів, потім чекає відповіді від браузера про те, що він отримав пакети (це називається підтвердженням або ACK), потім надсилає ще кілька - або, якщо він не отримав ACK, він може надіслати пакети знову.
Що таке повільний старт TCP?
Повільний старт TCP - це алгоритм, який використовується серверами, щоб з'ясувати, скільки пакетів він може відправити за один раз.
Коли браузер вперше встановлює з'єднання з вашим сервером - сервер не має можливості дізнатися про ширину каналу зв'язку між ними.
Пропускна здатність - це кількість даних, яка може бути передана через мережу за одиницю часу. Зазвичай вона вимірюється в бітах в секунду (біт/с). Поширеною аналогією є водопровід - уявіть собі пропускну здатність як кількість води, що може витікати з труби в секунду.
Ваш сервер не знає, скільки даних може обробити з'єднання - тому він починає з відправки вам невеликого і безпечного обсягу даних - як правило, 10 TCP-пакетів.
Якщо ці пакети успішно досягають відвідувача вашого сайту, його комп'ютер надсилає назад підтвердження (ACK) про те, що пакети були отримані.
Потім ваш сервер відправляє більше даних, але цього разу він подвоює кількість пакетів.
Цей процес повторюється до тих пір, поки пакети не стануть губитися і ваш сервер не отримає підтвердження ACK. (У цей момент сервер продовжує надсилати пакети, але з меншою швидкістю).
В цьому полягає суть повільного старту TCP - в реальному житті алгоритм змінюється, але по суті він працює саме так.
Так звідки ж береться 14 кб?
У більшості веб-серверів алгоритм повільного старту TCP починається з відправки 10 TCP-пакетів.
Максимальний розмір TCP-пакету становить 1500 байт.
Цей максимум не встановлений специфікацією TCP, він походить від стандарту ethernet
Кожен TCP-пакет використовує 40 байт в своєму заголовку - 16 байт для IP і додаткові 24 байти для TCP
Це залишає 1460 байт на TCP-пакет. 10 х 1460 = 14600 байт або приблизно 14 кБ!
Отже, якщо ви зможете вмістити свій веб-сайт - або його критичні частини - в 14 кБ, ви зможете заощадити відвідувачам багато часу - часу, необхідного для однієї пересилки між ними і сервером вашого веб-сайту.
Наскільки поганим може бути один запит в обидва боки?
Люди дуже нетерплячі - і один обхід може бути напрочуд довгим. Скільки часу залежить від затримки...
Затримка - це час, необхідний пакету даних для проходження від джерела до місця призначення. Якщо пропускна здатність - це кількість води, яка може пройти через трубу в секунду, то затримка - це час, необхідний краплі води, щоб увійти в трубу, а потім вийти з іншого кінця.
Ось цікавий приклад того, наскільки поганою може бути затримка:
Супутниковий інтернет
Супутниковий інтернет забезпечується супутником на орбіті навколо Землі. Ним користуються люди в дуже малонаселених районах, на нафтових вишках, круїзних лайнерах, а також в якості бортового Wi-Fi на авіалініях.
Щоб проілюструвати цей приклад поганої затримки, давайте уявимо, що група братів з нафтової вишки забула свої ігрові кості вдома і їм потрібно використовувати чудовий (менше 14 кБ) веб-сайт missingdice.com, щоб пограти в Dungeons & Dragons.
Спочатку один з них використовує свій телефон, щоб отримати доступ до веб-сторінки...
Телефон надсилає цей запит на WiFi роутер бурової установки - який надсилає ці дані на супутникову антену - давайте будемо люб'язні і скажемо, що це займає 1 мс.
Потім супутникова антена повинна відправити ці дані на супутник на орбіті над землею.
Зазвичай це досягається за допомогою супутника на геостаціонарній орбіті на висоті 35786 км над поверхнею Землі. Швидкість світла становить 299792458 м/с, тому повідомлення, надіслане з Землі на супутник, доставляється за 120 мс. Потім супутник відправляє повідомлення назад на наземну станцію, що займає ще 120 мс.
Потім наземна станція повинна відправити запит туди, де знаходиться сервер на землі (світло сповільнюється до 200000000 м/с, коли воно знаходиться у волоконно-оптичному кабелі). Якщо відстань між наземною станцією і сервером така ж, як відстань між Нью-Йорком і Лондоном, це займе близько 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 кБ пам'яті.
Як тільки ви втрачаєте відео, що автоматично відтворюються, спливаючі вікна, файли cookie, банери зі згодою на використання файлів cookie, кнопки соціальних мереж, скрипти відстеження, фреймворки javascript і css і весь інший непотріб, який нікому не подобається - ви, ймовірно, вже там.
Але, припустимо, що ви зробили все можливе, щоб вмістити все в 14 кБ, і не змогли - правило 14 кБ все ще корисне.
Якщо ви переконаєтеся, що перші 14 кБ даних, які ви відправляєте своїм відвідувачам, можуть бути використані для відображення чогось корисного - наприклад, деяких критично важливих CSS, JS і перших кількох абзаців тексту, що пояснюють, як користуватися вашим застосунком.
Примітка - Правило 14kB включає заголовки HTTP - які не стискаються (навіть при HTTP/2 при першій відповіді) - воно також включає зображення, тому завантажуйте тільки те, що знаходиться у видимій чачтині екрану, і робіть їх дуже маленькими, або використовуйте заповнювачі, щоб ваші відвідувачі знали, що вони чекають щось цікаве.
Деякі застереження до правила
Правило 14 кБ більше схоже на емпіричне правило, ніж на фундаментальний закон обчислень:
- Деякі сервери збільшили початкове вікно повільного запуску TCP до 30 пакетів замість 10
- Іноді сервер знає, що він може почати з більшої кількості пакетів, тому що він використовує рукостискання TLS для встановлення більшого вікна.
- Сервери можуть кешувати кількість пакетів, з якими може впоратися маршрут, і відправляти більше при наступному з'єднанні.
- Є й інші застереження - ось більш детальна стаття про те, чому правило 14kB не завжди працює
HTTP/2 і правило 14kB
Існує думка, що правило 14kB більше не діє при використанні HTTP/2. Я прочитав про це все, що міг, не занудившись до смерті - але я не бачив жодних доказів того, що сервери, які використовують HTTP/2, перестали використовувати повільний старт TCP, починаючи з 10 пакетів.
HTTP/3 і QUIC
Подібно до HTTP/2, існує думка, що HTTP/3 і QUIC покінчать з правилом 14kB - це не так. QUIC рекомендує те ж саме правило 14kB.
Читати далі
Значна частина контенту цієї статті взята з наступних ресурсів:
Ще немає коментарів