HTTP/3 là gì? Truyền tải QUIC, lợi ích và giới hạn

Scrapeless Agent Browser cung cấp một môi trường trình duyệt được quản lý dành cho tự động hóa web, trong đó giao thức yêu cầu đích phụ thuộc vào đường kết nối thực tế.

HTTP/3 thay đổi cách ánh xạ tầng truyền tải

HTTP/3 là phiên bản HTTP truyền các thông điệp HTTP qua QUIC, một giao thức truyền tải an toàn được xây dựng trên UDP. Bản đặc tả HTTP/3 định nghĩa cách yêu cầu, phản hồi, thông tin điều khiển và các trường HTTP được ánh xạ lên các luồng QUIC. Thay đổi này chủ yếu nằm bên dưới mô hình tài nguyên quen thuộc của ứng dụng: một URL vẫn định danh một tài nguyên, một phương thức thể hiện ý nghĩa của yêu cầu và một trạng thái mô tả kết quả phản hồi.

HTTP/3 không yêu cầu một ứng dụng phải đổi tên các endpoint của mình hoặc thay JSON bằng một định dạng dữ liệu khác. Một API công khai có thể giữ nguyên các nghiệp vụ kinh doanh trên các phiên bản HTTP khác nhau. Sự phân biệt đó giúp cô lập công việc triển khai. Hỗ trợ truyền tải thuộc về các client, server và trung gian mang yêu cầu, trong khi phân quyền, kiểm tra hợp lệ, phân trang và schema phản hồi thuộc về hợp đồng ứng dụng.

Việc một website hỗ trợ HTTP/3 cũng không có nghĩa là mọi yêu cầu đều sẽ sử dụng nó. Client phải hỗ trợ giao thức và thương lượng được một kết nối tương thích, và đường truyền mạng phải cho phép loại lưu lượng này. Một trình duyệt có thể sử dụng các phiên bản giao thức khác nhau cho các origin khác nhau trên cùng một trang. Hãy coi hỗ trợ là một khả năng, và giao thức được quan sát trên yêu cầu là bằng chứng của việc sử dụng thực tế.

QUIC bổ sung các luồng tin cậy phía trên UDP

QUIC cung cấp quản lý kết nối, chuyển giao luồng tin cậy, điều khiển luồng và điều khiển tắc nghẽn trên nền UDP. Bản thân UDP không cung cấp dịch vụ luồng byte tin cậy có thứ tự như quen thuộc từ TCP. Bản đặc tả truyền tải QUIC định nghĩa các cơ chế bổ sung đó, bao gồm nhiều luồng trong một kết nối. Do đó, gọi HTTP/3 chỉ đơn thuần là lưu lượng UDP không tin cậy sẽ bỏ qua tầng truyền tải thực sự mang trao đổi HTTP.

Dữ liệu trong một luồng QUIC được chuyển giao theo đúng thứ tự. Các luồng khác nhau có thể tiến triển độc lập khi mất gói chỉ ảnh hưởng tới dữ liệu của một luồng. Điều này làm giảm hiện tượng chặn truyền tải chéo luồng có thể xảy ra khi nhiều luồng HTTP/2 chia sẻ cùng một luồng byte TCP. Nó không loại bỏ độ trễ mạng hoặc đảm bảo rằng mọi tài nguyên đều sẽ hoàn thành sớm hơn trong mọi khối công việc.

Các kết nối vẫn chia sẻ năng lực mạng hữu hạn. Điều khiển tắc nghẽn có thể giảm tốc độ khả dụng cho mọi luồng, và điều khiển luồng ở cấp kết nối có thể hạn chế tổng lượng truyền tải. Ứng dụng cũng có thể phụ thuộc vào một phản hồi trước khi có thể diễn giải phản hồi khác. Một trang không thể render cho đến khi một script đến nơi vẫn có thể bị chậm nhìn thấy được ngay cả khi các tài nguyên khác tiếp tục được tải xuống trên các luồng độc lập.

HTTP/3 khác HTTP/2 như thế nào

HTTP/2 ghép kênh nhiều luồng HTTP trên TCP, trong khi HTTP/3 ánh xạ chúng lên QUIC. Cả hai phiên bản đều giữ nguyên mô hình yêu cầu và phản hồi của ứng dụng. Cách đóng khung, nén và cơ chế kết nối của chúng khác nhau, nên văn bản HTTP/1.1 thuần không phải là hình ảnh đúng nghĩa của biểu diễn trên dây của bất kỳ phiên bản nào. Các công cụ thường trình bày một dạng đã chuẩn hóa để giúp việc kiểm tra giao thức dễ đọc hơn.

Không phiên bản nào tự động làm cho một nguồn dữ liệu trở nên đầy đủ hoặc một phiên trình duyệt được cấp quyền. Một yêu cầu có thể nhận từ chối truy cập trên bất kỳ tầng truyền tải nào. Một phản hồi có thể chứa kết quả ứng dụng rỗng trên bất kỳ phiên bản nào. Hãy tách biệt chẩn đoán truyền tải khỏi việc chấp nhận dữ liệu: kiểm tra body dự kiến và các bản ghi bắt buộc trước khi quyết định rằng một tập hợp đã thành công.

