關於Web服務器的認識

       立刻就要畢業了，也要開始找工做了，大學寫了這麼多代碼了，卻沒有好好總結一下經常使用的概念非常遺憾額，就經過這篇博客記錄一下我最經常使用的一些知識好了。

       說到Web服務器，有不少文章都介紹的很好，以前看到一篇很是不錯的，對我幫助很大，惋惜如今找不到原文了，看到博客園有人轉載，我就在這裏也記一下好了，在此很是感謝做者的分析，受益不淺。

       那麼在說Web服務器以前，先說說線程、進程、以及併發鏈接數。

1.進程與線程

        進程是具備必定獨立功能的程序，關於某個數據集合上的一次運行活動，進程是系統進行資源分配和調度的一個獨立單位。從邏輯角度來看，多線程的意義在於一個應用程序（進程）中，有多個執行部分能夠同時執行。但操做系統並無將多個線程看作多個獨立的應用來實現，而是做爲進程來調度和管理以及資源分配。這就是進程和線程的重要區別，進程和線程的主要差異在於，進程有獨立的地址空間，一個進程崩潰後，在保護模式下不會對其它進程產生影響，而線程只是一個進程中的不一樣執行路徑。線程有本身的堆棧和局部變量，但線程之間沒有單獨的地址空間，一個線程死掉就等於整個進程死掉，因此多進程的程序要比多線程的程序健壯，但在進程切換時，耗費資源較大，效率要差一些。但對於一些要求同時進行而且又要共享某些變量的併發操做，只能用線程，不能用進程。下面咱們來講一說併發鏈接數。

2.併發鏈接數

(1).什麼是最大併發鏈接數呢？

         最大併發鏈接數是服務器同一時間能處理最大會話數量。

(2).何爲會話？

       咱們打開一個網站就是一個客戶端瀏覽器與服務端的一個會話，而咱們瀏覽網頁是基於http協議。

(3).HTTP協議如何工做？

       HTTP支持兩種創建鏈接的方式：非持久鏈接和持久鏈接(HTTP1.1默認的鏈接方式爲持久鏈接)。

(4).瀏覽器與Web服務器之間將完成下列7個步驟

• 創建TCP鏈接

• Web瀏覽器向Web服務器發送請求命令

• Web瀏覽器發送請求頭信息

• Web服務器應答

• Web服務器發送應答頭信息

• Web服務器向瀏覽器發送數據

• Web服務器關閉TCP鏈接

       通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，可是瀏覽器通常其頭信息加入了這行代碼 Connection:keep-alive，TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接目的，節省了爲每 個請求創建新鏈接所需的時間，還節約了網絡帶寬。

3.併發鏈接數的計算方法

        用戶下載服務器上的文件，則爲一個鏈接，用戶文件下載完畢後這個鏈接就消失了。有時候用戶用迅雷的多線程方式下載的話，這一個用戶開啓了5個線程的話，就算是5個鏈接。

        用戶打開你的頁面，就算停留在頁面沒有對服務器發出任何請求，那麼在用戶打開一面之後的15分鐘內也都要算一個在線。

        上面的狀況用戶繼續打開同一個網站的其餘頁面，那麼在線人數按照用戶最後一次點擊（發出請求）之後的15分鐘計算，在這個15分鐘內無論用戶怎麼點擊（包括新窗口打開）都仍是一人在線。

         當用戶打開頁面而後正常關閉瀏覽器，用戶的在線人數也會立刻清除。

2、Web服務器提供服務的方式

       Web服務器因爲要同時爲多個客戶提供服務，就必須使用某種方式來支持這種多任務的服務方式。通常狀況下能夠有如下三種方式來選擇，多進程方式、多線程方式及異步方式。其中，多進程方式中服務器對一個客戶要使用一個進程來提供服務，因爲在操做系統中，生成一個進程須要進程內存複製等額外的開銷，這樣在客戶較多時的性能就會下降。爲了克服這種生成進程的額外開銷，可使用多線程方式或異步方式。在多線程方式中，使用進程中的多個線程提供服務， 因爲線程的開銷較小，性能就會提升。事實上，不須要任何額外開銷的方式仍是異步方式，它使用非阻塞的方式與每一個客戶通訊，服務器使用一個進程進行輪詢就好了。

       雖然異步方式最爲高效，但它也有本身的缺點。由於異步方式下，多個任務之間的調度是由服務器程序自身來完成的，並且一旦一個地方出現問題則整個服務器就會出現問題。所以，向這種服務器增長功能，一方面要聽從該服務器自身特定的任務調度方式，另外一方面要確保代碼中沒有錯誤存在，這就限制了服務器的功能，使得異步方式的Web服務器的效率最高，但功能簡單，如Nginx服務器。

       因爲多線程方式使用線程進行任務調度，這樣服務器的開發因爲聽從標準，從而變得簡單並有利於多人協做。然而多個線程位於同一個進程內，能夠訪問一樣的內存空間，所以存在線程之間的影響，而且申請的內存必須確保申請和釋放。對於服務器系統來說，因爲它要數天、數月甚至數年連續不停的運轉，一點點錯誤就會逐漸積累而最終致使影響服務器的正常運轉，所以很難編寫一個高穩定性的多線程服務器程序。可是，不是不能作到時。Apache的worker模塊就能很好的支持多線程的方式。

       多進程方式的優點就在於穩定性，由於一個進程退出的時候，操做系統會回收其佔用的資源，從而使它不會留下任何垃圾。即使程序中出現錯誤，因爲進程是相互隔離的，那麼這個錯誤不會積累起來，而是隨着這個進程的退出而獲得清除。Apache的prefork模塊就是支持多進程的模塊。

