httpd基礎

内容：

1、http協定概述

2、http協定特點

3、http的工作模式(過程)

4、http請求封包、響應封包格式、常見狀态碼解析

5、web資源概述(靜态資源、動态資源)

http協定工作在TCP/IP模型的應用層，其定義web服務間通信的約定通信方式，HTTP基于tcp傳送資料，預設是80端口(伺服器端)

    幾個名詞：

        http：hyper texttransfer protocol，超文本傳輸協定，超文本傳輸協定(HTTP)是一種通信協定，它允許将超文本标記語言(HTML)文檔從Web伺服器傳送到用戶端的浏覽器。目前我們使用的是HTTP/1.1 版本。

        超文本：超文本檔案是與其它資料有關聯(links)的資料。包含與其他文檔連結的文檔；選擇連結時自動顯示第二個文檔。超文本檔案的一個簡單例子是大百科全書。假設你正在讀“樹”這個條目，在文章的最末有一個參考這樣寫到，“相關資訊參見‘植物’”。這最末一行就是一個關聯，從“樹”到“植物”這個條目。

        當然這隻是一個簡單例子，全球網是基于一個遠遠複雜得多的超文本檔案。特别的是，在檔案的任何地方都可能有關聯，不僅是在末尾。舉一個想象的例子。假設你正在用全球網閱讀樹的超文本檔案，每次提到一種新的樹就有一個關聯，每個關聯都以某種方式辨別起來以顯得突出。例如，有關聯的字可能被加亮或者加了下劃線，或者标注了一個數字。如果跟着關聯走，你将轉到那種類型的樹的條目去。在主條目裡還有其它題目的關聯，如“雨林”或“木”。這些關聯又引出完整的條目。你或許還能找到與技術術語的關聯，如“落葉科”和“針葉樹”。如果沿着這些關聯就會找到其定義。在全球網的語言裡，一個超文本檔案的檔案就是由一些資料組成，而這些資料又可能與其它檔案相關聯。

        html：hyper text marklanguage，超文本标記語

          URL：uniform resourcelocation，統一資源定位符，主要用于描述伺服器某特定資源的位置，現在幾乎和URI相同

        URL由三部分組成：資源類型、存放資源的主機域名、資源檔案名。

        URL的一般文法格式為：

      例如：http://www.sina.com.cn/index.html

scheme://<user>[:password:]@<host>[:<port>]/path;params?query#frag

  SCHEME:指明協定的

   如果是預設的公認端口，可以省略，比如80，如果改變了端口，需要指明

params:參數；name=value&name=value 

      query(查詢)

        可選，用于給動态網頁（如使用CGI、ISAPI、PHP/JSP/ASP/ASP。NET等技術制作的網頁）傳遞參數，可有多個參數，用“&”符号隔開，每個參數的名和值用“=”符号隔開。

   fragment（資訊片斷）

        字元串，用于指定網絡資源中的片斷。例如一個網頁中有多個名詞解釋，可使用fragment直接定位到某一名詞解釋。

        (1)c/s架構模式，也就是用戶端/伺服器端模式，一個伺服器可以為許多客戶服務

        (2)簡單快速：客戶向伺服器請求服務時，隻需要傳送請求方法和路徑，請求方法常用的隻有GET、HEAD、POST等幾種(後面有說明)，由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快

        (3)靈活：HTTP允許傳輸任意類型的資料對象，傳輸的類型由Context'-Type加以标記

        (4)無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。

解決辦法：引入keep-alive機制

    (5)無狀态：無狀态是指協定對于事務處理沒有記憶能力，伺服器不知道用戶端是什麼狀态。即我們給伺服器發送 HTTP 請求之後，伺服器根據請求，會給我們發送資料過來，但是，發送完，伺服器不會記錄任何，也就是說服務端不能判斷是否是來源同一個使用者

解決的方法：引入cookie(作用與用戶端)、session(作用于伺服器端)，具體工作過程說明這裡不詳細闡述，有興趣的可以查閱相關資料。

           （6）安全可靠

        http工作模式很簡單，用戶端請求，服務端響應回報，其實就是一個請求<---->響應的過程  

      (1)建立連接配接，伺服器接受請求或拒絕，接受的話，進行下一步

        (2)用戶端發送請求

        (3)服務端處理請求

        (4)從存儲中擷取相關的請求資源

        (5)建構響應

        (6)發送響應到用戶端

        (7)記錄相關日志

