首先说一下标题中提到2者之间的联系。半开连接是针对TCP协议来说，而且这种做法是普遍运用于BT,电驴用。

因为半开连接对于谁来说都是一种高效的做法。

先说一说路由器丢包的问题。

今天在BT下载时，偶然发现路由的log上有这么一些信息:

Free=866, Busy=158, Bind=154, Inv=0/1, Bc=0/0, Dns=109, cl=48, fc=0/0, sq=2/30

Free在路由初始化时，被设置成了1024，bind=0.其他的几个也没怎么看明白，Dns应该是dns请求数吧，cl可能是换行符？或者别的。sq可能是arp请求？bind难道和端口映射有关？

而free的初值，我想就应该是路由器的转发缓冲了。至于有多大？不知道，只知道有1k的缓冲项能力。当我把bt打开时，busy可以达到1000+，可见BT在寻找节点初的请求量，当若干分钟后busy会稳到200左右。后来我又打开电驴，初始化之初，free只有600。之后逐步递减到400左右。

路由丢包，原因已经很清楚。就是缓冲溢出，转发能力造成的。如果局域网内有多个高网络并发网络程序，那么很有可能会造成网络堵塞。这与adsl上行拥堵造成的网络不畅通有相似之处，也有差别。

同时，我也佩服这BT客户端，居然能在初始化之初并发这么大。相对电驴还是温和一些。

回过头来说半开连接，他是TCP四次握手（断开连接）的一种特例。正常情况下，如果四次握手行为中，只有2次握手出现，那么有一方很有实用了半开连接。

一个很明显的案例就是C/S中，服务器listen，然后accpet，在established后，客户端即将断开连接。此时会出现TCP的四次握手。但为什么四次握手之后，服务器依然还能接受本socket的TCP连接呢？

因为服务器就是用了类似半开连接的做法。在给予客户端FIN确认时。自己虽然关闭掉了一个worker线程，但并没有关闭自己的实际连接。因此它能够继续listen , accpet下去。

至于其他更多的内容，还需要我进一步的学习才会清楚。