HTTP/3 là gì – Giảm tốc độ giao thức dựa trên UDP mới

HTTP/3 được xây dựng dựa trên Giao thức dữ liệu người dùng (UDP) và đã được các công ty internet nổi tiếng như Google và Facebook sử dụng. Nếu bạn đang sử dụng Chrome và kết nối với dịch vụ của Google, có thể bạn đã sử dụng QUIC.

Phiên bản mới của giao thức HTTP được hưởng lợi từ giao thức UDP đơn giản, cấp thấp và xác định nhiều tính năng mới có trong các phiên bản trước của HTTP ở lớp TCP. Điều này cung cấp một cách giải quyết các hạn chế trong cơ sở hạ tầng internet hiện có.

Những kết quả đầu tiên đầy hứa hẹn và khi Bản thảo Internet của IETF hết hạn vào tháng 8 năm 2021, chúng ta có thể mong đợi HTTP/3 sẽ được quảng bá như một tiêu chuẩn HTTP thế hệ thứ ba mới.

Tiến trình HTTP/3 vào năm 2021

Một số ý kiến ​​cho rằng sự khao khát của ngành công nghiệp web về tốc độ cao hơn và độ trễ thấp hơn chỉ khớp với sự khao khát của Google Chrome về nhiều RAM hơn.

HTTP/2 là một tiêu chuẩn mà theo W3Techs, hiện đã đạt khoảng 45% tỷ lệ chấp nhận trên thế giới. Và theo chúng tôi, nó cũng được hỗ trợ bởi tất cả các trình duyệt web hiện đại. Tuy nhiên, chúng tôi đang ở đây, viết một bài về phiên bản tiếp theo của giao thức, HTTP/3.

HTTP/3, tại thời điểm viết bài này, là IETF Internet-Draft hoặc ID, có nghĩa là nó hiện đang được xem xét cho một tiêu chuẩn internet sắp tới bởi Lực lượng Đặc nhiệm Kỹ thuật Internet – một cơ quan tiêu chuẩn internet quốc tế , chịu trách nhiệm xác định và thúc đẩy các tiêu chuẩn giao thức internet đã được thống nhất, chẳng hạn như TCP, IPv6, VoIP, Internet of Things, v.v.

Nó là một cơ quan mở hợp nhất ngành công nghiệp web và tạo điều kiện thuận lợi cho việc thảo luận về hướng đi của internet. Hiện tại, giai đoạn “Dự thảo Internet” của HTTP/3 là giai đoạn cuối cùng trước khi các đề xuất được nâng cấp lên cấp độ Yêu cầu cho nhận xét (hoặc RFC ), mà chúng tôi có thể xem xét, cho tất cả các mục đích và mục đích, định nghĩa giao thức internet chính thức.

Mặc dù HTTP/3 chưa phải là một giao thức Internet chính thức, nhưng nhiều công ty và dự án đã bắt đầu bổ sung hỗ trợ HTTP/3 vào các sản phẩm của họ.

Hỗ trợ trình duyệt web cho HTTP / 3

Về mặt trình duyệt web , Chrome v87, Firefox v88 và Edge v87 đều được bật HTTP / 3 theo mặc định. Đối với người dùng Safari, tùy chọn bật HTTP / 3 đã được thêm vào Safari Technology Preview v104. Tuy nhiên, hỗ trợ HTTP / 3 hiện không khả dụng trong phiên bản ổn định của Safari.

Hỗ trợ thư viện cho HTTP / 3

Đối với các nhà phát triển muốn tận dụng công nghệ HTTP / 3, nhiều thư viện phổ biến đã bổ sung hỗ trợ cho HTTP / 3. Vì HTTP / 3 vẫn đang trong giai đoạn Dự thảo Internet, bạn sẽ muốn đảm bảo rằng mình đã cập nhật các bản cập nhật mới nhất khi làm việc với một trong các thư viện bên dưới.

• Python –  http3 và aioquic
• Rust –  quiche , neqo và quinn
• C –  nghttp3 và lsquic
• Đi –  quicgo
• JavaScript –  Node.js

