Eight Network Protocols in One Diagram

Network protocols are not eight different ways to do the same job. They sit at different layers and solve different problems. Some move bytes between machines, some secure those bytes, and some define what the bytes mean.

A useful way to read the list is from the bottom up. TCP and UDP are transport protocols. They decide how data moves between endpoints. HTTP, HTTPS, HTTP/3, WebSocket, SMTP, and FTP are application protocols or protocol families built on top of those transports.

TCP and UDP: the delivery layer

TCP gives applications a reliable ordered byte stream. It numbers bytes, expects acknowledgements, retransmits lost data, and uses flow control and congestion control so one fast sender does not overwhelm the network or the receiver. That makes TCP a good fit for web pages, APIs, databases, and anything where missing or reordered data would break the result. The cost is extra state, handshake latency, and head-of-line blocking: if one packet in a stream is missing, later bytes wait behind it.

UDP is much thinner. It sends independent datagrams with no built-in guarantee of delivery, ordering, or retry. That sounds primitive, but it is useful when low delay matters more than perfect recovery, or when the application wants to control recovery itself. DNS, voice calls, live video, online games, and QUIC all use UDP for that reason.

HTTP, HTTPS, and HTTP/3: the web family

HTTP defines requests and responses: methods such as GET and POST, headers, status codes, and optional bodies. It is stateless at the protocol level. A server does not automatically remember earlier requests unless the application adds cookies, sessions, or tokens. Classic HTTP commonly runs over TCP.

HTTPS is not a different application protocol from HTTP. It is HTTP carried inside TLS, the transport security layer that authenticates the server with a certificate and negotiates shared encryption keys. Once the TLS handshake completes, the HTTP messages are protected for confidentiality and integrity. That is why modern browsers treat plain HTTP as the exceptional case rather than the default.

HTTP/3 keeps normal HTTP semantics but moves them onto QUIC, which itself runs over UDP. QUIC provides reliable streams, encryption, and connection migration in one design. The practical win is that a single lost packet stalls only the affected stream instead of every stream sharing one TCP connection. That matters on mobile and lossy networks.

WebSocket: when request-response is not enough

WebSocket starts with an HTTP handshake, then upgrades the connection into a long-lived full-duplex channel. After that, client and server can send frames to each other at any time. Chat, collaborative editing, dashboards, and multiplayer systems use it when polling would be wasteful. The tradeoff is operational: long-lived connections consume memory, need heartbeats, and complicate load balancing.

SMTP and FTP: older protocols with narrow roles

SMTP is the protocol mail servers use to relay outgoing email. It is store-and-forward rather than instant end-to-end delivery. A server accepts a message, queues it, looks up the destination domain's mail exchanger, and retries if the next hop is unavailable. That delay-tolerant design is why email often arrives eventually even when part of the route is temporarily down.

FTP was built for file transfer and uses separate control and data channels. That design made sense early on, but it works badly with NAT and restrictive firewalls. It also predates modern transport security expectations. Today, plain FTP is uncommon on the public Internet. People usually prefer SFTP, SCP, or HTTPS-based downloads.

Why the stack matters

These protocols coexist because networks need layers. A browser might send HTTP semantics over HTTPS, which means HTTP over TLS over TCP over IP. A mobile app might use HTTP/3, which means HTTP semantics over QUIC over UDP over IP. The job of each layer is different. Once that clicks, protocol diagrams stop looking like alphabet soup and start looking like a set of engineering tradeoffs.