自上世紀80年代末至90年代扯訓聯網誕生以來，Web服務可以說是在互聯網的普及程序當中起到了巨大的作用，而Web服務應該是當今世界上普通用戶訪問互聯網的最廣泛的方式了，用戶只需在瀏覽器中輸入所謂網址的方式即可瀏覽互聯網上的海量資訊，而瀏覽器這種瘦客戶端的互動方式也是目前最主流的互動方式，
Web服務的基礎是http協議，基于http這個應用層協議才能實作客戶端和服務器端之間的資料互動，客戶端通過http協議向服務器端發送請求，服務器端接收到這個請求之后，服務器端基于http協議也能夠理解客戶端發送的請求的含義，同時回傳客戶端所請求的內容至客戶端，而客戶端接收到服務器端發送過來的回應之后就能夠決議相應內容并通過特定的格式展示給用戶，我們可以看到在此程序中，http協議作為雙方能夠實作通信的這樣一種標準而言至關重要，那在介紹http協議的相關知識之前我們在復習一些關于計算機網路的基礎知識，
一、網路協議基礎簡述
1、傳輸層協議：提供行程地址
我們知道，協議是分層的，正如目前互聯網事實上的標準TCP/IP協議族就分為了四層，自下而上依次是：物理層、網際介面層、傳輸層、應用層，每一層所完成的功能不盡相同，這樣做的好處是可以將一個大而復雜的問題拆分為許多小而相對獨立的邏輯單元，上層可以很方便的呼叫其下一層次所提供的服務用以完成自身特定的功能；同時當每一層次的具體實作細節改變時，呼叫其介面的上層服務也無需做人也修改，不至于影響全域，那TCP/IP這四層協議當中的傳輸層協議作用之一就是用來提供在主機上運行的各行程需要實作與外部主機通信時需要監聽的地址埠，
傳輸層協議主要有TCP協議和UDP協議兩大類，TCP（Transfer Control Protocol）協議是面向連接的協議，即通信雙方在通信之前需要建立專用于通信的虛擬鏈路，在通信結束后需要將鏈路拆除，此種方式可保證通信的可靠性，但效率會受到一定程度的影響，UDP（User Datagram Protocol）協議則是無連接的協議，即通信雙方在通信之前無需建立虛擬鏈路，此種方式不能保證通信的可靠性，但效率比TCP協議要高，
TCP和UDP是兩個相互獨立的協議，它們各有一套埠號用來提供給各行程使用，范圍為0-65535（其中源埠16位，目標埠16位），根據埠使用物件劃分,可分為如下幾類:
- 0-1023:眾所周知的埠，為特權埠，只有管理員才有權限操作，為了行業標準的統一及用戶使用的便捷性，IANA定義了將此類埠永久地分配給一批特定的應用程式使用，如22/tcp分配給了ssh服務，80/tcp分配給了http服務，443分配給了https服務；
- 1024-41951：為注冊埠，但要求不是特別嚴格，當某程式需要注冊為服務監聽某埠以實作與外部主機通信時使用，如：11211/tcp(memcached)，11211/udp(memcached)，3306/tcp(mysql)；
- 41952+：為客戶端程式隨機使用的埠，被稱為動態埠，或者私有埠，其范圍定義于檔案/proc/sys/net/ipv4/ip_local_port_range中；
2、Socket
Socket是IPC(行程間通信)的一種實作機制，它能夠實作不同主機甚至是同一主機上的不同行程之間進行通信．程式員可通過Socket API這樣一種C標準庫呼叫介面進行Socket編程．第一個真正被大眾廣泛接收的Socket API大約是在1983年前后發布；這個標準早期是出現在4.2版本的BSD系統上的，后來被廣泛移植到了各種各樣的Unix發行版上，甚至包括后來出現的Linux系統對其也都有支持．
Socket的格式諸如:IP:PORT每一個IP:PORT,我們稱其為一個套接字.因此根據使用協議埠的不同,可分為三類不同的套接字:
- SOCK_STREAM:TCP套接字,使用的是TCP埠;
- SOCK_DGRAM:UDP套接字,使用的是UDP埠;
- SOCK_RAM:裸套接字,既不是使用TCP埠,也不是使用UDP埠,而是直接通過ip報文封裝以后
此外,根據所使用的地址的 不同,又出現了Socket Domain這樣的概念,即根據Socket使用的IP地址的不同,可作如下分類:
- AF_INET:Address Family,IPv4(IPv4的地址家族)
- AF_INET6:IPv6的地址家族
- AF_UNIX:在同一主機上的不同行程之間進行通信時使用;(即本機既作為客戶端,有作為服務器端,本機基于本機進行通信;需要注意的是此種方式繞過了TCP/IP協議堆疊,直接通過內核完成通信;)
結合傳輸層協議來看,在上述三種分類中,每一類套接字都至少提供了兩種Socket的資料傳輸機制:流(基于TCP),資料報(基于UDP);對比TCP與UDP的特點,我們即可以知道流與資料報的區別:
流:提供可靠的面向連接資料傳輸,多個報文發送之間無邊界;
資料報:提供不可靠的無連接資料傳輸,多個報文發送之間有邊界(因為是無序發送,需要添加幀頭和幀尾用以標識一幀的開始和結束);
套接字相關的系統呼叫
- socket():創建一個套接字;
- bind():將行程與套接字系結;
- listen():監聽;
- accept():接收請求;
- connect():請求連接建立;
- write():發送資料;
- read():接收資料;
注:
- write(),read()的作用同send(),recv(),sendto(),revcfrom();
- 默認情況下,這些呼叫在IO無法完成時將會被阻塞;
3、IPv4的分類
按照IPv4的第一個位元組所處的范圍,大致可分為A,B,C,D,E五類:
A:1-127;
B:128-191;
C:192-223;
D:組播地址,224-239;
E:240-254
為滿足建立不與外部網路通信的局域網的需求,IPv4在A,B,C三類中又各預留了一段私有地址供使用,它們分別是:
A:10.0.0.0/8
B:172.16.0.0/16-172.31.0.0/16
C:192.168.0.0/24-192.168.255.0/24
4、TCP協議的特性
- 建立連接：三次握手；
- 將資料打包成段：每一段都包含一個校驗和（CRC-32）；
- 確認、重傳以及超時；
- 排序：邏輯序號；
- 流量控制：滑動視窗演算法（可以理解成當接收方每一次確認時視窗有多大都會通知給發送方，說白了就是這里能夠實作發送方得知接收報文的空閑空間有多大,以實作流量控制）；
如果說A、B主機之間進行通信時，A的發送速度可能大于B的接收速度，為了避免這中情況可能產生的問題，我們應該做流量控制;
滑動視窗演算法允許包含總共假如說n個位元組或者n個視窗大小的未確認段同時在發送者和接收者之間可以完成傳輸的，如果接收者的緩沖間完全被塞滿了，那么視窗就會被關閉，告訴發送方視窗為0即停止發送;
- 擁塞控制：慢啟動和擁塞避免演算法
（TCP的擁塞控制演算法主要用來防止快速的發送者壓垮整個網路的；因此它使用慢啟動的方式）
二、http協議基礎
http全稱為hyper text transfer protocol，即所謂的超文本傳輸協議，見名知意，從其名稱上我們可以得知，http協議是用于實作傳輸超文本的協議，那什么是超文本呢？
- 超文本
我們可以簡單將超文本理解為帶超鏈接的文本，而超鏈接是超文本當中一種特殊的語法格式，它用于實作超文本之間的跳轉，通過點擊超鏈接，我們可以實作從一個超文本跳轉到另一個超文本，甚至于實作在同一個超文本之內的不同內容之間進行跳轉，比如我們通常在瀏覽器中訪問的一個網頁就是一個超文本，點擊超鏈接，它又會跳轉到另一個網頁中去，
超文本是通過html撰寫的，html（hyper text mark language，超文本標記語言）是一種編程語言，它是由很多既定的標簽組成，每一種標簽的用法和屬性可能不盡相同，我們在瀏覽器中所看到的一個個生動形象的網頁就是通過html以及借助于CSS（Cascading Style Sheet，層疊樣式表）與JS（JavaScript，一種腳本語言）所實作的，
因此http協議就是實作超文本傳輸的協議，那么http為什么能夠實作超文本的傳輸呢？http協議傳輸純文本的資料流之外，為什么還能夠支持對如圖片等二進制資料的傳輸呢？http的作業機制到底是什么？那么接下來，我們就來介紹http協議的相關內容，
1、http協議版本
http協議誕生于20世紀80年代的歐洲核物理實驗室，誕生的初衷主要是為了能夠實作在多個部門之間可以共享檔案和快速實作檔案定位，http協議在發展程序中進行了多次版本迭代，其所實作的功能隨著版本更新也愈加豐富，
- http/0.9
在當時http/0.9是http協議應用最廣泛的版本，那個時候的Web服務僅支持純文本（即由純ASCII字符組成的文本），這種純文本還包含有超鏈接，這種超鏈接也是表現為純文本形式的，但這種文本比較獨特，因此稱為超文本，
- http/1.0
通過參照傳統的SMTP協議，在http/1.0中引入了MIME機制，從此之后，http協議也可以傳輸諸如圖片、音頻、視頻等非文本資料了；此外，http/1.0還引入了快取機制，
- http/1.1
http是基于TCP的應用層協議，而每一次TCP連接的建立都需要3次握手，在資料互動完成之后，有需要4次斷開，因此為了避免由于每一次訪問資源時的3次握手和4次斷開而造成的資源浪費，推出了http/1.1，
首先，在http/1.1中增強了快取功能；
其次，引入了長連接機制，即每一次連接在獲取到資源之后并不會立即斷開，而是繼續獲取下一個資源，
注意：建議閱讀http/1.0和http/1.1的RFC檔案，
2、http報文
http報文分為請求報文和回應報文，其格式不盡相同；
2.1 http請求報文
請求報文語法：
<method> <request-URL> <version>
<headers>
<entity-body>
<method>：請求方法，標明客戶端希望服務器對資源的執行動作，如GET、PUT、POST等；
常用method：
-
- GET：從服務器獲取一個資源；
- HEAD：只從服務器獲取檔案的回應首部；
- POST：向服務器發送要處理的資料；
- PUT：將請求的主體部分存盤在服務器上，簡而言之，PUT為向服務器上傳資料；
- DELETE：請求洗掉服務器上指定的檔案；
- TRACE：追蹤請求報文到達服務器中間經過的代理服務器；
- OPTIONS：請求服務器回傳對指定資源支持使用的請求方法；
<request-URL>：請求的資源路徑；
<version>：對應的請求資源協議的版本號；
<headers>：http協議請求報文首部，每個請求報文可包含任意個首部，每個首部都有首部名稱，后跟一個冒號，而后跟上一個可選空格，接著是一個值，其格式都形如key:value，需要注意的是，首部的最后面一行必須是空白行；
<entity-body>：報文的主體內容；
2.2 回應報文
回應報文語法：
<version> <status> <reason-phrase>
<headers>
<entity-body>
<version>：協議版本；
<status>：狀態碼，用以標識請求的狀態結果（正確與否），大約可分為5類：
-
- 1xx，100-101：純資訊，與請求的資源沒有太大關系；
- 2xx，200-206：“成功”類的狀態碼；
- 3xx，300-305：重定向類的資訊，即請求的資源存在，但資源已被挪到其它地方了，如：給服務器端給出的回應為一個參考答案，表示這個資源已經挪走了，請重新發起請求來請求另外一個地址，并且把另外的參考地址也回應給客戶端了；（常用的狀態碼：301（永久重定向，永久的挪到哪個位置去了）、302（臨時重定向，繁忙時暫時重定向到指定位置尋找）、304（表示請求的內容未發生任何改變，若快取過直接使用快取即可），重定向的資訊未必都是重定向，如304狀態碼，）
- 4xx，400-415：客戶端錯誤類的資訊；（常用的狀態碼：404（請求了一個不存在的檔案））
- 5xx，500-505：服務器端錯誤類的資訊；
常用狀態碼：
-
- 200：成功回應，請求的所有資料通過回應報文的entity-body部分發送；OK；
- 301：請求的URL指向的資源已經被洗掉；但在回應報文中通過首部Location指明了資源現在所處的新位置（永久重定向，即資源將被永久的挪到所處的新位置）；Moved permanently；
- 302：與301相似，但在回應報文中通過Location指明資源現在所處臨時新位置（臨時重定向，即繁忙時暫時重定向到指定位置尋找）；Found；
- 304：客戶端發出了條件式請求，若服務器上的資源未曾發生改變，則通過回應此回應狀態碼通知客戶端（表示請求的內容未發生任何改變，若快取過直接使用快取即可）；Not Modified；
- 401：需要輸入賬號和密碼認證方能訪問資源；Unauthorized；
- 403：請求被禁止；Forbidden；
- 404：服務器無法找到客戶端請求的資源；Not Found；
- 500：服務器內部錯誤；Internal Server Error
- 502：代理服務器從后端服務器收到了一條偽回應；Bad Gateway；
<reason-phrase>：對<status>的進一步補充說明；
<headers>：回應報文首部，每個回應報文可包含任意個首部；每個首部都有首部名稱，后跟一個冒號，而后跟上一個可選空格，接著是一個值，同樣的，回應報文首部的最后一行的下一行必須是空白行；
<entity-body>：回應報文主體
2.3 舉例
請求報文：
GET / HTTP/1.1
Host: www.test.com
Connection: keep-alive
回應報文：
HTTP/1.1 200 OK
X-Powered-By: PHP/5.2.17
Vary: Accept-Encoding,Cookie,User-Agent
Cache-Control: max-age=3, must-revalidate
Content-Encodiing: gzip
Content-Length:6931
注：GET / HTTP/1.1中的/表示此時訪問一個網站但沒有明確指定訪問哪個頁面，/表示訪問對方的默認頁面（主頁），
3、http headers（首部）
不管是http請求報文和http回應報文中都包含有首部，其格式為Name: Value，根據各首部的功能用途大約可分為以下幾類：
- 通用首部
- 請求首部
- 回應首部
- 物體首部
- 擴展首部
3.1 通用首部
通用首部即既可以在請求首部又可以在回應首部中的首部；
- Date：報文的創建時間；
- Connection：連接狀態；如，keep-alive，close；
- Via：顯示報文經過的中間節點；
- Cache-Control：控制快取的生效機制；
- Pragma：跟快取相關的首部；
3.2 請求首部
- Accept：通過向服務器定義自己可接受的媒體型別（MIME型別）；
- Accept-Charset：可接收的字符集；
- Accept-Encoding：客戶端請求一個服務器端資源如果是文本檔案為了節約帶寬有可能將資源壓縮以后傳遞給客戶端，客戶端解壓以后才能在瀏覽器中顯示，如果客戶端瀏覽器不支持壓縮功能的話，那么就無法查看，此項用于定義可接受的編碼格式，如gzip；
- Accept-Language：定義可接受的語言，即表示通過服務器只能發送哪些服務器編碼的頁面給客戶端本身；
- Client-IP：客戶端IP；
- Host：請求的服務器名稱和埠號；
- Referer：包含當前正在請求的資源的上一級資源；
- User-Agent：客戶端代理，說白了就是瀏覽器型別；
3.2.1 條件式請求首部
- Expect：期望發送的資訊；
- If-Modified-Since：表示自從在指定的時間之后，請求的資源是否發生修改；
- If-Unmodified-Since：表示自從在指定的時間之后，請求的資源是否未發生修改；
- If-None-Match：表示本地快取中存盤的檔案的ETag標簽是否與服務器檔案的Etag不匹配；
- If-Match：表示本地快取中存盤的檔案的ETag標簽是否與服務器檔案的Etag匹配；
3.2.2 安全請求首部
- Authorization：用于向服務器發送認證資訊，如賬號和密碼；
- Cookie：用于客戶端向服務器發送Cookie；
- Cookie2：Cookie有兩個版本，此為Version 2；
3.2.3 代理請求首部
若某一個請求中途經由代理服務器請求的話，它還有一個代理請求首部；
- Proxy-Authorization：向代理服務器認證；
3.3 回應請求首部
3.3.1 資訊性首部
- Age：回應持續時長，即資源的有效期限；
- Server：服務器程式軟體名稱和版本；
3.3.2 協商首部
某資源有多種表示方法時使用，比如用戶請求的頁面有中文版、英文版、阿拉伯語版，因此阿拉伯人訪問的時候，其瀏覽器跟服務器協商版本；
- Accept-Ranges：服務器可接受的請求范圍型別；
- Vary：服務器查看的其它首部串列，例如如果有些首部無法正常顯示，其值可能會有變化時，就放到Vary中；
3.3.3 安全回應首部
- Set-Cookie：向客戶端設定Cookie，說白了就是向客戶端發送一個此客戶端的唯一標識；
- Set-Cookie2：向客戶端設定Cookie2資訊；
- WWW-Authenticate：來自服務器對客戶端的質詢認證表單；
3.4 物體首部
- Allow：用于列出對此物體可使用的請求方法；
- Location：用于告訴客戶端真正的物體位于何處；
- Content-Encoding：主體的編碼；
- Content-Language：主體的語言；
- Content-Length：主體的長度；
- Content-Location：物體真正所處位置；
- Content-Range：整個資源中此物體表示的位元組范圍；
- Content-Type：主體的物件型別，為MIME型別；
3.4.1 快取相關
- ETag：物體的擴展標簽，基于標簽做條件式請求時會使用；
- Expires：物體的過期時間；
- Last-Modified：最后一次修改的時間；
4、一次完整的http請求處理程序
一次完整的http請求的處理程序包含從客戶端發起請求開始到服務器端發送回應報文完成，這一程序也被稱為一次完整的http事務；
(1). 建立并處理連接
處理連接的方式也無非就是：接收請求或拒絕請求，以下我們只考慮接收請求的情況；
(2).接收請求
即接收來自于網路的請求報文中對某資源的一次請求的程序；
(3).處理請求
對請求報文進行決議，并獲取請求的資源及請求方法等相關資訊；
(4).訪問資源
獲取報文中指定請求的資源；
web服務器，顧名思義為存放了Web資源的服務器，負責向請求者提供對方請求的資源，或動態運行后生成的資源，這些資源通常放置于某特定路徑下，此路徑通常被稱為DocRoot；
例如：在一臺名為www.test.com的Web服務器上，其DocRoot為/var/www/html，在此目錄下有一images目錄，在image目錄下有一檔案為1.jpg，即/var/www/html/images/1.jpg；因此，在通過瀏覽器向Web服務器請求此資源時，可通過訪問：http://www.test.com/images/1.jpg實作；
(5).構建回應報文
(6).發送回應報文
(7).記錄日志
我們再來深入了解一下這個程序，如下圖所示：
首先，我們明確一個概念，我們所謂的Web服務器在運行時本質上也無非就是一個運行于用戶空間的行程，因為Web服務器是一個應用程式，而只要是應用程式就應該在用戶空間，其次，用戶所訪問的資源其在服務器端表現形式為一個檔案，這個或者這些檔案也一定是存放于某持久性存盤設備，我們此處就以磁盤為例，
當用戶通過瀏覽器發起一個http請求時，此時瀏覽器作為Web服務通信時的客戶端，如果用戶在瀏覽器輸入http://www.test.com/index.html，很顯然，目前在互聯網中的主機之間通信是通過IP地址來作為唯一標識的，因此，首先需要進行域名決議，將我們訪問的主機名通過hosts檔案或者DNS服務器轉換為IP地址，而瀏覽器將封裝請求報文，并發送至網路中，經過層轉發，到達Web服務器，當這個請求到達Web服務器主機時，最先經過的是Web服務器主機的內核空間，因為這個客戶端的請求一定是通過網路協議發送過來的，而TCP/IP協議作業于內核當中，因此請求首先到達內核空間，
Web服務默認監聽在本機的TCP協議的80埠之上，內核空間通過對TCP/IP協議堆疊中的各種路由機制進行解碼等操作發現訪問的是本機80埠的套接字，因此內核會將此請求通過套接字轉交給用戶空間的Web服務器，因此執行流程就從內核空間轉移到了用戶空間，
若Web服務器發現用戶訪問的是一個靜態檔案(如：index.html)，而靜態檔案是存放于磁盤之上的，此時服務器就需要陷入內核重新轉換至內核空間，內核從磁盤上加載對應的檔案至內核空間，再回傳給用戶空間，Web服務器接收到這個檔案之后就可以回傳給客戶端了，因此此時再通過套接字回傳到內核空間，經由TCP/IP協議堆疊最終回應給客戶端，至此，http的一次事務完成，
我們此時再回過頭來分析一遍，如果我們在瀏覽器輸入www.test.com訪問，第一步需要把FQDN決議成IP，因此在請求發出之前需要先通過DNS服務器決議FQDN，而DNS服務器可能會進行遞回、迭代，需要消耗一些時間，因為有可能是第一次訪問，其結果未快取到本地，之后客戶端輸入地址發送請求給服務器，服務器在內部需要有一種機制能夠接收用戶的請求報文，這種機制就叫監聽，服務器端的某用戶行程會監聽在某個埠上，等待客戶端請求，一旦用戶請求來了，而內核通過TCP/IP協議堆疊發現有人監聽在這個埠上，于是這個請求就可以交給這個套接字了，但如果本地沒有任何一個用戶行程監聽某個套接字，但如果有用戶來訪問了，此時內核無法知道有誰能夠回應這個請求，此時服務器端會拒絕客戶端請求，所以必須到內核中去注冊需要使用哪個埠并一直在這個埠上處于等待狀態，當有請求到來時，通過TCP/IP協議的首部解碼后發現用戶訪問的是這個埠，于是把這個請求交給這個埠，而行程又一直在監聽這個埠，一旦有請求來了，可進行回應，
TCP/IP協議在封裝報文時，TCP首部主要是源埠（Source Port）、目標埠（Destination Port），IP首部主要是源IP地址（Source IP）、目標IP地址（Destination IP），但確并沒有說明具體訪問哪個檔案（資源），因此某一種特定的應用在通過TCP/IP協議往外發送時，TCP/IP最多就是將報文傳遞到目的地的，到達目的地后還需要具體協議的報文首部，因此http協議也有自己的首部，叫http首部（明確定義了基于哪種協議獲取哪個資源的），需要說明獲取什么檔案，如：GET /2.html，并且還需說明獲取哪個主機的資源，因此通常還有一個首部叫：Host:www.magedu.com（加主機是HTTP1.0當中的引入的一種機制，在發起獲取資源請求時，不但要指明獲取哪個資源，還要再加上獲取哪個主機的資源，這個主機一定是主機名稱，這是為虛擬主機提供準備的），說白了這一切就是我們之前提到的http報文，
5、Web服務器處理并發連接請求的架構方式（回應模型）（Web I/O）
對于一個正常的網站而言，在同一時間內甚至是同一時刻一定會存在多個用戶訪問的情況，那么我們的Web服務器同時接收到這些請求之后如何進行處理呢？這就是我們接下來要討論的Web服務器對于并發連接請求的處理方式，
- 單執行緒web服務器(Single-threaded web servers)
此種架構方式中，web服務器一次處理一個請求，結束后讀取并處理下一個請求，在某請求處理程序中，其它所有的請求將被忽略，因此，在并發請求較多的場景中將會出現嚴重的性能問題，
- 多行程/多執行緒web服務器
此種架構方式中，web服務器生成多個行程或執行緒并行處理多個用戶請求，行程或執行緒可以按需或事先生成，有的web服務器應用程式為每個用戶請求生成一個單獨的行程或執行緒來進行回應，不過，一旦并發請求數量達到成千上萬時，多個同時運行的行程或執行緒將會消耗大量的系統資源，
- I/O多路復用web服務器
為了能夠支持更多的并發用戶請求，越來越多的web服務器正在采用多種復用的架構——同步監控所有的連接請求的活動狀態，當一個連接的狀態發生改變時(如資料準備完畢或發生某錯誤)，將為其執行一系列特定操作；在操作完成后，此連接將重新變回暫時的穩定態并回傳至打開的連接串列中，直到下一次的狀態改變，由于其多路復用的特性，行程或執行緒不會被空閑的連接所占用，因而可以提供高效的作業模式，
- 多路復用多執行緒web服務器
將多行程和多路復用的功能結合起來形成的web服務器架構，其避免了讓一個行程服務于過多的用戶請求，并能充分利用多CPU主機所提供的計算能力，
三、常用軟體簡介
1、常用的客戶端瀏覽器
- IE
- Firefox
- Chrome
- Opera
- Safari
2、常用的Web服務器應用
- httpd：屬于ASF；
- IIS：不僅是純粹意義上的Web服務器還是應用程式服務器，其能結合.net決議asp,asp.net等動態腳本；
- Nginx
- lighttpd：由德國某公司開發的開源軟體；
- thttpd：在嵌入式中用到的；
3、應用程式服務器
所謂的應用程式服務器，它們既能提供Web服務，但并不是純粹意義上的Web服務器，通常還能夠編譯執行一些特定腳本檔案，這是Web服務器所不具備的功能；
- IIS
- Tomcat：Apache的開源（open source）產品，能夠決議JSP；
- Websphere：由IBM研發的Java企業級應用程式，能夠決議JSP的商業產品（commodity）；
- Weblogic：早期屬于Bea，后被Oracle收購（83億美元），能夠決議JSP，商業產品（commodity）；
- JBoss：當前屬于RedHat，分開源和商業版（商業版需要購買RedHat的服務），是重新封裝的Tomcat，在其基礎上做了更為豐富包裝；
注：www.netcraft.com ，此網站每隔一段時間統計一次全球互聯網中Web服務器各產品所占的比例，各位若有興趣可自行查看，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/84842.html
標籤：Linux