What is the difference between TCP and UDP? Video calls turn into PPTs, but webpages open instantly—I've figured out these two agreements

last week, my mom caught up with a video of her college niece. The screen froze into a PowerPoint slide, with her voice cutting out in every sentence. For a moment, she thought her phone was broken. But on the same WiFi line, I can instantly open the web and download things quickly. The network is half-paralyzed, and only half is broken—the root of this problem lies in the TCP and UDP protocols. Today, I've broken down these two things clearly. After reading them, you'll solve two types of practical problems: the strange issue of video cards and web pages not freezing, and the pitfalls of choosing the wrong port forwarding protocol and wasting the configuration.

to clarify first: one needs to sign for the mailbox, the other just stuffs the mailbox and leaves

Both

TCP and UDP are 'transportation modes' that help you pull data from one device to another. The difference lies in temperament.

TCP like sending a registered letter. Before shipping, both parties must contact each other. Each package requires the other party's signature receipt. If lost, it can be remailed. If the order of receipt gets messed up, the number can be reassembled as is. There are many rules, but a bit slower, but not a single byte is lost.

UDP like stuffing a letter into a mailbox and leaving. After sending it, they forget it, don't confirm whether the other party has received it, and don't care about the order. Traveling light, moving fast, the price is possible loss or disruption.

this account is most straightforward in the packet header: UDP packet headers are fixed at 8 bytes, TCP has at least 20 headers, and all the handshake confirmation retransmission mechanisms are packed inside. One left with a backpack, the other dragged three suitcases. No one is better, only whether the goods are suitable—if a page is missing one byte, it won't display completely, so you have to use TCP; If real-time voice is delayed by half a second, it becomes uncomfortable; better to use UDP.

TCP the elaborate routine: shake hands first, ask for receipts, resend if lost

TCP before work starts, there are three handshakes, which translate to three sentences in plain language: Can you hear them? You can hear it. Alright, I'll get started. After these three lines are completed, a "connection" is established. After that, all packages follow this path, each package has a serial number, and the other party collects one receipt for another. If the sender finds that the receipt hasn't arrived for a long time, they resend that package.

I opened a dozen web pages on my home computer, with cloud drives and WeChat running them, typing a netstat ano counted fifty or sixty ESTABLISHED TCP connections—every time I opened a webpage or sent a file, there was a handshake-like connection waiting behind me. You can also type this command. Windows comes with it, and the fourth column is all ESTABLISHED, which means the registered mail channels are signed for and received.

cost is obvious. When the internet shakes and packets are lost, TCP stops resending it, and the speed drops accordingly—I mentioned in my previous article packet loss troubleshooting that download speeds inexplicably halved. Often, it's not the network disconnection, but TCP frantically patching files behind the scenes. The advantage is that you've never seen a webpage open missing half an image, so the receipt mechanism is the catch.

After

conversation, there's still a farewell process, called four waves, and both sides confirm 'I'm done' and 'I'm done too' before removing the stitches. Therefore, every TCP connection is a complete process with a beginning and end; establishing it costs money, maintaining it costs money, and disconnecting it also costs money. If your phone stays on all night without locking, dozens of connections in the background just wait like this, and more than half of the router's session table is taken up by TCP—that's a topic for later, which I'll discuss later.

UDP don't care about any of this: after posting, they forget about speed

UDP didn't even shake hands; the bag was just thrown out. It sounds rough, but a lot of jobs work on this trick.

first is DNS queries. You type a website, and the computer asks the DNS server, 'What IP does this URL correspond to?' The Q&A totals dozens of bytes. Shake hands three times for these few cross-sections, then wave goodbye four times after answering—pure hassle. So DNS goes to UDP, and a package is sent out and you wait for the answer—this is the origin of the 'UDP 53 small packet' I mentioned when I wrote about DNS analysis. There are exceptions: if the answer exceeds 512 bytes (for example, a domain name has dozens of records), UDP will be cut off if the wrapper fails, and the client will automatically switch to TCP and ask again. Use UDP for small Q&A, TCP for large answers, each doing their own thing.

