1. TCP header format

  • Source Port: indicates the Port number for transmitting data over TCP
  • Destination Port: Port number corresponding to the Destination host for data transmission
  • Serial Number (Sequence Number) : Represents the offset of the data in the packet segment relative to all the data to be sent. (The data transmitted from the upper layer is usually segmented at the transport layer, so that if a packet segment is missing or in error, the sender only needs to transmit the corresponding packet segment (TCP error control). If the network layer or data link layer is segmented again, the whole data needs to be resend if an error occurs.)
  • Acknowledgement Number: Indicates the Sequence Number of the packet segment expected to be sent by the other party.
  • Data Offset: Indicates the Offset of the index Data in the entire TCP packet segment (that is, the length of the TCP header).
  • Control bits
    • URG(Urgent): indicates whether there is an Urgent situation. When the value is 1, the bytes of the Urgent pointer starting from Data Offset are preferentially sent
    • ACK(Acknowledgement): When the value is 1, the corresponding Acknowledgement number (ACK) indicates the serial number (SEQ) of the data expected to be sent next by the other party.
    • PSH(Push): When the PSH value is 1, the host that receives the packet delivers the data to the application as soon as possible, rather than waiting for the cache to be full before delivering it to the upper layer
    • Reset Flag (RST): When the value is 1, it indicates that the network status is bad and you need to release the connection and re-establish the connection
    • SYN(Synchronize Flag): When the value is 1, it indicates that a connection is set up with the peer party
    • FIN(Final Flag): Releases the connection
  • Window Size: the Size of the receive/send Window
  • Checksun: verifies TCP packet segments

2. Establish a connection (three handshakes)

  1. The client sends a connection request to the server (on the TCP header only): SYN = 1, ACK = 0, seq = x
  2. The server returns a message (on the TCP header only): SYN = 1, ACK = 1, SEq = y, ACK = x + 1
  3. The client returns a message (optionally with data) to the server again: ACK = 1, SEq = x + 1, ACK = Y + 1

Where x and y are randomly generated ISN (Initial Sequence Number)

2.1 Why does SEQ start with a random number instead of 1?

2.1.1 Data may be confused

  1. After the connection is established for the first time, host A sends data (SEQ = 1) to host B, and then disconnects
  2. After the second connection is established, the data sent from A to B reaches B, and B mistakenly thinks that the data is sent from A after the new connection is established

2.1.2 TCP Sequence prediction Attacks

If SEQ starts from A fixed value, as long as there is A listener monitoring the change of connection traffic of host A and host B, the corresponding SEQ value can be inferred and the data can be forged to impersonate A or B for communication

2.2 Why three handshakes instead of two?

2.2.1 The connection established by two handshakes cannot send data in both directions

  1. On the first handshake, the client sends a connection request (SYN = 1) to the server and sends its ISN(Initial Sequence Number) to the server (SEq = x).
  2. On the second handshake, the server sends the connection permission to the client (SYN = 1, ACK = 1), sends its ISN to the client (SEq = y), and tells the client that it is ready to receive the data from it (ACK = x + 1).
  3. On the third handshake, the client tells the server that it is ready to receive data (ACK = 1, ACK = y + 1)

Without a third handshake, data can only be sent from the client to the server, and the server cannot send data to the client (because the client is not ready to receive data from the server).

2.2.2 Two-handshake May cause server resources to be wasted

  1. A first sends A request to B for establishing A connection. Due to the network condition, the request sent by A does not reach B, so A does not wait for the response from B, so it sends A request to B for establishing A connection again
  2. User A’s second request to establish A connection is answered by user B. After user A and USER B send data to each other, the connection is disconnected
  3. B receives the request from A to establish A connection (the first request from A finally reaches B after the network delay), so it sends A confirmation of the connection to A. However, A does not think that it has sent A request to ESTABLISH A connection to B, so it ignores the confirmation of connection from B. B thinks he has established A connection with A, so he waits for the data sent from A. B’s resources are wasted

In the case of A three-way handshake, USER B sends A connection confirmation message to USER A and changes its state to SYN_RCVD. In this state, if no acknowledgement message from User A is received within A period of time (ACK = 1), user B sends A repeat acknowledgement message (SYN = 1, ACK = 1). If B does not receive an acknowledgement message from A (ACK = 1) after sending multiple acknowledgement messages (SYN = 1, ACK = 1), B sends an RST to A and disconnects

3. Release the connection

  1. A sends A FIN = 1 message to B indicating that it has no data to send and wants to disconnect. (After that, A does not actively send data to B.)
  2. B receives the disconnection message from A and replies (ACK = 1). But B might have data to send to A, so it didn’t send FIN = 1 to A
  3. After sending all data to A, B sends A FIN = 1 message to A, indicating that B also wants to disconnect. (If B receives A FIN = 1 message from A and has no data to send to A, B can directly send A FIN = 1, ACK = 1 message to A.)
  4. After receiving the message, A sends A confirmation ACK = 1 to B, B disconnects immediately after receiving the message, while A waits for 2MSL after sending and then disconnects (if data is received from B during this period, the time is reset to 2MSL).

3.1 why does A need to wait 2MSL before disconnecting?

This ensures that the data sent on this connection will not interfere with the next connection

MSL indicates the Maximum Segment Lifetime (default: 2 minutes). Waiting for 2MSL before disconnecting can ensure that the data sent by this connection will disappear into the network before disconnecting, without interfering with the next connection (sending data from A to B is one MSL, while the data sent from B to A is another MSL).