Open the takeout software and display the list of merchants. There are many items in the list, and each item contains some information: the merchant's name, picture, positive rating, location from you, rating...

For these operations, we have made the following designs:

1. Clarify what information is included in the current request and response (according to requirements)

Request: user identity, user's current location

Response: Contains several business information

2. Clarify the specific request and response formats

Example one:

The so-called clear format depends on how you construct a string. This string can then be transmitted as a TCP or UDP payload.

On the other hand, the server can parse this string and parse out that the userid is before the comma, and the longitude and latitude are after the comma.

At this time, we have constructed a response string, and the client can parse it according to this format.

The data transmitted on the network is essentially a string (to be precise, a binary "string"), and it is impossible to directly transmit content such as a Java object.

When writing code in Java, there are often various objects

But when sending data at the end, you need to convert the object into a (binary) string [serialization]

When receiving data, you also need to convert the (binary) string back to the object [deserialization]

Example two:

use! To split each merchant, use each information of the merchant; to split

Example three:

From the above method, you can see that the specific data organization form of requests and responses is very flexible. Programmers can organize it however they want. They just need to ensure that the client and server use the same rules.

2. Common protocol format

Although we say that custom protocol formats can be arbitrary, in order to avoid overly fanciful designs, some people have invented some "universal protocol formats". By referring to these formats, we can make decisions about our protocol design. important guiding role

Since there are many forms of expression, here we will select a few important ones and introduce them.

（1）xml

Paired tags are used to represent "key-value pair" information, and tag nesting is supported to form some more complex tree-structured data.

Advantages: xml expresses structured data very clearly

Disadvantages: Representing data requires the introduction of a large number of labels, which seems cumbersome and also takes up a lot of network bandwidth.

（2）json

json is the most popular data organization form

It is essentially a key-value pair, but it looks much cleaner than xml.

In json, { } is used to represent key-value pairs, and [ ] is used to represent arrays.

Each element in the array can be a number, a string, or other { } or [ ]

Advantages: Compared with xml, the data represented is much simpler and more readable, making it easier for programmers to observe results and debug problems.

Disadvantage: After all, it requires a certain amount of bandwidth to transmit the key name.

json is not sensitive to line breaks. If all these contents are placed on the same line, it is completely legal.

Generally, during network transmission, json will be compressed (unnecessary line breaks and spaces are removed), and all data will be put into one line to retrieve, and the overall bandwidth occupied will be lower (affecting readability)

（3）protobuffer

A set of binary data serialization methods proposed by Google

Use the binary method to agree on a certain number of bytes to represent which attribute

Save space to the greatest extent (no need to transmit key, distinguish each attribute according to position and length)

Advantages: Save bandwidth, maximize efficiency

Disadvantages: Binary data cannot be directly observed with the naked eye, is inconvenient for debugging, and is complicated to use (you need to write a special proto file to describe what the data looks like)

This is mainly used for scenarios with higher performance requirements.

2. Transport layer

1、UDP

Basic characteristics of UDP: connectionless, unreliable transmission, datagram oriented, full duplex

To learn a protocol, of course you need to master the characteristics of the protocol, and you also need to understand the protocol message format.

What's in the masthead? What does it all mean?

A communication involves five tuples:

Source port, destination port, source IP, destination IP, protocol type

The valid range of legal port numbers is 0 - 65535. In fact, 0 will not be used.

Among them, 1 - 1024 (well-known port numbers) are given specific meanings by the system and are generally not recommended for use.

Of course, you can also write a program to use ports before 1024 (your program needs administrator rights)

During the process of data transmission over the network, data may be corrupted due to external interference.

Network data are essentially optical signals/electrical signals/electromagnetic waves.

After being interfered by the outside world, it may cause errors in the data you want to transmit, such as 0 -> 1, 1 -> 0

After the receiver receives the data, it needs to confirm whether the data is incorrect data. Checksum is a simple and effective method.

The actual checksum is not just a "length", but is generated based on the content of the data. When the content changes, an error can be sensed.

How is the UDP checksum implemented?

A simple and crude CRC check algorithm (cyclic redundancy checksum) is used

