Speedbump - वैरिएबल लेटेंसी सपोर्ट करने वाला TCP प्रॉक्सी

 (github.com/kffl)
4 पॉइंट द्वारा GN⁺ 2024-01-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Speedbump Go में लिखा गया TCP प्रॉक्सी है, जो प्रॉक्सी किए जा रहे TCP ट्रैफिक में वैरिएबल नेटवर्क लेटेंसी जोड़कर देरी की स्थितियों को simulate करता है
  • बेस लेटेंसी में sine wave, sawtooth wave, square wave, triangle wave के रूप में लेटेंसी components जोड़े जा सकते हैं, और कई लेटेंसी components को एक साथ combine किया जा सकता है
  • उदाहरण में localhost:80 की ओर जाने वाले ट्रैफिक को पोर्ट 2000 पर प्रॉक्सी करते हुए 100ms बेस delay, 100ms sine wave amplitude और 1m period लागू करने वाला configuration दिखाया गया है
  • इंस्टॉलेशन release-wise prebuilt binary download करके, source से go build चलाकर, या kffl/speedbump container image चलाकर किया जा सकता है
  • CLI के अलावा Go के lib package के जरिए इसे library के रूप में इस्तेमाल किया जा सकता है, और buffer size, delay queue size, log level, listening host और port आदि को arguments से adjust किया जा सकता है

TCP delay simulation के लिए प्रॉक्सी

  • Speedbump Go में लिखा गया TCP प्रॉक्सी है और वैरिएबल नेटवर्क लेटेंसी simulate कर सकता है
  • प्रॉक्सी target CLI के <destination> argument से specify किया जाता है, और format host:post बताया गया है
  • default behavior TCP traffic को destination तक proxy करते हुए configured delay जोड़ने का है

इंस्टॉलेशन और चलाने के तरीके

  • सबसे आसान इंस्टॉलेशन तरीका हर release के Assets में अपने-आप attached prebuilt binary download करना है
  • source से build करने के लिए repository clone करने के बाद go build चलाएं
  • container में चलाने के लिए kffl/speedbump image इस्तेमाल की जा सकती है

बेसिक उपयोग का उदाहरण

  • पोर्ट 2000 पर listen करते हुए और TCP traffic को localhost:80 पर proxy करते हुए बेस delay 100ms, sine wave amplitude 100ms, और period 1m लागू किया जा सकता है
    • यह configuration maximum additional latency 200ms और minimum additional latency 0 बनाता है
    • run example speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80 है
  • वही configuration container image से भी चलाया जा सकता है
    • example docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80 है
  • sawtooth wave delay component भी configure किया जा सकता है
    • example में बेस delay 300ms, sawtooth wave amplitude 200ms, period 2m, port 2000, destination localhost:80 configuration है
    • run command speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80 है

लेटेंसी components का combination

  • Speedbump कई लेटेंसी components को एक साथ apply कर सकता है
  • README में sawtooth wave और sine wave combine किए गए delay graph का example शामिल है

CLI arguments और library usage

  • speedbump --help speedbump [<flags>] <destination> format में usage देता है
  • प्रमुख network settings इस प्रकार हैं
    • --host: listen करने वाला IP या hostname; specify न करने पर सभी network interfaces से bind करता है
    • --port: listening port, default value 8000 है
    • --buffer: TCP reads के लिए इस्तेमाल होने वाला buffer size, default value 64KB है
    • --queue-size: read buffers store करने वाली delay queue size, default value 1024 है
  • delay-related defaults और waveform options दिए गए हैं
    • --latency: proxy traffic में जोड़ी जाने वाली बेस लेटेंसी, default value 5ms है
    • --sine-amplitude, --sine-period: sine wave latency amplitude और period
    • --saw-amplitude, --saw-period: sawtooth wave latency amplitude और period
    • --square-amplitude, --square-period: square wave latency amplitude और period
    • --triangle-amplitude, --triangle-period: triangle wave latency amplitude और period
  • operations-related options भी शामिल हैं
    • --log-level: log level; possible values DEBUG, TRACE, INFO, WARN, ERROR हैं
    • --version: application version दिखाता है
  • Speedbump को Go library के रूप में भी इस्तेमाल किया जा सकता है, और यह lib package के जरिए उपलब्ध है
  • license Apache 2.0 License है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-17
