/ tất cả bài học → CHẶNG 01 · Networking ( CCNA )

Bài 03

TCP/IP và mô hình OSI: Hiểu cách dữ liệu đi từ A đến B

04 tháng 5, 2026 · 45 phút đọc

Bài 03 — TCP/IP và mô hình OSI: Hiểu cách dữ liệu đi từ A đến B

Chặng 01 — Networking (CCNA) | Bài 03 | Thời lượng: 60–90 phút

Tiền đề: Đã hiểu khái niệm IP, packet; đã học bài 01–02.

Phần 1 — Tại sao bài này quan trọng với DevOps?

Hồi mới vào nghề, mình từng nghĩ "ôi, OSI 7 layer là chuyện của mấy ông thi CCNA, làm DevOps biết IP với port là đủ". Sai bét. Sai cay đắng. Sai đến mức bốn năm sau, mỗi lần ngồi onboard đàn em mới, mình đều bắt đầu bằng câu: "Em chưa cần thuộc lòng 7 tầng, nhưng phải hiểu mỗi tầng giải quyết vấn đề gì — không thì sự cố production xảy ra, em sẽ đứng nhìn log mà không biết cào ở đâu."

Công việc DevOps thực chất là gì? Là khi hệ thống chạy ngon, không ai gọi mình. Là khi 2h sáng có cảnh báo timeout, mình phải vào và biết ngay: "Lỗi này ở tầng nào?". Cùng một triệu chứng connection refused thôi, nhưng nguyên nhân có thể nằm ở Layer 2 (cáp đứt, VLAN sai), Layer 3 (route không có), Layer 4 (port không listen, firewall block), hay Layer 7 (app bug, TLS mismatch). Không có khái niệm phân tầng rõ ràng trong đầu, mình sẽ debug như đoán xổ số.

Bài này không phải để bạn đi thi CCNA. Nó là cái khung tư duy mà mọi cuộc debug network sau này đều dựa vào — từ container networking, Kubernetes Service, đến VPC trên cloud. Học chắc một lần, dùng cả đời.

Phần 2 — Bản chất vấn đề

Trước khi nói OSI, mình muốn bạn trả lời câu hỏi: vì sao phải có "tầng" (layer) làm gì cho phức tạp?

Tưởng tượng bạn gửi một kiện hàng từ Hà Nội sang Tokyo. Bạn không tự lái xe sang Nhật — bạn đưa cho bưu điện. Bưu điện cũng không tự bay — họ giao cho hãng vận chuyển. Hãng vận chuyển không tự làm thủ tục hải quan — có dịch vụ riêng. Hải quan không tự xếp hàng lên máy bay — sân bay làm việc đó.

Mỗi khâu chỉ làm một việc và làm tốt việc đó. Bạn là người gửi, bạn không cần biết máy bay bay theo route nào. Hãng máy bay không cần biết trong kiện hàng có gì. Mọi người tin nhau qua một interface chuẩn: bạn đưa kiện hàng kèm địa chỉ → bưu điện lo phần còn lại.

Mạng máy tính cũng vậy. Khi bạn gõ curl https://google.com:

Browser/curl không cần biết packet đi qua bao nhiêu router
Router không cần biết content bên trong packet là HTML hay JSON
Card mạng không cần biết đây là HTTP hay SSH
Mỗi tầng bóc lớp vỏ của tầng trên ra, làm việc của mình, rồi đẩy xuống tầng dưới

Đó là encapsulation — đóng gói nhiều lớp như búp bê Nga (Matryoshka). Mỗi lớp có "phong bì" (header) riêng, và chỉ tầng tương ứng ở đầu bên kia mới mở ra đọc.

Phần 3 — Đi sâu vào kỹ thuật

3.1 Mô hình OSI 7 tầng