Accumulate each byte in the UDP datagram in turn, and save the accumulated result in a two-byte variable

It may overflow as you add more, but it doesn’t matter if it overflows.

After all bytes are added, the checksum is finally obtained

When transmitting data, the original data and checksum will be transmitted together. The receiver receives the data and also receives the checksum (old checksum) sent by the sender.

The receiver calculates it again in the same way to get a new checksum. If the old checksum and the new checksum are the same, it can be regarded as correct during the data transmission process. Otherwise, it is regarded as during the transmission process. The data is wrong

However, the same checksum does not necessarily mean the data is the same, but the probability of this happening is relatively low.

There are also some other algorithms for verification that can achieve higher accuracy, but they cost more.

2、TCP

(1) TCP protocol segment format:

TCP characteristics: connection, reliable transmission, byte stream oriented, full duplex

Reliable transmission is implemented by the kernel and cannot be perceived when writing code (the cost of perception is low, and the cost of use is also low)

(2) Implementation mechanism of reliable transmission:

Confirmation response mechanism (reliability):

Confirmation response is the core mechanism to ensure "reliability"

When we send multiple pieces of data continuously, the multiple pieces of data may appear in a "last-served, first-served" situation: one datagram is sent first, and another datagram is sent later, but the later datagram is sent later. Arrived first

Why does the "last come first come" situation occur?

There are many paths from A --> B on the network. Two datagrams may not necessarily take the same route from A --> B.

In addition, each node (router/switch) is busy at different levels. At this time, there will be differences in the forwarding process.

How to solve the above problem?

Number the data

Since TCP is oriented to byte streams and is not transmitted in units of "bars", we number the bytes.

(1) Number bytes, not "bars"

(2) The response message must also be associated with the received data, not equal.

As long as you know the starting number of this string of bytes and the length of the bytes, you will naturally know the number of each byte.

You only need to indicate the number of the first byte of this string of bytes in the TCP header, and then combine it with the length of the message. At this time, the number of each byte is determined.

The value of the confirmation sequence number is the number of the last byte received plus one.

In the previous structure diagram, the 32-bit serial number part stores the number of the first byte of this string of bytes.

The data stores the TCP payload data, which contains several bytes.

The 32-bit confirmation sequence number field is used for response messages.

How to distinguish whether the current message is a normal message or a confirmation response message?

Look at the six flags, focusing on the second flag: ACK

ACK = 0 means this is an ordinary message, and only the 32-bit sequence number is valid at this time

ACK = 1 indicates that this is a response message, and the sequence number and confirmation sequence number of this message are both valid.

There is no correlation between the sequence number of the confirmation message and the sequence number of the normal message. The sequence number is the number of the data sent by your own host.

Sometimes, ack is also used to refer to the response message.

Confirmation response is the core mechanism of TCP to ensure reliability.

Timeout retransmission mechanism (reliability):

Packet loss: On the network, it is very likely that a piece of data will be sent and then the data will be lost.

Routers/switches can be understood as "transportation hubs", connecting many devices

The structure is complex, and the amount of data transmitted is also uncertain. Sometimes more data is transmitted, sometimes less data is transmitted.

If the device is too busy, new data may be discarded if it waits for too long.

The higher the network load, the busier it is and the easier it is to lose packets

How to deal with packet loss?

Perform timeout retransmission

Timeout retransmission is equivalent to an important supplement to the confirmation response.

Timeout retransmission has the above two situations:

The first is that the sent message itself is lost, and the second is that the response message is lost.

But the sender cannot distinguish which case

Since it cannot be distinguished, retransmit them all.

But in the second scenario, B received the same message twice, but assuming that 10 yuan was transferred at this time, but due to retransmission, 20 yuan was transferred, so there is a problem here

After receiving the data, the receiver needs to deduplicate the data and discard the duplicate data to ensure that when the application calls inputStream.read, the data read will not be repeated.

How to remove duplicates? How to efficiently determine whether the currently received data is duplicated?

Directly use the TCP sequence number as the basis for judgment

