文章目錄

• HTTP
• • HTTP是不保存狀態(tài)的協(xié)議(對請求和響應不做持久化處理)
  • 請求URI定位資源
  • HTTP中的方法
  • • 1、GET(獲取資源)
    • 2、POST( 傳輸實體主體)
    • 3、PUT(傳輸文件)
    • 4、HEAD(獲取報文首部)
    • 5、DELETE：刪除文件
    • 6、OPTIONS
    • 7、TRACE(追蹤路徑)
    • • 例子
    • 8、CONNECT(要求用隧道協(xié)議連接代理，使用SSL或者TLS協(xié)議將通信內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸)
    • • 例子
    • 總結(jié)
  • 持久連接節(jié)省通信量
  • • 建立連接
    • 斷開TCP連接
    • 持久連接(HTTP1.1所有的連接都是持久連接)
    • 管線化(不需要等待響應即可直接發(fā)送下一個請求)
  • 使用Cookie管理狀態(tài)
  • • 例子
• HTTP報文內(nèi)的HTTP信息
• • 1、請求報文結(jié)構(gòu)
  • • 首部字段分類
  • 提升傳輸速率
  • • 編碼提升傳輸速率（客戶端收到后需要解碼）
    • 分割發(fā)送的分塊傳輸編碼
  • 發(fā)送多種數(shù)據(jù)的多部分對象集合
  • • MIME類型
    • • multipart/form-data
      • multipart/byteranges
      • multipart/byteranges
    • 獲取部分內(nèi)容的范圍請求(Range首部來指定資源的byte范圍)
  • 內(nèi)容協(xié)商返回合適內(nèi)容
  • • 內(nèi)容協(xié)商分類
• 返回結(jié)果的HTTP狀態(tài)碼
• • 狀態(tài)碼告知從服務端返回的請求結(jié)果
  • 2XX成功
  • • 200(表示請求被正常處理)
    • 204(No Content)
    • 206(Partial Content)
  • 3XX重定向
  • • 1、301Moved Permanently(永久性重定向)
    • 2、302 Found
    • 303(略)
    • 304(略)
    • 307(略)
  • 4XX客戶端錯誤
  • • 400 Bad Request(請求報文存在語法錯誤)
    • 401 Unauthorized
    • 403Forbidden
    • 404 Not Found
  • 5XX服務器錯誤
  • • 500 Internal Server Error(執(zhí)行請求時發(fā)生錯誤)
    • 503 Service Unavailable(服務器處于超負載或正在進行停機維護)
• 與HTTP協(xié)作的Web服務器
• • 1、用單個虛擬主機實現(xiàn)多域名(借助Host首部實現(xiàn))
  • 2、通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理、網(wǎng)關、隧道
  • • 代理(不會改變請求URI)
    • • 緩存代理
      • 透明代理
    • 網(wǎng)關
    • 隧道(保證服務端和客戶端可以安全通信)
  • 保存資源的緩存
• HTTP首部(請求頭、響應頭部分)
• • 首部傳遞重要信息
  • 首部結(jié)構(gòu)
  • 4種首部字段類型
  • • 通用首部字段
    • 請求首部字段
    • 響應首部字段
    • 實體首部字段
  • 首部具體信息(略)

HTTP

在兩臺計算機之間使用HTTP協(xié)議進行通信的時候，在一條鏈路上必定有一端是客戶端，另外一端則是服務端(但是角色可能會互換)。

就僅一條通信鏈路而言，服務端和客戶端的角色是固定的，而用HTTP協(xié)議能夠區(qū)分哪個是客戶端，哪個是服務端。

HTTP協(xié)議規(guī)定，請求從客戶端發(fā)出，最后服務器端響應請求并返回。也就是說服務端在沒有接收到請求之前不會發(fā)送響應。

HTTP是不保存狀態(tài)的協(xié)議(對請求和響應不做持久化處理)

HTTP協(xié)議是無狀態(tài)的協(xié)議，HTTP協(xié)議自身不對請求和響應之間的通信狀態(tài)進行保存。也就是說在HTTP這個級別，協(xié)議對于發(fā)送過的請求或者響應都不做持久化處理。

