TCP kapcsolat újralétrehozása adott adatmennyiség után

Linux-haladó

Üdv!

Adódott egy olyan helyzet, hogy adott mennyiségű adat után meg kéne szakítani bármely TCP kapcsolatot, majd újra létrehozni azt. Kis mennyiségenként kellene ezt megtenni (3-4KB-onként), és mindezt úgy, hogy kernel szinten, tehát az alkalmazásoknak ez úgy tűnjön, mintha létrejönne újra a kapcsolat.

1. Lehetséges-e egyáltalán ilyen a TCP Protokollal?
2. Ha nem lehetséges, akkor van-e rá mód, hogy csinálok valamilyen proxy-t, ami így működik és az használható is lesz. (Tehát folyamatos látszata lesz a dolognak).

Azért van erre szükség, mert van egy QoS szabály, ami az első x KB-ig normális sebességen tolja az adatot minden új kapcsolatnál, majd utána lelassítja azt. Ha az elméletem jó, akkor ezzel a QoS szabály mindig normál sebességen továbbítja az adatot, a kérdés már csak az, hogy az alkalmazások mennyire tolerálják azt (bármilyen internetet használó alkalmazásról beszélünk is).

A válaszokat előre is köszönöm.

  • 2625 megtekintés

( szgabor | 2012. 12. 03., h – 15:08 )

Burst sebességgel szeretnél tölteni? :) ejnyebejnye!!

Próbáld meg azt hogy figyeled mennyi adat megy ki, és amikor eléred a határt, küldj ki még egy SYN-t, azonos sequence-el, 2-es ttl-el. Ha szerencséd van, akkor ez átveri a QoS-t, viszont a kis ttl miatt nem megy el a cél szerverig, így nem fog hammeringet észlelni a másik oldal.

Lehet tudni valami bővebbet arról, hogy melyik szolgáltató milyen hozzáférési technológián alkalmaz ilyen session alapú, bármilyen forgalomtípust korlátozó QoS-t? Mert a böngészést (HTTP, TCP/80) a szolgáltatók általában nem szokták ilyen drasztikus megoldásokkal büntetni.

Lehet persze, 500MB-os mobilnet adatforgalom túllépése után 32kbit/32kbit-re korlátozzák a sávszélességet (kék virágnál) de szoftveresen, aminek hála nem folyamatosan jön ennyi, hanem szakaszosan, illetve minden kapcsolat felépítés után 40-64kbyte átmegy, aztán áll be erre a 3-4kb/s-re.

A speedtest.[kékvirágosneve].hu címről bármilyen adat korlátozás nélkül jön be, ugyanígy a speedtest.net is (még forgalom túllépés esetén is).

( stra | 2012. 12. 03., h – 15:17 )

"Kis mennyiségenként kellene ezt megtenni (3-4KB-onként)"
Ez annyit tesz, hogy PMTU nagyságban max. 3 csomagnyi adat megy át. Ehhez hozzájönnek a TCP felépítéséhez, és a lebontásához szükséges üzenetváltások, ez pedig ugye időbe kerül. Kicsit nagy lesz az overhead mind forgalomban, mind időben, ráadásul a TCP alapesetben pont a kezdésnél a leglassabb, lásd a klasszikus slow start mechanizmust. A kezdeti windowméret, és a (hálózati hibaként jelentkező) minimális adatforgalom utáni lebontás gyakorlati oldaláról nem ejtettünk szót.

Ráadásul a protokoll ismerete nélkül csak tippelni lehet arra, hogy a borzalmasnál mennyivel rosszabb eredményt érnél el ezzel. Vegyük az FTP-t példának. A control csatorna forgalma még nem lépte át a határt, viszont az adatcsatornáé igen. Lebontod. A kliensed meg jó sokáig belefeledkezik ebbe az állapotába. Ettől minden lesz az átvitel, csak nem gyors.

"az alkalmazásoknak ez úgy tűnjön, mintha létrejönne újra a kapcsolat."
Itt nem azt írtad, hogy "fennmaradna", hanem hogy "létrejönne újra". Bármikor megteheti az adott program, hogy a hálózati kapcsolatának elvesztésekor újra felépíti. Ezt a programnak támogatnia kell. De a fentiek miatt ennek sok értelmét nem látom.

A másik oldalról pedig nem hiszem hogy díjaznák, hogy egy nem túl nagy, példaként 100 MiB állomány letöltését is 25600 körüli új TCP kapcsolat felépítésével próbálnád megoldani.

Tényleg az lenne a legjobb, hogy a QoS-t adó szervezettől megérdeklődöd, hogy mik lennének a lehetőségek.

Nem hiszem, hogy nagyon lenne rá kompromisszum, hiszen ez egy tömegszolgáltatás, de amennyire lekorlátozzák, használhatatlanná válik. Amúgy ezt az újrakapcsolódást saját szerverre gondoltam, ott pedig maximum engem zavarhatna a sok TCP kapcsolat, de az én szerverem ezt egy kapcsolatként oldaná meg, és kis adagokban adná át. Első sorban a HTTP feljavítása már előrelépés lenne.

( athila v | 2012. 12. 03., h – 20:52 )

Mi ez a cigánykodás? Fizess egy nagyobb csomagért bakker.

( zwei | 2012. 12. 03., h – 21:17 )

nincs értelme.
A QoS nem session-re szól, hanem a forrás IP-re. Vagyis az adott IP T időintervalumon belül N mennyiségű adatot/csomagot forgalmazhat.

Ergo tökmindegy mit bűvészkedsz vele, nem lesz gyorsabb.

"normális sebességgel böngészni"
" az első 40-60KByte azonnal letöltődik"
Ha ez tényleg így van, akkor megpróbálhatod letiltani a böngészőben a HTTP keepalive-ot, úgy minden objektum külön TCP sessionben fog letöltődni. Bár mostanában a weboldalak objektumai nagyobbak ennél.

"Tehát van burst."
Zwei mellett én is furcsának találom ezt a flow alapú megoldást. Próbálj meg egy nagyobb méretű objektum folyamatos letöltése mellett - miután már beállt a 32 kbps körüli értékre - új letöltéseket indítani. Mert ha jól értem azt mondod, hogy ha történetesen elindítasz párhuzamosan n darab letöltést, akkor azok letöltési sebességeinek összege idővel beáll 32 kbps-re, de az n+1. session kezdetben a 40-64 kB forgalom eléréséig jóval nagyobb sávszélességet hoz, és ez bármilyen (nem negatív egész) n esetén igaz.

( hrgy84 | 2012. 12. 03., h – 22:25 )

Elolvasva a topicot, azert nezd at az ASZF-et, hogy belefer-e amit csinalsz. Az ilyen trukkozesek szoktak a vegen sokkal tobbe kerulni, mint egy _tenyleg_ korlatlan csomag.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( dap | 2012. 12. 03., h – 23:28 )

Erre praktikusan IP tunnel kéne, ez a TCP trükközés amiről írtál nem igazán életszerű.

Ha a QoS IP flow alapú, akkor IP over UDP tunnellel meg tudod oldani, hogy minden csomag egy másik flow-nak tűnjön (NAT-tal randomizálod a forrás IP címet és/vagy forrás és/vagy cél portot majd egy inverz NAT-tal a túlvégen újra egyesíted). Mondjuk ennek is megvan a hátulütője: könnyen felborulhat a csomagok sorrendje, ami megint lerontja az átvitelt. No meg kell hogy legyen egy szervered a QoS határon túl.

Én mondjuk szintén kételkedek abban, hogy kapcsolat alapú az osztályozás, nem pedig IP cím alapú. Előbbinek nem sok értelme lenne.