{"id":287,"date":"2025-12-16T02:05:52","date_gmt":"2025-12-16T02:05:52","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/demystifying-internet-protocols-from-tcp-ip-to-http-3\/"},"modified":"2026-09-25T09:22:38","modified_gmt":"2026-09-25T09:22:38","slug":"demystifying-internet-protocols-from-tcp-ip-to-http-3","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/demystifying-internet-protocols-from-tcp-ip-to-http-3\/","title":{"rendered":"Demystifying Internet Protocols: From TCP\/IP to HTTP\/3"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; Internet Protocols from TCP\/IP to HTTP\/3<\/p>\n<p>Internet traffic is easier to troubleshoot when you identify the layer that is failing. Start with DNS and the local route, verify the listening service, then test HTTP, TLS and-when enabled-QUIC over UDP.<\/p>\n<ul>\n<li><strong>TCP\/IP layers:<\/strong> \u2014 Application, transport, Internet and network access layers describe different parts of a connection.<\/li>\n<li><strong>TCP and UDP:<\/strong> \u2014 TCP provides an ordered reliable stream, while UDP provides datagrams and leaves recovery to the application.<\/li>\n<li><strong>HTTP versions:<\/strong> \u2014 HTTP\/2 multiplexes streams over TCP, while HTTP\/3 uses QUIC over UDP.<\/li>\n<li><strong>HTTP\/3 deployment:<\/strong> \u2014 Keep TCP 443 available, allow UDP 443 through every boundary and verify the negotiated protocol.<\/li>\n<li><strong>Troubleshooting:<\/strong> \u2014 Use `dig`, `ip route`, `ss`, `curl`, `mtr` and a short `tcpdump` capture in that order.<\/li>\n<li><strong>Performance:<\/strong> \u2014 Measure a baseline before changing congestion, timeout, cache or protocol settings.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">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.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 11 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#the-four-layers-of-tcp-ip\">The four layers of TCP\/IP<\/a><\/li>\n<li><a href=\"#how-http-1-1-http-2-and-http-3-differ\">How HTTP\/1.1, HTTP\/2 and HTTP\/3 differ<\/a><\/li>\n<li><a href=\"#check-your-server-before-enabling-http-3\">Check your server before enabling HTTP\/3<\/a><\/li>\n<li><a href=\"#a-practical-network-troubleshooting-checklist\">A practical network troubleshooting checklist<\/a><\/li>\n<li><a href=\"#related-guides\">Related guides<\/a><\/li>\n<li><a href=\"#http-and-network-troubleshooting-checklist\">HTTP and network troubleshooting checklist<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"the-four-layers-of-tcp-ip\">The four layers of TCP\/IP<\/h2>\n<p>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.<\/p>\n<table>\n<thead>\n<tr>\n<th>Layer<\/th>\n<th>Main job<\/th>\n<th>Examples<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Application<\/td>\n<td>Handle requests from applications<\/td>\n<td>HTTP, DNS, SMTP and FTP<\/td>\n<\/tr>\n<tr>\n<td>Transport<\/td>\n<td>Move data between processes<\/td>\n<td>TCP and UDP<\/td>\n<\/tr>\n<tr>\n<td>Internet<\/td>\n<td>Address and route packets<\/td>\n<td>IPv4, IPv6 and ICMP<\/td>\n<\/tr>\n<tr>\n<td>Network access<\/td>\n<td>Send frames across the local network<\/td>\n<td>Ethernet and Wi-Fi<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Application: web, email and name lookup<\/h3>\n<p>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.<\/p>\n<p>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.<\/p>\n<pre><code>dig +short A vps.tc\ndig +short AAAA vps.tc<\/code><\/pre>\n<p>The <code>+short<\/code> 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 <code>ping<\/code> checks ICMP reachability rather than HTTP.<\/p>\n<p><strong>What to do<\/strong> &#8211; Compare the returned records with the address configured on the server, then test the actual TCP and TLS service.<\/p>\n<h3>Transport: TCP and UDP<\/h3>\n<p><strong>TCP<\/strong> 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.<\/p>\n<p><strong>UDP<\/strong> sends independent datagrams without TCP&#8217;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.<\/p>\n<p>DNS, games, voice and video can use UDP, but &#8220;UDP is faster&#8221; 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.<\/p>\n<pre><code># Show TCP sockets\nss -t\n\nShow UDP sockets\nss -u<\/code><\/pre>\n<p><strong>What to do<\/strong> &#8211; Check which process owns a listening socket with <code>ss -lntup<\/code>, then confirm that the firewall permits the same protocol and port.<\/p>\n<h3>Internet: addresses and routes<\/h3>\n<p>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.<\/p>\n<p>ICMP carries network control and error messages. <code>ping<\/code> uses ICMP, while tools such as <code>traceroute<\/code> and <code>mtr<\/code> help show where a path changes or loses packets. A blocked ICMP echo request does not automatically mean that TCP port 443 is unavailable.<\/p>\n<pre><code>ip address show\nip route show\n\nUseful for a live view of path loss and latency\nmtr -rwbc 20 example.com<\/code><\/pre>\n<p>Look at the route before blaming the provider. The default route, source address selection and an IPv6 route can each produce a different result.<\/p>\n<h3>Network access: the local link<\/h3>\n<p>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.<\/p>\n<p>On a physical host, these commands are a useful first pass:<\/p>\n<pre><code>ip link show\nip -s link show dev eth0\nethtool eth0<\/code><\/pre>\n<p><strong>What to do<\/strong> &#8211; Confirm the interface is up and its error counters are stable before tuning TCP, changing DNS or restarting application services.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Use `dig +short A` and `dig +short AAAA` before editing web-server configuration. A correct DNS answer proves only that name resolution works, not that TCP, TLS or HTTP is healthy.<\/p>\n<\/div>\n<h2 id=\"how-http-1-1-http-2-and-http-3-differ\">How HTTP\/1.1, HTTP\/2 and HTTP\/3 differ<\/h2>\n<table>\n<thead>\n<tr>\n<th>Version<\/th>\n<th>Transport<\/th>\n<th>What changes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>HTTP\/1.1<\/td>\n<td>TCP<\/td>\n<td>Requests share persistent connections, but response handling is comparatively limited and can be affected by ordering<\/td>\n<\/tr>\n<tr>\n<td>HTTP\/2<\/td>\n<td>TCP<\/td>\n<td>Many streams share a connection; headers use HPACK compression<\/td>\n<\/tr>\n<tr>\n<td>HTTP\/3<\/td>\n<td>QUIC over UDP<\/td>\n<td>QUIC provides independent streams, loss recovery and TLS 1.3 as part of the connection setup<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>HTTP\/3 is not simply &#8220;HTTP over UDP&#8221;. QUIC supplies the transport features that applications normally expect from TCP, while avoiding TCP&#8217;s single ordered byte stream between HTTP streams.<\/p>\n<h3>HTTP\/2: several streams on one connection<\/h3>\n<p>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.<\/p>\n<p>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.<\/p>\n<pre><code># Check curl's supported protocols and features\ncurl --version\n\nRequest HTTP\/2 and print the version actually used\ncurl --http2 -sS -o \/dev\/null -w '%{http_version}\\n' https:\/\/www.vps.tc\/en\/vps<\/code><\/pre>\n<p>The server may negotiate another version, or your installed <code>curl<\/code> may lack HTTP\/2 support. Read the output rather than treating the request flag as proof.<\/p>\n<h3>HTTP\/3: web requests over QUIC<\/h3>\n<p>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.<\/p>\n<p>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 <a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc9000.html\" target=\"_blank\" rel=\"noopener\">QUIC transport specification<\/a> for the transport details.<\/p>\n<p><strong>What to do<\/strong> &#8211; Offer HTTP\/3 as an additional path, measure it with real clients and retain working TCP-based HTTP\/1.1 or HTTP\/2 fallback.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I once spent time examining an application because a UDP counter was climbing on a test VM. `ss` and the service logs showed that the traffic came from a monitoring probe pointed at the wrong address. Protocol counters need context.<\/p>\n<\/div>\n<h2 id=\"check-your-server-before-enabling-http-3\">Check your server before enabling HTTP\/3<\/h2>\n<p>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.<\/p>\n<p>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&#8217;s own locations before use.<\/p>\n<pre><code>server {\n    listen 443 quic reuseport;\n    listen 443 ssl;\n    server_name example.com;\n\n    ssl_certificate \/etc\/nginx\/ssl\/example.com.crt;\n    ssl_certificate_key \/etc\/nginx\/ssl\/example.com.key;\n    ssl_protocols TLSv1.2 TLSv1.3;\n\n    add_header Alt-Svc 'h3=\":443\"; ma=86400' always;\n\n    # Add your site's location blocks here.\n}<\/code><\/pre>\n<p>Check the <a href=\"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_v3_module.html\" target=\"_blank\" rel=\"noopener\">Nginx HTTP\/3 module documentation<\/a> for build and platform requirements. Test with <code>nginx -t<\/code>, then verify both TCP and UDP reachability from outside the server. A <a href=\"https:\/\/www.vps.tc\/en\/vps\">VPS<\/a> or <a href=\"https:\/\/www.vps.tc\/en\/cloud-server\">cloud server<\/a> still needs the right kernel, firewall, software build and network path.<\/p>\n<p>Do not assume that an <code>Alt-Svc<\/code> header means clients are already using HTTP\/3. It advertises an alternative; the client decides whether and when to try it.<\/p>\n<p><strong>What to do<\/strong> &#8211; Check the Nginx build, open UDP 443 at every network boundary, validate the configuration, and test with a client that reports the negotiated protocol.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>HTTP\/3 needs UDP reachability as well as TCP fallback. Check the host firewall, provider security group, load balancer and upstream proxy; opening UDP 443 on only the origin is not enough.<\/p>\n<\/div>\n<h2 id=\"a-practical-network-troubleshooting-checklist\">A practical network troubleshooting checklist<\/h2>\n<ol>\n<li><strong>Check the name:<\/strong> use <code>dig<\/code> to confirm the expected A and AAAA records.<\/li>\n<li><strong>Check the link and route:<\/strong> inspect the interface, counters and <code>ip route show<\/code>.<\/li>\n<li><strong>Check the listening service:<\/strong> use <code>ss -lntup<\/code> to inspect TCP and UDP ports.<\/li>\n<li><strong>Check HTTP and TLS:<\/strong> use <code>curl -v<\/code> or <code>curl -I<\/code> and read the server logs.<\/li>\n<li><strong>Check the path:<\/strong> use <code>mtr<\/code> or a short packet capture without exposing sensitive traffic.<\/li>\n<\/ol>\n<pre><code># Replace eth0 with your network interface\nsudo tcpdump -ni eth0 'tcp port 80 or tcp port 443 or udp port 443'\n\nShow socket and protocol statistics\nss -s\nnstat -az<\/code><\/pre>\n<p>Wireshark helps you inspect a trace. Tools such as <code>iftop<\/code> and <code>nload<\/code> 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.<\/p>\n<h3>Keep firewall changes small<\/h3>\n<ul>\n<li>Allow only the ports and protocols the service needs.<\/li>\n<li>Keep management access restricted.<\/li>\n<li>Separate public services from private systems.<\/li>\n<li>Keep console access available while testing firewall rules.<\/li>\n<\/ul>\n<h3>Measure before tuning<\/h3>\n<p>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.<\/p>\n<p>The same approach applies to a <a href=\"https:\/\/www.vps.tc\/en\/vds-server\">VDS<\/a> or a <a href=\"https:\/\/www.vps.tc\/en\/turkey-dedicated-server\">dedicated server<\/a>. A newer protocol will not repair a slow database, exhausted CPU or overloaded application.<\/p>\n<p><strong>What to do<\/strong> &#8211; Record the negotiated protocol and a small baseline before tuning, then compare the same request after each change.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>An `Alt-Svc` header advertises HTTP\/3; it does not force the client to use it. Confirm the negotiated version with a client request and test again from outside your network.<\/p>\n<\/div>\n<h2 id=\"related-guides\">Related guides<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.vps.tc\/blog\/en\/err-connection-reset-fix-chrome\/\">Fix ERR_CONNECTION_RESET in Chrome<\/a><\/li>\n<li><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-an-ip-address-and-how-does-it-work\/\">How IP addresses work<\/a><\/li>\n<li><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-a-proxy-server-and-how-does-it-work\/\">How proxy servers work<\/a><\/li>\n<li><a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-ftp-file-transfer-protocol-explained\/\">How FTP transfers files<\/a><\/li>\n<\/ul>\n<h2 id=\"http-and-network-troubleshooting-checklist\">HTTP and network troubleshooting checklist<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Run `dig +short A` and `dig +short AAAA` for the hostname.<\/li>\n<li>Inspect interface state, counters and the route with `ip link`, `ip -s link` and `ip route`.<\/li>\n<li>List listening TCP and UDP sockets with `ss -lntup`.<\/li>\n<li>Test the endpoint with `curl -v` and record the HTTP version and TLS result.<\/li>\n<li>Check TCP 443 and UDP 443 through every firewall and load-balancer boundary.<\/li>\n<li>Use `mtr` or a brief `tcpdump` capture to investigate path loss and retransmissions.<\/li>\n<li>Compare results with a saved baseline before changing performance settings.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>If you are debugging a connection, keep the command output from each layer in one note. That small habit makes the next incident much faster to compare and explain.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>What is the difference between TCP and UDP?<\/summary>\n<p>TCP gives an application an ordered byte stream and handles retransmission, flow control and congestion control. UDP sends independent datagrams with less transport machinery; it does not guarantee delivery or order. QUIC uses UDP as its packet substrate but adds reliability, streams, encryption and congestion control above it. The choice depends on the protocol and application, not on a blanket claim that one is always faster.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Does ping prove that a website is working?<\/summary>\n<p>No. `ping` normally tests ICMP echo, while a website needs DNS, a listening TCP or QUIC service, TLS and an HTTP response. A host can block ICMP and still serve HTTPS, or answer ping while port 443 is closed. Use `dig`, `ss`, `curl -v` and server logs to test the layers that a browser actually uses.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Why can HTTP\/2 still experience head-of-line blocking?<\/summary>\n<p>HTTP\/2 multiplexes streams, but those streams share one ordered TCP byte stream. When TCP loses a segment, later bytes cannot be delivered to the application until the missing data is recovered. HTTP\/3 avoids this transport-level coupling by using QUIC streams, so loss on one stream need not stop delivery on the others. Congestion can still affect the whole connection.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Do I need HTTP\/3 if HTTP\/2 already works?<\/summary>\n<p>Not necessarily. HTTP\/3 can help on some lossy or changing networks, but it adds UDP firewall, load-balancer and observability requirements. Keep HTTP\/2 available and measure real requests rather than enabling HTTP\/3 for a version number alone. Check latency, errors, connection reuse and application response time from the locations that matter to your users.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>How do I verify that a site is really using HTTP\/3?<\/summary>\n<p>Use a client that supports HTTP\/3 and ask it to report the negotiated protocol. For example, `curl &#8211;http3 -sS -o \/dev\/null -w &#039;%{http_version}\\n&#039; https:\/\/example.com` works only when that curl build includes HTTP\/3 support. Also inspect the response and server logs. An `Alt-Svc` header advertises HTTP\/3; it does not prove that the current request used it.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>What should I check before opening UDP 443?<\/summary>\n<p>Confirm that the web-server build supports QUIC, then check the host firewall, provider security group, load balancer, NAT and upstream proxy. Verify that UDP 443 reaches the intended listener from an external network and keep TCP 443 open for fallback. Review idle timeouts and MTU-related errors if connections fail intermittently. Change one boundary at a time so the result is clear.<\/p>\n<\/details>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Explore the fundamental internet protocols that power global communication, from the foundational TCP\/IP suite to the cutting-edge HTTP\/3, understanding their evolution and critical role in network architecture.<\/p>\n","protected":false},"author":1,"featured_media":286,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-287","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general"],"lang":"en","translations":{"en":287,"tr":281},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/287","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=287"}],"version-history":[{"count":9,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/287\/revisions"}],"predecessor-version":[{"id":930,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/287\/revisions\/930"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/286"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=287"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=287"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=287"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}