三次握手
先上图
报文标识解释
SYN: synchronization (同步) - 占1位
ACK: acknowledgement (确认:告知已收到)
seq: 序列号, 当前端成功发送的数据位数
ack: 确认号, 为当前端成功接收的数据位数
seq和ack主要是为了记录数据长度, 暂且按下不表
流程描述
client: [SYN] : 我准备发消息了
server: [SYN, ACK] : 好的, 我做好接收的准备了
client: [ACK] : 我知道了(然后开始发送消息)
疑问, 为什么这么设计?
- 理想情况下:
client: "我要开始了"
server: "好的"
然后client开始发送信息 - 第二种情况:
client: "我要开始了" -- 但是server没有收到
client: 发现半天server都没有反馈, 于是又发了一遍 "我要开始了"
server: "好的" -- 这回收到了
如果client发送的请求没有被server收到, 那么长时间没有收到server的回复后, 重新发送请求既可 - 第三种情况:
client: "我要开始了" -- 这个请求堵在路上了,server没有收到
client: 重新发送 "我要开始了"
server: "好的"
client: "开始发送信息"
在发送信息的过程中,server收到了之前堵在路上的请求, 只能重新建立连接!!
这并不是我们希望的, 为了避免client本该失效的请求被server接收, 必须要多一次握手, 即三次握手
其它
在
HTTP/1.1中,keep-alive能够复用TCP连接, 减少TCP三次握手的次数, 从而提升性能
四次挥手
先上图
报文标识解释
FIN: finish (结束) - 占1位
流程描述
client: [FIN] : 消息已经发送完毕了, 现在我要关闭连接了, 但仍保留接收消息的能力
server: [ACK] : 好的, 我知道了, 但是我还有一些数据包没有发送, 弄完了, 我告诉你
server: [FIN, ACK] : 好了数据发送完了, 我先关为敬
client: [ACK] : OK 我也关了
疑问, 为什么这么设计?
和建立连接一样的考虑, 需要3次挥手, 如下
client: "我要结束啦"
server: "好的"
client: "那我真的结束了"
但是结束和建立的一个区别在于,client想建立的时候,server能够 随时准备建立, 而client想结束的时候,server得先确保手中的数据发送完, 才能够结束
所以中间的一次挥手要拆分为两步, 如下:
client: "我要结束啦"
server: "好的, 等我把数据发完"
server: "我发完啦"
client: "那我真的结束啦" -- 如图, 还有一个TIME-WAIT阶段 (下面说)
然后client结束连接,server收到后也结束连接再考虑一种情况, 假如:
server没有收到client发送的"那我真的结束啦"呢?超时重传吗?client都已经关闭连接了!
所以解决办法是:
client在发完 "那我真的结束啦" 后, 等待一段时间 (2MSL), 如果这段时间内没有收到server的重传, 证明server已经确实收到了
之后client可以放心的结束了, 这就是图中TIME-WAIT阶段的作用
MSL是Maximum Segment Lifetime, 译为 "报文最大生存时间",
RFC 793中规定MSL为 2 分钟, 实际应用中常用的是30s,1min,2min
ps: 我也不知道RFC 793是什么东东 = =!!
总结
3次握手，用来保障 通讯双方 有通信的基础
4次挥手，用来保障 通讯双方 可以安全的回收 TCP通信的系统资源
参考
知乎 - 为什么http请求要３次握手与４次挥手？
CSDN - TCP的三次握手与四次挥手
CSDN - Time-wait状态(2MSL)一些理解
CSDN - 理解TCP序列号和确认号
阿里 - hit-alibaba.github.io
掘金 - 精读《图解HTTP》