second is multicasting. When an entire IPTV channel is watched by the entire city, the signal splits midway through the process and drops into multiple copies, making it impossible to sign for each viewer individually. Therefore, multicast only built on UDP, which was fixed from the protocol design.

third is video calls. When the live screen goes to TCP, something silly happens: the network shakes and loses two frames. TCP struggles to retransmit the old frame, but the scene is already over—you're basically watching a two-second replay in the live stream. Therefore, for real-time audio and video platforms like WeChat Video and Tencent Meeting, the industry standard approach is to use UDP as a base, then layer RTP on top for timestamps and sequence, then frame by frame and top. That night, my mom's PPT showed a UDP bag lost on the road and no one made up for it.

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

the last line is the easiest to confuse: many people think ping is UDP, but it's actually the ICMP protocol, which is three things alongside TCP and UDP, and it does echo detection for 'Are you there?' The I wrote about the delay article used it for pinging segment by segment.

two scenarios that are truly useful

first scenario: choosing the wrong port forwarding protocol means it's a wasted setup. TCP port 443 and UDP port 443 are two completely different gateways, each with rules that do not overlap. When configuring a console to port forwarding , the official table is always divided into two columns—PS5's TCP 1935 and UDP 3074 are two entries. If you only rotate the TCP side, the UDP door stays closed, and online mode still shows a yellow light. qBittorrent needs a green light for a startup, and TCP and UDP must also work. Its μTP transmission is essentially using UDP to mimic TCP's temperament. I the post about downloading the machine got tricked by it once during speed limits. If you really can't tell the difference, select 'All' in the agreement section. Opening one more door is no problem—it's better than opening fewer.

second scenario: triage for hemiplegia. Voice card and game lag, but web pages open instantly—UDP is missing. Check for late-night peak channel congestion, 2.4G interference, router QoS pressure on small packets; On the other hand, web spider speed and voice are okay, but that's TCP losing packets and retransmitting, and the speed is slowed down by the patch. The two types of root cause detection methods are different. I've written about a three-stage ping method for locating—just follow the guidelines. There's another hidden point: UDP entries in the router's NAT session table quickly time out, BT those with many UDP users and all new connections lost when the table is full, which is also largely UDP's fault.

games are the type that truly understands UDP's temperament. In shooting games, if you fire a shot and the data packet arrives half a second late, the person runs away, and that shot is like white hair—so battle data naturally follows UDP, so if you lose it, just lose it, and the next frame will come back immediately. The game accelerator's hype about "reducing latency" is mostly spent on making UDP packets smoother, with nothing to do with TCP. This explains a strange phenomenon: my home internet speed was 500Mbps, but the game still ran 460, because speed-testing web pages ran smoothly over TCP, but the few UDP packets in the game couldn't squeeze through others during evening rush hours.

Conclusion: What to do first, then what to do

you really encounter a half-paralysis like "video card and webpage is good," follow this order: Step one: Don't blame broadband immediately; first switch to a network cable or test right next to the router to eliminate the signal; Step 2: Ping in three stages to see which segment the packet dropped on; Step three: move your phone from 2.4G to 5G; UDP packets die fastest on crowded channels; Step four: Check the router's background to see if QoS or 'Smart Rate Limiting' is pressing uploads; Step five is still stuck. After 10 p.m., test again. After the evening rush hour, everything will be smooth. That's the shared exit's fault, and repair reports should be made with the lost packet record. There's no superiority between the two agreements: one delivers all the goods intact, the other throws them over quickly—knowing exactly what kind of food your family is eating, so if a strange problem arises, you won't resort to desperate treatments.

By the way, my mom's problem that night was finally figured out: she was used to scrolling on her phone in the bedroom, and that bar was 2.4G. During the evening rush hour, the whole building's 2.4G was packed into a mess, and the UDP small packet was the first to suffer. Pinning the phone to the 5G band, the picture is instantly smooth. Half of it looks strange, but when you open it up, half the cargo is on the way, and the other half is stuck in traffic.