HTTP/HTTPS: nó là gì, giao thức truyền tải dữ liệu và mã hóa TLS

HTTP và HTTPS là gì?

HTTP (HyperText Transfer Protocol) là giao thức lớp ứng dụng của mô hình OSI được thiết kế để truyền tải các tài liệu siêu văn bản và dữ liệu khác trên World Wide Web. Được phát triển bởi Tim Berners-Lee vào năm 1989, HTTP đã trải qua nhiều phiên bản: từ HTTP/0.9 (chỉ yêu cầu GET và phản hồi HTML) đến HTTP/2 và HTTP/3 hiện đại. Giao thức hoạt động theo mô hình yêu cầu-phản hồi: máy khách gửi yêu cầu đến máy chủ, máy chủ xử lý và trả về phản hồi.

HTTPS (HTTP Secure) là phần mở rộng của giao thức HTTP thêm một lớp mã hóa thông qua TLS (Transport Layer Security). HTTPS không phải là một giao thức riêng biệt — nó là sự kết hợp của HTTP và TLS. Dữ liệu được truyền qua HTTPS được mã hóa ở phía máy khách và giải mã ở máy chủ, khiến nó không thể bị chặn hoặc giả mạo. HTTPS cũng cung cấp xác thực máy chủ thông qua chứng chỉ SSL/TLS, đảm bảo rằng máy khách kết nối với máy chủ thực chứ không phải kẻ tấn công.

Sự khác biệt chính giữa HTTP và HTTPS là bảo mật. HTTP truyền dữ liệu dưới dạng văn bản thuần túy: bất kỳ nút mạng nào giữa máy khách và máy chủ đều có thể đọc nội dung của yêu cầu hoặc phản hồi. HTTPS mã hóa toàn bộ nội dung, bao gồm URL, tiêu đề và nội dung yêu cầu, chỉ để lại địa chỉ IP của máy chủ và cổng kết nối hiển thị. Đối với các ứng dụng di động hoạt động qua mạng Wi-Fi công cộng, HTTPS là yêu cầu bảo mật bắt buộc.

HTTP hoạt động như thế nào

HTTP là giao thức không trạng thái (stateless) hoạt động trên TCP/IP. Máy khách thiết lập kết nối TCP với máy chủ (thường trên cổng 80 cho HTTP hoặc 443 cho HTTPS), gửi yêu cầu HTTP, nhận phản hồi HTTP và đóng kết nối (trong HTTP/1.1, kết nối có thể được tái sử dụng). Mỗi tương tác giữa máy khách và máy chủ bao gồm một yêu cầu và một phản hồi. Không trạng thái có nghĩa là máy chủ không lưu trữ thông tin về các yêu cầu trước đó của máy khách — mỗi yêu cầu được xử lý độc lập.

Quy trình tương tác HTTP bao gồm các bước sau:

• Phân giải DNS — trình duyệt hoặc máy khách chuyển đổi tên miền thành địa chỉ IP qua DNS
• Bắt tay TCP — kết nối TCP được thiết lập thông qua bắt tay ba bước (SYN, SYN-ACK, ACK)
• Bắt tay TLS — đối với HTTPS, kết nối được mã hóa được thiết lập thêm (trao đổi chứng chỉ và khóa)
• Yêu cầu HTTP — máy khách gửi phương thức, URL, tiêu đề và tùy chọn nội dung yêu cầu
• Phản hồi HTTP — máy chủ trả về mã trạng thái, tiêu đề và nội dung phản hồi

Một đặc điểm quan trọng của HTTP là tính đẳng năng của phương thức. GET, HEAD, PUT, DELETE và OPTIONS có tính đẳng năng: thực hiện lặp lại cùng một yêu cầu không làm thay đổi trạng thái máy chủ sau lần thực hiện đầu tiên. POST, PATCH và CONNECT không có tính đẳng năng — mỗi lần gọi có thể tạo tài nguyên mới hoặc thay đổi trạng thái. Đối với phát triển di động, hiểu về tính đẳng năng là rất quan trọng: khi gửi lại yêu cầu do lỗi mạng, máy khách phải biết liệu việc lặp lại yêu cầu có an toàn hay không.

HTTPS và mã hóa TLS

HTTPS sử dụng giao thức mật mã TLS (Transport Layer Security) để bảo vệ dữ liệu được truyền. TLS là người kế thừa của SSL (Secure Sockets Layer), được phát triển bởi Netscape vào năm 1995. Các phiên bản SSL 2.0 và 3.0 được coi là lỗi thời và không an toàn; các phiên bản hiện đại TLS 1.2 (phát hành năm 2008) và TLS 1.3 (phát hành năm 2018) được sử dụng rộng rãi. TLS 1.3, đặc biệt, giảm thời gian thiết lập kết nối từ 2 vòng lặp xuống còn 1, tăng tốc đáng kể việc tải trên thiết bị di động.