Hỗ trợ cơ sở hạ tầng cho HTTP / 3

Về mặt cơ sở hạ tầng, Cloudflare đã dẫn đầu với việc hỗ trợ HTTP / 3 trên toàn bộ mạng biên của nó. Điều này có nghĩa là các trang web có bật Cloudflare có thể tận dụng các cải tiến về bảo mật và hiệu suất của HTTP / 3 mà không cần thực hiện thêm bất kỳ công việc nào.

Tại Kinsta, tất cả các trang web chúng tôi lưu trữ đều được bảo vệ bằng tích hợp Cloudflare miễn phí của chúng tôi . Ngoài tường lửa cấp doanh nghiệp và bảo vệ DDoS, khách hàng của Kinsta cũng có quyền truy cập vào HTTP / 3!

Để kiểm tra xem trang web của bạn có hỗ trợ HTTP / 3 hay không, bạn có thể sử dụng Công cụ kiểm tra HTTP/3 của Liteseed. Chỉ cần nhập tên miền của bạn và nhấn nút “Kiểm tra” và công cụ sẽ cho bạn biết liệu trang web của bạn có được bật HTTP/3 hay không.

Nếu trang web của bạn hỗ trợ HTTP/3, bạn sẽ thấy một thông báo như bên dưới. Vì vectorv.net được lưu trữ trên Litespeed Server nên HTTP/3 được hỗ trợ đầy đủ nhờ tích hợp Quic.cloud của chúng tôi.

Bạn cũng có thể sử dụng trình kiểm tra của trình duyệt để kiểm tra hỗ trợ HTTP/3. Đối với ví dụ này, chúng tôi sẽ sử dụng phiên bản Google Chrome mới nhất hỗ trợ HTTP/3.

Để mở trình kiểm tra, nhấp chuột phải vào trang và nhấp vào “Kiểm tra” và điều hướng đến tab “Mạng”. Trong cột “Giao thức”, bạn có thể thấy giao thức HTTP được sử dụng cho kết nối. Kết nối HTTP/2 hiển thị dưới dạng “h2”, trong khi kết nối HTTP/3 xuất hiện dưới dạng “h3” hay “h3-XX” (XX đề cập đến một bản nháp HTTP/3 cụ thể). Như bạn có thể thấy trong hình ảnh bên dưới, vectorv.net hỗ trợ các kết nối qua “h3”.

Bây giờ chúng ta đã xem qua trạng thái hiện tại của HTTP/3, chúng ta hãy đi sâu vào một số điểm khác biệt giữa HTTP/2 và HTTP/3!

Một chút thông tin cơ bản – Bắt đầu với HTTP / 2

HTTP/2 đã mang lại một số cải tiến nghiêm trọng với tải xuống không chặn, pipelining và đẩy máy chủ , điều này đã giúp chúng tôi khắc phục một số hạn chế của giao thức TCP cơ bản. Nó cho phép chúng tôi giảm thiểu số chu kỳ yêu cầu-phản hồi và bắt tay.

HTTP/2 làm cho nó có thể đẩy nhiều tài nguyên trong một kết nối TCP duy nhất – ghép kênh. Chúng tôi cũng linh hoạt hơn trong việc sắp xếp thứ tự tải xuống tĩnh và các trang của chúng tôi giờ đây không còn bị hạn chế bởi tiến trình tải xuống tuyến tính.

Trong thực tế, điều này có nghĩa là bây giờ một tài nguyên javascript lớn không nhất thiết phải bằng điểm cho tất cả các tài nguyên tĩnh khác đang chờ đến lượt của chúng.

Thêm vào những điều này, tiêu đề của HTTP/2 Nén HPACK và định dạng nhị phân mặc định của truyền dữ liệu, và trong nhiều trường hợp, chúng tôi có một giao thức hiệu quả hơn đáng kể.

Việc triển khai trình duyệt chính khiến nó trở thành một yêu cầu đối với các trang web phải triển khai mã hóa – SSL – để có thể thu được lợi ích của HTTP/2 – và đôi khi điều này phát sinh chi phí tính toán khiến việc cải thiện tốc độ không được chú ý. Thậm chí có một số trường hợp người dùng báo cáo bị chậm lại sau khi chuyển sang HTTP/2.