但是無狀態(tài)可能會導致業(yè)務處理變得棘手的情況增多，比如登陸到一家購物網(wǎng)站，即使跳轉(zhuǎn)到該網(wǎng)站的其他頁面，也需要能繼續(xù)保持登陸狀態(tài)。為了實現(xiàn)這個功能，于是引入了Cookie技術

請求URI定位資源

• 1、URI為完整的請求URI
  GET http://hackr.jp/index.htm HTTP/1.1
  URI在請求頭中

• 2、在首部字段HOST中寫明網(wǎng)絡域名或IP地址
  GET /index.htm HTTP/1.1
  Host:hackr.jp
  在Host中寫明域名或者IP

HTTP中的方法

1、GET(獲取資源)

GET方法用來請求訪問已被URI識別的資源。指定的資源經(jīng)服務端解析后返回內(nèi)容。
也就是說，如果是文本，那么就直接原樣返回，如果是像CGI那樣的程序，那么返回經(jīng)過執(zhí)行后的輸出結(jié)果

2、POST( 傳輸實體主體)

實體主體可以理解成請求體
雖然用GET也可以傳輸實體的主體，但是一般不用get，雖然POST和GET相似，但是POST的主要目的不是獲取響應的主體內(nèi)容。

3、PUT(傳輸文件)

要求在請求報文的主體中包含文件內(nèi)容。然后保存到請求URI的指定的位置。

4、HEAD(獲取報文首部)

HEAD和GET方法一樣，只是不返回報文主體部分，用于確認URI的有效性即資源更新日期時間等。

5、DELETE：刪除文件

DELETE方法用來刪除文件，是與PUT相反的方法，用于按請求URI刪除指定的資源。

6、OPTIONS

OPTIONS方法用來查詢針對請求URI指定的資源支持的方法。

7、TRACE(追蹤路徑)

TRACE方法是讓WEB服務器端將之前的請求通信返回給客戶端。

發(fā)送請求的時候，在Max-Forwards首部字段中填入數(shù)值，每經(jīng)過一個服務器端就將數(shù)字減去1，當數(shù)值剛好減到0的時候，就停止傳輸，最后接收到請求的服務器端返回狀態(tài)碼200 OK的響應。

客戶端可以通過TRACE方法查詢發(fā)送出去的請求是怎么樣被加工修改的。這是因為連接到目標服務器可能會通過代理中轉(zhuǎn)。

中間可能會經(jīng)過多個代理服務器，返回當Max-Forwards為0的時候，此時那個服務器或者代理服務器收到的請求。

例子

請求：

TRACE /HTTP/1.1 Host:hackr.jp Max-Forwards:2

響應：

HTTP/1.1 200 OK Content-Type:message/http Content-Length:1024TRACE /HTTP/1.1 Host:hackr.jp Max-Forwards:2

在上面的響應體中，返回響應包含的請求內(nèi)容

8、CONNECT(要求用隧道協(xié)議連接代理，使用SSL或者TLS協(xié)議將通信內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸)

CONNECT方法要求在代理服務器通信時候建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL(Secure Sockets Layer，安全套接字)和TLS(Transport Layer Security，傳輸層安全)協(xié)議把內(nèi)容加密后經(jīng)網(wǎng)絡隧道傳輸。

CONNECT方法的格式如下所示：

• CONNECT 代理服務器名：端口號 HTTP版本

例子

使用CONNECT方法的請求-響應的例子：

• 請求
  CONNECT proxy.hackr.jp:8080 HTTP/1.1
  HOST:proxy.hackr.jp

• 響應
  HTTP/1.1 200 OK（之后進入網(wǎng)絡隧道）

總結(jié)

方法說明支持的HTTP協(xié)議版本

GET	獲取資源	1.0、1.1
POST	傳輸實體實體	1.0、1.1
PUT	傳輸文件	1.0、1.1
HEAD	獲取報文首部	1.0、1.1
DELETE	刪除文件	1.0、1.1
OPTIONS	詢問支持的方法	1.1
TRACE	追蹤路徑	1.1
CONNECT	要求用隧道協(xié)議連接代理	1.1
LINK	建立和資源之間的聯(lián)系	1.0
UNLINK	斷開連接關系	1.0

在這里列舉了中多方法，LINK和UNLINK已經(jīng)被HTTP/1.1廢棄，不再支持。

