Giao thức WebSockets vs HTTP

Có nhiều blog và thảo luận về websocket và HTTP, và nhiều nhà phát triển và trang web rất ủng hộ websockets, nhưng tôi vẫn không thể hiểu tại sao.

ví dụ (đối số của những người yêu thích websocket):

Các ổ cắm web HTML5 đại diện cho sự phát triển tiếp theo của truyền thông web. Kênh truyền thông hai chiều, song công hoàn toàn hoạt động thông qua một ổ cắm duy nhất trên Web. ( http://www.websocket.org/quantum.html )

HTTP hỗ trợ phát trực tuyến: yêu cầu phát trực tiếp nội dung (bạn đang sử dụng nó trong khi tải lên các tệp lớn) và phát trực tiếp nội dung.

Trong khi thực hiện kết nối với WebSocket, máy khách và máy chủ trao đổi dữ liệu trên mỗi khung có 2 byte, so với 8 kilo byte tiêu đề http khi bạn thực hiện bỏ phiếu liên tục.

Tại sao 2 byte đó không bao gồm tcp và các giao thức tcp trên đầu?

GET /about.html HTTP/1.1
Host: example.org

Đây là ~ 48 byte tiêu đề http.

mã hóa http chunked - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• Vì vậy, chi phí cho mỗi phần không lớn.

Ngoài ra cả hai giao thức đều hoạt động trên TCP, vì vậy tất cả các sự cố TCP với các kết nối tồn tại lâu vẫn còn đó.

Câu hỏi:

1. Tại sao giao thức websockets tốt hơn?
2. Tại sao nó được thực hiện thay vì cập nhật giao thức http?

1) Tại sao giao thức WebSockets tốt hơn?

WebSockets tốt hơn cho các tình huống liên quan đến giao tiếp có độ trễ thấp, đặc biệt là độ trễ thấp cho các tin nhắn từ máy khách đến máy chủ. Đối với dữ liệu từ máy chủ đến máy khách, bạn có thể nhận được độ trễ khá thấp bằng cách sử dụng các kết nối dài và chuyển dữ liệu. Tuy nhiên, điều này không giúp ích cho độ trễ của máy khách đến máy chủ yêu cầu kết nối mới được thiết lập cho mỗi máy khách gửi tin nhắn máy chủ.

Cái bắt tay HTTP 48 byte của bạn không thực tế đối với các kết nối trình duyệt HTTP trong thế giới thực, nơi thường có vài kilobyte dữ liệu được gửi như một phần của yêu cầu (theo cả hai hướng) bao gồm nhiều tiêu đề và dữ liệu cookie. Dưới đây là ví dụ về yêu cầu / phản hồi khi sử dụng Chrome:

Yêu cầu ví dụ (2800 byte bao gồm dữ liệu cookie, 490 byte không có dữ liệu cookie):

GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]

Ví dụ phản hồi (355 byte):

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip

Cả HTTP và WebSockets đều có các bắt tay kết nối ban đầu có kích thước tương đương, nhưng với kết nối WebSocket, bắt tay ban đầu được thực hiện một lần và sau đó các tin nhắn nhỏ chỉ có 6 byte trên đầu (2 cho tiêu đề và 4 cho giá trị mặt nạ). Chi phí độ trễ không quá nhiều từ kích thước của các tiêu đề, nhưng từ logic để phân tích / xử lý / lưu trữ các tiêu đề đó. Ngoài ra, độ trễ thiết lập kết nối TCP có thể là một yếu tố lớn hơn kích thước hoặc thời gian xử lý cho mỗi yêu cầu.

2) Tại sao nó được triển khai thay vì cập nhật giao thức HTTP?

Có những nỗ lực để thiết kế lại giao thức HTTP để đạt được hiệu suất tốt hơn và độ trễ thấp hơn như SPDY , HTTP 2.0 và QUIC . Điều này sẽ cải thiện tình hình cho các yêu cầu HTTP thông thường, nhưng có khả năng WebSockets và / hoặc WebRTC DataChannel vẫn sẽ có độ trễ thấp hơn để truyền dữ liệu từ máy khách sang máy chủ so với giao thức HTTP (hoặc nó sẽ được sử dụng trong chế độ trông rất giống WebSockets dù sao đi nữa).

Cập nhật :

Đây là một khung để suy nghĩ về các giao thức web:

• TCP : lớp vận chuyển đơn hàng cấp thấp, hai chiều, song công hoàn toàn và được đảm bảo. Không hỗ trợ trình duyệt (ngoại trừ thông qua plugin / Flash).
• HTTP 1.0 : giao thức vận chuyển đáp ứng yêu cầu được xếp lớp trên TCP. Máy khách thực hiện một yêu cầu đầy đủ, máy chủ cung cấp một phản hồi đầy đủ và sau đó kết nối được đóng lại. Các phương thức yêu cầu (GET, POST, HEAD) có ý nghĩa giao dịch cụ thể cho các tài nguyên trên máy chủ.
• HTTP 1.1 : duy trì tính chất đáp ứng yêu cầu của HTTP 1.0, nhưng cho phép kết nối luôn mở cho nhiều yêu cầu đầy đủ / phản hồi đầy đủ (một phản hồi cho mỗi yêu cầu). Vẫn có đầy đủ các tiêu đề trong yêu cầu và phản hồi nhưng kết nối được sử dụng lại và không bị đóng. HTTP 1.1 cũng đã thêm một số phương thức yêu cầu bổ sung (TÙY CHỌN, PUT, XÓA, TRACE, CONNECT) cũng có ý nghĩa giao dịch cụ thể. Tuy nhiên, như đã lưu ý trong phần giới thiệu về đề xuất dự thảo HTTP 2.0, đường ống HTTP 1.1 không được triển khai rộng rãi nên điều này hạn chế rất nhiều tiện ích của HTTP 1.1 để giải quyết độ trễ giữa trình duyệt và máy chủ.
• Thăm dò ý kiến ​​dài : sắp xếp "hack" thành HTTP (1.0 hoặc 1.1) trong đó máy chủ không phản hồi ngay lập tức (hoặc chỉ trả lời một phần với các tiêu đề) cho yêu cầu của máy khách. Sau khi phản hồi của máy chủ, máy khách sẽ gửi ngay một yêu cầu mới (sử dụng cùng một kết nối nếu qua HTTP 1.1).
• Truyền phát HTTP : một loạt các kỹ thuật (phản hồi nhiều phần / phản hồi) cho phép máy chủ gửi nhiều hơn một phản hồi cho một yêu cầu khách hàng. W3C đang chuẩn hóa điều này dưới dạng Sự kiện do Máy chủ gửi bằng text/event-streamloại MIME. API trình duyệt (tương đối giống với API WebSocket) được gọi là API EventSource.
• Đẩy sao chổi / máy chủ : đây là một thuật ngữ bao gồm cả phát trực tuyến dài và HTTP. Thư viện Comet thường hỗ trợ nhiều kỹ thuật để thử và tối đa hóa hỗ trợ trình duyệt chéo và máy chủ chéo.
• WebSockets : lớp vận chuyển tích hợp TCP sử dụng bắt tay Nâng cấp thân thiện HTTP. Không giống như TCP là truyền tải trực tuyến, WebSockets là truyền tải dựa trên thông báo: các tin nhắn được phân định trên dây và được lắp ráp lại đầy đủ trước khi gửi đến ứng dụng. Các kết nối WebSocket là hai hướng, song công hoàn toàn và tồn tại lâu dài. Sau yêu cầu / phản hồi bắt tay ban đầu, không có ngữ nghĩa giao dịch và có rất ít chi phí cho mỗi tin nhắn. Máy khách và máy chủ có thể gửi tin nhắn bất cứ lúc nào và phải xử lý nhận tin nhắn không đồng bộ.
• SPDY : một đề xuất do Google khởi xướng để mở rộng HTTP bằng cách sử dụng giao thức dây hiệu quả hơn nhưng vẫn duy trì tất cả các ngữ nghĩa HTTP (yêu cầu / phản hồi, cookie, mã hóa). SPDY giới thiệu một định dạng khung mới (với các khung có tiền tố dài) và chỉ định một cách để xếp các cặp yêu cầu / phản hồi HTTP lên lớp khung mới. Các tiêu đề có thể được nén và các tiêu đề mới có thể được gửi sau khi kết nối được thiết lập. Có các triển khai SPDY trong thế giới thực trong các trình duyệt và máy chủ.
• HTTP 2.0 : có các mục tiêu tương tự như SPDY: giảm độ trễ và chi phí HTTP trong khi vẫn bảo tồn ngữ nghĩa HTTP. Dự thảo hiện tại có nguồn gốc từ SPDY và ​​xác định bắt tay nâng cấp và đóng khung dữ liệu rất giống với tiêu chuẩn WebSocket cho bắt tay và đóng khung. Một đề xuất dự thảo HTTP 2.0 thay thế (httpbis-speed-mobility) thực sự sử dụng WebSockets cho lớp vận chuyển và thêm ghép kênh SPDY và ​​ánh xạ HTTP làm tiện ích mở rộng WebSocket (tiện ích mở rộng WebSocket được đàm phán trong quá trình bắt tay).
• WebRTC / CU-WebRTC : đề xuất cho phép kết nối ngang hàng giữa các trình duyệt. Điều này có thể cho phép giao tiếp độ trễ trung bình và độ trễ tối đa thấp hơn vì vận chuyển cơ bản là SDP / datagram chứ không phải TCP. Điều này cho phép phân phối các gói / tin nhắn không theo thứ tự để tránh sự cố TCP về độ trễ trễ do các gói bị rơi làm trì hoãn việc gửi tất cả các gói tiếp theo (để đảm bảo phân phối theo thứ tự).
• QUIC : là một giao thức thử nghiệm nhằm giảm độ trễ web so với TCP. Nhìn bề ngoài, QUIC rất giống với TCP + TLS + SPDY được triển khai trên UDP. QUIC cung cấp điều khiển ghép kênh và điều khiển luồng tương đương với HTTP / 2, bảo mật tương đương với TLS và ngữ nghĩa kết nối, độ tin cậy và điều khiển tắc nghẽn tương đương với TCP. Vì TCP được triển khai trong các hạt nhân của hệ điều hành và phần sụn giữa, nên việc thay đổi đáng kể đối với TCP là không thể. Tuy nhiên, do QUIC được xây dựng dựa trên UDP, nên nó không bị giới hạn như vậy. QUIC được thiết kế và tối ưu hóa cho ngữ nghĩa HTTP / 2.

