S>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC.
Помницца когда битторрент навелосипедил uTP то был ор от провайдеров потому что их оборудование не тянуло такую нагрузку, т.к. в UDP нету сессий, соотвественно вся stateful обработка трафика основывается на таймаутах.
Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
S>>Соответственно, в будущей версии HTTP транспорт TCP заменят на QUIC. O>Помницца когда битторрент навелосипедил uTP то был ор от провайдеров потому что их оборудование не тянуло такую нагрузку, т.к. в UDP нету сессий, соотвественно вся stateful обработка трафика основывается на таймаутах.
В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний.
O>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет?
Скорее, провайдеры допилят свое оборудование.
В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей.
Pzz>В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний.
Это понятно. Но все же в большинстве случаев FIN/RST таки доходят, а значит бОльшая часть конекшенов освобождает ресурсы вовремя, в таймаут уходит не так много.
O>>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет? Pzz>В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей.
Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
Pzz>>В TCP тоже никуда не денешься от таймаутов. Последний пакет может и не прийти, на него нельзя рассчитывать. Более того, он может прийти несколько раз, и невозможно понять, какой из них самый последний. O>Это понятно. Но все же в большинстве случаев FIN/RST таки доходят, а значит бОльшая часть конекшенов освобождает ресурсы вовремя, в таймаут уходит не так много.
Вот смотри, вот нормальное завершение TCP сессии:
1) A->B: FIN
2) B->A: FIN+ACK
3) A->B: FIN+ACK
По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру. Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
O>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Здравствуйте, reversecode, Вы писали:
R>помнится там было другая проблема R>утп не контролировал полосу и отьедал ее всю
Вообще-то, µTP изначально имел congestion control, причем он был сконструирован таким образом, чтобы всегда проигрывать TCP в соревновании за полосу, чтобы не мешаться веб-траффику.
Pzz>Вот смотри, вот нормальное завершение TCP сессии: Pzz>1) A->B: FIN Pzz>2) B->A: FIN+ACK Pzz>3) A->B: FIN+ACK
Pzz>По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру.
В данной ситуации с потерей FIN+ACK в NAT'е вообще не вижу смысла чегото ждать. Ведь можно просто отвечать FIN+ACK-ом или даже RST на все FIN+ACKи, отсутствующие в данный момент в таблице трансляции.
Не говоря уж о том что stateful inspection FW может свободно забывать про конекшен уже на шаге 2.
Pzz> Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
Дело не в самом таймере, а в ресурсах связанных с конекшеном и которые заморожены на время ожидания сработки этого таймера.
O>>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено. Pzz>Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Как будто сейчас этого сделать нельзя. ICMP port unreachable это _уже_ работающий механизм. Если его послать с правильными портами — висящий recv с UDP сокета обломится с ошибкой. Или последующий sendto на этот порт обломится — деталей не помню уже, т.к. сканер UDP портов, работающий по данному принципу, писал >15 лет назад
Как много веселых ребят, и все делают велосипед...
O>>>Интересно тут что-то подобное планируется или они допилят UDP добавив в него end-of-session пакет? Pzz>>В QUIC, разумеется, есть пакет, обозначающий окончание сессии. Но он зашифрованный, как и все прочие пакеты QUIC, его от любого другого не отличишь, если не знать сессионных ключей. O>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
QUIC основан на UDP, но реализован полностью в пространстве пользователя (ядро менять не надо), поэтому, ICMP port unreachable слать не получится (если ты не root). Кроме того, в UDP нет tcp sequence и, скорее всего, такой ICMP port unreachable можно отправить сквозь маршрутизатор с перебором всех 65536-ти портов и на шлюзе все эти сессии из таблицы NAT будут удалены...
M>QUIC основан на UDP, но реализован полностью в пространстве пользователя (ядро менять не надо), поэтому
Ну и зачем вот оно такое? Сделали бы поверх UDP туннель с касторкой и гарантированной доставкой пакетов, и гоняли бы через него TCP. И UDP, а в нем еще один туннель — еще быстрее и отзывчивей. Такую систему ведь можно масштабировать фактически бесконечно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Ops, Вы писали:
C>>QUIC можно использовать вместо TCP напрямую. Ops>Для TCP не нужны никакие сертификаты в каждом утюге, в отличие от.
Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера.
Здравствуйте, Ops, Вы писали:
C>>Для QUIC тоже, можно просто сгенерировать эфемерные сертификаты при старте сервера. Ops>Объясни механизм. Как я могу доверять каким-то сгенеренным сертификатам без УЦ?
Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP. Единственное, что подслушивать можно будет только активно через MITM.
Здравствуйте, Cyberax, Вы писали:
C>Никак. В этом случае не будет никаких гарантий, как и при соединении по обычному TCP.
Тогда это профанация навязанного протоколом обязательного "шифрования" и бессмысленная нагрузка на устройства.
C>Единственное, что подслушивать можно будет только активно через MITM.
Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
