计算机网络第5版上——滑动窗口的讲解有个巨大的bug,为什么还有人在看?

C++语言 码拜 4年前 (2016-01-30) 141次浏览
5.7tcp的流量控制
这一节,作者为了讲解滑动窗口的作用————流量控制,结果引入一个大bug。
看图5.22:
计算机网络第5版上——滑动窗口的讲解有个巨大的bug,为什么还有人在看?
计算机网络第5版上——滑动窗口的讲解有个巨大的bug,为什么还有人在看?
计算机网络第5版上——滑动窗口的讲解有个巨大的bug,为什么还有人在看?
A 和B 建立tcp连接后, B 告诉A 其滑动窗口的大小是400(rwnd = 400),
发送1-100字节后,B 居然没有ack应答, A还继续发送101-200, b 依然没有应答。
然后呢, A发送第201个字节开始的报文的时候,丢失,
很搞笑的是,图中终于了应答了,然后呢,继续发送301, 401, 201。
本人靠, 201开头的报文就出错了,A 居然还继续发送301, 401。 尼玛你就不怕乱序乎?

顺便讨教第2个问题:
进程1和进程2的 (soure ip, dest ip, source port, dest port)都相同, dest port , source port都设置过了 端口复用。
问一下是几条tcp连接?
解决方案:38分
什么时候 收到一个包,确认一个,什么时候收到多个包,只确认一个?
看具体实现了。可以找个协议栈代码看下
假如201开头的那个包一直出错,tcp协议栈怎么样处理?
没有 ACK ,反复超时重传。
窗口是有大小的,201 没有 ACK ,传到 401 窗口就满了,不会继续传 501 以后。
而且报文是按照顺序发送! 看来得颠覆本人的想法了。
假如没有错误(重传),确实是顺序发送的。
但是要注意,即使没有错误(重传),发送的时候是顺序发送的,接收方也不一定是顺序接收的。
本人没发帖前,本人错误的以为,假如发现一个包出错,那么后面的报文就不会传输,直到解决了这个错误后,再传输后面的报文。
这是可行的,滑动窗口协议可以看做这个的升级版。原因是这样做效率比较低,处理错误的这段时间,网络实际是空闲的,没有数据在传输。
滑动窗口协议实际是利用了处理错误的这段时间,多传了几个后续的包。一旦错误解决,全部已传输的包可以一起 ACK 掉,节省时间。

CodeBye 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权 , 转载请注明计算机网络第5版上——滑动窗口的讲解有个巨大的bug,为什么还有人在看?
喜欢 (0)
[1034331897@qq.com]
分享 (0)