Hãy nói rằng những ngày đầu áp dụng phiên bản này không dành cho những người yếu tim.

Việc triển khai Nginx cũng thiếu tính năng đẩy máy chủ, dựa vào một mô-đun. Và các mô-đun Nginx không phải là các mô-đun thả vào Apache thông thường của bạn mà bạn chỉ có thể sao chép – NGINX phải được biên dịch lại với những mô-đun này.

Mặc dù một số vấn đề này đã được giải quyết ngay bây giờ, nhưng nếu chúng ta nhìn vào toàn bộ ngăn xếp giao thức, chúng ta thấy rằng hạn chế chính nằm ở cấp độ thấp hơn so với HTTP/2 đã dám mạo hiểm.

Để làm rõ điều này, chúng ta sẽ phân tích ngăn xếp giao thức internet ngày nay từ lớp dưới cùng lên trên cùng. Nếu bạn muốn tìm hiểu thêm về nền tảng của HTTP/2, hãy đảm bảo xem hướng dẫn HTTP / 2 cuối cùng của chúng tôi.

Giao thức Internet (IP)

Giao thức Internet (IP) xác định phần dưới cùng của toàn bộ cấu trúc liên kết internet. Chúng ta có thể nói một cách an toàn rằng đó là một phần của mạng lưới internet, thực sự không thể thương lượng nếu không thay đổi mọi thứ, bao gồm thay thế toàn bộ cơ sở hạ tầng phần cứng, từ bộ định tuyến đến máy chủ và thậm chí cả máy móc của người dùng cuối.

Vì vậy, trong khi việc đại tu giao thức có thể đến hạn, một nỗ lực sâu rộng như vậy vẫn chưa được thực hiện tại thời điểm này, chủ yếu là do chúng tôi chưa đưa ra được một giải pháp thay thế khả thi, đột phá nhưng tương thích ngược.

Chúng ta có thể theo dõi sự khởi đầu của giao thức IP từ năm 1974, trong một bài báo được xuất bản bởi Viện Kỹ sư Điện và Điện tử và do Vint Cerf và Bob Cahn tác giả. Nó trình bày chi tiết các gói được gửi qua mạng, định tuyến chúng qua các địa chỉ IP và địa chỉ được xác định bằng số của các nút trong một mạng / mạng. Giao thức xác định định dạng của các gói này, hoặc các gói dữ liệu – tiêu đề và trọng tải của nó.

Sau định nghĩa RFC 760 từ năm 1980, IETF đã giải quyết bằng định nghĩa được sử dụng rộng rãi cho đến ngày nay, trong Yêu cầu cho ý kiến ​​791 . Đây là phiên bản thứ tư của giao thức, nhưng có thể nói đó là phiên bản sản xuất đầu tiên.

Nó sử dụng các địa chỉ 32 bit, điều này đặt ra một hạn chế đối với số lượng địa chỉ là khoảng 4 tỷ. Hạn chế này là lời giải thích cho bí ẩn tại sao người dùng internet không phải doanh nghiệp nhận được “địa chỉ IP động” bởi ISP của họ và IP tĩnh được coi là “giá trị gia tăng” và thường phải trả thêm phí.

Họ đang phân chia khẩu phần.

Không lâu cho đến khi người ta nhận ra rằng địa chỉ 32-bit là không đủ và sự thiếu hụt đang xuất hiện, vì vậy nhiều RFC đã được xuất bản để cố gắng giải quyết vấn đề này. Mặc dù những giải pháp này ngày nay được sử dụng rộng rãi và là một phần của cuộc sống hàng ngày của chúng ta, nhưng có lẽ sẽ an toàn khi nói rằng những giải pháp này với các vụ hack.

