 |
 |
Perhaps why IE on a PC seems fast
|
|
|
|
|
Professional Poster
Join Date: Oct 2001
Location: London
Status:
Offline
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Senior User
Join Date: Dec 2001
Status:
Offline
|
|
d00p!
Maybe the reason you didn't see that thread is because your OS X browsing experience is so slow?
|
|
"Think Different. Like The Rest Of Us."
iBook G4/1.2GHz | 1.25GB | 60GB | Mac OS X 10.4.2
Athlon XP 2500+/1.83GHz | 1GB PC3200 | 120GB | Windows XP
|
| |
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Dec 2002
Status:
Offline
|
|
Maybe that's a bunk theory, and if you read the slashdottery about it, you'll notice that it's based on 2 or 3 year old data (IE 3??) and that it's basically adhering to the idea of HTTP Pipelining and HTTP Stay-Alive. Which is something that nearly all browsers use now-a-days. Thanks for the Troll...
|
|
www.JustinAugust.com
i'm a magic dream haver
i'm abracadaver
|
| |
|
|
|
|
|
|
|
Professional Poster
Join Date: Mar 2000
Location: New York, NY, USA
Status:
Offline
|
|
From the other thread on the same topic:
This has nothing to do with Keep-Alive. This is a blatant disregard of the TCP/IP protocol at the cost of security.
Keep-Alive establishes a normal connection to the web server and keeps it open for subsequent requests (such as images, stylesheets, etc.).
WinIE bypasses the normal TCP/IP connection procedure, which is to send a SYN (synchronization) packet, then wait for a SYN response and ACK (acknowledgment) packet. This is how all TCP/IP connections are established. What WinIE does is to immediately send out a HTTP request, without establishing a valid connection of any kind, and wait for either a) a response, b) an error message, or c) a connection timeout. If it doesn't get a response, or times out, it tries again the "legal" way.
Of course, all Microsoft server products respond perfectly to to this "illegal" form of HTTP request. All other operating systems drop the packet and either send an error message, or better yet, simply act like nothing happened. Either way, the packet never makes it to userspace. If an error is sent, the connection still seems relatively quick, otherwise, pageloads slow to a crawl waiting for timeouts.
Basically what a SYN packet does is create a short-term agreement between two hosts on a "magic number" that will be attached to every subsequent packet that is considered part of that connection. The main problem here is that without the SYN and ACK packets (required by the TCP/IP specs), it is trivially easy to spoof the network address of any packet. This is why any good TCP/IP stack will completely ignore any packets which have not been SYN'd and ACK'd.
Since Microsoft's TCP/IP stack obviously passes these (and other) malformed packets on to whatever application is listening for them, it should become quite clear how Microsoft has sacrificed security for perceived performance.
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
 
|
|
|
Forum Rules
|
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|
|
Top
