This is the 15th day of my participation in the August Text Challenge.More challenges in August
Understand Socket communication (2)
The last article talked about the long connection communication can use a variety of three-party framework, when the third party framework can not meet the design scenario, we should do what, this article explains the characteristics and principles of Socket TCP.
I. Application scenarios
1.1 a scene
As you all know, you type in a web address in a browser, and with the Internet available, the page will render.
The pattern is something like this, the connection ends at the end of the request.
Graph LR input [url] -- > B/request to the server B - > C/server returned data C - > D [page rendering] D - > E [over]
To meet this scenario, the Http protocol enables the TCP connection to be opened when a request is made and closed when the request is completed.
1.2 scenario 2
Student A sends A message to student B, and student B receives the message.
Graph LR [A classmate sent] -- > B/server receives B - > C/server transfer message to classmate B C - > D [B students receive news] D - > E [over]
To satisfy this scenario, there is a two-way connection, where the client can send messages to the server and the server can send connections to the client; In order to receive instant messages, it must be real-time, which is the use of long connections.
So the communication that establishes this scenario is a two-way long connection
2. TCP features
TCP is located in the transport layer, corresponding to the UDP transmission protocol, TCP why reliable, because it has a three-way handshake and a four-way wave when disconnecting, to ensure the reliability of sending data, corresponding to it will increase a little time, sacrifice a little efficiency.
In order to ensure the reliability of data, we use TCP transmission, when we use sockets to operate TCP, there is no need to care about the complex underlying logic of TCP.
So what are the features of TCP
-
TCP is full-duplex communication and will occupy the communication line between two computers until it is shut down by one or both
-
TCP is reliable, as evidenced by the three-way handshake and four-way wave + packet number
-
TCP is a stream, not a packet. Like a stream, it needs to be split to get the correct data out
What should we pay attention to when using Socket TCP
3.1 Connection Status
You can change the title of this chapter to something else, for example
Why do you need a heartbeat?
Why does the client still display the connection status when the server is disconnected?
normal
Under normal circumstances, both the client and the server can receive the callback and listen to the offline status of the other party when socket.close() is executed normally.
Forced disconnection
In the case of forced disconnection, the other party cannot detect the disconnection status
When the Socket TCP server is disconnected from the network, the client still displays the connection status.
Test using socket:
-
When the client is disconnected from the network, the client is connected to the disconnect callback
-
When the server is manually shut down, the client receives a disconnection callback
-
When the server is suddenly disconnected from the network, the client cannot receive the callback of the disconnection.
www.cnblogs.com/549294286/p…
Why can’t callbacks be picked up when the server is down?
This is because the channel established by TCP is broken and cannot be broken four times (because the network is down), creating what is called a dead link.
At this point, the heartbeat mechanism is needed to confirm that each other is online.
3.2 Sending Status
Similarly, the title could be changed
Why did I send a message and the Socket TCP callback succeeded, but the other party did not receive the message?
What guarantees message reliability during long connection?
Why is it that some Socket frameworks that provide callbacks to send results are unreliable?
In the case of disconnection, TCP is disconnected, but the other party does not disconnect in time.
However, if you send a message to an object, the send callback is success.
This is because, when the channel is broken, the other party does not receive it in time, and a successful connection merely means that the data has been put into the buffer, not that the data has been sent to the other party
So the result of this callback is only sent on behalf of me, and I don’t know what happens to me along the way, so it’s only useful for reference.
So if you want to make a message reliable, you should also, when you receive a message, tell the other party that the message was received successfully.
3.3 Sticking package subcontracting
concept
Stick package:
If the sent byte data packets are small and frequently sent, the Socket will glue the byte data into a whole packet to reduce memory consumption.
Subcontractor:
If the sent byte packet is large, the Socket subcontracts the sent byte data to reduce memory and performance consumption.
Why do sticky bags appear
In fact, sticky packet subcontracting is the optimization of data in TCP transmission protocol. TCP is a “flow” protocol, and the transmission process is like flowing water without boundaries and boundaries. In fact, we only need to take out the part we send. UDP is a “packet” protocol, so there is no sticky packet subcontracting in UDP.
Why subcontracting
In order to protect the network (also known as flow control), TCP does not transmit what is received. Instead, it determines how much data is sent based on a set of restrictions, including: User buffer (receive/send buffer), TCP underlying buffer (which varies from system to system), MTU (maximum transmission unit, which belongs to the data link layer), and so on
Example explanation
The current sender sent two packets with the following contents: 123456789 ABCDEFGHCopy the code
We want the receiver to receive two packets, the first packet is 123456789 and the second packet is ABCDEFGH. However, the situation of sticking packages and subcontracting is not the expected situation.
Stick package case
If two packets are sent at very short intervals, such as 0.1 seconds, the recipient will receive only one packet if the packet length is sufficient, as follows:
123456789ABCDEFGH
Copy the code
The subcontract conditions
Assuming that the maximum packet length is set to 5 bytes (the more extreme assumption is that the typical length is between 1000 and 1500), the receiver will receive 4 packets without sticky packets, as follows:
12345
6789
ABCDE
FGH
Copy the code
How to deal with sticky subcontracting?
Processing at the data level:
-
Convention terminator, split data when encountered.
-
The length of data is agreed when sending data, the length is first received when obtaining data, and then the data is segmented according to the length.
-
Concatenate line breaks at the end of sending data, using rd.readline () of BufferedReader.
Technical selection:
-
Use mature socket frameworks, many of which help with packet closing.
-
WebSocket is a message-based protocol that can automatically fragment data and assemble the fragmented data.