Reference answer
TCP, or Transmission Control Protocol, is a connection-oriented protocol. That means before any data exchange happens, TCP establishes a connection, often called a "three-way handshake." Think of it like making a phone call: you dial, the other person answers, and then you confirm you can hear each other before you start talking. This handshake involves SYN, SYN-ACK, and ACK packets. It ensures both ends are ready to communicate. Once established, TCP guarantees reliable delivery of data. It ensures packets arrive in order, without errors, and without being duplicated. If a packet gets lost, TCP will retransmit it. It also manages flow control, preventing a fast sender from overwhelming a slow receiver, and congestion control, adjusting transmission rates to avoid network overload. I've seen these mechanisms at play when analyzing packet captures. For instance, during a large file transfer, if I see TCP Window Full messages, I know the receiver's buffer is overwhelmed, and TCP is naturally slowing the sender down. This reliability is why applications like web browsing, email, and file transfers (FTP) heavily rely on TCP. If you're downloading a software update, you absolutely want every byte of that file to arrive correctly. I've used TCP extensively when setting up secure shell (SSH) connections to network devices or configuring BGP sessions between routers, where maintaining a consistent and accurate state is paramount.
UDP, or User Datagram Protocol, on the other hand, is connectionless. It's like sending a postcard; you just put it in the mail without any prior agreement or confirmation. There's no handshake. UDP sends data without establishing a connection first, and it doesn't guarantee delivery, order, or error checking. If a UDP packet gets lost, it's just gone. There's no retransmission mechanism built into UDP itself. It's a "fire and forget" protocol. It also doesn't implement flow or congestion control. This might sound unreliable, but it makes UDP much faster and introduces less overhead than TCP because it avoids all the connection setup and management processes. This speed and minimal overhead make UDP ideal for applications where low latency is more critical than absolute reliability, or where the application itself handles error checking at a higher layer. For example, Voice over IP (VoIP) and video streaming typically use UDP. If you miss a few milliseconds of audio in a phone call, you might not even notice, and it's better to get the next bit of audio quickly than to wait for a retransmission that might further delay the conversation. DNS queries also use UDP because they are typically small, single-request/single-response transactions where quickness is more important than a guaranteed session. I've configured DNS servers and seen them primarily using UDP port 53 for queries. Network monitoring protocols like SNMP also often use UDP because quick, periodic data collection is more valuable than ensuring every single data point arrives, especially if the network is under stress. When I'm checking application logs and see drops or timeouts related to these types of services, my first thought goes to whether the application is built to handle UDP's inherent unreliability or if there's a different underlying issue. I've configured QoS policies for VoIP traffic, prioritizing UDP packets over other traffic to ensure clear calls, directly leveraging UDP's characteristics for real-time services.