Slashdot Mirror


Why IE Is So Fast ... Sometimes

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..."

11 of 887 comments (clear)

  1. Re:Cut n Paste by AntiNorm · · Score: 5, Insightful

    What RFC means to MSFT:

    "Rules For Competitors." Not for themselves.

    --

    I pledge allegiance to the flag...
    of the Corporate States of America...
  2. Re:Sounds pretty decent... by gilroy · · Score: 5, Insightful
    Blockquoth the poster:

    this doesn't sound like an overly bad idea.

    Hmmm. Deliberately breaking -- oh, I'm sorry, "rewriting" -- one of the core technologies of the Internet, without telling anyone and in such a way as to pad their speed numbers? Nah, nothing wrong about that...
  3. It *isn't* ingenious by Anonymous Coward · · Score: 5, Insightful
    By not closing the connection, it severly hampers IIS's scalability - in other words, it's a helluva lot more susceptible to the /. effect. Any server must keep track of open connections, and any computer only has a finite space to do that in.

    Of course, when your target market is non-scalable toy computers, who cares if you software isn't scalable either.

  4. Re:Sounds pretty decent... by evilviper · · Score: 5, Insightful
    Essentially Microsoft is rewriting TCP to make it UDP-like by sacrificing TCP's guaranteed delivery for a speed boost. Since HTTP is essentially stateless, this doesn't sound like an overly bad idea.

    Well, because IE leaves server-side connections open, it would make things much more difficult for the server-end, no matter if you run IIS or not. So, it can basically be considered a low-level DoS attack on all non-IIS servers.

    Wouldn't you be upset if IE pre-cached all the links in a page, just so users would have a bit of a speed boost? If they wanted IE/IIS to be faster when speaking with each other, why no have them communicate on a different port, instead of casuing problems, and slow-downs on non-IIS servers? Hey, they could use port 80, UDP... That would be faster, and since non-IIS servers won't be using UDP/80, it won't be incorrectly leaving connections open, sending invalid packets, slowing down communications with non-IIS servers, etc.

    It's not that they sped things up, it's that they did it in such a way that it causes minor problems for servers that don't use IIS. Sound a little like the Microsoft Java fiasco a little while back? Leveraging their desktop monopoly to sell IIS...

    So, this is a overly bad idea, and there are a thousand ways they could have done this better, while not causing problems for non-Microsoft products.
    --
    Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  5. Re:Sounds pretty decent... by csnydermvpsoft · · Score: 5, Insightful

    Even if the Mozilla team did come up with this idea, it would never be implemented. Why? Standards compliance. That's been their goal from the beginning - they would never break a standard, especially as fundamental as TCP/IP.

    This just goes to show the differences between Microsoft and many open source projects. Microsoft didn't care at all about the impacts of this decision - as long as it makes IE and IIS look faster, it's in. However, Mozilla/Apache/etc. aren't willing to sell out.

  6. Re:Sounds pretty decent... by moncyb · · Score: 5, Insightful

    Read the article closly. A request from IE to a non-ms server will take longer than a request from a normal browser using compliant TCP to the same server. This not only gives IE a speed advantage with IIS, it makes non-ms servers appear slower than they actually are when you use IE! The only speed advantage is with IE and IIS. As I remember, this sounds like part of the antitrust case against microsoft.

  7. closer look at the TCP teardown procedure by kelnos · · Score: 5, Insightful
    Last time I checked, most web servers could reject persistent connections.

    Speaks pretty poorly of the server (or network architecture) if your only recourse is to say "it's the client's fault!"
    this isn't the same deal. based on the TCP specs, here is what a server (or client, for that matter) is supposed to do when it wants to close the connection:
    1) send FIN
    2) wait for ACK
    3) wait for FIN
    4) send an ACK
    if the server never receives the FIN in step 3, it assumes that the client wants to keep the connection open for some reason. this is _correct behaviour_ with regards to the TCP spec. if this article is correct, MS is merely exploiting the TCP spec to its advantage. yes, it's dirty and wastes resources, but it works.

    the thing that bothers me tho, is this is what should be happening on the server end (a non-IIS server, that is):
    1) send FIN
    2) wait for ACK
    3) ok, got ACK, now wait for FIN
    4) (after timeout) hmm, no FIN, must have been lost, so we'll resend our FIN
    5) client ACKs that FIN, but doesn't send its FIN
    6) server thinks the response FIN is lost again, so probably resends its FIN

    now the server will have a max amount of retries before it gives up and finally drops the connection (which is what it was trying for in the first place anyway). this should be a relatively low number, and the timeouts between each retransmission shouldn't be that long either. so unless IE comes back and requests another page fairly quickly, the server _should_ go ahead and drop the connection, so i fail to see how this is a problem.

    the only thing i can think of is that the client keeps responding with an ACK to the server's FINs (despite not sending its own FIN), so maybe the server won't drop the connection for that reason (since the client is obviously still alive, just not responding as expected). i don't remember the TCP spec all that clearly with regards to connection teardown, so that may be where IE is able to keep the connection open.

    then again, i could be totally wrong here, but i don't think so...
    --
    Xfce: Lighter than some, heavier than others. Just right.
  8. Re:MSIE is to blame! by Ageless · · Score: 5, Insightful

    Since when was there anyone else... that mattered? :)
    Majority rules baby. Live with it or do something to change it.

  9. Re:This sounds like T/TCP by jabley · · Score: 5, Insightful

    Not a standard. RFC 1644 is classed experimental; it's not a standards-track protocol. See The Internet Standards Process (RFC 2026). The claim in the story leader that Microsoft were somehow ignoring RFCs looks, uh, foolish though, which is the point you were making.

  10. This is getting ridiculous by zjbs14 · · Score: 5, Insightful

    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.

    --
    No sig, sorry.
  11. There is something wrong with your eyes by FooBarWidget · · Score: 5, Insightful

    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.