Platí hodnota MSS pro oba směry?
Pokud se sestavuje TCP spojení, pak platí signalizovaná hodnota MSS pro daný směr, kdo ji vyslal a nebo spojení jako celek má jen jednu hodnotu MSS?
IP source:54001> server:80: Flags [S], seq 1097913221, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
IP server:80> source:54001: Flags [S.], seq 956563554, ack 1097913222, win 29200, options [mss 1320,nop,nop,sackOK,nop,wscale 9], length 0
Bude mít TCP spojení hodnotu 1440 směrem od serveru a 1320 k serveru , nebo jednu hodnotu pro oba směry (tu nižší)?
to záleží na tom jak se protokol domluví....klidně můůže i plavat...
Co je to za nesmysl? Pokud plavbou myslíš to, že jde změnit uprostřed TCP spojení , tak to nedává smysl, protože tak to není dynamický parametr, ale základní parametr platící od počátku spojení.
A mě právě zajímá, jak ten prokol se domlouví, jestli když na začátku spojení A pošle v options MSS XYZ a a B pošle MSS ABC, jestli se tím myslí že pro oba směry platí jedna hodnota(patrně nižší z obou) a nebo platí pro každý směr ta kterou přijaly od protistrany.
Nebo chceš říct, že existuje TCP option, která mění význam optionu MSS na to platící pro celé spojení a na to pro každou stranu zvlášť?
No a co když ti během spojení spadne nějaký spoj mezi hostiteli a routery to odroutují jinudy, kde je velikost paketu omezena (edit: např. nějakým nouzovým VPN tunelem)?
MSS signalizuje vždy router odesílající straně, takže vskutku může být rozdílná v obou směrech. V dnešní době přefirewallovaného internetu však není jistota, že ICMP MSS paket skutečně dorazí k cíli, a tudíž je třeba aby spolehlivě fungoval clamping a fragmentace.
Jsk se to clampne přes iptables? Já konkrétně musím použít clamp narouteru, který forwarduje z vpn : cíl netuší o existenci tunelu
A je schopen clamping (iptables -I forward -j MSS --clamp-to-pmtu...) ale ďábel je v detailu: k pravidlu patří --tcp-flags SYN,RST SYN
Nicméně ten zužujíci selektor --tcp-flags vyřazuje použití uprostřed spojení
A nebo prostě se spojení ukončí.... Co myslíte?
clamping se používá tam, kde je třeba. Takže když máš WAN link spolehlivě fungující s 1500B MTU, není třeba to řešit. To si pořeší router kus dál, kde to potřeba bude.
Jo , významu MSS rozumím, dá se logicky odvodit pro jaký směr patří a čí hodnotu signalizuje...
Když odesílám paket, tak tím dávám informaci o svém konci, nemohu zčista jasna vědět MSS protistrany. To by byla strana.
A zároveň MSS říká, Takovouhle maximální hodnotu jsem schopen přijmout. To by byl směr. Protože jaksi odeslání se předpokládá že svá strana si pohlídá.
https://siete.ics.upjs.sk/prednaska-5/
Celý text jsem přečetl a nenašel explicitní zmínku, jestli MSS je jeden parametr pro celé spojení (tedy pro oba směry) a nebo každá stran má svoju MSS. I když z toho vyznívá, že asi platí jedno MSS pro oba směry, ale chtěl jsem se ujistit a dostat odpověď.
Neřeším Congestion a flow control.
Vidíš a já tam čtu:
Předpokládal jsem, že to z toho je jasné... Platí to pro oba směry. Nemělo by smysl, aby jedna strana při vysílání měla omezenou velikost packetu a při příjmu by jí to nevadilo.
Zdroj:
https://datatracker.ietf.org/doc/html/rfc879#section-3
Pak jsem nemel pravdu a omlouvam se.
No a na tom, jestli MSS platí oboustraně
je postavena má otázka:
A je nutné dělat i clamping i v příchozím směru? Tím myslím z venku přijde do tunelu paket, tunel na druhém konci ho před forwardnutím . Be toho si myslí, že v případě vracení odpovědi od serveru:80 k source server klidně může odesílat pakety přes routeru, které budou nad MTU tunelu a bude je muse gragmentovat ...
K tomu podotázky:
-dojdou fragmentované odpovědi až k source nebo je druhý konec tunelu reassembluje?
-nebo příchozí clamping není potřeba a router upozorní server přes ICMP too long a on sníží MSS+MTU?
Když si to pročítám, tak pozor, to mé vyjadřování může být nepřesné, ale příchozí clamping má vliv na odchozí pakety.... Snad jsem vám nezamotal hlavu.
Nyní se děje odchozí clamping - při odpovědi na příchozí spojení router opraví MSS z těch 1440 na 1320) před vysláním do tunelu. Tím opravím informaci, kterou odesílám protistraně, aby mi neposílala velké pakety.
(Pokud se podíváte na úryvek v úvodním příspěvku, tak příchozí směr je směrem od source na server:80) (pakety jsou zachyceny na rozhraní vpn. Kdyby byly zachycena na rozhraní eth0 vedoucí k serveru, tak druhý paket by měl MSS ještě před odchozím clampingem, tedy 1460)