Web服務之二：httpd安裝配置

httpd相關介紹

 

代理：Web代理服務器工做在Web客戶端與Web服務器之間，他負責接收來自客戶端的http請求，並將其轉發至對應的服務；然後接收來自於服務器的響應，並將響應報文回送至客戶端。

 

Apache：Open Source，Web服務器的引導者，不少Web服務器的標準都是參照Apache制定的，所以這也是事實上互聯網Web服務器的規範的指定者。

　　早先源自於NCSA，當時NCSA研發的一款軟件其進程叫httpd，所以httpd一直也是做爲Web服務器最先出現的表明而使用的。後來httpd這個軟件已經很完善了，NCSA以爲這個項目已經沒有完善下去的必要就解散了，所以NCSA的不少研發者到了其它公司工做，但它們又不想httpd沒落下去，所以經過互聯網協做起來繼續爲這個軟件新增了不少功能，主要就是打上補丁、補漏洞、新增額外功能。所以有人把它們從新發行的，基於互聯網協做發行的服務器httpd戲稱爲A Patchy Server（充滿補丁的服務器），後來簡寫爲Apache（Apache也是美國武裝直升機的代稱）。

 

FSF：GNU組織的，發佈了GPL協定的軟件基金會。

ASF：Apache Software Foundation，開源界最著名的基金會之一，與FSF齊名

　　到目前爲止，Apache是著名的軟件基金會，叫ASF

　　由ASF主導的著名項目有：

• 　　httpd：提供web服務，不少時候就以Apache稱呼httpd，由於早期httpd就被稱爲Apache Server，所以當聽到Apache表示一個具體的項目時，就是表示httpd；
• 　　Tomcat：JSP的應用程序服務器，可以提供JSP執行環境，是著名的實現JavaEE實現規範的參照程序；　　
• 　　Hadoop：提供並行處理運行環境，提供高性能運算的很是重要的計算框架，能夠實現將數千臺電腦組織起來完成同一個任務；

　　Apache官網：www.apache.org

　　web服務器httpd官方站點：http://httpd.apache.org

 

httpd：

　　純粹的Web Server，開源（Open Source），其開源協定再也不是GPL，而是Apache的開源協定。

 

httpd傳統風格特性：

1. 在進程控制上一般是事先建立進程；Web服務器響應用戶模型有多種，多進程/多線程是一個用戶請求使用一個進程來響應，所以若是接收到多個用戶請求後再進行建立進程速度會比較慢；因此Apache事先把進程啓動做爲空閒進程；
2. 事先建立的進程是有數目要求的，有一種適應性叫按需維持適當的進程；如：啓動500個進程響應500個請求，若500個請求中有400個請求都完成了，那麼400個進程都空閒下來了，但不能讓進程都空閒下來，所以當空閒太多時須要將空閒的進程一一銷燬，直到知足咱們所應該維持的最小或最大進程數爲止；
   
3. 模塊化設計（即只具有核心功能），其核心比較小，各類功能都經過模塊來進行添加，支持運行時配置，支持單獨編譯模塊。這些模塊能夠在運行時啓用，相似於Linux內核，平時只啓用其核心功能，用到額外的功能時，只須要將額外的功能的模塊裝載進來便可，同時須要注意的是咱們在用到哪一個模塊的功能時，能夠單獨編譯對應的模塊。甚至包括PHP均可以經過模塊的方式裝載進httpd，Apache與PHP結合有不少種方式，模塊化就是比較常見的一種，也是RedHat系列服務器上默認的一種；
4. 支持多種方式的虛擬主機配置。咱們在此處簡單引入一下虛擬主機的概念：若是須要提供Web服務，那就須要有一臺物理服務器，而且在服務器上須要運行Web服務器進程，當客戶端請求時，這個進程要可以予以響應。而若咱們要在互聯網上建一臺Web服務器，可以提供我的或公司的站點，須要有一臺物理服務器、須要IP地址、而且要保證明時可以在線、可以被互聯網上的主機所訪問，那這須要的資源會很是多，而且若是訪問的用戶很是少，會形成很是大的資源浪費。所以能夠經過提供虛擬主機的方式提供站點。
5. 支持https協議。經過mod_ssl模塊支持。
6. 支持基於IP或主機名的ACL。
7. 支持目錄的訪問控制。用戶訪問主站點的時候不用提供帳號密碼，可是訪問某一特殊路徑路徑時，就須要提供帳號密碼。
   
