โปรโตคอล WebSockets เทียบกับ HTTP

มีบล็อกและการสนทนามากมายเกี่ยวกับ websocket และ HTTP และนักพัฒนาและเว็บไซต์จำนวนมากสนับสนุน websockets อย่างมาก แต่ฉันก็ยังไม่เข้าใจว่าทำไม

ตัวอย่าง (ข้อโต้แย้งของคนรัก websocket):

HTML5 Web Sockets แสดงถึงวิวัฒนาการครั้งต่อไปของการสื่อสารทางเว็บซึ่งเป็นช่องทางการสื่อสารแบบสองทางเต็มรูปแบบที่ทำงานผ่านซ็อกเก็ตเดียวผ่านเว็บ ( http://www.websocket.org/quantum.html )

HTTP สนับสนุนการสตรีม: ร้องขอการสตรีมเนื้อหา (คุณใช้ในขณะที่อัปโหลดไฟล์ขนาดใหญ่) และการสตรีมเนื้อหาการตอบกลับ

ระหว่างทำการเชื่อมต่อกับ WebSocket ลูกค้าและข้อมูลการแลกเปลี่ยนเซิร์ฟเวอร์ต่อเฟรมซึ่งมีขนาด 2 ไบต์ต่อเมื่อเปรียบเทียบกับส่วนหัว http 8 กิโลไบต์ของ http เมื่อคุณทำการสำรวจต่อเนื่อง

ทำไม 2 ไบต์ไม่รวม tcp และภายใต้โปรโตคอล TCP ค่าใช้จ่าย?

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

นี่คือส่วนหัว http http ~ 48 ไบต์

http chunked encoding - 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

• ดังนั้นค่าใช้จ่ายต่อก้อนแต่ละชิ้นจึงไม่ใหญ่

นอกจากนี้โปรโตคอลทั้งสองทำงานผ่าน TCP ดังนั้นปัญหา TCP ทั้งหมดที่มีการเชื่อมต่อที่ยาวนานยังคงมีอยู่

คำถาม:

1. ทำไมโปรโตคอล websockets ถึงดีกว่า?
2. เหตุใดจึงมีการนำมาใช้แทนที่จะอัปเดตโปรโตคอล http

1) ทำไมโปรโตคอล WebSockets ถึงดีกว่า?

WebSockets จะดีกว่าสำหรับสถานการณ์ที่เกี่ยวข้องกับการสื่อสารที่มีความหน่วงต่ำโดยเฉพาะอย่างยิ่งสำหรับความหน่วงแฝงต่ำสำหรับข้อความของไคลเอ็นต์ไปยังเซิร์ฟเวอร์ สำหรับข้อมูลเซิร์ฟเวอร์ไปยังไคลเอนต์คุณสามารถรับเวลาในการตอบสนองค่อนข้างต่ำโดยใช้การเชื่อมต่อแบบยาวและการถ่ายโอนแบบเป็นก้อน อย่างไรก็ตามสิ่งนี้ไม่ได้ช่วยให้ลูกค้าทราบถึงความหน่วงของเซิร์ฟเวอร์ซึ่งต้องการการเชื่อมต่อใหม่ที่จะสร้างขึ้นสำหรับแต่ละข้อความลูกค้าไปยังเซิร์ฟเวอร์

การจับมือ HTTP 48 ไบต์ของคุณไม่เหมือนจริงสำหรับการเชื่อมต่อเบราว์เซอร์ HTTP ในโลกแห่งความจริงซึ่งมักจะมีข้อมูลหลายกิโลไบต์ที่ส่งเป็นส่วนหนึ่งของคำขอ (ทั้งสองทิศทาง) รวมถึงส่วนหัวและข้อมูลคุกกี้จำนวนมาก นี่คือตัวอย่างของคำขอ / ตอบสนองต่อการใช้ Chrome:

ตัวอย่างคำขอ (2800 ไบต์รวมถึงข้อมูลคุกกี้ 490 ไบต์โดยไม่มีข้อมูลคุกกี้):

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]]]

ตัวอย่างการตอบกลับ (355 ไบต์):

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

