ส่งซ้ำ WebSocket
เครื่องมือส่งซ้ำ WebSocket สร้างเซสชันที่นำกลับมาใช้เพื่อทดสอบปลายทาง WebSocket ได้ ใช้เชื่อมต่อใหม่ด้วยรายละเอียดแฮนด์เชกที่บันทึกไว้ แก้ไขข้อความ ส่งเฟรมใหม่ และดูการตอบกลับจากเซิร์ฟเวอร์
สร้างเซสชัน
สร้างเซสชันส่งซ้ำ WebSocket ได้สองวิธี:
- คลิกขวาที่ข้อความ WebSocket ที่บันทึกไว้ใน ประวัติ WS / SSE แล้วเลือก ส่งไปยังเครื่องมือส่งซ้ำ WS
- เปิด ส่งซ้ำ WS แล้วสร้างเซสชันด้วยตนเองโดยใช้ URL
ws://หรือwss://
เซสชันที่สร้างด้วยตนเองมีส่วนหัวกำหนดเองสำหรับคุกกี้ โทเค็นการอนุญาต การเจรจาโปรโตคอล หรือค่าแฮนด์เชกเฉพาะแอปพลิเคชันได้
ตั้งค่าเซสชัน
| ฟิลด์ | คำอธิบาย |
|---|---|
| ชื่อ | ป้ายชื่อเซสชันที่อ่านเข้าใจได้ |
| URL | ปลายทาง WebSocket URL ต้องขึ้นต้นด้วย ws:// หรือ wss:// |
| ส่วนหัว | ส่วนหัวแฮนด์เชกที่ส่งเมื่อเชื่อมต่อ ไม่จำเป็นต้องระบุ |
หากเปลี่ยน URL หรือส่วนหัว Ogma จะบันทึกเซสชันก่อนเปิดการเชื่อมต่อครั้งถัดไป
เชื่อมต่อ
เลือกเซสชันแล้วคลิก เชื่อมต่อ สถานะการเชื่อมต่อระบุว่าซ็อกเก็ตขาดการเชื่อมต่อ กำลังเชื่อมต่อ เปิดอยู่ กำลังปิด หรือปิดแล้ว
ใช้ ตัดการเชื่อมต่อ ก่อนเปลี่ยนเป้าหมายหรือรายละเอียดแฮนด์เชก เชื่อมต่อใหม่หลังแก้ไข URL หรือส่วนหัวเพื่อทดสอบพาธเซิร์ฟเวอร์หรือบริบทที่ยืนยันตัวตนใหม่
การเชื่อมต่อทำให้แฮนด์เชก WebSocket เสร็จสมบูรณ์เท่านั้น แอปพลิเคชันจำนวนมากต้องการเฟรมยืนยันตัวตนหรือเริ่มต้นก่อนรับข้อความการทำงาน ใช้ข้อความไคลเอนต์แรกที่บันทึกไว้เป็นค่าพื้นฐาน รอการตอบรับ แล้วจึงส่งข้อความที่แก้ไข คุกกี้ URL ที่ลงลายเซ็น และโทเค็นที่บันทึกไว้อาจหมดอายุแล้ว
ส่งข้อความ
ใช้ตัวเขียนข้อความเพื่อแก้ไขเพย์โหลดและส่งผ่านเซสชันที่เลือก เพย์โหลดข้อความจะถูกส่งเป็นเฟรมข้อความ WebSocket
เปลี่ยนเป็นโหมดไบนารีสำหรับไบต์ฐานสิบหก ส่งซ้ำข้อความ WebSocket แรกที่บันทึกไว้ ช่วยส่งข้อมูลเริ่มต้นอีกครั้ง และ ส่งข้อความขาออกที่บันทึกไว้ซ้ำตามลำดับ ส่งข้อความไคลเอนต์ที่บันทึกไว้ตามลำดับ ตรวจสอบคำตอบในไทม์ไลน์แทนการถือว่าการส่งลำดับนั้นสร้างสถานะแอปพลิเคชันเดิมขึ้นแล้ว
ตัวแก้ไขโปรโตคอลรองรับ WebSocket แบบ Raw และโหมด GraphQL ที่จัดการให้ ได้แก่ graphql-transport-ws และ graphql-ws แบบเดิม เลือกโปรโตคอลที่เป้าหมายใช้และระบุพารามิเตอร์การเชื่อมต่อ คงส่วนหัวซับโปรโตคอลเดิมเมื่อจำเป็น การขอโปรโตคอลผิดอาจทำให้การอัปเกรดล้มเหลว
อัปเดตเวลาประทับ ปิดอยู่โดยค่าเริ่มต้น เปิดเฉพาะคำขอที่ไม่ลงลายเซ็นและต้องการเวลาประทับใหม่ การเปลี่ยน URL หรือเพย์โหลดที่ลงลายเซ็นอาจทำให้ลายเซ็นใช้ไม่ได้ เชื่อมต่อใหม่อัตโนมัติ จะลองใหม่หลังตัดการเชื่อมต่อ แต่การเชื่อมต่อใหม่อาจยังต้องยืนยันตัวตนระดับแอปพลิเคชัน
ข้อความที่บันทึกไว้และส่งจากประวัติจะใช้เพย์โหลดเดิมเป็นจุดเริ่มต้น เพื่อให้เปลี่ยนทีละฟิลด์และเปรียบเทียบพฤติกรรมได้
ไทม์ไลน์ข้อความ
ไทม์ไลน์บันทึกเฟรมที่ส่งและรับสำหรับเซสชันที่เลือก
| คอลัมน์ | คำอธิบาย |
|---|---|
| ทิศทาง | เฟรมถูกส่งจากไคลเอนต์หรือรับจากเซิร์ฟเวอร์ |
| รหัสคำสั่ง | ประเภทเฟรม เช่น ข้อความ ไบนารี ping, pong หรือปิด |
| ขนาด | ขนาดเพย์โหลด |
| เวลา | เวลาที่ Ogma พบเฟรม |
เลือกข้อความเพื่อตรวจสอบเพย์โหลด เพย์โหลด JSON จัดรูปแบบเมื่อทำได้ และยังดูเนื้อหา Raw เพื่อตรวจสอบอย่างแม่นยำได้
เวิร์กโฟลว์ทดสอบ
- บันทึกการทำงาน WebSocket ปกติใน ประวัติ WS / SSE
- ส่งข้อความไคลเอนต์ที่น่าสนใจไปยัง ส่งซ้ำ WS
- เชื่อมต่อใหม่และส่งข้อความเดิมอีกครั้งเพื่อยืนยันพฤติกรรมพื้นฐาน
- เปลี่ยนทีละฟิลด์ โทเค็น ID หรือคำสั่ง
- บันทึกพฤติกรรมที่ยืนยันแล้วใน ประเด็นที่ตรวจพบ หรือจดไว้ใน บันทึกย่อ
การแก้ไขปัญหา
| อาการ | สิ่งที่ตรวจสอบ |
|---|---|
| การอัปเกรดถูกปฏิเสธหรือห้าม | URL, Origin, คุกกี้ การอนุญาต และค่าคิวรีที่ลงลายเซ็นซึ่งหมดอายุ |
| ซับโปรโตคอลไม่ถูกต้องหรือไม่ได้ร้องขอ | เปรียบเทียบส่วนหัวอัปเกรดกับแฮนด์เชกที่บันทึกไว้และโหมดโปรโตคอลที่เลือก |
| เชื่อมต่อสำเร็จแล้วปิด | ตรวจสอบข้อความระบบหรือปิดการเชื่อมต่อ แล้วส่งเฟรมเริ่มต้นหรือยืนยันตัวตนที่จำเป็น |
| ส่งข้อความแล้วแต่ไม่มีคำตอบที่ใช้ได้ | ยืนยัน ID การสมัครรับ ข้อความก่อนหน้า การยืนยันตัวตน และสถานะแอปพลิเคชัน การส่งผ่าน WebSocket ไม่ได้สร้างเซสชันเบราว์เซอร์ใหม่โดยอัตโนมัติ |
เมื่อใช้ MCP ให้ใช้เครื่องมือเฉพาะสำหรับดูรายการหรืออ่านข้อความในส่งซ้ำ WS และตัดการเชื่อมต่อ เครื่องมือประวัติที่บันทึกไว้อ่านบันทึกการแลกเปลี่ยนคนละชุด ดูคู่มือเครื่องมือ MCP