Khi một trang web báo 502, kết nối bảo mật thất bại hoặc API hết thời gian chờ, câu hỏi đầu tiên thường là: lỗi nằm ở ứng dụng, proxy, kết nối mạng hay quá trình phân giải tên miền? Mô hình OSI không trả lời trực tiếp, nhưng cho ta một bản đồ để chia hệ thống thành từng tầng và kiểm tra đúng chỗ.

Bài viết này không hướng tới việc học thuộc bảy tầng. Mục tiêu là hiểu mô hình OSI, cách Internet rút gọn nó thành bốn tầng, và cách áp dụng khi thiết kế, vận hành, xử lý sự cố cho ứng dụng web.

Mô hình OSI là gì?

OSI, viết tắt của Open Systems Interconnection, là một mô hình tham chiếu do ISO (International Organization for Standardization — Tổ chức Tiêu chuẩn hoá Quốc tế) xây dựng. Mô hình chia việc truyền dữ liệu thành bảy tầng. Mỗi tầng sử dụng dịch vụ của tầng bên dưới và cung cấp dịch vụ cho tầng bên trên.

Giá trị chính của OSI là tạo ra ngôn ngữ chung. Khi nói lỗi ở Network Layer, kỹ sư mạng hiểu cần kiểm tra địa chỉ IP và định tuyến. Khi nói Application Layer load balancer, kỹ sư ứng dụng hiểu thiết bị có thể đọc HTTP host, đường dẫn hoặc header để chọn máy chủ phía sau.

OSI là mô hình tư duy, không phải bản thiết kế bắt buộc của Internet. Nhiều giao thức hiện đại không nằm gọn trong một tầng. TLS (Transport Layer Security) thường được gắn với Presentation Layer, nhưng trên Internet nó hoạt động giữa Transport Layer và HTTP. QUIC còn kết hợp chức năng vận chuyển với quá trình mã hoá. Vì vậy, nên dùng OSI để phân chia trách nhiệm và khoanh vùng lỗi, không nên ép mọi công nghệ vào một ô tuyệt đối.

Bảy tầng của mô hình OSI

OSI được đọc từ Physical Layer ở dưới lên Application Layer ở trên. Càng lên tầng cao, dữ liệu càng gần với ý nghĩa mà ứng dụng và người dùng quan tâm.

Layer Trách nhiệm Ví dụ trong hệ thống web
7. Application Layer
(Tầng ứng dụng)		 Giao thức mà phần mềm sử dụng để trao đổi dữ liệu HTTP, DNS (Domain Name System), WebSocket, SMTP (Simple Mail Transfer Protocol)
6. Presentation Layer
(Tầng trình bày)		 Biểu diễn, chuyển đổi và mã hoá dữ liệu JSON, UTF-8, nén, TLS theo cách phân loại thường gặp
5. Session Layer
(Tầng phiên)		 Thiết lập, duy trì và kết thúc phiên trao đổi Không có giao thức Internet tương ứng một-một; phần lớn trạng thái do TLS và ứng dụng quản lý
4. Transport Layer
(Tầng vận chuyển)		 Truyền dữ liệu giữa hai tiến trình, quản lý cổng và độ tin cậy TCP (Transmission Control Protocol), UDP (User Datagram Protocol)
3. Network Layer
(Tầng mạng)		 Địa chỉ logic và định tuyến qua nhiều mạng IPv4, IPv6, router, ICMP (Internet Control Message Protocol)
2. Data Link Layer
(Tầng liên kết dữ liệu)		 Truyền khung dữ liệu trong cùng một liên kết cục bộ Ethernet, Wi-Fi, địa chỉ MAC (Media Access Control), switch
1. Physical Layer
(Tầng vật lý)		 Truyền tín hiệu điện, quang hoặc vô tuyến Cáp đồng, cáp quang, sóng Wi-Fi

Physical Layer và Data Link Layer: đưa dữ liệu qua liên kết gần nhất

Physical Layer biến bit thành tín hiệu. Data Link Layer đóng bit thành khung và chuyển khung giữa các thiết bị trong cùng mạng cục bộ. Switch (bộ chuyển mạch) chủ yếu hoạt động ở Data Link Layer và dùng địa chỉ MAC để quyết định khung cần đi qua cổng nào.

