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

5.7tcp的流量控制
这一节，作者为了讲解滑动窗口的作用————流量控制，结果引入一个大bug。
看图5.22:
计算机网络第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连接？

什么时候收到一个包，确认一个，什么时候收到多个包，只确认一个？
看具体实现了。可以找个协议栈代码看下
假如201开头的那个包一直出错，tcp协议栈怎么样处理？
没有 ACK ，反复超时重传。
窗口是有大小的，201 没有 ACK ，传到 401 窗口就满了，不会继续传 501 以后。
而且报文是按照顺序发送！看来得颠覆本人的想法了。
假如没有错误（重传），确实是顺序发送的。
但是要注意，即使没有错误（重传），发送的时候是顺序发送的，接收方也不一定是顺序接收的。
本人没发帖前，本人错误的以为，假如发现一个包出错，那么后面的报文就不会传输，直到解决了这个错误后，再传输后面的报文。
这是可行的，滑动窗口协议可以看做这个的升级版。原因是这样做效率比较低，处理错误的这段时间，网络实际是空闲的，没有数据在传输。
滑动窗口协议实际是利用了处理错误的这段时间，多传了几个后续的包。一旦错误解决，全部已传输的包可以一起 ACK 掉，节省时间。