持久連接節(jié)省通信量

HTTP協(xié)議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。

下面的建立連接和斷開連接可以以左邊為客戶端右邊為服務端為例子看

建立連接

• -----SYN—》
• 《----SYN/ACK-----
• -----ACK----》

斷開TCP連接

• 《----FIN----
• ------ACK—》
• -----FIN—》
• 《-----ACK-----

如果不支持持久連接，在很多HTML頁面中，可能要加載或者很多圖片等，那么就需要多次TCP的連接和斷開。

持久連接(HTTP1.1所有的連接都是持久連接)

為了解決TCP連接的問題，HTTP/1.1和一部分HTTP/1.0想出了持久連接的方法，持久連接的特點是，只要任意一端沒有明確斷開連接，則保持TCP連接狀態(tài)。

在HTTP/1.1中，所有的連接默認都是持久連接，但是在1.0的時候還沒有標準化。

管線化(不需要等待響應即可直接發(fā)送下一個請求)

持久連接使得多數(shù)請求以管線化(Pipeling)方式發(fā)送成為可能。從前發(fā)送請求需要等待并收到響應，才能發(fā)送下一個請求，管線化技術出現(xiàn)后，不用等待響應即可直接發(fā)送下一個請求。

使用Cookie管理狀態(tài)

因為HTTP是無狀態(tài)的，不對之前的請求和響應的狀態(tài)進行管理。也就是說，無法根據(jù)之前的狀態(tài)進行本次的請求處理。

無狀態(tài)好處：

• 不必保存狀態(tài)，自然可減少服務器的CPU以及內(nèi)存的消耗。

Cookie技術通過在請求和響應的報文中寫入Cookie信息來控制客戶端的狀態(tài)。

• 1、Cookie會根據(jù)從服務器發(fā)送的響應報文內(nèi)的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往服務器發(fā)送請求的時候，客戶端會自動在請求報文中加入Cookie值后發(fā)送出去。
• 2、服務器端發(fā)現(xiàn)客戶端發(fā)送來的Cookie之后，會去檢查究竟是從哪一個客戶端發(fā)來的連接請求，然后對比服務器上的記錄，得到之前的狀態(tài)信息。

例子

• 1、請求報文(沒有Cookie信息的狀態(tài))

GET /reader/ HTTP/1.1 Host:hackr.jp

• 2、響應報文(服務器端生成Cookie信息)

HTTP/1.1 200 OK Date: Thu,12 Jul 2012 07:12:20 GMT Server:Apache Set-Cookie:sid=13520771420226724;path=/;expires=Wed,10-Oct-12 07:12:20 GMT Context-Type:text/plain;charset=UTF-8

• 3、請求報文(自動發(fā)送保存著的Cookie信息)

GET /image/ HTTP/1.1 Host:hackr.jp Cookie:sid=13520771420226724

HTTP報文內(nèi)的HTTP信息

1、請求報文結(jié)構(gòu)

請求報文結(jié)構(gòu)

• 請求行
• 請求頭(報文首部)
• 請求空行
• 請求體(報文主體)

響應報文結(jié)構(gòu)：

• 響應行(狀態(tài)行)
• 響應頭
• 響應空行
• 響應體

首部字段分類

• 通用首部
• 請求首部
• 響應首部
• 實體首部

提升傳輸速率

編碼提升傳輸速率（客戶端收到后需要解碼）

編碼的操作需要計算機完成，因此會消耗更多的CPU資源。

常見的壓縮編碼有下面幾種：

• gzip(GNU zip)
• compress(UNIX 系統(tǒng)的標準壓縮)
• deflate(zlib)
• identity(不進行編碼)

分割發(fā)送的分塊傳輸編碼

在HTTP通信過程中，請求的編碼實體資源尚未傳輸完成之前是無法顯示請求頁面的，在傳輸大容量時，通過把數(shù)據(jù)分割成多塊，能夠讓瀏覽器逐步顯示頁面。

這種把實體主體分塊的功能稱為分塊傳輸編碼。

發(fā)送多種數(shù)據(jù)的多部分對象集合

MIME類型

MIME(Multipurpose Internet Mail Extensions)：多用途因特網(wǎng)郵件擴展