Một so sánh hiệu năng cũng cần các điều kiện tương đương. Giữ nguyên origin, nội dung, môi trường client, trạng thái bộ nhớ đệm và phương pháp quan sát ở mức có thể. Nếu không, một bộ nhớ đệm “ấm” hơn hoặc phản hồi ứng dụng nhanh hơn có thể bị nhầm là cải thiện do giao thức. Hãy báo cáo điều thực sự được đo thay vì trình bày một phần trăm cải thiện tổng quát mà bằng chứng không thể hỗ trợ.

Mã hóa được tích hợp vào QUIC

QUIC sử dụng TLS để thiết lập bảo vệ mật mã như một phần của quá trình thiết lập kết nối. The Tích hợp TLS cho QUIC mô tả mối quan hệ đó. Do đó, HTTP/3 không phải là lưu lượng HTTP được gửi công khai qua một socket UDP. Việc xác thực chứng chỉ và xác thực nguồn gốc vẫn là trung tâm để quyết định liệu máy khách có đang giao tiếp với dịch vụ dự định hay không.

Mã hóa không che giấu mọi thứ về trao đổi khỏi mọi bên tham gia. Máy chủ kết thúc kết nối được bảo vệ và nhìn thấy nội dung ứng dụng. Một trung gian được ủy quyền kết thúc kết nối có thể nhìn thấy nội dung trên chặng đó. Mẫu lưu lượng và thông tin định tuyến cũng có thể vẫn quan sát được. Hãy nêu rõ ranh giới mạng nào đang được bảo vệ khi giải thích các thuộc tính quyền riêng tư của một triển khai.

Một lớp truyền tải an toàn không thể sửa chữa một ứng dụng gửi thông tin xác thực đến sai máy chủ hoặc chấp nhận một yêu cầu không được phép. Hãy giữ nguồn gốc tin cậy, chính sách chứng chỉ và phạm vi thông tin xác thực luôn phù hợp với nhau. Hiện đại hóa giao thức nên đi kèm với các kiểm tra ứng dụng thông thường thay vì trở thành thứ thay thế cho chúng. Bảo mật của một luồng công việc dữ liệu web bao gồm xử lý bí mật, quy tắc ủy quyền và dữ liệu đầu ra được giữ lại cũng như lớp truyền tải mạng của nó.

QPACK Vẫn Có Những Thỏa Hiệp Về Phụ Thuộc

QPACK nén các trường HTTP cho HTTP/3 trong khi cho phép xử lý header hoạt động với các luồng độc lập của QUIC. Bản đặc tả nén trường QPACK tách các cập nhật trạng thái nén khỏi các phần trường đã mã hóa tham chiếu đến chúng. Thiết kế đó giải quyết môi trường truyền tải nơi các luồng độc lập có thể đến theo các thứ tự khác nhau.

Bộ giải mã vẫn có thể cần một bản cập nhật bảng động trước khi nó có thể giải mã một phần trường. Do đó QPACK bao gồm các kiểm soát đối với số lượng luồng có thể bị chặn trên trạng thái nén. Hệ quả thực tế hẹp hơn so với khẩu hiệu rằng HTTP/3 loại bỏ mọi chặn: các luồng truyền tải độc lập làm giảm một phụ thuộc cụ thể, trong khi nén và xử lý ứng dụng có thể tạo ra các phụ thuộc khác.

Hầu hết nhà phát triển ứng dụng không cần tự mình triển khai QPACK. Hãy sử dụng triển khai giao thức trong trình duyệt, máy chủ hoặc thư viện đã chọn và quan sát hành vi của nó thông qua các công cụ chẩn đoán được hỗ trợ. Nếu xuất hiện vấn đề về hiệu năng, hãy phân biệt giữa tạo phản hồi chậm với việc truyền gói tin, giải mã trường và dựng ứng dụng. Thay đổi phiên bản giao thức mà không tìm ra độ trễ có thể khiến nút thắt cổ chai thực sự không được chạm tới.

Di Chuyển Kết Nối Có Những Điều Kiện Xác Định

ID kết nối QUIC có thể cho phép một kết nối vẫn nhận diện được khi đường đi mạng thay đổi. Một thiết bị di chuyển giữa các giao diện mạng là một kịch bản hữu ích để hiểu tính năng đó. Việc di chuyển kết nối vẫn phụ thuộc vào hành vi đầu cuối và xác thực đường đi; đó không phải là lời hứa rằng mọi thay đổi mạng tùy ý sẽ giữ được mọi phiên mà không bị gián đoạn.

