MS changes IE and IIS TCP/IP rules

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Matt Alexander
Date:  
Subject: MS changes IE and IIS TCP/IP rules
Interesting... Microsoft is using TCP/IP in a way that makes IE respond
faster to IIS and slower to non-IIS webservers:

http://grotto11.com/blog/?+1039831658

Could someone with IE and IIS please verify this? A dump of TCP/IP
traffic with different versions of IE and IIS would be ideal.

Of course covered on Slashdot:

http://slashdot.org/article.pl?sid=03/01/05/2025254

This post sums things up:

The parent +5 post is flat out wrong. This is not about persistant
connections, which is a high-level HTTP feature that keeps a connection
open so that the browser can send more requests. This is about a
low-level TCP hack that IE uses to get a small speed boost on IIS
servers, while breaking TCP standards compliance.

If I read the article correctly, instead of creating a new TCP connection
and then sending a request, IE sends the request immediately without
bothering to finish the TCP handshake. Microsoft IIS web servers deal
with it automatically, and it is faster because it saves a round-trip
wait for the ACK and the following requset.

The down side is that non-IIS servers have no clue what this incoming
packet is. It must be invalid because it is not a SYN. So it gets thrown
away, and the server might or might not reset the connection. If a
non-IIS server resets the connection, IE goes with a standard TCP
handshake and has wasted only the round trip time for the request packet
and the RST. But if the server swallows the invalid packet and does not
send a RST, then Internet Explorer will just sit around for a few seconds
until it times out and falls back to a standard TCP conection.

The summary is that IE is breaking the TCP protocol for a small speed
boost when connecting to IIS servers. It results in a small speed penalty
when connecting to most non-IIS servers. When connecting to non-IIS
servers that do not reset the connetion, it results in a very noticable
delay.

It could also be a potential security risk, because if this is true, then
it makes it very easy to IP-spoof a HTTP request against IIS (since the
request is a self-contained packet instead of a long connection
sequence).