某些HTTP请求上的奇怪TCP重置（RST）

Question

我们有一个用Delphi编写的应用程序，它使用Delphi On Rails并充当服务器并使用HTTP，JSON和websockets与客户端通信。我们最近遇到了一些问题，很难调试它们并找到问题的来源。

使用Wireshark进行流量分析，我们可以看到以下行为：来自客户端的请求（HTTP GET用于文件）。通常，我们处理该请求并发送HTTP状态代码，该文件（如果没有缓存）等。但是，我们有一个可重现的问题，其中只有 来自客户端的请求，来自服务器的TCP SYN，但之后，服务器发送RST数据包，TCP通信停止。

奇怪的是，我们可以很好地重现问题（虽然RST数据包破坏通信的文件不同），并且在下列情况之一中神秘地消失了：

• 在调试环境（Delphi IDE）中，禁用madExcept
• 在发布环境中，不使用madExceptPatch修补可执行文件
• 将焦点放在与主应用程序窗口不同的窗口。

由于我们在Delphi On Rails上遇到了一些问题并且不得不对其进行微小的修改以避免访问冲突和调试异常，我怀疑DOR是罪魁祸首和一些奇怪的内存损坏或未捕获的异常是bug，但它是仍然令人困惑，特别是如果我们改变焦点，问题就会消失。

我的主要问题不是如何解决这个问题，而是如何调试它以及在哪里寻找问题。 TCP重置的来源也让我感到困惑，因为在这种情况下我们没有遇到the usual procedures that process requests，它似乎是DOR或其他东西（应用程序，Winsock，OS）错误地重置连接。

为了完整性，因为它可能是相关的，这里是我在Delphi On Rails项目和论坛帖子中报告的问题，我向madExcept作者询问了这个问题：Issue #6，Issue #7， Issue #8，forum entry。

Answer 1

作为测试，我们从版本控制中检查了一些较旧的DOR源，其中没有连接问题已知，并且它在没有显示任何上述问题的情况下工作。

因此我们决定以相反的方式解决问题：将DOR特定源代码（大约20个文件）回滚到最后一个稳定版本并逐个“重新更新”它，直到错误再次发生。如果发生这种情况，我们可以

1. 快速回到最新的工作版本
2. 希望与原始的DOR源非常接近，以便我们对库的更新做出反应。
3. 分析发生的错误并向DOR项目报告详细问题（甚至可能是解决方案）。

编辑：我们现在可以将除了一个文件之外的所有文件更新回旧状态，而不会出现连接问题。创建问题的文件是dorSynchronizer.pas，更确切地说是导致问题的文件的r179 - 线程在那里从Windows API更改为Delphi TThread。我们将进一步调查此问题，并可能在未来几天向DOR项目添加一个问题。

EDIT2：事实证明，DOR使用了可能导致未定义行为的弃用程序TThread.Suspend和TThread.Resume。我向DOR项目报告了an issue。