在CON_STATE_RESPONSE_START状态中，服务器开始准备给客户端的response：
case CON_STATE_RESPONSE_START:
/*
* the decision is done
* - create the HTTP-Response-Header
*
*/
if (srv->srvconf.log_state_handling) {
log_error_write(srv, __FILE__, __LINE__, "sds",
"state for fd", con->fd, connection_get_state(con->state));
}
if (-1 == connection_handle_write_prepare(srv, con)) {
connection_set_state(srv, con, CON_STATE_ERROR);
break;
}
connection_set_state(srv, con, CON_STATE_WRITE);
break;
可以看到，该状态主要调用了connection_handle_write_prepare函数，它根据客户端请求的method来设置response的headers（其实就是设置“Content-Length”的值）。
connection_handle_write_prepare函数的执行内容：
1.该函数首先判断连接的模式（mode）是否为DIRECT，如果是，说明连接没有经过插件处理，是由服务器自身处理的。
2.接着判断连接的请求method，如果是OPTION，则设置Allow的值，同时清空write_queue，因为没有数据需要返回。设置con->file_finished为1，表示不需要给客户端发送文件。
3.比较http_status的值，如果为204,205,304,说明服务器不需要给客户端返回文件，仅返回 response中headers及其之前的部分，设置con->file_finished为1。
4.判断file_finished的值。如果值为1，说明不需要给客户端返回文件数据。对于1xx，204和 304状态，将Content-Length设置为空值。如果method是HEAD，那么服务器可能需要返回一些数据，这时候要设置对应的 Content-Length。如果file_finished的值为0，那么要设置一下keep_alive的值。
5.最后，调用http_response_write_header将 headers写入write_queue，等待返回给客户端。如果一切顺利，状态机进入CON_STATE_WRITE状态。
下面是CON_STATE_WRITE分支的操作：
case CON_STATE_WRITE:
if (srv->srvconf.log_state_handling) {
log_error_write(srv, __FILE__, __LINE__, "sds",
"state for fd", con->fd, connection_get_state(con->state));
}
/* only try to write if we have something in the queue */
if (!chunkqueue_is_empty(con->write_queue)) {
#if 0
log_error_write(srv, __FILE__, __LINE__, "dsd",
con->fd,
"packets to write:",
con->write_queue->used);
#endif
}
if (!chunkqueue_is_empty(con->write_queue) && con->is_writable) {
if (-1 == connection_handle_write(srv, con)) {
log_error_write(srv, __FILE__, __LINE__, "ds",
con->fd,
"handle write failed.");
connection_set_state(srv, con, CON_STATE_ERROR);
} else if (con->state == CON_STATE_WRITE) {
con->write_request_ts = srv->cur_ts;
}
}
break;
由于数据可能不会一次写完，所以在CON_STATE_WRITE状态中，首先判断write_queue是否为空，即有没有数据需要发送。同时判断连接是否可写。如果有数据且可写，那么调用connection_handle_write发送数据。如果没有数据可写或者连接不可写，那么跳出switch(con->state)这个语句。
由于状态机状态没有发生改变，switch后面的if语句使得服务器退出了大while循环，进入循环后面的小switch(con->state)语句（如果连接的状态没有改变，说明连接读写数据还没有结束，但是需要等待IO事件）。在这里，进入 CON_STATE_WRITE分支，如果有数据可写且连接可写且没有达到流量限制，那么在fdevent中注册这个连接，等IO结束后继续写数据，否则，删除这个连接。
当有数据可写且连接可写时，进入connection_handle_write函数，下面看看该函数的作用：
1.首先调用network_write_chunkqueue函数，将write_queue中的数据写回给客户端。函数network_write_chunkqueue首先判断当前连接的流量是否超过了限制，如果是，则不发送任何数据，直接将连接加到作业列表（joblist）中，让其他连接发送数据。如果没有超限，那么首先设置TCP_CORK选项。这个选项可以将多个write调用的数据一起发送， 提高发送效率。
2.接下来调用srv->network_backendwirte()函数真正的写数据。这个函数的定义有多个，在network*.c文件中。服务器在network.c的network_init函数中会根据当前的运行环境设置不同的值。传统的IO方法先read再write，需要4次数据拷贝（从磁盘到内核缓冲区，从内核缓冲区到用户缓冲区，从用户缓冲区到网络接口的内核缓冲区，最后，从网络接口的内核缓冲区到网络设备缓冲区），为提高服务器的效率，不同的OS会提供一些特定的方法来减少拷贝的次数（直接IO），提高发送文件的速度，lighttpd根据不同的OS去调用特定的接口来实现network_backend_wirte()函数。这些实现大同小异，以network_write.c中的实现为例：
函数的主体是个大循环，遍历所有的chunk。
如果chunk的类型是 MEM_CHUNK，那么这个chunk中的数据是在内存中的，直接调用write或者windows下的send函数发送数据。
如果是 FILE_CHUNK类型，说明这个chunk表示的是一个文件，那么如果运行环境有mmap函数，就使用mmap映射文件并发送，否则就read再write。
如果这个chunk发送完了，则继续发送下一个chunk。
如果没有发送完（chunk_finished=0），退出循环，接着退出了这个函数。
3.服务器返回到network_write_chunkqueue中，做一些统计工作，再一次检查该连接的流量是否超限。
4.最后服务器返回到connection_handle_write中。
如果network_write_chunkqueue返回-1，表示服务器出错。状态机进 入CON_STATE_ERROR。
如果返回-2，则客户端关闭连接，状态机也进入CON_STATE_ERROR。
返回0表示发送完毕，进入下一个状态。
返回1说明数据没有发送完，标记is_wirtable为0。
5.从connection_handler_write函数返回后，如果数据没有发送完毕，那么状态机还在CON_STATE_WRITE状态，接着连接被加到fdevent系统中，等待下一次数据发送。重复上述过程直到发送完毕或出错。
6.如果数据发送完毕，状态机进入CON_STATE_RESPONSE_END状态。
在状态CON_STATE_RESPONSE_END中：
1.服务器首先调用 plugins_call_handle_request_done通知所有插件连接处理完毕。
2.判断是否保持连接，如果保持，将状态机设置为 CON_STATE_REQUEST_START。如果不保持，先调用plugins_call_handle_connection_close通知所有插件连接关闭，然后关闭连接。
3.重置con，清除前一次请求的数据。
至此，请求处理结束。