請求封包一般的格式如下(每個值之間都是空格進行隔開)：

            請求首行：<method><URL><version>

            請求頭：Name : Value

            Name:Value

            ...

               請求實體：

    響應封包格式：

         響應首行：<Vertion> <status><reason>

        響應頭：Name : Value

        Name:Value

        ...

        響應實體

    (1)method方法：

        GET:從伺服器擷取資源

        HEAD：隻從伺服器擷取響應封包的頭部

        POST：向伺服器端送出伺服器需要處理的資料

        PUT：用戶端想伺服器上傳資料，該資料直接存儲在伺服器上，而不需要進行處理，這就是與POST的差別

        DELETE：删除伺服器指定路徑的文檔

   (2)常見錯誤代碼

        伺服器傳回狀态碼

            1xx：表明服務端接收了用戶端請求，用戶端繼續發送請求；

            2xx：用戶端發送的請求被服務端成功接收并成功進行了處理；

            3xx：服務端給用戶端傳回用于重定向的資訊；

            4xx：用戶端的請求有非法内容；

            5xx：服務端未能正常處理用戶端的請求而出現意外錯誤。

    舉例：

        “200”  ; 服務端成功接收并處理了用戶端的請求；對應的reason為OK

        “301”  ; 用戶端所請求的URL已經移走，而且是永久移動，需要用戶端重定向到其它的URL；對應的reason為Moved Permanently

        “302”  ; 與301相似，用戶端所請求的URL已經移走，但是是臨時的，對應的reason為Found

        “304”  ; 用戶端發起了條件式請求，用戶端緩存的URL是否發生了修改，請求的URL未發生變化；對應的reason為Not Modified

        “401”  ; 用戶端登入認證失敗；對應reason為Unauthorized

        “403”  ; 用戶端請求被服務端所禁止(使用者沒有權限通路相關資源)；對應的reason為Forbbiden

        “404”  ; 用戶端所請求的URL在服務端不存在；對應的reason為Not Found

        “500”  ; 服務端在處理用戶端請求時出現異常；對應的reason為Internel server error

        “502”  ; 此為中間代理傳回給用戶端的出錯資訊，表明服務端傳回給代理時出錯；對應的reason為Bad Gateway

（3）首部的分類：

    通用首部

    請求首部

    響應首部

    實體首部

    擴充首部

5、web資源

       web資源：所謂web資源即放在Internet網上供外界通路的檔案或程式，又根據它們呈現的效果及原理不同，将它們劃分為靜态資源和動态資源。

        靜态資源：靜态資源是浏覽器能夠直接打開的，一個js檔案，在打開方式中選擇IE浏覽器打開，浏覽器可以直接打開沒有出現問題，那麼就說明它是一個靜态資源。html檔案、css檔案、js檔案等它們都是靜态資源。

        動态資源：一些資源浏覽器不能夠直接打開，但是經過翻譯之後浏覽器能夠打開的資源稱之動态資源。比如說jsp檔案、servlet、php、ASP等這些都是動态資源。這裡說的動态網頁，與網頁上的各種動畫、滾動字幕等視覺上的“動态效果”沒有直接關系，動态網頁也可以是純文字内容的，也可以是包含各種動畫的内容，這些隻是網頁具體内容的表現形式，無論網頁是否具有動态效果，采用動态網站技術生成的網頁都稱為動态網頁。 

6、httpd的三種MPM介紹

 # perfork MPM 

Apache 2.X  支援插入式并行處理子產品，稱為多路處理子產品（MPM）。在編譯apache時必須選擇也隻能選擇一個MPM，對類UNIX系統，有幾個不同的MPM可供選擇，它們會影響到apache的速度和可伸縮性。 

　　Prefork MPM : 這個多路處理子產品(MPM)實作了一個非線程型的、預派生的web伺服器，它的工作方式類似于Apache 1.3。它适合于沒有線程安全庫，需要避免線程相容性問題的系統。它是要求将每個請求互相獨立的情況下最好的MPM，這樣若一個請求出現問題就不會影響到其他請求。

