Rate limit network but allow bursting per TCP connection before limiting

This is a feature of ATT ksh93 that was added in bash 2.04. None of the other common shells have it, in particular you won't find it in any of the dash variants, in pdksh or mksh (as of July 2015), in any of the BusyBox or Android variants, or in zsh¹ or fish. Bash can be compiled without this feature (see --enable-net-redirections), so it may be absent from embedded devices, even if they have bash.

To test whether the feature is present, you can check the error message when trying to open a TCP port for the discard service: both bash and ksh say “Connection refused” (or the command returns immediately if you have a discard service on your local machine), which you wouldn't see if this doesn't attempt to make some network connection.

: </dev/tcp/127.0.0.1/9

One reason this isn't a common feature is that a lot of network protocols require two-way communication with careful handling of who talks when, which shells aren't very convenient for. Another reason is that for the simple cases, pipes involving netcat, socat or socket also work. These programs handle binary data and can be servers as well as clients. Most protocols that can be handled in a simple way have specialized tools, wake-on-LAN excepted.

echo -e "GET / HTTP/1.1\n\n" | nc www.google.com 80

echo -e "GET / HTTP/1.1\n\n" | socat - TCP:www.google.com:80

(socket doesn't really work as a HTTP client since it doesn't close its write of the connection on the end of input.)

For scripting:

case $(export LANGUAGE=C LC_ALL=C; { : </dev/tcp/127.0.0.1/9; } 2>&1) in
  ""|*"Connection refused"*) echo "/dev/tcp is present";;
  *)
    if type nc >/dev/null 2>/dev/null; then
      echo "netcat is present"
    elif type socat >/dev/null 2>/dev/null; then
      echo "socat is present"
    else
      echo "I can't do TCP"
    fi
esac

¹ _{Zsh has a different way of using UDP and TCP sockets.}

As I mentioned in my final edit, the reason that I am not able to get higher bandwidth using round-robin bonding when the switch has Link Aggregation Groups set is that switch Link Aggregation Groups do not do round-robin striping of packets on a single TCP connection, whereas the linux bonding does. This is mentioned in the kernel.org docs:

https://www.kernel.org/doc/Documentation/networking/bonding.txt

12.1.1 MT Bonding Mode Selection for Single Switch Topology

This configuration is the easiest to set up and to understand, although you will have to decide which bonding mode best suits your needs. The trade offs for each mode are detailed below:

balance-rr: This mode is the only mode that will permit a single TCP/IP connection to stripe traffic across multiple interfaces. It is therefore the only mode that will allow a single TCP/IP stream to utilize more than one interface's worth of throughput. This comes at a cost, however: the striping generally results in peer systems receiving packets out of order, causing TCP/IP's congestion control system to kick in, often by retransmitting segments.

It is possible to adjust TCP/IP's congestion limits by altering the net.ipv4.tcp_reordering sysctl parameter. The usual default value is 3. But keep in mind TCP stack is able to automatically increase this when it detects reorders.

Note that the fraction of packets that will be delivered out of order is highly variable, and is unlikely to be zero. The level of reordering depends upon a variety of factors, including the networking interfaces, the switch, and the topology of the configuration. Speaking in general terms, higher speed network cards produce more reordering (due to factors such as packet coalescing), and a "many to many" topology will reorder at a higher rate than a "many slow to one fast" configuration.

Many switches do not support any modes that stripe traffic (instead choosing a port based upon IP or MAC level addresses); for those devices, traffic for a particular connection flowing through the switch to a balance-rr bond will not utilize greater than one interface's worth of bandwidth.

If you are utilizing protocols other than TCP/IP, UDP for example, and your application can tolerate out of order delivery, then this mode can allow for single stream datagram performance that scales near linearly as interfaces are added to the bond.

This mode requires the switch to have the appropriate ports configured for "etherchannel" or "trunking."

The last note about having ports configured for "trunking" is odd, since when I make the ports in a LAG, all outgoing Tx from the switch go down a single port. Removing the LAG makes it send and receive half and half on each port, but results in many resends, I assume due to out-of-order packets. However, I still get an increase in bandwidth.