Transmission Control Protocol carries the vast majority of the data transmitted across both the public Internet and private intranets. Web sessions using HTTP, file transfers, file sharing and system backups typically use TCP. Windows desktop configurations loaded at start-up are TCP based.
However, if your system back-up is to a remote site that is a considerable distance away, you might be using only a small percentage of the bandwidth that you’re paying for. When your security cameras are transferring video to recorders that are remote or are using a wireless connection, the delivery could be slow or interrupted.
There are two primary reasons for poor TCP performance: significant delay (network latency) and network loss. Yes, TCP is designed to retransmit lost data segments, but they will probably be delayed. In the scenario of a long circuit, the resulting higher delay tells TCP that it must limit its rate of transmission so it won’t overwhelming the receiver’s buffer.
This problem is aggravated because most network analysis tools tell us that we have a TCP performance problem, but don’t tell us why it is happening. And we aren’t given suggestions for possible corrective actions.
Before digging deeper in this problem, let’s look at some things that may help improve TCP performance. We must keep in mind that TCP has a specific algorithm that controls its conduct. We can’t change it, but we can adapt in order to more efficiently use that algorithm.
+ ALSO ON NETWORK WORLD: 6 TED Talks that can change your career +
1. Boost the buffers
We need to reduce the likelihood of errors in the network that result in packet loss. Remember that wireless communication is prone to errors and those errors are usually invisible to network operators. Speak with your network device vendors to make sure that router and switch buffers are larger than the traditional 64k bytes, which were common in early wireless devices. Modern TCP implementations transmit much larger groups of segments than a 64k byte buffer can hold.
(Editor's Note: After this article was posted, we heard from readers who argued that the recommendation to increase buffers would tend to decrease TCP throughput due to a phenomenon known as bufferbloat. Much research on bufferbloat is underway. However, it is clear that it is not yet widely understood.)
2. Shorten the circuits
We must keep network circuits as short as possible, which is consistent with good business practices. Backups from New York to Philadelphia will happen much faster than backups from New York to Denver or New York to London, even if the available bandwidth and end systems are the same. In this situation a content delivery network (CDN) provider offers a significant advantage. They place the content closer to the user, decreasing network latency and increasing delivery performance.
3. Consider HTTP pipelining
If a task, such as a bulk file transfer, can be separated into two or more TCP sessions and transferred simultaneously, the available bandwidth will be used more efficiently. This is the idea behind HTTP pipelining. Many Netflix clients use this approach to quickly fill the playout buffer.
4. Update your stack
We should use the newest TCP stack whenever possible. Recent implementations of TCP work much better than the older versions. For example, Windows XP used a version of TCP commonly referred to as New Reno. Whereas, Windows 7/8 uses a newer release called Compound TCP. This version has a better reaction to segment loss and several other changes that help its performance. If you are a Linux user, make sure the version is at least 2.3.13. That’s when the TCP implementation called Cubic was introduced. Its performance, according to researchers, is similar to that of Compound TCP.
+ Why TCP/IP is on the way out +
5. Use a packet analyzer
Make sure that at least one person in the organization knows how to use a packet analyzer. They will be able to see that the client and server are negotiating the use of some of the newer options in TCP. Some of these are selective acknowledgement (SACK), windows scaling, and fast transmit. While the analyzer won’t tell you why these are important, it will establish that they are in use. This will point to the likelihood that newer TCP stacks are in both end systems.
By citing these five points, we don’t mean to give the impression that we can’t directly change the TCP algorithm. We can to a limited extent. For example, some research on Microsoft’s web site will reveal that we can change some parameters in the TCP stack.
However, we believe this can lead to as many problems as it can solve, especially if we don’t have the time to carefully test the changes before putting them into production. The steps we’ve suggested above are safe and could lead to significant benefits.
Where HTTP comes into play
Because of the heavy use of the browser, HTTP has also undergone some changes that affect throughput. The two that stand out are persistent connections and pipelining. Nearly all HTTP transfers are over TCP. It has become apparent that the time to set up a connection to issue a single HTTP 'get' request is often a significant portion of the time of the overall TCP connection.
When you account for the fact that a typical web page retrieval involves 50-100 individual 'get' requests, considerable time would be wasted if each happened in a separate TCP session, which was done in the original HTTP 1.0 specification.
The solution to this was the persistent connection, implemented in HTTP 1.1. If we couple this behavior with the ability to issue multiple 'gets' without waiting for each to be fulfilled, which is pipelining, we can affect the performance of HTTP significantly. The same lessons we learned with TCP apply as well to HTTP. Update the browser. The newest versions work best.
Much research has focused on which of these new TCP versions performs better. Summarizing all of this research is a daunting task but we can give some generalizations. Two things are usually considered in such research: How efficient is the version of TCP and how fair is it to other traffic that is competing with it? Most of the studies rate Cubic TCP higher on both factors than either New Reno or Compound TCP. Usually Compound TCP behaves a little better than New Reno TCP. But as more and more of us use the web from our mobile devices, don’t be surprised if TCP further evolves to meet the demands of wireless carriers.
Hippensteel is a professor, consultant and writer with over 40 years’ experience in higher education. He can be reached at pjhippen@centurylink.net.