Table of contents
Increased reliability with serial numbers and acknowledgments
Why is TCP a three-way handshake
Timeout retransmission mechanism
Increase speed with window control
Window control and retransmission control
UDP
UDP is an unreliable datagram protocol. The subtle processing will be handed over to the upper application to complete. In the case of UDP, although the size of the sent message can be guaranteed, there is no guarantee that the message will arrive. Therefore, the application sometimes performs retransmission processing according to its own needs. UDP's fast transmission speed and connectionless nature make it most suitable for real-time communication scenarios, such as online games and video streaming.
UDP protocol format
- Source port number (Source Por): The field is 16 bits long. This field is optional and sometimes the source port number may not be set. When there is no source port number, the value of this field is set to 0. Can be used in communications that do not require a return.
- Destination port number (Destination Por): Indicates the port of the receiving end, and the field length is 16 bits.
- Length: This field stores the sum of the length of the UDP header and the length of the data. The unit is byte (octet).
- Checksum (Checksum): Checksum is designed to provide callable UDP headers and data. When calculating the checksum, it is appended before the UDP pseudo-header and UDP datagram. Increase the full length by a factor of 16 by adding a "0" in the last digit. At this time, the checksum field of the UDP header is set to "0". Then perform a 1's complement sum in units of 16 bits, and write the obtained 1's complement sum into the checksum field. After the receiving host receives the UDP datagram, it obtains the IP address information from the IP header to construct the UDP Pseudo header, and then perform checksum calculation. The value of the checksum field is the 1’s complement sum of the rest of the checksum field. Therefore, the sum of all data including the checksum field is "16 The received data is considered correct only when all the bits are 1". In addition, the checksum may not be used in UDP. At this time, the checksum field is filled with 0. In this case, due to different By performing checksum calculation, the overhead of protocol processing will be reduced, which can increase the speed of data forwarding.
The process of UDP transmission is similar to sending a letter. No connection: If you know the IP and port number of the peer, you can directly transmit without establishing a connection; Unreliable: There is no confirmation mechanism and no retransmission mechanism; if the segment cannot be sent due to network failure On the other hand, the UDP protocol layer will not return any error information to the application layer; datagram-oriented: the number and quantity of read and write data cannot be flexibly controlled; the datagram-oriented application layer handed over to UDP the length of the message, and UDP sends it as it is , neither splitting nor merging; use UDP to transmit 100 bytes of data: if the sender calls sendto once to send 100 bytes, then the receiver must also call the corresponding recvfrom once to receive 100 bytes ; Instead of calling recvfrom 10 times in a loop, 10 bytes are received each time.
UDP has no real send buffer. Calling sendto will be directly handed over to the kernel, and the kernel will pass the data to the network layer protocol for subsequent transmission actions; UDP has a receiving buffer. But this receiving buffer cannot guarantee that the sequence of received UDP packets is consistent with the sequence of sending UDP packets; if the buffer is full, the arriving UDP data will be discarded. UDP is full-duplex communication.
TCP
TCP is a connection-oriented, reliable streaming protocol. A stream is an uninterrupted data structure, and you can think of it like the flow of water in a drain. When the application program uses TCP to send information, although the order of sending can be guaranteed, it is still as if a data stream without any interval is sent to the receiving end. In order to provide reliable transmission, TCP implements a "sequence control" or "retransmission control" mechanism. In addition, it has many functions such as "flow control (flow control)", "congestion control", and improvement of network utilization.
TCP protocol format
There is no field in TCP to indicate the packet length and data length. The length of the TCP packet can be known from the IP layer. The length of the data can be known from the packet length of the TCP.
source port number
Indicates the port number of the sending end, and the field length is 16 bits.
target port number
Indicates the port number of the receiving end, and the field length is 16 bits.
serial number
The field is 32 bits long. The serial number (also sometimes called the serial number) refers to the location where the data is sent. Every time data is sent, the size of the number of bytes of the data is accumulated - times. The serial number does not start from 0 or 1, but is a random number generated by the computer as its initial value when the connection is established, and is sent to the receiving host through the SYN packet. Then add the number of bytes forwarded each time to the initial value to indicate the position of the data. In addition, although the SYN packet and FIN packet sent when the connection is established and disconnected do not carry data, they will also increase the corresponding serial number as a byte.
Confirm answer number
The Acknowledgment Number field has a length of 32 bits. It refers to the serial number of the data that should be received next time. In practice, it refers to the data up to the digit preceding the acknowledgment number that has been received. After receiving the confirmation response, the sender can consider that the data before this sequence number has been received normally.
data offset
This field indicates which bit of the TCP packet should start to calculate the data part transmitted by TCP. Of course, it can also be regarded as the length of the TCP header. This field is 4 bits long, and the unit is 4 bytes (that is, 32 bits). If the option field is not included, the TCP header is 20 bytes long, so the data offset field can be set to 5. Conversely, if the value of this field is 5, it means that from the very beginning to 20 bytes of the TCP packet are all TCP headers, and the rest are TCP data.
reserve
This field is mainly used for future expansion, and its length is 4 bits. Generally set to 0, but even if the received packet is not 0 in this field, this packet will not be discarded.
control bit
The field length is 6 bits, and each bit is URG, ACK, PSH, RST, SYN, FIN from left to right. These control flags are also called control bits. When the value of their corresponding bit is 1, the specific meaning is as follows:
- URG: When this bit is 1, it means that there is urgent data in the packet. For the data that needs to be used urgently, it will be explained later in the urgent pointer.
- ACK: When this bit is ON, the field of the acknowledgment response becomes valid. TCP specifies that this bit must be set to 1 except for the SYN packet when the connection is initially established.
- PSH: When this bit is 1, it means that the received data needs to be transmitted to the upper layer application protocol immediately. When PSH is 0, it does not need to be transmitted immediately but cached first.
- RST: When this bit is 1, it means that an exception occurs in the TCP connection and the connection must be forcibly disconnected. For example, an unused port cannot communicate even if a connection request is sent. At this point, a packet with RST set to 1 can be returned. In addition, if the host restarts due to program crashes or power cuts, all connection information will be initialized, so the original TCP communication will not continue. In this case, if the communication partner sends a RST packet set to 1, the communication will be forcibly disconnected.
- SYN: Used to establish a connection. If SYN is 1, it means that a connection is expected to be established, and the initial value of the serial number is set in the field of its serial number.
- FIN: When this bit is 1, it means that there will be no more data to send in the future, and it is hoped to disconnect. When the communication is over and the connection is to be disconnected, the hosts on both sides of the communication can exchange the TCP segments whose FIN position is 1. After each host confirms and responds to the other party's FIN packet, it can disconnect. However, after receiving the TCP segment with FIN set to 1, the host does not need to reply a FIN packet immediately, but can wait until all the data in the buffer are automatically deleted because they have been successfully sent before sending.
Window Size
This field is 16 bits long. It is used to notify the data size (octets) that can be received from the position indicated by the acknowledgment number of the same TCP header. TCP does not allow sending data larger than the size shown here. However, if the window is 0, it means that a window probe can be sent to know the latest window size. But this data must be 1 byte.
checksum
Checksums for TCP are similar to UDP. The difference is that the checksum of TCP cannot be turned off.
TCP, like UDP, uses the TCP pseudo-header when calculating the checksum. In order to make its full length an integer multiple of 16 bits, it is necessary to fill in 0 at the end of the data part. First set the TCP checksum field to 0. Then perform the 1's complement sum calculation in units of 16 bits, and put the 1's complement sum of their sum into the checksum field. After receiving the TCP data segment, the receiving end obtains the IP address information from the IP header to construct the TCP pseudo-header, and then calculates the checksum. Since the checksum field stores the complement value of the sum of other parts except this field, if the 16-bit sum of all data including the checksum field is calculated, the result is "all 16 bits are 1" Indicates that the data received is correct.
Urgent Pointer
This field is 16 bits long. Only valid when the URG control bit is 1. The value of this field indicates the pointer of the urgent data in this segment. More precisely, urgent data is from the head of the data part to the position indicated by the urgent pointer. Therefore, it can also be said that the urgent pointer points out the position of the end of the urgent data in the message segment. How to handle urgent data is an application problem. It is generally used when communication is temporarily interrupted, or when communication is interrupted. For example, when clicking the stop button in the Web browser, or using TELNET to input Ctrl+C, there will be a package with URG of 1. In addition, the urgent pointer is also used as a flag to indicate the fragmentation of the data stream.
Options
The options field is used to improve the transmission performance of TCP. Because it is controlled according to the data offset (header length), its length is up to 40 bytes. In addition, the option field should be adjusted to an integer multiple of 32 bits as much as possible.
Increased reliability with serial numbers and acknowledgments
Through the use of sequence numbers and acknowledgment mechanisms, TCP can guarantee the correctness and reliability of transmitted data packets.
In TCP, when data from the sender arrives at the receiving host, the receiving host will return a notification that the message has been received. This message is called an acknowledgment (ACK).
Usually, when two people are talking, they can nod or ask at the pauses in the conversation to confirm the content of the conversation. If there is no feedback from the other party for a long time, the speaking party can repeat it again to ensure that the other party really heard it. Therefore, whether the other party understands the content of the conversation and whether the other party has fully heard the content of the conversation depends on the reaction of the other party to judge. A "acknowledgment reply" in networking is something like this - a concept. When the other party understands the content of the conversation, they will say: "Well", which is equivalent to returning an acknowledgment response (ACK). And when the other party didn't understand the content of the conversation or didn't hear it clearly, they would ask "Huh?" This is like a negative acknowledgment response (NACK).
TCP achieves reliable data transmission through positive acknowledgment responses (ACK). When the sender sends the data, it will wait for the confirmation response from the peer. If there is an acknowledgment response, it means that the data has successfully reached the peer. On the contrary, the possibility of data loss is very high.
If there is no confirmation response within a certain period of time, the sender can consider that the data has been lost and resend it. Therefore, even if packet loss occurs, it can still ensure that the data can reach the opposite end and realize reliable transmission.
Failure to receive an acknowledgment does not mean that data is necessarily lost. It is also possible that the other party has received the data, but the returned confirmation reply was lost on the way. This situation will also cause the sender to resend the data because it has not received the acknowledgment and thinks that the data has not reached the destination.
In addition, it is also possible that the acknowledgment response is delayed due to some other reasons, and it is not uncommon for the acknowledgment to arrive after the source host resends the data. At this point, the source sending host only needs to resend the data according to the mechanism. But for the target host, this is simply a "disaster". It will receive the same data over and over again. In order to provide reliable transmission for upper-layer applications, duplicate data packets must be discarded. For this reason, it is necessary to introduce a mechanism, which can identify whether the data has been received, and can judge whether it can be received.
The above-mentioned functions such as acknowledgment response processing, retransmission control, and repetition control can all be realized through the serial number. The serial number is a serial number that assigns a number to each byte (8-bit byte) of the sent data in sequence. The receiving end queries the serial number and the length of the data in the TCP header of the received data, and returns the serial number that it should receive in the next step as an acknowledgment response. In this way, through the sequence number and the confirmation response number, TCP can realize reliable transmission.
The initial value of the serial number is not 0. Instead, it is generated by a random number after the connection is established. The subsequent calculation is to add 1 to each byte.
Why is TCP a three-way handshake
The three-way handshake is a process used to establish a connection in the TCP protocol. Its main purpose is to ensure the reliability and security of communication and prevent network instability and data packet loss.
Specifically, the three-way handshake process is as follows:
The client sends a SYN message (SYN=1) to the server, indicating that it wants to establish a connection and tells the server that its initial serial number is x.
After receiving the SYN message from the client, the server confirms receipt and returns an ACK message (ACK=1), and at the same time sends a SYN message (SYN=1), telling the client that it wants to establish a connection, and its initial sequence number is y.
After receiving the server's SYN message, the client also sends an ACK message (ACK=1), telling the server that it has received the server's SYN message and agrees to establish a connection.
The reason why this process requires a three-way handshake is to ensure that the states of the client and the server are consistent and correct. After the first handshake, while the server is waiting for the second handshake, if the first SYN message gets lost or arrives late, the server will think that there is a new connection request, but the client does not necessarily initiate a connection , Therefore, the server needs to wait for the confirmation of the second handshake to confirm that the client really wants to establish a connection. The second handshake still requires the client to reply with a confirmation ACK to complete the exact establishment of the connection and prevent abnormal restarts.
Therefore, the three-way handshake is a reliable and secure communication protocol, which can effectively prevent unnecessary data transmission and misjudgment, thereby ensuring the safety and correctness of data transmission.
why waved four times
Four hand waving is a process used to release the connection in the TCP protocol. Its main purpose is to ensure that both parties in the communication can release the connection normally and prevent problems such as data duplication or leakage.
Specifically, the process of waving four times is as follows:
The client sends a FIN message (FIN=1) to request a half-closed connection and no more data to be sent, but the data sent by the server can still be accepted.
After receiving the FIN message, the server sends an ACK message (ACK=1) as a confirmation, and enters the CLOSE_WAIT state, waiting for the final data transmission to be completed.
The server closes the transmission, sends a FIN message (FIN=1), and requests to close the connection with the client.
After the client receives the FIN message, it also sends an ACK message (ACK=1) as a confirmation, enters the TIME_WAIT state, and waits for 2MSL (Maximum Segment Lifetime, the longest survival time) to expire after twice the maximum life cycle time of the message. During this period, if a retransmitted FIN message is received, repeat step 4 until the connection is closed after the time expires.
In fact, the reason why four waves are needed four times is because both ends of the connection need to perform confirmation operations to prevent unprocessed data between the two parties. Specifically, after the client sends a FIN message, the server waits for the data transmission to complete before sending the FIN message. At this time, the client also needs to confirm to close the connection safely.
Therefore, waving four times is a process to ensure the reliability and integrity of communication. Only when both the client and the server have completed these four steps can the connection be completely closed to prevent data omission or mistransmission.
The TIME_WAIT (time wait) state is a specific state in the TCP protocol, which is used to ensure that both communicating parties can close the connection normally and release resources. During the four-way wave, both the client and the server need to enter the TIME_WAIT state for a period of time to complete the final confirmation operation.
Specifically, the client enters the TIME_WAIT state after sending the last ACK message (that is, the ACK message in the fourth wave). In this state, the client does not send any packets anymore, but can still accept packets sent from the server, and waits for an elapsed time before entering the CLOSED state. The specific time is usually 2MSL (Maximum Segment Lifetime, the longest survival time), which is twice the maximum life cycle time of the packet.
What is the function of this state? The TIME_WAIT state can ensure that the ACK message can be correctly processed by the server, and can prevent similar message segments from being repeatedly sent to the closed TCP connection due to network delay or retransmission. If another client tries to use the port number of the closed connection, if the port is in the TIME_WAIT state, then the new SYN message will get a RST message to respond to the request, which avoids the subsequent connection of the closed port A useless request message was received.
In short, the role of the TIME_WAIT state is to ensure that the connection is closed correctly, and to prevent the connection from being closed due to network delay or retransmission within a certain period of time, to ensure the stability and reliability of the TCP protocol, and to avoid port reuse.
The CLOSE_WAIT (close waiting) state is a state in the TCP protocol, which means that the connection is closed passively, that is, the client sends a FIN message and requests to close the connection, and the server receives the FIN message and is about to close the connection. At this time, the server needs to check whether all the data has been transmitted. If the data has not been transmitted, the server will send an ACK message to the client, wait for the data to be transmitted, and then send a FIN message to close the connection. During this process, the server is in the CLOSE_WAIT state, waiting for the final data transmission to be completed.
The duration of the CLOSE_WAIT state is usually short, depending on the speed and volume of data transfers. In most cases, the data is usually transferred quickly, and the server will send the final FIN message to close. If the data transfer is slow or the data volume is particularly large, the CLOSE_WAIT state may last longer.
In the CLOSE_WAIT state, the server no longer receives data from the client, but can still send data to the client to ensure that all data is transmitted and processed to avoid data omission and incompleteness.
In short, the CLOSE_WAIT state indicates that the server has received the FIN message from the client, and waits for the final data transmission to be completed before releasing the connection to ensure the safe closing of the connection.
Timeout retransmission mechanism
Retransmission timeout refers to the specific time interval to wait for an acknowledgment before retransmitting data. If the confirmation response is not received after this time, the sender will resend the data.
So how to determine the specific time length of the retransmission timeout?
Ideally, find a minimum time, which can guarantee that "the confirmation response must be returned within this time". However, the length of time varies with the network environment in which the data packet passes. For example, the time is relatively short in high-speed LAN, but it should be longer than LAN in long-distance communication. Even in the same network, the length of time will change according to the degree of network congestion in different periods. TCP requires high-performance communication regardless of the network environment, and must maintain this characteristic regardless of changes in network congestion. To do this, it calculates the round-trip time "and its offset" each time a packet is sent. Add the round-trip time and the deviation, and the retransmission timeout time is a value slightly larger than the sum.
There are reasons why the calculation of the retransmission timeout should consider both the round-trip time and the deviation. Depending on the network environment, there can be large swings in the round-trip time, which occurs because fragments of the packet arrive over different wires. The purpose of TCP/IP is to control even in this environment and try not to waste network traffic.
In BSD's Unix and Windows systems, the timeout has been controlled in units of 0.5 seconds, so the retransmission timeout is an integral multiple of 0.5 seconds. However, since the round-trip time of the initial data packet is not yet known, its retransmission timeout is generally set to about 6 seconds. After the data is resent, if the confirmation response is still not received, it will be sent again. At this time, the time for waiting for the confirmation response will be extended with an exponential function of 2 times and 4 times. In addition, the data will not be resent infinitely and repeatedly. After reaching a certain number of retransmissions, if there is still no confirmation response returned, it will be judged that an abnormality has occurred in the network or the peer host, and the connection will be forcibly closed. And notify the application that the communication is terminated abnormally and forcibly.
flow control
TCP can perform flow control according to the processing capability of the receiving end to prevent the receiving end from being unable to process too many data packets from the other party.
The sender sends data according to its actual situation. However, the receiving end may receive an irrelevant packet and may spend some time dealing with other issues. Therefore, it will take some time to do other processing for this data packet, and even cannot receive any data under high load conditions. In this way, if the receiving end discards the data that should have been received, the retransmission mechanism will be triggered again, resulting in unnecessary waste of network traffic.
In order to prevent this phenomenon from happening, TCP provides a mechanism that allows the sender to control the amount of data sent according to the actual receiving capability of the receiver. This is called flow control. Its specific operation is that the receiving end host notifies the sending end host of the size of the data that it can receive, so the sending end will send data that does not exceed this limit. This size limit is called the window size. The value of the window size is determined by the receiving host. In the TCP header, there is a dedicated field to notify the window size. The receiving host notifies the sending end of the buffer size it can receive in this field. The larger the value of this field, the higher the throughput of the network.
However, once the buffer at the receiving end faces data overflow, the value of the window size will also be set to a smaller value to notify the sending end, thereby controlling the amount of data sent. That is to say, the sending host will control the amount of sent data according to the instructions of the receiving host. This also forms a complete TCP flow control (flow control).
The figure below is an example of controlling the flow process according to the window size.
When the receiving end receives the data segment starting from No. 3001, its buffer is full and has to temporarily stop receiving data. Afterwards, communication continues until notification of a send window update is received. If the update notification for this window is lost in transit, it may result in no further communication. In order to avoid such problems, the sending host will send a data segment called window detection from time to time. This data segment only contains one byte to obtain the latest window size information.
Increase speed with window control
TCP uses a segment as a unit, and each segment is sent for a confirmation response. This transmission method has a disadvantage, that is, the longer the round-trip time of the packet, the lower the communication performance.
To solve this problem, TCP introduced the concept of window. It controls degradation in network performance even with high round-trip times. As shown in the figure below, when the acknowledgment response is no longer in each segment, but in a larger unit, the forwarding time will be greatly shortened. That is to say, the sending host does not have to wait for the confirmation response after sending a segment, but continues to send.
The window size refers to the maximum value that can continue to send data without waiting for an acknowledgment response. The window size is 4 segments. This mechanism realizes the use of a large number of buffers (the buffer here represents the place where the data sent and received is temporarily stored. It is usually a part of the space opened in the computer memory.), through the function of confirming and responding to multiple segments at the same time. As shown in the figure below, the highlighted circled part of the sent data is the window mentioned above. Data within this window can be sent even if no acknowledgment is received. However, before the confirmation response of the entire window arrives, if some of the data is lost, the sender is still responsible for retransmission. To do this, the sending host has to set up a cache to keep the data to be retransmitted until it receives their acknowledgment.
The part outside the sliding window includes data that has not been sent and data that has been confirmed to be received by the peer. When the data is sent out, if the confirmation response is received as scheduled, there is no need to resend it, and the data can be cleared from the buffer at this time.
When the confirmation response is received, slide the window to the serial number in the confirmation response. This allows multiple segments to be sent sequentially and simultaneously to improve communication performance. This mechanism is also known as sliding window control.
The essence of the sliding window is a pointer or subscript, and the size of the sliding window can be 0.
Window control and retransmission control
The mechanism of timeout retransmission and sliding window protocol, as well as the congestion control algorithm and other mechanisms that automatically adjust the transmission speed according to the network congestion situation, ensure the stability of communication and improve the efficiency and accuracy of transmission.
When using window control, what should we do if a segment is lost?
First, let's consider the situation where the confirmation response fails to return. In this case, the data has already arrived at the peer end, and there is no need to resend it. However, when window control is not used, data that does not receive an acknowledgment will be resent. With window control, as shown in the figure, some acknowledgments do not need to be resent even if they are lost.
Second, we need to consider the case where a segment is lost. If the receiving host receives data other than the sequence number it should receive, it will return an acknowledgment response to the data received so far.
As shown below. When a message segment is lost, the sender will always receive a confirmation response with a sequence number of 1001. This confirmation response seems to remind the sender that "I want to receive data starting from 1001." Therefore, when the window is relatively large, and In the case of segment loss, confirmation responses with the same sequence number will be returned repeatedly. If the sending host receives the same acknowledgment response three times in a row, it will resend the corresponding data. This mechanism is more efficient than the timeout management mentioned above, so it is also called high-speed retransmission control.
congestion control
TCP can automatically adjust the transmission rate according to the degree of network congestion to ensure the stability and reliability of the network.
With TCP window control, even if the sending and receiving hosts no longer send confirmation responses in units of one data segment, they can still send a large number of data packets continuously. However, sending large amounts of data at the beginning of the communication can also cause other problems.
Generally speaking, computer networks are in a shared environment. Therefore, it is also possible that the network may be congested due to communication between other hosts. When the network is congested, if a large amount of data is sent suddenly, it is very likely that the entire network will be paralyzed.
In order to prevent this problem, TCP will control the amount of data sent through a value obtained by an algorithm called slow start at the beginning of communication.
First, in order to adjust the amount of data to be sent at the sender, a concept called "congestion window" is defined. Therefore, at the time of slow start, set the size of the congestion window to 1 data segment (1MSS) to send data, and then increase the value of the congestion window by 1 each time an acknowledgment (ACK) is received. When sending data packets, compare the size of the congestion window with the window size notified by the receiving host, and then send a smaller amount of data according to the smaller value among them.
If the timeout mechanism is used for retransmission, the initial value of the congestion window can be set to 1 before slow start correction is performed. With the above-mentioned mechanisms, the network congestion caused by continuous packet sending at the beginning of communication can be effectively reduced, and the occurrence of network congestion can also be avoided. However, with each round trip of the packet, the congestion window will also increase with an exponential function such as 1, 2, 4, etc., and the congestion situation will increase sharply and even lead to network congestion. In order to prevent these, the concept of slow start threshold is introduced. As long as the value of the congestion window exceeds this threshold, each time an acknowledgment is received, the congestion window is only allowed to be enlarged by the following ratio:
(bytes of 1 data segment/congestion window (bytes)) x1 data segment bytes
The larger the congestion window, the greater the number of confirmed requests. However, as each confirmation response is received, the increase will gradually decrease, even smaller than the number of bytes smaller than a data segment. Therefore, the size of the congestion window will show a linear upward trend.
When the TCP communication starts, the corresponding slow start threshold is not set. Instead, it will be set to half the size of the congestion window at that time when retransmission is timed out. High-speed retransmissions triggered by duplicate acknowledgments are handled somewhat differently from timeout retransmission mechanisms. Because the former requires at least 3 confirmation response data segments to be triggered after reaching the other host, the network congestion of the latter is lighter than that of the latter. While performing high-speed retransmission control by repeated acknowledgment responses, the slow start threshold is set to half of the current window size. Then the size of the window is set to the slow start threshold + the size of 3 data segments. With such a control, TCP's congestion window changes as shown in the figure above. Since the size of the window will directly affect the throughput when the data is forwarded, in general, the larger the window, the more high-throughput communication will be formed. When the TCP communication starts, the network throughput will gradually increase, but as the network congestion occurs, the throughput will also drop rapidly. So it will enter the process of slowly increasing the throughput again. Therefore, the characteristics of the so-called TCP throughput seem to be gradually occupying the feeling of network bandwidth.
Nagle Algorithm
In order to improve the utilization of the network for T in TCP, an algorithm called Nagle is often used. This algorithm refers to a processing mechanism that delays sending even if the sending end still has data that should be sent, but if this part of data is very little. Specifically, data can only be sent under any of the following conditions. If the two conditions are not satisfied, then wait for a period of time before sending data.
- When all the sent data has received an acknowledgment
- When data with the maximum segment length can be sent
According to this algorithm, although network utilization can be improved, some degree of delay may occur. For this reason, when using TCP in areas such as windowing systems and mechanical control, the enabling of this algorithm is often turned off.
delayed acknowledgment
A host receiving data may return a smaller window if it responds immediately with an acknowledgment every time. That's because the data has just been received and the buffer is full. When a receiving end receives the notification of this small window, it will use it as the upper limit to send data. For this reason, a method is introduced, that is, it does not return the confirmation response immediately after receiving the data, but delays it for a period of time. .
- No acknowledgment will be made until the data with the maximum segment length of 2x is received (depending on the operating system, there may be cases where the acknowledgment is returned as soon as two packets are received regardless of the data size.)
- In other cases, the maximum delay is 0.5 seconds to send the confirmation response (many operating systems are set to about 0.2 seconds)
If the delay is more than 0.5 seconds, it may cause the sender to resend the data. The smaller this time is, the higher the CPU load will be, and the performance will also decrease. Conversely, the longer this time is, the more likely it is to trigger the retransmission processing of the sending host, and when the window has only one data segment, the performance will also degrade.
In fact, there is no need for an acknowledgment for each data segment. TCP uses a sliding window control mechanism. Therefore, it is usually okay to confirm that there are fewer customers. In TCP file transmission, most of them return an acknowledgment response every two data segments.
piggybacking
According to the application layer protocol, the sent message reaches the peer end, and after the peer end processes it, a receipt will be returned. For example, the SMTP or POP of the electronic mail protocol, the connection control part of the file transfer protocol FIP, and the like. These application protocols use the same connection for data exchange. Even the HTTP protocol of the WWW is the same from version 1.1 onwards. For another example, in the remote login, the return check for the input characters is also a kind of receipt for sending the message. (Loopback verification means that in remote login, the characters entered from the keybox arrive at the server and then return to the client.) When people in rural areas go to the market to sell pigs, they drag a few baskets on the back of the pigs by the way
. The scene where the vegetables are taken to the market together. In fact, it means by the way, by the way.
In this type of communication, the TCP acknowledgment and receipt data can be sent in one packet. This method is called piggybacking. Through this mechanism, the amount of data sent and received can be reduced. In addition, if an acknowledgment is returned immediately after receiving data, piggybacking cannot be realized. Instead, pass the received data to the application to process and generate the return data, and then proceed to send the request, and must wait for the sending of the confirmation response. That is, piggybacking is not possible without enabling delayed acknowledgments. Delayed acknowledgment response is a better processing mechanism that can improve network utilization and reduce computer processing load.
In Internet applications, the TCP protocol plays an important role. It acts as an important transmission guarantee in the process of data transmission by ensuring the stability, integrity and reliability of transmission. Understanding the basic characteristics and implementation process of the TCP protocol is of great significance for improving the application level of computer network technology. Of course, the TCP protocol still has some shortcomings, such as restrictions on network bandwidth and load and impact on application layer protocols, etc., which can be optimized and improved in practical applications to better meet user needs.
The TCP buffer is the data exchange area between the sending end and the receiving end. It is a storage space for temporarily storing data packets. During transmission, the TCP buffer will dynamically allocate and manage memory resources to cope with different data transmission loads and network congestion levels.
At the sending end, the TCP buffer is mainly used to store data packets to be sent and send control information, such as sequence number, confirmation number, window size, etc. The sending end puts the data into the buffer, and then sends the data packet to the receiving end according to the network congestion. If the receiving end cannot receive the data packet, the sending end will automatically cache according to the window size of the other party to ensure flow control and stable data transmission.
At the receiving end, the TCP buffer is used to store received but unprocessed data packets, such as pending data packets and acknowledgment information. The receiving end will put the data packet into the buffer, analyze the data packet, and confirm and process it according to the confirmation number and other information of the data packet. If a data packet does not arrive or is sent incorrectly or repeatedly, the buffer at the receiving end will perform operations such as deduplication, reorganization, and sorting on the data to ensure the correctness and continuity of the data, and then send an ACK to the sending end, indicating that the data packet has been sent is received, and buffer space is freed up so that more packets can be received.
It should be noted that in actual use, the performance of TCP can be affected by adjusting the buffer size. If the buffer is too large, although it can support more data transmission, it may cause network congestion and delay; if the buffer is too small, data packets may be lost or the efficiency of data transmission will be reduced. Therefore, it is necessary to adjust the appropriate buffer size according to the specific network environment and application requirements.
Difference between TCP and UDP
Some people may think that since TCP is a reliable transport protocol, it must be better than UDP. actually not. The advantages and disadvantages of TCP and UDP cannot be compared simply and absolutely.
TCP is used when reliable delivery is necessary at the transport layer. Because it is connection-oriented and has mechanisms such as sequence control and retransmission control, it can provide reliable transmission for applications.
On the one hand, UDP is mainly used for communications or broadcast communications that have high requirements for high-speed transmission and real-time performance. Let's take an example of making a call through an IP phone. If TCP is used, if the data is lost during transmission, it will be resent, but this cannot transmit the voice of the caller smoothly, which will lead to the failure of normal communication. With UDP, it does not perform retransmission processing. Therefore, there will be no problem of greatly delayed arrival of sound. Even if some data is lost, it will only affect a small number of calls. Also, UDP is used instead of TCP for multicast and broadcast communications. Broadcast-based protocols such as RIP and DHCP also rely on UDP.
Therefore, TCP and UDP should be used as needed according to the purpose of the application.