當(dāng)前位置:首頁(yè) > IT技術(shù) > Web編程 > 正文

http協(xié)議各個(gè)版本
2021-09-23 10:08:35

HTTP/0.9

????????HTTP協(xié)議的最初版本,功能簡(jiǎn)陋,僅支持請(qǐng)求方式GET,并且僅能請(qǐng)求訪問(wèn)HTML格式的資源。

HTTP/1.0????

請(qǐng)求行必須在尾部添加協(xié)議版本字段(http/1.0);必須包含頭消息? ? ? ??

在0.9版本上做了進(jìn)步,增加了請(qǐng)求方式POST和HEAD;不再局限于0.9版本的HTML格式,根據(jù)Content-Type可以支持多種數(shù)據(jù)格式,即MIME多用途互聯(lián)網(wǎng)郵件擴(kuò)展,例如text/html、image/jpeg等;同時(shí)也開(kāi)始支持cache,就是當(dāng)客戶端在規(guī)定時(shí)間內(nèi)訪問(wèn)統(tǒng)一網(wǎng)站,直接訪問(wèn)cache即可。

再次,HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分,每次通信都必須包括頭信息(HTTP header),用來(lái)描述一些元數(shù)據(jù)。

其他的新增功能還包括狀態(tài)碼(status code)、多字符集支持、多部分發(fā)送(multi-part type)、權(quán)限(authorization)、緩存(cache)、內(nèi)容編碼(content encoding)等。

????????但是1.0版本的工作方式是每次TCP連接只能發(fā)送一個(gè)請(qǐng)求,當(dāng)服務(wù)器響應(yīng)后就會(huì)關(guān)閉這次連接,下一個(gè)請(qǐng)求需要再次建立TCP連接,就是不支持keepalive。

? ? ? ? TCP連接的新建成本很高,因?yàn)樾枰蛻舳撕头?wù)器三次握手,并且開(kāi)始時(shí)發(fā)送速率較慢(slow start)。所以,HTTP 1.0版本的性能比較差。隨著網(wǎng)頁(yè)加載的外部資源越來(lái)越多,這個(gè)問(wèn)題就愈發(fā)突出了。

為了解決這個(gè)問(wèn)題,有些瀏覽器在請(qǐng)求時(shí),用了一個(gè)非標(biāo)準(zhǔn)的Connection字段。

  1. ?
    ?
  2. ?
    Connection: keep-alive

這個(gè)字段要求服務(wù)器不要關(guān)閉TCP連接,以便其他請(qǐng)求復(fù)用。服務(wù)器同樣回應(yīng)這個(gè)字段。

  1. ?
    ?
  2. ?
    Connection: keep-alive

一個(gè)可以復(fù)用的TCP連接就建立了,直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接。但是,這不是標(biāo)準(zhǔn)字段,不同實(shí)現(xiàn)的行為可能不一致,因此不是根本的解決辦法。

Content-Type 字段

關(guān)于字符的編碼,1.0版規(guī)定,頭信息必須是 ASCII 碼,后面的數(shù)據(jù)可以是任何格式。因此,服務(wù)器回應(yīng)的時(shí)候,必須告訴客戶端,數(shù)據(jù)是什么格式,這就是Content-Type字段的作用。

下面是一些常見(jiàn)的Content-Type字段的值。

  • text/plain
  • text/html
  • text/css
  • image/jpeg
  • image/png
  • image/svg+xml
  • audio/mp4
  • video/mp4
  • application/javascript
  • application/pdf
  • application/zip
  • application/atom+xml

這些數(shù)據(jù)類型總稱為MIME type,每個(gè)值包括一級(jí)類型和二級(jí)類型,之間用斜杠分隔。

除了預(yù)定義的類型,廠商也可以自定義類型。

  1. ?
    ?
  2. ?
    application/vnd.debian.binary-package

上面的類型表明,發(fā)送的是Debian系統(tǒng)的二進(jìn)制數(shù)據(jù)包。

