作者回复: 哈哈,研究性质的算法,应该还不错吧,不知道什么时候可以实际使用
作者回复: 你说的不错,一般我们只在合并缓冲区的时候才需要,绝大多数都是使用write和send 。
作者回复: 赞
作者回复: 我觉得这个问题不愚钝。
每个包都有一个序列号,通过序列号按顺序就可以还原这个数据流;这个数据流本身也有例如checksum,序号大小等数据,这个数据流所有序列号的包都收到了,就可以完成数据流的拼装了。
解决粘包问题的关键是区分出数据的边界,我在第16降:如何理解TCP的“流”里讲到了这部分内容,你可以参考一下。
作者回复: Google出品,名声不小。
作者回复: 这是为了加速下载的时间,说白了就是抢带宽。
作者回复: 嗯,我也是刚知道这个算法。
作者回复: 协议栈实现的时候有默认值,而且算法可以动态调整;另外,也可以自己调用套接字接口函数来设置,不过一般不建议这么做。
作者回复: 是的,本来想打印出这个n的。
作者回复: 是的,基于同一个目的地址。这里是说为了提高网络利用率,不能无限制的发送小数据包,也就是说,多个小数据包会在合适的时机合并成一个大的数据包发送出去。你的理解是相反的?
作者回复: 需要等到发现窗口和拥塞窗口都要超过100才可以,发送窗口是在ACK返回时根据一定的算法更新的,一旦更新就会影响发送端的行为。
作者回复: 确实是两路不同的实现,但是我不理解为什么文件写需要缓冲区满才进行呢?应该会合并写入,但是不一定需要缓冲区满吧。
作者回复: 我个人觉得不会,应该是拆分成MSS大小的包,否则会浪费带宽。
作者回复: 当然有的。
作者回复: 是的。
作者回复: 不是原子操作,不过建议还是单线程来处理一个socket,因为加锁的读写操作太重了。
作者回复: 当然,我们决定不了发包的次数。只不过合并写的方式,让操作系统可以一次性发送出去的几率更大。
作者回复: TCP在收到乱序到达包会立即发送ACK,TCP利用3个相同的ACK来判定数据包的丢失,进行快速重传,以便让对方能在较短的时间内接受到丢失的包,本质上是一种通过"弥补"机制保证拥塞控制能完成。