TCP will arrange a memory space for each socket object in the kernel, which is equivalent to a queue, also called a "receive buffer". The received data will be placed in the buffer and sorted according to the serial number .

Arranging according to the serial number can ensure that even if there is a last-come-first-come situation, the data read by the application will still be in order.

At this point, you can easily find out whether the newly received data is duplicated.

After reading the data, will the data still be in the queue?

This involves the producer-consumer model again.

After receiving the data, the receiver's network card puts the data into the receive buffer of the corresponding socket object (in the kernel)

The application calls read to consume data from this receiving buffer. When read is gone, the data can be retrieved from the queue (generally, read will delete it after reading it).

Why can the data be transferred during retransmission?

Packet loss is essentially a probabilistic problem

Assuming that the probability of packet loss is 10% and the probability of successful transmission is 90%, then the probability of two consecutive packet losses is only 1%

As the number of retransmissions increases, the overall probability of successful transmission is greater.

How long is the wait timeout?

We don’t need to remember this value specially

The timeout is not a fixed value and will further increase as the timeout rounds increase.

As the number of retransmission rounds increases, the waiting time will become longer and longer.

This is because it is currently believed that under normal circumstances, the second retransmission has a high probability of successful retransmission. If multiple retransmissions fail, it means that the packet loss rate of the current network itself is already very high. You may have encountered some serious faults

At this point, frequent retransmissions are a waste of effort. Extending the time interval also leaves room for network recovery.

However, the number of timeout retransmission rounds is not unlimited. When the number of retransmissions reaches a certain level, an attempt will be made to "reset" the TCP connection.

This involves the TCP reset message

When RST = 1, it means a reset message. If the network has experienced a serious failure, the reset operation/reset operation will not succeed, and the connection will have to be abandoned in the end.

Connection management mechanism (reliability):

Connection management, to put it bluntly, is two things:

1. Establish a connection (three-way handshake)

2. Disconnect (wave four times )

Three handshakes:

handshake

Send a greeting data (this data does not carry business information), and use the greeting to trigger specific scenarios

To complete the process of establishing a connection, A and B need data to say hello three times.

After these four interactions are completed, the connection is established, and both parties have saved the information about the other party.

It looks like four times, but the two in the middle can be combined into one

Why merge?

After the merger, the process of encapsulation and separation is saved, the cost is reduced, and the efficiency is improved. In principle, merge if possible.

SYN is a request to establish a connection, "synchronization segment"

If SYN = 1, it is a synchronization segment, which means that one host is trying to establish a connection with another host.

What is the process of TCP three-way handshake?

This picture vividly represents the three-way handshake process.

Three-way handshake, the first SYN must be initiated by the client

This code starts the three-way handshake. After the new operation is completed, the three-way handshake is completed.

Three-way handshake, this is the work done by the kernel, the application cannot intervene here

At the same time, the server does not need to involve any application layer code for the three-way handshake. It only needs that your process is bound to the corresponding TCP interface, and the three-way handshake can be automatically completed in the kernel, regardless of your How is the code written?

After the three-way handshake is completed, both the client and the server form a connection

At this point, accept can return, take out the head element from the connection queue, and further obtain the socket object in it to communicate with the peer.

But accept will not participate in the three-way handshake process

Single-threaded TCP server, when the server is processing the first client, although it cannot call accept for the second time, it does not affect the work of the kernel. The kernel has completed the three-way handshake with the second client, and the formed object is in the connection queue. socket

That is, the connection has been formed, but no one is taking it from the queue. The accept job is to take out the elements from the queue.

What is the meaning of the three-way handshake and what purpose is it intended to accomplish?

The three-way handshake is also a mechanism to ensure reliability.

In order for TCP to ensure reliable transmission, the prerequisite for reliable transmission is that the network path is smooth.

TCP's three-way handshake is to verify whether the communication to the network is smooth and to verify the sending and receiving capabilities of each host.

This is similar to how the subway runs an empty train every morning to prevent possible failures on a certain line.

Three handshakes, why three times?

Exactly three times can verify that the sending and receiving capabilities of both parties are normal.

