[e2e] RFI: Microsoft accused of TCP standards violation

David P. Reed dpreed at reed.com
Mon Jan 6 07:40:57 PST 2003

The following was shared with me and is making the rounds on 
slashdot.   Before I do the work to verify/refute this, has anyone from e2e 
any input?   I'm personally slightly skeptical that this is correct (though 
of course I'd be really concerned if it were).
Interesting... Microsoft is using TCP/IP in a way that
makes IE respond faster to IIS and slower to non-IIS
 > http://grotto11.com/blog/?+1039831658
Could someone with IE and IIS please verify this? A dump of
traffic with different versions of IE and IIS would be
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).

More information about the end2end-interest mailing list