TCP协议
延迟应答
它也是基于滑动窗口,提高效率的一种机制,结合滑动窗口以及流量控制,能够以延迟应答ACK的方式,把反馈的窗口,搞大.核心在于允许范围内,让窗口尽可能大.
如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小.
典型场景:发送方不停发,接收方不停取
新收到的数据也占一部分空间.如果不是立即返回,比如延时100ms,在100ms之内,接收方应用程序就能再多消费一些数据,剩余的空间就更大,返回的窗口就是一个比较大的值.
一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标就是在保证网络不拥塞的情况下尽可能提高传输效率;
那么所有包都可以延时应答吗?肯定也不是;
具体的数量和超时时间,依操作系统不同也有差异;一般N取2,超时时间取200ms;
捎带应答
尽可能把能合并的数据包合并,从而提高效率的效果.
正常情况下,2和3之间有一定时间间隔,此时就分两个包发送.但是由于延迟应答,ack应答时间有所推迟,ack就可以和response合并.
ack在延时的这段时间里,响应数据刚好准备好了.此时就可以把ack和应答的响应数据合并成一个TCP数据报.本身ack也不携带任何载荷,只是把ACK载荷设置为1,并设置确认序号以及窗口大小.
面向字节流
创建一个TCP的socket,同时在内核中创建一个发送缓冲区和一个接收缓冲区.
由于缓冲区的存在,TCP程序的读和写不需要一一匹配,例如:
粘包问题
在tcp传输的数据到了接收方之后,接收方要根据socket api来read出来.read出来的结果就是应用层数据包.由于整个read过程非常灵活,可能使代码中无法区分出当前的数据从哪到哪是一个完整的数据包.
那么如何避免粘包问题呢?归根结底就是一句话,明确两个包之间的边界.
思考:对于UDP协议来说,是否也存在"粘包问题"呢?
粘包问题,是TCP引起的,但TCP本身并不解决,而是由程序员写代码自行处理(应用层逻辑),xml,json, protobuffer都能处理粘包问题.
异常情况
TCP/UDP对比
我们说TCP是可靠连接,那么是不是TCP一定优于UDP呢?TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较.
归根结底,TCP和UDP都是程序员的工具,什么时候用,具体怎么用,还是根据具体场景判定.
如何用UDP实现可靠传输?
参考TCP可靠性机制,在应用层实现类似逻辑.
例如