Với nhà phát triển web, hai tầng này thường chỉ được chú ý khi Wi-Fi yếu, cáp lỗi, card mạng có vấn đề hoặc MTU (Maximum Transmission Unit) không phù hợp. Tuy nhiên, hiện tượng mất gói ở đây có thể xuất hiện ở tầng trên dưới dạng API chậm, TCP truyền lại nhiều lần hoặc WebSocket thường xuyên mất kết nối.

Network Layer: đưa gói tin tới đúng mạng

Network Layer dùng địa chỉ IP và bảng định tuyến để chuyển gói tin qua nhiều router. Địa chỉ MAC thay đổi theo từng chặng cục bộ, còn địa chỉ IP xác định nguồn và đích trên đường truyền đầu cuối, trừ khi đi qua NAT (Network Address Translation) hoặc proxy.

Lỗi ở Network Layer thường liên quan tới định tuyến, subnet, VPN (Virtual Private Network), tường lửa theo địa chỉ IP, Network ACL (Access Control List) hoặc việc không có đường tới mạng đích. traceroute có thể giúp quan sát các chặng, nhưng một router không phản hồi ICMP không đồng nghĩa lưu lượng ứng dụng bị chặn.

Transport Layer: kết nối đúng tiến trình

Transport Layer thêm khái niệm cổng. Một máy chủ có thể cùng lúc nhận HTTPS ở cổng 443, SSH (Secure Shell) ở cổng 22 và kết nối cơ sở dữ liệu ở một cổng khác.

TCP cung cấp kết nối có thứ tự, truyền lại dữ liệu bị mất và điều chỉnh tốc độ gửi. UDP gửi datagram mà không tự bảo đảm thứ tự hay truyền lại. HTTP/1.1 và HTTP/2 thường chạy trên TCP; HTTP/3 chạy trên QUIC, còn QUIC sử dụng UDP làm nền.

Session Layer, Presentation Layer và Application Layer: nơi ứng dụng web hoạt động

Trong hệ thống Internet thực tế, trách nhiệm của ba tầng trên thường nằm chung trong thư viện và ứng dụng. HTTP định nghĩa yêu cầu, phản hồi, phương thức, mã trạng thái và header. JSON hoặc Protocol Buffers biểu diễn dữ liệu. TLS mã hoá kênh truyền. Cookie, token và nơi lưu phiên duy trì trạng thái đăng nhập.

Điểm cần nhớ là Session Layer không đồng nghĩa hoàn toàn với phiên HTTP của ứng dụng. Phiên HTTP là một cách ứng dụng duy trì trạng thái người dùng; Session Layer là khái niệm rộng hơn về việc duy trì cuộc trao đổi giữa hai bên.

Từ 7 tầng OSI đến 4 tầng TCP/IP

Các ứng dụng Internet thường dùng mô hình bốn tầng được mô tả trong RFC (Request for Comments) 1122: Application Layer, Transport Layer, Internet Layer và Link Layer.

1DE2vMVC8yf7NWfwLk4aL_wf3rU7I7MqZ

TCP/IP Layer OSI mapping Giao thức và thành phần thường gặp
Application Layer Application Layer, Presentation Layer và Session Layer HTTP, DNS, TLS, WebSocket, định dạng dữ liệu, logic phiên
Transport Layer Transport Layer TCP, UDP, QUIC theo cách phân loại thực tế
Internet Layer Network Layer IPv4, IPv6, ICMP, định tuyến
Link Layer Data Link Layer và Physical Layer Ethernet, Wi-Fi, MAC, tín hiệu vật lý

Mô hình bốn tầng gần với cách Internet được triển khai hơn, còn OSI chi tiết hơn khi cần thảo luận trách nhiệm. Trong công việc, hai mô hình bổ sung cho nhau: dùng TCP/IP để nhìn kiến trúc thực tế, dùng OSI để diễn đạt chính xác vị trí của một vấn đề.

Một yêu cầu HTTPS đi qua các tầng như thế nào?

Giả sử người dùng mở https://example.com/products. Trước khi ứng dụng nhận được yêu cầu HTTP, nhiều bước đã xảy ra.
1D-4GTXAj6aYe32WD8ZrT34zEHUrSEMw5

1. Phân giải tên miền

Trình duyệt cần đổi tên miền thành địa chỉ IP. Nó kiểm tra bộ nhớ đệm cục bộ, hệ điều hành và bộ phân giải DNS. DNS thuộc Application Layer dù nhiệm vụ của nó hỗ trợ kết nối mạng. DNS truyền thống thường dùng UDP hoặc TCP ở cổng 53; DNS over HTTPS lại gửi truy vấn DNS bên trong HTTPS.

