上传压死下载 & 常见TCP选项

上传压死下载

 

下载文件的速度非常低。

抓取数据包分析，发现：

服务器 —> 客户端 的包，经历时间 < 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倍。