Як швидкість світла обмежує швидкість твого веб-сайту

Головне

• Умови задачі: бекенд у Лос-Анджелесі/Сан-Франциско обробляє запит за 20 мс, клієнт у Києві, між ними ~10 000 км. Навіть за абсурдно оптимістичних припущень — один прямий оптоволоконний кабель, без Wi-Fi, без маршрутизації, без провайдерів — фізика задає нижню межу.
• Математика: світло у вакуумі — 300 000 км/с, а в оптоволокні ~200 000 км/с (на третину повільніше). 10 000 км в один бік = 50 мс, тож ping туди-назад = 100 мс у найкращому разі. Його конкретний висновок: з Києва ви ніколи не гратимете в CS:GO на американських серверах із пінгом менше 100 мс — швидкість світла не дозволить.
• Складаємо round-trip-и: запит (50 мс) + бекенд (20 мс) + відповідь (50 мс) = 120 мс, уже 6× часу бекенда. Додаємо TCP handshake (SYN / SYN-ACK / ACK) — ACK може нести дані запиту, тож це ~один додатковий round-trip → 220 мс (11× бекенда). Додаємо TLS handshake (Hello, сертифікат, обмін ключами, в обидва боки) → ~420 мс, 21× від 20 мс реальної роботи. І він зауважує, що це ще без DNS-запиту й TCP slow start (не можна одразу вистрелити 50 KB на повній швидкості).
• Саме тому важливі CDN — не через «сиру» швидкість, а через зменшення затримки: статичні файли/зображення розміщуються ближче до користувача.
• Перевірка на практиці: він підняв nginx-сервер у Лос-Анджелесі, зробив субдомен і зняв у Wireshark звичайний HTTP- та HTTPS-запити. Сам TCP handshake показав ~190–192 мс на round-trip; запит/відповідь по звичайному HTTP — ~400 мс; повний HTTPS-запит вийшов ~800 мс — приблизно 2× від його теоретичних 420 мс. Звичайний ping підтвердив ~192 мс туди-назад — гірше за ідеал через реальний Wi-Fi, провайдерів і непрямі маршрути.
• Він звертає увагу на ACK-и, що повторюються по всьому дампу: TCP мусить підтверджувати отримані дані (UDP — ні), і це базовий компроміс надійності та частина ціни.