Giao thức Internet phiên bản 6 hoặc IPv6 ra đời như một cách để giải quyết những hạn chế này, bao gồm cả việc dần dần được áp dụng so với phiên bản trước. Nó đã được làm tài liệu Dự thảo Tiêu chuẩn cho IETF vào năm 1998 và được nâng lên thành Tiêu chuẩn Internet vào năm 2017.

Mặc dù không gian địa chỉ IPv4 bị giới hạn bởi độ dài địa chỉ 32 bit, nhưng tiêu chuẩn IPv6 được cung cấp 128 bit hoặc 3,4 * 10 ^ 38 địa chỉ có thể. Điều này sẽ đủ để kéo dài chúng ta trong một thời gian khá dài.

Theo kết nối của Google và IPv6 giữa những người dùng của nó, tỷ lệ chấp nhận IPv6 chỉ đạt hơn 35% tính đến tháng 6 năm 2021.

IP là một lớp thô sơ của ngăn xếp internet, xác định hầu hết những thứ cơ bản, không có đảm bảo về phân phối, tính toàn vẹn của dữ liệu hoặc thứ tự của các gói được truyền. Riêng nó thì không đáng tin cậy. Định dạng tiêu đề của IPv4 cung cấp tổng kiểm tra tiêu đề, mà các nút truyền sử dụng để xác minh tính toàn vẹn của tiêu đề. Điều này làm cho nó khác với phiên bản IPv6, dựa vào lớp liên kết bên dưới, cho phép nó nhanh hơn.

Hiểu vai trò của TCP và UDP

Bây giờ đã đến lúc khám phá xem HTTP / 3 phù hợp với TCP và UDP ở đâu.

TCP

Mặc dù IP là lớp cơ bản của tất cả các thông tin liên lạc trực tuyến của chúng ta ngày nay, TCP (Transmission Control Protocol) là một phần cấp cao hơn của bộ giao thức internet, cung cấp độ tin cậy cần thiết cho web, thư, truyền tệp (FTP) – cho các lớp / giao thức ứng dụng của internet.

Điều này bao gồm thiết lập kết nối nhiều bước, với sự bắt tay, thứ tự các gói được đảm bảo và truyền lại các gói bị mất. Nó cung cấp phản hồi (Acks) về việc gửi hàng cho người gửi, v.v. Ngoài ra còn có tính toán tổng kiểm tra để phát hiện lỗi.

Tất cả những điều này chỉ ra rất nhiều bước làm cho TCP trở thành một giao thức đáng tin cậy, làm cho nó trở thành nền tảng của các dịch vụ internet khét tiếng nhất mà chúng ta sử dụng ngày nay.

Đặc điểm kỹ thuật của nó có từ năm 1974 (RFC 675) và 1981 (RFC 793) đã không thay đổi đáng kể cho đến ngày nay.

Tuy nhiên, độ tin cậy mà TCP cung cấp không đi kèm với chi phí. Chi phí của tất cả các bước đi vòng theo yêu cầu bắt tay, phản hồi giao hàng, đảm bảo đặt hàng và tổng kiểm tra có thể được coi là yếu và dư thừa. Nó đã làm cho TCP trở thành nút thắt cổ chai của ngăn xếp giao thức hiện đại. HTTP / 2 đã đạt được một loạt các cải tiến tốc độ có thể đạt được trên TCP.

UDP

User Datagram Protocol (UDP) cũng là một trong những phần của Internet Protocol Suite, với đặc điểm kỹ thuật của nó có từ năm 1980 (RFC 768) .

Như tên cho thấy, nó là một giao thức không kết nối dựa trên datagram. Có nghĩa là không có bắt tay và không có đảm bảo về việc đặt hàng hoặc giao hàng. Điều này có nghĩa là bất kỳ bước nào có thể có để đảm bảo phân phối, tính toàn vẹn của dữ liệu và những thứ khác được để lại cho lớp ứng dụng. Điều này có nghĩa là một ứng dụng xây dựng trên UDP có thể lựa chọn các chiến lược mà nó sẽ sử dụng tùy thuộc vào từng trường hợp cụ thể hoặc có thể tận dụng các yếu tố của lớp liên kết , như tổng kiểm tra, để tránh chi phí.

