如果服务端还有未确认数据，关闭连接会怎样？

正文

请到「今天看啥」查看全文

3.如果established阶段发送seo=301 数据包(数据包的长度：100)，在fin阶段被接收了，这时候，客户端回复是什么呢？服务端在closed_wait接收到了这个回复包，处理逻辑是什么呢？

4.fin阶段用了seo=301、established阶段也有seo=301，这样会不会造成序列号混乱呢？

针对上面的疑惑的点，希望大佬们帮忙解惑一下。

为了让文章看起来不是那么枯燥，派出小明、小丽分别担任客户端、服务器端。他们俩使用快递包裹来传递字节信息。

Day 1

小丽发出编号= 300 包裹，包裹里携带 1 byte数据。

Day 2

小丽发出的编号=301 包裹，包裹里携带 1 byte数据。

Day 3

小明收到编号= 300 包裹，按理应该立马发出确认编号 = 301的包裹。但是考虑到自己没有多余的包裹（byte）要发给小丽，所以要明确告知小丽，小明要单向关闭发送通道（这里的单向是指，小明到小丽方向），怎么告知呢？只要将FIN =1即可。所以小明自作聪明 将确认包裹与关闭连接意图的包裹合二为一，只发出一个包裹 。包裹上写明以下信息：

1. 确认编号 = 301

2. FIN = 1

3. 自己包裹序列号 = 100

有同学会说，1 和2 放在包裹里算是理解了，为什么要有3呢？

这个序列号100，为 FIN意图（小明关闭连接的意图）逻辑占据一个字节 。所谓逻辑占据，并不是说报文里携带一个字节的data，而是没有data，但是序列号100被FIN意图占据。

通常小丽对于空包裹（比如纯ACK包裹）是不确认的，但是由于FIN包裹逻辑占据一个字节序列号，所以逼迫小丽必须发出ACK确认包裹。

• 小明确认收到编号为300以前的所有数据，正期待着300以后更多字节的到来
• 小明单向关闭连接的意图

画外音

小明在发出这个包裹时，并没有收到小丽编号= 301的包裹，否则小明发出的包裹肯定是确认编号= 302。可是小明并没有这么做，所以逻辑推理小明并没有收到。

请到「今天看啥」查看全文