OSI (Open Systems Interconnection) là mô hình lý thuyết do ISO chuẩn hóa từ thập niên 80. Nó không phải là cách Internet thực sự được implement — nhưng nó là ngôn ngữ chung mà cả ngành dùng để nói chuyện về network. Khi sếp bạn nói "lỗi này nằm ở Layer 7" — sếp đang nói tiếng OSI.

┌────────────────────────────────────────────────────┐
│ Layer 7 — Application   │ HTTP, DNS, SSH, FTP      │  ← Cái bạn code, bạn dùng
├────────────────────────────────────────────────────┤
│ Layer 6 — Presentation  │ TLS/SSL, JPEG, ASCII     │  ← Mã hoá, nén, format
├────────────────────────────────────────────────────┤
│ Layer 5 — Session       │ Quản lý phiên            │  ← Mở/đóng/giữ kết nối
├────────────────────────────────────────────────────┤
│ Layer 4 — Transport     │ TCP, UDP                 │  ← Đảm bảo data tới đúng
├────────────────────────────────────────────────────┤
│ Layer 3 — Network       │ IP, ICMP, OSPF, BGP      │  ← Định tuyến giữa mạng
├────────────────────────────────────────────────────┤
│ Layer 2 — Data Link     │ Ethernet, MAC, ARP       │  ← Truyền trong cùng LAN
├────────────────────────────────────────────────────┤
│ Layer 1 — Physical      │ Cáp, sóng, điện áp       │  ← Bit thật chạy trên dây
└────────────────────────────────────────────────────┘

Mình giới thiệu nhanh từng tầng — ưu tiên cách nó biểu hiện khi sự cố, không phải định nghĩa SGK:

Layer 1 — Physical: Cáp, port, sóng wifi, sóng quang. Sự cố ở đây thường nhìn thấy bằng mắt: cáp đứt, port nháy đèn đỏ, switch tắt nguồn. Lệnh hay dùng: ip link show xem card mạng up/down.

Layer 2 — Data Link: Đây là tầng "trong cùng một LAN, làm sao máy A nói được với máy B". Dùng địa chỉ MAC. ARP là giao thức tầng này (hỏi "ai có IP này, cho tôi MAC tương ứng"). Sự cố thường gặp: VLAN sai, MAC table đầy, ARP cache loạn.

Layer 3 — Network: Tầng định tuyến — packet đi qua nhiều mạng khác nhau bằng cách nào. IP nằm ở đây. Router làm việc ở tầng này. Sự cố: route không có, default gateway sai, IP conflict. Lệnh hay dùng: ip route, traceroute, mtr.

Layer 4 — Transport: TCP và UDP nằm đây. TCP đảm bảo data tới đủ và đúng thứ tự (như gửi thư bảo đảm), UDP thì cứ gửi đi không quan tâm tới hay không (như tờ rơi). Port number ở tầng này. Sự cố: port không listen, firewall chặn, TCP handshake fail. Lệnh: ss, nc (netcat), tcpdump.

Layer 5/6/7: Trong thực tế, ranh giới giữa Session, Presentation, Application rất mờ. Nói chung đây là tầng app — HTTP, gRPC, SSH, DNS, TLS. Đây là nơi 80% thời gian DevOps debug.

3.2 Mô hình TCP/IP 4 tầng

Mô hình mà Internet thực sự chạy gọn hơn — chỉ 4 tầng:

       OSI                         TCP/IP
┌─────────────────┐         ┌─────────────────┐
│ 7. Application  │ ──┐     │                 │
├─────────────────┤   │     │  Application    │
│ 6. Presentation │ ──┼───► │  (HTTP, DNS,    │
├─────────────────┤   │     │   TLS, SSH...)  │
│ 5. Session      │ ──┘     │                 │
├─────────────────┤         ├─────────────────┤
│ 4. Transport    │ ──────► │  Transport      │
│                 │         │  (TCP, UDP)     │
├─────────────────┤         ├─────────────────┤
│ 3. Network      │ ──────► │  Internet       │
│                 │         │  (IP, ICMP)     │
├─────────────────┤         ├─────────────────┤
│ 2. Data Link    │ ──┐     │                 │
├─────────────────┤   ├───► │  Link           │
│ 1. Physical     │ ──┘     │  (Ethernet)     │
└─────────────────┘         └─────────────────┘