Vì UDP phổ biến rộng rãi giống như TCP, nên nó có thể đạt được những cải tiến mà không yêu cầu cập nhật chương trình cơ sở trên nhiều thiết bị được kết nối với internet hoặc những thay đổi đáng kể trong hệ điều hành.

Việc triển khai các giao thức mới bị cản trở bởi nhiều tường lửa, NAT, bộ định tuyến và các hộp trung gian khác chỉ cho phép TCP hoặc UDP được triển khai giữa người dùng và máy chủ mà họ cần tiếp cận. 

HTTP/3 giải thích

Chủ đề này trên Hacker News có thể giúp chúng ta bắt đầu hiểu lý do đằng sau việc xây dựng phiên bản HTTP mới trên nền tảng mạng hiện có, thay vì phát minh lại nó (mặc dù còn nhiều điều hơn thế).

Đặc tả định dạng gói UDP khá tối thiểu, tiêu đề của nó bao gồm cổng nguồn, cổng đích, độ dài, tính bằng byte, của tiêu đề gói và dữ liệu gói, và tổng kiểm tra. Checksum có thể được sử dụng để xác minh tính toàn vẹn của dữ liệu cho cả phần tiêu đề và phần dữ liệu của gói.

Checksum là tùy chọn khi lớp giao thức bên dưới là IPv4 và bắt buộc với IPv6. Cho đến nay, UDP đã được sử dụng cho những thứ như đồng bộ hóa đồng hồ hệ thống máy tính ( NTP ), ứng dụng VoIP, phát trực tuyến video, hệ thống DNS và giao thức DHCP .

QUIC và HTTP / 3

QUIC (Kết nối Internet UDP nhanh) được Google triển khai lần đầu tiên vào năm 2012. Nó xác định lại ranh giới của các lớp mạng, dựa trên giao thức UDP cấp thấp hơn, xác định lại các tính năng bắt tay, độ tin cậy và tính năng bảo mật trong “không gian người dùng”, tránh sự cần thiết nâng cấp hạt nhân của hệ thống kết nối internet.

Cũng giống như HTTP/2, một tiến bộ được dẫn đầu bởi SPDY của Google hoặc tốc độ nhanh, HTTP/3 sẽ lại xây dựng dựa trên những thành tựu này.

Mặc dù HTTP/2 đã cung cấp cho chúng tôi khả năng ghép kênh và giảm thiểu việc chặn đầu dòng, nhưng nó lại bị hạn chế bởi TCP. Bạn có thể sử dụng một kết nối TCP duy nhất cho nhiều luồng được ghép lại với nhau để truyền dữ liệu, nhưng khi một trong những luồng đó bị mất gói, toàn bộ kết nối (và tất cả các luồng của nó) sẽ bị giữ làm con tin, có thể nói, cho đến khi TCP thực hiện được nhiệm vụ của nó ( truyền lại gói bị mất).

Điều này có nghĩa là tất cả các gói, ngay cả khi chúng đã được truyền và đang chờ, trong bộ đệm của nút đích, đang bị chặn cho đến khi gói bị mất được truyền lại. Daniel Stenberg trong cuốn sách của mình trên http/3 gọi đây là “khối đầu dòng dựa trên TCP”. Ông tuyên bố rằng, với 2% mất gói, người dùng sẽ làm tốt hơn với HTTP/1, với sáu kết nối để phòng ngừa rủi ro này.

QUIC không bị ràng buộc bởi điều này. Với việc xây dựng QUIC dựa trên giao thức UDP không kết nối, khái niệm kết nối không mang những hạn chế của TCP và các lỗi của một luồng không phải ảnh hưởng đến phần còn lại.

Với việc tập trung vào các luồng UDP , QUIC đạt được khả năng ghép kênh mà không cần phải dựa trên một kết nối TCP. QUIC xây dựng kết nối của nó ở mức cao hơn TCP. Luồng mới trong kết nối QUIC không bị buộc phải đợi những luồng khác kết thúc. Kết nối QUIC cũng được hưởng lợi từ việc loại bỏ chi phí bắt tay TCP, giúp giảm độ trễ.

