TCP protocol intractable panorama analysis

ISO proposes the OSI layered network model. This layered model is theoretical. TCP/IP finally implements a layered protocol model. Each level corresponds to a set of network protocols to complete a specific set of functions. The protocol is multiplexed and demultiplexed by the layers below it. This is the essence of the layered model, and eventually, all logic is encoded into cables or electromagnetic waves.

Author: Bomb250 Source: CSDN blog | 2015-09-15 10:09 Favorite Share

1. Network protocol design

The layered model is well understood, but the protocol design for each layer is not so easy. The beauty of TCP/IP is that the more complex the protocol is, the more complex it is. We define networks as devices that are connected to each other. The essential role of the network is "end-to-end" communication. However, devices that want to communicate with each other do not have to be "directly" connected, so some intermediate devices are inevitable. The data is forwarded, so the protocol running on the cable connecting these intermediate devices is defined as the link layer protocol. In fact, the so-called link is actually originating with one device and ending with another device through one line. We call a link "one hop." So an end-to-end network contains "a lot of hops."

TCP protocol intractable panorama analysis

2.TCP and IP protocols

Ending with the IP protocol, we can already complete an end-to-end communication. Why do we need the TCP protocol? This is a problem. Understand this problem, we can understand why the TCP protocol is what it is now, why is it so "complex"? Why is it so simple?

As its name suggests, the role of TCP is to control transmission, that is, to control end-to-end transmission, so why this control is not implemented in the IP protocol. The answer is simple, that is, this will increase the complexity of the IP protocol, and the IP protocol needs to be simple. What is the cause of this?

First of all, let's know why the IP protocol is the thin waist of the hourglass. The lower layer is a multitude of link layer protocols. These links provide semantics that is very different and far apart. In order to interconnect these heterogeneous networks, we need a network layer protocol to provide at least some adaptation functions. It must not provide too many "guarantee services", because the guarantee of the upper layer depends on the more restrictive guarantee of the lower layer, you can never guarantee the throughput of 1000M under the IP protocol implemented on a 100M throughput link. the amount...

The IP protocol is designed as a packet forwarding protocol. Each hop passes through an intermediate node. The design of the route is another big innovation of the TCP/IP network. Thus, the IP protocol does not need directionality, and the routing information and the protocol itself are no longer strongly associated. They are only associated with IP address, so the IP protocol is much simpler. The router as an intermediate node can't be too complicated, which involves cost issues, so the router is only responsible for routing and forwarding packets.

Therefore, the transmission control protocol necessarily needs to be implemented at the endpoint. Before we talk about the TCP protocol, we must first look at what it can't do. Because the IP protocol does not provide a guarantee, TCP can't provide such guarantees that depend on the IP lower layer link, such as bandwidth, such as delay, these are chains. The road layer decides that since the IP protocol cannot be patched, TCP can't, but it can correct some "non-guaranteed properties" that start from the IP layer. These properties include the unreliability of the IP layer, the out-of-order of the IP layer, and the IP layer. No direction / no connection.

To sum up this section, the TCP/IP model is from bottom to top, functions are increased, and the number of devices that need to be implemented is reduced. However, the complexity of the device is increasing, thus ensuring the minimization of costs. As for performance or factors, it is adjusted by software. The TCP protocol is such a software. In fact, in the beginning, TCP does not consider performance, efficiency, and fairness. It is because of this that the TCP protocol is complicated.

3.TCP protocol

This is a pure software protocol, why design it with two endpoints, see the previous section, this section details the TCP protocol, interspersed with some short discussion.

3.1. TCP protocol

To be exact, the TCP protocol has two identities. As a network protocol, it makes up for the shortcomings of the IP protocol's best-effort service and achieves connection, reliable transmission, and message arrival in order. As a host software, it isolates host services and networks from UDP and left and right transport layer protocols. They can be thought of as a multiplexer/demultiplexer that multiplexes/demultiplexes many host process data. Go to the IP layer. It can be seen that, regardless of the angle, TCP exists as an interface. As a network protocol, it and the TCP interface of the peer implement TCP control logic. As a multiplexing/demultiplexing device, it interfaces with the underlying IP protocol. The function of the protocol stack is implemented, and this is the basic definition of the hierarchical network protocol model (two types of interfaces, one type and one lower level interface, another type and peer layer interface).