8. 支持URL重寫。如：原本訪問的是/image/a.jpg但卻能夠重寫成/bbs/images/abc.jpeg，而這對於客戶端來說是透明的，能夠在服務器上將這種內容通通轉發到另一個路徑上從新訪問。

 

Nginx：

　　Nginx是基於多進程響應n個用戶請求的這樣一種模型，因此它可以使用有限的資源響應比Apache更多的用戶請求。但卻代替不了httpd，由於Nginx目前來說做爲一個完整意義上的提供諸多豐富特性的Web服務器來說，它沒有辦法與httpd相比較的。就其穩定性來說也沒法與httpd相比較，因此它們各有各的發揮場所，Nginx通常用來作反向代理，而httpd仍然是Web中當之無愧的老大。

 

虛擬主機的相關問題

虛擬主機：簡單來說，若咱們只有一臺物理服務器，並且安裝的Web程序也只有一個，但這個Web服務器自己卻能夠根據用戶請求的不一樣提供多個站點，即能夠服務於多個不一樣的站點。如：若使用www.a.com與www.b.org發生在同一臺主機，可是打開的網站確實是不一樣的，那這種咱們就把它稱爲虛擬主機。

 

那麼如何區別不一樣的虛擬主機呢？

　　咱們剛纔已經說了，對於多個虛擬主機來說，Web服務器只有一個，而目標IP也可能只有一個，端口就是80端口。在這種前提之下，要想讓用戶訪問的是不一樣的站點，那麼靠什麼區別呢？

　　在此以前咱們須要明確的是，事實上服務器在特定的地址或套接字上提供服務的話，那麼每個服務必需要佔據一個套接字（套接字即IP:Port的組合），而每個套接字只能爲一個服務器提供服務。因此若要實現多種不一樣方式的虛擬主機的話有多種不一樣的組合方式，如：一臺服務器上配置多個IP地址，每個IP地址提供一個網站。

　　因此實現虛擬主機的方式有這麼幾種變化方式：

• 基於IP的虛擬主機；
• 基於端口的虛擬主機；
• 基於域名的虛擬主機；若端口、IP都同樣，但因爲其站點訪問的時候的DNS的主機名不一樣，卻也能夠打開不一樣的虛擬主機。

　　在互聯網上，基於域名的虛擬主機的實現更現實一些。由於IPv4地址是緊缺的資源，所以基於IP的虛擬主機不現實；而Web服務器的端口默認爲80端口，但基於端口的虛擬主機就須要使用其它端口，用戶將沒法得知具體端口號，也不現實。

 

咱們再來回顧一下，客戶端請求報文的格式爲：

protocol://HOST:PORT/path/to/source

　　Method URL version
　　header　　　

　　body

　　GET /download/linux.tar.bz2 HTTP/1.0
　　HOST:www.test.com

 

　　Host與Method後的路徑組織起來就是完整意義上的遵循規範的URL了，而Host指定的是域名，所以這個報文傳到服務器後，服務器端徹底能夠根據Host區別到底訪問的是哪一個虛擬主機，這就是基於域名虛擬主機的實現的最基本的前提。這也是爲何請求報文中必定要有一個首部叫Host予以標識的緣由。

　　但若是在實現基於域名的虛擬主機的前提之下用戶訪問的是IP地址呢？若請求的時候就是基於IP地址請求的話，此時可返回一個默認的虛擬主機，同時若是用戶訪問不存在的虛擬主機一樣返回默認的虛擬主機。

 

httpd在CentOS上的安裝配置：

httpd在CentOS上的安裝配置方式：

• 經過系統自帶的rpm包；
• 源碼編譯。rpm包有其侷限性如：有些須要的功能未編譯、有些不須要的功能編譯了、版本落後、漏洞等等。

 

理論基礎：

　　httpd安裝包：

　　安裝完成後執行進程在：/usr/sbin/httpd；

