TCP questions

Hello! Here are some questions & answers. The goal isn't to get all the questions "right". Instead, the goal is to learn something! If you find a topic you're interested in learning more about, I'd encourage you to look it up and learn more.

does every TCP packet have a source/destination IP address?

yes!

here's how a TCP packet is structured (if it's sent over Ethernet): 

+-+-+-+-+-+-+-+-+--
| Ethernet header |
+-+-+-+-+-+-+-+-+--
| IP header       |
+-+-+-+-+-+-+-+-+--
| TCP header      |
+-+-+-+-+-+-+-+-+-+
| packet contents |
+-+-+-+-+-+-+-+-+-+

that's why we call it "TCP/IP" -- TCP packets basically always have an IP header.

does every TCP packet have a port number in it?

yes!

The port field in the TCP header is 16 bits.

what's the first packet that gets sent in a TCP connection?

a SYN!

Every TCP connection starts with this 3-way handshake:

  • client: SYN
  • server: SYN + ACK
  • client: ACK

if a firewall is blocking your connection, can the TCP handshake finish?

no!

a very common symptom of a firewall issue is seeing SYN packets being sent but no ACK being sent back.

does email
use TCP?

yes!

email is sent over SMTP, which uses TCP

FTP, POP3, HTTP/1, HTTP/2, websockets, and a bunch of other Internet protocols also use TCP

are TCP connections two-way? (can both the client & server send messages?)

yes!

An HTTP request/response is a single TCP connection -- the client sends a HTTP request, then the server sends a response.

if the server sends a reply to the client, can the client send more data?

yes!

For example, websockets use TCP to let the client and server send data back & forth as much as they want.

if you send a long message over TCP, is it split into multiple packets?

yes!

packets always have a maximum size (often 1500 bytes), so often a TCP message needs to be split into many packets

when you send TCP packets, will the packets always arrive at the destination computer in the order you sent them?

no!

there's no guarantee that network packets will arrive in the order you sent them.

where's the code that's responsible for understanding the TCP protocol?

usually in your operating system!

Linux, Mac, Windows, etc all have TCP implementations. Almost any networking code you run on a desktop computer is going to use the OS's TCP implementation.

If you want, you can write your own TCP implementation though!

which field in the TCP packet does your OS use to put packets in the correct order?

the sequence number!

Every packet's sequence number tells you its position in the overall stream. The sequence number counts bytes, not packets. Here's an example set of packet contents & sequence numbers (each character is 1 byte): 

+-+-+-+-+-+-+-+-+-+-+-
| contents   | seq # |
+-+-+-+-+-+-+-+-+-+-+-
| hello  I   |   0   |
+-+-+-+-+-+-+-+-+-+-+-
| pple!      |   17  |
+-+-+-+-+-+-+-+-+-+-+-
| 'm a pinea |   7   |
+-+-+-+-+-+-+-+-+-+-+-

when put in the correct order, these packets rearrange to "hello I'm a pineapple!"

do sequence numbers always start at 0?

no!

usually the first sequence number in a connection is a big number like 1737132723, and all the other sequence numbers are relative to that number. So you have to subtract the first sequence number.

If you look at TCP packets in Wireshark/tcpdump they'll do the subtraction to make it look like the sequence number starts at 0 so it's easier to read.

if you send a TCP packet, how can you tell it was received?

you receive an ACK!

For example, if a server has received a packet with sequence number 1200 and has also received all the earlier packets, it'll send an ACK packet with the sequence number set to 1200.

are TCP packets that get dropped retried?

yes!

if the client (or server) doesn't get an ACK for a packet it sent within a certain amount of time, it'll retry sending the packet.