Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
по ходу чтения возникли некоторые вопросы.
во первых, про обрыв соединения на этапе установки tls соединения, вроде как, у нас ech блокируется в tls1.3, небыло возможности проверить?
во вторых, касательно всплеска tcp соединений, http2 использует мультиплексирование, поэтому для провайдера клиента не имеет значения то, сколько именно запросов он делает, ведь они идут через одно tcp соединение и трафик выглядит идентично (особенно если учитывать тлс). могу предположить, что дело в рейтлимите или ограничении max_concurrent_streams?
буду рад если ответите
про ech в tls 1.3 - на сервере его не включали, но провайдеры у нас его реально режут наглухо. вполне вероятно что у части юзеров браузер пытался подтянуть ech и соединение тупо падало на clienthello.
про http2 согласен, я там уже обновил и переписал этот блок в статье. при http2 соединение одно и мультиплексирование работает. проблема была именно в качестве самого канала до зарубежного ип. при потере пакетов на плохом канале проявляется head-of-line blocking и пачка стримов начинает отваливаться по таймаутам. плюс внешняя зависимость telegram.org зависала сама по себе.
переезд на московские ноды selectel cdn как раз и закрыл проблему с каналом. а склейка бандла была уже вторичной историей чтобы убрать лишние rtt.
касательно ech, раз поддержки небыло, то клиенты не могли его использовать, т.к. сервер не заявил о поддержке, так что да, вероятнее всего проблема в самом качестве соединения. (дополнительно не очень понял, почему был сделан вывод, что соединение рвется именно на clienthello, вроде в девтулзах настолько подробной информации нет, хотя могу ошибаться)
а про склейку бандла - интересно, вообще не очень понял при чем тут rtt, ведь контент запрашивался бы параллельно. да и в контексте использования cdn, наверное склеивать бандл все таки странное решение. после подключения cdn проводили замеры какие нибудь? пробовали старый подход с множеством файлов при использовании cdn? не увидел в статье четких цифр и замеров, если они есть - было бы интересно посмотреть, так как решение не очевидное. спасибо
про clienthello - тут да, обычные девтулзы этого не покажут. смотрели через chrome://net-internals на компе у одного из юзеров, там видно что рвётся именно на этапе рукопожатия.
про склейку бандла - справедливое замечание. cdn там и правда основной фикс, он закрыл проблему с каналом полностью, а склейка бандла это уже была доп подстраховка сверху, не более того. решение принято в 2 ночи, без замеров до/после именно на cdn, чисто чтобы убрать лишнюю точку отказа раз уж всё равно копался в сети. если бы это был единственный фикс без cdn, я бы сначала померил. по мере роста проекта вернём нормальный vendor-chunking, но пока для моего масштаба (нечастые деплои, небольшое приложение) склейка себя оправдывает.
все равно не очень понял про rtt. если правильно помню, в http2 у нас есть окно как общее, так и у каждого стрима свое, поменьше. то есть, когда мы отдаем множество мелких файлов, они зачастую влезают в окно стрима, и вот таким образом rtt экономятся (если мы про round trip, конечно же). а вот если файл большой, и влезает в общее окно соединения, но не влезает в окно конкретного стрима, то отдав часть файла, нужно ждать пока клиент увеличит окно, и вот это вроде бы и увеличивает rtt, а не уменьшает.
дополнительно не вижу проблем в head of line блокировках. созданием большого бандла это точно не исправить, потери это врядли может уменьшить. поэтому все равно не до конца понимаю, как это может быть хоть в какой то степени полезно
насчёт окон и hol, тут по делу, per-stream окно я не учёл, а hol на уровне tcp и правда никак не лечится склейкой файлов, раз всё идёт через одно соединение. если честно, объяснял это тогда интуицией, а не разбором механизма, и явных доказательств что склейка что-то ускорила у меня нет, кроме сокращения числа отдельных http-запросов. cdn был единственным подтверждённым фиксом, и он закрыл проблему полностью сам по себе. надо было в статье сразу так и написать, а не пытаться подкрепить довесок теорией которая не выдерживает проверки. поправил блок в статье, спасибо
это не совпадение, это системная штука
👏
Мы были вынуждены упаковать все в один чанк, на кеширование это влияет никак но зато помогло кратно повысить скорость загрузки. Когда пошли жалобы я сам открыл девтулзы и смотрел как чанки начиная со 2 грузятся со скоростью... вы видели как картинки на 33.600 грузились?
"На шестой день Зоркий Глаз заметил, что в тюрьме нет одной стены" )
Штош, бывает. Так-то уже давно приходится учитывать "системную деградацию зарубежных ip", также известную как Чебурнет.
Если вам принципиально важно сохранить местонахождение бекенда на зарубежных ip, но возможно перенести доменные имена в нашу "локальную сеть" - можете попробовать ещё проксирование через nginx: разместить его на внутренних серверах, к которым нет вопросов у тспу, а upstream с них прокинуть на реальный бекенд там.
Сдается, что сложив многое в один пакет, можно только ухудшение кеширования заработать.
попробуйте ещё пакеты меньшей длины слать (искусственное занижение MTU). Ловим прецедент, внутри VPN-канала HTTPS-хэндшейк не выполняется, “вчера всё работало”, ни клиент ни сервер просто так конфиг не меняли, у соседей с другого региона работает, при смене провайдера у проблемного клиента тоже работает. Пришли к выводу, что слишком длинные пакеты фрагментируются на сетях провайдера (потому как дефолтный конфиг таки влезал в 1500 байт с инкапсуляцией), и там же дропаются. Обошли занижением MTU на VPN-интерфейсе у конкретного клиента.
приложение не открывается.
у кого-то заходит, только если включить VPN.
О каком приложении речь? И оно именно не открывается, или не соединяется с чем-то, или не выполняет какую-то функцию?
А как оно ведет себя если вообще сети нет?
Тут все по классике - в т.ч. и то, что у всех все по-разному. Более того, у нас часть пользователей самостоятельно решила эту проблему подключившись через SOCKS и HTTP (правда, без S) прокси - и у некоторых так заработало, а у некоторых так и вообще перестал идти коннект. А напрямую передавало хотя бы первые 16 килобайт.
Тоже столкнулся с этим. Проблема один в один как ниписали. Причём скрипты лежали на российском сервере.
Началось по моим наблюдениям примерно в марте-апреле.
Проблема проявлялась у пользователей по мобильной сети и только с телефонов. На компах через мобильную раздачу работало. Через проводной интернет все работало без проблем на любых устройствах.
Сокращал количество чанков до 5-ти - один фиг, 2 грузится, 3 в таймаут. Причём в хаотичном порядке.
Решил вопрос подключением CDN через Яндекс. Теперь 20 чанков грузятся без проблем.
Полдня подозревал браузеры и TLS, ещё день считал запросы, а трафику в итоге просто понадобилась пересадка в Москве. Очень жизненно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приложение открывается только с VPN. Разбирался почему