O>>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
M>Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Это само собой. Кстати тут можно дополнить, что скорее всего скорость клиент->сервер большого значения не имеет, и гораздо важней сервер->клиент. Тогда можно сделать так: если клиент не умеет в TCP_MAXSEG то для клиент->сервер ставим MTU=1380, которое fits for all. А на сервере делаем кастомный TCP стек, который на таймаутах подбирает оптимальный MTU для server->client. Гугл же может пропатчить KDE под FreeBSD TCP стек на своих серверах?
А если скорость клиент->сервер все же важна, и браузер под линуксом окажется быстрее чем под виндой, то микрософт быренько реализует TCP_MAXSEG в winsock'е.
Но миром правит hype-driven-development. На тюнингованном протоколе хайпа не вырастишь, то ли дело навелосипедить новый.

O>>Это однократный таймаут, потом все пакеты такому клиенту надо слать с определенным MTU, периодически в фоне проверяя нельзя ли его подрастить. Причем оптимальный MTU должен запоминать не только гугл, но и сам клиент.
M>Причем, MTU клиент->сервер может отличаться от MTU сервер->клиент.
Это само собой. Кстати тут можно дополнить, что скорее всего скорость клиент->сервер большого значения не имеет, и гораздо важней сервер->клиент. Тогда можно сделать так: если клиент не умеет в TCP_MAXSEG то для клиент->сервер ставим MTU=1380, которое fits for all. А на сервере юзаем TCP_MAXSEG или ваще делаем кастомный TCP стек, который на таймаутах подбирает оптимальный MTU для server->client. Гугл же может пропатчить KDE под FreeBSD TCP стек на своих серверах?
А если скорость клиент->сервер все же важна, и браузер под линуксом окажется быстрее чем под виндой, то микрософт быренько реализует TCP_MAXSEG в winsock'е.
Но миром правит hype-driven-development. На тюнингованном протоколе хайпа не вырастишь, то ли дело навелосипедить новый.