网络原理(3):三次握手四次挥手滑动窗口与丢包

最新推荐文章于 2024-11-13 22:18:25 发布

DJ懒羊羊。

最新推荐文章于 2024-11-13 22:18:25 发布

阅读量413

点赞数 9

分类专栏：网络编程文章标签：网络服务器运维

本文链接：https://blog.csdn.net/weixin_65492194/article/details/132626841

版权

网络编程专栏收录该内容

11 篇文章 0 订阅

订阅专栏

我在csdn等你!!!

一:TCP

1:连接层管理

1:三次握手

1:意义

①: 三次握手,也是一种保证可靠性的机制."投石问路".TCP三次握手,就是要验证网络通信是否畅通,以及验证每个主机的发送和接收能力是否正常.恰好三次握手,就能验证双方的发送和接收能力是否正常.

为了帮助大家更好的理解,举个栗子:

在这个栗子中:麦克风:发送能力.耳机:接收能力====>通过三次握手,是进行可靠传输的前提条件.

2:三次握手的作用

三次握手,还能起到,"消息协商"这样的效果.

通信的时候会涉及到一些参数,需要双方保持一致.通过协商,来确定具体的参数是多少!!!

举个栗子:

你和你女朋友结婚的时候,办酒席,摆多少桌?

一场结婚酒席,包含两类人:婆家娘家

2:断开连接

1:四次挥手

四次挥手示意图:

将由服务器发出的ACK和FIN合并成一项可以吗?或者将四次挥手可以改成三次可以吗?

四次挥手有的时候可以改成三次,有的时候不能改.

原因:

FIN的触发,是由应用程序代码控制的===>调用socket.close()来进行触发的,

如果close触发的慢,那么无法和内核控制的ack进行合并.那么,此时就是四次挥手

如果close触发的快,那么就可以和内核控制的ack进行合并.那么,此时就是三次挥手

即;两个步骤能否合并取决于close的执行快慢.

2:两个问题

a:如果服务器,始终不进行close,会怎么样?客户端的连接就始终不关闭吗?

客户端给服务器发送过去了FIN(在内核中完成),此时服务器收到了,在内核中触发了ack,ack为1,此时,服务器始终不进行close,会怎么样?客户端的连接始终不关闭吗?

原因:

情况1:

客户端给服务器发送FIN,服务器端的内核会立即向客户端发送ACK(在内核中完成),服务器端没有进行close操作,那么服务器端就会进入close_wait状态,当发送成功后,便会进入last_ack状态.

站在服务器的角度来看,此时,客户端已经删除了服务器端的信息,即使服务器不进行close操作,这个连接也不能使用了.

针对服务器端的socket进行读操作:

a:如果还没有读完(即缓冲区里面还有数据),可以正常读

b:如果已经读完了,由于TCP协议是面向字节流的,此时,(EOP为-1,hasNext为false)

针对服务器端的socket进行写操作:

无法进行写操作,此时便会直接报出异常.(客户端没有服务器端的连接,此时服务器端的socket进行写操作,将其当做响应传递给客户端,但没有办法找到响应的客户端,此时,便会抛出异常)

综上所述,此时这个连接就是废人一个.

情况2:

更极端的情况,close忘记写了,此时,客户端一直等待服务器的close,却一直没有等到,客户端便会单方面删除服务器端的连接)

b:如果通信过程中,出现丢包了,又怎样处理?

原因:

第一组的FIN/ACK丢失了,可以让其客户端进行重传

第二组的FIN/ACK丢失了:

如果第二组的ACK丢失了,让B进行重传FIN即可,但是当第二组的ack,即A向B发送ACK时,ack丢失了,此时B没有收到A的ack消息,B就会重新将FIN传递给A,(在此过程中,由于A将自己和B的连接给删除了),导致B的FIN传不到A里面去,那么,B就永远也收不到A的ack了

