首先，无论是XP或VISTA系统中所作的连接数限制并不是限制系统的TCP的连接数量，而是TCP 的半开连接数。所谓TCP半开连接，就是发送了TCP连接请求，等待对方应答的状态（也就是连接尚未完全建立起来，双方还无法进行通信交互的状态）。
这里要说一个概念：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据。
上述是一个完整的TCP连接过程。
在完成三次握手之后，TCP连接已经建立，那么对系统来说，这就是一个TCP连接数。系统对这样一个数没有限制。 如果三次握手没有完成，客户端与服务器没有开始传送数据，那么，这样试图完成三次握手的事件发生的数是被系统所限制的。而这个数就是所谓的半开连接数了。
引用内容
为什么一开BT就超级慢呢？问题的根本在于BT是频繁的建立TCP连接，并且是同时建立，所以导致有大量的SYN包。
TCP是Layer 4，从技术角度说是非常耗费资源的，无论是系统资源还是网络资源，在同时并发1000个左右的连接请求的时候。
你可以想象你的网络带宽里都充斥着SYN包，所以频繁建立TCP连接才是让BT影响网络的根本原因。
下面再说两个概念：一是系统所限制的TCP半开连接数，二是P2P软件所设定的TCP半开连接数。
P2P软件所设定的TCP半开连接数超过了系统所限制的数量，它们在下载文件的时候不断建立新的半开连接，系统自然会给出EventID 4226事件警告。
遇到这种情况应该怎么办呢？三种办法：一是卸载掉产生过多TCP半开连接数的P2P软件软件，二是修改P2P软件所设定的TCP半开连接数（降低），三是修改P2P软件所允许的最大TCP连接数（降低已经开始传送数据的连接数量）。
因为每进行一次半开连接都会使系统（包括路由器、防火墙、操作系统等）引入额外的开销，过多的半开连接数只会导致系统资源紧张、不稳定甚至崩溃，反而会影响网络的实际传输。其实这个才是影响BT下载时不能浏览网页的主要因素。再者，可能会被黑客利用，散布虚假资源信息或进行DDoS攻击等手段。
这里补充一下：半开连接数的多少不会对下载文件的最高速率有影响。也就是说，不会提高下载的最高速率。如果已经建立了适当的连接，就没必要拥有更多的连接，这样反而可能造成系统和网络负担。