Mạng và truyền thông cho người mới · Bài 3/6 · Biên soạn lại tháng 10/2026.

Phân biệt encoding, nén và mật mã hóa; hiểu UTF-8, JSON, HTTPS và trạng thái đăng nhập mà không nhầm với các tầng OSI.

1. Gửi được dữ liệu chưa chắc đã hiểu đúng dữ liệu

Bạn mở một bài học và thấy tiếng Việt biến thành những ký tự lạ. Kết nối có thể vẫn hoạt động: byte đã được gửi tới nơi, nhưng phía đọc hiểu sai cách biểu diễn. Một ví dụ khác là hai chương trình cùng nhận được dữ liệu nhưng một bên cho rằng nó là ảnh, bên kia lại cố đọc như văn bản.

Các phía cần thống nhất kiểu dữ liệu, cách biểu diễn và cách diễn giải. Trong OSI, tầng trình diễn giúp mô tả nhóm chức năng này. Trên Internet thực tế, các chức năng có thể nằm trong giao thức ứng dụng, thư viện hoặc cơ chế bảo mật; không nhất thiết tồn tại một chương trình riêng tên “tầng 6” mà mọi byte đều phải đi qua.

Trong bài này, ta dùng dữ liệu của một ứng dụng web để hiểu từng công việc. Đây là minh họa chức năng, không phải quy tắc khẳng định JSON hay TLS chỉ thuộc duy nhất một ô trong mọi mô hình phân tầng.

2. Encoding: thống nhất cách biểu diễn

Máy tính truyền byte, còn người dùng nhìn thấy chữ. UTF-8 là một cách mã hóa ký tự Unicode thành byte. Ký tự A có thể được biểu diễn bằng một byte trong UTF-8, còn nhiều ký tự tiếng Việt cần nhiều byte. Vì vậy đếm byte không luôn bằng đếm ký tự; giới hạn một tệp 1 MB không đồng nghĩa nó chứa đúng một triệu chữ.

Nếu bên gửi dùng UTF-8 mà bên đọc hiểu các byte đó theo bảng mã khác, chữ có thể bị lỗi dù dữ liệu truyền tới không mất. Đổi font không phải lúc nào cũng giải quyết được lỗi sai encoding. Với web, cần khai báo và xử lý charset phù hợp trong tài liệu, header và quá trình lưu trữ.

Encoding theo nghĩa biểu diễn không bảo vệ bí mật. Base64 chuyển byte sang một dạng ký tự thuận tiện để vận chuyển, và có thể được chuyển ngược mà không cần khóa bí mật. Không dùng Base64 như cách giấu mật khẩu.

3. Serialization: các trường dữ liệu được tổ chức ra sao?

Một đối tượng khóa học có tên và giá. Để trao đổi, ứng dụng có thể tuần tự hóa nó thành JSON. JSON quy định cách biểu diễn object, array, chuỗi, số và một số giá trị khác. UTF-8 giải quyết cách văn bản đó trở thành byte; hai khái niệm phối hợp nhưng không thay thế nhau.

{
  "ten": "Mạng máy tính cơ bản",
  "mienPhi": true,
  "soBai": 6
}

Phía nhận còn phải hiểu quy ước nghiệp vụ: soBai là số lượng hay chỉ số, giá tiền dùng đơn vị nào, trường nào bắt buộc. Một JSON hợp lệ về cú pháp vẫn có thể sai nghiệp vụ. Content-Type như application/json cho biết dạng nội dung; nó không tự chứng minh dữ liệu chính xác hoặc đáng tin.

4. Nén, encoding và mật mã hóa giải quyết các việc khác nhau

Nén nhằm giảm số byte cần lưu hoặc truyền bằng cách khai thác cấu trúc dữ liệu. Dữ liệu đã được nén hiệu quả có thể không giảm thêm đáng kể; nén còn tốn tài nguyên xử lý. Ví dụ một response văn bản có thể dùng cơ chế nén mà trình duyệt hỗ trợ.

Mật mã hóa dùng thuật toán và khóa để bảo vệ tính bí mật trong mô hình bảo mật đã chọn. Cần phân biệt nó với encoding dù tiếng Việt đôi khi dùng chung từ “mã hóa”. Ngoài bí mật, một kênh bảo mật còn cần xem xét tính toàn vẹn và xác thực. Không kết luận một nội dung có vẻ khó đọc đã được bảo vệ đúng.

5. HTTPS và TLS giúp gì cho lần mở website?

Khi kết nối HTTPS được thiết lập đúng, TLS góp phần bảo vệ dữ liệu trên đường truyền và xác thực máy chủ bằng chứng chỉ theo cơ chế được hỗ trợ. Trình duyệt cần kiểm tra tên máy chủ và chuỗi chứng chỉ; không nên hướng dẫn người mới bỏ qua cảnh báo chứng chỉ để “vào cho nhanh”.

TLS bảo vệ kênh trao đổi, không thay thế mọi kiểm tra của ứng dụng. Một website lừa đảo vẫn có thể có chứng chỉ hợp lệ cho tên miền của nó. Dữ liệu cũng có thể được giải mã tại một proxy được cấu hình hoặc ở máy chủ, nên bảo vệ khi truyền không đồng nghĩa mọi nơi lưu dữ liệu đều đã an toàn.

