Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Why IE Is So Fast ... Sometimes 934

safrit writes "Finally the scoop on how IE "cheats" a little to up its performance! Do RFCs mean nothing anymore? What's next, Riots in the streets, dogs and cats living together, mass hysteria! From the blog story: 'Internet Explorer on Windows always seems either to run impossibly fast (page requests are fulfilled almost before the mouse button has returned to its original unclicked position), or ridiculously slow...' Now read to see why..."
This discussion has been archived. No new comments can be posted.

Why IE Is So Fast ... Sometimes

Comments Filter:
  • by crashnbur ( 127738 ) on Sunday January 05, 2003 @05:42PM (#5021375)
    ...but the site has already been slashdotted! I suppose I'll just read it late tonight after the "mass hysteria" has settled.
    • by Sayjack ( 181286 ) on Sunday January 05, 2003 @06:47PM (#5021802) Homepage
      Hmm...wierd, IE displayed the site before I even thought to click on the link.
  • by stephenisu ( 580105 ) on Sunday January 05, 2003 @05:42PM (#5021376)
    The same powers that make IE impossibly fast also made this site crash impossibly fast. :)
    • by Anonymous Coward
      More like, the powers that keep slashdot editors from telling people they're going to be linked caused perl to suck up all our CPU. Nothing crashed, the proc was simply pegged until I woke up and fixed it.

      It's back up with a redirect for slashdot.
  • Cut n Paste (Score:3, Informative)

    by dogbowl ( 75870 ) on Sunday January 05, 2003 @05:45PM (#5021391) Homepage
    Straight from the site.......

    Internet Explorer on Windows always seems either to run impossibly fast (page requests are fulfilled almost before the mouse button has returned to its original unclicked position), or ridiculously slow (as with the weird stalling-on-connect problem that many people, including myself, have noticed).

    One possible explanation is something that my team and I noticed a couple of years ago, in analyzing packet traces of IE's connection setup procedure. Microsoft might have fixed this since then; I'm not sure. But it's a possible culprit.

    First of all, for those rusty on their TCP/IP-- here's how a normal HTTP request over TCP should work:

    Client Server
    1. SYN ->
    4. Request ->

    This is how the client and server synchronize their sequence numbers, which is how a connection gets established. The client sends a synchronization request, the server acknowledges it and sends a synchronization request of its own, and the client acknowledges that. Only then can the HTTP request proceed reliably.

    The server's SYN (synchronize) and ACK (acknowledgement) packets are combined for speed; there's no reason to send two separate packets, when you're trying to get a connection established as quickly as possible. Another speed enhancement that Mac OS 9's stack uses, by the way, is to combine the client's ACK and the HTTP request into a single packet; this is legal, but not frequently done. The idea is that within the structure of TCP/IP, you want to minimize the number of transactions that need to take place in setting up the two-way handshake necessary before you can send the HTTP request.

    When tearing down a connection, it looks like this:

    Client Server
    3. FIN ->
    Uh... what? Dunno what the hell this is. I'll ignore it, or RST.
    2. Oh, you're a standard server. Okay: SYN ->
    5. Request ->

    In other words, instead of sending a SYN packet like every other TCP/IP application in the world, IE would send out the request packet first of all. Just to check. Just in case the HTTP server was, oh, say, a Microsoft IIS server. Because IIS' HTTP teardown sequence looked like this:

    Client Server
    1. ...And that's it. The client doesn't FIN, and the server doesn't ACK. In other words, the connection is kept "half-open" on the server end. The reason for this? Why, to make subsequent connections from IE clients faster. If the connection isn't torn down all the way, all IE has to do is send an HTTP request, with no preamble-- and the server will immediately respond. Ingenious!

    They probably called it "Microsoft Active Web AccelerationX(TM)®" or something.

    (I may be remembering this incorrectly; it might be that the client does FIN, and the server simply keeps the connection around after it ACKs it. Instead of shutting down the connection entirely, it just waits to see if that client will come back, so it can open the connection back up immediately instead of having to go through that whole onerous SYN-SYN/ACK procedure. Damn rules!)

    Now, what does this mean for non-IIS servers? It means that if you use IE to connect to them, it first tries to send that initial request packet, without any SYNs-- and then it only proceeds with the standard TCP connection setup procedure if the request packet gets a RST or no response (either of which is a valid way for a legal stack to deal with an unsynchronized packet). 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. But IE to non-IIS servers waste a packet at the beginning of each request-- and depending on how the server handles that illegal request, it might immediately RST it, or it might just time out... which would make the browser seem infuriatingly slow to connect to new websites.

    This is only marginally less stupid than RunTCP's "solution"-- and I say "marginally" only because in the grand scheme of things, this probably makes sense to Microsoft's network engineers. After all, eventually all clients will be Windows platforms running IE, and all servers will be Windows platforms running IIS. And then we can break all kinds of rules! Rules are only there to hold us back and force us to play nice with other vendors. Well, once the other vendors are all gone, who cares about some stupid RFC?

    I have to admire their arrogance and their confidence. But it'll be some time before I can bring myself to admire their technical integrity.
    • by Afrosheen ( 42464 ) on Sunday January 05, 2003 @05:51PM (#5021438)
      One thing looked familiar to me:

      " Client Server
      1. SYN ->
      4. Request ->"

      That's very similar to the working of the infamous underpants gnomes.

      1. Collect underpants
      2. ?
      3. Profit!
    • i wonder about the relationship between this and the standard keepalive protocol, which basically is a standard that keeps a connection open for a certain amount of time so the browser doesn't have to keep opening new tcp connections for each image or whatever.
      i would assume that the keepalive protocol reduces the ill effects of this system, since once a connection is made it doesn't have to be torn down and reestablished, or at least not for each request.
    • Re:Cut n Paste (Score:4, Informative)

      by Todd Knarr ( 15451 ) on Sunday January 05, 2003 @05:57PM (#5021475) Homepage

      If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it. If the server doesn't support persistent connections, it's free to close it's end of the connection. The browser is supposed to see this, close it's end and open a new connection for the next request, but it's possible IE is simply assuming persistent connections and only doing the close-and-reopen when it sees an error sending the additional requests. My guess is that they combined error-recovery ("the connection died, close it, open a new one and retry the request") with handling servers that don't support persistent connections ("server closed the connection, close our half and open a new one for this request").

      • by xcomputer_man ( 513295 ) on Sunday January 05, 2003 @06:29PM (#5021678) Homepage
        Err, I don't think so. From what I've read about HTTP KeepAlive, the connection should be kept alive by adding a "Connection: KeepAlive" header to the request or something like that. I can't imagine any reason why any protocol should want to interfere with the TCP handshaking sequence for keepalive purposes. That would mean crossing out of the application layer into the transport layer.

        This issue caused me a lot of grief last year, and I am just figuring out why. We set up a webmail server using Apache/Vhosts and OpenSSL, and we had this recurring problem of links just suddenly breaking in IE ... It'd just return "Page could not be loaded" or something like that. The problem never cropped up in Mozilla or other browsers, and eventually I found out that if I added this line:

        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

        to the virtual host configuration, the problem went away. Now that I've read this article, I think I understand why. What I think is happening here is that Microsoft trying to make the most out of keepalive/persistent connections by bending the rules. And it's not right.
      • by Admiral Burrito ( 11807 ) on Sunday January 05, 2003 @07:13PM (#5021959)
        If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it.

        You might want to look into HTTP 1.1 as well. In fact, so should Microsoft, because (if the article is accurate) they've apparently re-invented the wheel in square form.

        Standard HTTP 1.1 keepalive still uses a regular, plain, vanilla TCP connection. No FIN packets until the connection actually is finished. It simply doesn't close the connection, allowing further requests on the same connection (because the connection is still open). The connection is closed - using the standard methods - when one side decides to close the connection (eg. after a timeout).

        What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.

        • No, what's described is a plain vanilla half-close of a standard TCP connection. The server called shutdown(), sends a FIN, the client stack ACKs it. The browser doesn't call shutdown(), hence it doesn't generate any FIN packet for it's half of the connection. It's entirely acceptable from a TCP-protocol standpoint, although highly annoying.

        • by RickHunter ( 103108 ) on Sunday January 05, 2003 @09:09PM (#5022522)

          What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.

          You know, I seem to recall some guy saying that Microsoft's long-term goal was to embrace, extend, extinguish TCP/IP. And that they'd start by making tiny little changes so that Microsoft programs talking to Microsoft programs worked much better than Microsoft/non-Microsoft. He got booed down quite loudly - everyone claimed that they could never try anything like that. It'd be noticed immediately and they'd have a PR disaster.

          The odd thing? He was half-right. He was wrong only in saying that they hadn't done it yet.

        • by inKubus ( 199753 ) on Sunday January 05, 2003 @09:29PM (#5022601) Homepage Journal
          What is much more interesting is what IE does AFTER it sends that first request without opening the connection... You know the lovely MSN Search page it loves to pop up? Everytime IE encounters (for the first time in each session) a non-IIS server, it promptly connects to MSN Search and submits the website address....

          You are being watched, friends.
      • Re:Cut n Paste (Score:3, Interesting)

        by Bodhidharma ( 22913 )
        I run a bunch of Apache/mod_ssl servers for WebCT, an online course management tool. We have to disable keepalives for IE users because otherwise their connections get hosed up.

        I wonder if this habit of playing fast and loose with the protocol is responsible.

    • What RFC means to MSFT:

      Rules For Cowards.

      Maybe this is what they mean by innovation? We all what they really mean by innovation:

      "Screw the Open Standards, we will create our own Standard, but make it secret!".

    • that cannot be... surely there'd be an endless amount of problems with stateful firewalls. not to mention that isa and msproxy server would have to support this.

      are we sure that the author just doesn't understand persistant connections???

      a simple netstat -a would show you if the connection was kept open... i'm using squid as my proxy so can't test this.
    • A different take on it than the usual "Profit!!!"...

      Client Server
      1. SYN ->
      4. Request ->

      Three, sir.

    • by jabley ( 100482 ) on Sunday January 05, 2003 @09:01PM (#5022491) Homepage

      RFC 1379 [] and RFC 1644 [] describe a mechanism for improving the performance of transactions in standard TCP, by avoiding the three-way handshake involved in TCP virtual-circuit establishment and teardown. The document was published over ten years ago, and has been implemented in several IP stacks. The article that this story linked to did not give enough detail to confirm that it was T/TCP he was looking at, but the sketchy description he gave was consistent with T/TCP.

      The T/TCP Home Page [] describes some early implementations (e.g. FreeBSD since 2.0.5).

      From RFC 1379 (R. Braden, ISI, November 1992):

      This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.

      You can trivially turn on T/TCP in FreeBSD as follows (it is off by default):

      sysctl -w net.inet.tcp.rfc1644=1

      Morals of this story:

      • not everything is an Evil Microsoft Plot to take over the world
      • sometimes it helps to know what you are talking about before revealing astonishing revelations.
      • This is NOT T/TCP (Score:5, Insightful)

        by sdxxx ( 471771 ) on Monday January 06, 2003 @02:59AM (#5023891)
        As described by the article, it actually doesn't sound like IE is using T/TCP. With T/TCP, new connections still require SYN packets. It's just that the SYN packet can also contain data, because a monotonically increasing connection counter guarantees that the server is not just seeing some old duplicate SYN packet.

        The article is admitedly not very clear about what is going on. However, it seems to imply that the server resurrects a given TCP connection, and sends data with later sequence numbers than the FIN. That doesn't sound right.

        It's also quite possible that the article is wrong or mischaracterizes the observed behavior. In particular, if IE really worked as described, you'd think people would have run into problems with certain stateful firewalls and NAT boxes.

        I wish the article would elaborate a bit more on what goes on in step "1. Request".
  • by nother_nix_hacker ( 596961 ) on Sunday January 05, 2003 @05:46PM (#5021406)
    ...but I think thats because during the build process it caches the entire web, hence the build time!
  • by BLiP2 ( 54296 ) on Sunday January 05, 2003 @05:46PM (#5021411)
    Seeing as I'm stuck using dialup for the next few weeks, all I ever see with IE is slow. What is this 'fast' of which you speak?
  • by Groganz ( 552205 ) on Sunday January 05, 2003 @05:48PM (#5021416)
    Ah, damn Mozilla.
  • Nothing new really (Score:3, Interesting)

    by Anonymous Coward on Sunday January 05, 2003 @05:49PM (#5021425)
    Heck, IE still uses an HTTP Accept line with */* at the end without quality ratings rather than a more complete one, like Mozilla's. Reason? It saves a few bytes.

    IE 6/Win: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*

    Mozilla: application/x-shockwave-flash,text/xml,application /xml,application/xhtml+xml,text/html;q=0.9,text/pl ain;q=0.8,video/x-mng,image/png,image/jpeg,image/g if;q=0.2,*/*;q=0.1
  • Opera is Worse (Score:3, Informative)

    by checkitout ( 546879 ) on Sunday January 05, 2003 @05:49PM (#5021429)
    For Opera to get it's "Fastest browser on earth" title, it caches EVERYTHING. Even things that aren't supposed to be cached like SSL pages.
    • No, it's not. (Score:5, Informative)

      by Rui del-Negro ( 531098 ) on Sunday January 05, 2003 @06:02PM (#5021508) Homepage
      No, it doesn't. In fact, it doesn't even cache any page that's protected by a password, nor does it add them to the list of recently visited addresses (which is nice both for security and privacy reasons).

      They are only kept in the RAM cache (i.e., when you press "back" or "forward", it will usually show you a page's last state (down to the position of the scroll bars), without reloading it. This is quite useful, BTW; it means you can go back and forth between pages without losing what you were writing in a form (unlike MSIE, where forms are reset).

    • Re:Opera is Worse (Score:4, Informative)

      by doowy ( 241688 ) on Sunday January 05, 2003 @06:02PM (#5021516) Homepage
      For Opera to get it's "Fastest browser on earth" title, it caches EVERYTHING. Even things that aren't supposed to be cached like SSL pages.
      Opera also renders super fast. Even going through local pages or cache, the difference is noticeable to me (admittedly, on an outdated machine - but saying I should need a P4 to browse the web is silly).

      Opera isn't worse. It's better. Definitley less bloat. It CAN render faster. And if I understand the article correctly (I actually read it) then it means this:
      • IE retrieves faster from IIS servers.
      • IE retrieves SLOWER from all non-IIS servers.

      Common slashdot propoganda suggests MOST servers are not IIS. This would mean Opera can retrieve faster on average.. and I'm fairly certain it can render the page for display quite a bit faster.

      P.S. You can turn off caching in the options if it really bother you.
  • security (Score:3, Interesting)

    by agurkan ( 523320 ) on Sunday January 05, 2003 @05:52PM (#5021442) Homepage
    Does anyone know if this sequence is there for security purposes? It looks like this might lead to a spoofing vulnerability.
    • Re:security (Score:3, Informative)

      by TheMidget ( 512188 )
      Does anyone know if this sequence is there for security purposes? It looks like this might lead to a spoofing vulnerability.

      Indeed, it makes spoofing much easyer: no need to bother with sequence number guessing, just send your data packet right away, and pretend the connection is already open. This, combined with the fact that many IIS servers are often full of SQL-injectionable scripts should provide for great phun! Who needs open proxies when you can spoof so easily?

    • by Glytch ( 4881 ) on Sunday January 05, 2003 @07:06PM (#5021919)

      Of course not. Microsoft would never do such a thing. I scoff at your ridiculous suggestion, good sir.

  • by beezly ( 197427 ) <beezly.beezly@org@uk> on Sunday January 05, 2003 @06:01PM (#5021502) Homepage
    Ok, I've only been able to read the copy of the blog from that which has been pasted in these Slashdot replies (i.e. I might have missed some of the story), but I've just tried this out and it's not what I'm seeing at all. Between an IE6/XP machine and my Apache box...
    21:54:48.351781 > S 3610909795:3610909795(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
    21:54:48.352052 > S 4178252606:4178252606(0) ack 3610909796 win 5840 <mss 1460,nop,nop,sackOK> (DF)
    21:54:48.352202 > . ack 1 win 64240 (DF)
    21:54:48.352400 > P 1:243(242) ack 1 win 64240 (DF)
    21:54:48.352528 > . ack 243 win 6432 (DF)
    Which appears to be a perfectly standard SYN->SYN->ACK handshake at the beginning. Also, do IE5.5/6 support HTTP pipelining? Surely this would explain the web browser not tearing down connections in between HTTP commands. Mozilla supports it! :) ... or maybe I've just not understood the blog entry correctly!
    • by Panoramix ( 31263 ) on Sunday January 05, 2003 @07:38PM (#5022094) Homepage

      Thank you for posting that dump. The first thing I thought of was sniffing my ethernet myself, just to see if this was true. Regrettably, I have no Windows machines available here to test with (never imagined that I would ever think of this as 'regrettable' :-).

      Anyway, I'm having a really hard time believing this story. I just can't get me to think that such a nasty hack would have gone unnoticed for years (the article speaks of years). I mean, think of the security holes it would open! The many router and firewall mysterious misbehaving it would trigger. And no sysadmin, or lowly script kiddie noticing this? It just can't be.

      I'd love to have information on how to reproduce this, and see it for myself on my network. Yes I'd put Windows and (yuck) IIS in one of my boxes, for a couple of hours, to run this test. But until I can see it myself, or read about it in Bugtraq, I won't believe it, and will be ashamed that Slashdot is publishing it without a big note stating at the very least that "this may be not true".

      Really, even though I'm a GNU/Linux user, the kind that actually uses the "GNU/Linux" tag from time to time, and that I love Mozilla and all, if find this just as low as the best FUD Microsoft has come up with in their dirty history.

  • Wow (Score:3, Interesting)

    by archnerd ( 450052 ) <nonce+slashdot@org.dfranke@us> on Sunday January 05, 2003 @06:06PM (#5021540) Homepage
    This almost makes me want to break some other rules and hack my TCP stack to send back some other amusing responses to unsynchronized packets - perhaps a ping of death or an invalid OOB packet (WinNuke)?
  • by sweede ( 563231 ) on Sunday January 05, 2003 @06:10PM (#5021565)
    i've ran Netscape 4.1 on my pentium 133 with a 28.8 kps modem, but web pages load instantly on my box. whats my secret??

    Well i'll tell you !!

    i upgraded to IE 6.0* and the web pages popped up instantly !! even the pop-ups where there just as quickly

    using IE increased the speed of web browsing on the internet for me, it can for you too !

    *Note: to run IE 6.0 i also had to upgrade to a more recent AMD XP system running Windows XP and a 1.5mbs Cable Modem service which had a 98% impact on page load and rendering times.
  • FTP the same? (Score:4, Interesting)

    by Shelled ( 81123 ) on Sunday January 05, 2003 @06:11PM (#5021571)
    A custom application we run at work makes use of the IE ftp client to make automated connects to our ftp server. Any other client, Linux or Windows, disconnects from the server on shutdown. IE or the IE-based ftp client don't, even if you exit IE. Because of this we've been forced to set a session idle timeout of 1 minute on the server to avoid hanging connections. Is this another example of the same technique, client-side?
  • by suwain_2 ( 260792 ) on Sunday January 05, 2003 @06:17PM (#5021611) Journal
    Reading this, I was forced to wonder... Is this really a bad thing? For once, it almost seems like true innovation, rather than their 'embrace and extend' (ie - 'extend' a standard just enough to make it incompatible with non-Microsoft stuff): they've found something superior to the current method in use, and both their browser and server software implements it. Better yet, it's backwards-compatible: a non-MS browser can connect to an IIS server, and IE can connect to a non-IIS server.

    The thing I don't understand... Isn't this somewhat like keepalive and pipelining?

    I normally hate Microsoft, and think they are up to massive conspiracies. However, in this case, it seems more to me like a legitimate innnovation, as opposed to some elaborate scheme. I fail to understand what is 'evil' about this: isn't this a good thing?

    • Isn't this somewhat like keepalive and pipelining?

      As has been said countless times already, no. This is a violation of the TCP standard. Pipelining works within the HTTP standard, and part of that is keeping the connection open using standard TCP signalling technology, which this is definitely not.
  • Pure BS (Score:3, Insightful)

    by unterderbrucke ( 628741 ) <> on Sunday January 05, 2003 @06:18PM (#5021616)
    "One possible explanation is something that my team and I noticed a couple of years ago"

    They had IE 3 a "couple" of years ago. This article is based on faulty data from two or three years ago, which the author even admits.

    Maybe the editors should read the links in stories before posting the stories, it gives Slashdot a bad name to be posting articles like this.
  • Cute! (Score:3, Insightful)

    by overshoot ( 39700 ) on Sunday January 05, 2003 @06:19PM (#5021617)
    So, if I understand this correctly, IE and IIS skip right over that picky TCP synchronization and get right to transferring traffic packets. Which, IIRC, leaves them wide-open to quite a few interesting failure modes and cracks.

    Not that a few bugs and vulnerabilities more or less would make much difference, of course. Still, in case any doubt remains WRT Microsoft's attitude towards reliability and security ....

  • by abischof ( 255 ) <alex @ s p a m c o> on Sunday January 05, 2003 @06:20PM (#5021626) Homepage

    IE's other trick, or so it is assumed (since the source isn't available) is that it does full DOM and JS caching.

    That is to say, if you visit a webpage with (say) Mozilla, the HTML is interpreted and the HTML tree is built in memory. Pages with advanced CSS have a more complicated tree, of course. However, when the user leaves the page, that tree is destroyed and has to be recreated each time the user visits the page.

    The bug to correct this in Mozilla is bug 38486 [] - "[FEATURE] Keep DOM and JS context in memory to provide fast access when clicking back". You can also vote for it [] (free Bugzilla account [] required) though you'll have to copy-n-paste the URL into your browser window since Bugzilla doesn't accept referrers from Slashdot.

    PS Threaded e-mail is handy, eh? It sure is, unless your mail reader doesn't remember that you want to see your mailboxes in threaded view and keeps reverting back to collapsed form. That one is bug 64426 [] (vote for it [] if you like).

  • by nuckin futs ( 574289 ) on Sunday January 05, 2003 @06:21PM (#5021633)
    No matter how fast or how slow IE is, a lot of people are still stuck using it because there are just some sites that are Windows-centric. Some sites just don't work or looks like crap if you're using something else.
  • by Anonymous Coward on Sunday January 05, 2003 @06:26PM (#5021660)
    4069902 TCP in 2.5.1 should have similar slow start mechanism as in 2.6 13 Aug 1997


    The TCP specification requires something known as "slow start". The
    algorithm applies to the sender side and is described in RFC2001.

    The intent of the slow start algorithm is to avoid a "congestion
    collapse" in a network by ensuring that each TCP sender doesn't
    overwhelm the network. The algorithm mandates that the first
    transmission be a single packet. If the recipient acknowledges
    the first packet successfully (i.e. the communication doesn't time
    out and the recipient believes that the packet has arrived without
    error), the sender sends two more packets. Successful transmission
    results in the sender sending yet more packets in parallel, until
    the capability of the underlying network is reached and one or more
    packets are not acknowledged successfully. Essentially the sender
    uses ACKs as a "clock" to regulate and gradually increase the
    rate packets are injected into the network until it reaches an

    The TCP specification describes another technique known as
    "delayed ACK", which concerns the receive side. The technique
    calls for an acknowledgement of a data packet to be delayed for a
    short period of time - the delayed-ACK interval. Different TCP
    implementations use different delay intervals. The TCP specification
    (RFC1122) mandates that the delayed-ACK interval must be less than
    0.5 second. Delayed ACK serves to give the application an opportunity
    to send an immediate response, in which case the ACK can be
    piggyback'ed with the packet carrying the response. This technique
    is very useful, both in saving the network bandwidth and in reducing
    the protocol processing overhead, and is widely adopted by TCP
    implementations. The TCP standard also recommends that an ACK not to
    be delayed for more than two data packets. This is to keep the slow
    start algorithm on the sender side flowing, which counts on the ACK
    packets coming back from the receive side in order to strobe more
    data packets into the network.


    A simplistic implementation of delayed ACK can cause unnecessary
    idle time during the initial data transfer phase in a client-server
    network environment. The scenario is as follows. When a sender
    request can't fit in one TCP packet, TCP will break it up into
    multiple packets. During the initial slow start phase, the sender
    is allowed to send only one packet. Therefore only a partial sender
    request is sent. The receiver application, upon receiving the
    data in the packet, is not able to respond because the data is
    incomplete. In the mean time, the receiver TCP is holding back the
    ACK, waiting for the second data packet to show up. But the sender
    TCP is waiting for an ACK to come back before sending more data - a
    temporary deadlock. Eventually, the receiver TCP will give up the
    waiting after a delayed-ACK interval, and send back an ACK.

    This interplay of a simplistic delayed-ACK implementation with
    slow-start algorithm accounts for the idle time problem seen in a
    number of WEB benchmarks. These benchmarks employ HTTP response
    messages of at least 8KB and usually more. On a typical network,
    this size of data requires more than one TCP packet to carry.

    During the idle time, the client TCP holds back the acknowledgement
    of the first packet while the client HTTP is waiting for the rest
    of the response data from the server before it can issue the next
    HTTP request. But the server is waiting for the client TCP to ACK
    before it can send the rest of response data.


    Only configurations with clients that use a simplistic delayed ACK
    implementation, e.g. Windows/NT, will exhibit the idle time problem
    when talking to a Solaris server. Configurations using Solaris
    clients are not affected by this problem because Solaris uses a more
    sophisticated delayed-ACK algorithm. It recognizes the initial data
    transfer phase, and will not delay the acknowledgement of the first
    data packet.


    Configurations using a server running Windows/NT, or an OS with a
    BSD derived TCP stack don't exhibit this idle time problem. This
    is, rather ironically, due to a widespread bug in the slow start
    implementation in both Windows/NT and BSD derived TCP stacks.

    The bug in the server erroneously takes the last ACK in the TCP 3-way
    connection handshake as an indication of a data packet successfully
    going through the wire. Therefore, when the server is ready to send
    back the first response, it is allowed to send TWO, instead of one
    TCP packet. The client, upon receiving two packets, will ACK
    immediately as suggested by the TCP specification.


    A new TCP tunable "tcp_slow_start_initial" has been added to the
    Solaris 2.6 release. The default value is one (1), which gives the
    same behavior as Solaris 2.x releases prior to 2.6, and is fully
    compliant with the current TCP slow-start standard (RFC2001).

    The amount of the extra delay described above depends on the
    delayed-ACK interval of the client's TCP stack, and is usually on
    the order of 200 milli-seconds. For a normal TCP connection, this
    delay is hardly noticeable. Nevertheless, it may not be true in an
    environment that employs many short-lived connections, or connections
    transmitting only a small amount of data. A good example is a WEB
    server. In those environments, one should consider changing
    "tcp_slow_start_initial" from the default value of one (1) to two (2).

    The potential downside of the change is that, with many clients all
    starting at two packets instead of one, more network congestion
    might be introduced. IETF (Internet Engineering Task Force, the
    industry group that governs the Internet standards), after recognizing
    the problem described here and the widespread of the slow start bug
    described in 4) only recently, conducted a preliminary study over the
    global Internet on the effect of amending the slow start algorithm
    to start at two packets instead of one. The study found no evidence
    that the change caused more congestions. It's still conceivable,
    although rare, that on a configuration that supports many clients on
    very slow-links, the change might induce more network congestions.
    Therefore the change of "tcp_slow_start_initial" should be made with

    Sun is actively participating in an effort in IETF to revise TCP
    specification to allow more packets to be sent initially. Once the
    revision is ratified, Sun will take the appropriate actions to
    upgrade Solaris TCP accordingly.

    6) COMMANDS FOR THE WORKAROUND (Solaris 2.6 only)

    > su to root
    > ndd -set /dev/tcp tcp_slow_start_initial 2

    See ndd(1M) for an explanation of the tuning facility.
  • by The1Genius ( 58749 ) on Sunday January 05, 2003 @06:46PM (#5021795) Journal
    Sounds to me like this blog is describing pipelinging which is a standard part of HTTP 1.1...

    What is HTTP pipelining?

    Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.

    HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.

    Pipelining can also dramatically reduce the number of TCP/IP packets. With a typical MSS (maximum segment size) of 512 bytes, it is possible to pack several HTTP requests into one TCP/IP packet. Reducing the number of packets required to load a page benefits the internet as a whole, as fewer packets naturally reduces the burden on IP routers and networks.

    HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests. This obviously has the potential to introduce a new category of evangelism bugs, since no other popular web browsers implement pipelining.

    When should we pipeline requests?

    Only idempotent requests can be pipelined, such as GET and HEAD requests. POST and PUT requests should not be pipelined. We also should not pipeline requests on a new connection, since it has not yet been determined if the origin server (or proxy) supports HTTP/1.1. Hence, pipelining can only be done when reusing an existing keep-alive connection.

    How many requests should be pipelined?

    Well, pipelining many requests can be costly if the connection closes prematurely because we would have wasted time writing requests to the network, only to have to repeat them on a new connection. Moreover, a longer pipeline can actually cause user-perceived delays if earlier requests take a long time to complete. The HTTP/1.1 spec does not provide any guidelines on the ideal number of requests to pipeline. It does, however, suggest a limit of no more than 2 keep-alive connections per server. Clearly, it depends on the application. A web browser probably doesn't want a very long pipeline for the reasons mentioned above. 2 may be an appropriate value, but this remains to be tested.

    What happens if a request is canceled?

    If a request is canceled, does this mean that the entire pipeline is canceled? Or, does it mean that the response for the canceled request should simply be discarded, so as not to be forced to repeat the other requests belonging to the pipeline? The answer depends on several factors, including the size of the portion of the response for the canceled request that has not been received. A naive approach may be to simply cancel the pipeline and re-issue all requests. This can only be done because the requests are idempotent. This naive approach may also make good sense since the requests being pipelined likely belong to the same load group (page) being canceled.

    What happens if a connection fails?

    If a connection fails or is dropped by the server partway into downloading a pipelined response, the web browser must be capable of restarting the lost requests. This case could be naively handled equivalently to the cancelation case discussed above.
  • by jelson ( 144412 ) on Sunday January 05, 2003 @07:06PM (#5021918) Homepage
    Which is a standard [] What is everyone complaining about?
  • by Leeji ( 521631 ) <{slashdot} {at} {}> on Sunday January 05, 2003 @07:23PM (#5022011) Homepage

    The blog describes the full HTTP transaction process as:

    Client: SYN
    Server: ACK
    Server: SYN
    Client: ACK
    Client: HTTP Request

    Which IE (allegedly) "hacks" and the transaction really goes like:
    Client: HTTP Request
    If this is true, then IE saves 2 round trips per connection. Clients generally open 4 connections per server, and keep them open (alive) until they've downloaded the page and all supporting files. So IE possibly saves 8 round trips per page with this (alleged) hack.

    For domestic dialup connections, the average round-trip latency is 60ms. DSL is around 40, while cable is around 20. Ping to find out the latency of your connection.

    So, for a domestic dialup user connecting to an IIS server, a straight request (with no handshake) would save 8*0.06s = 0.48s. The page mentions combining SYN/ACK packets, so this may even be less of a savings.

    An 0.48s cheat in page load times hardly makes IE "impossibly fast" when page load times over a modem typically run > 20s.

    Also, don't forget that this blog also talks about non-IIS servers balking at this non-standard connection setup with with an RST packet. That adds 4*0.06 = 0.24s to page load times on, say, Apache servers. If true, that doesn't make IE "ridiculously slow," either.

  • This is a hoax! (Score:5, Informative)

    by hotpotato ( 569630 ) <guygurari AT gmail DOT com> on Sunday January 05, 2003 @07:48PM (#5022152)
    This seems to be a hoax.

    Here's a tcpdump [] for [], on an XP box:

    03:47:16.259661 > S 2485226999:2485226 999(0) win 16384 (DF)
    03:47:16.279661 > S 631604626:63160462 6(0) ack 2485227000 win 65535 (DF)
    03:47:16.289661 > . ack 1 win 17520 (D F)
    03:47:16.289661 > P 1:398(397) ack 1 w in 17520 (DF)
    03:47:16.339661 > . ack 398 win 65139

    And here's for []:

    03:50:22.169661 > S 2535664221:2535664221(0) wi n 16384 (DF)
    03:50:22.199661 > S 3601141750:3601141750(0) ac k 2535664222 win 65535 (DF)
    03:50:22.209661 > . ack 1 win 17520 (DF) 03:50:22.209661 > P 1:391(390) ack 1 win 17520 (DF)
    03:50:22.269661 > . ack 391 win 65146

    These look like perfectly valid TCP handshakes. I did notice that when refreshing a site, IE reuses the previous connection, but that's legal (assuming it used Connection: KeepAlive in the HTTP header. I didn't verify that.)

    The samples were taken on my network's gateway, which is a Linux box, hence impartial :)

    But don't take my word for it. Try it yourself!

  • by hayden ( 9724 ) on Sunday January 05, 2003 @07:49PM (#5022162)
    Atleast from IE's point of view. It sounds as though the way pipelining is done is by simply trying a request first and they are using some low level api to the network stack. So if the connection happens to be open they get a speed up, if not they get a slow down. Seeing as the connection is going to be open more than it is closed it's a general plus.

    The IIS team probably noticed this and just accepted the command even though there wasn't actually a valid TCP connection present. So if they receive a packet that looks enough like a HTTP request then do it. There's probably a stack of vulnerabilities here.

    The interesting point is that IE and IIS must be using the network stack at a layer lower than the BSD style socket calls otherwise these packets would be rejected at the OS level and no, I don't believe Windows' networking stack is that crap. TCP processing is fiddly so cue more security holes.

    This is also an easy in to hurt IE performance. Rather than responding to the dud packet with a RST, don't respond at all (which according to the article is an acceptable response). I'm not sure how linux handles this atm. The end result is IE is dog slow to start loading the page but every other browser is super quick.

    And to all those people who posted saying this is HTTP pipelining, please don't talk about networking, ever. You lack a basic understanding of how network protocols are layer upon each other. It would be better if you just rub your chin and nod sagely, possibly saying "hmmmm" at the same time. That way you wont look so stupid.

  • Persistent connections work through the HTTP protocol layer over standard TCP, this is a violation of a much lower TCP protocol layer instead.
  • by CySurflex ( 564206 ) on Sunday January 05, 2003 @08:52PM (#5022451)
    I had a problem with IE & IIS I had to deal with a few years ago. We used a server side redirect, and it would break sometimes on IE 4, it worked fine on the rest of the browsers. It turned out it was a bug, in the way IE interacted with IIS.

    it's documented here: "Object Moved Error" []

  • i'd like to see... (Score:4, Interesting)

    by drDugan ( 219551 ) on Sunday January 05, 2003 @08:56PM (#5022471) Homepage
    something I can run on my apache server that rejects clients that don not follow the rfc for tcp/ip, and hence rejects ie

    I've toyed with blocking based on agent string, but that seems cruel and stoops to the level of MS...(who do this regualrly) and besides, it goes against my beliefs of software choice... however, it would be nice to redirect peopel to a page that says, "Your browser is not standards-compliant"

  • by Effugas ( 2378 ) on Sunday January 05, 2003 @09:08PM (#5022516) Homepage
    Whatever. Y'all seem to like it when *I* screw with TCP :-)

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
  • by pjrc ( 134994 ) <> on Sunday January 05, 2003 @09:19PM (#5022561) Homepage Journal
    I just fired up a vmware session with windows 98 and did a test with MSIE 5.00.2614.3500 (the one that came installed with win98 second edition, no patches or updates). Watching the ethernet with tcpdump, I did not see the behaviour specified.

    I then fired up Windows XP Pro. XP sends lots of netbios stuff at startup and periodically. Very interesting. But again, nothing nearly as interesting as this article suggests. MSIE 6.0.2600.0000... also did not reproduce this non-RFC behavior.

    Here is the packet log from tcpdump, with some comments. is the Windows XP client. is the nameserver, and is the web server (

    First, XP asks the nameserver for the IP number of
    15:19:50.426473 > 2+ A? (31)

    The nameserver responds
    15:19:50.702603 > 2 10/11/0 CNAME[|domain] (DF)

    XP/MSIE sends a normal SYN packet. There is no non-RFC packet transmitted before this standard SYN packet, corresponding to an already-open connection before this as the article claims.
    15:19:50.734980 > S 3861657940:3861657940(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)

    Yahoo responds with a normal SYN
    15:19:50.797377 > S 3674114276:3674114276(0) ack 3861657941 win 65535 <mss 1460> (DF)

    XP/MSIE sends a normal ACK to finish the connection setup
    15:19:50.802506 > . ack 1 win 17520 (DF)

    XP/MSIE sends the HTTP request (196 bytes)
    15:19:50.809064 > P 1:197(196) ack 1 win 17520 (DF)

    Yahoo responds with the first 1460 bytes of data
    15:19:50.907564 > . 1:1461(1460) ack 197 win 65535 (DF)

    XP/MSIE acks it
    15:19:50.919180 > . ack 2921 win 17520 (DF)

    Yahoo responds with another 1460 bytes
    15:19:50.923751 > . 2921:4381(1460) ack 197 win 65535 (DF)

    XP/MSIE acks it
    15:19:50.941174 > . ack 4381 win 17520 (DF)

    Yahoo responds with two more packets
    15:19:50.999791 > . 4381:5841(1460) ack 197 win 65535 (DF)
    15:19:51.007961 > . 5841:7301(1460) ack 197 win 65535 (DF)

    XP/MSIE acks that it has received up to 7301. Notice how Microsoft is properly delaying the ack until a second packet is received.
    15:19:51.013652 > . ack 7301 win 17520 (DF)

    So there are two tests, with the MSIE shipped (unpatched) with Windows 98 SE and Windows XP Pro. It looks like there just isn't a story here.

    • by MoosePirate ( 114589 ) on Sunday January 05, 2003 @09:49PM (#5022697) Homepage
      You put a lot of work into that. But alas, Yahoo isn't using IIS so its all a moot point. The idea is that the combination of IE and IIS will cause this. Netcraft [] shows that Yahoo is running FreeBSD, and thus NOT IIS.
  • by Alien Being ( 18488 ) on Sunday January 05, 2003 @09:38PM (#5022639)
    Is there anyone out there who really expected their *handshake* to mean something?
  • horse manure... (Score:5, Informative)

    by Supp0rtLinux ( 594509 ) <> on Sunday January 05, 2003 @11:25PM (#5023083)
    Whoever wrote this and his 'team' are tards. What they were seeing was a keep-alive (persistent) connection, or a persistent's total BS that IE would ever send a request to a host without a connection already being open. IIS just allows for persistent connections...when you hit, you open the sock, send your request and all and specify keep-alive. Now, the socket just stays open, so when they hit another page on the same host, they send a request to the already-open socket without the initial 3-way handshake since they've already done that. If it was true that IIS allowed IE to get a page without a 3-way handshake first (not that the Windows TCP/IP stack would even _allow_ that packet to get through because it's based off of the BSD TCP/IP stack, and a 3-way handshake _must_ be done before any data can get to a user-land socket..and not like any NATed routers would let it through, either), it would allow total TCP hijacking and DoS's But it's always nice to see that people who don't know jack are able to post stuff to slashdot ;o
  • by Krellan ( 107440 ) <`krellan' `at' `'> on Monday January 06, 2003 @12:58AM (#5023474) Homepage Journal
    The 4 steps when the server finishes sending data and closes the connection, from the article:

    Client Server
    <-- FIN
    ACK -->
    FIN -->
    <-- ACK

    When the server has no more data, it sends FIN.

    The server should not be allowed to send more data after the FIN! This is a violation of the TCP spec. Otherwise, how would clients truly know whether or not the server had more data to send?

    TCP does support something called "half close". It is possible to indicate that you have no more data to send, but that you are still willing to receive data. This is why both sides must send FIN, in order to cleanly close the connection. If one side sends FIN but the other doesn't, the connection remains open, but data can only flow in one direction (sending from the side that did not send the FIN). This is useful for cleanly shutting down connections and making sure that both sides receive all the data they were expecting.

    In the example from the article, when the client receives a FIN but does not send a FIN of its own, this is legal: the TCP connection now is one way, and data can only be sent from the client to the server. The server is not allowed to send more data. So, if IIS is doing this, it is breaking the spec. It is important to note that the client is doing nothing wrong in this case.
  • by zjbs14 ( 549864 ) on Monday January 06, 2003 @03:11AM (#5023922) Homepage
    700+ comments, 95% of which are:
    - MS sucks for breaking RFC's
    - Apache should do something about it
    - Users of IE are clueless morons.

    All of this because some blogger can't read a packet trace correctly. Everyone in the thread who's actually TRIED it (the other 5%) hasn't seen this behavior.

    There's no way anything's going to work if IE doesn't send a SYN. Nothing, Nada, Zip. It just won't happen. Firewalls, NAT, transparent proxies would kill it. IIS isn't going to care, the TCP/IP stack won't even let it get there. Same goes for Apache. Get THE book [] on TCP/IP and find out why.

    I think this thread is a prime example of what Slashdot has become. Never mind news for nerds (definition not limited to the Linux crowd) and stuff that matters. We'll post anything as long as it's anti-MS.
    • by FooBarWidget ( 556006 ) on Monday January 06, 2003 @08:13AM (#5024410)
      I don't know where you get those "95% of which are blabla" from, but I see 800+ comments:
      - 70% "the article is fake!" or "I tested it but IE use standard TCP requests. fuck you anti-Microsoft Linux zealots!"
      - 10% "MS sucks"
      - 10% junk/flamebait/trolls/crapfloods

      Sorry, but your claims are completely false. Slashdot is everything but anti-MS. Why do you think your post is modded as +5 Insightful?
      That Slashdot is an anti-MS site is simply false. People have been saying how Slashdot is anti-MS for centuries but every time I browse through the comments, there are always lots and lots of pro-MS comments, a lot of them are even modded +3/+4/+5.

1 Angstrom: measure of computer anxiety = 1000 nail-bytes