Misc 50

Today I'm in the mood for some protocol analysis. We'll take a look at the TCP protocol. I'm not going to tell you again that TCP stands for Transmission Control Protocol and it is connection-oriented and reliable, but I just did.
You're probably familiar by now with how a TCP connection initiates. The first three packet of a connection is used to synchronize the sequence numbers. This is also known as the Three-Way Handshake. The Three-Way Handshake goes like this:

Client                              Server
|                 ISNc=500, SYN --> |
| <-- ack="" acks="501," br="" isns="2000," syn="">|                ACKc=2001, ACK --> |

This is all we know, don't we? What happens after that? Now, here's where I fill you in. From this point onwards, all packets will have the ACK bit set. The initiator usually begins sending data now. For example, if we're connecting to a web server, than the initiator would be sending a GET request as the first packet.

This is how TCP works: Whenever TCP receives a packet, it does not immediately send it to the application. TCP actually buffers and reassembles the data while waiting for a packet with the PSH bit. The PSH bit, which stands for Push, actually tells the protocol to send the assembled data to the upper layers (which in this case, only means the application).

A GET request is pretty small, so a single TCP segment would suffice. Therefore, you would notice that the first GET request is actually flagged as ACK and PSH at the same time.

Source: 192.168.1.150
Destination: 209.85.132.104
TCP: ACK, PSH
SEQ: 1
ACK: 1
Total Size (including headers): 958 Bytes

After a PSH, the receiving end would send a blank ACK to signal that it has successfully received and reassembled the entire sequence.

Destination: 209.85.132.104
Source: 192.168.1.150
TCP: ACK
SEQ: 1
ACK: 959
Data: None
Total Size (including headers): 0 Bytes

Now, as a website cannot fit into a single TCP segment, here is where things get interesting. The data is actually sent by chunks, with the last chunk flagged with PSH:

Destination: 209.85.132.104
Source: 192.168.1.150
TCP: ACK
SEQ: 1
ACK: 959
Data: None
Total Size (including headers): 1430 Bytes

Destination: 209.85.132.104
Source: 192.168.1.150
TCP: ACK
SEQ: 1431
ACK: 959
Data: None
Total Size (including headers): 1430 Bytes

Destination: 209.85.132.104
Source: 192.168.1.150
TCP: ACK, PSH
SEQ: 2861
ACK: 959
Data: None
Total Size (including headers): 1008 Bytes

The last three packets actually represent the returned web page in gzip compressed format! Notice that the ACK number is the same through the three packet as the client hasn't communicated with the server. Guess what's the next packet? Well, if you said a blank ACK, you're right! And if you guessed that the ACK number is 3869 (2861+1008), you'd also be right!

Destination: 192.168.1.150
Source: 209.85.132.104
TCP: ACK
SEQ: 3869
ACK: 959
Data: None
Total Size (including headers): 0 Bytes

Now if you're wondering why it isn't 3870 instead, it is because the first byte sent is the 2861th byte, so the 1008th byte would be the 3868th byte sent, therefore the next sequence would be 3869.

When a server sends a packet with TCP Sequence 1 with a payload of 3 bytes, the first byte is the first sequence, so the third byte is third sequence, therefore the Acknowledgment would be 4. Therefore, Next ACK = Sequence + Payload Size in Bytes.

The volley continues in the same manner:
-ACKc Data
-ACKc Data
-ACKc Data
-ACKc PSHc Data
-ACKs
-ACKs Data
-ACKs Data
-ACKs PSHs Data
-ACKc
-...

TCP connections are terminated one way. This means that even if one side sends a FIN, the other side can continue to send data and the finished side can still receive until the sending side sends a FIN as well.

If one side has finished, while the other side has not, it is considered a half-open connection as well. Termination can be completed with a Four-Way Handshake:
1) FIN
2) ACK
3) FIN
4) ACK

Or, it can be completed with a Three-Way Handshake:
1) FIN
2) FIN ACK
3) ACK