Demystifying Internet Protocols: From TCP/IP to HTTP/3

HTTP problems are rarely solved by restarting the server first. Check the name, route, listening socket and TLS negotiation in order; then determine whether the client is using HTTP/1.1, HTTP/2 or HTTP/3. That sequence tells you which layer is failing and prevents a harmless DNS problem from becoming a risky configuration change.

The four layers of TCP/IP

Each layer has a different job, but real failures often cross those boundaries. DNS can return the correct address while a firewall drops the connection, and a healthy web server can still be unreachable because the local route is wrong.

Application: web, email and name lookup

HTTP carries web requests. SMTP transfers mail between servers and submission clients, while IMAP and POP3 let mail clients access messages. DNS maps names to records such as IPv4, IPv6 and mail-server addresses. FTP transfers files, although encrypted alternatives such as SFTP are usually a better choice for new deployments.

Start with DNS before changing a web server. A stale, incorrect or split-horizon answer can send you to the wrong host even when the origin server is perfectly healthy.

dig +short A vps.tc
dig +short AAAA vps.tc

The +short output is deliberately compact, which makes it useful when comparing resolvers. A successful lookup does not prove that the website works. Test the service next, and remember that ping checks ICMP reachability rather than HTTP.

What to do – Compare the returned records with the address configured on the server, then test the actual TCP and TLS service.

Transport: TCP and UDP

TCP establishes a connection and presents applications with an ordered, reliable byte stream. It detects loss, retransmits missing data and adjusts the amount of data in flight through flow and congestion control. HTTP/1.1 and HTTP/2 normally use TCP.

UDP sends independent datagrams without TCP’s connection and retransmission machinery. It still includes a checksum for error detection, but it does not resend failed datagrams. Applications that need reliability, ordering or encryption must provide those features themselves, as QUIC does.

DNS, games, voice and video can use UDP, but “UDP is faster” is too broad to be useful. The application, path, congestion and packet size all matter. On one of my own test VMs, a rising UDP counter initially looked like a service failure; it turned out to be a monitoring probe aimed at the wrong address.

# Show TCP sockets
ss -t

Show UDP sockets
ss -u

What to do – Check which process owns a listening socket with ss -lntup, then confirm that the firewall permits the same protocol and port.

Internet: addresses and routes

IP gives packets source and destination addresses. Routers consult routing tables to choose the next hop. IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses and has a much larger address space, but it still needs correct addressing, routing and firewall policy.

ICMP carries network control and error messages. ping uses ICMP, while tools such as traceroute and mtr help show where a path changes or loses packets. A blocked ICMP echo request does not automatically mean that TCP port 443 is unavailable.

ip address show
ip route show

Useful for a live view of path loss and latency
mtr -rwbc 20 example.com

Look at the route before blaming the provider. The default route, source address selection and an IPv6 route can each produce a different result.

Network access: the local link

Ethernet and Wi-Fi move frames across a local link. At this layer, check the interface state, cable, switch port, wireless signal, VLAN and negotiated speed. A fault here can break every service above it.

On a physical host, these commands are a useful first pass:

ip link show
ip -s link show dev eth0
ethtool eth0

What to do – Confirm the interface is up and its error counters are stable before tuning TCP, changing DNS or restarting application services.

How HTTP/1.1, HTTP/2 and HTTP/3 differ

HTTP/3 is not simply “HTTP over UDP”. QUIC supplies the transport features that applications normally expect from TCP, while avoiding TCP’s single ordered byte stream between HTTP streams.

HTTP/2: several streams on one connection

HTTP/2 lets a client send several requests at once on one connection and compresses repeated header fields with HPACK. That can reduce connection overhead for pages with many resources.

TCP still delivers one ordered byte stream underneath those HTTP/2 streams. If a TCP segment is lost, the connection can wait for recovery before later bytes are delivered, so multiplexing does not remove transport-level head-of-line blocking.

# Check curl's supported protocols and features
curl --version

Request HTTP/2 and print the version actually used
curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://www.vps.tc/en/vps