Although the two-way handshake can verify the correctness of the device's communication capabilities, the server has no way of knowing the information that passed the verification.

Four times is fine, but it’s not necessary (split the middle time into two). Once is enough. If you can merge it, merge it. Splitting it into two times reduces the efficiency.

The three-way handshake can also have the effect of "message negotiation"

Communication involves some parameters, which require both parties to be consistent and determine the collective parameters through negotiation.

During the TCP communication process, there is actually a lot of information that needs to be negotiated

For example, where do the serial numbers of both parties start?

This is to ensure that the sequence numbers of messages can be quite different between two connections, so that it is better to determine whether a message belongs to this connection.

For example: messages transmitted on the network may arrive first. In extreme cases, a certain message may be late for a long time. When the message reaches the other end, the server and client have disconnected the previous connection. This is a re-established connection.

At this time, you can clearly identify through the sequence number that this is the message from the previous connection, and you can discard it.

To sum up, the original intention of the three-way handshake is twofold:

(1) Ask for directions and verify whether the communication is smooth and whether the sending/receiving capabilities of both parties are normal.

(2) Negotiate necessary parameters so that the client and server use the same parameters for message transmission

Four waves:

During the connection, both parties in the communication save the relevant information of the other end in their memory.

But if the connection is no longer needed, the above storage space must be released in time.

The process of waving four times is very similar to waving three times.

Three waves must be initiated by the client; four waves may be initiated by the server or the client (mostly)

FIN is one of six flags

When FIN = 1, it means the end of the message segment

After the above four steps, the connection will no longer be used, and both parties can release their own space to save the peer's messages.

Why wave four times? Can it be three times?

Sometimes waving four times can indeed be done three times, but sometimes it doesn't.

The triggering of FIN is controlled by the application code. When socket.close() is called or the process ends, FIN will be triggered.

In contrast, ACK is controlled by the kernel, and ACK will be returned immediately after receiving FIN.

It's hard to say when this close is executed. It depends on how your code is written.

In the above code, close is executed very quickly. As soon as the client is disconnected, the server will immediately sense it, end the loop, and trigger close.

But if the server needs to do a lot of other finishing work, the execution of close will actually be very slow.

When close is triggered quickly, it may be merged with the previous ACK.

If close is triggered slowly, it cannot be merged with the previous ACK.

What will happen if the server never closes?

At this time, the server's TCP is in the CLOSE_WAIT state

From the server's perspective, although the connection here is not closed, it can no longer be used normally.

When performing a read operation on the current socket, if the data has not been read yet (there is still data in the buffer), it can be read normally; if the data has been read, EOF will be read at this time (for byte streams, return - 1. If it is scanner.hasNext, it will be false)

Performing a write operation on the current socket will directly trigger an exception.

Regardless, the connection is no longer useful and closing is the only option

In more extreme cases, for example, if a BUG is written in the code, close is forgotten.

At this time, from the client's perspective, the other party's FIN has not been received for a long time, and it will wait.

If it fails to wait for a long time, the connection will be unilaterally abandoned at this time, and the client will directly delete the peer information it has saved and release it.

When releasing resources, it is best if both parties can release them smoothly. If conditions do not allow it, it will not affect the client's unilateral release.

What should I do if packet loss occurs during communication?

This also involves timeout retransmission.

The three-way handshake and four-way wave also have a retransmission mechanism.

It will retransmit as much as possible. If the retransmission still fails multiple times in a row, the connection will still be released unilaterally.

If the first set of FIN/ACK is lost, A can directly retransmit the FIN.

If the second set of FIN/ACK is lost, focus on the ACK loss

In the circled area in the picture, can A directly release the connection at this time?

No, because the last ACK may still be lost.

If the last ACK is lost, B will retransmit a FIN

At this time, if A has released the connection, no one will be able to ACK the retransmitted FIN.

Therefore, you need to let A wait for a while after sending the last ACK (mainly to see if the other party will receive a FIN retransmitted during the waiting process. If you wait for a period of time, the other party has not retransmitted it. FIN, it is considered that the ACK has been received by the other party)

At this point, A can correctly release the connection

How long does A wait for the connection to be released?

