Summary of TCP and UDP

Reference article

35 illustrations: TCP three-way handshake and four waved hands that have been asked thousands of times. The interview questions are
easy to understand and explain the TCP flow control mechanism, and learn about
TCP congestion control (detailed explanation)

What is TCP

TCP is a connection -oriented , reliable, orderly, byte stream- based transport layer communication protocol.

  1. Connection-oriented: It must be "one-to-one" to connect. It can't be like UDP protocol that one host can send messages to multiple hosts at the same time, that is, one-to-many is not possible;
  2. Reliable: No matter what kind of link changes occur in the network link, TCP can guarantee that a message will reach the receiving end;
  3. Byte stream: Messages have "no boundaries", so no matter how big our messages are, they can be transmitted. And the message is " ordered ". When the "previous" message is not received, even if it receives the next byte first, it cannot be thrown to the application layer for processing. At the same time, the "duplicate" message will be processed. Automatically discarded.

Why do we need TCP protocol? On which layer does TCP work?

The IP protocol at the network layer is "unreliable" and it does not guarantee data integrity. If you need to ensure the reliability of network data packets, then the upper layer (transport layer) TCP protocol is responsible.

Basic understanding of TCP

TCP provides full-duplex services for the application layer, which means that data can be transmitted independently in two directions.

TCP will communicate three times before transmission, which is generally referred to as the "three-way handshake". When the data is disconnected, it must communicate four times, which is generally referred to as the "four waves of hands".
Insert picture description here

  1. Source port number (16 bits): It (along with the source host IP address) identifies an application process of the source host

  2. Destination port number (16 bits): It (along with the destination host IP address) identifies an application process of the destination host

  3. Sequence number seq (32 bits): The random number generated by the computer when the connection is established is used as its initial value, and is transmitted to the receiving host through a SYN packet. Each time data is sent, the "data byte number" is "accumulated". size. Used to solve the problem of network packet disorder .

  4. Acknowledgment number ack (32 bits): Refers to the serial number of the data received next "expected". Therefore, the confirmation sequence number should be the byte sequence number of the last successfully received data plus 1. The confirmation sequence number field is valid only when the ACK flag is 1. After the sender receives this confirmation response, it can be considered that the data before this sequence number has been received normally. Used to solve the problem of no packet loss .

  5. Header length (4 bits): The length of the optional field is variable, so this value is needed to indicate the overall length of the header, which is convenient for fetching data (where does the data start). This field occupies 4 bits, so TCP has a 60-byte header at most. However, there is no optional field, and the normal length is 20 bytes.

  6. Reserved bits (6 bits): reserved for future use, must be set to

  7. Control bit:

    SYN: Synchronization sequence number, 1 means connection request, used to establish a connection and synchronize the sequence number (synchronize)
    ACK: 1 means the confirmation number is valid, 0 means the message does not contain confirmation information, and the confirmation number field is ignored.
    FIN: Used to release the connection, 1 means that the sender has no data to send, that is, close the data stream of the local party.

  8. Window size (16 bits): number of data bytes

  9. Checksum (16 bits): This checksum is calculated on the entire TCP message segment, including the TCP header and TCP data, in a 16-bit word. Used for data security verification at the receiving end.

  10. Data: Specific data is optional. When a connection is established and a connection is terminated, the message segment exchanged by both parties has only the TCP header. If one party has no data to send, the header without any data is also used to confirm the received data. In many cases of processing timeouts, segments without any data will also be sent

How to uniquely determine a TCP connection

Source address + source port and destination address + destination port can uniquely determine a connection

The source address and destination address fields (32 bits) are in the IP header, and the function is to send messages to the opposite host through the IP protocol

The source port and destination port fields (16 bits) are in the TCP header, which tells the TCP protocol to which process the message should be sent

TCP three-way handshake

Insert picture description here

  1. The first handshake: Host A sends a bit code of syn=1, and randomly generates a data packet with seq number=1234567 to the server. Host B
    knows by SYN=1 , and A requests to establish a connection;
  2. The second handshake: Host B needs to confirm the connection information after receiving the request, and send ack number=(seq+1 of host A), syn=1, ack=1, randomly generate seq=7654321 packet
  3. The third handshake: Host A checks whether the ack number is correct after receiving it, that is, the first sent seq number+1, and the bit code ack is 1, if it is correct, Host A will send another ack number=(Host B’s seq+1),ack=1, host B confirms the seq value and ack=1 after receiving it, the connection is established successfully.

Why is the initial serial number ISN of the client and server different?

  1. If a failed connection is reused, but the historical message of the old connection still remains in the network, if the sequence number is the same, then it is impossible to tell whether the message is a historical message or not. If the historical message is new If the connection is received, data will be corrupted. Therefore, reinitializing a sequence number each time before establishing a connection is mainly for the two parties in communication to discard the segments that do not belong to the connection according to the sequence number.
  2. On the other hand, for security, to prevent hackers from forging TCP packets with the same serial number from being received by the other party.

Why is TCP a three-way handshake? Not twice or four times