工作的過程：      

   httpd伺服器會根據<IfModulempm_prefork_module>指令定義的參數維護程序池中的程序。

  當使用者向httpd伺服器發起連接配接請求的時候，httpd的主程序就會從程序池中派一個子程序來負責響應使用者的請求，

   如果該伺服器的并發請求量為100的話，一下子就使用完，程序池中空閑程序數(我們定義了程序池中最小空閑程序數為5)，90個使用者的連接配接請求隻好等待。這時主程序fork()出子程序，然後才能響應處于等待90個使用者的連接配接請求。

   雖然是一個程序負責響應一個使用者的請求，當該程序完成了使用者的請求之後，會話上司程序并不會馬上kill掉該程序。而是使用了重用的機制。意思是在程序的生命周期内它響應完負責的使用者請求後，還可以響應後續的使用者請求。這是為了減少消耗在建立程序上面的時間。

   實作快速地響應使用者請求的一種機制

　　這個MPM具有很強的自我調節能力，隻需要很少的配置指令調整。最重要的是将MaxClients設定為一個足夠大的數值以處理潛在的請求高峰，同時又不能太大，以緻需要使用的記憶體超出實體記憶體的大小。

　Prefork 是UNIX平台上預設的MPM，它所采用的預派生子程序方式也是apache 1.3中采用的模式。prefork 本身并沒有使用到線程，2.0 版本使用它是為了與1.3版保持相容性；另一方面，perfork用單獨的子程序來處理不同的請示，之程之間是彼此獨立的，這也使其成為最穩定的MPM之一 。

<IfModulempm_prefork_module>StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxRequestWorkers 250

MaxConnectionsPerChild 0</IfModule>

# StartServers:　　數量的伺服器程序開始

# MinSpareServers:　　最小數量的伺服器程序,儲存備用

# MaxSpareServers:　　最大數量的伺服器程序,儲存備用

# MaxRequestWorkers:　　最大數量的伺服器程序

# MaxConnectionsPerChild:　　最大連接配接數的一個伺服器程序服務

　　prefork 控制程序在最初建立“StartServers”個子程序後，為了滿足MinSpareServers設定的需要建立一個程序，等待一秒鐘，繼續建立兩 個，再等待一秒鐘，繼續建立四個……如此按指數級增加建立的程序數，最多達到每秒32個，直到滿足MinSpareServers設定的值為止。這種模式 可以不必在請求到來時再産生新的程序，進而減小了系統開銷以增加性能。MaxSpareServers設定了最大的空閑程序數，如果空閑程序數大于這個 值，Apache會自動kill掉一些多餘程序。這個值不要設得過大，但如果設的值比MinSpareServers小，Apache會自動把其調整為 MinSpareServers+1。如果站點負載較大，可考慮同時加大MinSpareServers和MaxSpareServers。  

　　MaxRequestsPerChild設定的是每個子程序可處理的請求數。每個子程序在處理了“MaxRequestsPerChild”個請求後将自 動銷毀。0意味着無限，即子程序永不銷毀。雖然預設設為0可以使每個子程序處理更多的請求，但如果設成非零值也有兩點重要的好處：

1、可防止意外的記憶體洩 漏。2、在伺服器負載下降的時侯會自動減少子程序數。

是以，可根據伺服器的負載來調整這個值。

　　MaxRequestWorkers指令集同時将服務請求的數量上的限制。任何連接配接嘗試在MaxRequestWorkerslimit将通常被排隊，最多若幹基于上ListenBacklog指令。 

在apache2.3.13以前的版本MaxRequestWorkers被稱為MaxClients 。

（MaxClients是這些指令中最為重要的一個，設定的是 Apache可以同時處理的請求，是對Apache性能影響最大的參數。其預設值150是遠遠不夠的，如果請求總數已達到這個值（可通過ps -ef|grep http|wc -l來确認），那麼後面的請求就要排隊，直到某個已處理請求完畢。這就是系統資源還剩下很多而HTTP通路卻很慢的主要原因。雖然理論上這個值越大，可以 處理的請求就越多，但Apache預設的限制不能大于256。）

      如果調大了并發使用者數(伺服器的性能條件下)，雖然一次性可以處理的使用者請求數增加了，但是在伺服器上程序的切換的次數也增加了。因為程序的切換是浪費CPU時間周期的。是以，我們要為伺服器定做一個黃金比例。既能處理更多的使用者并發請求，浪費在程序間切換的時間又很合理

