The video becomes a PPT webpage and opens instantly. I understand TCP and UDP.

Last week, my mother was watching a video of her niece from college. The screen was stuck in a PPT and the sound was cut off. She thought her phone was broken. But under the same WiFi, I can browse web pages and open them in seconds, and download things very quickly. Half of the network is paralyzed, but only half of it is broken. The root of this problem lies in the two protocols TCP and UDP. Today I will clarify these two things. After reading them, you can solve two types of practical problems.: The strange problem of the video card webpage not being stuck, and the pitfall of choosing the wrong protocol for port forwarding.

Make it clear first: One has to sign for it, the other stuffs it in the mailbox and leaves.

TCP and UDP are both "transportation methods" that help you pull data from one device to another. The difference is in temperament.

TCP is like sending registered mail. The two parties contact each other first before shipping. Each package must be signed by the other party for receipt. If it is lost, it will be re-sent. If the order of receipt is messed up, it can be put back together according to the number. There are more rules, a little slower, but not a single byte less.

UDP is like putting a letter in the mailbox and leaving. Just forget about it after sending it, without confirming whether the other party has received it or not, and regardless of the order. Travel lightly and fly quickly, but the price is that you may lose it and get it out of order.

This account can be seen most directly on the data packet header.: UDP's packet header is fixed at 8 bytes, TCP's packet header starts at least 20 bytes, and a bunch of mechanisms for handshake confirmation and retransmission are all stuffed in it. One carried a backpack and went out, and the other dragged three suitcases. No one is better, only the goods are not suitable - the web page will be incomplete if one byte is missing, and TCP is required ； Real-time voice is uncomfortable if it is delayed by half a second, so I would rather use UDP.

What TCP pays attention to: Shake hands first, ask for a receipt, and resend if lost.

There is a three-way handshake before TCP starts, which can be translated into three sentences in human language: can you hear it? can hear. Okay, let me start. After completing these three sentences, a "connection" is established. After that, all packets follow this path. Each packet has a sequence number, and the other party receives a receipt and a receipt. If the sender finds out which receipt has not come, it will resend that packet.

I opened a dozen web pages on the computer at home, connected the network disk and WeChat, and typed netstat -ano After counting, there are fifty or sixty TCP connections in the ESTABLISHED state - every time a web page is opened or a file is transferred, there is a connection waiting for a handshake behind it. You can also type this command. It comes with Windows. The status of the fourth column is all ESTABLISHED, which is a registered mail channel signed and received.

The price is also clear. When the network shakes and packets are lost, TCP stops retransmitting and the speed drops accordingly - I wrote before Packet loss troubleshooting As mentioned in that article, the download speed was inexplicably cut in half. In many cases, it was not because the network was disconnected, but because TCP was crazily patching things up behind the scenes. The advantage is that you have never seen a webpage open with half a picture missing, which means the receipt mechanism is at fault.

After the chat, you have to go through a farewell process, which is called waving four times in jargon. Both parties confirm "I'm done" and "I'm done" before removing the stitches. Therefore, every TCP connection is a complete process with a beginning and an end. There is a cost to establish, a cost to maintain, and a cost to disconnect. If the phone is left on all night without locking the screen, dozens of connections are waiting in the background, and more than half of the router's session table is occupied by TCP - this is a story for later, and will be mentioned below.

UDP doesn't care about this: Send it and forget about it, the picture is just for quickness

UDP doesn't even have a handshake, just throw the packet out and that's it. It sounds rough, but this is what happens in many jobs.

The first one is a DNS query. You type in a URL, and the computer asks the DNS server "What IP does this URL correspond to?" The question and answer totals dozens of bytes. Shaking hands three times for these dozens of bytes, and then waving goodbye four times after answering is purely torturous, so DNS uses UDP, sends out one packet and waits for the answer directly - this is me Write the article about DNS resolution The origin of the "UDP 53 packet" mentioned at the time. There are exceptions: If the answer exceeds 512 bytes (for example, a domain name has dozens of records), UDP will be truncated if it cannot fit in the package, and the client will automatically change to TCP and ask again. The small question and answer sheet uses UDP, and the large answer sheet uses TCP. Each one does its own thing.

The second one is multicast. One IPTV channel is watched by the entire city, and the signal is split from one to multiple at the halfway point, making it impossible for each viewer to sign in, so multicast It is only built on UDP, which is fixed when the protocol is designed.

