HTTP/1.1 so với HTTP/2: Đóng khung, Đa phương tiện và Hiệu suất

Giới thiệu

HTTP/1.1 và HTTP/2 mang cùng một ngữ nghĩa ứng dụng qua các định dạng dây khác nhau. Một GET vẫn là một GET, mã trạng thái giữ nguyên ý nghĩa, và URIs xác định cùng một tài nguyên. Thay đổi lớn là cách mà các thông điệp chia sẻ một kết nối.

HTTP/1.1 tuần tự hóa các thông điệp văn bản trên mỗi kết nối. HTTP/2 tách các thông điệp thành các khung nhị phân được gán cho các luồng, cho phép nhiều giao dịch tiến triển trên một kết nối. Điều này loại bỏ một số giới hạn lập lịch ở cấp HTTP, nhưng cả hai phiên bản vẫn phụ thuộc vào TCP và do đó chia sẻ một số hành vi vận chuyển.

Thông điệp Văn bản so với Khung Nhị phân

HTTP/1.1 định nghĩa một dòng bắt đầu, các trường văn bản, một dòng trống và nội dung tùy chọn. Độ dài thông điệp được xác định qua các quy tắc như Content-Length, mã hóa chuyển giao, đóng kết nối, hoặc ngữ nghĩa phương thức và trạng thái. Lỗi phân tích có thể mất đồng bộ một kết nối nếu các triển khai không đồng ý về các ranh giới.

RFC 9112 định nghĩa thông điệp HTTP/1.1.HTTP/2 thay thế cú pháp dây văn bản đó bằng các khung nhị phân kiểu. Các khung HEADERS và DATA mang thông điệp qua một luồng được đánh số, trong khi các khung điều khiển quản lý cài đặt, dòng chảy và trạng thái kết nối.

Đồng thời và Đa phương tiện

Một kết nối HTTP/1.1 thường bảo tồn thứ tự phản hồi, vì vậy các khách hàng mở nhiều kết nối để đạt được độ song song hoặc sử dụng xếp chồng được kiểm soát cẩn thận. Mỗi kết nối bổ sung có chi phí thiết lập và tài nguyên, và các trình duyệt giới hạn cách họ sử dụng chúng.

HTTP/2 đa phương tiện các luồng qua một kết nối TCP. Một phản hồi chậm không cần phải chặn một phản hồi sau đó ở lớp HTTP vì các khung của chúng có thể xen kẽ. Ghi chép Tài liệu chuẩn HTTP/2 cũng định nghĩa kiểm soát dòng và kết nối theo luồng để người nhận có thể giới hạn lượng dữ liệu đang truyền tải.

Nén Tiêu đề với HPACK

Các yêu cầu web lặp lại tên và giá trị trường như cookie, user agents, loại nội dung và chỉ thị bộ nhớ đệm. HTTP/1.1 gửi dạng văn bản của chúng trên mỗi yêu cầu, chịu sự nén khác chỉ ở các lớp khác nhau.

HTTP/2 sử dụng HPACK để mã hóa danh sách tiêu đề với các bảng tĩnh và động. Các giá trị lặp lại có thể trở thành tham chiếu gọn gàng, trong khi các trường nhạy cảm có thể được đánh dấu để tránh lập chỉ mục. Trạng thái nén thuộc về kết nối, vì vậy các trung gian không thể đơn giản cắt nối các luồng tùy ý mà không tham gia vào giao thức.

Hành vi Đầu dòng TCP

HTTP/2 giải quyết áp lực thứ tự giữa các thông điệp HTTP, nhưng mỗi luồng vẫn chia sẻ một luồng byte TCP đáng tin cậy. Nếu một đoạn TCP bị mất, các byte sau đó không thể được chuyển tới lớp HTTP/2 cho đến khi khoảng trống được sửa chữa, vì vậy các luồng không liên quan có thể tạm dừng cùng nhau.

Sự phân biệt này giải thích lý do tại sao đa phương tiện có giá trị mà không phải là phép thuật. Trên các đường dẫn sạch sẽ và độ trễ thấp, một kết nối ấm là hiệu quả. Dưới tình trạng mất mát, một nhóm các luồng hoạt động có thể chia sẻ một sự cố. HTTP/3 thay đổi ánh xạ vận chuyển sang QUIC để việc phục hồi mất mát có thể được cô lập theo luồng.

