Skip to main content

OSI Model & Packet Encapsulation

Mục lục​

1. Mô hình OSI 7 lớp — tổng quan​

Giả sử bạn gửi một request HTTPS từ trình duyệt tới một web server. Ở tầng ứng dụng, bạn chỉ đơn giản gõ một địa chỉ rồi nhấn Enter. Nhưng trước khi byte đầu tiên chạm tới dây cáp mạng, dữ liệu đó đã bị "đóng gói" qua ít nhất bốn lớp xử lý khác nhau, mỗi lớp thêm vào một phần thông tin riêng mà lớp trước hoàn toàn không biết tới. Mô hình OSI (Open Systems Interconnection) là cách chuẩn hóa để mô tả chính xác từng lớp xử lý đó, gồm 7 tầng xếp chồng lên nhau.

💡 Hình dung như thế này: một nhà máy đóng gói hàng xuất khẩu có dây chuyền 7 trạm nối tiếp nhau. Trạm 1 đóng gói sản phẩm vào hộp nhỏ, trạm 2 dán nhãn ngôn ngữ, trạm 3 gộp nhiều hộp vào một thùng carton, trạm 4 dán mã vận đơn... Mỗi trạm chỉ biết đúng một việc của mình — trạm dán mã vận đơn không cần biết bên trong thùng carton có sản phẩm gì. OSI hoạt động y hệt vậy: mỗi layer chỉ quan tâm đúng nhiệm vụ của layer đó, và hoàn toàn "mù" trước công việc của các layer khác.

Bảy lớp đó, đi từ trên (gần người dùng nhất) xuống dưới (gần dây cáp vật lý nhất):

The OSI 7-Layer ModelLayer 7 — ApplicationHTTP, SMTP, DNS — giao tiếp trực tiếp với appLayer 6 — PresentationMã hoá, nén, định dạng: SSL/TLS, JPEGLayer 5 — SessionThiết lập, duy trì, kết thúc phiên giao tiếpLayer 4 — TransportTCP/UDP — port, độ tin cậy, control flowLayer 3 — NetworkIP — định tuyến, logical addressingLayer 2 — Data LinkMAC address, framing, error detectionLayer 1 — PhysicalBits, cáp, điện áp, tín hiệu vật lýLayer 5-7 xử lý nội dung; Layer 1-4 lo việc vận chuyển nó đi

Ba lớp trên cùng (Application, Presentation, Session) thường được gộp chung là "upper layers" — chúng chỉ quan tâm tới nội dung và ngữ nghĩa của dữ liệu, hoàn toàn không biết gì về việc dữ liệu sẽ được vận chuyển ra sao. Bốn lớp dưới (Transport, Network, Data Link, Physical) mới là nơi thực sự lo việc "đưa dữ liệu từ điểm A tới điểm B" — và cũng chính bốn lớp này sẽ là trọng tâm của toàn bộ tài liệu, vì đây là nơi khái niệm packet, frame, MTU thực sự sống.

Một lưu ý quan trọng: OSI là mô hình tham chiếu (reference model) — trên thực tế, bộ giao thức phổ biến nhất hiện nay là TCP/IP, vốn chỉ có 4 lớp (Application gộp chung layer 5-7, Transport, Internet tương đương Network, Network Access gộp chung layer 1-2). Nhưng giới networking vẫn dùng thuật ngữ theo OSI 7 lớp trong giao tiếp hàng ngày vì nó tách bạch rõ ràng hơn — tài liệu này cũng theo đúng quy ước đó.

2. PDU và Encapsulation — dữ liệu "phình to" qua từng lớp như thế nào?​

Mỗi lớp trong OSI gọi đơn vị dữ liệu của mình bằng một cái tên riêng — gọi chung là PDU (Protocol Data Unit). Việc gọi đúng tên PDU ở đúng lớp là một trong những điều hay bị hỏi nhất khi thi CCNA, vì nó phản ánh chính xác bạn đang "đứng" ở lớp nào khi nói chuyện.

LớpTên PDU
Layer 7-5 (Application/Presentation/Session)Data
Layer 4 (Transport)Segment (nếu dùng TCP) hoặc Datagram (nếu dùng UDP)
Layer 3 (Network)Packet
Layer 2 (Data Link)Frame
Layer 1 (Physical)Bits