　　在RedHat5.8系統上的httpd處理模式（多道處理模塊MPM）是prefork的，須要事先啓動空閒進程用來接收用戶請求。所以啓動後會發現系統上有不少個叫httpd的進程，而在衆多進程當中，有一個進程運行的屬主屬組是root用戶root組，其它進程的屬主屬組是apache用戶apache組，這是由於在Linux系統上小於1024端口的要想啓動只有管理員有權限，而這個root用戶root組的進程自己並不響應用戶請求，它專門用來建立空閒進程或銷燬多餘的空閒進程，因此這是一個主導進程（master process），其它進程稱爲work process。因此每個用戶請求都由主導進程建立一個工做進程響應用戶請求。

　　服務腳本：/etc/rc.d/init.d/httpd；

　　佔據端口及使用的協議：80/TCP；若基於ssl工做，則爲443/TCP。

　　若基於rpm包編譯安裝，它會假設本身的工做根目錄在/etc/httpd下，工做的根目錄即進程運行的根目錄至關於程序的安裝目錄。

　　配置文件目錄：/etc/httpd/conf；

　　　　主配置文件爲/etc/httpd/conf/httpd.conf，Apache的主配置文件很是大，裏面有不少內容，所以RedHat將它們分段引用了，所以全部的位於/etd/httpd/conf.d/*.conf的文件都是主配置文件的組成部分；

　　Apache的各類模塊目錄：/etc/httpd/modules，這個模塊是一個連接；

　　日誌目錄：/etc/httpd/logs（連接）指向/var/log/httpd；

　　　　Apache的日誌文件分爲兩類，一類叫訪問日誌（access Log），指的是客戶端每次發起訪問請求以及服務器端響應的結果；一類叫錯誤日誌（error_log），指的是錯誤的訪問及服務器運行過程中出現的問題，包括服務器啓動過程中出現問題了。

　　響應的文件：/var/www；

　　　　/var/www/html：靜態頁面所在的路徑；

　　　　/var/www/cgi/bin：Apache提供動態內容時使用的路徑；

CGI：

　　CGI是讓Web服務器可以跟額外的應用程序通訊的一種機制。它可以讓Web服務器在必要的時候啓動一個額外的程序來處理動態內容，所以，CGI稱爲Common Gateway Interface（通用網關接口），這種通用網關接口就是讓Web服務器可以跟應用程序服務器打交道的一種協議（能夠將其理解成一種協議）。

　　所以當客戶端向服務器請求一個動態內容index.cgi時，對於這個cgi腳本，httpd能夠判斷出客戶端請求這個腳本，須要一個應用程序來執行，因而它就發起一個進程，應用程序處理完成後，再從新響應給httpd，httpd將其組合起來響應給客戶端。過程如：

　　　　Client --> httpd(index.cgi) --> Spawn Proccess(index.cgi) --> httpd --> Client

　　那麼什麼語言能夠開發CGI或動態網站呢？　　其實只要是程序語言均可以開發成動態網站，就連C也是。只不過C語言是編譯型語言，開發成網站後須要編譯成可執行程序。而既然全部語言都能開發動態網站，那所以就須要讓Web服務器可以識別究竟是哪種語言開發的，只要Web服務器可以識別，它就能調用相應的程序執行。但不管哪種語言開發的都叫CGI，那麼Web服務器怎麼去識別呢？其實，每個可執行程序均可根據其前幾個字節判斷出來可執行程序的類型，也可以調用相應的執行程序工做，只不過一般都叫作CGI或者說它們均可以以CGI的方式跟Apache結合起來工做。

 

應用程序與Apache的其它結合方式以及LAMP概念的引入：

　　有些程序跟Apache不只僅是CGI一種，爲了下降Web服務器的工做壓力，能夠經過這樣一種方式讓動態服務器進程跟Web服務器結合：Web服務器不管用或不用，動態進程也像Web服務器同樣事先生成好進程，有一個專門啓動的服務叫動態服務啓動進程，它也建立了不少空閒子進程。當有人向Web服務器發起內容請求時，而Web服務器發現這是一個動態內容時，它要發起一個新的進程來響應執行這個動態內容，而進程已經建立好了就不用發起了。因而Web服務器只須要將這個動態請求的頁面交給一個空閒的服務器進程執行一次就能夠了。因而這些動態進程的建立和回收再也不由Web服務器維護了，而是由這些動態的專門的管理進程（Method Process）來管理。像這種Web服務器跟動態服務器通訊的機制叫fastcgi，fastcgi是向PHP工做的一種機制，像Python還有別的工做機制。

　　在這種機制之下，動態服務器進程就不用再由Web服務器控制啓動或銷燬了，而是由一個專門的進程負責，而這個專門的進程是工做在某個端口或套接字上個Web服務器通訊，所以此時Web服務器與應用程序服務器能夠放在不一樣的主機上了。如能夠分爲兩臺物理服務器，一個物理服務器專門用於接收用戶請求的靜態內容，若是請求的是靜態內容直接從本地返回便可。當用戶請求的是動態內容時，此服務器會經過本地的TCP/IP協議由本地網絡將請求發送給另一臺主機，另外一臺主機上運行的有一個動態服務進程，同時它還建立了不少子進程隨時等待響應發送過來的請求。請求處理完成後，經過網絡將結果返回給Web服務子進程，子進程再響應給客戶端。子進程在響應給客戶端。這樣靜態內容和動態內容就可使用不一樣的主機分別進行處理了。這就是處理動態內容的服務器被稱爲應用進程服務器的緣由，因此它是專門用來處理應用程序或動態內容的。

　　這樣一來，前端就能夠放置兩個Web服務器了，不管哪一臺服務器用到動態內容時，均可以嚮應用程序服務器發起執行內容的請求。這正如咱們曾經說過的一個域名能夠有有兩個A記錄，所以有一個域名叫www.test.com，用戶請求時，來自不一樣用戶的請求解析到不一樣的Web服務器上，這臺Web服務器若是靜態內容都是同樣的，當它請求一些動態內容須要執行的話，只須要將內容交給同一臺服務器一執行將結果返回便可，這就是Web服務器站點，這也是動態內容跟靜態內容怎麼進行分層次的（程序分層）。這樣就實現了各司其職，一我的只完成特定的工做。

　　咱們在繼續討論這個話題，程序還有一種特性，咱們都知道程序是由指令和數據組成的，若是咱們要處理的數據很是大，而早期數據都是放在文件當中的,如：用戶帳號密碼在/etc/passwd和/etc/shadow中，passwd和shadow就是一個數據庫文件，可是條目若是多達數十萬種，咱們從中挑選一個數據會很是慢，並且管理起來會很是不方便。所以必需要有一種行之有效的數據管理機制，專門用來管理數據的服務器就叫數據庫服務器，存儲數據的地方叫數據庫，而可以幫助管理數據的，運行數據庫軟件的這種服務器就叫數據庫服務器。

　　當數據量很是大時再用簡單的文本文件管理數據就變得很是低效了，因而就須要數據庫服務器。所以須要有服務可以幫咱們存儲這種數據並且可以專門用某種接口將這種數據服務提供給提供給額外的其它應用程序或直接提供給用戶，這種接口能夠理解爲數據庫的API。所以若將數據庫服務器創建好了，用戶一旦須要處理程序執行，那個動態腳本就須要在應用程序服務器上執行，而應用程序服務器要執行一個腳本，這個腳本中涉及到數據處理，那這個數據處理的請求就須要提交給數據服務進程了。實際上不管是應用程序服務器仍是數據庫服務器都是CPU密集型的（CPU-bound，對CPU的佔用率很是大），所以前端的用戶愈來愈多致使後端的應用程序服務器忙不過來了，響應的速度回很是慢，此時能夠考慮分層，將數據庫服務器獨立出來，再找一臺物理機專門用來提供數據庫服務。所以當程序須要訪問數據時，應用程序服務器再次向後端的數據庫服務器發起請求，由數據庫服務器將數據返回給應用程序服務器，應用程序服務器再格式化成HTML文檔返回給Web服務器進程，由Web服務器進程響應給客戶端。

　　此時分出類三層，靜態內容層、應用程序層、數據層。而每個對應的層上須要一個專門的服務器提供，前端使用httpd，也叫Apache。中間使用PHP，數據層使用MySQL。它們都運行在Linux上，因而簡稱爲LAMP。

 

安裝配置使用httpd：

　　httpd自己是受SELinux控制的，可是事先應讓SELinux處於permission或disabled的狀態，否則不少配置均可能沒法正常運行。

關閉SELinux：

httpd的rpm包組成：

　　httpd.i386：服務器端包；

　　httpd-devel：開發包，包括一些開發庫和頭文件；

　　httpd-manual：手冊，httpd官方文檔；

 

安裝httpd：

　　/etc/httpd/conf/magic：用於定義本地如何識別經過MIME編碼而來的其它多媒體（非純文本文檔）；

　　/etc/rc.d/init.d/httpd：服務腳本，其配置文件在/etc/sysconfig/httpd，爲服務腳本提供配置文件，能夠把配置文件中的某些參數一改服務腳本就可以工做在不一樣模式下了；

　　/usr/bin/ab：Apache服務器的壓力測試工具，可用來評估Apache服務器的工做性能；

　　/usr/bin/{htdbm,htdigest,htpasswd}：建立Apache用戶認證帳號密碼的幾個命令；

啓動服務：

查看80端口：

查看系統進程：

測試訪問：

 

歡迎頁面位置： 

　　歡迎頁面重命名後將不會被訪問：

　　新建歡迎頁面：

　　其實Web服務器的默認配置頁面是須要在Web服務器的配置文件中指定是哪一個頁面的，而不是簡單的隨意給定一個頁面。

 

Web服務器自己的配置文件定義：

　　配置文件分爲三個字段：

　　　　注意：第二字段和第三字段不能同時生效，默認使用主服務器段，即第二字段。

　　#後有空格爲註釋，#後無空格爲可啓用的選項，在Apache中叫指令，由於Apache的配置文件由directive（指令，不區分大小寫）和其value（根據須要有哦可能區分大小寫）組成；

　　Apache配置文件的每個指令的值在Apache官方文檔中有指定的參考。

　　安裝參考文檔的rpm包：

　　

　　再看配置文件/etc/httpd/conf/httpd.conf：

 

 

　　　　ServerRoot：服務器的根目錄或工做目錄，不到萬不得已不要改，不少其它路徑都是相對於這個路勁而言的；

　　　　PidFile：保存pid號的文件的路徑（相對路徑，相對於ServerRoot而言），每個進程都有一個pid號，尤爲是服務類的軟件運行起來後這個pid號會保存在以這個進程命名的文件中；

　　　　Timeout：超時時間，TCP協議三次握手創建鏈接發起請求，若出現TCP的第一次握手發起後等它第二次就無響應了的狀況，此處Timeout指的就是處於等待狀態的時間，單位爲秒；

　　　　KeepAlive：是否使用長鏈接，通常狀況下，服務器的訪問量不是特別大，應該打開長鏈接，會顯著提升性能，由於若不打開長鏈接每一次請求都會三次握手，此處將其改成On；

　　　　MaxKeepAliveRequests：不能讓用戶一直處於長鏈接，所以開啓長鏈接後須要設定最多一次請求多少個。設定爲0表示無限制，只要用戶本身不斷開就永遠不斷開了；

　　　　KeepAliveTimeOut：長鏈接的斷開時長，單位爲秒；若只請求了一個資源，不能讓請求一直佔用這個資源不斷開，對於繁忙的服務器來說，應儘量將這個時間下降一些，既可以幫助一個用戶的屢次請求，又可以儘量下降因爲空閒鏈接空閒而致使的資源浪費。對於不一樣的服務器來說這個值須要本身測試才能得出，如使用ab命令或LoaderRunner（HP公司專業級的測試工具）；

 

　　LoaderRunner：HP公司專業級的測試工具，能夠模擬應用程序的真實場景而對服務器作接近於真實的測試。（嘗試自學）

 

MPM：Multi Path Modules，多道處理模塊

　　當多個用戶同時請求時，有多進程響應多個請求、一個進程響應多個請求等方式，而MPM就是定義在一個Web服務響應多個請求時所工做的模型的。

　　經常使用方式：（面試中多是問到最多的話題，做爲運維工程師是否瞭解Web服務器？請講述這幾種模型它們彼此之間的聯繫和區別（用專業的語言通俗易懂的講給別人聽））

• mpm_winnt：

　　是Windows NT上專用的，由於Windows是原生支持多線程的，因此是Windows上使用的一種特殊處理機制；

• prefork：

　　預先生成進程，一個請求用一個進程響應。

　　好處在於穩定可靠，任何一個進程崩潰了都不會影響其它請求，但性能比較差，尤爲是多個用戶請求併發量很大的時候性能不好，由於它對資源的消耗量很是多，並且會涉及到大量的進程切換。

• worker：

　　基於線程工做的，一個進程響應多個用戶請求，但一個進程下使用多個線程來響應用戶請求，一個請求用一個線程響應。

　　首先，它會生成兩個工做進程，而咱們都知道線程是進程的子單位，所以線程必定是處於進程當中的，因此在worker模型下，Web服務器會生成多個進程（通常而言，默承認能啓動兩個）。但啓動的進程不是用來響應用戶請求的，而是每個進程會生成多個線程，用一個線程響應一個用戶請求。這樣的好處在於對於Thread而言，因爲多個線程共享同一個進程的資源，因此若是某一個進程曾經訪問過某一個文件並且已經打開了的話，那麼第二個線程訪問同一個文件就不用再打開直接訪問便可，這樣效率比較高；

　　可是多個線程在共享資源時，若是要寫一個資源的話會致使資源爭用的，因此爲了不資源競爭，必需要實現加鎖，所以若是不能良好的避免鎖競爭的話，事實上線程是否比進程效率更高，這個很難說的清楚,尤爲是Linux不是原生態支持線程的。因此worker模型通過測試發如今Linux上還不如prefork模型性能好，這也是爲何默認使用prefork而不是worker模型的緣由。

• event

　　基於事件驅動，一個進程處理多個用戶請求，可是是同時處理多個，而不是使用線程響應的，使用一個進程處理多個請求。

　　在Apache2.4後才原生態支持event，而且默認就使用event，只要系統庫（I/O）支持；由於event纔是最強大的，Nginx就是使用event機制，但在Apache2.2中默認使用的是prefork的模型

 

prefork和worker模型在配置文件/etc/httpd/conf/httpd.conf中有各自不一樣的屬性的定義：

　　prefork：

　　　　<IfModule...>：意爲若是某個模塊配置（啓用）了的話，是Apache中的一種重要的指令使用機制，其中的指令只對這一個片斷有效；能夠理解爲容器，這個容器裝有全部的配置屬性，只對這個容器對應的那個對象生效；

　　　　StartServers：服務器剛啓動時啓動的空閒進程數；

　　　　MinSpareServers：最小空閒進程數；

　　　　MaxSpareServers：最大空閒進程數；

　　　　MaxClients：最多容許多少個請求數同時鏈接；

　　　　ServerLimit：指定MaxClients的上限值，須要先關掉服務器，kill掉進程再重啓服務器纔可生效；

　　　　MaxRequestsPerChild：Web服務會生成不少個服務器進程，這些進程接收用戶請求，用戶請求結束了，那這個進程就空閒了，空閒後可能沒辦法kill了，由於又有新的用戶請求須要予以響應，此處定義每個進程最多響應多少次；

　　worker：

　　　　StartServers：剛開始啓動的進程數；

　　　　ThreadPerChild：每個進程能夠生成多少個線程；

　　　　MinSpareThreads、MaxSpareThreads定義的是整體線程數，而不是單個進程的線程數；

 

查看當前服務器支持的模型：（不包括worker模型）：

　　httpd -l　　#列出當前服務器進程編譯的時候所支持的模塊
　　httpd_core.c、core：不只包括httpd還包括反向代理等各類額外的功能，還包括緩存等；
　　mod_so：支持動態模塊加載；

　　若未來想使用worker模型的服務的話，使用httpd.worker便可，httpd默認使用的是prefork。

演示使用worker模型的Web服務器：

　　修改服務器的啓動腳本配置文件便可：

　　若使用event模型，改爲event便可：

　　在httpd2.2中，event是測試模型，不建議使用，2.4之後event才真正成熟起來併成爲獨立的rpm。

 

繼續來看咱們httpd的配置文件：

　　Listen：指定監聽的地址和端口，地址可省略，若不帶IP地址，說明監聽當前主機上的全部地址的80端口。Listen指令可出現屢次，所以能夠指定不一樣的端口；

　　LoadModule：指定Apache啓動時裝載的模塊，格式：LoadModule 模塊名稱 模塊路徑；

　　include conf.d/*.conf：包含其它配置文件；

　　User、Group：Apache的work進程都要使用普通用戶運行，故此處指定這個普通用戶與組