หน้าแชทโหลดได้แต่การเชื่อมต่อสดล้มเหลว: ควรตรวจตรงไหน

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

หาคำขอที่พาข้อความไป

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

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

การตั้งค่า การส่ง และอายุ ล้มเหลวต่างกัน

WebSocket เปิดด้วยการอัปเกรด HTTP ที่ตอบกลับด้วยสถานะ 101 และทุกอย่างหลังจากนั้นเป็นข้อความที่แบ่งเป็นเฟรม ไม่ใช่การดึงหน้า สองขั้นตอนที่ RFC 6455 แยกไว้อย่างชัดเจน สตรีมเหตุการณ์ตอบด้วยชนิดเนื้อหาแบบสตรีมและตรึงเนื้อหาคำตอบไว้ ทั้งสองแบบอาจเปิดไม่สำเร็จ เปิดได้แต่ไม่ส่งอะไรเลย หรือเปิดได้ ส่งได้ แล้วตายเงียบ ๆ

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

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

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

โฮสต์สดเป็นปลายทางแยก

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

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

แก้รายการปลายทาง ไม่ใช่การตรวจความปลอดภัย

การแก้รายการปลายทางเป็นการเปลี่ยนเส้นทาง และเป็นหน้าที่ของเจ้าของเส้นทาง การผ่อนการตรวจใบรับรองหรือการถอดเฮดเดอร์ Origin เป็นการเปลี่ยนความปลอดภัย และเป็นหน้าที่ของเจ้าของนโยบาย ซึ่งมักไม่ใช่คนที่กำลังดีบักตั๋ว วิธีที่เร็วที่สุดทำให้การเชื่อมต่อดูสำเร็จมักเป็นวิธีที่เร็วที่สุดทำให้เกิดเหตุการณ์ได้

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

บันทึกให้พอต่อการส่งต่อ

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

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