Speedbump - พร็อกซี TCP ที่รองรับเลย์เทนซีแบบแปรผัน

 (github.com/kffl)
4 คะแนน โดย GN⁺ 2024-01-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พร็อกซี TCP ที่เขียนด้วยภาษา Go ซึ่งสามารถจำลองความหน่วงเครือข่ายแบบแปรผันได้หลากหลายรูปแบบ

ตัวอย่างการใช้งานพื้นฐาน

  • สร้างอินสแตนซ์ใหม่ที่รับฟังบนพอร์ต 2000 เพื่อพร็อกซีทราฟฟิก TCP ไปยัง localhost:80 โดยมีความหน่วงพื้นฐาน 100ms, แอมพลิจูดคลื่นไซน์ 100ms (ความหน่วงเพิ่มเติมสูงสุด 200ms, ต่ำสุด 0) และคาบ 1 นาที: 
    speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80
  • หรือเมื่อรัน speedbump โดยใช้คอนเทนเนอร์อิมเมจ kffl/speedbump: 
    docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
  --sine-period=1m --port=2000 localhost:80
  • สร้างอินสแตนซ์ใหม่ที่มีความหน่วงพื้นฐาน 300ms และมีความหน่วงแบบคลื่นฟันเลื่อยที่มีแอมพลิจูด 200ms คาบ 2 นาที ตามที่แสดงในกราฟด้านล่าง: 
    speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80
  • สามารถรันการรวมความหน่วงหลายแบบพร้อมกันได้
  • Speedbump สามารถใช้งานเป็นไลบรารี Go ผ่านแพ็กเกจ lib ได้

ความคิดเห็นของ GN⁺:

  • Speedbump เป็นเครื่องมือที่มีประโยชน์สำหรับการจำลองความหน่วงเครือข่าย และอาจช่วยในการทดสอบและปรับแต่งประสิทธิภาพของแอปพลิเคชันที่ทำงานบนเครือข่ายได้
  • เนื่องจากเขียนด้วยภาษา Go จึงคุ้นเคยสำหรับนักพัฒนา Go และมีความสามารถในการจำลองรูปแบบความหน่วงที่หลากหลายได้อย่างง่ายดาย
  • เป็นโอเพนซอร์สและใช้สัญญาอนุญาต Apache 2.0 จึงมีโอกาสได้รับการพัฒนาอย่างต่อเนื่องผ่านการมีส่วนร่วมจากชุมชน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-17
ความคิดเห็นจาก Hacker News
  • เคยค้นคว้างานลักษณะคล้ายกันเพื่อทดสอบการทำงานของ ActivityPub ภายใต้ขนาดและสภาพเครือข่ายที่หลากหลาย เรียนรู้วิธีใช้คำสั่ง tc เพื่อเพิ่มความหน่วงให้กับอินเทอร์เฟซที่กำหนด ซึ่งทำงานได้ดีกับ Docker container ด้วย และอาจมีติดตั้งอยู่แล้วในหลายระบบ
    • ตัวอย่างคำสั่ง: tc qdisc add dev eth0 root netem delay 100ms
  • ที่ Netflix เคยพัฒนาเครื่องมือที่เรียกว่า 'latency monkey' การตรวจจับว่าบริการปลายทางทำงานช้าลงนั้นยากกว่าการตรวจจับว่าบริการใช้งานไม่ได้มาก เครื่องมือนี้จะทิ้งแพ็กเก็ตตามสัดส่วนที่กำหนดเพื่อบังคับให้เกิดการส่งซ้ำ และทำให้แพ็กเก็ตล่าช้าหรือสลับลำดับกัน พบปัญหาจำนวนมากในโค้ดจัดการข้อผิดพลาดเกี่ยวกับการเข้าถึงเครือข่าย
  • วิศวกรซอฟต์แวร์ทุกคนที่ทำงานกับแอปพลิเคชันอินเทอร์เน็ตควรใช้เครื่องมือแบบนี้เป็นประจำ ทั้ง QUIC และ TCP จำเป็น และควรดักจับ UDP ทั้งหมดรวมถึง DNS ได้ด้วย มั่นใจว่าถ้านักพัฒนาไม่ได้ใช้สภาพแวดล้อมคอมพิวเตอร์สมรรถนะสูง เว็บแอป 90% คงหายไป
  • แอปจำนวนมากทำงานได้แย่ลงเมื่อการเชื่อมต่อเครือข่ายติดๆ ดับๆ นักพัฒนาแอปสามารถช่วยคนอื่นได้ด้วยการทดสอบการเชื่อมต่อแบบไม่ต่อเนื่องที่จำลองขึ้น แอปจำนวนมากยังขาดฟังก์ชัน 'กล่องรอส่ง' แบบโปรแกรมอีเมล มีคำถามว่าใครจะพัฒนา 'ตัวกลายพันธุ์ test case' สำหรับ toxiproxy เพื่อจำลองปัญหาการเชื่อมต่อทั่วไปในสถานการณ์บรรเทาภัยพิบัติได้บ้าง
  • บน Mac สามารถใช้เครื่องมือที่มีมาในระบบเพื่อทำสิ่งที่คล้ายกันได้ มีการยกตัวอย่างคำสั่งสำหรับจำลองความเร็วการเชื่อมต่อเครือข่าย
  • ตอนต้องการจำลองเครือข่ายช้าบน Mac ได้ไปเจอ Network Link Conditioner ใช้งานได้โดยไม่ต้องตั้งค่า proxy หรือการตั้งค่าอื่นเพิ่มเติม และต้องติดตั้งจากเครื่องมือเสริมของ Xcode
  • แม้จะไม่ได้ใช้งานมานานแล้ว แต่ชื่อ 'comcast' ก็บอกอะไรได้หลายอย่าง
  • เครื่องมือคล้ายกันที่เคยใช้บน Windows คือ 'clumsy'
  • FreeBSD ก็มีความสามารถชื่อ 'dummynet' ซึ่งเป็นส่วนหนึ่งของ ipfw สำหรับใส่ความหน่วง จำกัดแบนด์วิดท์ กำหนดขนาดคิว และจำลองการสูญหายของแพ็กเก็ตได้ เป็นความสามารถแบบเดียวกับบน MacOS
  • ไม่มีวันลืมตอนที่ผู้จัดการในงานแรกตั้งค่าไฟร์วอลล์ FreeBSD IPFW ให้ตอบ ICMP ช้าลง ทุกครั้งที่มีคนส่ง ping เข้ามา เวลาตอบสนองจะดูสูงที่สุด ผู้จัดการคนนั้นเป็นคนชอบแกล้ง