Mô hình TCP/IP 4 tầng — đủ dùng thay cho OSI 7

TL;DR: Khi app gửi GET /, dòng chữ đó không đi thẳng lên dây mạng. Nó được bọc dần qua 4 tầng như thư bỏ vào nhiều lớp phong bì: tầng Transport thêm header TCP (kèm số port) thành segment, tầng Internet thêm header IP (kèm địa chỉ IP) thành packet, tầng Link thêm header Ethernet (kèm địa chỉ MAC) thành frame, rồi mới thành bit trên dây. Máy nhận bóc ngược từng lớp. Đây gọi là encapsulation, và mô hình mô tả nó là TCP/IP 4 tầng — thứ Internet thực sự chạy, gọn hơn OSI 7 tầng học thuật. Hiểu nó, bạn biết mỗi địa chỉ (MAC/IP/port) thuộc tầng nào và một lỗi đang nằm ở tầng nào.

Ở bài trước bạn đã xem một request đi theo dòng thời gian: DNS → TCP → TLS → HTTP. Bài này lùi lại một bước và hỏi câu khác: bên trong máy, dữ liệu được tổ chức thế nào để đi được tới đích?

Vì khi bạn gọi fetch("https://api.com/users"), chuỗi GET /users HTTP/1.1... không thể tự bay tới server. Có hàng loạt câu hỏi phải trả lời: gửi tới máy nào (địa chỉ)? đi đường nào? lỡ mất gói thì sao? tới đúng ứng dụng nào trên máy đó? Mỗi câu hỏi được một tầng riêng lo. Bài này giải thích 4 tầng đó, cách chúng xếp chồng, và vì sao dev không cần học OSI 7 tầng.

1. Analogy — Thư bỏ trong nhiều lớp phong bì

Bạn muốn gửi một lá thư nội bộ cho phòng Kế toán của một công ty ở thành phố khác:

1. Bạn viết nội dung thư (đây là dữ liệu).
2. Bỏ vào phong bì ghi "Gửi: phòng Kế toán" — để trong công ty biết đưa cho đúng phòng.
3. Bỏ phong bì đó vào một bao lớn ghi địa chỉ toà nhà công ty — để bưu điện biết chuyển tới đâu.
4. Bưu điện dán thêm nhãn tuyến chặng xe kế tiếp — để mỗi trạm trung chuyển biết đẩy bao đi đâu.

Mỗi lớp bọc phục vụ một "người xử lý" khác nhau, và người nhận bóc ngược thứ tự: trạm bưu điện đọc nhãn tuyến, công ty đọc địa chỉ toà nhà, lễ tân đọc "phòng Kế toán", kế toán mới mở thư đọc nội dung.

2. Bốn tầng TCP/IP

Từ trên xuống, mỗi tầng giải quyết một bài toán và dùng một loại "địa chỉ" riêng:

• Application — nơi app của bạn sống. HTTP, DNS, hay TLS đều ở đây. Tầng này chỉ quan tâm nghĩa của dữ liệu (một request GET, một câu hỏi DNS), không quan tâm nó tới đích bằng cách nào.
• Transport — phân phối dữ liệu tới đúng ứng dụng trên máy đích qua port, và (với TCP) đảm bảo tới đủ, đúng thứ tự. Đây là tầng phân biệt "gói này cho web server cổng 443" với "gói kia cho SSH cổng 22".
• Internet — định tuyến gói tin tới đúng máy qua địa chỉ IP, nhảy qua các router. Tầng này không đảm bảo gì cả — chỉ "cố gắng hết sức" chuyển gói đi (best-effort).
• Link — truyền dữ liệu qua một chặng vật lý giữa hai thiết bị kề nhau (máy bạn tới router Wi-Fi chẳng hạn), dùng địa chỉ MAC (Media Access Control — định danh phần cứng 48-bit ghi vào card mạng, duy nhất trong một chặng LAN). Mỗi chặng trên đường đi là một lần đóng/mở lớp Link mới.

3. Encapsulation — dữ liệu được bọc dần thế nào

Khi gói dữ liệu đi xuống qua các tầng để rời máy, mỗi tầng thêm header của mình — một khối byte nhỏ nằm đầu dữ liệu, chứa thông tin địa chỉ và điều khiển cho tầng tương ứng ở đầu nhận. Sản phẩm sau mỗi tầng có tên riêng:

flowchart TD
    A["Application: du lieu HTTP - GET /users"] --> B["Transport: them TCP header => SEGMENT"]
    B --> C["Internet: them IP header => PACKET"]
    C --> D["Link: them Ethernet header + trailer => FRAME"]
    D --> E["Physical: chuoi bit tren day dong / song wifi"]

• Dữ liệu app + header TCP = segment (nếu là UDP thì gọi datagram).
• segment + header IP = packet (đôi khi cũng gọi datagram).
• packet + header/trailer Ethernet = frame.
• frame được phát thành bit trên môi trường vật lý.

Nhìn theo "lớp phong bì" — dữ liệu nằm trong cùng, mỗi tầng bọc thêm một header bên ngoài:

Ở máy nhận, quá trình chạy ngược lại — gọi là de-encapsulation: card mạng nhận frame, bóc header Ethernet, đưa packet lên tầng Internet; tầng Internet bóc header IP, đưa segment lên Transport; Transport bóc header TCP, nhìn port để biết giao cho app nào; app cuối cùng nhận đúng GET /users.

4. Một request thật, soi theo tầng

Quay lại curl -v https://api.com/users. Cùng một lệnh, nhìn theo tầng:

Application   GET /users HTTP/2          <- noi dung ban quan tam
              (TLS boc quanh truoc khi xuong TCP)
Transport     TCP, dst port 443          <- toi dung web server
Internet      IP, dst 203.0.113.10       <- toi dung may chu
Link          Ethernet, MAC router       <- qua chang dau tien: may -> router

Mỗi dòng là một tầng thêm "phong bì". Khi debug, biết tầng giúp bạn chọn công cụ: lỗi nội dung/status thì soi tầng Application (curl -v); nghi sai máy/định tuyến thì soi Internet (ping, traceroute); nghi sai cổng/kết nối thì soi Transport (ss, nc).

5. TCP/IP 4 tầng vs OSI 7 tầng

Bạn sẽ gặp cả hai mô hình. OSI là chuẩn học thuật 7 tầng ra đời để mô tả mạng một cách lý tưởng; TCP/IP là mô hình 4 tầng mà Internet thực sự chạy. Chúng ánh xạ như sau:

Vì sao dev dùng 4 tầng? Vì OSI tầng 5 và 6 (Session, Presentation) gần như không có triển khai riêng trong thực tế — chức năng của chúng nằm rải trong thư viện app và TLS. Bạn hầu như chỉ làm việc ở Application và Transport, thỉnh thoảng đụng Internet khi debug mạng. Học thuộc 7 tầng OSI để thi thì được, nhưng để làm việc thì 4 tầng TCP/IP gọn và đúng với thực tế hơn.

6. Mỗi tầng một địa chỉ — đừng trộn lẫn

Một nguồn nhầm lẫn kinh điển: ba loại "địa chỉ" thuộc ba tầng khác nhau, làm ba việc khác nhau.

Một gói tin từ máy bạn tới server giữ nguyên IP đích suốt hành trình, nhưng MAC thay đổi ở mỗi chặng (máy → router → router kế → … → server), vì MAC chỉ có nghĩa trong một chặng LAN. Đây là ý tưởng nền cho cả routing lẫn cơ chế ARP — hai chủ đề sẽ được đào sâu ở module tiếp theo.

→

→

→

IP đích 203.0.113.10 — giữ nguyên suốt 4 chặng

MAC — đổi ở mỗi chặng: máy↔router nhà, router nhà↔router ISP, router ISP↔server

7. Pitfall — hiểu nhầm thường gặp

❌ Nhầm 1: "Mỗi tầng là một chương trình/phần mềm riêng." ✅ Tầng là mô hình khái niệm, không phải process riêng. Trong thực tế, tầng Link nằm ở card mạng + driver, Internet và Transport nằm trong kernel OS, Application nằm trong app của bạn. Phân tầng giúp suy nghĩ, không phản ánh ranh giới process.

❌ Nhầm 2: "TCP/IP là một giao thức." ✅ "TCP/IP" là tên bộ giao thức (protocol suite), đặt theo hai thành viên nổi nhất (TCP ở Transport, IP ở Internet). Nó gồm hàng chục giao thức: UDP, ICMP, ARP, DNS… đều thuộc bộ này.

❌ Nhầm 3: "Encapsulation chỉ là lý thuyết, không ảnh hưởng gì." ✅ Mỗi header tốn byte (overhead). Header IP + TCP cộng lại khoảng 40 byte mỗi gói; với gói nhỏ tỉ lệ overhead cao. Đây là một lý do MTU và việc gộp dữ liệu lại quan trọng (sẽ gặp ở module TCP).

8. 📚 Deep Dive — tài liệu gốc

9. Tóm tắt

• Dữ liệu app được bọc dần qua 4 tầng trước khi rời máy: Application → Transport → Internet → Link, rồi bóc ngược ở máy nhận (encapsulation / de-encapsulation).
• Sản phẩm mỗi tầng có tên: dữ liệu → segment (TCP) → packet (IP) → frame (Ethernet) → bit.
• Mỗi tầng lo một việc và một địa chỉ: Application (nội dung), Transport (port — đúng app), Internet (IP — đúng máy), Link (MAC — đúng chặng).
• IP đích giữ nguyên suốt hành trình; MAC đổi ở mỗi chặng.
• TCP/IP 4 tầng là thứ Internet chạy thật; OSI 7 tầng là mô hình học thuật. Ngành vẫn dùng số tầng OSI khi nói "L4/L7".
• Tầng là khung tư duy, không phải process riêng — nhưng cực hữu ích để biết một lỗi nằm ở đâu và dùng công cụ nào.

10. Tự kiểm tra

Bài tiếp theo: Module 1 — Tổng kết & cheat sheet