最近幾天用C++重新寫了之前的HTTP伺服器，對以前的程式碼進行改進。新的HTTP伺服器採用Reactor模式，有多個執行緒並且每個執行緒有一個EventLoop，主程式將任務分發到每個執行緒，其中採用的是輪盤排程來均勻分配任務。

伺服器的原始碼放在Github。以前的舊版本也放在我的GitHub上，在Oh-Server倉庫中。新程式碼又新建了一個倉庫。

HTTP基礎知識

寫HTTP伺服器當然要了解HTTP的基礎知識。HTTP/1.1由RFC2616定義，它和TCP/IP協議族內的其他協議相同，是用於客戶和伺服器之

間的通訊。請求訪問資源的一端成為客戶端，而提供資源響應的一端成為伺服器端。我們要寫的是服務端。

HTTP請求報文

HTTP協議規定，請求從客戶端發出，然後伺服器響應該請求。一個HTTP請求報文的例子如下所示：

GET / HTTP/1.1

Host: www.cnblogs.com

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Connection: keep-alive

這是一個真實的HTTP請求的例子，其中每一行都以\r\n

第一行稱為請求行，GET是請求方法，表示獲取資源，除此之外還有POST方法、PUT方法、HEAD方法、DELETE方法和OPTIONS方法等。由於我們寫一個簡單的伺服器，所以暫時僅支

持GET方法。/是URI，表示客戶希望訪問的資源的URI。HTTP/1.1是HTTP協議的版本，此例中表示1.1版本。我們需要解析請求行，需要解析出方法欄位、URI和HTTP協議版本。

第二行是Host欄位，表示所請求的資源所在的主機名和埠號。

第三行User-Agent是客戶的瀏覽器的型別，此例是執行在Ubuntu上的Firefox瀏覽器。

第四行Accept

第四行Accept-Language表示客戶接受的語言型別。

第五行Connection表示伺服器在傳送完客戶請求的資料之後是否斷開TCP連線。keep-alive表示不斷開，close表示斷開。

HTTP應答報文

HTTP/1.1 200 OK

Server: Apache/2.2.22 (Debian)

Content-length: 1223

Content-Type: text/html

第一行為應答行，HTTP/1.1是協議版本，200是狀態碼，OK是狀態短語，表示請求正常。

第二行Server表示伺服器的型別，此例中是Apache伺服器。

第三行Content-length表示實體的長度，單位位元組。

第四行Content-Type表示實體的檔案型別。

程式執行流程

編譯完畢後在終端中輸入 ./Servant 8080開始執行伺服器程式，再開啟瀏覽器輸入localhost:8080訪問我們寫的HTTP伺服器。

伺服器在Servant.cpp中定義的mian函式中監聽到了客戶瀏覽器傳送的連線請求，主函式accept客戶連線並選擇一個執行緒將客戶的已連線套接字註冊到此執行緒的EventLoop中。

EventLoop是一個事件迴圈，每個迴圈都是在試圖從其中的epoll中獲取活動的套接字描述符並交給Handler類中處理。

Handler類是處理客戶HTTP請求的類，它首先將客戶的原始請求轉發給Parser類處理，從而獲取客戶請求的解析結果，Parser類將解析後的結果存入HTTPRequest型別的結構體中。Handler類根據解析後的結果首先測試客戶請求的檔案是否存在，如果不存在將返回錯誤。如果檔案存在但客戶的許可權不允許那麼也返回客戶錯誤資訊。

每個客戶請求處理完畢後就關閉此套接字然後EventLoop繼續迴圈。

解析HTTP請求

HTTP伺服器的一個重要任務是解析HTTP請求，原始碼中Parser.h和Parser.cpp檔案中定義的Parser類就是幹這個的。為了表示解析後的結果我們定義了

一個結構體HTTPRequest結構儲存解析後的結果，定義如下：

