Mô hình mạng & Các tầngNetwork Models & Layers

Thuộc bộ kiến thức Network Engineer Roadmap.

Tổng quan

Network model (mô hình mạng) là một framework tham chiếu phân tầng, chia bài toán khổng lồ “đưa dữ liệu từ một chương trình trên máy này tới một chương trình trên máy khác, ở bất kỳ đâu trên Trái Đất” thành một chồng (stack) các tầng nhỏ hơn, có định nghĩa rõ ràng. Mỗi tầng (layer) chỉ có một trách nhiệm duy nhất, chỉ giao tiếp với tầng ngay trên và ngay dưới nó, và có thể được thiết kế, cài đặt cũng như suy luận một cách độc lập.

Có hai mô hình thống trị lĩnh vực này:

• OSI model (Open Systems Interconnection) — mô hình tham chiếu khái niệm gồm 7 tầng do ISO công bố. Không ai triển khai một “OSI stack” thực sự, nhưng mọi kỹ sư đều dùng từ vựng của nó hằng ngày (“đây là vấn đề ở Layer 2”, “ta cần một L7 load balancer”).
• TCP/IP model (còn gọi là Internet model) — mô hình thực tế gồm 4 hoặc 5 tầng, mô tả cách Internet thật sự hoạt động. Đây chính là stack đang chạy trong hệ điều hành của bạn ngay lúc này.

Tại sao lại cần phân tầng?

• Separation of concerns (tách bạch trách nhiệm) — Ethernet không cần biết gì về HTTP; TCP không cần biết nó đang chạy trên Wi-Fi hay cáp quang.
• Interoperability (khả năng tương tác) — miễn là hai thiết bị đồng ý về protocol tại một tầng nhất định, các tầng bên dưới có thể hoàn toàn khác nhau.
• Fault isolation (khoanh vùng lỗi) — khi có sự cố, việc phân tầng cho bạn một “chiếc thang” có hệ thống để leo: cáp có kết nối không (L1)? Switch có forward frame không (L2)? Có route được tới đích không (L3)? Port có mở không (L4)? Ứng dụng có phản hồi không (L7)?

Note này chính là bản đồ tư duy mà phần còn lại của roadmap dựa vào. Một khi bạn có thể đặt bất kỳ protocol, thiết bị hay lỗi nào vào đúng tầng của nó, mọi thứ còn lại — core protocols, network devices, và IP addressing & subnetting — sẽ tự khớp vào chỗ.

Kiến thức nền tảng

Mô hình OSI 7 tầng

Câu ghi nhớ kinh điển (từ trên xuống) là “All People Seem To Need Data Processing” (Application → Physical), hoặc từ dưới lên “Please Do Not Throw Sausage Pizza Away”.

Mỗi tầng trao đổi một PDU (Protocol Data Unit) với tầng ngang hàng (peer) trên host phía xa. Tên của PDU thay đổi khi bạn đi xuống stack — cần nhớ kỹ cách gọi tên này vì kỹ sư dùng nó liên tục.