Khi đi làm, các bạn senior thường nói "Layer 4" hay "Layer 7" — họ đang ám chỉ OSI cho gọn (Transport vs Application). Còn khi đọc tài liệu kỹ thuật chuẩn (RFC), thường dùng TCP/IP model. Cứ thoải mái, hai cái này không mâu thuẫn — chỉ là cách nhóm khác nhau.

3.3 Encapsulation — gói búp bê Nga

Khi browser gửi request GET / tới google.com, dữ liệu được đóng gói qua từng tầng:

[Application] HTTP request: "GET / HTTP/1.1\r\nHost: google.com\r\n\r\n"
       ↓ Layer 6 mã hoá bằng TLS
[Presentation] <encrypted blob>
       ↓ Layer 4 thêm TCP header (port nguồn 54321, port đích 443)
[Transport]    [TCP header][encrypted blob]
       ↓ Layer 3 thêm IP header (IP nguồn, IP đích)
[Network]      [IP header][TCP header][encrypted blob]
       ↓ Layer 2 thêm Ethernet frame (MAC nguồn, MAC đích = MAC router gateway)
[Data Link]    [Eth header][IP header][TCP header][encrypted blob][Eth trailer]
       ↓ Layer 1 chuyển thành tín hiệu điện/sóng
[Physical]     0101110100110...

Bên Google nhận được, bóc ngược lại từng lớp. Mỗi lớp không quan tâm lớp trên là gì — chỉ làm việc của mình.

Hiểu cái này rồi, khi bạn nhìn output tcpdump hay Wireshark sẽ không còn thấy đáng sợ — đó chính là 4–5 lớp header xếp chồng nhau, đúng theo thứ tự trên.

Phần 4 — Câu chuyện hiện trường

💡 Một lần ở production...

Tháng 8/2024, team backend bên mình deploy một service mới gọi API tới một đối tác fintech. Code chạy ngon trên dev, lên staging cũng ngon. Production deploy xong khoảng 30 phút thì bắt đầu có alert: tỉ lệ lỗi gọi API ngoài ~12%, lúc cao điểm lên 40%. Triệu chứng cụ thể: client báo connection reset hoặc handshake timeout.

Bạn dev đầu tiên xử lý đoán ngay là "bên đối tác có vấn đề" và mở ticket sang bên kia. Họ trả lời cụt lủn: "service bên mình ổn, các khách hàng khác không ai báo lỗi". Quả banh quay về bên mình.

Mình vào, làm theo đúng quy trình debug từ thấp lên cao.

Layer 3 (IP routing): traceroute từ pod ra IP đối tác — đi qua được, không drop ở hop nào. OK, không phải routing.

Layer 4 (TCP): tcpdump -i eth0 host <ip-đối-tác> trên node, thấy gói SYN gửi đi, gói SYN-ACK trả về, ACK xong — tức là TCP 3-way handshake thành công. Không phải firewall, không phải port, không phải Layer 4.

Lên Layer 6/7 — TLS. Mình bật flag debug TLS trong app:
# Bật log chi tiết của TLS handshake trong JVM
JAVA_OPTS="-Djavax.net.debug=ssl,handshake"
Log đổ ra một dòng làm mình lạnh sống lưng:
Received fatal alert: protocol_version
Lúc đó là 23:47. Sau khi gọi xác nhận, đối tác mới thừa nhận đã âm thầm disable TLS 1.0 và 1.1 vào lúc 22:00 cùng ngày để tuân thủ chính sách bảo mật mới. JVM bên mình build từ một base image cũ (OpenJDK 8 update 181) có default behavior fallback xuống TLS 1.0 trong một số trường hợp. Ở dev/staging chúng mình test với mock server không strict, nên không lộ.

