Today to talk about Python common interview questions in the interview particularly high frequency of a topic: TCP three-way handshake agreement with the four waving.
Related to the knowledge points are:
Difference 1, TCP, UDP protocol
2, TCP header structure
3. Detailed three-way handshake process with the four waving
4. What is the state TIME_WATI
Content a little bit, and we have some patience to read!
A difference, TCP, UDP protocol
Before introducing the difference between the two, we need to understand a concept: TCP / IP protocol suite. It is defined as follows:
The current mainstream protocol suite Internet (Internet) using the TCP / IP protocol suite, which is a hierarchical, multi-protocol communication system "Linux High Performance Programming"
Extracting keywords: layered, and multi-protocol communications. That is, it has a plurality of levels, each level has a different protocol, another protocol by cooperation between these levels, and ultimately to network communications.
Speaking layered, should not be very familiar with, TCP / IP protocol suite is a four-layer protocol system, bottom-up are: the data link layer, network layer, transport layer and application layer. We are here to say to the TCP and UDP protocols belong to the transport layer. (Layers of action and related protocols will not be discussed here, being the first)
Let us return to the title: TCP, UDP protocol differences, summed up the answer points to this question is as follows:
1, they are both home transport layer protocol, the so-called "transport layer", which is to provide end to end communication two hosts, i.e. from A <-> B.
2, TCP reliable protocol, UDP protocol is not reliable. Refers reliable data sent by A to B, if the data is really to ensure delivery to the B. TCP protocol timeout and retransmission, data validation, etc. to ensure that data packets are correctly transmitted to the destination, and UDP protocol can not guarantee that the data transmitted from the transmitting side correctly to the destination, if data is lost during transmission, or the destination by data validation data error, the UDP protocol simply failed to send notification application for the TCP protocol has a retransmission timeout, data validation and other applications that require their own to deal with this logic.
3, TCP is connection-oriented, UDP is connectionless. It is relatively easy to understand, because the TCP connection only needs "three-way handshake, waving four times."
4, TCP is a stream-based service, while UDP is based, there is no boundary data stream (length) limit the datagram, and the datagram-based service, each of the UDP datagram has a length, the receiving end must be the minimum length of the entire contents of disposable units of readout.
5, when the sender performs a write operation a plurality of times, the module will first TCP data into the TCP transmission buffer, the TCP module when actually start sending data, the transmit buffer waiting to be sent in the data may be encapsulated into a or more TCP segments sent, therefore, write operations are no fixed relationship between the number of TCP segments and the number of application execution module sends TCP. Similarly, when the receiver receives one or more TCP segment, TCP module in accordance with the data number (see below for the sequence number of the TCP header structure) are put into the TCP receiving buffer, and notifies the application reads data. Alternatively one receiving terminal or multiple times the data is read from the buffer (depending on the size of the user-specified application has a read buffer). Thus, the number of read data receiving side and the transmitting side the number of BPDUs sent segments there is no fixed number of relationships. In conclusion, i.e. ** For TCP connections, there is no relationship between the number of data read operations and the number of write operations performed by the receiving side performs the transmission side, which is based on the characteristics of the streaming service. ** For UDP services, each of the transmitting side performs a write operation, it will be packaged into one of the UDP datagram and transmitted, while receiving the read must be transmitted according to the end, otherwise packet loss. Thus, for UDP connections, the sender writes data to the number of times of reading is the same, which is also based on the characteristics of datagram services.
6, TCP connection is one to one, so if it is based on broadcast or multicast applications that can not use TCP, and UDP is very suitable for broadcast and multicast.
Summary sentence of the definition:
TCP protocol (Transmission Control Protocal, Transmission Control Protocol) provides reliable, flow-based connection-oriented services for the application layer. The UDP protocol (User Datagram Protocal, User Datagram Protocol) and TCP protocol is exactly the opposite, that the application layer provides unreliable, connectionless packet-based data and services.
Two, TCP header structure
TCP packet structure is divided into a header portion and part of why you need to know the TCP header structure, because after "three-way handshake with the four waving" in the head structure will be used in the flag. Simple to understand there are certain advantages to understanding later in the process.
Below them out each role:
16-bit source port number and destination port number, this is better understood, not too much explanation.
32 Serial number: during connection establishment (or closed), and this number is used for placeholder, sends a connection request when the A to B, this time will bring a number (random value, called ISN), and B is confirmed after the connection, this number will return to +1, while the number bring their charge. When the connection is established, the random number value generated by adding the segment ISN segment carried in the first byte offset in the whole byte stream. For example, a TCP segment data is transmitted byte stream of 100 to 200 bytes, then the number of ISN + 100. In summary therefore be described to establish a connection (or closed), the serial number is to occupying the role, and the connection, in order to mark the first byte of the current data stream.
4 header length: TCP header identifies the number of 32 bit words, because it is four, i.e., the maximum TCP header 15 can be expressed, i.e. up to 60 bytes. I.e., it is used to record the maximum length of the head.
Six flags, including:
URG flag: that urgent pointer is valid.
ACK flag: Confirm flag. Usually called carry ACK flag TCP segment to confirm the segment.
PSH flag: the program should prompt the receiving end should receive from the TCP buffer immediately go read data, to receive subsequent data to make room (if you do not go read the data would have been in the buffer zone).
RST flag: Indicates ask to re-establish the connection. Usually called RST flag carry a TCP segment to the reset segment.
SYN flag: indicates a request to establish a connection. Usually called TCP segments carrying the SYN flag is called synchronous segment.
FIN flag: Turn off the mark, commonly known as TCP segment carrying FIN flag to the end of the segment.
These flags illustrate the purpose of the current request, namely what to do.
16-bit window size: this indicates how many bytes TCP receive buffer also receiving data, so that the sender can control the speed of transmission data, it is a TCP flow control means.
16-bit checksum: Verify data corruption, by a CRC algorithm verification. This includes not only check TCP header also includes a data portion.
16 urgent pointer: a positive offset value is added to it and the sequence number field indicates the next sequence number of the last byte of urgent data. TCP urgent pointer is a method of transmitting urgent data is sent to the receiving side.
A TCP header option: a variable length optional information, which portion comprises up to 40 bytes because the maximum TCP header is 60 bytes, the fixing portion comprises 20 bytes. Will not be discussed in detail, refer to "Linux high performance programming" 3.2.2
Three, four and three-way handshake Detailed waved process
Paint
First to explain the three-way handshake:
1, the sender sends a connection request, 6 flag is SYN, simultaneously bring their number (at this time because no data is transmitted, it does not represent the byte offset, are placeholders), such as a 223.
2, the receiving terminal receives the request, it agrees connections, send consent response SYN + ACK flag belt while the acknowledgment number of 224 (plus a transmission end ID), and bring its own number (in this case again due to transmitting data, it does not indicate the byte offset, are placeholders), such as a 521.
3, the sender receives a confirmation message and then sent back to the receiver to indicate that I have received your confirmation, then mark remains ACK, the acknowledgment number is 522.
Issues related to: Why is the three-way handshake, rather than four or twice?
First, explain why not four times. Four of the process is this:
Sender: I will not even you.
Recipient: Good.
Receiver: I'm ready, you connect it.
Sender: Good.
Apparently the recipient is ready to connect and agree to be connected can be combined, so you can improve the efficiency of the connection.
Again, we explain why not twice. In fact, it is better understood, we know that TCP is full-duplex communication, but also reliable connections and are closed on both sides have to perform truly complete, but also need to make sure that both ends of the connection have been implemented or closed. If only twice, the process is this:
Sender: I will not even you.
Recipient: Good.
Obviously, the recipient does not know can not guarantee a certain sender receives a "good" This information, once the recipient really did not receive this information, the case of receiving income "unilateral connection" will appear, this when the sender will have to retry sending connection requests until actually received "good" this information be considered after the connection is completed. For three times, if the sender does not wait for you to reply to confirm that it is not really in a connected state, it will retry the confirmation request.
Then we take a look at four waved process:
1, the transmitting side transmits shutdown request flag is: FIN, will also bring their number (in this case since the same data is not transmitted, it does not represent the byte offset, are placeholders).
2, the recipient after receiving the request, returns an acknowledgment: ACK, while confirming the request number plus a number.
3, the receiving side decides to close the connection, sending a shutdown notification to the FIN flag, while also bring the profile step 2, i.e. the ACK, as well as their number and acknowledgment number.
4, the sender acknowledgment reply message: ACK, the receiver sequence number plus one.
Issues related to: Why do I need four-way handshake, instead of three?
Process three times is this:
Sender: I will not send you the data.
Recipient: Well, I am not sent you.
Sender: Okay, bye.
This is because when the receiver receives a shutdown request, it is confirmed in response to immediately close, here it was confirmed that the recipient closed, i.e., the sender will not send the data to a recipient, but he can receive a recipient sent his data. And if the receiver needs to close "to send data to the sender," this channel, depending on the operating system. Operating system could take a few seconds and then turn off sleep, if combined into three, it may cause the recipient does not receive timely confirmation request, may cause a timeout retry the like. Therefore it requires four.
Fourth, what is the TIME_WAIT state
First, we look at a piece of code (say so much theory, finally Aspect code). To give an example of using a simple python tcp socket for communication:
Server:
socket_server_test.py
# - * - Coding: UTF-8 - * -
"" "
@time: 2019/6/26 4:58 pm
@author: Demon
@file: socket_server_test.py
@Desc:
" ""
Import socket
HOST = '127.0.0.1' # standard loopback address (localhost)
pORT = # 9999 listening port (port non-system level: greater than 1023)
S = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
# third parameter, If 0, can not be multiplexed
# 1 if the third may be multiplexed
# s.setsockopt (socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind ((the HOST, PORT))
s.listen ()
Conn , addr = s.accept ()
with Conn:
Print ( 'Connected by', addr)
the while True:
Data = conn.recv (1024)
Print ( "Data:", Data)
IF Data:
print("close")
s.close()
break
conn.sendall(data)
Client:
# - * - Coding: UTF-8 - * -
"" "
@time: 2019/6/26 pm 4:55
@author: Yrr
@file: socket_client_test.py
@Desc: Test self._socket.setsockopt (socket.SOL_SOCKET , socket.SO_REUSEADDR,. 1)
"" "
Import Socket
the hOST = '127.0.0.1' host name or IP address of the server #
pORT = 9999 # ports used by the server
S = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
S .connect ((the HOST, PORT))
s.sendall (b'Hello, World ')
Data = s.recv (1024)
Print (' Received ', the repr (Data))
Implementation of the results:
We find that when we take the initiative to shut down the server, if we run this program again, the error will be reported, said the port is still occupied. This is very strange, obviously has closed the connection, why would occupy the port it? We use the netstat -an | grep 9999 command to view and found that the current connection is in the TIME_WAIT state.
Us under TIME_WAIT state. That is, when one party is disconnected, it does not directly enter CLOSED state, but transferred to the TIME_WAIT state, in this state, need to wait 2MSL (Maximum Segment Life, segment maximum survival time) time to completely shut down.
Issues involved:
1, Why have TIME_WAIT state exist?
In simple terms there are two reasons:
a. When the last sender send a confirmation message, still no guarantee that recipients can receive the information, if not received, then the recipient will be retried at a time when the sender has actually closed, not to accept the request .
b. If the sender closed after a confirmation message, the recipient to process the information in the acknowledgment, the sender is possible to issue a connection request again, this time it went wrong. Just connect finished, it received information confirming closed.
2. Why is long 2MSL it?
In fact, this is relatively easy to understand, so I send a confirmation message to reach the maximum time MSL, and if you do not receive, try again, but also the longest MSL, then I'll wait 2MSL, if you have not received a request to prove that you really I have received normally.
Just because we have the TIME_WAIT state, so we usually say the client to close, generally does not allow the server to shut down. How to avoid the situation that after closing the port is occupied appearance (ie, how to solve the problems above code example) it? Very simple, add a line of code can be realized:
# Socket.SO_REUSEADDR close a rear port reusable
s.setsockopt (socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
Python common interview questions in this three-way handshake with the topic of the fourth wave is still relatively high, the knowledge contained more also, slowly digested! There are places where unclear,