Speedbump - proxy TCP hỗ trợ độ trễ biến thiên

• Một proxy TCP được viết bằng Go, có thể mô phỏng nhiều mức độ trễ mạng biến thiên khác nhau

Ví dụ sử dụng cơ bản

• Tạo một instance mới lắng nghe trên cổng 2000 để proxy lưu lượng TCP tới localhost:80, với độ trễ mặc định là 100ms, biên độ sóng sin là 100ms (độ trễ bổ sung tối đa 200ms, tối thiểu 0), chu kỳ 1 phút:

  speedbump --latency=100ms --sine-amplitude=100ms --sine-period=1m --port=2000 localhost:80  
  

• Hoặc khi chạy speedbump bằng image container kffl/speedbump:

  docker run --net=host kffl/speedbump:latest --latency=100ms --sine-amplitude=100ms \  
    --sine-period=1m --port=2000 localhost:80  
  

• Tạo một instance mới với độ trễ mặc định 300ms, và độ trễ dạng sóng răng cưa có biên độ 200ms, chu kỳ 2 phút như biểu đồ bên dưới:

  speedbump --latency=300ms --saw-amplitude=200ms --saw-period=2m --port=2000 localhost:80  
  

• Có thể chạy đồng thời việc cộng gộp nhiều mức độ trễ.
• Speedbump có thể được dùng như một thư viện Go thông qua gói lib.

---

Ý kiến của GN⁺:

• Speedbump là một công cụ hữu ích để mô phỏng độ trễ mạng, có thể giúp kiểm thử và tối ưu hiệu năng của các ứng dụng dựa trên mạng.
• Được viết bằng Go nên quen thuộc với các nhà phát triển Go, đồng thời cung cấp khả năng dễ dàng mô phỏng nhiều kiểu độ trễ khác nhau.
• Đây là mã nguồn mở và tuân theo giấy phép Apache 2.0, nên có khả năng tiếp tục được cải thiện thông qua sự đóng góp của cộng đồng.

[GN⁺]

Ý kiến trên Hacker News

• Đã tìm hiểu những công việc tương tự để kiểm thử việc triển khai ActivityPub trong nhiều quy mô và điều kiện mạng khác nhau. Đã học được cách dùng lệnh tc để thêm độ trễ cho một giao diện cụ thể, và nó cũng hoạt động tốt trong container Docker. Có thể nó đã được cài sẵn trên nhiều hệ thống.
  • Ví dụ lệnh: tc qdisc add dev eth0 root netem delay 100ms
• Tại Netflix, họ đã phát triển một công cụ gọi là 'latency monkey'. Việc phát hiện một dịch vụ downstream đang chậm khó hơn rất nhiều so với phát hiện khi dịch vụ không thể sử dụng được. Công cụ này làm rơi gói tin theo một tỷ lệ nhất định để kích hoạt truyền lại, từ đó khiến gói tin bị trễ hoặc bị đảo thứ tự. Nó đã phát hiện ra rất nhiều vấn đề trong mã xử lý lỗi liên quan đến truy cập mạng.
• Mọi kỹ sư phần mềm làm về ứng dụng Internet đều nên dùng các công cụ như thế này hằng ngày. Cả QUIC lẫn TCP đều cần thiết, và cần có khả năng bắt toàn bộ UDP, bao gồm cả DNS. Tôi tin chắc rằng nếu các nhà phát triển không dùng môi trường điện toán hiệu năng cao thì 90% web app sẽ biến mất.
• Nhiều ứng dụng hoạt động kém khi kết nối mạng chập chờn. Các nhà phát triển ứng dụng có thể giúp người khác bằng cách kiểm thử kết nối chập chờn được mô phỏng. Nhiều ứng dụng thiếu tính năng 'hộp thư đi' như các ứng dụng email. Có câu hỏi về việc ai có thể phát triển một 'trình biến đổi ca kiểm thử' toxiproxy tham chiếu để mô phỏng các vấn đề kết nối phổ biến trong tình huống cứu trợ thiên tai.
• Trên Mac, có thể làm việc tương tự bằng các công cụ tích hợp sẵn. Có đưa ra ví dụ lệnh để mô phỏng tốc độ kết nối mạng.
• Khi muốn mô phỏng mạng chậm trên Mac, đã tìm thấy Network Link Conditioner. Có thể dùng nó mà không cần cấu hình proxy hay thiết lập khác, nhưng phải cài từ bộ công cụ bổ sung của Xcode.
• Dù đã lâu không hoạt động, cái tên 'comcast' vẫn gợi ra rất nhiều điều.
• Một công cụ tương tự từng dùng trên Windows là 'clumsy'.
• FreeBSD cũng có tính năng 'dummynet', là một phần của ipfw, có thể chèn độ trễ, giới hạn băng thông, kích thước hàng đợi và mất gói. Chức năng này tương tự như trên MacOS.
• Tôi không thể quên việc ở công ty đầu tiên, quản lý đã cấu hình tường lửa FreeBSD IPFW để làm chậm phản hồi ICMP. Mỗi khi ai đó gửi ping, thời gian phản hồi luôn hiện ở mức cao nhất. Người quản lý đó đúng là một tay thích đùa.