Fix: thêm -Dhttps.protocols=TLSv1.2,TLSv1.3 cho JVM, rebuild image, deploy. 00:30 sáng — error rate về 0.

Bài học rút ra:

TCP handshake thành công không có nghĩa kết nối "tốt" — TLS handshake là một tầng riêng phía trên, có thể fail độc lập.

Nếu mình không có khái niệm rõ ràng "tầng nào làm gì" trong đầu, sẽ không biết bật -Djavax.net.debug=ssl ở đâu, debug ở Layer mấy. Cứ đoán mò là mất nguyên đêm.

Mỗi tầng có công cụ debug riêng — Layer 3: traceroute, mtr. Layer 4: tcpdump, ss. Layer 6 với TLS: log handshake, openssl s_client. Phải nhớ bộ đồ nghề cho từng tầng.

Phần 5 — Lab thực hành: Bắt và phân tích gói tin HTTP bằng Wireshark

Mục tiêu: Sau lab này bạn sẽ tự mở Wireshark, bắt được một request HTTP, và chỉ ra được header của từng layer (Ethernet, IP, TCP, HTTP) trong cùng một packet.

Môi trường: Máy laptop có Wireshark cài sẵn. Linux/macOS/Windows đều OK. Cần internet.

Yêu cầu tiên quyết: Đã cài Wireshark từ https://www.wireshark.org. Trên Linux/Mac có thể cần sudo để bắt traffic.

Các bước

Bước 1 — Mở Wireshark và chọn interface

Mở Wireshark. Bạn sẽ thấy danh sách network interface (eth0, wlan0, en0...). Chọn cái đang có internet. Trên macOS thường là en0. Click đúp vào để bắt đầu capture.

Bước 2 — Đặt filter trước khi bắt (rất quan trọng)

Nếu không filter, sẽ có hàng nghìn packet rác (DNS, ARP, traffic background). Trong ô filter trên cùng, gõ:

host example.com and tcp.port == 80

Filter này chỉ bắt traffic đi/về example.com qua port 80. Mục đích là chọn HTTP (cleartext) chứ không phải HTTPS — để bạn thấy được nội dung không mã hoá.

Bước 3 — Tạo traffic

Mở terminal, chạy:

# Gọi HTTP (KHÔNG phải HTTPS) tới example.com
# Cờ -v để in chi tiết request/response ra màn hình
curl -v http://example.com

Quay lại Wireshark, bạn sẽ thấy 5–7 packet xuất hiện.

Bước 4 — Phân tích một packet

Click vào packet có GET / HTTP/1.1 trong cột Info. Ở panel giữa, bạn sẽ thấy đại loại như sau:

▶ Frame 1: 489 bytes on wire
▶ Ethernet II, Src: aa:bb:cc:..., Dst: dd:ee:ff:...                   ← Layer 2
▶ Internet Protocol Version 4, Src: 192.168.x.x, Dst: 93.184.216.34   ← Layer 3
▶ Transmission Control Protocol, Src Port: 54321, Dst Port: 80        ← Layer 4
▶ Hypertext Transfer Protocol                                          ← Layer 7

Click vào từng dòng để bung ra. Đây chính là encapsulation đã nói ở phần 3.3 — bạn đang nhìn thấy bằng mắt.

Bước 5 — Quan sát TCP 3-way handshake

Cuộn lên trên cùng. Bạn sẽ thấy 3 packet đầu tiên:

1. [SYN]      192.168.x.x → 93.184.216.34   (mình hỏi: tao muốn kết nối)
2. [SYN, ACK] 93.184.216.34 → 192.168.x.x   (server: ok, đồng ý)
3. [ACK]      192.168.x.x → 93.184.216.34   (mình: chốt)

Đây là TCP 3-way handshake kinh điển. Sau bước này, kết nối TCP mới được "thiết lập" và HTTP request mới được gửi đi (packet thứ 4 trở đi).

