Сайт не открывался на iPhone. Причём тут РКН, ТСПУ и HTTP/2

На Hitro-Shop.ru поймал странную проблему: у части людей сайт плохо открывался на iPhone через мобильный интернет.

Не у всех. Не всегда. Именно чаще на iPhone.

На Android и ПК при этом сайт мог открываться нормально.

В такой ситуации первое подозрение сейчас очевидное: РКН, ТСПУ, DPI, мобильные операторы и вся инфраструктура, которая может вмешиваться в трафик.

Но это была не классическая блокировка, когда сайт просто недоступен для всех.

Проблема выглядела иначе: сайт зависал, открывался через раз или не догружал часть ресурсов.

Один из шагов, который мог помочь, — включение HTTP/2.

И тут важный момент: HTTP/2 не обходит блокировки РКН и не «лечит ТСПУ». Он просто меняет то, как браузер загружает сайт.

Что могло ломаться

Когда человек открывает сайт, браузер загружает не один файл.

Он забирает HTML, CSS, JS, картинки, иконки, шрифты, счётчики и другие ресурсы.

Hitro-Shop.ru — это каталог товаров. На странице много карточек и картинок. Значит, для браузера это не один запрос, а пачка запросов к одному домену.

На HTTP/1.1 браузер обычно открывает несколько параллельных соединений.

Условно:

соединение 1 → HTML
соединение 2 → CSS
соединение 3 → JS
соединение 4 → картинка
соединение 5 → картинка
соединение 6 → картинка

Каждое соединение — это отдельный TCP + TLS handshake.

То есть наружу несколько раз подряд улетает примерно один и тот же набор признаков:

ClientHello
SNI: hitro-shop.ru
TLS-отпечаток Safari/iOS

Для обычного пользователя это просто «открываю сайт».

Для DPI или ТСПУ это набор технических признаков:

• какой домен открывают;
• какой клиент подключается;
• какой TLS-профиль у браузера;
• сколько соединений идёт параллельно;
• как выглядит общий рисунок трафика.

И если оборудование оператора криво реагирует на такую комбинацию, сайт может не блокироваться полностью, а просто плохо загружаться.

Почему чаще именно iPhone

Дело не в том, что iPhone хуже Android.

Дело в том, что iPhone для сети выглядит иначе.

Когда Safari на iOS подключается к HTTPS-сайту, он отправляет свой TLS ClientHello. В нём есть набор признаков: версии TLS, шифры, расширения, ALPN, SNI и другие параметры.

Это можно назвать TLS-отпечатком браузера.

У Safari/iOS он один. У Chrome на Android — другой. У Chrome на Windows — третий.

DPI не обязательно «видит айфон» как устройство. Но он видит характерный сетевой профиль Safari/iOS.

И вот здесь появляется важная связка:

iPhone / Safari
+ мобильный оператор
+ SNI hitro-shop.ru
+ TLS-отпечаток Safari
+ несколько параллельных HTTPS-соединений

Если сбой возникает именно на такой комбинации, то чаще страдают пользователи iPhone через мобильный интернет.

Не потому что сайт сломан только для iPhone.

А потому что именно эта связка даёт другой рисунок трафика.

Плюс на iPhone браузеры обычно ведут себя ближе друг к другу, потому что сильно завязаны на системную сетевую логику iOS.

На Android больше разнообразия: разные браузеры, разные реализации, разные TLS-профили, разные прошивки.

Поэтому Android и ПК могут проходить нормально, а iPhone у части пользователей — попадать в проблему.

Причём тут мобильный интернет

Wi-Fi и мобильный интернет — это разные маршруты.

Через домашний Wi-Fi трафик идёт через одного провайдера.

Через мобильный интернет — через мобильного оператора. Там могут быть свои DPI, свои ТСПУ, свои NAT, свои маршруты и свои странности.

Поэтому ситуация вполне реальная:

ПК + Wi-Fi → сайт открывается
Android + мобильный интернет → сайт открывается
iPhone + Wi-Fi → сайт открывается
iPhone + мобильный интернет → сайт зависает

Это не противоречие.

Это разные клиенты и разные сетевые цепочки.

Что меняет HTTP/2

HTTP/2 позволяет загружать много ресурсов через одно TLS-соединение.

Это называется multiplexing.

Условно:

одно TLS-соединение
    ├── HTML
    ├── CSS
    ├── JS
    ├── картинки
    ├── иконки
    └── шрифты

То есть вместо нескольких отдельных TLS-подключений браузер может держать одно соединение и внутри него тащить сразу много файлов.

Для пользователя сайт остаётся тем же.

Но для сети картина меняется.

Становится меньше повторяющихся событий:

ClientHello + SNI + TLS fingerprint

Если проблема была в том, что DPI, ТСПУ или оборудование оператора криво реагировало на пачку параллельных HTTPS-соединений от Safari/iOS, HTTP/2 мог убрать один из триггеров.

Не гарантированно решить проблему.

Но снизить вероятность сбоя.

Почему это важно именно для каталога

На простой текстовой странице разница могла бы быть почти незаметной.

А каталог товаров — это много ресурсов.

На странице есть карточки, изображения, стили, скрипты, иконки, возможно, шрифты и счётчики.

Для HTTP/1.1 это часто означает несколько параллельных соединений к одному домену.

Для HTTP/2 — одно соединение и несколько потоков внутри него.

Поэтому включение HTTP/2 могло повлиять не только на скорость, но и на стабильность загрузки в конкретных сетевых условиях.

Что важно понимать в итоге

HTTP/2 не обходит блокировки РКН и не чинит ТСПУ.

Но если проблема не в жёсткой блокировке, а в кривой загрузке у части пользователей, он может помочь.

HTTP/2 изменил поведение загрузки: браузер стал меньше плодить отдельные соединения к домену.

И этого могло хватить, чтобы сайт начал открываться стабильнее.

Главный вывод простой: если сайт странно не открывается у части пользователей, особенно на iPhone, не надо смотреть только в код.