💡 Hình dung như thế này: đây chính xác là búp bê Nga (matryoshka) — mỗi lớp bọc thêm một lớp vỏ mới quanh lớp trong, nhưng lớp trong vẫn nguyên vẹn, không hề bị thay đổi hay biến mất. Khi tới nơi, quá trình diễn ra ngược lại: từng lớp vỏ được bóc ra đúng theo thứ tự cho tới khi lộ ra con búp bê gốc.

Cơ chế "bọc thêm lớp vỏ" đó gọi là encapsulation: khi dữ liệu đi từ lớp trên xuống lớp dưới, mỗi lớp thêm một header riêng (và với Data Link, thêm cả một trailer) chứa thông tin mà lớp đó cần để làm đúng việc của nó. Quá trình ngược lại — bóc từng lớp header/trailer ra khi dữ liệu đi từ dưới lên — gọi là de-encapsulation.

PDU qua từng Layer — EncapsulationPDU tại Application/Presentation/SessionDataSegment (TCP) / Datagram (UDP) — Layer 4L4 HeaderDataPacket — Layer 3L3 Header (IP)L4 HeaderDataFrame — Layer 2 (có cả Header lẫn Trailer!)L2 HeaderL3 HeaderL4 HeaderDataFCSChỉ Frame (Layer 2) mới có Trailer (FCS) — các PDU khác chỉ có Header

Nhìn kỹ hàng cuối cùng (Frame) trong sơ đồ trên: đây là PDU duy nhất có cả header lẫn trailer. Trailer đó chính là FCS (Frame Check Sequence) — một giá trị kiểm tra lỗi được tính toán và gắn vào cuối frame, để bên nhận biết frame có bị hỏng dọc đường hay không. Không PDU nào khác (Segment, Packet) có trailer — đây là điểm khác biệt đáng nhớ giữa Data Link layer và các layer còn lại.

3. Cấu trúc một Ethernet Frame​

Ethernet là giao thức Layer 2 phổ biến nhất, và Frame của nó là thứ cuối cùng thực sự "chạy" trên dây cáp trước khi bị chuyển thành bits. Cấu trúc đầy đủ của một Ethernet frame (Ethernet II — kiểu framing phổ biến nhất hiện nay) gồm 7 phần liên tiếp:

Ethernet Frame Structure (Ethernet II)Frame size = 64–1518 bytesPreamble(7B)SFD(1B)Dest MAC(6B)Src MAC(6B)EtherType(2B)Payload (46–1500B)gói IP nằm ở đâyFCS(4B)Preamble + SFD không tính vào frame size — đo từ Dest MAC đến hết FCSPayload < 46B → Ethernet tự động thêm padding cho đủ tối thiểu

Giải thích nhanh từng phần:

  • Preamble (7 byte) + SFD (1 byte) — một chuỗi bit xen kẽ 1-0 giúp bên nhận đồng bộ clock trước khi frame thật sự bắt đầu. SFD (Start Frame Delimiter) là byte cuối cùng báo hiệu "từ byte tiếp theo, Destination MAC bắt đầu". Hai phần này không được tính vào frame size.
  • Destination MAC / Source MAC (6 byte mỗi trường) — địa chỉ vật lý của thiết bị nhận và gửi trên cùng một segment Layer 2. Đây chính là thứ sẽ thay đổi ở mỗi hop router — chi tiết ở Mục 9.
  • EtherType (2 byte) — cho biết payload bên trong là loại giao thức gì (ví dụ 0x0800 cho IPv4, 0x86DD cho IPv6).
  • Payload (46–1500 byte) — chính là gói tin Layer 3 (IP packet) nằm trọn trong đây. Nếu payload nhỏ hơn 46 byte, Ethernet tự động thêm padding cho đủ mức tối thiểu — lý do là để đảm bảo frame đủ dài, tránh bị nhầm với nhiễu tín hiệu trên các mạng Ethernet cũ dùng CSMA/CD (Carrier Sense Multiple Access with Collision Detection — cơ chế các thiết bị cùng "nghe" đường truyền trước khi gửi, và có quy tắc xử lý khi hai bên vô tình gửi trùng lúc gây collision; ngày nay hầu hết mạng chạy full-duplex nên collision gần như không còn xảy ra, nhưng luật padding tối thiểu 46 byte thì vẫn giữ nguyên).
  • FCS — Frame Check Sequence (4 byte) — trailer duy nhất trong toàn bộ các PDU, dùng để kiểm tra lỗi. Bên nhận tính lại checksum của frame vừa nhận, so với giá trị FCS đi kèm; nếu lệch, frame bị coi là hỏng và bị drop ngay lập tức, không có cơ chế sửa lỗi hay yêu cầu gửi lại ở tầng này.

