實際的Web服務器處理客戶端請求的步驟分析

第一步——接受客戶端鏈接

接受一個客戶端鏈接，或者若是不但願與這個客戶端創建鏈接，就將其關閉。

第二步——接收請求報文

從網絡中讀取一條HTTP請求報文

解析報文

1. 解析請求行，查找請求方法、指定的資源標識符（URI）以及版本號，各項之間由一個空格分隔，並以一個回車換行（CRLF）序列做爲行的結束；
2. 讀取以CRLF結尾的報文首部；
3. 檢測到以CRLF結尾的、標識首部結束的空行（若是有的話）；
4. 若是有的話（長度由Content-Length首部指定），讀取請求主體。

報文的內部表示法

有些Web服務器還會用便於進行報文操做的內部數據結構來存儲請求報文

鏈接的輸入/輸出處理結構

不一樣的Web服務器結構會以不一樣的方式爲請求服務

單線程Web服務器

一次只處理一個請求，直到其完成爲止。一個事務處理結束以後，纔去處理下一條鏈接

多進程及多線程Web服務器

服務器會爲每條鏈接分配一個線程/進程;但當服務器同時要處理成百、上千，甚至數以萬計的鏈接時，須要的進程或線程數量可能會消耗太多的內存或系統資源。所以，不少多線程Web服務器都會對線程/進程的最大數量進行限制。

複用I/O的服務器

Web服務器都採用了複用結構。在複用結構中，要同時監視全部鏈接上的活動。當鏈接的狀態發生變化時（好比，有數據可用，或出現錯誤時），就對那條鏈接進行少許的處理；處理結束以後，將鏈接返回到開放鏈接列表中，等待下一次狀態變化。只有在有事情可作時纔會對鏈接進行處理；在空閒鏈接上等待的時候並不會綁定線程和進程。

複用的多線程Web服務器

有些系統會將多線程和複用功能結合在一塊兒，以利用計算機平臺上的多個CPU。多個線程（一般是一個物理處理器）中的每個都在觀察打開的鏈接（或打開的鏈接中的一個子集），並對每條鏈接執行少許的任務

第三步——處理請求

對請求報文進行解釋，並採起行動，好比post可能提交了一些信息，服務器須要來處理這些信息

第四步——對資源的映射及訪問

訪問報文中的指定資源，好比Get請求根據地址映射獲取服務器上的某個文件。

docroot

一般，Web服務器的文件系統中會有一個特殊的文件夾專門用於存放Web內容。這個文件夾被稱爲文檔的根目錄（document root，或docroot）。Web服務器從請求報文中獲取URI，並將其附加在文檔根目錄的後面。
不少web服務器都支持配置document 在配置文件httpd.conf中添加一個DocumentRoot行就能夠爲Apache Web服務器設置文檔的根目錄了：
DocumentRoot /usr/local/httpd/files

虛擬託管的docroot

虛擬託管的Web服務器會在同一臺Web服務器上提供多個Web站點；每一個站點在服務器上都有本身獨有的文檔根目錄。虛擬託管Web服務器會根據URI或Host首部的IP地址或主機名來識別要使用的正確文檔根目錄。經過這種方式，即便請求URI徹底相同，託管在同一Web服務器上的兩個Web站點也能夠擁有徹底不一樣的內容了。

解析目錄

咱們能夠對大多數Web服務器進行配置，使其在客戶端請求目錄URL時採起不一樣的動做。

1. 返回一個錯誤。
2. 不返回目錄，返回一個特殊的默認「索引文件」（Web服務器可自行配置索引優先級）。
3. 掃描目錄，返回一個包含目錄內容的HTML頁面（自動生成且返回一個展現目錄下的全部文件/目錄的html文件）。

大多數Web服務器都會去查找目錄中一個名爲index.html或index.htm的文件來表明此目錄。若是用戶請求的是一個目錄的URL，並且這個目錄中有一個名爲index.html（或index.htm）的文件，服務器就會返回那個文件的內容。

第五步——構建響應

一旦Web服務器識別出了資源，就執行請求方法中描述的動做，並返回響應報文。

響應實體

若是事務處理產生了響應主體，就將內容放在響應報文中回送過去。
響應報文中一般包括：

1. 描述了響應主體MIME類型的Content-Type首部；
2. 描述了響應主體長度的Content-Length首部；
3. 實際報文的主體內容。

重定向

Web服務器有時會返回重定向響應而不是成功的報文。Web服務器能夠將瀏覽器重定向到其餘地方來執行請求。重定向響應由返回碼3XX說明。Location響應首部包含了內容的新地址或優選地址的URI。重定向可用於下列狀況。

永久搬離的資源

資源可能已經被移動到了新的位置，或者被從新命名，有了一個新的URL。態碼301Moved Permanently就用於此類重定向。

臨時搬離的資源

若是資源被臨時移走或重命名了，服務器可能但願將客戶端重定向到新的位置上去。狀態碼303 See Other以及狀態碼307 Temporary Redirect就用於此類重定向。

URL加強

服務器一般用重定向來重寫URL，每每用於嵌入上下文。當請求到達時，服務器會生成一個新的包含了嵌入式狀態信息的URL，並將用戶重定向到這個新的URL上去。[插圖]客戶端會跟隨這個重定向信息，從新發起請求，但此次的請求會包含完整的、通過狀態加強的URL。這是在事務間維護狀態的一種有效方式。狀態碼303 See Other和307 Temporary Redirect用於此類重定向。

負載均衡

若是一個超載的服務器收到一條請求，服務器能夠將客戶端重定向到一個負載不過重的服務器上去。狀態碼303 See Other和307 TemporaryRedirect可用於此類重定向。

第六步——發送響應

將響應報文返回給客戶端

第七步——記錄日誌

最後，當事務結束時，Web服務器會在日誌文件中添加一個條目，來描述已執行的事務。大多數Web服務器都提供了幾種日誌配置格式。