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

Internet protocols are rules that let devices exchange data. They define how a message is addressed, sent and read. When a website fails to load, the fault may be in DNS, the network, TLS or the web server.

This guide explains the TCP/IP layers and the move from HTTP/1.1 to HTTP/3. It also gives you a short set of checks to find where a connection fails.

The four layers of TCP/IP

Each layer has a clear job. The table shows where common tools and protocols fit.

Application: web, email and name lookup

HTTP carries web requests. SMTP sends email, while IMAP and POP3 let mail clients read it. DNS looks up the IP address for a name. FTP transfers files.

Check DNS before changing a web server. A wrong address can send users to the wrong host.

dig vps.tc

A successful lookup does not prove that the website works. Test the web service next. Use ping for ICMP reachability, not as a test of HTTP.

Transport: TCP and UDP

TCP opens a connection and delivers an ordered stream of bytes. It detects loss and sends missing data again. It also controls how much data is in flight. Web traffic over HTTP/1.1 and HTTP/2 uses TCP.

UDP sends separate messages without a connection handshake. It has no built-in guarantee of delivery or order. Apps must handle loss when they need to. UDP has a checksum for error detection; it does not resend failed messages.

DNS, games and real-time media often use UDP. That does not make UDP faster in every case. Delay and throughput also depend on the app and the network.

# Show TCP sockets
ss -t

# Show UDP sockets
ss -u

Internet: addresses and routes

IP gives packets source and destination addresses. Routers use routing tables to choose the next hop. IPv4 uses 32-bit addresses. IPv6 uses 128-bit addresses and has a much larger address space.

ICMP carries network control messages. Tools such as ping use it to test reachability. Check the local route if a server cannot reach another network.

ip route show

Network access: the local link

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

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

HTTP/2: several streams on one connection

HTTP/2 lets a client send several requests at once on one connection. It also reduces repeated header data. These changes help pages that load many files.

TCP still delivers bytes in order. If a packet is lost, delivery can pause for all HTTP/2 streams on that connection while TCP recovers it.

# Check curl's supported 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 use another version. Read the output instead of assuming that a request flag proves HTTP/2 support.

HTTP/3: web requests over QUIC

HTTP/3 uses QUIC over UDP. QUIC adds reliable streams, loss recovery and flow control. A loss affecting one stream need not block delivery on another. Congestion can still slow the whole connection.

QUIC uses TLS 1.3. It also supports connection migration, which can help when a phone moves between networks. Repeat connections may use early data when the client and server support it. Early data has replay risks, so it needs careful use. See the QUIC transport specification for details.

Check your server before enabling HTTP/3

Your server build must support QUIC. The firewall and load balancer must also pass UDP traffic on the chosen port, usually 443. Keep TCP port 443 available for clients that use earlier HTTP versions.

This Nginx example shows the key listener settings. Replace the name and certificate paths. 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;

    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 requirements. Test with nginx -t and on a staging server before applying a change. A VPS or cloud server still needs the right software and network settings to serve HTTP/3.

A practical network troubleshooting checklist

1. Check the name: use dig to confirm the expected IP address.
2. Check the link and route: inspect the interface and ip route show.
3. Check the listening service: use ss -lntup to inspect ports.
4. Check HTTP and TLS: use curl -v and read the server logs.
5. Check packet loss: inspect counters or capture a short trace.

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

# Show protocol counters
netstat -s

Wireshark helps you inspect a trace. Tools such as iftop and nload show live bandwidth use. A capture of encrypted HTTPS traffic shows packet details, not the clear-text page content.

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. Change one setting at a time. Compare delay, errors and throughput with a baseline. Save the old settings so you can restore them.

The same approach applies to a VDS or a dedicated server. A newer protocol alone will not fix a slow database or an overloaded app.

Related guides

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