Quy trình bắt tay TLS bao gồm các giai đoạn sau:

• Client Hello — máy khách gửi danh sách các phiên bản TLS và bộ mật mã được hỗ trợ
• Server Hello — máy chủ chọn phiên bản TLS và bộ mật mã, gửi chứng chỉ SSL/TLS của nó
• Xác minh chứng chỉ — máy khách xác minh chứng chỉ của máy chủ thông qua chuỗi tin cậy đến CA gốc
• Trao đổi khóa — máy khách và máy chủ tạo khóa bí mật chung (khóa phiên)
• Chuyển đổi mật mã — cả hai bên xác nhận chuyển sang giao tiếp được mã hóa

Xác minh chứng chỉ SSL/TLS là bước quan trọng cho bảo mật. Máy khách kiểm tra rằng chứng chỉ: chưa hết hạn, được ký bởi tổ chức chứng thực (CA) đáng tin cậy, khớp với tên miền trong URL và chưa bị thu hồi (qua CRL hoặc OCSP). Trong các ứng dụng di động, nên sử dụng Ghim chứng chỉ (Certificate Pinning) — liên kết với một chứng chỉ máy chủ cụ thể hoặc khóa công khai. Điều này ngăn chặn các cuộc tấn công MITM ngay cả khi CA bị xâm phạm. Tuy nhiên, ghim chứng chỉ đòi hỏi thận trọng: khi chứng chỉ thay đổi, ứng dụng phải được cập nhật trước.

Cấu trúc yêu cầu và phản hồi HTTP

Yêu cầu HTTP bao gồm ba phần: dòng yêu cầu, tiêu đề và nội dung tùy chọn. Dòng yêu cầu chứa phương thức HTTP, URL yêu cầu và phiên bản HTTP. Tiêu đề truyền thông tin meta: loại nội dung, mã thông báo xác thực, cài đặt bộ nhớ đệm. Nội dung chỉ có trong các phương thức truyền dữ liệu (POST, PUT, PATCH) và không có trong GET và DELETE.

Ví dụ về yêu cầu HTTP tới REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Phản hồi HTTP có cấu trúc tương tự: dòng trạng thái với phiên bản HTTP và mã trạng thái, tiêu đề và nội dung. Mã trạng thái là số có ba chữ số xác định kết quả xử lý yêu cầu. Tiêu đề phản hồi bao gồm Content-Type, Content-Length, Cache-Control, Set-Cookie và các tiêu đề khác. Nội dung phản hồi chứa dữ liệu được yêu cầu ở định dạng được chỉ định trong Content-Type (thường là JSON cho API, HTML cho trang web, hình ảnh cho nội dung đa phương tiện).

Tiêu đề đóng vai trò quan trọng trong hoạt động của HTTP. Content-Type và Accept kiểm soát định dạng dữ liệu. Authorization truyền mã thông báo truy cập. Cache-Control quản lý bộ nhớ đệm. Tiêu đề CORS (Access-Control-Allow-Origin) kiểm soát truy cập từ các tên miền khác trong trình duyệt. User-Agent xác định ứng dụng khách. Đối với ứng dụng di động, tiêu đề kiểm soát bộ nhớ đệm đặc biệt quan trọng — chúng giúp giảm lượng dữ liệu truyền và cải thiện hiệu suất trên tín hiệu yếu.

Mã trạng thái HTTP

Mã trạng thái HTTP được nhóm thành năm lớp, được biểu thị bằng chữ số đầu tiên: 1xx (thông tin), 2xx (thành công), 3xx (chuyển hướng), 4xx (lỗi máy khách), 5xx (lỗi máy chủ). Hiểu các mã này là cần thiết để xử lý chính xác các phản hồi trong ứng dụng di động: 2xx có nghĩa là thành công và dữ liệu có thể được hiển thị, 4xx chỉ ra vấn đề với yêu cầu (hiển thị lỗi cho người dùng), 5xx chỉ ra vấn đề máy chủ (thử lại yêu cầu sau).

Đối với ứng dụng di động, xử lý mã 401 Unauthorized đặc biệt quan trọng. Khi nhận được mã này, máy khách nên thử làm mới mã thông báo truy cập bằng Refresh Token và thử lại yêu cầu ban đầu. Nếu làm mới mã thông báo cũng trả về 401, người dùng phải được chuyển hướng đến màn hình đăng nhập. Logic này thường được triển khai trong Interceptor (OkHttp) hoặc trong lớp middleware của máy khách mạng.