The waiting time is the maximum transmission time between any two points on the network (MSL) * 2

The timeout retransmission must be <= MSL

If the timeout reaches MSL, 100% of the packets have been lost. If the timeout is set larger, it will be meaningless.

There are also extreme cases. For example, while A is waiting for 2MSL time, B is retransmitting FIN many times, and these FINs are lost (theoretically)

If this situation really occurs, the current network must have suffered a serious failure. At this time, the prerequisite for "reliable transmission" is not met, so it does not matter if A unilaterally releases the resources.

Sliding window mechanism (efficiency):

Improve transmission efficiency (more accurately, let TCP not be too efficient under the premise of reliable transmission) (make up for it)

Using a sliding window cannot make TCP faster than UDP, but it can narrow the gap

There is no sliding window, which can ensure reliability, but a lot of time is spent waiting for ACK.

The purpose of using a sliding window is to reduce the above waiting time

Send a set of data at once. During the process of sending this set of data, you do not need to wait for ACK, just send it forward.

At this time, it is equivalent to using only "one waiting time" to wait for 4 ACKs

How much data can be sent at once without waiting for ACK is called a "window"

The larger the window, the larger the data sent in batches and the higher the efficiency.

However, the window cannot be infinitely large. If it is infinitely large, it is equivalent to not having to wait for ACK at all. At this time, it is almost the same as unreliable transmission.

If it is infinite, the receiver may not be able to handle it, and the network equipment in the middle may not be able to withstand it.

Currently, A sends data of 1001 - 5000 in batches to B, and needs to wait for 4 corresponding ACKs.

The arrival order of these four ACKs is also first and last.

When 2001 reaches host A, should A continue to send the next message? Or does A need to wait for 5001 to arrive before continuing to send the next message?

After receiving the ACK of 2001, A immediately sends the data of 5001-6000. At this time, the ACK that A is waiting for is 3001-6000.

Still waiting for four ACKs, but moved back one grid

Intuitively, it seems that the window has slid back one step.

Sliding window is a vivid metaphor, which is essentially sending data in batches

This can shorten the waiting time and improve efficiency to a certain extent than before (but still not higher than UDP)

Now if we transmit in this batch manner, what should we do if packets are lost in the middle?

For TCP, improving efficiency should not affect reliability.

Two situations:

(1) Data is lost

(2) ACK lost

1. ACK lost

If the ACK is lost, there is no need to do any processing, which is also correct.

2001 confirmation sequence number, indicating that all data before 2001 has been received, including 1-1000

Although A did not receive the ACK of 1001, the ACK of 2001 covers the meaning of 1001

Unless all ACKs are lost (a major network failure occurs), otherwise, only a part of the ACKs are lost, which has no impact on reliable transmission.

2. The datagram is lost

At this time, retransmission is necessary

After 1001 - 2000 is lost, the data 2001 - 3000 reaches B, and the confirmation sequence number returned by B is still 1001

B then asks A for the data 1001

Although the subsequent data from A to B can be transmitted smoothly, as long as the data 1001 is not available, B will always ask for the data 1001 from A (the ACK confirmation sequence number returned is always 1001)

When A receives the data requesting 1001 from B several times in a row, A will understand that 1001 is lost, and A will retransmit the data 1001-2000.

When the retransmitted 1001 reaches B, the ACK returned by B is 7000.

If the receiving buffer is missing this block, the returned ACK will always ask for the 1001 datagram. Once the 1001 datagram is added, the data after 1001 - 2000 does not need to be retransmitted (all in Stay in the buffer)

Next, check whether there is any missing data in the following data. If there is any missing, ask for the corresponding data. If there is no missing, just ask for the next data of the last data in the buffer.

At this point, it is equivalent to using the minimum cost to complete the operation of retransmitting the data.

(Only the lost data is retransmitted, other data is not repeated)

We call this fast retransmission: it is a timeout retransmission combined with a deformation operation generated under a sliding window. In essence, it is still a timeout retransmission.

Sliding window does not necessarily mean that using TCP will involve

If the communicating parties transmit data on a large scale, it must be a sliding window (fast retransmission)