The third one is video calling. A stupid thing will happen when using TCP for real-time images.: The network trembled and two frames were lost. TCP struggled to retransmit the old frames, but the scene had already passed. You were watching a replay of two seconds ago in the live broadcast. Therefore, the common practice in the industry for real-time audio and video such as WeChat videos and Tencent conferences is that UDP is used as the base, and a layer of RTP is placed on top to take care of timestamps and sequences. If a frame is lost, the next frame is directly compiled on top. My mother’s PPT picture that night showed that the UDP packet was lost on the road and no one was there to fix it.

Who at home uses TCP and who uses UDP?: A table to distinguish

The last line is the easiest to confuse: Many people think that pinging UDP is actually an ICMP protocol. It is three kinds of things in parallel with TCP and UDP. It does echo detection of "Are you there?", I Write about the delay It is used for pinging from section to section.

Two really useful scenes

first scene: If the port forwarding protocol is selected incorrectly, it is equivalent to a wasted configuration. TCP port 443 and UDP port 443 are two completely different doors, and their respective rules do not overlap with each other. For game consoles port forwarding The official table at that time was divided into two columns - PS5's TCP 1935 and UDP 3074 are two entries. If you only switch the TCP door, the UDP door will still be closed, and the connection will still have a yellow light. qBittorrent requires a green light to be seeded, and both TCP and UDP are required. Its μTP transmission itself uses UDP to imitate the temperament of TCP. Write about the downloader I was tricked by it once when driving at the speed limit. I really can't tell, so I choose "all" in the agreement column. It's better to open more doors than to open less doors.

second scene: Hemiplegia triage. The voice card and game card are stuck, but the webpage opens instantly - UDP is lost. Check the following directions: channel congestion during evening peak hours, 2.4G interference, and router QoS suppression of small packets. ； On the contrary, the web page is slow and the voice is not bad. That is because TCP is losing packets and retransmitting, and the speed is slowed down by the patch. The root cause investigation methods for the two types of diseases are different. I have written a three-stage ping method, just follow it. There is another hidden spot: The UDP entry in the router's NAT session table times out quickly and hangs. BT species protection That kind of UDP has a large number of users, and all new connections are lost when the table is full. This is also the main fault of UDP.

Games are the category that understands the temper of UDP the most. In a shooting game, you fire a shot, and the data packet of this shot arrives half a second late, and everyone runs away. This shot is like a waste of time - so the battle data is born in UDP, and if it is lost, it is lost, and it will come back immediately in the next frame. The game accelerator boasts of "reducing latency", and most of the time is spent on finding a smoother path for UDP packets, which has nothing to do with TCP. This also explains a strange phenomenon: The internet speed at home was measured at 500 Mbit/s, and the game was still 460 Mbit/s. This is because the speed test webpage ran smoothly using TCP, but the small UDP packets for the game could not squeeze through others in the channel during the evening rush hour.

ending: What to do first and then what to do

If you really encounter the "video card website is good" kind of paralysis, follow this order: The first step is not to blame the broadband. First, change the network cable and connect it directly or test it against the router to rule out the signal. ； The second step is to ping three sections to see which section the packet loss falls on. ； The third step is to move the mobile phone from 2.4G to 5G. UDP packets die fastest on crowded channels. ； Step 4: Check QoS or "Smart Speed ​​Limit" in the background of the router to see if there is pressure to upload. ； The fifth step is still stuck. Test again after ten o'clock in the evening. It will be smooth after the evening rush hour. That is the fault of the shared exit. When reporting for repair, please bring the packet loss record. The two agreements are indistinguishable, one must deliver all the goods, and the other must throw the goods over quickly-knowing which bowl of rice each item in your house is for will prevent you from rushing to the doctor if you get a strange illness.

By the way, I finally figured out what was wrong with my mother that night.: She is used to checking her mobile phone in her bedroom, and the signal there is 2.4G. During the evening peak, the 2.4G signal in the whole building is squeezed into a pot of porridge, and UDP packets are the first to suffer. Plug the phone into the 5G band and the picture will be smooth on the spot. Half of them were paralyzed and looked at the evil door. When they were taken apart, half of the goods were on the way and the other half were stuck in traffic jams.