Giao diện
OSI Model — Bản đồ tư duy cho kiến trúc sư hệ thống
🎯 Mục tiêu
🎯 Sau bài này bạn sẽ nắm được:
- Hiểu OSI như bản đồ định vị, không phải bài thi thuộc lòng — mỗi tầng là một "khu phố" với trách nhiệm riêng
- Map được công nghệ thực tế (Nginx, TCP, BGP, gRPC…) vào đúng tầng OSI
- Phân biệt L4 vs L7 và ý nghĩa chiến lược khi thiết kế hệ thống
- Biết khi nào cần quan tâm tầng nào trong một system design interview — không lãng phí thời gian vào tầng không liên quan
Tháng 6/2019, Cloudflare — công ty bảo vệ hơn 20 triệu website trên toàn cầu — sập hoàn toàn trong 27 phút. Nguyên nhân gốc rễ? Một BGP route leak từ một ISP nhỏ ở Pennsylvania lan truyền khắp internet, khiến traffic đi lạc qua một mạng không có đủ bandwidth. Đây là sự cố ở L3 — Network Layer. Những engineer hiểu OSI model đã xác định được tầng gặp vấn đề trong vài phút đầu tiên; những người không nắm rõ mô hình này mất hàng giờ chạy theo triệu chứng — kiểm tra application logs (L7), restart services, đổ lỗi cho DNS — tất cả đều sai tầng.
OSI không phải kiến thức hàn lâm để thi chứng chỉ. Nó là framework chẩn đoán mà mọi infrastructure engineer sử dụng hàng ngày. Khi bạn nói "vấn đề ở L4" hay "cần load balancer L7", bạn đang dùng ngôn ngữ chung của ngành — và nếu không hiểu ngôn ngữ này, bạn sẽ bị lạc trong mọi cuộc thảo luận về kiến trúc hệ thống.
Trong bài này, chúng ta sẽ biến 7 tầng OSI từ một bảng cần ghi nhớ thành một bản đồ tư duy sống — nơi bạn có thể chỉ vào bất kỳ công nghệ nào và nói: "Nó sống ở đây, nó nói chuyện với tầng kia, và đây là lý do tôi quan tâm."
Bức tranh tư duy
OSI giống hệ thống bưu điện Việt Nam
Hãy tưởng tượng bạn ngồi ở Hà Nội, viết một lá thư gửi cho người bạn ở TP.HCM. Toàn bộ hành trình của lá thư đó chính là mô hình OSI:
- L7 — Application: Nội dung thư bạn viết — câu chuyện, yêu cầu, thông tin. Đây là thứ người nhận thực sự quan tâm.
- L6 — Presentation: Ngôn ngữ và encoding — bạn viết tiếng Việt hay tiếng Anh? Viết tay hay đánh máy? Có mã hóa (encryption) không? Tầng này đảm bảo hai bên "đọc hiểu" nhau.
- L5 — Session: Cuộc hội thoại — đây là thư đầu tiên hay thư trả lời? Bạn đang duy trì một chuỗi trao đổi (session) hay gửi đơn lẻ?
- L4 — Transport: Phương thức gửi — chuyển phát nhanh đảm bảo (TCP: giao hàng tận tay, ký nhận, gửi lại nếu mất) hay thả tờ rơi (UDP: gửi đi và quên, nhanh nhưng không đảm bảo)?
- L3 — Network: Địa chỉ trên bao thư — số nhà, đường, quận, thành phố (IP address). Hệ thống bưu điện dựa vào địa chỉ để quyết định tuyến đường.
- L2 — Data Link: Xe chở thư giữa các bưu cục — xe nào chở từ bưu cục Hoàn Kiếm sang bưu cục Cầu Giấy (MAC address, Ethernet frame). Mỗi chặng có "phương tiện" riêng.
- L1 — Physical: Con đường vật lý — cáp quang xuyên Việt Nam, sóng WiFi, dây đồng. Tín hiệu điện/quang thực sự di chuyển trên đây.
Nhưng thực tế bạn chỉ cần 4 "tầng chiến lược"
Analogy bưu điện giúp bạn hình dung, nhưng analogy nào cũng có giới hạn. Trong thực tế System Design, bạn không cần nhớ cả 7 tầng. L5 và L6 gần như đã bị "hấp thụ" vào L7 trong thực tế (TLS thường được xem là một phần của transport hoặc application layer, session management nằm trong application logic).
Đây là 4 tầng bạn thực sự cần nắm chắc:
| Tầng chiến lược | Vai trò trong System Design | Bạn quan tâm khi... |
|---|---|---|
| L7 — Application | Nơi application logic sống. HTTP routing, API gateway, content-based decisions | Thiết kế API, chọn protocol, cấu hình reverse proxy |
| L4 — Transport | Nơi quyết định transport và load balancing. TCP vs UDP, port mapping | Chọn load balancer, thiết kế connection pooling, quyết định protocol |
| L3 — Network | Nơi routing và IP addressing sống. Subnet, VPC, BGP | Thiết kế network topology, VPC peering, multi-region routing |
| L2/L1 — "Dưới đất" | Physical và data link — hiếm khi bạn đụng tới | Bạn là network engineer hoặc đang debug latency ở mức physical |
💡 Quy tắc ngón tay cái: Trong 90% system design interviews, bạn chỉ cần nói về L4 và L7. L3 xuất hiện khi bàn về multi-region hoặc CDN routing. L2/L1 gần như không bao giờ được hỏi.
Cốt lõi kỹ thuật
Bản đồ công nghệ theo tầng
Đây là bảng tham chiếu bạn sẽ dùng đi dùng lại trong sự nghiệp. Bookmark nó:
| Tầng | Tên | Công nghệ thực tế | Khi nào bạn quan tâm? |
|---|---|---|---|
| L7 | Application | HTTP/1.1, HTTP/2, HTTP/3, gRPC, WebSocket, GraphQL, DNS (query), SMTP, FTP | Luôn luôn — đây là nơi bạn thiết kế API, chọn protocol, và tối ưu user experience |
| L6 | Presentation | TLS/SSL encryption, JSON serialization, Protobuf encoding, gzip compression, UTF-8 | Khi bàn về encryption strategy và serialization format — thường được gộp vào L7 |
| L5 | Session | Session tokens, OAuth flows, RPC session management | Khi thiết kế authentication flow — thường được gộp vào L7 |
| L4 | Transport | TCP, UDP, QUIC, L4 load balancers (AWS NLB, IPVS, Maglev), TLS handshake | Khi chọn load balancer, quyết định TCP vs UDP, thiết kế connection pooling |
| L3 | Network | IP (IPv4/IPv6), BGP, ICMP (ping/traceroute), OSPF, routing tables, VPC, subnets | Khi thiết kế network topology, multi-region architecture, debug routing issues |
| L2 | Data Link | Ethernet, ARP, MAC addresses, VLANs, switches, Wi-Fi (802.11) | Khi bạn là network engineer hoặc debug latency trong data center |
| L1 | Physical | Fiber optic, Cat6 cables, Wi-Fi radio waves, repeaters, hubs | Hiếm khi — trừ khi bạn đang xây data center |
Tại sao L4 vs L7 là câu hỏi quan trọng nhất?
Trong mọi system design interview, khi bạn vẽ load balancer lên sơ đồ, interviewer sẽ hỏi: "L4 hay L7?". Câu hỏi này tưởng đơn giản nhưng phản ánh chiều sâu hiểu biết kiến trúc của bạn.
L4 Load Balancer — Nhanh nhưng "mù"
L4 LB hoạt động ở Transport Layer — nó chỉ nhìn thấy IP address và port number. Nó không mở gói tin ra xem bên trong có gì. Quyết định routing dựa hoàn toàn trên thông tin TCP/UDP header.
Client 203.0.113.50:54321 → L4 LB → Server 10.0.1.5:8080
(chỉ biết IP:Port, không biết URL hay header)Ưu điểm: Cực nhanh (10M+ connections/s), overhead cực thấp (~10-50μs), không cần decrypt SSL.
Nhược điểm: Không route theo URL, không đọc cookies, không thêm headers, không thể inspect hay modify request content.
L7 Load Balancer — Chậm hơn nhưng "thông minh"
L7 LB hoạt động ở Application Layer — nó mở gói tin ra, đọc HTTP headers, URL path, cookies, thậm chí request body. Quyết định routing dựa trên nội dung request.
Client → L7 LB → Đọc URL: /api/v2/users → Route to API cluster
Đọc URL: /static/image.png → Route to CDN origin
Đọc Header: X-Region: asia → Route to Asia clusterƯu điểm: Content-based routing, SSL termination, header manipulation, request/response transformation, WAF integration.
Nhược điểm: Chậm hơn (~100-500μs overhead), throughput thấp hơn (100K-1M RPS), phải decrypt SSL (tốn CPU).
Bảng trade-off quyết định
| Tiêu chí | L4 Load Balancer | L7 Load Balancer |
|---|---|---|
| Throughput | 10M+ conn/s | 100K–1M req/s |
| Latency overhead | ~10-50μs | ~100-500μs |
| Content routing | ❌ Không thể | ✅ URL, header, cookie |
| SSL termination | ❌ Pass-through only | ✅ Decrypt tại LB |
| WebSocket | ✅ Transparent | ✅ Nhưng cần config |
| Health check | TCP connect only | HTTP endpoint check |
| Cost | Thấp (ít CPU) | Cao (decrypt + parse) |
| Khi nào dùng? | Edge LB, ultra-high traffic, TCP passthrough | API gateway, intelligent routing, SSL offload |
Production pattern chuẩn: Đặt L4 LB ở edge chịu internet traffic (AWS NLB, Google Maglev, IPVS) → route đến cluster L7 LB (Nginx, Envoy, AWS ALB) để xử lý intelligent routing. Không bao giờ để L7 LB chịu raw internet traffic trực tiếp — nó sẽ chết trước khi kịp parse request.
OSI trong một request lifecycle
Khi bạn gõ https://example.com vào trình duyệt và nhấn Enter, đây là hành trình của request qua từng tầng OSI — đi xuống ở phía client, truyền qua mạng, rồi đi lên ở phía server:
Mỗi tầng thêm một "phong bì" (header) khi gửi đi và tách phong bì khi nhận:
| Bước | Tầng | Hành động | Thêm gì? |
|---|---|---|---|
| 1 | L7 | Browser tạo HTTP request | HTTP headers + body |
| 2 | L4 | TCP đóng gói, gán port | TCP header (src/dst port, seq number) |
| 3 | L3 | IP routing, gán địa chỉ | IP header (src/dst IP, TTL) |
| 4 | L2 | Ethernet framing | Ethernet header (src/dst MAC) + FCS |
| 5 | L1 | Chuyển thành tín hiệu vật lý | Bits → electrical/optical signals |
| 6 | L1→L7 (server) | Tách từng lớp header ngược lại | Mỗi tầng đọc header của mình, bóc ra, chuyển lên |
Quá trình này gọi là encapsulation (đóng gói) khi gửi và decapsulation (tách gói) khi nhận. Mỗi tầng chỉ quan tâm đến header của tầng mình — L3 router không cần biết HTTP request chứa gì, nó chỉ nhìn IP address để route.
💡 Câu hỏi trade-off mà senior engineer hay hỏi
"Bạn sẽ đặt load balancer ở L4 hay L7?"
Khi một senior engineer hỏi câu này, họ không đang hỏi bạn định nghĩa L4 và L7. Họ thực sự đang đánh giá bạn trên 3 chiều:
1. Throughput vs Intelligence trade-off: Bạn có hiểu rằng L4 cho throughput cao hơn 10-100x nhưng "mù" trước content? Bạn có biết khi nào throughput quan trọng hơn intelligence (edge load balancing) và ngược lại (API gateway)?
2. SSL termination strategy: Nếu chọn L4, SSL pass-through đến backend — mỗi server phải decrypt (tốn CPU, quản lý cert phức tạp). Nếu chọn L7, LB decrypt một lần — backend nhận plaintext (đơn giản nhưng có security implication cho internal traffic).
3. Ranh giới trách nhiệm: Load balancer nên biết gì về application logic? Nếu LB cần route /api/v2 sang cluster mới và /api/v1 sang cluster cũ, đó là L7 decision. Nếu LB chỉ cần phân phối đều, L4 là đủ.
Câu trả lời "đạt điểm": "Thông thường tôi sẽ dùng L4 ở edge để chịu tải cao, sau đó route đến cluster L7 LB để xử lý intelligent routing. Nhưng nếu hệ thống đơn giản và chỉ cần distribute traffic, L4 alone có thể đủ — ít complexity hơn."
🐦 Caselet: Khi 500 triệu người cùng refresh News Feed
Hãy hình dung bạn đang thiết kế hệ thống News Feed cho một mạng xã hội lớn — quy mô Facebook với 500 triệu daily active users. Mỗi khi người dùng mở app, hàng chục request được gửi đi đồng thời để fetch feed, stories, notifications, và ads. Hiểu mỗi request sống ở tầng OSI nào giúp bạn tối ưu đúng chỗ.
L7 — Application Layer: HTTP/2 multiplexing cho feed API. News Feed API sử dụng HTTP/2 để multiplex nhiều request trên cùng một TCP connection. Thay vì mở 6 connection riêng cho feed, stories, notifications, ads, suggestions, và live status — tất cả chạy song song trên 1 connection. Điều này giảm TLS handshake overhead từ 6 lần xuống 1 lần. Các API endpoint sử dụng gRPC (chạy trên HTTP/2) cho internal service-to-service communication, giảm payload size 5-10x so với JSON nhờ Protobuf serialization.
L4 — Transport Layer: TCP connection pooling giữa services. Giữa API gateway và hàng nghìn backend services, mỗi service duy trì một connection pool — thay vì tạo TCP connection mới cho mỗi request (TCP handshake tốn 1.5 RTT), connection được tái sử dụng. Với 500 triệu users, nếu mỗi user tạo 1 request/s và mỗi request cần new connection, hệ thống sẽ cần handle 500M TCP handshakes/s — bất khả thi. Connection pooling giảm con số này xuống còn vài triệu active connections.
L3 — Network Layer: CDN edge routing cho static assets. Ảnh profile, video thumbnails, và static JS/CSS bundles không được serve từ data center chính. DNS-based routing (sử dụng BGP anycast) đưa user đến CDN edge server gần nhất — user ở Hà Nội hit CDN PoP ở Hà Nội thay vì server ở Singapore. Điều này giảm latency từ ~80ms xuống ~5ms cho static assets. Khi CDN edge không có cache, nó dùng tiered caching (L3 routing) để fetch từ regional origin trước khi về main origin.
Tại sao hiểu layers giúp tối ưu critical path? Khi News Feed chậm, đội ngũ engineering cần xác định bottleneck ở tầng nào: L7 (API processing chậm — optimize query, add cache)? L4 (connection pool exhausted — tăng pool size, debug connection leak)? L3 (routing suboptimal — kiểm tra BGP, CDN cache miss ratio)? Không có "bản đồ OSI" trong đầu, bạn sẽ debug mù — thử từng thứ một thay vì hướng đến đúng tầng.
Sai lầm điển hình
⚠️ Cạm bẫy
1. Nghĩ OSI là lý thuyết hàn lâm, không cần cho System Design
Đây là sai lầm phổ biến nhất. OSI không phải kiến thức để thi — nó là ngôn ngữ giao tiếp của ngành. Khi interviewer hỏi "anh đặt LB ở đâu?", câu trả lời "ở L4 edge rồi L7 internal" chứng tỏ bạn hiểu architecture; câu trả lời "dùng Nginx" chỉ chứng tỏ bạn biết một tool. Mỗi khi bạn nói về latency, throughput, hay routing, bạn đang ngầm nói về một tầng OSI cụ thể — tốt hơn hết là nói rõ ràng.
2. Nhầm lẫn L4 và L7 load balancing — chọn sai, trả giá đắt
Dùng L7 LB (Nginx, ALB) ở edge chịu 10M connections/s → LB chết vì phải parse HTTP cho mỗi connection. Dùng L4 LB để route /api/v2 sang cluster mới → không thể vì L4 không đọc URL. Sai lầm này dẫn đến re-architecture đắt đỏ. Quy tắc: L4 cho volume, L7 cho intelligence. Khi cần cả hai, dùng cả hai theo thứ tự.
3. Bỏ qua TLS termination khi thiết kế
Nhiều engineer vẽ diagram với "Load Balancer" mà không nghĩ TLS terminate ở đâu. Nếu TLS terminate tại L7 LB: backend nhận plaintext, đơn giản nhưng internal traffic không encrypted (rủi ro trong zero-trust environment). Nếu TLS pass-through qua L4: mỗi backend phải manage cert, CPU overhead phân tán, nhưng end-to-end encryption. Đây là quyết định kiến trúc cần nêu rõ trong design, không phải detail bỏ qua.
4. Không hiểu vì sao DNS quan trọng — "nó chỉ là resolve domain thôi mà"
DNS sống ở L7 nhưng ảnh hưởng đến mọi tầng bên dưới. DNS là điểm vào đầu tiên của mọi request — nếu DNS chậm hoặc sai, toàn bộ hệ thống "biến mất". DNS-based load balancing (GeoDNS, weighted DNS) là L7 decision ảnh hưởng đến L3 routing. TTL của DNS record quyết định tốc độ failover. Trong sự cố Facebook 2021, DNS servers không reachable → 3 tỷ users không thể access bất kỳ service nào trong 6 giờ — không phải vì servers chết, mà vì không ai tìm được đường đến servers.
✅ Checklist triển khai
Checklist ghi nhớ
Kiến thức nền tảng
- [ ] Vẽ được 7 tầng OSI và gán ít nhất 2 công nghệ thực tế cho mỗi tầng
- [ ] Giải thích được encapsulation/decapsulation — mỗi tầng thêm/bóc header gì
- [ ] Phân biệt L4 vs L7 load balancer: throughput, latency, khả năng content routing
- [ ] Hiểu tại sao production dùng L4 ở edge + L7 ở internal
Khi thiết kế hệ thống
- [ ] Xác định rõ TLS termination xảy ra ở tầng nào (L4 pass-through vs L7 termination)
- [ ] Khi vẽ load balancer, luôn ghi rõ L4 hay L7 — không để mơ hồ
- [ ] Cân nhắc DNS design: TTL, GeoDNS, failover strategy
- [ ] Với inter-service communication, chọn protocol phù hợp ở L7 (REST vs gRPC vs GraphQL)
- [ ] Khi bàn về CDN, hiểu nó operate ở L3 (routing) + L7 (caching rules)
Khi debug production issues
- [ ] Bắt đầu xác định vấn đề ở tầng nào trước khi dive vào chi tiết
- [ ] Dùng đúng tool cho đúng tầng:
curl(L7),netstat/ss(L4),traceroute(L3),arp(L2) - [ ] Kiểm tra health check hoạt động ở đúng tầng: TCP check (L4) vs HTTP check (L7)
- [ ] Khi latency cao, phân biệt network latency (L3/L4) vs application latency (L7)
- [ ] Hiểu rằng "server không response" có thể là vấn đề ở bất kỳ tầng nào — đừng assume L7
🧠 Quiz
Câu 1: Cloudflare sập năm 2019 do BGP route leak. BGP hoạt động ở tầng nào của OSI model?
- [ ] A. L7 — Application Layer
- [ ] B. L4 — Transport Layer
- [x] C. L3 — Network Layer
- [ ] D. L2 — Data Link Layer Giải thích: BGP (Border Gateway Protocol) là routing protocol hoạt động ở L3 — Network Layer. Nó quyết định traffic đi theo đường nào qua internet. Khi BGP bị leak, traffic bị route sai đường — đây là vấn đề routing (L3), không phải application (L7) hay transport (L4).
Câu 2: Bạn cần load balancer có khả năng route /api/v1 sang cluster cũ và /api/v2 sang cluster mới. Bạn cần LB ở tầng nào?
- [ ] A. L4 — vì throughput cao hơn
- [x] B. L7 — vì cần đọc URL path
- [ ] C. L3 — vì cần biết IP address
- [ ] D. L4 + L3 kết hợp Giải thích: Routing dựa trên URL path (
/api/v1vs/api/v2) yêu cầu LB phải mở gói tin và đọc HTTP request — đây là khả năng của L7 LB. L4 LB chỉ thấy IP:Port, không thể phân biệt URL paths. Đây là ví dụ điển hình về intelligence trade-off: bạn hy sinh throughput (L7 chậm hơn L4) để có content-based routing.
Câu 3: Trong kiến trúc "L4 edge + L7 internal", tại sao không đặt L7 LB trực tiếp ở edge?
- [ ] A. Vì L7 LB không support internet traffic
- [ ] B. Vì L7 LB không có SSL support
- [x] C. Vì L7 LB phải parse HTTP cho mỗi connection → throughput thấp, dễ bị overwhelm bởi DDoS và high traffic
- [ ] D. Vì L7 LB chỉ hoạt động trong internal network Giải thích: L7 LB phải decrypt TLS và parse HTTP request cho mỗi connection — overhead này giới hạn throughput ở ~100K-1M RPS. Edge traffic có thể lên đến hàng chục triệu connections/s (đặc biệt khi bị DDoS). L4 LB ở edge handle raw TCP connections (10M+ conn/s) rồi forward đến cluster L7 LB ở internal — nơi traffic đã được filter và volume thấp hơn nhiều.
Câu 4: DNS thường được phân loại ở L7, nhưng tại sao nó lại ảnh hưởng đến L3 routing?
- [ ] A. DNS không ảnh hưởng đến L3 — chúng hoàn toàn độc lập
- [x] B. DNS resolve domain thành IP address, và IP address quyết định L3 routing path — GeoDNS có thể trả về IP khác nhau cho users ở regions khác nhau
- [ ] C. DNS hoạt động ở L3, không phải L7
- [ ] D. DNS chỉ ảnh hưởng đến L7 application logic Giải thích: DNS query/response là L7 protocol (chạy trên UDP:53 hoặc TCP:53), nhưng kết quả của DNS resolution — IP address — là input cho L3 routing. GeoDNS trả về IP address của server gần user nhất, quyết định traffic đi qua routing path nào ở L3. Đây là ví dụ tuyệt vời về cách các tầng OSI không hoạt động cô lập — quyết định ở tầng này ảnh hưởng đến hành vi ở tầng khác.
🏗️ Kéo thả: Đặt đúng công nghệ vào đúng tầng OSI
Thử thách: Bạn có 10 công nghệ bên trái. Hãy "kéo" mỗi công nghệ vào đúng tầng OSI bên phải.
Danh sách công nghệ
| # | Công nghệ | Mô tả ngắn |
|---|---|---|
| 1 | Nginx | Reverse proxy, web server, load balancer |
| 2 | TCP | Reliable, ordered, connection-oriented transport |
| 3 | BGP | Border Gateway Protocol — inter-domain routing |
| 4 | Redis | In-memory data store, thường dùng qua TCP |
| 5 | gRPC | RPC framework chạy trên HTTP/2 |
| 6 | IPVS | Linux kernel L4 load balancer |
| 7 | Ethernet | LAN protocol, frame-based, dùng MAC address |
| 8 | TLS | Transport Layer Security — encryption |
| 9 | DNS | Domain Name System — resolve domain → IP |
| 10 | WebSocket | Full-duplex communication protocol trên HTTP |
Tầng OSI — Điền vào chỗ trống
┌─────────────────────────────────────────────────┐
│ L7 — Application │ ___, ___, ___, ___, ___│
├─────────────────────────────────────────────────┤
│ L6 — Presentation │ ___ │
├─────────────────────────────────────────────────┤
│ L5 — Session │ (thường gộp vào L7) │
├─────────────────────────────────────────────────┤
│ L4 — Transport │ ___, ___ │
├─────────────────────────────────────────────────┤
│ L3 — Network │ ___ │
├─────────────────────────────────────────────────┤
│ L2 — Data Link │ ___ │
├─────────────────────────────────────────────────┤
│ L1 — Physical │ (không có trong list) │
└─────────────────────────────────────────────────┘✅ Đáp án và giải thích
| Tầng | Công nghệ | Lý do |
|---|---|---|
| L7 — Application | Nginx (reverse proxy xử lý HTTP), Redis (application-level data store, giao tiếp qua protocol riêng trên TCP), gRPC (RPC framework trên HTTP/2), DNS (domain resolution protocol), WebSocket (full-duplex application protocol) | Tất cả đều là application-level protocols hoặc tools hoạt động ở L7 |
| L6 — Presentation | TLS (encryption/decryption) | TLS xử lý encryption — thuộc Presentation layer. Lưu ý: Trong thực tế, TLS thường được xem là nằm giữa L4-L7, nhưng theo mô hình OSI chuẩn, encryption/encoding thuộc L6 |
| L5 — Session | (Thường gộp vào L7 trong thực tế) | Session management ngày nay nằm trong application logic |
| L4 — Transport | TCP (reliable transport), IPVS (kernel-level L4 load balancer quyết định dựa trên TCP/UDP header) | TCP là transport protocol; IPVS route dựa trên L4 information (IP:Port) |
| L3 — Network | BGP (inter-domain routing protocol) | BGP quyết định đường đi của IP packets giữa các autonomous systems |
| L2 — Data Link | Ethernet (frame-based LAN protocol) | Ethernet hoạt động với MAC addresses, frames — đúng L2 |
| L1 — Physical | (Không có trong danh sách) | Fiber optic, cables — hardware layer |
Lưu ý quan trọng: Ranh giới giữa các tầng không phải lúc nào cũng rõ ràng. TLS có thể được xếp vào L6, L5, hoặc thậm chí "between L4 and L7" tùy ngữ cảnh. Redis giao tiếp qua TCP (L4) nhưng protocol logic là L7. Trong interview, quan trọng là bạn giải thích được reasoning, không phải nhớ đúng tầng.