|
*********************
Recommended programs:
webROCKET
ActiveSpeed
Dr. Speed
TweakMASTER
Turbo
Surfer |
TCP/IP TweakingWhen the TCP/IP stack first appeared in Windows 95, people slowly learned that the default TCP/IP settings weren't optimized for wide-area networks. TCP/IP was originally included in Windows 95 for LANs, as the Internet had not quite begun to explode, so the defaults remained LAN-centric for quite some time. The setting in TCP/IP that gained the most attention was MTU, or the Maximum Transmission Unit. (In Windows, the MTU and other TCP/IP settings are stored in the Registry.) The MTU setting describes, in bytes, the largest possible TCP packet size. The default MTU size is 1500 bytes for Ethernet -- i.e., for LANs. On the Internet, however, the default MTU size is 576 bytes. Why the difference? LANs tend to run fast and furious (10Mbit/sec or 100Mbits/sec typically). Everything runs very quickly, with very low latency, so to get the most out of the system, the MTU size can be a little larger. The Internet is almost exactly the opposite -- at least, it's like that for dial-up users. Packet sizes have to be a little smaller, at least for dial-up users, so that traffic can be regulated a little more effectively. Almost every single one of the "tweak" programs I looked at for this story, some of which I'll discuss in detail later, featured the MTU as one of the settings they allowed you to edit. A common recommendation for dial-up users is to set the MTU to 576; for DSL people using PPPoE, 1400; for everyone else, 1500. Now, how effective altering the MTU setting is in boosting your connection speed is not something that appears to be very well established, partly because there are many other factors that people don't often take into account -- which ISP they're using, what brand of modem, the revision of their TCP stack, and so on. Also, MTU tends to be overshadowed by other settings -- like the TCP Receive Window Size. Any tweaking of network settings like MTU and other parameters I've specified below, should not be done lightly, and should never be done in a haphazard way. Unless you're a real expert, the best way to edit these settings is with the aid of an application, which can back up your settings and track changes you make so you can undo whatever you've done in the event it only makes things worse. We'll cover various connection tweaking applications later. The Receive Window Size is another TCP/IP setting that dictates how much data is received before the receiving computer sends back an ACK (acknowledgement) packet. The ack is a way of saying, "I got the data OK." If no ACK packet comes back after a certain interval, the packets that weren't ACKed get retransmitted. If you ramp up the TCP Window Size, the computer doesn't have to send quite as many ACK packets for the data received, and therefore can shave that much more latency and bandwidth off the connection. Now here's the bad news. A larger window size also means that much more data has to be retransmitted if an ACK packet doesn't make it back to the host. This is only something you need to worry about if you have a lot of errors in transmission, or if you're running on a dial-up connection (though errors in transmission across high-speed links with high latency can also waste a lot of time with retransmission of much data). A way to offset this, however, is to turn on Selective Acknowledgement, or SACK, in the TCP/IP protocol, which can confirm the receipt of specific non-contiguous packets in a data stream, rather than just a sequential series of packets up to the last good packet received chronologically in time. This forces the server to retransmit only the dropped packets, not the entire set of data from the point where the last good ACK was received. (A similar addition, called RFC 1323 Timestamps, forces each packet to carry a timestamp that helps derive round-trip metrics. Unfortunately, the overhead for each timestamped packet defeats a good deal of the optimizations this provides, so it's best left off.) The default Receive Window Size in Windows is 8K for Windows 95, 98 and NT. For Windows Me, 2000 or XP, it's 16K. (Most Linux distributions use a setting of 32-64K.) 16K is probably the upper limit of what you would want to use on a dial-up connection, but is at the low end of what to use if you're on a broadband link. Most broadband users should try anywhere from 32K to 64K and see what sort of results they get. The upshot of all this is not that the MTU is useless, but that it's hardly the only player in what can be a very complicated game. The Time To Live, or TTL, is a value that indicates how many hops a packet can traverse before it is considered lost or misrouted. The upper bound for this is 32 by default, and many routers will force a packet that comes in with a TTL higher than 32 to be dropped back to 32. There's no harm in setting it higher, but if it's simply scaled back by the routers on your ISP then it's pointless to change this. Some of the programs I experimented with recommended setting this as high as 128 -- probably not harmful in itself, though, but I could not verify that anything I was sending with a TTL that high was in fact being forwarded intact. Or more precisely, I couldn't insure that they were still using the TTL I had set, or were using a "truncated" TTL (like 32 or less instead of 128). Another setting that doesn't have a lot of affect on a client system is the Black Hole Detect function. The way Black Hole Detect works is a little complicated: it attempts to find out if there are routers out there that don't forward a key piece of packet information -- specifically, the "Don't Fragment" bit. If the Don't Fragment bit is set, then packets are sent through in sequence, and the MTU is decreased to allow faster transmission. Routers that don't forward this information will allow the TCP stack to increase the number of retransmission tries to compensate. Unless you are running a server or dealing with a relatively archaic network, this setting isn't going to make much visible difference, and can in fact waste bandwidth if it's enabled. It's disabled by default; I recommend you leave it off. One setting which can pay off for web browsing is MaxConnectionsPerServer. The HTTP 1.1 spec states that a client can only open up to two connections to a web server at a given time. If you change this setting, you can ramp that up -- the recommended upper limit for this is 4 -- but it won't make bandwidth magically appear. This is a recommended change for people on a good broadband connection, since it will allow you to make better use of the bandwidth you do have. Be warned that there may be web servers out there programmed not to allow more than two connections as a way of enforcing the spec and preventing connection-hogging. Why is this useful? For one thing, whenever we load a web page, the browser usually makes one connection to download the text of the page itself -- i.e. the .HTML file -- and another connection to fetch the images. If there are a lot of images, they load one at a time, and even on a fast connection this can take time. A machine with a high MaxConnectionsPerServer can open multiple connections to the remote server and download more than one image at a time, completing the page faster. (This is, of course, assuming the remote server accepts more than two connections from a single host.) If nothing else, it's worth trying, especially on a fast connection. Something else that can be done to accelerate many TCP-based activities is DNS caching. Whenever the system is asked to contact a particular domain name, it has to perform a DNS lookup on the name. Sometimes this is a time-consuming process, especially if your ISP has a slow DNS server. Since these addresses almost never change anyway, one way to speed things up is to locally cache DNS addresses. Many pros do this manually by adding entries to a HOSTS file on their system, but one of the applications profiled later in this article does the work for you intelligently. Some network proxying or Internet connection sharing applications will do this for you as well. A feature exclusive to Windows 2000 and Windows XP is the Quality of Service Packet Scheduler, a component of the TCP/IP stack that's installed by default. QoS, as it's commonly abbreviated, controls the rate of flow for various network services. It's not terribly useful unless you're using apps which are QoS-aware or running a server, so you can gain some network overhead back by turning it off. In the next section I'll look at some of the apps I've come across that let you modify various connection parameters, as well as applications that allow you to get other information about your connection.
|