Kết quả mong đợi: Bạn bắt được ít nhất 1 packet HTTP, click vào và thấy đủ 4 layer header. Bạn cũng quan sát được 3-way handshake.

Self-check:

Bạn có chỉ ra được dòng nào trong Wireshark là Layer 4 không?
Port nguồn của bạn là số bao nhiêu? (Gợi ý: nó được sinh ngẫu nhiên trong khoảng ~32768–65535, gọi là ephemeral port.)
Thử lại với https://example.com — vì sao bạn không đọc được nội dung HTTP nữa? (Gợi ý: Layer 6 đã mã hoá.)

Phần 6 — Best practices

1. Khi debug network, luôn xác định "đây là sự cố tầng nào?" trước khi gõ command

WHY: Mỗi tầng có bộ công cụ riêng. Lệnh ping chỉ test Layer 3 — ping thông không có nghĩa app sẽ chạy được. Lẫn lộn tầng = debug sai chỗ = mất thời gian.

HOW: Triệu chứng → đoán tầng → chọn tool. App báo connection refused → nghi Layer 4 → nc -zv host port. App "chạy chậm" → có thể Layer 3 (latency) hoặc Layer 7 (app chậm) → bắt đầu bằng mtr.

2. Debug từ thấp lên cao khi nghi infrastructure, từ cao xuống thấp khi nghi app

WHY: Nếu Layer 2/3 hỏng thì Layer 7 không thể chạy. Test ngược chiều giúp loại trừ tầng nhanh.

HOW: Hạ tầng mới deploy → bắt đầu ip link, ip route, ping. Service đã chạy lâu, bỗng dưng lỗi → có khả năng cao là app/config Layer 7 → đọc log app trước, rồi mới xuống.

3. Học thuộc bộ tool tối thiểu cho mỗi tầng

WHY: Khi sự cố production, không có thời gian Google. Phải nhớ ngay tool nào.

HOW: Bộ tool tối thiểu nên thuộc lòng:

Layer 2: ip link, arp -n
Layer 3: ip addr, ip route, ping, traceroute / mtr
Layer 4: ss -tlnp, nc -zv, tcpdump
Layer 7: curl -v, dig, openssl s_client

4. Không phán đoán mù, hãy capture traffic

WHY: Đoán = lãng phí thời gian. tcpdump hay Wireshark cho bạn sự thật khách quan, không cần tin lời ai.

HOW: Nghi sự cố network giữa pod và service → kubectl exec vào pod, chạy tcpdump -i any -w /tmp/dump.pcap host <ip>. Copy file .pcap về máy phân tích bằng Wireshark.

5. Khi đọc log app, luôn map error message vào tầng tương ứng

WHY: Cùng một message có thể hiểu nhiều cách. Map về tầng giúp tìm root cause nhanh.

HOW: connection refused (Layer 4 — đầu kia có nhận packet nhưng không có process listen). connection timeout (Layer 3/4 — packet không tới được hoặc tới nhưng không trả). host not found (Layer 7 — DNS). SSL handshake failed (Layer 6 — TLS). Phân biệt từng thông báo này thành phản xạ.

Phần 7 — Pitfalls — Lỗi thường gặp

Pitfall 1: ping thông là tưởng network OK

Triệu chứng: "Em ping thông server rồi mà sao app gọi vẫn lỗi?"
Nguyên nhân: ping chỉ test Layer 3 (ICMP). Nó không nói gì về Layer 4 (port có mở không?) hay Layer 7 (app có chạy không?). Mình từng thấy nhiều case ping được mà port 443 bị firewall chặn.
Phòng tránh: Sau ping, luôn test thêm Layer 4: nc -zv <host> <port> hoặc curl -v lên port thực tế.

Pitfall 2: Lẫn lộn IP và port

