Здравствуйте, ononim, Вы писали:

C>>Проблема в том, что существующий TCP ломается у заметного количества клиентов, если не делать таких уродских хаков.
O>Учитывая вводные (свой код клиента и сервера)
Откуда такая вводная? Клиент может быть совершенно любой.

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

O>задача определения и настройки PMTU должна тривиально решаться при помощи setsockopt(...TCP_MAXSEG...) где оно поддерживается (лялих) и чуть менее тривиально при помощи setsockopt(...TCP_NODELAY..) и ручной буферизации исходящих данных где set(TCP_MAXSEG) не работает (винда).
Вот Вася сидит в региональном отделении православного банка Рогатус&Копытус. Его локальный MTU — это 1500 байт (Ethernet), но его филиал подключён к Интернету через VPN и PPPoE, которые отъедают примерно 90 байт пакетов.

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

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

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

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

C>>Если есть идеи как это исправить в рамках существующего TCP — добро пожаловать в Гугл на семизначную зарплату.
O>Боюсь гномиков разверну не под тем углом.
Они там уже не спрашивают их.