GIỚI THIỆU
Kể từ lần đầu được giới thiệu vào thập niên 90 cho đến nay, giao thức HTTP không ngừng được phát triển và đóng vai trò quan trọng trong thế giới Internet. HTTP hoạt động dựa trên mô hình máy khách - máy chủ. Trong mô hình này, máy tính người dùng đóng vai trò làm máy khách, sau một thao tác của người dùng, máy khách sẽ thực hiện một giao thức HTTP gửi yêu cầu đến máy chủ và chờ đợi phản hồi từ máy chủ. Hiện tại, web chủ yếu áp dụng HTTP/1.1 và HTTP/2. Trong khi đó, HTTP/3 hiện chỉ được khoảng 5% trang web sử dụng và chưa được các trình duyệt web hỗ trợ đầy đủ.
Trong nỗ lực cải thiện tốc độ cho mạng, Google đã nghiên cứu một giao thức mạng thử nghiệm có tên QUIC (Quick UDP Internet Connections). QUIC không dựa trên TCP, thay vào đó sử dụng giao thức “đối lập” là UDP. Phiên bản 3 của giao thức HTTP (HTTP/3) dựa trên QUIC được đánh giá sẽ là sự thay thế cho các phiên bản HTTP hiện nay.
QUIC là một giao thức truyền tải Internet đem đến rất nhiều cải tiến về thiết kế để tăng tốc lưu lượng cũng như làm cho HTTP bảo mật hơn. Các tính năng của giao thức QUIC bao gồm [1]: Giảm đáng kể thời gian thiết lập kết nối; cải thiện kiểm soát tắc nghẽn; ghép kênh mà không chặn HOL; sửa lỗi chuyển tiếp; di chuyển kết nối.
CÁC THÀNH PHẦN CỦA GIAO THỨC QUIC
Hình 1 dưới đây mô tả các thành phần của giao thức QUIC.
Hình 1. Các thành phần của giao thức QUIC
Trong đó:
- Lớp ứng dụng QUIC: bao gồm các tính năng kiểm soát luồng.
- Lớp TLS: cung cấp cơ chế trao đổi khóa.
- Lớp truyền tải QUIC: cung cấp khả năng truyền dữ liệu đáng tin cậy (phát hiện mất gói) và kiểm soát tắc nghẽn.
- Lớp bảo vệ gói QUIC: các ứng dụng QUIC gửi dữ liệu dưới dạng các khung trong các gói QUIC được mã hóa bởi thành phần bảo vệ gói QUIC. QUIC định nghĩa sáu kiểu gói dữ liệu, bao gồm:
+ Gói có tiêu đề dài: Initial; Version Negotiation; 0-RTT; Handshake; Retry.
+ Gói có tiêu đề ngắn: 1-RTT.
Lớp ứng dụng QUIC
Lớp ứng dụng QUIC bao gồm các tính năng kiểm soát luồng tương ứng với tính năng của giao thức HTTP/2.
Các giao thức ứng dụng trao đổi thông tin qua một kết nối QUIC thông qua các chuỗi byte có thứ tự được gọi là luồng. QUIC sử dụng một lược đồ dựa trên giới hạn để giới hạn việc tạo luồng và giới hạn số lượng dữ liệu có thể được gửi [2]. Số lượng dữ liệu trong QUIC được kiểm soát trên từng luồng riêng lẻ và trên toàn bộ kết nối. Bên cạnh đó, để hạn chế sự đồng thời trong một kết nối, đầu cuối QUIC còn kiểm soát số luồng tích lũy tối đa mà bên giao tiếp có thể khởi tạo:
- Bên nhận gửi cho bên gửi các khung MAX_ STREAM_DATA cùng với ID luồng tương ứng để thông báo giá trị tối đa cho một luồng hoặc MAX_ DATA để thông báo giá trị tối đa của tất cả các luồng.
- Giới hạn số luồng đến tích lũy mà một bên ngang hàng có thể mở ban đầu được thiết lập trong các tham số truyền tải. Các giới hạn tiếp theo được thông báo bằng cách sử dụng các khung MAX_STREAMS.
Lớp TLS
QUIC cung cấp tính bảo mật và tính toàn vẹn của các gói tin thông qua giao thức TLS 1.3 như được mô tả trong [3].
TLS 1.3 giới thiệu cơ chế bắt tay hoàn toàn mới giúp rút ngắn thời gian mã hóa một kết nối. Các chế độ của giao thức bắt tay trong TLS 1.3 bao gồm bắt tay 1-RTT đầy đủ và bắt tay 0-RTT.
Bắt tay 1-RTT
Hình dưới đây minh họa quá trình bắt tay đầy đủ 1-RTT trong TLS 1.3 [4].
Hình 2. Bắt tay 1-RTT trong TLS 1.3
Quá trình bắt tay chia làm ba giai đoạn:
1. Trao đổi khóa: Thiết lập nguyên liệu khóa được chia sẻ và lựa chọn các tham số mật mã. Tất cả các thông báo sau giai đoạn này đều được mã hóa.
2. Thiết lập tham số máy chủ: Thiết lập các tham số bắt tay khác (máy khách có được xác thực hay không, hỗ trợ giao thức tầng ứng dụng nào…).
3. Xác thực: Xác thực máy chủ (và có thể cả xác thực máy khách nếu được yêu cầu) đồng thời cung cấp xác nhận khóa và tính toàn vẹn của bắt tay.
Bắt tay 0-RTT
Khi máy khách và máy chủ chia sẻ một khóa chia sẻ trước (Pre-Shared Key - PSK) lấy từ bên ngoài hoặc thông qua một lần bắt tay trước đó, TLS 1.3 cho phép máy khách gửi dữ liệu trong lần trao đổi đầu tiên (early data). Trong đó, PSK được sử dụng để xác thực trình chủ và mã hóa dữ liệu ban đầu. Phần còn lại của quá trình bắt tay tương tự như bắt tay 1-RTT.
Trong QUIC, ngoài thỏa thuận các tham số mật mã, quá trình bắt tay còn mang và xác thực các giá trị cho các tham số truyền tải.
Bộ mã trong TLS 1.3
TLS 1.3 đã loại bỏ một số chế độ và thuật toán mật mã yếu, chỉ giữ lại năm bộ mã bao gồm [4]:
- TLS_AES_256_GCM_SHA384.
- TLS_CHACHA20_POLY1305_SHA256.
- TLS_AES_128_GCM_SHA256.
- TLS_AES_128_CCM_8_SHA256.
- TLS_AES_128_CCM_SHA256.
Lớp truyền tải QUIC
QUIC cung cấp thông tin phản hồi cần thiết để thực hiện truyền đáng tin cậy và kiểm soát tắc nghẽn.
Phát hiện mất gói dựa trên xác nhận
Phát hiện mất gói dựa trên xác nhận tương tự như ý tưởng các thuật toán của TCP. Một gói được coi là bị mất nếu nó đáp ứng tất cả các điều kiện sau [5]:
- Gói chưa được xác nhận, đang được truyền và được gửi trước một gói đã được xác nhận.
- Gói đã được gửi trước một gói đã được xác nhận một số lượng gói nhất định (ngưỡng gói) hoặc đã được gửi một thời gian đủ lâu (ngưỡng thời gian).
Kiểm soát tắc nghẽn
Không giống như trong TCP, QUIC có thể phát hiện việc mất các gói chỉ chứa các khung ACK và sử dụng thông tin đó để điều chỉnh bộ điều khiển tắc nghẽn. Bộ điều khiển tắc nghẽn được mô tả trong [5] có ba trạng thái riêng biệt: khởi động chậm; khôi phục và tránh tắc nghẽn. Quá trình chuyển đổi giữa ba trạng thái được minh họa trong Hình 3.
Hình 3. Các trạng thái kiểm soát tắc nghẽn
Lớp bảo vệ gói QUIC
Không giống như TLS qua TCP, các ứng dụng QUIC không gửi dữ liệu dưới dạng các bản ghi Dữ liệu ứng dụng TLS, mà gửi dưới dạng các khung trong các gói QUIC được mã hóa bởi thành phần bảo vệ gói QUIC.
Cơ chế bảo vệ gói chung
Các gói QUIC có các mức bảo vệ bằng mật mã khác nhau dựa trên kiểu gói: - Các gói Version Negotiation không được bảo vệ bằng mật mã. - Các gói Retry sử dụng một hàm mã hóa có xác thực với dữ liệu liên kết (AEAD) để bảo vệ khỏi sự sửa đổi ngẫu nhiên. - Các gói Initial sử dụng một hàm AEAD, các khóa được dẫn xuất từ trường Destination Connection ID của gói Initial đầu tiên được gửi bởi máy khách.
Tất cả các gói tin khác được bảo vệ bằng các khóa được dẫn xuất từ quá trình bắt tay mật mã [3]. Bắt tay mật mã đảm bảo rằng chỉ các đầu cuối giao tiếp nhận được các khóa tương ứng cho các gói Handshake, 0-RTT và 1-RTT. Các gói được bảo vệ bằng khóa 0-RTT và 1-RTT có tính bảo mật và tính toàn vẹn cao. Quy trình bảo vệ gói tin tương tự được áp dụng cho các gói tin Initial. Tuy nhiên, vì việc xác định các khóa được sử dụng cho các gói Initial là rất đơn giản, các gói này không được coi là có tính bảo mật hoặc tính toàn vẹn. Các gói tin Retry sử dụng một khóa cố định và do đó cũng thiếu tính bảo mật và tính toàn vẹn.
Bảo vệ tiêu đề
Sau khi áp dụng bảo vệ gói tin, một số trường của tiêu đề gói QUIC như trường Packet Number cùng với bit Reversed Bits, trường Packet Number Length và bit Key Phase cũng được bảo vệ bằng cách sử dụng một khóa được dẫn xuất riêng từ khóa bảo vệ gói và vector khởi tạo.
Cùng một khóa bảo vệ tiêu đề được sử dụng trong suốt thời gian kết nối, ngay cả sau khi cập nhật khóa.
ĐÁNH GIÁ HIỆU NĂNG CỦA GIAO THỨC QUIC
Mô hình thử nghiệm
Mô hình được sử dụng để đánh giá hiệu năng của giao thức QUIC, được minh họa như trong Hình 4, bao gồm hai máy tính (Host1, Host2) được kết nối với nhau thông qua đường truyền 100Mbps, trong đó “Host1” chứa các máy chủ triển khai HTTP2/TCP, HTTP3/ QUIC; “Host2” chứa các máy khách triển khai HTTP2/ TCP, HTTP3/QUIC. Các máy tính sử dụng hệ điều hành Ubuntu 18.04 LTS và được cài đặt sẵn docker.
Hình 4. Mô hình đánh giá hiệu quả giao thức QUIC
Để đánh giá hiệu suất của HTTP3/QUIC, một tệp khá lớn (150MB) được tải từ máy chủ về máy khách trong các điều kiện khác nhau: điều kiện lí tưởng (Kịch bản 1); điều kiện mạng không lí tưởng (gói tin gửi đi bị mất, Kịch bản 2) và điều kiện số luồng dữ liệu TCP tăng lên (Kịch bản 3).
Các bộ phần mềm cho máy chủ và máy khách được sử dụng trong các kịch bản thử nghiệm như sau: HTTP2 sử dụng máy chủ Nginx và máy khách sử dụng Curl; HTTP3/QUIC sử dụng các triển khai từ Nginx; Ngtcp2.
Kết quả triển khai kịch bản thử nghiệm
Kết quả triển khai kịch bản 1
Bảng 1. Băng thông HTTP3/QUIC so với HTTP2/TCP trong điều kiện lí tưởng
Như vậy, cả hai giao thức đều đạt băng thông rất cao trên môi trường mạng 100Mbps, tuy nhiên, băng thông tối đa mà giao thức HTTP2 có thể đạt được cao hơn so với các triển khai của giao thức HTTP3 được sử dụng.
Kết quả triển khai kịch bản 2
Bảng 2. Băng thông HTTP3/QUIC so với HTTP2/TCP trong điều kiện mất gói 3%
Bảng 3. Băng thông HTTP3/QUIC so với HTTP2/TCP trong điều kiện mất gói 5%
Kết quả triển khai kịch bản 3
Bảng 4. Tính cạnh tranh giữa luồng QUIC và TCP
Như vậy, khi số luồng TCP tăng lên, luồng HTTP3/QUIC có băng thông vượt trội hơn so với các luồng HTTP2/TCP. Điều đó minh chứng hiệu quả cạnh tranh luồng của HTTP3/QUIC so với HTTP2/TCP.
KẾT LUẬN
Bảo mật tăng cường của QUIC được cung cấp bởi TLS phiên bản 1.3 mã hóa cho tất cả các thông báo ngay sau thông báo ServerHello, đồng thời chỉ sử dụng các chế độ và thuật toán mật mã đủ mạnh. Hiệu suất mạng của QUIC được cải thiện thông qua các thuật toán giúp phát hiện mất gói và kiểm soát tắc nghẽn hiệu quả của lớp truyền tải QUIC. Ngoài ra, vì QUIC không được tích hợp trong không gian nhân của hệ điều hành mà được phát triển như một giao thức truyền tải lớp ứng dụng giúp áp dụng nhanh chóng, bất kỳ cập nhật nào của giao thức cũng chỉ đòi hỏi thay đổi mã ứng dụng chứ không yêu cầu các thay đổi phức tạp trong nhân hệ điều hành.
TÀI LIỆU THAM KHẢO [1]. Barry Pollard, “HTTP/2 In Action”, 2019. [2]. RFC9000, QUIC: A UDP-Based Multiplexed and Secure Transport, 2021. [3]. RFC9001, Using TLS to Secure QUIC, 2021. [4]. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, 2018. [5]. RFC9002, QUIC Loss Detection and Congestion Control. |