# worker MPM 

　　Worker MPM : 此多路處理子產品(MPM)使網絡伺服器支援混合的多線程多程序。由于使用線程來處理請求，是以可以處理海量請求，而系統資源的開銷小于基于程序的MPM。但是，它也使用了多程序，每個程序又有多個線程，以獲得基于程序的MPM的穩定性

      一個線程服務一個使用者的連接配接請求。線程比程序更輕量級，建立和消耗的速度比程序的建立和消耗要快得多。線程之間還可以共享資源，如：打開的檔案描述符等。這樣如果：兩個用戶端請求的是同一個檔案，就不需要從磁盤上加載兩次了，速度要比基于程序的響應速度快。但線程的管理要比程序複雜得多。線程之間很多資源是共享的，是以它沒有prefork模型，一個程序服務一個服務請求那麼安全穩定。況且，linux不是真線程的作業系統，worker 與 prefork 這兩種模型，在linux上的表現幾乎都一樣。通常使用prefork模型。windows 是真線程的作業系統，它對線程的支援就很好。

不管是Worker模式或是Prefork 模式，Apache總是試圖保持一些備用的(spare)或者是空閑的子程序（空閑的服務線程池）用于迎接即将到來的請求。這樣用戶端就不需要在得到服務前等候子程序的産生。

<IfModulempm_worker_module>StartServers 3

MinSpareThreads 75

MaxSpareThreads 250 

ThreadsPerChild 25

MaxRequestWorkers 400

# StartServers:　　初始數量的伺服器程序開始

# MinSpareThreads:　　最小數量的工作線程,儲存備用

# MaxSpareThreads:　　最大數量的工作線程,儲存備用

# ThreadsPerChild:　　固定數量的工作線程在每個伺服器程序

# MaxRequestWorkers:　　最大數量的工作線程

　　Worker 由主要制程序生成“StartServers”個子程序，每個子程序中包含固定的ThreadsPerChild線程數，各個線程獨立地處理請求。同樣， 為了不在請求到來時再生成線程，MinSpareThreads和MaxSpareThreads設定了最少和最多的空閑線程數

　　而MaxRequestWorkers 設定了同時連入的clients最大總數。如果現有子程序中的線程總數不能滿足負載，控制程序将派生新的子程序 

　　MinSpareThreads和 MaxSpareThreads的最大預設值分别是75和250。這兩個參數對Apache的性能影響并不大，可以按照實際情況相應調節 。

　　ThreadsPerChild是worker MPM中與性能相關最密切的指令。ThreadsPerChild的最大預設值是64，如果負載較大，64也是不夠的。這時要顯式使用 ThreadLimit指令，它的最大預設值是20000。 

　　Worker模式下所能同時處理的請求總數是由子程序總數乘以ThreadsPerChild 值決定的，應該大于等于MaxRequestWorkers。如果負載很大，現有的子程序數不能滿足時，控制程序會派生新的子程序。預設最大的子程序總數是16，加大時 也需要顯式聲明ServerLimit（最大值是20000）。需要注意的是，如果顯式聲明了ServerLimit，那麼它乘以 ThreadsPerChild的值必須大于等于MaxRequestWorkers，而且MaxRequestWorkers必須是ThreadsPerChild的整數倍，否則 Apache将會自動調節到一個相應值。

# Event MPM 

　　Event MPM：以上兩種穩定的MPM方式在非常繁忙的伺服器應用下都有些不足。盡管HTTP的Keepalive方式能減少TCP連接配接數量和網絡負載，但是 Keepalive需要和服務程序或者線程綁定，這就導緻一個繁忙的伺服器會耗光所有的線程。 Event MPM是解決這個問題的一種新模型，它把服務程序從連接配接中分離出來。在伺服器處理速度很快，同時具有非常高的點選率時，可用的線程數量就是關鍵的資源限 制，此時Event MPM方式是最有效的。一個以Worker MPM方式工作的繁忙伺服器能夠承受每秒好幾萬次的通路量（例如在大型新聞服務站點的高峰時），而Event MPM可以用來處理更高負載。值得注意的是，Event MPM不能在安全HTTP（HTTPS）通路下工作。 