#	Tầng (Layer)	PDU	Chức năng cốt lõi	Ví dụ protocol / chuẩn	Ví dụ thiết bị	Lỗi thường gặp
7	Application	Data	Giao diện tới ứng dụng người dùng; định nghĩa ngữ nghĩa của việc trao đổi	HTTP, HTTPS, DNS, SMTP, FTP, SSH, gRPC	Firewall (L7/WAF), API gateway, proxy	Lỗi 404/500, bad request, cert hết hạn, sai Host header
6	Presentation	Data	Chuyển đổi, encoding, serialization, mã hóa, nén	TLS/SSL, JPEG, ASCII/UTF-8, JSON/Protobuf, gzip	(thường là thư viện phần mềm)	Sai encoding, TLS handshake thất bại, hỏng charset
5	Session	Data	Thiết lập, quản lý, đóng session/dialog giữa các ứng dụng	NetBIOS, RPC, SOCKS, (TLS session resumption)	(phần mềm)	Session timeout, session half-open, auth token hết hạn
4	Transport	Segment (TCP) / Datagram (UDP)	Giao nhận end-to-end, ports/multiplexing, độ tin cậy, flow & congestion control	TCP, UDP, QUIC (trên UDP), SCTP	L4 load balancer, stateful firewall, NAT	Port đóng/bị filter, connection refused/reset, retransmit, vấn đề MTU/MSS
3	Network	Packet	Địa chỉ logic và routing giữa các mạng	IP (IPv4/IPv6), ICMP, IPsec, OSPF, BGP	Router, L3 switch, firewall	No route to host, TTL exceeded, sai subnet/gateway, routing loop
2	Data Link	Frame	Giao nhận node-to-node trên cùng một link; địa chỉ MAC; phát hiện lỗi	Ethernet, Wi-Fi (802.11), PPP, ARP, VLAN (802.1Q), STP	Switch, bridge, NIC, wireless AP	MAC flapping, sai VLAN, duplex mismatch, lỗi CRC, STP loop
1	Physical	Bit (symbol)	Truyền các bit thô qua môi trường; điện áp, ánh sáng, sóng radio, sơ đồ chân	Ethernet PHY, RJ45, fiber, DSL, USB, Bluetooth radio	Cáp, hub, repeater, transceiver, modem	Đứt cáp, không có link light, hỏng SFP, nhiễu EMI, sai pinout, port down

Một cách nhớ tiện: các tầng 1–4 là các tầng “thấp”/hạ tầng (đưa các bit tới đúng port trên đúng host một cách tin cậy), còn các tầng 5–7 là các tầng “cao”/ứng dụng (làm cho dữ liệu có ý nghĩa với phần mềm). Network engineer chủ yếu sống ở L1–L4; developer chủ yếu sống ở L5–L7.

Lưu ý về các tầng “phụ”. Trong thực tế, các tầng 5, 6 và 7 khá mờ nhòe — cùng một protocol (ví dụ HTTPS) trải cả presentation (TLS) lẫn application (HTTP) cùng lúc. Đây là một lý do khiến mô hình TCP/IP gộp chúng lại.

Mô hình TCP/IP và cách nó ánh xạ sang OSI

Mô hình TCP/IP là thứ Internet thật sự triển khai (các tầng của nó được định nghĩa trong RFC 1122). Nó có hai cách mô tả phổ biến — bản 4 tầng và bản 5 tầng (tách tầng dưới cùng ra, khớp với OSI hơn). Cả hai đều đúng; bản 5 tầng dễ dạy hơn vì nó tách phần cáp (Physical) khỏi phần đóng frame (Data Link).

TCP/IP (4 tầng)	TCP/IP (5 tầng)	Tương đương OSI	Ví dụ protocol
Application	Application	7 + 6 + 5 (App, Presentation, Session)	HTTP, DNS, TLS, SSH, SMTP
Transport	Transport	4 (Transport)	TCP, UDP, QUIC
Internet	Internet (Network)	3 (Network)	IP, ICMP, IPsec
Link / Network Access	Data Link	2 (Data Link)	Ethernet, ARP, Wi-Fi
	Physical	1 (Physical)	Cáp, radio, fiber

Vì sao stack thực tế là TCP/IP chứ không phải OSI:

• Nó đã được triển khai, và đã thắng. TCP/IP được cài đặt, deploy và cải tiến trên ARPANET/Internet trong khi OSI vẫn còn là một đặc tả trên bàn hội đồng. Code chạy được đã đánh bại một mô hình hoàn hảo.
• Nó thực dụng. Các mối quan tâm về session và presentation không cần một tầng mạng riêng — chúng được xử lý bởi các thư viện ở tầng application (một thư viện TLS, một bộ serialize JSON), nên gộp chúng lại đơn giản hơn.
• “Eo thắt hẹp” (narrow waist). Cái hay của TCP/IP là IP đóng vai một Layer 3 tối giản, phổ quát: bất kỳ công nghệ link nào bên dưới (Ethernet, Wi-Fi, 5G, vệ tinh) và bất kỳ ứng dụng nào bên trên (web, email, video) đều tương tác được miễn là chúng nói IP ở giữa. Hình dạng “đồng hồ cát” này là lý do Internet mở rộng quy mô được.

Vậy: dùng OSI để có từ vựng và để troubleshoot; hiểu rằng các bit trên dây tuân theo mô hình TCP/IP.

