Cloud Parts

Network protocols

The agreed rules that move bytes between machines, stacked in layers: IP finds the host, a transport such as TCP or UDP finds the program, TLS keeps it private, and HTTP or FTP says what the bytes mean.

7 technologies on this page ↓
Live model
What you’re watchingTop: requests travel over one TCP connection and every one gets its reply, because TCP resends whatever the network drops. Bottom: a sensor fires UDP datagrams with no connection and no acknowledgements; the ones the network drops are simply gone.

How it works

Every message travels in layers. IP carries a datagram from one address to another, router by router, with no promise that it arrives, arrives once or arrives in order. A transport protocol on top adds port numbers, 16-bit values that pick the program on that host: a web server listens on TCP port 443, a DNS server on UDP port 53. TCP is connection-oriented: a three-way handshake (SYN, SYN-ACK, ACK) agrees on sequence numbers, then it delivers a reliable, in-order byte stream, resending lost segments and slowing down when the path is congested. UDP is a datagram service: each message goes out on its own behind an 8-byte header, and nothing is resent, deduplicated or reordered. QUIC builds reliable, encrypted streams on top of UDP. A security layer, TLS, proves the server’s identity with a certificate and encrypts everything above it. The application protocol defines the conversation itself: HTTP’s methods, paths and status codes, or FTP’s USER, RETR and STOR commands. Fetching https://shop.example/cart means a DNS lookup for the address, a TCP connection to port 443, a TLS handshake, then an HTTP request and response inside the encrypted stream.

Think of it as

A letter in nested envelopes. The outer one has the street address (IP), the next names the person in the building (the port), a sealed, tamper-evident one keeps the letter private (TLS), and the letter inside is written in a language both sides agreed on (HTTP). TCP is registered mail with a receipt for every page; UDP is a postcard.

Reach for it when

  • HTTPS for anything that crosses a network you don’t control, including calls between your own services
  • TCP, or QUIC, when every byte must arrive in order: web pages, APIs, database sessions, file transfers
  • UDP when late data is worthless or the application handles loss itself: DNS lookups, voice, video, game state, metrics
  • SFTP or FTPS when a partner or an older system exchanges files by logging in to a server

Think twice when

  • Plain HTTP or FTP outside a lab: passwords, cookies and files cross the network readable by anyone on the path
  • Raw UDP for data that must not be lost, unless you build acknowledgements, retries and congestion control yourself (or use QUIC)
  • A home-made protocol over raw TCP when HTTP or an RPC framework already handles message framing, errors and timeouts
  • Plain FTP through NAT and firewalls: its separate data connection on a negotiated port breaks easily, so prefer SFTP or HTTPS

A real example

A phone app loads https://api.shop.example/orders. DNS returns 203.0.113.10. The phone opens a TCP connection to port 443 (one round trip for SYN, SYN-ACK, ACK), runs a TLS 1.3 handshake (one more round trip), and only then sends GET /orders. On a mobile link with a 50 ms round trip, that’s 100 ms before the request leaves the phone. Over HTTP/3, QUIC sets up the transport and TLS in one combined round trip, and a returning client can send its request in the very first flight (0-RTT). Meanwhile the app reports telemetry as UDP datagrams; if one in a hundred is lost, the dashboard barely changes and nothing is resent.

Kinds of network protocols

Specific products, and what each does differently.

Security protocols →

TLS: the layer that proves the server’s identity with a certificate, agrees on fresh keys and then encrypts and integrity-checks every byte for the protocol above it.

TLSOpen sourceTransport Layer Security: a handshake that authenticates the server (and optionally the client) and agrees on fresh keys, then records that keep everything above it private and tamper-evident.

The common protocols at a glance#

Each row stacks on the layers below it. Ports are the defaults a client uses when none is given.

ProtocolLayerDefault portRuns overEncryptionSpecification
TCPTransportCarries the port numbersIPNoneRFC 9293 (2022), first RFC 793 (1981)
UDPTransportCarries the port numbersIPNoneRFC 768 (1980)
QUICTransportAny UDP port; UDP 443 for HTTP/3UDPTLS 1.3, always onRFC 9000 (2021)
TLSSecuritySet by the protocol it protectsTCP; inside QUIC’s handshakeIs the encryptionRFC 9846 (2026), first TLS 1.3 as RFC 8446 (2018)
HTTPApplicationTCP 80TCPNoneRFC 9110 (semantics), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2)
HTTPSApplicationTCP 443; UDP 443 for HTTP/3TLS over TCP, or QUICTLSRFC 9110, RFC 9114 (HTTP/3)
FTPApplicationTCP 21 (control); data on a second, negotiated portTCPNoneRFC 959 (1985)
FTPSApplicationTCP 21 with AUTH TLS (explicit), or TCP 990 (implicit)TLS over TCPTLSRFC 4217 (2005)
SFTPApplicationTCP 22 (SSH)SSH over TCPSSHInternet-Drafts only, never an RFC
  • Ports from the IANA service name and port number registry. IANA assigns 0–1023 and 1024–49151 to services; 49152–65535 are never assigned and are used for temporary client ports.
  • TCP port 115 is registered as “sftp” for the unrelated Simple File Transfer Protocol. SSH File Transfer Protocol runs on SSH’s port 22.