Tính tương thích và Đàm phán

Các khách hàng HTTPS thường đàm phán HTTP/2 với ALPN trong quá trình bắt tay TLS. Nếu cả hai bên chọn nó, ứng dụng sử dụng HTTP/2; nếu không nó có thể tiếp tục với HTTP/1.1. Điều này làm cho việc triển khai chủ yếu là một nhiệm vụ cấu hình cạnh, máy chủ và khách hàng thay vì tái thiết kế API.

Các trung gian và khách hàng chuyên biệt cũ có thể chỉ hỗ trợ HTTP/1.1. Giữ cho sự quay trở lại khỏe mạnh, bảo tồn định tuyến Host và quyền chính xác, và xác nhận rằng các công cụ quan sát có thể giải mã phiên bản đã được thương thảo. Hướng dẫn tiến hoá HTTP của MDN đặt các phiên bản trong bối cảnh triển khai của chúng.

Khi nào HTTP/2 Hỗ trợ Nhất

HTTP/2 có xu hướng hỗ trợ các trang và API phát hành nhiều yêu cầu tới cùng một nguồn, lặp lại các tập tiêu đề lớn, hoặc gặp phải chi phí thiết lập kết nối. Nó cũng cung cấp cho các máy chủ một mô hình luồng rõ ràng hơn cho kiểm soát lưu lượng và hủy bỏ.

Một tải xuống lớn đơn lẻ có thể thấy ít lợi ích. Ưu tiên kém, bộ xử lý ứng dụng chậm, thiếu bộ nhớ đệm, nội dung quá lớn hoặc một nguồn gốc bị quá tải có thể chiếm ưu thế trong lợi ích giao thức. Đo lường giao thức đã thương thảo, thời gian đến byte đầu tiên, thời gian truyền, sử dụng lại kết nối, mất mát và độ bão hòa của máy chủ trước khi gán sự thay đổi hiệu suất chỉ cho HTTP/2 mà thôi.

Kế hoạch xác thực HTTP/1.1 so với HTTP/2

Ngữ nghĩa HTTP vẫn ổn định. Các ứng dụng thường không ghi lại các tuyến đường hoặc phương thức cho HTTP/2. Xác thực tuyên bố đó trên toàn bộ đường dẫn sản xuất. Bắt đầu với một trao đổi đại diện nhỏ, ghi lại hành vi đã được đàm phán tại phía khách hàng và cạnh, và xác nhận rằng ứng dụng nhận được các trường, khung, hoặc sự kiện mà nó mong đợi thông qua cùng một cổng, proxy, điểm kết thúc chứng chỉ và chính sách mạng được sử dụng bởi lưu lượng thực.

Biến giả định thiết kế đầu tiên thành một bài tập thất bại: Bật HTTP/2 ở biên TLS. Sau đó xem xét áp lực tài nguyên xung quanh giả định thứ hai: Giữ cho dự phòng HTTP/1.1 được kiểm tra. Một triển khai đúng nên thất bại trong các giới hạn được tài liệu hóa, giải phóng trạng thái kết nối và bộ đệm, và để lại một dấu vết giải thích kết quả mà không phơi bày thông tin xác thực hoặc tải riêng tư.

Các trang nặng tài sản và cổng API kiểm tra các phần khác nhau của thiết kế, vì vậy việc kiểm tra tính tương thích nên bao gồm cả hai hình dạng lưu lượng khi chúng có liên quan. Thêm một trình duyệt hiện tại, một khách hàng không phải trình duyệt, một đường mạng chậm hơn, và người trung gian hỗ trợ lâu nhất. Ghi lại việc chọn phiên bản, tuổi thọ kết nối, tuổi tin nhắn hoặc phản hồi, độ sâu hàng đợi và lý do đóng cho con đường ưu tiên và dự phòng của nó.