Hacker News की टिप्पणियां

  • मैंने अलग-अलग नेटवर्क आकारों और स्थितियों में कई ActivityPub implementations को टेस्ट करने के लिए कुछ ऐसा ही देखा था, लेकिन पता चला कि मेरी मशीन पर tc के रूप में जरूरत की सारी चीजें पहले से इंस्टॉल थीं
    मेरे distro में यह iproute2 package में शामिल था, और इसका विवरण यहां भी है: https://wiki.archlinux.org/title/advanced_traffic_control
    किसी खास interface पर delay जोड़ने के लिए tc qdisc add dev eth0 root netem delay 100ms जैसा command चला सकते हैं
    इस्तेमाल में आसान है, Docker containers में भी अच्छे से काम करता है, delay, packet loss, duplication जैसी conditions लागू कर सकता है, और संभव है कि आपके पास पहले से इंस्टॉल हो

    • tc/netem/tbf वाकई शानदार हैं। इनके ऊपर मैंने एक साधारण Python GUI बनाया और उसे touchscreen case में लगे Pi पर चलाया; यह एक छोटा-सा काला box था जिसमें “packet drop: [0%] [1%] [10%] [50%] / packet corruption: ...” जैसी चीजें थीं, और customers काफी प्रभावित हुए
      हैरानी की बात है कि commercial hardware products के रूप में ऐसे frontend ज्यादा दिखते नहीं; अगर मैंने search में miss नहीं किया, तो शायद market में हैं ही नहीं
    • tc की कमी यह है कि इसे incoming packets पर लागू करना थोड़ा अजीब और कठिन है
      पहले मैंने एक खास commercial satellite terminal की नकल करने के लिए खुद emulator बनाया था। वह terminal packets को queue में रखता था और किसी threshold पर पहुंचने या timeout होने पर उन्हें एक साथ burst में भेज देता था; साथ ही वह छोटे packets को “मेहरबानी” करके queue के आगे reorder कर delay कम करने की कोशिश करता था, लेकिन TCP stack को यह बिल्कुल पसंद नहीं आया
    • speedbump की अच्छी बात यह है कि failure conditions को समय के साथ adjust किया जा सकता है। tc यह नहीं कर पाता
      समय के साथ बदलते satellite/RF weather effects को simulate करने में यह काफी उपयोगी हो सकता है

  • Netflix ने जो बनाया था, वह ठीक यही था, और उसका नाम latency monkey था
    हमने पाया कि कोई downstream service “slow” है या नहीं, यह तय करना उसके “unavailable” होने का पता लगाने से कहीं ज्यादा कठिन है; इसलिए यह test करने का एक अहम तरीका था कि services slowdown और network issues को कैसे handle करती हैं
    implementation बहुत simple था: configurable ratio के हिसाब से packets drop किए जाते थे, जिससे retransmission मजबूर होती थी और दूसरी तरफ packets delayed और out-of-order पहुंचते थे
    आखिर में network access से जुड़े error-handling code में बहुत सारी समस्याएं मिलीं

  • interactive Internet applications बनाने वाले हर software engineer को अपने रोजमर्रा के काम में ऐसे tools जरूर इस्तेमाल करने चाहिए। सिर्फ TCP ही नहीं, QUIC भी चाहिए, और DNS को भी पकड़ना हो तो ideally सभी UDP भी शामिल होने चाहिए
    मुझे यकीन है कि अगर बनाने वाले लोग सिर्फ gold-plated Cadillac जैसी computing environment में काम न करते, तो web apps की 90% bloating गायब हो जाती

    • Firefox developer tools में भी यह किया जा सकता है। Chrome developer tools में भी शायद similar feature होगा
      https://firefox-source-docs.mozilla.org/devtools-user/networ...
      बेशक, यह केवल frontend, browser-based testing पर लागू होता है

  • disaster relief जैसी situations में, जहां network connection रुक-रुक कर टूटता है, कई apps बेहद खराब तरीके से काम करते हैं
    अगर और app developers intermittent connectivity simulate करके test करें, तो इससे दूसरों को मदद मिल सकती है
    “Toxiproxy is a framework for simulating network conditions” (2021) https://news.ycombinator.com/item?id=29084277#29088775 में यह बात आई थी:

    कई apps में, उदाहरण के लिए email client में अपेक्षित ‘outbox में pending रखना’ जैसी सुविधा नहीं होती

    • [ ] क्या कोई common #DisasterRelief connectivity issues को simulate करने वाले reference toxiproxy ‘test case mutators’ का set बना सकता है?
    • मुझे सबसे ज्यादा खराब वह स्थिति लगती है जब packets भेजने से पहले buffer भरा नहीं जाता। तब खराब Internet connection—यानी packet drops और high latency के कारण TCP retransmission वाली environment—में अचानक सिर्फ 120kps मिलता है
      क्योंकि आप केवल 50-byte packets भेज रहे होते हैं और उनमें से हर 10 में 1 packet खो जाता है। इस दौरान server का एक thread कोई उपयोगी काम नहीं कर रहा होता

  • Mac पर built-in tools से भी यही किया जा सकता है

    # Setup pipe  
