HTTP/1.1 vs HTTP/2

Thông điệp dạng text và frame nhị phân biểu diễn cùng một công việc

HTTP/1.1 dùng cấu trúc thông điệp dạng text với dòng yêu cầu hoặc trạng thái, các trường và cơ chế đóng khung phần thân thông điệp. Đặc tả thông điệp HTTP/1.1 định nghĩa cách bên nhận phân tích cú pháp các thông điệp đó và xác định ranh giới của chúng. Kết nối kéo dài (persistent) cho phép nhiều hơn một yêu cầu trên một kết nối.

HTTP/2 biểu diễn giao tiếp bằng các frame nhị phân và các luồng. Đặc tả đóng khung và luồng HTTP/2 định nghĩa cách ánh xạ thông điệp lên cấu trúc đó. Biểu diễn nhị phân không làm cho các giá trị ứng dụng đúng hơn; nó chỉ thay đổi cách giao thức truyền tải chúng.

Giữ ranh giới biểu diễn tách biệt với payload của ứng dụng. Một phản hồi JSON có thể truyền qua bất kỳ phiên bản nào. Một lỗi phân tích cú pháp trong JSON đó không thể được giải thích chỉ bởi sự hiện diện của các frame HTTP/2 trên đường truyền. Chẩn đoán đóng khung truyền tải, giải mã biểu diễn và kiểm tra schema nghiệp vụ như các giai đoạn riêng biệt, mỗi giai đoạn có kết quả quan sát được riêng.

Ghép kênh làm giảm ràng buộc thứ tự phản hồi ở tầng HTTP

Ghép kênh HTTP/2 cho phép frame từ các luồng khác nhau chia sẻ một kết nối. Một phản hồi dài không cần chiếm toàn bộ chuỗi phản hồi ở tầng ứng dụng trước khi một luồng khác có thể tiến triển. Trong HTTP/1.1, các phản hồi pipelined trên một kết nối phải tuân theo thứ tự yêu cầu, và client thường dùng nhiều kết nối để làm việc đồng thời.

Khác biệt này có thể giúp một khối lượng công việc yêu cầu nhiều tài nguyên từ cùng một origin. Nó không có nghĩa là công việc song song không giới hạn là miễn phí. Máy chủ công bố các giới hạn, các luồng chia sẻ năng lực truyền tải, và ứng dụng có thể có các nút thắt cổ chai riêng. Tôn trọng cơ chế điều khiển luồng và hành vi song song của cả client và server.

Đối với một collector, hãy tách biệt độ đồng thời HTTP với độ đồng thời tác vụ nghiệp vụ. Nhiều luồng hoàn thành nhanh vẫn có thể đẩy vào một giai đoạn trích xuất hoặc cơ sở dữ liệu không theo kịp. Đo lường toàn bộ đường đi của hàng đợi trước khi tăng khối lượng công việc đồng thời. Truyền nhanh hơn vào một giai đoạn xử lý đang tắc nghẽn có thể làm tăng áp lực bộ nhớ mà không cải thiện tốc độ ghi nhận hợp lệ.

HPACK nén header thay vì phần thân phản hồi

HTTP/2 dùng HPACK để mã hóa các trường header một cách hiệu quả. Định dạng nén header HPACK định nghĩa các bảng tĩnh và động cùng các quy tắc mã hóa. Thông tin header lặp lại có thể được biểu diễn cô đọng hơn so với việc gửi đi cùng các trường dạng text nhiều lần.

Nén header tách biệt với nén phần thân phản hồi. Máy chủ có thể nén HTML hoặc JSON thông qua content encoding bất kể sự khác biệt giữa biểu diễn header và mã hóa payload. Hãy so sánh riêng các lớp đó khi đo số byte được truyền.

Đừng cho rằng mọi phản hồi đều được lợi như nhau. Một yêu cầu nhỏ lặp lại với nhiều header chung đáng kể sẽ có đặc tính khác với một phần thân phản hồi lớn với rất ít header có thể tái sử dụng. Nếu một trung gian thay đổi kết nối, ngữ cảnh nén thuộc về kết nối đó thay vì tự động được mang theo trên toàn bộ đường đi. Theo dõi chặng đo được và tránh gán toàn bộ số byte tiết kiệm được cho một tính năng.

TCP Vẫn Ghép Việc Giao Hàng Giữa Các Luồng HTTP/2

HTTP/2 ghép kênh các luồng ứng dụng nhưng không loại bỏ hành vi giao hàng có thứ tự của TCP. Nếu dữ liệu tầng truyền tải bị thiếu làm chậm việc giao các byte đến sau, nhiều luồng trên cùng một kết nối TCP có thể bị ảnh hưởng. Đây là lý do tại sao ghép kênh ở tầng ứng dụng và hành vi head-of-line ở tầng truyền tải cần được giải thích riêng.

Tác động phụ thuộc vào điều kiện mạng và tải công việc. Một kết nối ổn định mang nhiều tài nguyên nhỏ có thể được lợi đáng kể từ việc chia sẻ dung lượng. Một kết nối gặp mất mát có thể thể hiện những đánh đổi khác nhau. Không quan sát nào chứng minh được rằng một giao thức luôn thắng trên mọi đường truyền.