If the size of data transmitted by both communicating parties is relatively small, the sliding window will not be used at this time (timeout retransmission)

Flow control mechanism (reliability):

As a complement to sliding windows

Sliding window, the larger the window, the higher the transmission efficiency, but the window cannot be infinitely large. If the window is too large, the receiver may not be able to handle it, or the intermediate link of the transmission may not be able to handle it.

This will cause packet loss and retransmission. The window does not improve efficiency, but actually affects it.

Flow control is to apply the brakes on the sliding window: to avoid making the window too large, causing the receiver to be unable to process it

This is a producer-consumer model:

The production speed here is very fast, but the consumption speed here B cannot keep up.

There will be more and more receiving buffers, and eventually it will be full. If you continue to send data after it is full, packet loss will occur.

Therefore, flow control is to limit the sending speed (window size) of the sender based on the processing capabilities of the receiver.

How to measure the processing speed of the receiver?

Here we use the remaining space of the receive buffer as a measure.

The larger the remaining space, the faster the application consumes data

Here, the remaining space of the receiving buffer will be directly fed back to the sender through the ACK message, as the reference basis for the window size of the sender's next data transmission.

Congestion control mechanism (reliability):

The overall transmission efficiency is a barrel effect and depends on the shortest board

In the process of transmitting data from A to B, it has to pass through many switches/routers, which forms a relatively long transmission link.

If there is a link in the middle where the forwarding capability is particularly poor, then A’s sending speed should not exceed the threshold here.

How to specifically measure the forwarding capability of the intermediate device?

Here, we will not quantify the forwarding capability of the intermediate device, but adopt an "experimental" approach to dynamically adjust it to generate an appropriate window size.

Treat all the equipment in the middle as a whole

(1) Use a smaller window for transmission. If the transmission is smooth, increase the window size.

(2) Use a larger window for transmission. If packets are lost during transmission (congestion occurs), adjust the window to a smaller size.

In this way, you can also adapt to the dynamic changes of the network environment very well.

Congestion window: the window size used under the congestion control mechanism

In TCP, congestion control specifically unfolds as follows :

1. Slow start: When communication first starts, a very small window will be used to test the water first.

Because if the network is congested and there is a large amount of traffic, the network bandwidth that is not rich will be worsened.

2. Exponential growth: During the process of smooth transmission, the congestion window will grow exponentially (*2)

The exponential growth rate is extremely fast, so it cannot be unrestricted, otherwise very large values will appear.

3. Linear growth: exponential growth. When the congestion window reaches a threshold, it will convert from exponential growth to linear growth (+ n)

The exponential growth and linear growth here are based on the rounds of transmission.

For example: Now that the given window size is 4000, after I send as much data as 4000, this round is over. After receiving the ACK, I continue to send data and enter the next round.

Linear growth is also growth, which will make the sending speed faster and faster. When it reaches a certain level, it is close to the limit of network transmission, and packet loss may occur.

4. The congestion window returns to the small window: When the window size increases, if packet loss occurs during transmission, it is considered that the current network is congested. At this time, the window size will be adjusted to the original small window and continue to return to the previous exponential growth + linear growth. The process of growth. In addition, the threshold will also be adjusted based on the current congestion window size.

The congestion window is a process that is constantly changing and readjusting during this process.

Such adjustments can adapt well to changing network environments.

Of course, there is also a lot of performance loss here.

Every time I go back to slow start, the transmission speed will be greatly reduced.

Therefore, some optimization algorithms were born behind congestion control (shortening the small window time as much as possible)

actual sender window = min (congestion window, flow control window)

Congestion control and flow control jointly limit the sliding window mechanism, which can improve transmission efficiency under the premise of reliability.

Delayed response mechanism (efficiency):

It is a mechanism to improve transmission efficiency

How to increase the window size as much as possible if conditions permit?

It is necessary to delay for a while when returning ACK. Using this delay time, you can free up more time for the application to consume data, and the remaining time of the receiving buffer will be larger.

If ACK is returned immediately, the size of the return window is 3 kb.