Trong luồng HTTPS dùng TCP, có thể học TCP handshake và TLS handshake như hai việc khác nhau. Với HTTP/3, QUIC tích hợp quá trình bắt tay bảo mật theo thiết kế của nó. Ở đây chỉ cần biết trách nhiệm; không cần học thuộc toàn bộ thông điệp mật mã.

6. Vì sao website nhớ bạn đã đăng nhập?

Bạn đăng nhập, chuyển sang trang khác và vẫn thấy tên tài khoản. Ứng dụng phải liên hệ những request đó với trạng thái người dùng. Một cách phổ biến là lưu phiên phía server, gửi một mã định danh phiên qua cookie rồi nhận lại mã trong những request phù hợp tiếp theo.

Mã phiên giống một dấu hiệu tham chiếu tới trạng thái đang được server quản lý, không phải mật khẩu được hiển thị lại trong mỗi trang. Server phải kiểm tra mã còn hợp lệ, hết hạn hoặc đã bị thu hồi hay chưa. Đăng xuất cần xử lý trạng thái phiên hoặc token tương ứng theo thiết kế ứng dụng.

Không phải mọi ứng dụng đều dùng cùng cơ chế này; có hệ thống dùng token hoặc kết hợp nhiều cách. Cookie có thể mang mã phiên, tùy chọn giao diện hay dữ liệu khác. “Có cookie” không đồng nghĩa “đã đăng nhập”.

1. Client gửi yêu cầu đăng nhập tới ứng dụng qua kết nối được bảo vệ.
2. Ứng dụng xác thực và tạo trạng thái hoặc thông tin xác thực phù hợp.
3. Trình duyệt lưu cookie được phép theo các thuộc tính của nó.
4. Request tiếp theo gửi cookie phù hợp; server kiểm tra rồi quyết định nội dung trả về.

7. Ba chữ “phiên” rất dễ bị trộn lẫn

Tầng phiên trong OSI mô tả chức năng tổ chức hội thoại và đồng bộ trao đổi. Phiên đăng nhập web là trạng thái ở mức ứng dụng. Kết nối TCP là một quan hệ truyền tải giữa hai điểm cuối. Ba khái niệm có liên quan trong một hệ thống nhưng không phải một.

Một lần đăng nhập có thể tồn tại qua nhiều kết nối TCP nối tiếp. Mất kết nối tạm thời không nhất thiết làm mất phiên đăng nhập; đóng một tab cũng không luôn tương đương đăng xuất. Ngược lại, cookie phiên không tự khôi phục mọi luồng dữ liệu đang truyền dở. Cách phục hồi phải do giao thức và ứng dụng thực hiện.

8. Quan sát ngắn trong trình duyệt

Mở DevTools ở một website bạn sử dụng, chọn Network rồi xem header của request document. Tìm Content-Type, Content-Encoding nếu có và thông tin giao thức. Content-Type mô tả loại nội dung, còn Content-Encoding như gzip hoặc br cho biết dạng biến đổi nén được dùng khi đó. Không thấy header nén ở một response không chứng minh cả website không dùng nén.

Trong Application/Storage, xem tên cookie và các thuộc tính như Secure, HttpOnly, SameSite. Chỉ quan sát cấu trúc, không sao chép giá trị phiên vào bài viết hoặc ảnh chụp. HttpOnly hạn chế JavaScript đọc cookie; Secure giới hạn việc gửi qua kết nối bảo mật theo quy tắc trình duyệt; SameSite liên quan các tình huống gửi cookie giữa các site. Những thuộc tính này bổ sung cho thiết kế xác thực, không tự giải quyết mọi lỗi ứng dụng.

9. Đọc thêm sau phần nền tảng

ASN.1 và các quy tắc biểu diễn như BER có vai trò trong những hệ thống cụ thể, bao gồm các cấu trúc liên quan chứng chỉ. Người mới nên biết đây là các cách mô tả và mã hóa dữ liệu có cấu trúc, rồi học riêng khi cần đọc giao thức đó. Không cần đưa định nghĩa cú pháp trừu tượng, PPDU và các dịch vụ OSI chi tiết lên trước ví dụ chữ, JSON và HTTPS.

Ghi nhớ sau bài học

• Encoding giúp biểu diễn; nén giúp giảm dung lượng; mật mã hóa bảo vệ bí mật theo cơ chế dùng khóa.
• JSON và UTF-8 giải quyết hai phần khác nhau của trao đổi dữ liệu.
• HTTPS không tự chứng minh nội dung website đáng tin hoặc ứng dụng không có lỗi.
• Phiên đăng nhập, tầng phiên OSI và kết nối TCP không đồng nhất.
• Quan sát cookie cần chú ý tên và thuộc tính; giá trị phiên là dữ liệu cần giữ kín.

Tài liệu đối chiếu và đọc thêm

• UTF-8
• Định dạng JSON
• TLS 1.3
• MDN: TLS
• MDN: HTTP cookies