Network Foundations

Chapter 1: TCP Reliability

TCP transforms the unreliable mess of IP into a reliable, ordered byte stream. How? Three mechanisms: sequence numbers, acknowledgments, and retransmission. And before any data flows, the two sides must agree to talk — that is the three-way handshake.

The Three-Way Handshake

Before a client and server can exchange data, they must establish a connection. Why? Because TCP needs both sides to agree on initial sequence numbers and allocate resources (buffers, state). The handshake has three steps:

Sequence Numbers and Acknowledgments

Once the connection is established, every byte of data gets a sequence number. If the client's ISN was 1000 and it sends 500 bytes, those bytes are numbered 1001 through 1500. The server responds with an ACK number of 1501, meaning "I have received all bytes up to 1500; send me byte 1501 next."

This is how TCP detects loss. If the client sends bytes 1001-1500 and then bytes 1501-2000, but the first segment is lost, the server will keep ACKing 1001 — "I'm still waiting for byte 1001." After three duplicate ACKs for the same number, the client knows the segment was lost and retransmits it.

Notice that the server buffered the out-of-order segments (1501-2000 and 2001-2500). When the missing segment finally arrived, the server delivered all the buffered data at once and jumped the ACK number forward. This is called selective acknowledgment (SACK) in modern TCP.

Animated TCP Handshake & Data Transfer

Retransmission Timeout (RTO)

How long does TCP wait before retransmitting a lost packet? It uses a retransmission timeout (RTO) that adapts to the network. TCP continuously measures the round-trip time (RTT) — how long between sending a segment and receiving its ACK — and sets the RTO to be slightly larger than the smoothed RTT.

This adaptive approach is crucial. On a LAN with 1ms RTT, the RTO might be 10ms. On a transatlantic link with 150ms RTT, it might be 800ms. TCP adjusts automatically.

Putting It All Together: A Complete TCP Segment

Every TCP segment carries a header with critical fields. Here is what a real TCP header looks like:

The sequence number and acknowledgment number fields are the heart of TCP's reliability. The window field is flow control. The checksum catches corruption. Everything we discussed in this chapter is encoded in these 20 bytes.

Chapter 2: Connection Lifecycle

A TCP connection is not just "open" or "closed." It moves through a carefully defined set of states, each serving a specific purpose. Understanding these states is essential for debugging real production problems like port exhaustion, half-open connections, and the infamous TIME_WAIT buildup.

The TCP State Machine

Every TCP connection on your machine is in one of these states at any given moment. You can see them with netstat -an or ss -tan.

The Four-Way Close

Opening a connection takes 3 messages. Closing takes 4, because each direction closes independently. Think of TCP as two one-way streets — each side must close its own lane.

TIME_WAIT: Why Wait 2×MSL?

The Maximum Segment Lifetime (MSL) is the longest time a TCP segment can exist in the network before being discarded (typically 30 seconds to 2 minutes; Linux uses 60 seconds). TIME_WAIT lasts 2 × MSL (so 1-4 minutes).

Why wait at all? Two reasons:

