bittorent clients aggressively connect to peers ... and some routers interpret this as a syn-flood.
When uTorrent is loaded and uploads/downloads are paused (not stopped) it maintains open connections with your peers. Meanwhile legions of internet peers will still attempt to connect to you to find out if you have the bits they want.
Eventually you will reach the open connection limit imposed by your OS (in Windows 7 this is 10 connections) and connections from new clients will start queuing at your router.
Queued clients will check aggressively to see if a connection is free. This aggressive polling may be interpreted as a syn-flood attack by the router.
- lower your half-open connection limit in your bittorent software below the connection limit imposed by your OS
- disable IP flood protection at your router/modem.
In addition, with uTorrent (or any bulk traffic) connection running unrestricted, the upload (and possibly download) pipe reaches full usage, forcing some "upkeep" traffic to take a back seat, which ends up decreasing network usefulness.
Here is an example:
- High speed download (torrent or otherwise) saturates downstream link.
- User tries to browse to a site not recently visited. Computer generates a request for DNS info for desired site. "Upload" of request to DNS server succeeds (not challenged for upstream pipe access).
- DNS server responds (or tries to), but response gets hung up on trying to get to the user's machine because the download pipe is saturated with download content, and since something has to be dropped, and the download is aggressive about maintaining speed, the DNS response gets dropped (at some point before it gets to the local router).
The same thing can happen if upload is unrestricted. With upload saturated, packets known as TCP-ACK (which are sent as "Hey, I got packet xyz successfully" type responses) get hung up, making downloads grind to a halt, causing web browsing to become very patchy.
- Figure out what the maximum capabilities of your connection are (up and down, individually), and set the maximum speed of your bulk transfer clients to not use more than about 80% of that speed. This will leave "headroom" for things like DNS and TCP-ACK packets to bypass the bulk traffic and get dealt with quickly.
- Use a router that can handle traffic shaping such that certain traffic (DNS, IMCP Ping, TCP-ACK) can be prioritized ahead of other forms of traffic, and some forms of traffic (torrent in particular) can be de-prioritized. This is my preferred method. This can give the added benefit of allowing the full up and down pipe to be usable for torrent traffic when higher priority traffic does not challenge it.
- Use some combination of 1 and 2 to restrain "misbehaving" traffic.
If interested in more info about traffic shaping Linux/BSD distros, MonoWall and IPCop both have some good information.