Proposal for a Docker and Linux-based Weak Network Simulation Feature

[dsphper]

@mhils

Problem Description

I have been working on a feature to simulate weak network conditions. Implementing a native weak network simulation that is cross-platform compatible has proven challenging. The feature is currently only viable in Linux environments or via Docker for non-Linux systems.

Proposal

I've developed a solution that functions well within a Docker or Linux environment. While it may not be the ideal cross-platform solution, it does provide a functioning weak network simulation for non-Linux platforms through Docker.

Benefits

The current weak network simulation combined with the WireGuard, Sock5 features can simulate weak network conditions for all types of traffic, including video calls, chats, as well as common TCP and UDP requests, etc. This is highly user-friendly for testers and developers, and it is applicable to all modes of mitmproxy.

Alternatives

I have considered finding a more universal method to simulate weak network conditions across various platforms. However, the technical challenges and potential inconsistencies might outweigh the benefits.

Additional context

This feature could prove particularly useful for testing how applications handle weak network conditions. However, its current limitation to Docker or Linux environments may restrict its wide applicability.

I would appreciate your feedback. Would you still be interested in this PR?

Best,

[mhils]

Hi there!

If you have a draft PR ready, please just send it. It's easier to talk about concrete code (even if not finished/polished) than hypothentical changes.

Generally speaking, mitmproxy's current design does not lend itself very well to simulating bad network conditions. Most proxy modes are based on regular sockets, so it's hard to drop or delay individual packets. With WireGuard mode it's maybe a bit different, but I feel that could/should maybe be a completely separate project? Again, if you have a simple proof of concept let's look at that and take it from there. 😃

[dsphper]

Hi there! 你好呀！

If you have a draft PR ready, please just send it. It's easier to talk about concrete code (even if not finished/polished) than hypothentical changes.如果您已准备好 PR 草稿，请直接发送。谈论具体代码（即使尚未完成/完善）比假设的更改更容易。

Generally speaking, mitmproxy's current design does not lend itself very well to simulating bad network conditions. Most proxy modes are based on regular sockets, so it's hard to drop or delay individual packets. With WireGuard mode it's maybe a bit different, but I feel that could/should maybe be a completely separate project? Again, if you have a simple proof of concept let's look at that and take it from there. 😃一般来说，mitmproxy 当前的设计不太适合模拟恶劣的网络条件。大多数代理模式都基于常规套接字，因此很难丢弃或延迟单个数据包。使用 WireGuard 模式可能有点不同，但我觉得这可以/应该是一个完全独立的项目？再说一次，如果您有一个简单的概念证明，让我们看看并从那里开始。 😃

Thank you for your prompt response and valuable feedback.

I'm glad to inform you that I have already implemented this feature in my customized version, and it's working well. It's important to note that the implementation is at the network layer rather than the application layer, which allows for packet-level simulation.

I understand your concerns about the complexity of simulating bad network conditions within the current design of mitmproxy. However, with the network layer implementation, we can create a more realistic simulation that could prove useful for developers and testers.

I will make time to prepare a draft PR with the current implementation for you to review. Looking forward to your feedback.

Best,

[mhils]

Awesome, thanks. Feel free to just dump non-working stuff in a PR that illustrates what you are doing, I don't need a polished PR to evaluate. :)