WebSocket มอบช่องทางสองทางที่คงอยู่ถาวรระหว่างไคลเอนต์และเซิร์ฟเวอร์ผ่านการเชื่อมต่อ TCP เพียงครั้งเดียว เมื่อเปิดการเชื่อมต่อแล้ว ทั้งสองฝ่ายสามารถส่งข้อความได้ตลอดเวลา ซึ่งเป็นหัวใจหลักของแชทสด, ฟีดการซื้อขาย, เกมที่มีผู้เล่นหลายคน, และแดชบอร์ด การทดสอบ WebSocket นั้นแตกต่างจากการทดสอบ API แบบ request-response เนื่องจากไม่มีการตอบกลับเดียวให้ตรวจสอบ มีแต่กระแสข้อมูล
คู่มือนี้เน้นการใช้งานจริง ครอบคลุมถึงสิ่งที่ curl ทำได้และทำไม่ได้กับ WebSocket, วิธีใช้เครื่องมือเฉพาะอย่าง websocat, และเมื่อใดที่ไคลเอนต์แบบ GUI เป็นทางเลือกที่ดีกว่า ทุกคำสั่งที่นี่ใช้งานได้จริงและพร้อมคัดลอก
ทำไมการทดสอบ WebSocket จึงไม่เหมือนการทดสอบ REST
การทดสอบ REST คือธุรกรรม คุณส่งคำขอหนึ่งครั้ง, ได้รับการตอบกลับหนึ่งครั้ง, ยืนยันผล และเสร็จสิ้น การทดสอบ WebSocket คือการสนทนา คุณเปิดการเชื่อมต่อหนึ่งครั้ง จากนั้นแลกเปลี่ยนข้อความมากมายตลอดช่วงชีวิตของการเชื่อมต่อ และข้อความสามารถมาถึงได้โดยไม่ต้องร้องขอ
นั่นเปลี่ยนสิ่งที่คุณตรวจสอบ คุณยืนยันว่าการเชื่อมต่ออัปเกรดจากการเชื่อมต่อ HTTP ได้อย่างถูกต้อง คุณยืนยันว่าเซิร์ฟเวอร์ยอมรับข้อความแรกของคุณและตอบกลับตามที่คาดไว้ คุณยืนยันว่าข้อความที่เซิร์ฟเวอร์ผลักดันมาถึงโดยที่คุณไม่ต้องร้องขอ คุณเฝ้าดูว่าการเชื่อมต่อปิดอย่างไร และด้วยรหัสการปิดใด เครื่องมือที่สร้างขึ้นสำหรับคำขอแบบครั้งเดียวประสบปัญหาในการจัดการทั้งหมดนี้ ซึ่งเป็นเหตุผลว่าทำไม curl ซึ่งเป็นเครื่องมือ HTTP สากลจึงเหมาะสมเพียงบางส่วนเท่านั้น สำหรับภาพรวมการทดสอบที่กว้างขึ้น ความแตกต่างระหว่างสถานการณ์ทดสอบและกรณีทดสอบจึงสอดคล้องอย่างลงตัวกับการสนทนา WebSocket เทียบกับการตรวจสอบข้อความเดียว
การจับมือ (Handshake) ของ WebSocket
การเชื่อมต่อ WebSocket ทุกครั้งเริ่มต้นด้วยคำขอ HTTP ที่ร้องขอให้อัปเกรด ไคลเอนต์ส่งส่วนหัว Upgrade: websocket และ Connection: Upgrade พร้อมด้วย Sec-WebSocket-Key และเซิร์ฟเวอร์ตอบกลับด้วย HTTP 101 Switching Protocols หลังจากนั้น การเชื่อมต่อจะไม่ได้เป็น HTTP อีกต่อไป แต่จะใช้โปรโตคอลเฟรม WebSocket ที่กำหนดไว้ใน RFC 6455
นี่คือรากฐานของข้อจำกัดของ curl curl แบบคลาสสิกใช้ HTTP มันสามารถส่งส่วนหัวการอัปเกรดได้ แต่ไม่สามารถจัดเฟรมและยกเลิกการจัดเฟรมข้อความ WebSocket หลังจากการจับมือ การพยายามจำลองเซสชัน WebSocket ที่สมบูรณ์ด้วยแฟล็กส่วนหัวดิบไม่สามารถทำงานได้เกินกว่าการจับมือกัน คุณต้องมีเครื่องมือที่เข้าใจเฟรม
การทดสอบ WebSocket ด้วย curl
curl เวอร์ชัน 7.86 และใหม่กว่า ได้เพิ่มการสนับสนุน WebSocket ในตัวแบบทดลองเข้ามา มันใช้งานได้จริงสำหรับการตรวจสอบง่ายๆ โดยมีข้อแม้ว่ายังอยู่ในสถานะทดลอง
ขั้นแรก ยืนยันเวอร์ชันของคุณ:
curl --version
หากคุณใช้เวอร์ชัน 7.86 หรือใหม่กว่า คุณสามารถเชื่อมต่อกับปลายทาง WebSocket ได้โดยตรง นี่คือการเชื่อมต่อกับเซิร์ฟเวอร์ echo สาธารณะ ซึ่งจะตอบกลับด้วยสิ่งที่คุณส่งไป:
curl --include --no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Version: 13" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://echo.websocket.org
แฟล็ก --include จะแสดงส่วนหัวการตอบกลับเพื่อให้คุณยืนยันสถานะ 101 ได้ และ --no-buffer จะหยุด curl ไม่ให้เก็บผลลัพธ์ไว้ ซึ่งสำคัญสำหรับกระแสข้อมูล สำหรับการเชื่อมต่อที่ปลอดภัย ให้ใช้ URL แบบ wss:// เช่นเดียวกับการใช้ https://
การสนับสนุน WebSocket ของ curl โดดเด่นในเรื่องเดียวคือ: การยืนยันว่าปลายทางสามารถเข้าถึงได้และดำเนินการอัปเกรดเสร็จสมบูรณ์ มันไม่สะดวกสำหรับเซสชันแบบโต้ตอบที่คุณส่งข้อความหลายครั้งและอ่านการตอบกลับ เนื่องจาก curl ไม่ได้สร้างขึ้นมารองรับการวนลูปข้อความ สำหรับการตรวจสอบอย่างรวดเร็วว่า "ปลายทางนี้ทำงานอยู่หรือไม่" ในสคริปต์ก็ถือว่าใช้ได้ สำหรับการทดสอบแบบโต้ตอบจริง ให้เลือกใช้เครื่องมือเฉพาะทาง หากคุณกำลังเขียนสคริปต์การตรวจสอบเหล่านี้ลงในไปป์ไลน์ คู่มือของเราเกี่ยวกับการทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน CI/CD ครอบคลุมการรวมการตรวจสอบด้วยบรรทัดคำสั่งเข้ากับการบิลด์
การทดสอบ WebSocket ด้วย websocat
websocat เป็นเครื่องมือบรรทัดคำสั่งที่คนส่วนใหญ่ต้องการจริงๆ สำหรับงาน WebSocket มันสร้างขึ้นมาโดยเฉพาะ เข้าใจเฟรมอย่างถูกต้อง และทำงานเหมือน netcat สำหรับ WebSocket
ติดตั้งด้วยตัวจัดการแพ็กเกจของคุณ เช่น brew install websocat บน macOS หรือผ่าน cargo install websocat จากนั้นการเชื่อมต่อและการสนทนาทำได้ด้วยคำสั่งเดียว:
websocat wss://echo.websocket.org
นั่นจะเปิดเซสชันแบบโต้ตอบ พิมพ์ข้อความหนึ่งบรรทัด กด Enter แล้วมันจะถูกส่งเป็นข้อความ การตอบกลับของเซิร์ฟเวอร์จะแสดงขึ้นเมื่อมาถึง หากต้องการส่งข้อความเดียวแล้วออก ให้ส่งผ่าน pipe เข้าไป:
echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed
websocat ยังจัดการฟังก์ชันเสริมที่เป็นประโยชน์ คุณสามารถส่งส่วนหัวสำหรับปลายทางที่ต้องการการรับรองความถูกต้องได้:
websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/socket
และคุณสามารถรันมันเป็นเซิร์ฟเวอร์ท้องถิ่นเพื่อทดสอบไคลเอนต์ หรือเชื่อมต่อ WebSocket กับพอร์ต TCP ธรรมดา สำหรับการทดสอบ WebSocket ด้วยบรรทัดคำสั่ง websocat ครอบคลุมเกือบทุกอย่างที่ curl ทำไม่ได้ จัดการการยืนยันผลในลักษณะเดียวกับที่คุณทำที่อื่น; บันทึกของเราเกี่ยวกับการการเขียนการยืนยันผล API ที่มีประโยชน์ใช้กับการตรวจสอบเพย์โหลดข้อความด้วย
การทดสอบ WebSocket ด้วยเครื่องมือ GUI
เครื่องมือบรรทัดคำสั่งยอดเยี่ยมสำหรับสคริปต์และการตรวจสอบอย่างรวดเร็ว แต่น่าเบื่อสำหรับการทดสอบแบบสำรวจ ซึ่งคุณต้องการดูไทม์ไลน์ของข้อความ, ส่ง JSON ที่มีโครงสร้างได้อย่างสะดวกสบาย และเปิดการเชื่อมต่อไว้ในขณะที่คุณทดลอง
Apidog มีไคลเอนต์ WebSocket โดยเฉพาะที่สร้างขึ้นมาเพื่อการนี้ คุณป้อน URL แบบ ws:// หรือ wss:// เชื่อมต่อ และดูทุกข้อความที่ส่งและรับในมุมมองไทม์ไลน์พร้อมการเน้นไวยากรณ์ JSON คุณสามารถบันทึกการเชื่อมต่อ, ตั้งค่าส่วนหัวและพารามิเตอร์การสอบถามสำหรับการรับรองความถูกต้อง และรักษาการเชื่อมต่อให้ทำงานอยู่ตลอดในขณะที่คุณทดลอง มันจัดการ REST, GraphQL และ SOAP ในแอปพลิเคชันเดียวกัน ดังนั้นการทดสอบ WebSocket จึงอยู่ควบคู่ไปกับงาน API อื่นๆ ของคุณแทนที่จะอยู่ในเครื่องมือแยกต่างหาก ดาวน์โหลด Apidog เพื่อทดสอบปลายทาง WebSocket ด้วยไทม์ไลน์ภาพ
GUI เป็นทางเลือกที่เหมาะสมเมื่อคุณกำลังสำรวจ WebSocket API ที่ไม่คุ้นเคย, ดีบักว่าทำไมข้อความไม่มาถึง, หรือแชร์การทดสอบที่สามารถทำซ้ำได้กับเพื่อนร่วมทีม บรรทัดคำสั่งเป็นทางเลือกที่เหมาะสมเมื่อคุณต้องการให้การตรวจสอบทำงานโดยอัตโนมัติ วิศวกรส่วนใหญ่ใช้ทั้งสองอย่าง โดยเลือกตามงาน หากคุณต้องการภาพรวมที่กว้างขึ้นของตัวเลือก GUI การรวบรวมเครื่องมือทดสอบ API ออนไลน์ฟรีของเรามีหลายตัวที่รองรับ WebSocket
รายการตรวจสอบการทดสอบ WebSocket อย่างง่าย
- ยืนยันการอัปเกรด การเชื่อมต่อควรตอบกลับ HTTP 101 หากไม่เป็นเช่นนั้น แสดงว่าปลายทาง, พาธ หรือส่วนหัวของคุณผิด
- ตรวจสอบการรับรองความถูกต้อง เซิร์ฟเวอร์ WebSocket จำนวนมากคาดหวังโทเค็นในส่วนหัวหรือพารามิเตอร์การสอบถาม การเชื่อมต่อที่เปิดแล้วปิดทันทีมักหมายถึงโทเค็นถูกปฏิเสธ
- ส่งข้อความที่รู้จักและตรวจสอบการตอบกลับ ใช้เพย์โหลดจริงที่ API ของคุณเข้าใจและยืนยันรูปแบบการตอบกลับ
- ตรวจสอบข้อความที่เซิร์ฟเวอร์ผลักดัน สมัครสมาชิกช่องและยืนยันว่าการอัปเดตมาถึงโดยไม่ต้องมีการร้องขอเพิ่มเติมจากคุณ
- ทดสอบการปิด ปิดการเชื่อมต่อและตรวจสอบรหัสการปิด การปิดที่สะอาดคือ 1000; รหัสอื่น ๆ บ่งชี้ปัญหาเฉพาะ
- ทดสอบเส้นทางความล้มเหลว ส่งข้อความที่ผิดรูปแบบและยืนยันว่าเซิร์ฟเวอร์ตอบสนองอย่างสมเหตุสมผลแทนที่จะละทิ้งไปอย่างเงียบๆ
สำหรับการจัดระเบียบสิ่งเหล่านี้ให้เป็นชุดที่สามารถทำซ้ำได้ คู่มือของเราเกี่ยวกับการการสร้างชุดทดสอบ API ใช้ได้กับโฟลว์ WebSocket เช่นเดียวกับ REST
การดีบักการเชื่อมต่อ WebSocket ที่ไม่ทำงาน
เมื่อการเชื่อมต่อ WebSocket ล้มเหลว สาเหตุเกือบทั้งหมดเป็นหนึ่งในชุดปัญหาเล็กๆ น้อยๆ ไล่เรียงตรวจสอบตามลำดับ
เริ่มต้นด้วยรูปแบบ URL การเชื่อมต่อ wss:// จากหน้าเว็บหรือบริบทที่คาดหวัง ws:// หรือในทางกลับกัน จะล้มเหลวทันที เบราว์เซอร์ยังบล็อกการเชื่อมต่อ ws:// จากหน้าเว็บที่ให้บริการผ่าน HTTPS เนื่องจากเป็นการผสมเนื้อหาที่ปลอดภัยและไม่ปลอดภัย ยืนยันว่ารูปแบบตรงกับสภาพแวดล้อม
ถัดไป ตรวจสอบการตอบกลับการจับมือ หากคุณไม่เห็น HTTP 101 แสดงว่าเซิร์ฟเวอร์ไม่เคยตกลงที่จะอัปเกรด รหัส 404 หมายความว่าพาธผิด รหัส 401 หรือ 403 หมายความว่าการรับรองความถูกต้องล้มเหลวก่อนการอัปเกรด รหัส 400 มักหมายถึงส่วนหัวการอัปเกรดขาดหายไปหรือไม่ถูกต้อง แฟล็ก --include ของ curl และโหมดละเอียดของ websocat ทั้งสองอย่างจะแสดงการตอบกลับนี้ให้คุณเห็น คุณจึงสามารถแยกแยะความล้มเหลวในการจับมือจากการเกิดปัญหาในภายหลังได้
หากการจับมือสำเร็จ แต่การเชื่อมต่อหลุดในไม่กี่วินาทีต่อมา ให้ดูที่การหมดเวลาเมื่อไม่มีการใช้งานและเฟรม ping หรือ pong เซิร์ฟเวอร์จำนวนมากคาดหวังให้ไคลเอนต์ตอบเฟรม ping เพื่อพิสูจน์ว่ายังคงทำงานอยู่ และจะปิดการเชื่อมต่อที่เงียบไป พร็อกซีหรือโหลดบาลานเซอร์ที่อยู่หน้าเซิร์ฟเวอร์ก็สามารถตัดการเชื่อมต่อที่ไม่มีการใช้งานได้ตามกำหนดเวลาของมันเอง สุดท้าย ให้อ่านรหัสการปิด รหัสเหล่านี้ถูกกำหนดไว้ใน RFC 6455 และรหัสเช่น 1006 บ่งชี้ถึงการปิดที่ผิดปกติโดยไม่มีการจับมือที่สะอาด ในขณะที่ 1011 บ่งชี้ข้อผิดพลาดของเซิร์ฟเวอร์ รหัสการปิดมักจะบอกคุณว่าฝ่ายใดละทิ้งและเพราะเหตุใด
การทำให้การตรวจสอบ WebSocket เป็นไปโดยอัตโนมัติ
การทดสอบด้วยตนเองเพียงครั้งเดียวยืนยันว่าปลายทางทำงานได้ในวันนี้ แต่ไม่ได้ปกป้องคุณจากการถดถอยในสัปดาห์หน้า สำหรับการป้องกันนั้น การตรวจสอบ WebSocket ต้องทำงานโดยอัตโนมัติ
เครื่องมือบรรทัดคำสั่งทำให้เรื่องนี้ง่ายขึ้น สคริปต์เล็กๆ สามารถเปิดการเชื่อมต่อด้วย websocat, ส่งข้อความที่รู้จัก, ดักจับการตอบกลับ, และเปรียบเทียบกับค่าที่คาดหวังได้ จากนั้นจะออกด้วยค่าที่ไม่ใช่ศูนย์หากไม่ตรงกัน สคริปต์นั้นจะเข้าสู่ไปป์ไลน์ CI เช่นเดียวกับขั้นตอนการทดสอบอื่นๆ เครื่องมือ GUI ที่มีตัวรันสถานการณ์ เช่น Apidog สามารถบันทึกโฟลว์ WebSocket รวมถึงข้อความที่ส่งและการยืนยันผลการตอบกลับ และเล่นซ้ำตามกำหนดเวลาหรือจากการกระตุ้นของไปป์ไลน์
ให้การทดสอบ WebSocket แบบอัตโนมัติมีความมุ่งเน้น ยืนยันการอัปเกรดการเชื่อมต่อ, ยืนยันคู่คำขอและการตอบกลับที่รู้จักหนึ่งคู่, และยืนยันว่าช่องที่สมัครสมาชิกส่งข้อความที่ถูกผลักดันอย่างน้อยหนึ่งข้อความภายในระยะเวลาที่กำหนด การพยายามยืนยันผลทุกข้อความที่เป็นไปได้ของการเชื่อมต่อที่คงอยู่นานทำให้การทดสอบช้าและไม่น่าเชื่อถือ ข้อจำกัดที่ทำให้กรณีทดสอบคมชัดทำให้การตรวจสอบ WebSocket น่าเชื่อถือ: ทดสอบสิ่งเดียวที่ชัดเจน และทดสอบให้ดี
คำถามที่พบบ่อย
curl สามารถทดสอบการเชื่อมต่อ WebSocket ได้หรือไม่?
บางส่วน curl เวอร์ชัน 7.86 และใหม่กว่า มีการสนับสนุน WebSocket ในตัวแบบทดลองที่สามารถทำการจับมือและแลกเปลี่ยนข้อความพื้นฐานได้ ซึ่งเพียงพอที่จะยืนยันว่าปลายทางสามารถเข้าถึงได้ มันไม่สะดวกสำหรับเซสชันแบบโต้ตอบที่มีข้อความจำนวนมาก สำหรับการทดสอบ WebSocket จริง websocat หรือไคลเอนต์ GUI อย่าง Apidog เหมาะสมกว่า
ความแตกต่างระหว่าง ws และ wss คืออะไร?
ws:// คือการเชื่อมต่อ WebSocket ที่ไม่เข้ารหัส และ wss:// คือการเชื่อมต่อที่เข้ารหัสด้วย TLS ซึ่งเทียบเท่า WebSocket ของ HTTP เทียบกับ HTTPS ควรใช้ wss:// เสมอสำหรับสิ่งอื่นใดนอกเหนือจากการพัฒนาในเครื่อง เนื่องจาก ws:// ส่งข้อความเป็นข้อความธรรมดา เครื่องมือปฏิบัติต่อ URL ทั้งสองแบบเหมือนกัน ยกเว้นการเข้ารหัส
ทำไมการเชื่อมต่อ WebSocket ของฉันถึงเปิดแล้วปิดทันที?
สาเหตุที่พบบ่อยที่สุดคือการรับรองความถูกต้อง หากเซิร์ฟเวอร์คาดหวังโทเค็นในส่วนหัวหรือพารามิเตอร์การสอบถามและไม่ได้รับโทเค็นที่ถูกต้อง มันจะยอมรับการเชื่อมต่อ TCP แล้วจึงปิดลง ตรวจสอบรหัสการปิด, ยืนยันโทเค็นของคุณ, และยืนยันว่าคุณส่งในแบบที่เซิร์ฟเวอร์คาดหวัง
websocat ดีกว่า curl สำหรับการทดสอบ WebSocket หรือไม่?
สำหรับ WebSocket โดยเฉพาะ ใช่ websocat สร้างขึ้นมาโดยเฉพาะ, เข้าใจโปรโตคอลเฟรมได้อย่างสมบูรณ์, รองรับเซสชันแบบโต้ตอบ, ส่วนหัวที่กำหนดเอง, และการส่งข้อความเข้าและออกผ่าน pipe curl เป็นเครื่องมือ HTTP ทั่วไปที่การสนับสนุน WebSocket ยังคงเป็นแบบทดลอง ใช้ curl สำหรับการตรวจสอบการเข้าถึงอย่างรวดเร็ว และ websocat สำหรับการทดสอบจริง
ฉันจะทดสอบได้อย่างไรว่าเซิร์ฟเวอร์ผลักดันข้อความโดยไม่มีการร้องขอ?
เปิดการเชื่อมต่อ, สมัครสมาชิกช่องหรือเหตุการณ์ที่เกี่ยวข้องหาก API กำหนด, จากนั้นรอและดู ด้วย websocat ข้อความที่ถูกผลักดันจะแสดงขึ้นเมื่อมาถึง ด้วยไคลเอนต์ GUI อย่าง Apidog พวกมันจะปรากฏในไทม์ไลน์ข้อความ ยืนยันว่าข้อความมาถึงโดยไม่มีการป้อนข้อมูลเพิ่มเติมจากคุณ เนื่องจากการส่งที่ไม่ต้องร้องขอเป็นจุดประสงค์หลักของ WebSocket