Nếu DNS trả NXDOMAIN, trình duyệt chưa hề kết nối tới máy chủ web. Kiểm tra code ứng dụng lúc này không giúp ích.

2. Thiết lập kết nối và mã hoá

Với HTTP/1.1 hoặc HTTP/2, phía gửi thường mở kết nối TCP tới cổng 443, sau đó thực hiện quá trình bắt tay TLS. TLS xác minh chứng chỉ, thoả thuận thuật toán mã hoá và tạo khoá phiên. Sau bước này, yêu cầu HTTP mới được gửi trong kênh mã hoá.

Với HTTP/3, phía gửi dùng QUIC trên UDP. QUIC tích hợp quá trình thiết lập kết nối với TLS 1.3, hỗ trợ nhiều luồng độc lập và giảm ảnh hưởng khi một gói tin của luồng khác bị mất. Đây là ví dụ cho thấy giao thức hiện đại không luôn khớp hoàn toàn với ranh giới OSI.

3. Đóng gói và truyền qua mạng

Với HTTP/1.1 hoặc HTTP/2, dữ liệu HTTP được đặt trong TLS record, rồi vào phân đoạn TCP, gói IP và cuối cùng là khung Ethernet hoặc Wi-Fi. Với HTTP/3, HTTP/3 frame được đặt trong QUIC packet, sau đó vào UDP datagram, gói IP và khung liên kết. QUIC dùng TLS để bắt tay và bảo vệ kết nối, nhưng không dùng TLS record layer như HTTP/1.1 hoặc HTTP/2 chạy trên TCP.

Mỗi router bỏ lớp liên kết của chặng cũ, chọn đường đi tiếp và tạo lớp liên kết mới. Quá trình thêm thông tin theo từng tầng gọi là đóng gói; phía nhận thực hiện ngược lại để lấy yêu cầu HTTP.

10DgvJURvQqoff3PSfdqaRE65x7gWN_nL

4. Đi qua hạ tầng web

Địa chỉ IP đích có thể thuộc CDN, WAF (Web Application Firewall), Layer 7 load balancer hoặc Layer 4 load balancer thay vì máy chạy ứng dụng. CDN và Layer 7 load balancer thường kết thúc kết nối từ trình duyệt, đọc thông tin HTTP rồi mở kết nối khác tới hệ thống phía sau. Layer 4 load balancer kiểu passthrough có thể chỉ chuyển tiếp kết nối TCP hoặc UDP mà không kết thúc TLS hay đọc HTTP.

Yêu cầu có thể tiếp tục qua reverse proxy, service mesh và API gateway trước khi tới ứng dụng. Phản hồi quay lại theo đường logic ngược lại, nhưng các gói tin trên Internet không bắt buộc đi qua đúng cùng một tuyến. Điều ứng dụng nhìn thấy thường là yêu cầu HTTP đã qua nhiều lần chuyển tiếp, không phải kết nối trực tiếp từ trình duyệt. Trong Kubernetes, chuỗi này có thêm Ingress (proxy ở Layer 7), Service qua kube-proxy (NAT theo IP và cổng) và, với một số CNI (Container Network Interface), overlay network như VXLAN đóng gói lại khung Ethernet của Pod bên trong UDP; cách khoanh vùng theo tầng vẫn áp dụng như trên.

Ứng dụng mô hình phân tầng khi thiết kế hệ thống web

Phân biệt Layer 4 và Layer 7 load balancer

Layer 4 load balancer định tuyến dựa trên địa chỉ IP, cổng và giao thức của Transport Layer. Nó không cần hiểu nội dung HTTP, nên phù hợp với TCP/UDP nói chung và có chi phí xử lý thấp.

Layer 7 load balancer hiểu giao thức ứng dụng. Với HTTP, nó có thể chọn hệ thống phía sau theo domain, đường dẫn, phương thức hoặc header; đồng thời kết thúc kết nối TLS, chuyển hướng và áp dụng một số chính sách bảo mật.

Tiêu chí Layer 4 load balancer Layer 7 load balancer
Thông tin dùng để định tuyến IP, cổng, TCP/UDP Host, đường dẫn, phương thức, header, cookie
Có đọc HTTP không? Không Có
Dùng cho Giao thức TCP/UDP, chuyển tiếp kết nối Website, API, định tuyến theo nội dung
Đánh đổi Ít tính năng ứng dụng Xử lý phức tạp hơn và phải hiểu giao thức