Các nhân viên tại Cisco đã thực hiện một video thú vị giải thích về cách bắt tay 3 chiều của TCP:

Mặc dù QUIC loại bỏ các tính năng tin cậy của TCP, nó bù đắp cho nó ở trên lớp UDP, cung cấp khả năng truyền lại các gói, sắp xếp thứ tự, v.v. Google Cloud Platform đã giới thiệu hỗ trợ QUIC cho bộ cân bằng tải của họ vào năm 2018 và đã chứng kiến ​​sự cải thiện về thời gian tải trang trung bình 8% trên toàn cầu và lên đến 13% ở các khu vực có độ trễ cao hơn.

Giữa Google Chrome, YouTube, Gmail, tìm kiếm của Google và các dịch vụ khác, Google đã có thể triển khai QUIC trên một phần lớn internet mà không cần đợi IETF. Các kỹ sư của Google tuyên bố rằng trong năm 2017, 7% lưu lượng truy cập internet đã được thực hiện qua QUIC.

Phiên bản QUIC của Google chỉ tập trung vào truyền tải HTTP, sử dụng cú pháp HTTP / 2. Những người từ IETF (những người chịu trách nhiệm chuẩn hóa QUIC), đã quyết định rằng phiên bản IETF của QUIC sẽ có thể truyền tải nhiều thứ hơn là chỉ HTTP. Tuy nhiên, hiện tại, mọi hoạt động trên các giao thức không phải HTTP qua QUIC đều đang bị tạm dừng.

Một điều nữa mà nhóm làm việc của IETF quyết định là phiên bản chuẩn hóa sẽ sử dụng mã hóa TLS 1.3 thay vì giải pháp tùy chỉnh của Google. TLS 1.3, so với các phiên bản cũ hơn, cũng góp phần vào tốc độ giao thức, vì quá trình bắt tay của nó yêu cầu ít vòng tua hơn. Kinsta hỗ trợ TLS 1.3 trên tất cả các máy chủ và Kinsta CDN của chúng tôi.

Hiện tại, Google tiếp tục sử dụng phiên bản QUIC của riêng mình trong sản phẩm của mình, đồng thời hướng các nỗ lực phát triển của mình theo tiêu chuẩn IETF. Hầu hết các trình phát internet khác đang xây dựng trên phiên bản IETF (hai phiên bản này khác nhau ở một số khía cạnh khác ngoài mã hóa).

Nếu chúng tôi mở Công cụ dành cho nhà phát triển của Chrome và tải một số sản phẩm của Google, chẳng hạn như Gmail, trong cột Giao thức của tab Mạng, chúng tôi sẽ thấy nhiều tài nguyên được tải qua phiên bản giao thức QUIC của Google. Đây cũng là trường hợp của các sản phẩm của Google như Analytics, Trình quản lý thẻ của Google, v.v.

Cloudflare đã xuất bản một bản cập nhật rất rộng rãi về tiến trình tiêu chuẩn hóa.

Mặc dù UDP cung cấp cho QUIC và HTTP/3 một số lợi thế vốn có, nhưng nó cũng mang lại một số thách thức.

TCP đã là giao thức chủ đạo trong nhiều năm, trong khi UDP thì không, do đó, hệ điều hành và phần mềm cho nó nói chung không được tối ưu hóa. Do đó, có một số yêu cầu/tải CPU cao hơn nhiều với QUIC, theo một số ước tính, gấp đôi so với HTTP/2.

Tối ưu hóa đi sâu vào hạt nhân của hệ điều hành và các bộ định tuyến và phần mềm thiết bị khác nhau . Đây hướng dẫn điều chỉnh Red Hat có thể làm sáng tỏ hơn về chủ đề này cho những kỹ thuật hơn nghiêng.

Chúng ta có thể nói rằng QUIC cố gắng thiết kế lại các tính năng của TCP trên một giao thức tối thiểu hơn và linh hoạt hơn.

