iPon Hírek

Google: TCP optimalizációval gyorsulhat az internet

Dátum | 2012. 01. 26.
Szerző | J.o.k.e.r
Csoport | HÁLÓZAT

A Google szakemberei az Internet sebességének növelésén dolgoznak, ám ehhez most nem a fizikai hálózat sávszélességét növelik, hanem a TCP-t (Transmission Control Protocol) próbálják optimalizálni annak érdekében, hogy a protokoll a lehető legjobb hatásfok mellett üzemelhessen.

Az említett optimalizációnak köszönhetően minden hálózaton növekedni fog a sebesség, amely az új, továbbfejlesztett TCP protokollt használja, de ezzel együtt a fizikai hálózat skálázhatósága is javul, hála a TCP hatékonyabb működésének. Az új TCP kompatibilis marad a régivel: az optimalizált, jobb hatásfokkal működő új protokoll csak akkor lép működésbe, ha mind a kliens oldal, mind pedig a szerver oldal támogatja azt.

Hogy mégis milyen optimalizációkkal lehet jobb TCP hatásfokot elérni? Erre az alábbi felsorolás adja meg a választ.
 


A fentiek mellett a kutató-fejlesztő csoport ezzel együtt a zajos mobil környezetben tapasztalható csomagvesztés mértékének csökkentésével is foglalkozik: az új algoritmusnak köszönhetően gyorsabban történik majd a csomag-helyreállítás, ami szintén jótékonyan hat majd a sebességre.

A témával kapcsolatban minden részletre kiterjedő információt itt találnak az érdeklődők.

Új hozzászólás írásához előbb jelentkezz be!

Eddigi hozzászólások

14. felziusz
2012.01.26. 18:11
[i]Ez az újítás már a Linux kernel részét képezi és hamarosan a TCP szabványba is bekerülhet.[/i]

Az USB 3.0 drivere már akkor benne volt amikor olyan eszköz nem volt a piacon (tán még a tervezőasztalon sem) Specifikációk megvoltak és már került bele a driver.
 
Válasz írásához előbb jelentkezz be!
13. Vendég-Ven...
2012.01.26. 19:20
Már önmagában az meglepő, hogy ilyenb sokáig, évtizedekig húzta komolyabb változtatások nélkül.
 
Válasz írásához előbb jelentkezz be!
12. Szerzetes
2012.01.26. 20:27
Annyira nem meglepő. Mindenki csak hozzárakott, tákolta, aztán nem merik megpiszkálni, mert félő h összedől az egész.
 
Válasz írásához előbb jelentkezz be!
11. gargantu
2012.01.26. 21:20
"Már önmagában az meglepő, hogy ilyenb sokáig, évtizedekig húzta komolyabb változtatások nélkül."

Annyira azért nem meglepő: nem Redmondban tervezték (fő cél: profit), hanem katonák számára (fő céltabilitás).
 
Válasz írásához előbb jelentkezz be!
10. gargantu
2012.01.26. 21:21
azt írtam, hogy stabilitás
 
Válasz írásához előbb jelentkezz be!
9. Ciscoboy89
2012.01.26. 21:22
hát én ebben a témában pesszimista vagyok mivel a TCP és az egész TCP/IP család komoly követelményeknek felelt meg anno, nem kezdem el sorolni de szerintem ezt mindenki tudja,de én szerintem ha meg is lesz oldva ez a dolog akkor is kevés lesz az a hálózatrész ami ezt az új TCP követelményeket el fogja tudni viselni, mert pl ha veszünk egy végpont-tol végpontig futó kapcsolatot amin csak nagysebességü köttetések vannak az talán el fogja tudni viselni ezeket a követelményeket, de mi van pl a csomagveszteségesebb hálózatokkal??? mi lesz a gyengébb összeköttetésű wlanokkal és a nagyobb válaszidejű hálózatokkal? szerintem ez az elv el fog bukni.... ...de mint olvastuk, írják hogy mobiltechnológiás csomagveszteséges környezet fejlesztését is...... kíváncsi leszek rá hát sok sikert.
 
Válasz írásához előbb jelentkezz be!
8. Ciscoboy89
2012.01.26. 21:29
....igen tudom a TCP/IP-nek semmi köze ehhez, csak a TCP -röl mint szállítási rétegbeli protokollrol van szo!!!
 
