Shulou(Shulou.com)11/24 Report--

This article comes from the official account of Wechat: low concurrency programming (ID:dibingfa). Author: flash.

You are a computer. Your name is A.

After a lot of trouble in the article "if you Design the Network", as long as you know the IP address of another partner B and the network between you is connected, you can send a packet to your partner B no matter how far away it is.

This is what the physical layer, the data link layer and the network layer do.

Standing on the fourth floor, you can shamelessly use the groundwork made by the lower three layers and send data at will without having to worry about not finding each other.

Although you haven't done anything yet, you still have a loud name for your own layer, called the transport layer.

You thought everything would be all right on the fourth floor, but soon problems followed.

Here comes the problem.

The first three protocols can only move packets from one host to another, but which program (process) does the packet hand over to when it arrives at the destination?

So, you need to distinguish between the processes that communicate, so you assign each process a number, and you give it a loud name: the port number.

Then you add the header of the transport layer, the source port number and the destination port number to the packet to be sent.

OK, so you upgrade the original host-to-host communication to process-to-process communication.

You don't realize that you have unwittingly implemented the UDP protocol!

(of course, in UDP protocol, there are not only active ports and destination ports, but also packet length and check value, which we will skip for a moment.)

In this way, you communicate with B carefree using the UDP protocol, and there has been no problem.

But soon, you find that things become very complicated.

Packet loss problem due to the unreliable network, packets may be lost halfway, but An and B are not aware of it.

For the problem of packet loss, only two things need to be solved.

First, how does A know the bag is missing?

Answer: let B tell A

Second, what about the lost bag?

Answer: retransmit

So you design the following plan: every time A sends a packet, you must receive an ACK from B and send the next one, otherwise you will retransmit the packet if you don't receive the confirmation within a certain period of time.

You call it stopping waiting for the agreement. As long as according to this agreement, although A cannot guarantee that B will receive the packet, A can confirm whether B has received the packet, try again if it is not received, and try its best to make the communication process reliable. So your current communication process has a new feature, reliable delivery.

The efficiency problem can be solved by stopping waiting, but the efficiency is too low. A could have started sending the second packet immediately after sending the first packet, but because of the stop waiting protocol, A had to wait for the packet to arrive at B, and B's ACK packet returned to A before it could continue to send the second packet, which is not 1.2 points.

So you improve the process by using an assembly line instead of foolishly waiting.

Sequence problem, but the network is complex and unreliable.

Sometimes the packets sent by A take different routes to B, which may not be guaranteed to be in the same order as when the packets were sent.

Multiple packets and ACK packets flow out of order in the pipeline, and the corresponding relationship between them is out of order.

Is it still going back to stopping waiting for the agreement? An every time a packet ACK is received and the next packet is sent, there is no order problem at all. There should be a better way!

An adds a sequence number (seq) to the packet sent, while B adds a confirmation number (ack) to the ACK packet, which not only solves the efficiency problem of stopping waiting for the protocol, but also solves the order problem by marking the sequence number in this way.

The confirmation number B is meaningful: for example, B sends a confirmation number ack = 3, which not only means that the packet with sequence number 2 sent by A has been received, but also that all packets before 2 have been received. This method is called cumulative confirmation or cumulative response.

Note that the number of the ack is actually the sequence number of the last packet received, seq + 1, which tells the other party what the next sequence number should be. But in the figure, for ease of understanding, ack represents the serial number received, without entanglement.

Traffic problems sometimes, A sends packets too fast, and B does not have enough receiving capacity, but B does not inform An of the situation.

How to solve it?

It is very simple. B tells An its receiving ability, and A controls its transmission rate accordingly according to B's receiving ability.

B how to tell A? Does B say "I'm strong" to A? That certainly won't work. There must be a strict standard.

So B decides that every time a packet is sent to A, a value, called window size (win), is passed along, which indicates the receiving ability of B. By the same token, every time A sends a packet to B, it also brings its own window size, indicating the receiving ability of A.

B told An its own window size, how can A use it to control the flow of the package sent by A?

Very simply, if the window size win from B to An is 5, then A divides the data to be sent into these categories according to this value.

If the picture is too clear, it will no longer be explained in words.

When A keeps sending packets, the last sequence number that has been sent moves to the right until it touches the upper boundary of the window. At this time, A can no longer send packets and achieves flow control.

But when A keeps sending packets, A will also receive acknowledgement packets from B, and the whole window will move to the right, so the upper boundary will also move to the right, so A will be able to send more packets.

The above is in the case of the same window size, and B in the ACK package sent to A, each can reset a new window size, if A receives a new window size value, A will adjust accordingly.

If A receives a larger window size than the original window value, such as win = 6, A will directly move the upper boundary of the window 1 unit to the right.

If A receives a window size smaller than the original window value, such as win = 4, then A will not change the window size for the time being, let alone move the upper boundary of the window to the left, but wait for the arrival of ACK and keep moving the left boundary to the right until the window size value shrinks to the new size.

