Networking Protocols
Go hides the network behind convenient calls: you write http.Get, net.Dial, stand up a server in two lines — and see no handshakes, no segments, no lost packets. But in production that abstraction leaks. A connection hangs, HTTP/2 stalls because of one lost TCP packet, and a mobile client breaks a download when moving from Wi-Fi to cellular. The explanation for each case is in the networking protocols themselves — and that is exactly where a backend engineer is tested in an interview.
The topics cluster around one trade-off — reliability vs latency. At the bottom are two transports: TCP gives reliable ordered delivery at the cost of latency, UDP guarantees nothing but never waits. Atop TCP lives the text-based HTTP with its versions — from keep-alive to multiplexing in HTTP/2. And QUIC with HTTP/3 moved on top of UDP to sidestep TCP's rigidity and its head-of-line blocking. This topic dissects the networking layer beneath the Go runtime piece by piece.
Topic Map
- TCP vs UDP — reliable ordered delivery vs fast delivery with no guarantees, and when UDP is justified.
- How HTTP works — the text-based request/response: start line, headers, body, status codes, the stateless nature, and the versions.
- QUIC and HTTP/3 — a transport over UDP with built-in TLS 1.3, independent streams, and connection migration.
Common Mistakes and Traps
| Mistake | Consequence |
|---|---|
Saying "TCP is more reliable, so it is always better" | UDP has its own niche: real-time, gaming, DNS, QUIC — there latency beats per-packet guarantees |
Thinking UDP "guarantees delivery, just faster" | UDP guarantees nothing: a datagram may be lost, duplicated, or arrive out of order |
Assuming QUIC is built on TCP | QUIC runs on top of UDP and implements reliability and ordering itself, per-stream |
| Thinking HTTP "remembers" a user between requests | HTTP is stateless; session state is carried by cookies/tokens in every request |
| Confusing the status code classes | 4xx is a client error, 5xx a server error — not the other way around |
Thinking HTTP/2 killed head-of-line blocking entirely | It removed HOL at the HTTP level, but TCP HOL blocking remains — solved only by QUIC/HTTP/3 |
Calling QUIC "a new version of HTTP" | QUIC is a transport protocol over UDP; HTTP/3 is merely the HTTP semantics on top of it |
Interview Relevance
Networking protocols are a mandatory section of a Go backend interview. They test not command knowledge but a model: where the reliability-vs-latency boundary lies, how HTTP is built under http.Get, and why the industry moved to QUIC.
What interviewers usually check:
- How
TCPdiffers fromUDPby mechanism — handshake,ACK, retransmit, ordering vs datagrams with no guarantees. - When
UDPis justified — real-time, gaming,DNS,QUIC— and that you build reliability yourself on top of it. - What an HTTP request and response are made of — start line, headers, blank line, body, code classes.
- Why HTTP is stateless and where cookies and tokens come in.
- What head-of-line blocking is and why
HTTP/2overTCPis not free of it. - Why
QUICexists — independent streams, built-inTLS 1.3, connection migration by connection ID.
A typical wrong answer: "QUIC is just a new version of HTTP, and it is built on TCP." That triggers a discussion of how QUIC is a transport protocol over UDP that implements reliability and ordering itself per-stream, while HTTP/3 is merely the HTTP semantics that ride on it.