Xem xét ngữ nghĩa và vận chuyển như các lớp riêng biệt trong quá trình kiểm tra. Một kết nối thành công không chứng minh rằng ứng dụng đã xử lý đúng thứ tự, ủy quyền, hủy bỏ, bộ nhớ đệm, phát lại, hoặc phục hồi trạng thái. Tương tự, một lỗi ứng dụng không chứng minh rằng giao thức đã được đàm phán thất bại. Gắn thẻ các quan sát với tài nguyên, phạm vi người dùng, hoạt động logic, và định danh kết nối, sau đó so sánh những gì mà mỗi điểm cuối đã tin là đã xảy ra. Sự phân tách này giúp công việc công suất hữu ích hơn: các nhóm có thể thấy liệu độ trễ đến từ việc thiết lập kết nối, truyền tải mạng, hàng đợi, xử lý ứng dụng, tuần tự hóa, hoặc một người nhận chậm. Giữ nội dung riêng tư ra khỏi giám sát thường xuyên trong khi vẫn giữ đủ thông tin về thời gian và dữ liệu kết quả để tái tạo quyết định.

Nơi HTTP/1.1 so với HTTP/2 Xuất Hiện Trong Thực Tế

Danh sách kiểm tra Sản xuất HTTP/1.1 so với HTTP/2

• Bật HTTP/2 ở biên TLS. Chuyển điểm này thành một bài kiểm tra chấp nhận bằng văn bản để những người đánh giá có thể phân biệt hành vi dự định và chi tiết thực hiện ngẫu nhiên.
• Giữ cho dự phòng HTTP/1.1 được kiểm tra. Đặt tên cho thành phần sở hữu cài đặt và người hoặc nhóm đáp ứng khi hành vi quan sát của nó thay đổi.
• Xác nhận đàm phán ALPN trong chẩn đoán. Ghi lại tín hiệu liên quan trong nhật ký hoặc dấu vết, sau đó xác minh rằng tín hiệu tồn tại qua mọi proxy, cổng, và ranh giới dịch vụ trong đường đi thực tế.
• Xóa phân vùng miền chỉ được thêm vào để đáp ứng giới hạn kết nối cũ. Kiểm tra quyết định với một trường hợp bình thường, một đối tác chậm, một kết nối đã đóng, một đầu vào quá lớn, và sự không khớp về phiên bản hoặc khả năng.
• Đo lường tính đồng thời yêu cầu theo nguồn gốc. Tài liệu hóa mặc định an toàn và điều kiện chính xác cho phép một ngoại lệ; các ngoại lệ ẩn trở thành vấn đề tương tác trong các thay đổi sau này.
• Theo dõi luồng và cửa sổ kiểm soát dòng kết nối. Kiểm tra hành vi này từ một trình duyệt hoặc khách hàng đại diện thay vì chỉ dựa vào một bài thử nghiệm đơn vị địa phương hoặc màn hình cấu hình phía máy chủ.
• Giữ kích thước tiêu đề trong giới hạn tài liệu hóa. Đặt giới hạn tài nguyên hữu hạn và làm cho từ chối kết quả trở nên rõ ràng với cả những người điều hành và ứng dụng gọi.
• Xác thực các trung gian với định dạng nhị phân. Bảo tồn đủ định danh để tương quan một trao đổi logic qua khách hàng, cạnh, ứng dụng, và bất kỳ công nhân không đồng bộ nào.
• Tương quan mất gói với sự đình trệ đa luồng. Xem xét lựa chọn sau khi thay đổi hình dạng lưu lượng vì số lượng kết nối, kích thước tải, và tần suất tin nhắn có thể thay đổi thiết kế đúng.
• So sánh tải thực trước và sau khi triển khai. Giữ cho đường dẫn dự phòng có thể quan sát và đã được kiểm tra để đảm bảo tính tương thích không phụ thuộc vào một đường dẫn cũ đã ngừng hoạt động âm thầm.

Kết luận

Chất nghĩa HTTP vẫn giữ ổn định. Các ứng dụng thường không viết lại các tuyến đường hoặc phương thức cho HTTP/2. HTTP/2 không phải là một đảm bảo tốc độ toàn cầu. Hình thái tải, độ trễ, mất mát, điều chỉnh máy chủ và bộ nhớ cache xác định kết quả. Áp dụng hai sự thật đó với giới hạn rõ ràng, trạng thái có thể quan sát và một đường dẫn dự phòng được kiểm tra bởi các khách hàng đại diện thay vì giả định từ cấu hình.

Tài liệu tham khảo

• Tài liệu trình duyệt Scrapeless Scraping
• Tổng quan sản phẩm trình duyệt Scrapeless Scraping
• Hướng dẫn ghi khung WebSocket Scrapeless