【计算机网络】传输层协议——TCP(下)

文章目录

  • 1. 三次握手
    • 三次握手的本质是建立链接,什么是链接?
    • 整体过程
    • 三次握手过程中报文丢失问题
    • 为什么2次握手不可以?
    • 为什么要三次握手?
  • 2. 四次挥手
    • 整体过程
    • 为什么要等待2MSL
  • 3. 流量控制
  • 4. 滑动窗口
    • 共识
    • 滑动窗口的一般情况
    • 理解滑动窗口
    • 滑动窗口的特殊情况

1. 三次握手

【计算机网络】传输层协议——TCP(下)_第1张图片

SYN: 是一个连接请求的报文 (三次握手),发送的是TCP报头

三次握手的本质是建立链接,什么是链接?

操作系统内会存在多个已经建立好的链接,操作系统是需要把这些建立好的链接 管理起来的
而管理的本质是 先描述 在组织
操作系统内为了管理连接维护的数据结构
先使用 struct tcp_link结构体,内部包含链接的各种字段
再使用链表 将其组织起来


创建并维护链接是有成本的
1. 内存空间的消耗 (想要创建链接,就需要创建链接对象,所以就要new/nalloc链接对象)
2. CPU资源的消耗 (维护定时器,来保证超时重传等)

整体过程

【计算机网络】传输层协议——TCP(下)_第2张图片

客户端只要把 SYN 发出去了,客户端的状态变为 SYN_SENT,称为 同步发送
只要服务器端收到 SYN,服务器端的状态 变为 SYN_RCVD
服务器端再进行 SYN+ACK 响应,响应后
客户端收到了ACK,并且发出ACK时,客户端的三次握手就完成了

服务器端直到收到 ACK时,服务器端的三次握手才完成

三次握手过程中报文丢失问题

【计算机网络】传输层协议——TCP(下)_第3张图片

若第一个报文丢失 即SYN丢失
服务器端不会受到任何影响,因为从来没有收到过报文


【计算机网络】传输层协议——TCP(下)_第4张图片

若第二个报文丢失 即SYN+ACK丢失
双方的三次握手过程没有成功,因为双方的连接没有建立起来


【计算机网络】传输层协议——TCP(下)_第5张图片

若第三个报文丢失 即ACK丢失
对于客户端来说,只需把ACK发出,就认为 三次握手就完成了
对于服务器端来说,只有收到了ACK报文,才认为三次握手完成了


【计算机网络】传输层协议——TCP(下)_第6张图片

所以当ACK报文丢失时,客户端认为完成了,而服务器端认为没完成
此时客户端认为建立好了,所以会直接给服务器发消息
而服务器端没建立好,则服务器端立即进行连接重置,响应RST
此时客户端会把连接关掉,然后重新建立连接

为什么2次握手不可以?

【计算机网络】传输层协议——TCP(下)_第7张图片

2次握手不可以,因为非常容易收到攻击
很容易收到 一台机器不断给你发送海量的SYN,服务器端收到SYN后,直接就给ACK不管客户端有没有收到
服务器已经认为建立好了连接
维护连接是有成本的,如果机器发送大量的SYN
服务器立马维护,就会立马消耗内存,内存被消耗的非常多,可能服务器无法对正常用户提供服务

为什么要三次握手?

1. 没有明显的设计漏洞,一旦建立连接出现异常,成本嫁接到客户端,服务器端成本较低

2. 验证双方的通信信道的通畅情况
三次握手是验证全双工通信 信道通畅的最小成本


【计算机网络】传输层协议——TCP(下)_第8张图片

第一次握手时,能证明 客户端 能发报文
第二次握手时,能证明 客户端 能收报文

第一次握手时,证明服务器 能收到报文
第三次握手时,能证明服务器 能发报文
(只有当客户端收到报文时并做出应答时,才能证明服务器发了报文)

2. 四次挥手

断开时,客户端想断开,服务器有可能不想断开
服务器想断开,客户端有可能不想断开

要断开连接,是需要征得双方同意的,不能只征得一方同意,因为双方的地位是对等的
四次挥手使双方以最小成本断开

整体过程

【计算机网络】传输层协议——TCP(下)_第9张图片

FIN: 是一个连接断开的请求报文

第一次挥手:
当发送 FIN报文后, 客户端状态 为 FIN_WAIT 1
服务器端收到FIN 报文 ,服务器端状态为 CLOSE_WAIT

第二次挥手:
客户端收到 服务器 做出 响应的 ACK报文时,客户端 状态为 FIN_WAIT 2

第三次挥手:
若服务器端也想断开连接,则向客户端发送 FIN报文,之后服务器端 进入 LAST_ACK 状态

第四次挥手:
客户端收到 收到服务器来自 FIN报文后,会向服务器端发送ACK应答
由于是客户端主动关闭,所以客户端之后进入 TIME_WAIT 状态,而服务器收到 来自客户端的ACK应答后,服务器就进入 CLOSE状态

客户端进入 TIME_WAIT 状态,需要等待2MSL后,客户端进入CLOSE 状态


发出最后一次 ACK报文后, 客户端就认为 完成 四次挥手
服务器端收到 ACK报文,服务器端才认为 完成 四次挥手