Tổng kết kích thước: frame size tối thiểu là 64 byte, tối đa 1518 byte (tính từ Destination MAC đến hết FCS, không tính Preamble/SFD).

Trong mạng thực tế: 802.1Q VLAN tag làm frame "phình" thêm 4 byte​

Cấu trúc ở trên là frame "trần" — nhưng trong hầu hết mạng doanh nghiệp thực tế, switch/router chia mạng thành nhiều VLAN, và khi một frame đi qua trunk link (liên kết mang nhiều VLAN cùng lúc), nó cần thêm một chỉ dấu "mình thuộc VLAN nào". Chỉ dấu đó là 802.1Q tag — 4 byte được chèn thêm ngay giữa Source MAC và EtherType.

Untagged vs 802.1Q Tagged FrameUntagged (max 1518B)Dest MACSrc MACEtherTypePayloadFCS802.1Q Tagged (max 1522B)Dest MACSrc MAC802.1Q(4B, mới)EtherTypePayloadFCS802.1Q chèn giữa Src MAC và EtherType → frame max tăng từ 1518B lên 1522B

Bên trong 4 byte đó gồm: TPID (Tag Protocol Identifier, 2 byte, luôn là 0x8100) — giá trị đặc biệt để phân biệt "đây là frame có tag" với frame thường; và TCI (Tag Control Information, 2 byte) chứa ba trường nhỏ hơn: PCP (3 bit, mức ưu tiên 802.1p, dùng cho CoS — 0 thấp nhất, 7 cao nhất), DEI (1 bit, cờ cho phép rớt gói khi nghẽn), và VLAN ID (12 bit, giá trị từ 0–4095, chính là con số VLAN quen thuộc khi cấu hình switch). Vì TPID chiếm đúng vị trí mà EtherType từng đứng ở frame thường, thiết bị nhận biết ngay "nếu 2 byte đầu tiên sau Src MAC là 0x8100, đây là frame có tag — phải đọc thêm 2 byte TCI trước khi tới EtherType thật".

4. Cấu trúc IPv4 Header​

Bên trong phần Payload của Ethernet frame vừa thấy ở Mục 3 chính là một IP packet — và IP packet luôn bắt đầu bằng một header cố định tối thiểu 20 byte (có thể lên tới 60 byte nếu dùng thêm Options).

IPv4 Header — 20 byte cố định + OptionsVer / IHLType of Service (DSCP)Total Length(16 bit — header + payload)IdentificationFlagsFragment OffsetTTLProtocolHeader ChecksumSource IP Address (32 bit)Destination IP Address (32 bit)TTL giảm 1 mỗi khi qua 1 router — về 0 thì gói bị drop (xem Mục 9)Identification/Flags/Fragment Offset (vàng) — phục vụ fragmentation, xem Mục 6

Các trường quan trọng nhất, theo đúng thứ tự bạn sẽ gặp khi đọc packet capture:

  • Version / IHL — Version luôn là 4 với IPv4; IHL (Internet Header Length) cho biết header dài bao nhiêu, tính theo đơn vị 32-bit word (giá trị tối thiểu 5, tức 20 byte).
  • Total Length — tổng độ dài cả header lẫn payload, tính bằng byte. Đây là trường quyết định "gói tin IP này lớn bao nhiêu" — sẽ liên quan trực tiếp tới MTU ở Mục 6.
  • Identification, Flags, Fragment Offset — bộ ba trường này chỉ có một nhiệm vụ duy nhất: phục vụ việc phân mảnh (fragmentation) khi gói tin quá lớn so với MTU của một chặng nào đó trên đường đi. Identification giúp bên nhận biết các fragment nào thuộc cùng một gói gốc; Fragment Offset cho biết fragment đó nằm ở vị trí nào trong gói gốc.
  • TTL (Time To Live) — một con số đếm ngược, giảm đi 1 mỗi khi gói tin đi qua một router. Khi TTL về 0, gói bị drop và router gửi lại một thông báo ICMP Time Exceeded cho nguồn — đây chính là cơ chế traceroute dựa vào để dò từng hop trên đường đi.
  • Protocol — cho biết payload bên trong gói IP là giao thức Layer 4 nào (6 = TCP, 17 = UDP...).
  • Header Checksum — chỉ kiểm tra lỗi của riêng phần header (không phải payload), và được tính lại ở mỗi router vì TTL vừa bị thay đổi.
  • Source / Destination IP Address — hai trường 32-bit cuối cùng, chính là địa chỉ IP thật của người gửi và người nhận — và khác hẳn với MAC address ở Mục 3, hai địa chỉ này không đổi trong suốt hành trình của gói tin (trừ khi có NAT — Network Address Translation, kỹ thuật đổi địa chỉ IP nguồn/đích khi gói tin đi qua một thiết bị biên, thường dùng để nhiều máy trong mạng nội bộ cùng dùng chung một IP public — can thiệp).