3、多進程、多線程、異步模式的對比

     Web服務器總的來講提供服務的方式有三種,多進程方式，多線程的方式，異步方式。其中效率最高的是異步的方式，最穩定的是多進程方式，佔用資源較少的是多線程的方式。

1.多進程

       此種架構方式中，web服務器生成多個進程並行處理多個用戶請求，進程能夠按需或事先生成。有的web服務器應用程序爲每一個用戶請求生成一個單獨的進程來進行響應，不過，一旦併發請求數量達到成千上萬時，多個同時運行的進程將會消耗大量的系統資源。（即每一個進程只能響應一個請求或多個進程對應多個請求）

優勢：

• 最大的優點就在於穩定性，一個進程出錯不會影響其它進程。如，服務器同時鏈接100個請求對就的是100個進程，其中一個進程出錯，只會殺死一個進程，還有99個進程繼續響應用戶請求。每一個進程響應一個請求

缺點：

• 進程量大，進程切換次數過多，致使CPU資源使用效率低，每一個進程的地址空間是獨立的，不少空間中重複的數據，因此內存使用效率低，進程切換因爲內核完成，佔用CPU資源。

2.多線程

       在多線程方式中，每一個線程來響應一下請求，因爲線程之間共享進程的數據，因此線程的開銷較小，性能就會提升。

優勢：

• 線程間共享進程數據，每一個線程響應一個請求，線程切換不可避免（切換量級比較輕量），同一進程的線程能夠共享進程的諸多資源，對內存的需求較之進程有很大降低，讀能夠共享，寫不能夠共享

缺點：

• 線程快速切換時會帶來線程抖動，多線程會致使服務器不穩定

3.異步方式

       一個進程或線程響應多個請求，不須要任何額外開銷的，性能最高，佔用資源最少。但也有問題一但進程或線程出錯就會致使整個服務器的宕機。

4、Web 服務請求過程

       在上面的講解中咱們說明，Web服務器的如何提供服務的，有多進程的方式、多線程的方式還有異步方式咱們先簡單這麼理解，後面咱們慢慢說，如今咱們無論Web服務器是如何提供服務的，多進程也好、多線程好，異步也罷。下面咱們來講一下，一個客戶端的具體請求Web服務的具體過程，從上圖中咱們能夠看到有11步，下面咱們來具體說一下，

• 1.首先咱們客戶端發送一個請求到Web服務器，請求首先是到網卡。2.網卡將請求交由內核空間的內核處理，其實就是拆包了，發現請求的是80端口。3.內核便將請求發給了在用戶空間的Web服務器，Web服務器接受到請求發現客戶端請求的index.html頁面。4.Web服務器便進行系統調用將請求發給內核。5.內核發如今請求的是一頁面，便調用磁盤的驅動程序，鏈接磁盤。6.內核經過驅動調用磁盤取得的頁面文件。7.內核將取得的頁面文件保存在本身的緩存區域中便通知Web進程或線程來取相應的頁面文件。8.Web服務器經過系統調用將內核緩存中的頁面文件複製到進程緩存區域中。9.Web服務器取得頁面文件來響應用戶，再次經過系統調用將頁面文件發給內核。10.內核進程頁面文件的封裝並經過網卡發送出去。11.當報文到達網卡時經過網絡響應給客戶端

簡單來講就是：用戶請求-->送達到用戶空間-->系統調用-->內核空間-->內核到磁盤上讀取網頁資源->返回到用戶空間->響應給用戶。上述簡單的說明了一下，客戶端向Web服務請求過程，在這個過程當中，有兩個I/O過程，一個就是客戶端請求的網絡I/O，另外一個就是Web服務器請求頁面的磁盤I/O。 下面咱們就來講說Linux的I/O模型。

