1. Introduction
While testing our applications before their deployment, the ideal is to emulate as close as possible the actual expected conditions. So we must design a set of input data that properly exercise all possible conditions, including corner cases. We’ll also set up a testing environment that is architecturally closer to production. In many cases, we’ll even try to load stress. It shall give insights into how the application will perform under its predicted load. Moreover, we must try to replicate harsh environmental conditions if it is expected that the application should withstand them. For instance, mobile applications should be prepared to recover from connectivity issues like connection losses, high packet-error rates, duplicated packets, or slow bandwidth. In this quick tutorial, we shall discuss when and how we can simulate network conditions and some of the tools that we might use.
2. Why/When to Simulate Specific Network Conditions
Under normal circumstances, testing applications for extreme or uncommon network conditions may be overkill. It doesn’t make sense, for instance, to expect high error rates for the communication between the application backend and its database located in the same subnetwork. However, if they are continents apart, connected through satellite links, we must consider the higher latency and error rates. So, in order to check the need for specific network conditions simulation, it is good to understand how each component of our solution will connect with each other. For each communications path, we must establish its performance requirements, throughput, latency, connection rate, robustness, concurrency, etc. Also, we must take note of the communications flows that pass through networks where performance requirements may not be met. Good candidates are networks that are not under our governance (like the Internet, customers’ own ISP, for instance) or that rely on non-ideal components (like satellite or radio links, high-noise physical layers, congested networks). The diagram bellows show the architectural placement of a traffic-shaping proxy that can modulate network traffic between the end-user and the presentation layer.
3. Simulating Slow Links and Errors
Depending on the communication flow, we want to add specific simulation conditions. There are a number of solutions. If we only need to simulate bandwidth limitations for web applications from an end-user perspective, we can use the web browser. Many web browsers like Chrome, Edge, and Firefox have configurations to throttle traffic in their developer’s mode settings. For packet errors and latency, we must use other solutions. If more different conditions testing is needed, or for simulating problems between software components in the solutions, some Virtual Machine environments allow the creation of virtual networks with limited bandwidth or even with a packet loss. For further control, we can add virtual hosts operating as routers between software components where we can add other effects like latency, packet duplication, or disordering. In these routers, we can use packet filtering or traffic-shaping proxies. Some of the solutions we might use to shape the traffic between software components are:
3.1. In-host Firewall or Packet Filtering
Many packet filtering solutions have options to add throttling and packet discarding rules that can simulate specific network issues. In some cases, it can be done even with the operating systems’ embedded packet filters, such as iptables in Linux or pf in BSD based-systems (FreeBSD, NetBSD, macOS X), We might as well need to use 3rd party software such clumsy in Windows, dummynet (various OSes).
3.2. Network Proxy Applications
For more flexibility and configuration options we may use network proxy applications like NetEm (network emulation) or Wondershaper. These programs can recreate an even broader set of network issues, such as packet duplication and reordering. For web applications, we can also use web debug proxies like Charles or Fiddler. They not only allow the simulation of slow connections but also have tools to save and replay test cases in order to make it easier to create stress tests.
3.3. Web-browsers Developer’s Mode
If we only need to assess the end-user experience, we can use the web browsers’ native Developer’s mode console (e.g. chrome devtools). Besides allowing us to emulate different devices and screen sizes, these tools also have network throttling capability. That way, we can simulate the user experience of bandwidth-limited users.
3.4. Virtual Machine Software
Many virtual machine software, such as VMware ESX or HyperV, are bundled with software-defined virtual switches. They can not only limit the throughput of their virtual ports but also recreate, in software, complex network configurations.
4. Conclusion
In this tutorial, we discussed the conditions when we should explore the application behavior under specific network issues and conditions. Even if we feel that specific network conditions simulations are not necessary, we should ensure testing our application at least for common network issues, e.g., connections losses and timeouts. But in some cases, we must go further. Making sure that the system can work on nonreliable network conditions is essential in many application domains. For those, be sure to properly simulate and test.