Mở rộng: IPv6 header khác IPv4 ở đâu?​

CCNA 200-301 yêu cầu biết cả hai, nên đáng để so sánh nhanh. IPv6 header cố định đúng 40 byte, không có Options (mọi tính năng mở rộng chuyển qua cơ chế Extension Header riêng, xếp nối tiếp sau header chính thay vì nhồi vào cùng một header như IPv4) — đổi lại IPv6 bỏ hẳn ba thứ mà IPv4 có: không còn Header Checksum (lớp Data Link và Transport đã tự kiểm tra lỗi riêng, nên việc router phải tính lại checksum ở mỗi hop bị coi là dư thừa và tốn CPU), không còn field fragmentation trong header chính (IPv6 quy định chỉ nguồn mới được fragment, dùng Extension Header riêng cho việc đó — router giữa đường không được phép tự ý fragment như IPv4), và trường TTL được đổi tên thành Hop Limit nhưng hoạt động giống hệt — giảm 1 mỗi hop, về 0 thì drop. Tóm lại: IPv6 đánh đổi việc bỏ bớt vài field "ít dùng" của IPv4 để đổi lấy một header đơn giản, cố định, xử lý nhanh hơn ở tốc độ đường truyền cao.

5. Cấu trúc TCP Header​

Ở Mục 6 sắp tới, bạn sẽ thấy nhắc tới MSS — một con số được tính từ chính TCP header. Trước khi qua đó, cần mổ xẻ header này giống hệt cách đã làm với IPv4 ở Mục 4, vì TCP header cũng có kích thước tối thiểu 20 byte, xếp ngay sau IP header, bên trong phần Payload của IP packet.

TCP Header — 20 byte cố định + Options (RFC 9293)Source Port (16 bit)Destination Port (16 bit)Sequence Number (32 bit)Acknowledgment Number (32 bit)OffsetRsvdFlags:URG ACK PSH RST SYN FINWindow Size (16 bit)Checksum (16 bit)Urgent Pointer (16 bit)Options (variable, tối đa 40 byte — chỉ có nếu Data Offset > 5)Cùng 20 byte tối thiểu như IPv4 Header (Mục 4) — cả hai đều mở rộng được bằng Options

Các trường đáng chú ý nhất:

  • Source Port / Destination Port — xác định đúng ứng dụng nào ở mỗi đầu đang nói chuyện (ví dụ port 443 cho HTTPS). Đây là thứ giúp một máy chủ phục vụ được hàng nghìn kết nối cùng lúc mà không nhầm lẫn dữ liệu của ai với ai.
  • Sequence Number / Acknowledgment Number — hai bộ đếm dùng để theo dõi đúng thứ tự byte đã gửi/đã nhận, cho phép TCP phát hiện mất gói và yêu cầu gửi lại đúng phần bị thiếu — đây chính là phần "độ tin cậy" đã nhắc sơ qua ở Mục 1.
  • Data Offset — tương tự IHL của IPv4, cho biết header TCP dài bao nhiêu (tính theo 32-bit word) để biết Options kết thúc ở đâu và data thật bắt đầu từ đâu.
  • Flags — các bit điều khiển trạng thái kết nối: SYN (đề nghị mở kết nối), ACK (xác nhận đã nhận), FIN (đề nghị đóng kết nối), RST (buộc hủy kết nối ngay vì lỗi), PSH (đẩy dữ liệu lên ứng dụng ngay, không chờ buffer đầy), URG (đánh dấu có dữ liệu khẩn). Bộ ba SYN → SYN/ACK → ACK chính là three-way handshake mở đầu mọi kết nối TCP.
  • Window Size — bên nhận dùng trường này để báo cho bên gửi biết "tôi còn bao nhiêu chỗ trống trong buffer", giúp bên gửi tự điều chỉnh tốc độ gửi (flow control) thay vì gửi tràn làm bên nhận quá tải.
  • Checksum — kiểm tra lỗi cho toàn bộ segment TCP (khác IPv4 Header Checksum ở Mục 4 chỉ kiểm tra phần header).
  • Options — trường mở rộng tùy chọn, và đây chính xác là nơi giá trị MSS được hai bên trao đổi với nhau ngay trong gói SYN/SYN-ACK của three-way handshake — chi tiết ở Mục 6.