Tài liệu tham khảo :

• HTTP :
  • Trang HTTP Wikipedia
  • W3C Danh sách các Bản nháp / Giao thức liên quan đến HTTP
  • Danh sách các bản nháp IETF HTTP / 1.1 và HTTP / 2.0
• Sự kiện gửi máy chủ :
  • Sự kiện / Sự kiện được gửi bởi Máy chủ W3C
  • Dự thảo gửi sự kiện / sự kiện nguồn máy chủ W3C
• WebSockets :
  • Giao thức WebSockets của IETF RFC 6455
  • IETF RFC 6455 WebSocket Errata
• SPDY :
  • Dự thảo SPDET của IETF
• HTTP 2.0 :
  • Dự thảo IETF HTTP 2.0 httpbis-http2
  • Dự thảo về tốc độ di động của IETF HTTP 2.0 httpbis
  • Dự thảo thân thiện với mạng http -is của IETF - một đề xuất liên quan đến HTTP 2.0 cũ hơn
• WebRTC :
  • Dự thảo API WebRTC của W3C
  • Danh sách các Dự thảo WebRTC của IETF
  • Dự thảo tổng quan về IETF WebRTC
  • Dự thảo dữ liệu kênh IETF WebRTC
  • Trang bắt đầu đề xuất Microsoft CU-WebRTC
• QUIC :
  • Dự án QUIC Chrominum
  • Dự thảo IETF QUIC

Bạn dường như cho rằng WebSocket là sự thay thế cho HTTP. Không phải vậy. Đó là một phần mở rộng.

Trường hợp sử dụng chính của WebSockets là các ứng dụng Javascript chạy trên trình duyệt web và nhận dữ liệu thời gian thực từ máy chủ. Trò chơi là một ví dụ tốt.

Trước WebSockets, phương pháp duy nhất để các ứng dụng Javascript tương tác với máy chủ là thông qua XmlHttpRequest. Nhưng những điều này có một nhược điểm lớn: Máy chủ không thể gửi dữ liệu trừ khi khách hàng yêu cầu rõ ràng.

Nhưng tính năng WebSocket mới cho phép máy chủ gửi dữ liệu bất cứ khi nào nó muốn. Điều này cho phép thực hiện các trò chơi dựa trên trình duyệt với độ trễ thấp hơn nhiều và không phải sử dụng các bản hack xấu xí như AJAX bỏ phiếu dài hoặc các plugin trình duyệt.

Vậy tại sao không sử dụng HTTP bình thường với các yêu cầu và phản hồi truyền phát

Trong một bình luận cho một câu trả lời khác, bạn đề nghị chỉ truyền phát yêu cầu của khách hàng và cơ thể phản hồi không đồng bộ.

