网络业界

热门软件下载：

我设计了一个tcp/ip协议栈，在实现tcp协议中发现一个问题，当我的设备使用一条低速链路的时候，如果网络速率出现振荡导致丢包，进而触发快速重传和快速恢复，我是按照jacobson   1990b修改方案实现的，由于快速恢复方案将cwnd开的较大（至少3个mss），丢失的数据包被迅速重新发送，这样导致网络带宽被大量的重发包占据，使得链路再次拥塞，再次进入触发快速重传和快速恢复，网络就在这个状态稳定下来，链路上大量的重发包(cwnd稳定在6个mss左右,   ssthresh在3个mss左右)。  
  我想了解：  
  1.怎样避免以上问题  
  2.是不是快速重传再为收到有效ack时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的  
  3.快速恢复重发包是重发三次ack后紧接的数据包，还是重新发送所有的（窗口允许发送的数据），如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢

推荐阅读

快速恢复方案将cwnd开的较大？？？  
  答：  
  这应该没有问题，因为快速恢复要的就是大cwnd值，否则就是慢启动了！在收到三个重复的ack后会触发快速重传并启动快速恢复，但在重传数据报的时候慢启动门限最小是二个mss值，并且cwnd的值是一个mss，在调用完tcp_output重传丢失数据报后，才将cwnd增大到“慢启动门限＋重复ack个数*mss”的大小！  
   
  丢失的数据包被迅速重新发送，这样导致网络带宽被大量的重发包占据？？？？？？？  
  答：丢失的数据包就发送一次，以后如果收到相同的重复的ack则只是增加cwnd的值而己  
   
  是不是快速重传再为收到有效ack时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的  
  答：可以继续发送数据，只要对方的窗口是打开的就会发送数据。否则要滑动窗做什么？  
   
  快速恢复重发包是重发三次ack后紧接的数据包，还是重新发送所有的，如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢  
  答：只发送三次ack后紧接的数据包，对方一定缓存后续的未确认的数据。tcp有重装队列  
   
  爽～～好久没有这么专业的帖子，呵呵……  
   
 

嘿嘿  
  同意楼上

实话实说，tiro的做法：缩小一个报文段大小的拥塞窗口对稳定网络传输的帮助不大，这种局部的调整所带来的性能的改变很小。你需要统计测量一下。不过楼主的帖子在csdn里已经很少见了！！！佩服！  
   
          我已经将openbsd的协议栈移到了自己的操作系统上了，下一步准备写一个web   client，但是我对http的工作原理不是很了解，如果楼主有时间，可以给点建议或者好的联接？  
   
  多谢！！！