เปรียบเทียบ WebSocket, Server-Sent Events, Long Polling, WebRTC และ WebTransport

 (rxdb.info)
4 คะแนน โดย GN⁺ 2024-03-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เปรียบเทียบ WebSocket, Server-Sent Events, Long Polling, WebRTC และ WebTransport

  • ในเว็บแอปพลิเคชันแบบเรียลไทม์สมัยใหม่ ความสามารถในการส่งอีเวนต์จากเซิร์ฟเวอร์ไปยังไคลเอนต์เป็นสิ่งจำเป็น
  • จากความต้องการนี้ จึงมีการพัฒนาวิธีการหลายแบบขึ้นมา ซึ่งแต่ละแบบก็มีข้อดีและข้อเสียต่างกัน
  • ในช่วงแรก Long Polling เป็นตัวเลือกเดียวที่ใช้งานได้ แต่ต่อมาก็มี WebSocket ซึ่งเป็นโซลูชันที่แข็งแกร่งกว่าสำหรับการสื่อสารสองทาง
  • หลังจาก WebSocket ก็มี Server-Sent Events (SSE) ซึ่งเป็นวิธีที่เรียบง่ายกว่าสำหรับการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์
  • โปรโตคอล WebTransport มอบแนวทางที่มีประสิทธิภาพ ยืดหยุ่น และขยายระบบได้ดีกว่า และดูมีแนวโน้มว่าจะเข้ามาพลิกโฉมด้านนี้มากยิ่งขึ้น
  • สำหรับบางกรณีการใช้งาน WebRTC ก็อาจเป็นตัวเลือกที่ควรพิจารณาสำหรับอีเวนต์ระหว่างเซิร์ฟเวอร์กับไคลเอนต์

Long Polling คืออะไร?

  • Long Polling เป็นเทคนิคแบบ “แฮ็ก” รุ่นแรกที่ทำให้สามารถส่งข้อความระหว่างเซิร์ฟเวอร์กับไคลเอนต์ผ่าน HTTP ในเบราว์เซอร์ได้
  • ต่างจาก Polling แบบดั้งเดิมที่ไคลเอนต์จะคอยร้องขอข้อมูลจากเซิร์ฟเวอร์เป็นระยะ Long Polling จะสร้างการเชื่อมต่อไปยังเซิร์ฟเวอร์และค้างไว้จนกว่าจะมีข้อมูลใหม่พร้อมใช้งาน
  • เมื่อเซิร์ฟเวอร์มีข้อมูลใหม่ ก็จะส่งคำตอบกลับไปยังไคลเอนต์และปิดการเชื่อมต่อ
  • ทันทีที่ไคลเอนต์ได้รับคำตอบจากเซิร์ฟเวอร์ ก็จะเริ่มคำขอใหม่ และกระบวนการนี้จะเกิดซ้ำไปเรื่อย ๆ
  • วิธีนี้ช่วยให้การอัปเดตข้อมูลเกิดขึ้นได้แทบจะทันที และลดทราฟฟิกเครือข่ายที่ไม่จำเป็นรวมถึงภาระของเซิร์ฟเวอร์
  • อย่างไรก็ตาม มันยังคงก่อให้เกิดความหน่วงในการสื่อสาร และมีประสิทธิภาพน้อยกว่าเทคโนโลยีเรียลไทม์อื่น ๆ เช่น WebSocket

WebSocket คืออะไร?

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

Server-Sent Events คืออะไร?

  • Server-Sent Events (SSE) มอบวิธีมาตรฐานในการ push การอัปเดตจากเซิร์ฟเวอร์ไปยังไคลเอนต์ผ่าน HTTP
  • ต่างจาก WebSocket, SSE ถูกออกแบบมาสำหรับการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์เท่านั้น จึงเหมาะกับสถานการณ์ที่ไคลเอนต์ต้องรับการอัปเดตแบบเรียลไทม์โดยไม่จำเป็นต้องส่งข้อมูลกลับไปยังเซิร์ฟเวอร์

WebTransport API คืออะไร?

  • WebTransport เป็น API สมัยใหม่ที่ออกแบบมาสำหรับการสื่อสารที่มีประสิทธิภาพและมีความหน่วงต่ำระหว่างเว็บไคลเอนต์กับเซิร์ฟเวอร์
  • มันอาศัยโปรโตคอล HTTP/3 QUIC เพื่อเปิดให้ใช้งานความสามารถด้านการส่งข้อมูลที่หลากหลาย
  • WebTransport เป็นเครื่องมือที่ทรงพลังสำหรับแอปพลิเคชันที่ต้องการเครือข่ายประสิทธิภาพสูง เช่น เกมแบบเรียลไทม์ การสตรีมสด และแพลตฟอร์มการทำงานร่วมกัน
  • ปัจจุบัน WebTransport ยังอยู่ในขั้น Working Draft และยังไม่ได้รับการนำไปใช้อย่างแพร่หลาย

WebRTC คืออะไร?

  • WebRTC (เว็บเรียลไทม์คอมมิวนิเคชัน) เป็นทั้งโครงการโอเพนซอร์สและมาตรฐาน API ที่ทำให้สามารถใช้งานความสามารถด้านการสื่อสารแบบเรียลไทม์ (RTC) ภายในเว็บเบราว์เซอร์และแอปพลิเคชันบนมือถือได้ โดยไม่ต้องมีโครงสร้างพื้นฐานเซิร์ฟเวอร์ที่ซับซ้อนหรือการติดตั้งปลั๊กอินเพิ่มเติม
  • WebRTC รองรับการเชื่อมต่อแบบ peer-to-peer สำหรับการแลกเปลี่ยนเสียง วิดีโอ และข้อมูลระหว่างเบราว์เซอร์
  • WebRTC ถูกออกแบบมาให้ทำงานผ่าน NAT และไฟร์วอลล์ได้ โดยใช้โปรโตคอลอย่าง ICE, STUN และ TURN เพื่อสร้างการเชื่อมต่อระหว่าง peer

ข้อจำกัดของเทคโนโลยี

  • มีเพียง WebSocket และ WebTransport เท่านั้นที่สามารถส่งข้อมูลได้ทั้งสองทิศทาง
  • ข้อจำกัดที่ 6 คำขอต่อโดเมนทำให้การใช้งานวิธีส่งข้อความแบบต่อเนื่องระหว่างเซิร์ฟเวอร์กับไคลเอนต์ทั้งหมดมีข้อจำกัดด้านการใช้งาน
  • ในแอปมือถือ ระบบปฏิบัติการจะย้ายแอปไปทำงานเบื้องหลังโดยอัตโนมัติหากไม่มีการใช้งานเป็นระยะเวลาหนึ่ง และจะปิดการเชื่อมต่อที่เปิดอยู่
  • ในสภาพแวดล้อมองค์กร พร็อกซีและไฟร์วอลล์จำนวนมากจะบล็อกการเชื่อมต่อที่ไม่ใช่ HTTP ทำให้การผสานเซิร์ฟเวอร์ WebSocket เข้ากับโครงสร้างพื้นฐานทำได้ยาก

การเปรียบเทียบประสิทธิภาพ

  • หากต้องการเปรียบเทียบประสิทธิภาพของ WebSocket, SSE, Long Polling และ WebTransport โดยตรง ควรประเมินปัจจัยสำคัญ เช่น ความหน่วง ปริมาณรับส่งข้อมูล ภาระของเซิร์ฟเวอร์ และความสามารถในการขยายระบบภายใต้เงื่อนไขที่หลากหลาย

ความหน่วง

  • WebSocket: ให้ความหน่วงต่ำที่สุดด้วยการสื่อสารแบบสองทิศทางเต็มรูปแบบผ่านการเชื่อมต่อถาวรเพียงครั้งเดียว
  • Server-Sent Events: ให้ความหน่วงต่ำสำหรับการสื่อสารจากเซิร์ฟเวอร์ไปยังไคลเอนต์ แต่ไม่สามารถส่งข้อความกลับไปยังเซิร์ฟเวอร์ได้โดยไม่มีคำขอ HTTP เพิ่มเติม
  • Long Polling: ทำให้เกิดความหน่วงสูงกว่า เพราะอาศัยการสร้างการเชื่อมต่อ HTTP ใหม่สำหรับการส่งข้อมูลแต่ละครั้ง
  • WebTransport: คาดว่าจะให้ความหน่วงต่ำใกล้เคียงกับ WebSocket และได้ประโยชน์จากโปรโตคอล HTTP/3 ในด้านการ multiplex และการควบคุมความหนาแน่นของทราฟฟิกที่มีประสิทธิภาพมากกว่า

ปริมาณรับส่งข้อมูล

  • WebSocket: สามารถทำปริมาณรับส่งข้อมูลได้สูงจากการเชื่อมต่อแบบถาวร แต่ประสิทธิภาพอาจลดลงเมื่อไคลเอนต์ไม่สามารถประมวลผลข้อมูลได้เร็วเท่ากับที่เซิร์ฟเวอร์ส่งมา
  • Server-Sent Events: สามารถกระจายข้อความไปยังไคลเอนต์จำนวนมากได้ด้วยโอเวอร์เฮดที่น้อยกว่า WebSocket จึงอาจทำปริมาณรับส่งข้อมูลได้สูงกว่าสำหรับการสื่อสารทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์
  • Long Polling: โดยทั่วไปให้ปริมาณรับส่งข้อมูลต่ำกว่า เพราะมีโอเวอร์เฮดจากการเปิดและปิดการเชื่อมต่อบ่อยครั้ง
  • WebTransport: คาดว่าจะรองรับปริมาณรับส่งข้อมูลสูงสำหรับทั้งสตรีมแบบสองทางและทางเดียวภายในการเชื่อมต่อเดียว และอาจเหนือกว่า WebSocket ในสถานการณ์ที่ต้องใช้หลายสตรีม

ความสามารถในการขยายระบบและภาระของเซิร์ฟเวอร์

  • WebSocket: การคงการเชื่อมต่อ WebSocket จำนวนมากไว้พร้อมกันอาจเพิ่มภาระของเซิร์ฟเวอร์อย่างมาก ซึ่งส่งผลต่อความสามารถในการขยายระบบของแอปพลิเคชันที่มีผู้ใช้จำนวนมาก
  • Server-Sent Events: มีโอเวอร์เฮดของการเชื่อมต่อน้อยกว่า WebSocket จึงขยายระบบได้ดีกว่าในสถานการณ์ที่ต้องการอัปเดตจากเซิร์ฟเวอร์ไปยังไคลเอนต์เป็นหลัก
  • Long Polling: มีความสามารถในการขยายระบบต่ำที่สุด เนื่องจากภาระสูงของเซิร์ฟเวอร์ที่เกิดจากการตั้งค่าการเชื่อมต่อบ่อยครั้ง
  • WebTransport: ถูกออกแบบมาให้ใช้ประโยชน์จากประสิทธิภาพของ HTTP/3 ในการจัดการการเชื่อมต่อและสตรีม จึงมีความสามารถในการขยายระบบสูงพร้อมลดภาระของเซิร์ฟเวอร์เมื่อเทียบกับ WebSocket และ SSE

คำแนะนำและความเหมาะสมของกรณีใช้งาน

  • ในโลกของเทคโนโลยีการสื่อสารระหว่างเซิร์ฟเวอร์กับไคลเอนต์ แต่ละแบบมีจุดแข็งเฉพาะตัวและเหมาะกับกรณีใช้งานที่ต่างกัน
  • Server-Sent Events (SSE) เป็นตัวเลือกที่ง่ายที่สุดในการนำไปใช้งาน และสามารถหลีกเลี่ยงข้อจำกัดของไฟร์วอลล์ในองค์กรเพื่อลดปัญหาทางเทคนิคได้
  • WebSocket โดดเด่นในสถานการณ์ที่ต้องการการสื่อสารแบบสองทางอย่างต่อเนื่อง
  • WebTransport ยังมีอุปสรรคในการนำไปใช้จริง โดยยังไม่ได้รับการรองรับอย่างแพร่หลายในเฟรมเวิร์กฝั่งเซิร์ฟเวอร์รวมถึง Node.js และยังไม่เข้ากันได้กับ Safari
  • Long Polling ไม่มีประสิทธิภาพ และไม่แนะนำสำหรับกรณีใช้งานส่วนใหญ่ เนื่องจากมีโอเวอร์เฮดสูงจากการต้องสร้างการเชื่อมต่อ HTTP ใหม่ซ้ำ ๆ

ปัญหาที่ทราบอยู่แล้ว

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

ความเห็นของ GN⁺

  • บทความนี้เปรียบเทียบเทคโนโลยีการสื่อสารหลายแบบที่นักพัฒนาสามารถเลือกใช้เมื่อสร้างเว็บแอปพลิเคชันแบบเรียลไทม์ จึงให้ข้อมูลที่มีประโยชน์ต่อการตัดสินใจเลือกเทคโนโลยี
  • WebSocket และ SSE ถูกใช้งานอย่างแพร่หลายอยู่แล้ว โดยเฉพาะ WebSocket ที่ได้รับความนิยมมากในแอปพลิเคชันที่ต้องการการสื่อสารสองทาง เช่น แชตแบบเรียลไทม์หรือเกม
  • WebTransport ยังอยู่ในขั้นร่างและยังไม่ได้รับการรองรับอย่างกว้างขวาง จึงอาจยังไม่เหมาะกับการนำไปใช้ในโปรเจกต์จริงในตอนนี้ อย่างไรก็ตาม ในฐานะเทคโนโลยีบนพื้นฐาน HTTP/3 มันมีศักยภาพสูงในอนาคตและน่าจับตามอง
  • Long Polling แม้จะเป็นเทคโนโลยีเก่า แต่ก็อาจยังมีประโยชน์ในบางสถานการณ์ โดยเฉพาะเมื่อความเข้ากันได้กับระบบ legacy เป็นสิ่งสำคัญ
  • เมื่อเลือกเทคโนโลยีการสื่อสารแบบเรียลไทม์ ควรพิจารณาความต้องการของแอปพลิเคชัน เบราว์เซอร์และโครงสร้างพื้นฐานเซิร์ฟเวอร์ที่รองรับ รวมถึงระดับความ成熟ของเทคโนโลยีนั้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-19
ความคิดเห็นจาก Hacker News

  • แสดงความชื่นชอบต่อ Server Sent Events(SSE) พร้อมกล่าวถึงการไม่มี flow control (backpressure) และการ multiplexing ใน WebSockets, ข้อจำกัดของ SSE ที่ส่งข้อมูลไบนารีไม่ได้, และปัญหาที่อาจเกิดขึ้นเมื่อนำ WebTransport มาใช้

    "ชื่นชอบ Server Sent Events และแสดงความกังวลเกี่ยวกับการไม่มี flow control และ multiplexing ใน WebSockets, ข้อจำกัดของ SSE ในการส่งข้อมูลไบนารี, และปัญหาในการนำ WebTransport มาใช้"

  • ชี้ให้เห็นความยากในการทำฟีเจอร์แบบเรียลไทม์ในสภาพแวดล้อมองค์กรและข้อจำกัดในการแก้ปัญหาจากระบบราชการ พร้อมเสนอการเพิ่มปุ่มรีเฟรชเป็นทางออกง่าย ๆ

    "ชี้ให้เห็นความยากของการทำฟีเจอร์เรียลไทม์ในสภาพแวดล้อมองค์กรและปัญหาจากระบบราชการ พร้อมเสนอการเพิ่มปุ่มรีเฟรชเป็นวิธีแก้ที่เรียบง่าย"

  • มีความเห็นว่าเมื่อสมมติว่าใช้ HTTP/2 ขึ้นไป การใช้ EventSource ร่วมกับ fetch() น่าจะดีพอ ๆ กับโปรโตคอลอื่นที่ใช้การเชื่อมต่อ TCP เดียว และกล่าวถึงการใช้ UDP ของ HTTP/3

    "เสนอความเห็นเชิงบวกว่าเมื่อใช้ HTTP/2 ขึ้นไป การจับคู่ EventSource กับ fetch() มีประสิทธิภาพดี และกล่าวถึงการใช้ UDP ของ HTTP/3"

  • ระบุว่าไม่เข้าใจว่าทำไม WebSockets และ SSE จึงไม่รองรับการส่ง header ในคำขอเริ่มต้น และชี้ให้เห็นว่าสุดท้ายเรื่องนี้ถูกโยนให้คนที่ต้องทำระบบยืนยันตัวตนสำหรับบริการเรียลไทม์รับผิดชอบเอง

    "ตั้งคำถามต่อการที่ WebSockets และ SSE ไม่รองรับการส่ง header ในคำขอเริ่มต้น และชี้ให้เห็นปัญหาการพึ่งพาผู้พัฒนาที่ต้องทำระบบยืนยันตัวตนของบริการเรียลไทม์เอง"

  • กล่าวถึงปัญหาในการดูแล WebSockets และ SSE ในระดับขนาดใหญ่, ความต้องการด้านการสังเกตการณ์เป็นพิเศษของฝั่งแบ็กเอนด์, ความยากในการดีบักบนอุปกรณ์พกพา, ต้นทุนของการเชื่อมต่อเครือข่าย และความยากของการรักษาสถานะ

    "มีการกล่าวถึงปัญหาการจัดการ WebSockets และ SSE ในระดับใหญ่, ความยากในการดีบักทั้งฝั่งแบ็กเอนด์และอุปกรณ์พกพา, รวมถึงต้นทุนของการเชื่อมต่อเครือข่ายและปัญหาการคงสถานะ"

  • แชร์ประสบการณ์จากการออกแบบระบบประมูลออนไลน์ในยุค 90 ที่จัดการอัปเดตแบบเรียลไทม์ผ่าน server push/HTTP streaming

    "แชร์ประสบการณ์การจัดการอัปเดตแบบเรียลไทม์ผ่าน server push/HTTP streaming ในระบบประมูลออนไลน์ยุค 90"

  • แสดงความคิดถึงความเรียบง่ายของ Long polling พร้อมเอ่ยถึงการประเมิน WebRTC ในเชิงบวก

    "แสดงความคิดถึงความเรียบง่ายของ Long polling และชื่นชม WebRTC ในเชิงบวก"

  • ในฐานะคนที่ทำงานที่ Stream แนะนำให้ใช้ websockets พร้อมส่ง keep-alive ping ทุก 30 วินาทีในกรณีส่วนใหญ่ และกล่าวถึง latency ต่ำของ WebTransport รวมถึงความเหมาะสมกับเกมเรียลไทม์หรือการส่งข้อมูลเสียง

    "แนะนำการใช้ websockets พร้อม keep-alive ping และเสนอให้พิจารณา WebTransport สำหรับ latency ต่ำ รวมถึงเกมเรียลไทม์และการส่งข้อมูลเสียง"

  • แสดงความเห็นเชิงวิจารณ์ต่อบทความที่ไม่ได้พูดถึงข้อดีของการสื่อสารแบบ UDP-based ของ WebRTC

    "วิจารณ์ว่าบทความละเลยข้อดีของการสื่อสารแบบ UDP-based ของ WebRTC"