TCP拥塞窗口大小:奇怪的行为

我正在使用Netkit使用各种TCP算法。 有两台机器,c1和c2,由一台强制200ms延迟的路由器连接。 c1上的程序每1ms向c2发送100字节的数据包(TCP_NODELAY打开)。 Reno用作两台机器上的拥塞控制。 根据tcpdump,只有前2个数据包立即发送(200个字节),然后c1停止发送并等待ACK。接收器的窗口大约是2MSS(MSS = 1460),所以我猜它是阻止c1发送更多数据包的CWND。 根据Reno规范,初始CWND为1MSS。我在那里遗漏了什么?甚至发送1字节的数据包给出了相同的图片,发送了2个数据包,然后发送者等待ACK。可能是初始CWND大小是由初始段大小决定的,而不是MSS?
ip route show cache
表示类似的东西
cache mtu 1500 rtt 361ms rttvar 360ms cwnd 5 advmss 1460 hoplimit 64
我想知道这是否意味着CWND = 5MSS?     
已邀请:
来自RFC 2581   IW,cwnd的初始值,必须是   小于或等于2 * SMSS字节   并且不得超过2段。      我们注意到一个非标准的,   实验TCP扩展允许   TCP可以使用更大的初始值   窗口(IW),如等式1中所定义   [AFP98]:
  IW = min (4*SMSS, max (2*SMSS, 4380 bytes))           (1)
     使用此扩展,TCP发送方   可以使用3或4段初始   窗口,提供的组合大小   细分不超过4380   字节。我们不允许这种改变   标准的一部分定义   这个文件。但是,我们包括   在其余部分讨论(1)   本文件的指南   那些试验的人   改变,而不是符合   目前的TCP标准   拥堵控制。      SENDER MAXIMUM SEGMENT SIZE(SMSS):   SMSS的大小         发件人可以传输的最大段。这个值可以         基于网络的最大传输单位,   路径         MTU发现[MD90]算法,RMSS(参见下一项)或其他         因素。大小不包括TCP / IP标头和         选项。 您可能想要检查您的实现如何计算SMSS。     
据我所知,在这种情况下,Linux会测量“段”中的cwnd - 所以只要你发送了两个段进行飞行,那么你的cwnd就会关闭以获取新数据。     
初始窗口为2.它不是1的原因与延迟的ack有关。接收器通常在发送ack之前等待两个数据包。如果初始窗口为1,则ack将在默认时间之后发送,该默认时间通常远大于必要的时间。这增加了不必要的延迟和混乱时钟的混乱。     

要回复问题请先登录注册