python - 从urllib.request向HTTPServer发出许多并发请求时的神秘异常

Question

我正在尝试this Matasano crypto challenge，其中涉及使用人为放慢的字符串比较功能对服务器进行定时攻击。它说使用“​​您选择的Web框架”，但是我不想安装Web框架，因此我决定使用HTTPServer class模块中内置的 http.server 。

我想出了一些可行的方法，但是它非常慢，因此我尝试使用 multiprocessing.dummy 内置的(记录不良)线程池来加快速度。它的速度要快得多，但是我注意到了一些奇怪的事情:如果我同时发出8个或更少的请求，它就可以正常工作。如果我不止这些，它会工作一段时间，并在看似随机的时间给我错误。错误似乎是不一致的，并不总是相同的，但是它们中通常包含Connection refused, invalid argument，OSError: [Errno 22] Invalid argument，urllib.error.URLError: <urlopen error [Errno 22] Invalid argument>，BrokenPipeError: [Errno 32] Broken pipe或urllib.error.URLError: <urlopen error [Errno 61] Connection refused>。

服务器可以处理的连接数是否有限制？我认为线程本身并不是问题所在，因为我编写了一个简单的函数，无需运行Web服务器就可以进行慢速的字符串比较，并使用500个并发线程进行调用，并且运行良好。我不认为仅从多个线程发出请求就成为问题，因为我制作的爬虫使用了100个以上的线程(所有爬虫都同时向同一个网站发出请求)，而且它们工作正常。看起来HTTPServer并不是要可靠地托管获得大量流量的生产网站，但令我惊讶的是它很容易崩溃。

我尝试从我的代码中逐渐删除看起来与问题无关的内容，就像我通常在诊断像这样的神秘错误时所做的那样，但这在这种情况下不是很有帮助。似乎在删除似乎无关的代码时，服务器可以处理的连接数量逐渐增加，但是并没有明确的崩溃原因。

是否有人知道如何增加我一次可以发出的请求数量，或者至少为什么会这样？

我的代码很复杂，但是我想出了一个简单的程序来演示问题:

#!/usr/bin/env python3

import os
import random

from http.server import BaseHTTPRequestHandler, HTTPServer
from multiprocessing.dummy import Pool as ThreadPool
from socketserver import ForkingMixIn, ThreadingMixIn
from threading import Thread
from time import sleep
from urllib.error import HTTPError
from urllib.request import urlopen


class FancyHTTPServer(ThreadingMixIn, HTTPServer):
    pass


class MyRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        sleep(random.uniform(0, 2))
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"foo")

    def log_request(self, code=None, size=None):
        pass

def request_is_ok(number):
    try:
        urlopen("http://localhost:31415/test" + str(number))
    except HTTPError:
        return False
    else:
        return True


server = FancyHTTPServer(("localhost", 31415), MyRequestHandler)
try:
    Thread(target=server.serve_forever).start()
    with ThreadPool(200) as pool:
        for i in range(10):
            numbers = [random.randint(0, 99999) for j in range(20000)]
            for j, result in enumerate(pool.imap(request_is_ok, numbers)):
                if j % 20 == 0:
                    print(i, j)
finally:
    server.shutdown()
    server.server_close()
    print("done testing server")

出于某种原因，上面的程序除非有超过100个线程，否则都可以正常工作，但是我为该挑战编写的真实代码只能处理8个线程。如果以9运行它，通常会出现连接错误，而以10运行，则总是会出现连接错误。我尝试使用 concurrent.futures.ThreadPoolExecutor ， concurrent.futures.ProcessPoolExecutor 和 multiprocessing.pool 代替 multiprocessing.dummy.pool，但这些似乎都没有帮助。我尝试使用一个普通的 HTTPServer对象(不使用 ThreadingMixIn)，这只会使事情运行非常缓慢，并且无法解决问题。我尝试使用 ForkingMixIn，但也没有解决。