主动断开连接的一方,一定会发送最后一次ACK报文


为什么要等待2MSL

TCP协议规定 主动关闭连接的一方 要进入 最终的TIME_WAIT 状态,并且等待 2MSL
MSL 表示 一个报文在网络里存在的最大时间
TCP规定一般要等待 2个 MSL时间
发出的报文的最大生存时间是 1个 MSL,对方将来需要应答,应答的时间也是一个 MSL


要等待2MSL
保证两个传输方向上的尚未被接收 或 迟到 的报文段 都已经消失

若不等待2MSL
则有可能 刚把连接断开,网络里有断开连接之前的残余报文,断开连接后,立马对服务器进行重新连接
当把连接建立好后,就会有历史的残余报文存在,就会影响接收方对应的正常的接收数据

所以尽量保证历史的报文消散,不要影响下一次 正常通信

3. 流量控制

【计算机网络】传输层协议——TCP(下)_第10张图片

客户端和服务器在通信时,都有自己的发送和接收缓冲区
客户端发数据时,将客户端的发送缓冲区里的数据 发送到 服务器的接收缓冲区 中
服务器发数据时,将服务器的发送缓冲区里的数据 发送到 客户端的接收缓冲区 中

在确认应答中,就可以携带16位窗口大小,来表示接收缓冲区中剩余空间的大小,即承载能力
作为接收方,知道了数据接收的承载能力,可以让发送方发送数据时,发送慢一点,导致能够接收
这种操作就叫做 流量控制


若接收端发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值 通知给发送端
若发送端接收到这个窗口之后,就会减慢自己的发送速度

若接收端缓冲区满了,就会将窗口置为0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端

4. 滑动窗口

共识

【计算机网络】传输层协议——TCP(下)_第11张图片

对于每个发送的数据段,都要给一个ACK确认应答,收到ACK后再发送下一个数据段
但是这样做 收发效率非常低下


【计算机网络】传输层协议——TCP(下)_第12张图片

并发访问效率高,但是也是有接收能力上限的
发送方并发发送,一定要在对方能够接受的前提条件下,进行并发发送

发送方最大一次可以向对方发送多少数据,是由对方的窗口大小决定的

滑动窗口的一般情况

因为接收方的接受能力有限,所以发送方的发送
发送方的发送速度受对方接收缓冲区剩余空间大小影响的

【计算机网络】传输层协议——TCP(下)_第13张图片

滑动窗口是发送缓冲区的一部分
滑动窗口这部分数据 :暂时不用收到应答,可以直接发送


【计算机网络】传输层协议——TCP(下)_第14张图片

因为滑动窗口的存在,将发送缓冲区切成三部分
左侧 称为 已经发送已经确认
可以被覆盖 即无效数据

右侧 称为 尚未发送的数据区域
滑动窗口:可以直接发送,但是尚未收到应答
滑动窗口的大小与对方的接收能力有关

理解滑动窗口

【计算机网络】传输层协议——TCP(下)_第15张图片

把发送缓冲区 看作一个char类型的数组
因为char类型 只占一个字节,体现字节流
该数组叫做 sendbuffer


【计算机网络】传输层协议——TCP(下)_第16张图片

滑动窗口本质就是 由两个数组下标(start end)维护的区间
窗口进行滑动 就是让 start 和end 下标进行++

滑动窗口的特殊情况

情况1 ——滑动窗口只能向右滑动吗? 能不能向左滑动?

不能向左滑动,因为左侧的区域是 已经发送并且收到确认的数据,没有意义
所以只能向右滑动


情况2 ——滑动窗口能变大,能变小吗?能变成0吗? 变0之后表示什么意思?

可以变大/变小,滑动窗口变大变小 是取决于对方的接收能力的
滑动窗口变大 即 end 下标增加
滑动窗口变小 即 end下标不动,start下标向右移动

所以 滑动窗口的大小是浮动的,不是固定大小的

接收方的上层应用层 从来不取数据,则会导致接收缓冲区的剩余空间 越来越小,直至为0
从而导致发送方的发送数据越来越少,直至为0 即 滑动窗口为0 表示对方无法接收
start 和end 指向同一个


情况3 —— 滑动窗口内存在多个报文 可以直接发送,如果第一个丢失了呢?

【计算机网络】传输层协议——TCP(下)_第17张图片

若有报文 1000 2000 3000 4000
若第一个报文1000丢失,则有两种情况

情况1:报文收到了,但是确认应答(ACK)丢失
根据确认序号,当收到报文2000 对应的确认应答2001时,就知道对应的报文1000,接收方一定收到了


情况2:第一个报文1000的数据丢失

此时由于第一个报文丢失了,即 1001-2000区间内的数据丢失了 ,所以确认序号不能返回2001 、3001
因为 2001 表示 2000之前的序号全部接收到了,而1000是没有接收到的
所以就只能返回确认序号1001,表示1000之前的序号已经收到了
所以就会收到很多重复的ACK序号,TCP就识别到丢包了,进行超时重传

而数据要支持重传,就必须被暂时保存起来,保存到滑动窗口中

你可能感兴趣的:(计算机网络,计算机网络,tcp/ip,网络)