<IfModule mpm_event_module>StartServers3

MaxSpareThreads 250

# StartServers:初始數量的伺服器程序開始

 在httpd2.2中并不支援event，生産環境中特别不穩定，2.4中event則已經可以在生産環境中使用了

如何檢視目前安裝的Apache 的三種MPM。

在2.2中：

[root@Cent6 ~]#  ps aux | grep http
root       2197  0.0  1.0 139212  4936 pts/0    S+   12:52   0:00 vim conf/httpd.conf
root       2798  0.0  0.9 184120  4452 ?        Ss   13:20   0:00 /usr/sbin/httpd.worker
apache     2963  0.0  0.7 528380  3432 ?        Sl   13:26   0:00 /usr/sbin/httpd.worker
apache     2964  0.0  0.7 528380  3420 ?        Sl   13:26   0:00 /usr/sbin/httpd.worker
apache     2965  0.0  0.7 528380  3420 ?        Sl   13:26   0:00 /usr/sbin/httpd.worker      

httpd -l 的方式并不可靠。

在2.4中：

[root@centos7-2 httpd]# httpd -M | grep mpm
 mpm_worker_module (shared)      

另外2.2不支援DSO機制，使用安裝包的httpd編輯/etc/sysconfig/httpd,後需要重新啟動服務。

而2.4則很好的支援了DSO（平滑重新開機）的機制，修改/etc/httpd/conf.module.d/00-mpm.conf後立即生效

1. prefork 中沒有線程的概念，是多程序模型，一個程序處理一個連接配接；穩定；響應快。其缺點是在連接配接數比較大時就非常消耗記憶體。

2. worker 是多程序多線程模型，一個程序有多個線程，每個線程處理一個連接配接。與prefork相比，worker模式更節省系統的記憶體資源。不過，需要注意worker模式下的Apache與php等程式子產品的相容性。

3. event 是worker模式的變種，它把服務程序從連接配接中分離出來,在開啟KeepAlive場合下相對worker模式能夠承受的了更高的并發負載。event模式不能很好的支援https的通路（HTTP認證相關的問題）

7、httpd2.4的特性以及httpd2.2和2.4的差別

httpd-2.4

   新特性：

1.MPM支援運作為DSO機制，以子產品形式按需加載

2.eventMPM生産環境可用

3.異步讀寫機制

4.支援每子產品及每目錄的單獨日志級别定義

5.每請求相關的專用配置

6.增強版的表達式分析式

7.毫秒級持久連接配接時長定義

8.基于FQDN的虛拟主機時，不用使用namevirtualhost了

9.新指令，AllowOverridelist

10.支援使用者自定義變量

11.更低的記憶體消耗

1.新子產品：

    1.mod_proxy_fcgi

    2.mod_proxy_scgi

    3.mod_remotei

.切換使用的MPM的方式：

編輯/etc/httpd/conf.module.d/00-mpm.conf

2.基于IP的通路控制：

    允許所有主機通路：require allgranted

    拒絕所有主機通路：require all deny

    控制特定的ip通路：

    requireipIpaddr：授權指定來源的ip通路

    requirenotip IPADDR：拒絕

控制特定的主機通路：

    RequirehostHOSTNAME：授權指定來源的主機通路

    requirenothost HOSTNAME：拒絕

    HOSTNAME：這種比較少用，需要反解域名

    FQDN：特定主機

domin.tld；指定域名下的所有主機

  eg: 要加封裝

 <RequireAll>

     Requireall granted 

     Requirenot ip 172.16.100.2

  </RequireAll>

httpd2.2和httpd2.4的不同之處

1.在2中修改網頁檔案目錄直接修改DocumentRoot即可，而4需要修改DocumentRoot後限定目錄，使用Directory

2.在2中基于域名的虛拟主機需要加上NameVirtualHost*:80 ，4中不需要

3.修改MPM的工作模型2中可以通過修改/etc/sysconfig/httpd中的選項設定；4中可以修改/etc/httpd/conf.modules.d/00-mpm.conf中的子產品

4.httpd2.4中ssl的配置檔案ssl.conf中Listen443https(2.2中不需要加https)