M>>Будет ли TCP fast open работать при смене IP клиента? Насколько я знаю, нет.
O>Смена ип клиента сама по себе не быстрая операция, странно экономить на спичках спалив тонну дров.

Итого, TCP Fast Open в большинстве случаев (смена IP мобильным клиентом) вообще не работает. А кроме того, оказывается, это экономия на спичках (и в реальности на большинстве клиентов вообще выключен). Так нафига про него вспоминают при каждом сравнении HTTP/3 и TCP+TLS 1.3?

Смена IP клиента происходит при переходе с WiFi на GSM (когда ты вышел из метро или офиса) и от нее никак не избавиться. Происходит один раз при смене подключения (и, скорее всего, в большинстве случаев в фоне), после этого каждое соединение, которое у тебя было в метро или офисе устанавливается заново (часто интерактивно). В GSM RTT нифига не спички (раза в 2 выше latency по сравнению даже с тормозным WiFi) — минимум пару сотен миллисекунд ожидания к каждому соединению (которое совсем не новое, просто было сделано с другого IP).

В общем, мой посыл, что HTTP/3 (QUIC) сильно лучше для мобильных клиентов, чем TCP Fast Open + TLS 1.3. Там реализована миграция клиента, полноценное мультиплексирование каналов в соединении, больше возможностей управления трафиком (повторная передача, управление насыщением канала), шифрование всего, чтобы провайдеры не лезли в трафик.

M>Итого, TCP Fast Open в большинстве случаев (смена IP мобильным клиентом) вообще не работает. А кроме того, оказывается, это экономия на спичках (и в реальности на большинстве клиентов вообще выключен). Так нафига про него вспоминают при каждом сравнении HTTP/3 и TCP+TLS 1.3?
M>Смена IP клиента происходит при переходе с WiFi на GSM (когда ты вышел из метро или офиса)
4 раза в день сайт откроется чуть медленней чем обычно. Проблема высосана из пальца.

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

S>Только зачем все это нужно, проблему какую решают?

Что бы клиент мог подряд отправить несколько команд, и потом получив несколько ответов сопоставить запрос-ответ

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

Pzz>Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком.
Это ты про железки уровня домашнего WiFi?

Pzz>Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Это только если необходимо собирать сессию и делать DPI, но и это уже давно решенные задачи для скоростей 10+Gb, уровни вложеннсти протоколов могут быть очень сложными (условно MPLS->IP->TCP->IP->UDP), TCP/UDP на одном уровне никакой погоды не делает. Для обычной маршрутизации ничего этого не надо. Там зачастую и IP нет (MPLS).

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

Pzz>Роутинговые решения довольно дорогие, и их надо кешировать. Для TCP это сделано в контексте TCP-соединения.
"-1" В общем случае TCP на решение о маршруте не влияет никак.

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

O>4 раза в день сайт откроется чуть медленней чем обычно. Проблема высосана из пальца.

Ну на самом деле, UDP сильно лучше в плане медиастриминга. Только надо бы, чтобы оно еще и понимало, что передает (задержался пакет из кина дольше разумного времени — можно смело дропать его, и все остальное до ближайшего I-frame. Но при этом надо понимать, где какие пакеты в потоке). И я что-то сомневаюсь, что на данном этапе это сделано.