Triệu chứng: "Em sửa IP rồi mà sao port vẫn không mở được?"
Nguyên nhân: IP (Layer 3) và port (Layer 4) là hai tầng khác nhau. IP nói "máy nào", port nói "process nào trên máy đó". Đổi IP không làm process tự listen port mới.
Phòng tránh: Khi config service, luôn nghĩ rõ: bind IP nào (0.0.0.0 vs 127.0.0.1?), port nào, firewall mở chưa.

Pitfall 3: Quên rằng TLS là một tầng riêng

Triệu chứng: Như case bên đối tác fintech ở Phần 4 — TCP handshake thành công nhưng TLS fail. Log app có thể chỉ báo "connection error" chung chung.
Nguyên nhân: Default log của nhiều framework không show TLS detail. Phải bật flag riêng (-Djavax.net.debug=ssl cho Java, NODE_DEBUG=tls cho Node, ...).
Phòng tránh: Khi gặp lỗi gọi HTTPS không rõ nguyên nhân, luôn bật TLS debug trước khi đoán tiếp.

Pitfall 4: Đọc tcpdump mà không hiểu byte nào ở đâu

Triệu chứng: Mở Wireshark thấy hàng nghìn dòng, bối rối, đóng lại.
Nguyên nhân: Chưa nắm vững encapsulation, không biết byte nào thuộc layer nào.
Phòng tránh: Lab phần 5 phía trên — phân tích từng packet theo tầng. Làm 3–4 lần là quen.

Pitfall 5: Tin tưởng tuyệt đối vào diagram trên giấy

Triệu chứng: "Theo sơ đồ thì traffic phải đi qua firewall A rồi load balancer B..." — nhưng thực tế lại không phải thế.
Nguyên nhân: Diagram trên Confluence thường outdated. Network thực có thể có route khác do BGP, có policy routing, có NAT phức tạp.
Phòng tránh: Khi debug, đừng tin diagram trước, tin packet trước. traceroute từ điểm A đến điểm B xem packet thực sự đi đường nào.

Phần 8 — Liên kết với DevOps thực tế

Bài này là nền móng của gần như mọi chặng còn lại. Cụ thể:

Khi bạn học Container Networking (chặng 04), sẽ gặp khái niệm bridge, veth pair, network namespace — toàn bộ là Layer 2 và 3. Hiểu OSI rồi, bạn sẽ thấy Docker thực ra chỉ là "tạo một LAN ảo trên máy host" — không có gì huyền bí.

Khi học Kubernetes Service (chặng 05), bạn sẽ thấy: ClusterIP và NodePort là Layer 4 (TCP/UDP forwarding); Ingress là Layer 7 (HTTP routing dựa trên path/host); LoadBalancer trên cloud có loại Layer 4 (NLB) và Layer 7 (ALB) — chọn loại nào tuỳ use case.

Câu chuyện về MTU mismatch trong overlay network (Calico/Flannel) mà mình thường kể — đó là Layer 3 fragmentation trong gói VXLAN. Nếu chưa hiểu Layer 2/3 vững, gặp bug đó thì không cách gì lần ra được.

Khi sang CI/CD và Cloud (chặng 06–07), config VPC, security group, NACL trên AWS/GCP cũng đều quay về OSI: VPC subnet là Layer 3, security group là Layer 4 (port-based), WAF là Layer 7.

Tóm lại: bài này không phải kiến thức rời rạc. Nó là cái khung mà mọi thứ network sau này móc vào.

Phần 9 — Dùng AI thông minh khi học phần này

AI rất hữu ích nếu bạn biết hỏi đúng. Một số prompt mình thấy hiệu quả:

Prompt tốt 1 — Hỏi để hiểu, không phải để chép:

Tao đang học mô hình OSI. Tao hiểu Layer 4 là TCP/UDP nhưng chưa rõ:
- Khi xuất hiện lỗi "connection refused", packet đi tới đâu thì bị reject?
- TCP RST packet được gửi từ ai, ở thời điểm nào?
Hãy giải thích bằng ví dụ cụ thể, có thể kèm ASCII diagram nếu cần.