在把輸出結(jié)果傳送到瀏覽器上的時候，瀏覽器必須啟動適當?shù)膽贸绦騺硖幚磉@個傳輸文檔，這就可以通過MIME來完成。在HTTP中，MIME類型被定義在Content-Type Head中。

multipart/form-data

在web表單文件上傳時使用

multipart/byteranges

狀態(tài)碼206響應報文包含了多個范圍的內(nèi)容時使用

multipart/byteranges

在HTTP報文中使用多部分對象集合時，需要在首部里加上Content-type。

獲取部分內(nèi)容的范圍請求(Range首部來指定資源的byte范圍)

要實現(xiàn)該功能需要指定下載的實體范圍，像這樣，指定范圍發(fā)送的請求叫做范圍請求。

5001-10000字節(jié)：

• Range:bytes=5001-10000

從5001字節(jié)之后全部：

• Range:bytes=5001-

從一開始到3000字節(jié)和5000-7000字節(jié)的多重范圍：

• Range:bytes=0-3000,5000-7000

內(nèi)容協(xié)商返回合適內(nèi)容

在一個Web網(wǎng)站可能存在多份相同內(nèi)容的頁面，比如英語版本、中文版本的web頁面，雖然內(nèi)容上相同，但是使用的語言不同。

當瀏覽器的默認語言為英語或者中文，訪問相同的URI的WEB頁面的時候，則會顯示對應的英語版或者中文版本的頁面。這樣的機制稱為內(nèi)容協(xié)商。

內(nèi)容協(xié)商會以語言、字符集、編碼方式等為基準判斷響應的資源：

• ACCEPT
• ACCEPT-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

內(nèi)容協(xié)商分類

• 服務器驅(qū)動協(xié)商
  以請求的首部為參考，在服務端自動處理。
• 客戶端驅(qū)動協(xié)商
  用戶從瀏覽器顯示的可選選項中進行手動選擇
• 透明協(xié)商
  這是服務器驅(qū)動和客戶端驅(qū)動的結(jié)合體，是由服務器端和客戶端各自進行內(nèi)容協(xié)商的一種方法。

返回結(jié)果的HTTP狀態(tài)碼

狀態(tài)碼告知從服務端返回的請求結(jié)果

類別原因短語

1XX	信息性狀態(tài)碼	接收的請求正在處理
2XX	成功狀態(tài)碼	請求正常處理完畢
3XX	重定向狀態(tài)碼	需要進行附加操作以完成請求
4XX	客戶端錯誤狀態(tài)碼	服務器無法處理請求
5XX	服務器錯誤狀態(tài)碼	服務器處理請求錯誤

只要遵守狀態(tài)碼類別的定義，即使改變RFC2616中定義的狀態(tài)碼或服務器端自行創(chuàng)建狀態(tài)碼都沒問題。

2XX成功

200(表示請求被正常處理)

表示從客戶端發(fā)來的請求在服務器端被正常處理了。

204(No Content)

表示服務器接收的請求已成功處理，但是在返回的響應報文中不含實體的主體部分，也不允許返回任何實體的主體。

當瀏覽器發(fā)出請求處理之后，返回204響應，那么瀏覽器顯示的頁面不發(fā)生更新。

206(Partial Content)

該狀態(tài)碼表示客戶端進行了范圍請求，而服務器成功執(zhí)行了這部分的get請求。

響應報文中包含有Content-Range指定范圍的實體內(nèi)容。

3XX重定向

1、301Moved Permanently(永久性重定向)

永久性重定向.
這個狀態(tài)碼表示請求的資源已經(jīng)被分配了新的URI。以后應該使用資源現(xiàn)在所指的URI。

2、302 Found

臨時性重定向
該狀態(tài)碼表示請求的資源被分配了新的URI。希望用戶(本次)能使用新的URI訪問。
和301不同的是，302資源不是被永久移動。

303(略)

304(略)

307(略)

4XX客戶端錯誤

400 Bad Request(請求報文存在語法錯誤)

該狀態(tài)碼表示請求報文中存在語法錯誤。

401 Unauthorized

表示發(fā)送的請求需要有HTTP認證(BASIC、DIGEST認證)的認證信息。如果之前以及進行過一次請求，那么表示用戶認證失敗。

403Forbidden