sudo dnctl pipe 1 config bw 1Kbit/s delay 800

# Setup matching pf rule  
echo "dummynet out proto tcp from any to 127.0.0.1 port 11211 pipe 1" | sudo pfctl -f -

# Turn on firewall  
sudo pfctl -e

# Test  
time nc -vz 127.0.0.1 11211  
Connection to 127.0.0.1 port 11211 [tcp/*] succeeded!  
nc -vz 127.0.0.1 11211 0.01s user 0.00s system 0% cpu 1.333 total
    • Dummynet और ये features FreeBSD से आए हैं, और वहां ये काफी समय से मौजूद हैं। 15 साल से भी ज्यादा पहले मैंने इससे packet loss testing की थी और यह अच्छी तरह काम करता था

  • एक project है जो कुछ समय से inactive है, लेकिन नाम ही बहुत कुछ कह देता है: https://github.com/tylertreat/comcast

  • हाल ही में Mac पर slow network simulate करने की कोशिश करते हुए मुझे Network Link Conditioner मिला, और यह काफी अच्छा है। proxy जैसी कोई चीज setup करने की जरूरत नहीं
    इसे Xcode additional tools से install करना होता है
    https://nshipster.com/network-link-conditioner/

  • Shopify का बेहतरीन tool toxiproxy भी देखने लायक है: https://github.com/Shopify/toxiproxy
    networking libraries को खुद implement करके test करने का भी यह बहुत अच्छा तरीका है, क्योंकि stack को ज्यादातर adverse situations को सही से handle कर पाना चाहिए
    ‘chaos engineering’ का idea शानदार है

    • मैंने भी शुरुआत में toxiproxy देखा था, लेकिन client-server model मेरे लिए ठीक नहीं था और speedbump HTTP delay simulation वाले मेरे use case के लिए बिल्कुल सही था
      मैं web crawler के लिए progress bar develop कर रहा हूं, लेकिन localhost पर test करने पर यह इतना तेज होता है कि problem है या नहीं, समझना मुश्किल होता है
      speedbump इस्तेमाल करके बस podman run --net=host kffl/speedbump:latest --latency=1s --port=8001 localhost:8000 चलाना होता है और http://localhost:8001 पर crawler test करना होता है
      साफ-सुथरा tool है

  • Windows पर मैंने एक similar tool इस्तेमाल किया है
    https://jagt.github.io/clumsy/

    • करीब 10 साल पहले कई intercontinental network conditions test करने के लिए इस्तेमाल किया था, और results reality से अच्छी तरह match करते थे। recommend करने लायक है
    • अच्छा दिखता है, लेकिन screenshots से लगता है कि यह per-adapter लागू होने के बजाय filter के साथ system-wide application जैसा है

  • FreeBSD में भी ipfw के हिस्से के रूप में dummynet है, जिससे delay, bandwidth limits, queue size, और packet loss inject किए जा सकते हैं। यह MacOS में मौजूद feature जैसा ही है

    • क्या यह Linux के tc जैसा है?