1. 三次握手

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

三次握手的本质是建立链接，什么是链接？

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

---

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

整体过程

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

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

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

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

---

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

---

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

---

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

为什么2次握手不可以？

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

为什么要三次握手？

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

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

---

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

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

2. 四次挥手

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

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

整体过程

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. 流量控制

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

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

---

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

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

4. 滑动窗口

共识

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

---

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

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

滑动窗口的一般情况

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

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

---

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

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

理解滑动窗口

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

---

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

滑动窗口的特殊情况

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

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

---

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

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

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

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

---

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

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

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

---

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

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

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