А, понял. А SNI при этом остаётся прежним? А если MTU уменьшить, заметна разница?
В TLS вообще нельзя влезть, в нем защита от изменений. Любой бит изменить - сеанс порушится.
Так что да. SNI остается.
Если MTU уменьшить до такой степени, что разделение пройдет до фактического конца SNI (около 300 байтов), то да. Но скорость замедлится, потому что резать будет все. И ipv6 отвалится
обходилки DPI режут лишь пакеты с TLS ClientHello, остальное не трогают
Ясно. Ну тогда это определённо намеренные действия. Интересно только на каком участке это производится?
Там ещё такой момент, что тот же гугл требует при превышении некоторого объёма трафика у крупных операторов обязательно переходить на PNI, даже если прямая сессия ранее на ТОТ была установлена. А на российских ТОТ сейчас порты гугла почти закончились, расширить канал тоже сложно. Поэтому и предлагается гонять трафик в Франкфурт и Амстердам. Так что, возможно, таким образом хотят уменьшить количество трафика? Хорошо бы поделать тесты с разных операторов, чтобы понять, все ли они подвержены замедлению или нет. С Филанко я разницы особо не вижу:
$ curl -s -o/dev/null -k --connect-to ::google.com -k -L -H Host:\ mirror.gcr.io --range 0-40000000 --max-time 30 https://mirror.gcr.io/v2/cimg/android/blobs/sha256:6fd8bdac3da660bde7bd0b6f2b6a46e1b686afb74b9a4614def32532b73f5eaa -w %{speed_download}
41023580
$ curl -s -o/dev/null -k --connect-to ::google.com -k -L -H Host:\ mirror.gcr.io --range 0-40000000 --max-time 30 https://test.googlevideo.com/v2/cimg/android/blobs/sha256:6fd8bdac3da660bde7bd0b6f2b6a46e1b686afb74b9a4614def32532b73f5eaa -w %{speed_download}
44651928
Это понятно. Но, похоже, что всё же зависит от оператора, так как вон в тестах выше не замечено разницы от того, какой SNI используется для скачивания файла
Вчера вечером у меня еще не резалось, а сегодня с утра - да
Поделал несколько тестов с curl и разными SNI, интересные результаты получил.
-
Если сеть напрямую подключена в ТОТ и имеет сессию с ней (сравнивал нижеуказанные варианты)
AS28917 MSK-IX → AS15169 msk-ix-gw1.google.com
AS29076 Cloud-IX → AS15169 google-gw.msk.cloud-ix.net
AS50952 DataIX → AS15169 as15169.ix.dataix.eu
то замедления нет, SNI никак не влияет на скорость. -
Если же прямой сессии нет, и трафик идёт через какого-нибудь промежуточного оператора, то при использовании SNI googlevideo наблюдается снижение скорости. Причём оно разное, и зависит от оператора, например, у Selectel разница в два раза, а у CityTelecom в 4 раза.
Так что можно сделать вывод, что замедление проводится на оборудовании конечных операторов, а не на ТОТ. Вопрос остается лишь сделано это на ТСПУ или же самими операторами? Надо бы больше тестов с различных точек и указаниями маршрутов.
А какой оператор? Можно mtr сделать до узла mirror.gcr.io, желательно с ресолвингом ASN (опция -z)?
sknt
4. AS35807 93.100.0.63 5. AS35807 185.37.128.162
6. AS15169 72.14.205.120
7. AS15169 74.125.244.132
8. AS15169 216.239.48.163
9. AS15169 72.14.235.193 0.0% 5 5.1 5.1 4.9 5.6 0.3
10. (waiting for reply)
...........
18. (waiting for reply)
19. AS15169 64.233.164.82
tiera
1. AS39598 95.161.x.x
2. AS??? 10.148.0.61 3. AS??? 10.148.0.26
4. AS??? 10.148.0.18
5. AS31500 109.239.128.82
6. AS??? 178.18.225.41 7. AS15169 74.125.244.180 8. AS15169 216.239.48.163 9. AS15169 172.253.64.51 10. (waiting for reply)
..........
20. (waiting for reply)
21. AS15169 74.125.131.82
Ага, вот уже интереснее. А на Tiera вижу маршрут через тот же dataix идёт, как у меня. Разница между замерами тоже в два раза или другая? И какие узлы при этом у гугла видны тут? http://redirector.googlevideo.com/report_mapping?di=no
Сейчас 120-200K / 3.5-4M
95.161.x.x => led03s01 : router: “pr03.led03” next_hop_address: “127.0.0.1” (95.161.x.0/22)
Я вчера и сегодня проверял, никакой разницы нет…
Трассировка не принципиальна: замедление происходит при подключении к любому хосту (IP-адресу).
В командах тестирования выше подключение выполняется на google.com (--connect-to ::google.com). Домен в URL (https://mirror.gcr.io/…) используется только для SNI.
Я тестировал только домашние подключения. На серверных замедления не вижу, но у меня всего несколько серверов в РФ.
Кто знает, может они только часть ТСПУ задействовали для этого “теста”
Вот сейчас со скайнета, похоже, вообще не замедляют. Что со сплитом, что без 2M дает.
Там трейс идет напрямую на AS15169
На серверных, такое чувство, что до сих пор никаких ограничений в принципе не стоит - на серваке в Питере ни блокировок, ни замедлений (вообще никаких)
Подтверждаю, УРФО - тоже отключили.
На моих каналах без изменений.
Из-за того, что youtube загружает видео кусками с паузами между ними, и иногда переустанавливает соединение, у меня видео особо не тормозит. Проблемы начинаются только на 4K@60, на него канала с замедлением уже не хватает — выше 30 мбит/с пиковая скорость не поднимается.
С tpws из zapret (--split-tls=sni --disorder) пиковая скорость легко достигает 350 мбит/с (на канале 500 мбит\с).
2024-07-13T13:15:00Z
| name | isp | asn | city | Google IP + GCR SNI (KB/s) | Google IP + Googlevideo SNI (KB/s) |
|---|---|---|---|---|---|
| ru-001 | ТТК | AS8427 | Magnitogorsk | 6318 | 448 |
| ru-003 | МТС | AS28832 | Chelyabinsk | 7008 | 294 |
| ru-004 | МГТС | AS25513 | Moscow | 28884 | 712 |
| ru-005 | Dom.ru | AS49048 | Tver | 5260 | 696 |
| ru-006 | Dom.ru | AS50544 | Krasnoyarsk | 7572 | 459 |
| ru-008 | Ростелеком (онлайм) | AS42610 | Moscow | 7931 | 543 |
| ru-009 | Линклайн | AS44041 | Moscow | 8439 | 6284 |
| ru-010 | МГТС | AS25513 | Moscow | 7939 | 578 |
| ru-011 | ENEVA/OBIT | AS8492 | Saint Petersburg | 7615 | 462 |
| ru-012 | Beeline/Corbina | AS8402 | Tula | 8239 | 470 |
| ru-013 | Dom.ru | AS50543 | Saratov | 2087 | 333 |
| ru-014 | Rostelecom | AS12389 | Orenburg | 284 | 83 |
| ru-019 | JSC Ufanet | AS60095 | Nizhny Novgorod | 8167 | 495 |
| ru-020 | PJSC MegaFon | AS31205 | Khakasiya | 332 | 337 |
| ru-021 | ER-Telecom Holding | AS56981 | Tomsk | 5047 | 389 |
| ru-022 | Sibirskie Seti | AS40995 | Novokuznetsk | 6955 | 275 |
| ru-023 | Rostelecom | AS12389 | Perm region | 13384 | 430 |
| ru-025 | Rostelecom | AS12389 | Kemerovo | 3819 | 230 |
| ru-026 | Rostelecom | AS12389 | Kemerovo | 3541 | 3508 |
| ru-027 | Sibirskie Seti | AS47433 | Kemerovo | 126 | 86 |
| ru-028 | Beeline | AS3216 | Kemerovo | 126 | 97 |
| ru-029 | Beeline | AS16345 | Kemerovo | 753 | 1246 |
| ru-030 | ER-Telecom Holding | AS34533 | Syzran’ | 8198 | 715 |
| ru-031 | Beeline | AS42110 | Sochi | 7428 | 340 |
| ru-032 | Sibirskie Seti Ltd. | AS34757 | Novosibirsk | 638 | 89 |
| ru-033 | P.a.k.t LLC | AS39087 | Saint Petersburg | 8398 | 849 |
| ru-036 | Igra-Service | AS33991 | Krasnoyarsk | 6970 | 363 |
| ru-038 | Beeline | AS8402 | Krasnodar | 6065 | 352 |
| ru-040 | Dom.ru (EG/Novotelecom) | AS31200 | Novosibirsk | 6971 | 346 |
| ru-041 | Zeltelecom | AS57652 | Moscow | 7258 | 372 |
Подтверждаю, при просмотре 1080p30/1080p60 даже с замедлением, не заикается видео замечал.
Для 4К уже не хватает скорости.
Эти разрешения в ютубе сжимаются с битрейтом примерно плавающий битрейт ~ 5000 клбти/c. А 4K сжимают с ~ 25мбит/с плавающий битрейт.
а ты уверен что все таки блокируют, а не сам ютуб устраивает боротьбу с загрузками? имхо если вот такая загрузка была, я наверное 4К спокойно не мог открыть
но 4К спокойно без буферизации можно смотреть
а загрузка через ytdlp считается? через впн нормально, без впна вот такие скоростя
Как Ютуб может на что-то влиять, если вы на скринкасте в обоих командах качаете тестовый файл из Селектела?
Как вариант - трафик с Ютуб не проходит через ТСПУ в вашем случае.