// 解析請求後的資料儲存在HTTPRequest結構體中
typedef struct
{
    std::string method;     // 請求的方法
    std::string uri;        // 請求的uri
    std::string version;    // HTTP版本
    std::string host;       // 請求的主機名
    std::string connection; // Connection首部
} HTTPRequest;

各個欄位的意義正如註釋中所示。Parser類的建構函式接受一個字串型別的引數，解析後的值儲存在_parseResult結構體中，並提供一個介面getParseResult函式訪問解析

後的結果。解析的順序如下：

首先parseLine函式按照\r\n作為分隔解析出每一行請求，並把結果儲存在_lines中，其中每一個元素是一行請求。

然後呼叫parseRequestLine函式解析請求行，函式按空格解析各個欄位，並把解析得到的方法、URI和HTTP版本存入HTTPRequest型別的結構體中。

最後呼叫parseHeaders函式解析其他頭部欄位，並將結果存入HTTPRequest型別的結構體中。

執行緒池

要想提高伺服器的效能，使用執行緒池是一種很好的方法，它避免了單執行緒的低效率，並且避免了每次建立一個執行緒的額外開銷。原始碼中EventLoopThreadPool.h檔案定義了執行緒池的類EventLoopThreadPool。其中的每個執行緒都是一個EventLoopThread，EventLoopThread是EventLoop和Thread類的結合體，意思就是每個執行緒執行一個EventLoop。每個執行緒的執行函式就是EventLoop類中定義的loop函式。執行緒池中執行緒的數目由主函式設定，我設定為4。執行緒的數目不宜過多也不宜過少，過多的話會增加CPU的排程開銷；過少的話不能發揮多核CPU的效能。所以執行緒池中常駐執行緒的數目應該等於CPU核心數，以儘量減少任務切換帶來的額外開銷並充分發揮處理器的效能。

具體實現請參考原始碼。

其他模組的作用

由於我們寫的是非阻塞的HTTP伺服器，所以緩衝區是必須要有的。在讀取客戶瀏覽器的請求和傳送伺服器的響應時我們會先將不完整的請求和響應暫存到緩衝區中，等到資料全部讀完或者寫完後再一併傳送或者交給其他模組處理。所以Buffer.cpp和Buffer.h檔案中定義的Buffer類就顯得非常有用了。

Buffer類有readFd和sendFd函式分別用於讀取客戶的請求和傳送伺服器的響應。Buffer類底層儲存的是一個char型的vector，每次新增資料就呼叫push_back將資料新增到字元陣列末尾。_readIndex和_writeIndex分別表示開始讀的索引和開始寫的索引，用這兩個索引可以方便的讀和寫資料。

I/O複用

我們使用I/O複用技術的epoll系列函式來監聽套接字並通知主函式。至於為什麼選擇epoll而不是select或者poll，是因為epoll採用回撥的方式通知事件；而select和poll採用的

都是輪詢的方式，每次呼叫都要掃描整個註冊檔案描述符集合，並將其中就緒的描述符返回給使用者。因此它們的時間複雜度是O(n)，而epoll由於採用回撥的方式所以其時間複雜度為O(1)。

但是當活動連線比較多的時候epoll_wait的效率未必比select和poll高多少，因為此時回撥函式觸發的比較頻繁，所以epoll_wait用於連線數量多但是活動連線比較少的情況。

其他注意的地方

1. 對於監聽套接字設定SO_REUSEADDR套接字選項，以允許伺服器在其派生的子程序正在處理客戶請求的過程中重啟伺服器程序。

2. 忽略SIGPIPE訊號，當一個程序向某個已收到RST的套接字執行寫操作時，核心向該程序傳送一個SIGPIPE訊號，該訊號的預設動作是終止程序，因此程序必須捕獲它以免被終止。

參考資料：

UNIX網路程式設計（第三版）卷一 人民郵電出版社

深入理解計算機系統（第二版） 機械工業出版社

Linux多執行緒服務端程式設計 電子工業出版社

Linux高效能伺服器程式設計 機械工業出版社