ทั้ง HTTP และ WebSockets มี handshake การเชื่อมต่อเริ่มต้นที่มีขนาดเท่ากัน แต่ด้วยการเชื่อมต่อ WebSocket การจับมือเริ่มต้นจะดำเนินการเพียงครั้งเดียวแล้วข้อความขนาดเล็กจะมีโอเวอร์เฮด 6 ไบต์เท่านั้น (2 สำหรับส่วนหัวและ 4 สำหรับค่ามาสก์) ค่าใช้จ่ายในการตอบสนองไม่มากนักจากขนาดของส่วนหัว แต่จากตรรกะไปยังการแยกวิเคราะห์ / จัดการ / จัดเก็บส่วนหัวเหล่านั้น นอกจากนี้เวลาแฝงในการตั้งค่าการเชื่อมต่อ TCP อาจเป็นปัจจัยที่ใหญ่กว่าขนาดหรือเวลาประมวลผลสำหรับแต่ละคำขอ

2) เหตุใดจึงมีการนำมาใช้แทนที่จะอัพเดตโปรโตคอล HTTP

มีความพยายามในการออกแบบโปรโตคอล HTTP ใหม่เพื่อให้ได้ประสิทธิภาพที่ดีขึ้นและลดเวลาในการตอบสนองเช่นSPDY , HTTP 2.0และQUIC QUICสิ่งนี้จะช่วยปรับปรุงสถานการณ์สำหรับคำขอ HTTP ปกติ แต่เป็นไปได้ว่า WebSockets และ / หรือ WebRTC DataChannel จะยังคงมีเวลาแฝงที่ต่ำกว่าสำหรับไคลเอ็นต์ไปยังการถ่ายโอนข้อมูลเซิร์ฟเวอร์กว่าโปรโตคอล HTTP (หรือจะใช้ในโหมดที่ดูเหมือน WebSockets มาก อย่างไรก็ตาม).

อัปเดต :

นี่คือกรอบการคิดเกี่ยวกับเว็บโปรโตคอล:

• TCP : เลเยอร์ต่ำ, สองทิศทาง, ฟูลดูเพล็กซ์และเลเยอร์การขนส่งตามคำสั่งที่รับประกัน ไม่รองรับเบราว์เซอร์ (ยกเว้นผ่านปลั๊กอิน / Flash)
• HTTP 1.0 : โพรโทคอลการขนส่งการตอบสนองการร้องขอชั้นบน TCP ไคลเอนต์ทำการร้องขอแบบเต็มหนึ่งเซิร์ฟเวอร์ให้การตอบสนองอย่างเต็มรูปแบบหนึ่งแล้วการเชื่อมต่อถูกปิด วิธีการร้องขอ (GET, POST, HEAD) มีความหมายเฉพาะสำหรับการทำธุรกรรมสำหรับทรัพยากรบนเซิร์ฟเวอร์
• HTTP 1.1 : รักษาลักษณะการตอบสนองการร้องขอของ HTTP 1.0 แต่อนุญาตให้การเชื่อมต่อเปิดอยู่สำหรับการร้องขอแบบเต็ม / การตอบกลับแบบเต็มหลายครั้ง (การตอบกลับหนึ่งครั้งต่อการร้องขอ) ยังคงมีส่วนหัวแบบเต็มในคำขอและการตอบกลับ แต่การเชื่อมต่อถูกนำมาใช้ใหม่และไม่ปิด HTTP 1.1 ยังเพิ่มวิธีการร้องขอเพิ่มเติม (OPTIONS, PUT, DELETE, TRACE, CONNECT) ซึ่งมีความหมายเฉพาะสำหรับธุรกรรมเช่นกัน อย่างไรก็ตามดังที่กล่าวไว้ในเบื้องต้นเกี่ยวกับข้อเสนอฉบับร่าง HTTP 2.0 การวางสาย HTTP 1.1 ไม่ได้ถูกนำไปใช้อย่างกว้างขวางดังนั้นสิ่งนี้จึง จำกัด ยูทิลิตี้ของ HTTP 1.1 อย่างมากเพื่อแก้ปัญหาเวลาแฝงระหว่างเบราว์เซอร์และเซิร์ฟเวอร์
• Long-Poll : การเรียงลำดับของ "แฮ็ค" ไปยัง HTTP (ทั้ง 1.0 หรือ 1.1) โดยที่เซิร์ฟเวอร์ไม่ตอบสนองทันที (หรือตอบเพียงบางส่วนด้วยส่วนหัว) ต่อคำขอของลูกค้า หลังจากการตอบสนองของเซิร์ฟเวอร์ไคลเอนต์ส่งคำขอใหม่ทันที (ใช้การเชื่อมต่อเดียวกันถ้าผ่าน HTTP 1.1)
• การสตรีม HTTP : เทคนิคที่หลากหลาย (การตอบกลับแบบหลายส่วน / แบบแยกส่วน) ที่อนุญาตให้เซิร์ฟเวอร์ส่งการตอบกลับมากกว่าหนึ่งครั้งไปยังคำขอไคลเอนต์เดียว W3C กำลังทำให้มาตรฐานนี้เป็นเหตุการณ์ที่เซิร์ฟเวอร์ส่งโดยใช้text/event-streamประเภท MIME เบราว์เซอร์ API (ซึ่งค่อนข้างคล้ายกับ WebSocket API) เรียกว่า EventSource API
• ดาวหาง / เซิร์ฟเวอร์พุช : นี่เป็นคำศัพท์ในร่มที่มีทั้งแบบสำรวจความยาวและการสตรีม HTTP ห้องสมุดดาวหางมักจะสนับสนุนเทคนิคหลายอย่างเพื่อลองและเพิ่มการรองรับข้ามเบราว์เซอร์และข้ามเซิร์ฟเวอร์ให้สูงสุด
• WebSockets : TCP ในตัวเลเยอร์การขนส่งที่ใช้ handshake อัพเกรดที่เป็นมิตรกับ HTTP ซึ่งแตกต่างจาก TCP ซึ่งเป็นการส่งผ่านข้อมูลแบบสตรีม WebSockets คือการส่งผ่านข้อความ: ข้อความถูกคั่นบนสายไฟและประกอบเข้าด้วยกันใหม่ก่อนที่จะส่งไปยังแอปพลิเคชัน การเชื่อมต่อ WebSocket เป็นการเชื่อมต่อสองทางฟูลดูเพล็กซ์และอายุการใช้งานยาวนาน หลังจากการร้องขอ / การตอบสนองการจับมือเริ่มต้นไม่มีความหมายของการทำธุรกรรมและมีค่าใช้จ่ายต่อข้อความน้อยมาก ไคลเอนต์และเซิร์ฟเวอร์อาจส่งข้อความได้ตลอดเวลาและต้องจัดการการรับข้อความแบบอะซิงโครนัส
• SPDY : ข้อเสนอที่ริเริ่มโดย Google เพื่อขยาย HTTP โดยใช้โปรโตคอลลวดที่มีประสิทธิภาพมากขึ้น แต่ยังคงความหมาย HTTP ทั้งหมด (คำขอ / ตอบกลับ, คุกกี้, การเข้ารหัส) SPDY แนะนำรูปแบบการจัดเฟรมใหม่ (พร้อมเฟรมที่มีความยาวนำหน้า) และระบุวิธีในการจัดวางคู่การร้องขอ / การตอบกลับ HTTP ลงในเลเยอร์การสร้างเฟรมใหม่ ส่วนหัวสามารถบีบอัดและส่วนหัวใหม่สามารถส่งหลังจากการเชื่อมต่อได้รับการจัดตั้งขึ้น SPDY มีการใช้งานจริงในเบราว์เซอร์และเซิร์ฟเวอร์
• HTTP 2.0 : มีเป้าหมายคล้ายกันกับ SPDY: ลดเวลาแฝงและค่าใช้จ่าย HTTP ในขณะที่ยังคงรักษาซีแมนทิกส์ HTTP ไว้ ร่างปัจจุบันมาจาก SPDY และกำหนด handshake อัพเกรดและกำหนดกรอบข้อมูลที่คล้ายกับมาตรฐาน WebSocket สำหรับ handshake และ framing มาก ข้อเสนอฉบับร่าง HTTP 2.0 ทางเลือก (httpbis-speed-mobility) ใช้ WebSockets สำหรับเลเยอร์การขนส่งและเพิ่ม SPDY มัลติเพล็กซิ่งและการจับคู่ HTTP เป็นส่วนขยาย WebSocket (ส่วนขยาย WebSocket ถูกเจรจาระหว่างการจับมือกัน)
• WebRTC / CU-WebRTC : ข้อเสนอเพื่ออนุญาตการเชื่อมต่อแบบ peer-to-peer ระหว่างเบราว์เซอร์ สิ่งนี้อาจเปิดใช้งานการสื่อสารเวลาแฝงเฉลี่ยและสูงสุดต่ำกว่าเนื่องจากในขณะที่การรับส่งข้อมูลพื้นฐานคือ SDP / ดาตาแกรมมากกว่า TCP สิ่งนี้ช่วยให้การจัดส่งแพ็กเก็ต / ข้อความที่ไม่เป็นไปตามคำสั่งซึ่งหลีกเลี่ยงปัญหา TCP ของ spikes แฝงที่เกิดจากแพ็กเก็ตที่ถูกปล่อยซึ่งล่าช้าในการส่งมอบแพ็กเก็ตต่อมาทั้งหมด (เพื่อรับประกันการจัดส่งตามลำดับ)
• QUIC : เป็นโปรโตคอลทดลองที่มุ่งลดความหน่วงแฝงของเว็บผ่าน TCP บนพื้นผิว QUIC คล้ายกับ TCP + TLS + SPDY ที่ใช้งานบน UDP QUIC ให้บริการมัลติเพล็กซิ่งและโฟลว์คอนโทรลเทียบเท่ากับ HTTP / 2 ความปลอดภัยเทียบเท่ากับ TLS และซีแมนทิกส์การเชื่อมต่อความน่าเชื่อถือและการควบคุมความแออัดเทียบเท่ากับ TCP เนื่องจาก TCP ถูกนำไปใช้ในเมล็ดของระบบปฏิบัติการและเฟิร์มแวร์กล่องจดหมายกลางการทำการเปลี่ยนแปลงที่สำคัญกับ TCP จึงเป็นไปไม่ได้ อย่างไรก็ตามเนื่องจาก QUIC ถูกสร้างขึ้นที่ด้านบนของ UDP จึงมีข้อ จำกัด ดังกล่าว QUIC ได้รับการออกแบบและปรับให้เหมาะสมสำหรับความหมาย HTTP / 2