Kết nối QUIC, mà chúng tôi đã đề cập trước đó, kết hợp TLS và chuyển giao bắt tay. Sau khi được thiết lập, chúng được xác định bởi các CID (ID kết nối) duy nhất. Các ID này vẫn tồn tại qua các lần thay đổi IP và có thể giúp đảm bảo quá trình tải xuống không bị gián đoạn, ví dụ: chuyển từ 4G sang WiFi. Điều này có liên quan, đặc biệt là vì ngày càng có nhiều lưu lượng truy cập internet được thực hiện trên các thiết bị di động. Có thể nảy sinh câu hỏi liệu yếu tố này có được Google hình thành để tạo điều kiện cho việc theo dõi người dùng tốt hơn trên các kết nối và nhà cung cấp internet khác nhau hay không.

TLS là bắt buộc và có nghĩa là để các thiết bị ở giữa khó có thể giả mạo hoặc đánh hơi lưu lượng truy cập. Đó là lý do tại sao không hiếm khi thấy các nhà cung cấp và nhà cung cấp tường lửa như Cisco coi giao thức UDP là một vấn đề và đưa ra các cách để vô hiệu hóa nó. Người trung gian khó kiểm tra và giám sát hoặc lọc lưu lượng QUIC.

Luồng QUIC được gửi qua các kết nối QUIC, một chiều hoặc hai chiều. Luồng có ID xác định trình khởi tạo và luồng là một chiều hay hai chiều, đồng thời cũng phục vụ kiểm soát luồng trong luồng.

Trong khi QUIC là một giao thức lớp truyền tải, HTTP là lớp trên đó, một giao thức lớp ứng dụng hoặc giao thức ứng dụng.

Vì khả năng tương thích ngược là điều quan trọng hàng đầu, IETF đã thúc đẩy việc triển khai HTTP / 3 và sẽ bao gồm phiên bản cũ (HTT1 hoặc HTTP / 2) trong phản hồi. Nó sẽ bao gồm một tiêu đề thông báo cho khách hàng rằng HTTP / 3 khả dụng, cùng với thông tin về cổng / máy chủ, như được mô tả trong RFC 7838 .

Điều này khác với HTTP / 2, trong đó việc truyền tải có thể được thương lượng trong quá trình bắt tay TLS . Nhưng vì IETF đã áp dụng tất cả, trừ HTTP / 3 dựa trên QUIC làm tiêu chuẩn tiếp theo, chúng tôi có thể mong đợi các ứng dụng khách web dự đoán hỗ trợ HTTP / 3 ngày càng nhiều hơn. Máy khách có thể lưu dữ liệu vào bộ nhớ cache từ các kết nối HTTP / 3 trước đó và kết nối trực tiếp (zero-round-trip hoặc 0-RTT) trong các lần truy cập tiếp theo vào cùng một máy chủ.

Tóm lược

Có những người nghĩ rằng, với việc tiêu chuẩn HTTP/2 chưa được áp dụng đầy đủ, có thể còn quá sớm để tạo ra một sự thúc đẩy rộng rãi cho HTTP/3. Đây là một điểm hợp lệ, nhưng, như chúng tôi đã đề cập, giao thức này đã được chứng kiến ​​các thử nghiệm và triển khai quy mô lớn. Google đã bắt đầu thử nghiệm nó vào đầu năm 2015 , cũng như Facebook vào năm 2017 .

Vào năm 2021, chúng tôi có hỗ trợ HTTP/3 từ các trình duyệt chính như Google Chrome và Brave. Về mặt cơ sở hạ tầng, các máy chủ web như Litespeed và Nginx đều có triển khai hoạt động của HTTP/3, trong khi các nhà cung cấp mạng như Cloudflare đã triển khai hỗ trợ đầy đủ cho HTTP/3 .

Tại thời điểm này, HTTP/3 vẫn đang trong giai đoạn Dự thảo Internet và bản sửa đổi gần đây nhất sẽ hết hạn vào tháng 8 năm 2021. Năm nay sẽ rất thú vị, vì chúng ta có thể mong đợi động thái của các nhà cung cấp phần mềm lớn để triển khai Tiêu chuẩn.