Phần 1: Mạng máy tính tổng quan và mô hình tầng

Sau bài này bạn làm được: đọc được diagram luồng request từ trình duyệt tới server; giải thích “lỗi này nằm tầng nào”; phân biệt latency với throughput khi đọc metric.

Khi bạn gọi một API, điều gì thực sự xảy ra?

Hãy lấy thí dụ curl https://api.example.com/users. Từ góc nhìn code, bạn gọi một URL. Nhưng dưới engine, chuỗi sự kiện dài hơn nhiều:

[code của bạn]
      │ gọi HTTP library
      ▼
[HTTP library] ──▶ mở socket TCP
      │
      ▼
[Kernel / TCP stack] ──▶ DNS lookup → lấy IP
      │                ──▶ TCP handshake (3 bước)
      │                ──▶ TLS handshake (nếu HTTPS)
      ▼
[NIC / driver] ──▶ đóng gói thành frame Ethernet
      │
      ▼
[Dây cáp / Wi-Fi / cloud fabric]
      │
      ▼
[Server phía kia: NIC → Kernel → process NGINX → app]

Sự cố có thể xảy ra ở bất kỳ bước nào. Đây là lý do DevOps cần biết hơn mức “code ổn là xong”.

Mô hình tầng — dùng như bản đồ, không cần thuộc lòng

Bạn sẽ nghe đến “OSI 7 tầng” và “TCP/IP 4 tầng”. Thực tế vận hành, phân biệt 4 nhóm sau là đủ:

Nhóm	Giao thức điển hình	Câu hỏi debug
Liên kết	Ethernet, Wi-Fi	Cùng switch/VLAN chưa?
Mạng (IP)	IPv4, IPv6	Route đúng không? Firewall/SG chặn chưa?
Giao vận	TCP, UDP	Cổng mở chưa? Kết nối timeout hay refused?
Ứng dụng	HTTP, DNS, TLS	Status code? Cert hợp lệ?

Quy tắc debug: luôn đi từ dưới lên. Nếu TCP không mở được thì đừng mất thời gian đọc HTTP log.

Luồng dữ liệu thực tế qua các tầng

Khi bạn gửi một HTTP request, kernel đóng gói (encapsulation) theo chuỗi:

[HTTP data]
    ↓ wrap TCP header (src/dst port, seq number…)
[TCP segment]
    ↓ wrap IP header (src/dst IP, TTL…)
[IP packet]
    ↓ wrap Ethernet header (src/dst MAC)
[Ethernet frame]
    ↓ gửi ra dây / Wi-Fi

Phía nhận tháo ngược (decapsulation): tháo Ethernet → IP → TCP → trao data cho HTTP library.

Mỗi thiết bị trung gian (router, LB) chỉ nhìn tới tầng nó cần: router đọc IP header, LB L7 đọc tới HTTP header.

MTU — giới hạn kích thước gói

MTU (Maximum Transmission Unit) là kích thước tối đa của một Ethernet frame payload (~1500 byte thông thường).

Khi IP packet lớn hơn MTU:

Fragmentation (IPv4): router chia packet thành các mảnh nhỏ hơn, ghép lại ở đích.
PMTUD (Path MTU Discovery): kernel thử tìm MTU nhỏ nhất trên đường đi; nếu ICMP “Fragmentation Needed” bị chặn → PMTUD black hole — kết nối treo kỳ lạ.

Gặp trong thực tế:

VPN hoặc tunnel overlay (VXLAN, WireGuard) giảm MTU hiệu dụng xuống ~1400–1450 byte.
Container trong VPC cloud đôi khi cần cấu hình MTU thủ công.
Triệu chứng: ping nhỏ (< 1400 byte) thành công, tải file lớn hoặc SSH copy file treo.

Latency vs Throughput

Hai chỉ số hay bị nhầm lẫn:

Chỉ số	Định nghĩa	Ảnh hưởng
Latency	Thời gian một gói đi một chiều hoặc RTT (round-trip time)	TTFB, tương tác realtime, số lượng round-trip trong handshake
Throughput	Dữ liệu truyền được trong đơn vị thời gian	Tải file lớn, streaming, backup

Ví dụ dễ nhầm: đường truyền vệ tinh có throughput hàng trăm Mbps nhưng latency 600ms → ping web nhanh về RTT nhưng cảm giác “chậm” vì nhiều round-trip.

Áp dụng: API “chậm cảm giác” với payload nhỏ → nghi ngờ latency / nhiều RTT (TLS handshake, redirect); API đơn chiều nhưng tải chậm → nghi ngờ throughput / bandwidth.

IPv4/IPv6 và Happy Eyeballs

Khi tên miền có cả bản ghi A (IPv4) và AAAA (IPv6), client hiện đại (browser, curl, getaddrinfo trên Linux/macOS/Windows) dùng thuật toán Happy Eyeballs (RFC 8305): thử IPv6 trước, nếu sau ~250ms chưa có phản hồi thì parallel với IPv4, dùng bên nào connect xong trước.

Hệ quả vận hành:

AAAA record hỏng (IP chết, firewall không mở v6) → user vẫn vào được qua fallback IPv4, nhưng thêm ~250ms cho mỗi cold connection.
Logs LB có thể thấy client IP là IPv6 hôm nay, IPv4 hôm khác cùng user.
Cloud hiện khuyến khích dual-stack; từ 2024 AWS tính phí mỗi public IPv4 → lý do kinh tế để test IPv6 ngay (xem bài 11).

Tóm tắt

Mỗi request đi qua chuỗi tầng; sự cố có thể ẩn ở bất kỳ tầng nào bên dưới HTTP.
Debug theo thứ tự: Liên kết → IP → TCP → Ứng dụng.
MTU là giới hạn vật lý ảnh hưởng đến VPN, container và cloud overlay.
Latency và throughput cần đo bằng công cụ khác nhau (ping/mtr vs iperf/speedtest).

Câu hỏi hay gặp

Một request HTTPS thành công đi qua những handshake nào và tốn khoảng bao nhiêu RTT?

Trả lời: Thường có DNS (0 RTT nếu cache, hoặc vài RTT nếu phải đi recursive), TCP (1 RTT cho 3-way handshake), TLS (TLS 1.2 thường ~2 RTT, TLS 1.3 thường ~1 RTT), sau đó mới tới byte HTTP đầu tiên. Redirect HTTP→HTTPS hay challenge thêm bước. Tổng RTT phụ thuộc phiên bản TLS và có bật session resumption hay không.

SSH tương tác ổn nhưng `scp` file lớn bị treo — hay gặp nguyên nhân gì?

Trả lời: Thường nghi MTU/PMTUD (gói lớn bị drop qua VPN/tunnel/overlay), đường truyền tắc nghẽn, hoặc I/O đĩa phía gửi/nhận. Lệnh nhỏ không tạo luồng TCP lớn liên tục nên ít kích hoạt vấn đề so với transfer dài.

“Server 10Gbps throughput” có nói lên latency thấp không?

Trả lời: Không. Throughput là băng thông đạt được; latency là độ trễ từng gói/RTT. Hai độc lập: đường 10Gbps vẫn có thể RTT cao (khoảng cách địa lý, vệ tinh, queue sâu).

Bài tiếp theo (Giai đoạn I): IP, subnet và routing cơ bản — nền để hiểu VPC và Kubernetes Service network.