“只有在创造中才能够学到更多。” ——皮亚杰在本系列的第二部分中，你创造了一个可以处理基本 HTTP GET 请求的、朴素的 WSGI 服务器。当时我问了一个问题：“你该如何让你的服务器在同一时间处理多个请求呢？”在这篇文章中，你会找到答案。系好安全带，我们要认真起来，全速前进了！你将会体验到一段非常快速的旅程。准备好你的 Linux、Mac OS X（或者其他 *nix 系统），还有你的 Python。本文中所有源代码均可在 GitHub 上找到。服务器的基本结构及如何处理请求首先，我们来回顾一下 Web 服务器的基本结构，以及服务器处理来自客户端的请求时，所需的必要步骤。你在第一部分及第二部分中创建的轮询服务器只能够一次处理一个请求。在处理完当前请求之前，它不能够接受新的客户端连接。所有请求为了等待服务都需要排队，在服务繁忙时，这个队伍可能会排的很长，一些客户端可能会感到不开心。这是轮询服务器 webserver3a.py 的代码：##################################################################### # 轮询服务器 - webserver3a.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ##################################################################### import socket SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 5 def handle_request(client_connection): request = client_connection.recv(1024) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) while True: client_connection, client_address = listen_socket.accept() handle_request(client_connection) client_connection.close() if __name__ == '__main__': serve_forever() 为了观察到你的服务器在同一时间只能处理一个请求的行为，我们对服务器的代码做一点点修改：在将响应发送至客户端之后，将程序阻塞 60 秒。这个修改只需要一行代码，来告诉服务器进程暂停 60 秒钟。这是我们更改后的代码，包含暂停语句的服务器 webserver3b.py：###################################################################### # 轮询服务器 - webserver3b.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # # # # - 服务器向客户端发送响应之后，会阻塞 60 秒 # ###################################################################### import socket import time SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 5 def handle_request(client_connection): request = client_connection.recv(1024) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) time.sleep(60) ### 睡眠语句，阻塞该进程 60 秒 def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) while True: client_connection, client_address = listen_socket.accept() handle_request(client_connection) client_connection.close() if __name__ == '__main__': serve_forever() 用以下命令启动服务器：$ python webserver3b.py 现在，打开一个新的命令行窗口，然后运行 curl 语句。你应该可以立刻看到屏幕上显示的字符串“Hello, World!”：$ curl http://localhost:8888/hello Hello, World! 然后，立刻打开第二个命令行窗口，运行相同的 curl 命令：$ curl http://localhost:8888/hello 如果你在 60 秒之内完成了以上步骤，你会看到第二条 curl 指令不会立刻产生任何输出，而只是挂在了哪里。同样，服务器也不会在标准输出流中输出新的请求内容。这是这个过程在我的 Mac 电脑上的运行结果（在右下角用黄色框标注出来的窗口中，我们能看到第二个 curl 指令被挂起，正在等待连接被服务器接受）：当你等待足够长的时间（60 秒以上）后，你会看到第一个 curl 程序完成，而第二个 curl 在屏幕上输出了“Hello, World!”，然后休眠 60 秒，进而终止。这样运行的原因是因为在服务器在处理完第一个来自 curl 的请求之后，只有等待 60 秒才能开始处理第二个请求。这个处理请求的过程按顺序进行（也可以说，迭代进行），一步一步进行，在我们刚刚给出的例子中，在同一时间内只能处理一个请求。现在，我们来简单讨论一下客户端与服务器的交流过程。为了让两个程序在网络中互相交流，它们必须使用套接字。你应当在本系列的前两部分中见过它几次了。但是，套接字是什么？ 套接字 （ socket ） 是一个通讯通道 端点 （ endpoint ） 的抽象描述，它可以让你的程序通过文件描述符来与其它程序进行交流。在这篇文章中，我只会单独讨论 Linux 或 Mac OS X 中的 TCP/IP 套接字。这里有一个重点概念需要你去理解：TCP 套接字对 （ socket pair ） 。TCP 连接使用的套接字对是一个由 4 个元素组成的元组，它确定了 TCP 连接的两端：本地 IP 地址、本地端口、远端 IP 地址及远端端口。一个套接字对唯一地确定了网络中的每一个 TCP 连接。在连接一端的两个值：一个 IP 地址和一个端口，通常被称作一个套接字。（引自《UNIX 网络编程 卷1：套接字联网 API （第3版）》）所以，元组 {10.10.10.2:49152, 12.12.12.3:8888} 就是一个能够在客户端确定 TCP 连接两端的套接字对，而元组 {12.12.12.3:8888, 10.10.10.2:49152} 则是在服务端确定 TCP 连接两端的套接字对。在这个例子中，确定 TCP 服务端的两个值（IP 地址 12.12.12.3 及端口 8888），代表一个套接字；另外两个值则代表客户端的套接字。一个服务器创建一个套接字并开始建立连接的基本工作流程如下：服务器创建一个 TCP/IP 套接字。我们可以用这条 Python 语句来创建：listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 服务器可能会设定一些套接字选项（这个步骤是可选的，但是你可以看到上面的服务器代码做了设定，这样才能够在重启服务器时多次复用同一地址）：listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) 然后，服务器绑定一个地址。绑定函数 bind 可以将一个本地协议地址赋给套接字。若使用 TCP 协议，调用绑定函数 bind 时，需要指定一个端口号，一个 IP 地址，或两者兼有，或两者全无。（引自《UNIX网络编程 卷1：套接字联网 API （第3版）》）listen_socket.bind(SERVER_ADDRESS) 然后，服务器开启套接字的监听模式。listen_socket.listen(REQUEST_QUEUE_SIZE) 监听函数 listen 只应在服务端调用。它会通知操作系统内核，表明它会接受所有向该套接字发送的入站连接请求。以上四步完成后，服务器将循环接收来自客户端的连接，一次循环处理一条。当有连接可用时，接受请求函数 accept 将会返回一个已连接的客户端套接字。然后，服务器从这个已连接的客户端套接字中读取请求数据，将数据在其标准输出流中输出出来，并向客户端回送一条消息。然后，服务器会关闭这个客户端连接，并准备接收一个新的客户端连接。这是客户端使用 TCP/IP 协议与服务器通信的必要步骤：下面是一段示例代码，使用这段代码，客户端可以连接你的服务器，发送一个请求，并输出响应内容：import socket ### 创建一个套接字，并连接值服务器 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(('localhost', 8888)) ### 发送一段数据，并接收响应数据 sock.sendall(b'test') data = sock.recv(1024) print(data.decode()) 在创建套接字后，客户端需要连接至服务器。我们可以调用连接函数 connect 来完成这个操作：sock.connect(('localhost', 8888)) 客户端只需提供待连接的远程服务器的 IP 地址（或主机名），及端口号，即可连接至远端服务器。你可能已经注意到了，客户端不需要调用 bind 及 accept 函数，就可以与服务器建立连接。客户端不需要调用 bind 函数是因为客户端不需要关注本地 IP 地址及端口号。操作系统内核中的 TCP/IP 协议栈会在客户端调用 connect 函数时，自动为套接字分配本地 IP 地址及本地端口号。这个本地端口被称为 临时端口 （ ephemeral port ） ，即一个短暂开放的端口。服务器中有一些端口被用于承载一些众所周知的服务，它们被称作 通用 （ well-known ） 端口：如 80 端口用于 HTTP 服务，22 端口用于 SSH 服务。打开你的 Python shell，与你在本地运行的服务器建立一个连接，来看看内核给你的客户端套接字分配了哪个临时端口（在尝试这个例子之前，你需要运行服务器程序 webserver3a.py 或 webserver3b.py）：>>> import socket >>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> sock.connect(('localhost', 8888)) >>> host, port = sock.getsockname()[:2] >>> host, port ('127.0.0.1', 60589) 在上面的例子中，内核将临时端口 60589 分配给了你的套接字。在我开始回答我在第二部分中提出的问题之前，我还需要快速讲解一些概念。你很快就会明白这些概念为什么非常重要。这两个概念，一个是进程，另外一个是文件描述符。什么是进程？进程就是一个程序执行的实体。举个例子：当你的服务器代码被执行时，它会被载入内存，而内存中表现此次程序运行的实体就叫做进程。内核记录了进程的一系列有关信息——比如进程 ID——来追踪它的运行情况。当你在执行轮询服务器 webserver3a.py 或 webserver3b.py 时，你其实只是启动了一个进程。我们在终端窗口中运行 webserver3b.py：$ python webserver3b.py 在另一个终端窗口中，我们可以使用 ps 命令获取该进程的相关信息：$ ps | grep webserver3b | grep -v grep 7182 ttys003 0:00.04 python webserver3b.py ps 命令显示，我们刚刚只运行了一个 Python 进程 webserver3b.py。当一个进程被创建时，内核会为其分配一个进程 ID，也就是 PID。在 UNIX 中，所有用户进程都有一个父进程；当然，这个父进程也有进程 ID，叫做父进程 ID，缩写为 PPID。假设你默认使用 BASH shell，那当你启动服务器时，就会启动一个新的进程，同时被赋予一个 PID，而它的父进程 PID 会被设为 BASH shell 的 PID。自己尝试一下，看看这一切都是如何工作的。重新开启你的 Python shell，它会创建一个新进程，然后在其中使用系统调用 os.getpid() 及 os.getppid() 来获取 Python shell 进程的 PID 及其父进程 PID（也就是你的 BASH shell 的 PID）。然后，在另一个终端窗口中运行 ps 命令，然后用 grep 来查找 PPID（父进程 ID，在我的例子中是 3148）。在下面的屏幕截图中，你可以看到一个我的 Mac OS X 系统中关于进程父子关系的例子，在这个例子中，子进程是我的 Python shell 进程，而父进程是 BASH shell 进程：另外一个需要了解的概念，就是文件描述符。什么是文件描述符？文件描述符是一个非负整数，当进程打开一个现有文件、创建新文件或创建一个新的套接字时，内核会将这个数返回给进程。你以前可能听说过，在 UNIX 中，一切皆是文件。内核会按文件描述符来找到一个进程所打开的文件。当你需要读取文件或向文件写入时，我们同样通过文件描述符来定位这个文件。Python 提供了高层次的操作文件（或套接字）的对象，所以你不需要直接通过文件描述符来定位文件。但是，在高层对象之下，我们就是用它来在 UNIX 中定位文件及套接字，通过这个整数的文件描述符。一般情况下，UNIX shell 会将一个进程的标准输入流（STDIN）的文件描述符设为 0，标准输出流（STDOUT）设为 1，而标准错误打印（STDERR）的文件描述符会被设为 2。我之前提到过，即使 Python 提供了高层次的文件对象或类文件对象来供你操作，你仍然可以在对象上使用 fileno() 方法，来获取与该文件相关联的文件描述符。回到 Python shell 中，我们来看看你该怎么做到这一点：>>> import sys >>> sys.stdin <open file '<stdin>', mode 'r' at 0x102beb0c0> >>> sys.stdin.fileno() 0 >>> sys.stdout.fileno() 1 >>> sys.stderr.fileno() 2 当你在 Python 中操作文件及套接字时，你可能会使用高层次的文件/套接字对象，但是你仍然有可能会直接使用文件描述符。下面有一个例子，来演示如何用文件描述符做参数来进行一次写入的系统调用：>>> import sys >>> import os >>> res = os.write(sys.stdout.fileno(), 'hello\n') hello 下面是比较有趣的部分——不过你可能不会为此感到惊讶，因为你已经知道在 Unix 中，一切皆为文件——你的套接字对象同样有一个相关联的文件描述符。和刚才操纵文件时一样，当你在 Python 中创建一个套接字时，你会得到一个对象而不是一个非负整数，但你永远可以用我之前提到过的 fileno() 方法获取套接字对象的文件描述符，并可以通过这个文件描述符来直接操纵套接字。>>> import socket >>> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) >>> sock.fileno() 3 我还想再提一件事：不知道你有没有注意到，在我们的第二个轮询服务器 webserver3b.py 中，当你的服务器休眠 60 秒的过程中，你仍然可以通过第二个 curl 命令连接至服务器。当然 curl 命令并没有立刻输出任何内容而是挂在哪里，但是既然服务器没有接受连接，那它为什么不立即拒绝掉连接，而让它还能够继续与服务器建立连接呢？这个问题的答案是：当我在调用套接字对象的 listen 方法时，我为该方法提供了一个 BACKLOG 参数，在代码中用 REQUEST_QUEUE_SIZE 常量来表示。BACKLOG 参数决定了在内核中为存放即将到来的连接请求所创建的队列的大小。当服务器 webserver3b.py 在睡眠的时候，你运行的第二个 curl 命令依然能够连接至服务器，因为内核中用来存放即将接收的连接请求的队列依然拥有足够大的可用空间。尽管增大 BACKLOG 参数并不能神奇地使你的服务器同时处理多个请求，但当你的服务器很繁忙时，将它设置为一个较大的值还是相当重要的。这样，在你的服务器调用 accept 方法时，不需要再等待一个新的连接建立，而可以立刻直接抓取队列中的第一个客户端连接，并不加停顿地立刻处理它。欧耶！现在你已经了解了一大块内容。我们来快速回顾一下我们刚刚讲解的知识（当然，如果这些对你来说都是基础知识的话，那我们就当复习好啦）。轮询服务器服务端套接字创建流程（创建套接字，绑定，监听及接受）客户端连接创建流程（创建套接字，连接）套接字对套接字临时端口及通用端口进程进程 ID（PID），父进程 ID（PPID），以及进程父子关系文件描述符套接字的 listen 方法中，BACKLOG 参数的含义如何并发处理多个请求现在，我可以开始回答第二部分中的那个问题了：“你该如何让你的服务器在同一时间处理多个请求呢？”或者换一种说法：“如何编写一个并发服务器？”在 UNIX 系统中编写一个并发服务器最简单的方法，就是使用系统调用 fork()。下面是全新出炉的并发服务器 webserver3c.py 的代码，它可以同时处理多个请求（和我们之前的例子 webserver3b.py 一样，每个子进程都会休眠 60 秒）：####################################################### # 并发服务器 - webserver3c.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # # # # - 完成客户端请求处理之后，子进程会休眠 60 秒 # # - 父子进程会关闭重复的描述符 # # # ####################################################### import os import socket import time SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 5 def handle_request(client_connection): request = client_connection.recv(1024) print( 'Child PID: {pid}. Parent PID {ppid}'.format( pid=os.getpid(), ppid=os.getppid(), ) ) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) time.sleep(60) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) print('Parent PID (PPID): {pid}\n'.format(pid=os.getpid())) while True: client_connection, client_address = listen_socket.accept() pid = os.fork() if pid == 0: ### 子进程 listen_socket.close() ### 关闭子进程中复制的套接字对象 handle_request(client_connection) client_connection.close() os._exit(0) ### 子进程在这里退出 else: ### 父进程 client_connection.close() ### 关闭父进程中的客户端连接对象，并循环执行 if __name__ == '__main__': serve_forever() 在深入研究代码、讨论 fork 如何工作之前，先尝试运行它，自己看一看这个服务器是否真的可以同时处理多个客户端请求，而不是像轮询服务器 webserver3a.py 和 webserver3b.py 一样。在命令行中使用如下命令启动服务器：$ python webserver3c.py 然后，像我们之前测试轮询服务器那样，运行两个 curl 命令，来看看这次的效果。现在你可以看到，即使子进程在处理客户端请求后会休眠 60 秒，但它并不会影响其它客户端连接，因为他们都是由完全独立的进程来处理的。你应该看到你的 curl 命令立即输出了“Hello, World!”然后挂起 60 秒。你可以按照你的想法运行尽可能多的 curl 命令（好吧，并不能运行特别特别多 ^_^），所有的命令都会立刻输出来自服务器的响应 “Hello, World!”，并不会出现任何可被察觉到的延迟行为。试试看吧。如果你要理解 fork()，那最重要的一点是：你调用了它一次，但是它会返回两次 —— 一次在父进程中，另一次是在子进程中。当你创建了一个新进程，那么 fork() 在子进程中的返回值是 0。如果是在父进程中，那 fork() 函数会返回子进程的 PID。我依然记得在第一次看到它并尝试使用 fork() 的时候，我是多么的入迷。它在我眼里就像是魔法一样。这就好像我在读一段顺序执行的代码，然后“砰！”地一声，代码变成了两份，然后出现了两个实体，同时并行地运行相同的代码。讲真，那个时候我觉得它真的跟魔法一样神奇。当父进程创建出一个新的子进程时，子进程会复制从父进程中复制一份文件描述符：你可能注意到，在上面的代码中，父进程关闭了客户端连接：else: ### 父进程 client_connection.close() # 关闭父进程的副本并循环 不过，既然父进程关闭了这个套接字，那为什么子进程仍然能够从来自客户端的套接字中读取数据呢？答案就在上面的图片中。内核会使用描述符引用计数器来决定是否要关闭一个套接字。当你的服务器创建一个子进程时，子进程会复制父进程的所有文件描述符，内核中该描述符的引用计数也会增加。如果只有一个父进程及一个子进程，那客户端套接字的文件描述符引用数应为 2；当父进程关闭客户端连接的套接字时，内核只会减少它的引用计数，将其变为 1，但这仍然不会使内核关闭该套接字。子进程也关闭了父进程中 listen_socket 的复制实体，因为子进程不需要关注新的客户端连接，而只需要处理已建立的客户端连接中的请求。listen_socket.close() ### 关闭子进程中的复制实体 我们将会在后文中讨论，如果你不关闭那些重复的描述符，会发生什么。你可以从你的并发服务器源码中看到，父进程的主要职责为：接受一个新的客户端连接，复制出一个子进程来处理这个连接，然后继续循环来接受另外的客户端连接，仅此而已。服务器父进程并不会处理客户端连接——子进程才会做这件事。打个岔：当我们说两个事件并发执行时，我们所要表达的意思是什么？当我们说“两个事件并发执行”时，它通常意味着这两个事件同时发生。简单来讲，这个定义没问题，但你应该记住它的严格定义：如果你不能在代码中判断两个事件的发生顺序，那这两个事件就是并发执行的。（引自《信号系统简明手册 (第二版): 并发控制深入浅出及常见错误》）好的，现在你又该回顾一下你刚刚学过的知识点了。在 Unix 中，编写一个并发服务器的最简单的方式——使用 fork() 系统调用；当一个进程分叉（fork）出另一个进程时，它会变成刚刚分叉出的进程的父进程；在进行 fork 调用后，父进程和子进程共享相同的文件描述符；系统内核通过描述符的引用计数来决定是否要关闭该描述符对应的文件或套接字；服务器父进程的主要职责：现在它做的只是从客户端接受一个新的连接，分叉出子进程来处理这个客户端连接，然后开始下一轮循环，去接收新的客户端连接。进程分叉后不关闭重复的套接字会发生什么？我们来看看，如果我们不在父进程与子进程中关闭重复的套接字描述符会发生什么。下面是刚才的并发服务器代码的修改版本，这段代码（webserver3d.py 中，服务器不会关闭重复的描述符）：####################################################### # 并发服务器 - webserver3d.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ####################################################### import os import socket SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 5 def handle_request(client_connection): request = client_connection.recv(1024) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) clients = [] while True: client_connection, client_address = listen_socket.accept() ### 将引用存储起来，否则在下一轮循环时，他们会被垃圾回收机制销毁 clients.append(client_connection) pid = os.fork() if pid == 0: ### 子进程 listen_socket.close() ### 关闭子进程中多余的套接字 handle_request(client_connection) client_connection.close() os._exit(0) ### 子进程在这里结束 else: ### 父进程 # client_connection.close() print(len(clients)) if __name__ == '__main__': serve_forever() 用以下命令来启动服务器：$ python webserver3d.py 用 curl 命令连接服务器：$ curl http://localhost:8888/hello Hello, World! 好，curl 命令输出了来自并发服务器的响应内容，但程序并没有退出，而是仍然挂起。到底发生了什么？这个服务器并不会挂起 60 秒：子进程只处理客户端连接，关闭连接然后退出，但客户端的 curl 命令并没有终止。所以，为什么 curl 不终止呢？原因就在于文件描述符的副本。当子进程关闭客户端连接时，系统内核会减少客户端套接字的引用计数，将其变为 1。服务器子进程退出了，但客户端套接字并没有被内核关闭，因为该套接字的描述符引用计数并没有变为 0，所以，这就导致了连接终止包（在 TCP/IP 协议中称作 FIN）不会被发送到客户端，所以客户端会一直保持连接。这里也会出现另一个问题：如果你的服务器长时间运行，并且不关闭文件描述符的副本，那么可用的文件描述符会被消耗殆尽：使用 Control-C 关闭服务器 webserver3d.py，然后在 shell 中使用内置命令 ulimit 来查看系统默认为你的服务器进程分配的可用资源数：$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 3842 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 3842 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited 你可以从上面的结果看到，在我的 Ubuntu 机器中，系统为我的服务器进程分配的最大可用文件描述符（文件打开）数为 1024。现在我们来看一看，如果你的服务器不关闭重复的描述符，它会如何消耗可用的文件描述符。在一个已有的或新建的终端窗口中，将你的服务器进程的最大可用文件描述符设为 256：$ ulimit -n 256 在你刚刚运行 ulimit -n 256 的终端窗口中运行服务器 webserver3d.py：$ python webserver3d.py 然后使用下面的客户端 client3.py 来测试你的服务器。####################################################### # 测试客户端 - client3.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ####################################################### import argparse import errno import os import socket SERVER_ADDRESS = 'localhost', 8888 REQUEST = b"""\ GET /hello HTTP/1.1 Host: localhost:8888 """ def main(max_clients, max_conns): socks = [] for client_num in range(max_clients): pid = os.fork() if pid == 0: for connection_num in range(max_conns): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(SERVER_ADDRESS) sock.sendall(REQUEST) socks.append(sock) print(connection_num) os._exit(0) if __name__ == '__main__': parser = argparse.ArgumentParser( description='Test client for LSBAWS.', formatter_class=argparse.ArgumentDefaultsHelpFormatter, ) parser.add_argument( '--max-conns', type=int, default=1024, help='Maximum number of connections per client.' ) parser.add_argument( '--max-clients', type=int, default=1, help='Maximum number of clients.' ) args = parser.parse_args() main(args.max_clients, args.max_conns) 在一个新建的终端窗口中，运行 client3.py 然后让它与服务器同步创建 300 个连接：$ python client3.py --max-clients=300 过一会，你的服务器进程就该爆了。这是我的环境中出现的异常截图：这个例子很明显——你的服务器应该关闭描述符副本。僵尸进程但是，即使你关闭了描述符副本，你依然没有摆脱险境，因为你的服务器还有一个问题，这个问题在于“ 僵尸 （ zombies ） ”！没错，这个服务器代码确实在制造僵尸进程。我们来看看怎么回事。重新运行你的服务器：$ python webserver3d.py 在另一个终端窗口中运行以下 curl 命令：$ curl http://localhost:8888/hello 现在，运行 ps 环境，来查看正在运行的 Python 进程。下面是我的环境中 ps 的运行结果：$ ps auxw | grep -i python | grep -v grep vagrant 9099 0.0 1.2 31804 6256 pts/0 S+ 16:33 0:00 python webserver3d.py vagrant 9102 0.0 0.0 0 0 pts/0 Z+ 16:33 0:00 [python] <defunct> 你看到第二行中，pid 为 9102，状态为 Z+，名字里面有个 <defunct> 的进程了吗？那就是我们的僵尸进程。这个僵尸进程的问题在于：你无法将它杀掉！就算你尝试使用 kill -9 来杀死僵尸进程，它们仍旧会存活。自己试试看，看看结果。这个僵尸到底是什么，为什么我们的服务器会造出它们呢？一个 僵尸进程 （ zombie ） 是一个已经结束的进程，但它的父进程并没有等待（waited）它结束，并且也没有收到它的终结状态。如果一个进程在父进程退出之前退出，系统内核会把它变为一个僵尸进程，存储它的部分信息，以便父进程读取。内核保存的进程信息通常包括进程 ID、进程终止状态，以及进程的资源占用情况。OK，所以僵尸进程确实有存在的意义，但如果服务器不管这些僵尸进程，你的系统将会被壅塞。我们来看看这个会如何发生。首先，关闭你运行的服务器；然后，在一个新的终端窗口中，使用 ulimit 命令将最大用户进程数设为 400（同时，要确保你的最大可用描述符数大于这个数字，我们在这里设为 500）：$ ulimit -u 400 $ ulimit -n 500 在你刚刚运行 ulimit -u 400 命令的终端中，运行服务器 webserver3d.py：$ python webserver3d.py 在一个新的终端窗口中，运行 client3.py，并且让它与服务器同时创建 500 个连接：$ python client3.py --max-clients=500 然后，过一会，你的服务器进程应该会再次爆了，它会在创建新进程时抛出一个 OSError: 资源暂时不可用 的异常。但它并没有达到系统允许的最大进程数。这是我的环境中输出的异常信息截图：你可以看到，如果服务器不管僵尸进程，它们会引发问题。接下来我会简单探讨一下僵尸进程问题的解决方案。我们来回顾一下你刚刚掌握的知识点：如果你不关闭文件描述符副本，客户端就不会在请求处理完成后终止，因为客户端连接没有被关闭；如果你不关闭文件描述符副本，长久运行的服务器最终会把可用的文件描述符（最大文件打开数）消耗殆尽；当你创建一个新进程，而父进程不等待（wait）子进程，也不在子进程结束后收集它的终止状态，它会变为一个僵尸进程；僵尸通常都会吃东西，在我们的例子中，僵尸进程会吃掉资源。如果你的服务器不管僵尸进程，它最终会消耗掉所有的可用进程（最大用户进程数）；你不能杀死（kill）僵尸进程，你需要等待（wait）它。如何处理僵尸进程？所以，你需要做什么来处理僵尸进程呢？你需要修改你的服务器代码，来等待（wait）僵尸进程，并收集它们的终止信息。你可以在代码中使用系统调用 wait 来完成这个任务。不幸的是，这个方法离理想目标还很远，因为在没有终止的子进程存在的情况下调用 wait 会导致服务器进程阻塞，这会阻碍你的服务器处理新的客户端连接请求。那么，我们有其他选择吗？嗯，有的，其中一个解决方案需要结合信号处理以及 wait 系统调用。这是它的工作流程。当一个子进程退出时，内核会发送 SIGCHLD 信号。父进程可以设置一个信号处理器，它可以异步响应 SIGCHLD 信号，并在信号响应函数中等待（wait）子进程收集终止信息，从而阻止了僵尸进程的存在。顺便说一下，异步事件意味着父进程无法提前知道事件的发生时间。修改你的服务器代码，设置一个 SIGCHLD 信号处理器，在信号处理器中等待（wait）终止的子进程。修改后的代码如下（webserver3e.py）：####################################################### # 并发服务器 - webserver3e.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ####################################################### import os import signal import socket import time SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 5 def grim_reaper(signum, frame): pid, status = os.wait() print( 'Child {pid} terminated with status {status}' '\n'.format(pid=pid, status=status) ) def handle_request(client_connection): request = client_connection.recv(1024) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) ### 挂起进程，来允许父进程完成循环，并在 "accept" 处阻塞 time.sleep(3) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) signal.signal(signal.SIGCHLD, grim_reaper) while True: client_connection, client_address = listen_socket.accept() pid = os.fork() if pid == 0: ### 子进程 listen_socket.close() ### 关闭子进程中多余的套接字 handle_request(client_connection) client_connection.close() os._exit(0) else: ### 父进程 client_connection.close() if __name__ == '__main__': serve_forever() 运行服务器：$ python webserver3e.py 使用你的老朋友——curl 命令来向修改后的并发服务器发送一个请求：$ curl http://localhost:8888/hello 再来看看服务器：刚刚发生了什么？accept 调用失败了，错误信息为 EINTR。当子进程退出并触发 SIGCHLD 事件时，父进程的 accept 调用被阻塞了，系统转去运行信号处理器，当信号处理函数完成时，accept 系统调用被打断：别担心，这个问题很好解决。你只需要重新运行 accept 系统调用即可。这是修改后的服务器代码 webserver3f.py，它可以解决这个问题：####################################################### # 并发服务器 - webserver3f.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ####################################################### import errno import os import signal import socket SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 1024 def grim_reaper(signum, frame): pid, status = os.wait() def handle_request(client_connection): request = client_connection.recv(1024) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) signal.signal(signal.SIGCHLD, grim_reaper) while True: try: client_connection, client_address = listen_socket.accept() except IOError as e: code, msg = e.args ### 若 'accept' 被打断，那么重启它 if code == errno.EINTR: continue else: raise pid = os.fork() if pid == 0: ### 子进程 listen_socket.close() ### 关闭子进程中多余的描述符 handle_request(client_connection) client_connection.close() os._exit(0) else: ### 父进程 client_connection.close() ### 关闭父进程中多余的描述符，继续下一轮循环 if __name__ == '__main__': serve_forever() 运行更新后的服务器 webserver3f.py：$ python webserver3f.py 用 curl 来向更新后的并发服务器发送一个请求：$ curl http://localhost:8888/hello 看到了吗？没有 EINTR 异常出现了。现在检查一下，确保没有僵尸进程存活，调用 wait 函数的 SIGCHLD 信号处理器能够正常处理被终止的子进程。我们只需使用 ps 命令，然后看看现在没有处于 Z+ 状态（或名字包含 <defunct> ）的 Python 进程就好了。很棒！僵尸进程没有了，我们很安心。如果你创建了一个子进程，但是不等待它，它就会变成一个僵尸进程；使用 SIGCHLD 信号处理器可以异步地等待子进程终止，并收集其终止状态；当使用事件处理器时，你需要牢记，系统调用可能会被打断，所以你需要处理这种情况发生时带来的异常。正确处理 SIGCHLD 信号好的，一切顺利。是不是没问题了？额，几乎是。重新尝试运行 webserver3f.py 但我们这次不会只发送一个请求，而是同步创建 128 个连接：$ python client3.py --max-clients 128 现在再次运行 ps 命令：$ ps auxw | grep -i python | grep -v grep 看到了吗？天啊，僵尸进程又出来了！这回怎么回事？当你同时运行 128 个客户端，建立 128 个连接时，服务器的子进程几乎会在同一时间处理好你的请求，然后退出。这会导致非常多的 SIGCHLD 信号被发送到父进程。问题在于，这些信号不会存储在队列中，所以你的服务器进程会错过很多信号，这也就导致了几个僵尸进程处于无主状态：这个问题的解决方案依然是设置 SIGCHLD 事件处理器。但我们这次将会用 WNOHANG 参数循环调用 waitpid 来替代 wait，以保证所有处于终止状态的子进程都会被处理。下面是修改后的代码，webserver3g.py：####################################################### # 并发服务器 - webserver3g.py # # # # 使用 Python 2.7.9 或 3.4 # # 在 Ubuntu 14.04 及 Mac OS X 环境下测试通过 # ####################################################### import errno import os import signal import socket SERVER_ADDRESS = (HOST, PORT) = '', 8888 REQUEST_QUEUE_SIZE = 1024 def grim_reaper(signum, frame): while True: try: pid, status = os.waitpid( -1, ### 等待所有子进程 os.WNOHANG ### 无终止进程时，不阻塞进程，并抛出 EWOULDBLOCK 错误 ) except OSError: return if pid == 0: ### 没有僵尸进程存在了 return def handle_request(client_connection): request = client_connection.recv(1024) print(request.decode()) http_response = b"""\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) def serve_forever(): listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind(SERVER_ADDRESS) listen_socket.listen(REQUEST_QUEUE_SIZE) print('Serving HTTP on port {port} ...'.format(port=PORT)) signal.signal(signal.SIGCHLD, grim_reaper) while True: try: client_connection, client_address = listen_socket.accept() except IOError as e: code, msg = e.args ### 若 'accept' 被打断，那么重启它 if code == errno.EINTR: continue else: raise pid = os.fork() if pid == 0: ### 子进程 listen_socket.close() ### 关闭子进程中多余的描述符 handle_request(client_connection) client_connection.close() os._exit(0) else: ### 父进程 client_connection.close() ### 关闭父进程中多余的描述符，继续下一轮循环 if __name__ == '__main__': serve_forever() 运行服务器：$ python webserver3g.py 使用测试客户端 client3.py：$ python client3.py --max-clients 128 现在来查看一下，确保没有僵尸进程存在。耶！没有僵尸的生活真美好 ^_^。大功告成恭喜！你刚刚经历了一段很长的旅程，我希望你能够喜欢它。现在你拥有了自己的简易并发服务器，并且这段代码能够为你在继续研究生产级 Web 服务器的路上奠定基础。我将会留一个作业：你需要将第二部分中的 WSGI 服务器升级，将它改造为一个并发服务器。你可以在这里找到更改后的代码。但是，当你实现了自己的版本之后，你才应该来看我的代码。你已经拥有了实现这个服务器所需的所有信息。所以，快去实现它吧 ^_^。然后要做什么呢？乔希·比林斯说过：“就像一枚邮票一样——专注于一件事，不达目的不罢休。”开始学习基本知识。回顾你已经学过的知识。然后一步一步深入。“如果你只学会了方法，你将会被这些方法所困。但如果你学会了原理，那你就能发明出新的方法。”——拉尔夫·沃尔多·爱默生“有道无术，术尚可求也，有术无道，止于术”——中国古代也有这样的话，LCTT 译注下面是一份书单，我从这些书中提炼出了这篇文章所需的素材。他们能助你在我刚刚所述的几个方面中发掘出兼具深度和广度的知识。我极力推荐你们去搞到这几本书看看：从你的朋友那里借，在当地的图书馆中阅读，或者直接在亚马逊上把它买回来。下面是我的典藏秘籍：《UNIX 网络编程 卷1：套接字联网 API （第3版）》《UNIX 环境高级编程（第3版）》《Linux/UNIX 系统编程手册》《TCP/IP 详解 卷1：协议（第2版）《信号系统简明手册 (第二版): 并发控制深入浅出及常见错误》，这本书也可以从作者的个人网站中免费下载到。顺便，我在撰写一本名为《搭个 Web 服务器：从头开始》的书。这本书讲解了如何从头开始编写一个基本的 Web 服务器，里面包含本文中没有的更多细节。订阅原文下方的邮件列表，你就可以获取到这本书的最新进展，以及发布日期。via: https://ruslanspivak.com/lsbaws-part3/作者：Ruslan 译者：StdioA 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
在第一部分中，我提出了一个问题：“如何在你刚刚搭建起来的 Web 服务器上适配 Django, Flask 或 Pyramid 应用，而不用单独对 Web 服务器做做出改动以适应各种不同的 Web 框架呢？”我们可以从这一篇中找到答案。曾几何时，你所选择的 Python Web 框架会限制你所可选择的 Web 服务器，反之亦然。如果某个框架及服务器设计用来协同工作的，那么一切正常：但你可能正面对着（或者曾经面对过）尝试将一对无法适配的框架和服务器搭配在一起的问题：基本上，你需要选择那些能够一起工作的框架和服务器，而不能选择你想用的那些。所以，你该如何确保在不对 Web 服务器或框架的代码做任何更改的情况下，让你的 Web 服务器和多个不同的 Web 框架一同工作呢？这个问题的答案，就是 Python Web 服务器网关接口 （ Web Server Gateway Interface ） （缩写为 WSGI，念做“wizgy”）。WSGI 允许开发者互不干扰地选择 Web 框架及 Web 服务器的类型。现在，你可以真正将 Web 服务器及框架任意搭配，然后选出你最中意的那对组合。比如，你可以使用 Django，Flask 或者 Pyramid，与 Gunicorn，Nginx/uWSGI 或 Waitress 进行结合。感谢 WSGI 同时对服务器与框架的支持，我们可以真正随意选择它们的搭配了。所以，WSGI 就是我在第一部分中提出，又在本文开头重复了一遍的那个问题的答案。你的 Web 服务器必须实现 WSGI 接口的服务器部分，而现代的 Python Web 框架均已实现了 WSGI 接口的框架部分，这使得你可以直接在 Web 服务器中使用任意框架，而不需要更改任何服务器代码，以对特定的 Web 框架实现兼容。现在，你已经知道 Web 服务器及 Web 框架对 WSGI 的支持使得你可以选择最合适的一对来使用，而且它也有利于服务器和框架的开发者，这样他们只需专注于其擅长的部分来进行开发，而不需要触及另一部分的代码。其它语言也拥有类似的接口，比如：Java 拥有 Servlet API，而 Ruby 拥有 Rack。这些理论都不错，但是我打赌你在说：“Show me the code!” 那好，我们来看看下面这个很小的 WSGI 服务器实现：### 使用 Python 2.7.9，在 Linux 及 Mac OS X 下测试通过 import socket import StringIO import sys class WSGIServer(object): address_family = socket.AF_INET socket_type = socket.SOCK_STREAM request_queue_size = 1 def __init__(self, server_address): ### 创建一个监听的套接字 self.listen_socket = listen_socket = socket.socket( self.address_family, self.socket_type ) ### 允许复用同一地址 listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) ### 绑定地址 listen_socket.bind(server_address) ### 激活套接字 listen_socket.listen(self.request_queue_size) ### 获取主机的名称及端口 host, port = self.listen_socket.getsockname()[:2] self.server_name = socket.getfqdn(host) self.server_port = port ### 返回由 Web 框架/应用设定的响应头部字段 self.headers_set = [] def set_app(self, application): self.application = application def serve_forever(self): listen_socket = self.listen_socket while True: ### 获取新的客户端连接 self.client_connection, client_address = listen_socket.accept() ### 处理一条请求后关闭连接，然后循环等待另一个连接建立 self.handle_one_request() def handle_one_request(self): self.request_data = request_data = self.client_connection.recv(1024) ### 以 'curl -v' 的风格输出格式化请求数据 print(''.join( '< {line}\n'.format(line=line) for line in request_data.splitlines() )) self.parse_request(request_data) ### 根据请求数据构建环境变量字典 env = self.get_environ() ### 此时需要调用 Web 应用来获取结果， ### 取回的结果将成为 HTTP 响应体 result = self.application(env, self.start_response) ### 构造一个响应，回送至客户端 self.finish_response(result) def parse_request(self, text): request_line = text.splitlines()[0] request_line = request_line.rstrip(' ') ### 将请求行分成几个部分 (self.request_method, # GET self.path, # /hello self.request_version # HTTP/1.1 ) = request_line.split() def get_environ(self): env = {} ### 以下代码段没有遵循 PEP8 规则，但这样排版，是为了通过强调 ### 所需变量及它们的值，来达到其展示目的。 ### ### WSGI 必需变量 env['wsgi.version'] = (1, 0) env['wsgi.url_scheme'] = 'http' env['wsgi.input'] = StringIO.StringIO(self.request_data) env['wsgi.errors'] = sys.stderr env['wsgi.multithread'] = False env['wsgi.multiprocess'] = False env['wsgi.run_once'] = False ### CGI 必需变量 env['REQUEST_METHOD'] = self.request_method # GET env['PATH_INFO'] = self.path # /hello env['SERVER_NAME'] = self.server_name # localhost env['SERVER_PORT'] = str(self.server_port) # 8888 return env def start_response(self, status, response_headers, exc_info=None): ### 添加必要的服务器头部字段 server_headers = [ ('Date', 'Tue, 31 Mar 2015 12:54:48 GMT'), ('Server', 'WSGIServer 0.2'), ] self.headers_set = [status, response_headers + server_headers] ### 为了遵循 WSGI 协议，start_response 函数必须返回一个 'write' ### 可调用对象（返回值.write 可以作为函数调用）。为了简便，我们 ### 在这里无视这个细节。 ### return self.finish_response def finish_response(self, result): try: status, response_headers = self.headers_set response = 'HTTP/1.1 {status} '.format(status=status) for header in response_headers: response += '{0}: {1} '.format(*header) response += ' ' for data in result: response += data ### 以 'curl -v' 的风格输出格式化请求数据 print(''.join( '> {line}\n'.format(line=line) for line in response.splitlines() )) self.client_connection.sendall(response) finally: self.client_connection.close() SERVER_ADDRESS = (HOST, PORT) = '', 8888 def make_server(server_address, application): server = WSGIServer(server_address) server.set_app(application) return server if __name__ == '__main__': if len(sys.argv) < 2: sys.exit('Provide a WSGI application object as module:callable') app_path = sys.argv[1] module, application = app_path.split(':') module = __import__(module) application = getattr(module, application) httpd = make_server(SERVER_ADDRESS, application) print('WSGIServer: Serving HTTP on port {port} ...\n'.format(port=PORT)) httpd.serve_forever() 当然，这段代码要比第一部分的服务器代码长不少，但它仍然很短（只有不到 150 行），你可以轻松理解它，而不需要深究细节。上面的服务器代码还可以做更多——它可以用来运行一些你喜欢的框架写出的 Web 应用，可以是 Pyramid，Flask，Django 或其它 Python WSGI 框架。不相信吗？自己来试试看吧。把以上的代码保存为 webserver2.py，或直接从 Github 上下载它。如果你打算不加任何参数而直接运行它，它会抱怨一句，然后退出。$ python webserver2.py Provide a WSGI application object as module:callable 它想做的其实是为你的 Web 应用服务，而这才是重头戏。为了运行这个服务器，你唯一需要的就是安装好 Python。不过，如果你希望运行 Pyramid，Flask 或 Django 应用，你还需要先安装那些框架。那我们把这三个都装上吧。我推荐的安装方式是通过 virtualenv 安装。按照以下几步来做，你就可以创建并激活一个虚拟环境，并在其中安装以上三个 Web 框架。$ [sudo] pip install virtualenv $ mkdir ~/envs $ virtualenv ~/envs/lsbaws/ $ cd ~/envs/lsbaws/ $ ls bin include lib $ source bin/activate (lsbaws) $ pip install pyramid (lsbaws) $ pip install flask (lsbaws) $ pip install django 现在，你需要创建一个 Web 应用。我们先从 Pyramid 开始吧。把以下代码保存为 pyramidapp.py，并与刚刚的 webserver2.py 放置在同一目录，或直接从 Github 下载该文件：from pyramid.config import Configurator from pyramid.response import Response def hello_world(request): return Response( 'Hello world from Pyramid!\n', content_type='text/plain', ) config = Configurator() config.add_route('hello', '/hello') config.add_view(hello_world, route_name='hello') app = config.make_wsgi_app() 现在，你可以用你自己的 Web 服务器来运行你的 Pyramid 应用了：(lsbaws) $ python webserver2.py pyramidapp:app WSGIServer: Serving HTTP on port 8888 ... 你刚刚让你的服务器去加载 Python 模块 pyramidapp 中的可执行对象 app。现在你的服务器可以接收请求，并将它们转发到你的 Pyramid 应用中了。在浏览器中输入 http://localhost:8888/hello ，敲一下回车，然后看看结果：你也可以使用命令行工具 curl 来测试服务器：$ curl -v http://localhost:8888/hello ... 看看服务器和 curl 向标准输出流打印的内容吧。现在来试试 Flask。运行步骤跟上面的一样。from flask import Flask from flask import Response flask_app = Flask('flaskapp') @flask_app.route('/hello') def hello_world(): return Response( 'Hello world from Flask!\n', mimetype='text/plain' ) app = flask_app.wsgi_app 将以上代码保存为 flaskapp.py，或者直接从 Github 下载，然后输入以下命令运行服务器：(lsbaws) $ python webserver2.py flaskapp:app WSGIServer: Serving HTTP on port 8888 ... 现在在浏览器中输入 http://localhost:8888/hello ，敲一下回车：同样，尝试一下 curl，然后你会看到服务器返回了一条 Flask 应用生成的信息：$ curl -v http://localhost:8888/hello ... 这个服务器能处理 Django 应用吗？试试看吧！不过这个任务可能有点复杂，所以我建议你将整个仓库克隆下来，然后使用 Github 仓库中的 djangoapp.py 来完成这个实验。这里的源代码主要是将 Django 的 helloworld 工程（已使用 Django 的 django-admin.py startproject 命令创建完毕）添加到了当前的 Python 路径中，然后导入了这个工程的 WSGI 应用。（LCTT 译注：除了这里展示的代码，还需要一个配合的 helloworld 工程才能工作，代码可以参见 Github 仓库。）import sys sys.path.insert(0, './helloworld') from helloworld import wsgi app = wsgi.application 将以上代码保存为 djangoapp.py，然后用你的 Web 服务器运行这个 Django 应用：(lsbaws) $ python webserver2.py djangoapp:app WSGIServer: Serving HTTP on port 8888 ... 输入以下链接，敲回车：你这次也可以在命令行中测试——你之前应该已经做过两次了——来确认 Django 应用处理了你的请求：$ curl -v http://localhost:8888/hello ... 你试过了吗？你确定这个服务器可以与那三个框架搭配工作吗？如果没试，请去试一下。阅读固然重要，但这个系列的内容是重新搭建，这意味着你需要亲自动手干点活。去试一下吧。别担心，我等着你呢。不开玩笑，你真的需要试一下，亲自尝试每一步，并确保它像预期的那样工作。好，你已经体验到了 WSGI 的威力：它可以使 Web 服务器及 Web 框架随意搭配。WSGI 在 Python Web 服务器及框架之间提供了一个微型接口。它非常简单，而且在服务器和框架端均可以轻易实现。下面的代码片段展示了 WSGI 接口的服务器及框架端实现：def run_application(application): """服务器端代码。""" ### Web 应用/框架在这里存储 HTTP 状态码以及 HTTP 响应头部， ### 服务器会将这些信息传递给客户端 headers_set = [] ### 用于存储 WSGI/CGI 环境变量的字典 environ = {} def start_response(status, response_headers, exc_info=None): headers_set[:] = [status, response_headers] ### 服务器唤醒可执行变量“application”，获得响应头部 result = application(environ, start_response) ### 服务器组装一个 HTTP 响应，将其传送至客户端 … def app(environ, start_response): """一个空的 WSGI 应用""" start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Hello world!'] run_application(app) 这是它的工作原理：Web 框架提供一个可调用对象 application （WSGI 规范没有规定它的实现方式）。Web 服务器每次收到来自客户端的 HTTP 请求后，会唤醒可调用对象 applition。它会向该对象传递一个包含 WSGI/CGI 变量的环境变量字典 environ，以及一个可调用对象 start_response。Web 框架或应用生成 HTTP 状态码和 HTTP 响应头部，然后将它传给 start_response 函数，服务器会将其存储起来。同时，Web 框架或应用也会返回 HTTP 响应正文。服务器将状态码、响应头部及响应正文组装成一个 HTTP 响应，然后将其传送至客户端（这一步并不在 WSGI 规范中，但从逻辑上讲，这一步应该包含在工作流程之中。所以为了明确这个过程，我把它写了出来）这是这个接口规范的图形化表达：到现在为止，你已经看过了用 Pyramid、Flask 和 Django 写出的 Web 应用的代码，你也看到了一个 Web 服务器如何用代码来实现另一半（服务器端的） WSGI 规范。你甚至还看到了我们如何在不使用任何框架的情况下，使用一段代码来实现一个最简单的 WSGI Web 应用。其实，当你使用上面的框架编写一个 Web 应用时，你只是在较高的层面工作，而不需要直接与 WSGI 打交道。但是我知道你一定也对 WSGI 接口的框架部分感兴趣，因为你在看这篇文章呀。所以，我们不用 Pyramid、Flask 或 Django，而是自己动手来创造一个最朴素的 WSGI Web 应用（或 Web 框架），然后将它和你的服务器一起运行：def app(environ, start_response): """一个最简单的 WSGI 应用。 这是你自己的 Web 框架的起点 ^_^ """ status = '200 OK' response_headers = [('Content-Type', 'text/plain')] start_response(status, response_headers) return ['Hello world from a simple WSGI application!\n'] 同样，将上面的代码保存为 wsgiapp.py 或直接从 Github 上下载该文件，然后在 Web 服务器上运行这个应用，像这样：(lsbaws) $ python webserver2.py wsgiapp:app WSGIServer: Serving HTTP on port 8888 ... 在浏览器中输入下面的地址，然后按下回车。这是你应该看到的结果：你刚刚在学习如何创建一个 Web 服务器的过程中自己编写了一个最朴素的 WSGI Web 框架！棒极了！现在，我们再回来看看服务器传给客户端的那些东西。这是在使用 HTTP 客户端调用你的 Pyramid 应用时，服务器生成的 HTTP 响应内容：这个响应和你在本系列第一部分中看到的 HTTP 响应有一部分共同点，但它还多出来了一些内容。比如说，它拥有四个你曾经没见过的 HTTP 头部：Content-Type, Content-Length, Date 以及 Server。这些头部内容基本上在每个 Web 服务器返回的响应中都会出现。不过，它们都不是被严格要求出现的。这些 HTTP 请求/响应头部字段的目的在于它可以向你传递一些关于 HTTP 请求/响应的额外信息。既然你对 WSGI 接口了解的更深了一些，那我再来展示一下上面那个 HTTP 响应中的各个部分的信息来源：我现在还没有对上面那个 environ 字典做任何解释，不过基本上这个字典必须包含那些被 WSGI 规范事先定义好的 WSGI 及 CGI 变量值。服务器在解析 HTTP 请求时，会从请求中获取这些变量的值。这是 environ 字典应该有的样子：Web 框架会利用以上字典中包含的信息，通过字典中的请求路径、请求动作等等来决定使用哪个视图来处理响应、在哪里读取请求正文、在哪里输出错误信息（如果有的话）。现在，你已经创造了属于你自己的 WSGI Web 服务器，你也使用不同 Web 框架做了几个 Web 应用。而且，你在这个过程中也自己创造出了一个朴素的 Web 应用及框架。这个过程真是累人。现在我们来回顾一下，你的 WSGI Web 服务器在服务请求时，需要针对 WSGI 应用做些什么：首先，服务器开始工作，然后会加载一个可调用对象 application，这个对象由你的 Web 框架或应用提供然后，服务器读取一个请求然后，服务器会解析这个请求然后，服务器会使用请求数据来构建一个 environ 字典然后，它会用 environ 字典及一个可调用对象 start_response 作为参数，来调用 application，并获取响应体内容。然后，服务器会使用 application 返回的响应体，和 start_response 函数设置的状态码及响应头部内容，来构建一个 HTTP 响应。最终，服务器将 HTTP 响应回送给客户端。这基本上是服务器要做的全部内容了。你现在有了一个可以正常工作的 WSGI 服务器，它可以为使用任何遵循 WSGI 规范的 Web 框架（如 Django、Flask、Pyramid，还有你刚刚自己写的那个框架）构建出的 Web 应用服务。最棒的部分在于，它可以在不用更改任何服务器代码的情况下，与多个不同的 Web 框架一起工作。真不错。在结束之前，你可以想想这个问题：“你该如何让你的服务器在同一时间处理多个请求呢？”敬请期待，我会在第三部分向你展示一种解决这个问题的方法。干杯！顺便，我在撰写一本名为《搭个 Web 服务器：从头开始》的书。这本书讲解了如何从头开始编写一个基本的 Web 服务器，里面包含本文中没有的更多细节。订阅邮件列表，你就可以获取到这本书的最新进展，以及发布日期。via: https://ruslanspivak.com/lsbaws-part2/作者：Ruslan 译者：StdioA 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
一天，有一个正在散步的妇人恰好路过一个建筑工地，看到三个正在工作的工人。她问第一个人：“你在做什么？”第一个人没好气地喊道：“你没看到我在砌砖吗？”妇人对这个答案不满意，于是问第二个人：“你在做什么？”第二个人回答说：“我在建一堵砖墙。”说完，他转向第一个人，跟他说：“嗨，你把墙砌过头了。去把刚刚那块砖弄下来！”然而，妇人对这个答案依然不满意，于是又问了第三个人相同的问题。第三个人仰头看着天，对她说：“我在建造世界上最大的教堂。”当他回答时，第一个人和第二个人在为刚刚砌错的砖而争吵。他转向那两个人，说：“不用管那块砖了。这堵墙在室内，它会被水泥填平，没人会看见它的。去砌下一层吧。”这个故事告诉我们：如果你能够理解整个系统的构造，了解系统的各个部件如何相互结合（如砖、墙还有整个教堂），你就能够更快地定位及修复问题（那块砌错的砖）。如果你想从头开始创造一个 Web 服务器，那么你需要做些什么呢？我相信，如果你想成为一个更好的开发者，你必须对日常使用的软件系统的内部结构有更深的理解，包括编程语言、编译器与解释器、数据库及操作系统、Web 服务器及 Web 框架。而且，为了更好更深入地理解这些系统，你必须从头开始，用一砖一瓦来重新构建这个系统。荀子曾经用这几句话来表达这种思想：“ 不闻不若闻之。 （ I hear and I forget. ） ”“ 闻之不若见之。 （ I see and I remember. ） ”“ 知之不若行之。 （ I do and I understand. ） ”我希望你现在能够意识到，重新建造一个软件系统来了解它的工作方式是一个好主意。在这个由三篇文章组成的系列中，我将会教你构建你自己的 Web 服务器。我们开始吧~先说首要问题：Web 服务器是什么？简而言之，它是一个运行在一个物理服务器上的网络服务器（啊呀，服务器套服务器），等待客户端向其发送请求。当它接收请求后，会生成一个响应，并回送至客户端。客户端和服务端之间通过 HTTP 协议来实现相互交流。客户端可以是你的浏览器，也可以是使用 HTTP 协议的其它任何软件。最简单的 Web 服务器实现应该是什么样的呢？这里我给出我的实现。这个例子由 Python 写成，即使你没听说过 Python（它是一门超级容易上手的语言，快去试试看！），你也应该能够从代码及注释中理解其中的理念：import socket HOST, PORT = '', 8888 listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listen_socket.bind((HOST, PORT)) listen_socket.listen(1) print 'Serving HTTP on port %s ...' % PORT while True: client_connection, client_address = listen_socket.accept() request = client_connection.recv(1024) print request http_response = """\ HTTP/1.1 200 OK Hello, World! """ client_connection.sendall(http_response) client_connection.close() 将以上代码保存为 webserver1.py，或者直接从 GitHub 上下载这个文件。然后，在命令行中运行这个程序。像这样：$ python webserver1.py Serving HTTP on port 8888 … 现在，在你的网页浏览器的地址栏中输入 URL：http://localhost:8888/hello ，敲一下回车，然后来见证奇迹。你应该看到“Hello, World!”显示在你的浏览器中，就像下图那样：说真的，快去试一试。你做实验的时候，我会等着你的。完成了？不错！现在我们来讨论一下它实际上是怎么工作的。首先我们从你刚刚输入的 Web 地址开始。它叫 URL，这是它的基本结构：URL 是一个 Web 服务器的地址，浏览器用这个地址来寻找并连接 Web 服务器，并将上面的内容返回给你。在你的浏览器能够发送 HTTP 请求之前，它需要与 Web 服务器建立一个 TCP 连接。然后会在 TCP 连接中发送 HTTP 请求，并等待服务器返回 HTTP 响应。当你的浏览器收到响应后，就会显示其内容，在上面的例子中，它显示了“Hello, World!”。我们来进一步探索在发送 HTTP 请求之前，客户端与服务器建立 TCP 连接的过程。为了建立链接，它们使用了所谓“ 套接字 （ socket ） ”。我们现在不直接使用浏览器发送请求，而在命令行中使用 telnet 来人工模拟这个过程。在你运行 Web 服务器的电脑上，在命令行中建立一个 telnet 会话，指定一个本地域名，使用端口 8888，然后按下回车：$ telnet localhost 8888 Trying 127.0.0.1 … Connected to localhost. 这个时候，你已经与运行在你本地主机的服务器建立了一个 TCP 连接。在下图中，你可以看到一个服务器从头开始，到能够建立 TCP 连接的基本过程。在同一个 telnet 会话中，输入 GET /hello HTTP/1.1，然后输入回车：$ telnet localhost 8888 Trying 127.0.0.1 … Connected to localhost. GET /hello HTTP/1.1 HTTP/1.1 200 OK Hello, World! 你刚刚手动模拟了你的浏览器（的工作）！你发送了 HTTP 请求，并且收到了一个 HTTP 应答。下面是一个 HTTP 请求的基本结构：HTTP 请求的第一行由三部分组成：HTTP 方法（GET，因为我们想让我们的服务器返回一些内容），以及标明所需页面的路径 /hello，还有协议版本。为了简单一些，我们刚刚构建的 Web 服务器完全忽略了上面的请求内容。你也可以试着输入一些无用内容而不是“GET /hello HTTP/1.1”，但你仍然会收到一个“Hello, World!”响应。一旦你输入了请求行并敲了回车，客户端就会将请求发送至服务器；服务器读取请求行，就会返回相应的 HTTP 响应。下面是服务器返回客户端（在上面的例子里是 telnet）的响应内容：我们来解析它。这个响应由三部分组成：一个状态行 HTTP/1.1 200 OK，后面跟着一个空行，再下面是响应正文。HTTP 响应的状态行 HTTP/1.1 200 OK 包含了 HTTP 版本号，HTTP 状态码以及 HTTP 状态短语“OK”。当浏览器收到响应后，它会将响应正文显示出来，这也就是为什么你会在浏览器中看到“Hello, World!”。以上就是 Web 服务器的基本工作模型。总结一下：Web 服务器创建一个处于监听状态的套接字，循环接收新的连接。客户端建立 TCP 连接成功后，会向服务器发送 HTTP 请求，然后服务器会以一个 HTTP 响应做应答，客户端会将 HTTP 的响应内容显示给用户。为了建立 TCP 连接，客户端和服务端均会使用套接字。现在，你应该了解了 Web 服务器的基本工作方式，你可以使用浏览器或其它 HTTP 客户端进行试验。如果你尝试过、观察过，你应该也能够使用 telnet，人工编写 HTTP 请求，成为一个“人形” HTTP 客户端。现在留一个小问题：“你要如何在不对程序做任何改动的情况下，在你刚刚搭建起来的 Web 服务器上适配 Django, Flask 或 Pyramid 应用呢？”我会在本系列的第二部分中来详细讲解。敬请期待。顺便，我在撰写一本名为《搭个 Web 服务器：从头开始》的书。这本书讲解了如何从头开始编写一个基本的 Web 服务器，里面包含本文中没有的更多细节。订阅邮件列表，你就可以获取到这本书的最新进展，以及发布日期。via: https://ruslanspivak.com/lsbaws-part1/作者：Ruslan 译者：StdioA 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出