The Evolution of TCP
#sdas #webperf Like everything about the Internet, TCP keeps on changing.
In 1974 a specification was developed that would, eventually, launch what we know of as "The Internet." That specification was TCP and though it is often overshadowed by HTTP as the spark that lit the fire under the Internet, without TCP HTTP wouldn't have a (transport) leg to stand on.
Still, it would take 10 years before the Internet (all 1000 hosts of it) converted en masse to using TCP/IP for its messaging. Once that adoption had occurred, it was a much shorter leap for the development of HTTP to occur and then, well, your refrigerator or toaster can probably tell you the rest at this point.
That makes TCP 40 years old this year. And despite the old adage you can't teach an old dog new tricks, TCP has continued to evolve right along with the needs of the applications that rely so heavily on its reliable transport mechanism.
Consider the additions, modifications, enhancements and changes that have been made just in the past 20 years or so. In total, there are well over 100 different RFCs associated with TCP that offer ways to improve performance, or reliability or support new technology like mobile networks and devices.
Like SSL and even HTTP, TCP must continue to evolve. Unlike the Internet in 1984 which boasted a mere 1000 hosts, the ISC domain survey puts the number of hosts in Jan 2013 at well over 1 billion. That means to move to some other transport protocol we'd have to coordinate, well, more than seems humanly possible. Especially given that doesn't count the switch required on the client side - which numbers in the 2.4 billion range according to Internet World Stats, which tracks growth of Internet users world wide.
What this means, practically, is that TCP must evolve because we can't just move to something else. Not without a long term transition plan and we see how well that's working for the move to IPv6, despite the depletion of IPv4 addresses.
So it shouldn't be a surprise when new, TCP-related technologies like MPTCP (Multipath TCP) are introduced to address challenges that continue to crop up as new devices, networks and applications pop up like dandelions in your front yard. Nor should we be surprised when support for such protocols, like SPDY before it, are offered to the market with a transitional approach, i.e. gateways and dual-stack supporting proxies.
The only real way to support the use of what would otherwise be a disruptive technology without disrupting the billions of hosts and users that communicate each and every day is to provide strategic transitional protocol points of control that enable transparent and (one hopes) seamless support as hosts and devices begin to support it.
TCP isn't going anywhere, it's too critical to the entire Internet at this point. But that doesn't mean it's static or inflexible. It is constantly evolving to meet the needs of the next generation of devices, networks and applications that rely upon it.