In code · python

import socket
import ssl

REQUEST = b"HEAD / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n"

# TCP: create_connection runs the three-way handshake, then bytes flow in order
with socket.create_connection(("example.com", 80), timeout=5) as tcp:
    tcp.sendall(REQUEST)
    print(tcp.recv(1024).split(b"\r\n")[0])  # b'HTTP/1.1 200 OK'

# HTTPS: the same request inside TLS, on port 443
ctx = ssl.create_default_context()  # verifies the certificate and host name
with socket.create_connection(("example.com", 443), timeout=5) as raw:
    with ctx.wrap_socket(raw, server_hostname="example.com") as tls:
        print(tls.version())  # TLSv1.3
        tls.sendall(REQUEST)
        print(tls.recv(1024).split(b"\r\n")[0])  # b'HTTP/1.1 200 OK'

# UDP: no connection; each sendto is one datagram that may or may not arrive
rx = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
rx.bind(("127.0.0.1", 0))  # the OS picks a free port
tx = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
tx.sendto(b"temp=21.5", rx.getsockname())
print(rx.recvfrom(1500)[0])  # b'temp=21.5'

Often confused with

Remote procedure callsWeb APIsDNSLoad balancersCDNsAPI gatewaysRemote accessService discovery & mesh
Where it came from1971–2021

File transfer is one of the oldest jobs on the network. In April 1971 Abhay Bhushan at MIT published a File Transfer Protocol as RFC 114, for moving files between the Multics and ITS machines over the ARPANET’s host-to-host protocol, NCP. As ARPA funded packet radio and satellite networks, it became clear that NCP couldn’t span them, and in 1973 work began on a protocol that could. The result was split into layers: IP (RFC 791, September 1981) moves datagrams between hosts with no promise of delivery, TCP (RFC 793, the same month) adds reliable connections at the two ends, and UDP (RFC 768, August 1980) gives programs such as name servers a bare datagram. The ARPANET planned to switch from NCP to TCP/IP completely by 1 January 1983, and FTP was rewritten for TCP, ending up as RFC 959 in 1985.

Tim Berners-Lee’s HTTP of 1991 was one line over a TCP connection to port 80: GET and a document address, answered with HTML, after which the server closed the connection. HTTP/1.0 (RFC 1945, 1996) and HTTP/1.1 (RFC 2068, 1997) added headers, media types, caching and persistent connections. Security arrived as a separate layer underneath. Netscape’s SSL, whose version 3.0 of November 1996 became the basis of the IETF’s TLS 1.0 in 1999, ran under HTTP on its own port, 443, which RFC 2818 documented in 2000.

The newest layers came from the web’s need for speed. Google’s SPDY (2009) multiplexed many requests over one connection and became the foundation of HTTP/2 (RFC 7540, 2015). TCP still delivered bytes strictly in order, though, so one lost packet stalled every stream. Google’s QUIC experiment (2013) moved streams, loss recovery and encryption into a new protocol over UDP. The IETF standardised QUIC as RFC 9000 in May 2021, with TLS 1.3 built in, and HTTP/3 on top of it in June 2022. Meanwhile browsers dropped FTP: Chrome 88 disabled it entirely, noting that its FTP client had no support for encrypted connections.

Why it’s built this way

Layers that each do one job
IP only moves datagrams between hosts and has “no mechanisms to augment end-to-end data reliability, flow control, sequencing” (RFC 791). Reliability lives in the two end hosts, in TCP, so new transports such as UDP and later QUIC could be added without changing the routers in between.
Port numbers to address programs
One host runs many services. A 16-bit port in every TCP and UDP header picks the program, and well-known ports (21 for FTP, 80 for HTTP, 443 for HTTPS) let a client reach a service without asking first.
A connection for streams, a datagram for messages
TCP pays for a handshake and keeps state so it can resend, reorder and pace data. UDP skips all of that: “delivery and duplicate protection are not guaranteed” (RFC 768), which suits a one-packet name lookup or live audio, where a late packet is useless.
Encryption as a layer of its own, later built in
SSL and TLS slid under existing protocols unchanged, which is why HTTPS and FTPS are the old protocols plus TLS on another port or after one command. QUIC instead makes TLS 1.3 part of the transport handshake and authenticates every packet, so nothing it carries is ever sent unprotected.

Timeline

  1. 1971

    RFC 114 proposes a File Transfer Protocol for the ARPANET

  2. 1980

    UDP published as RFC 768

  3. 1981

    IP and TCP published as RFC 791 and RFC 793

  4. 1991

    Tim Berners-Lee’s first HTTP: one GET line over TCP port 80

  5. 1999

    TLS 1.0 (RFC 2246), based on Netscape’s SSL 3.0

  6. 2015

    HTTP/2 (RFC 7540), built from Google’s SPDY

  7. 2021

    QUIC standardised as RFC 9000; HTTP/3 follows in 2022

Sources17

Improve this page on GitHub