Simple repro - in one window watch processes in top, in the other run: nc -lkp 10000 > /dev/null & ( head -50000000 /dev/urandom | nc -N 127.0.0.1 10000 ) & ( head -50000000 /dev/urandom | nc -N 127.0.0.1 10000 )
Observe that only one head
and nc
process are actively using CPU.
Attach strace to the head
that isn't active - see it's stalled on a write, e.g.:
strace: Process 589084 attached
write(1, "\264\347\270\26\27\24'BRb^\353\302\36@\216\17V\210*n\252`\353\330\351\276\2\250\330\350\217"..., 4096^Cstrace: Process 589084 detached
<detached ...>
Set up two listeners on different ports - e.g. 10000 and 10001, and both go at full speed.
This is a simple example, but I can reproduce it with other inputs and outputs - e.g. zcatting large files and sending them to production services over the network. It's not to do with the input, and it's not to do with the listening socket.
So - why can I can only have one tcp connection to any given host/port actively sending data?
There is an independent data source (feel free to experiment if you don't believe me), and an independent process opening its own tcp connection (netstat
will show them both open) - the only thing in common is the destination (which doesn't have to be an nc
listening on lo
- happens to anything).
Given the destination can definitely have multiple incoming sockets receiving data at once, and the source can definitely send data down multiple network sockets at once, I'm struggling to figure out where the contention is coming from, causing only one pipe to be active at once.