5、Linux I/O 模型

1.I/O模型分類

說明：咱們都知道web服務器的進程響應用戶請求，但沒法直接操做I/O設備，其必須經過系統調用，請求kernel來協助完成I/O動做，以下圖：

      對於數據輸入而言，即等待(wait)數據輸入至buffer須要時間，而從buffer複製(copy)數據至進程也須要時間  
根據等待模式不一樣，I/O動做可分爲五種模式。

• 1.阻塞I/O，2.非阻塞I/O，3.I/O複用（select和poll），4.信號（事件）驅動I/O（SIGIO），5.異步I/O（Posix.1的aio_系列函數）

2.I/O模型的相關術語

(1).阻塞和非阻塞:

       阻塞和非阻塞指的是執行一個操做是等操做結束再返回，仍是立刻返回。好比你去車站接朋友，這是一個操做。能夠有兩種執行方式。第一種，你這人特實誠，老早就到了車站一直等到車來了接到朋友爲止。第二種，你到了車站，問值班的那趟車來了沒有，「尚未」，你出去逛一圈，可能過會回來再問。第一種就是阻塞方式，第二種則是非阻塞的。我認爲阻塞和非阻塞講得是作事方法，是針對作事的人而言的。

(2).同步和異步:

       同步和異步又是另一個概念，它是事件自己的一個屬性。好比老闆讓你去搬一堆石頭，並且只讓你一我的幹，你只好本身上陣，最後的結果是搬完了，仍是你砸到腳了，只有搬完了你才知道。這就是同步的事件。若是老闆還給你個小弟，你就可讓小弟去搬，搬完了告你一聲。這就變成異步的了。其實異步還能夠分爲兩種：帶通知的和不帶通知的。前面說的那種屬於帶通知的。有些小弟幹活可能主動性不是很夠，不會主動通知你，你就須要時不時的去關注一下狀態。這種就是不帶通知的異步。 對於同步的事件，你只能以阻塞的方式去作。而對於異步的事件，阻塞和非阻塞都是能夠的。非阻塞又有兩種方式：主動查詢和被動接收消息。被動不意味着必定很差，在這裏它偏偏是效率更高的，由於在主動查詢裏絕大部分的查詢是在作無用功。對於帶通知的異步事件，二者皆可。而對於不帶通知的，則只能用主動查詢。

(3).I/O

       回到I/O，無論是I仍是O，對外設(磁盤)的訪問均可以分紅請求和執行兩個階段。請求就是看外設的狀態信息（好比是否準備好了），執行纔是真正的I/O操做。在Linux 2.6以前，只有「請求」是異步事件，2.6以後才引入AIO把「執行」異步化。別看Linux/Unix是用來作服務器的，這點上比Windows落後了好多，IOC（Windows上的AIO）在Win2000上就有了。

(4).總結

      Linux上的前四種I/O模型的「執行」階段都是同步的，只有最後一種才作到了真正的全異步。第一種阻塞式是最原始的方法，也是最累的辦法。固然累與不累要看針對誰。應用程序是和內核打交道的。對應用程序來講，這種方式是最累的，但對內核來講這種方式偏偏是最省事的。還拿接人這事爲例，你就是應用程序，值班員就是內核，若是你去了一直等着，值班員就省事了。固然如今計算機的設計，包括操做系統，愈來愈爲終端用戶考慮了，爲了讓用戶滿意，內核慢慢的承擔起愈來愈多的工做，IO模型的演化也是如此。非阻塞I/O ，I/O複用，信號驅動式I/O其實都是非阻塞的，固然是針對「請求」這個階段。非阻塞式是主動查詢外設狀態。I/O複用裏的select，poll也是主動查詢，不一樣的是select和poll能夠同時查詢多個fd（文件句柄）的狀態，另外select有fd個數的限制。epoll是基於回調函數的。信號驅動式I/O則是基於信號消息的。這兩個應該能夠歸到「被動接收消息」那一類中。最後就是偉大的AIO的出現，內核把什麼事都幹了，對上層應用實現了全異步，性能最好，固然複雜度也最高。

6、Linux I/O 模型具體說明

         首先咱們先來看一下，基本 Linux I/O 模型的簡單矩陣，從圖中咱們能夠看到的模型有，同步阻塞I/O（阻塞I/O）、同步非阻塞I/O（非阻塞I/O ）、異步阻塞I/O（I/O複用），異步非阻塞I/O（有兩種，信號驅動I/O和異步I/O）。好了如今就來具體說一說吧。