การอ้างอิง :

• HTTP :
  • หน้า Wikipedia HTTP
  • W3C รายการร่าง / โปรโตคอลที่เกี่ยวข้องกับ HTTP
  • รายการ IETF HTTP / 1.1 และ HTTP / 2.0 Draft
• เหตุการณ์ที่เซิร์ฟเวอร์ส่ง :
  • W3C เหตุการณ์ที่เซิร์ฟเวอร์ส่ง / EventSource คำแนะนำผู้สมัคร
  • เหตุการณ์ W3C ที่เซิร์ฟเวอร์ส่ง / ร่างแหล่งเหตุการณ์
• WebSockets :
  • IETF RFC 6455 WebSockets Protocol
  • IETF RFC 6455 WebSocket Errata
• SPDY :
  • IETF SPDY ฉบับร่าง
• HTTP 2.0 :
  • IETF HTTP 2.0 httpbis-http2 Draft
  • IETF HTTP 2.0 httpbis-speed-mobility Draft
  • IETF httpbis- เครือข่ายที่เป็นมิตรกับร่าง - ข้อเสนอที่เกี่ยวข้องกับ HTTP 2.0 ที่เก่ากว่า
• WebRTC :
  • W3C WebRTC API Draft
  • รายชื่อ IETF WebRTC Draft
  • IETF WebRTC ภาพรวมร่าง
  • IETF WebRTC DataChannel Draft
  • หน้าเริ่มต้นข้อเสนอ Microsoft CU-WebRTC
• QUIC :
  • โครงการ Chromicum QUIC
  • IETF QUIC Draft

ดูเหมือนว่าคุณจะถือว่า WebSocket เป็นสิ่งทดแทนสำหรับ HTTP มันไม่ใช่. มันเป็นส่วนเสริม

กรณีการใช้งานหลักของ WebSockets คือแอปพลิเคชัน Javascript ซึ่งทำงานในเว็บเบราว์เซอร์และรับข้อมูลแบบเรียลไทม์จากเซิร์ฟเวอร์ เกมเป็นตัวอย่างที่ดี

ก่อน WebSockets มีเพียงวิธีเดียวเท่านั้นที่แอปพลิเคชัน Javascript โต้ตอบกับเซิร์ฟเวอร์ XmlHttpRequestวิธีเดียวสำหรับการใช้งานจาวาสคริการโต้ตอบกับเซิร์ฟเวอร์ผ่าน แต่สิ่งเหล่านี้มีข้อเสียที่สำคัญ: เซิร์ฟเวอร์ไม่สามารถส่งข้อมูลเว้นแต่ว่าลูกค้าได้ร้องขออย่างชัดเจน

แต่คุณสมบัติ WebSocket ใหม่ช่วยให้เซิร์ฟเวอร์สามารถส่งข้อมูลได้ทุกเมื่อที่ต้องการ สิ่งนี้ทำให้สามารถใช้เกมที่มีเบราว์เซอร์ที่มีความล่าช้าน้อยกว่าและไม่ต้องใช้แฮ็กที่น่าเกลียดเช่น AJAX long-polling หรือปลั๊กอินของเบราว์เซอร์

ดังนั้นทำไมไม่ใช้ HTTP ปกติกับคำขอและการตอบกลับที่สตรีม

ในความคิดเห็นไปยังคำตอบอื่นคุณแนะนำให้สตรีมคำขอของลูกค้าและเนื้อหาการตอบสนองแบบอะซิงโครนัส

อันที่จริงแล้ว WebSockets นั้นโดยทั่วไปแล้ว ความพยายามในการเปิดการเชื่อมต่อ WebSocket จากไคลเอ็นต์ดูเหมือนคำขอ HTTP ในตอนแรก แต่คำสั่งพิเศษในส่วนหัว (อัปเกรด: websocket) บอกให้เซิร์ฟเวอร์เริ่มการสื่อสารในโหมดอะซิงโครนัสนี้ ร่างแรกของโปรโตคอล WebSocketไม่ได้มีอะไรมากไปกว่านั้นและการจับมือกันบางอย่างเพื่อให้แน่ใจว่าเซิร์ฟเวอร์เข้าใจว่าลูกค้าต้องการสื่อสารแบบอะซิงโครนัสอย่างแท้จริง แต่แล้วมันก็รู้ว่าพร็อกซีเซิร์ฟเวอร์จะสับสนเพราะมันถูกใช้ในรูปแบบการร้องขอ / ตอบกลับตามปกติของ HTTP สถานการณ์การโจมตีที่อาจเกิดขึ้นกับเซิร์ฟเวอร์พร็อกซี่ที่ถูกค้นพบ เพื่อป้องกันสิ่งนี้จำเป็นต้องทำให้การรับส่งข้อมูลของ WebSocket ไม่เหมือนกับการรับส่งข้อมูล HTTP ปกติใด ๆ นั่นเป็นสาเหตุที่มีการนำคีย์มาสก์รุ่นสุดท้ายของโปรโตคอล

REST API ปกติใช้ HTTP เป็นโปรโตคอลพื้นฐานสำหรับการสื่อสารซึ่งเป็นไปตามคำขอและกระบวนทัศน์การตอบสนองหมายถึงการสื่อสารที่เกี่ยวข้องกับลูกค้าที่ขอข้อมูลหรือทรัพยากรบางอย่างจากเซิร์ฟเวอร์และเซิร์ฟเวอร์ตอบกลับไปยังลูกค้านั้น อย่างไรก็ตาม HTTP เป็นโปรโตคอลไร้สัญชาติดังนั้นทุกรอบการตอบสนองคำขอจะสิ้นสุดลงโดยไม่จำเป็นต้องทำซ้ำข้อมูลส่วนหัวและข้อมูลเมตา สิ่งนี้จะเกิดความล่าช้าเพิ่มเติมในกรณีที่มีการตอบสนองคำขอซ้ำบ่อยครั้ง

ด้วย WebSockets แม้ว่าการสื่อสารยังคงเริ่มต้นเป็น handshake HTTP เริ่มต้น แต่เป็นการอัพเกรดเพิ่มเติมเพื่อติดตามโปรโตคอล WebSockets (เช่นถ้าทั้งเซิร์ฟเวอร์และไคลเอนต์สอดคล้องกับโปรโตคอลเนื่องจากไม่ใช่เอนทิตีทั้งหมดที่สนับสนุนโปรโตคอล WebSockets)

ขณะนี้มี WebSockets เป็นไปได้ที่จะสร้างการเชื่อมต่อทั้งสองและเต็มเพล็กซ์ระหว่างไคลเอนต์และเซิร์ฟเวอร์ ซึ่งหมายความว่าไม่เหมือนคำขอและการตอบสนองการเชื่อมต่อจะเปิดอยู่ตราบใดที่แอปพลิเคชั่นทำงานอยู่ (เช่นเป็นแบบถาวร) และเนื่องจากเป็นแบบเพล็กซ์เต็มรูปแบบการสื่อสารแบบสองทางพร้อมกันจึงเป็นไปได้ การสื่อสารและ 'ดัน' ข้อมูลบางอย่างไปยังลูกค้าเมื่อมีข้อมูลใหม่ (ที่ลูกค้าสนใจ) จะพร้อมใช้งาน

โพรโทคอล WebSockets เป็น stateful และช่วยให้คุณสามารถใช้รูปแบบการส่งข้อความ Publish-Subscribe (หรือ Pub / Sub) ซึ่งเป็นแนวคิดหลักที่ใช้ในเทคโนโลยีเรียลไทม์ที่คุณสามารถรับการปรับปรุงใหม่ในรูปแบบของเซิร์ฟเวอร์โดยไม่ต้อง ลูกค้าต้องร้องขอ (รีเฟรชหน้า) ซ้ำ ๆ ตัวอย่างของแอปพลิเคชันดังกล่าวคือการติดตามตำแหน่งของรถ Uber การแจ้งเตือนแบบพุชราคาตลาดของการอัปเดตแบบเรียลไทม์แชทเกมเล่นหลายคนเครื่องมือถ่ายทอดสดออนไลน์ที่ทำงานร่วมกันเป็นต้น

คุณสามารถตรวจสอบบทความการดำน้ำลึกบนเว็บซ็อกเก็ตซึ่งอธิบายประวัติของโพรโทคอลนี้ว่ามันเป็นอย่างไรสิ่งที่มันใช้และวิธีที่คุณสามารถนำไปใช้เอง

นี่คือวิดีโอจากงานนำเสนอที่ฉันทำเกี่ยวกับ WebSockets และวิธีที่แตกต่างจากการใช้ REST API ปกติ: การสร้างมาตรฐานและการใช้ประโยชน์จากการเพิ่มขึ้นของข้อมูลสตรีมชี้แจง

สำหรับ TL; DR ต่อไปนี้เป็น 2 เซ็นต์และเวอร์ชันที่ง่ายกว่าสำหรับคำถามของคุณ:

1. WebSockets ให้ประโยชน์เหล่านี้ผ่าน HTTP:

   • การเชื่อมต่อ stateful ถาวรสำหรับช่วงเวลาของการเชื่อมต่อ
   • เวลาแฝงต่ำ: ใกล้กับการสื่อสารแบบเรียลไทม์ระหว่างเซิร์ฟเวอร์ / ไคลเอ็นต์เนื่องจากไม่มีค่าใช้จ่ายในการสร้างการเชื่อมต่อใหม่สำหรับแต่ละคำขอตามที่ HTTP ต้องการ
   • Full duplex: ทั้งเซิร์ฟเวอร์และไคลเอนต์สามารถส่ง / รับพร้อมกัน

2. WebSocket และโปรโตคอล HTTP ได้รับการออกแบบมาเพื่อแก้ไขปัญหาต่าง ๆ IE WebSocket ได้รับการออกแบบมาเพื่อปรับปรุงการสื่อสารแบบสองทิศทางในขณะที่ HTTP ถูกออกแบบมาให้ไร้สัญชาติโดยใช้รูปแบบการร้องขอ / ตอบกลับ นอกเหนือจากการแชร์พอร์ตด้วยเหตุผลดั้งเดิม (การรุกของไฟร์วอลล์ / พร็อกซี) แล้วยังมีพื้นดินทั่วไปที่จะรวมเข้าไว้ในโปรโตคอลเดียว

ทำไมโปรโตคอล websockets ถึงดีกว่า?

ฉันไม่คิดว่าเราสามารถเปรียบเทียบพวกเขาแบบเคียงข้างกันว่าใครจะดีกว่า นั่นจะไม่เป็นการเปรียบเทียบที่ยุติธรรมเพียงเพราะพวกเขากำลังแก้ปัญหาที่แตกต่างกันสองอย่าง ความต้องการของพวกเขาแตกต่างกัน มันจะเป็นเหมือนการเปรียบเทียบแอปเปิ้ลกับส้ม พวกเขาแตกต่าง.

HTTPเป็นโปรโตคอลการตอบสนองการร้องขอ ไคลเอนต์ (เบราว์เซอร์) ต้องการสิ่งที่เซิร์ฟเวอร์มอบให้ นั่นคือ. หากไคลเอ็นต์ข้อมูลต้องการมีขนาดใหญ่เซิร์ฟเวอร์อาจส่งข้อมูลการสตรีมเพื่อหลีกเลี่ยงปัญหาบัฟเฟอร์ที่ไม่ต้องการ ความต้องการหรือปัญหาหลักคือวิธีการร้องขอจากลูกค้าและวิธีตอบสนองทรัพยากร (hybertext) ที่พวกเขาร้องขอ นั่นคือที่ HTTP ส่องแสง

