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就识别到丢包了，进行超时重传
而数据要支持重传，就必须被暂时保存起来，保存到滑动窗口中