我该怎么办？我在2013年末运行OS X 10.11.3的MacBook Pro上运行Python 3.5.1。

编辑:我还尝试了其他一些操作，包括使用进程而不是线程在服务器上运行服务器，作为简单的 HTTPServer， ForkingMixIn和 ThreadingMixIn。这些都没有帮助。

编辑:这个问题比我想象的要陌生。我尝试使用服务器编写一个脚本，使用大量线程发出请求的脚本，然后在终端的不同选项卡中运行它们。服务器的进程运行良好，但发出请求的服务器崩溃了。异常(exception)是 ConnectionResetError: [Errno 54] Connection reset by peer， urllib.error.URLError: <urlopen error [Errno 54] Connection reset by peer>， OSError: [Errno 41] Protocol wrong type for socket， urllib.error.URLError: <urlopen error [Errno 41] Protocol wrong type for socket>和 urllib.error.URLError: <urlopen error [Errno 22] Invalid argument>的混合。

我使用上述虚拟服务器进行了尝试，如果将并发请求的数量限制为5个或更少，则可以正常工作，但如果有6个请求，则客户端进程将崩溃。服务器出现了一些错误，但是它一直在继续。无论我使用线程还是进程发出请求，客户端都崩溃。然后，我尝试将减慢功能放入服务器中，该功能能够处理60个并发请求，但崩溃了70个。这似乎与服务器出问题的证据相矛盾。

编辑:我尝试了使用 requests而不是 urllib.request描述的大多数事情，并遇到了类似的问题。

编辑:我现在正在运行OS X 10.11.4，并遇到相同的问题。

Answer 1

您正在使用默认的listen()待办事项值，这可能是造成这些错误的主要原因。这不是已经建立连接的并发客户端数，而是在建立连接之前在侦听队列中等待的客户端数。将服务器类更改为:

class FancyHTTPServer(ThreadingMixIn, HTTPServer):
    def server_activate(self):
        self.socket.listen(128)

128是一个合理的限制。如果要进一步增加它，则可能要检查socket.SOMAXCONN或操作系统somaxconn。如果在重负载下仍然存在随机错误，则应检查ulimit设置并根据需要增加。

我以您的示例为例，并运行了1000多个线程，因此我认为应该可以解决您的问题。

更新

如果它有所改善，但同时并发200个客户端仍然崩溃，那么我可以肯定您的主要问题是积压的大小。请注意，您的问题不是并发客户端数，而是并发连接请求数。简要解释这意味着什么，而不必太深入探讨TCP内部原理。

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((HOST, PORT))
s.listen(BACKLOG)
while running:
    conn, addr = s.accept()
    do_something(conn, addr)

在此示例中，套接字现在在给定端口上接受连接，并且 s.accept()调用将阻塞，直到客户端连接为止。您可能有许多客户端尝试同时连接，并且根据您的应用程序，您可能无法调用 s.accept()并以与客户端尝试连接一样快的方式调度客户端连接。待处理的客户端排队，该队列的最大大小由BACKLOG值确定。如果队列已满，则客户端将失败，并显示“连接被拒绝”错误。

线程处理无济于事，因为ThreadingMixIn类的作用是在单独的线程中执行 do_something(conn, addr)调用，因此服务器可以返回到mainloop和 s.accept()调用。

您可以尝试进一步增加积压，但在某些情况下这无济于事，因为如果队列太大，则某些客户端将在服务器执行 s.accept()调用之前超时。

因此，如上所述，您的问题是并发连接尝试的次数，而不是并发客户端的数目。也许128对您的实际应用程序就足够了，但是您在测试中遇到了一个错误，因为您试图同时连接所有200个线程并泛滥队列。

除非您收到 ulimit错误，否则不要担心 Too many open files，但是如果您想将积压增加到128以上，请对 socket.SOMAXCONN进行一些研究。这是一个好的开始: https://utcc.utoronto.ca/~cks/space/blog/python/AvoidSOMAXCONN