为了解决这一问题,A在发送出去最后一个ACK时,便会等一会(A的等待时间,网络上任意两点之间传输时间的最大时间*2),万一B没有收到,此时就可以等B再重新发送FIN ,直到B接收到由A发送的应答报文(ack).这样,A就可以释放连接了.

MSL:存活时间,理论啊上拍脑门拍出来的时间,这个时间是s/ms

3:TCP是如何可靠传输的?

1:确认应答=====>可靠性传输的核心

2:超时重传

3:连接管理(三次握手,四次挥手)

4:滑动窗口

提高传输效率(更正确的说,是让TCP在可靠传输的前提下,效率不要太拉胯)

使用滑动窗口,不能使TCP变的比UDP快,只能说缩小两个的速度差距

无滑动窗口:将大量的时间用在等待ack上

有滑动窗口:"一次等待时间"等三个ack.

注意:

1:窗口越大,批量发送的数据也就越大,运行效率更高

2:窗口也不能无限大,相当于批量发送的数据无限多,此时,便会接近udp协议,所以窗口不能无限大另一方面,如果窗口无限大,接收方能不能处理过来,中间的设备能不能承受的住!!!都是未知数.

滑动窗口图例:

如上图:主机A给主机B发送数据,1001-5000的数据

数据如下:

1001-2000 2001-3000 3001-4000 4001-5000

当B接收到A的数据后,B就会给A返回上述四组数据所对应的ACK.

当A收到2001的ack之后,A就会向B传输5001-6000这个数据,

A向B发送的数据就会变成如下的样子:

2001-3000 3001-4000 4001-5000 5001-6000

我们会发现,当一个ack传完之后,会将已经传完的ack进行过滤掉,往后再移动一个格子.类似于滑动一样.

滑动窗口批量传输数据时,发送丢包,该怎么办?

情况1:数据包丢了

一旦丢失的数据报被补上了,此时,1001-2000后面的数据都不必重新传输了(都在缓冲区待着呢)====>此时,就完成了重传的过程.这个过程,只是把丢失的数据进行重传了===>快速重传(超时重传+滑动窗口)

情况2:ack丢了

如上图所示:ack丢了,不用做任何处理!!!

原因:

1001的ack丢了,但2001的ack传递过去了,在前面我们学习的过程中.2001代表2001之前的数据都被传递过去了即包含(1-2000)的数据,换句话说,包含1001的ack.

5:流量机制

流量控制:实际上为了给滑动窗口的窗口大小做限制(如果滑动窗口窗口过大,会导致接收方接收不过来,中间链路处理不过来)

以上图为例:

主机A 给主机B的内核态发送数据,内核将发送的数据存储在接收缓冲区.

假设:A生产速度很快,B这边的消费速度跟不上,那么,就会导致接收缓冲区的数据越来越多, 最终就满了,此时,剩余的传过来的数据便会被丢包

流量控制怎样解决?

流量控制会根据接收方的内核中的接收缓冲区剩余大小作为主机A给主机B传输数据的速度大小的依据,当接收缓冲区剩余的空间越大,那么,应用程序消费的数据也就越大.同时主机B便会将剩余缓冲区的空间当做ack发送给主机A,作为发送方下一次的数据,窗口大小.

如上图所示:流量控制可以控制滑动的大小.

假设滑动窗口默认是4000,刚开始主机A已经给主机B发送了1000大小的数据,相当于剩下3000的接收缓冲区.那么,此时主机A连续主机B发了3000大小的数据,此时,主机B还没有来得急处理从主机A的3000大小的数据,但此时主机B的接收缓冲区大小已经满了.相当于剩余缓冲区为0.

主机B就不会接收从主机A传来的消息,即主机A先暂停发送(ack=0).主机A便会发送一个"窗口探测包",只是为了触发ack(查询当前缓冲区的情况,一旦发现ack=1)时,便可以继续发送.

接收方就可以根据窗口大小,来反向限制发送方传输速度了.