Válasz írásához előbb jelentkezz be!
7. Ciscoboy89
2012.01.26. 21:38
esetleg egy komolyabb protokolladat tömörítés szerintem jobban kivitelezhető lenne mivel a mai gépeknek ez nem lenne akadály (esetleg talán a kisebb hálózati eszközöknek valamennyikével nagyobb terhelést jelentene, de meglehetne találni az arany középutat hogy ne növekedjen a késleltetés számottevően nagyot
 
Válasz írásához előbb jelentkezz be!
6. sanyix
2012.01.26. 21:56
így is tömörítve megy a legtöbb adat, nem a protokoll által, hanem a programok által.
 
Válasz írásához előbb jelentkezz be!
5. Ciscoboy89
2012.01.26. 22:01
de én a protokoll tömörítés-röl beszélek mert a zlib és társai elégé gyengék szerintem de igen vannak 7rétegbeli tömörítések azok elégé "sajátosak" globális módban gondolkodtam és közvetlen 4dik rétegben ha ez egyáltalán megvalósítható
 
Válasz írásához előbb jelentkezz be!
4. sanyix
2012.01.26. 22:43
De nem érted? eleve tömörített tartalmat már sehogysem fogsz tovább a protokollal tömöríteni, csak pazarolni rá az erőforrást.
png meg jpg, gif képeket nem fogsz sehogy sem tovább tömöríteni márpedig ezek adják a weboldalak letöltésének nagy részét. Más programok is maguk tömörítenek. A multis játékok is, steam is tömörít, minden.
 
Válasz írásához előbb jelentkezz be!
3. Ciscoboy89
2012.01.26. 22:51
amiről te beszélsz az 7. rétegbeli alkalmazás tömörítés én 4. rétegbeliröl beszéltem és globális tömörítésről vagyis mindegy hogy az milyen alkalmazáshoz menne ugyanazt a tömöritést alkalmazná vagyis független a felsőbb rétegektől, és valami komolyabb sűrűségről beszélek (de a kisebb pc-k ezt nem bírnák vagy terheltek lennének)
 
Válasz írásához előbb jelentkezz be!
2. fbi1984
2012.01.28. 17:51
Amikor a TCP[UDP]/IP-t megalkották a katonák számára az volt a szempont,
hogy még a drótkerítésen elvezetve is működjön (TTL, csomag ismétlés, stb.)
Ma már a fizikai réteg és az eszközök is megbízhatóak (most a kábellopásoktól tekintsünk el), nagyobb biztonsággal küldhetők át csomagok hibamentesen.
Tehát nem kell rossz adatátviteli környezetre berendezkedni.
Az említett módosítások csekélyek a protokoll szempontjából, inkább nevezném finomhangolásnak, mint egy új verziónak (sok paraméter ma is állítható).

Ami igazán nagy javulást hozna az az adatcsomag méretének növelése MTU.
Még mindig nagyon kis csomagokat (1500 bytes) küldünk nagy overhaeddel.
Ez olyan, mintha egy teherautónyi homokot talicska helyett kiskanállal hordanánk odébb, mert ha kiszóródik, akkor csak egy kiskanálnyi veszik.
 
Válasz írásához előbb jelentkezz be!
1. fbi1984
2012.01.28. 18:03
Ciscoboy89:
Az adatcsomag a 7. (alkalmazás) rétegben tömörítődik.
A 4. (transport) rétegben mit tömörítenél a csomag headert?
Akkor minden routernek előbb ki kellene tömörítenie minden csomagot, hogy hozzájusson a cél címhez/hálózati maszkoz.
A routereknek nagyon gyorsnak kell lenniük útválasztás során, amit ez akadályozna.
Amit nyernél a kisebb/tömörebb csomaggal, azt többszörösen elvesztenéd a lassabb, bonyolultabb routerrel.

Nem hiába az SSL is csak a shared key átküldésénél használ 2 kulcsos titkosítást, mert az is lassú. Ezután az adatok már "csak" szinkron titkosítással mennek (sokkal gyorsabban).
 
Válasz írásához előbb jelentkezz be!