Mitől látszik gyorsnak az Internet Exploler?

Internet, Közösségi média

Egy érdekes feljegyzést postáztak a Slashdotra, amelyben valaki azt állítja, hogy azért látszik gyorsabban működni az Internet Exploler, mert csal, azaz nem az RFC-kben leírt módon építi fel a kapcsolatot a böngésző kliens és a http szerver között. A cikk írója szerint az Internet Exploler működése érdekes, mert néha lehetetlenül gyors, szinte már akkor elénk teszi a kért oldalt, amikor még alig kattintottunk az egérrel, néha pedig olyan lassú, mint a tetű. Ennek okait boncolgatja ez a cikk.

A cikk szerint az IE ahelyett hogy először SYN csomagokat küldene, mint minden rendes TCP/IP alkalmazás, először elküldi a request csomagot, és ellenőrzi a választ. Ha jön válasz, akkor a távolban egy MS IIS szerver van, így megspórolta a 1. SYN -> 2.
kéréseket, ezzel időt nyerve. Ezt azért tudja megcsinálni mert az IIS szerver erre fel van készítve. Na de mi van akkor, ha egy "rendes" HTTP szerver van a másik oldalon? Olyankor várhatunk, hiszen az IE-nek meg kell ismételnie a kérést, ezúttal az RFC-ben rögzített ajánlások szerint. Tehát ha a másik oldalon nem IIS van, akkor esetenként többet kell várnunk, mintha mindjárt 'rendes' kérést küldött volna. Viszont több nem-IIS szerver van, mint IIS.... Úgyhogy amennyiben a feltevés helyes, mi csak rosszabbul járhatunk az IE-vel.

( szaszg | 2003. 01. 06., h – 11:05 )

Hmm???

Szerintetek egy Flash 'mozi' letöltéséhez képest, arányaiban mekkora időnyereség a prominens lépések kihagyása?

1. SYN ->

2.

Zsiráf

( szaszg | 2003. 01. 06., h – 12:02 )

Azt is érdemes lenne megnézni, hogy az oldal 'lejövetele' alatt az illető böngésző mennyi időt töltött a lap megjelenítésével. Lehet, hogy ott van inkább különbség???

Zsiráf

( szaszg | 2003. 01. 06., h – 12:16 )

Bocs,

de én nem azt kérdeztem, hogy ez mekkora kiesés, ha a szerver a normális protokollt várja, és az IE-nek rá kell jönni, hogy nem kap választ, hanem az a kérdés, ha a rendes protokollból ezt a három lépést kihagyod -- és egy IIS-el van szerencsére párkapcsolatod --, akkor mit nyersz, mondjuk az origó párezer kb-os nyitóoldalának letöltése során?

( szaszg | 2003. 01. 06., h – 12:19 )

De a jelen oldal nem MicroFo$ szerveren található!!! (vagy tévedtem trey ;-)

Ezek szerint nem lehet a fenti dolog a különbség oka! Sőt elvileg az IE így még hátrányban is van, hiszen rá kell jönnie, hogy nem fajtársával találkozott :-)

Zsiráf

( szaszg | 2003. 01. 06., h – 14:30 )

Gyerekek!

Én egydolgot nem értek. Gyorsan átnyálaztam a HTTP/1.1 és HTTP/1.0 RFC-ket, de ilyenről mint SYN, ACK, FIN semmit sem találtam! Amúgymeg a cikkben azt mondja, hogy ha TCP fölötti a HTTP protokol. Má bocsi? De a browsernek mi köze ahhoz, hogy mi fölött megy a HTTP protokol? Neki csak ahhoz kéne érteni, nemde??

Amúgy 'telnet www.gnu.org 80' majd 'GET [ENTER]', s má gyün is a webpage!!! Most a telnet csinyát SYN/ACK-ot, vagy nem? ;-) Merthogy én biztosan NEM!

Ha jól értem a dolgot, becses kacsóim voltak a HTTP Client Software, míg a telnet, csak közvetítette a dolgot. Szóval ha az IE valahol lejebb turkál a protokollokban, akkor az IE ollyan dolgot csinyál, ami nem az ő dolga (nem csak HTTP kliens)... Akkor pedig nem a HTTP kliensekkel kéne összehasonlítgatni...

Vagy nincs igazam?

Zsiráf

A kliens (IE) bekapcsolodott a szerverhez. A szerver mondott neki egy keep-alive-ot es ezért nem látott a csákó egy db SYN-t sem. Csak a hülye aszitte, hogy mekkora nagy hacker, hogy Ő erre rájött. A baj csak az, hogy a fél slashdot beszopta-;)

Amugy jól érted a dolgot, a SYN/ACK-ot a kernel TCP stack-je zongorézza le, nem a telnet kliens.

( uid_395 v | 2003. 01. 06., h – 14:48 )

btw akkor lehetne olyan kerdes is, hogy mitol indul el az IE szinte azonnal es a mozilla miert nem indul el szinte azonnal? :)

Udv.

-kRiX-

Making a Connection with tcpdump, Part II

Scenario 1: Established Telnet Connection

Javaslom elovasni.

"#tcpdump -nn host 192.168.2.165 and port 23

Before examining the output, let's take a detour and get a brief overview of TCP/IP connection management. This small detour will assist those individuals who are new to protocols. To guarantee a reliable connection (startup and shutdown), TCP uses a method in which three messages are exchanged. The process is called a three-way-handshake. To startup a connection:

* The requesting Host sends a synchronization flag (SYN) in a TCP segment to create a connection.

* The receiving Host 192.168.2.165 receives the SYN flag and returns an acknowledgment flag (ACK).

* The requesting Host 192.168.2.10 receives the SYN flag and returns it's own ACK flag.

A similar handshake process is used to close a connection using a finish flag (FIN)."

( trey | 2003. 01. 06., h – 14:59 )

igy igaz. ezert volt bajban a ms, amikor kotelezni akartak/koteleztek arra, hogy eltavolithatonak kell lennie az IE-nek a rendszerbol. bajban volt mert az windows exploler (gyk. intezo) annyire egybe volt epitve az internet explolerrel, hogy szinte nem lehetett kettevalasztani. szoval az intezo elindul, aminek csak egy resze az IE.

( uid_395 v | 2003. 01. 06., h – 15:02 )

Na ilyesmire gondoltam enis elsokorbe. Bar mozilla -nal badarsag lenne ezt megoldani mert imho kurva sok memoriat megenne.


Ps.: mplayer vs. radiocard support? ;) gepet nemtok hozza kuldeni se fejlesztot :)) csak radiocard-ot :P :)

De al3x-ot rakene inditani :)

Udv.

-kRiX-

Bocs, de a második lépésben a 192.168.2.165 nem egy olyan csomagot küld amin syn+ack egyszerre van bekapcsolva ??

én úgy tudtam hogy így müködik

client server

1. -> Syn

2.

3. -> Ack

Ja és a Half Open scan (nmap -sS)

a válasz vételekor leáll így nehezebb/máshogy kell detectálni.