Ethan Banks On productivity.

OECG – Chapter 6 “TCP/IP Transport and Application Services” – TCP + UDP


Just before we get into routing in chapter 7, we’re going to review a few more “odds and ends”. In this chapter, we review the basics about the most commonly used transport protocols that ride on IP: TCP & UDP. In addition, we review FTP & SNMP (which I’ll hit in the next post).

For anyone who’s spent some quality time with a sniffer debugging Bad Application Behavior, this review of TCP may seem obvious. But the devil is in the details, as they say. So let’s get to it.

  • TCP, transmission control protocol, RFC 793, IP protocol 6.
    • Uses port numbers to identify various conversations or “sockets”, many of which can be going on at the same time.
    • Supports reordering data if the packets show up at the destination out of order.
    • Is considered a reliable or “connection-oriented” protocol. TCP sends acknowledgments for received data, will resend data that is not ACK’ed, based on the sequence and acknowledgment fields in the TCP header.
      • Remember that an ACK tells the sender what byte the recipient is expecting to see next. So, if an ACK is not received for the next bytes to be sent, that implies that the last group of bytes was not received, and needs to be send again.
      • Also, the senders keeps track of ACK’s through a timer. If a MRTT (measured round-trip time) timer expires, that will also tell the sender that the data needs to be sent again.
    • Supports flow control using sliding windows. Features congestion avoidance via an algorithm.
      • The concept of a “window” is that the recipient will advertise how many bytes of data he’ll accept at a whack before acknowledging. This is known as the “receiver’s window,” the “receiver’s advertised window,” or the “granted window”.
      • The sender can only send as many bytes as it takes to fill the window, and then must stop sending until an acknowledgment is received. This is a fail-safe for the receiver – it prevents his TCP stack from being overflowed with data from the sender.
      • The recipient can dynamically grow or shrink this byte window as needed.
      • The sender can also shrink the window for congestion avoidance, defined in RFC 2581 as a means of avoiding packet loss.
      • Therefore, you end up with a sliding window. The window slides between the window advertised by the recipient, and the RFC 2581 value computed by the sender, also known as the congestion window (CWND).
        • Once the 3-way handshake is complete, the CWND is set to a smallish value, often 1 maximum segment size (MSS).
        • If there’s no packet loss (i.e., all ACK’s are received in a timely fashion), CWND will grow exponentially using “slow start” logic.
        • When there’s packet loss, CWND is cut in half.
        • When the lost packets have been re-sent and ACK’ed, CWND goes back to growing via “slow start”.
        • However, once packet loss has occurred, the exponential growth of “slow start” will continue until CWND reaches half the size it was originally (the “slow start threshold”). Then CWND will grow more slowly, linearly now, using the “congestion avoidance” algorithm.
    • Conversations run through connections, where there’s a 3-way handshake to set up the connection, and 4-way finish to close the connection.
      • To create a connection, a host opens a sockets to a destination. He chooses a random source port on his side, sets the SYN code bit flag, and sets a starting sequence number.
      • The destination responds with an acknowledgment of the sequence number (ack=seq+1), starts his own sequence number, and sets the SYN and ACK code bit flags.
      • The host then responds with an acknowledgment of the destination’s sequence number, increments his own sequence number, and sets the ACK code bit.
      • SYN -> SYN/ACK -> ACK.
      • For a conversation completion or “connection termination”, the “by the book” method is ACK/FIN -> ACK -> ACK/FIN -> ACK. But from experience, I can tell you that a lot of TCP stacks will consider a single “FIN/ACK” with a responding “ACL” enough to close the connection.
    • TCP header is 20 bytes.
      • source port, 2 bytes. (These aren’t source IP addresses, remember – that’s a job for the IP header.)
      • destination port, 2 bytes.
      • sequence number – 4 bytes.
      • acknowledgment number – 4 bytes.
      • offset (HLen) – 4 bits. Multiply this value by 4, and you get the TCP header length in bytes.
      • Res. – 6 bits.
      • Code bits – 6 bits.
        • SYN – part of the 3 way handshake connection establishment
        • ACK – acknowledgment
        • PSH – push is used by a sender to tell the receiver that data is coming and to send that data to the application
        • URG – urgent allows the sender to prioritize the packet over other packet perhaps recently received. The TCP stack is to send this packet to the application ahead of anything that might be sitting around in a buffer.
      • Window – 2 bytes.
      • Header checksum – 2 bytes. Computed against the header itself, not the header and the data.
      • Urgent pointer – 2 bytes. Used in conjunction with the URG code bit, this defines just how much data is of an urgent nature.
      • Options and padding – a multiple of 4 bytes.
  • UDP, user datagram protocol, RFC 768, IP protocol 17.
    • Uses ports, just like TCP.
    • Does not order data. If packets arrive out of order, you’re out of luck.
    • Is not reliable. There’s no ACK’ing of data.
    • Does not support flow control or congestion avoidance. (Anyone remember trying to stream RealAudio via UDP back in the 90’s over a 14.4Kbps dial-up? And do you remember agonizing over whether to spend the extra money on a 14.4K vs. a 9600 baud like everyone else had? Ah…the bad ol’ days…)
    • UDP header is 8 bytes (much less needed information than TCP, since TCP is doing a lot more with acknowledgments, sequence, and so on).
      • source port – 2 bytes
      • destination port – 2 bytes
      • message length – 2 bytes
      • header checksum – 2 bytes
By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.