wifidog自带http服务器wiLighttpd1.4.20源码分析之状态机（4） 错误处理和连接关闭
Lighttpd所要处理的错误分为两种。一种是http协议规定的错误，如404错误。另一种就是服务器运行过程中的错误，如write错误。
对于http协议规定的错误，lighttpd返回相应的错误提示文件。其实对于lighttpd而言，这不算错误。在返回错误提示文件后，相当于顺利的完成了一次请求，只是结果和客户端想要的不一样而已。
对于服务器运行中的错误，状态机会直接进入CON_STATE_ERROR状态。大部分的情况下，这种错误都是由客户端提前断开连接所造成的。比如你不停的刷新页面，在你刷新的时候，前一次的连接没有完成，但被浏览器强行断开，这时，服务器就会出现连接错误。对于服务器而言，刷新前后的两个连接是不相干的。因此，服务器在接收后一个连接的时候仍然会继续处理前一次的连接。而这时前一次的连接已经断开，这就产生了连接错误。
进入CON_STATE_ERROR状态后，如果前面的处理已经得到了结果。也就是http_status不为空。那么调用plugins_call_handle_request_done告诉插件请求处理结束。
/*
* even if the connection was drop we still have to write it to the
* access log
*/
if (con->http_status)
{
plugins_call_handle_request_done(srv, con);
}
接着，如果使用了ssl，关闭ssl连接。关闭ssl连接的代码很长，但大部分都是错误处理。再朝后，如果连接模式不是DIRECT，调用plugins_call_handle_connection_close告诉插件连接已经关闭。到此，如果连接没有设置keep_alive，那么关闭连接并做一些清理工作之后就直接结束状态机的运行了。
如果设置了keep_alive，此时可能是服务器首先关闭连接的。调用shutdown关闭连接的读和写。如果关闭没有出错，状态机进入CON_STATE_CLOSE状态。
/*
* close the connection
*/
if ((con->keep_alive == 1) && (0 == shutdown(con->fd, SHUT_WR)))
{
con->close_timeout_ts = srv->cur_ts;
connection_set_state(srv, con, CON_STATE_CLOSE);、
if (srv->srvconf.log_state_handling)
{
log_error_write(srv, __FILE__, __LINE__, "sd",
"shutdown for fd", con->fd);
}
}
上面的代码中有这么一句：con->close_timeout_ts = srv->cur_ts;将close_timeout_ts的值设置为当前时间。这时干吗用的？不着急，继续完后走。
进入CON_STATE_ERROR状态之后，如果是keep_alive，且缓冲区中有数据还没读，那么把这些数据读出来然后直接丢弃。如果没有数据可读，直接设置close_time_ts为0。接着执行下面的代码：
if (srv->cur_ts - con->close_timeout_ts > 1)
{
connection_close(srv, con);
if (srv->srvconf.log_state_handling)
{
log_error_write(srv, __FILE__, __LINE__, "sd", "connection closed for fd", con->fd);
}
}
除了输出日志，这段代码就是调用了connection_close。connection_close做最后的清理工作，包括调用close，将对应的connection放回缓冲池中等。前面刚刚说过，在CON_STATE_ERROR中设置了close_time_ts为cur_ts。在出了CON_STATE_ERROR后，进入CON_STATE_CLOSE，这段时间cur_ts是没有改变的。如果前面的代码中测试缓冲区中没有数据可读，此时const_time_ts是等于cur_ts。也就是说状态机还在CON_CLOSE_STATE这个状态，然后就退出了状态机的大while循环。服务器进入了connection_state_mechine最后面的那个switch语句。在这个switch中，连接对应的fd被加入到fdevent系统中并监听读入事件。
这个时候连接都已经关闭了还有什么能读的啊？别急！细心的读者应该注意到了，到这个时候，服务器仅仅是对连接调用了shutdown函数，没有调用close函数。首先说一下shutdown和close的区别。close作用在socket fd上和作用在其他fd上的效果差不多，都是减少引用计数，当计数为0的时候释放资源，关闭连接。shutdown函数则是针对socket fd的专门函数。shutdown可以关闭socket连接的一个方向，也就是可以只关闭写或者只关闭读（socket连接是全双工的）。另外一个区别就是，如果连接是多个进程共享的，那么在一个进程中调用close不影响其他进程使用连接，因为仅仅是引用计数减少1。而如果一个进程调用了shutdown ，那么，不管三七二十一，系统直接咔嚓掉这个连接，其他进程看到的也是关闭的连接。还有一个区别，调用了close的socket fd，read，write函数不能再从这个fd上读取或发送数据。而调用了shutdown的socket fd，如果缓冲区中还有数据可读，由于此时对于进程而言，socket fd没有关闭，read依然可以从这个fd读数据。由于shutdown仅仅是关闭了连接，不会进行资源的释放，要想释放连接占用的资源，还必须调用close函数。
对于keep_alive的连接，关闭是服务器主动发起的。根据TCP协议，主动发起关闭的一方，其连接将进入TIME_WAIT状态，此时连接所占用的资源没有释放。更悲剧的是要在这个状态待很长时间。。。（默认4分钟）对于高并发的服务器，如果服务器主动关闭大量连接，那么服务器的资源很快就会被用光（端口，内存等），新的连接将无法建立。关于这个TIME_WAIT状态，读者可自行google之，网上有很多介绍的文章以及处理办法。虽然这个TIME_WAIT状态看似会给我们带来很多麻烦，但是，如果没有这个状态我们会更麻烦。。。《UNIX Network Programming Volum1》这本神作中有详细的介绍，有兴趣的读者可以看看。既然麻烦不可避免，那么就尽量将麻烦的影响见到最低。连接占用的资源主要就是端口和内存。端口是没办法的，占用就占用了。但是，内存还是可以节省一点的。前面说了，shutdown之后，我们依然可以把缓冲区的数据读出来。那么，我们把这些数据读出来以后，缓冲区所占用的内存就可以释放了。从而降低了内存的使用。
在CON_STATE_CLOSE中，下面的代码把缓冲区的数据读了出来：
if (ioctl(con->fd, FIONREAD, &b))
{
log_error_write(srv, __FILE__, __LINE__, "ss", "ioctl() failed", strerror(errno));
}
if (b > 0)
{
char buf[1024];
log_error_write(srv, __FILE__, __LINE__, "sdd", "CLOSE-read()", con->fd, b);
read(con->fd, buf, sizeof(buf));
}
else
{
/*
* nothing to read
*/
con->close_timeout_ts = 0;
}
如果没有数据可读，那么设置close_timeout_ts会使连接在后面的代码中被关闭。如果有数据可读，读取数据之后，连接依然处在CON_STATE_CLOSE状态中，连接对应的fd被加入到fdevent系统中监听读事件。如果缓冲区中还有数据，那么在connection_handle_fdevent 函数中，也有上面这段代码，再次运行之。如果数据没有读完，服务器将会重复的在connection_handle_fdevent函数中运行上述代码直到数据读完。随着close_timeout_ts被设置为0，在下次joblist的调度中，状态机将会关闭连接，清理所有资源。
至此，连接正式关闭。之所以这么麻烦，就是由于连接是服务器主动关闭的，会有TIME_WAIT状态的问题。这样处理仅仅在内存上有了一些节省。但是具体效果怎样，这要看系统内核是如何处理连接缓冲区的。如果各位读者了解这方面的内容，还请不吝赐教！
另外，shutdown之后内核中的缓冲区到底会怎样笔者并不是很确定。上面的内容只是根据代码的推断。还是那句话，如果给为读者有什么高见，还行不吝赐教啊。
本文章由 http://www.wifidog.pro/2015/04/13/wifidog-lighttpd-1.html 整理编辑，转载请注明出处
