104，“对等连接重置”套接字错误，或者何时关闭套接字会导致RST而不是FIN？

Question

我们正在并行开发一个Python
Web服务和一个客户端网站。当我们从客户端向服务发出HTTP请求时，一个调用始终在socket.py中引发socket.error，其读取方式为：

（104，“对等方重置连接”）

当我用wireshark收听时，“好”和“坏”的响应看起来非常相似：

• 由于OAuth标头的大小，该请求被分为两个数据包。服务以ACK响应
• 该服务发送响应，每个报头一个数据包（HTTP / 1.0 200 OK，然后是Date报头，等等）。客户端使用ACK响应每个请求。
• （良好请求）服务器发送FIN，ACK。客户端以FIN ACK响应。服务器响应ACK。
• （错误请求）服务器发送RST，ACK，客户端未发送TCP响应，套接字错误在客户端引发。

Web服务和客户端都在运行glibc-2.6.1的Gentoo Linux x86-64机器上运行。我们在同一virtual_env中使用Python
2.5.2。

客户端是Django 1.0.2应用，正在调用httplib2
0.4.0发出请求。我们正在使用OAuth签名算法对请求进行签名，并且OAuth令牌始终设置为空html" target="_blank">字符串。

该服务正在运行Werkzeug
0.3.1，该版本使用Python的wsgiref.simple_server。我通过wsgiref.validator运行了WSGI应用程序，没有任何问题。

看起来这应该很容易调试，但是当我在服务端通过一个好的请求进行跟踪时，看起来就像在socket._socketobject.close（）函数中的坏请求一样，将委托方法变成了伪方法。当send或sendto（不记得哪个）方法关闭时，将发送FIN或RST，然后客户端开始处理。

“通过对等方重置连接”似乎应该归咎于服务，但是我也不信任httplib2。客户会错吗？

进一步调试-看起来像Linux上的服务器

我有一台MacBook，所以我尝试在一个上运行该服务，在另一个上运行客户端网站。Linux客户端调用OS X服务器时不会出现错误（FIN ACK）。OS
X客户端使用错误（RST
ACK和（54，“对等重置连接”））调用Linux服务。因此，看起来好像是在Linux上运行的服务。是x86_64吗？坏glibc？wsgiref？还在寻找…

进一步测试-wsgiref看起来不整洁

我们已经使用Apache和mod_wsgi进行了生产，并且连接重置已消失。请参阅下面的答案，但我的建议是记录连接重置并重试。这样一来，您的服务器就可以在开发模式下正常运行，并在生产环境中稳定运行。

Answer 1

我有这个问题。请参阅Python“对等连接重置”问题。

您（很可能）遇到了基于Python全局解释器锁定的小计时问题。

您可以（有时）从time.sleep(0.01)策略上更正此问题。

“哪里？” 你问。打败我。这个想法是为了在客户端请求之内和周围提供更好的线程并发。尝试 在 发出请求 之前
放好它，以便重置GIL，Python解释器可以清除所有未决线程。