Foundations of Python Network Programming 978-1-4302-3004-5

C H A P T E R 3
■ ■ ■
TCP
The Transmission Control Protocol (TCP) is the workhorse of the Internet. First defined in 1974, it lets
applications send one another streams of data that, if they arrive at all—that is, unless a connection dies
because of a network problem—are guaranteed to arrive intact, in order, and without duplication.
Protocols that carry documents and files nearly always ride atop TCP, including HTTP and all the
major ways of transmitting e-mail. It is also the foundation of choice for protocols that carry on long
conversations between people or computers, like SSH and many popular chat protocols.
When the Internet was younger, it was sometimes possible to squeeze a little more performance out
of a network by building your application atop UDP and choosing the size and timing of each individual
packet yourself. But modern TCP implementations tend to be very smart, having benefited from more
than 30 years of improvement, innovation, and research, and these days even very performance-critical
applications like message queues (Chapter 8) often choose TCP as their medium.
How TCP Works
As we learned in Chapter 2, real networks are fickle things that sometimes drop the packets you transmit
across them, occasionally create extra copies of a packet instead, and are also known to deliver packets
out of order. With a bare-packet facility like UDP, your own application code has to worry about whether
messages arrived, and have a plan for recovering if they did not. But with TCP, the packets themselves
are hidden and your application can simply stream data toward its destination, confident that it will be
re-transmitted until it finally arrives.
The classic definition of TCP is RFC 793 from 1981, though many subsequent RFCs have detailed
extensions and improvements.
How does TCP provide a reliable connection? It starts by combining two mechanisms that we
discussed in Chapter 2. There, we had to implement them ourselves because we were using UDP. But
with TCP they come built in, and are performed by the operating system’s network stack without your
application even being involved.
First, every packet is given a sequence number, so that the system on the receiving end can put
them back together in the right order, and so that it can notice missing packets in the sequence and ask
that they be re-transmitted.
Instead of using sequential integers (1,2,…) to mark packets, TCP uses a counter that counts the
number of bytes transmitted. So a 1,024-byte packet with a sequence number of 7,200 would be followed
by a packet with a sequence number of 8,224. This means that a busy network stack does not have to
remember how it broke a data stream up into packets; if asked for a re-transmission, it can break the
stream up into packets some other way (which might let it fit more data into a packet if more bytes are
now waiting for transmission), and the receiver can still put the packets back together.
The initial sequence number, in good TCP implementations, is chosen randomly so villains cannot
assume that every connection starts at byte zero and easily craft forged packets by guessing how far a
transmission that they want to interrupt has proceeded.
35