Reason 1 : The three-way handshake can ensure that both parties have the ability to receive and send.

TCP provides full-duplex services for the application layer, which means that data can be transmitted independently in two directions. Both parties need to confirm that the other party has the ability to receive and send.
Insert picture description here
Reason two : avoid historical connection

The network environment is intricate and complicated. It is often not as expected. The data packet sent first arrives at the target host first. On the contrary, it is very messy. It may be messy due to network congestion and other reasons, which will make old data packets first. To reach the target host, how to avoid the TCP three-way handshake in this case?
Insert picture description here

If it is a two-way handshake connection, it is impossible to determine whether the current connection is a historical connection. For a three-way handshake, when the client (sender) is about to send the third message, the client has enough context to determine whether the current connection is Historical connection:

  1. If it is a historical connection (serial number expired or timed out), the message sent in the third handshake is an RST message to terminate the historical connection;
  2. If it is not a historical connection, the message sent for the third time is an ACK message, and the communication parties will successfully establish a connection;

Reason 3 : Synchronize the initial serial numbers of both parties

Both communication parties of the TCP protocol must maintain a "serial number". The serial number is a key factor for reliable transmission. Its function:

  1. The receiver can remove duplicate data;
  2. The receiver can receive in order according to the sequence number of the data packet;
  3. It can identify which of the sent data packets have been received by the other party;

It can be seen that the sequence number occupies a very important role in the TCP connection, so when the client sends a SYN message carrying the "initial sequence number", the server needs to return an ACK response message, indicating that the client's SYN message has been After being successfully received by the server, when the server sends the "initial serial number" to the client, it still has to get the response from the client. This way, the initial serial numbers of both parties can be reliably synchronized.

Insert picture description here
The four-way handshake can actually synchronize the initialization sequence numbers of both parties reliably, but since the second and third steps can be optimized into one step, it becomes a "three-way handshake."

The two handshake only ensures that the initial serial number of one party can be successfully received by the other party, and there is no way to ensure that the initial serial number of both parties can be confirmed and received.

summary

When TCP establishes a connection, the three-way handshake can ensure that both parties have the ability to receive and send, prevent the establishment of historical connections, and help both parties to synchronize the initialization sequence number.

The sequence number can ensure that data packets are not repeated, discarded, and transmitted in order.

Reasons for not using "two handshake":

  1. It is impossible to ensure that both parties have the ability to receive and send, to prevent the establishment of historical connections, and to reliably synchronize the serial numbers of both parties;

Reasons for not using the "four-way handshake":

  1. The three-way handshake is theoretically the least reliable connection establishment, so there is no need to use more communication times.

Basic understanding of UDP

UDP does not provide a complicated control mechanism, and uses IP to provide a "connectionless" communication service.

The UDP protocol is really simple, the header is only 8 bytes (64 bits), and the format of the UDP header is as follows:
Insert picture description here

  1. Destination and source ports: mainly to tell the UDP protocol to which process the message should be sent.
  2. Packet length: This field stores the sum of the length of the UDP header and the length of the data.
  3. Checksum: Checksum is designed to provide reliable UDP header and data.

The difference between TCP and UDP

  1. connection

    TCP is a connection-oriented transport layer protocol, and a connection must be established before data transmission.
    UDP does not need to be connected and transmits data immediately.

  2. Service object

    TCP is a one-to-one two-point service, that is, a connection has only two endpoints.
    UDP supports one-to-one, one-to-many, and many-to-many interactive communication

  3. reliability

    TCP delivers data reliably, and the data can arrive in sequence without errors, loss, repetition, and order.
    UDP is a best-effort delivery and does not guarantee reliable delivery of data.

  4. Congestion control, flow control

    TCP has congestion control and flow control mechanisms to ensure the security of data transmission.
    UDP does not. Even if the network is very congested, it will not affect the sending rate of UDP.

  5. Head overhead

    The length of the TCP header is longer, and there will be a certain amount of overhead. The header is 20 bytes when the "option" field is not used, and it will become longer if the "option" field is used.
    The UDP header has only 8 bytes, and it is fixed, and the overhead is small.

  6. transfer method

    TCP is streaming, without boundaries, but it guarantees order and reliability.
    UDP is a packet-by-packet transmission. There are boundaries, but packet loss and disorder may occur.

  7. The shards are different (not very understanding)

    If the TCP data size is greater than the MSS size, it will be fragmented at the transport layer. After the target host receives it, it will also assemble TCP packets at the transport layer. If a fragment is lost in the middle, only the missing fragment needs to be transmitted. .

    If the UDP data size is greater than the MTU size, it will be fragmented at the IP layer. After the target host receives it, it will assemble the data at the IP layer and then transmit it to the transport layer. However, if a fragment is lost halfway, it will be required Retransmit all data packets, so the transmission efficiency is very poor, so usually UDP packets should be smaller than MTU.

Why does the UDP header have no "header length" field, but the TCP header has a "header length" field?

