Tracker 服务器源码分析之三：HTTPHandler 类

上一篇我们讲到， RawServer 只负责网络 I/O，也就是从网络上读取和发送数据，至于读到的数据如何分析，以及应该发送什么样的数据，则交给 Handler 类来处理。如果是用 c++ 来实现的话，那么 Handler 应该是一个接口类（提供几个虚函数作为接口），但是 python 动态语言的特性，并不需要专门定义这么一个接口类，所以实际上并没有 Handler 这么一个类。任何一个提供了以下成员函数的类，都可以作为一个 Handler 类来与 RawServer 配合，它们是：

external_connection_made()：在建立新的连接的时候被调用

data_came_in()：连接上有数据可读的时候被调用

connection_flushed()：当在某个连接上发送完数据之后被调用

       HTTPHandler 就是这样一个 Handler 类，它具备以上接口。

       HTTPHandler 代码很少，因为它把主要工作又交给 HTTPConnection 了。

       我们看 HTTPHandler 类的这几个函数：

l         external_connection_made()：

每当新来一个连接的时候，就创建一个 HTTPConnection 类。

l         data_came_in()：

当连接上有数据可读的时候，调用 HTTPConnection::data_came_in()。我们接下去看HTTPConnection::data_came_in()。

我们知道，BT client端与 tracker服务器之间是通过tracke HTTP 协议来进行通信的。HTTP协议分为请求（request）和响应（response），具体的协议请看相关的 RFC 文档。我这里简单讲一下。

对 tracke 服务器来说，它读到的数据是 client 端的HTTP 请求。

HTTP请求以行为单位，行的结束符是“回车换行”，也就是 ascii 字符 “\r”和“\n”。

第一行是请求的 URL，例如：

GET              /announce?ip=aaaaa;port=bbbbbbb       HTTP/1.0

这行数据被空格分为三部分，

第一部分GET表示命令，其它命令还有POST、HEAD等等，常用的就是GET了。

第二部分是请求的URL，这里是 /announce?ip=aaaaa;port=bbbbbbb。如果是普通的上网浏览网页，那么URL 就是我们要看的网页在该web服务器上的相对路径。但是，这里的URL仅仅是交互信息的一种方式，client 端把要报告给 tracker 的信息，放在URL中，例子里面是 ip 和 port，更详细的信息请看“BT协议规范”中 tracker 协议部分。

第三部分是HTTP协议的版本号，在程序中忽略。

接下来的每一行，都是HTTP协议的消息头部分，例如：

Host:www.sina.com.cn

Accept-encoding:gzip

通过消息头，tracker服务器可以知道 client端的一些信息，这其中比较重要的就是 Accept-encoding，如果是 gzip ，那么说明 client 可以对 gzip 格式的数据进行解压，那么tracker服务器就可以考虑用 gzip 把响应数据压缩之后再传回去，以减少网络流量。我们可以在代码中看到相应的处理。

在消息头的最后，是一个空行，表示消息头结束了。对GET和HEAD命令来说，消息头的结束，也就意味着整个client端的请求结束了。而对 POST 命令来说，可能后面还跟着其它数据。由于我们的 tracker服务器只接受 GET 和 HEAD 命令，所以在协议处理过程中，如果遇到空行，那么就表示处理结束。

HTTPConnection::data_came_in() 用一个循环来进行协议分析：

首先是寻找行结束符号：

i = self.buf.index('\n')

（我认为仅仅找 “\n”并不严谨，应该找 “\r\n”这个序列）。

如果没有找到，那么 index() 函数会抛出一个异常，而异常的处理是返回 True，表示数据不够，需要继续读数据。

如果找到了，那么 i  之前的字符串就是完整的一行。于是调用协议处理函数，代码是：

self.next_func = self.next_func(val)

在 HTTPConnection 的初始化的时候，有这么一行代码：

self.next_func = self.read_type

next_func 是用来保存协议处理函数的，所以，第一个被调用的协议处理函数就是 read_type()。它用来分析client端请求的第一行。在 read_type() 的最后，我们看到：

return self.read_header

这样，在下一次调用 next_func 的时候，就是调用 read_header()了，也就是对 HTTP 协议的消息头进行分析。

下面先看 read_type()，

它首先把 GET 命令中的 URL 部分保存到 self.path中，因为这是 client端最关键的信息，后面要用到。

然后检查一下是否是GET或者HEAD命令，如果不是，那么说明数据有错误。返回None，否则return self.read_header

接下来我们看read_header()，

这其中，最重要的就是对空行的处理，因为前面说了，空行表示协议分析结束。

在检查完 client 端是否支持 gzip 编码之后，调用：

r = self.handler.getfunc(self, self.path, self.headers)

通过一层层往后追查，发现 getfunc() 实际是 Tracker::get()，也就是说，真正对 client 端发来的请求进行分析，以及决定如何响应，是由 Tracker 来决定的。是的，这个 Tracker 在我们tracker 服务器源码分析系列的第一篇文章中就已经看到了。在创建 RawServer 之后，马上就创建了一个 Tracker 对象。所以，要了解 tracker 服务器到底是如何工作的，需要我们深入进去分析 Tracker 类，那就是我们下一篇文章的工作了。

在调用完 Tracker::get() 之后，返回的是决定响应给 client 端的数据，

if r is not None:

self.answer(r)

最后，调用 answer() 来把这些数据发送给 client 端。

对 answer() 的分析，我们在下一篇分析 Tracker类的文章中一并讲解。

l         connection_flushed()：

tracker服务器用的是非阻塞的网络 I/O ，所以不能保证在一次发送数据的操作中，把要发送的数据全部发送出去。

这个函数，检查在某个连接上需要发送的数据，是否已经全部被发送出去了，如果是的话，那么关闭这个连接的发送端。（为什么仅仅关闭发送端，而不是完全关闭这个连接了？疑惑）。