1.阻塞I/O

說明：應用程序調用一個IO函數，致使應用程序阻塞，等待數據準備好。 若是數據沒有準備好，一直等待數據準備好了，從內核拷貝到用戶空間,IO函數返回成功指示。這個不用多解釋吧，阻塞套接字。下圖是它調用過程的圖示：（注，通常網絡I/O都是阻塞I/O，客戶端發出請求，Web服務器進程響應，在進程沒有返回頁面以前，這個請求會處於一直等待狀態）

2.非阻塞I/O

       咱們把一個套接口設置爲非阻塞就是告訴內核，當所請求的I/O操做沒法完成時，不要將進程睡眠，而是返回一個錯誤。這樣咱們的I/O操做函數將不斷的測試數據是否已經準備好，若是沒有準備好，繼續測試，直到數據準備好爲止。在這個不斷測試的過程當中，會大量的佔用CPU的時間，全部通常Web服務器都不使用這種I/O模型。具體過程以下圖:

3.I/O複用（select和poll）

        I/O複用模型會用到select或poll函數或epoll函數(Linux2.6之後的內核開始支持)，這兩個函數也會使進程阻塞，可是和阻塞I/O所不一樣的的，這兩個函數能夠同時阻塞多個I/O操做。並且能夠同時對多個讀操做，多個寫操做的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操做函數。具體過程以下圖:

4.信號驅動I/O（SIGIO）

       首先，咱們容許套接口進行信號驅動I/O，並安裝一個信號處理函數，進程繼續運行並不阻塞。當數據準備好時，進程會收到一個SIGIO信號，能夠在信號處理函數中調用I/O操做函數處理數據。具體過程以下圖:

綜上能夠看出，越日後，阻塞越少，理論上效率也是最優。其五種I/O模型中，前三種屬於同步I/O，後二者屬於異步I/O。

同步I/O:

• 1.阻塞I/O，2.非阻塞I/O，3.I/O複用（select和poll）     

異步I/O:

• 1.信號驅動I/O（SIGIO） （半異步），2.異步I/O（Posix.1的aio_系列函數） （真正的異步）

異步 I/O 和 信號驅動I/O的區別:

• 信號驅動 I/O 模式下，內核能夠複製的時候通知給咱們的應用程序發送SIGIO 消息。異步 I/O 模式下，內核在全部的操做都已經被內核操做結束以後纔會通知咱們的應用程序。

7、Linux I/O模型的具體實現

1.主要實現方式有如下幾種：

• select，poll，epoll，kqueue，/dev/poll，iocp

       其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O複用）模型，iocp對應第5種（異步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，能夠看做有了第4種（信號驅動I/O）模型的某些特性，如callback機制。

2.爲何epoll、kqueue、/dev/poll比select高級？

       答案是，他們無輪詢。由於他們用callback取代了。想一想看，當套接字比較多的時候，每次select()都要經過遍歷FD_SETSIZE個Socket來完成調度，無論哪一個Socket是活躍的，都遍歷一遍。這會浪費不少CPU時間。若是能給套接字註冊某個回調函數，當他們活躍時，自動完成相關操做，那就避免了輪詢，這正是epoll、kqueue、/dev/poll作的。這樣子說可能很差理解，那麼我說一個現實中的例子，假設你在大學讀書，住的宿舍樓有不少間房間，你的朋友要來找你。select版宿管大媽就會帶着你的朋友挨個房間去找，直到找到你爲止。而epoll版宿管大媽會先記下每位同窗的房間號，你的朋友來時，只需告訴你的朋友你住在哪一個房間便可，不用親自帶着你的朋友滿大樓找人。若是來了10000我的，都要找本身住這棟樓的同窗時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高併發服務器中，輪詢I/O是最耗時間的操做之一，select、epoll、/dev/poll的性能誰的性能更高，一樣十分明瞭。

3.Windows or *nix （IOCP or kqueue、epoll、/dev/poll）？

       誠然，Windows的IOCP很是出色，目前不多有支持asynchronous I/O的系統，可是因爲其系統自己的侷限性，大型服務器仍是在UNIX下。並且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內核copy數據到應用層的阻塞，從而不能算做asynchronous I/O類。可是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經作得很優秀了。

4.總結一些重點

       只有IOCP(windows實現)是asynchronous I/O，其餘機制或多或少都會有一點阻塞。select（Linux實現）低效是由於每次它都須要輪詢。但低效也是相對的，視狀況而定，也可經過良好的設計改善epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9以前只支持select模型，2.2.9以後支持epoll模型，Nginx 支持epoll模型，Java nio包是select模型

• （完）  by  JonnyF