Đặt kiểm soát bảo mật đúng tầng

Không có một tầng duy nhất giải quyết toàn bộ bảo mật. Tường lửa hoặc Security Group ở Network Layer và Transport Layer giới hạn nguồn, đích và cổng. TLS bảo vệ dữ liệu trên đường truyền. WAF ở Application Layer kiểm tra yêu cầu HTTP. Xác thực và phân quyền nằm trong ứng dụng.

Nếu chỉ mở cổng 443, hệ thống vẫn có thể có lỗi phân quyền. Nếu chỉ dùng WAF, cổng quản trị không cần thiết vẫn có thể bị phơi ra mạng. Mỗi lớp kiểm soát xử lý một loại rủi ro khác nhau.

Hiểu nơi phát sinh độ trễ

Thời gian tải trang không chỉ là thời gian chạy code trên máy chủ. Nó có thể gồm phân giải DNS, thiết lập TCP, quá trình bắt tay TLS, truyền dữ liệu qua mạng, hàng đợi ở proxy, thời gian xử lý ứng dụng và truy vấn cơ sở dữ liệu.

Mô hình phân tầng giúp tách các phần này. Bộ nhớ đệm DNS giảm thời gian phân giải tên. Tái sử dụng kết nối giảm số lần bắt tay TCP/TLS. CDN đưa nội dung tới gần người dùng. HTTP/2 và HTTP/3 cải thiện cách nhiều yêu cầu dùng chung kết nối. Tối ưu code ứng dụng không giải quyết được độ trễ do mất gói hoặc kết nối mới được tạo quá thường xuyên.

Thiết kế thời gian chờ theo chuỗi

Một yêu cầu thường đi qua trình duyệt, CDN, bộ cân bằng tải, reverse proxy, ứng dụng và cơ sở dữ liệu. Mỗi thành phần có thời gian chờ riêng. Quy tắc thực tế là thời gian chờ của tầng trong phải ngắn hơn tầng ngoài: ví dụ database ngắn hơn ứng dụng, ứng dụng ngắn hơn proxy, proxy ngắn hơn CDN hoặc trình duyệt. Khi lỗi xảy ra, thành phần bên trong kết thúc trước và trả lỗi cụ thể cho tầng gọi nó, thay vì để tầng ngoài cùng trả 504 chung chung.

Giá trị cụ thể phụ thuộc vào tác vụ, nhưng mọi timeout cần nằm trong ngân sách thời gian của toàn yêu cầu. Log và trace phải cho biết yêu cầu dừng ở thành phần nào thay vì chỉ ghi một thông báo timeout chung chung.

Dùng mô hình phân tầng để xử lý sự cố web

Cách hiệu quả nhất là bắt đầu từ triệu chứng rồi thu hẹp phạm vi. Nếu người dùng nhận được mã trạng thái HTTP, kết nối đã đi qua nhiều tầng bên dưới; nên kiểm tra từ Application Layer đi xuống. Nếu không tạo được kết nối, nên kiểm tra DNS, cổng và định tuyến trước khi đọc code nghiệp vụ.

Triệu chứng Vùng nên kiểm tra trước Công cụ hoặc dữ liệu hữu ích
NXDOMAIN, không tìm thấy domain DNS ở Application Layer dig, nslookup, cấu hình zone và record
Connection refused Host đã tới được nhưng không có tiến trình lắng nghe cổng, hoặc tường lửa chủ động từ chối nc, cổng đang lắng nghe, trạng thái tiến trình, quy tắc REJECT của tường lửa
Kết nối hết thời gian chờ DNS, định tuyến, Security Group hoặc Network ACL chặn bằng cách drop, mất gói hoặc máy chủ quá tải dig, traceroute, VPC Flow Logs, số liệu mạng và máy chủ
Chứng chỉ không hợp lệ TLS và cấu hình domain openssl s_client, chuỗi chứng chỉ, SNI (Server Name Indication), thời hạn chứng chỉ
502 Bad Gateway Proxy không nhận được phản hồi hợp lệ từ dịch vụ phía sau Log proxy, health check, cổng và giao thức kết nối phía sau
504 Gateway Timeout Dịch vụ phía sau trả lời chậm hoặc thời gian chờ giữa các proxy không khớp Theo dấu yêu cầu, thời gian chờ từng chặng, thời gian xử lý ứng dụng
Lỗi CORS (Cross-Origin Resource Sharing) Chính sách trình duyệt và HTTP header ở Application Layer Developer Tools, Origin, Access-Control-Allow-*
Chạy được ở máy cá nhân nhưng lỗi trên production DNS, TLS, proxy, tường lửa, biến môi trường hoặc định tuyến So sánh curl -v, cấu hình và log giữa hai môi trường

