4,356
社区成员
发帖
与我相关
我的任务
分享精通TCP/IP协议的请进
我设计了一个TCP/IP协议栈，在实现TCP协议中发现一个问题，当我的设备使用一条低速链路的时候，如果网络速率出现振荡导致丢包，进而触发快速重传和快速恢复，我是按照Jacobson 1990b修改方案实现的，由于快速恢复方案将cwnd开的较大（至少3个MSS），丢失的数据包被迅速重新发送，这样导致网络带宽被大量的重发包占据，使得链路再次拥塞，再次进入触发快速重传和快速恢复，网络就在这个状态稳定下来，链路上大量的重发包(cwnd稳定在6个MSS左右, ssthresh在3个MSS左右)。
我想了解：
1.怎样避免以上问题
2.是不是快速重传再为收到有效ACK时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的
3.快速恢复重发包是重发三次ACK后紧接的数据包，还是重新发送所有的（窗口允许发送的数据），如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢
我想了解：
1.怎样避免以上问题
2.是不是快速重传再为收到有效ACK时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的
3.快速恢复重发包是重发三次ACK后紧接的数据包，还是重新发送所有的（窗口允许发送的数据），如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢
...全文
请发表友善的回复…
发表回复
ejiue 2003-09-06
- 打赏
- 举报
mark
dash 2003-07-25
- 打赏
- 举报
好贴，收藏。
cai3995 2003-05-09
- 打赏
- 举报
嘿嘿
同意楼上
同意楼上
Tiro 2003-05-09
- 打赏
- 举报
我找出代码中的问题，我是在PowerPC的做的，我的驱动程序数据发送队列长度有限，TxBD表上实现过程中存在一些问题，就是当网络拥塞时，三层无法将数据置入TxBD发送队列，数据被错误的丢弃，所以这样被丢弃的往往是重发包，导致对方仍然没有收到重发数据，当然就会不断的重复同一ack,网络上就有大量的重发包，为了减轻这种情况我才从第四个重复ACK后每收到一个重复ACK就减小一个MSS，这样表面上是缓解了问题，实际上并没有解决，明天我修改程序后再看一看。
To johnsonest我没有在底层做过webbrowser，很抱歉，不知道到你在什么系统上实现？
To johnsonest我没有在底层做过webbrowser，很抱歉，不知道到你在什么系统上实现？
ShareTool 2003-05-09
- 打赏
- 举报
up 虽然有点麻木
jigsawpuzzle 2003-05-09
- 打赏
- 举报
我想追求最大吞吐量和追求平稳流量两者应该是一样的，因为当前时刻的流量
首先己经确定了。在重传的数据包没有到达接收方并接收到此报文的ACK回复时，
发送端应该还会接二连三的收到重复的ACK数据包。因为到达对端失序报文>=4
个的情况很常见（这和MSS、带宽、通告窗口、RTT等情况应该是相关的），所以
从第四个重复ACK后每收到一个重复ACK就减小一个MSS，最终将陷入慢启动状态。
和快速重传、快速恢复的大算法就偏离了
欢迎大家讨论～
讨论这种技术帖可以提高理论知识，看帖的兄弟们也up一下啊～！
首先己经确定了。在重传的数据包没有到达接收方并接收到此报文的ACK回复时，
发送端应该还会接二连三的收到重复的ACK数据包。因为到达对端失序报文>=4
个的情况很常见（这和MSS、带宽、通告窗口、RTT等情况应该是相关的），所以
从第四个重复ACK后每收到一个重复ACK就减小一个MSS，最终将陷入慢启动状态。
和快速重传、快速恢复的大算法就偏离了
欢迎大家讨论～
讨论这种技术帖可以提高理论知识，看帖的兄弟们也up一下啊～！
johnsonest 2003-05-09
- 打赏
- 举报
to jigsawpuzzle:
我懂你的意思，收到第四个重复的ACK时，说明新的分组已经离开了网络。教好的实现是静静的把ACK丢弃，至于是否要增加拥塞窗口，要看追求的什么：如果追求最大吞吐量，当然是增加窗口了，但是楼主已经说明想平稳流量，所以我觉得楼主的做法也没有什么不可。
我之所以说对平稳流量作用不大，是因为楼主的这点改进毕竟是在快速重传和快速恢复的大算法下做的小改动。
欢迎继续讨论。
哪位大哥能给我画一个webbrowser的架构图，并大致讲讲原理，不胜感激！！！
我懂你的意思，收到第四个重复的ACK时，说明新的分组已经离开了网络。教好的实现是静静的把ACK丢弃，至于是否要增加拥塞窗口，要看追求的什么：如果追求最大吞吐量，当然是增加窗口了，但是楼主已经说明想平稳流量，所以我觉得楼主的做法也没有什么不可。
我之所以说对平稳流量作用不大，是因为楼主的这点改进毕竟是在快速重传和快速恢复的大算法下做的小改动。
欢迎继续讨论。
哪位大哥能给我画一个webbrowser的架构图，并大致讲讲原理，不胜感激！！！
jigsawpuzzle 2003-05-09
- 打赏
- 举报
to Tiro: 你说：“如果继续收到相同的ack后，我将窗口缩小一个mss”???
你把哪个窗口缩小了？通告的接收窗口吗？这是违反RFC规则的～
如果是cwnd就更不应该了，因为接收一个相同的ack说明网络有可能变的不拥塞了，所以正是加大cwnd的时候！
to johnsonest: 缩小一个报文段大小的拥塞窗口对稳定网络传输的帮助不但不大,反而是有害的！！！量三思～
你把哪个窗口缩小了？通告的接收窗口吗？这是违反RFC规则的～
如果是cwnd就更不应该了，因为接收一个相同的ack说明网络有可能变的不拥塞了，所以正是加大cwnd的时候！
to johnsonest: 缩小一个报文段大小的拥塞窗口对稳定网络传输的帮助不但不大,反而是有害的！！！量三思～
Tiro 2003-05-09
- 打赏
- 举报
我写的是Web Server,对它我不太满意，打算有时间重新写一遍，因为这个http把网页和脚本做到协议中去了，这样非常不好，我打算采用文件系统和类似PHP的WEB脚本解释器，用FLASH作为存储介质，用FTP,TFTP,WEB或者NFS来更新网页和脚本文件。
我的mail是:feibaoli@yahoo.com.cn，非常愿意同大家交流问题。
我的mail是:feibaoli@yahoo.com.cn，非常愿意同大家交流问题。
johnsonest 2003-05-09
- 打赏
- 举报
实话实说，TIRO的做法：缩小一个报文段大小的拥塞窗口对稳定网络传输的帮助不大，这种局部的调整所带来的性能的改变很小。你需要统计测量一下。不过楼主的帖子在CSDN里已经很少见了！！！佩服！
我已经将openBSD的协议栈移到了自己的操作系统上了，下一步准备写一个web client，但是我对http的工作原理不是很了解，如果楼主有时间，可以给点建议或者好的联接？
多谢！！！
我已经将openBSD的协议栈移到了自己的操作系统上了，下一步准备写一个web client，但是我对http的工作原理不是很了解，如果楼主有时间，可以给点建议或者好的联接？
多谢！！！
Tiro 2003-05-09
- 打赏
- 举报
谢谢各位！问题我已经基本解决，主要出在底层驱动接口数据队列过短，当网络拥塞时，一部分数据包被丢弃，导致大量重发。
为了加速退避速度，我在收到3次ack后进行快速重传和快速恢复，如果继续收到相同的ack后，我将窗口缩小一个mss,同时保证cwnd至少为一个mss，这样的目的为了使我的程序在网络带宽发生很大变化时能够迅速稳定下来，同时也不想丢失快速恢复的特性。这样改动后发现如果网络上还有另外一个TCP(单TCP连接的网络蚂蚁)，稳定后总带宽被我的TCP占用了1/3，网络蚂蚁占了2/3，不知道这样是否合理，有没有什么隐患？
我在开发一个协议栈，目前写了IP,ARP,ICMP,UDP,TCP,RIP,PPP,PPPoE,RADIUS,TFTP,HTTP,TELNET，任务的调度，定时器，内存管理，SOCKET接口等
还计划写一个文件系统，NAT,DHCP,OSPF,NFS,IGMP,L2TP,RTP,RTCP,FTP，SMTP,POP3,SNMP,简单的WEB脚本的解释器等，希望大家多提建议和意见。
再一次谢谢大家！
为了加速退避速度，我在收到3次ack后进行快速重传和快速恢复，如果继续收到相同的ack后，我将窗口缩小一个mss,同时保证cwnd至少为一个mss，这样的目的为了使我的程序在网络带宽发生很大变化时能够迅速稳定下来，同时也不想丢失快速恢复的特性。这样改动后发现如果网络上还有另外一个TCP(单TCP连接的网络蚂蚁)，稳定后总带宽被我的TCP占用了1/3，网络蚂蚁占了2/3，不知道这样是否合理，有没有什么隐患？
我在开发一个协议栈，目前写了IP,ARP,ICMP,UDP,TCP,RIP,PPP,PPPoE,RADIUS,TFTP,HTTP,TELNET，任务的调度，定时器，内存管理，SOCKET接口等
还计划写一个文件系统，NAT,DHCP,OSPF,NFS,IGMP,L2TP,RTP,RTCP,FTP，SMTP,POP3,SNMP,简单的WEB脚本的解释器等，希望大家多提建议和意见。
再一次谢谢大家！
jigsawpuzzle 2003-05-08
- 打赏
- 举报
快速恢复方案将cwnd开的较大（至少3个MSS）？？？
答：
这应该没有问题，因为快速恢复要的就是大cwnd值，否则就是慢启动了！在收到三个重复的ACK后会触发快速重传并启动快速恢复，但在重传数据报的时候慢启动门限最小是二个MSS值，并且cwnd的值是一个MSS，在调用完tcp_output重传丢失数据报后，才将cwnd增大到“慢启动门限＋重复ACK个数*MSS”的大小（应该大于5个MSS的大小？？）！
丢失的数据包被迅速重新发送，这样导致网络带宽被大量的重发包占据？？？？？？？
答：丢失的数据包就发送一次，以后如果收到相同的重复的ACK则只是增加cwnd的值而己（并调用tcp_output函数，但绝对不会重传数据）
是不是快速重传再为收到有效ACK时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的
答：可以继续发送数据，只要对方的窗口是打开的就会发送数据。否则要滑动窗做什么？
快速恢复重发包是重发三次ACK后紧接的数据包，还是重新发送所有的（窗口允许发送的数据），如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢
答：只发送三次ACK后紧接的数据包，对方一定缓存后续的未确认的数据。TCP有重装队列
爽～～好久没有这么专业的帖子，呵呵……
答：
这应该没有问题，因为快速恢复要的就是大cwnd值，否则就是慢启动了！在收到三个重复的ACK后会触发快速重传并启动快速恢复，但在重传数据报的时候慢启动门限最小是二个MSS值，并且cwnd的值是一个MSS，在调用完tcp_output重传丢失数据报后，才将cwnd增大到“慢启动门限＋重复ACK个数*MSS”的大小（应该大于5个MSS的大小？？）！
丢失的数据包被迅速重新发送，这样导致网络带宽被大量的重发包占据？？？？？？？
答：丢失的数据包就发送一次，以后如果收到相同的重复的ACK则只是增加cwnd的值而己（并调用tcp_output函数，但绝对不会重传数据）
是不是快速重传再为收到有效ACK时，不发送新的数据，这样可能避免以上问题，但是会不会降低效率，失去快速恢复的目的
答：可以继续发送数据，只要对方的窗口是打开的就会发送数据。否则要滑动窗做什么？
快速恢复重发包是重发三次ACK后紧接的数据包，还是重新发送所有的（窗口允许发送的数据），如果只发送紧接的数据包，对方有没有可能不缓存后续未确认的数据，这样会使得恢复过程非常缓慢
答：只发送三次ACK后紧接的数据包，对方一定缓存后续的未确认的数据。TCP有重装队列
爽～～好久没有这么专业的帖子，呵呵……
Tiro 2003-05-08
- 打赏
- 举报
?
