--- title: "The TCP/IP Model Explained: Four Layers of the Internet" description: Explore the TCP/IP model and its four layers, including key protocols that power internet communication. image: https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-03-2026-02-40-37-0977-AM.jpeg --- [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [📘 Learn ▾](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [CDN Fundamentals](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us) [By Content Type](https://blog.blazingcdn.com/by-content-type?hsLang=en-us) [Advanced Concepts](https://blog.blazingcdn.com/advanced-concepts?hsLang=en-us) [📖 Glossary](https://blog.blazingcdn.com/glossary?hsLang=en-us) [🎬 Video & Streaming ▾](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [🔴 Live Streaming](https://blog.blazingcdn.com/live-streaming?hsLang=en-us) [📺 VOD & OTT](https://blog.blazingcdn.com/vod-ott?hsLang=en-us) [🎞️ Encoding & Players](https://blog.blazingcdn.com/encoding-players?hsLang=en-us) [🎧 Audio & Podcasts](https://blog.blazingcdn.com/audio-podcasts?hsLang=en-us) [💰 Bandwidth & Costs](https://blog.blazingcdn.com/bandwidth-costs?hsLang=en-us) [🏗️ Infrastructure ▾](https://blog.blazingcdn.com/cdn-infrastructure?hsLang=en-us) [🗄️ Storage & Origin](https://blog.blazingcdn.com/storage-origin?hsLang=en-us) [📦 Large File Delivery](https://blog.blazingcdn.com/large-file-delivery?hsLang=en-us) [💸 Cloud Costs & Egress](https://blog.blazingcdn.com/cloud-costs-egress?hsLang=en-us) [🌐 Networking & ISP](https://blog.blazingcdn.com/networking-isp?hsLang=en-us) [⚙️ DevOps & Cloud Infra](https://blog.blazingcdn.com/devops-cloud-infra?hsLang=en-us) [⚡ Web Performance](https://blog.blazingcdn.com/web-performance?hsLang=en-us) [🏭 Industries ▾](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [📺 Media & Broadcasting](https://blog.blazingcdn.com/media-broadcasting?hsLang=en-us) [💾 Software & SaaS](https://blog.blazingcdn.com/software-saas?hsLang=en-us) [📣 AdTech & Advertising](https://blog.blazingcdn.com/adtech-advertising?hsLang=en-us) [🎮 Gaming & Esports](https://blog.blazingcdn.com/gaming-esports?hsLang=en-us) [📱 Mobile Apps & Developers](https://blog.blazingcdn.com/mobile-apps-developers?hsLang=en-us) [🤖 AI & Machine Learning](https://blog.blazingcdn.com/ai-machine-learning?hsLang=en-us) [🏛️ Enterprise & Corporate](https://blog.blazingcdn.com/enterprise-corporate?hsLang=en-us) [📚 E-Learning & EdTech](https://blog.blazingcdn.com/e-learning-edtech?hsLang=en-us) [🏟️ Sports & Live Events](https://blog.blazingcdn.com/sports-live-events?hsLang=en-us) [💰 Pricing & Compare ▾](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [Provider Pricing](https://blog.blazingcdn.com/provider-pricing?hsLang=en-us) [Cost Optimization](https://blog.blazingcdn.com/cost-optimization?hsLang=en-us) [Decision Support](https://blog.blazingcdn.com/decision-support?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [Provider Comparisons](https://blog.blazingcdn.com/provider-comparisons?hsLang=en-us) [Strategy Comparisons](https://blog.blazingcdn.com/strategy-comparisons?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [🔒 Security ▾](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [Attack Protection](https://blog.blazingcdn.com/attack-protection?hsLang=en-us) [Encryption & Access](https://blog.blazingcdn.com/encryption-access?hsLang=en-us) [Video & DRM Security](https://blog.blazingcdn.com/video-drm-security?hsLang=en-us) [🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [Get Started](https://blazingcdn.com/sign-up-contact-form/) [Infrastructure](https://blog.blazingcdn.com/en-us/tag/infrastructure) [Infrastructure - Networking & ISP](https://blog.blazingcdn.com/en-us/tag/infrastructure-networking-isp) # The TCP/IP Model Explained: Four Layers of the Internet Vadym Borovskyi Nov 3, 2026, 3:43:10 AM ![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-03-2026-02-40-37-0977-AM.jpeg) The TCP/IP model splits internet communication into four layers: link, internet, transport and application, as defined in RFC 1122. It folds the seven OSI layers into four. IP handles addressing and routing, TCP or UDP handles delivery semantics, and TLS and HTTP both sit in one application layer. For content delivery, the useful way to read the model is as a cost ledger. Every layer adds bytes to each packet and round trips to each new connection, and those two costs are what an edge network actually optimizes. As of 2026, a fresh HTTPS request over TCP with TLS 1.3 needs three round trips before the first response byte arrives: one for the TCP handshake, one for the TLS handshake and one for the request itself. HTTP/3 over QUIC merges the transport and cryptographic handshakes, which brings a new connection down to two round trips, and to one with 0-RTT resumption. ## **How the four TCP/IP model layers map to the OSI model** The TCP/IP model maps onto OSI as follows: the link layer covers OSI layers 1 and 2, the internet layer matches layer 3, the transport layer matches layer 4, and the application layer absorbs layers 5, 6 and 7. TCP/IP came from working protocols rather than a reference design, so its layer boundaries follow real implementations. | TCP/IP layer | OSI equivalent | Protocols in a content request | Unit and key header cost | | --- | --- | --- | --- | | Application | 5 Session, 6 Presentation, 7 Application | HTTP/1.1, HTTP/2 (RFC 9113), HTTP/3 (RFC 9114), TLS 1.3 (RFC 8446), DNS | Messages and records; TLS 1.3 adds about 22 bytes per record with AES-GCM | | Transport | 4 Transport | TCP (RFC 9293), UDP (RFC 768), QUIC (RFC 9000) running over UDP | Segments or datagrams; TCP 20 bytes plus 12 for timestamps, UDP 8 bytes | | Internet | 3 Network | IPv4 (RFC 791), IPv6 (RFC 8200), ICMP, BGP-driven routing including Anycast | Packets; IPv4 20 bytes, IPv6 40 bytes | | Link | 1 Physical, 2 Data link | Ethernet, Wi-Fi, DOCSIS, 5G radio bearers | Frames; Ethernet costs 38 bytes on the wire per frame including preamble and inter-frame gap | Most of the real engineering decisions in content delivery happen in the two middle layers, even though product names and marketing cluster at the application layer. ## **Where IP, TCP, UDP, TLS and HTTP sit in the TCP/IP protocol suite** In the TCP/IP protocol suite, IP sits at the internet layer, TCP and UDP sit at the transport layer, and both TLS and HTTP sit at the application layer. TLS occupies an awkward spot: it runs on top of TCP but beneath HTTP. QUIC complicates the picture further by moving transport logic and TLS 1.3 into one user-space protocol carried over UDP. ### Internet layer: where Anycast lives IP has no connection state. It routes each packet independently, and that is what makes Anycast possible: many edge servers announce the same prefix over BGP, and every client lands on whichever one is topologically closest. The trade-off is that TCP and QUIC hold state the internet layer cannot see. If a BGP path changes in the middle of a connection, packets may reach a different server that has never heard of the flow. In practice this is rare on stable networks, but it is the reason Anycast operators care about route stability at least as much as raw proximity. ### Transport layer: where delivery semantics are decided TCP provides an ordered, reliable byte stream with congestion control running in the kernel. UDP provides nothing beyond ports and a checksum, which is exactly why QUIC chose it. QUIC rebuilds reliability, congestion control and stream multiplexing in user space, so it can ship and evolve without waiting for operating system kernels or middleboxes to change. Congestion control (CUBIC or BBR) belongs to this layer, and on long-haul paths with any loss it moves throughput more than any application-layer tweak. ### Application layer: TLS and HTTP stacked together The four-layer model treats TLS as just another application protocol. Operationally it acts like a session layer: it adds a handshake round trip, frames data into records of up to 16 KB, and carries the SNI and ALPN fields an edge uses to choose a certificate and negotiate HTTP/2. HTTP/2 multiplexes many streams over one TCP connection, which works well until a packet is lost. At that point every stream waits for the retransmission. That head-of-line blocking is a transport-layer problem that surfaces as application-layer latency. ## **The byte ledger: header overhead per layer on a 100 MB download** Here is the overhead stack for one full-size Ethernet frame on a 1,500-byte MTU, with TCP timestamps enabled: - **Link layer:** 38 bytes on the wire per frame. - **Internet layer:** 20 bytes for IPv4, or 40 bytes for IPv6. - **Transport layer:** 32 bytes for TCP. - **Resulting payload:** 1,448 bytes of TLS data per segment on IPv4, or 1,428 bytes on IPv6. TLS 1.3 then spends 22 bytes on each 16 KB record. Applying all of that to a 100,000,000-byte file gives the result below. All figures are arithmetic. | Path | TLS records | TCP segments | Bytes on the wire | Goodput efficiency | | --- | --- | --- | --- | --- | | IPv4 + TCP + TLS 1.3 | 6,104 (134,288 bytes of overhead) | 69,154 | 106,358,852 | 94.0% | | IPv6 + TCP + TLS 1.3 | 6,104 (134,288 bytes of overhead) | 70,123 | 107,849,174 | 92.7% | Layering costs about 6 to 7% of wire capacity on bulk transfers, so a 1 Gb/s port tops out near 940 Mb/s of file data before any loss or protocol inefficiency. Two consequences matter in practice. First, TLS encryption is nearly free in bytes, at 0.13% of the transfer; the expensive layers are the link and the IP/TCP headers. Second, the 1.3-point gap between IPv4 and IPv6 is real but small. It is not a reason to delay IPv6. QUIC lands in a similar range (our estimate: roughly 25 to 40 bytes of UDP, QUIC header and AEAD tag per packet on top of IP). Many QUIC stacks also cap packets near 1,200 to 1,450 bytes to avoid fragmentation, which costs a little extra efficiency on bulk downloads. ## **The round-trip ledger: why handshakes beat bandwidth for small objects** For objects under a few hundred kilobytes, delivery time is bounded by round trips, not link speed. Each layer that needs a handshake adds one round trip before useful data moves, and TCP slow start adds more after that. A 100 KB response at 100 Mb/s serializes in 8 ms. At 80 ms RTT, the handshakes alone cost 240 ms. | Connection setup | RTTs to first byte | At 10 ms RTT (nearby edge) | At 80 ms RTT (distant origin) | | --- | --- | --- | --- | | TCP + TLS 1.2, full handshake | 4 | 40 ms | 320 ms | | TCP + TLS 1.3 | 3 | 30 ms | 240 ms | | TCP + TLS 1.3 with 0-RTT early data | 2 | 20 ms | 160 ms | | QUIC (HTTP/3), new connection | 2 | 20 ms | 160 ms | | QUIC with 0-RTT resumption | 1 | 10 ms | 80 ms | | Reused HTTP/2 connection, any of the above | 1 | 10 ms | 80 ms | Shortening the RTT and reusing connections each beat a protocol upgrade: TCP with TLS 1.3 to an edge 10 ms away reaches first byte in 30 ms, while the best-case QUIC handshake to an origin 80 ms away needs 80 ms. Slow start then adds its own cost. With the standard initial congestion window of 10 segments (RFC 6928) and a 1,448-byte MSS, a 100 KB response needs 69 segments. That takes three flights of 10, 20 and 40 segments, which is two more round trips after the first byte. At 80 ms RTT, a cold 100 KB fetch over TCP with TLS 1.3 therefore takes about 400 ms; at 10 ms RTT, about 50 ms. Both figures ignore server processing time and loss. This arithmetic is the core argument for terminating TCP and TLS at the edge: every layer's handshake gets cheaper in direct proportion to the RTT. 0-RTT has a security trade-off. Early data can be replayed, so it should only carry idempotent requests such as GETs for cacheable objects. ## **Where the layering leaks: trade-offs and failure modes** The four-layer model assumes each layer stays out of the others' business. On the real internet, that assumption breaks in predictable places. - **Path MTU black holes.** Path MTU discovery depends on ICMP "packet too big" messages traveling back from the internet layer. Firewalls that drop ICMP cause large segments to vanish silently. Small requests succeed while large downloads stall after the handshake. MSS clamping on tunnel and VPN edges is the usual fix. - **Protocol ossification.** Middleboxes inspect and rewrite TCP headers they have no business touching. That made new TCP options nearly impossible to deploy, and it is the main reason QUIC encrypts almost everything above UDP. - **Head-of-line blocking.** HTTP/2 removes blocking at the application layer but inherits it from TCP. At 1 to 2% packet loss, a single TCP connection carrying dozens of streams stalls all of them on every retransmission. - **Split TCP blind spots.** A CDN runs one TCP connection to the client and a separate one to the origin. Origin logs therefore show the edge's network behavior, not the user's, so client-side loss never appears in origin metrics. - **Observability gaps.** HTTP access logs record application-layer timing only. Retransmits, RTT variance and congestion window collapse live in kernel TCP state, and most stacks never export that data to logs. ## **Verify this on your own stack** Four checks map each layer to a measurable signal: - **Transport:** read the kernel's per-connection TCP info (the ss utility with the t and i options) and compare rtt, mss and retrans across client regions. - **Application:** check the negotiated ALPN protocol and TLS version on sampled connections, and compute requests per connection from your logs. A value near 1 means you are paying the full handshake cost on every request. - **Internet:** confirm that the advertised MSS is 1,460 on IPv4 and 1,440 on IPv6, both without timestamps. Lower values point to tunnels or clamping somewhere on the path. - **Application timing:** emit a Server-Timing header so browser devtools can separate edge processing time from network time. ## **When layer-by-layer reasoning helps, and when it misleads** The TCP/IP model earns its keep in incident triage and capacity math. Asking "which layer owns this symptom" quickly separates a BGP path change from a congestion control problem or a slow cache lookup. It is also the right frame for the byte and round-trip arithmetic above. It misleads when it is treated as a strict architecture. QUIC spans transport and security, Anycast ties a routing decision to connection state, and TLS ALPN decides which application protocol runs at all. Engineers who design edge systems need the cross-layer interactions, not the boxes. The model is a debugging map, not a blueprint. For more foundational material, see the [**CDN fundamentals articles on protocol and network layers**](https://blog.blazingcdn.com/cdn-fundamentals?hsLang=en-us). ## **FAQ: TCP/IP model layers and the TCP/IP protocol suite** ### What are the four layers of the TCP/IP model? The four layers of the TCP/IP model are link, internet, transport and application, as defined in RFC 1122. Ethernet and Wi-Fi operate at the link layer, IPv4 and IPv6 at the internet layer, and TCP, UDP and QUIC at the transport layer. HTTP, TLS and DNS all sit at the application layer, even though TLS behaves more like a session layer in practice. ### Is TLS a transport layer or application layer protocol in the TCP/IP model? In the TCP/IP model, TLS belongs to the application layer because it runs on top of TCP. Operationally it acts as a layer between TCP and HTTP: it adds one handshake round trip in TLS 1.3, frames data into records of up to 16 KB, and uses ALPN to negotiate HTTP/2. In QUIC, TLS 1.3 is built directly into the transport protocol. ### How does the TCP/IP model differ from the OSI model? The TCP/IP model uses four layers, while the OSI model uses seven. TCP/IP merges OSI's physical and data link layers into its link layer, and merges session, presentation and application into one application layer. TCP/IP was derived from protocols already running on real networks. OSI was designed as a reference framework, which is why its session and presentation layers rarely map cleanly onto deployed protocols. ### Where do HTTP/3 and QUIC fit in the TCP/IP model layers? HTTP/3 sits at the application layer and runs over QUIC. QUIC operates at the transport layer but is carried inside UDP datagrams. QUIC also absorbs the TLS 1.3 handshake, so transport and security setup complete in one round trip instead of two. That cuts a new HTTPS connection from three round trips to first byte down to two, or one with 0-RTT. ## **Measure your handshake cost this week** Pull a day of access logs and compute requests per TCP connection and the p95 client RTT for each region. Multiply your new connections by three RTTs (TCP plus TLS 1.3 plus the request) to get the total handshake time your users pay. Then compare that figure against the time spent actually transferring bytes. If handshakes dominate for objects under 200 KB, connection reuse and shorter RTTs will help more than any application-layer change. For heavy static workloads, BlazingCDN serves over HTTP/2, IPv6 and TLS 1.3 on Anycast routing with NVMe SSD servers. On a 100 MB HTTPS download measured June 2026, it recorded 24 ms and 1.11 Gb/s in North America. HTTP/3 is not offered by design. The [**BlazingCDN Anycast CDN overview**](https://blazingcdn.com/anycast-cdn/) describes how that stack is built. Share: [f](https://www.facebook.com/sharer/sharer.php?u=https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet) [in](https://www.linkedin.com/sharing/share-offsite/?url=https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet) [𝕏](https://twitter.com/intent/tweet?url=https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet&text=) [✉](mailto:?subject=%3Cspan%20id="hs_cos_wrapper_name"%20class="hs_cos_wrapper%20hs_cos_wrapper_meta_field%20hs_cos_wrapper_type_text"%20style=""%20data-hs-cos-general-type="meta_field"%20data-hs-cos-type="text"%20%3EThe%20TCP/IP%20Model%20Explained:%20Four%20Layers%20of%20the%20Internet%3C/span%3E&body=https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet) ![BlazingCDN](https://blog.blazingcdn.com/hs-fs/hubfs/Logo/blog-logo-w.png?height=24&name=blog-logo-w.png) *Heavy traffic.* Light bill. The CDN for video and large traffic Their monthly bill vs ours - 20 TBFastly $2,087**$92.50** - 50 TBCDN77 $990**$215** - 200 TBCloudFront $11,965**$765** Published list prices, Aug 2026 [Calculate your cost](https://blazingcdn.com/cdn-cost-calculator/?utm_source=blog&utm_medium=sidebar&utm_campaign=blog_sidebar&utm_content=compare_calc) ## Related posts [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-04-2026-07-50-38-8948-AM.jpeg)](https://blog.blazingcdn.com/en-us/what-is-ipv6-ipv6-vs-ipv4-and-why-it-matters?hsLang=en-us) Infrastructure ### [What Is IPv6? IPv6 vs IPv4 and Why It Matters](https://blog.blazingcdn.com/en-us/what-is-ipv6-ipv6-vs-ipv4-and-why-it-matters?hsLang=en-us) The short answer to what is IPv6: Internet Protocol version 6 is the network-layer protocol that replaces IPv4's 32-bit ... Nov 4, 2026, 8:52:25 AM [Read more](https://blog.blazingcdn.com/en-us/what-is-ipv6-ipv6-vs-ipv4-and-why-it-matters?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-04-2026-05-45-38-9119-AM.jpeg)](https://blog.blazingcdn.com/en-us/what-is-a-network-port-ports-80-and-443-explained?hsLang=en-us) Infrastructure ### [What Is a Network Port? Ports 80 and 443 Explained](https://blog.blazingcdn.com/en-us/what-is-a-network-port-ports-80-and-443-explained?hsLang=en-us) The short answer to what is a port: a network port is a 16-bit number, from 0 to 65535, carried in every TCP and UDP ... Nov 4, 2026, 6:47:39 AM [Read more](https://blog.blazingcdn.com/en-us/what-is-a-network-port-ports-80-and-443-explained?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-04-2026-03-40-38-3827-AM.jpeg)](https://blog.blazingcdn.com/en-us/dns-propagation-why-dns-changes-take-time?hsLang=en-us) Infrastructure ### [DNS Propagation: Why DNS Changes Take Time](https://blog.blazingcdn.com/en-us/dns-propagation-why-dns-changes-take-time?hsLang=en-us) DNS propagation is the window after a record change during which recursive resolvers, operating system caches and ... Nov 4, 2026, 4:42:52 AM [Read more](https://blog.blazingcdn.com/en-us/dns-propagation-why-dns-changes-take-time?hsLang=en-us) [![](https://blog.blazingcdn.com/hubfs/Gemini-Blog/image-Nov-04-2026-01-35-38-5774-AM.jpeg)](https://blog.blazingcdn.com/en-us/dns-records-explained-a-aaaa-cname-txt-and-more?hsLang=en-us) Infrastructure ### [DNS Records Explained: A, AAAA, CNAME, TXT and More](https://blog.blazingcdn.com/en-us/dns-records-explained-a-aaaa-cname-txt-and-more?hsLang=en-us) DNS records are typed entries in an authoritative zone that map a name to data. An A record returns a 32-bit IPv4 ... Nov 4, 2026, 2:37:32 AM [Read more](https://blog.blazingcdn.com/en-us/dns-records-explained-a-aaaa-cname-txt-and-more?hsLang=en-us) [![BlazingCDN](https://blog.blazingcdn.com/hubfs/Logo/blog-logo-w.png)](https://blog.blazingcdn.com?hsLang=en-us) [📘 Learn](https://blog.blazingcdn.com/cdn-learn?hsLang=en-us) [📊 Benchmarks](https://blog.blazingcdn.com/cdn-ratings-and-benchmarks?hsLang=en-us) [🎬 Video & Streaming](https://blog.blazingcdn.com/video-streaming-cdn?hsLang=en-us) [🏭 Industries](https://blog.blazingcdn.com/cdn-industry-insights?hsLang=en-us) [💰 Pricing & Costs](https://blog.blazingcdn.com/cdn-pricing-and-cdn-costs?hsLang=en-us) [⚡ Compare](https://blog.blazingcdn.com/cdn-comparison?hsLang=en-us) [🔒 Security](https://blog.blazingcdn.com/cdn-security?hsLang=en-us) [🛠️ Tools](https://blog.blazingcdn.com/cdn-tools?hsLang=en-us) [✍️ Publish with us](https://blog.blazingcdn.com/publish-with-us?hsLang=en-us) in f 𝕏 ✉ Copyright © BlazingCDN |. All rights reserved. ```json { "@context" : "https://schema.org", "@id" : "https://blazingcdn.com/#organization", "@type" : "Organization", "description" : "High-volume CDN for video, live streaming, OTT/IPTV, software, games, SaaS and large-file delivery.", "logo" : { "@id" : "https://blazingcdn.com/#logo", "@type" : "ImageObject", "height" : 560, "url" : "https://blazingcdn.com/wp-content/uploads/2024/08/logo-560-560.png", "width" : 560 }, "name" : "BlazingCDN", "sameAs" : [ "https://www.linkedin.com/company/blazingcdn", "https://x.com/BlazingCdn", "https://www.reddit.com/r/BlazingCDN/", "https://www.wikidata.org/wiki/Q141711074" ], "url" : "https://blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/#website", "@type" : "WebSite", "inLanguage" : "en-US", "name" : "BlazingCDN Blog", "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "url" : "https://blog.blazingcdn.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet#article", "@type" : "BlogPosting", "author" : { "@id" : "https://blog.blazingcdn.com/en-us/author/blazingcdn#person", "@type" : "Person", "description" : "Vadym Borovskyi is Chief Product and Marketing Officer at BlazingCDN, where he has led product strategy and growth since 2021. He has more than 11 years of experience in IT product management and B2B marketing. On this blog he writes about CDN pricing and egress costs, video and software delivery, cache configuration, and how teams evaluate and switch CDN providers. He is based in Warsaw, Poland.", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/vadym-borovskyi.jpg", "jobTitle" : "Chief Product and Marketing Officer", "knowsAbout" : [ "Content Delivery Networks (CDN)", "CDN pricing", "Video streaming delivery", "Software and game distribution", "Cache optimization", "Product Management", "B2B Marketing", "Digital Marketing", "Pay Per Click Marketing (PPC)", "Google Ads", "Search Engine Marketing (SEM)", "Marketing Strategy", "Artificial Intelligence (AI)", "Cloud Management", "SaaS Development", "IT Consulting", "Computer Networking", "Project Management", "Startups" ], "name" : "Vadym Borovskyi", "sameAs" : [ "https://www.linkedin.com/in/axelt/" ], "url" : "https://blog.blazingcdn.com/en-us/author/blazingcdn", "worksFor" : { "@id" : "https://blazingcdn.com/#organization" } }, "dateModified" : "2026-11-09T14:45:14Z", "datePublished" : "2026-11-03T02:43:10Z", "description" : "Explore the TCP/IP model and its four layers, including key protocols that power internet communication.", "headline" : "The TCP/IP Model Explained: Four Layers of the Internet", "image" : "https://143144902.fs1.hubspotusercontent-eu1.net/hubfs/143144902/Gemini-Blog/image-Nov-03-2026-02-40-37-0977-AM.jpeg", "inLanguage" : "en-us", "isPartOf" : { "@id" : "https://blog.blazingcdn.com/#website" }, "mainEntityOfPage" : { "@id" : "https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet", "@type" : "WebPage" }, "publisher" : { "@id" : "https://blazingcdn.com/#organization" }, "wordCount" : 2335 } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet#breadcrumb", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us", "name" : "Blog", "position" : 1 }, { "@type" : "ListItem", "item" : "https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet", "name" : "The TCP/IP Model Explained: Four Layers of the Internet", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@id" : "https://blog.blazingcdn.com/en-us/the-tcp-ip-model-explained-four-layers-of-the-internet#faq", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "The four layers of the TCP/IP model are link, internet, transport and application, as defined in RFC 1122. Ethernet and Wi-Fi operate at the link layer, IPv4 and IPv6 at the internet layer, and TCP, UDP and QUIC at the transport layer. HTTP, TLS and DNS all sit at the application layer, even though TLS behaves more like a session layer in practice." }, "name" : "What are the four layers of the TCP/IP model?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "In the TCP/IP model, TLS belongs to the application layer because it runs on top of TCP. Operationally it acts as a layer between TCP and HTTP: it adds one handshake round trip in TLS 1.3, frames data into records of up to 16 KB, and uses ALPN to negotiate HTTP/2. In QUIC, TLS 1.3 is built directly into the transport protocol." }, "name" : "Is TLS a transport layer or application layer protocol in the TCP/IP model?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "The TCP/IP model uses four layers, while the OSI model uses seven. TCP/IP merges OSI's physical and data link layers into its link layer, and merges session, presentation and application into one application layer. TCP/IP was derived from protocols already running on real networks. OSI was designed as a reference framework, which is why its session and presentation layers rarely map cleanly onto deployed protocols." }, "name" : "How does the TCP/IP model differ from the OSI model?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "HTTP/3 sits at the application layer and runs over QUIC. QUIC operates at the transport layer but is carried inside UDP datagrams. QUIC also absorbs the TLS 1.3 handshake, so transport and security setup complete in one round trip instead of two. That cuts a new HTTPS connection from three round trips to first byte down to two, or one with 0-RTT." }, "name" : "Where do HTTP/3 and QUIC fit in the TCP/IP model layers?" } ] } ```