More about TCP

Just finished the TCP course from INE  :

CCIE R&S: Understanding Transmission Control Protocol (TCP) 

Really recommend this to anyone who is interested in a bit deeper dive of how TCP works, great quality content, Keith Bogart is doing amazing job as instructor !


Some TCP facts which I didn’t mentioned in my previous post :

  • Before TCP connection is established TCP goes through the following steps:
  • Closed Initial State
  • Active Open (APP notifies the CPU and requests for service time) – client side
  • Transmission Control Block setup process  – CPU creates TCB to keep track of each new TCP connection – for each TCP session we create a new TCB with unique identifier (socket – SRC IP; SRC TCP Port; DST IP; DST TCP Port)
  • Initial sequence number will be random to prevent attacks on TCP
  • When TCB is ready we are sending SYN(x random Seq# number) – this is called a Syn Sent State
  • Receiving Syn(y random seq# number from server) + ACK (seq# x + 1)
  • Sending ACK(seq# y+1) for that
  • TCP Client side state changes to Established

This is Active Open – TCB creation process, initiated only per need of client.

Also we have Passive Open (server – listening process)


  • The initial state – closed
  • TCB creates partiality filled socket – so called unspecified passive open
  • From server is listening on specific port, when receives a SYN from client
  • Changes the state to Syn Received
  • Then responds with ACK and state changes to Established

A bit about Nagle  :

  • On by default on most of operating systems
  • When congestion occurs might be harmful – Storage vendors advising to disable it
  • Basically what Nagle does after getting the CPU time is gathers the data from Buffer and stores it – doesn’t send anything until we have a bytes on a flight  = unacknowledged bytes
  • If yes it will keep storing until his he has those unack bytes, after receiving ACKs for them it will send out multiple segments which we collected from buffer.


TCP checks the MTU and configures MSS accordingly. If we have a jumbo MTU 9216 MSS will be 9216 – 20 (IP Header) – 20 TCP header.

Relative Sequence Number in Wireshark and Subdisector

  • Wireshark by default shows not the real sequence numbers but the relative ones – this can be changed in menu
  • When troubleshooting HTTP long responds – be aware that by default Allow subdisector to reassemble TCP stream in Wireshark is enabled – which could bring a lot of confusion as it reasembles the packets and wait of full web page load, instead of getting the picture in 1ms you can see it wireshark as getting in 30 seconds, despite that there was no problem at all. Recomending to view a video on this :  Wireshark Tutorial Series #2. Tips and tricks used by insiders and veterans

Sequence Numbers 

  • Built to count the bytes in segment
  • When segment sent only with ACK without the data you might see that seq# is not incrementing – as there is nothing to count
  • Also it might increment even while empty – this called phantom byte – add +1 to seq#

About the Missed ACKs 

  • Not each sent segment will receive an ACK for it – might be we will be acking each 5 segments
  • RTO – Re-transmission timeout value – depends on RTT, also so called SRTT Smooth RTT – when we are comparing multiple RTT values and taking the average.
  • Why TCP is reliable ? Because before and after sending the Segment it puts it into the Re-transmission Queue and only after receiving an ACK it removes the segment from there.
  • Duplicate ACKs are appearing after one of the segments has been delivered but other one was lost – then we are repeating the last ACKed segment – selective repeat here comes into play with option field which helps to retransmit only what is missing.

Sliding Window Rules :

  • Bytes sent and acknowledged  – removing from retransmission queue.
  • Bytes sent but not yet acknowledged
  • Bytes not yet sent for which receiver is ready – usable window
  • Bytes not sent and receiver is not ready to receive them

Urgent Bit 

  • No priorities here, just flagging the segment about it’s urgency – TCP does nothing special here, only allows to upper layer APP to identify the urgent packet.
  • So no VIP delivery from the TCP side.
  • Urgent pointer field points to the first byte of non urgent data.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s