Ai đó có thể vui lòng giải thích ghép kênh liên quan đến HTTP / 2 và cách nó hoạt động không?
Câu trả lời:
Nói một cách đơn giản, ghép kênh cho phép Trình duyệt của bạn kích hoạt nhiều yêu cầu cùng một lúc trên cùng một kết nối và nhận lại các yêu cầu theo bất kỳ thứ tự nào.
Và bây giờ cho câu trả lời phức tạp hơn nhiều ...
Khi bạn tải một trang web, nó tải trang HTML xuống, nó thấy nó cần một số CSS, một số JavaScript, tải hình ảnh ... vv.
Trong HTTP / 1.1, bạn chỉ có thể tải xuống một trong số chúng tại một thời điểm trên kết nối HTTP / 1.1 của mình. Vì vậy, trình duyệt của bạn tải xuống HTML, sau đó nó yêu cầu tệp CSS. Khi được trả lại, nó sẽ yêu cầu tệp JavaScript. Khi được trả lại, nó sẽ yêu cầu tệp hình ảnh đầu tiên ... vv HTTP / 1.1 về cơ bản là đồng bộ - khi bạn gửi một yêu cầu, bạn sẽ gặp khó khăn cho đến khi nhận được phản hồi. Điều này có nghĩa là hầu hết thời gian trình duyệt không hoạt động nhiều, vì nó đã kích hoạt một yêu cầu, đang chờ phản hồi, sau đó kích hoạt một yêu cầu khác, sau đó chờ phản hồi ... vv Tất nhiên các trang web phức tạp với rất nhiều JavaScript yêu cầu Trình duyệt thực hiện nhiều xử lý, nhưng điều đó phụ thuộc vào JavaScript được tải xuống, vì vậy, ít nhất là lúc đầu, sự chậm trễ kế thừa đến HTTP / 1.1 có thể gây ra vấn đề. Thông thường, máy chủ isn '
Vì vậy, một trong những vấn đề chính trên web ngày nay là độ trễ mạng trong việc gửi yêu cầu giữa trình duyệt và máy chủ. Nó có thể chỉ là hàng chục hoặc có lẽ hàng trăm mili giây, có vẻ không nhiều, nhưng chúng cộng lại và thường là phần chậm nhất của trình duyệt web - đặc biệt là khi các trang web ngày càng phức tạp và yêu cầu thêm tài nguyên (khi chúng đang nhận được) và truy cập Internet ngày càng tăng thông qua di động (với độ trễ chậm hơn so với băng thông rộng).
Ví dụ, giả sử có 10 tài nguyên mà trang web của bạn cần tải sau khi HTML được tải chính nó (đây là một trang rất nhỏ theo tiêu chuẩn ngày nay vì hơn 100 tài nguyên là phổ biến, nhưng chúng tôi sẽ giữ cho nó đơn giản và đi kèm với điều này thí dụ). Và giả sử mỗi yêu cầu mất 100ms để di chuyển trên Internet đến máy chủ web và quay lại và thời gian xử lý ở hai đầu là không đáng kể (giả sử 0 cho ví dụ này để đơn giản hơn). Vì bạn phải gửi từng tài nguyên và đợi phản hồi một lần, điều này sẽ mất 10 * 100ms = 1.000ms hoặc 1 giây để tải xuống toàn bộ trang web.
Để giải quyết vấn đề này, các trình duyệt thường mở nhiều kết nối đến máy chủ web (thường là 6). Điều này có nghĩa là một trình duyệt có thể kích hoạt nhiều yêu cầu cùng một lúc, điều này tốt hơn nhiều, nhưng phải trả giá bằng sự phức tạp của việc phải thiết lập và quản lý nhiều kết nối (ảnh hưởng đến cả trình duyệt và máy chủ). Hãy tiếp tục ví dụ trước và cũng nói rằng có 4 kết nối và để đơn giản hơn, giả sử tất cả các yêu cầu đều như nhau. Trong trường hợp này, bạn có thể chia các yêu cầu trên tất cả bốn kết nối, do đó, hai sẽ có 3 tài nguyên để nhận và hai sẽ có 2 tài nguyên để nhận toàn bộ mười tài nguyên (3 + 3 + 2 + 2 = 10). Trong trường hợp đó, trường hợp xấu nhất là 3 lần vòng hoặc 300ms = 0,3 giây - một cải tiến tốt, nhưng ví dụ đơn giản này không bao gồm chi phí thiết lập nhiều kết nối đó,
HTTP / 2 cho phép bạn gửi nhiều yêu cầu trên cùng mộtkết nối - vì vậy bạn không cần phải mở nhiều kết nối như trên. Vì vậy, trình duyệt của bạn có thể nói "Gimme this CSS file. Gimme that JavaScript file. Gimme image1.jpg. Gimme image2.jpg ... vv" để sử dụng đầy đủ một kết nối duy nhất. Điều này có lợi ích về hiệu suất rõ ràng là không làm chậm trễ việc gửi các yêu cầu khi chờ kết nối miễn phí. Tất cả các yêu cầu này thực hiện theo cách của chúng qua Internet đến máy chủ trong (gần như) song song. Máy chủ phản hồi từng cái và sau đó chúng bắt đầu quay lại. Trên thực tế, nó thậm chí còn mạnh hơn thế vì máy chủ web có thể phản hồi chúng theo bất kỳ thứ tự nào mà bạn cảm thấy thích và gửi lại các tệp theo thứ tự khác nhau, hoặc thậm chí chia nhỏ từng tệp được yêu cầu thành nhiều phần và trộn các tệp lại với nhau.vấn đề chặn đầu dòng ). Sau đó, trình duyệt web được giao nhiệm vụ ghép tất cả các phần lại với nhau. Trong trường hợp tốt nhất (giả sử không có giới hạn băng thông - xem bên dưới), nếu tất cả 10 yêu cầu được kích hoạt song song khá nhiều cùng một lúc và được máy chủ trả lời ngay lập tức, điều này có nghĩa là bạn về cơ bản có một chuyến đi khứ hồi hoặc 100ms hoặc 0,1 giây, để tải xuống tất cả 10 tài nguyên. Và điều này không có nhược điểm mà nhiều kết nối có đối với HTTP / 1.1! Điều này cũng có thể mở rộng hơn nhiều khi tài nguyên trên mỗi trang web tăng lên (hiện tại các trình duyệt mở tối đa 6 kết nối song song theo HTTP / 1.1 nhưng liệu điều đó có phát triển khi các trang web trở nên phức tạp hơn không?).
Sơ đồ này cho thấy sự khác biệt và có một phiên bản hoạt hình nữa .
Lưu ý: HTTP / 1.1 có khái niệm pipelining cũng cho phép gửi nhiều yêu cầu cùng một lúc. Tuy nhiên, chúng vẫn phải được trả lại theo thứ tự được yêu cầu, toàn bộ, vì vậy không nơi nào tốt bằng HTTP / 2, ngay cả khi nó tương tự về mặt khái niệm. Chưa kể thực tế là nó được hỗ trợ bởi cả trình duyệt và máy chủ rất kém nên nó hiếm khi được sử dụng.
Một điều được nhấn mạnh trong các bình luận bên dưới là băng thông tác động đến chúng ta như thế nào ở đây. Tất nhiên kết nối Internet của bạn bị giới hạn bởi số lượng bạn có thể tải xuống và HTTP / 2 không giải quyết điều đó. Vì vậy, nếu 10 tài nguyên được thảo luận trong các ví dụ trên đều là hình ảnh chất lượng in lớn, thì chúng vẫn sẽ tải xuống chậm. Tuy nhiên, đối với hầu hết các trình duyệt web, băng thông ít là vấn đề hơn độ trễ. Vì vậy, nếu mười tài nguyên đó là các mục nhỏ (đặc biệt là các tài nguyên văn bản như CSS và JavaScript có thể được nén thành rất nhỏ), như rất phổ biến trên các trang web, thì băng thông không thực sự là một vấn đề - đó là khối lượng tài nguyên tuyệt đối thường là vấn đề và HTTP / 2 sẽ giải quyết vấn đề đó. Đây cũng là lý do tại sao nối được sử dụng trong HTTP / 1.1 như một cách giải quyết khác, vì vậy, ví dụ: tất cả CSS thường được nối với nhau thành một tệp:anti-pattern trong HTTP / 2 - mặc dù cũng có những lập luận chống lại việc loại bỏ nó hoàn toàn).
Để đặt nó như một ví dụ trong thế giới thực: giả sử bạn phải đặt 10 mặt hàng từ một cửa hàng để được giao hàng tận nhà:
HTTP / 1.1 với một kết nối có nghĩa là bạn phải đặt hàng từng món một và bạn không thể đặt hàng tiếp theo cho đến khi hàng cuối cùng đến. Bạn có thể hiểu rằng sẽ mất nhiều tuần để vượt qua mọi thứ.
HTTP / 1.1 với nhiều kết nối có nghĩa là bạn có thể có một số lượng (giới hạn) các đơn đặt hàng độc lập khi đang di chuyển cùng một lúc.
HTTP / 1.1 với pipelining có nghĩa là bạn có thể yêu cầu tất cả 10 mục lần lượt mà không cần chờ đợi, nhưng sau đó tất cả đều đến theo thứ tự cụ thể mà bạn yêu cầu. Và nếu một mặt hàng hết hàng thì bạn phải đợi điều đó trước khi nhận được các mặt hàng bạn đã đặt sau đó - ngay cả khi những mặt hàng sau đó thực sự còn trong kho! Điều này tốt hơn một chút nhưng vẫn có thể bị chậm trễ và giả sử hầu hết các cửa hàng không hỗ trợ cách đặt hàng này.
HTTP / 2 có nghĩa là bạn có thể đặt các mặt hàng của mình theo bất kỳ đơn hàng cụ thể nào - mà không có bất kỳ sự chậm trễ nào (tương tự như trên). Cửa hàng sẽ gửi họ khi họ đã sẵn sàng, vì vậy họ có thể đến theo đơn đặt hàng khác với đơn hàng bạn yêu cầu và thậm chí họ có thể chia nhỏ các mặt hàng để một số phần của đơn hàng đó đến trước (tốt hơn ở trên). Cuối cùng, điều này có nghĩa là bạn 1) nhận được mọi thứ nhanh hơn về tổng thể và 2) có thể bắt đầu làm việc với từng mặt hàng khi nó đến ("ồ, nó không đẹp như tôi nghĩ, vì vậy tôi có thể muốn đặt một cái gì đó khác hoặc thay thế" ).
Tất nhiên, bạn vẫn bị giới hạn bởi kích thước của xe đưa thư của bạn (băng thông), vì vậy họ có thể phải để lại một số gói hàng ở văn phòng phân loại cho đến ngày hôm sau nếu chúng đã đầy cho ngày hôm đó, nhưng đó hiếm khi là một vấn đề so với đến sự chậm trễ trong việc thực sự gửi đơn đặt hàng qua lại. Hầu hết việc duyệt web liên quan đến việc gửi các bức thư nhỏ qua lại thay vì các gói hàng cồng kềnh.
Hy vọng rằng sẽ giúp.
Yêu cầu ghép kênh
HTTP / 2 có thể gửi nhiều yêu cầu dữ liệu song song qua một kết nối TCP duy nhất. Đây là tính năng tiên tiến nhất của giao thức HTTP / 2 vì nó cho phép bạn tải xuống các tệp web không đồng bộ từ một máy chủ. Hầu hết các trình duyệt hiện đại giới hạn kết nối TCP với một máy chủ. Điều này làm giảm thời gian khứ hồi bổ sung (RTT), làm cho trang web của bạn tải nhanh hơn mà không có bất kỳ tối ưu hóa nào và làm cho việc phân bổ miền trở nên không cần thiết.
Simple Ans ( Nguồn ):
Ghép kênh có nghĩa là trình duyệt của bạn có thể gửi nhiều yêu cầu và nhận nhiều phản hồi được "gói" vào một kết nối TCP duy nhất. Vì vậy, khối lượng công việc liên quan đến tra cứu DNS và bắt tay được lưu cho các tệp đến từ cùng một máy chủ.
Ans phức tạp / chi tiết:
Hãy xem câu trả lời do @BazzaDP cung cấp.
Ghép kênh trong HTTP 2.0 là kiểu quan hệ giữa trình duyệt và máy chủ sử dụng một kết nối duy nhất để cung cấp song song nhiều yêu cầu và phản hồi, tạo ra nhiều khung riêng lẻ trong quá trình này.
Ghép kênh tách khỏi ngữ nghĩa yêu cầu-phản hồi nghiêm ngặt và cho phép các mối quan hệ một-nhiều hoặc nhiều-nhiều.
Vì câu trả lời của @Juanma Menendez là đúng trong khi sơ đồ của anh ấy khó hiểu, tôi quyết định cải thiện nó, làm rõ sự khác biệt giữa ghép kênh và ghép nối, những khái niệm thường bị nhầm lẫn.
Pipelining (HTTP / 1.1)
Nhiều yêu cầu được gửi qua cùng một kết nối HTTP. Các câu trả lời được nhận theo thứ tự. Nếu phản hồi đầu tiên mất nhiều thời gian, các phản hồi khác phải xếp hàng chờ. Tương tự như phân luồng CPU trong đó một lệnh được tìm nạp trong khi một lệnh khác đang được giải mã. Nhiều hướng dẫn được thực hiện cùng một lúc, nhưng thứ tự của chúng được giữ nguyên.
Ghép kênh (HTTP / 2)
Nhiều yêu cầu được gửi qua cùng một kết nối HTTP. Phản hồi được nhận theo thứ tự tùy ý. Không cần phải đợi phản hồi chậm đang chặn người khác. Tương tự như việc thực thi lệnh không theo thứ tự trong các CPU hiện đại.
Hy vọng rằng hình ảnh được cải thiện sẽ làm rõ sự khác biệt:
