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..."
Nothing new really (Score:3, Interesting)
Example:
IE 6/Win: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Mozilla: application/x-shockwave-flash,text/xml,applicatio
security (Score:3, Interesting)
Re:Cut n Paste (Score:2, Interesting)
1 packet???? (Score:2, Interesting)
I find this hard to believe, and also very un-newsworthy.
keepalive protocol? (Score:3, Interesting)
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:Of course (Score:5, Interesting)
I think the initial probe may be to detect if there is a still open connection to use - rather than an IIS detector.
This isn't what I'm seeing (Score:5, Interesting)
Wow (Score:3, Interesting)
Re:Sounds pretty decent... (Score:2, Interesting)
Re:http://grotto11.com/blog/?+1039831658 (Score:1, Interesting)
This is (was) often used to confuse IDS systems as they wouldn't look for data in a new connection.
FTP the same? (Score:4, Interesting)
Is This Bad? Pipelining? (Score:3, Interesting)
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?
but... firewalls??? proxies??? caches??? netstat! (Score:3, Interesting)
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.
does it really matter? (Score:3, Interesting)
Re:Cut n Paste (Score:2, Interesting)
This is fuzzy math. I do not like IE/IIS any more than the next guy but if the server to leave a half open connection on IT's side two things would happen.
#1 The client's TCP stack (not IE, the stack) would have no idea that this connection was still open and would send a new SYN as soon as the user selected another link. This new request would have a different sequence number (probably source port as well) and would have to do the THREE-WAY handshake (SYN - SYN/ACK - ACK). Negating any benefit
#2. Those 1/2 open connections on the server use resources. Any host has a limit to the # of connection it can maintain at which point it stops accepting new ones (Check out how syn-floods work!) that means if this were true IIS server would need to be restarted constantly to clear these buffers.
Plenty of other examples... (Score:2, Interesting)
Re:Persistent Connections (Score:5, Interesting)
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
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.
Re:Cut n Paste (Score:3, Interesting)
True, but suppose they hacked their TCP stack to recognize a magic SYN number, and bypass the three-way handshake if the client sends this magic number. Improbable? IE is part of the Windows kernel, so what's to say it doesn't poke directly in the TCP/IP stack. Wild speculation, I know.
RFCs (Score:1, Interesting)
One place of note in particular, is the implementation, of Nagle's algorithm in the TCP/IP stack.
Nagle's algorithm is specified as the algorithm to use for TCP/IP sockets that are no flagged as NoDelay, yet Linux blatantly ignores that, and implements its own algorithm, which while superior in some case, is worse in others, and is definetly NOT standard.
----------
For reference.. Nagle's algorithm basically says that only one TCP packet is outstanding at a time, if no packets are outstanding, a packet is sent as soon as data is available. If a packet has been sent but unACKd, just buffer the outgoing data and send it in the next packet when the ACK arrives.
Linux's implementation DOES NOT send data as soon as it is available, and adds a timed delay for the first packet, even though no packets are outstanding.
This leads to horrible performance in applications that do not enable NoDelay but do not send large amounts of data in one batch.
What's the point ? (Score:2, Interesting)
Boring.
This is NOT the standard HTTP 1.1 keepalive (Score:5, Interesting)
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.
You're only saving on Round-Trip delays (Score:3, Interesting)
The blog describes the full HTTP transaction process as:
Which IE (allegedly) "hacks" and the transaction really goes like:
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 slashdot.org 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.
Re:Cut n Paste (Score:3, Interesting)
I wonder if this habit of playing fast and loose with the protocol is responsible.
Re:Why is IE dealing with SYN? (Score:3, Interesting)
Does IE have a custom TCP layer in it?
You're kidding right? IE is not some stadn alone program. It has MANY links into low level microsoft stuff where it is 'part' of the WIndows OS. This was the whole arguement of M$'s lawyers, that IE couldn't be removed easily.
So it wouldnt' surprise me if IE had access to some special stack API to pull stuff like this. Would not surprise me at all.
Re:This isn't what I'm seeing (Score:5, Interesting)
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.
This sounds like a cock-up, not a conspiracy (Score:3, Interesting)
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.
This is bad because? (Score:1, Interesting)
Quite honestly I don't care a hoot about the standards, TCP or any of that techno-babble. If IE is faster then for everyday people that's a Good Thing.
Boo-hoo, waaahh, my 'zilla is slower - shame an army of developers didn't figure this out and hack it into the appropriate sources first, if they had then it would be; Yay for OSS!
Re:Cut n Paste (Score:5, Interesting)
cheers.
Re:Cut n Paste (Score:1, Interesting)
Re:Sounds pretty decent... (Score:3, Interesting)
another case of special interaction of IE & II (Score:3, Interesting)
it's documented here: "Object Moved Error" [15seconds.com]
i'd like to see... (Score:4, Interesting)
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"
Re:Sounds pretty decent...(MISUNDERSTAND? You do.) (Score:2, Interesting)
I HIGHLY DOUBT that Microsoft would make the connection to an IIS server between Internet Explorer and IIS lose the reliability of TCP. Images and other large files would be a nightmare to get without acknowledgements.
What I think may be happening(ingenious YES and no, read on), assuming the article isn't all just conspiracy theory, is that Internet Explorer visits a website, and leaves the connection open. Then you hit the back button(which is used extensively in web browsing) or you go to other links on the same web server. Because the client doesn't close its end of the TCP connection(REMEMBER TCP IS FULL DUPLEX), half of the connection is open. The client can just send the request immediately, the sequence numbers were already assigned, because the connection was NOT CLOSED. What support is there for my view?
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." What is this saying? Quite simply subsequent connections would be faster by leaving it open.
2. The article goes on to show IIS's server's sequence, how it shuts down but the client leaves its upstream to the server open.
It's definitely a trade off. It means YOUR computer as well as the IIS server keeps track of the connection. For a one shot deal on a server(frequently for slashdot users), the connection being left open is a waste. Eventually it must time out, but it does eat up some server resources and it would make the slash effect worse on the machine.
The article doesn't mention what non IIS servers do. If the client(IE) doesn't FIN its end of the connection, the connection is not closed. Do other servers time out? I do notice that when web browsing there are a lot of open connections in a timed wait when I use Internet Explorer. I don't think they all use IIS. In this case, their speedup would work on any client. But I am not knowledgable enough about what Apache/other http servers do to know for sure. In my TCP/IP class a year ago in college we discussed the FIN ACK sequence both ways, but didn't discuss what happens if the client decides not to FIN(aka doesn't follow the rules) by most standard servers. It is probably a design decision. Also what does MS IIS do on the first connection? It would probably be best to respond immediately with that packet so the client could immediately open the connection. And the super slow pages could be on servers that don't answer at all so IE has to wait for the request to time out. Essentially what this article is saying is that Microsoft Internet Explorer is a resource hog. But we all knew that already, that's why we call it Internet Exploiter.
Re:so what? (Score:3, Interesting)
# HTML support
# URI parsing that's RFC-2396 compliant
# Cookies support, RFC-2965 compliant
# XHTML 1.0 rendering
# Plain text rendering
# Image formats support: PNG, JPEG and GIF (no animated GIFs)
# HTTP 1.x Compliance
RFC / W3C STANDARDSEven more interesting..... (Score:4, Interesting)
You are being watched, friends.
Re:FTP the same? (Score:4, Interesting)
There's your problem. From IE 4.0 onwards, there's only one way to exit IE: You shut down Windows. Just ask the attorneys that testified before Judge Jackson.
deliberate? (Score:2, Interesting)
In any sufficiently complex software, there are bugs. One should certainly entertain the fact that this behavior is accidental. Not everything MS does is deliberate, and I find it entertaining that so many folks assume their 'enemy' is malicious and organized.
Re:Not reproducsble with MSIE 5.0 on Win98 (Score:2, Interesting)
This person is WRONG (Score:1, Interesting)
The first thing you need to do when you start a network trace is start with a clean slate. I'm sure that if this trace was done properly, that the results would be different.
IE CANNOT do what is requested here without modifications not only to IE but to the entire IP stack of the client AND the server AND firewalls AND NAT routers AND proxy servers.
For someone to send a packet requesting data without first opening up a connection would force the connection to not only be RST by every known host on the planet, but also by every known firewall and NAT router in which most of the world runs through at some point in time these days.
Therefore, it would be impossible for this packet go get through without first going through the standard TCP setup and teardown procedures.
Michael (too lazy to create an account to post under)
That explains a lot (Score:1, Interesting)
Re:DNS is a possibility (Score:5, Interesting)
IIRC this was a problem with Sun's implementation of InetAddress.getByName() on Windows. When passed a string containing a dotted numeric quad, it stupidly tried to do a DNS lookup on it instead of simply filling in the four bytes and handing you an InetAddress. Because who knows- maybe someone registered "192.168.1.23" as a domain name! (Which would be akin to registering "microsoft.com" with a Cyrillic "o", but never mind.) Then of course your thread stalled inside InetAddress for half a minute while it waited for the DNS timeout. This makes me suspect that Sun's code was waiting for the successful DNS response and ignoring the failure response that actually arrived. Probably the same moron was responsible for both bugs. Editing the hosts file became the standard workaround.
I don't know when it got fixed but there's code in there to check for a dotted quad now.
Re:Not reproducsble with MSIE 5.0 on Win98 (Score:2, Interesting)
Re:This is a hoax! (Score:3, Interesting)
Never assume.
This is the key to this whole mess. The dude who wrote the blog doesn't know about the KeepAlive HTTP header.
This is about the funniest thing i've ever seen on Slashdot.
Read the whole fucking RFC people.
Data after FIN shouldn't be allowed (Score:4, Interesting)
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.
Re:security (Score:3, Interesting)
Anyone tested it?
Re:Even more interesting..... (Score:1, Interesting)
Oh no it doesn't (Score:2, Interesting)
Re:Sounds pretty decent... (Score:2, Interesting)
because like it or not IIS is not the majority server out there. There for more often then not they are creating more traffic and slowing down your browsing not speeding it up.
Any other questions?