Tránh chẩn đoán vấn đề truyền tải chỉ từ một yêu cầu chậm. Thu thập phiên bản đã đàm phán, việc tái sử dụng kết nối, các giai đoạn thời gian và các quan sát máy chủ liên quan khi có thể. Một truy vấn ứng dụng chậm, một tra cứu DNS bị trễ và mất mát truyền tải đều có thể tăng thời gian trôi qua trong khi cần những cách khắc phục khác nhau. Giữ kết luận giới hạn trong bằng chứng mà phép đo của bạn thực sự ghi nhận.

Ngữ Nghĩa HTTP và TLS Là Các Lớp Tách Biệt

Các phương thức HTTP và ý nghĩa mã trạng thái được áp dụng xuyên suốt các phiên bản. Các ngữ nghĩa HTTP không phụ thuộc phiên bản cung cấp mô hình dùng chung. Chuyển sang HTTP/2 không giải quyết được thông tin xác thực không hợp lệ, không biến một tài nguyên bị cấm thành được cho phép, hay khẳng định rằng phần thân phản hồi chứa dữ liệu như mong đợi.

TLS là một lớp khác. Các triển khai HTTPS thường đàm phán HTTP/2 thông qua các cơ chế TLS, nhưng khung nhị phân của giao thức tự nó không phải là mã hóa. Hãy mô tả tính bí mật và xác thực theo cấu hình TLS và ứng dụng liên quan thay vì coi số phiên bản là một thuộc tính bảo mật đầy đủ.

Khả năng tương thích cần được kiểm tra trong chính client và đường triển khai thực tế. Một máy chủ có thể hỗ trợ HTTP/2 trong khi một bản build thư viện cụ thể hoặc trung gian lại dùng HTTP/1.1. Giữ lại giao thức đã quan sát cùng với chi tiết môi trường. Một ô chọn tính năng trên origin không chứng minh được giao thức nào đã mang một yêu cầu cụ thể.

Lập Sơ Đồ Mọi Chặng Trong Quy Trình Proxy Hoặc Nhà Cung Cấp

Một trung gian tạo ra nhiều mối quan hệ giao thức thay vì một nhãn phiên bản đầu-cuối duy nhất. Client của bạn có thể đàm phán một phiên bản với proxy hoặc nhà cung cấp API trong khi dịch vụ đó dùng một kết nối khác tới đích. Một đường hầm CONNECT tạo thêm sự phân biệt giữa truyền tải của proxy và lưu lượng bên trong đường hầm.

Đối với Scrapeless Web Unlocker, hãy phân biệt yêu cầu tới API với việc nhà cung cấp truy xuất mục tiêu. Đừng suy diễn hành vi giao thức mục tiêu không được ghi tài liệu từ phiên bản quan sát được trên kết nối client của bạn. Phần thảo luận về các tầng truyền tải trong thu thập dữ liệu web cung cấp bối cảnh liên quan để tách các chặng trên đường đi của một yêu cầu.

Sử dụng Scrapeless pricing hiện tại khi lập kế hoạch dùng nhà cung cấp và đo lường kết nối client của bạn một cách độc lập. Trạng thái chấp nhận của API và kết quả truy xuất mục tiêu mô tả các ranh giới khác nhau; giao thức đã đàm phán là một quan sát bên cạnh chúng chứ không thay thế cho bên nào.

Đánh Giá Phiên Bản Với Một Tải Công Việc Được Kiểm Soát

Một so sánh hữu ích giữ nguyên nội dung được yêu cầu và tiêu chí chấp nhận. Ghi lại phiên bản và cấu hình client, đích, giao thức đã đàm phán, việc tái sử dụng kết nối, các giai đoạn thời gian và số byte khi bề mặt đo lường cho phép. Tách biệt việc thiết lập kết nối khỏi các yêu cầu lặp lại trên một kết nối đã được thiết lập.

Bao gồm tải công việc quan trọng: một phản hồi API đơn lẻ, một trang với nhiều tài nguyên cùng nguồn, hoặc một chuỗi yêu cầu thu thập. Kết quả cho một hình dạng không nên được khái quát sang hình dạng khác. Kiểm tra tính đầy đủ của đầu ra trước khi so sánh độ trễ để đảm bảo một phản hồi chưa hoàn chỉnh không thắng chỉ vì làm ít việc hơn.

Bắt đầu với các mặc định được hỗ trợ của client và chỉ tinh chỉnh sau khi xác định được một ràng buộc cụ thể. Kiểm tra các giới hạn máy chủ và xử lý ứng dụng song song với các số liệu truyền tải. Quyết định kích hoạt hoặc ưu tiên HTTP/2 nên cải thiện tải công việc được đo mà không làm suy yếu khả năng tương thích hoặc khả năng quan sát. Giữ lại đủ thông tin môi trường để tái tạo phép so sánh sau khi client hoặc máy chủ được cập nhật.

Kết luận

So sánh HTTP/1.1 với HTTP/2 hữu ích nhất khi gắn với một kết nối và tải công việc cụ thể. Hiểu về framing, ghép kênh và nén header, rồi đo đường đi client đã triển khai. Giữ riêng biệt hành vi TCP, TLS, ranh giới nhà cung cấp và tính đúng đắn của ứng dụng. Phiên bản giao thức là bằng chứng về truyền tải, trong khi một phản hồi hợp lệ vẫn là bằng chứng về nhiệm vụ.

Tài liệu tham khảo

• Ranh giới truy xuất Web Unlocker API
• Scrapeless Web Unlocker
• Các tầng truyền tải trong quy trình dữ liệu web