6. MTU nằm ở lớp nào? MTU vs MSS và Fragmentation​

Đây là câu hỏi khiến nhiều người mới học nhầm lẫn nhất: MTU (Maximum Transmission Unit) là một khái niệm của Layer 2 — nó mô tả kích thước frame lớn nhất mà một liên kết vật lý/giao thức Data Link cụ thể cho phép gửi đi trong một lần truyền. Giá trị phổ biến nhất trên Ethernet là 1500 byte, nhưng con số này áp cho phần payload của frame (theo đúng ô "Payload" đã thấy ở Mục 3) — tức cũng chính là kích thước tối đa của gói IP nằm bên trong nó.

💡 Hình dung như thế này: MTU giống như kích thước cố định của một chiếc thùng carton chuyển hàng — thùng chỉ có đúng một size, không co giãn được. IP packet là món hàng phải nhét vừa trong thùng đó. Còn MSS là quy tắc mà người đóng hàng (TCP) tự đặt ra cho chính mình: "tôi sẽ không bao giờ cắt một món hàng lớn hơn kích thước sẽ vừa khít thùng, kể cả sau khi đã cộng thêm hộp nhỏ (header) bên trong".

MTU vs MSS — Ai giới hạn ai?Layer 2:Ethernet Frame Payload — MTU = 1500 bytesLayer 3:IP Hdr (20B)IP Packet PayloadLayer 4:TCP Hdr (20B)Application Data — giới hạn bởi MSSMSS = MTU − 20 (IP header) − 20 (TCP header) → mặc định thường 1460 bytesTCP thương lượng MSS lúc bắt tay 3 bước — mục tiêu: không bao giờ vượt MTU của Layer 2