Trên thực tế, WebSockets về cơ bản là vậy. Lần đầu tiên cố gắng mở kết nối WebSocket từ máy khách trông giống như một yêu cầu HTTP, nhưng một lệnh đặc biệt trong tiêu đề (Nâng cấp: websocket) cho máy chủ bắt đầu giao tiếp ở chế độ không đồng bộ này. Bản nháp đầu tiên của giao thức WebSocket không nhiều hơn thế và một số bắt tay để đảm bảo rằng máy chủ thực sự hiểu rằng máy khách muốn giao tiếp không đồng bộ. Nhưng sau đó, người ta nhận ra rằng các máy chủ proxy sẽ bị nhầm lẫn bởi điều đó, bởi vì chúng được sử dụng cho mô hình yêu cầu / phản hồi thông thường của HTTP. Một kịch bản tấn công tiềm năng chống lại các máy chủ proxy đã được phát hiện. Để ngăn chặn điều này, cần phải làm cho lưu lượng truy cập WebSocket trông không giống bất kỳ lưu lượng HTTP thông thường nào. Đó là lý do tại sao các phím mặt nạ được giới thiệu trongphiên bản cuối cùng của giao thức .

API REST thông thường sử dụng HTTP làm giao thức cơ bản để liên lạc, tuân theo mô hình yêu cầu và phản hồi, nghĩa là giao tiếp liên quan đến máy khách yêu cầu một số dữ liệu hoặc tài nguyên từ máy chủ và máy chủ phản hồi lại máy khách đó. Tuy nhiên, HTTP là một giao thức không trạng thái, do đó, mọi chu kỳ phản hồi yêu cầu sẽ phải lặp lại thông tin siêu dữ liệu và tiêu đề. Điều này phát sinh độ trễ bổ sung trong trường hợp chu kỳ đáp ứng yêu cầu thường xuyên lặp lại.

Với WebSockets, mặc dù giao tiếp vẫn bắt đầu như một cái bắt tay HTTP ban đầu, nó được nâng cấp thêm để tuân theo giao thức WebSockets (tức là nếu cả máy chủ và máy khách đều tuân thủ giao thức vì không phải tất cả các thực thể đều hỗ trợ giao thức WebSockets).

Giờ đây với WebSockets, có thể thiết lập kết nối song công hoàn toàn và liên tục giữa máy khách và máy chủ. Điều này có nghĩa là không giống như yêu cầu và phản hồi, kết nối vẫn mở miễn là ứng dụng đang chạy (nghĩa là nó vẫn tồn tại) và vì nó là song công hoàn toàn, nên có thể giao tiếp đồng thời hai chiều, hiện tại máy chủ có khả năng khởi tạo một giao tiếp và 'đẩy' một số dữ liệu đến máy khách khi dữ liệu mới (mà máy khách quan tâm) có sẵn.

Giao thức WebSockets có trạng thái và cho phép bạn triển khai mẫu tin nhắn Publish-Theo dõi (hoặc Pub / Sub), là khái niệm chính được sử dụng trong các công nghệ thời gian thực nơi bạn có thể nhận các bản cập nhật mới dưới dạng đẩy máy chủ mà không cần khách hàng phải yêu cầu (làm mới trang) nhiều lần. Ví dụ về các ứng dụng như theo dõi vị trí của xe Uber, Thông báo đẩy, cập nhật giá thị trường chứng khoán trong thời gian thực, trò chuyện, trò chơi nhiều người chơi, công cụ cộng tác trực tuyến, v.v.

Bạn có thể kiểm tra một bài viết chuyên sâu về Websockets giải thích lịch sử của giao thức này, nó ra đời như thế nào, nó được sử dụng để làm gì và bạn có thể tự thực hiện nó như thế nào.

Đây là video từ một bài thuyết trình tôi đã làm về WebSockets và cách chúng khác với việc sử dụng API REST thông thường: Tiêu chuẩn hóa và thúc đẩy sự gia tăng theo cấp số nhân trong truyền dữ liệu

Đối với TL; DR, đây là 2 xu và phiên bản đơn giản hơn cho câu hỏi của bạn:

1. WebSockets cung cấp những lợi ích này qua HTTP:

   • Kết nối trạng thái liên tục trong suốt thời gian kết nối
   • Độ trễ thấp: giao tiếp gần thời gian thực giữa máy chủ / máy khách do không có chi phí thiết lập lại các kết nối cho mỗi yêu cầu khi HTTP yêu cầu.
   • Song công hoàn toàn: cả máy chủ và máy khách đều có thể gửi / nhận đồng thời

