จะแก้ไขหน่วยความจำ ws และ socket.io รั่วได้อย่างไร

ฉันได้อ่านว่ามีหน่วยความจำรั่วเกิดขึ้นในทั้งโมดูล node.js websocket ws และ socket.io เป็นมาหลายปีแล้ว กำลังสงสัยว่าจะแก้ไขอย่างไร

มีการกล่าวถึงต่อไปนี้เพื่อชื่อไม่กี่:

• https://github.com/socketio/socket.io/issues/2427 (ปิดแต่ไม่มีทางออก)
• https://github.com/socketio/socket.io/issues/3477 (การตั้งค่า perMessageDeflate: เห็นได้ชัดว่าเป็นเท็จช่วย แต่สาเหตุที่แท้จริงคือปัญหาเกี่ยวกับการแยกส่วน ซึ่งเห็นได้ชัดว่าไม่ได้เกิดจากไลบรารีหรือโหนดของ websocket แต่วิธีการเรียกใช้และสามารถแก้ไขได้โดยการโหลด jemalloc ล่วงหน้า)
• https://github.com/nodejs/node/issues/8871#issuecomment-250915913 (โซลูชันเดียวกันที่นำเสนอที่นี่)
• https://github.com/websockets/ws/issues/804 (ดูเหมือนว่าปัญหาจะได้รับการแก้ไขโดยการตั้งค่า perMessageDeflate เป็นเท็จ - โดยไม่ต้องใช้ jemalloc)

เนื่องจากตอนนี้เป็นปี 2021 การตั้งค่าคีย์ perMessageDeflate เป็น False และบางทีการโหลด jemalloc ไว้ล่วงหน้ายังคงเป็นทางออกที่ดีที่สุดหรือไม่

ความเข้าใจเบื้องต้นของฉันเกี่ยวกับปัญหานี้มีดังนี้ (อย่าอ้างถึงฉัน):

• โมดูล ws node.js (เช่น โมดูล websockets) และโมดูล socket.io node.js ต่างก็ใช้โมดูลอื่นที่เรียกว่า zlibโมดูลนี้รับผิดชอบในการบีบอัดข้อความใด ๆ เมื่อส่งผ่าน websocket
• โมดูล zlib เคยมีปัญหาในอดีตเกี่ยวกับการกระจายตัวของหน่วยความจำ ซึ่งเลียนแบบการรั่วไหลของหน่วยความจำ (กล่าวคือ ไม่ใช่การรั่วไหลของหน่วยความจำ แต่เป็นการกระจายตัวของหน่วยความจำ)
• การบีบอัดข้อความถูกปิดใช้งานตามค่าเริ่มต้นบนเซิร์ฟเวอร์ แต่เปิดใช้งานโดยค่าเริ่มต้นบนไคลเอนต์ (เช่น เบราว์เซอร์) หากเราปิดใช้งานโมดูล zlib จะไม่ถูกใช้ ซึ่งจะขจัดปัญหาการกระจายตัวของหน่วยความจำ
• ในการปิดใช้งานการบีบอัดบนไคลเอนต์ (เช่น เบราว์เซอร์) เราให้ ต่อข้อความยุบ ป้อนรหัสเซิร์ฟเวอร์ของคุณเป็นค่า เท็จ. นั่นคือ:

const wss = WebSocket.Server ใหม่ ({ เซิร์ฟเวอร์:httpsServer, perMessageDeflate: เท็จ });

แน่นอนว่านี่ไม่ใช่วิธีแก้ปัญหาสำหรับผู้ที่ต้องการบีบอัดข้อความ แต่มันก็คุ้มค่าที่จะกล่าวถึงว่า:

• ปัญหาการกระจายตัวของหน่วยความจำด้วย zlib ได้รับการแก้ไขแล้วบางส่วนด้วย https://github.com/websockets/ws/pull/1204 แต่ดูเหมือนจะยังเป็นปัญหาอยู่ และ
• ประโยชน์ของการบีบอัดข้อความขนาดเล็ก เช่น ข้อความขนาดเล็ก ได้รับการถกเถียงกัน บางคนระบุว่าการบีบอัดข้อความขนาดเล็กจะทำให้การทำงานช้าลง หากคุณกำลังทำงานกับข้อมูลขนาดใหญ่ เช่น รูปภาพหรือวิดีโอ คุณอาจพบว่าประสบความสำเร็จโดยการบีบอัดข้อมูลด้วยตนเอง (เช่น ไม่มี ws/socket.io/zlib) ก่อนที่จะส่งผ่านเว็บซ็อกเก็ต

นอกจากนี้ บางคนตั้งข้อสังเกตว่าการตั้งค่า perMessageDeflate: false ช่วยลดปัญหาเท่านั้น แต่ไม่สามารถแก้ปัญหาได้ทั้งหมด ฉันจะมุ่งความสนใจไปที่การสนทนานี้ ซึ่งมีการกล่าวว่าการใช้หน่วยความจำที่เหลือและคงที่ (เช่น ไม่เพิ่มขึ้น) จากการเปิดและปิดเว็บซ็อกเก็ตเป็นเรื่องปกติ (ฉันไม่จำเป็นต้องบอกว่าสิ่งนี้ถูกต้อง): https://github.com/websockets/ws/issues/804#issuecomment-302612661

สำหรับการโหลดล่วงหน้า Jemalloc ดูเหมือนจะไม่สามารถแก้ไขปัญหาได้ แม้ว่าโค้ดด้านบนจะใช้งานไม่ได้ แต่ก็คุ้มค่าที่จะพิจารณา (หรือลอง)

เป็นเช่นนั้น preMessageDeflate: เท็จ ทางออกที่ดีที่สุดในตอนนี้? ตามความเข้าใจผมคงตอบว่าใช่

ถ้าใครมีการแก้ไขหรือข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้โปรดเพิ่ม