表示對請求資源的訪問被服務器拒絕了。
服務器沒有必要給出拒絕的理由，但是如果要給出拒絕理由的話，可以在實體的主體部分對原因進行描述。這樣用戶就能看到。

404 Not Found

表示服務器上無法找到請求的資源

5XX服務器錯誤

500 Internal Server Error(執(zhí)行請求時發(fā)生錯誤)

表示服務器端在執(zhí)行請求時發(fā)生錯誤

503 Service Unavailable(服務器處于超負載或正在進行停機維護)

表示服務器暫時處于超負載或者正在進行停機維護。

與HTTP協(xié)作的Web服務器

1、用單個虛擬主機實現(xiàn)多域名(借助Host首部實現(xiàn))

在互聯(lián)網(wǎng)上，域名通過DNS解析映射到IP地址，可見，當請求發(fā)送到服務器的時候，已經(jīng)上以IP地址形式訪問了。

所以如果多域名的話，當接收到請求的時候就要弄清楚究竟要訪問哪個域名。

在相同的IP地址下，虛擬主機可以寄存多個不同主機名和域名的web網(wǎng)站，因此在發(fā)送HTTP請求的時候，必須在Host首部內(nèi)完整指定主機名或域名的URI

2、通信數(shù)據(jù)轉(zhuǎn)發(fā)程序：代理、網(wǎng)關、隧道

在HTTP通信的時候，還有一些用于轉(zhuǎn)發(fā)通信數(shù)據(jù)的應用程序，如：代理、網(wǎng)關和隧道。

這些應用程序和服務器可以將請求轉(zhuǎn)發(fā)給通信線路上的下一站服務器，并且能接收從那臺服務器發(fā)送的響應再轉(zhuǎn)發(fā)給客戶端。

代理(不會改變請求URI)

代理是一種有轉(zhuǎn)發(fā)功能的應用程序，位于服務器和客戶端之間，接收由客戶端發(fā)送來的請求再轉(zhuǎn)發(fā)給服務器，同時也接收服務器返回的響應并轉(zhuǎn)發(fā)給客戶端。

代理的好處：利用緩存減少網(wǎng)絡帶寬的流量。

緩存代理

預先將資源的副本保存在代理服務器
當對相同資源請求的時候，可以不從原服務器取數(shù)據(jù)，而是將之前緩存的資源作為響應返回。

透明代理

不對報文做任何加工的代理。

網(wǎng)關

網(wǎng)關是其他服務器通信數(shù)據(jù)的服務器，接收從客戶端發(fā)來的請求，它就像自己擁有資源的服務器一樣對請求進行處理，有時客戶都不會察覺自己的通信目標是一個網(wǎng)關。

網(wǎng)關和代理類似，但是網(wǎng)關能使通信線路上的服務器提供非HTTP協(xié)議服務。

隧道(保證服務端和客戶端可以安全通信)

隧道可以按照要求建立起一條與其他服務器的通信線路，屆時可以使用SSL等加密方式進行通信。隧道目的是為了保證服務端和客戶端之間可以安全通信。

保存資源的緩存

緩存服務器好處在于利用緩存可以避免多次從原服務器轉(zhuǎn)發(fā)資源，因此客戶端就近從服務器上獲取資源，而原服務器也不必多次處理相同請求。

HTTP首部(請求頭、響應頭部分)

首部傳遞重要信息

HTTP首部是構(gòu)成HTTP報文的重要要素之一。無論是請求和響應都會使用首部字段，它能起到傳遞額外重要信息的作用。

首部是為了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證等內(nèi)容

首部結(jié)構(gòu)

首部字段名：字段值
例如：

• Content-Type來表示報文主體的對象類型
  Content-Type：text/html

4種首部字段類型

通用首部字段

在請求和響應兩方都有的首部。

請求首部字段

從客戶端向服務端發(fā)送請求報文時使用的首部，補充了請求的附加內(nèi)容、客戶端信息、響應內(nèi)容相關內(nèi)容優(yōu)先級等信息

響應首部字段

從服務器端向客戶端返回響應報文時使用的首部，補充了響應的附加內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息。

實體首部字段

補充了資源內(nèi)容更新時間等與實體有關的信息。

首部具體信息(略)

總結(jié)

以上是生活随笔為你收集整理的图解HTTP-HTTP的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。