In production, TIME_WAIT buildup is a common problem. A busy server closing thousands of connections per second can accumulate thousands of TIME_WAIT sockets, exhausting ephemeral ports. Solutions include SO_REUSEADDR, tcp_tw_reuse, and connection pooling (which we'll cover in Chapter 7).

Diagnosing Connection States in Production

Here is what to look for when you see each state accumulating:

bash
# Count connections by state
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

# Example output for a healthy server:
#  2847 ESTAB        ← active connections, normal
#   142 TIME-WAIT    ← recently closed, normal if <1000
#    12 LISTEN       ← server sockets, normal
#     3 FIN-WAIT-2   ← closing, transient, normal

# Example output for a SICK server:
#  2847 ESTAB
# 28104 TIME-WAIT    ← PORT EXHAUSTION IMMINENT
#  1893 CLOSE-WAIT   ← APPLICATION BUG (not closing sockets)
#    12 LISTEN

TCP State Machine Visualization

Chapter 3: Flow Control

Imagine you are reading aloud to a friend who is writing down every word. You speak at 200 words per minute. Your friend writes at 50 words per minute. Within seconds, they fall behind. Words pile up faster than they can be recorded. Information is lost.

The same problem exists in TCP. A fast sender (a powerful server sending a large response) can overwhelm a slow receiver (a mobile phone with limited memory). The receiver's buffer fills up, and new packets have nowhere to go — they get dropped, retransmitted, dropped again. Without some mechanism to match the sender's speed to the receiver's capacity, the connection devolves into an inefficient cycle of overflow and retransmission.

Flow control is TCP's elegant solution: the receiver explicitly tells the sender how much buffer space is available, in every single ACK packet. The sender limits itself to sending only that much unacknowledged data. If the receiver is slow, the sender automatically slows down. If the receiver speeds up, the sender speeds up too. The mechanism is entirely receiver-driven — the receiver is always in control of the pace.

The Receive Window

Every TCP ACK packet contains a field called the receive window (rwnd) — a 16-bit number (up to 65,535 bytes, or much larger with window scaling) that says "I have this many bytes of free buffer space." The sender must obey this limit.

As the receiver's application reads data from the buffer, more space frees up, and the receiver advertises a larger window. As the buffer fills, the window shrinks. If the buffer is completely full, the receiver advertises rwnd = 0, and the sender must stop sending entirely.

Zero Window and the Persist Timer

When the receiver advertises rwnd = 0, the sender enters a zero window state and stops sending data. But how does the sender know when the receiver has space again? The receiver will send a new ACK with a larger window when buffer space frees up — but what if that ACK is lost? The sender would wait forever.

TCP solves this with the persist timer. When the sender sees rwnd = 0, it periodically sends tiny window probe packets (1 byte) to ask "do you have space yet?" The receiver responds with the current window size. This prevents deadlocks.

Sliding Window Animation

When you set the read speed low, watch the receive window shrink. The sender is forced to slow down — that is flow control in action. Set it to 1 and watch the window hit zero: the sender stops completely until the application drains the buffer.

Window Scaling

The original TCP header allocated 16 bits for the receive window, giving a maximum of 65,535 bytes. On modern networks with high bandwidth and high latency (e.g., a 10 Gbps transatlantic link with 100ms RTT), 64 KB is absurdly small. You'd need to send 64 KB, wait 100ms for an ACK, send 64 KB, wait, send... Your effective throughput would be 64 KB / 100ms = 640 KB/s — on a 10 Gbps link.

Window scaling is negotiated during the three-way handshake using a TCP option. Both sides advertise their scale factor. Modern operating systems enable this by default.

Flow Control vs. Congestion Control

These two mechanisms are frequently confused. Let's make the distinction crystal clear:

In practice, for most web traffic within a datacenter (low RTT, fast receivers), congestion control is the bottleneck — cwnd limits sending during slow start. For cross-continental transfers with slow endpoints, flow control is the bottleneck — rwnd limits sending because the receiver can't process data fast enough.

Chapter 4: Congestion Control

Flow control prevents a fast sender from overwhelming a slow receiver. But what about the network between them? Routers have finite buffer space. If too many senders push data too fast, router buffers overflow, packets are dropped, and every sender retransmits, making the congestion worse. This is called congestion collapse, and it nearly killed the early internet in 1986. Literally: the internet's usable bandwidth dropped to a tiny fraction of its physical capacity because every sender was aggressively retransmitting lost packets, which caused more congestion, which caused more loss, which caused more retransmission. Van Jacobson's 1988 paper introduced the algorithms we are about to learn, and the internet recovered.

Congestion control is TCP's mechanism for sensing and avoiding network overload. It is separate from flow control: flow control is about the receiver's capacity; congestion control is about the network's capacity. Every TCP sender on Earth runs congestion control independently, and together they cooperatively share the internet's bandwidth without any central coordinator. It is one of the most successful distributed algorithms ever deployed.

The Congestion Window (cwnd)

In addition to the receiver's window (rwnd), each TCP sender maintains its own congestion window (cwnd) — an estimate of how much data the network can handle. The actual sending limit is:

The sender can never have more than effective_window bytes in flight. Even if the receiver has a huge buffer, the sender will self-limit based on its perception of network congestion.

Phase 1: Slow Start

When a new connection starts, the sender has no idea how much bandwidth the network can handle. It starts with cwnd = 1 MSS (maximum segment size, typically 1460 bytes). For every ACK received, cwnd increases by 1 MSS. Since each RTT roughly doubles the number of segments acknowledged, cwnd grows exponentially: 1, 2, 4, 8, 16, 32...

"Slow start" is a misnomer — the growth is exponential, so it ramps up quickly. It continues until cwnd reaches a threshold called ssthresh (slow start threshold).

Phase 2: Congestion Avoidance (AIMD)

Once cwnd ≥ ssthresh, TCP switches to congestion avoidance. Now cwnd grows linearly: increase by 1 MSS per RTT (not per ACK). This is the additive increase phase — carefully probing for more bandwidth without being aggressive.

When a packet loss is detected (via timeout or triple duplicate ACK), TCP assumes the network is congested and cuts cwnd dramatically — typically by half. This is the multiplicative decrease. Together, this is AIMD: Additive Increase, Multiplicative Decrease.

Fast Retransmit & Fast Recovery

There are two ways to detect loss:

Fast retransmit means retransmitting the lost segment immediately upon receiving the third duplicate ACK, without waiting for the full timeout. Fast recovery means starting congestion avoidance (linear growth) from the halved window rather than going back to slow start. These two optimizations make TCP much more responsive to isolated packet losses.

Congestion Window Visualization

The sawtooth is the signature of AIMD. Linear growth probes for available bandwidth. Each drop halves the window. Over time, TCP oscillates around the maximum capacity the network can handle. It is a beautifully simple and robust mechanism.

Fairness: How AIMD Shares Bandwidth

One of AIMD's most elegant properties is fairness. If two TCP connections share a bottleneck link, they converge to equal bandwidth — with no communication between them.

Imagine two senders, A and B, sharing a 100 Mbps link. A has cwnd=80, B has cwnd=40. Total = 120, which exceeds capacity. Packets are dropped. Both halve: A=40, B=20. Now both increase linearly: A=41, B=21, then A=42, B=22. At the next drop: A=halved, B=halved. Over time, the ratio converges to 1:1. This works because additive increase adds the same absolute amount, while multiplicative decrease preserves the ratio — but the combination trends toward equality.

CUBIC vs BBR: The Modern Landscape

Chapter 5: TLS/SSL

TCP gives us reliable, ordered delivery. But it provides zero security. Every byte you send over TCP is transmitted in plaintext. Anyone on the network path — your ISP, a coffee shop WiFi operator, a compromised router — can read your passwords, credit card numbers, and private messages. They can also modify them in transit without you knowing.

TLS (Transport Layer Security) solves three problems at once:

Symmetric vs. Asymmetric Encryption

TLS uses both types of encryption, each for a different purpose:

Asymmetric encryption (RSA, ECDHE) uses a key pair: a public key anyone can have, and a private key only the owner holds. It is slow but solves the key exchange problem — two strangers can agree on a shared secret over a public channel.

Symmetric encryption (AES-256-GCM, ChaCha20-Poly1305) uses a single shared key for both encryption and decryption. It is fast — 100-1000x faster than asymmetric. Once both sides have the shared secret, all data is encrypted symmetrically.

The TLS 1.3 Handshake

TLS 1.3 (the current standard) completes the handshake in a single round trip, down from two in TLS 1.2. Here is every step:

Certificate Chain Verification

How does the client know the server's certificate is legitimate? Through a chain of trust:

The client walks the chain: verify the server cert was signed by the intermediate CA, verify the intermediate was signed by a root CA that the client trusts. If any link fails, the connection is rejected.

Forward Secrecy

TLS 1.3 mandates forward secrecy (also called perfect forward secrecy, PFS). This means that even if the server's private key is compromised in the future, past recorded conversations cannot be decrypted.

How? Because each connection generates a new ephemeral Diffie-Hellman key pair. The shared secret is derived from these ephemeral keys, not directly from the server's long-term key. The server's private key is only used to authenticate (sign the handshake), not to encrypt. Once the connection closes, the ephemeral keys are discarded.

TLS Handshake Animation

Python TLS Socket

python
import ssl
import socket

# Create a TLS-wrapped TCP connection
context = ssl.create_default_context()  # loads system CA certs

with socket.create_connection(("example.com", 443)) as sock:
    with context.wrap_socket(sock, server_hostname="example.com") as tls:
        # Handshake happens automatically
        print(tls.version())       # 'TLSv1.3'
        print(tls.cipher())        # ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
        cert = tls.getpeercert()
        print(cert['subject'])     # server identity

        # Send an HTTP request over TLS
        tls.sendall(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")
        response = tls.recv(4096)
        print(response.decode())

python
# Inspecting TLS details programmatically
import ssl

context = ssl.create_default_context()

# Verify hostname and certificate
context.check_hostname = True
context.verify_mode = ssl.CERT_REQUIRED

# Pin to specific TLS version (TLS 1.3 only)
context.minimum_version = ssl.TLSVersion.TLSv1_3
context.maximum_version = ssl.TLSVersion.TLSv1_3

# Restrict cipher suites
context.set_ciphers("TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256")

Chapter 6: Custom Protocols

TCP is brilliant for most applications: web browsing, file transfer, database queries, API calls. But its guarantees come at a cost. For some use cases, TCP's reliability mechanisms actually hurt performance.

When TCP Hurts: Head-of-Line Blocking

TCP delivers data as an ordered byte stream. If segment 5 out of 10 is lost, segments 6-10 must wait in the receiver's buffer until segment 5 is retransmitted and arrives. The application sees nothing until the gap is filled. This is head-of-line blocking.

For a file transfer, this is fine — you need the bytes in order. But for real-time applications, it is devastating:

UDP: The Escape Hatch

UDP (User Datagram Protocol) is the anti-TCP. It provides almost nothing: no reliability, no ordering, no flow control, no congestion control. You send a datagram, and it either arrives or it doesn't. Each datagram is independent.

UDP is not "unreliable TCP." It is a blank canvas. Applications that use UDP implement exactly the guarantees they need and nothing more. A game might implement reliable delivery for chat messages but fire-and-forget for position updates. A video player might implement FEC (forward error correction) to recover from loss without retransmission.

python
import socket, struct, time

# UDP sender: fire-and-forget position updates
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

seq = 0
while True:
    x, y = get_player_position()
    # Pack: sequence number + position
    data = struct.pack("!Iff", seq, x, y)
    sock.sendto(data, ("game-server.example.com", 9000))
    seq += 1
    time.sleep(1/60)  # 60 Hz update rate

# UDP receiver: always use LATEST position, drop stale
def receive_positions(sock):
    latest_seq = -1
    while True:
        data, addr = sock.recvfrom(1024)
        seq, x, y = struct.unpack("!Iff", data)
        if seq > latest_seq:  # ignore out-of-order (stale)
            latest_seq = seq
            update_player(addr, x, y)
        # else: discard — we already have newer data

QUIC: The Best of Both Worlds

QUIC (originally "Quick UDP Internet Connections") is the protocol underneath HTTP/3. It runs on UDP but provides:

• Reliable, ordered delivery per stream. Multiple independent streams multiplexed on one connection. Loss in stream A does NOT block stream B.
• Built-in TLS 1.3. Encryption is mandatory and integrated — the handshake combines transport and TLS setup into a single round trip (0-RTT for repeat connections!).
• Connection migration. A QUIC connection is identified by a connection ID, not by (IP, port). If you switch from WiFi to cellular, the connection survives.
• Improved congestion control. Runs in userspace, so it can be updated without OS kernel changes.

When to Use What

Choosing between TCP, UDP, and QUIC is not about which is "better" — it is about matching your application's requirements to the protocol's guarantees. The decision framework is simple: ask yourself two questions. First: "Can my application tolerate data loss?" If no, you need reliability (TCP or QUIC). If yes, UDP. Second: "Am I multiplexing independent streams?" If yes, QUIC avoids head-of-line blocking. If no, TCP is simpler and universally supported.

The Big Comparison: TCP vs UDP vs QUIC

QUIC Under the Hood

QUIC is not just "TCP over UDP." It rethinks the transport layer from the ground up. Here are the critical implementation details:

The fact that each stream has its own offset is what eliminates head-of-line blocking. If stream 3's offset is missing, QUIC only blocks stream 3's data. Streams 1, 2, and 4 have their own offsets and can be delivered to the application immediately.

Connection Setup Latency

Another major difference: how many round trips before data can flow.

Chapter 7: Network in Practice

You understand the protocols. Now let's talk about operating them in production. Every day, engineers debug TCP problems that waste hours — and the symptoms are always the same: "it's slow" or "connections are failing." The fix depends on understanding which TCP mechanism is misbehaving.

Nagle's Algorithm and TCP_NODELAY

Nagle's algorithm (RFC 896) solves the "small packet problem." If your application writes 1 byte at a time (e.g., keystrokes in a telnet session), TCP would send a 41-byte packet (20 bytes IP header + 20 bytes TCP header + 1 byte data) for each byte of payload. This is wildly inefficient.

Nagle's algorithm says: if there is unacknowledged data in flight, buffer small writes and send them as one segment when the ACK arrives. This batches small writes into larger, efficient segments.

For interactive applications (SSH, gaming, RPC services), Nagle's algorithm adds intolerable latency. The fix: setsockopt(TCP_NODELAY, 1). This disables Nagle's algorithm, sending every write immediately regardless of size. Every modern web server, database driver, and RPC framework sets TCP_NODELAY.

python
import socket

# Disable Nagle's algorithm for low-latency RPC
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

# Verify it's set
nodelay = sock.getsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY)
print(f"TCP_NODELAY: {'enabled' if nodelay else 'disabled'}")

# Note: Python's http.client and requests library set this by default
# But raw socket connections do NOT — you must set it yourself

Delayed ACK Interaction

We mentioned Nagle's algorithm, but the real devil is its interaction with delayed ACKs. The TCP receiver doesn't ACK every segment immediately — it waits up to 200ms (the delayed ACK timer) hoping to piggyback the ACK on a response data segment. This is efficient when the application sends a response quickly. But when combined with Nagle's algorithm, disaster strikes:

This is not a theoretical problem. It causes real 200ms latency spikes in production systems every day. The solution is TCP_NODELAY on interactive/RPC connections. There is almost never a reason to leave Nagle's algorithm enabled on a service that makes request-response calls.

TCP Keep-Alive

TCP keep-alive detects dead connections. By default, TCP has no heartbeat — if one side crashes without sending FIN (power failure, OOM kill), the other side has no idea. It sits in ESTABLISHED state forever, holding resources.

Connection Pooling

Each TCP connection costs 1 RTT (handshake) + memory (buffers, state) + a TIME_WAIT socket when closed. If your application opens a new connection for every request (like naive HTTP/1.0), you pay this cost thousands of times per second.

Connection pooling keeps a set of established connections open and reuses them for multiple requests. This eliminates handshake latency and TIME_WAIT buildup.

python
import urllib3

# urllib3 connection pool: reuses TCP connections
pool = urllib3.HTTPSConnectionPool(
    "api.example.com",
    port=443,
    maxsize=10,         # keep up to 10 connections alive
    block=True,         # wait for a free connection if all 10 are busy
    retries=3,          # retry on connection failure
)

# First request: opens connection (1 RTT handshake + TLS)
resp1 = pool.request("GET", "/users/1")

# Second request: reuses existing connection (0 RTT overhead)
resp2 = pool.request("GET", "/users/2")

# Connection stays alive between requests (HTTP keep-alive)

Debug Scenarios

These are the three most common TCP problems in production. Learn to recognize the symptoms and you will save hours of debugging.

TCP Tuning Cheat Sheet

bash
# View current TCP settings
sysctl net.ipv4.tcp_wmem          # send buffer (min, default, max)
sysctl net.ipv4.tcp_rmem          # receive buffer (min, default, max)
sysctl net.ipv4.tcp_congestion_control  # cubic, bbr, etc.

# Enable BBR congestion control (better for high-latency links)
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

# Increase buffer sizes for high-BDP links
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"   # 16 MB max
sysctl -w net.ipv4.tcp_wmem="4096 87380 16777216"

# Allow TIME_WAIT socket reuse
sysctl -w net.ipv4.tcp_tw_reuse=1

# Aggressive keep-alive for production services
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=6

# Monitor TCP state distribution
ss -tan state time-wait | wc -l   # count TIME_WAIT sockets
ss -tan state close-wait | wc -l  # count CLOSE_WAIT (application bug!)
ss -tin dst X.X.X.X               # detailed TCP info for connections to X

Network Debug Dashboard

The simulation below models a production scenario. A client sends requests to a server. You can introduce different problems — Nagle delay, small receive window, TIME_WAIT buildup — and watch the metrics change in real time. This is what ss -tin output looks like, made visual.

Real-World Case Studies

These are not hypothetical — these are actual production incidents that TCP misconfigurations cause.

Chapter 8: Interview Arsenal

Networking is a favorite interview topic for backend, infrastructure, and distributed systems roles. Here is everything you need to answer confidently.

Quick Reference: TCP vs UDP vs QUIC

Whiteboard: Explain TCP Congestion Control

If an interviewer says "explain TCP congestion control on a whiteboard," here is the structure:

Common Interview Questions

Design Questions

Numbers Every Engineer Should Know

Coding Drills

python
# Drill 1: TCP echo server with connection pooling awareness
import socket, selectors

sel = selectors.DefaultSelector()

def accept(sock):
    conn, addr = sock.accept()
    conn.setblocking(False)
    conn.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)  # disable Nagle
    sel.register(conn, selectors.EVENT_READ, data=echo)