Prompt tốt 2 — Diễn giải log thực tế:

Đây là output `tcpdump` của tao [paste output]. Hãy chỉ rõ:
- Packet nào là TCP handshake?
- Có TLS không?
- Nếu có lỗi, lỗi nằm ở layer nào?

Prompt tốt 3 — Xác minh sau khi tự đoán:

Tao nghi sự cố này nằm ở Layer 4 vì [lý do của tao].
Lập luận của tao có lỗ hổng gì không?

Cảnh báo những câu hỏi AI hay trả lời SAI:

"Lệnh chính xác để cấu hình X trên Cisco IOS phiên bản Y" — AI rất hay bịa command Cisco: nhớ sai version, nhớ sai syntax, hợp logic nhưng không tồn tại. Luôn verify với docs Cisco chính thức trước khi gõ vào thiết bị thật.
"MTU mặc định trên Calico là bao nhiêu?" — Câu trả lời phụ thuộc backend (VXLAN, IPIP, BGP), version Calico, và môi trường. AI sẽ trả lời rất tự tin nhưng có thể sai. Đọc docs Calico hoặc check calicoctl thực tế.
"tcpdump filter expression cho trường hợp đặc thù" — AI hay nhầm syntax giữa BPF (tcpdump capture filter) và Wireshark display filter. Hai cái khác nhau hoàn toàn. Verify bằng man tcpdump.

Quy tắc vàng: AI là người đồng đội thông minh nhưng đôi khi tự tin sai. Mọi command/config nó đưa, bạn phải hiểu được vì sao đúng — nếu không hiểu, đừng paste vào production.

Phần 10 — Tóm tắt: 3 điều cần khắc cốt

Mỗi tầng giải quyết một vấn đề riêng, và sự cố ở mỗi tầng có triệu chứng — công cụ debug — cách fix khác nhau. Phản xạ đầu tiên khi gặp lỗi network: "Đây là tầng nào?".
TCP handshake thành công ≠ kết nối hoạt động. TLS, HTTP, application logic là các tầng riêng phía trên. ping thông không nói lên gì về app.
Khi debug, đừng đoán — hãy capture. tcpdump, Wireshark, log debug là sự thật. Diagram, lời nói, kinh nghiệm chỉ là giả thuyết cần được kiểm chứng.

Phần 11 — Câu hỏi tự kiểm tra

Sắp xếp các giao thức/khái niệm sau vào đúng layer của OSI: HTTP, MAC address, TCP, IP, TLS, cáp Ethernet, ARP, port 443.
Bạn ping được tới một server (Layer 3 OK) nhưng curl http://server báo connection refused. Nguyên nhân khả dĩ nằm ở tầng nào? Bạn sẽ kiểm tra bằng lệnh gì?
Trong câu chuyện hiện trường ở Phần 4, vì sao TCP handshake thành công mà kết nối vẫn fail? Kỹ sư đã debug ở những tầng nào trước khi tìm ra root cause?
Khi đóng gói một HTTP request đi qua các tầng, header của tầng nào được thêm đầu tiên và header của tầng nào được thêm cuối cùng?
Bạn deploy một service Kubernetes loại LoadBalancer trên AWS. Cloud provider tạo ra một NLB (Network Load Balancer). NLB hoạt động ở Layer mấy? Khác gì so với ALB (Application Load Balancer)?
Một packet HTTPS đi từ browser tới server. Liệt kê tối thiểu 5 header mà packet đó mang theo, và mỗi header thuộc tầng nào.
Bạn dev báo: "API gọi sang microservice khác lúc được lúc không, error rate ~5%, không có pattern rõ ràng". Bạn sẽ debug từ tầng nào lên hay từ tầng nào xuống? Vì sao? Nêu 3 lệnh đầu tiên bạn sẽ chạy.

Bài tiếp theo: Bài 04 — Subnetting và CIDR: chia mạng thành các "khu phố" như thế nào.