Dotaz: Uzavírání TCP spojení podle odezvy (latency)

[Jiří J.]

Zdravím,
mám další z těch nezvyklých dotazů - lze nějakým patchem aplikovaným na netfilter nebo nějakou jinou metodou docílit "automatického" zpracovávání packetů toho spojení? (tj. uzavřít jej, třeba přes TCP RST)
Napadají mě dvě možnosti, jak to udělat:

1) Jelikož jde o TCP spojení, navazují se klasickým 3-way-handshake, tj. klient pošle serveru packet s příznakem SYN (TCP flags 0x02), server odpoví packetem s příznaky SYN a ACK (TCP flags 0x12) a pak klient vrátí ACK (TCP flags 0x10) - napadlo mě měřit odezvu mezi prvním a posledním packetem v tomto handshake. Jak reálné to je? Existuje na to vůbec nějaká utilitka/patch?

2) Prográmek spouštěný cronem, který by "odněkud" (možná ze speciálního TCP wrapperu) tahal informace o latencích otevřených spojení a podle toho jednal.

Na co to potřebuji? "Čistě ze zvědavosti." - kamarád mi připomněl vysokou latenci u starých online her, kdy se na server napojil člověk s astronomickým "pingem" - zajímalo by mne, zda se toto dá ošetřit na úrovni systému. Možná z toho vzejde projekt nakonec.


PS: Hledal jsem pěknou chvíli, nacházejíc vesměs traceroutovací grafické utilitky pro MS Windows a netem, ne však to, co jsem hledal..

Odpovědi

[Jiří J.]

Teď mě napadlo možná o dost snazší řešení (proč jsem nebyl trknut dříve?) - nastavit nízký timeout - kdysi jsem někde četl o nastavení timeoutů jednotlivých TCP stavů (snad někde v /proc) - můžete prosím nasměrovat?

[Jiří J.]

Zvláštní je, jak se sám doplňuji
Kdyby mě to řešení s timeoutem napadlo dříve, mohl to být maximálně tak zápisek do blogu, ale snad i tady někomu pomůže. Budu to pravděpodobně řešit přes ip_ct_tcp_timeout_syn_recv, jakmile zjistím, jak to aktivovat v jádře:

The ip_ct_tcp_timeout_syn_recv variable sets the timeout value for the SYN-RECEIVED (also known as SYN-RCVD or SYN-RECV) state as defined in RFC 793. The SYN-RECEIVED state is entered from the LISTEN or SYN-SENT state once the server receives a SYN packet and then replies with a SYN/ACK packet. The SYN-RECEIVED state is left for the ESTABLISHED state once the server receives the final ACK packet in the 3-way handshake.

[Jiří J.]

Tak jsem hledal snad ve všech jazycích, dozvěděl jsem se, že ip_ct_tcp_timeout_syn_recv je z tcp-window-tracking - součástí patch-o-matic, jenomže pro jádro 2.4.x.
Dále jsem hledal port na 2.6.x, nalezl jsem pro verze 2.6.9 a 2.6.11, pak se zprávy o tomto patchi neobjevují. Hledal jsem i v patch-o-matic-ng na netfilter.org, po prohledání zdrojáků nejnovějšího snapshotu ani zmínka o tcp-window* nebo ip_ct či IP_CT ...
Máte nějaké novější zprávy? V configu svého 2.6.22-ARCH to nemohu najít, předpokládám, že to v jádře asi nebude..

[Jiří J.]

Možná ze zoufalosti jsem si tak projížděl find /proc/ ručně a padlo mi do oka to, co jsem zmiňoval již dříve:

-.. kdysi jsem někde četl o nastavení timeoutů jednotlivých TCP stavů (snad někde v /proc) ...

Celou dobu jsem to měl doslova pod nosem - v /proc/sys/net/ipv4/netfilter/ při modprobnutém nf_conntrack_ipv4:

ip_conntrack_buckets          ip_conntrack_tcp_be_liberal           ip_conntrack_tcp_timeout_last_ack
ip_conntrack_checksum         ip_conntrack_tcp_loose                ip_conntrack_tcp_timeout_max_retrans
ip_conntrack_count            ip_conntrack_tcp_max_retrans          ip_conntrack_tcp_timeout_syn_recv
ip_conntrack_generic_timeout  ip_conntrack_tcp_timeout_close        ip_conntrack_tcp_timeout_syn_sent
ip_conntrack_icmp_timeout     ip_conntrack_tcp_timeout_close_wait   ip_conntrack_tcp_timeout_time_wait
ip_conntrack_log_invalid      ip_conntrack_tcp_timeout_established  ip_conntrack_udp_timeout
ip_conntrack_max              ip_conntrack_tcp_timeout_fin_wait     ip_conntrack_udp_timeout_stream

Takže snad je to konečně dořešeno.
"Proč to správné řešení musí být až to poslední..."

[Zdenek]

A nebude problem v tom, ze online hry spis pouzivaji UDP?

[Milan "Nemo" Cingroš]

A u UDP se spojení dost těžko zavírá Na úrovni UDP žádné není, tak jedině zjistit jakým paketem se hra "loučí" se serverem a tento paket hře "podstrčit" se zdrojovou adresou klienta. Případně zjistit jestli existuje i paket kterým server klienta "vykopává" ze hry...

[Jiří J.]

Quake 1,2,3 možná ano (na ty existuje zase přímo patch netfilteru), ale některé i přes TCP.. taky mě zaráží /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout..

[Filip Jirsák]

taky mě zaráží /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout..

To je podle mne kvůli NATu a sledování spojení. Netfilter musí vědět, co s UDP pakety, které přicházejí např. od herního serveru k hráči – musí vědět, jak je přeNATovat na vnitřní IP a kam je poslat. Na to má nějakou tabulku sledovaných spojení, a tohle je timeout, po jaké době od posledního paketu se záznam z tabulky vymaže.

[Zdenek]

Malo her u kterych zalezi na latenci bude pres TCP, ale rad si necham nejakou ukazat

[Jiří J.]

Nemluvil jsem jen o akčních hrách, na TCP jede hodně strategických a MMORPG her. V praxi při otevřeném spojení si pak klient a server posílají data přes TCP packety s flagy PSH ACK a ACK (0x18 a 0x10).