作为背景，我有一个嵌入式设备，可以通过 IP 与第三方服务器通信。第三方服务器中的代码不太可能更改。在最近的一个版本中，我将 ip disconnect 函数更改为在调用 close() 之前调用 shutdown()（之前它只是调用了 close()）。如果发生某些中断，嵌入式设备会在未完成通信会话的情况下断开连接。当这种情况发生在会话中的错误点时，服务器现在正在生成一个跟踪文件，由于各种原因，该文件对客户来说是不可接受的。这仅在调用 shutdown 时发生，服务器将此视为发送失败错误（并生成跟踪文件），而将更突然的 close() 视为不需要跟踪的另一端断开连接错误。
所以显而易见的解决方案是停止调用关机。Barnes 先生在这个问题中的回答很好地描述了这两个功能，但是，如果您知道只有一个进程连接到特定套接字，那么有什么理由在关闭之前使用关闭？
谢谢，帕特里克
在我看来，“突然断开连接”已经成为您通信协议的一部分，这不是一件好事。如果客户端在“某些中断发生”之后运行很长时间来决定是否使用shutdown()或close()影响另一端看到的内容，那么最好更新您的协议以可靠地传递“此会话已中止消息。 "
也就是说，听起来好像这个系统（即所有的交互软件）已经（在服务器上）严重冻结了一点，以至于这种变化永远不会发生。可能你想要做的，而不是弄清楚问题到底是什么，是让经理签署一个快速而肮脏的“只使用close()”解决方案，在向他解释你不确定其他什么之后这可能会产生影响，但之前的情况似乎确实运行良好。（自从您进行更改后，您没有注意到任何其他错误消失，是吗？）
决定是否进行潜在昂贵的搜索以查看此处实际发生的情况，以及与另一端负责维护该软件的某个组织进行潜在的昂贵（政治上，如果不是财务上），实际上是管理决策，而不是技术决策第一，虽然要正确制作，但需要了解技术风险。
如果您知道只有一个进程连接到特定套接字，那么在关闭之前是否有任何理由使用关闭？
不，没有。与那里的许多文档相反。如果尚未发送，则关闭 FIN/ACK 关闭握手。
编辑：但这并不是说关机没有它的用途：当然它有。如果您想停止发送，并希望接收者知道这一点，但又想继续接收，那就是它的目的。另一个用途是几乎解决了两军问题并获得同步关闭：如果您读取 EOS，则发送关闭并关闭；如果要启动关闭，请发送关闭并读取直到 EOS，然后关闭。如果您的应用程序协议正确，则后一步不应读取任何数据，并且两端的关闭将是相当同时的。