JavaEE传送门

JavaEE

网络原理——传输层_UDP

网络原理——No.1 传输层_TCP的确认应答机制与超时重传

---

---

TCP的连接管理

描述的就是 TCP 建立链接和断开链接的过程

TCP 的链接, 只是一个 “逻辑上的” “虚拟的连接” (只要网络能通信, 不管是用 TCP 还是 UDP 还是什么协议, 物理上肯定是连接好的)

1. 主机A 和 主机B 建立连接
2. 主机A 的系统内核里, 记录一个数据结构, 包含看和他连接的对方, 是谁(IP, 端口, 使用的协议…)
3. 主机B 的系统内核里, 记录了一个数据结构, 包含了和他连接的对方, 是谁…

三次握手(建立连接)

双方建立一个相互认同的关系

我们来看这样一个场景: 小Gujiu 和 大GUJIU 本来只是普通关系, 之后开始建立连接

建立连接的过程其实是四次的数据交互, 那为什么是 “三次握手” 呢?

本来是四次, 但中间两次可以合并在一起, 一共就是三次.

# 注意 # 三次握手中, B 给 A 返回的 ACK 是收到 A 给 B 的 syn之后, 立即触发的, 也是立即发送的

为什么要建立链接

1. 投石问路, 检查一下当前的网络情况是否通畅

2. 三次握手同时也是在检查通信双方的发送能力和接收能力都是正常的

3. 三次握手过程中, 也在协商一些重要的参数

   比如： TCP 的序号并非是从 1 开始的, 通常都是建立连接的时候协商了一个数字, 目的保证两个连接的序号有差别. 如果我们连接断开, 又快速重连, 接收方就可以区分当前收到的数据是当前连接的还是上次连接的

两个重点 TCP 状态

1. LISTEN: 服务器启动之后, 绑定端口之后 (new ServerSocket 完成). 表示 手机打开, 信号良好, 可以接听别人的电话
2. ESTABLISHED: 连接建立好了之后的稳定状态. 表示电话接通, 可以说话了

---

四次挥手(断开连接)

通信双方, 各自向对方申请断开连接, 再各自给对方回应

FIN: 结束报文段

四次挥手是有可能变为三次的, 但不是 100%.

既然两个数据实际都不相同, 为什么还有可能合并呢 ?

TCP 中还有一个机制, 捎带应答. 后面文章会讲解.

两个重要的 TCP 状态

1. CLOSE_WAIT: 等待代码中调用 close 操作. (如果你的服务器上出现了大量的 CLOSE_WAIT 状态的连接,说明代码 bug, 说明 close 没有被及时调用到)

2. TIME_WAIT: 主动发起关闭的一方, 会进入 TIME_WAIT. (A 处理完最后一个 ack 之后, 不能立即释放连接, 而需要保持一定的时间, 为了万一最后的ack 丢了, 还有机会进行重传.)

   TIME_WAIT 需要等待 2 MSL(网络上的两个位置之间传输消耗的最大时间)

   

---

🌷(( ◞•̀д•́)◞⚔◟(•̀д•́◟ ))🌷

以上就是今天要讲的内容了，希望对大家有所帮助，如果有问题欢迎评论指出，会积极改正！！

这里是Gujiu吖！！感谢你看到这里🌬 祝今天的你也 开心满怀，笑容常在。