Why two ways to send

IP moves a datagram from one address to another by handing it from router to router. Each router reads the destination address, picks the next hop and passes the datagram on. That is all it does, and it makes no promise about the result. A datagram can arrive late, arrive twice, arrive out of order, or not arrive.

This is deliberate. A router that never repairs anything stays simple, and the repair is left to the two ends, which know what their data is for. TCP and UDP are the two ways the ends commonly do it. Both ride on IP: the IP header names the one inside by a protocol number, 6 for TCP and 17 for UDP.

UDP gives an application the datagram and nothing else. No handshake, no resend, no ordering. What the sender hands over arrives whole or not at all, and if it does not arrive, nobody is told.

TCP gives an application a reliable, in-order stream of bytes, in the words of RFC 9293. It numbers the bytes, acknowledges what arrived, sends again what did not, and hands the receiving program the bytes in order. The price is state at both ends, and a wait whenever something is missing.

Where the classroom bends

The lesson uses a classroom because it can be watched, and it is wrong in four places. A strip stands for a range of bytes, not a page or a sentence, and TCP's cuts fall wherever they fall. Real data crosses in milliseconds, not minutes, and arrives over time. A desk is a router: it reads the address and passes the datagram on without reading what is inside. Real loss is mostly a full queue or a noisy radio link, not a desk that misbehaves. The kids are not computers either: the senders and receivers are programs, with ports and buffers, as the next lessons show.

What it costs

Choosing the wrong one has a price you can name. A file sent over UDP arrives with holes unless the program checks for them and asks again, which is rebuilding TCP by hand. A live score sent over TCP has the opposite problem: when one segment goes missing, every byte behind it waits for the resend, even though the newer score is already in the receiver's buffer. Neither is slow or fast by nature. Speed comes from the network between them. What differs is what each one repairs.

On an ESP32, WiFiClient is TCP and WiFiUDP is UDP, both on the same lwIP stack, and the last lesson comes back to them. Joining Wi-Fi in the first place is Wi-Fi station mode.

Common mistakes

• Choosing by "fast" or "important". Ask what the data needs when a piece goes missing: a repair, or the next piece.
• Thinking UDP loses packets all the time. On a healthy local network loss is rare. The point is that nobody repairs it for you when it happens.
• Thinking a TCP acknowledgement means the other program used the data. It means the other side's TCP has the bytes. Whether the program read them is another matter.
• Picturing a wire between the two ends. A connection is state kept in the two ends. Apart from NAT and stateful firewalls, the routers between them keep none.