def echo(conn):
    data = conn.recv(4096)
    if data:
        conn.sendall(data)
    else:
        sel.unregister(conn)
        conn.close()  # important! prevents CLOSE_WAIT leak

srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("", 8000))
srv.listen(128)  # backlog size
srv.setblocking(False)
sel.register(srv, selectors.EVENT_READ, data=accept)

while True:
    for key, mask in sel.select():
        key.data(key.fileobj)

python
# Drill 2: Measure TCP handshake + TLS overhead
import socket, ssl, time

def measure_connect(host, port=443):
    # TCP handshake
    t0 = time.perf_counter()
    sock = socket.create_connection((host, port))
    tcp_ms = (time.perf_counter() - t0) * 1000

    # TLS handshake
    t1 = time.perf_counter()
    ctx = ssl.create_default_context()
    tls = ctx.wrap_socket(sock, server_hostname=host)
    tls_ms = (time.perf_counter() - t1) * 1000

    print(f"TCP handshake: {tcp_ms:.1f}ms")
    print(f"TLS handshake: {tls_ms:.1f}ms")
    print(f"Total:         {tcp_ms+tls_ms:.1f}ms")
    print(f"TLS version:   {tls.version()}")
    tls.close()

measure_connect("google.com")
# TCP handshake: 12.3ms
# TLS handshake: 28.7ms
# Total:         41.0ms
# TLS version:   TLSv1.3

Mental Models for Quick Recall

When under interview pressure, these mental models let you reason about networking questions without memorizing every detail:

5-Minute Whiteboard: TLS Handshake

Chapter 9: Connections

You now have a solid understanding of how computers communicate reliably, securely, and efficiently over networks. This knowledge is the foundation for everything in distributed systems.

What We Covered

How This Connects to Distributed Systems

Everything in this lesson is prerequisite knowledge for distributed systems topics:

Key Takeaways for Systems Design

The Evolution of Network Protocols

Understanding where these protocols came from helps you see where they are going.

The trend is clear: move complexity from the kernel to userspace (QUIC), reduce round trips (TLS 1.3, 0-RTT), and decouple streams (QUIC multiplexing). The next frontier is likely kernel bypass (DPDK, io_uring) for the lowest-latency applications, and post-quantum cryptography for TLS.

Further Reading

If you want to go deeper into any of these topics, these are the definitive sources:

Implementation Checklist

If you are building a production networked service, here is the minimum you must get right:

"The nice thing about standards is that you have so many to choose from." — Andrew S. Tanenbaum