HTTP/1.1, HTTP/2 và HTTP/3

HTTP/1.1, được xuất bản năm 1999, vẫn là phiên bản được sử dụng rộng rãi của giao thức. Nhược điểm chính của nó là head-of-line blocking: các yêu cầu đến cùng một máy chủ được thực hiện tuần tự, mỗi yêu cầu đợi yêu cầu trước hoàn thành. Để khắc phục hạn chế này, trình duyệt mở 6-8 kết nối TCP song song đến cùng một tên miền, làm tăng tải máy chủ và tiêu thụ bộ nhớ. HTTP/1.1 cũng truyền tiêu đề dưới dạng văn bản thuần túy và không hỗ trợ server push.

HTTP/2 (2015) giải quyết vấn đề chặn thông qua ghép kênh — nhiều luồng dữ liệu được truyền đồng thời qua một kết nối TCP duy nhất. Máy chủ có thể gửi tài nguyên đến máy khách trước khi máy khách yêu cầu (server push). HTTP/2 cũng nén tiêu đề thông qua HPACK, giảm lượng dữ liệu truyền. Đối với ứng dụng di động, HTTP/2 đặc biệt hữu ích: một kết nối thay thế nhiều kết nối, giảm thời gian bắt tay TLS và tiêu thụ pin.

HTTP/3 (2022) là phiên bản mới nhất của giao thức, sử dụng QUIC (Quick UDP Internet Connections) thay vì TCP. QUIC hoạt động trên UDP, loại bỏ vấn đề head-of-line blocking ở cấp giao thức vận chuyển. HTTP/3 giảm thời gian thiết lập kết nối xuống 0 vòng lặp trong trường hợp tốt nhất (trên các kết nối lặp lại) và 1 vòng lặp ở lần kết nối đầu tiên, nhanh hơn đáng kể so với HTTP/2 với 2-3 vòng lặp. Đối với thiết bị di động, HTTP/3 đặc biệt hiệu quả khi chuyển đổi giữa Wi-Fi và mạng di động — kết nối không bị gián đoạn vì QUIC sử dụng định danh kết nối thay vì địa chỉ IP.

HTTPS trong phát triển di động

Sử dụng HTTPS trong ứng dụng di động không phải là khuyến nghị mà là yêu cầu bắt buộc. Bắt đầu từ Android 9 (API 28) và iOS 9 (ATS — App Transport Security), tất cả các yêu cầu mạng phải sử dụng HTTPS theo mặc định. Các yêu cầu HTTP bị chặn bởi hệ thống và việc cho phép chúng yêu cầu một ngoại lệ rõ ràng trong cấu hình ứng dụng. Google Play Store và App Store từ chối các ứng dụng truyền dữ liệu nhạy cảm qua HTTP, bao gồm mật khẩu, mã thông báo và dữ liệu cá nhân.

Cấu hình HTTPS trong ứng dụng Android bao gồm:

<!-- AndroidManifest.xml — quyền yêu cầu mạng -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — cấu hình HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Trên iOS, cấu hình tương tự được thực hiện thông qua Info.plist với khóa NSAppTransportSecurity. Để gỡ lỗi lưu lượng HTTPS trong ứng dụng di động, các công cụ proxy được sử dụng: Charles Proxy, Proxyman hoặc mitmproxy. Chúng yêu cầu cài đặt chứng chỉ SSL đáng tin cậy trên thiết bị. Trong bản dựng sản xuất, khả năng gỡ lỗi phải bị vô hiệu hóa và Ghim chứng chỉ phải được xác minh là đã cấu hình đúng. Sử dụng OkHttp trên Android với CertificatePinner hoặc TrustManager trên iOS với SecTrustEvaluate là các phương pháp tiêu chuẩn để triển khai ghim chứng chỉ.

Một khía cạnh bảo mật quan trọng của HTTPS trong phát triển di động là Ghim SSL (SSL Pinning). Không có ghim chứng chỉ, ứng dụng tin tưởng bất kỳ chứng chỉ nào được ký bởi CA đã biết. Nếu CA bị xâm phạm, kẻ tấn công có thể chặn lưu lượng của ứng dụng. Ghim chứng chỉ liên kết ứng dụng với một chứng chỉ máy chủ cụ thể hoặc khóa công khai. Khi chứng chỉ máy chủ thay đổi, phải phát hành bản cập nhật ứng dụng, vì vậy ghim chứng chỉ được lên kế hoạch có dự phòng — liên kết với chứng chỉ CA cấp trên hoặc sử dụng nhiều khóa dự phòng.