The reason is that TCP has a variable-length "option" field, while the length of the UDP header does not change, and there is no need for one more field to record the length of the UDP header.

TCP connection lost

TCP disconnection takes four times. This is caused by the half-close of TCP. Because the TCP connection is full duplex (that is, data can be transmitted in both directions at the same time), each direction must be closed separately when closing. This one-way closing is called semi-close. When one party completes its data sending task, it sends a FIN to notify the other party that
the connection in this direction will be terminated . The party that shuts down first will execute the active shutdown, and the other party will execute the passive shutdown

  1. Close the connection from the client to the server: First, client A sends a FIN to close the data transmission from the client to the server, and then waits for the server's confirmation. The termination flag bit FIN=1, the sequence number seq=u
  2. When the server receives this FIN, it sends back an ACK with the acknowledgment number plus 1 for the received sequence number. Client A receives the ack to verify whether it is correct (u+1) and close the connection correctly.
  3. Close the connection from the server to the client: it also sends a FIN to the client.
  4. After receiving the FIN, the client segment sends back an ACK message confirmation, and sets the confirmation sequence number seq to the received sequence number plus 1.
    Insert picture description here
    After host A sends the FIN, it enters the termination waiting state. After server B receives the connection release message segment from host A, it immediately sends an acknowledgement to host A, and then server B enters the close-wait state. At this time, the TCP server process informs the higher layer The application process, and thus the connection from A to B is released. At this time, it is "half-closed". That is, A cannot be sent to
    B, but B can be sent to A.

At this time, if B has no datagram to send to A, its application process will notify TCP to release the connection, and then send to A connection release segment, and wait for confirmation. After A sends the confirmation, it enters time-wait. Note that the TCP connection has not been released at this time, and then waits for the 2MSL set by the timer before A enters the close state.

Why does TCP need to wave four times

It can be seen from the above process that the server usually needs to wait for the completion of the data transmission and processing, so the ACK and FIN of the server are generally sent separately, which is one more time than the three-way handshake.

Why TIME_WAIT wait time is 2MSL

MSL is the Maximum Segment Lifetime, and the maximum survival time of a message >= the propagation time of one data transmission.

If the passive closing party does not receive the last ACK message of the disconnection, it will trigger a timeout retransmission of the Fin message. After the other party receives the FIN, it will resend an ACK to the passive closing party.
There are exactly 2 MSLs in and out.

The time of 2MSL starts when the client sends ACK after receiving FIN. If within the TIME-WAIT time, because the client's ACK has not been transmitted to the server, and the client receives the FIN message retransmitted by the server, the 2MSL time will be counted again.

TCP control flow

Phenomenon: When the rate at which the originator sends data is greater than the rate at which the receiver processes the data, the receiver does not process the data in time, and the receiver's data buffer space will become full over time. At this time, the sender still sends data, and the receiver will lose the data, causing a waste of network resources.

Insert picture description here
the term:

接收窗口:接收方的缓存区的剩余空间;
发送窗口:发送方的发送数据大小;

Solution: The receiver will return to its own receiving window size win each time after receiving data, and the sender will adjust the sending window according to the size of the receiving window to keep the balance between receiving and sending.

See detailed article easy to understand explanation TCP flow control mechanism, to find out

Insert picture description here

TCP congestion control

Phenomenon: The demand for a certain resource in the network exceeds the available part that the resource can provide, and the network performance will deteriorate. This situation is called network congestion. Bandwidth, buffers and processors in switching nodes are all network resources. If congestion occurs without control, the throughput of the entire network will decrease as the input load increases.

Insert picture description here
the term:

拥塞窗口(cwnd/swnd):发送方发送报文的数量。不是固定值,初始1,没有发生拥塞前cwnd变大,发生拥塞后cwnd变小。
慢开始门限(ssthresh):一个状态变量,用于控制 拥塞窗口 增值的阈值
	cwnd < ssthresh :使用 慢开始 增长cwnd 的值
	cwnd > ssthresh : 改用 拥塞控制 增长cwnd 的值
	cwnd = ssthresh :慢开始/拥塞控制 增长cwnd 的值
慢开始:每个传输轮次,按指数(乘2)增长 cwnd 的值。
拥塞控制:每个传输轮次,按线性(加1)增长 cwnd 的值。
快重传:尽快的重传(连续收到3个重复确认),不用等到超时重传。
快恢复:发送拥塞后cwnd 不是变成1,而是 = 拥塞值/2 向下取整。

Solution: When the
Insert picture description here
sender starts to generate data, it is 1 message. After receiving the confirmation message, there is no problem with the verification. After each round of transmission, the congestion window is rapidly increased by the **slow start algorithm (multiplied by 2) . When the slow start threshold is reached, the congestion window is slowly increased according to the congestion avoidance algorithm (plus one) **. If congestion occurs (retransmission timeout), is called fast recovery algorithm adjusts the congestion window and the slow start threshold congestion value = / 2 rounded down, then the data occurs.

Guess you like

Origin blog.csdn.net/fangye1/article/details/111867312