Encapsulation và decapsulation

Dữ liệu không “dịch chuyển tức thời” xuống stack — mỗi tầng bọc (wrap) PDU từ tầng trên bằng header của riêng nó (và đôi khi cả trailer), thêm vào thông tin điều khiển mà tầng ngang hàng cần. Việc bọc này là encapsulation khi đi xuống (gửi), và decapsulation — gỡ từng header — khi đi lên (nhận). Đây là khái niệm cơ học quan trọng nhất trong networking.

Gửi (trên → dưới, encapsulation):

Application:  [ Data ]                                        (ví dụ một HTTP request)
Transport:   [ TCP hdr | Data ]                    → SEGMENT  (thêm src/dst port, seq#, flags)
Network:     [ IP hdr | TCP hdr | Data ]           → PACKET   (thêm địa chỉ IP src/dst, TTL)
Data Link:   [ Eth hdr | IP hdr | TCP hdr | Data | Eth trailer ] → FRAME (thêm MAC src/dst, FCS/CRC)
Physical:    0101110010101110...                    → BITS     (mã hóa thành tín hiệu điện/quang/radio)

• Tầng Transport cắt dữ liệu ứng dụng thành các mảnh vừa với mạng (theo MSS, Maximum Segment Size) và thêm header TCP hoặc UDP → segment (TCP) / datagram (UDP).
• Tầng Network thêm IP header (địa chỉ IP nguồn và đích, TTL, protocol number) → packet (còn gọi là IP datagram).
• Tầng Data Link thêm header (địa chỉ MAC nguồn/đích) và trailer (checksum FCS/CRC để phát hiện lỗi) → frame.
• Tầng Physical chuyển các byte của frame thành bits — tín hiệu thật trên dây đồng, cáp quang, hoặc không khí.

Nhận (dưới → trên, decapsulation): ngược lại y hệt. NIC biến tín hiệu về lại thành frame, kiểm tra FCS, gỡ Ethernet header/trailer → đẩy packet lên. Tầng IP kiểm tra IP đích và gỡ IP header → đẩy segment lên. TCP kiểm tra port, ráp lại/sắp xếp lại, gỡ header của nó → giao dữ liệu cho ứng dụng đang lắng nghe trên port đó.

Những mô hình tư duy quan trọng mà điều này mở ra:

• Mỗi tầng chỉ đọc header của chính nó. Một switch (L2) đọc Ethernet header và bỏ qua IP payload; một router (L3) đọc IP header và ghi lại Ethernet header cho hop kế tiếp; một firewall có thể được xây để soi bất kỳ tầng nào bạn muốn.
• Địa chỉ MAC đổi ở mỗi hop; địa chỉ IP (thường) thì không. Khi một packet đi qua các router, frame L2 bị gỡ và dựng lại cho từng link (MAC nguồn/đích mới), trong khi địa chỉ IP L3 giữ nguyên end-to-end. Đây là cái insight kinh điển hay hỏi khi phỏng vấn.
• Overhead là có thật. Header của mỗi tầng ăn vào payload. Đây là lý do MTU (kích thước frame tối đa, kinh điển là 1500 byte với Ethernet) và MSS quan trọng, và vì sao các vấn đề fragmentation hay PMTUD gây ra những bug khó hiểu kiểu “request lớn thì bị treo”.

Nhìn kỹ tầng Transport: TCP vs UDP

Layer 4 là nơi “các mạng” trở thành “các kết nối giữa các chương trình”. Có hai protocol thống trị.

TCP (Transmission Control Protocol) — connection-oriented, tin cậy, có thứ tự, dạng byte-stream.

• 3-way handshake để thiết lập kết nối:
  1. Client → Server: SYN (seq = x) — “mình muốn nói chuyện, sequence number khởi đầu của mình là x”
  2. Server → Client: SYN, ACK (seq = y, ack = x+1) — “ok, của mình là y; mình đã nhận được của bạn”
  3. Client → Server: ACK (ack = y+1) — “nhận rồi, ta đã kết nối” Sau bước này, cả hai phía đã thống nhất sequence number và kết nối ở trạng thái ESTABLISHED.
• Reliability (độ tin cậy) — mỗi byte đều được đánh số thứ tự; bên nhận ACK những gì đã nhận; dữ liệu chưa được ACK sẽ được retransmit (truyền lại) sau timeout (RTO) hoặc khi có duplicate ACK (fast retransmit).
• Ordering (thứ tự) — các segment mang sequence number, nên nếu tới không đúng thứ tự vẫn được ráp lại đúng trước khi giao cho app.
• Flow control — cơ chế sliding window (window size được quảng bá) cho phép bên nhận nói với bên gửi “tôi chỉ buffer được từng này thôi”, tránh việc bên gửi nhanh làm ngợp bên nhận chậm.
• Congestion control — các thuật toán (slow start, congestion avoidance, ví dụ CUBIC/Reno/BBR) điều tiết bên gửi dựa trên mức độ nghẽn của mạng (mất gói / độ trễ), bảo vệ Internet khỏi sụp đổ.
• Teardown (đóng kết nối) — đóng “lịch sự” dùng FIN / FIN, ACK ở mỗi chiều (trao đổi 4 bước). Ngắt đột ngột dùng RST (reset) — “kết nối này mất rồi, đừng nói nữa”. Một RST trong bản capture gần như luôn báo hiệu vấn đề: port đóng, firewall drop, app crash, hoặc timeout.

UDP (User Datagram Protocol) — connectionless, không tin cậy, dạng message. Chỉ có port nguồn/đích, độ dài, và một checksum. Không handshake, không ACK, không sắp thứ tự, không congestion control. Nó là một lớp bọc mỏng trên IP: “fire and forget” (bắn rồi quên). Nếu cần độ tin cậy, bạn tự xây bên trên (đó chính xác là điều QUIC làm trên UDP).

Thuộc tính	TCP	UDP
Kết nối	Connection-oriented (có handshake)	Connectionless
Độ tin cậy	Đảm bảo giao nhận (ACK + retransmit)	Best-effort, không đảm bảo
Thứ tự	Giao đúng thứ tự	Không sắp thứ tự
Flow / congestion control	Có	Không
Kích thước header	20+ byte	8 byte
Tốc độ / độ trễ	Độ trễ cao hơn (setup + ACK)	Độ trễ thấp hơn, ít overhead
Tên PDU	Segment	Datagram
Broadcast/multicast	Không	Có
Dùng điển hình	HTTP(S), SSH, SMTP, kết nối DB, truyền file	DNS, DHCP, VoIP, video streaming, game, QUIC/HTTP-3

Nguyên tắc chung: dùng TCP khi độ chính xác quan trọng hơn tốc độ (tải một trang web, truyền một file, một truy vấn database — mất một byte là không chấp nhận được). Dùng UDP khi tính kịp thời quan trọng hơn sự hoàn hảo và bạn có thể chịu/tự xử lý việc mất gói (một gói thoại bị rớt còn hơn là bị trễ; một bản cập nhật trạng thái game bị rớt sẽ được bản kế tiếp thay thế). Lưu ý web hiện đại đang chuyển sang QUIC/HTTP-3, chạy các stream tin cậy, có thứ tự trên UDP để có được đảm bảo của TCP mà không bị head-of-line blocking và handshake chậm.

Khái niệm chính

Nói chuyện theo tầng: “L2 vs L3”, “L4 vs L7”

Lợi ích thực tế lớn nhất của các mô hình này là một bộ từ vựng chung để mô tả một thiết bị hay một quyết định vận hành ở đâu.

Thiết bị L2 vs L3 (xem network devices):

• Một switch về bản chất là thiết bị L2 — nó forward frame dựa trên địa chỉ MAC, trong một broadcast domain / LAN duy nhất. Nó không biết và không quan tâm tới IP.
• Một router là thiết bị L3 — nó forward packet giữa các mạng khác nhau dựa trên địa chỉ IP và một routing table.
• Một “Layer 3 switch” là switch có tích hợp sẵn phần cứng routing — nó làm được cả hai (switching L2 nhanh trong các VLAN và routing L3 giữa chúng).

Middlebox L4 vs L7 — sự phân biệt này thống trị hạ tầng hiện đại:

	L4 (Transport) load balancer / firewall	L7 (Application) load balancer / firewall
Nhìn thấy	Địa chỉ IP + port TCP/UDP	Toàn bộ dữ liệu ứng dụng (URL, header, cookie, HTTP method)
Ra quyết định dựa trên	5-tuple (src/dst IP, src/dst port, protocol)	Hostname, path, header, cookie, nội dung request
Ví dụ	AWS NLB, HAProxy ở chế độ TCP, iptables, IPVS	AWS ALB, Nginx/Envoy, API gateway, WAF
Chi phí	Nhanh, rẻ, không phụ thuộc protocol	Tốn CPU hơn (phải parse & thường phải terminate TLS)
Có thể làm	Route “toàn bộ traffic trên :443 tới pool này"	"Route /api/* chỗ này, /images/* chỗ kia; chặn mẫu SQL-injection”

Một firewall L4 quyết định “cho phép/từ chối dựa trên IP + port” (stateful firewall kinh điển). Một firewall L7 / WAF hiểu protocol ứng dụng và có thể chặn, ví dụ, một HTTP request độc hại dù port đang mở hợp lệ.

Khoanh vùng lỗi theo tầng (chiếc thang troubleshooting)

Vì stack được phân tầng, cách debug chuyên nghiệp là cô lập tầng đang hỏng từ dưới lên (hoặc dùng chia-để-trị). Một checklist kinh điển:

Tầng	Câu hỏi	Công cụ / bằng chứng
L1 Physical	Có link không? Cáp/SFP có tốt không?	Link LED, ethtool, interface counters (CRC/error), đổi cáp
L2 Data Link	Đúng VLAN chưa? MAC đã học chưa? ARP có phân giải không?	arp -a, MAC table của switch, ip neigh, kiểm tra VLAN tag
L3 Network	Có tới được IP không? Route/gateway đúng chưa?	ping, traceroute/tracert, ip route, kiểm tra subnet mask
L4 Transport	Port có mở/listening/tới được không?	telnet host port, nc -zv, ss -tlnp, tìm RST/SYN retransmit
L5–L7 App	App có trả lời đúng không? TLS ổn không?	curl -v, openssl s_client, log app, HTTP status code

Kỷ luật ở đây: đừng debug app (L7) khi cáp đang bị rút (L1). Câu đùa “It’s always DNS” tồn tại chính vì kỹ sư hay nhảy cóc qua các tầng. ping chạy nhưng curl lỗi → L3 ổn, hãy nhìn L4/L7. ping bằng IP mà không tới nhưng interface đang up → nhìn L2/L3 (routing, ARP, gateway).

Các tầng cao trong thực tế: session, presentation, application

Trong thế giới TCP/IP, ba tầng OSI này bị gộp thành “Application”, nhưng các mối quan tâm thì vẫn có thật và đáng gọi tên:

• Session (L5) — theo dõi một cuộc hội thoại logic kéo dài hơn một request đơn lẻ. Trong thực tế: session web (một session cookie / JWT gắn nhiều HTTP request stateless vào một người dùng đã đăng nhập), TLS session resumption (tránh handshake đầy đủ khi kết nối lại), session kết nối database, và các kênh RPC. Lỗi thường thấy: “tôi bị đăng xuất”, “token hết hạn”, “kết nối rớt giữa chừng”.
• Presentation (L6) — cách dữ liệu được biểu diễn để cả hai phía đồng ý về ý nghĩa của nó: character encoding (UTF-8 vs Latin-1 → bug mojibake), serialization (JSON, Protobuf, XML, MessagePack), compression (gzip, Brotli), và quan trọng nhất là encryption: TLS là dịch vụ tầng presentation kinh điển, biến một byte stream plaintext thành một luồng được xác thực và mã hóa. TLS handshake (thương lượng cipher suite, trao đổi certificate) là mối quan tâm tầng presentation, đặt trên một kết nối TCP (transport).
• Application (L7) — protocol mà phần mềm thật sự nói: HTTP/HTTPS cho web và API, DNS cho phân giải tên, SMTP/IMAP cho email, SSH cho remote shell, gRPC cho giao tiếp service-to-service. Đây là nơi “request” và “response” mà developer suy luận thật sự sống. Đào sâu về những cái này thuộc về core protocols.

Một ví dụ cụ thể gắn kết mọi thứ lại — tải https://example.com:

1. DNS (L7, trên UDP/L4) phân giải example.com → một IP.
2. TCP (L4) 3-way handshake tới IP của server trên port 443.
3. TLS (L6) handshake thương lượng mã hóa và xác thực certificate.
4. HTTP (L7) request/response chảy bên trong đường hầm TLS đã mã hóa.
5. Bên dưới tất cả, mọi byte đã được encapsulate thành TCP segment → IP packet → Ethernet/Wi-Fi frame → bits, được các router (L3) định tuyến từng hop và các switch (L2) chuyển mạch từng link.

Chỉ một URL đó đã vận dụng toàn bộ stack — và đó chính xác là lý do mô hình phân tầng là nền tảng mà mọi thứ khác xây lên trên.

Best Practices

• Học OSI để có từ vựng, học TCP/IP để hiểu thực tế. Khi troubleshoot hay phỏng vấn, hãy gọi tên tầng một cách rõ ràng (“đây là vấn đề L2”) — điều đó buộc bạn phải chính xác và giúp giao tiếp nhanh hơn.
• Debug từ dưới lên (hoặc chia-để-trị), đừng đoán mò. Xác nhận L1/L2 trước khi đổ lỗi cho app. Dùng chiếc thang troubleshooting ở trên để không bao giờ nhảy cóc qua một tầng.
• Nhớ tên các PDU và cái gì thay đổi ở mỗi hop. “Segment → packet → frame → bits”, và “MAC đổi mỗi hop, IP giữ nguyên end-to-end” là hai sự thật mở khóa hầu hết câu hỏi về encapsulation.
• Chọn đúng transport cho việc cần làm. Mặc định dùng TCP cho các luồng cần độ chính xác; chọn UDP (hoặc QUIC) cho traffic nhạy về độ trễ, chịu được mất gói, hoặc fanout cao (broadcast/multicast) — và đừng tự phát minh lại reliability trên UDP trừ khi thật sự cần.
• Chọn middlebox L4 vs L7 một cách có chủ đích. Dùng LB/firewall L4 cho throughput thô và routing không phụ thuộc protocol; dùng L7 (ALB, Nginx, Envoy, WAF) khi cần routing theo nội dung, terminate TLS, hoặc bảo mật hiểu-ứng-dụng — và chấp nhận cái giá về CPU.
• Để ý MTU/MSS. Overhead của encapsulation và MTU không khớp (VPN, tunnel, jumbo frame) gây fragmentation và bug PMTUD black-hole; hãy clamp MSS trên tunnel và giữ path MTU nhất quán.
• Terminate và soi ở đúng tầng. Đừng bắt một thiết bị L4 làm content filtering, và đừng đốt CPU L7 cho traffic mà chỉ cần forward ở L4.
• Capture traffic để nhìn thấy các tầng. tcpdump/Wireshark cho bạn thấy từng header (Ethernet → IP → TCP → payload) một cách trực quan. Đọc một bản capture là cách nhanh nhất để thấm khái niệm encapsulation và để phát hiện vấn đề RST/retransmit/handshake.

Tài liệu tham khảo

• OSI Model — Cloudflare Learning Center
• What is the OSI Model? — Cisco
• RFC 1122 — Requirements for Internet Hosts (Communication Layers)
• RFC 9293 — Transmission Control Protocol (TCP)
• RFC 768 — User Datagram Protocol (UDP)
• TCP vs UDP — Cloudflare Learning Center
• What is the Internet Protocol (IP)? — Cloudflare
• TCP/IP Model — MDN / IBM overview

Application:  [ Data ]                                        (e.g. an HTTP request)
Transport:   [ TCP hdr | Data ]                    → SEGMENT  (adds src/dst ports, seq#, flags)
Network:     [ IP hdr | TCP hdr | Data ]           → PACKET   (adds src/dst IP addresses, TTL)
Data Link:   [ Eth hdr | IP hdr | TCP hdr | Data | Eth trailer ] → FRAME (adds src/dst MAC, FCS/CRC)
Physical:    0101110010101110...                    → BITS     (encoded as electrical/optical/radio signals)