httpd之Web服務概述（一）

来源:https://www.cnblogs.com/long-cnblogs/archive/2020/05/10/12542283.html
-Advertisement-
Play Games

自上世紀80年代末至90年代初互聯網誕生以來，Web服務可以說是在互聯網的普及過程當中起到了巨大的作用。而Web服務應該是當今世界上普通用戶訪問互聯網的最廣泛的方式了，用戶只需在瀏覽器中輸入所謂網址的方式即可瀏覽互聯網上的海量信息，而瀏覽器這種瘦客戶端的交互方式也是目前最主流的交互方式。 Web服務 ...


　　自上世紀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():接收數據;

　　註:

  1. write(),read()的作用同send(),recv(),sendto(),revcfrom();
  2. 預設情況下,這些調用在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伺服器各產品所占的比例，各位若有興趣可自行查看。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Expression拼接
    public static class ExpressionHelp { /// <summary> /// Lambda表達式拼接 /// </summary> /// <typeparam name="T"></typeparam> /// <param name="first"></param ...
  • 如何兩個對象數據比對
    public partial class ModelStatusDictionary<T> where T : new() { static readonly DynamicMethod<T> _dynamicMethod = new DynamicMethod<T>(); /// <summary ...
  • Windows 視窗樣式 什麼是 WS_EX_NOREDIRECTIONBITMAP 樣式
    我覺得我可以加入歷史博物館了，加入微軟歷史博物館，本文也是和大家吹歷史的博客 ...
  • Windows 對全屏應用的優化
    全屏應用對應的是視窗模式應用，全屏應用指的是整個屏幕都是被咱一個應用獨占了，屏幕上沒有顯示其他的應用，此時的應用就叫全屏應用。如希沃白板這個程式。本文主要告訴大家從微軟官方的文檔以及考古瞭解到的 Windows 對全屏應用的優化，以及是如何進行的優化，方便小伙伴在撕的時候可以找到根據 ...
  • Shell學習
    "TOC" Shell學習 shell概述 shell是一個命令行解釋器，它接收應用程式/用戶命令，然後調用操作系統內核。 shell解釋器 1. Linux提供的解釋器有 2. bash和sh的關係 3. Centos預設的解析器是bash Shell腳本入門 1. 腳本格式 腳本以 !/bin/ ...
  • 進程管理類命令
    進程管理類命令 信號: 在linux當中所有的進行管理都是靠信號來管理的.像我們平時要結束某個進程就是使用的15信號SIGTERM,還有想要強制殺死某個進程,就是使用的9信號SIGKILL等等. 在linux可以查看信號有哪些的指定太多了,kill -l ; trap -l; man 7 signa ...
  • 進程監控類命令
    liunx中各種監控工具,量大.本篇全是命令介紹,筆者把各個命令的都實驗一遍,給同學們看看. ...
  • 圖解Linux的IO模型和相關技術
    阻塞IO模型（Blocking I/O） 內核一開始提供了 與 阻塞式操作。 當客戶端連接時，會在對應進程的文件描述符目錄（/proc/進程號/fd）生成對應的文件描述符（0 標準輸入；1 標準輸出；2 標準錯誤輸出；），比如 fd 8 , fd 9； 應用程式需要讀取的時候，通過系統調用 讀取，如 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類