[e2e] RFI: Microsoft accused of TCP standards violation

H.Shrikumar shri.e2e at enablery.org
Mon Jan 6 11:55:43 PST 2003


> From: "David P. Reed" <dpreed at reed.com>
> Subject: [e2e] RFI: Microsoft accused of TCP standards violation
> 
> 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
>  http://slashdot.org/article.pl?sid=03/01/05/2025254


I am leaning very heavily towards "false alarm". Both articles
neglect to take simple traces that could have been easily
obtained, and yet jump to make very scathing accusations
(but you get that at "/." anyday just if you utter "M$") -- and are
very speculative to say the least.

Further, there does exist a much simpler explanation ... (if
I may, in my turn, be speculative).

What they are complaining about this this sequence.

     Client      Server
   0. SYN - SYN-ACK - ACK ... as usual
   1. GET  ->
   2.         <- DATA
   3. ACK  ->
   4.         <- FIN
   5. ACK  ->
   6. (pause)
   7. GET  ->

   With non-IIS Server:
   8.           (long delay)
   9. SYN  ->
   10.        <- SYN-ACK etc.

With an IIS server, apparently that "(long delay)" does not
occur.  Instead, they claim, the same connection is somehow
"re-opened" and data is sent on it, but they are speculating
and have not reported to have actually packet traced an
actual IIS server. The only thing they have tcpdumped is
the connection to their non-IIS server. (note the "would"
and "would be").

  | But IIS, playing by its own rules, would respond to that
  | packet with an HTTP response right away, without bothering to
  | complete the handshake. So IE to IIS servers will be nice and
  | snappy, especially on subsequent connections after the first one.


I think what could be hapenning is a simple combination of
the following (well known things) --

1. IIS causes its stack to send a RST shortly after the FIN
from its side. (IIRC, this has been discussed on e2e some
years ago). The server knows this HTTP connection cannot ever
produce any useful traffic anymore, and yet many browsers
keep holding their end of it open, and obligate the server
stack to keep a TCP state vector open as well. So, the server
sends a RST to force the client to wipe out its state vector
for that connection and allow it to wipe out its own.

2. Then when the browser comes to step 7, there is no TCP
connection lying around to re-use, so it goes to step 9.

3. The non-IIS server they have traced evidently did not
send the RST. So there is a half-open connection to send the
"GET" on.

Of course, one may argue that the browser could have known
that there is no point in sending a GET on a half-open
connection -- perhaps the browser neglects to make this
optimization, but that is not a crime. Therefore it "re-uses"
a half-open connection -- and results in the time-waste.

Perhaps this is what they saw in their trace.

(BTW, the article has now moved off the front page on /., which
means the thread is dead over there)


-- //Shrikumar









More information about the end2end-interest mailing list