Spojení TCP na příkladu SSH:
1) A:X -> B:22: Prosím o spojení na A:X
2) B:Y -> A:X: Nabízím komunikaci na portu Y
3) A:X -> B:Y: Ok, můžeme komunikovat
A v téhle chvíli máme obousměrný tunel A:X <> B:Y se zaručeným pořadím dat a zaručeným doručením, pokud není přerušená linka.
Tohle myslíte naprosto vážně? Tedy ona je to v zásadě je to pravda, ale nerozumím tomu, proč tam zavádíte nějaké Y, když je stejně vždy 22.
A teď si představme, že se někdo rozhodne po UDP přenášet balíčky souborů na jednu UDP žádost:
AC:X->B:443: Pošli stránku ..., do potvrzení smí odejít 10MB
B:Y->C:X: Stream až 10MB
Jak konkrétně to hodláte v případě QUICu provést? Pokud ten falešný request chcete poslat jako nový request, pořád budete muset být schopen nejdřív odpovědět na paket od serveru (poslaný na C), stejně jako u TCP. Pokud se pokoušíte navázat na dřívější komunikaci mezi C a B, musel byste přesvědčit B, že jste C (ve smyslu jejich předchozího spojení), což bude ještě těžší.