SPDY có khác biệt so với http ghép kênh để giữ kết nối còn sống

Question

HTTP 1.1 hỗ trợ kết nối còn sống, kết nối không được đóng cho đến khi "Kết nối: đóng" được gửi.

Vì vậy, nếu trình duyệt, trong trường hợp này firefox có network.http.pipelining enabled và network.http.pipelining.maxrequests tăng không phải là cùng một hiệu ứng cuối cùng?

Tôi biết rằng các cài đặt này bị tắt vì một số trang web có thể tăng tải nhưng tôi nghĩ cờ tiêu đề http đơn giản có thể cho trình duyệt biết cách ghép kênh và vấn đề này có thể được giải quyết dễ dàng hơn.

Sẽ không dễ thay đổi cài đặt mặc định trong trình duyệt hơn là tạo ra một giao thức mới làm tăng độ phức tạp, đặc biệt là trong các máy chủ http?

Answer 1

SPDY có một số lợi thế mà đi xa hơn những gì HTTP pipelining có thể cung cấp, được mô tả trong SPDY whitepaper:

1. Với pipelining, máy chủ vẫn phải quay trở lại các câu trả lời cùng một lúc theo thứ tự họ đã được yêu cầu. Đây có thể là vấn đề nếu máy khách yêu cầu một tài nguyên được tạo động trước khi một tài nguyên tĩnh: máy chủ không thể gửi bất kỳ phản hồi tĩnh "dễ dàng" nào cho đến khi máy chủ được tạo động và gửi đi. Với SPDY, các phản hồi có thể được trả về theo thứ tự hoặc song song khi chúng được tạo ra, làm giảm tổng thời gian nhận tất cả các tài nguyên.
2. Như bạn đã lưu ý trong câu hỏi của mình, không phải tất cả các máy chủ đều có thể xử lý pipelining: không chỉ tải, một số máy chủ thực sự hoạt động không chính xác khi máy khách yêu cầu pipelining. Sử dụng tiêu đề để cho biết rằng việc thực hiện pipel là quá trễ để có được lợi ích tối đa: bạn đã nhận được phản hồi đầu tiên tại thời điểm đó, vì vậy trong khi bạn có thể sử dụng nó trong các kết nối trong tương lai thì đã quá muộn.
3. SPDY nén tiêu đề bằng thuật toán dành riêng cho tác vụ đó (trạng thái và kiến ​​thức về những gì bình thường trong tiêu đề HTTP); trong khi có, SSL đã bao gồm nén, chỉ cần nén chúng với deflate là không hiệu quả. Hầu hết các yêu cầu HTTP không có nội dung và chỉ có một dòng GET ngắn, do đó các tiêu đề tạo nên hầu như toàn bộ yêu cầu: mọi nén bạn có thể nhận được là một cải tiến. Nhiều phản hồi cũng nhỏ so với tiêu đề của chúng.
4. SPDY cho phép máy chủ gửi lại các phản hồi bổ sung mà không cần ứng dụng khách yêu cầu. Ví dụ: máy chủ có thể bắt đầu gửi lại CSS cho một trang cùng với HTML gốc, trước khi khách hàng có cơ hội nhận và phân tích cú pháp HTML để xác định URL biểu định kiểu. Điều này có thể tăng tốc độ tải trang hơn nữa bằng cách loại bỏ sự cần thiết cho khách hàng để phân tích cú pháp HTML thực sự trước khi yêu cầu các tài nguyên khác cần thiết để hiển thị trang. Nó cũng hỗ trợ một phiên bản ít băng thông của tính năng này, nơi nó có thể "gợi ý" về tài nguyên nào cần thiết và cho phép khách hàng quyết định: điều này cho phép, ví dụ, khách hàng không quan tâm đến hình ảnh không bận tâm yêu cầu họ, nhưng khách hàng muốn hiển thị hình ảnh vẫn có thể yêu cầu hình ảnh bằng cách sử dụng các URL đã cho mà không cần phải đợi HTML.
5. Những thứ khác nữa: xem câu trả lời của William Chan để biết thêm nữa.

Answer 2

• HTTP pipelining là nhạy cảm với người đứng đầu của dòng chặn (http://en.wikipedia.org/wiki/Head-of-line_blocking) ở mức giao dịch HTTP trong khi SPDY chỉ có người đứng đầu dòng chặn ở mức độ vận chuyển, do việc sử dụng ghép kênh.
• Đường ống dẫn HTTP có vấn đề về triển khai. Xem http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 mô tả một số giải pháp và cách giải quyết khác nhau để giảm thiểu điều này.SPDY như được triển khai trong tự nhiên không có vấn đề này vì nó thường được triển khai trên SSL (cổng 443) bằng cách sử dụng NPN (http://technotes.googlecode.com/git/nextprotoneg.html) để thương lượng hỗ trợ SPDY. SSL là chìa khóa, vì nó ngăn cản các trung gian can thiệp.
• SPDY có tiêu đề nén. Xem http://dev.chromium.org/spdy/spdy-whitepaper thảo luận về một số kết quả chuẩn về lợi ích của nén tiêu đề. Bây giờ, rất hữu ích để lưu ý rằng băng thông ít hơn và ít hơn của một vấn đề (xem http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/), nhưng nó cũng hữu ích để nhớ rằng băng thông vẫn là chìa khóa cho điện thoại di động. Hãy xem https://developers.google.com/speed/articles/spdy-for-mobile cho biết SPDY có lợi cho điện thoại di động như thế nào.
• SPDY hỗ trợ các tính năng như đẩy máy chủ. Xem http://dev.chromium.org/spdy/spdy-best-practices để biết cách sử dụng tính năng đẩy máy chủ để cải thiện khả năng lưu nội dung của bộ nhớ cache và vẫn giảm các vòng quay.
• Đường ống dẫn HTTP có ngữ nghĩa lỗi không xác định. Khi máy chủ đóng kết nối, làm thế nào để bạn biết yêu cầu nào đã được xử lý thành công? Đây là một lý do chính tại sao POST và các yêu cầu không phải là idempotent khác không được phép trên các kết nối pipelined. SPDY cung cấp ngữ nghĩa để hủy từng luồng trên cùng một kết nối và cũng có khung GOAWAY cho biết luồng cuối cùng được xử lý thành công.
• Đường ống dẫn HTTP gặp khó khăn, thường là do trung gian, cho phép đường ống sâu. Điều này (ngoài nhiều lý do khác như chặn HoL) có nghĩa là bạn vẫn cần sử dụng nhiều kết nối TCP để đạt được sự song song tối đa. Sử dụng nhiều kết nối TCP có nghĩa là không thể chia sẻ thông tin điều khiển tắc nghẽn, các ngữ cảnh nén không thể được chia sẻ (như SPDY với tiêu đề), tệ hơn cho internet (chi phí trung gian và máy chủ).

Tôi có thể tiếp tục và về HTTP pipelining so với SPDY. Nhưng tôi khuyên bạn chỉ nên đọc về SPDY. Hãy xem http://dev.chromium.org/spdy và cuộc trò chuyện công nghệ của chúng tôi về SPDY tại http://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video.

Answer 3

Xem Difference between HTTP pipeling and HTTP multiplexing with SPDY