พื้นฐานของโลกดิจิทัลทั้งหมดคือการสื่อสารระหว่างเครื่องจักร คลายเอนต์ที่ได้รับอนุญาตสร้างคำขอที่เซิร์ฟเวอร์ได้รับ ตีความ และให้การตอบสนองที่เหมาะสม นี่คือความเข้าใจทั่วไปของการสื่อสารดิจิทัลสำหรับคนทั่วไป อย่างไรก็ตาม งานเบื้องหลังนี้มีความซับซ้อนและน่าเบื่อ
นักพัฒนาแอปพลิเคชันต้องทำงานมากมายเพื่อให้แน่ใจว่าการสื่อสารระหว่างลูกค้าและเซิร์ฟเวอร์นี้ทำงานอย่างถูกต้อง การเลือกโปรโตคอลการสื่อสารที่ถูกต้องเป็นหนึ่งในงานเหล่านี้ เมื่อผู้พัฒนาพยายามที่จะเลือกโปรโตคอลการสื่อสารที่มีความเป็นไปได้ HTTP และ WebSocket เป็นสองแนวคิดทั่วไปที่พวกเขาจะพบ
การชี้แจงสองสิ่งนี้ ความคล้ายคลึงกัน ฟังก์ชัน และด้านอื่น ๆ เป็นสิ่งสำคัญสำหรับการเลือกตัวเลือกที่ถูกต้องตามความต้องการจริง
การแนะนำ HTTP#
มาทำความเข้าใจกับ HTTP กันก่อน นี่น่าจะเป็นโปรโตคอลที่ใช้มากที่สุดในด้านการสื่อสารดิจิทัล เวอร์ชันเริ่มต้นของ HTTP ได้รับการเผยแพร่ในปี 1989 ด้วยฟังก์ชันที่จำกัดและขอบเขตการใช้งาน แต่ก็ได้รับการปรับปรุงและอัปเกรดอย่างรวดเร็วเพื่อสนับสนุนการสื่อสารขนาดใหญ่ระหว่างเบราว์เซอร์และเซิร์ฟเวอร์
HTTP เป็นโปรโตคอลทางเดียว ซึ่งหมายความว่าในเวลาใด ๆ เพียงฝ่ายเดียวในสื่อถามสามารถส่งหรือรับข้อมูลได้ เมื่อคลายเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์ คำขอนี้จะถูกส่งในรูปแบบของ HTTP หรือ HTTPS และเซิร์ฟเวอร์จะส่งการตอบที่เป็นเอกลักษณ์ที่สอดคล้องไปยังคลายเอนต์หลังจากได้รับคำขอ แต่ละคำขอ HTTP หรือ HTTPS จะสร้างการเชื่อมต่อใหม่กับเซิร์ฟเวอร์และยุติการเชื่อมต่อโดยอัตโนมัติหลังจากได้รับการตอบ
ฟีเจอร์หลักบางอย่างของ HTTP รวมถึง:
- ไม่มีสถานะ
- สามารถทำงานโดยใช้โปรโตคอลที่มีการเชื่อมต่อ (เช่น SCTP และ TCP)
- ข้อมูลถูกเข้ารหัสใน ASCII
- ส่วนประกอบหลักของคำขอ HTTP รวมถึงเวอร์ชันของ HTTP (HTTP/1.1, HTTP/2, HTTP/3) วิธี หัว HTTP ข้อมูลโฮสต์ และข้อความ
WebSocket คืออะไร?#
WebSocket เป็นโปรโตคอลการสื่อสารที่สามารถบรรลุการสื่อสารแบบสองทางเรียลไทม์ระหว่างคลายเอนต์และเซิร์ฟเวอร์
WebSocket เป็นโปรโตคอลสำหรับสร้างช่องสื่อสารแบบสองทางเรียลไทม์ในแอปพลิเคชันเว็บ แตกต่างจากคำขอ HTTP ปกติ (โดยปกติคำขอหนึ่งจะตอบครบหนึ่งครั้ง) WebSocket สามารถสร้างการเชื่อมต่อที่ต่อเนื่อง ทำให้เซิร์ฟเวอร์สามารถส่งข้อมูลไปยังคลายเอนต์ในเวลาจริงได้ รวมทั้งรับข้อมูลจากคลายเอนต์ เมื่อเปรียบเทียบกับการโพลลิงแบบดั้งเดิม WebSocket จะลดการจราจรของเครือข่ายและความหน่วงเวลาอย่างมีนัยสำคัญ เพิ่มประสิทธิภาพและความเร็วในการส่งข้อมูลให้ดียิ่งขึ้น โดยเฉพาะเหมาะสำหรับพัฒนาแอปพลิเคชันเว็บเรียลไทม์และเกมออนไลน์
ฟีเจอร์หลักบางอย่างของ WebSocket รวมถึง:
- อิงจากการเชื่อมต่อ TCP ที่ต่อเนื่อง ซึ่งยังคงเปิดอยู่จนกว่าคลายเอนต์หรือเซิร์ฟเวอร์จะเริ่มคำร้องเพื่อยุติ
- อิงจากโปรโตคอล HTTP คำขอ WebSocket ทั้งหมดจะถูกส่งผ่านโปรโตคอล HTTP มาตรฐานและระบุเป็นข้อมูลหัวที่เฉพาะเจาะจงในการอัปเกรดฝั่งเซิร์ฟเวอร์
- โปรโตคอล WebSocket อิงตามเฟรม (แพ็กเก็ตข้อมูล) แพ็กเก็ตข้อมูลที่สมบูรณ์สามารถแบ่งเป็นเฟรมหลาย ๆ เฟรม ที่แต่ละเฟรมประกอบด้วยส่วนหนึ่งของข้อมูลและข้อมูลหัว
ความสัมพันธ์ระหว่าง HTTP และ WebSocket#
จากบทนำข้างต้นเราจะเห็นว่าโปรโตคอล HTTP และ WebSocket:
- ใช้โปรโตคอล TCP ในการส่งข้อมูล
- ใช้สำหรับการสื่อสารระหว่างลูกค้าและเซิร์ฟเวอร์
เราสามารถแสดงความแตกต่างระหว่าง HTTP และ WebSocket ได้ชัดเจนขึ้นผ่านตารางต่อไปนี้
| HTTP | WebSocket |
|---|
| ตั้งค่าการเชื่อมต่อใหม่สำหรับแต่ละคำขอ (เว้นแต่ว่าใช้การเชื่อมต่อ HTTP ระยะยาว เช่น HTTP/1.1 Keep-Alive) และปิดการเชื่อมต่อหลังจากสิ้นสุดการสื่อสาร | การเชื่อมต่อคงอยู่หลังจากการมือจับครั้งแรกสำเร็จ เว้นแต่ว่าจะปิดโดยตรงหรือเกิดข้อผิดพลาด |
| โหมดการสื่อสารทางเดียว คลายเอนต์ส่งคำขอ เซิร์ฟเวอร์คืนการตอบสนอง แต่ละการสื่อสารใหม่ต้องตั้งค่าการเชื่อมต่อใหม่ | โหมดการสื่อสารสองทาง หลังจากตั้งค่าการเชื่อมต่อแล้ว คลายเอนต์และเซิร์ฟเวอร์สามารถส่งข้อมูลได้ทุกเวลาโดยไม่ต้องตั้งค่าการเชื่อมต่อใหม่ |
| แต่ละการสื่อสารต้องส่งหัวคำขอและตอบสนองที่สมบูรณ์เป็นจำนวนมาก ทำให้มีปริมาณตลอดในกรณีของการสื่อสารข้อความสั้น ๆ บ่อย ๆ | เมื่อการเชื่อมต่อตั้งค่าเสร็จแล้ว การส่งข้อมูลจะเบากว่า ไม่ต้องส่งข้อมูลหัวทุกครั้ง เหมาะสำหรับความต้องการการสื่อสารที่มีความถี่สูงและความหน่วงต่ำ |
| ส่วนใหญ่ใช้สำหรับการส่งข้อมูลที่ค่อนข้างคงที่ | ส่วนใหญ่ใช้สำหรับการส่งข้อมูลเวลาจริง |
| เนื่องจากต้องตั้งค่าการเชื่อมต่อใหม่สำหรับแต่ละคำขอและพกพาข้อมูลจำเป็นผ่านหัว ฯลฯ ประสิทธิภาพการใช้แบนด์วิธและความเร็วในการตอบสนองได้รับผลกระทบ | การเชื่อมต่อคงอยู่ไม่ต้องผ่านกระบวนการตั้งค่าการเชื่อมต่อและข้อมูลจำเป็นสำหรับแต่ละคำขอ ส่งผลให้ความหน่วงต่ำกว่าและประสิทธิภาพการใช้แบนด์วิธสูงกว่า |
| คำขอบ่อยครั้งส่งผลต่อการทำงาน | คำขอบ่อยครั้งไม่ส่งผลต่อการทำงาน |
วิธีเลือกใช้โปรโตคอลใด?#
โดยพิจารณาข้อดีและข้อเสียของ HTTP และ WebSocket จากส่วนก่อนหน้า เราสามารถประเมินสถานการณ์การใช้งานจากสองมิติ:
- ข้อมูลเปลี่ยนแปลงอย่างรวดเร็วหรือไม่ และการทำงานขึ้นอยู่กับข้อมูลแบบเรียลไทม์หรือไม่
- เกี่ยวข้องกับการสื่อสารสองทางที่บ่อยหรือไม่
ตัวอย่างเช่น หากแจ็คต้องการสร้างแอปพลิเคชันแชทวิดีโอที่แต่ละผู้ใช้ต้องรับข้อมูลวิดีโอแบบเรียลไทม์จากคู่สนทนาและส่งข้อมูลวิดีโอสตรีมของตัวเองไปยังฝ่ายตรงข้าม WebSocket จะเป็นตัวเลือกที่ดีที่สุด
คอนโซลผู้ดูแลระบบของ Logto ไม่จำเป็นต้องได้รับทรัพยากรการใช้การเข้าสู่ระบบของผู้ใช้บ่อย ๆ เพราะทรัพยากรจะเปลี่ยนสถานะเมื่อผู้ใช้ปรับเปลี่ยนการตั้งค่าเท่านั้น แค่ต้องรับสถานะทรัพยากรใหม่เมื่อผู้ใช้ทำการกระทำกับทรัพยากรเท่านั้น จากมุมมองนี้ HTTP เหมาะสำหรับสถานการณ์การใช้งานของ Logto Admin Console นอกจากนี้ สำหรับแผงควบคุมบริการคลาวด์ส่วนใหญ่ HTTP สามารถถูกเลือกเป็นโปรโตคอลการสื่อสารระหว่างแผงควบคุมและเซิร์ฟเวอร์ได้
