网络原理-TCP/IP(5)

TCP协议

延迟应答

它也是基于滑动窗口,提高效率的一种机制,结合滑动窗口以及流量控制,能够以延迟应答ACK的方式,把反馈的窗口,搞大.核心在于允许范围内,让窗口尽可能大.

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小.

1.假设接收端缓冲区为1M.一次收到了500K的数据;如果立刻应答,返回的窗口就是500K;

2.但实际上可能处理端处理的速度很快1,10ms之内就把500K数据从缓冲区消费掉了;

3.在这种情况下,接收端处理还远没有到达自己的极限,即使窗口再放大一些,也能处理的过来;

4.如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口就是1M;

简而言之:接受方收到数据之后,不会立即返回ACK.而是稍等一下,等一会再返回ACK.等的这一会,相当于给接收方的应用程序这里,腾出更多的时间,来消费这里的数据.

典型场景:发送方不停发,接收方不停取

新收到的数据也占一部分空间.如果不是立即返回,比如延时100ms,在100ms之内,接收方应用程序就能再多消费一些数据,剩余的空间就更大,返回的窗口就是一个比较大的值.

一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标就是在保证网络不拥塞的情况下尽可能提高传输效率;

那么所有包都可以延时应答吗?肯定也不是;

数量限制:每隔N个包就应答一次;

时间限制:超过最大延迟时间就应答一次;

具体的数量和超时时间,依操作系统不同也有差异;一般N取2,超时时间取200ms;

捎带应答

尽可能把能合并的数据包合并,从而提高效率的效果.

在延迟应答的基础上,我们发现,很多情况下,客户端服务器在应用层也是"一发一收"的.意味着客户端给服务器说了"How are you",服务器也会给客户端回一个"Fine, thank you";

那么这个时候ACK就可以搭顺风车,和服务器回应的"Fine, thank you"一起给回客户端.

正常情况下,2和3之间有一定时间间隔,此时就分两个包发送.但是由于延迟应答,ack应答时间有所推迟,ack就可以和response合并.

ack在延时的这段时间里,响应数据刚好准备好了.此时就可以把ack和应答的响应数据合并成一个TCP数据报.本身ack也不携带任何载荷,只是把ACK载荷设置为1,并设置确认序号以及窗口大小.

注意!很多时候客户端和服务端之间是长连接,要进行若干次请求的.在捎带应答的加持下,在捎带应答的加持下,后续每次传输请求响应,都可能触发捎带应答(也不是一定触发,具体是否能触发,取决于代码怎么写,取决于下一个数据来的快不快),都可能把接下来的数据和ack合二为一.

面向字节流

创建一个TCP的socket,同时在内核中创建一个发送缓冲区和一个接收缓冲区.

调用write时,数据会先写入发送缓冲区中;

如果发送的字节数太长,会被拆分成多个TCP的数据包发出;

如果发送的字节太短,就会先在缓冲区中等待,等到缓冲区长度差不多了,或者其他合适的时机发送出去;

接收数据的时候,数据也是从网卡的驱动程序到达内核的接收缓冲区;

然后应用程序可以调用read从接收缓冲区拿数据;

另一方面,TCP的一个连接,既有发送缓冲区,也有接收缓冲区,那么对于一个连接,既可以读数据,也可以写数据,这个概念叫全双工;

由于缓冲区的存在,TCP程序的读和写不需要一一匹配,例如:

写100个字节数据时,可以调用一次write写100个字节,也可以调用100个write,每次写一个字节;

读100个字节数据时,也完全不需要考虑写的时候是怎么写的,既可以一次read100个字节,也可以一次read一个字节,重复100次;

粘包问题

在tcp传输的数据到了接收方之后,接收方要根据socket api来read出来.read出来的结果就是应用层数据包.由于整个read过程非常灵活,可能使代码中无法区分出当前的数据从哪到哪是一个完整的数据包.

首先要明确,粘包问题中的"包",是指应用层的数据包;

在TCP协议头中,没有如同UDP一样的"报文长度"这样的字段,但是有一个序号这样的字段;

站在传输层的角度上,TCP是一个一个报文过来的,按照序号排好放在缓冲区中;

站在应用层的角度,看到的只是一串连续的字节数据;

那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分到哪个部分,是一个完整的应用层数据包;

那么如何避免粘包问题呢?归根结底就是一句话,明确两个包之间的边界.

对于定长的包,保证每次都按固定的大小读取即可;例如上面的Request结构,是固定大小,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;

对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包结束的位置;

对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序员自己来定的,只要保证分隔符不和正文冲突即可);

思考:对于UDP协议来说,是否也存在"粘包问题"呢?

对于UDP,如果还没有上层交付数据,UDP报文长度仍然存在.同时,UDP是一个一个把数据交付给应用层.就有很明确的数据边界.

站在应用层的角度,使用UDP的时候,要么收到完整的UDP报文,要么不收.不会出现"半个"的情况.

UDP的接收缓冲区不是队列结构,而是链表,每一个结点都是一个UDP数据报.

粘包问题,是TCP引起的,但TCP本身并不解决,而是由程序员写代码自行处理(应用层逻辑),xml,json, protobuffer都能处理粘包问题.

异常情况

进程终止:进程终止会导致释放文件操作符,仍然可以发送FIN,和正常关闭没有什么区别.(进程无论是正常结束,还是异常崩溃,都会触发到回收文件资源,关闭文件这样的效果(系统自动完成的),就会触发四次挥手)

TCP连接的生命周期,可以比进程更长一些.虽然进程已经退出了,但是TCP连接还在,仍然可以继续进行四次挥手.

其中一方机器关机(按照正常流程关机):当有个主机,触发关机操作,就会先强制终止所有的进程(类似于上述的强杀进程),终止进程自然会触发四次挥手~

点了关机之后,此时,四次挥手不一定能挥完,因为系统马上就关闭了.如果挥的快,就能够顺利挥完,此时,本端和对端都能正确删除保存的连接信息.(四次挥手的核心流程)

如果挥的不快,至少也能把第一个FIN发给对端,至少能告诉对方,我这边要结束了.

对端收到FIN之后,对端也要进入释放连接的流程了,返回ACK,并且也发FIN.这里的FIN不会有ACK了,FIN没收到ACK时,势必要进行重传(超时重传的流程中了).

当重传几次后,发现还是不行,还是没有ACK,这个时候就会单方面释放连接信息.

其中一方出现了断电(也算关机,更突然的关机):

(a):断电的是接收方:发送方就会突然发现,没有ACK了,就要重传.重传了几次后,还是不行.

TCP就会尝试复位连接.相当于清除原来的TCP中的各种临时数据重新开始.

需要利用到TCP的"复位报文段"(RST). 但此时的RST也不会有ACK.重置了还不行,单方面放弃连接.

(b):断电的是发送方:这个情况下,接收方需要区分出,发送方是挂了,还是好着暂时没发.

TCP也是如此,接收方一段时间之后,没有收到对方的消息,就会触发"心跳包"来询问对方情况

如果对端没心跳了,此时本端也就会尝试复位并且单方面释放连接了.