FIN & RST 设置在 socket 通信中答案

【问题标题】：FIN & RST set in socket communicationFIN & RST 设置在 socket 通信中
【发布时间】：2020-01-10 05:08:09
【问题描述】：

存在启用了 TLS 1.2 的现有套接字通信，为此我已包含单向/双向支持，这样做时我观察到套接字中频繁重置。在使用线鲨分析数据包时，观察到发送的 FIN、ACK 和 RST 标志，我认为这是重置或中止连接的原因。

我的查询：

我相信在套接字对话期间，在许多情况下，我在尝试 readObject() 时观察到 EOFexcetpion。这会导致套接字重置或断开连接吗？
如果我希望套接字连接永久连接，我如何忽略 FIN 和 RST 标志并保持套接字连接永久？
当套接字发现空闲然后断开连接时是否有效。是通过RST还是FIN标志？

【问题讨论】：

1. EOFException 本身不能导致 RST，但是您接下来的响应可以。 2. 你不能：见@jiJmGarrison 的回答。 3. (a) 是的，丢失空闲连接是有效的，并且 (b) 断开连接会导致 FIN，除非你做了一些奇怪的事情，比如没有读取所有待处理的数据。
@user207421 ，我理解我的服务器代码会生成一个带有执行器服务的套接字实例，并且如果套接字断开连接，它会在循环中重新创建。但是由于某种原因，我在此处观察到的服务器代码在发送消息套接字后关闭，并且客户端尝试 readObject() 过早抛出导致套接字 close() 的 EOF 异常，为了解决这个问题，我可以制作 socket.shutdown()这样客户端才会有幸在实际关闭之前仍然阅读吗？我的意思是在服务器端和客户端都添加 socket.shutdown() 而不是 socket.close() ？
服务器不会重新创建任何东西。它接受新的连接。 EOFException 表示对端提前关闭了连接。如果它发生在readObject() 你在发送端做错了什么。据我所知，这里不需要shutdown()。您需要发布客户端代码。

标签： java sockets ssl tcp

【解决方案1】：

socket发现空闲然后断开连接是否有效

是的，断开或拆除套接字以进行空闲连接是有效的。如果空闲连接没有被拆除，那么随着新连接的启动，连接（套接字连接）会继续保留并消耗系统资源/内存。此外，每个套接字连接都在一个新端口上，因此随着新连接不断进入（例如，如果您的服务器像 Web 服务器一样繁忙），您将继续使用 tcp 端口！
还有两种不同的状态，FIN_WAIT_1 和 FIN_WAIT_2（参考RFC 793 for TCP Specification）所以最重要的是，继续让套接字连接始终或永久连接可能不是一个好主意——对于接受大量客户端流量的繁忙服务器来说当然不是一个好主意——新接受的连接将继续保持随着更新的连接不断涌入，逐渐消耗或使用本地 tcp 端口...

【讨论】：

所有传入的 TCP 连接使用与接受它们的侦听套接字相同的端口。 FIN_WAIT_1 和 FIN_WAIT_2 是端口状态，而不是 FIN 的风格，它是一个段标志。
正确的是它们是端口状态，而不是 FIN 的“风味”，这是问题所在，并且是段标头中的一位 (RFC 793)，因此不能可能有两种口味。你的说法没有道理。
是的，这是正确的 FIN_WAIT_1 和 FIN_WAIT_2 是两种状态（如 RFC 793 中所定义，不同的状态为 - 连接在其生命周期内经历了一系列状态） FIN-WAIT-1 - 表示等待来自远程 TCP 的连接终止请求，或对先前发送的连接终止请求的确认。 FIN-WAIT-2 - 表示等待来自远程 TCP 的连接终止请求。（我将编辑答案以删除风味一词）
是的，FIN_WAIT 和其他端口状态实际上与这个问题没有任何关系。您关于端口的错误仍未得到纠正。这个答案中唯一能正确回答问题的部分是前两句话。

【解决方案2】：

...如何忽略 FIN 和 RST 标志...

简单的答案是你不能。

该协议规定，一旦您收到 FIN，连接就处于被拆除的过程中。你可以尝试做任何你想做的事情，但是无论你做什么，FIN 数据包的发送者都会离开。

当您将数据发送到不期望您发送数据包的端点时，即当您尝试忽略 FIN 时，RST 标志会发送回您。

“永久”保持连接打开需要连接双方的合作，如果网络出现故障，连接仍可能由于超时而失败。

【讨论】：