We are accustomed to using TCP as the top of the protocol stack, without using the application layer protocol as part of the protocol stack. This is partly because the application layer is demultiplexed by TCP/UDP, which presents a too complicated situation. Application layer protocols are interpreted in a very different way. Application layer protocols are accustomed to being encapsulated with a similar ASN.1 standard, which reflects the importance of the TCP protocol as a multiplexing/demultiplexer due to direct And the application interface, which can be easily controlled directly by the application to implement different transmission control strategies, which is one of the reasons why TCP is designed not too far from the application.

In short, there are four main points of TCP, one connection, two reliable transmissions, three data arrival, and four end-to-end flow control. Note that TCP is designed to guarantee only these four points. At this point, although it has some problems, it is very simple, but the bigger problem is quickly presented, so that it has to consider things related to IP networks, such as fairness. Efficiency, thus increasing congestion control, so TCP is what it is now.

3.2. TCP with the connection, reliable transmission, and data arriving in order

The IP protocol has no direction. The datagram transmission can reach the peer end by routing. Therefore, it arrives at the peer end by one hop. As long as one hop does not reach the route of the opposite end, the data transmission will fail. In fact, the route is also the Internet. One of the cores, in fact, the core basic functions provided by the IP layer have two points. The first point is address management, and the second point is route routing. TCP takes advantage of the simple function of IP routing, so TCP does not have to consider routing, which is why it is designed as an end-to-end protocol.

Since IP has been able to get individual datagrams to the opposite end, TCP can implement other, more rigorous control functions on this best-effort network. TCP adds connectivity to connectionless IP network communications, confirms the state of the data that has been sent, and guarantees the order of the data.

3.2.1. Have a connection

This is the basis of TCP, because the reliability of subsequent transmissions and the order of data depend on a connection, which is the simplest implementation, so TCP is designed as a stream-based protocol, since TCP needs to establish a connection before, after It doesn't matter how much data is transferred, as long as the data of the same connection can be identified.

Intractable diseases 1: 3 handshakes and 4 wavers

TCP uses a 3-way handshake to establish a connection that initializes the information necessary for transmission reliability and data sequenceability. The information includes the initial sequence number in both directions. The confirmation number is generated from the initial sequence number. The 3-way handshake is used because the second handshake has prepared the necessary information for transmission reliability and data sequence. The third time of the handshake is not actually required to be transmitted separately and can be transmitted with the data.

TCP uses 4 waves to remove a connection. Why do you need 4 times? Because TCP is a full-duplex protocol, each channel must be removed separately. Note that the meaning of 4 wave and 3 handshakes is different. Many people will ask why the connection is a 3 handshake, and the connection is 4 waves. The purpose of the 3rd handshake is very simple. It is to allocate resources and initialize the serial number. At this time, data transmission is not involved. 3 times is enough to do this, and the purpose of 4 waved is to terminate data transmission and recycle resources. There is no relationship between the serial numbers of the two endpoints in both directions. The virtual link must be removed when there is no data transmission in both directions. It is not as simple as initialization. The SYN flag is initialized to initialize a serial number and confirm the sequence of SYN. number. Therefore, the data transmission in that direction must be terminated separately in one direction.

Intractable Disease 2: TIME_WAIT Status

Why is this state, the reason is very simple, that is, each time the connection is established, the serial number is randomly generated, and the serial number is 32-bit, it will wrap around. Now let me explain what this has to do with TIME_WAIT.

Any TCP segment should be transmitted on the best-effort IP network. The intermediate router may randomly cache any IP datagram. It does not care what data is carried on this IP datagram. However, based on experience and The size of the Internet, an IP datagram is the most surviving MSL (this is based on the surface area of the Earth, the transmission rate of electromagnetic waves in various media and the TTL of the IP protocol, etc., if on Mars, this MSL will be much larger. ..).

Now we consider that the passive party when terminating the connection sends a FIN, and then the active party replies with an ACK. However, this ACK may be lost, which causes the passive party to resend the FIN, which may survive the MSL on the Internet.

