wcf - 是什么导致 SOAP 服务在响应单个消息后不断断开 TLS 客户端的连接？

Question

我在 Microsoft 服务跟踪查看器中加载了一个客户端 .svclog 文件，日志中有很多条目说设置安全 session 和关闭安全 session 。在服务器端，我可以看到许多 trust/RST/SCT/Cancel 实例，这表明连接正在服务器端关闭，但仅在对 SOAP 消息做出响应之后。似乎每个 Web 服务调用都涉及为 SOAP 设置 TLS session ，然后在发送响应后立即关闭连接，要求为下一次调用再次设置 TLS。

我读了这篇文章:https://blogs.technet.microsoft.com/tspring/2015/02/23/poor-mans-guide-to-troubleshooting-tls-failures/

它说:

Keep in mind that TCP resets should always be expected at some point as the client closes out the session to the server. However, if there are a high volume of TCP resets with little or no “Application Data” (traffic which contains the encapsulated encrypted data between client and server) then you likely have a problem. Particularly if the server side is resetting the connection as opposed to the client.

不幸的是，这篇文章没有对此进行扩展，因为这正是我所看到的!

这是安装在某些客户环境中的 net.tcp Web 服务，设置为使用 Windows 身份验证。

我诊断的下一步是什么？

Answer 1

您看到的行为很可能是正常的，除非您遇到一些问题，否则我不会担心。您引用的 MSFT 文档是指 TCP 重置，但您说您的日志显示 信任/RST/SCT/取消条目，在这种情况下，RST 表示 请求安全 token .换句话说，您的日志消息绝不意味着正在发生 TCP 重置 (RST) 帧。
Web 服务安全对话语言 (WS-SecureConversation) 规范 (here) 说:

It is not uncommon for a requestor to be done with a security context token before it expires. In such cases the requestor can explicitly cancel the security context using this specialized binding based on the WS-Trust Cancel binding. The following Action URIs are used with this binding: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT/Cancel

Once a security context has been cancelled it MUST NOT be allowed for authentication or authorization or allow renewal. Proof of possession of the key associated with the security context MUST be proven in order for the context to be cancelled.

如果您确实因意外的 TCP RST 帧而遇到传输问题，或者如果您看到它们并想了解它们的根本原因，那么您需要捕获网络流量以了解 TCP 重置发生的方式和原因，以及是否它们是正常的或异常的。
我会通过启动 WireShark 来做到这一点并看着框架。如果您看到来自每一方的 FIN、ACK 消息，那么您希望连接在等待一段时间后正常关闭。否则，您将看到 RST 帧，原因有多种:应用程序重置(执行以避免占用大量处于等待状态的端口)、重新访问处于等待状态的端口时序列号错误、路由器或防火墙 RST 消息(通常发送两个方向)、重传超时、端口选择 RST 消息等。
有很多资源可以帮助进行 TCP 流量分析。您可能会发现查看 https://blogs.technet.microsoft.com/networking/2009/08/12/where-do-resets-come-from-no-the-stork-does-not-bring-them/ 会有所帮助快速概览。
如果您不熟悉 WireShark，它可能看起来有点复杂，但是您想要在这里做的事情非常简单，即使没有先前的经验，您也可以很快得到答案。只需搜索 wireshark 教程，您就会找到适合您认知风格的教程。
您还可以使用 WireShark 对更高级别的协议(protocol)(包括 TLS)进行故障排除。你可以在很多地方找到有关这方面的信息。我将仅列出一些以帮助您入门:
关于 SSL 的 WireShark 文档是 here .
关于 HTTPS 的维基学院部分是 here .
查看 SSL 流量的 5 分钟 youtube 教程是 here .
我相信这可以很好地涵盖您的下一个诊断步骤，但如果没有，请随时发布更多信息，我可以尝试提供更好的答案。