Re[15]: TCP все...
От: ononim  
Дата: 18.11.18 10:39
Оценка:
C>>>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков.
O>>Учитывая вводные (свой код клиента и сервера)
C>Откуда такая вводная? Клиент может быть совершенно любой.
Это вводные, равнозначные вводным QUIC'а.

C>Ну ладно, предположим, что мы колхозим в Chrome, а остальных отправляем в канал с обычным MTU в 1380.

Угу.

C>Вот Вася сидит в региональном отделении православного банка Рогатус&Копытус. Его локальный MTU — это 1500 байт (Ethernet), но его филиал подключён к Интернету через VPN и PPPoE, которые отъедают примерно 90 байт пакетов.

C>Так что PMTU получается в 1410. Гугл начинает передавать ему данные, наращивает окно и в итоге передаёт пакет в 1411 байт. Этот пакет не проходит через финальный VPN и клиент VPN отправляет в сторону Гугла сообщение ICMP о том, что пакет слишком большой.
Ненене. Не нужно никаких ICMP. Они считать что ICMP проходит — то вообще ничего не нужно, PMTU discovery придуман давно, но он не работает когда ICMP блочится. Что является корнем проблемы с PMTU. Т.о. нужно определять PMTU без использования ICMP.

C>Но не тут-то было! Так как банк — большой и очень умный, то исходящий трафик фильтруется через middlebox, который считает ICMP изобретением дьявола и блокирует его. Тем более, что трафик ещё и на сервера в Калифорнии идёт. Нельзя такого допускать, никак нельзя.

Да!

C>И всё, пользователь видит застывшую полосу загрузки. Через некоторый таймаут Гугл поймёт, что переборщил с размером пакетов и уменьшит его. Но тайамаут — это тормоза.

Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
Встречный вопрос: а как тогда решается данная проблема QUIC'ом? Ведь явно на тех же таймаутах. Потому что больше надежных путем нету. Потому все еще в упор не вижу преимуществ QUIC'а над тюнингом TCP.

C>Сразу начинают придумываться идеи типа: "А что если одновременно послать один большой пакет, пока мы в фоне посылаем маленькие?". Но от этого middlebox'ам плохеет так, что они вообще соединение разрывают.

О да, а от QUIC'а мидлбоксы будут расслабленно плевать в потолок
Как много веселых ребят, и все делают велосипед...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.