MIME type還可以在尾部使用分號(hào),添加參數(shù)。

  1. ?
    ?
  2. ?
    Content-Type: text/html; charset=utf-8

上面的類型表明,發(fā)送的是網(wǎng)頁(yè),而且編碼是UTF-8。

客戶端請(qǐng)求的時(shí)候,可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式。

  1. ?
    ?
  2. ?
    Accept: */*

上面代碼中,客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

MIME type不僅用在HTTP協(xié)議,還可以用在其他地方,比如HTML網(wǎng)頁(yè)。

  1. ?
    ?
  2. ?
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  3. ?
    <!-- 等同于 -->
  4. ?
    <meta charset="utf-8" />

Content-Encoding 字段

由于發(fā)送的數(shù)據(jù)可以是任何格式,因此可以把數(shù)據(jù)壓縮后再發(fā)送。Content-Encoding字段說(shuō)明數(shù)據(jù)的壓縮方法。

  1. ?
    ?
  2. ?
    Content-Encoding: gzip
  3. ?
    Content-Encoding: compress
  4. ?
    Content-Encoding: deflate

客戶端在請(qǐng)求時(shí),用Accept-Encoding字段說(shuō)明自己可以接受哪些壓縮方法。

  1. ?
    ?
  2. ?
    Accept-Encoding: gzip, deflate

HTTP/1.1 ???

1.1 版的最大變化,就是引入了持久連接(persistent connection),即TCP連接默認(rèn)不關(guān)閉,可以被多個(gè)請(qǐng)求復(fù)用,不用聲明Connection: keep-alive。解決了1.0版本的keepalive問(wèn)題,1.1版本加入了持久連接,一個(gè)TCP連接可以允許多個(gè)HTTP請(qǐng)求;

客戶端和服務(wù)器發(fā)現(xiàn)對(duì)方一段時(shí)間沒(méi)有活動(dòng),就可以主動(dòng)關(guān)閉連接。不過(guò),規(guī)范的做法是,客戶端在最后一個(gè)請(qǐng)求時(shí),發(fā)送Connection: close,明確要求服務(wù)器關(guān)閉TCP連接。

  1. ?
    ?
  2. ?
    Connection: close

目前,對(duì)于同一個(gè)域名,大多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接。降低了延遲同時(shí)提高了帶寬的利用率。

? ??

加入了管道機(jī)制,在同一個(gè)TCP連接里,允許多個(gè)請(qǐng)求同時(shí)發(fā)送,增加了并發(fā)性,進(jìn)一步改善了HTTP協(xié)議的效率;舉例來(lái)說(shuō),客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是,在同一個(gè)TCP連接里面,先發(fā)送A請(qǐng)求,然后等待服務(wù)器做出回應(yīng),收到后再發(fā)出B請(qǐng)求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出A請(qǐng)求和B請(qǐng)求,但是服務(wù)器還是按照順序,先回應(yīng)A請(qǐng)求,完成后再回應(yīng)B請(qǐng)求。

Content-Length 字段

一個(gè)TCP連接現(xiàn)在可以傳送多個(gè)回應(yīng),勢(shì)必就要有一種機(jī)制,區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)回應(yīng)的。這就是Content-length字段的作用,聲明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度。

  1. ?
    ?
  2. ?
    Content-Length: 3495

上面代碼告訴瀏覽器,本次回應(yīng)的長(zhǎng)度是3495個(gè)字節(jié),后面的字節(jié)就屬于下一個(gè)回應(yīng)了。

在1.0版中,Content-Length字段不是必需的,因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接,就表明收到的數(shù)據(jù)包已經(jīng)全了。

分塊傳輸編碼

使用Content-Length字段的前提條件是,服務(wù)器發(fā)送回應(yīng)之前,必須知道回應(yīng)的數(shù)據(jù)長(zhǎng)度。

對(duì)于一些很耗時(shí)的動(dòng)態(tài)操作來(lái)說(shuō),這意味著,服務(wù)器要等到所有操作完成,才能發(fā)送數(shù)據(jù),顯然這樣的效率不高。更好的處理方法是,產(chǎn)生一塊數(shù)據(jù),就發(fā)送一塊,采用"流模式"(stream)取代"緩存模式"(buffer)。

因此,1.1版規(guī)定可以不使用Content-Length字段,而使用"分塊傳輸編碼"(chunked transfer encoding)。只要請(qǐng)求或回應(yīng)的頭信息有Transfer-Encoding字段,就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。

  1. ?
    ?
  2. ?
    Transfer-Encoding: chunked

每個(gè)非空的數(shù)據(jù)塊之前,會(huì)有一個(gè)16進(jìn)制的數(shù)值,表示這個(gè)塊的長(zhǎng)度。最后是一個(gè)大小為0的塊,就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。下面是一個(gè)例子。

  1. ?
    ?
  2. ?
    HTTP/1.1 200 OK
  3. ?
    Content-Type: text/plain
  4. ?
    Transfer-Encoding: chunked
  5. ?
    ?
  6. ?
    25
  7. ?
    This is the data in the first chunk
  8. ?
    ?
  9. ?
    1C
  10. ?
    and this is the second one
  11. ?
    ?
  12. ?
    3
  13. ?
    con
  14. ?
    ?
  15. ?
    8
  16. ?
    sequence
  17. ?
    ?
  18. ?
    0

新增了請(qǐng)求方式PUT、PATCH、OPTIONS、DELETE等。

另外,客戶端請(qǐng)求的頭信息新增了Host字段,用來(lái)指定服務(wù)器的域名。在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址,因此,請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名(hostname)。但隨著虛擬主機(jī)技術(shù)的發(fā)展,在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)(Multi-homed Web Servers),并且它們共享一個(gè)IP地址。

  1. ?
    ?
  2. ?
    Host: www.example.com

有了Host字段,就可以將請(qǐng)求發(fā)往同一臺(tái)服務(wù)器上的不同網(wǎng)站,為虛擬主機(jī)的興起打下了基礎(chǔ)。(實(shí)現(xiàn)了在一臺(tái)WEB服務(wù)器上可以在同一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來(lái)創(chuàng)建多個(gè)虛擬WEB站點(diǎn)。也即是說(shuō),web server上的多個(gè)虛擬站點(diǎn)可以共享同一個(gè)ip和端口。)且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤(400 Bad Request)。

????????雖然1.1版允許復(fù)用TCP連接,但是同一個(gè)TCP連接里面,所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)端是按隊(duì)列順序處理請(qǐng)求的,服務(wù)器只有處理完一個(gè)回應(yīng),才會(huì)進(jìn)行下一個(gè)回應(yīng)。假如前面的請(qǐng)求處理時(shí)間很長(zhǎng),后面就會(huì)有許多請(qǐng)求排隊(duì)等著,這樣就造成了“隊(duì)頭阻塞”的問(wèn)題;同時(shí)HTTP是無(wú)狀態(tài)的連接,因此每次請(qǐng)求都需要添加重復(fù)的字段,降低了帶寬的利用率。

多路復(fù)用帶來(lái)一個(gè)新的問(wèn)題是,在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí),這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁(yè),首頁(yè)的html內(nèi)容應(yīng)該優(yōu)先展示,之后才是各種靜態(tài)資源文件,腳本文件等加載,這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁(yè)內(nèi)容。

為了避免這個(gè)問(wèn)題,只有兩種方法:一是減少請(qǐng)求數(shù),二是同時(shí)多開(kāi)持久連接。這導(dǎo)致了很多的網(wǎng)頁(yè)優(yōu)化技巧,比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片(domain sharding)等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些,這些額外的工作是可以避免的。

100(Continue) Status(節(jié)約帶寬)

HTTP/1.1加入了一個(gè)新的狀態(tài)碼100(Continue)。客戶端事先發(fā)送一個(gè)只帶頭域的請(qǐng)求,如果服務(wù)器因?yàn)闄?quán)限拒絕了請(qǐng)求,就回送響應(yīng)碼401(Unauthorized);如果服務(wù)器接收此請(qǐng)求就回送響應(yīng)碼100,客戶端就可以繼續(xù)發(fā)送帶實(shí)體的完整請(qǐng)求了。100 (Continue) 狀態(tài)代碼的使用,允許客戶端在發(fā)request消息body之前先用request header試探一下server,看server要不要接收request body,再?zèng)Q定要不要發(fā)request body。

HTTP/1.1在1.0的基礎(chǔ)上加入了一些cache的新特性,當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變?yōu)閟tale對(duì)象,cache不需要直接拋棄stale對(duì)象,而是與源服務(wù)器進(jìn)行重新激活(revalidation)。

HTTP 1.1支持只發(fā)送header信息(不帶任何body信息),如果服務(wù)器認(rèn)為客戶端有權(quán)限請(qǐng)求服務(wù)器,則返回100,否則返回401??蛻舳巳绻邮艿?00,才開(kāi)始把請(qǐng)求body發(fā)送到服務(wù)器。這樣當(dāng)服務(wù)器返回401的時(shí)候,客戶端就可以不用發(fā)送請(qǐng)求body了,節(jié)約了帶寬。

HTTP1.1還有身份認(rèn)證機(jī)制,許多web站點(diǎn)要求用戶提供一個(gè)用戶名—口令對(duì)才能訪問(wèn)存放在其服務(wù)器中的文檔,這種要求稱為身份認(rèn)證(authentication)。HTTP提供特殊的狀態(tài)碼和頭部來(lái)幫助Web站點(diǎn)執(zhí)行身份認(rèn)證。

HTTP支持傳送內(nèi)容的一部分。這樣當(dāng)客戶端已經(jīng)有一部分的資源后,只需要跟服務(wù)器請(qǐng)求另外的部分資源即可。這是支持文件斷點(diǎn)續(xù)傳的基礎(chǔ)。

HTTP/1.1支持文件斷點(diǎn)續(xù)傳,RANGE:bytes,HTTP/1.0每次傳送文件都是從文件頭開(kāi)始,即0字節(jié)處開(kāi)始。RANGE:bytes=XXXX表示要求服務(wù)器從文件XXXX字節(jié)處開(kāi)始傳送,斷點(diǎn)續(xù)傳。即返回碼是206(Partial Content)

在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼,如409(Conflict)表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突;410(Gone)表示服務(wù)器上的某個(gè)資源被永久性的刪除。

HTTP/2.0

????????為了解決1.1版本利用率不高的問(wèn)題,提出了HTTP/2.0版本。增加雙工模式,即不僅客戶端能夠同時(shí)發(fā)送多個(gè)請(qǐng)求,服務(wù)端也能同時(shí)處理多個(gè)請(qǐng)求,解決了隊(duì)頭堵塞的問(wèn)題(HTTP2.0使用了多路復(fù)用的技術(shù),做到同一個(gè)連接并發(fā)處理多個(gè)請(qǐng)求,而且并發(fā)請(qǐng)求的數(shù)量比HTTP1.1大了好幾個(gè)數(shù)量級(jí));HTTP請(qǐng)求和響應(yīng)中,狀態(tài)行和請(qǐng)求/響應(yīng)頭都是些信息字段,并沒(méi)有真正的數(shù)據(jù),因此在2.0版本中將所有的信息字段建立一張表,為表中的每個(gè)字段建立索引,客戶端和服務(wù)端共同使用這個(gè)表,他們之間就以索引號(hào)來(lái)表示信息字段,這樣就避免了1.0舊版本的重復(fù)繁瑣的字段,并以壓縮的方式傳輸,提高利用率。

????????另外也增加服務(wù)器推送的功能,即不經(jīng)請(qǐng)求服務(wù)端主動(dòng)向客戶端發(fā)送數(shù)據(jù)。

當(dāng)前主流的協(xié)議版本還是HTTP/1.1版本。

二進(jìn)制協(xié)議

HTTP/1.1 版的頭信息肯定是文本(ASCII編碼),數(shù)據(jù)體可以是文本,也可以是二進(jìn)制。HTTP/2 則是一個(gè)徹底的二進(jìn)制協(xié)議,頭信息和數(shù)據(jù)體都是二進(jìn)制,并且統(tǒng)稱為"幀"(frame):頭信息幀和數(shù)據(jù)幀。

二進(jìn)制協(xié)議的一個(gè)好處是,可以定義額外的幀。HTTP/2 定義了近十種幀,為將來(lái)的高級(jí)應(yīng)用打好了基礎(chǔ)。如果使用文本實(shí)現(xiàn)這種功能,解析數(shù)據(jù)將會(huì)變得非常麻煩,二進(jìn)制解析則方便得多。

多工

HTTP/2 復(fù)用TCP連接,在一個(gè)連接里,客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng),而且不用按照順序一一對(duì)應(yīng),這樣就避免了"隊(duì)頭堵塞"。

舉例來(lái)說(shuō),在一個(gè)TCP連接里面,服務(wù)器同時(shí)收到了A請(qǐng)求和B請(qǐng)求,于是先回應(yīng)A請(qǐng)求,結(jié)果發(fā)現(xiàn)處理過(guò)程非常耗時(shí),于是就發(fā)送A請(qǐng)求已經(jīng)處理好的部分, 接著回應(yīng)B請(qǐng)求,完成后,再發(fā)送A請(qǐng)求剩下的部分。

這樣雙向的、實(shí)時(shí)的通信,就叫做多工(Multiplexing)。

數(shù)據(jù)流

因?yàn)?HTTP/2 的數(shù)據(jù)包是不按順序發(fā)送的,同一個(gè)連接里面連續(xù)的數(shù)據(jù)包,可能屬于不同的回應(yīng)。因此,必須要對(duì)數(shù)據(jù)包做標(biāo)記,指出它屬于哪個(gè)回應(yīng)。

HTTP/2 將每個(gè)請(qǐng)求或回應(yīng)的所有數(shù)據(jù)包,稱為一個(gè)數(shù)據(jù)流(stream)。每個(gè)數(shù)據(jù)流都有一個(gè)獨(dú)一無(wú)二的編號(hào)。數(shù)據(jù)包發(fā)送的時(shí)候,都必須標(biāo)記數(shù)據(jù)流ID,用來(lái)區(qū)分它屬于哪個(gè)數(shù)據(jù)流。另外還規(guī)定,客戶端發(fā)出的數(shù)據(jù)流,ID一律為奇數(shù),服務(wù)器發(fā)出的,ID為偶數(shù)。

數(shù)據(jù)流發(fā)送到一半的時(shí)候,客戶端和服務(wù)器都可以發(fā)送信號(hào)(RST_STREAM幀),取消這個(gè)數(shù)據(jù)流。1.1版取消數(shù)據(jù)流的唯一方法,就是關(guān)閉TCP連接。這就是說(shuō),HTTP/2 可以取消某一次請(qǐng)求,同時(shí)保證TCP連接還打開(kāi)著,可以被其他請(qǐng)求使用。

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級(jí)。優(yōu)先級(jí)越高,服務(wù)器就會(huì)越早回應(yīng)。

頭信息壓縮

HTTP 協(xié)議不帶有狀態(tài),每次請(qǐng)求都必須附上所有信息。所以,請(qǐng)求的很多字段都是重復(fù)的,比如CookieUser Agent,一模一樣的內(nèi)容,每次請(qǐng)求都必須附帶,這會(huì)浪費(fèi)很多帶寬,也影響速度。

HTTP/2 對(duì)這一點(diǎn)做了優(yōu)化,引入了頭信息壓縮機(jī)制(header compression)。一方面,頭信息使用gzipcompress壓縮后再發(fā)送;另一方面,客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表,所有字段都會(huì)存入這個(gè)表,生成一個(gè)索引號(hào),以后就不發(fā)送同樣字段了,只發(fā)送索引號(hào),這樣就提高速度了。

服務(wù)器推送

HTTP/2 允許服務(wù)器未經(jīng)請(qǐng)求,主動(dòng)向客戶端發(fā)送資源,這叫做服務(wù)器推送(server push)。

意思是說(shuō),當(dāng)我們對(duì)支持HTTP2.0的web server請(qǐng)求數(shù)據(jù)的時(shí)候,服務(wù)器會(huì)順便把一些客戶端需要的資源一起推送到客戶端,免得客戶端再次創(chuàng)建連接發(fā)送請(qǐng)求到服務(wù)器端獲取。這種方式非常合適加載靜態(tài)資源。

服務(wù)器端推送的這些資源其實(shí)存在客戶端的某處地方,客戶端直接從本地加載這些資源就可以了,不用走網(wǎng)絡(luò),速度自然是快很多的。

常見(jiàn)場(chǎng)景是客戶端請(qǐng)求一個(gè)網(wǎng)頁(yè),這個(gè)網(wǎng)頁(yè)里面包含很多靜態(tài)資源。正常情況下,客戶端必須收到網(wǎng)頁(yè)后,解析HTML源碼,發(fā)現(xiàn)有靜態(tài)資源,再發(fā)出靜態(tài)資源請(qǐng)求。其實(shí),服務(wù)器可以預(yù)期到客戶端請(qǐng)求網(wǎng)頁(yè)后,很可能會(huì)再請(qǐng)求靜態(tài)資源,所以就主動(dòng)把這些靜態(tài)資源隨著網(wǎng)頁(yè)一起發(fā)給客戶端了。

服務(wù)端推送能把客戶端所需要的資源伴隨著index.html一起發(fā)送到客戶端,省去了客戶端重復(fù)請(qǐng)求的步驟。正因?yàn)闆](méi)有發(fā)起請(qǐng)求,建立連接等操作,所以靜態(tài)資源通過(guò)服務(wù)端推送的方式可以極大地提升速度。

普通的客戶端請(qǐng)求過(guò)程:

服務(wù)端推送的過(guò)程:

HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬,而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我「調(diào)諧」,起初會(huì)限制連接的最大速度,如果數(shù)據(jù)成功傳輸,會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣?。這種調(diào)諧則被稱為 TCP 慢啟動(dòng)(擁塞控制)。由于這種原因,讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效。
HTTP/2 通過(guò)讓所有數(shù)據(jù)流共用同一個(gè)連接,可以更有效地使用 TCP 連接,讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升。

二、HTTP響應(yīng)模型

????????服務(wù)器收到HTTP請(qǐng)求之后,會(huì)有多種方法響應(yīng)這個(gè)請(qǐng)求,下面是HTTP響應(yīng)的四種模型:

????????單進(jìn)程I/O模型

服務(wù)端開(kāi)啟一個(gè)進(jìn)程,一個(gè)進(jìn)程僅能處理一個(gè)請(qǐng)求,并且對(duì)請(qǐng)求順序處理;

????????多進(jìn)程I/O模型

服務(wù)端并行開(kāi)啟多個(gè)進(jìn)程,同樣的一個(gè)進(jìn)程只能處理一個(gè)請(qǐng)求,這樣服務(wù)端就可以同時(shí)處理多個(gè)請(qǐng)求;

????????復(fù)用I/O模型

服務(wù)端開(kāi)啟一個(gè)進(jìn)程,但是呢,同時(shí)開(kāi)啟多個(gè)線程,一個(gè)線程響應(yīng)一個(gè)請(qǐng)求,同樣可以達(dá)到同時(shí)處理多個(gè)請(qǐng)求,線程間并發(fā)執(zhí)行;

????????復(fù)用多線程I/O模型

服務(wù)端并行開(kāi)啟多個(gè)進(jìn)程,同時(shí)每個(gè)進(jìn)程開(kāi)啟多個(gè)線程,這樣服務(wù)端可以同時(shí)處理進(jìn)程數(shù)M*每個(gè)進(jìn)程的線程數(shù)N個(gè)請(qǐng)求。

本文摘自 :https://www.cnblogs.com/

開(kāi)通會(huì)員,享受整站包年服務(wù)立即開(kāi)通 >