2. WebSocket và giao thức HTTP đã được thiết kế để giải quyết các vấn đề khác nhau, IE WebSocket được thiết kế để cải thiện giao tiếp hai chiều trong khi HTTP được thiết kế để không trạng thái, được phân phối bằng mô hình yêu cầu / phản hồi. Khác với việc chia sẻ các cổng vì lý do di sản (thâm nhập tường lửa / proxy), không có nhiều điểm chung để kết hợp chúng thành một giao thức.

Tại sao giao thức websockets tốt hơn?

Tôi không nghĩ chúng ta có thể so sánh họ cạnh nhau như ai tốt hơn. Điều đó sẽ không được so sánh công bằng chỉ đơn giản vì họ đang giải quyết hai vấn đề khác nhau . Yêu cầu của họ là khác nhau. Nó sẽ giống như so sánh táo với cam. Họ khác nhau.

HTTP là một giao thức đáp ứng yêu cầu. Máy khách (trình duyệt) muốn một cái gì đó, máy chủ cung cấp cho nó. Đó là. Nếu máy khách dữ liệu muốn lớn, máy chủ có thể gửi dữ liệu phát trực tuyến để loại bỏ các vấn đề bộ đệm không mong muốn. Ở đây yêu cầu chính hoặc vấn đề là làm thế nào để thực hiện yêu cầu từ khách hàng và cách đáp ứng các tài nguyên (hybertext) mà họ yêu cầu. Đó là nơi HTTP tỏa sáng.

Trong HTTP, chỉ yêu cầu khách hàng. Máy chủ chỉ đáp ứng.

WebSocket không phải là giao thức đáp ứng yêu cầu trong đó chỉ khách hàng mới có thể yêu cầu. Nó là một socket (rất giống với socket TCP). Có nghĩa là một khi kết nối được mở, một trong hai bên có thể gửi dữ liệu cho đến khi kết nối TCP được gạch chân. Nó giống như một ổ cắm bình thường. Sự khác biệt duy nhất với ổ cắm TCP là websocket có thể được sử dụng trong web. Trong web, chúng tôi có nhiều hạn chế cho một ổ cắm bình thường. Hầu hết các tường lửa sẽ chặn cổng khác ngoài 80 và 433 mà HTTP đã sử dụng. Proxy và trung gian cũng sẽ có vấn đề. Vì vậy, để làm cho giao thức dễ dàng triển khai hơn đến websocket cơ sở hạ tầng hiện tại, hãy sử dụng bắt tay HTTP để nâng cấp. Điều đó có nghĩa là khi kết nối lần đầu tiên được mở, khách hàng đã gửi yêu cầu HTTP để thông báo cho máy chủ rằng "Đó không phải là yêu cầu HTTP, vui lòng nâng cấp lên giao thức websocket".

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Khi máy chủ hiểu yêu cầu và được nâng cấp lên giao thức websocket, không có giao thức HTTP nào được áp dụng nữa.

Vì vậy, câu trả lời của tôi là Không ai tốt hơn nhau. Chúng hoàn toàn khác nhau.

Tại sao nó được thực hiện thay vì cập nhật giao thức http?

Chà, chúng ta cũng có thể làm mọi thứ dưới cái tên gọi là HTTP . Nhưng chúng ta thì sao? Nếu chúng là hai thứ khác nhau, tôi sẽ thích hai cái tên khác nhau. Hickson và Michael Carter cũng vậy .

Các câu trả lời khác dường như không chạm vào một khía cạnh quan trọng ở đây và đó là bạn không đề cập đến việc yêu cầu hỗ trợ trình duyệt web với tư cách là khách hàng. Hầu hết các hạn chế của HTTP đơn giản ở trên đều cho rằng bạn sẽ làm việc với các triển khai trình duyệt / JS.

Giao thức HTTP hoàn toàn có khả năng giao tiếp song công hoàn toàn; Sẽ là hợp pháp khi khách hàng thực hiện POST với chuyển mã hóa được mã hóa và máy chủ trả về phản hồi với cơ thể mã hóa chunked. Điều này sẽ loại bỏ chi phí tiêu đề chỉ trong thời gian init.

Vì vậy, nếu tất cả những gì bạn đang tìm kiếm là song công hoàn toàn, kiểm soát cả máy khách và máy chủ và không quan tâm đến việc đóng khung / tính năng bổ sung của websockets, thì tôi sẽ cho rằng HTTP là một cách tiếp cận đơn giản hơn với độ trễ / CPU thấp hơn (mặc dù độ trễ sẽ thực sự chỉ khác nhau trong micro giây hoặc ít hơn cho một trong hai).