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
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.
...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.
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
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
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
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
~~~
Absolutely, agreed, hallel.. oops..
I just upp'ed from a 200 mhz that I used to do the recording in my studio, limited video editing.. major graphics.. but I still had to use IE in order to get any kind of desirable surfing. Especially if someone is over my shoulder.
Noooow I have an athlon 2100xp with 1 gig ddr for my MASSIVE dvd video editing, 24 channel recording studio, chat, wi-fi porn war dialing, and MOZZILLA (in the shape of Phex) with an absolute feeling of euphoria every surfing experience. My slashdot time has doubled. Think about my porn hours.
IE has lost the game once mom and pop upgrade to modern machines.
bye bye
pm
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
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'?
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
And you post this on Slashdot? As an AC? Talk about irony..
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
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?
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 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.
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!
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
"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.
Go figure... my IE isn't coming with anything when I hit the above link.
In other words, slashdot editors are no better than spammers. They both effectively steal bandwidth. When will this change? Taco needs to act now!
.-.--
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
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.
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.
Speaks pretty poorly of the server (or network architecture) if your only recourse is to say "it's the client's fault!"
..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.
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?
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
This is more than just a persistant connections. What IE is doing is sending the request for the page *before* any sending SYN or ACK packets that every TCP/IP application is supposed to send. Only Microsoft's own IIS server responds to these requests, so connections to any site using Apache (more than 50% according to Netcraft) or another server will result in one extra useless packet at the start, before IE realises it isn't talking to an IIS server and goes back to obeying standard TCP/IP rules. This is what causes some sites (ones using IIS) to load incredibly fast in IE, and some sites (ones using other server software) to take a lot longer than they should.
jasp
My worthless opinion:
1. Slashdot is not a hosting site so they shouldn't offer to mirror. /.-ed you just need to spend 2 seconds reading the comments.
2. They have no way of knowing if a site can't handle the load.
3. Waiting for a mirror to appear would make news show up incredibly slow.
4. The community automatically mirrors or pastes content that has been
5. The guy with the Lego site is probably tickled pink that his site just got a billion hits and probably doesn't mind things crawling to a halt for a while. It's his 15 minutes of internet fame.
FWIW...
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
So what you're saying is that MSIE is responsible for a lot of the /. effect? It seems that all of those windows-using /. readers might think once or twice about their OR or browser if they know that they're ruining the Internet for everyone else.
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 ;)
Yeah, and you have no sense of humour, Einstein!
As the owner and operator of a small commercial web hosting outfit I wholeheatedly agree. Just two days ago one of my clients' sites got slashdotted.
/. traffic accounts for less than 1% of my servers' total traffic, it just happens to happen over a short period of time. It is not economical for me to have 99% idle bandwidth for the 0.01% of the time that it is needed. Also, you trolls aren't paying for it, I am.
It is extremely annoying to see posts about poor server configuration from the losers who post here. The server is seldom the issue, the bandwidth is. My server gets slashdotted about once a month and every time the server load is nominal, yet my two T1s get crushed. Of course I surcharge my clients responsible for this as it creates problems for the rest of my clients.
Some responsible behavior on the part of Slashdot editors/administrators is in order. It doesn't take a genius to figure out which sites may survive a slashdotting and which may not. When in doubt, ask.
As for the trolls that whine like little bitches about lack of bandwidth,
I think that the appropriate place for your review of various "borwsers" is maybe in your journal. It's completely unrelated to this discussion.
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"
Wow. So instead of moving my mouse "up" to the tabs, I instead move it "down" to the taskbar? or even have to press TWO buttons at the same time? Whoa. That is serious. I can see where tabs in the browser can save several nanoseconds, while taking up valuable screen real estate. Impressive.
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.'"
... and /. is renowned for getting news to it's readers in a timely fashion, so this would be intolerable.
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.
2. They have no way of knowing if a site can't handle the load.
/.-ed you just need to spend 2 seconds reading the comments.
We have this remarkable thing called e-mail.
3. Waiting for a mirror to appear would make news show up incredibly slow.
Slow? Like Slashdot posting about the Lindows CEO days after it's been on CNN's front page? FAST!
4. The community automatically mirrors or pastes content that has been
They essentially steal the decision of whether or not a site wants its content reproduced on Slashdot, in an ad-hoc attempt at 'mirroring.'
5. The guy with the Lego site is probably tickled pink that his site just got a billion hits and probably doesn't mind things crawling to a halt for a while. It's his 15 minutes of internet fame.
People pay for bandwidth. Some of them would like Slashdot to ask permission first. Remember Doug Bagely's Shootout, you pompous, self-centered, delusional prick?
This can be adjusted/eliminatged with the following pref:
user_pref("nglayout.initialpaint.delay", 0);
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.
Well, Slashdot can devastate my site with traffic whenever they'd like.
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
Nice. As we all know, the real flamewars are best fought anonymously. As kirk would say 'double dumbass to you!', and recognize an obvious joke when you see it next time.
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!
There's "What's good for the next quarter?" business, and then there's "What's good for our business over the long haul?" business. Not considering the future won't keep it from happening.
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
Mozilla was changed recently to wait just 250ms before it starts to render a page. So the next release will feel a little bit faster because of this.
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
Does IE have a custom TCP layer in it?
You're kidding right? IE is not some stadn alone program. It has MANY links into low level microsoft stuff where it is 'part' of the WIndows OS. This was the whole arguement of M$'s lawyers, that IE couldn't be removed easily.
So it wouldnt' surprise me if IE had access to some special stack API to pull stuff like this. Would not surprise me at all.
Top Most Bizarre/Disturbing Error Messages
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).
NO TEXT
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.
2. They have no way of knowing if a site can't handle the load.
I'd agree with you there, if it weren't for the fact that it happens all the damn time, hence your fourth point.
It really wouldn't kill the editors to at least try to get in touch with the server admin; you know, display a little common sense and courtesy?
It's official. Most of you are morons.
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!
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.
It is preposterous to expect slashdot to be responsible for linking to someone else's site. By putting content on the WWW, you are explicitly allowing others to visit your site.
The site operators are the ones who are liable for their own content and their own bandwidth usage. If they don't want more than a certain number of people visiting their site, they should tweak their web server accordingly. Not everyone has bandwidth that is metered.
just my 2 cents.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
My worthless answer to your opinion:
.edu site that it probably cannot handle it (unless it's got a specific disclaimer saying something like 'Bring it on Slashdot!' ).
1. Slashdot is a hosting site in that I can create my own journal on it and they have free membership.
2. Common sense will tell you that if you aren't linking to a major, well known website or some sort of
3. Sorry if you have no patience, but if you're expecting someone else to find news for you then you're already adding what should be, to you, an intolerable delay and instead you should be out combing the web to find news long before it shows up on slashdot.
4. The community automatically STEALS the copyrighted information from these sites without requesting permission or even checking to see if there's any statement allowing reprinting of information. If you're one of those people who thinks 'information wants to be free' you just go ask your local judge whether copying a copyrighted work without permission is illegal or not and see what (s)he says.
5. The guy with the lego site might've been tickled pink. Or he might've been atomic red. At least userfriendly has a little banner that someone can use when they've been selected as a LOTD.
Slashdot is rude in selecting their targets. And I've had submissions rejected before only to see them appear a day later (I'm not bitching about that; I know there're various editors and factors concerning what links are chosen) so timeliness of news really isn't a good argument. While anyone with a geek nature wants to know things ASAP, this really wasn't a time sensitive thing. There was no reason to post this link without dropping a quick email to the site owner and attempting to defend slashdot's editors in this case is like trying to attack an elephant with a fly swatter. Either endeavour will not result in much success.
On IE:
1. Open In new Window
2. Window pops up
3. Switch back to old window until the new window is loaded
4. Later Switch to now window
On Mozilla:
1. Middle-click for opening in new tab
2. Later switch to new window
Understood?
Claus
And sometimes they get the news to us more than once in a timely fashion! It's great, like having instant replay on the news...
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.
-----
Score 3? For what? Being wrong, at length? - smirkleton
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
and /. is renowned for getting news to it's readers in a timely fashion, so this would be intolerable.
So timely infact that they have to post it again and again sometimes twice on the same day!
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
It is being set up properly. What happens is that the browser hasn't closed it's half of the connection. When the next request happens it tries a TCP write, but since the server side has closed the connection the write fails. That's what's confusing the blog author, they're not familiar with the TCP protocol. A TCP connection has two halves and it's entirely legal to close one half but not the other, leaving a socket that can be read from but not written to (or vice versa). IE doesn't check for the server-side close like it should, treats the socket as if it's writable (which it is) and writes to it. Since the server's closed the socket on it's end, that attempted write generates an RST (which is TCPly correct), the browser gets a write error and finally notices that it's connection has been closed by the remote end, closes everything down like it should have much earlier and builds a completely new socket.
You can get this same behavior between two Linux systems. The server side goes:
- socket(...)
- listen(...)
- accept(...)
- read(...)
- write(...)
- shutdown( SHUT_RDWR )
- close()
The client side goes:- socket(...)
- connect(...)
- write(...)
- read(...)
- write(...)
- Note error
- close(...)
- socket(...)
- connect(...)
In IE, steps 3 and 4 in the client handle one request. Step 5 is an attempt to handle the next request assuming that the server handles persistent connections. Step 6 is where IE notices that the server doesn't do persistent connections.The right thing to do would be to notice the HTTP version and lack of a Connection: header indicating support for persistent connections in the response and close the connection upon receipt of the response. IE is stupid in not handling non-persistent-connection servers as it should, but it's not violating or even bending the TCP protocol spec in any way. It's just stupid coding.
This is more than just a persistant connections. What IE is doing is sending the request for the page *before* any sending SYN or ACK packets that every TCP/IP application is supposed to send.
.. note: the connect request does not return until it has been acknowledged.
... where the WSAConnect call has data it will send with the connect packet inside it.
I think you'll find that the request is sent with the connection request, and is perfectly legal TCP/IP.
The thing is, BSD sockets doesn't let you easily do this.
Most Unix apps do this:
SOCKET s = socket(...);
s.connect(...);
s.send(...);
What IE is doing is this:
SOCKET s = socket(...);
WSAConnect(...);
This is ALL perfectly valid TCP. Remember; the flags in the packet are what determine how to handle the incoming packets; the data is handled separately. You can quite happily send data with your connect request, as long as you're willing to accept that the request may well fail.
Simon
Coming soon - pyrogyra
it's documented here: "Object Moved Error"
We have this remarkable thing called e-mail.
You might not always be able to find the right address, even if there is an address on the page it might not be the right person to ask about bandwidth.
People pay for bandwidth.
I'd avoid those ISPs where you have to pay for the amount of traffic. Signing a contract where you have to pay for something where the price is completely out of your control sounds like a bad idea to me.
Do you care about the security of your wireless mouse?
1. true.
2. well if it's say a geocities site, they have an idea, I'd say.
3. Been here very long? Dupes and old news IS Slashdot.
4. Can you trust a cut n paste?
5. Read the Kuro5hin article and you'll see that, yes people sometimes do like being Slashdotted.
Also I was once talking with a former MS Exchange developer. He said that since Exchange shipped separately from Windows, they were restricted to documented API's.
IIS and IE ship as part of Windows and so would not be subject to this limitation.
LedgerSMB: Open source Accounting/ERP
I'm surprised you fell for that, it's a really bad attempt at a troll.
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"
There is no such thing as a competitor in Redmond.
paintball
Retorts to some very silly arguments:
1. Slashdot is a hosting site in that I can create my own journal on it and they have free membership.
Irrelevant and immaterial. This has nothing to do with my comment that /. is not a hosting site, it is not.
2. Common sense will tell you that if you aren't linking to a major, well known website or some sort of .edu site that it probably cannot handle it
Then you should not post your content into the free and clear public domain where there are no controls to stop people from viewing it. It's Slashdot's fault if you post shit with no security and lots of people click on it???
3. Sorry if you have no patience, but if you're expecting someone else to find news for you then you're already adding what should be, to you, an intolerable delay and instead you should be out combing the web to find news long before it shows up on slashdot.If Slashdot didn't post current news then their competitor, Ampersand-tilde would. And ampersand-tilde would become the most travelled site on the internet and you would bitch at them for the ampersand-effect. Are you too dumb to realize this?
If you don't like Slashdot then don't read it and fer chrissake don't post in the messageboards. Do you genuinely think you're protesting Slashdot by hanging in their forums?
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.
(LinuxFromScratch) mozilla build howto:
Is that site slashdotted too? I cannot get to the page.
And BTW I think that security problem probably only applies to public accessible browsers. As long as you run the browser under your personal userID, I think there is no need to worry.
Do you care about the security of your wireless mouse?
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.
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!
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
So what you're saying is that it's the fault of Slashdot for their "criticize, condemn, and crash" strategy even though you then turn around and blame it on the "H1B monkeys"... Yes, it's the fault of all these immigrant monkeys, you hit the nail on the head. Has it ever occurred to you that these immigrant "monkeys" are stealing your jobs because you're a race of fat lazy shits, not because they're monkeys????????
Your correct! No, they are not the ones responsible.
Guns don't kill people - people kill people.
And tell me why I am a non-smoker when I've been exposed to all the same tobacco advertising and peer-pressure that everyone else has?
Because I am responsible for my own actions. Thats why.
Blaming tobacco companies for smoking and gun manufacturers for gun related violence is a wimpy escape for weak minded sheep who have no sense of personal accountability.
I suppose you also think that Mac Donalds is responsible for all the fat-assed Americans being so fat? And maybe the rope manufactueres are responsible for all the suicides commited by hanging ones self?
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
# HTML support
# URI parsing that's RFC-2396 compliant
# Cookies support, RFC-2965 compliant
# XHTML 1.0 rendering
# Plain text rendering
# Image formats support: PNG, JPEG and GIF (no animated GIFs)
# HTTP 1.x Compliance
RFC / W3C STANDARDSYou keep going until you die..."Me".
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.
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.
2. They have no way of knowing if a site can't handle the load.
/. grabs a copy of the linked sites nanoseconds before posting the story, just in case. /. starts substituing the mirror link for the next hour.
/. can honor the same robots.txt standard that keeps sites out of Google's mirror as well. Furthermore, /. can "whitelist" the freequently-linked commercial sites like CNN, Wired News, Washington Post, and etc. who should be big enough to handle things on their own, and therefore wouldn't want the mirror anyway.
Here's an easy to automate solution...
1.
2. Have a "report dead link" option next to new stories. (Those who abuse this feature can pay in karma.)
3. If too many users report the link as dead,
4. After time's up, the link reverts back to normal. If the complaint threshhold is reached again, the process repeats.
5. Once a link has survived 12 hours without need for the mirror, the mirror page can be deleted, because the worst is now over.
If anybody doesn't want that mirroring service,
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.
Ahhh, I get it now: "we can't remove IE from Windows, because then it wouldn't get all of its naughty speed hacks..."
Since when was there anyone else... that mattered? :)
Majority rules baby. Live with it or do something to change it.
2. Have a "report dead link" option next to new stories. (Those who abuse this feature can pay in karma.)
You could do even better.
Just before a story goes up, it would be easy to load-test the site. They could hit it with, say, 500 parallel requests.
If it passes that, then the story goes up as normal, but Slashdot checks the site every minute. If performance drops off substantially, then n% of Slashdot readers get a link to the mirror. If the site is stil slow, n is increased until the site is reachable.
Then, n is allowed to decay over time; if it goes too low, the automatic monitoring would bump it up again.
And then for dessert, we can write a peer-to-peer mirroring system, so that Slashdot doesn't have to pay out for the extra bandwidth.
Hmm... This sounds fun. If anybody has the connections to get this incorporated into the Slashcode used on Slashdot, let me know; I'd be glad to work on the monitoring, mirroring, and sharing stuff.
the best comment on that was the first one I saw, here
Search engines look at robots.txt, maybe a similar txt file could be placed that is meant for metanewssites or similar stuff. Let's call it mirror.txt and you put in there something like
temporary=yes
validity=2days
etc. That way smaller sites could indicate that they want to be mirrored to esape being slashdottet.
My plan was designed so that /. itself would never request the page more than once, and it would rely on the users to report a failure.
The problem is, 500 requests within a span of a few seconds can bring down some small servers, particularly if the page is dynamically generated. /. could be accused of launching a DOS in the name of load testing.
The idea is to reduce the number of hits a weak server takes, not add 500 to the number /. is about to throw at it anyway.
They don't need to wait for a mirror to appear -- just send an email to the site owner warning him and giving info on how to arrange a mirror should he so want.
4. The community automatically mirrors or pastes content that has been /.-ed you just need to spend 2 seconds reading the comments.
Sometimes. 5. The guy with the Lego site is probably tickled pink that his site just got a billion hits and probably doesn't mind things crawling to a halt for a while. It's his 15 minutes of internet fame.
Yes, especially if he has some banners or such he's earning money from, he may bitterly resent having his content displayed elsewhere without his ads.
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."
Don't you mean .95 * .3 == .285??
500 requests within a span of a few seconds can bring down some small servers, particularly if the page is dynamically generated. /. could be accused of launching a DOS in the name of load testing.
Good point. Better to use a slow-start algorithm on your worker threads so that you can gradually discover the maximum hits/s that the server can handle. Then if that number is lower than the peak expected, the Slashcode can turn on the n% mirroring right away.
The trouble with waiting until users report it is that you are guaranteed to bring down the weak servers. Slashdot is already accused of being a DOS attack tool; they might as well own up to it and try to make it behave a little better.
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.
And another thing: don't use Internet Explorer even if it is built into Windows.
No other web browser supports the ActiveX controls required to download security patches from Windows Update.
Will I retire or break 10K?
When trying to connect to an address of form 1.2.3.4, the program would halt for some twenty-thirty seconds before proceeding.
IIRC this was a problem with Sun's implementation of InetAddress.getByName() on Windows. When passed a string containing a dotted numeric quad, it stupidly tried to do a DNS lookup on it instead of simply filling in the four bytes and handing you an InetAddress. Because who knows- maybe someone registered "192.168.1.23" as a domain name! (Which would be akin to registering "microsoft.com" with a Cyrillic "o", but never mind.) Then of course your thread stalled inside InetAddress for half a minute while it waited for the DNS timeout. This makes me suspect that Sun's code was waiting for the successful DNS response and ignoring the failure response that actually arrived. Probably the same moron was responsible for both bugs. Editing the hosts file became the standard workaround.
I don't know when it got fixed but there's code in there to check for a dotted quad now.
I agree 100%.
/.ers) for (mostly) educational purposes is hardly criminal - It's a technological problem with no perfect immediate solution.
There is no good solution at the moment. But a good solution could possibly involve some sort of adaptive bandwidth throttling done on the server side to avoid getting a huge over-bandwidth charge.
Agreed about the guns and rioters, but viewing web pages (even by hordes of geeky
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
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
Why not just have operators add a default file to their site, sort of like a robots.txt file?
Something like:
mirror.txt (allow_automatic_mirror:true/false)
Seems like an easy solution?
N.
"Nothing strengthens authority so much as silence." - Charles de Gaulle
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
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
~~~
Oh wait.
Sorry about the combative tone of my last comment. I wrote it and thought I hit preview yet it submitted it anyway. Ohh well. Anyway, I'd still argue that slashdot is a hosting site, they just do free hosting on a limited basis. Your second argument seems a bit odd. You seem, unless I'm misreading you, to advocate that everyone build electronic gates to their sites lest someone discover it. The fact that I don't have a gate around my yard does not mean that I'm inviting the world to come onto my property. However people with business to transact (such as UPS or Fedex) or friends of mine or other such expected visitors or even the occasional unexpected visitor are welcome to stop by and transact their business or talk to me. But I'd be pretty annoyed if the UPS guy told one of his buddies to invite everyone possible to come party at my house and to invite all their friends because the party is expected to be a megabash and maybe my house'll burn down or my lawn will be destroyed but that's ok because I can rebuild/re-sod it, right? We shouldn't need to gate off the internet just because some people out there think it's just fine to invite everyone to my website without even asking me. It's not hard to ask permission. And slashdot is not known for their current news but for their interesting news. That's why they don't have reporters who investigate but instead wait for submissions and review those submissions all in good time and not immediately (though sometimes it is pretty instant, it just depends). I do like slashdot but its because of their sometimes interesting stories, not their manners. I'm not asking for miracles, I'm asking for courtesy such that people who do write interesting things don't feel compelled to hide their work behind elaborate fences and gateways to keep out random websurfers. You wouldn't want me to invite many thousands of people to party at your house without discussing it with you first, would you?
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!
How did you manage that, while being too stupid to understand bandwidth throttling?
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.
Ok, now would all the rocket scientists here explain to me why IE loads apache pages just as fast as IIS pages? And way faster than Mozilla? This smells like FUD from Open Source land because there isn't a speed difference based on the server OS. IE renders pictures much faster than Netscape/Mozilla, that is the difference. God forbid if Microsoft actually codes something better than open source or it's competitors. So it HAS to be standards breaking! Wonder how they got the Apache group to comply?
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
You bitter or what? Seriously...he said basically "Moz has tabbed browsing, which makes it better than IE".
You then go "Opera is a pioneer, and Moz is just a robber. Plus, IE is going to do the same soon, so it's no benefit."
If you haven't tried Moz recently, I'd suggest doing so. At one point, it was dog-slow and I used Opera too. But those days are long gone, and Moz's compatibility is better and performance on roughly the same level (at least in the Linux version of Opera).
Plus, Moz doesn't force you to use MDI. God, I hate MDI. Sucks horribly with multiple viewports (even when I'm using Windows, I gotta have a pager).
May we never see th
I don't know anyone that likes AutoComplete, actually. Everyone I know disables it (and the "password manager").
May we never see th
Business is business...
Yet I stop hearing this from Windows people when people write worms and exploits for Outlook or IE or Word.
All depends on which shoe the foot is on, doesn't it?
May we never see th
How about popup blocking (doing this in a proxy, as one must do on IE, is slower and less reliable)?
May we never see th
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
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
In my case I'm using TCPViewPro from www.winternals.com (or there's the freeware version from www.sysinternals.com)
Others may be logging them on their firewall/routers.
Simon
Coming soon - pyrogyra
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
> I have made MANY web sites that validate (strict) and they look right on IE and Opera, but not moz/netscape.
Passing the HTML validator != "correct". (This has been pointed out before. Wish I had a link to one of the relevant convos/posts.)
Mozilla's CSS compliance runs circles around MSIE's, and is a hair better than Opera's. For example, MSIE does table CSS totally wrong. Well... that's not quite true: actually it doesn't do real table CSS at all.
There's boatloads of the CSS-2 spec that MSIE simply ignores.
And there are also plenty of sites out there whose HTML and CSS both validate fine, but that have bad document structure, using various hacks to achieve a given "look" whether or not things are intended to be used that way.
Il n'y a pas de Planet B.
If the majority really ruled, than Al Gore would be President. Fact is, the majority is only right when it can do something about it or when it isn't wrong (or else how would desegregation have ever happened?)...
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.
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.
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.
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
It [b]does[/b] hurt. IE becomes slower when trying to access webpages from non-IIS servers!
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..)
Ho ho! The starry-eyed optimism of youth.
24% of respondents secretly love Windows XP in the first poll. And in the second poll, 33% of Slashdot users' main computers run Linux, while (drumroll please) 47% use a form of Windows. I don't think the babies of the world have to worry about their candy just yet.
http://slashdot.org/pollBooth.pl?qid=898&aid=- 1
http://slashdot.org/pollBooth.pl?qid=848&aid=- 1
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.
Nobody will sue for free advertising and no cort would support a business who sued for getting to much traffic.
But mirroring a site is a copyright volation and most judges will see it that way.
I don't actually exist.
Don't you mean .95 * .3 == .285??
It's even less than that, if you consider the number of ISPs that use transparent Web proxies. (Which, incidentally, is also why I have no way of verifying or debunking this article, since I don't happen to know the location of an IIS server that isn't running on port 80.)
--
"This isn't the post you're looking for. Move along."
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
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.
It looks like the server is sending an HTTP 1.0 version in the response, though, which makes the relevant RFC 1945, not 2616. IE should be checking the HTTP response version to determine whether it's in fact HTTP 1.1, or it should be checking the readability of the socket before writing (to detect an HTTP 1.0 server closing the connection after the response).
It's not at all a matter of courtesy and common sense. It's a technical matter. There's quite a difference.
/.ers all try to hit it at once? Yes. But it will not crash Joe Hobbyist's server, and it won't rack up a high bandwidth bill for him either.
To reiterate my point - if said hobbist puts up a web page for just his buddies, he should have tweaked his web server to allow no more than, say, four concurrent connections. Even four is probably overkill. Will it still be inaccessible when thousands of
If a dance club doesn't want more than a 100 people in their club at a time, what do they do? They have the bouncer count heads and once capacity reaches 100, only admit one person for every person that exits. It's quite simple really. Does the club manager care if 50,000 people want to get into his club? No! Because he know's there is the 100 person limit in effect. If the club manager doesn't limit the capacity, it's his own damn fault when 600 people pack themselves into a club that only has room for 100 and a riot ensues.
The same goes for a web server. If you don't want to pay for 3 terabytes of bandwidth - set your server settings accordingly.
Thanks for YOUR troll though.
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
Comment removed based on user account deletion
Thanks for mod'ing me down, coward. My post was no more offtopic than the original post. This however is offtopic. Not that I care much. Are you one of the inconsiderate editors or just a gutless coward? Who knows, who cares. Good luck in life, chicken. I'll enjoy looking down at you from the top.
p.s. if you're going to be arrogant, be intelligent enough to do it well and don't be vengeful when someone smarter comes along and makes you look stupid. Replying to someone in kind is the civilized way. Replying to someone by falsely attacking their reputation is barbaric. Enjoy your hut.
"so? they can do whatever they want with their own program."
Oh c'mon, that non-argument is so old already.
Yes, you can do whatever you want with your own stuff, under normal conditions. I'll give you 2 examples:
Let's say you make your own knife. You can do whatever you want... except killing people or doing other things that the law prohibits!
Let's say there's a certain person you don't like. You don't let him enter your own house. Nothing wrong with that.
But what if you own all the supermarkets in the country (--> see the relation with Microsoft's monopoly), except that 1 little supermarket 600 miles away, and you prohibits every supermarket from selling stuff to that person? Even though you own those supermarkets, that wouldn't be fair, would it?
Microsoft is a monopoly and have a huge market share, you cannot deny that. Therebefore, they are directly responsible for the slowness of 95% of the desktop users. Furthermore, average users are not even aware that alternative browsers exists, and some sites REQUIRE you to use IE.
With great power comes great responsibility. This isn't just a matter of "they can do whatever they want with their own program".
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.
"with where microsoft makes their browsers go faster"
And slower with non-IIS servers.
"they're getting MOST content faster than they would with crapzilla"
So you're saying most webservers run IIS, not Apache? Funny, last month Apache had a market share of 60%.
If you don't believe me, check out NetCraft: --> IE users actually get MOST content slower because MOST servers are running Apache. Apache has twice as much market share as IIS. Not to mention all the other small non-IIS web servers.
"If people can't stand that 1/10 of a second difference, then they would try to get a new browser."
If they know there is such a thing called "browser". For average users, that 'E' icon is the Internet itself. And the percentage of people who know that alternative browsers even exist are becoming smaller and smaller.
"Just because most servers are apache doesn't mean most content comes from them, buddy."
Then give me some proof that most content comes from IIS servers. I've backed up my claims, now it's time to backup yours.
"That's like telling me that the newbie car mechanic doesn't know what a wrench is."
Wrong comparison. Newbie car mechanic == newbie programmer. Newbie car driver == newbie computer user.