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..."
...but the site has already been slashdotted! I suppose I'll just read it late tonight after the "mass hysteria" has settled.
The same powers that make IE impossibly fast also made this site crash impossibly fast. :)
Sigs? We don't need no stinking sigs!
kind of like how that blog link is coming up incredibly slow?
;-)
"It is seldom that liberty of any kind is lost all at once." -David Hume
um hasnt this already been covered?
oh yeah and that was the quickest slashing of a site ive seen in a awhile
oh well, wait till tomorrow, after they rebuild their smoking pile of a webserver
Can anyone post this blog, it's either down or Slashdotted
3000 dead over past 2 years, still no free Palestinians, still
Straight from the site.......
...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!
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 ->
2.
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
1.
3. FIN ->
4.
Uh... what? Dunno what the hell this is. I'll ignore it, or RST.
2. Oh, you're a standard server. Okay: SYN ->
3.
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.
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.
These pretzels are making me thirsty.
It would make things a little easier for them and us.
Just tired of seeing stories that aren't reachable by the time i click them.
SIG:Slashdot: indymedia for nerds.
And Internet Exploder, well, exploded the page.
Heh, so now we know that IE is behind the /. effect.
IE is WAY faster than everything else... and for a Windows user, like myself, I don't really care why. I've installed Ad-Aware and Spybot, so as long as it's not installing any of that garbage I don't give a crap.
IE is about 10 times faster than Netscape, that's all that matters to me.
...but I think thats because during the build process it caches the entire web, hence the build time!
18:07 - What makes IE so fast?
(top) 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 -> 2. <- SYN/ACK 3. ACK -> 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 1. <- FIN 2. ACK -> 3. FIN -> 4. <- ACK
This generally takes four steps, and the FIN/ACK packets are usually not consolidated because connection teardown is nowhere near as speed-sensitive as startup is. (The FIN sequence can be initiated either by the client or the server.)
Many very stupid companies have tried to come up with overly clever ways to speed up TCP/IP. TCP, by its nature, is a stateful and bidirectional protocol that requires all data packets to be acknowledged; this makes the data flow reliable, by providing a mechanism for dropped packets to be retransmitted; but this also makes for a more strictly regimented flow structure involving more packets transmitted over the wire than in simpler, non-reliable protocols like UDP-- and therefore it's slower. One company that thought itself a lot smarter than it really was, called RunTCP, came up with the idea of "pre-acking" TCP packets; it would send out the acknowledgments for a whole pile of data packets in advance, thus freeing them from the onerous necessity of double-checking that each packet actually got there properly. And it worked great, speeding up TCP flows by a significant margin-- in the lab, under ideal test conditions. The minute you put RunTCP's products out onto the real Internet, everything stopped working. Which stands to reason-- their "solution" was to tear out all the infrastructure that made TCP work reliably, under competing load and in adverse conditions, in the first place. Dumbasses.
So then there's this thing we discovered in the lab. We noticed that when you entered a URL in Internet Explorer 5, its sequence of startup packets didn't look like the one shown above. Instead, it looked like this:
Client Server 1. Request -> Uh... what? Dunno what the hell this is. I'll ignore it, or RST. 2. Oh, you're a standard server. Okay: SYN -> 3. <- SYN/ACK 4. ACK -> 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. <- FIN 2. ACK ->
...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.
Quick /.ing again...
Personally, the only reason I had used IE for a while is because it launched faster (due to integration) on my older system. Now that I have a descent system, I can run stuff like Mozilla, and truthfully, I see no difference in page rendering time.
but not as fast as a speeding 'slashdoting'...
Ah, damn Mozilla.
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.
n /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
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
Client Server
1. SYN ->
2.
4. Request ->
5. Profit!!
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.
Does anyone know if this sequence is there for security purposes? It looks like this might lead to a spoofing vulnerability.
ato
then I tried Mozilla's Chaimera. I was surprised at how fast it was, when I thought IE was fast. It was like using a top of the line PC then going home to my better, fasater MAC with less problems. I mean this app is still in beta and it beats IE with it's own bloddy arm. I am so looking forward to one day never using anything Microsoft aside from Xbox (only becasue they bought out Bungie!)
yet another reason why we must erase microsoft.
I find this hard to believe, and also very un-newsworthy.
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.
Let the flames commence, because I *do* think it's ingenious.
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.
I do have one question, however; how is it that Internet Explorer is able to rewrite TCP rules? Doesn't it use win32's TCP service? Or does it call a different, special TCP service?
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
This is becoming more of an issue each day (slashdottting). Not to mention I bet the people that run the Slashdotted servers don't appreciate us taking them down so easily and fast so I propose a really simple fix:
1. Slashdot should take a snapshot of the article moments before posting and leave on file for atleast a day or 2 (or until requests for the article die down a bit).
2. Change out the Cached version of the URL after #1 is satisfied.
Should be easy. Or perhaps Slashdot can just include CACHE'd links from Google instead of the real URL?
Just some ideas from a long time Slashdotter.
-GG
I thought IE was fast because most of its' code was built in to the kernel (thats why they don't offer a way to un-install IE).
Just like doing quicktime on Mac OSX.2 is fast as hell, because its built with Quartz extreme in the kernel's model.
who cry "karma whore" like 4 year old children, that should be moderated down.
This copy-paste is the only reason anyone can read the article while the source is being slashdotted... and this is the only copy where the author didn't screw up the greater-than and less-than symbols.... so without this... no one would even know what this story was about until hours from now.
Dumbass.
Want to Know How to Cheat the GPL? Read On!
what's trolly about the parents post? In my opinion it raises a very good point and could spawn an interesting discussion.
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).
RMN
~~~
And this is the highest irony...
That the poster did it as an AC... which means they get no karma.
Ooh. Double-dumbass.
Want to Know How to Cheat the GPL? Read On!
They couldn't determine the ? for the underpants, so now they're trying it with socks.
RMN
~~~
Where else can you get into 100+ post flame wars because someone used the word American instead of the 'Correct' 'USian'?
As much as it pains me, this probably isn't anything intentionally evil in the M$ implementation here - it's just more of the useless bloat and cruftiness that's standard M$ fare. The developers who wrote MFC's CSocket class probably didn't even try to communicate with a non-M$ product, and the IE and IIS developers are probably the same idiots - the ones who can't spell "security".
HTTP 1.1 allows for this - it's called a persistant connection.... and is exactly what Mozilla, Opera, IE, and every other browser is SUPPOSED to do...
The speed probably comes as a side effect of broadband and a well connected server... as a colleague of mine pointed out, Mozilla is just slow because they wait 1 second before they display the page, in case the layout changes...
Maybe the slashdot editors need to do a little bit of reading about a subject before they post them.
Easy to do, yes. Practical? No way in hell. Slashdot already sees so much traffic that on heavy days I end up with TCP errors. Caching linked pages locally would only increase Slashdot's traffic woes.
And I haven't even mentioned *storage* yet...
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
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)?
mozilla is a better browser anyways. ;)
smd4985
Heres a much faster browser: Man Gets 70mpg in Homemade Car-Made from a Mainframe Computer
I hear you and those are indeed valid concerns.
:)
So why not just link to the Google Cache'd version?
-GG
And you post this on Slashdot? As an AC? Talk about irony..
I'm curious how long it will take one of the slashbots to hit you with "REaD the SlAshdot FAQ!!1!!".
I have all four of the (IMO) major browsers on my system. I ditched IE, not because it was slow, but because certain pop-ups would cause it to frequently crash, i got Opera, and have been very happy. My computer also came with Netscape 6, and lord is it slow, nuf said. I'd heard good things about Mozilla, and downloaded it to see how it stacked up against Opera. It didn't, it was almost as slow as Netscape 6. If you dont mind the ad on the free version, Opera 6.01 is definitly the best IMO, tabbed, no pop-ups, loads fast, loads pages fast. Internet explorer is a decent browser, i still use it ocasionally for some e-commerce, and some flash games that dont work with Opera. Moz is decent, but blocked pop-ups and tabbed browsing dont make up for its slowness. Netscape, *shakes head* what happened, it used to be decent. Opera is definitly worth the $29.95 or whatever. I'm thinking a lot of people who use and staunchly defend Mozilla all used to use Netscape just to avoid Microsoft in general and switched for the extra features. Seriously, everyone should give Opera a try.
"Sic Semper Tyrannosaurus Rex."
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.
I follow the SDK and GDN principles.. Spelling Dont Kount, Grammer Dont Neither
Unless, of course, they happen to be astroturfing whores....
Everyone knows that the slashdot effect is a liberal myth.
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?
Why doesn't Apache step in and support this? It may be a sucky RFC workaround, but Internet Explorer uses it (and many people use Internet Explorer), so if Apache imitates IIS and replies to Internet Explorer's requests, then Apache servers will appear to run a little faster to IE users!
without first verifyng if it's still applicable?
Isn't SYN supposed to be TCP's job?
Does IE have a custom TCP layer in it?
Does MS's TCP stack exhibit this behavior for other programs? What API call do I make to get my own program to act like this?
[Error 407: No signature found]
now *that* is a good idea! :)
In fact, every time I submit an article (not that any of my submissions have ever been accepted), I will attempt to find a google cached version.
It may be futile, if the story is too fresh. But I vow to try!
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
IE, old Netscape and Mozilla all seemed pretty much the same to me. I find Opera to be faster than all of them.
I can open IE and Opera nearly simultainously and be surfing with Opera before IE has finished thrashing the hard drive.
Page loading times are nearly always more dependant upon bandwidth and the server than the browser, and differences so negligable that to compare on that score pointless.
I haven't noticed that IE is faster than Opera.
Somehow I doubt that not closing and reopening connection will save any significant amount of time.
IE is fast because Microsoft know Windows coding inside and out. When you run iexplore.exe, no, it's not loaded at startup, the executable just loads the relevant COM objects. The UI appears first, then their rendering engine (Trident) is loaded async which is why you see a flat white area when IE is loading for a second or two before it becomes a 3D cutout. Everything is load on demand. That's why it's fast.
Office is fast because the Office coders aren't stupid. They don't pull any OS startup tricks or anything to make that happen. How do I know this? Because I once reinstalled Windows on top of Office - deleted the whole of the windows directory and reinstalled it. Word still started in under 3 seconds, although it gave one or two complaints about missing registry entries it started fine, and boy was it fast.
Maybe IE still pulls this trick, maybe it doesn't, but at the end of the day IE feels fast because they've put a lot of work into optimization. You'll note that Mozilla is catching up now as they also get the optimizations in.
Of course, when your target market is non-scalable toy computers, who cares if you software isn't scalable either.
You don't need to post this message every time we destroy a web server and cost people tons of money. If they didn't want us to hurt their web servers they wouldn't have plugged them into the network. Now stop posting this crap and filling up all of slashdots comments with information about silly things like ethics.
If this behavior existed in an OSS app, we'd all be talking about what a cool hack it was...But since it was done by Microsoft is must be evil..Despite the fact that it DOES increase the overall positive user experience, it WORKS and while it might not be 100% standards compliant, it doesn't BREAK things that aren standards compliant. Cry me a river!
What, praytell, are these trolls^H^H^H^H^H^Hdiaries that Rusty wants to keep off the site?
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?
________________________________________________
suwain_2
Something cached in RAM is sometimes recoverable if the machine has not been switched off since the offending item was cached. And then after a machine has been power-cycled it's possible errant data is still recoverable from the pagefile (of a windows system). It's also possible to cause a situation where windows will dump it's memory to a dump file for later analysis :)
So if you're really really worried about security.. get a tool that securely cleans up after all these things.
"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.
But what's another service outage to a M$ product?
Go figure... my IE isn't coming with anything when I hit the above link.
I did the same thing with a story I submitted recently - it was a NYT story so I submitted the google partner link. They didn't publish it though :) I urge all submitters to do the same in the future.
(Incidently, the story was about copyrights in Europe that will expire soon)
Robots are everywhere, and they eat old people's medicine for fuel.
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).
Alex Bischoff
HTML/CSS coder for hire
It is forcing persistant connections rather than requesting them the HTTP/1.1 way! This means that these servers are stuck with tons of open Sockets causing it to refuse new ones!
I demand an Apache workaround by tomorrow! (j/k, apache is unnaffected and takes longer to load in MSIE because of its COMPLIANCE TO A STANDARD that M$ is trying to bend to their own will).
Will benchmarking authors be blackmailed/bribed into making their software use this while testing MSIE and MSIIS?
btw, faster connections don't mean squat if your server takes ittself down monthly!
You can't judge a book by the way it wears its hair.
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.
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.
HELP!!! HELP!!! I'M BEING REPRESSED!!! I'M BEING REPRESSED!!!
/., Rob is tightening the screws too! DOUBLEWAH!!! OHHHH, little troll troll is being censored on a private web site he doesn't own. ooohhhhhh, poor Mr. little trollie. And so Mr. little troll troll is being censored on a private web site he doesn't own. ooohhhhhh, poor Mr. Trollie.
Rusty won't let me and my troll friends fuck his site up anymore! WAH! And at
Enjoy my -1, Offtopic!
I don't know. I guess you could be lucky with getting the server's HTML code back in one hit assuming it fits into a single UDP packet.
But, we also have graphics and other much bigger chunks of data which needs to get to the client from the server. I'd be a bumby ride without the flow-control mechanisms which TCP conveniently provides for us already. Remember the ethernet frames are less than 65K.
Just my two cents.
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
Do you even remember the 'first slashdot troll post' fiasco? When hundreds of slashdot users had their posts permanently set at -1, just for posting in a specific thread? Then the slashdot admins got defensive and blamed the users for being 'offtopic'? Right there is when I stopped respecting this site.
I'd like to read the story, but it's Slashdotted right now (could someone cut/paste it?). Is there any evidence of this besides someone's blog entry?
Later,
Patrick
..of Microsoft browser networking bugs which make it only work well with IIS. For example, This bug causes IE to fail to properly shutdown SSL connections. IE browsers using SSL conenctions with standard Apache webserver configurations will have all kinds of errors due to this issue. You need to either disable keepalives or increase the keepalive timeout to something outrageous like 2 minutes. This "bug" has been around for ages yet despite IE being in version 6, it is yet to be fixed. My guess is this is actually some kind of "feature" that makes IE work faster with IIS (since the connection never closes, subsequent reqests go faster, assuming the webserver knows how to speak the broken protocol).
-----------
Posted by timothy on Sunday January 05, @ 11:11PM
from the who-cares-if-its-fast dept.
zupah^x0r writes "Good news guyz!!1! While looking through the Mozila source I spoted the reason behind the browsers' supercallifagilistick speed; it seems the good folx at Mozilla are "cheating" when crating the HTTP requestor to the web server or something. Heres teh skoop. Please be sure to donation to the Mosila org, k?" Yes, they're cheating as far as the RFC is concenred, but this is a good thing as far as I'm concerned becuase the browser is fastest. Yay open source!
(Read More... | 4621 "comments" )
-----------
Now back to our regularly scheduled programming.
4069902 TCP in 2.5.1 should have similar slow start mechanism as in 2.6 13 Aug 1997
/dev/tcp tcp_slow_start_initial 2
) TCP BASICS - SLOW START AND DELAYED ACK
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
equilibrium.
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.
2) TCP SENDER/RECEIVER DEADLOCK - THE IDLE TIME
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.
3) SOLARIS CLIENTS - NO DELAY ON INITIAL ACK
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.
4) SLOW START BUG - NO MORE IDLE TIME
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.
5) BREAKING DEADLOCK - THE WORKAROUND
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
caution.
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
See ndd(1M) for an explanation of the tuning facility.
As I understand this, and correct me if I'm wrong, IE is using an abbreviated initial handshaking mechanism when connecting to web sites, which result in a faster connection when using Microsoft-brand IIS web servers, and a slower connection when using non-IIS servers.
Will this functionality be emulated in an upcoming mod_ben_over_here_comes_Microsoft plug-in to apache?
I could appreciate the attempt to improve performance, but not at the cost of what I perceive to be yet another underhanded attempt to leverage Microsoft's monopoly on the desktop to promote their own products.
Lynx is great, links is better, but for those that need graphics there is only one choice: DILLO
The fasted web browser on earth! Blows opera to pieces! The only problem is that it's very alpha and lacks many essential features and support for lots of common things. Keep your eyes out though. If anyone ever expands upon this engine it will blow everything completely out of the water!
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.
... 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:
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.
Am I a hipster-doofus?
Konqueror loads pages much much faster than IE ever will....At school and home...at school, IE takes 10 or more seconds to load compared to Konqueror...
Whether this is just HTTP keep-alive is definitely worth investigating.
They never have ment anything before. If it's not enforced it's useless.
Have some patience amigo. It's not like apocalypse will descend if you don't get to read it immediately.
The HTTP spec allows keep-alive between the browser and the proxy. No extra magic needed there.
Lynx is faster... :)
They'd need to cache all linked images and video from the slashdotted page as well, since this typically happens to pages whose main content is pictures of lego casemods or whatever, and Google doesn't cache images.
Another solution might be to run a QoS proxy. So, if Slashdot is about to link to weaksite.org that can only handle 10 hits/sec, the link would be:
>;k
take a look at:
SpeedChimera
It enables "pipelining" on Chimera. I think it's the same thing, isn't it? It really makes page loading faster on my Mac, anyway.
Perhaps mozilla and other browsers should use the same technique IE does, because mozilla is terribly slow.
Noooo, you don't understand this, but that's not your fault, because the author of the article doesn't understand it either! This is all just bullshit.
But, wouldn't you need to setup the connection properly even if it's a persistent connection? Persistent just means we don't close the connection again just in case more data needs to be sent later. When we close the browser or go to a new page we'll still close the connection with the server gracefully.
I haven't read the HTTP1.1 spec, so please bear with me.
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
That's cuz it's been slashdotted genius.
-Mark
Dovie'andi se tovya sagain.
Isn't it time to upgrade to Opera 6.05? After all, Opera 7 will come out soon and blow everyone else out of the water.:)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
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.
The1Genius - Littera Scripta Manet
If you make so much money what are you doing on Slashdot, you fuckwad?
No, that's exactly how it's supposed to work. If you connect to a HTTP1.1 server, and tell it you want to keepAlive, and it doesn't explicitly refuse, you can assume that it's going to keep a persistent connection.
How can someone who's been reading Slashdot for so long not realize that he's not getting karma. I suppose you plan to vote for Al Sharpton.
Sorry about the all caps, but this is really starting to get ridiculous. Sure, it's very funny for all of us reading to know that we can bring a site to its knees. But, this persistent slashdotting has got to come to an end! Would it really be that had for Slashdot to mirror the submitted site in cases where the editors know that it is going to get slaughtered?
Don't say that they would have to ask for permission. They have no qualms with devastating a site, so why should they worry about the repurcussions of mirroring the site?
There is an op-ed over at Kuroshin that deals with this subject.
Come on people, can't we try and be a little bit more responsible?
How long do you think that would go on before the lawsuits started flooding in?
Maybe this explains why I get :
"the connection unexpectedly died" sometimes when I browse IIS sites with Konqueror?
using UDP in favor of TCP is a very bad idea, because of TCP's congestion avoidance, or the lack thereof in UDP. If everyone starts using UDP the net performance is going to crawl. Read Tannenbaums network book for a better explenation ;)
Before jumping on the let's kill MS for ignoring RFCs. Maybe Linux needs to look at itself, as I'm sure there are places it does NOT adhere to RFCs.
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.
Yeah, and you have no sense of humour, Einstein!
You see our point. OOOOHHH. It's going to cost so much to do this. In the mean we'll fuck little guys over with the bill. Hello lawsuit. It's coming slashdot. You're going to fuck the wrong person someday.
Several folks have posted the text above, like this one. I always look for these posts when a sight gets slashdotted.
Run and catch, run and catch, the lamb is caught in the blackberry patch.
If this were true, firewalls would not work with ie.. as it would send a (something) before the syn.. and most firewalls will not pass packets that are part of unopneed tcp connections.
This looks more like a misinterpretation of persistent connections.
This story will provoke angst about standards, but, to be sure, why should an end user worry about standards? If the 90+ percent of the world that use IE are satisfied with its performance, what relevance have standrds for them?
Standards make life easier for developers, but not necessarily for users. Isn't there some truth in the fact that standards tend to be the refuge of people who can't sell enough product?
-- Slashdot: When Public Access TV Says "No"
Comment removed based on user account deletion
It's amusing that netscape did it first (before IE existed) and now IE is getting flamed for similar behavior.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
TCP has a standard for this, called T/TCP.
Its also perfectly legal to send data on the SYN, the SYN gets acked after all.
So what's the big deal?
Way to teach us all the enlightened path that I'll bet no one has ever thought of before. Kuro5hin knows the wise path before we even acknowledge the problem! Wow!
Pack up and get out. You're fired.
Which is a standard What is everyone complaining about?
Of course not. Microsoft would never do such a thing. I scoff at your ridiculous suggestion, good sir.
"Nobody cares about your post but I'm responding it anyway to point out that nobody cares and that's why I'm replying to your post that nobody cares about and... and... ah, ah, ahhhhh I'm cumming on my hand because all I can do is masturbate to the video of steve balmer jumping around like a psychotic monkey"
Comment removed based on user account deletion
I'm missing the point of this /. story. M$ bashing? An attempt to establish a position on the "moral highground" for the non-M$ community? Trying to convince IE users to switch to another browser because using IE would constitute a standards violation (say it isn't so!)?
Boring.
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.
I looked at a connection from IE6 and it sent the apropriate packets. Please discard parent article.
I live in a giant bucket.
Comment removed based on user account deletion
IT IS CORRECT. ARTICLE IS WRONG.
PLEASE STOP ACTING LIKE MORONS.
(Use the Preview Button! Check those URLs! Don't forget the http://!)(Use the Preview Button! Check those URLs! Don't forget the http://!)(Use the Preview Button! Check those URLs! Don't forget the http://!)(Use the Preview Button! Check those URLs! Don't forget the http://!)(Use the Preview Button! Check those URLs! Don't forget the http://!)
hey, Linux users, for more Phoenix speed plug this into yr ~/.phoenix/default/xxxxxxxx.xlt/user.js file:
user_pref("nglayout.initialpaint.delay", 0);
CB
free ipod and free gmail!
Kuso5hin is comprised of a bunch of pretentious buttfuckers.
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.
It all goes downhill from first post
Er, if you can read Japanese. Here. I ran it through Babelfish the other day and got some fun results.
Phoenix runs fast enuf for me!
:)
#dampbarn @ IRCnet, In open-source we believe!!
//Micke
and Links is better... :)
M$ actually used TCP/IP as an example of how the software market has been harmed by free/open-source software instead of commercial software.
Looks to me like they hold the creators of TCP/IP in contempt for not making it licensed, closed-source software!
And at the same time, they steal and modify the TCP/IP stack from BSD UNIX so they can forward their own business goals! Oh wait, they call that 'innovation'...
-Dragoth
--
Microsoft announces new emoticon product ratings, gives latest Windows and Office products XP
The more IE windows you have open, the longer this pause tends to be.
I looked into this a while back and came to the same conclusion. Running stopwatch tests and curve fitting to A*N^2+B*N+C, it looked like the time went up with the square of the number of windows (B was ~ 0, and C was...a constant).
So I told the user who brought it up to 1) not open so many windows or 2) switch to something other than IE.
IIRC, she switched to Opera.
-- MarkusQ
>(page requests are fulfilled almost before the mouse button has returned to its original unclicked position)... I can`t understand this text mean,,,, maybe I`m really stupid....
Maybe if you were using a first-post-compliant browser, you wouldn't have the abysmal shame of third post. However, because you insist on using inferior, non-first-post-compliant-technology, YOU FAIL IT !
You didn't mention at the end that your benchmarking was sponsored and funded by Microsoft.
If my memory serves this problem was with WIN98 and Sun's java; When trying to connect to an address of form 1.2.3.4, the program would halt for some twenty-thirty seconds before proceeding. Giving the address an alias in hosts file was a working workaround. Dunno, if the problem was with the program, java or windows, but two things were wrong. One: trying for DNS resolution in the first place. Two: ignoring the negative DNS response. The system waited for a timeout even if the DNS server responded that the name couldn't be resolved.
I too am inclined to think that Windows occasionally meditating might have something to do with DNS.
Any faster, and the damn thing will be reading my mind. Now if only the Phoenix project made makeup for my girlfriend.
"I'll be right down honey!" -sigh
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).
The definition of a dumbass is a guy who uses his dialup account to download an early Traci Lords clip from an overseas server and then sweats blood over how to wipe his RAM cache and swap space at the same time.
Good one!!!
The Article is completely FUD.
I've written a thingie which sits between winsock and apps, redirecting them through socks5 proxy transparently using Layered Service Provider API. So I traced a little bit what IE do.
Let me ensure you - IE uses standard winsock functions with ordinary parameters as any app do.
No conspiracy here.
Probably author of the article had some experimental features of windows tcp/ip stack turned on, or just had lame sniffer.
Where are at least packet logs to prove the point ?
Seems very doubtful to me.
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
i found out that mean.
Hell, I was holding back. Good thing I didn't really speak my mind.
page requests are fulfilled almost before the mouse button has returned to its original unclicked position
Must be talking about this, as i can't imagine any other page popping up that fast.
SEO Copywriter. Just Say ON
NO TEXT
The guy calls me a hippy like I'm some commie fruitcake and doesn't see that what's killing me is watching bad business practice perpetuated by horrible management. I'm glad someone recognizes that scrapping everything and just switching everything to microsoft is not automatically the equivalent of a wise business decision.
the same tired repudiated themes Lunatix like to listen to
Please don't be rude. You know damn well it's spelled "Linatux."
Yeah, IE is ridiculously slow sometimes, like right now as I'm trying to load this site... oh wait, that's just because the server is engulfed in flames.
Here's a tcpdump for www.microsoft.com, on an XP box:
03:47:16.259661 10.0.0.52.1328 > www.us.microsoft.com.http: S 2485226999:2485226 999(0) win 16384 (DF)
03:47:16.279661 www.us.microsoft.com.http > 10.0.0.52.1328: S 631604626:63160462 6(0) ack 2485227000 win 65535 (DF)
03:47:16.289661 10.0.0.52.1328 > www.us.microsoft.com.http: . ack 1 win 17520 (D F)
03:47:16.289661 10.0.0.52.1328 > www.us.microsoft.com.http: P 1:398(397) ack 1 w in 17520 (DF)
03:47:16.339661 www.us.microsoft.com.http > 10.0.0.52.1328: . ack 398 win 65139
And here's for www.msn.com:
03:50:22.169661 10.0.0.52.1397 > www.msn.com.http: S 2535664221:2535664221(0) wi n 16384 (DF)
03:50:22.199661 www.msn.com.http > 10.0.0.52.1397: S 3601141750:3601141750(0) ac k 2535664222 win 65535 (DF)
03:50:22.209661 10.0.0.52.1397 > www.msn.com.http: . ack 1 win 17520 (DF) 03:50:22.209661 10.0.0.52.1397 > www.msn.com.http: P 1:391(390) ack 1 win 17520 (DF)
03:50:22.269661 www.msn.com.http > 10.0.0.52.1397: . 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!
eat shit little doggy
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.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
..not to mention the Bush economic "stimulus" package:
1. Cut taxes on the wealthy
2. ?
3. Economy magically rebounds!
I'm a 2000 man.
Hmmmm...
1.) Go to www.dictionary.com and input query 'troglodytic'.
2.) Read definition: "A person considered to be reclusive, reactionary, out of date, or brutish"
3.) Be outraged.
4.) ???
5.) PROFIT!
Everyone catch their breath from MS bashing and think for a second. There's no way IE is using some custom TCP layer, and there's no way it could get away with not sending SYN's.
I've seen plenty of packet traces with several versions of IE and everthing is perfectly legal TCP-wise. I'm guessing the author of the blog just caught part of a sequence that had used a persisent connection that had been closed. In fact, if the client didn't get the RST on that connection, it sounds more like a server issue.
postin as anonymous cause I don't want the flames, but we need a module in slash called cachedot. That would automatically cache the site to the news site in some sort of compressed form. (Whole page as a 256 color jpeg?) Which could be then launched from within slash for stories on the headline page......I'm no coder, I'm just a network hardware weenie.....
what's trolly about the parents post? In my opinion it raises a very good point and could spawn an interesting discussion.
For all I know, what the post links to might contain the Answer to Life, the Universe, and Everything, and still leave plenty of room for enlightening discussion. But the parent's parent's post is just simply "Fuck slashdot". Hardly a very good point in and of itself, and certainly not worthy of interesting discussion (and I include my own post in this).
Perhaps if we moderated links, it might be worth a "+5 informative". But we don't, we moderate posts. You even specifically reference the post. And that was certainly a trolly one.
What the article describes is not httpd pipelining, it is below the http level, not a part of tcp/ip standards, and causes problems with IE talking to non IIS sites.
Sound possible Microsoft may have implemented RFC1644 which would produce similar results? (the request in one packet rather than way for SYN/ACK)
I'm sure he appreciates the $500 overage as well !
don't you think that slashdot knows how to avoid this problem ? The reason they persist in crashing peoples sites is because they can. That's what slashdot is about these days - criticize , condemn and crash. If these stupid site owners set up their servers the one right way they wouldn't have these problems. The real problem is all of these H1B monkeys using unapproved methods to host non-essential sites with worthless ideas.
It's spelled "IE" ... but it's pronounced "aiyee!" (the sound one makes upon seeing a nightmarish monster).
-kgj
So MS works things so their stuff is quicker -
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!
Hell, even the complaints about slashdotting take more space than the article itself - Add to that that usually the article is pseudo-mirrored in the comments area anyway.
Who the fuck uses IE in this day and age? it's slow all the fucking time, get a real browser.
Its very buggy right now. My browser was far slower using that exact same fix. BTW it's not just a Chimera option, any Gecko based browser can use it.
I don't recommend it with Chimera, I was having lots of crashes and spinning beach balls. Unexplained rendering problems, some sites wouldn't render till the 3-4th try. You'll also notice lookup problems. All of this went away when I turned it off.
The Internet treats everything stupid like that as a network failure and routes around it.
There are hacks all through most Web, FTP etc servers to deal with stupid traffic from IE and/or Windows. For example, there's a standard SetEnvIf command for Apache's config to work around this exact problem with IE (which would otherwise work at connection-flooding the server, and if said server actually left those ports open like IE wanted it would be begging to be blind-spoofed).
If you complain, nothing gets done...
Got time? Spend some of it coding or testing
Yes, there is that, but even more annoying is he's helping the software drug trade along by handing out free samples. If `Microsoft is evil' then so is their software.
Got time? Spend some of it coding or testing
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.
Got time? Spend some of it coding or testing
IE and I are out to destroy the world since windows screws up everytime i used mozilla!
I'm guessing that it'd still work with the firewall, but it'd probably be a little slower.
I wonder what ISA does. I'd expect it to handle requests without the usual negotiation, but does it make similar requests itself? Does IIS also provide a web proxy? If so, what about that?
Persistent connections work through the HTTP protocol layer over standard TCP, this is a violation of a much lower TCP protocol layer instead.
Got time? Spend some of it coding or testing
go back and read this thread
basically, it isnt http1.1, it's a small hack to the TCP protocol that IE and IIS use to allow a short speed up in data transfer time
it's documented here: "Object Moved Error"
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"
it looked weird to see the M$IE icon on slashdot.
-------
Support Indy Music. Buy
There is no such thing as a competitor in Redmond.
paintball
I wish I had some mod points today - this is an informative post & deserves attention. Whether or not IE actually implements it, one explicit goal of the T/TCP RFC is to eliminate the initial handshake. (I say "whether or not" because I can't reconcile that some people are packet tracing and not seeing the described behavior... whole thing reeks of observation error on someone's part)
Meta-comments: Slashdot users should be as vigilant in exposing & preventing the dissemination of anti-MS FUD as they are of pro-MS FUD. People are always served better by knowing the truth *as well as* your opinion. Despite Slashdot's "news for nerds" tagline, it really isn't any more than an opinion site, basically the equivalent to talk radio news programs.
Before Slashdot can complete the jump to "trusted news" it will need to offer at least some mechanism for retracting wrong articles, among other journalism-integrity features. In true Slashdot tradition, I'm sure they'll be cleverly implemented via community metamoderation!
First of all, the article leaves out if the URL was visited previously in the browsing session, or it was a first visit to the URL. Secondly it Does NOT MENTION a specific test with IIS. The article says what IE's teardown sequence looks like, but does not cite a full trace of an IIS server. It is basically a bunch of speculation and conspiracy theory, or the authors were in a hurry. It definitely was NOT scientifically conducted.
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.
Whatever. Y'all seem to like it when *I* screw with TCP :-)
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
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.
I'm using Mozilla 1.2.1...
Look at all the happy creatures dancing on the lawn...
this doesn't hurt anyone. Why does it matter if they're smart enough to make my browser go faster? all of the sudden you find out why microsoft products are better than linux products and you call it cheating.
Wouldn't this process IE uses be broken by a stateful firewall running in front of the IIS server?
Ok, that last step is kind of extreme, and I in fact had to remove it because it broke Windows Update (which I consider a feature, not a bug, but whatever...).
Of course, why do you have Windows and IE users in your organization anyway? Simply beat them with a cluestick untill they switch to Linux and Netscape. Don't let someone who claims to be a master of reality tell you otherwise -- Linux is ready for the desktop.
By the way, you should be routing all your SMTP through a Sendmail (or postfix or whatever) relay, especially if you run Exchange. This keeps your incoming mail queued up when Exchange crashes. It also prevents Exchange from talking to other Exchange servers -- or to script kiddies.
Tired of FB/Google censorship? Visit UNCENSORED!
And don't patronize anything served by IIS. Your collective bullshit wailing and gnashing of teeth does nothing. Put up or shut up. If you don't like it, walk. Shit or get off the pot.
...noone got the Ghostbusters quote:
Doctor Peter Venkman: This city is about to face a disaster of biblical proportions.
Mayor: What do you mean, "biblical?"
Doctor Raymond Stantz: We mean real wrath-of-God type stuff. Plagues, darkness--
Winston Zeddemore: The dead rising from the grave!
Doctor Egon Spengler: Forty years of darkness! Earthquakes, volcanoes--
Doctor Peter Venkman: Riots in the streets, dogs and cats living together, mass hysteria!
I don't have a TV now, but that's ok. The shows in my mind are almost ALWAYS better...
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. 192.168.194.211 is the Windows XP client. 192.168.194.1 is the nameserver, and 66.218.71.83 is the web server (www.yahoo.com).
First, XP asks the nameserver for the IP number of www.yahoo.com
15:19:50.426473 192.168.194.211.1026 > 192.168.194.1.domain: 2+ A? www.yahoo.com. (31)
The nameserver responds
15:19:50.702603 192.168.194.1.domain > 192.168.194.211.1026: 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 192.168.194.211.1032 > 66.218.71.83.http: S 3861657940:3861657940(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
Yahoo responds with a normal SYN
15:19:50.797377 66.218.71.83.http > 192.168.194.211.1032: 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 192.168.194.211.1032 > 66.218.71.83.http: . ack 1 win 17520 (DF)
XP/MSIE sends the HTTP request (196 bytes)
15:19:50.809064 192.168.194.211.1032 > 66.218.71.83.http: P 1:197(196) ack 1 win 17520 (DF)
Yahoo responds with the first 1460 bytes of data
15:19:50.907564 66.218.71.83.http > 192.168.194.211.1032: . 1:1461(1460) ack 197 win 65535 (DF)
XP/MSIE acks it
15:19:50.919180 192.168.194.211.1032 > 66.218.71.83.http: . ack 2921 win 17520 (DF)
Yahoo responds with another 1460 bytes
15:19:50.923751 66.218.71.83.http > 192.168.194.211.1032: . 2921:4381(1460) ack 197 win 65535 (DF)
XP/MSIE acks it
15:19:50.941174 192.168.194.211.1032 > 66.218.71.83.http: . ack 4381 win 17520 (DF)
Yahoo responds with two more packets
15:19:50.999791 66.218.71.83.http > 192.168.194.211.1032: . 4381:5841(1460) ack 197 win 65535 (DF)
15:19:51.007961 66.218.71.83.http > 192.168.194.211.1032: . 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 192.168.194.211.1032 > 66.218.71.83.http: . 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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
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.
Cool! Amazing Toys.
but you got BEST POST!
Good idea! I have mod points!
F1rzt p0zt b1ch3zz!!!
Is there anyone out there who really expected their *handshake* to mean something?
People were quick to forgive Netscape, but not so quick to forgive MS. I hate MS as much as the next guy, but all this umbrage is amusing when related to days past.
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.
lynx only has to cache the text of the entire web, so it doesn't have to swap as much ;-)
38486 has no chance of happening, so why waste a vote on it? It would most likely just make Mozilla seem more bloated and Moz gets enough flack for that as it is.
More lame excuses
Please subscribe this to the Apache Wishlist. We want this on the featurelist. Like something in the config
IE-boost_on = true
just to make them swallow their own weapons. Once we dominate the server market...ugh? we do?? err forget about...honestly, this just plain sucks if it's true, i'm really upset...i don't know what to post.
Lispy
Anyhow, I noticed before at work, we had an NT4 box running IIS in the office (don't ask) ... when I setup my linux box with iptables, I saw alot of weird traffic coming from it ... I don't know if this is related but I ended up denying everything but port 80 traffic. I think the statefulness of my firewall did not like it's playing games either... perhaps its not only on the client side?
FLR
very interesting...
and naughty...
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:
...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!
Client Server 1.
So what your complaining about is that Microsoft being ingenious is wrong.
apache.c:
if (browser = msie)
{
sleep(10);
}
I think you've hit the nail on the head. This isn't a big conspiracy, it's a clever trick to eke a little more performance out of the server. There aren't any serious breakages here; the browser just leaves the connection half open for future use. The server can time the connection out if it needs to, or just zap it if the socket tables get full. I don't think it's even illegal at the TCP level; TCP doesn't say that you _have_ to close any given connection.
I've done network benchmarking work in the past; the overhead imposed on a server that doesn't understand this trick should be pretty minimal. You can open a heck of a lot of sockets before it starts clogging things up, especially on any reasonably configured server. There won't be any entries in the various timeout queues because all the data will have been acknowledged; the only entry will be in the socket table, and maybe one entry in a FIN wait queue somewhere.
There isn't a reliability hit here either; the protocol is still doing ACKs.
Everyone is posting like they understand the issue, but we're taking the article's word that this is actually how IE/IIS work!
I am also one of those unfortunate souls without an IIS machine handy (last system I "added" it to for a test, I had to rebuild because of it). However, I'm reluctant to believe stuff like this without seeing it myself.
Sorry, years in the support department of a network monitoring company make me leery of other people's packet analyses.
I'm sorry, but this person must not know how to perform a network trace.
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)
Sometimes, when I enter a URL in OS X in IE, the first time I try it 404s but when I press return a second time it connects. Now I understand...and hate Microsoft more than ever for their flaunting of the standards that bring us all together. Orwellian for sure. Big Brother Bill.
Didn't L)pht already cover thsi awhile ago..I think 2 year ago in one of their "research" articles?
Don't Tread on OpenSource
I wonder what maxed-out karma /. accounts are going for on e-bay? Move over, EQ/AC/UO! /. accounts for sale!
Yeah, yeah; off-topic. I think it goes without saying that MS needs a good thrashing about the face and neck over crap like this. Worst part is, if someone writes a server that follows network specs 100% and takes no crap from non-compliant (read: MS) clients, causing them to fail to connect to said server, then would Microsoft have succeeded in their quest to "embrace and extend"?
The question is, who will stop them? How many kludges are already in server programs like Apache that had to be put in to cope with Microsoft's shenanigans?
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
Look at another recent slashdot thread here:4 /183522 2. jpg
http://slashdot.org/article.pl?sid=03/01/0
Specifically, look at one of their slides here:
http://www.fys.ku.dk/~nvj/ms-gpl/img_0222r
at the bottom it reads:
"Open Standards have become a point of confusion".
Does one need to add anything?!
In case you were wondering, that was nearly six years ago. Which is a few more than a "couple" (two, last I checked, or is your state doing three-way marriages now?)
This looks like a very scientific and well backed up study if ever I saw one.
You've convinced me to change browser.
I've had problems when I was looking after apache servers with MSIE on Mac's. Just try explaining to my boss (a mac user) that there isn't anything wrong with the servers.
F -8 &oe=utf-8&threadm=sanderSPAM-AF0862.00112018082002 %40netnews.attbi.com&rnum=7&prev=/groups%3Fq%3Dmsi e%2Bssl%2Bmac%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe% 3Dutf-8%26selm%3DsanderSPAM-AF0862.00112018082002% 2540netnews.attbi.com%26rnum%3D7
For some more info check out
http://groups.google.com/groups?hl=en&lr=&ie=UT
From your own cut-n-paste:
This is a TCP-level hack that violates the spec. It has nothing to do with HTTP, and could be done with any TCP-based protocol.
I see several posts here claiming attempts to duplication have failed...
Is the original article B.S.?
If it won't follow the standard. If I make an http client that sends "TEG index.html HTTP/0.9" instead of "GET index.html HTTP/0.9" can I bitch when IIS and Apache don't support it?
As a summer job I had to make a Java applet that would let the user design a sign, preview it, then order it by sending an email through a M$ outlook ESMTP server. I won't go into the specifics, but I will say that it violated several parts of the ESMTP spec. It was lenient in some areas and strictly adhering to its mistake in other areas.
I won't go into how IIS had to be reinstalled weekly or how M$'s VM was too horridly incompliant with Swing(needed for advanced font crap) for compatibility to be a possibility without writing my own windowing toolkit!
Consider this a rant if you wish, but please realize that I dealt with too much bullshit from that monopoly to keep my mouth shut and stay in their crooked little line.
You can't judge a book by the way it wears its hair.
Sounds like it's time to modify Apache so that clients are forced into proper behavior. What could MS do since Apache has a what 65% market share, or something like that. Open source guys need to get tough on MS and quit trying to accomodate them, i.e. Mono, etc.
---- Go ahead, mod me down, I'll just post it again and you lose your mod points.
+1 Obscure!
Right. Keep Alive is a standard aspect of HTTP. This nonsense is being done on the TCP/IP level.
Dyolf Knip
Whoever wrote this and his 'team' are tards. What they were seeing was a keep-alive (persistent) connection, or a persistent connection...it'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 blah.com, 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
Translate it. Is any use of the word "black" now considered racist?
Yeah, I know, I've been trolled ...
One simple rule for its versus it's
If your going to simply cut'n'paste for karma, you could at least give credit to the source
---
Silence is consent.
This is nothing but a big pile of BS.
/.
1)It wouldn't work.
NATs would be screwed up. Proxies would be screwed up. All kinds of things break.
2)Its impractical. MS is not going to rewrite their TCP stack just for IE. IE uses winsock just like everything else does.
3)It's not even signifcant. Opening up a connection doesn't take very long. Besides, connections can be left open until they aren't needed anymore (which is probably what this guy was seeing).
Conclusion: Should never have made it to
----
All of whose base are belong to the what-now?
You're one of those cocksucking faggots with a shitty system and 32MB RAM who tries to run 300 apps at once, aren't you? Turn off all that shitty skinning and close at least a dozen of those im clients in your taskbar.
Now now, no need to get upset. Just stop being so gay.
I don't think the explanation given in the article is correct because it doesn't account for session management or transmission sequencing. Without some creative playing with load/connection distribution logic you can't maintain a single connection across multiple paths and multiple destinations, and even if you could the TCP sequence numbers are going to be totally out of whack, which should cause a reset anyway.
Unless that is the stack is poorly writeen... Which is of course the case, but I don't know if its poorly wroitten in that specific way.
Plus most any real firewall or proxy server would vomit on seeing the malformed http request from a client (at either end). It would completley screw up any stateful inspection firewall, and wouldn't work with a proxy anyway snese the proxy would undoubtedly make a fully qualified connection to the web server, with preamble etc...
That being said, it is entirely possible that the backend (presentation and application layer) logic and buffers within the httpd arent being reset. In fact that would make sense, and arguably would be a case of good programming practice for efficient resource mangement, which has never really been a priority at MS (actually not completely true but ever since they decided to compromise the HAL for NT3.51 it has been)
The eyes may be the windows on the soul But the word is the doorway to the mind
1. Cut taxes on the wealthy
2. pretend to serve justice to corporate criminals
2.1 bomb various brown peoples
2.2 form secret police
2.3 create all-knowing govt data warehouse
2.4 detain low wage immigrants
2.5 slash interest rates
2.6 wait x years
3. Economy magically rebounds!
Exactly. The difference between rendering a page in 0.5 seconds and rendering it in 0.3 seconds is irrelevant. But things like Ctrl+Shift+Click (open in background), the way the cursor jumps to the address bar when you hit Ctrl+N, searching for selected text on the net directly from the context menu, zooming in on pages, etc., are things I find really hard to live without.
Unfortunately, while Opera 7 (beta) has much better support for dynamic HTML / CSS / DOM (nearly as good as Mozilla), the interface is still nowhere near as polished as Opera 6's.
RMN
~~~
I was talking about this earlier... When did Music TV become a haven for staged reality, sensationalism, pandering, and muck? I don't know, however, I may have just grown up...
Doh!!!
I would like to see someone confirm this article with a packet log of their own (or perhaps a follow-up from the original blogger indicating that they had ruled out HTTP keep-alives) before I believe it.
--
Do I look like I speak for my employer?
The idea that the server would leave the connection open for someone else to come along and pick it up makes no sense.
Sockets are an address/port pairing. You can't have someone with a completely different ip address just pick up where someone else left off. That makes no sense at all, and that isn't even getting into the sequence number problems.
Sounds to me like this author misread his packet dumps.
You really don't want to do that. HTTP over UDP is simply a bad idea... Why? In order to meet the most basic needs of a stream reliant protocol (ala HTTP) you need a few things:
1. Reordering (No guarantee packets arrive in order)
2. Retransmiting (Detect lost packets and resend)
3. Speed throttling (Packets go too fast -> router interface buffers overflow -> packet dropped)
It is of course possible to write a protocol on top of UDP to do these things, but thankfully we don't have to as someone did the work for us... it is called TCP.
I suppose if you wanted to use a HTTP/UDP mechanism for very short communication only (read: one request packet, one reply packet) then those issues aren't relevant, but otherwise leave the heavy lifting to TCP or other stream based IP protocols.
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.
Dr. Demento On The 'Net!
And people wonder why Microsoft wins all the time. It is because of these morons all over the place. There are even idiots who accuse Microsoft for doing something legitimately. That means that the very same people don't know the spec themselves and thus they can not even write a spec compliant software.
Read some of the other comments, especially the ones in response to other comments like yours.
Whether or not this is true, it is *not* HTTP pipelining, keep-alive or any other *HTTP* level method of persistent connections. When the server times out and closes the connection, IE doesn't do the same. If it needs the same site again it just sends the request on its still open socket. If the server is IIS, it will reopen it's side (somehow) and return the requested page, instead of sending a reset like it should. I don't know if IE and IIS actually do this or not but *that* was what the article was talking about. It's a TCP level hack.
If you're going to whore, at least make sure it is relevant.
Comment removed based on user account deletion
Comment removed based on user account deletion
Does this go both ways? I don't use IE, but I've noticed that sometimes I can't seem to get NS loose from some servers (the connexion stays open until NS has been shut down for several minutes).
~REZ~ #43301. Who'd fake being me anyway?
That's right, who cares if it violates standards to do so? I run Windows! All bow before me! Fuck the rest of you that don't run Windows!
I run stop signs--it gets me to work quicker! Who cares if I break the law--as long as I get there!
The difference is that with running stop signs, the community has recognized issues with the behavior, and goes out of its way to increase the cost of this behavior (police cars, fines, tickets, license revocations).
This hasn't happened with MS deliberately violating standards (not sure they were in this case, though it's definitely happened in the past). The problem is that because so many people use IE, simply blocking IE from downloading pages from your server usually doesn't work very well.
A better solution is to give perks to the other people. Not infrequently, Linux versions of software are less expensive or free (I was just using icc the other day, for example). Instead of trying a zero-tolerance policy, it's better to give people little perks for engaging in the behavior you like.Regulating IE Use.
May we never see th
i recall strategies of "taking shortcuts" being quite prominent in the Linux community. The whole rationale being that it still "works", so why's it bad?
Last summer I was using IE's FTP client. I had "do not save password" enabled, yet even after rebooting, IE automatically entered the password when reconnecting. I was running the lastest version of IE available through Windows Update (probably 6.x).
Which probably means that on the machines of IE FTP users have a bunch of their passwords sitting around somewhere.
May we never see th
What software are people using to get the TCP/IP dumps I've seen in this story? It doesn't look like netstat but I could be wrong.
I don't read The Register very much, but I wasn't aware that they didn't have a good reputation. This true?
May we never see th
Method A - what TCP session? Just send the request!
Method B - initiate TCP handshake and begin legitimate conversation.
So what you're saying is that since method A is going to fail if attempted through a stateful firewall, Every corporate customer of Microsoft has to wait until method A fails for every single outbound web connection, regardless of the server, so that joe sixpack with a modem will think M$ is the shit.Unless of course, you don't run a firewall. Trustworthy computing, anyone?
I wonder if the mindless millions of corporate tools who've standardized on IIS/IE have any concept of this.
Mark this down on the calanders everyone...
Karma whorin' since 1999
Except that, with "legal" keepalives, you tell the server that you want the connection kept alive, via "Connection: KeepAlive" or something like that in the HTTP header.
It has nothing to do with TCP/IP. This article, however is about TCP/IP, more specifically Microsoft's playing fast and loose with the TCP/IP standards.
Try it yourself -- use windump (tcpdump for Windows) to capture the packet trace.
Report back, share the news. I don't think there is a real "request" packet as mentioned in the blog article, but would sure like to see it. If there is such a packet, perhaps it's Transactional TCP (RFC1644).
It is preposterous to apologize for an organization that unleashes a DoS attack on several servers every freakin' day.
By putting content on the WWW, you are explicitly allowing others to visit your site.
By having an email address you are explicitly allowing others to spam you with penis extension and make.money.fast schemes. Right?
Not everyone has bandwidth that is metered.
Not everyone has unlimited free bandwidth. In fact, I'd wager that such sites don't even exist, excepting maybe www.quest.com and the like.
And don't nobody bring up the red herring about 'legal issues with mirroring.' If you offer to mirror, and they agree, there are no legal issues. If you offer, and they content owners declines the offer, then you don't mirror and there are no legal issues. Bottom line: there are no legal issues with mirroring.
In the latter case, nothing changes. In the former case, /. readers would actually be able to see what /. links to, without waiting a couple days for the stampede to pass. Imagine that! Slashdot, but with readable content in every link. Slashdot readers would have a better exerience, site operatores would have fewer DoS attacks, and everybody would be happy.
Well, everyone but the slashdot people, of course... they'd have to (gasp!) ask permission to mirror and maybe actually (egads!) mirror a few pages before posting some of their stories. Oh, that extra work would be un-freaking-bearable.
So, DoS it is!
Build stuff. Stuff that walks, stuff that rolls, whatever.
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.
Errrr wrong! Read section 8.1 RFC 2616 (HTTP/1.1 spec).
Connection: KeepAlive is a HTTP/1.0 addition. In HTTP/1.1 all compliant servers as well as clients are supposed to assume persistent connections. If either the client or the server does not support or want persistent connections it should send "Connection: close" instead. So if what IE is doing is a persistent connection, then it is not violating any specifications at least not RFC 2616. BTW, KDE's http handler also supports persistent connection by default.
Regards,
Dawit A.
If a programmer comes up with a good working solution to a problem, even if it bends the RFC = smart programmer!
If this this programmer works at Microsoft = SCANDAL!!!
You anti-Microsoft jerks are the most selfish lot I have ever met!
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.
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. [...]
I'm confused now, does all this mean that IE sucks and I should now use anythingexceptmicrosoft browser?
--
Geeks farting around with software/creating code are NOT engineers, let's stop this fallacy before it corrupts everything. Oops, too late.
As in reproducible.
This is yet another fine example of how Microsoft utilizes its position, only to hurt the market. Well, at least it seems so. Never the less they have slowed down roughly fifty percent of the internet. Nice job too coupled with the shoddy way the network itself is becoming. I think this one is going to bite them in the ass. Not only do they open themselves up to legal confrontation, but when the users hear of this what will they do?
I myself use windows typically (due to software issues, office) for the workstation. Internet Explorer is a convenient application, not to mention various compatibility issues with how information is rendered. Never the less, I'll have to nip that one right in the bud. Anyone who wants a truly faster connection will be doing the same. Its good that there are still several options beyond the obvious one.
I always get annoyed at how slow IE feels when I have to use it. Mozilla seems to load pages (in both XP and Linux) quite a bit faster than IE does. I haven't taken speed metrics or anything.. it just feels faster. I do use a proxy server so possibly Mozilla deals with the proxy server better than IE does.
The proxy seriously speeds up web traffic to my LAN though and reduces bandwidth usage. I use Squid on my remote server and a proxy of my own design on my LAN (that talks to Squid on the remote) and half a dozen users on the LAN can comfortably web browse over a dial-up. Bandwidth usage with multiple people browsing is usually still low enough to use ssh to a remote server comfortably.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
...because if you're IIS server is maxing out on connections, chances are you'll have to add another one; and another IIS licensce at several hundred a pop :).
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
This at least requires a client to have raw socket access in my opinion. If it is supposed to setup a connection without the normal syn startup (as i read the article) it needs some direct raw ip access. This allows a lot of spoofing from windows boxed that are "rooted:"
Want to know more about raw socket access, ask gibson about that.
Gun's don't kill people - people kill people, and people with guns kill more people - you forgot that last bit, and it's important.
:-)
I agree - there should be an onus on individual responsibility - but there is also room for corporate responsibility too - you're sitting on one extreme end of the argument criticising the other extreme end of the argument - both are nonsensical.
Move to the middle ground and make a bit more sense.
In regards to the website linking - use your common sense. If people out there put up their hobbyist web sites for their buddies they don't really expect to be linked on Slashdot - the slashdot editors are well-aware any stories kill whatever server they link to, so you would think this techno-oriented community which has much experience designing and testing systems would be well-aware that this organic system/community needs to find a better solution to display content to their readers so we can all stop clicking on dead links and killing the little guys web servers. It's just a matter of common sense and courtesy.
Thanks for the troll tho
phoenix = absolute best browser.. try it
Would this be the De-Commoditization talked about in the first Halloween document? I mean, with 95% of the browser-market, they can monopolize the server-market with these tricks. Hello judge...?
Aside the technical stuff, it just seems to me that bashing Microsoft could be used to attract visitors to political sites. I just wish Slashdot didn't post this link at all.
from http://www.dict.org/bin/Dict?Form=Dict2&Database=
From WordNet (r) 1.7
protocol
n 1: (computer science) rules determining the format and transmission of data [syn: communications protocol]
2: forms of ceremony and etiquette observed by diplomats and heads of state
3: code of correct conduct: "safety protocols"; "academic protocol"
This has nothing to do with antitrust cases or any other legal action whatsoever. It is simply a case of Microsoft trying their best to improve their customers' web surfing a little bit provided that the server admin runs IIS. Sure they are bending the rules a bit but hey, they are in a position which allows them to do it and IE users are the majority anyway. What I think should be done is to add a similar behavior pattern to Apache and whatever other web servers you might be using. If some RFC disallows this, then another RFC should be written to allow it.
The secret to a successful
...Banged my head on the wall until I found the solution you mention was suggested on the Apache site. They claim it's only a problem in a beta of MSIE but I've seen it in all recent versions up to 6.
And here's the page!
-- thinkyhead software and media
Put Iraq on the back burner (figuratively, rather than literally!), and sort out this mess once and for all!
Put the UN (including Arab states) in to keep the peace whilst the solution is resolved, and hopefully, whilst they are not killing each other, the tempers can be cooled down to a point where they can be rational enough to agree to some resolution.
Eclectic beats from Leeds, UK
handmadehands.co.uk
Just out of interest does IE on Solaris exibit the same behavoir?
MySQL gains performance by completely ignoring ANSI SQL-92. NEXT!
Hands up!! It's been a long time I laughed so much until I read your post!
To be honest, thinking of Balmer's shitface makes it impossible for me to bone anything. Ever checked the pics of the M$ executives at the M$ presspass site? It's a shame uglyfaces.com ran out of money, I 've once had the idea of submitting some pics from that site...
"Karma: Bad (mostly affected by moderation done to your comments)" Mods@/. != geek?
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.
If the story is correct, then an IE client behind a NAT firewall will always be slow, because the first packet will get lost (NAT uses the SYNs to establish NAT connections).
Can someone test this experimentally? (I'm not in a position to..)
The majority of the Supreme Court, that is.
You gotta admit, this is a pretty smart trick. MS has a lot of intellogent people in there making things quicker and better.
This sort of trick is one that would be cool to see in all browsers, provided that IIS will accept the same trickery from a non-MS browser....
The price we pay for immortality... is death. Narnia The Great Fall
How does this interact with stateful firewalls. As the connection in the beginning isn't done, the firewall doesn't allow the connection and just drops your request. So shouldn't in this case every IE behind a firewall be slower than without firewall. Don't have any window-computer here, so can't test. But this seems to make IE slower behind a firewall than other browsers. Or don't I understand firewalls correct?
cu
--== Jerri ==--
Homepage: http://www.jerri.de/
Now make Apatchi handle IE connections accordingly and operate normally otherwise thus granting a universal improvement vs the IE only improvement.
Also add this to mosaic or ISS connections only.
If this works so well why not draft a http2? Then as Microsoft fails to implement it the rest of us can have this support.
Obligitory MS slam via reality check:
I can see if other web browsers pulled this stunt web masters would just block them to avoid a DOS type glut of expired connections.
I don't actually exist.
Someone mod this up? This is pretty interesting! (They might just be incompetent at playing by common rules :)
Not Buzzword 2.0 compliant. Please speak english.
No, this happened on April 1st too
McCartney fans pay bus tickets. [...] Lennon fans too, with discretion.
When we rolled out IE6, we started getting an annoying "Work OFfline?" message sometimes when going to an certain oft-visited https site through a (Solaris) proxy. The site in question was doing some rapid redirects. A tcpdump trace showed that IE6 was skipping the ACK, and Solaris didn't know what to do, and then IE figured that the client must be offline!
Had to bypass the proxy for that site to work around the problem.
In /. we /. you!
MSIE i opresume MSIE means ms ie, if it works dont fix it, unless yer talkin bout animals, ms should refuine, rerfine, refine XP
Picking nits...
You are right that HTTP persistent connections are an application-layer construct. However, HTTP/1.1 uses no headers to signal use of persistent connections; if the request is "HTTP/1.1" then the default is to treat the connection as persistent. Connection: close signals deviation from that default behavior.
The "Keep-Alive" header was a hack to wedge persistent connections into HTTP/1.0; its use by HTTP/1.1 clients is frowned upon (see RFC2068 section 19.7.1 MUST NOT, and RFC2616 section 19.6.2 which references the above).
If I'm reading things correctly, I see three neat things about this protocol extension, which I will call, for the sake of argument, BILL.
1: Both the client (IE) and the server (IIS) can fall back to standard HTTP if the other side isn't BILL compliant.
2: The change is trivial in that it isn't very secret. Therefore, developers can make their own BILL-compliant servers and clients (or simply strap BILL onto their current open-source servers and clients).
3: BILL/HTTP impedance mismatches aren't causing a huge screw-up, especially if the the server sends a complaint packet about the first request packet.
Given the above, the HTTP developers can respond to "Embrace, Extend, and Extinguish" with a simple Embrace. If I read it correctly, the Web would be faster as a whole that way.
While I'm annoyed that MS didn't publish this (or did they?) I'm actually glad they did this.
--The basis of all love is respect
From a later article on the linked site:
It seems I've been Slashdotted. [...] I've got to stop posting things that people on Slashdot might find interesting
ROFL! "Find something that no Slashdot reader will find interesting" seems like a Zen koan one could meditate on for weeks.
Gentlemen! You can't fight in here, this is the War Room!
A month or so ago I noticed that my dual 550 linux box could surf faster than my 1.5Ghz AMD W2k box. Instead of being a linux zelot and claiming that linux was _WAY_ faster I looked into why IE was being so slow.
The reason turned out to be a 200+ meg IE disk cache that was full of 1k files. Everytime I went to load a new page it checked for cached items. Even with the directory structure cached, a page with 50+ images apparently was linearly scanning the directory structure 50+ times looking for a matching filename. Deleting the IE cache data, and lowering the cache size to something like 5 megs, was like someone unhooked a 2 ton trailer from my little sports car. It was truely amazing.
BTW: I also know how to add new zones to IE, so if anyone is interrested just ask I will provide the URL or details.
I thought that was 'over' to indicate end of message and 'roger' to acknowledge receipt; hence 'over and out' to close your message and the conversation in one shot, and 'roger, wilco' to indicate acceptance of instructions (IIRC 'wilco' is a contraction of 'will comply').
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
Comment removed based on user account deletion
Intended: this guy is an idiot
Apparent: I am an idiot
Or lets try this...
Intended: I am a well-educated person who just set you straight on your mistake
Apparent: I am a pedantic idiot who thinks I can correct people to look smart - but I am tragically mistaken on both points
Right, it would only work for one packet each way, which would be fine for images, HEAD requests, and so forth. A lot of what HTTP does doesn't rely of streams. If you need to know whether your packet arrived (e.g., a POST), you must use TCP. If a response doesn't arrive, you should use TCP (UDP might not be supported by the server, or the network is dropping packets).
So HTTP/UDP would be useful for cases where order doesn't matter, duplicates don't matter, and retransmission is simple (I still don't have anything for this URL, better ask again, maybe trying TCP).
Leave the heavy lifting to TCP, but if there's anything that's not heavy lifting, it's most of HTTP.
You're an idiot.
... faster BogoMIPS calculations (yes, it now boots 2 seconds faster than
it used to: we're considering changing the name from "Linux" to "InstaBOOT"
-- Linus, in the announcement for 1.3.26
- this post brought to you by the Automated Last Post Generator...