Re[4]: TCP все...
От: Pzz Россия https://github.com/alexpevzner
Дата: 14.11.18 11:58
Оценка:
Здравствуйте, 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 потока. Оборудование подозреваю уже отработает такой пакет как положено.


Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.