引言 HTTP協(xié)議是Hyper Text Transfer Protocol(超文本傳輸協(xié)議)的縮寫,是用于從萬維網(wǎng)..."/>
您好,登錄后才能下訂單哦!
cdn.xitu.io/2018/6/11/163ef70cbdb6cd86?w=428&h=230&f=jpeg&s=7010">
HTTP協(xié)議是Hyper Text Transfer Protocol(超文本傳輸協(xié)議)的縮寫,是用于從萬維網(wǎng)服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。HTTP 是基于 TCP/IP 協(xié)議通信協(xié)議來傳遞數(shù)據(jù)(HTML 文件, 圖片文件, 查詢結(jié)果等)。它不涉及數(shù)據(jù)包(packet)傳輸,主要規(guī)定了客戶端和服務(wù)器之間的通信格式,默認(rèn)使用80端口。
1.簡(jiǎn)單快速:客戶向服務(wù)器請(qǐng)求服務(wù)時(shí),只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、PUT、DELETE、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單,使得HTTP服務(wù)器的程序規(guī)模小,因而通信速度很快。
2.靈活:HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。
3.無連接:無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求,并收到客戶的應(yīng)答后,即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。
4.無狀態(tài):HTTP協(xié)議是無狀態(tài)的,HTTP 協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。任何兩次請(qǐng)求之間都沒有依賴關(guān)系。直觀地說,就是每個(gè)請(qǐng)求都是獨(dú)立的,與前面的請(qǐng)求和后面的請(qǐng)求都是沒有直接聯(lián)系的。協(xié)議本身并不保留之前一切的請(qǐng)求或 響應(yīng)報(bào)文的信息。這是為了更快地處理大量事務(wù),確保協(xié)議的可伸縮性,而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的。
Http報(bào)文包括請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩大部分,其中請(qǐng)求報(bào)文由請(qǐng)求行(request line)、請(qǐng)求頭(header)、空行和請(qǐng)求體四個(gè)部分組成。而響應(yīng)報(bào)文由狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)體四個(gè)部分組成。接下來我們?cè)敿?xì)介紹下請(qǐng)求報(bào)文的各個(gè)部分及其作用。
POST /chapter17/user.html HTTP/1.1
以上代碼中“POST ”代表請(qǐng)求方法,“/chapter17/user.html”表示URI,“HTTP/1.1”代表協(xié)議和協(xié)議的版本。現(xiàn)在比較流行的是Http1.1版本
請(qǐng)求頭部通知服務(wù)器有關(guān)于客戶端請(qǐng)求的信息。它包含許多有關(guān)的客戶端環(huán)境和請(qǐng)求正文的有用信息。其中比如:
Host,表示主機(jī)名,虛擬主機(jī);
Connection,HTTP/1.1增加的,使用keepalive,即持久連接,一個(gè)連接可以發(fā)多個(gè)請(qǐng)求;
User-Agent,請(qǐng)求發(fā)出者,兼容性以及定制化需求。
name=tom&password=1234&realName=tomson
上面代碼,承載著name、password、realName三個(gè)請(qǐng)求參數(shù)。
DELETE 請(qǐng)求服務(wù)器刪除指定的頁面。
狀態(tài)代碼有三位數(shù)字組成,第一個(gè)數(shù)字定義了響應(yīng)的類別,共分五種類別:
比如我們平時(shí)常見兩種出錯(cuò)的狀態(tài)碼:
403 Forbidden //對(duì)被請(qǐng)求頁面的訪問被禁止
404 Not Found //請(qǐng)求資源不存在,比如:輸入了錯(cuò)誤的URL
HTTP協(xié)議的初始版本中,每進(jìn)行一次HTTP通信就要斷開一次TCP連接。以當(dāng)年的通信情況來說,因?yàn)槎际切┤萘亢苄〉奈谋緜鬏敚约词惯@樣也沒有多大問題??呻S著 HTTP 的 普及,文檔中包含大量圖片的情況多了起來。比如,使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁面時(shí),在發(fā)送請(qǐng)求訪問 HTML 頁面資源的同時(shí),也會(huì)請(qǐng) 求該 HTML 頁面里包含的其他資源。因此,每次的請(qǐng)求都會(huì)造成無謂的 TCP 連接建立和斷開,增加通信量的 開銷。
為解決上述 TCP 連接的問題,HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接(HTTP Persistent Connections,也稱為 HTTP keep-alive 或 HTTP connection reuse)的方法。持久連接的特點(diǎn)是,只要任意一端沒有明確提出斷開連接,則保持TCP連接狀態(tài)。
持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷,減輕了服務(wù)器端的負(fù)載。另外, 減少開銷的那部分時(shí)間,使 HTTP 請(qǐng)求和響應(yīng)能夠更早地結(jié)束,這樣 Web 頁面的顯示速度也就相應(yīng)提高了。
在 HTTP/1.1 中,所有的連接默認(rèn)都是持久連接,但在 HTTP/1.0 內(nèi)并未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過非 標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接,但服務(wù)器端不一定能夠支持持久連接。毫無疑問,除了服務(wù)器端,客戶端也需 要支持持久連接。
持久連接使得多數(shù)請(qǐng)求以管線化(pipelining)方式發(fā)送成為可能。從前發(fā)送請(qǐng)求后需等待并收到響應(yīng),才能 發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后,不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求。
這樣就能夠做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求,而不需要一個(gè)接一個(gè)地等待響應(yīng)了。通俗地講,請(qǐng)求打包一次傳輸過去,響應(yīng)打包一次傳遞回來。管線化的前提是在持久連接下。
假如當(dāng)請(qǐng)求一個(gè)包含 10 張圖片的 HTML Web 頁面,與挨個(gè)連接相比,用持久連接可以讓請(qǐng)求更快結(jié)束。 而管線化技術(shù)則比持久連接還要快。請(qǐng)求數(shù)越多,時(shí)間差就越明顯??蛻舳诵枰?qǐng)求這十個(gè)資源。以前的做法是,在同一個(gè)TCP連接里面,先發(fā)送A請(qǐng)求,然后等待服務(wù)器做出回應(yīng),收到后再發(fā)出B請(qǐng)求,以此類推,而管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出這十個(gè)請(qǐng)求,但是服務(wù)器還是按照順序,先回應(yīng)A請(qǐng)求,完成后再回應(yīng)B請(qǐng)求。
于是在使用持久連接的情況下,某個(gè)連接上消息的傳遞類似于
請(qǐng)求1->響應(yīng)1->請(qǐng)求2->響應(yīng)2->請(qǐng)求3->響應(yīng)3
管線化方式發(fā)送變成了類似這樣:
請(qǐng)求1->請(qǐng)求2->請(qǐng)求3->響應(yīng)1->響應(yīng)2->響應(yīng)3
《圖解HTTP》[日] 上野宣 著
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。