网络原理-TCP/IP(5)

绝地灬酷狼 2024-04-06 15:17 51阅读 0赞

## TCP协议 ##

### 延迟应答 ###

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

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

> 1.假设接收端缓冲区为1M.一次收到了500K的数据;如果立刻应答,返回的窗口就是500K;
> 
> 2.但实际上可能处理端处理的速度很快1,10ms之内就把500K数据从缓冲区消费掉了;
> 
> 3.在这种情况下,接收端处理还远没有到达自己的极限,即使窗口再放大一些,也能处理的过来;
> 
> 4.如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口就是1M;
> 
> **简而言之:接受方收到数据之后,不会立即返回ACK.而是稍等一下,等一会再返回ACK.等的这一会,相当于给接收方的应用程序这里,腾出更多的时间,来消费这里的数据.**

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

![61d88209297b4985a098ff5bc17f97de.png][]

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

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

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

> 数量限制:每隔N个包就应答一次;
> 
> 时间限制:超过最大延迟时间就应答一次;

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

![f128e8e280ae48f798b7b3036919c79f.png][]

### 捎带应答 ###

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

> 在延迟应答的基础上,我们发现,很多情况下,客户端服务器在应用层也是"一发一收"的.意味着客户端给服务器说了"How are you",服务器也会给客户端回一个"Fine, thank you";
> 
> 那么这个时候ACK就可以搭顺风车,和服务器回应的"Fine, thank you"一起给回客户端.

![8ce9cd34b091489fa9a9ac5b9631024d.png][]

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

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

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

![f92ee43858a94953ae2ff7a266a3c36c.png][]

### 面向字节流 ###

创建一个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是一个一个报文过来的,按照序号排好放在缓冲区中;
> 
> 站在应用层的角度,看到的只是一串连续的字节数据;
> 
> **那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分到哪个部分,是一个完整的应用层数据包**;

![4e8bd3532b8543749e92e9fa37b59f74.png][]

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

> 对于定长的包,保证每次都按固定的大小读取即可;例如上面的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也是如此,接收方一段时间之后,没有收到对方的消息,就会触发"心跳包"来询问对方情况
> 
> 如果对端没心跳了,此时本端也就会尝试复位并且单方面释放连接了.

### TCP/UDP对比 ###

我们说TCP是可靠连接,那么是不是TCP一定优于UDP呢?TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较.

> TCP用于可靠传输的场景,应用于文件传输,重要状态更新,数据包很大的传输;(绝大部分场景)
> 
> UDP用于高速传输和实时性要求较高的通信领域,例如,早期的QQ,视频传输等.另外UDP可以用于广播;(对于效率要求很高,但对于可靠性不高).

**归根结底,TCP和UDP都是程序员的工具,什么时候用,具体怎么用,还是根据具体场景判定**.

**如何用UDP实现可靠传输?**

参考TCP可靠性机制,在应用层实现类似逻辑.

例如

> 引入序列号,保证数据顺序;
> 
> 引入确认应答,确保对端收到了数据;
> 
> 引入超时重传,如果隔一段时间没有应答,就重发数据.

[61d88209297b4985a098ff5bc17f97de.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/02ac712870f34d7a9fefc6c865569ac6.png
[f128e8e280ae48f798b7b3036919c79f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/e511a54825784712a3e2ed6a73b9d74d.png
[8ce9cd34b091489fa9a9ac5b9631024d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/40018d80b1324be4be26639f6a10ce48.png
[f92ee43858a94953ae2ff7a266a3c36c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/e3d6e226c3dd4ec58a73fc3086d4821b.png
[4e8bd3532b8543749e92e9fa37b59f74.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/4076c44989c14ad0b76432fe643733da.png