时延与传输速率(通过这个帖子可以了解网络传输速率的实际计算方法)

一位客户通过卫星接入Internet,带宽为2M，连接方式如下:下行链路为卫星小站接LNB再接RCR，然后用RJ45接口接到以太网；上行链路是路由器V.35接MOD再接ODU，然后通过卫星小站发送出去。路由器配置如下： interfac ...

一位客户通过卫星接入Internet,带宽为2M，连接方式如下:下行链路为卫星小站接LNB再接RCR，然后用RJ45接口接到以太网；上行链路是路由器V.35接MOD再接ODU，然后通过卫星小站发送出去。

路由器配置如下：

interface FastEthernet0/0

ip address 202.101.111.1 255.255.255.0

no ip directed-broadcast

!

interface Serial0/0

bandwidth 2048

ip address 10.1.1.2 255.255.255.252

no ip directed-broadcast

no keepalive

ignore-dcd

ip route 0.0.0.0 0.0.0.0 10.1.1.1

由于Serial 0/0 只发送不接收，对端无DCD信号，无keepalive信号，所以要设置no keepalive和ignore-dcd.

RCR (由卫星施工人员设置)的以太网地址与路由器F0/0同一子网，默认网关设为:202.101.111.1(路由器的以太网口地址).

设置完成后，测试发现：首先，ping 对端主机延时大,一个来回约为690ms。

由于卫星距地面约3.8万公里，信号往返约为3.8 x 4 =15.2 万公里，除以光速 30万公里每秒，约为0.5s，即500ms,所以延时基本正常。呵呵，这样算对吗?

还有一个让用户无法接受的测试结果是：用FTP从对端服务器下载文件，速率只能达到32k/s!

照理说线路的传输速率是2M bps，约等于250k 字节每秒才对，就算减掉协议的损耗，也该有个200k/s吧？

这个问题的揭示更有意思，它让我们发现延时是如何地影响了数据传输的速率。

我们知道FTP基于TCP，TCP在传输数据的时候接收方要进行应答，发送方在发送w个数据包后必须要收到一个应答包表明这些数据包已经送到，才能继续发送。如果线路的传输误码率很低，则w可以增大，反之要减少，这就是窗口机制。

本例中假设因线路质量极好，w达到16,MTU=1500,则发送方发送16 x 1500 = 24000 字节之后等待接收方的一个应答包(更正：Windows值为字节数，即发送n个字节后应等待一个应答，最大值：65535，故在此应为假设w=24000)，忽略建立连接的时间（三步握手建立连就用了 345 ms x 3 = 1035 ms 呢 ）,忽略字节流的传输时间，这24000个字节经过卫星链路到达接收方时花了345ms(690 ms / 2),接收发的应答包在345ms后亦传到了接收方处，则在这次传输中 24000 字节花了 690 ms, 速率为33.97k 字节每秒。

照此计算，在一般局域网中，如果延时为10 ms, 则在同样 n=16 MTU=1500的条件下速率可达2344k 字节每秒。当然，这要求你的线路带宽大于2344k 字节每秒(即18.3M bps)，否则网络将出现阻塞，速度下降。

由于速率只有32k/s，故上述的一个FTP会话其实只占了带宽的大约1/8.如果使用多线程的FTP工具，如netants,由可以充分利用带宽，使下载速度达到200k/s左右,实验证明了这一点。

一位客户通过卫星接入Internet,带宽为2M，连接方式如下:下行链路为卫星小站接LNB再接RCR，然后用RJ45接口接到以太网；上行链路是路由器V.35接MOD再接ODU，然后通过卫星小站发送出去。路由器配置如下： interfac ...

一位客户通过卫星接入Internet,带宽为2M，连接方式如下:下行链路为卫星小站接LNB再接RCR，然后用RJ45接口接到以太网；上行链路是路由器V.35接MOD再接ODU，然后通过卫星小站发送出去。

路由器配置如下：

interface FastEthernet0/0

ip address 202.101.111.1 255.255.255.0

no ip directed-broadcast

!

interface Serial0/0

bandwidth 2048

ip address 10.1.1.2 255.255.255.252

no ip directed-broadcast

no keepalive

ignore-dcd

ip route 0.0.0.0 0.0.0.0 10.1.1.1

由于Serial 0/0 只发送不接收，对端无DCD信号，无keepalive信号，所以要设置no keepalive和ignore-dcd.

RCR (由卫星施工人员设置)的以太网地址与路由器F0/0同一子网，默认网关设为:202.101.111.1(路由器的以太网口地址).

设置完成后，测试发现：首先，ping 对端主机延时大,一个来回约为690ms。

由于卫星距地面约3.8万公里，信号往返约为3.8 x 4 =15.2 万公里，除以光速 30万公里每秒，约为0.5s，即500ms,所以延时基本正常。呵呵，这样算对吗?

还有一个让用户无法接受的测试结果是：用FTP从对端服务器下载文件，速率只能达到32k/s!

照理说线路的传输速率是2M bps，约等于250k 字节每秒才对，就算减掉协议的损耗，也该有个200k/s吧？

这个问题的揭示更有意思，它让我们发现延时是如何地影响了数据传输的速率。

我们知道FTP基于TCP，TCP在传输数据的时候接收方要进行应答，发送方在发送w个数据包后必须要收到一个应答包表明这些数据包已经送到，才能继续发送。如果线路的传输误码率很低，则w可以增大，反之要减少，这就是窗口机制。

本例中假设因线路质量极好，w达到16,MTU=1500,则发送方发送16 x 1500 = 24000 字节之后等待接收方的一个应答包(更正：Windows值为字节数，即发送n个字节后应等待一个应答，最大值：65535，故在此应为假设w=24000)，忽略建立连接的时间（三步握手建立连就用了 345 ms x 3 = 1035 ms 呢 ）,忽略字节流的传输时间，这24000个字节经过卫星链路到达接收方时花了345ms(690 ms / 2),接收发的应答包在345ms后亦传到了接收方处，则在这次传输中 24000 字节花了 690 ms, 速率为33.97k 字节每秒。

照此计算，在一般局域网中，如果延时为10 ms, 则在同样 n=16 MTU=1500的条件下速率可达2344k 字节每秒。当然，这要求你的线路带宽大于2344k 字节每秒(即18.3M bps)，否则网络将出现阻塞，速度下降。

由于速率只有32k/s，故上述的一个FTP会话其实只占了带宽的大约1/8.如果使用多线程的FTP工具，如netants,由可以充分利用带宽，使下载速度达到200k/s左右,实验证明了这一点。