Rate Limiting and Validation

WebSocket ที่เปิดอยู่คือคำเชิญที่เปิดกว้าง เมื่อ handshake เสร็จแล้ว client ส่ง message ได้มากเท่าที่ต้องการ, ใหญ่เท่าที่ต้องการ, ในรูปแบบใดก็ได้ที่ต้องการ — และ server จะพยายามจัดการทุกอันอย่างซื่อสัตย์ client ที่มี bug หรือที่ประสงค์ร้าย สามารถเปลี่ยนความใจกว้างนั้นให้เป็น denial of service บทเรียนนี้เป็นเรื่องของการป้องกันราคาถูกสามอย่างที่กันไม่ให้การเชื่อมต่อเดียวทำลายงานเลี้ยง: rate limiting, size cap, และ defensive validation

client ถล่มคุณได้

WebSocket ไม่มี throttle มาให้ในตัว loop while (true) ws.send(...) ในเบราว์เซอร์ยิง frame ได้หลายพันตัวต่อวินาที แต่ละตัวปลุก event loop, allocate, parse แล้วรัน handler ของคุณ คูณด้วยจำนวน client ที่เชื่อมต่ออยู่ แค่ peer ที่ประสงค์ร้ายตัวเดียวก็ทำ CPU อิ่มตัว memory หมด หรือยัดงานเข้า loop จนหน่วง message ของ client คนอื่นทุกคน ได้ คุณจึงต้องมีเพดาน และเพดานนั้นต้องเป็น ราย connection เพื่อไม่ให้ client เจ้าปัญหาตัวเดียวกินงบของคนอื่นไปหมด

Token bucket: rate limit ที่ยอมให้มี burst

อัลกอริทึมคลาสสิกคือ token bucket แต่ละ connection เป็นเจ้าของ bucket ที่มี capacity สูงสุดของ token Token จะ refill ในอัตราคงที่เมื่อเวลาผ่านไป ทุก message มีต้นทุน หนึ่ง token: ถ้ามี token อยู่ message จะถูกประมวลผลและ token หนึ่งตัวถูกเอาออก; ถ้า bucket ว่าง message จะถูกปฏิเสธ (หรือ connection ถูกปิดถ้าใช้งานในทางที่ผิดซ้ำ ๆ)

รูปร่างของสิ่งนี้คือสิ่งที่คุณต้องการพอดีสำหรับ traffic แบบ chat: ผู้ใช้ส่ง burst สั้น ๆ ได้ (ใช้ทั้ง bucket ในคราวเดียว) แต่อัตรา sustained ของพวกเขาถูกจำกัดด้วยอัตรา refill เลือก capacity เป็น เช่น 10 และ refill 5 ต่อวินาที แล้วคุณจะได้ “10 ใน burst แล้วหลังจากนั้น 5/วินาที”

flowchart TB
  R["Refill: +rate tokens/sec<br/>(capped at capacity)"] --> B["Bucket<br/>(0 … capacity tokens)"]
  M["Incoming message"] --> Q{"tokens >= 1 ?"}
  B --> Q
  Q -- "yes: spend 1 token" --> P["Process message"]
  Q -- "no: bucket empty" --> D["Reject / throttle<br/>(close on repeat abuse)"]

Token bucket: token เติมเมื่อเวลาผ่านไป; แต่ละ message ใช้หนึ่งตัว

Validate ทุก message อย่างระแวดระวัง

Rate limiting จำกัด จำนวนเท่าไร; validation จำกัด อะไร จงมองทุก frame ที่เข้ามาว่าเป็นศัตรูจนกว่าจะพิสูจน์ได้ว่าไม่ใช่:

จำกัดขนาดก่อน ปฏิเสธ frame ที่ใหญ่กว่าลิมิตที่สมเหตุสมผล (ไม่กี่ KB สำหรับ chat, มากกว่านั้นสำหรับ payload ที่รู้จัก) ก่อน ลงมือ parse WebSocket library ส่วนใหญ่ให้ตั้ง maxPayload ได้ frame ที่ใหญ่เกินจะโดนปฏิเสธตั้งแต่ระดับ protocol — ตั้งค่านี้ไว้ แล้วตรวจซ้ำอีกทีใน handler ของคุณ
Parse ใน try/catch การ JSON.parse บน input ของผู้โจมตี ต้อง throw สักวัน ดักไว้ให้หมด อย่าปล่อยให้ frame ที่ผิดรูปทำการเชื่อมต่อหรือ process crash
Validate รูปร่าง ยืนยันว่า type เป็น string ที่รู้จัก, field ที่จำเป็นมีอยู่และมี type ถูกต้อง, string อยู่ในความยาว, number อยู่ในช่วง ปฏิเสธอะไรก็ตามที่ไม่ตรงกับรูปร่าง message ที่รู้จัก — อย่า “พยายามเต็มที่” ฝ่าขยะไป

เดโม token-bucket และ validation ที่รันได้จริง