Một bộ lệnh tối thiểu có thể kiểm tra nhiều tầng:

# macOS: dùng TCP probe tới cổng HTTPS
traceroute -P tcp -p 443 example.com

# Linux: dùng TCP probe tới cổng HTTPS
traceroute -T -p 443 example.com

dig example.com
nc -vz example.com 443
openssl s_client -connect example.com:443 -servername example.com
curl -v https://example.com/health

traceroute mặc định thường dùng probe không giống lưu lượng HTTPS. TCP probe tới cổng 443 gần với đường đi cần kiểm tra hơn, nhưng vẫn không bảo đảm giống hoàn toàn do định tuyến theo luồng, proxy hoặc CDN. Nếu có sẵn, mtr giúp quan sát loss và độ trễ qua nhiều lần probe.

Thứ tự trên lần lượt kiểm tra tên miền, khả năng mở kết nối, TLS, HTTP và đường mạng. Không phải lúc nào cũng cần chạy tất cả. Nếu curl đã trả 401, mạng và TLS cơ bản đang hoạt động; vấn đề nhiều khả năng nằm ở xác thực tại Application Layer.

ping không phải phép kiểm tra website. Máy chủ hoặc tường lửa có thể chặn ICMP nhưng vẫn phục vụ HTTPS bình thường. Ngược lại, ping thành công chỉ chứng minh đích phản hồi ICMP, không chứng minh ứng dụng ở cổng 443 hoạt động.

Những điểm dễ hiểu sai

Nhận định dễ nhầm Cách hiểu đúng
Mỗi giao thức chỉ thuộc đúng một tầng OSI là mô hình tham chiếu; TLS, QUIC, VPN và proxy có thể trải qua hoặc kết hợp trách nhiệm của nhiều tầng
Application Layer chỉ là code do đội phát triển viết DNS, HTTP, WAF và reverse proxy cũng hoạt động với thông tin của Application Layer
Có mã trạng thái HTTP nghĩa là lỗi chỉ nằm ở code 502 hoặc 504 xuất hiện ở Application Layer, nhưng nguyên nhân có thể là DNS nội bộ, TCP, TLS hoặc dịch vụ phía sau quá tải
CORS là lỗi mạng CORS là chính sách bảo mật của trình duyệt dựa trên HTTP header; yêu cầu có thể đã tới máy chủ
HTTPS mã hoá mọi thông tin mạng TLS bảo vệ nội dung ứng dụng, nhưng địa chỉ IP, cổng, kích thước và thời điểm truyền gói tin vẫn có thể quan sát được. Khi chưa dùng ECH, SNI trong ClientHello có thể lộ tên miền; truy vấn DNS không mã hoá cũng có thể lộ tên miền (RFC 9849)
Học thuộc bảy tầng là đủ Giá trị thực nằm ở việc đặt đúng câu hỏi, chọn đúng công cụ và xác định ranh giới giữa các thành phần

Không cần tranh luận TLS chính xác thuộc Session Layer, Presentation Layer hay Application Layer để xử lý một chứng chỉ hết hạn. Chỉ cần thống nhất rằng lỗi xảy ra sau khi có kết nối ở Transport Layer nhưng trước khi HTTP trao đổi thành công. Mô hình tốt là mô hình giúp đội ngũ hành động nhanh hơn.

Kết luận

Mô hình OSI chia truyền thông thành bảy tầng để mô tả trách nhiệm rõ ràng. Mô hình TCP/IP gộp các trách nhiệm này thành bốn tầng gần với cách Internet vận hành hơn.

Với kỹ sư phần mềm, lợi ích lớn nhất của OSI không phải trả lời câu hỏi phỏng vấn. Nó giúp đọc kiến trúc, hiểu Layer 4 và Layer 7 load balancer, đặt kiểm soát bảo mật đúng vị trí, phân tích độ trễ và khoanh vùng sự cố. Khi gặp lỗi, hãy xác định tầng cao nhất còn hoạt động và tầng thấp nhất bắt đầu thất bại, rồi kiểm tra ranh giới giữa hai tầng đó.

Tài liệu tham khảo

Mô hình mạng

Giao thức web