Từ hình trên, thấy rõ ba khái niệm lồng vào nhau:

  • MTU (Layer 2) — trần trên cùng, do đường truyền vật lý quyết định. Ethernet mặc định 1500 byte, nhưng một số mạng hỗ trợ Jumbo Frame lên tới 9000 byte.
  • IP packet (Layer 3) — phải nằm gọn trong đúng phần Payload mà MTU cho phép. Nếu không, gói tin buộc phải fragment (dùng đúng ba trường Identification/Flags/Fragment Offset đã nói ở Mục 4) — hoặc bị drop nếu bit DF (Don't Fragment) được bật.
  • MSS (Maximum Segment Size, Layer 4) — con số mà TCP tự tính để đảm bảo, sau khi cộng thêm IP header (20 byte, Mục 4) và TCP header (20 byte, Mục 5) của chính nó, tổng kích thước không bao giờ vượt quá MTU. Với MTU 1500 byte, MSS mặc định phổ biến là 1460 byte. Hai bên trao đổi giá trị MSS ngay trong trường Options của gói SYN/SYN-ACK (chính là Options đã nói ở Mục 5), và sẽ dùng giá trị nhỏ hơn trong hai giá trị được đề xuất.

Nói ngắn gọn: MTU là giới hạn cứng do Layer 2 áp đặt, còn MSS là cách Layer 4 tự "né" giới hạn đó ngay từ đầu — thay vì để IP phải fragment giữa chừng (vốn tốn tài nguyên và có thể bị nhiều thiết bị hiện đại chặn vì lý do bảo mật), TCP chủ động cắt dữ liệu vừa đủ nhỏ ngay từ nguồn.

MTU khi xếp chồng nhiều lớp encapsulation​

Sơ đồ trên chỉ mới có đúng hai header (IP + TCP) nằm trong ngân sách 1500 byte. Nhưng thực tế mạng doanh nghiệp thường xếp chồng thêm nhiều giao thức khác — GRE, VXLAN, MPLS label, IPsec — mỗi thứ lại đòi thêm chỗ. Vậy phần ngân sách đó lấy từ đâu ra?

Câu trả lời: 1500 byte của Payload là một con số cố định, không tự co giãn. Header nào chen thêm vào giữa Ethernet header và dữ liệu gốc đều phải chia sẻ chung đúng ngân sách đó — phần còn lại dành cho dữ liệu thật sẽ co hẹp lại đúng bằng số byte mà header mới chiếm dụng.

MTU khi xếp chồng nhiều lớp encapsulationKhông tunnel — Data ≈ 1460BIP Hdr 20BTCP Hdr 20BApplication Data ≈ 1460BCó GRE tunnel — cùng 1 ngân sách 1500B, Data co lại còn ≈ 1436BOuter IP 20BGRE 4BInner IP 20BTCP Hdr 20BApplication Data ≈ 1436B802.1Q VLAN tag là ngoại lệ — cộng THÊM ngoài ngân sách (frame max 1518→1522B)GRE/VXLAN/MPLS/IPsec thì ngược lại — luôn ĂN VÀO bên trong ngân sách 1500B có sẵn

Hai nhóm hành xử hoàn toàn khác nhau:

  • 802.1Q VLAN tag (Mục 3) — đây là ngoại lệ duy nhất được cộng thêm ngoài ngân sách Payload: IEEE 802.1Q cho phép frame max tăng từ 1518 lên 1522 byte, vì tag này nằm ở phần header của frame (giữa Src MAC và EtherType), không nằm trong chính phần Payload.
  • GRE, VXLAN, MPLS label, IPsec (ESP/AH) — những cái này không được đặc cách như vậy. Chúng nằm bên trong Payload (như đã thấy với GRE ở tài liệu "GRE Tunnel trên Junos"), nên toàn bộ outer header + IP gốc + TCP + dữ liệu phải nhét vừa trong đúng 1500 byte sẵn có — phần dành cho dữ liệu thật bị thu hẹp đúng bằng số byte mà tunnel header chiếm dụng.

Hệ quả thực tế khi xếp chồng nhiều lớp (ví dụ GRE + IPsec chạy cùng lúc): tổng overhead cộng dồn từ tất cả các lớp có thể ăn mòn ngân sách 1500 byte khá nhiều. Ba cách xử lý phổ biến:

  1. Tính tổng overhead của toàn bộ chồng giao thức, trừ khỏi MTU vật lý gốc để ra "effective MTU" thật sự dành cho traffic gốc.
  2. MSS clamping — chủ động ép giá trị MSS nhỏ hơn ngay tại thiết bị biên (thường là router/firewall đầu tunnel), để TCP tự cắt dữ liệu nhỏ hơn ngay từ đầu thay vì để IP phải fragment giữa đường.
  3. Path MTU Discovery (PMTUD) — để các thiết bị dọc đường tự báo hiệu MTU nhỏ nhất khả dụng, giúp nguồn gửi tự điều chỉnh kích thước gói mà không cần cấu hình tay từng chặng.

7. ARP — Làm sao biết được Destination MAC?​

Toàn bộ Mục 3 nói về Destination MAC như một trường có sẵn trong frame — nhưng làm sao một máy tính biết được giá trị của trường đó trước khi gửi gói đầu tiên? Đây chính là việc của ARP (Address Resolution Protocol), chuẩn hóa tại RFC 826: dịch một địa chỉ IP (Layer 3) sang đúng địa chỉ MAC (Layer 2) tương ứng trên cùng một segment mạng.

💡 Hình dung như thế này: bạn tới một tòa nhà văn phòng để giao hàng, chỉ biết tên công ty (địa chỉ IP) chứ không biết số phòng (địa chỉ MAC). Bạn hét to giữa sảnh: "Ai là công ty ABC?" (broadcast) — mọi công ty trong tòa nhà đều nghe thấy, nhưng chỉ đúng công ty ABC lên tiếng trả lời riêng với bạn: "Tôi ở phòng 305" (unicast reply). Từ đó về sau, bạn nhớ luôn "ABC ở phòng 305" mà không cần hỏi lại lần nữa.

ARP: Làm sao biết được Destination MAC?1. ARP Request (broadcast, Dst MAC=FF:FF:FF:FF:FF:FF): Who has 10.0.0.20?PC A10.0.0.10Switch(L2 — floodsbroadcast tớimọi port)PC B10.0.0.202. ARP Reply (unicast): 10.0.0.20 is at MAC-B3. PC A lưu MAC-B vào ARP cache — lần sau gửi thẳng unicast, không cần broadcast lại

Quy trình đầy đủ gồm ba bước:

  1. ARP Request — PC A muốn nói chuyện với 10.0.0.20 nhưng chưa biết MAC tương ứng, nên gửi một frame broadcast (Destination MAC = FF:FF:FF:FF:FF:FF) với nội dung "Ai đang giữ địa chỉ 10.0.0.20? Hãy cho tôi biết MAC của bạn." Vì là broadcast, switch (Mục 8) sẽ flood frame này ra mọi port.
  2. ARP Reply — chỉ đúng thiết bị đang sở hữu 10.0.0.20 (PC B) mới trả lời, và trả lời bằng unicast trực tiếp về PC A: "10.0.0.20 đang ở MAC-B."
  3. Lưu vào ARP cache — PC A ghi nhớ cặp (10.0.0.20 → MAC-B) vào bảng ARP cache của mình trong một khoảng thời gian nhất định. Từ lần gửi tiếp theo, PC A tra thẳng cache, không cần phát broadcast lại — đây cũng chính là điều giải thích vì sao ping đầu tiên tới một địa chỉ mới thường có độ trễ (delay) nhỏ cao hơn hẳn so với các lần ping sau.

Điểm cần nhớ: ARP chỉ hoạt động trong phạm vi một segment Layer 2 (cùng subnet) — đây là lý do khi PC A muốn gửi tới một địa chỉ IP ở subnet khác, nó sẽ ARP để tìm MAC của default gateway (chính là router) chứ không phải ARP trực tiếp tới đích thật — đúng như sẽ thấy ở Mục 10.

8. Gói tin đi qua Switch (Layer 2) như thế nào?​

Đã hiểu cấu trúc frame/packet, giờ xem điều gì thực sự xảy ra khi một frame đi qua một thiết bị mạng — bắt đầu với thiết bị đơn giản nhất: switch.

💡 Hình dung như thế này: switch giống một nhân viên bưu cục nội bộ trong cùng một tòa nhà — chỉ nhìn đúng tên phòng ghi trên phong bì (Destination MAC) để bỏ vào đúng ngăn, tuyệt đối không bóc phong bì ra xem nội dung bên trong là gì.

Switch (Layer 2): Frame đi qua như thế nào?PC ASwitch (L2)MAC Address Table:Port1 → aa:aa (PC A)Port2 → bb:bb (PC B)→ forward theo Dest MACPC BFrame: Src=MAC-A, Dst=MAC-BFrame giữ nguyênSwitch không nhìn IP header — chỉ quan tâm Dest MAC trong Frame→ Đây là lý do 2 máy cùng subnet không cần router để nói chuyện

Quy trình xử lý của switch cực kỳ đơn giản, gồm đúng hai việc:

  1. Học (learn) địa chỉ MAC nguồn của frame vừa nhận vào, gắn với cổng vật lý vừa nhận — đây là cách switch tự xây dựng MAC Address Table mà không cần cấu hình gì thêm.
  2. Chuyển tiếp (forward) frame ra đúng cổng tương ứng với Destination MAC, tra trong chính bảng MAC vừa xây dựng. Nếu không tìm thấy MAC đích trong bảng, switch flood frame ra toàn bộ cổng còn lại (trừ cổng vừa nhận vào) — đúng cơ chế mà ARP Request ở Mục 7 dựa vào.

Điểm mấu chốt: switch không hề đọc IP header — toàn bộ frame, kể cả IP packet bên trong, được forward đi nguyên vẹn, không hề bị sửa đổi. Đây chính là lý do vì sao hai máy trong cùng một subnet Layer 2 có thể nói chuyện với nhau mà không cần bất kỳ router nào can thiệp.

9. Gói tin đi qua Router (Layer 3) như thế nào?​

Nếu switch chỉ "nhìn phong bì" thì router bắt buộc phải bóc phong bì ra đọc địa chỉ thật bên trong — đây chính là điểm khác biệt cốt lõi giữa hai loại thiết bị.

💡 Hình dung như thế này: router giống một trạm trung chuyển quốc tế. Nó phải bóc lớp bao bì vận chuyển nội địa cũ (frame cũ) ra, đọc đúng địa chỉ người nhận cuối cùng ghi bên trong (IP packet), tra bản đồ tuyến đường (routing table) để biết nên gửi tiếp qua ngả nào, rồi dán một lớp bao bì vận chuyển mới (frame mới, với địa chỉ MAC khác hoàn toàn) trước khi gửi tiếp — địa chỉ người nhận cuối cùng bên trong thì không đổi, chỉ có "bao bì ngoài" là đổi mới ở mỗi trạm.

Router (Layer 3): Frame và Packet thay đổi ra sao?Host ARouter (L3)1. Decap Frame2. Route lookup3. TTL − 14. Re-encap FrameHost BFrame#1: Src=MAC-A, Dst=MAC-RouterFrame#2: Src=MAC-Router, Dst=MAC-BBên trong: IP packet KHÔNG đổi Source/Dest IP — chỉ TTL giảm 1MAC (Layer 2) đổi mỗi hop — IP (Layer 3) giữ nguyên end-to-end

Bốn bước router thực hiện với mỗi gói tin đi qua nó:

  1. De-encapsulate frame nhận vào — bóc bỏ Ethernet header/trailer để lộ ra IP packet bên trong.
  2. Tra routing table — dựa vào Destination IP trong header (Mục 4), tìm ra next-hop và cổng ra tương ứng.
  3. Giảm TTL đi 1 — và tính lại Header Checksum cho khớp với TTL mới (vì checksum chỉ bảo vệ header, và header vừa đổi).
  4. Re-encapsulate thành frame mới — đóng một Ethernet header hoàn toàn khác: Source MAC giờ là MAC của chính router (ở cổng ra), Destination MAC là MAC của next-hop (có thể là host đích, hoặc một router trung gian khác — và để biết chính xác MAC nào, router cũng phải ARP y hệt Mục 7 nếu chưa có sẵn trong cache) — rồi mới gửi frame mới này đi tiếp.

Điểm khác biệt cốt lõi so với switch ở Mục 8: Source/Destination IP không đổi trong suốt hành trình (đây là địa chỉ logic, mang tính "toàn cục"), nhưng Source/Destination MAC đổi hoàn toàn ở mỗi router (vì đây chỉ là địa chỉ "cục bộ", chỉ có ý nghĩa trên đúng một segment Layer 2). Ai từng thắc mắc "vì sao ping vẫn tới đích được dù đi qua bao nhiêu router, trong khi ARP table trên mỗi segment lại toàn thấy MAC khác nhau" — câu trả lời chính xác nằm ở đây.

10. Tổng hợp: theo dõi một gói tin từ đầu đến cuối​

Ghép Mục 7, 8 và 9 lại, ta có bức tranh đầy đủ của một gói tin đi từ PC1 tới PC2 nằm ở hai subnet khác nhau, qua hai switch và một router ở giữa.

Hành trình 1 gói tin: PC1 → Switch → Router → Switch → PC2PC1Switch1(L2)Router(L3)Decap→Route→TTL-1Switch2(L2)PC2Dst=MAC-Router(không đổi)Dst=MAC-PC2(không đổi)IP Packet: Source IP=PC1, Dest IP=PC2 — không đổi suốt hành trình (chỉ TTL giảm dần)Frame (MAC): đổi mới ở router — switch chỉ forward, không tạo frame mới

Ráp lại toàn bộ những gì đã học ở các mục trước, hành trình đầy đủ của gói tin trông như sau:

  1. PC1 đã ARP từ trước (Mục 7) để biết MAC của default gateway (chính là router), nên gửi frame với Destination MAC = MAC của router, Destination IP = IP thật của PC2.
  2. Switch1 chỉ nhìn Destination MAC, forward nguyên frame ra đúng cổng nối tới router — không đụng gì vào IP packet bên trong (Mục 8).
  3. Router de-encapsulate frame, đọc Destination IP, tra routing table, giảm TTL, rồi đóng một frame hoàn toàn mới với Destination MAC = MAC của PC2 (Mục 9) — nhưng Destination IP bên trong packet thì giữ nguyên là IP của PC2.
  4. Switch2 lại chỉ nhìn Destination MAC của frame mới, forward tới đúng cổng nối với PC2 — một lần nữa không đụng gì vào IP packet.
  5. PC2 nhận frame, de-encapsulate ngược lên từng lớp OSI, cho tới khi ứng dụng ở Layer 7 nhận đúng dữ liệu gốc mà PC1 gửi ban đầu.

Nắm được toàn bộ bức tranh này — PDU nào ứng với layer nào, ai đổi ai giữ nguyên, MTU/MSS giới hạn ở đâu, ARP lấp khoảng trống nào giữa Layer 2 và Layer 3 — là nền tảng bắt buộc trước khi học tiếp bất kỳ giao thức routing, switching, hay tunneling nào khác (bao gồm cả GRE Tunnel đã nói ở tài liệu trước).

Nguồn tham khảo​

Nguồn gốc: Baeldung on Computer Science — "OSI Model: Packets vs. Frames" (link); kiến thức nền CCNA 200-301 (OSI model, encapsulation, Ethernet frame, IPv4 header, MTU/MSS).