ใน HTTP คำขอของไคลเอ็นต์เท่านั้น เซิร์ฟเวอร์ตอบกลับเท่านั้น

WebSocketไม่ได้เป็นโปรโตคอลตอบสนองคำขอที่ลูกค้าเท่านั้นที่สามารถร้องขอ มันเป็นซ็อกเก็ต (คล้ายกับซ็อกเก็ต TCP) หมายถึงเมื่อการเชื่อมต่อเปิดขึ้นฝั่งใดฝั่งหนึ่งสามารถส่งข้อมูลได้จนกว่าการเชื่อมต่อ TCP จะถูกปิด มันก็เหมือนซ็อกเก็ตปกติ ข้อแตกต่างกับซ็อกเก็ต TCP คือ websocket สามารถใช้ในเว็บได้ ในเว็บเรามีข้อ จำกัด มากมายสำหรับซ็อกเก็ตปกติ ไฟร์วอลล์ส่วนใหญ่จะบล็อกพอร์ตอื่นที่ไม่ใช่ 80 และ 433 ที่ใช้ HTTP พร็อกซีและตัวกลางจะมีปัญหาเช่นกันดังนั้นเพื่อให้โปรโตคอลง่ายขึ้นในการปรับใช้กับโครงสร้างพื้นฐาน websocket ที่มีอยู่ใช้จับมือ HTTP ในการอัพเกรด ซึ่งหมายความว่าเมื่อการเชื่อมต่อครั้งแรกกำลังจะเปิดลูกค้าส่งคำขอ HTTP เพื่อบอกเซิร์ฟเวอร์ว่า "นั่นไม่ใช่คำขอ HTTP โปรดอัปเกรดเป็นโปรโตคอล websocket"

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

เมื่อเซิร์ฟเวอร์เข้าใจคำขอและอัพเกรดเป็นโปรโตคอล websocket จะไม่มีการใช้โปรโตคอล HTTP อีกต่อไป

ดังนั้นคำตอบของฉันคือไม่มีใครดีกว่ากัน พวกเขาแตกต่างอย่างสิ้นเชิง

เหตุใดจึงมีการนำมาใช้แทนที่จะอัปเดตโปรโตคอล http

เราสามารถสร้างทุกอย่างภายใต้ชื่อHTTP ได้เช่นกัน แต่เราจะ? หากพวกเขาเป็นสองสิ่งที่แตกต่างกันฉันจะชอบชื่อสองชื่อ Hickson และMichael Carter ก็เช่นกัน

คำตอบอื่น ๆ ดูเหมือนจะไม่ได้สัมผัสกับประเด็นสำคัญที่นี่และนั่นคือคุณไม่ต้องพูดถึงว่าต้องการการสนับสนุนเว็บเบราว์เซอร์ในฐานะลูกค้า ข้อ จำกัด ส่วนใหญ่ของ HTTP ธรรมดาด้านบนคาดว่าคุณจะทำงานกับเบราว์เซอร์ / การใช้งาน JS

โปรโตคอล HTTP นั้นมีความสามารถเต็มที่ในการสื่อสารแบบดูเพล็กซ์ มันเป็นเรื่องถูกกฎหมายที่จะให้ไคลเอนต์ทำการ POST ด้วยการถ่ายโอนการเข้ารหัสแบบ chunked และเซิร์ฟเวอร์เพื่อส่งคืนการตอบกลับด้วยเนื้อหาการเข้ารหัสแบบ chunked นี่จะเป็นการลบส่วนหัวของค่าใช้จ่ายในเวลาเริ่มต้น

ดังนั้นหากสิ่งที่คุณกำลังมองหาคือ full-duplex ให้ควบคุมทั้งไคลเอนต์และเซิร์ฟเวอร์และไม่สนใจในการสร้างเฟรม / ฟีเจอร์พิเศษของ websockets แล้วฉันจะโต้แย้งว่า HTTP นั้นเป็นวิธีที่ง่ายกว่าโดยมี latency / CPU ที่ต่ำกว่า จะแตกต่างกันในหน่วยไมโครวินาทีหรือน้อยกว่าเท่านั้น)