If there is no TIME_WAIT, it is assumed that connection 1 has been disconnected, but the FIN that the passive party finally retransmits (or any TCP segment sent before the FIN) is still on the network, but connection 2 reuses all 5 elements of connection 1. (source IP, destination IP, TCP, source port, destination port), just the connection will be established, the FIN that arrives late 1 will arrive, and this FIN will terminate the connection with a relatively low but indeed possible probability.

Why is the probability low? This involves a matching problem. The serial number of the late FIN segment must fall within the expected sequence number of the party connecting 2. Although this coincidence rarely happens, it does happen, after all, the initial serial number is randomly generated. Therefore, the active party that terminates the connection must wait for 2*MSL time to enter the CLOSE state after accepting the passive party and replying to the ACK. The reason is multiplied by 2 because this is a conservative algorithm. In the worst case, the ACK for the passive side. Lost when arriving on the passive side via the Internet on the longest route (experiencing an MSL).

In response to this problem, RFC793 has a suggestion for the generation of the initial sequence number, which is to set a benchmark, random on top of this benchmark, this benchmark is time, we know that time is monotonically increasing. However, this is still a problem, that is, the wraparound problem, if a wraparound occurs, the new serial number will fall to a very low value. So, the best way is to avoid "overlap", which means that a random range above the benchmark is set.

You know, many people really don't like to see a lot of connections in the TIME_WAIT state on the server, so they set the value of TIME_WAIT very low, which is feasible in most cases, but it is also a risky behavior. The best way is to not reuse a connection.

Intractable Disease 3: Reusing a connection and reusing a socket

This is fundamentally different, and there is generally no problem with reusing a socket alone because TCP is connection-based. For example, if a TIME_WAIT connection appears on the server side, then the connection identifies a five element. As long as the client does not use the same source port, there is no problem connecting the server, because the late FIN will never reach the connection. Remember, a five element identifies a connection, not a socket (of course, for BSD sockets, the server's accept socket does identify a connection).

3.2.2. Transmission reliability

Basically, the transmission reliability is achieved by the acknowledgment number. That is to say, each time a segment is sent, the receiving end must send an acknowledgment, and the sender can send the next byte after receiving the acknowledgment. This principle is the simplest. The "stop-and-wait" protocol in textbooks is a byte version of this principle, except that TCP uses a sliding window mechanism so that it does not necessarily send one byte at a time, but this is a post, this section is only Talk about the timeout mechanism for confirmation.

How do you know that the data arrives at the opposite end? That is, the peer sends an acknowledgment, but if you have not received the acknowledgment from the peer, how long does the sender wait? If you wait until the data is lost, the protocol will not be available. If the waiting time is too short, it may be confirmed that it is still on the road, so waiting time is a problem, and how to manage this timeout is also a problem.

Intractable disease 4: Calculation of timeout time

You should never feel free to guess the timeout but give an accurate algorithm to calculate. Undoubtedly, the time when a TCP segment reply arrives is the time of a datagram round trip, so the standard defines a new noun RTT that represents the round-trip time of a TCP segment. However, we know that the IP network is doing its best, and the routing is dynamic, and the router will cache without any warning or discard any datagrams, so this RTT needs to be dynamically measured, that is, at least every once in a while. It's about to measure once if it's the same every time, everything is fine, but the world is not what you want, so we need to find exactly one "average" instead of an exact value.

If this average is only taken directly by calculating the arithmetic mean of multiple measurements, it is not appropriate, because, for data transmission delay, we must consider the instantaneous jitter of the path delay, otherwise if the two measurements are 2 and 98 respectively , then the timeout value will be 50, this value is too large for 2, the result is too much delay of the data (the retransmission waits for a long time to retransmit), but for 98, it is too small The result is excessive retransmission (the road is far away, it should have been slow, and as a result a large number of retransmissions have been correctly confirmed but late TCP segments).

Therefore, in addition to considering the deviation of every two measurements, the rate of change should also be taken into account. If the rate of change is too large, the RTT is calculated mainly by the function of the rate of change as an independent variable (if it increases abruptly, then the value is a relatively large positive number. If it is abruptly decreased, the value is a relatively small negative number and then weighted with the average value. Otherwise, if the rate of change is small, the measured average value is taken. It is self-evident that this algorithm still works very well today.

Intractable disease 5: timeout

DON'T WANT TO MISS A THING?

100% Pass Cisco, PMP, CISA, CISM, AWS Practice test on SALE!
Get Now