Skip to main content

Protocol Comparisons

Side-by-side comparisons of protocols and specifications. When to use each, what the key differences are, and what the RFCs actually say.

35 comparisons available

HTTP

HTTPvsHTTPS

HTTP is the application protocol for web communication – it defines methods, headers, status codes, and message format. HTTPS is HTTP over TLS – the same protocol wrapped in an encrypted tunnel. In 2026, HTTPS is the only acceptable choice for any real deployment. HTTP exists for localhost development and the initial redirect to HTTPS.

TransportTCP – plaintext
Default port80
EncryptionNone – all traffic readable by any observer
View full comparison →
HTTP/1.1vsHTTP/2

HTTP/1.1 is a text-based protocol with persistent connections. Browsers open up to 6 parallel connections per origin to work around sequential request-response ordering. HTTP/2 is a binary protocol that multiplexes all requests over a single TCP connection and compresses headers with HPACK (85–90% reduction). For workloads dominated by many small assets, HTTP/2 significantly reduces round-trip overhead. The semantics – methods, headers, status codes – are identical. Only the wire format changed.

Wire formatText-based (ASCII, CRLF)
MultiplexingNo true multiplexing – responses are ordered. HTTP/1.1 defines pipelining but it was poorly deployed. Browsers open up to 6 parallel TCP connections per origin as a workaround.
HOL blockingSevere – slow response blocks all subsequent ones
View full comparison →
HTTP/2vsHTTP/3

HTTP/2 (RFC 9113) multiplexes requests over a single TLS-encrypted TCP connection, eliminating HTTP/1.1 head-of-line blocking at the HTTP layer. HTTP/3 (RFC 9114) goes further by replacing TCP with QUIC (UDP-based), eliminating TCP-level head-of-line blocking entirely and adding 0-RTT connection resumption. HTTP/3 is now the default on most CDNs. For most deployments behind a proxy or CDN, enabling HTTP/3 is a configuration change that improves performance with zero application changes.

TransportTCP + TLS 1.2/1.3
RFCRFC 9113 (2022)
Head-of-line blockingEliminated at HTTP layer; still exists at TCP layer
View full comparison →

Security

SSLvsTLS

SSL (Secure Sockets Layer) is the deprecated predecessor of TLS (Transport Layer Security). All SSL versions (2.0, 3.0) have critical vulnerabilities and are disabled in modern software. TLS 1.2 and 1.3 are the current standards. When people say 'SSL certificate' they mean a TLS certificate – the term persists from habit.

Latest versionSSL 3.0 (1996) – deprecated
Security statusBroken – POODLE, BEAST, DROWN attacks
Handshake RTTSSL 3.0: 2 RTT
View full comparison →
TLS 1.2vsTLS 1.3

TLS 1.3 (RFC 8446) is strictly better than TLS 1.2 in every meaningful dimension: 1 RTT handshake vs 2 RTT, mandatory forward secrecy via ephemeral key exchange, 5 cipher suites (all AEAD) vs a combinatorial set in TLS 1.2 that includes RC4, 3DES, NULL, and export-grade entries, encrypted certificates, and no renegotiation. The only reason to retain TLS 1.2 is legacy client compatibility.

Handshake round trips2 RTT – data starts on 4th message
0-RTT resumptionNot available
Forward secrecyOptional – static RSA key exchange still allowed
View full comparison →
IPsecvsWireGuard

IPsec is the enterprise VPN standard with decades of deployment, complex configuration, and IKEv2 key exchange. WireGuard is a modern VPN with ~4000 lines of code, fixed cryptography (Curve25519, ChaCha20), and kernel-level performance. WireGuard is simpler and faster; IPsec has broader interoperability and richer policy options.

Codebase size~400,000 lines (Linux kernel)
CryptographyNegotiable (AES-GCM, ChaCha20, SHA-2, DH groups)
Key exchangeIKEv2 (complex state machine, certificates or PSK)
View full comparison →

API & Application

RESTvsgRPC

REST uses HTTP/1.1 or HTTP/2 with JSON over text – human-readable, universally supported, and browser-friendly. gRPC uses HTTP/2 with Protocol Buffers (binary) – strongly typed, 5–10x smaller payloads, and bidirectional streaming. REST is the right default for public APIs and browser clients. gRPC is the right choice for internal microservice communication where performance and schema enforcement matter.

ProtocolHTTP/1.1 or HTTP/2, any transport
SerializationJSON (text) – human-readable, ~3–10x larger than Protobuf
SchemaOptional (OpenAPI/Swagger) – not enforced by default
View full comparison →
JSONvsProtobuf

JSON is human-readable text – easy to debug, universally supported, and self-describing. Protocol Buffers (Protobuf) is a binary format requiring a .proto schema – field numbers replace key names in every message, producing smaller payloads and faster parsing for typical structured data. The performance advantage is workload-dependent: measurable at high throughput, negligible for small payloads or low-RPS services. JSON wins on tooling and browser compatibility. Protobuf wins on throughput and compile-time type safety. gRPC uses Protobuf; REST APIs typically use JSON.

FormatText (UTF-8)
Human readableYes – readable in curl, browser, logs
Schema requiredNo (optional OpenAPI)
View full comparison →
WebSocketvsSSE

WebSocket is a full-duplex binary protocol – both client and server can send messages at any time. SSE (Server-Sent Events) is a half-duplex HTTP protocol – only the server pushes data; client-to-server communication uses separate HTTP requests. SSE is simpler, works over plain HTTP/2, and automatically reconnects. WebSocket is needed for true bidirectional, low-latency communication.

DirectionFull-duplex – client and server send simultaneously
ProtocolWebSocket (RFC 6455) – separate from HTTP after upgrade
Data formatBinary frames or text – any payload
View full comparison →
PollingvsWebhooks

Polling has the client ask the server repeatedly: 'Is there anything new?' Webhooks have the server push updates to the client when they happen. Polling is simple to implement and works everywhere. Webhooks are more efficient for infrequent events but require the client to have a publicly accessible HTTPS endpoint. The right choice depends on event frequency, infrastructure, and latency requirements.

Who initiatesClient pulls – requests on a schedule
LatencyUp to poll interval (seconds to minutes)
EfficiencyWasteful – most polls return 'nothing new'
View full comparison →
OAuth 2.0vsJWT

OAuth 2.0 is an authorization framework – a protocol defining how to delegate access between systems. JWT (JSON Web Token) is a token format – a compact, self-contained way to encode claims. They are not alternatives: OAuth 2.0 commonly uses JWT as its token format. Comparing them is like comparing a shipping protocol to the box format used for shipping.

What it isAuthorization framework – defines flows and grant types
ScopeProtocol – specifies how delegation happens
Stateful/statelessCan be either – depends on token type issued
View full comparison →
Synchronous APIsvsAsynchronous APIs

Synchronous APIs respond immediately – the client blocks until the result arrives. Asynchronous APIs accept a request, return immediately with a job ID or 202 Accepted, then deliver the result later via polling or webhook. Synchronous is simpler to implement and consume. Asynchronous is necessary when operations take longer than a few seconds or when decoupling producers from consumers.

Response timingImmediate – client waits for result
Client complexitySimple – one request, one response
Server complexityLower – simple request handler
View full comparison →