The server may negotiate another version, or your installed curl may lack HTTP/2 support. Read the output rather than treating the request flag as proof.

HTTP/3: web requests over QUIC

HTTP/3 uses QUIC over UDP. QUIC provides reliable, ordered delivery within each stream, loss recovery, flow control and congestion control. Loss affecting one stream does not have to block delivery on another, although congestion and a poor network path can still slow the entire connection.

QUIC uses TLS 1.3 during its handshake and supports connection migration, which can help when a client moves between networks. Repeat connections may use 0-RTT early data when both sides support it. That data can be replayed, so use it only for operations designed to tolerate replay. See the QUIC transport specification for the transport details.

What to do – Offer HTTP/3 as an additional path, measure it with real clients and retain working TCP-based HTTP/1.1 or HTTP/2 fallback.

Check your server before enabling HTTP/3

Your web server build must include QUIC support. The host firewall, security group, load balancer and any upstream proxy must pass UDP traffic on the chosen port, normally 443. Keep TCP port 443 available for clients that use HTTP/1.1 or HTTP/2.

This Nginx example uses syntax supported by modern Nginx builds with the HTTP/3 module. Replace the name and certificate paths, and add your site’s own locations before use.

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # Add your site's location blocks here.
}

Check the Nginx HTTP/3 module documentation for build and platform requirements. Test with nginx -t, then verify both TCP and UDP reachability from outside the server. A VPS or cloud server still needs the right kernel, firewall, software build and network path.

Do not assume that an Alt-Svc header means clients are already using HTTP/3. It advertises an alternative; the client decides whether and when to try it.

What to do – Check the Nginx build, open UDP 443 at every network boundary, validate the configuration, and test with a client that reports the negotiated protocol.

A practical network troubleshooting checklist

1. Check the name: use dig to confirm the expected A and AAAA records.
2. Check the link and route: inspect the interface, counters and ip route show.
3. Check the listening service: use ss -lntup to inspect TCP and UDP ports.
4. Check HTTP and TLS: use curl -v or curl -I and read the server logs.
5. Check the path: use mtr or a short packet capture without exposing sensitive traffic.

# Replace eth0 with your network interface
sudo tcpdump -ni eth0 'tcp port 80 or tcp port 443 or udp port 443'

Show socket and protocol statistics
ss -s
nstat -az

Wireshark helps you inspect a trace. Tools such as iftop and nload show live bandwidth use. A capture of encrypted HTTPS traffic shows packet metadata and handshake details, not the clear-text page content. Be careful with captures on busy or multi-tenant systems; packet contents may contain credentials or personal data.

Keep firewall changes small

• Allow only the ports and protocols the service needs.
• Keep management access restricted.
• Separate public services from private systems.
• Keep console access available while testing firewall rules.

Measure before tuning

TCP buffers, congestion control, keepalives and DNS caching can affect performance. For HTTP/3, UDP state timeouts, MTU issues and load-balancer support matter too. Change one setting at a time, compare delay, errors and throughput with a baseline, and save the old settings so you can restore them.

The same approach applies to a VDS or a dedicated server. A newer protocol will not repair a slow database, exhausted CPU or overloaded application.

What to do – Record the negotiated protocol and a small baseline before tuning, then compare the same request after each change.

Related guides

• Fix ERR_CONNECTION_RESET in Chrome
• How IP addresses work
• How proxy servers work
• How FTP transfers files

HTTP and network troubleshooting checklist

• Run `dig +short A` and `dig +short AAAA` for the hostname.
• Inspect interface state, counters and the route with `ip link`, `ip -s link` and `ip route`.
• List listening TCP and UDP sockets with `ss -lntup`.
• Test the endpoint with `curl -v` and record the HTTP version and TLS result.
• Check TCP 443 and UDP 443 through every firewall and load-balancer boundary.
• Use `mtr` or a brief `tcpdump` capture to investigate path loss and retransmissions.
• Compare results with a saved baseline before changing performance settings.

Frequently Asked Questions