But after waiting for 500ms, ACK is returned at this time. It is possible that within this 500ms, the application has consumed another 2kb. At this time, the size of the returned window is 5kb.

Here, how much speed can be improved by delaying the response still depends on the actual processing capabilities of the receiving application.

So can all packets be responded to with delay?

Quantity limit: respond once every N packets (for sliding window)

Time limit: respond once after the maximum delay time (for non-sliding windows)

Delayed response reduces the impact of reliable transmission on transmission efficiency

Piggyback response mechanism (efficiency):

On the basis of delayed response, a mechanism is introduced to further improve efficiency.

Delayed response is to make the timing of ACK transmission slower, and piggyback response is to allow data to be merged based on delayed response.

The interaction between the client and the server is in the form of questions and answers

Why does it say that four waves may be three times?

Mainly due to the effect of delayed response and piggyback response

Datagrams are merged from two into one, and the efficiency will be significantly improved.

Mainly because every time data is transmitted here, it needs to be encapsulated and separated.

Reasons for merging:

On the one hand, the timing can be simultaneous

On the other hand, the ACK data itself does not need to carry a payload, and does not conflict with normal data. It is completely possible for this datagram to carry both the payload and the ACK information (ACK flag bit, window size, confirmation sequence number )

Oriented to byte streams;

In the case of byte stream oriented, some problems will arise

Sticky bag problem:

The "sticky" here refers to "application layer datagram"

The data read/written through TCP are the payload of TCP data packets, that is, application layer data.

The sender can send multiple application layer datagrams at one time, but when receiving, how to distinguish where a complete datagram comes from?

In other words, if two packets are sent, but they are read as one or one and a half packets, problems will arise at this time.

Here, the correct approach is to design the application layer protocol reasonably

This problem needs to be solved from the perspective of the application layer

1. In the application layer protocol, delimiters are introduced to distinguish the boundaries between packets.

2. In the application layer protocol, "packet length" is introduced to distinguish the boundaries between packets

1. Use \n as the separator between packages

You can use any symbol as a delimiter, as long as you make sure that the character of the delimiter does not exist in the official message.

2. Use the length of the packet to distinguish

Through the above process, the overall reading and parsing process is completed.

The problem of sticky packets is not only unique to TCP, but also has the same problem as long as it is a byte stream-oriented mechanism (file).

The solution is the same, either use delimiters or length

Especially when customizing application layer protocols, you can use this idea to solve problems.

In contrast, these solutions introduced earlier:

xml / json are distinguished by delimiters

protobuffer is distinguished by length

TCP exception handling:

There will be some variables in the network itself, causing the TCP connection to not work properly.

1. Process crash

The process crashes --> PCB is gone --> the file descriptor table is released --> equivalent to calling socket.close() --> the party that crashed will issue a FIN, which will further trigger four waves. At this time The connection is released normally

soncket is also a file in the system kernel and will also be placed in the file descriptor table

At this time, there is no difference between TCP processing and normal process entry and exit.

2. Shut down the host (normal shutdown procedure)

Normal shutdown will first try to kill all processes (try to terminate the process), which is the same as the crash handling just mentioned.

It will take a certain amount of time for the host to shut down. Within this time, the four waves may be completed (just right). If not, it doesn't matter.

3. The host is powered off (unplug the power, there is no room for reaction)

The computer suddenly goes black. Of course, there is no room for operation at this time. At this time, A cannot send any FIN to B.

(1) If B is sending a message to A (the receiver is powered off)

This situation is easy to handle. There will be no ACK for the message sent by B. B will trigger a timeout retransmission. If the retransmission still fails, a reset message (RST = 1) will be triggered. It will try to reset the connection, but the reset operation still fails. , the connection will continue to be released unilaterally at this time (B has no negative impact)

(2) If A is sending a message to B at this time (the sender is powered off)

This situation is a little more complicated

B is waiting for a message from A, and A suddenly stops sending messages. B does not know whether A will continue to send messages, and B will enter blocking waiting.

This involves the "heartbeat package"

Although B is the receiver, it will periodically send a TCP datagram that does not carry any business data (payload) to the other party.

