This is the third day of my participation in the August Challenge. For details, see:August is more challenging
UDP
Features:
- No connection, unreliable.
- For datagrams, send and receive can only be done once.
- There is a receive buffer, there is no send buffer (the sender does not care if it is received)
- The maximum data to be sent is 64K, which needs to be manually layered at the application layer and sent multiple times. The receiver manually asseminates the data.
UDP application scenarios:
1. Datagram oriented 2. Most network data is short messages 3. No special requirements for data security 5. The network burden is heavy, but the response speed is high
Application layer protocol based on UDP:
NFS: network file system TFTP: simple file transfer protocol DHCP: dynamic host configuration protocol BOOTP: startup protocol DNS: domain name resolution protocolCopy the codeUsing UDP to achieve reliable transmission?
The transport layer cannot guarantee the reliable transmission of data, only through the application layer to achieve. The implementation mode can be similar to the TCP reliability transport mode, but the implementation is not at the transport layer, the implementation is transferred to the application layer. The simplest way is to mimic the reliable transport of TRANSPORT layer TCP at the application layer. Simple design for reliable UDP without considering congestion handling. 1. Add seQ/ACK mechanism to ensure that data is sent to the peer end. 2. Add send and receive buffers, mainly for user timeout retransmission. 3. Add the timeout retransmission mechanism.Copy the codeUDP programming server side of the general steps are:
Create a socket using the socket() function. Setsockopt (); setsockopt(); * Optional 3. Bind IP address, port, and other information to the socket using the function bind(); Recvfrom (); recvfrom(); 5. Close the network connection;
UDP programming client general steps are:
Create a socket using the socket() function. Setsockopt (); setsockopt(); * Optional 3. Bind IP address, port, and other information to the socket using the function bind(); * Optional 4. Set the IP address and port of the peer. 5. Send data with sendto(); 6. Close the network connection;
TCP
TCP Format
16-bit source port number: The 16-bit source port contains the initial communication port. The source port and source IP address are used to identify the return address of the packet.
16-bit Destination port: The 16-bit destination port domain defines the destination of transmission. This port indicates the application address interface on the receiving computer.
32-bit serial number: The 32-bit serial number used by the receiving computer to refragment the packet into its original form. When SYN occurs, the sequence code is actually the initial sequence code, and the first data byte is the ISN+1. This sequence number (sequence code) can be used to compensate for inconsistencies in transmission.
32-bit confirmation serial number: The 32-bit serial number used by the receiving computer to reassemble the segmented packet into its original form. If the ACK control bit is set, this value represents the sequence code of a packet to be received.
4-bit header length: the 4-bit includes the TCP header size, indicating where data starts.
Reserved (6 bits) : A range of 6 bits, which must be 0. Reserved for future definition of new uses.
The 6-bit flag fields are: emergency flag, meaningful reply flag, push, reset connection flag, synchronize serial number flag, and complete sending data flag. The values are URG, ACK, PSH, RST, SYN, and FIN in that order.
6 bit Window size: Used to represent the size of each TCP data segment you want to receive. TCP flow control is provided by each end of the connection through a declared window size. The window size is in bytes, starting with the value specified in the validation ordinal field, which is the number of bytes the receiver expects to receive. The window size is a 16-byte field, so the maximum window size is 65535 bytes.
16-bit checksum: 16-bit TCP header. The source machine calculates a value based on the data content, and the receiver of the information should be exactly the same as the value of the source machine, so as to prove the validity of the data. Check and cover the entire TCP packet segment: this is a mandatory field that must be calculated and stored by the sender and verified by the receiver.
16-bit emergency pointer: Points to a byte followed by priority data. This is valid only when the URG flag is set. If the URG flag is not set, the emergency field is populated. Speed up processing of data segments marked urgent.
Options: length varies, but must be 1 byte. If you don’t have an option it means that this field of 1 byte is equal to 0.
TCP Security Mechanism
Acknowledgement response mechanism
After the three-way handshake, both the client and the server enter the data transmission state. TCP needs to ensure reliable connections over unreliable channels. The following problems are faced :(1) how to deal with packet loss when a packet of data may be split into multiple packets for transmission; To solve this problem, TCP establishes a send buffer, and the sequence number of the first byte after the establishment of the link is 0, and the sequence number of each subsequent byte is increased by 1. Send data, part from the send buffer data form to send a message, in the TCP header comes with serial number and length of the receiver to return confirmation message after receiving the data, confirm the ACK packet is received a serial number and length = under a pack of initial sequence number, which is under a pack need to send the starting serial number. This way of asking and answering can make the sender confirm that the sent data has been received. The sender can also send multiple packets of data consecutively at one time, and the receiver only needs to reply with an ACK. In this way, the sender can divide the data to be sent into a series of fragments and send it to the peer end. The peer end can reconstruct the complete data according to the sequence number and length after receiving it.
Timeout retransmission mechanism
As shown in the figure above, if a packet loss occurs during transmission, such as 100-199, the receiver will send an ACK =100 datagram to the sender. The receiver will resend it.
So how do you determine timeout? Due to the impact of the network bandwidth, the time is calculated dynamically. Set a base time, each time the base will be doubled, reach a certain number of times will close the connection!
Finally, there is a possibility of repeated transmission, this is very easy to solve, through the serial number can exclude repeated packets!!
Flow control
This is achieved by the window size of the TCP header.
The receiver puts its buffer size in the window size and tells the sender that the larger the window field is, the greater the network throughput and the higher the transmission speed will be. If the receiver finds that the buffer is almost full, it sets the window size to a small value and slows down the sending speed after receiving. In this way, flow control can be achieved. If the buffer is full, the window size is set to 0. The sender then stops sending data after receiving it, but periodically sends window probes to check whether the receiver can receive the data.
Congestion control
The sender will first send a small amount of data to detect network congestion, and then determine the speed of sending data based on the actual situation. The network status of the sender is identified by the congestion window size.
TCP connection mechanism (three handshakes, four waves)
A three-way handshake
- First handshake: When the connection is established, the client sends a SYN packet (SYN =x) to the server and enters the SYN_SENT state, waiting for the server to confirm. SYN: synchronization Sequence Numbers.
- Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK =x+1) and send its own SYN (ACK =y) packet. Then the server enters the SYN_RECV state.
- Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK =y+1) to the server. After the ACK packet is sent, the client and server enter the ESTABLISHED state (TCP connection succeeds) and complete the three-way handshake.
Interview question: Why three handshakes instead of two?
After the server replies with the SYN+ACK, the connection is set up to prevent errors caused by an invalid request packet being suddenly retransmitted to the server.
Assume two handshake is adopted to establish the connection, the client server sends a SYN packet request related to establish a connection, for some unknown reason, the server did not arrive, stranded in the middle is a network node, in order to connect the client will resend the SYN packet, the normal service, the server will reply to the SYN + ACK, after the connection is established. But the first packet of data block of network nodes, suddenly back, the first a pack of SYN packets sent to the server again, then the server will think that the client has launched a new connection, which has reached the awaited state data after two shake hands, the service side considered two connection, and the client as a connection, cause inconsistent state.
In the case of the three-way handshake, if the server does not receive the final ACK packet, the connection will not be considered successful, so the three-way handshake is essentially to solve the problem of unreliable network channels, in order to establish a reliable connection over unreliable channels.
Interview question: What if the client fails after the connection is established?
TCP also has a keepalive timer, so obviously, if a client fails, the server can’t wait and waste resources. The server resets the timer every time it receives a request from the client. The time is usually set to two hours. If no data is received within two hours, the server sends a probe segment and then sends it every 75 seconds. If there is no response after 10 consecutive probes, the server considers the client to be faulty and closes the connection.
Four waves
1) The client process sends the connection release packet and stops sending data. The header of the data packet is released, FIN=1, and its serial number is SEq = U (equal to the serial number of the last byte of the data that has been transmitted plus 1). At this time, the client enters the FIN-wait-1 state. According to TCP, a FIN packet segment consumes a serial number even if it does not carry data. 2) After receiving the connection release packet, the server sends a acknowledgement packet with ACK=1, ACK= U +1 and its serial number seq= V. Then the server enters the close-wait state. The TCP server notifies the high-level application process, and the client is released to the server. At this time, the client is in the semi-closed state, that is, the client has no data to send. However, if the server sends data, the client still accepts it. This state will continue for a period of time, that is, the entire duration of the closewait state. 3) After the client receives the acknowledgement request from the server, the client enters the FIN-wait-2 state, waiting for the server to send the connection release packet (before receiving the last data sent by the server). 4) After the server sends the LAST data, it sends the connection release packet to the client, FIN=1, ACK = U +1. Since the server is in the semi-closed state, it is likely to send some more data, assuming that the sequence number at this time is SEq =w, at this time, the server enters the last-ACK state. Wait for confirmation from the client. 5) After receiving the connection release packet from the server, the client must send acknowledgement, ACK=1, ACK= w+1, and its serial number is SEq = U +1. At this TIME, the client enters the time-wait state. Notice That the TCP connection is not released, and the client enters the CLOSED state only after 2∗∗MSL (maximum packet segment lifetime) expires and the corresponding TCB is revoked. 6) As long as the server receives the confirmation from the client, it will enter the CLOSED state immediately. Again, canceling the TCB terminates the TCP connection. As you can see, the server ends the TCP connection a little earlier than the client.
Interview question: Why do clients need to wait timeout?
This is to ensure that the other party has received the ACK packet, since the client is assumed to release the connection after sending the last ACK packet. Once an ACK packet is lost in the network, the server stays in the last-ack state. If the client waits for a period of time after sending the last ACK packet, the server resends the FIN packet because it does not receive the ACK packet. In response, the client resends the ACK packet and refreshes the timeout period.
Four waves are also used to ensure reliable disconnection and confirmation in unreliable network links.
Efficiency mechanism of TCP
The sliding window
An application of THE TCP protocol. It is used to control the flow of data transmission on the network. It sends datagrams concurrently to improve the transmission rate of the network and avoid congestion. This protocol allows the sender to send multiple data packets before stopping and waiting for confirmation. Since senders do not have to stop for acknowledgement every time they send a packet, the protocol speeds up data transmission and improves network throughput.
TCP does not respond to each packet segment with an ACK. It may send one ACK for two packet segments or one ACK for multiple packet segments. For example, the sender has 1, 2,3 packet segments and sends 2,3 packet segments first, but the receiver expects to receive 1 packet segment. If packet 1 does not arrive, 2/3 of the packet will be discarded. If packet 1 does arrive, an ACK will be sent to acknowledge the three packets once.
In fact, I even think this picture looks very annoying, at first glance, can not understand. Let me summarize briefly. This sliding window mechanism is designed to send data concurrently and improve transmission efficiency. A window is the number of datagrams we can send concurrently at one time. Within this window size, I send concurrently, and do not need to wait for the receiver’s ACK to send. Only if the receiver returns me an ACK telling me the number of the next datagram to send, will I slide the length according to that number. But returns an ack often are not satisfied, can be in the middle of a bunch of datagram, lost some packets, the receiver based on the idea of to get a complete packet, no matter what is lost, he will lack the packet sequence number is returned to you, and you can according to send serial number to know whether the data packet loss, for a special case, if the missing is the middle section of the bag, In this way, it is convenient for the sender to retransmit all the packets behind the lost segment according to its ACK, so that there will be no duplicate packets.
Delayed response
After receiving the data, the receiver can delay its response time without using the network, so that the server can consume the data quickly. After the idle buffer is larger, the window size of return to the receiver is larger, so that the transmission rate can be accelerated.
Delay mechanism: it can ack every n packets. You can also set a delay response time, after this time will ack once.
From the reply
On the basis of delayed response, we find that the receiver and sender are both “one send, one receive”, so when we send data, we send ACK to each other in the way of hitchhiking.
Stick package problem
Unlike UDP, TCP has no record of the packet length and only a serial number. Moreover, UDP is sent once and read once, while TCP is written to the buffer and sent again. In this way, the boundary between the start and end of multiple packets is not so clear. Therefore, we need to agree on the TCP data format at the application layer, and both parties parse according to the established format.
Finally, let’s summarize the differences between TCP and UDP
- TCP has high security but low efficiency. Udp is connectionless, unreliable, but fast.
- TCP is byte stream oriented and can be sent and received multiple times. Udp is datagrams oriented and can only be sent and received at one time
- Both sides of a TCP connection have send and receive buffer pools, while UDP has a receive buffer pool and no send buffer pool.
- The size of the data sent by TCP is not limited. The size of the data sent by UDP is the first. The maximum size of the data sent by UDP is 64K.
References:
Blog.csdn.net/qq_38950316…
Blog.csdn.net/m0_57668040…
\