OK, finally solved the flow control problem almost, you look at the above small motion pictures, give this window a more vivid name, sliding window.

Congestion problem, but sometimes, it is not the acceptability of B is not enough, but the network is not very good, resulting in network congestion.

Congestion control is similar to flow control, but flow control is affected by the receiving capacity of B, and congestion control is affected by the network environment.

The solution of congestion control is still by setting a certain window size, but the window size of flow control is directly told to A by B, and the window size of congestion control should be actively told by the network environment.

But how can the network environment take the initiative to tell A? Only A can unilaterally feel the quality of the network environment through exploration, and then determine the size of its own congestion window.

There are many complex algorithms for calculating the size of the congestion window, so we will not expand it in this paper. If the size of the congestion window is cwnd and the size of the sliding window of the previous part of the flow control is rwnd, then the right boundary of the window is affected by these two values, so we need to take the minimum of the two values.

Window size = min (cwnd, rwnd)

The meaning is easy to understand, when the receptivity of B is relatively poor, even if the network is very smooth, A needs to limit its sending window according to the receiving capacity of B. When the network environment is poor, even if B has a strong receiving capacity, A should limit its sending window according to the congestion of the network. It is said that it is affected by its deficiency.

Connection problem sometimes, when the corresponding process of host B is not ready or hung up, A begins to send packets, resulting in waste.

The problem is that A begins to send a series of messages without confirming whether B is ready before communicating with B. It's like when you talk to another person on the phone, and you don't "feed" to make sure the other person is listening, you talk a lot about Barabara.

How to solve this problem?

Everyone knows, three-way handshake!

A: I'm ready (SYN)

B: I know (ACK), and I'm ready (SYN)

A: I know (ACK)

An and B each maintain their own state variables in memory, and after a three-way handshake, the state of both sides becomes ESTABLISHED.

Although only three packets have been sent and the state variables are maintained in their respective memory, it always feels too low. You see that this process is equivalent to the process of establishing a connection between the two parties, so you have an idea and call it connection-oriented.

Note: this connection is virtual and is maintained by the two terminals An and B. the devices in the network do not know about the connection at all!

But everything has a beginning and an end, and when there is a process of establishing a connection, it is necessary to consider the process of releasing the connection. As everyone knows, wave four times!

A: goodbye, I'm going to shut down (FIN)

B: I know (ACK)

Give B some time to deal with his own affairs.

B: goodbye, I'm going to shut down (FIN)

A: I know (ACK)

To sum up, what is mentioned above is the core idea of the TCP protocol. The information that needs to be transmitted in the above process is reflected in the head of the TCP protocol. Here is the most common TCP protocol header interpretation diagram.

I don't know if you can understand the following sentence now:

TCP is

Connection-oriented, reliable, byte-stream-based

Transport layer communication protocol

Connection-oriented and reliable, these two words are easy to understand through the above description, so what is based on byte flow?

Quite simply, TCP needs to tell the other party MSS (the maximum message segment size) when establishing a connection.

In other words, if the data to be sent is very large, the TCP layer needs to be cut into TCP message segments according to MSS.

When I cut, I don't care what your original data means, where you need to break a sentence or something. I will treat it as a series of meaningless bytes and click it where I want to cut and mark it with a serial number. as long as the receiver can spell out the final complete data according to the serial number.

In my TCP transmission, I treat it as a byte, that is, based on the meaning of byte stream.

Finally, I leave you an assignment to simulate An and B to establish a TCP connection.

The first question: a sends "aaa" to B, and then B replies to A with a simple string "success" and grabs the process.

Question 2: a sends "aaaaaa... a" to B that exceeds the maximum message segment size, and then B replies to A with a simple string "success" and captures the process.

Here is the bag I grabbed (question 2)

Three-way handshake stage

A-> B [SYN] Seq=0 Win=64240 Len=0MSS=1460 WS=256B-> A [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0MSS=1424 WS=512A-> B [ACK] Seq=1 Ack=1 Win=132352 Len=0 data transmission phase

A-> B [ACK] Seq=1 Ack=1 Win=132352 Len=1424A-> B [ACK] Seq=1425 Ack=1 Win=132352 Len=1424A-> B [PSH, ACK] Seq=2849 Ack=1 Win=132352 Len=1247B-> A [ACK] Seq=1 Ack=1425 Win=32256 Len=0B-> A [ACK] Seq=1 Ack=2849 Win=35328 Len=0B-> A [ACK] Seq=1 Ack=4096 Win=37888 Len=0B-> A [PSH, ACK] Seq=1 Ack=4096 Win=37888 Len=7 four waves

B-> A [FIN, ACK] Seq=8 Ack=4096 Win=37888 Len=0A-> B [ACK] Seq=4096 Ack=9 Win=132352 Len=0A-> B [FIN, ACK] Seq=4096 Ack=9 Win=132352 Len=0 (sorry for the missing line of ACK below) this article comes from the official account of Wechat: low concurrency programming (ID:dibingfa). Author: flash.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.