上传压死下载
下载文件的速度非常低。
抓取数据包分析，发现：
服务器 —> 客户端 的包，经历时间 < 1ms后，对方做出反应。
客户端 —> 服务器 的包，经历几十至几百ms后，对方才有反应。一个文件中的第一个SYN请求还超时，3s后重传。
服务器 —> 客户端 的包，至少都重传了一遍，不论是在建立连接时，还是在传送数据时。
可能的原因：客户端 —> 服务器的链路拥塞，丢包率高，客户端的ACK丢失了，服务器就会超时重传。
标准TCP的实现借助反馈机制（ACK数据包）来控制流量。当链路上行方向带宽用满后，下行方向数据的ACK数据包
将与上行方向的大数据流竞争上行带宽，丢包的概率增大。ACK数据包的丢失将严重影响TCP的流控机制，从而降低
下行方向的数据吞吐率，造成下行带宽的严重浪费，即所谓的上传压死下载。
根本上的解决方法：杜绝上行拥塞，并给予ACK数据包高优先级。
更具体的猜测：
P2P软件在下载的同时，也在为其他用户提供上传。BT、迅雷等软件在下载的同时又作为种子为其他人提供下载服务，
由于ADSL上行带宽最大只有512Kbps，所以使用P2P软件后更容易造成局域网出口上行带宽的拥塞，但是任何上网操作
均需要上行/下行两个方向的流量，如果上行带宽被占满，就会影响到下行带宽的使用。
常见TCP SYN包选项构成
02 04 05 b4
04 02 08 0a
00 00 ed d1
00 00 00 00
0103 03 06
Maximum Segment Size
0x 02 04 05 b4
Kind = 2
Length = 4
Maximum Segment Size = 0x05b4 = 1460
SACK permitted
0x 04 02
Kind = 4
Length = 2
Timestamp
0x 08 0a 00 00 ed d1 00 00 00 00
Kind = 8
Length = 10
Timestamp Value = 0x0000edd1 = 60881
Timestamp Echo Reply = 0x00000000 = 0
NOP
0x 01
Kind = 1
Window Scale
0x 03 03 06
Kind = 3
Length = 3
Shift count = 6
TCP头中Window size value为14600，表示tcp_rmem为14600字节。接下来的数据包中，这个值就要扩大64倍。