目录
前情回顾
HTTP收尾，中间人攻击，证书，数字签名，校验机制
UDP协议：简单的协议，无连接，不可靠传输，面向数据报，全双工，源端口，目的端口，长度，校验和
TCP协议【重要！】：有连接，可靠传输，面向字节流，全双工
保证TCP可靠传输的两个核心机制
- 确认应答->接收方通过ack（应答报文）告知发送方，我收到了
- 引入序号和确认序号，应答报文设为1->TCP接收方就可以通过序号对数据包进行去重/排序
- 超时重传->对丢包情况的处理
- 超出一定时间，没有收到应答报文，就认为是丢包了->触发超时重传操作
连接管理
建立连接：三次握手
三次握手（中间两个传输合并了）
所谓的连接 ，指的是 ->通信双方各自保存对端的关键信息
LISTEN状态：服务器启动，随时可以有用户连接上来（listen）
ESTABLISHED状态：连接建立完毕，随时可以发送数据（established）
三次握手的意义
- 投石问路，初步验证通信链路是畅通的
- 验证通信双方的各自的发送能力和接收能力（为啥两次不行？因为不能完成验证；为啥四次不行？因为可以合并成三次）
- 协商关键信息（初始序号从多少开始）
易错点 ：三次握手对可靠传输有一定的帮助 ，但是如果说，TCP实现可靠传输 全靠三次握手 那就非常不科学了
三次握手只在最开始建立连接的时候进行
一旦连接建立好了，后续业务数据的通信也和三次握手没关系了
后续业务的可靠性，还得是靠确认应答和超时重传
断开连接：四次挥手
四次挥手中的 ACK和FIN可以合并成一步吗？
如能！
不能 是因为：ACK 被内核 收到后，会马上返回给发送方，FIN 被内核收到后需要进一步调用应用程序代码（慢一点）
能 是因为：延时应答机制，让ACK延迟发送了，恰好和FIN一起发送
四次挥手的各种状态
TIME_WAIT状态 ：给最后一个ACK丢包的行为做个托底，主动发起FIN的一方会进入到TIME_WAIT状态（主动提出离婚的人）
CLOSE_WAIT状态 ：被动发起FIN的一方 ，会进入CLOSE_WAIT状态（等待 你的应用程序代码，来调用close方法）（被离婚的人）
这里不能用客户端or服务器这样的词来表述，因为客户端or服务器都可能主动发起FIN
TIME_WAIT（服务器的状态） 和 TIME_WAITING（线程的状态）没有什么关系
为什么要有TIME_WAIT状态呢？
那等多久合适呢？
按照网络上任意两个节点传输过程中消耗的最大时间 * 2
通常这个消耗的最大时间 会配成60s ，因为超时重传的阈值是ms级别的
此处TIME_WAIT等待2min（这个数值不要背，因为不同系统可能不一样，这个值是可以修改的）
四次挥手的异常情况
比如服务器始终不调用close
- 站在A的视角，此时A发给B的FIN 已经过去很久了，B还是没有回应，A就会主动释放连接（把B的核心信息删了）
- B这边，由于代码逻辑有bug，A释放连接后，B 这里的连接 还会暂时存在（还会保存对方信息，但是也没办法进行正常的数据通信了）
经典面试题
- LISTEN
- ESTABLISHED
- TIME_WAIT
- CLOSE_WAIT
- 三次握手的过程
- 四次挥手 的过程
END✿✿ヽ(°▽°)ノ✿