introduce

In the network layer, the communication between two hosts can be realized through the IP protocol, but it is impossible to determine which process in the host is the communication, and the actual and performance communication is the process in the host.

<! — more –>

TCP connection-oriented service in which a connection must be established before data can be transmitted and released after data transmission is complete. Therefore, TCP is a reliable transportation service, but because of this, it inevitably adds a lot of overhead, such as verification, flow control, etc. The corresponding application layer protocols are SMTP,TELNET,HTTP,FTP and so on. TCP regards connection as the most basic object. Each TCP connection has two endpoints. This kind of breakpoint is called a socket, which is defined as a socket formed when the port number is concatenated with the IP address. The resulting socket is 127.0.0.1:80. TCP uses full duplex communication, which requires that both the server and the client must be able to send data to each other, so the connection must be established or disconnected twice.

TCP packet

  1. Source port and destination port: Write to the source port and destination interface, respectively.
  2. Serial number: Four bytes, each byte of the byte stream transmitted in a TCP connection is numbered sequentially. At current 301, if 100 bytes have been transmitted, the next segment starts at 401.
  3. Confirmation number: 4 bytes. It is the ordinal number of the first byte of data that is expected to receive the other party’s next message.
  4. Data offset: Four bits (half a byte), which indicates how far the data of a TCP packet is from the beginning of a TCP segment.
  5. Reserved position: occupy 6 bits, reserved for future use, but at present should all be 0 bits.
  6. Urgent Urg: When URG=1, the Urgent Pointer field is valid. Tell the system that there is emergency data in this message segment.
  7. Acknowledge ACK: The confirmation number field is only valid if ACK=1. TCP specifies that all packets transmitted after the connection is established must have ACK set to 1.
  8. Push PSH: When two application processes communicate interactively, sometimes the application process on one end expects to receive a response immediately after typing a command, and PSH=1 is set.
  9. Reset RST: When RST=1, there is a serious error in the TCP connection. The connection must be released and then re-established.
  10. Synchronize SYN: Used to synchronize serial numbers when a connection is established. When SYN=1 and ACK=0, it indicates the connection request message. If the connection is approved, the response message should be SYN=1 and ACK=1.
  11. Terminate FIN: Used to release the connection. When FIN=1, it indicates that the data of the sender of the message has been sent and it is required to be released.
  12. Window: 2 bytes, which notifies the recipient how much space you need to send the text to receive.
  13. Checksum: 2 bytes, verifies the header and data parts.
  14. Emergency pointer: 2 bytes, indicating the number of bytes of emergency data in this paragraph.
  15. Options: The length is variable, and some other optional parameters are defined.

TCP connection establishment (three handshakes)

  1. The server enters its LISTEN state by creating a transport control block that is ready to Listen for connection requests from client processes.

  2. The client also establishes the transmission control block and sends the connection request message to the server, at which point the client enters the SYN-SENT state.

    TCP specifies that a SYN segment (SYN=1)
    Cannot carry data, but consumes a sequence number.


    The contents of the packet are SYN=1, seq=x.

  3. After the server receives the request, if it agrees to connect, it issues an acknowledgement message, at which point the server enters the SYN-RCVD state (Synchronously Receive).

    This message also cannot carry data and consumes a serial number.


    SYN=1,ACK=1,seq=y, ACK= x+1 Seq is the serial number sent by itself, and ACK is X + directly because the last sent connection request message did not contain data.

  4. After the client process receives the acknowledgement, it also gives the acknowledgement to the server. After confirmation, the TCP connection is ESTABLISHED and the client enters the ESTABLISHED state.

    TCP specifies that an ACK segment may carry data, but does not consume a sequence number if it does not carry data.


    ACK=1,seq=x+1, ACK= y+1; This is the second request from the client to the server as opposed to the synchronous request, with all seq being x+1.

  5. When the server receives the client’s acknowledgement, it also enters the ESTABLISHED state, after which the two parties can begin to communicate.

Disconnection of TCP connection (quadruple recovery)

  1. The client sends the connection to release the message, stops sending the data, and enters the FIN-WAIT-1 state (terminates WAIT 1).

    TCP specifies that a FIN segment consumes a serial number even if it does not carry data. Similar to a SYN message segment.


    The contents of the packet are FIN=1,seq=u. The sequence number here follows the sequence number of the previous data, adding one to the sequence number of the last byte of data.

  2. The server receives the connection release message and sends its own release message. The server enters a close-wait state.

    The TCP server notifies the high-level application process, and the client is released in the direction of the server. At this time, the client is in a semi-closed state, that is, the client has no data to send, but if the server sends data, the client still needs to accept it. This process takes some time, waiting for the server to finish sending the data.


    ACK=1, SEQ = V, ACK= U +1.

  3. After receiving the release confirmation from the server, the client enters the FIN-WAIT-2 state and waits for the server to send the connection release message. During this process, the client will continue to receive the data content sent by the server.

  4. After the server sends the data, it sends the connection release message to the client, and the server enters the last-ack state, waiting for the final confirmation.

    In the last procedure, the client will not send information to the server, so ACK remains the same, while the server will send information to the client, so SEQ will change.

  5. After the client receives the release of the connection, it issues an acknowledgement to the server and enters the time-wait state.

    Note that the TCP connection has not been released at this time. It must be CLOSED after 2*MSL (the longest lifetime of the message segment), when the client revokes the corresponding TCB.


    ACK=1, SEQ = U +1, ACK= W +1.

  6. After receiving the confirmation information, the server will enter the state of Closed immediately, revoke the TCB and end the connection.