Hãy tách biệt danh tính kết nối truyền tải khỏi trạng thái ứng dụng đã đăng nhập của một trang web. Cookie, quyền tài khoản và phiên phía máy chủ vẫn xác định ngữ cảnh ứng dụng của người dùng. Một kết nối truyền tải có thể thay đổi trong khi phiên ứng dụng vẫn tiếp tục, và một phiên ứng dụng có thể hết hạn trong khi kết nối mạng vẫn còn. Gỡ lỗi từng lớp với các định danh và bằng chứng thuộc về lớp đó.

Đối với các quan sát tự động, hãy ghi lại liệu tác vụ được chạy từ một môi trường ổn định hay không và liệu một thành phần định tuyến có thay đổi trong quá trình thu thập hay không. Một đường ra khác có thể thay đổi độ trễ và hành vi nguồn gốc một cách độc lập với giao thức. Một báo cáo hữu ích xác định chặng yêu cầu và các điều kiện được đo lường thay vì gán mọi thay đổi cho khả năng di chuyển của QUIC.

Đàm Phán Giao Thức Và Đường Đi Mạng Cần Được Kiểm Tra

HTTP/3 sử dụng khám phá và đàm phán giao thức thay vì một scheme URL công khai mới. Một địa chỉ HTTPS tự thân không thể cho biết phiên bản HTTP được chọn. Máy chủ có thể quảng bá một dịch vụ thay thế, nhưng việc sử dụng thực tế vẫn phụ thuộc vào máy khách và đường đi. Hãy kiểm tra chi tiết yêu cầu của trình duyệt hoặc một công cụ chẩn đoán giao thức phù hợp cho tài nguyên cụ thể đang được xem xét.

Các trung gian làm phức tạp góc nhìn đó. Kết nối từ trình duyệt đến proxy có thể dùng một lớp truyền tải trong khi yêu cầu từ proxy đến origin dùng lớp khác. Công cụ dành cho nhà phát triển của trình duyệt thường mô tả kết nối hiển thị từ phía trình duyệt, điều này có thể không phản ánh giao thức hướng tới origin. Phần thảo luận về truyền tải TCP và UDP mở rộng sự phân biệt này cho các hệ thống dữ liệu web.

Một cấu hình proxy HTTP thông thường cũng không nên được coi là hỗ trợ tự động cho lưu lượng UDP tùy ý. Hãy kiểm tra hợp đồng proxy và đường hầm thực tế trước khi dự đoán liệu HTTP/3 có thể được sử dụng đầu cuối hay không. Khi một mạng không cho phép đường đi cần thiết, hãy ghi lại giao thức đã được đàm phán và đánh giá tác vụ dựa trên hành vi đã quan sát đó.

HTTP/3 Có Ý Nghĩa Gì Đối Với Tự Động Hóa Trình Duyệt

Tự động hóa trình duyệt thường hoạt động phía trên lớp truyền tải, thông qua điều hướng trang và tương tác. Scrapeless Agent Browser cung cấp một trình duyệt đám mây cho quy trình đó. Phần tổng quan về tự động hóa trình duyệt thiết lập môi trường trình duyệt, trong khi giao thức thực tế được dùng cho một yêu cầu mục tiêu cần được quan sát riêng. Bài viết này không tuyên bố có bảo đảm HTTP/3 cấu hình được cho một phiên Scrapeless cụ thể.

Kết nối điều khiển tự động hóa của trình duyệt cũng khác biệt với kết nối đến trang web mục tiêu. Một kênh điều khiển có thể vẫn khỏe mạnh trong khi trang nhận lỗi ứng dụng. Hãy giữ riêng bằng chứng cho việc thực thi lệnh, hoàn tất yêu cầu và nội dung trang được chấp nhận. Một lệnh điều hướng thành công tự thân không thể khẳng định rằng các bản ghi mong đợi đã được trả về hoặc chặng đến origin đã dùng HTTP/3.

Xem lại bảng giá Scrapeless khi ước tính chi phí khối lượng công việc của trình duyệt, hãy xác định thành công của tác vụ bằng nội dung của trang và các điều kiện hoàn tất. HTTP/3 có thể cải thiện hành vi truyền tải trong các điều kiện phù hợp, nhưng bộ thu thập vẫn cần điều hướng được giới hạn, bộ chọn chính xác, quyền truy cập đã được ủy quyền và xác thực dữ liệu. Những yêu cầu đó vẫn giữ nguyên bất kể phiên bản HTTP được thương lượng là gì.

Kết luận

HTTP/3 giữ nguyên mô hình ứng dụng của HTTP trong khi truyền nó qua QUIC. Hãy đánh giá các luồng độc lập, mã hóa và thương lượng như các thuộc tính truyền tải, sau đó kiểm tra đường đi thực tế mà yêu cầu của bạn đã thực hiện. Một quy trình trình duyệt đáng tin cậy đo lường giao thức đã thương lượng và nội dung đã chấp nhận một cách riêng biệt, để các cải tiến truyền tải không che mờ các vấn đề về quyền hạn hoặc chất lượng bộ dữ liệu.