⑴ 第五章：Web伺服器
5.1各種形狀和尺寸的Web伺服器
Web伺服器會對HTTP請求進行處理並提供響應。術語「Web伺服器」可以用來表示Web伺服器的軟體，也可以用來表示提供Web頁面的特定設備或計算機。
Web伺服器有著不同的風格、形狀和尺寸。有普通的10行Perl腳本的Web伺服器、50MB的安全商用引擎以及極小的卡上伺服器。但不管功能有何差異，所有的 Web伺服器都能夠接收請求資源的 HTTP請求，將內容回送給客戶端（參見圖1-5)。
5.1.1Web伺服器的實現
Web伺服器實現了HTTP和相關的TCP連接處理。負責管理Web伺服器提供的資源,以及對Web伺服器的配置、控制及擴展方面的管理。
Web伺服器邏輯實現了HTTP 協議、管理著Web資源，並負責提供Web伺服器的管理功能。Web伺服器邏輯和操作系統共同負責管理TCP連接。底層操作系統負責管理底層計算機系統的硬體細節，並提供了TCP/IP網路支持、負責裝載Web資源的文件系統以及控制當前計算活動的進程管理功能。
5.3實際的Web伺服器會做些什麼
例5-1顯示的 Perl伺服器是一個Web伺服器的小例子。最先進的商用Web伺服器要比它復雜得多，但它們確實執行了幾項同樣的任務，如圖5-3所示。
(1)建立連接一—接受一個客戶端連接，或者如果不希望與這個客戶端建立連接，就
將其關閉。
(2)接收請求——從網路中讀取一條HTTP請求報文。(3)處理請求——對請求報文進行解釋，並採取行動。(4)訪問資源-———訪問報文中指定的資源。
(5)構建響應——創建帶有正確首部的 HTTP響應報文。(6)發送響應——將響應回送給客戶端。
(7)記錄事務處理過程—-將與已完成事務有關的內容記錄在一個日誌文件中。
5.4第一步——接受客戶端連接
如果客戶端已經打開了一條到伺服器的持久連接，可以使用那條連接來發送它的請求。否則，客戶端需要打開一條新的到伺服器的連接（回顧第4章，復習一下HTTP的連接管理技術)。
5.4.1處理新連接
客戶端請求一條到Web伺服器的TCP連接時，Web伺服器會建立連接，判斷連接的另一端是哪個客戶端，從TCP連接中將IP地址解析出來。'一旦新連接建立起來
並被接受，伺服器就會將新連接添加到其現存Web伺服器連接列表中，做好監視連接上數據傳輸的准備。
Web伺服器可以隨意拒絕或立即關閉任意一條連接。有些Web伺服器會因為客戶端IP地址或主機名是未認證的，或者因為它是已知的惡意客戶端而關閉連接。Web伺服器也可以使用其他識別技術。
5.4.2客戶端主機名識別
可以用「反向 DNS」對大部分Web伺服器進行配置，以便將客戶端IP地址轉換成客戶端主機名。Web伺服器可以將客戶端主機名用於詳細的訪問控制和日誌記錄。但要注意的是，主機名查找可能會花費很長時間，這樣會降低Web事務處理的速度。很多大容量Web伺服器要麼會禁止主機名解析，要麼只允許對特定內容進行解析。
可以用配置指令HostnameLookups啟用Apache的主機查找功能。比如，例5-2中的Apache配置指令就只打開了HTML和CGI資源的主機名解析功能。
例5-2配置Apache,為 HTML和CGI資源查找主機名
HostnameLookups off
<Files ~" - 《html |htmlcgi)$">
HostnameLookups on
</Files>
5.5第二步—接收請求報文
連接上有數據到達時，Web伺服器會從網路連接中讀取數據，並將請求報文中的內容解析出來（參見圖5-5)。
解析請求報文時，Web伺服器會:
·解析請求行，查找請求方法、指定的資源標識符（URI)以及版本號，3各項之
間由一個空格分隔，並以一個回車換行(CRLF)序列作為行的結束,「
·讀取以CRLF結尾的報文首部;
檢測到以CRLF結尾的、標識首部結束的空行（如果有的話)﹔
·如果有的話（長度由content-Length首部指定)，讀取請求主體。
解析請求報文時，Web伺服器會不定期地從網路上接收輸入數據。網路連接可能隨時都會出現延遲。Web伺服器需要從網路中讀取數據，將部分報文數據臨時存儲在內存中,直到收到足以進行解析的數據並理解其意義為止。
5.5.1 報文的內部表示法
有些Web伺服器還會用便於進行報文操作的內部數據結構來存儲請求報文。比如，數據結構中可能包含有指向請求報文中各個片段的指針及其長度，這樣就可以將這些首部存放在一個快速查詢表中，以便快速訪問特定首部的具體值了（參見圖5-6)。
5.5.2連接的輸入/輸出處理結構
高性能的 Web伺服器能夠同時支持數千條連接。這些連接使得伺服器可以與世界各地的客戶端進行通信，每個客戶端都向伺服器打開了一條或多條連接。某些連接可能在快速地向Web伺服器發送請求，而其他一些連接則可能在慢慢發送，或者不經常發送請求,還有一些可能是空閑的，安靜地等待著將來可能出現的動作。
因為請求可能會在任意時刻到達，所以Web伺服器會不停地觀察有無新的Web請求。不同的Web伺服器結構會以不同的方式為請求服務，如圖5-7所示。
·單線程Web伺服器(參見圖5-7a)
單線程的Web伺服器一次只處理一個請求，直到其完成為止。一個事務處理結束之後，才去處理下一條連接。這種結構易於實現，但在處理過程中，所有其他連接都會被忽略。這樣會造成嚴重的性能問題，只適用於低負荷的伺服器，以及type-o-serve這樣的診斷工具。
·多進程及多線程Web伺服器(參見圖5-7b)
多進程和多線程Web伺服器用多個進程,或更高效的線程同時對請求進行處理。3可以根據需要創建，或者預先創建一些線程/進程。°有些伺服器會為每條連接分配一個線程/進程，但當伺服器同時要處理成百、上千，甚至數以萬計的連接時，需要的進程或線程數量可能會消耗太多的內存或系統資源。因此，很多多線程Web伺服器都會對線程/進程的最大數量進行限制。
·復用I/O的伺服器(參見圖5-7c)
為了支持大量的連接，很多Web伺服器都採用了復用結構。在復用結構中，要同時監視所有連接上的活動。當連接的狀態發生變化時（比如，有數據可用，或出現錯誤時)，就對那條連接進行少量的處理，處理結束之後，將連接返回到開放連接列表中，等待下一次狀態變化。只有在有事情可做時才會對連接進行處理,在空閑連接上等待的時候並不會綁定線程和進程。
·復用的多線程Web伺服器（參見圖5-7d)
有些系統會將多線程和復用功能結合在一起，以利用計算機平台上的多個CPU.多個線程（通常是一個物理處理器）中的每一個都在觀察打開的連接(或打開的連接中的一個子集)，並對每條連接執行少量的任務。
5.6第三步———處理請求
一旦Web伺服器收到了請求，就可以根據方法、資源、首部和可選的主體部分來對請求進行處理了。
有些方法（比如POST)要求請求報文中必須帶有實體主體部分的數據。其他一些方法（比如OPTIONS）允許有請求的主體部分，也允許沒有。少數方法（比如GET)禁止在請求報文中包含實體的主體數據。
這里我們並不對請求的具體處理方式進行討論，因為本書其餘大多數章節都在討論這個問題。
5.7第四步——-對資源的映射及訪問
Web 伺服器是資源伺服器。它們負責發送預先創建好的內容，比如HTML頁面或JPEG 圖片，以及運行在伺服器上的資源生成程序所產生的動態內容。
5.7.1 docroot
Web伺服器支持各種不同類型的資源映射，但最簡單的資源映射形式就是用請求URI作為名字來訪問Web伺服器文件系統中的文件。通常，Web伺服器的文件系統中會有一個特殊的文件夾專門用於存放Web內容。這個文件夾被稱為文檔的根目錄(document root，或docroot)。Web伺服器從請求報文中獲取URI，並將其附加在文檔根目錄的後面。
在圖5-8中，有一條對/specials/saw-blade.gif 的請求到達。這個例子中Web伺服器的文檔根目錄為/us/local/httpd/files。Web伺服器會返迴文件/usr/local/httpd/files/specials/saw-blade.gif。
在配置文件httpd.conf中添加一個 DocumentRoot行就可以為Apache Web伺服器設置文檔的根目錄了:
DocumentRoot /usr/ local/httpd/files
伺服器要注意，不能讓相對URL退到docroot之外，將文件系統的其餘部分暴露出來。比如，大多數成熟的Web伺服器都不允許這樣的URI看到Joe的五金商店文檔根目錄上一級的文件:
http://www.joes-hardware.com/ ..
5.8.3重定向
Web伺服器有時會返回重定向響應而不是成功的報文。Web伺服器可以將瀏覽器重定向到其他地方來執行請求。重定向響應由返回碼3XX說明。Location響應首部包含了內容的新地址或優選地址的URI。重定向可用於下列情況。
·永久刪除的資源
資源可能已經被移動到了新的位置，或者被重新命名，有了一個新的URL。Web伺服器可以告訴客戶端資源已經被重命名了，這樣客戶端就可以在從新地址獲取資源之前，更新書簽之類的信息了。狀態碼301 Moved Permanently就用於此類重定向。·臨時刪除的資源
如果資源被臨時移走或重命名了，伺服器可能希望將客戶端重定向到新的位置上去。但由於重命名是臨時的，所以伺服器希望客戶端將來還可以回頭去使用老的URL，不要對書簽進行更新。狀態碼303 See Other以及狀態碼307 TemporaryRedirect就用於此類重定向。
⑵ web的工作原理
web的工作原理：
1、用戶在瀏覽器中輸入要訪問的web站點地址或在已打開的站點點擊超鏈接。
2、由DNS進行域名解析，找到伺服器的IP地址，向該地址指向的web伺服器發出請求。
3、web伺服器根據請求將URL地址轉換為頁面所在的伺服器上的文件全名，查找相應的文件。
4、若URL指向靜態文件，則伺服器將文件通過http協議傳輸給用戶瀏覽器；若HTML文檔中嵌入了ASP,PHP,JSP等程序，則由伺服器直接運行後返回給用戶；
如果web伺服器所運行程序包含對資料庫的訪問，伺服器會將查詢指令發送給資料庫伺服器，對資料庫執行查詢操作，查詢結果由資料庫返回給web伺服器，再由web伺服器將結果潛入頁面，並以html格式發送給瀏覽器。
5、瀏覽器解釋html文檔，在客戶端屏幕上展示結果。
(2)web伺服器響應擴展閱讀
web的特點
1、圖形化
Web 非常流行的一個很重要的原因就在於它可以在一頁上同時顯示色彩豐富的圖形和文本的性能。在Web之前Internet上的信息只有文本形式。Web可以提供將圖形、音頻、視頻信息集合於一體的特性。
2、與平台無關
無論用戶的系統平台是什麼，你都可以通過Internet訪問WWW。瀏覽WWW對系統平台沒有什麼限制。無論從Windows平台、UNIX平台、Macintosh等平台我們都可以訪問WWW。
3、分布式的
大量的圖形、音頻和視頻信息會佔用相當大的磁碟空間，我們甚至無法預知信息的多少。對於Web沒有必要把所有信息都放在一起，信息可以放在不同的站點上，只需要在瀏覽器中指明這個站點就可以了。
4、動態的
由於各Web站點的信息包含站點本身的信息，信息的提供者可以經常對站上的信息進行更新。如某個協議的發展狀況，公司的廣告等等。一般各信息站點都盡量保證信息的時間性。所以Web站點上的信息是動態的、經常更新的，這一點是由信息的提供者保證的。
5、交互的
Web的交互性首先表現在它的超鏈接上，用戶的瀏覽順序和所到站點完全由他自己決定。另外通過FORM的形式可以從伺服器方獲得動態的信息。用戶通過填寫FORM可以向伺服器提交請求，伺服器可以根據用戶的請求返回相應信息。
⑶ web伺服器是什麼
WEB伺服器也稱為WWW(WORLD WIDE WEB)伺服器，主要功能是提供網上信息瀏覽服 務。
(1)應用層使用HTTP協議。
(2)HTML文檔格式。
(3)瀏覽器統一資源定位器(URL)。
WWW代表萬維網的意思
Web伺服器可以解析(handles)HTTP協議。當Web伺服器接收到一個HTTP請求(request)，會返回一個HTTP響應(response)，例如送回一個HTML頁面。為了處理一個請求(request)，Web伺服器可以響應(response)一個靜態頁面或圖片，進行頁面跳轉(redirect)，或者把動態響應(dynamic response)的產生委託(delegate)給一些其它的程序例如CGI腳本，JSP(JavaServer Pages)腳本，servlets，ASP(Active Server Pages)腳本，伺服器端(server-side)JavaScript，或者一些其它的伺服器端(server-side)技術。無論它們(譯者註：腳本)的目的如何，這些伺服器端(server-side)的程序通常產生一個HTML的響應(response)來讓瀏覽器可以瀏覽。
要知道，Web伺服器的代理模型(delegation model)非常簡單。當一個請求(request)被送到Web伺服器里來時，它只單純的把請求(request)傳遞給可以很好的處理請求(request)的程序(譯者註：伺服器端腳本)。Web伺服器僅僅提供一個可以執行伺服器端(server-side)程序和返回(程序所產生的)響應(response)的環境，而不會超出職能范圍。伺服器端(server-side)程序通常具有事務處理(transaction processing)，資料庫連接(database connectivity)和消息(messaging)等功能。
雖然Web伺服器不支持事務處理或資料庫連接池，但它可以配置(employ)各種策略(strategies)來實現容錯性(fault tolerance)和可擴展性(scalability)，例如負載平衡(load balancing)，緩沖(caching)。集群特徵(clustering—features)經常被誤認為僅僅是應用程序伺服器專有的特徵。
⑷ 計算機網路——應用層-Web&HTTP
計算機網路系列博文——目錄
20世紀90年代初
網際網路應用
Web應用的組成
由對象組成。對象是一個文件，如HTML文件，JPEG圖像，Java程序，視頻片段等。
對象可通過一個URL地址定址。
Web頁面常由一個HTML基本文件和多個引用對象構成。
URL(Uniform Resoure Locator)：統一資源定位器 RFC1738
用以定址Web對象
由一個存放對象的伺服器主機名和對象路徑名構成。
HTTP 由客戶端程序和服務端程序實現，二者通過交換HTTP報文會話。
HTTP規范定義了HTTP客戶端和服務端之間的通信協議。
Web瀏覽器實現HTTP客戶端,請求、接收、展示Web對象
Web伺服器實現HTTP服務端,響應客戶的請求，發送對象
HTTP使用TCP作為支撐運輸層協議。
埠：80
無狀態協議 伺服器不保存關於客戶的任何信息
伺服器向客戶發送被請求的文件，而不存儲任何關於客戶的狀態信息。
往返時間（Round-Trip Time,RTT)
一個短分組從客戶到伺服器然後再返回客戶所花費的時間。
某客戶和伺服器的一次會話中，每個請求/響應對通過一個單獨的TCP連接傳輸
HTTP 1.0版本使用非持續性連接
對多個待獲得的web對象，客戶端一次只請求一個對象，待前一個對象接收完畢後再發送對下一個對象的請求。
時間分析
瀏覽器通常支持並行的TCP連接。並行TCP連接數通常為5~10個。
對多個待獲得的web對象，客戶端一次可同時建立多個TCP連接，以同時請求多個web對象。
時間分析
某客戶和伺服器的一次會話中，所有請求/響應對經同一TCP連接傳輸
HTTP 1.1版本在默認方式下採用持續連接，但也可由客戶端/伺服器配置為非持續連接。
客戶端只有收到前一個響應後才發送新的請求
可理解為同個TCP內的串列
時間分析
客戶端只要遇到一個引用對象就盡快發出請求
可理解為同個TCP內的並行
HTTP 1.1的默認選項
時間分析
TCP 三次握手
1.客戶向伺服器發送一個小TCP報文段；
2.伺服器用一個小TCP報文段做出確認和響應；
3.客戶向伺服器返回確認和一個HTTP請求報文；
4.伺服器返回相應HTML文件;
HTTP規范
RFC 1945 , RFC 2616
用ASCII文本書寫
HTTP協議有兩類消息，請求消息(request)和響應消息(response)
請求行 HTTP請求報文的第一行
方法
首部行 請求行後繼的其它行，包含一些會話信息
空行 回車換行，分隔首部行和實體體
實體體(entity body)
GET方法下實體體為空
POST方法下實體體包含表單信息
狀態行
常見狀態碼
首部行
空行
實體體
包含了所請求的對象
HTTP是無狀態協議，但cookie技術允許伺服器識別用戶
cookie在無狀態的HTTP之上建立一個用戶會話層
參見 [RFC 6265]
cookie組件
cookie技術的爭議在於它可能泄露用戶的隱私
代表原Web伺服器來響應HTTP請求的網路實體
Web緩沖器通常由ISP購買並安裝
允許緩存器證實其緩存的副本是新的。
如果緩存器有web對象最新的版本，則初始伺服器不需要向緩存器發送該web對象
在HTTP請求消息中聲明所持有版本的日期
If-modified-since: <date>
如果緩存的版本是最新的，則響應消息中不包含對象
HTTP/1.0 304 Not Modified
內容分發網路（Content Distribution Network,CDN）
基於緩存器技術，CDN公司在網際網路上安裝許多地理上分散的緩存器，使得大流量本地化。
有共享CDN(Akamai,Limelight)，專用CDN（谷歌，微軟）
⑸ 伺服器響應慢是怎麼回事和怎麼解決響應速度慢
這種問題挺復雜的，有些原因真的很出意料，一般程式化的方法還找不到。
1.先用瀏覽器F12控台查看一下網頁載入資源的情況，看是不是某些資源載入慢的緣故。
2.如果不是的話， 那就檢查一下是不是網路問題。
3.如果都不是上面的問題，你再去看下伺服器的狀況，應該有後台可以看，看下是不是帶寬不足。（或者用top，iptraf命令看一下）
4.最後還有問題的話看下你php代碼是不是有問題，用xhprof看下代碼哪裡慢。
---------
例1：
伺服器: 戴爾 PowerEdge R620 Rack Mount Chassis
今天公司的 web伺服器響應異常的慢 平常 200ms 執行完畢的一個action，現在要 2秒多才能執行那個完畢。
之前也出現過這種狀況,但再重啟之後就一般及解決了。
遍歷網上
說是
1、網路原因 2、系統原因 3、硬體原因
首先分析網路原因 我 ping 伺服器的 接收到響應要1ms，平常都是小於 1ms
2、系統原因
我查看了任務管理器發現 CPU 橫容易就奔向100%了。
4 個cpu 核心 馬上沖向頂端持平了。
3、硬體原因
聽網上說可能還有一部分磁碟 i/o 也會導致運行速度大減的
2、3 部分圖片當時很著急解決問題沒有截圖、
下面是今天晚上伺服器 恢復正常後的基本空閑時的cpu 狀況、和磁碟讀取狀況
想問一下、普通我這種刀片伺服器正常運行時oracle 的一般最高讀寫速度、為什麼怎樣找到程序中那個可能正執行死循環的程序
經過之前一天的推測，覺得應該是伺服器上的另一個應用伺服器，出現了死循環，聯系了此程序開發人員讓其恢復了上一個版本，問題就沒有了。
就是那一個個驗證推測麻煩，花了我一天的時間，想直接知道哪裡死循環。
經過之前一天的推測，覺得應該是伺服器上的另一個應用伺服器，出現了死循環，聯系了此程序開發人員讓其恢復了上一個版本，問題就沒有了。
就是那一個個驗證推測麻煩，花了我一天的時間，想直接知道哪裡死循環。
例2：
我的WIN2003獨立伺服器（P4 2.8G/1G的方正商用機，非專業伺服器），ACCESS資料庫有800多兆，同時在線會員100多人。瀏覽速度很慢，日發帖從1000多銳減到200多貼，網友怨聲載道，不得已才轉換到DZ。
轉換後DZ的資料庫有600多兆。剛開始挺快的，隨後升級到DZ6.1，現在過了才1個多月，伺服器響應越來越慢。CPU佔用並不高，通常不到20%，內存佔用好像也正常。就是經常硬碟燈一直亮（是常亮，不是閃亮），每到這時論壇頁面就打不開，有時光顯示頁面頭部，要等很長時間。硬碟燈不常亮的時候速度挺快。
以前是一兩天出現一次，後來越來越頻繁，現在過不多大會兒就出現一次，簡直受不了了。
相信很多人在用windows2003伺服器或者vps，而且一開始用，速度都相當的快，但是過了幾天速度變慢了很多，也會遇到有時候網站打開卡等現象，即使網站沒什麼流量也會出現。
有時候就會懷疑是不是我的伺服器或者vps很差勁，買到假貨了？其實不然。
其實這些問題作祟的都是w3wp.exe這個iis進程在搗鬼。
在WINDOWS2003+IIS6下，經常出現w3wp的內存佔用不能及時釋放，從而導致伺服器響應速度很慢。
遇到這些現象，我們可以用以下方法進行解決，不影響網站運營及系統問題。
可以做以下配置修改進行改善：
1、在IIS中對每個網站進行單獨的應用程序池配置。即互相之間不影響。
2、設置應用程序池的回收時間，默認為1720小時，可以根據情況修改。同時，設置同時運行的web工作進程數目為1。再設置當內存或者cpu佔用超過多少，就自動回收內存。
一般來說就可以解決了。但仍然會出現個別網站因為程序問題，不能正確釋放。
那麼，怎麼樣才能找到是哪一個網站的？解決辦法：
1、在任務管理器中增加顯示pid欄位。就可以看到佔用內存或者cpu最高的進程pid
2、在命令提示符下運行iisapp -a。注意，第一次運行，會提示沒有js支持，點擊確定。然後再次運行就可以了。這樣就可以看到pid對應的應用程序池
3、到iis中察看該應用程序池對應的網站，就可以了。