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....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.
2.1. Invent time machine
2.2. Go back to before the time of the Karma Cap
2.3. Whore madly for karma
2.4. Leave the account dormant until now
2.5. Sell 300-karma account on eBay to an infamous troll
3. Profit!!!
2.1. Invent time machine 2.2. Go back to before the time of the Karma Cap 2.3. Whore madly for karma 2.4. Leave the account dormant until now 2.5. Sell 300-karma account on eBay to an infamous troll 3. Profit!!!
dang!
you found out my plan! i've got the car, now to figure out exactly how much a jigawatt really is.
"...now to figure out exactly how much a jigawatt really is."
That's just the "phonetic" spelling of the proper pronunciation of gigaWatt (which I think is one thousand megaWatts). The root word is "gigantic" (or whatever the word gigantic is based on), hence the "j" sound. And yes, you have been mispronouncing gigabyte and gigaHertz all this time as well. But then, so have I.
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?
1. Sell anthrax and other biological weapons [osd.mil] to Saddam Hussein. 2. Wait a few years. 3. "Discover" that Iraq owns weapons of mass destruction, and start a war against them. 4. Replace their nasty military dictator with a friendly military dictator. 5. Steal their oil. 6. Profit!
I think what we're seeing is the use of the HTTP Keep-Alive which is part of the HTTP 1.1 standard. Am I wrong?
IE does use Keep-Alive, but that's much higher up the protocol stack, and is a separate issue from taking shorcuts when setting up a low-level connection.
Keep-Alive merely provides a means for a browser to signal to the server that additional requests will follow on the same socket. If the server plays along, it will both leave the socket open at the end of the request, and will signal the browser by returning an appropriate header. This saves a lot of extra socket setup and tear-down, but is independent of whether the socket is set up correctly, or by a dubious short-cut.
This isn't an HTTP-level keep alive. It's TCP/IP, which is lower-level than that.
Additionally, this isn't a keep alive. Regardless of whether there is a connection to a server or not, IE sends a request packet first, which is wrong according to the TCP/IP standards. Secondly, it doesn't completely close connections.
Keep alives are so that the client and server keep on using the same socket to load the whole page (not just the HTML, but the images as well), but usually end the connection once the entire page has loaded. The client tells the server, "There are going to be some more requests coming real soon, so keep the connection open." and then the server acknowledges this.
On the other hand, what IE is doing is just not entirely closing the connection. The server is not informed that this is a keep alive, because it ISN'T A KEEP ALIVE. Internet Explorer is hoping that, by acknowledgint the server's FIN packet, but not sending a FIN packet of its own, the server will keep the connection open at least for a little while longer, to make IE seem faster at loading pages (a decent server would just timeout and close the connection after a set amount of time, but who knows what IIS does). While it might seem like IE is staying within the standards, there is a specified way to close a TCP/IP connection, and IE doesn't fully follow that spec.
Besides, it is a sneaky thing to do, because if the server is keeping the connection open to wait for the client's FIN packet that will never come, the server's resources are being wasted on an unused connection. The connection probably won't stay open for long, but if a server is getting hammered (the site got linked on Slashdot, or whatever), this only makes things worse.
I am no TCP guru, but this looks a bit odd. From the text I understand they say IE establish a connection without sending a SYN packet.... I may be wrong, but this is totally impossible to do over TCP/IP. SYN is required, in order to establish a new TCP sequence and inform the server that it is a *NEW* connection, not something related to an old one. If all this guy claims is true, the screwup is below IIS and IE. It is in the windows TCP/IP stack. And I am really puzzled how they manage to do connection tracking this way. Ah, and for sure, if it really works this way, it can't be called TCP/IP.
Ofcourse if it just opens the connection in a normal SYN way and keeps it open for all the HTTP requests, nothing is wrong. These are new features of HTTP/1.1 called keep-alive and pipelining, and even Mozilla supports them (check preferences/advanced/HTTP networking).
Unless they are *not* using the standard sockets interface... rather using some undocumented hack inside win32 that does this (hey, linux has something like this, its called the "Packet Generator"(LOL), but it is atleast documented (and has its usage higly counter-recommended)). Man, if this is the case, I see some ppl getting pretty pissed off. Thats why closed-source monopoly software is not a Good Thing (TM). Anyone remember the stories about M$ using undocumented windows APIs in Office to be faster than the competition?
Rather than speculating, just find out. Attach WinDbg to IE and check to see if it using the standard Winsock interface, or some other one. Be sure to make sure that all "reserved" parameters have their documented required value.
no they haven't "hacked around tcp". Newer kernels have a feature called "Packet Generator", which is completely unrelated to the TCP/IP stack, and can be used to throw whatever you want on the wire, even bastardized TCP/IP packets. But can be used for UDP, IPX, AppleTalk, or you can even invent your own transport and use it;-)
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.
Yes I think so. Many are saying, "why doesent the server just dump the conn?" Well its the server who has the load and its time is precious. It would prefer not to have to reopen a connection if it can keep it open. Saves time to keep it open. Clients are relatively unloaded when their users are browsing, its a leisurely activity.
So M$ is abusing the servers trust. Otherwise I didnt hear any really down side to what they are donig. Maybe others should just even it up by joining them. Of course protocols were designed that way for a purpose...
If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it. If the server doesn't support persistent connections, it's free to close it's end of the connection. The browser is supposed to see this, close it's end and open a new connection for the next request, but it's possible IE is simply assuming persistent connections and only doing the close-and-reopen when it sees an error sending the additional requests. My guess is that they combined error-recovery ("the connection died, close it, open a new one and retry the request") with handling servers that don't support persistent connections ("server closed the connection, close our half and open a new one for this request").
And therefore use that pernicious turd, the CSocket class.
As much as it pains me, this probably isn't anything intentionally evil in the M$ implementation here - it's just more of the useless bloat and cruftiness that's standard M$ fare. The developers who wrote MFC's CSocket class probably didn't even try to communicate with a non-M$ product, and the IE and IIS developers are probably the same idiots - the ones who can't spell "security".
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.
Err, I don't think so. From what I've read about HTTP KeepAlive, the connection should be kept alive by adding a "Connection: KeepAlive" header to the request or something like that. I can't imagine any reason why any protocol should want to interfere with the TCP handshaking sequence for keepalive purposes. That would mean crossing out of the application layer into the transport layer.
This issue caused me a lot of grief last year, and I am just figuring out why. We set up a webmail server using Apache/Vhosts and OpenSSL, and we had this recurring problem of links just suddenly breaking in IE... It'd just return "Page could not be loaded" or something like that. The problem never cropped up in Mozilla or other browsers, and eventually I found out that if I added this line:
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.
No, that's exactly how it's supposed to work. If you connect to a HTTP1.1 server, and tell it you want to keepAlive, and it doesn't explicitly refuse, you can assume that it's going to keep a persistent connection.
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).
...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.
But, wouldn't you need to setup the connection properly even if it's a persistent connection? Persistent just means we don't close the connection again just in case more data needs to be sent later. When we close the browser or go to a new page we'll still close the connection with the server gracefully.
I haven't read the HTTP1.1 spec, so please bear with me.
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.
I agree that the half-close is part of the TCP standard, but the way I interpret the article an IIS server would send data through it's part of the socket -- which is closed.
To bad I don't have any Micro$oft boxes in my lan, or I would verify this:)
... unless otherwise indicated, a client
SHOULD assume that the server will maintain a
persistent connection...
So Internet Explorer is correct when it assumes
that the connection is persistent, even without having seen a Connection: keep-alive.
Actually keep-alive is an obsolete token from HTTP 1.0; the only token used in HTTP 1.1 is "close". If the server did send a "close" token,
Internet Explorer would be violating HTTP 1.1 in sending the second request, but it wouldn't be violating TCP.
If the server calls shutdown() without sending
a Connection: close, it is not behaving as it SHOULD according to rfc2616, section 8.1.2.1:
If the server chooses to close the connection
immediately after sending the response,
it SHOULD send a
Connection header including
the connection-token close
If the FIN hasn't arrived at the time IE
does the read() in step 4 above, it has no
way of knowing that the connection was shut down
by the server. If the read provided enough content
that IE could send a new request, there is no reason it shouldn't do so.
I may be missing something, but it seems to me that IE is behaving exactly like it should, and that the packet traces actually just indicate that it has a good quality HTTP 1.1 implementation.
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).
That's stupid alright! Though, it seemed to me like the article was mainly concerned with the _initial_ connect. Anyway, they've since updated the blog with this bit:
UPDATE: Since this post got Slashdotted, I've been getting a pretty fair amount of e-mail, suggesting that the behavior we observed here might be anything from T/TCP to HTTP/1.1 pipelining to delirium tremens. Well, I should point out that this phenomenon was something we observed in 1997, before HTTP/1.1 was in wide use; both the client and server were using vanilla HTTP/1.0. As it turned out, it was actually the NT stack that was causing this to happen-- it didn't matter what client or server software you used. It even happened with our home-grown network test tools.
It's entirely possible that Microsoft has changed the NT stack in recent iterations so that this doesn't happen anymore. But if you're trying to reproduce the behavior, use NT 4.0 machines for worst results.
If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it.
You might want to look into HTTP 1.1 as well. In fact, so should Microsoft, because (if the article is accurate) they've apparently re-invented the wheel in square form.
Standard HTTP 1.1 keepalive still uses a regular, plain, vanilla TCP connection. No FIN packets until the connection actually is finished. It simply doesn't close the connection, allowing further requests on the same connection (because the connection is still open). The connection is closed - using the standard methods - when one side decides to close the connection (eg. after a timeout).
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
No, what's described is a plain vanilla half-close of a standard TCP connection. The server called shutdown(), sends a FIN, the client stack ACKs it. The browser doesn't call shutdown(), hence it doesn't generate any FIN packet for it's half of the connection. It's entirely acceptable from a TCP-protocol standpoint, although highly annoying.
Half-close? As in half-correct? I thought this is a three-way handshake, which is a necessity as the underlying protocol is considered unreliable. RFC 761 it is explicitly stated that both connecting and disconnecting involves a three-way handshake with SYN/ACKs and in the case of disconnecting FIN/ACKs.
Of course, the second FIN may be lost (or not send at all, as in MSIEs case), so additionally there is a time-out, which will make the connection close anyway. But this is somehow undermining the sense of the ACKs.
In RFC 793 [x42.com] (supersedes RFC 761) 3.1, I read nothing about a "half-close".
You failed to read all of RFC793. When the server sends a FIN to the client, the client is required to ACK it, but the client is not required to send a FIN to the server at that point. If the client doesn't close it's half of the connection (triggering the send of it's FIN packet), it's allowed to continue to write. That's why the shutdown() socket call takes an argument indicating whether to close the read half, the write half or both halves of the connection. Of course, if the server has completely closed and disposed of the socket on it's end, incoming packets will fail to match a connected socket on the server and an RST will be generated.
It was thought more likely to work the other way, with the browser sending a FIN packet to the server immediately after sending it's request, closing the browser-to-server half of the connection, and the server would then send the response back down the server-to-browser half of the connection before sending it's FIN packet to the browser to complete closing the connection. As it turns out, things took a different route and the opposite happens.
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
You know, I seem to recall some guy saying that Microsoft's long-term goal was to embrace, extend, extinguish TCP/IP. And that they'd start by making tiny little changes so that Microsoft programs talking to Microsoft programs worked much better than Microsoft/non-Microsoft. He got booed down quite loudly - everyone claimed that they could never try anything like that. It'd be noticed immediately and they'd have a PR disaster.
The odd thing? He was half-right. He was wrong only in saying that they hadn't done it yet.
Personally I believe that TCP/IP is just too entrenched too be changed into TCP/MS. MS will probably focus more on the protocols at a higher level of abstraction, like HTML, NetBeui and the layers on top of SOAP+XML.
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....
2.) Tell us exactly what address or domain IE is allegedly connecting to, so I can block outbound connections to it at the router? Others in the house still use IE, the poor dopes...
Oh he's just joking about what IE does if it can't find the server to connect to. When it can't connection it runs a search on MSN for the domain name.
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....
Either this depends on a specific option being set or using a specific version of IE other than the one I have, or this is an outright lie. I just watched a packet dump of IE making an HTTP request, and there were no suspicious extra IP addresses involved in the transfer (just myself, the nameserver, and the server requested).
I have to agree... I captured my traffic, and connecting to a simple html site (http://www.opensource.org/ if you must know) yielded a measly 3 TCP connects, all of which appeared to be to spec. No insidious plot to undermine everyone's privacy. Move along.
I run a bunch of Apache/mod_ssl servers for WebCT, an online course management tool. We have to disable keepalives for IE users because otherwise their connections get hosed up.
I wonder if this habit of playing fast and loose with the protocol is responsible.
That would explain this behaviour in the additional requests, but I believe the author was stating that when accessing a webpage for the first time, IE simply sends a request with no SYN sequence. Someone should test this.
It may be called that, but a certain subset of RFCs, including the one at issue here, become de facto standards in the Internet community. And when they become de facto standards, it's at very least good practice to follow these standards to ensure interoperability. Guess who's not?
The whole Internet culture of 'RFC's is part of why the 'net doesn't scale well to the whole world. You can't base an entire world network on consensus. Consensus doesn't scale well beyond a community. It's the sad truth.
Look at another recent slashdot thread here: http://slashdot.org/article.pl?sid=03/01/04 /183522 2 Specifically, look at one of their slides here: http://www.fys.ku.dk/~nvj/ms-gpl/img_0222r. jpg at the bottom it reads:
"Open Standards have become a point of confusion".
They're just mad because they didn't think of it already. Had some Linux setup done this first, every fanboy would have been crowing over how much faster/cooler/etc is was than X$ (where X$ is whatever OS that isn't Linux).
Whatever happened to logged in trolls? You are obviously trolling, but you haven't done it as a logged in user. How sad. I post all my trolls with this account when I feel like trolling. You should try it. It's good for the spirit.
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.
If IE+IIS can jump this synchronization step without a problem, this means that all synchs are simply useless?
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.
Except that, with "legal" keepalives, you tell the server that you want the connection kept alive, via "Connection: KeepAlive" or something like that in the HTTP header.
It has nothing to do with TCP/IP. This article, however is about TCP/IP, more specifically Microsoft's playing fast and loose with the TCP/IP standards.
Granted I cannot read the actual article as the site is down by based on the above:
This is fuzzy math. I do not like IE/IIS any more than the next guy but if the server to leave a half open connection on IT's side two things would happen.
#1 The client's TCP stack (not IE, the stack) would have no idea that this connection was still open and would send a new SYN as soon as the user selected another link. This new request would have a different sequence number (probably source port as well) and would have to do the THREE-WAY handshake (SYN - SYN/ACK - ACK). Negating any benefit
#2. Those 1/2 open connections on the server use resources. Any host has a limit to the # of connection it can maintain at which point it stops accepting new ones (Check out how syn-floods work!) that means if this were true IIS server would need to be restarted constantly to clear these buffers.
#1 The client's TCP stack (not IE, the stack) would have no idea that this connection was still open and would send a new SYN as soon as the user selected another link. This new request would have a different sequence number (probably source port as well) and would have to do the THREE-WAY handshake (SYN - SYN/ACK - ACK). Negating any benefit
True, but suppose they hacked their TCP stack to recognize a magic SYN number, and bypass the three-way handshake if the client sends this magic number. Improbable? IE is part of the Windows kernel, so what's to say it doesn't poke directly in the TCP/IP stack. Wild speculation, I know.
I am pretty sure that's incorrect. MS's TCP stack though - where all this would happen - is (last I knew) mostly kernel-land. IE's rendering stuff, etc is most certainly *not* kernel land.
Considering that certain problems having nothing to do with web pages or even the internet at all can sometimes be fixed by running IE's repair function (or updating IE to a newer version), I would say that IE is more than just a web browser. Whatever else it is for is anybody's guess, including kernel-level manipulation. As we can not examine the source, anything you or I say about IE's innards is pure speculation.
IE's influence on a windows box is (unfortunately) quite widespread, but AFAIK, it's mainly just a bunch of COM components. Does anyone know if IE installs a driver (.SYS) file? That's the only way it would be able to jump into kernel mode.
The original poster who said that IE is "in the kernel" probably meant that IE is part of the internal guts of how Windows works. That probably means he has it mixed up with Windows Explorer, but that would be an easy mistake to make, especially if you've never seen earlier versions of the two programs from before they started sharing display libraries and WE started rendering HTML (c1998).
IE didn't _used_ to install a driver as such, but I haven't installed a recent version of IE. (I've used IE6, but it was preinstalled.)
Anyway, what the article describes isn't totally clear, but if I understood correctly, it's not talking about IE _really_ trying to send a request packet where no connection has ever been set up, but rather about the issue first being noticed as a result of a trace that showed behavior that _appeared_ to be that -- which it would, if the server closed the connection and IE pretended it was still open and tried to use it. I suspect that's what's really happening, but if you jump in in the middle you see that there's nothing on the server end in the way of a connection and this unsynchronised request packet appears out of the blue, _as if_ IE were skipping the handshake -- but perhaps it really just never closed its end of an earlier connection.
As far as whether that violates the TCP, you'd have to ask a TCP guru, which I'm not. If it did violate TCP, I can easily believe Microsoft might do it anyway, but I'm not ready to assume that it violates the protocol without checking, since many protocols leave room for behaviors that are not usually done, and it could be that Microsoft followed the protocol in a different way from others.
If you accept MS's claims that IE is now inseperable from the OS as a whole, then you're getting pretty close to being in kernel land. Once you get there, it's pretty easy to just start putting special hooks that allow IE to randomly mess with how the TCP stack works.
Remember: the same company that wrote MSIE wrote MS-Windows. Just because most normal programs aren't able to mess with TCP sequences doesn't mean that IE's programmers don't know something that we don't.
Doesn't a great deal of spyware tie into the TCP stack? Or am I thinking of something that happens at a higher level? I thought thats why bad things happened when you just simply deleted certain spyware.dlls, that they had their hooks too deeply in the network stack.
#2. Those 1/2 open connections on the server use resources. Any host has a limit to the # of connection it can maintain at which point it stops accepting new ones (Check out how syn-floods work!) that means if this were true IIS server would need to be restarted constantly to clear these buffers.
oh.
you've just described "system administration" of any IIS server under load.
hang->reboot->repeat.
i had over 160 of the damn things under me in a previous life. i literally had monkeys running up and down the aisles pressing reboot on hung servers.
glad to be away from that fucking hell-hole.
that means if this were true IIS server would need to be restarted constantly to clear these buffers.
Of course, the connections would eventually time out, negating this effect to some extent. But I wonder how the hacks of standards play out into the general performance of the product.
RFC 1379 [rfc-editor.org] and RFC 1644 [rfc-editor.org] describe a mechanism for improving the performance of transactions in standard TCP, by avoiding the three-way handshake involved in TCP virtual-circuit establishment and teardown. The document was published over ten years ago, and has been implemented in several IP stacks. The article that this story linked to did not give enough detail to confirm that it was T/TCP he was looking at, but the sketchy description he gave was consistent with T/TCP.
The T/TCP Home Page [kohala.com] describes some early implementations (e.g. FreeBSD since 2.0.5).
From RFC 1379 (R. Braden, ISI, November 1992):
This memo discusses extension of TCP to provide transaction-oriented service, without altering its virtual-circuit operation. This extension would fill the large gap between connection-oriented TCP and datagram-based UDP, allowing TCP to efficiently perform many applications for which UDP is currently used. A separate memo contains a detailed functional specification for this proposed extension.
You can trivially turn on T/TCP in FreeBSD as follows (it is off by default):
sysctl -w net.inet.tcp.rfc1644=1
Morals of this story:
not everything is an Evil Microsoft Plot to take over the world
sometimes it helps to know what you are talking about before revealing astonishing revelations.
Thanks for taking the time to shine some new light on the subject. Perhaps one day people will be willing to find out if what they're reading on slashdot is true or not.
RFC 1379 is an Informational RFC and RFC 1644 is an Experimental RFC. Neither of these documents are recommended (by the IETF) for use on the Internet.
The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.
4.2.2 Informational
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3).
Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor.
Note the striking lack of text describing how the IETF doesn't recommend protocols described by Experimental or Informational RFC documents.
As described by the article, it actually doesn't sound like IE is using T/TCP. With T/TCP, new connections still require SYN packets. It's just that the SYN packet can also contain data, because a monotonically increasing connection counter guarantees that the server is not just seeing some old duplicate SYN packet.
The article is admitedly not very clear about what is going on. However, it seems to imply that the server resurrects a given TCP connection, and sends data with later sequence numbers than the FIN. That doesn't sound right.
It's also quite possible that the article is wrong or mischaracterizes the observed behavior. In particular, if IE really worked as described, you'd think people would have run into problems with certain stateful firewalls and NAT boxes.
I wish the article would elaborate a bit more on what goes on in step "1. Request".
Cut n Paste (Score:3, Informative)
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.
Couldn't resist... (Score:0)
1. SYN ->
2.
4. Request ->
5. Profit!!
Re:Cut n Paste (Score:5, Funny)
" Client Server
1. SYN ->
2.
4. Request ->"
That's very similar to the working of the infamous underpants gnomes.
1. Collect underpants
2. ?
3. Profit!
Re:Cut n Paste (Score:5, Funny)
1) Rewrite TCP
2) ???
3) Speed boost!
Re:Cut n Paste (Score:3, Funny)
1. Karma
2. ???
3. Profit!
Re:Cut n Paste (Score:4, Funny)
2.1. Invent time machine 2.2. Go back to before the time of the Karma Cap 2.3. Whore madly for karma 2.4. Leave the account dormant until now 2.5. Sell 300-karma account on eBay to an infamous troll 3. Profit!!!
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
dang!
you found out my plan! i've got the car, now to figure out exactly how much a jigawatt really is.
Re:Cut n Paste (Score:2)
That's just the "phonetic" spelling of the proper pronunciation of gigaWatt (which I think is one thousand megaWatts). The root word is "gigantic" (or whatever the word gigantic is based on), hence the "j" sound. And yes, you have been mispronouncing gigabyte and gigaHertz all this time as well. But then, so have I.
Re:Cut n Paste (Score:1)
1. No Karma
2. ???
3. Profit!
EBAY! (Score:2)
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?
Re:Cut n Paste (Score:2)
1. Natalie Portman
2. ?
3. Profit!
--
sed 's/commun/terror/g' mccarthy > bush
Re:Cut n Paste (Score:3, Funny)
1. Natalie Portman
2. Profit!
Re:Cut n Paste (Score:2)
Proprietary Internet Microsoft Protocols?
They gave up (Score:2, Funny)
RMN
~~~
Re:They gave up (Score:1)
they Leave the Right side ones
Re:Cut n Paste (Score:1)
" Client Server
1. SYN ->
2.
4. Request ->"
1. Collect packets
2.
3. Profit!
Re:Cut n Paste (Score:3, Insightful)
1. Sell anthrax and other biological weapons [osd.mil] to Saddam Hussein.
2. Wait a few years.
3. "Discover" that Iraq owns weapons of mass destruction, and start a war against them.
4. Replace their nasty military dictator with a friendly military dictator.
5. Steal their oil.
6. Profit!
No, wait...
There is no "?" in that one.
Re:Cut n Paste (Score:2, Interesting)
Mod parent up! (Score:0)
Re:Cut n Paste (Score:5, Informative)
IE does use Keep-Alive, but that's much higher up the protocol stack, and is a separate issue from taking shorcuts when setting up a low-level connection.
Keep-Alive merely provides a means for a browser to signal to the server that additional requests will follow on the same socket. If the server plays along, it will both leave the socket open at the end of the request, and will signal the browser by returning an appropriate header. This saves a lot of extra socket setup and tear-down, but is independent of whether the socket is set up correctly, or by a dubious short-cut.
Re:Cut n Paste (Score:1)
Additionally, this isn't a keep alive. Regardless of whether there is a connection to a server or not, IE sends a request packet first, which is wrong according to the TCP/IP standards. Secondly, it doesn't completely close connections.
Keep alives are so that the client and server keep on using the same socket to load the whole page (not just the HTML, but the images as well), but usually end the connection once the entire page has loaded. The client tells the server, "There are going to be some more requests coming real soon, so keep the connection open." and then the server acknowledges this.
On the other hand, what IE is doing is just not entirely closing the connection. The server is not informed that this is a keep alive, because it ISN'T A KEEP ALIVE. Internet Explorer is hoping that, by acknowledgint the server's FIN packet, but not sending a FIN packet of its own, the server will keep the connection open at least for a little while longer, to make IE seem faster at loading pages (a decent server would just timeout and close the connection after a set amount of time, but who knows what IIS does). While it might seem like IE is staying within the standards, there is a specified way to close a TCP/IP connection, and IE doesn't fully follow that spec.
Besides, it is a sneaky thing to do, because if the server is keeping the connection open to wait for the client's FIN packet that will never come, the server's resources are being wasted on an unused connection. The connection probably won't stay open for long, but if a server is getting hammered (the site got linked on Slashdot, or whatever), this only makes things worse.
Re:Cut n Paste (Score:2, Redundant)
I am no TCP guru, but this looks a bit odd. From the text I understand they say IE establish a connection without sending a SYN packet....
I may be wrong, but this is totally impossible to do over TCP/IP. SYN is required, in order to establish a new TCP sequence and inform the server that it is a *NEW* connection, not something related to an old one.
If all this guy claims is true, the screwup is below IIS and IE. It is in the windows TCP/IP stack. And I am really puzzled how they manage to do connection tracking this way. Ah, and for sure, if it really works this way, it can't be called TCP/IP.
Ofcourse if it just opens the connection in a normal SYN way and keeps it open for all the HTTP requests, nothing is wrong. These are new features of HTTP/1.1 called keep-alive and pipelining, and even Mozilla supports them (check preferences/advanced/HTTP networking).
cheers
Re:Cut n Paste (Score:5, Interesting)
cheers.
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
cheers
keepalive protocol? (Score:3, Interesting)
i would assume that the keepalive protocol reduces the ill effects of this system, since once a connection is made it doesn't have to be torn down and reestablished, or at least not for each request.
Re:keepalive protocol? (Score:2)
So M$ is abusing the servers trust. Otherwise I didnt hear any really down side to what they are donig. Maybe others should just even it up by joining them. Of course protocols were designed that way for a purpose...
Re:Cut n Paste (Score:4, Informative)
If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it. If the server doesn't support persistent connections, it's free to close it's end of the connection. The browser is supposed to see this, close it's end and open a new connection for the next request, but it's possible IE is simply assuming persistent connections and only doing the close-and-reopen when it sees an error sending the additional requests. My guess is that they combined error-recovery ("the connection died, close it, open a new one and retry the request") with handling servers that don't support persistent connections ("server closed the connection, close our half and open a new one for this request").
IE and IIS probably coded with MFC (Score:0)
As much as it pains me, this probably isn't anything intentionally evil in the M$ implementation here - it's just more of the useless bloat and cruftiness that's standard M$ fare. The developers who wrote MFC's CSocket class probably didn't even try to communicate with a non-M$ product, and the IE and IIS developers are probably the same idiots - the ones who can't spell "security".
Re:IE and IIS probably coded with MFC (Score:2)
IIS and IE ship as part of Windows and so would not be subject to this limitation.
Re:IE and IIS probably coded with MFC (Score:2, Funny)
Re:Persistent Connections (Score:5, Interesting)
This issue caused me a lot of grief last year, and I am just figuring out why. We set up a webmail server using Apache/Vhosts and OpenSSL, and we had this recurring problem of links just suddenly breaking in IE
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
to the virtual host configuration, the problem went away. Now that I've read this article, I think I understand why. What I think is happening here is that Microsoft trying to make the most out of keepalive/persistent connections by bending the rules. And it's not right.
Re:Persistent Connections (Score:0)
Re:Persistent Connections (Score:2)
Same here (Score:2)
...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! [apache.org]
Still need the connection setup? (Score:1)
But, wouldn't you need to setup the connection properly even if it's a persistent connection? Persistent just means we don't close the connection again just in case more data needs to be sent later. When we close the browser or go to a new page we'll still close the connection with the server gracefully.
I haven't read the HTTP1.1 spec, so please bear with me.
zRe:Still need the connection setup? (Score:5, Informative)
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.
Re:Still need the connection setup? (Score:1)
To bad I don't have any Micro$oft boxes in my lan, or I would verify this
Re:Still need the connection setup? (Score:1)
-
-
-
I may be missing something, but it seems to me that IE is behaving exactly like it should, and that the packet traces actually just indicate that it has a good quality HTTP 1.1 implementation.Section 8.1.2 in rfc 2616:
So Internet Explorer is correct when it assumes that the connection is persistent, even without having seen a Connection: keep-alive.Actually keep-alive is an obsolete token from HTTP 1.0; the only token used in HTTP 1.1 is "close". If the server did send a "close" token, Internet Explorer would be violating HTTP 1.1 in sending the second request, but it wouldn't be violating TCP.
If the server calls shutdown() without sending a Connection: close, it is not behaving as it SHOULD according to rfc2616, section 8.1.2.1:
If the FIN hasn't arrived at the time IE does the read() in step 4 above, it has no way of knowing that the connection was shut down by the server. If the read provided enough content that IE could send a new request, there is no reason it shouldn't do so.
Re:Still need the connection setup? (Score:2)
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).
Re:Still need the connection setup? (Score:1)
That's stupid alright! Though, it seemed to me like the article was mainly concerned with the _initial_ connect. Anyway, they've since updated the blog with this bit:
UPDATE: Since this post got Slashdotted, I've been getting a pretty fair amount of e-mail, suggesting that the behavior we observed here might be anything from T/TCP to HTTP/1.1 pipelining to delirium tremens. Well, I should point out that this phenomenon was something we observed in 1997, before HTTP/1.1 was in wide use; both the client and server were using vanilla HTTP/1.0. As it turned out, it was actually the NT stack that was causing this to happen-- it didn't matter what client or server software you used. It even happened with our home-grown network test tools.
It's entirely possible that Microsoft has changed the NT stack in recent iterations so that this doesn't happen anymore. But if you're trying to reproduce the behavior, use NT 4.0 machines for worst results.
All the fuss for their premature assumptions. :-)
zThis is NOT the standard HTTP 1.1 keepalive (Score:5, Interesting)
You might want to look into HTTP 1.1 as well. In fact, so should Microsoft, because (if the article is accurate) they've apparently re-invented the wheel in square form.
Standard HTTP 1.1 keepalive still uses a regular, plain, vanilla TCP connection. No FIN packets until the connection actually is finished. It simply doesn't close the connection, allowing further requests on the same connection (because the connection is still open). The connection is closed - using the standard methods - when one side decides to close the connection (eg. after a timeout).
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
Re:This is NOT the standard HTTP 1.1 keepalive (Score:3, Informative)
No, what's described is a plain vanilla half-close of a standard TCP connection. The server called shutdown(), sends a FIN, the client stack ACKs it. The browser doesn't call shutdown(), hence it doesn't generate any FIN packet for it's half of the connection. It's entirely acceptable from a TCP-protocol standpoint, although highly annoying.
Re:This is NOT the standard HTTP 1.1 keepalive (Score:2)
RFC 761 it is explicitly stated that both connecting and disconnecting involves a three-way handshake with SYN/ACKs and in the case of disconnecting FIN/ACKs.
Of course, the second FIN may be lost (or not send at all, as in MSIEs case), so additionally there is a time-out, which will make the connection close anyway. But this is somehow undermining the sense of the ACKs.
In RFC 793 [x42.com] (supersedes RFC 761) 3.1, I read nothing about a "half-close".
Re:This is NOT the standard HTTP 1.1 keepalive (Score:2)
You failed to read all of RFC793. When the server sends a FIN to the client, the client is required to ACK it, but the client is not required to send a FIN to the server at that point. If the client doesn't close it's half of the connection (triggering the send of it's FIN packet), it's allowed to continue to write. That's why the shutdown() socket call takes an argument indicating whether to close the read half, the write half or both halves of the connection. Of course, if the server has completely closed and disposed of the socket on it's end, incoming packets will fail to match a connected socket on the server and an RST will be generated.
It was thought more likely to work the other way, with the browser sending a FIN packet to the server immediately after sending it's request, closing the browser-to-server half of the connection, and the server would then send the response back down the server-to-browser half of the connection before sending it's FIN packet to the browser to complete closing the connection. As it turns out, things took a different route and the opposite happens.
Re:This is NOT the standard HTTP 1.1 keepalive (Score:5, Informative)
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
You know, I seem to recall some guy saying that Microsoft's long-term goal was to embrace, extend, extinguish TCP/IP. And that they'd start by making tiny little changes so that Microsoft programs talking to Microsoft programs worked much better than Microsoft/non-Microsoft. He got booed down quite loudly - everyone claimed that they could never try anything like that. It'd be noticed immediately and they'd have a PR disaster.
The odd thing? He was half-right. He was wrong only in saying that they hadn't done it yet.
Re:This is NOT the standard HTTP 1.1 keepalive (Score:1)
Personally I believe that TCP/IP is just too entrenched too be changed into TCP/MS. MS will probably focus more on the protocols at a higher level of abstraction, like HTML, NetBeui and the layers on top of SOAP+XML.
Re:This is NOT the standard HTTP 1.1 keepalive (Score:1)
Re:This is NOT the standard HTTP 1.1 keepalive (Score:2)
Even more interesting..... (Score:4, Interesting)
You are being watched, friends.
Re:Even more interesting..... (Score:1)
1.) Provide some documentation of this, and
2.) Tell us exactly what address or domain IE is allegedly connecting to, so I can block outbound connections to it at the router? Others in the house still use IE, the poor dopes...
Given #2, my firewall logs will satisfy #1.
Re:Even more interesting..... (Score:2)
Re:Even more interesting..... (Score:3, Informative)
Re:Even more interesting..... (Score:1, Interesting)
Re:Cut n Paste (Score:3, Interesting)
I wonder if this habit of playing fast and loose with the protocol is responsible.
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:3, Funny)
Rules For Cowards.
Maybe this is what they mean by innovation? We all what they really mean by innovation:
"Screw the Open Standards, we will create our own Standard, but make it secret!".
Re:Cut n Paste (Score:5, Insightful)
"Rules For Competitors." Not for themselves.
Re:Cut n Paste (Score:3, Insightful)
That's obviously wrong. (Score:2)
Re:If you don't like it, don't use their products. (Score:2, Funny)
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.
Re:Cut n Paste (Score:1)
That doesn't sound like a rule to me. And obviously, Microsoft has made their comment.
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
Re:Cut n Paste - about Open standards @ MS (Score:1)
http://slashdot.org/article.pl?sid=03/01/0
Specifically, look at one of their slides here:
http://www.fys.ku.dk/~nvj/ms-gpl/img_0222r
at the bottom it reads:
"Open Standards have become a point of confusion".
Does one need to add anything?!
Re:Cut n Paste - about Open standards @ MS (Score:1)
Re:Cut n Paste (Score:0)
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:1)
If IE+IIS can jump this synchronization step without a problem, this means that all synchs are simply useless?
Re:Cut n Paste (Score:2)
not that windows isnt already far easier to blind spoof on than any other modern os.
but... firewalls??? proxies??? caches??? netstat! (Score:3, Interesting)
are we sure that the author just doesn't understand persistant connections???
a simple netstat -a would show you if the connection was kept open... i'm using squid as my proxy so can't test this.
Re:but... firewalls??? proxies??? caches??? netsta (Score:1, Insightful)
Re:but... firewalls??? proxies??? caches??? netsta (Score:2)
Re:but... firewalls??? proxies??? caches??? netsta (Score:1)
It has nothing to do with TCP/IP. This article, however is about TCP/IP, more specifically Microsoft's playing fast and loose with the TCP/IP standards.
Re:Cut n Paste (Score:2, Interesting)
This is fuzzy math. I do not like IE/IIS any more than the next guy but if the server to leave a half open connection on IT's side two things would happen.
#1 The client's TCP stack (not IE, the stack) would have no idea that this connection was still open and would send a new SYN as soon as the user selected another link. This new request would have a different sequence number (probably source port as well) and would have to do the THREE-WAY handshake (SYN - SYN/ACK - ACK). Negating any benefit
#2. Those 1/2 open connections on the server use resources. Any host has a limit to the # of connection it can maintain at which point it stops accepting new ones (Check out how syn-floods work!) that means if this were true IIS server would need to be restarted constantly to clear these buffers.
Re:Cut n Paste (Score:3, Interesting)
True, but suppose they hacked their TCP stack to recognize a magic SYN number, and bypass the three-way handshake if the client sends this magic number. Improbable? IE is part of the Windows kernel, so what's to say it doesn't poke directly in the TCP/IP stack. Wild speculation, I know.
Re: (Score:2)
Re:Cut n Paste (Score:1)
Are you sure about that?
I am pretty sure that's incorrect. MS's TCP stack though - where all this would happen - is (last I knew) mostly kernel-land. IE's rendering stuff, etc is most certainly *not* kernel land.
Considering that certain problems having nothing to do with web pages or even the internet at all can sometimes be fixed by running IE's repair function (or updating IE to a newer version), I would say that IE is more than just a web browser. Whatever else it is for is anybody's guess, including kernel-level manipulation. As we can not examine the source, anything you or I say about IE's innards is pure speculation.
Re:Cut n Paste (Score:1, Interesting)
Re:Cut n Paste (Score:2)
meant that IE is part of the internal guts of how Windows works.
That probably means he has it mixed up with Windows Explorer, but
that would be an easy mistake to make, especially if you've never
seen earlier versions of the two programs from before they started
sharing display libraries and WE started rendering HTML (c1998).
IE didn't _used_ to install a driver as such, but I haven't installed
a recent version of IE. (I've used IE6, but it was preinstalled.)
Anyway, what the article describes isn't totally clear, but if I
understood correctly, it's not talking about IE _really_ trying to
send a request packet where no connection has ever been set up, but
rather about the issue first being noticed as a result of a trace
that showed behavior that _appeared_ to be that -- which it would,
if the server closed the connection and IE pretended it was still
open and tried to use it. I suspect that's what's really happening,
but if you jump in in the middle you see that there's nothing on
the server end in the way of a connection and this unsynchronised
request packet appears out of the blue, _as if_ IE were skipping
the handshake -- but perhaps it really just never closed its end
of an earlier connection.
As far as whether that violates the TCP, you'd have to ask a TCP
guru, which I'm not. If it did violate TCP, I can easily believe
Microsoft might do it anyway, but I'm not ready to assume that it
violates the protocol without checking, since many protocols leave
room for behaviors that are not usually done, and it could be that
Microsoft followed the protocol in a different way from others.
Re:Cut n Paste (Score:2)
Remember: the same company that wrote MSIE wrote MS-Windows. Just because most normal programs aren't able to mess with TCP sequences doesn't mean that IE's programmers don't know something that we don't.
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:2)
Re:Cut n Paste (Score:1)
oh. you've just described "system administration" of any IIS server under load.
hang->reboot->repeat.
i had over 160 of the damn things under me in a previous life. i literally had monkeys running up and down the aisles pressing reboot on hung servers.
glad to be away from that fucking hell-hole.
Re:Cut n Paste (Score:1)
i thought it did?
Re:Cut n Paste (Score:2)
Of course, the connections would eventually time out, negating this effect to some extent. But I wonder how the hacks of standards play out into the general performance of the product.
Re:Cut n Paste (Score:1)
Medicine man speak (Score:2)
(You'll probably find that this is in your httpd.conf already).
Re:Cut n Paste (Score:1)
Re:Cut n Paste (Score:3, Funny)
A different take on it than the usual "Profit!!!"...
Client Server
1. SYN ->
2.
4. Request ->
Three, sir.
Three!
This is T/TCP. It is not a Microsoft Conspiracy. (Score:5, Informative)
RFC 1379 [rfc-editor.org] and RFC 1644 [rfc-editor.org] describe a mechanism for improving the performance of transactions in standard TCP, by avoiding the three-way handshake involved in TCP virtual-circuit establishment and teardown. The document was published over ten years ago, and has been implemented in several IP stacks. The article that this story linked to did not give enough detail to confirm that it was T/TCP he was looking at, but the sketchy description he gave was consistent with T/TCP.
The T/TCP Home Page [kohala.com] describes some early implementations (e.g. FreeBSD since 2.0.5).
From RFC 1379 (R. Braden, ISI, November 1992):
You can trivially turn on T/TCP in FreeBSD as follows (it is off by default):
Morals of this story:
Re:This is T/TCP. It is not a Microsoft Conspiracy (Score:2)
T/TCP available in Linux as well (Score:3, Informative)
http://www.csn.ul.ie/~heathclf/fyp/
Re:This is T/TCP. It is not a Microsoft Conspiracy (Score:2, Informative)
Re:This is T/TCP. It is not a Microsoft Conspiracy (Score:5, Informative)
From RFC 2026 [ietf.org]:
Note the striking lack of text describing how the IETF doesn't recommend protocols described by Experimental or Informational RFC documents.
This is NOT T/TCP (Score:5, Insightful)
The article is admitedly not very clear about what is going on. However, it seems to imply that the server resurrects a given TCP connection, and sends data with later sequence numbers than the FIN. That doesn't sound right.
It's also quite possible that the article is wrong or mischaracterizes the observed behavior. In particular, if IE really worked as described, you'd think people would have run into problems with certain stateful firewalls and NAT boxes.
I wish the article would elaborate a bit more on what goes on in step "1. Request".