เพราะ rate limiting เป็น logic ล้วน ๆ เดโมด้านล่างจึงรัน ในหน้าเว็บ — ไม่ต้องใช้ server โดย implement token bucket กับ validator แบบระแวดระวัง จากนั้น replay burst ของ message (บางอันถูกต้อง, บางอันผิดรูป, บางอันใหญ่เกิน) แล้วแสดงว่าอันไหนถูกยอมรับ, ถูก throttle, หรือถูกปฏิเสธ ฟังก์ชัน consume() และ validate() เดียวกันนี้หย่อนลงใน ws.on('message') handler จริงได้ทันที

JavaScript

(function () {
  // --- Token bucket: capacity 5, refill 2 tokens/sec ---
  function makeBucket(capacity, refillPerSec) {
    return { tokens: capacity, capacity: capacity, rate: refillPerSec, last: Date.now() };
  }
  function consume(b) {
    const now = Date.now();
    b.tokens = Math.min(b.capacity, b.tokens + ((now - b.last) / 1000) * b.rate);
    b.last = now;
    if (b.tokens >= 1) { b.tokens -= 1; return true; }
    return false;
  }

  // --- Defensive validation ---
  const MAX_BYTES = 64;
  function validate(raw) {
    if (raw.length > MAX_BYTES) return { ok: false, reason: 'too large' };
    let msg;
    try { msg = JSON.parse(raw); } catch { return { ok: false, reason: 'bad json' }; }
    if (typeof msg !== 'object' || msg === null) return { ok: false, reason: 'not an object' };
    if (msg.type !== 'chat') return { ok: false, reason: 'unknown type' };
    if (typeof msg.text !== 'string' || msg.text.length === 0) return { ok: false, reason: 'bad text' };
    return { ok: true, msg: msg };
  }

  // --- Simulate a burst of incoming frames over one connection ---
  const bucket = makeBucket(5, 2);
  const incoming = [
    '{"type":"chat","text":"hi"}',
    '{"type":"chat","text":"how are you"}',
    'not json at all',
    '{"type":"chat","text":"' + 'x'.repeat(100) + '"}',
    '{"type":"delete","text":"nope"}',
    '{"type":"chat","text":"msg 3"}',
    '{"type":"chat","text":"msg 4"}',
    '{"type":"chat","text":"flood 1"}',
    '{"type":"chat","text":"flood 2"}',
    '{"type":"chat","text":"flood 3 — over budget"}',
  ];

  for (const raw of incoming) {
    if (!consume(bucket)) { console.log('THROTTLED (bucket empty):', raw.slice(0, 28)); continue; }
    const v = validate(raw);
    if (!v.ok) { console.log('REJECTED (' + v.reason + '):', raw.slice(0, 28)); continue; }
    console.log('ACCEPTED:', v.msg.text);
  }
  console.log('tokens left:', bucket.tokens.toFixed(2));
})();

ลองรันแล้วอ่านคำตัดสิน: frame ที่ผิดรูป ใหญ่เกิน และ type ที่ไม่รู้จัก จะโดน validator ปฏิเสธ และเมื่อ burst ดูด bucket ห้า token จนหมด frame ที่ตามมาก็โดน throttle ไม่ว่าเนื้อหาจะเป็นอย่างไร การ์ดสองอันที่เป็นอิสระต่อกัน — อันหนึ่งคุม rate, อันหนึ่งคุม รูปร่าง — และการเชื่อมต่อเดียวจะถล่มหรือทำให้ server สับสนไม่ได้อีกต่อไป

Rate Limit Type	จำกัดอะไร	เหมาะกับ
Connection rate	connection ใหม่ต่อ IP ต่อวินาที	ป้องกัน connection flood
Message rate	message ต่อ connection ต่อวินาที	ป้องกัน spam, abuse
Payload size	ขนาด message สูงสุด	ป้องกัน memory exhaustion
Room join rate	join room ต่อวินาที	ป้องกัน room flooding

ข้อผิดพลาดที่พบบ่อย

ไม่มี Payload Size Limit อาการ:

client ส่ง message ขนาด 100MB — server buffer ล้น
ทำให้ memory spike และ อาจ crash server
ตั้ง max message size: ปฏิเสธ message ที่ใหญ่เกิน limit และปิด connection

ไม่ Validate Message Content อาการ:

รับ message JSON แล้วส่งต่อโดยไม่ validate schema
malformed message ทำให้ consumer crash
ใช้ Zod หรือ JSON Schema validate ทุก message ที่รับ ก่อน process

💡 ตัวอย่างจากของจริง

Discord:

rate limit message: 5 message ต่อ 5 วินาทีต่อ user

ส่งเกิน → 4008 opcode (Rate limited) → client ต้องรอก่อน retry

Binance WebSocket:

connection rate limit ต่อ IP

subscription limit: subscribe ได้สูงสุด N stream ต่อ connection

🔌 จำกัดทั้ง rate และรูปร่าง ราย connection

WebSocket ไม่มี throttle ในตัว ดังนั้นเพิ่มเข้าไป: token bucket ราย connection จำกัดจำนวน message ที่ client ส่งได้, size cap (ใช้ maxPayload ของ library) หยุด frame ที่ใหญ่เกิน, และ การ parse แบบ try/catch บวกกับ validate รูปร่าง หยุด frame ที่ผิดรูป ใช้ทั้งสามอย่างกับทุก connection — client ที่ใช้งานในทางที่ผิดหนึ่งตัวต้องไม่มีทางทำให้ตัวอื่นอดอยากได้เลย