The purpose of sending this packet is to trigger ACK, which is to confirm whether A is working normally/to confirm whether the network is smooth

If side A cannot return ACK correctly, it means that side A is down.

Heartbeat packets are the same thing as the "flow control" window detection packets we mentioned before.

Although TCP already has heartbeat packet support, it is not enough. We often need to re-implement heartbeat packets in the application layer and applications (TCP heartbeat packets, the cycle is too long)

4. The network cable is disconnected

Equivalent to an upgraded version when the host loses power

A The situation sent here is the first situation when the host loses power.

The situation sent here by B is the second situation when the host loses power.

Comparison of TCP and UDP

The advantage of TCP is reliability, which is suitable for most scenarios

The advantage of UDP is efficiency, which is suitable for communication within the computer room and between hosts (inside the computer room, the bandwidth is relatively abundant, it is not easy to encounter congestion and packet loss, and the communication between hosts is expected to be faster)

Typical scenario: Competitive games require both reliable transmission and efficiency. In this case, neither TCP nor UDP is suitable.

Sometimes other more suitable protocols are also used, such as protocols like KCP (other so-called "transport layer protocols" do not really work at the transport layer, but are often implemented in the application layer similar to the transport layer mechanism, while at the bottom It is based on UDP to achieve reliable transmission)

3. Network layer

(1) 4-digit version number: used to indicate the version of the IP protocol

There are only two versions of the existing IP protocol, IPv4 and IPv6. Other versions may only exist in laboratories and have not been commercially used on a large scale.

(2) 4-bit header length, the setting is the same as TCP

The IP header can be long, and the IP header has options.

The unit here is also 4 bytes

(3) 8-bit service type

(Really only 4 bits are effective)

Minimum delay: the time to transmit a datagram is as short as possible

Maximum throughput: transfer as much data as possible within a certain period of time

Highest reliability: least likely to trigger packet loss during transmission

Minimum cost: the lowest hardware resources consumed during the transmission process

The four forms are mutually exclusive and you can only switch to one form.

Although the IP protocol supports this mechanism, it is rarely actually applied in development. It is usually in-depth customization at the system level.

(4) 16-bit total length

This length refers to: IP header + payload length

Total length - IP header length = payload length (total length of TCP packet)

Total length of TCP message - TCP header length = TCP payload length

The 16-bit total length here does involve the issue of 64kb, but the IP protocol itself supports the "unpacking and grouping" mechanism, and the 64kb here only restricts an IP datagram.

If relatively long data needs to be carried, the IP protocol will automatically split one data into multiple datagrams, and the receiver will also merge multiple datagrams into one when splitting.

(5) 16-bit identification, 3-bit identification bit, 13-bit slice offset

These three describe the entire IP datagram unpacking and packaging process.

When an IP datagram needs to carry relatively long data, the unpacking operation is triggered at the IP protocol layer.

Split a package into multiple small packages

Multiple small IP datagrams will carry IP headers, and the payload is several parts of the TCP datagram

16-bit identifier: The 16-bit identifiers of these multiple packages are the same.

13-bit slice offset: Different, the slice offset of the previous packet is smaller and the latter one is larger. The sequence of the packets can be distinguished by the slice offset.

3-digit identification bits: One of them is not used, another one indicates whether unpacking is allowed, and the remaining one indicates the end mark (identifying whether the current packet is the last one)

(6) 8-bit time-to-live TTL

The unit is times

Initially, TTL will have a value (32/64/128)

Every time it is forwarded through a router, the TTL will be -1. When TTL = 0, it will be discarded.

Normally. TTL is enough to support datagrams reaching any location on the network. If 0 does appear, it can be basically considered that the IP is unreachable.

(7) 8-bit protocol

Describes which protocol is used by the upper layer, the transport layer

(8) 16-bit header checksum

To verify whether the data is correct, you only need to verify the header.

Because the payload part is either TCP or UDP, I have already checked it myself.

(9) 32-bit source address, 32-bit destination address

The most important part of the IP protocol

Detailed explanation of network principles (combination of pictures and text)

1. Application layer

1. Request and response