如何实现一个Web Server

　　近来重构了来年制的一个轮子 Vino。Vino 旨正在真现一个沉量而且可以包管机能的 Web Server，仅存眷 Web Server 的素质部门。正在重构历程中，Vino 鉴戒了很多优良开源项目标思惟，如 Nginx、Mongoose 战 Webbench。因而，比照上一个版本的 Vino，如今的 Vino 不只机能获得提拔，并且设想也更加文雅、强健 :D。

　　本文将会对 Vino 今朝所具有的枢纽特征停止论述，并总结开辟历程中的一面心得。

　　单线程 + Non-Blocking

　　Vino 团体接纳了基于变乱驱动的单线程 + Non-Blocking 模子。接纳单线程模子，制止了体系分派多线程及线程之间通讯的开消，同时低落了内存的耗用。因为接纳了单线程模子，为了更好的进步线程操纵率，Vino 将默许 Blocking 的 I/O 设置为 Non-Blocking I/O，即正在线程读/写数据的历程中，假如缓冲区为空/缓冲区谦，线程没有会壅闭，而是立刻返回，并设置 errno。

　　Vino 最后的灵感滥觞于 Computer Systems: A Programmer's Perspective 一书报告收集编程时真现的一个简朴的 Web Server，每到去一个恳求，Web Server 城市 fork 一个历程来处置。隐然，正在下并收的场景下，那种模子是没有开理的。每次 fork 历程会带去宏大的开消，而且体系中历程的数目是有限的。同时，陪伴多历程带去的历程调理的开消也不成小觑，CPU 会破费年夜量的工夫用于决议挪用哪个历程。历程调理激发的历程高低文之间的切换，也需求消耗相称年夜的资本。

　　很简单遐想到接纳多线程模子去替换多历程模子，比拟于多历程模子，多线程模子占用的体系资本会年夜年夜低落，可是素质上并出有加小线程调理带去的开消。为了加小由线程调理招致的开消，我们能够接纳线程池模子，即牢固线程的数目，可是成绩照旧存正在：果为 Linux 默许 I/O 是壅闭(Blocking)的，假如线程池中一切的线程同时壅闭于正正在处置的恳求，那末新到去的恳求便出有线程来处置了。因而，假如我们用 Non-Blocking 的 I/O 交换默许的 Blocking I/O，线程将没有会壅闭于数据的读写，成绩即可获得处理。

　　HTTP Keep-Alive

　　Vino 撑持 HTTP 少毗连(Persistent Connections)，即多个恳求能够复用统一个 TCP 毗连，以此削减由 TCP 成立/断开毗连所带去的机能开消。每到去一个恳求，Vino 会对恳求停止剖析，判定恳求头中能否存正在 Connection: keep-alive 恳求头。假如存正在，正在处置完一个恳求后会连结毗连，并对数据缓冲区(用于保留恳求内容，呼应内容)及形态标识表记标帜停止重置，不然，封闭毗连。

　　闭于 HTTP Keep-Alive 的劣势，RFC 2616 有着更完美的总结，援用以下。

　　By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.

　　HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.

　　Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.

　　Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.

　　HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.

　　按时器 Timer

　　假如一个恳求正在成立毗连后早早出有收收数据，大概对圆忽然断电，该当怎样处置?我们需求真现按时器去处置超时的恳求。Vino 按时器的真现参考了 Nginx 的设想，Nginx 利用一颗白乌树去存储各个按时变乱，每次变乱轮回时从白乌树中不竭找出最小(早)的变乱，假如超时则触收超时处置。为了简化真现，正在 Vino 中，我真现了一个小顶堆去存储按时变乱，假如被处置的按时变乱同时撑持少毗连，那末正在该恳求处置终了后会更新该恳求对应的按时器，也便是从头计时。按时器相干代码睹 vn_event_timer.h 战 vn_event_timer.c。

　　HTTP Parser

　　因为收集的没有肯定性，我们其实不能包管一次便能读与一切的恳求数据。因而，关于每个恳求，我们城市开拓一段缓冲区用于保留曾经读与到的数据。同时，我们需求同时对读与到的数据停止剖析，以包管读与到的数据皆是开理的数据，比方，假定今朝缓冲区内的数据为 GET /index.html HTT，那末下一次读与到的字符必需为 P，不然，应立刻检测出当前恳求是一个非常的恳求，并自动封闭当前的毗连。

　　基于以上阐发，我们需求真现一个 HTTP 形态机(Parser)去保持当前的剖析形态，Vino 形态机的真现参考了 Nginx 的设想，并对 Nginx 的真现做了简化。HTTP Parser 相干代码睹 vn_http_parse.h 战 vn_http_parse.c。

　　Memory Pool

　　我们普通利用 malloc/calloc/free 去分派/开释内存，可是那些函数关于一些需求少工夫运转的法式去道会有一些短处。频仍利用那些函数分派战开释内存，会招致内存碎片，没有简单让体系间接收受接管内存。典范的例子便是年夜并收频仍分派战收受接管内存，会招致历程的内存发生碎片，而且没有会坐马被体系收受接管。

　　利用内存池分派内存，能够正在必然水平上提拔内存分派的服从，没有需求每次皆挪用 malloc/calloc 函数。同时，利用内存池使得内存办理愈加简朴。正在 Vino 中，针对每个恳求，Vino 城市为其分派一或多个内存池(各个内存池构成一个单链表)，正在恳求处置终了后，一并开释一切的内存。

　　Vino 内存池的真现照旧参考了 Nginx 的真现，并做了简化，Memory Pool 相干代码睹 vn_palloc.h 战 vn_palloc.c。

　　其他

　　正在开辟 Vino 的历程中，借有很多需求思索战衡量的处所。呼应恳求时，假如用户恳求的是一个很年夜的文件，招致写缓冲区谦，我们怎样更好的设想呼应缓冲区?怎样更下效的设想底层数据构造(如字符串、链表、小顶堆等)?怎样更文雅的剖析号令止参数?怎样对特定疑号停止处置?怎样更强健的处置毛病疑息?今世码的数目到达必然水平后，怎样更快的定位非常代码?

　　Vino 的开辟 & 重构临时告一段降，源码放正在了 GitHub 上。固然，Vino 借有很多不敷的地方，和已真现的特征。

　　仅撑持 HTTP GET 办法，久没有撑持其他 HTTP method。

　　久没有撑持静态恳求的处置。

　　撑持的 HTTP/1.1 特征有限。

　　...

　　写那篇文章，期望对初教者有所协助。