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進程都要使用普通用戶運行，故此處指定這個普通用戶與組