Pop a bit

Here’s an example:

  • Party A: Hello, this is Party A, can you hear me?
  • Party B: Hello, can I hear you, this is Party B, can you hear me? < Party A receives, Party A establishes connection to >
  • Party A: I can hear you. < Party B receives, Party B establishes connection to >
  • The connection is made, and the fight begins.
  • Party A Party B:… (in dispute).
  • Party A: I’m done. That’s all.
  • Party B: You have said all right, I will say one last thing.
  • Party B:… Party B’s approval is in demand.
  • Party B: I’m done. Let’s hang up.
  • Party A: OK, hang up. < Party B received it, and Party B hung up >
  • Party A: {wait for a return time, he should have received}. < Party A hung up >

A little problem

Why does the TCP client send an acknowledgement at the end? (Why not 2 handshakes)

To prevent the network jitter caused by various reasons for the connection request, and suddenly sent to the server, resulting in errors. Under the condition of using two shake hands, assuming that the first connection request blocked in the network, the server did not receive the client’s request message will not processing, the client has not receive confirmation will think server did not receive, will resend the request, then the client and server to complete shake hands, the connection is established. Problems arise when the first request that is blocked in the network suddenly arrives at the server.

If the connection is established after the complete data and closing the connection, will be to establish a connection problems, and use three times handshake, even if the server received a wrong connection requests and send the confirmation, but there is no need to transfer the client data, not for the third handshake operation, won’t be a problem.


If an incorrect connection request is received while the data is being transmitted, the handshake will not be made a third time, even if the confirmation is made. (To be discussed here)

Is the server vulnerable to SYN attacks?

Server resources are allocated on the second handshake, while client resources are allocated on the third handshake. Therefore, the server is vulnerable to SYN flood attack, which is to forge a large number of non-existent IP in a short period of time, and constantly send SYN packets to the server. The server will reply and wait for the acknowledgement packet, but the source address is fictitious, so it will not receive the acknowledgement packet, so the server will continue to resend and retry until the timeout. These bogus SYN packets will occupy a large number of unconnected queues for a long time, causing normal requests to be discarded, causing a network crash. Unconnected footprint can be released by reducing the host’s wait time, or repeated SYN packets received for an IP within a short time will discard subsequent requests.

Why does the client wait for 2MSL at the end?

Ensure that the last ACK message from the client reaches the server. If the ACK is not received by the client, it will be considered that the server did not receive the FIN request sent by the client, and then it will resend the FIN request. For the client, after receiving the FIN request, it sends the ACK confirmation information. If the server does not receive the ACK information, it will send the FIN request again, and the client will receive the FIN request again. If the client does not receive the FIN request again, it can disconnect the connection as there is no problem.

What if the connection is established, but the client suddenly fails?

TCP has a conservator, and the server will reset the timer every time it receives data. If the timer runs out and no data is received from the client, the server will send a probe message. If a probe message is sent in 75 seconds and no recovery is received after 10 consecutive probes, the client will be considered to have failed and the connection will be disconnected.

Why four waves instead of three or five?

Wave the second and third wave is the server to the client sends a message that the second wave were the server received the client’s disconnect request, inform the client received, at this time the client without the data sent to the server, but do not represent the service side also have no data is sent to the client, because the server to the rest of the haven’t send a message is sent to disconnect; The third wave is when the server sends all the data and sends the disconnect request message (FIN=1) to the client. If you combine these two, the server will acknowledge the request immediately and disconnect, resulting in incomplete data sent by the server to the client. Five times is not necessary.

What is three connections and four disconnects?

The reason why the disconnection is four is the same as the answer to the problem above. For establishing a connection, three times is actually the minimum number of times a reliable connection can be established. Refer to the first question. Because when the server receives the client’s SYN connection request message, it can directly send the SYN+ACK message. ACK message is used for reply and SYN message is used for synchronization. However, when closing the connection, when the Server receives the FIN message, it may not close the connection immediately, so it can only reply an ACK message first, telling the client, “I received the FIN message you sent”. I can only send FIN message when all the messages of my server end have been sent, so they cannot be sent together. So you need a four-step handshake. Four waves, instead of three handshakes, split the ACK+SYN message back to the client into two sends.

This article by the blog multiple platform
OpenWriteRelease!