最詳細的http協(xié)議邮偎、tcp/ip協(xié)議（轉自頭條號豬哥亮額）

圖解傳說中的HTTP協(xié)議

先扒一扒HTTP協(xié)議背景肌似？

• HTTP(HyperText Transfer Protocol) 即超文本傳輸協(xié)議讯赏，現在基本上所有web項目都遵從HTTP協(xié)議（協(xié)議就是一種人為的規(guī)范）垮兑。

• 目前絕大部分使用的都是HTTP/1.1版本（1.0太老，2.0仍在制訂中漱挎。系枪。。）磕谅。

因為HTTP協(xié)議是屬于TCP/IP協(xié)議簇的私爷，所以先簡單介紹下與HTTP相關的TCP/IP知識。

TCP/IP簡介膊夹。

• TCP/IP是一個協(xié)議簇衬浑，是由許多協(xié)議組成的。

TCP/IP四層模型割疾。

• TCP/IP按照層次從上至下分為四層：應用層嚎卫，傳輸層，網絡層宏榕，數據鏈路層拓诸。（實際上最初理論上OSI模型是分的七層，我們程序猿的話通常只用分四層就行了麻昼。）

圖解傳說中的HTTP協(xié)議（一）

1. 應用層 ：

• 應用層決定了向用戶提供應用服務時通信的活動奠支。TCP/IP協(xié)議族內預存了各類通用的應用服務。比如抚芦，FTP（File Transfer Protocol倍谜，文件傳輸協(xié)議）和DNS（Domain Name System迈螟，域名系統(tǒng)）服務就是其中兩類。HTTP協(xié)議也處于該層尔崔。

1. 傳輸層 ：

• 傳輸層對上層應用層答毫，提供處于網絡連接中的兩臺計算機之間的數據傳輸。在傳輸層有兩個性質不同的協(xié)議：TCP（Transmission ControlProtocol季春，傳輸控制協(xié)議）和UDP（User Data Protocol洗搂，用戶數據報協(xié)議）。

1. 網絡層 ：

• 網絡層用來處理在網絡上流動的數據包载弄。數據包是網絡傳輸的最小數據單位耘拇。該層規(guī)定了通過怎樣的路徑（所謂的傳輸路線）到達對方計算機，并把數據包傳送給對方宇攻。與對方計算機之間通過多臺計算機或網絡設備進行傳輸時惫叛，網絡層所起的作用就是在眾多的選項內選擇一條傳輸路線。

1. 鏈路層（又名數據鏈路層逞刷，網絡接口層） ：

• 用來處理連接網絡的硬件部分嘉涌。包括控制操作系統(tǒng)、硬件的設備驅動夸浅、NIC（Network Interface Card洛心，網絡適配器，即網卡）题篷，及光纖等物理可見部分（還包括連接器等一切傳輸媒介）。硬件上的范疇均在鏈路層的作用范圍之內厅目。

TCP/IP具體是怎么通信的呢番枚？

• 利用TCP/IP協(xié)議族進行網絡通信時，會通過分層順序與對方進行通信损敷。發(fā)送端從應用層往下走葫笼，接收端則往應用層往上走。我們用HTTP舉例來說明拗馒，首先作為發(fā)送端的客戶端在應用層（HTTP協(xié)議）發(fā)出一個想看某個Web頁面的HTTP請求路星。接著，為了傳輸方便诱桂，在傳輸層（TCP協(xié)議）把從應用層處收到的數據（HTTP請求報文）進行分割洋丐，并在各個報文上打上標記序號及端口號后轉發(fā)給網絡層。在網絡層（IP協(xié)議）挥等，增加作為通信目的地的MAC地址后轉發(fā)給鏈路層友绝。這樣一來，發(fā)往網絡的通信請求就準備齊全了肝劲。接收端的服務器在鏈路層接收到數據迁客，按序往上層發(fā)送郭宝，一直到應用層。當傳輸到應用層掷漱，才能算真正接收到由客戶端發(fā)送過來的HTTP請求粘室。

圖解傳說中的HTTP協(xié)議（一）

• 發(fā)送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息卜范。反之衔统，接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去先朦。這種把數據信息包裝起來的做法稱為封裝（encapsulate）缰冤。

圖解傳說中的HTTP協(xié)議（一）

負責傳輸的IP協(xié)議。

• 按層次分喳魏，IP（Internet Protocol）網際協(xié)議位于網絡層棉浸。Internet Protocol這個名稱可能聽起來有點夸張，但事實正是如此刺彩，因為幾乎所有使用網絡的系統(tǒng)都會用到IP協(xié)議迷郑。TCP/IP協(xié)議族中的IP指的就是網際協(xié)議，協(xié)議名稱中占據了一半位置创倔，其重要性可見一斑嗡害。可能有人會把IP和IP 地址搞混畦攘，IP其實是一種協(xié)議的名稱霸妹。

• IP協(xié)議的作用是把各種數據包傳送給對方。而要保證確實傳送到對方那里知押，則需要滿足各類條件叹螟。其中兩個重要的條件是IP地址和MAC地址（Media Access Control Address）。IP地址指明了節(jié)點被分配到的地址台盯，MAC地址是指網卡所屬的固定地址罢绽。IP地址可以和MAC地址進行配對。IP地址可變換静盅，但MAC地址基本上不會更改良价。

• 使用ARP協(xié)議憑借MAC地址進行通信。IP間的通信依賴MAC地址蒿叠。在網絡上明垢，通信的雙方在同一局域網（LAN）內的情況是很少的，通常是經過多臺計算機和網絡設備中轉才能連接到對方栈虚。而在進行中轉時袖外，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時魂务，會采用ARP協(xié)議（Address Resolution Protocol）曼验。ARP 是一種用以解析地址的協(xié)議泌射，根據通信方的IP地址就可以反查出對應的MAC地址。

• 沒有人能夠全面掌握互聯(lián)網中的傳輸狀況鬓照，即在傳輸過程中每一個節(jié)點只需要了解下一個節(jié)點的信息熔酷，再往下的信息就交給下個節(jié)點去處理就行了。在到達通信目標前的中轉過程中豺裆，那些計算機和路由器等網絡設備只能獲悉很粗略的傳輸路線拒秘。 這種機制稱為路由選擇（routing），有點像快遞公司的送貨過程臭猜。想要寄快遞的人躺酒，只要將自己的貨物送到集散中心，就可以知道快遞公司是否肯收件發(fā)貨蔑歌，該快遞公司的集散中心檢查貨物的送達地址羹应，明確下站該送往哪個區(qū)域的集散中心。接著次屠，那個區(qū)域的集散中心自會判斷是否能送到對方的家中园匹。我們是想通過這個比喻說明，無論哪臺計算機劫灶、哪臺網絡設備裸违，它們都無法全面掌握互聯(lián)網中的細節(jié)。

圖解傳說中的HTTP協(xié)議（一）

確北净瑁可靠性的TCP協(xié)議供汛。

• 按層次分，TCP位于傳輸層涌穆，提供可靠的字節(jié)流服務紊馏。所謂的字節(jié)流服務（Byte Stream Service）是指，為了方便傳輸蒲犬，將大塊數據分割成以報文段（segment）為單位的數據包進行管理。而可靠的傳輸服務是指岸啡，能夠把數據準確可靠地傳給對方原叮。一言以蔽之，TCP協(xié)議為了更容易傳送大數據才把數據分割巡蘸，而且TCP協(xié)議能夠確認數據最終是否送達到對方奋隶。

• 確保數據能到達目標。為了準確無誤地將數據送達目標處悦荒，TCP協(xié)議采用了三次握手（three-way handshaking）策略唯欣。用TCP協(xié)議把數據包送出去后，TCP不會對傳送后的情況置之不理搬味，它一定會向對方確認是否成功送達境氢。握手過程中使用了TCP的標志（flag） ——SYN（synchronize） 和ACK（acknowledgement）蟀拷。發(fā)送端首先發(fā)送一個帶SYN標志的數據包給對方。接收端收到后猛蔽，回傳一個帶有SYN/ACK標志的數據包以示傳達確認信息犯眠。最后楼肪，發(fā)送端再回傳一個帶ACK標志的數據包，代表握手結束此衅。若在握手過程中某個階段莫名中斷，TCP協(xié)議會再次以相同的順序發(fā)送相同的數據包亭螟。除了上述三次握手挡鞍，TCP協(xié)議還有其他各種手段來保證通信的可靠性。

圖解傳說中的HTTP協(xié)議（一）

負責域名解析的DNS服務预烙。

• DNS（Domain Name System）服務是和HTTP協(xié)議一樣位于應用層的協(xié)議墨微。它提供域名到IP地址之間的解析服務。計算機既可以被賦予IP地址默伍，也可以被賦予主機名和域名欢嘿。比如www.baidu.com。因為域名更加直觀也糊，所以用戶通常使用主機名或域名來訪問對方的計算機炼蹦，而不是直接通過IP地址訪問。但要讓計算機去理解名稱狸剃，相對而言就變得困難了掐隐。因為計算機更擅長處理一長串數字。為了解決上述的問題钞馁，DNS服務應運而生虑省。DNS協(xié)議提供通過域名查找IP地址，或逆向從IP地址反查域名的服務僧凰。

圖解傳說中的HTTP協(xié)議（一）

HTTP協(xié)議與其他TCP/IP協(xié)議是如何協(xié)作的探颈？

圖解傳說中的HTTP協(xié)議（一）

URI和URL。

URI是Uniform Resource Identifier的縮寫训措，即統(tǒng)一資源標識符伪节。

• RFC2396分別對這 3 個單詞進行了如下定義：

• Uniform ：規(guī)定統(tǒng)一的格式可方便處理多種不同類型的資源， 而不用根據上下文環(huán)境來識別資源指定的訪問方式绩鸣。另外怀大， 加入新增的協(xié)議方案（如http:或ftp:） 也更容易。

• Resource ：資源的定義是可標識的任何東西呀闻。 除了文檔文件化借、 圖像或服務（例如當天的天氣預報） 等能夠區(qū)別于其他類型的， 全都可作為資源捡多。 另外蓖康， 資源不僅可以是單一的铐炫， 也可以是多數的集合體。

• Identifier ：表示可標識的對象钓瞭。 也稱為標識符驳遵。

• 綜上所述，URI就是由某個協(xié)議方案表示的資源的定位標識符山涡。 協(xié)議方案是指訪問資源所使用的協(xié)議類型名稱堤结。 采用HTTP協(xié)議時， 協(xié)議方案就是http鸭丛。 除此之外竞穷， 還有ftp、mailto鳞溉、telnet瘾带、file等。 標準的URI協(xié)議方案有 30 種左右熟菲， 由隸屬于國際互聯(lián)網資源管理的非營利社團ICANN（Internet Corporation for Assigned Names and Numbers看政， 互聯(lián)網名稱與數字地址分配機構） 的IANA（Internet Assigned Numbers Authority， 互聯(lián)網號碼分配局） 管理頒布抄罕。

• URI用字符串標識某一互聯(lián)網資源允蚣， 而URL表示資源的地點（互聯(lián)網上所處的位置） 。 可見URL是URI的子集呆贿。（當然通橙峦茫可以大致把URL理解成URI）

URI的格式。

• 要想表示指定的資源做入， 就得使用涵蓋全部必要信息的絕對URI冒晰，同樣的也會有相對URI。這里以相對URL為例竟块，就是指從瀏覽器中基本URL處指定的URL壶运，形如/image/logo.gif這種形式。

接下來結合下面這個例子著重介紹一下絕對URI：

圖解傳說中的HTTP協(xié)議（二）

• 協(xié)議方案名：使用http:或https:等協(xié)議方案名獲取訪問資源時要指定協(xié)議類型浪秘。 不區(qū)分字母大小寫前弯， 最后附一個冒號（:）。也可使用data:或javascript:這類指定數據或腳本程序的方案名秫逝。

• 登錄信息（認證） ：指定用戶名和密碼作為從服務器端獲取資源時必要的登錄信息（身份認證） 。 此項是可選項询枚。

• 服務器地址 ：使用絕對URI必須指定待訪問的服務器地址违帆。 地址可以是類似baidu.com這種DNS可解析的域名， 或是192.168.1.1這類IPv4地址金蜀， 還可以是[0:0:0:0:0:0:0:1]這樣用方括號括起來的IPv6地址刷后。

• 服務器端口號 :指定服務器連接的網絡端口號的畴。 此項也是可選項， 若用戶省略則自動使用默認端口號尝胆。

• 帶層次的文件路徑 :指定服務器上的文件路徑來定位特指的資源丧裁。 這與UNIX系統(tǒng)的文件目錄結構相似。

• 查詢字符串 :針對已指定的文件路徑內的資源含衔， 可以使用查詢字符串傳入任意參數煎娇。 此項可選。

• 片段標識符 :使用片段標識符通程叭荆可標記出已獲取資源中的子資源（文檔內的某個位置） 缓呛。 但在RFC中并沒有明確規(guī)定其使用方法。 該項也為可選項杭隙。

RFC : Request for Comments哟绊， 征求修正意見書。一些用來制定HTTP協(xié)議技術標準的文檔痰憎，當然并不是強制性的票髓，所以還是有一小部分應用程序并沒有遵從RFC標準，這也就導致了其他應用不同標準的互聯(lián)網資源可能就無法與該應用程序進行通訊了铣耘。

• RFC3986列舉了幾種URI的常用語法格式：

1. tp://ftp.is.co.za/rfc/rfc1808.txt

2. http://www.ietf.org/rfc/rfc2396.txt

3. ldap://[2001:db8::7]/c=GB?objectClass?one

4. mailto:John.Doe@example.com

5. news:comp.infosystems.www.servers.unix

6. tel:+1-816-555-1212

7. telnet://192.0.2.16:80/

8. urn:oasis:names:specification:docbook:dtd:xml:4.1.2

HTTP協(xié)議用于客戶端和服務器端之間的通信洽沟。

• HTTP協(xié)議和TCP/IP協(xié)議族內的其他眾多的協(xié)議相同， 用于客戶端和服務器之間的通信涡拘。請求訪問文本或圖像等資源的一端稱為客戶端玲躯， 而提供資源響應的一端稱為服務器端。在兩臺計算機之間使用HTTP協(xié)議通信時鳄乏， 在一條通信線路上必定有一端是客戶端跷车， 另一端則是服務器端。有時候橱野， 按實際情況朽缴， 兩臺計算機作為客戶端和服務器端的角色有可能會互換。 但就僅從一條通信路線來說水援， 服務器端和客戶端的角色是確定的密强， 而用HTTP協(xié)議能夠明確區(qū)分哪端是客戶端， 哪端是服務器端蜗元。

圖解傳說中的HTTP協(xié)議（二）

通過請求和響應的交換達成通信或渤。

圖解傳說中的HTTP協(xié)議（二）

• HTTP協(xié)議規(guī)定， 請求從客戶端發(fā)出奕扣， 最后服務器端響應該請求并返回薪鹦。 換句話說， 肯定是先從客戶端開始建立通信的， 服務器端在沒有接收到請求之前不會發(fā)送響應池磁。

圖解傳說中的HTTP協(xié)議（二）

• 起始行開頭的GET表示請求訪問服務器的類型奔害， 稱為方法（method） 。 隨后的字符串/index.htm指明了請求訪問的資源對象地熄，也叫做請求URI（request-URI） 华临。 最后的HTTP/1.1， 即HTTP的版本號端考， 用來提示客戶端使用的HTTP協(xié)議功能雅潭。綜合來看， 這段請求內容的意思是： 請求訪問某臺HTTP服務器上的/index.htm頁面資源跛梗。

• 請求報文是由請求方法寻馏、 請求URI、 協(xié)議版本核偿、 可選的請求首部字段和內容實體構成的诚欠。

圖解傳說中的HTTP協(xié)議（二）

• 緊挨著的200 OK表示請求的處理結果的狀態(tài)碼（status code） 和原因短語（reason-phrase） 。 下一行顯示了創(chuàng)建響應的日期時間漾岳， 是首部字段（header field） 內的一個屬性轰绵。接著以一空行分隔， 之后的內容稱為資源實體的主體（entity body）尼荆。響應報文基本上由協(xié)議版本左腔、 狀態(tài)碼（表示請求成功或失敗的數字代 碼） 、 用以解釋狀態(tài)碼的原因短語捅儒、 可選的響應首部字段以及實體主體構成液样。 稍后我們會對這些內容進行詳細說明。

HTTP是不保存狀態(tài)的協(xié)議巧还。

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

圖解傳說中的HTTP協(xié)議（二）

• 使用HTTP協(xié)議阶牍， 每當有新的請求發(fā)送時喷面， 就會有對應的新響應產生。 協(xié)議本身并不保留之前一切的請求或響應報文的信息走孽。 這是為了更快地處理大量事務惧辈， 確保協(xié)議的可伸縮性， 而特意把HTTP協(xié)議設計成如此簡單的磕瓷『谐荩可是， 隨著Web的不斷發(fā)展， 因無狀態(tài)而導致業(yè)務處理變得棘手的情況增多了县昂。 比如， 用戶登錄到一家購物網站陷舅， 即使他跳轉到該站的其他頁面后倒彰， 也需要能繼續(xù)保持登錄狀態(tài)。 針對這個實例莱睁， 網站為了能夠掌握是誰送出的請求待讳， 需要保存用戶的狀態(tài)。HTTP/1.1雖然是無狀態(tài)協(xié)議仰剿， 但為了實現期望的保持狀態(tài)功能创淡， 于是引入了Cookie技術。 有了Cookie再用HTTP協(xié)議通信南吮， 就可以管理狀態(tài)了琳彩。 有關Cookie的詳細內容稍后講解。

請求URI定位資源

• HTTP協(xié)議使用URI定位互聯(lián)網上的資源部凑。 正是因為URI的特定功能露乏， 在互聯(lián)網上任意位置的資源都能訪問到。

[圖片上傳中...(image-c7ac2e-1586849894854-124)]

• 當客戶端請求訪問資源而發(fā)送請求時涂邀，URI需要將作為請求報文中的請求URI包含在內瘟仿。 指定請求URI的方式有很多。

[圖片上傳中...(image-a60fd7-1586849894854-123)]

• 除此之外比勉， 如果不是訪問特定資源而是對服務器本身發(fā)起請求劳较， 可以用一個*來代替請求URI。 下面這個例子是查詢HTTP服務器端支持的HTTP方法種類浩聋。

[圖片上傳中...(image-1e410c-1586849894854-122)]

告知服務器意圖的HTTP方法观蜗。

• 向請求URI指定的資源發(fā)送請求報文時， 采用稱為方法的命令赡勘。方法的作用在于嫂便， 可以指定請求的資源按期望產生某種行為。 方法中有GET闸与、POST和HEAD等毙替。

[圖片上傳中...(image-71e72b-1586849894854-121)]

• 下表列出了HTTP/1.0和HTTP/1.1支持的方法。 另外践樱， 方法名區(qū)分大小寫厂画， 注意要用大寫字母。

[圖片上傳中...(image-511f3f-1586849894854-120)]

在這里列舉的眾多方法中拷邢，LINK和UNLINK已被HTTP/1.1廢棄袱院， 不再支持。

GET： 獲取資源。

• GET方法用來請求訪問已被URI識別的資源忽洛。 指定的資源經服務器端解析后返回響應內容腻惠。 也就是說， 如果請求的資源是文本欲虚， 那就保持原樣返回集灌； 如果是像CGI（Common Gateway Interface， 通用網關接口）那樣的程序复哆， 則返回經過執(zhí)行后的輸出結果欣喧。

[圖片上傳中...(image-cc51a5-1586849894854-119)]

[圖片上傳中...(image-3f3183-1586849894854-118)]

POST： 傳輸實體主體。

• 雖然用GET方法也可以傳輸實體的主體梯找， 但一般不用GET方法進行傳輸唆阿， 而是用POST方法。 雖說POST的功能與GET很相似锈锤， 但POST的主要目的并不是獲取響應的主體內容驯鳖。

[圖片上傳中...(image-91e173-1586849894854-117)]

[圖片上傳中...(image-3503ed-1586849894854-116)]

PUT： 傳輸文件。

• PUT方法用來傳輸文件牙咏。 就像FTP協(xié)議的文件上傳一樣臼隔， 要求在請求報文的主體中包含文件內容， 然后保存到請求URI指定的位置妄壶。但是摔握， 鑒于HTTP/1.1的PUT方法自身不帶驗證機制， 任何人都可以 上傳文件 , 存在安全性問題丁寄， 因此一般的Web網站不使用該方法氨淌。 若配合Web應用程序的驗證機制， 或架構設計采用REST（REpresentational State Transfer伊磺， 表征狀態(tài)轉移） 標準的同類Web網站盛正， 就可能會開放使用PUT方法。

[圖片上傳中...(image-486378-1586849894854-115)]

[圖片上傳中...(image-a32645-1586849894854-114)]

HEAD： 獲得報文首部屑埋。

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

[圖片上傳中...(image-3daf22-1586849894854-113)]

[圖片上傳中...(image-2c1fa4-1586849894854-112)]

DELETE： 刪除文件续崖。

• DELETE方法用來刪除文件， 是與PUT相反的方法团搞。DELETE方法按請求URI刪除指定的資源严望。 但是，HTTP/1.1的DELETE方法本身和PUT方法一樣不帶驗證機制逻恐， 所以一般的Web網站也不使用DELETE方法像吻。 當配合Web應用程序的驗證機制峻黍， 或遵守REST標準時還是有可能會開放使用的。

[圖片上傳中...(image-49b520-1586849894853-111)]

[圖片上傳中...(image-51c233-1586849894853-110)]

OPTIONS： 詢問支持的方法拨匆。

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

[圖片上傳中...(image-3b37ce-1586849894853-109)]

[圖片上傳中...(image-726f27-1586849894853-108)]

TRACE： 追蹤路徑。

• TRACE方法是讓Web服務器端將之前的請求通信環(huán)回給客戶端的方法惭每。發(fā)送請求時阵面， 在Max-Forwards首部字段中填入數值， 每經過一個服務器端就將該數字減1洪鸭， 當數值剛好減到0時， 就停止繼續(xù)傳輸仑扑， 最后接收到請求的服務器端則返回狀態(tài)碼200 OK的響應览爵。客戶端通過TRACE方法可以查詢發(fā)送出去的請求是怎樣被加工修改的镇饮。 這是因為蜓竹， 請求想要連接到源目標服務器可能會通過代理中轉，TRACE方法就是用來確認連接過程中發(fā)生的一系列操作储藐。但是俱济，TRACE方法本來就不怎么常用， 再加上它容易引發(fā)XST（Cross-Site Tracing钙勃， 跨站追蹤） 攻擊蛛碌， 通常就更不會用到了。

[圖片上傳中...(image-192f9f-1586849894853-107)]

[圖片上傳中...(image-32da4c-1586849894853-106)]

CONNECT： 要求用隧道協(xié)議連接代理辖源。

• CONNECT方法要求在與代理服務器通信時建立隧道蔚携， 實現用隧道協(xié)議進行TCP通信。 主要使用SSL（Secure Sockets Layer克饶， 安全套接層） 和TLS（Transport Layer Security酝蜒， 傳輸層安全） 協(xié)議把通信內容加密后經網絡隧道傳輸。

[圖片上傳中...(image-b76eac-1586849894853-105)]

[圖片上傳中...(image-68df21-1586849894853-104)]

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

• HTTP 協(xié)議的初始版本中亡脑， 每進行一次 HTTP 通信就要斷開一次 TCP 連接。以當年的通信情況來說邀跃，因為都是些容量很小的文本傳輸， 所以即使這樣也沒有多大問題坞嘀。 可隨著 HTTP 的普及躯护， 文檔中包含大量圖片的情況多了起來。比如丽涩， 使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時棺滞， 在發(fā)送請求訪問 HTML 頁面資源的同時裁蚁， 也會請求該 HTML 頁面里包含的其他資源。 因此继准， 每次的請求都會造成無謂的 TCP 連接建立和斷開葛假， 增加通信量的開銷搀矫。

[圖片上傳中...(image-886540-1586849894853-103)]

[圖片上傳中...(image-59d48e-1586849894853-102)]

持久連接。

• 為解決上述 TCP 連接的問題， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent onnections究珊， 也稱為 HTTP keep-alive 或 HTTP connection reuse） 的方法。 持久連接的特點是颠通， 只要任意一端沒有明確提出斷開連接险污， 則保持 TCP 連接狀態(tài)。

[圖片上傳中...(image-1d74e3-1586849894853-101)]

• 持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷憎瘸， 減輕了服務器端的負載入篮。 另外， 減少開銷的那部分時間幌甘， 使 HTTP 請求和響應能夠更早地結束潮售， 這樣 Web 頁面的顯示速度也就相應提高了。在 HTTP/1.1 中锅风， 所有的連接默認都是持久連接酥诽， 但在 HTTP/1.0 內并未標準化。 雖然有一部分服務器通過非標準的手段實現了持久連接皱埠，但服務器端不一定能夠支持持久連接肮帐。 毫無疑問， 除了服務器端边器， 客戶端也需要支持持久連接泪姨。

管線化。

• 持久連接使得多數請求以管線化（pipelining） 方式發(fā)送成為可能饰抒。 從前發(fā)送請求后需等待并收到響應肮砾， 才能發(fā)送下一個請求。 管線化技術出現后袋坑， 不用等待響應亦可直接發(fā)送下一個請求仗处。這樣就能夠做到同時并行發(fā)送多個請求， 而不需要一個接一個地等待響應了枣宫。

[圖片上傳中...(image-c94dc6-1586849894853-100)]

• 比如婆誓， 當請求一個包含 10 張圖片的 HTML Web 頁面， 與挨個連接相比也颤， 用持久連接可以讓請求更快結束洋幻。 而管線化技術則比持久連接還要快。 請求數越多翅娶， 時間差就越明顯文留。

使用 Cookie 的狀態(tài)管理好唯。

• HTTP 是無狀態(tài)協(xié)議， 它不對之前發(fā)生過的請求和響應的狀態(tài)進行管理燥翅。 也就是說骑篙， 無法根據之前的狀態(tài)進行本次的請求處理。假設要求登錄認證的 Web 頁面本身無法進行狀態(tài)的管理（不記錄已登錄的狀態(tài)） 森书， 那么每次跳轉新頁面不是要再次登錄靶端， 就是要在每次請求報文中附加參數來管理登錄狀態(tài)。不可否認凛膏， 無狀態(tài)協(xié)議當然也有它的優(yōu)點杨名。 由于不必保存狀態(tài)， 自然可減少服務器的 CPU 及內存資源的消耗猖毫。 從另一側面來說镣煮， 也正是因為 HTTP 協(xié)議本身是非常簡單， 所以才會被應用在各種場景里鄙麦。

[圖片上傳中...(image-bc7069-1586849894853-99)]

• 保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的矛盾問題， 于是引入了 Cookie 技術镊折。 Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態(tài)胯府。Cookie 會根據從服務器端發(fā)送的響應報文內的一個叫做 Set-Cookie 的首部字段信息， 通知客戶端保存 Cookie恨胚。當下次客戶端再往該服務器發(fā)送請求時骂因， 客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出去。服務器端發(fā)現客戶端發(fā)送過來的 Cookie 后赃泡， 會去檢查究竟是從哪一個客戶端發(fā)來的連接請求寒波， 然后對比服務器上的記錄， 最后得到之前的狀態(tài)信息升熊。

[圖片上傳中...(image-95b41a-1586849894853-98)]

[圖片上傳中...(image-ae03a-1586849894853-97)]

上圖展示了發(fā)生 Cookie 交互的情景俄烁， HTTP 請求報文和響應報文的內容如下。上圖展示了發(fā)生 Cookie 交互的情景级野， HTTP 請求報文和響應報文的內容如下页屠。

[圖片上傳中...(image-40ef28-1586849894853-96)]

有關請求報文和響應報文內 Cookie 對應的首部字段， 請參考之后的章節(jié)蓖柔。

HTTP 報文內的 HTTP 信息辰企。

• HTTP 通信過程包括從客戶端發(fā)往服務器端的請求及從服務器端返回客戶端的響應。 本章就讓我們來了解一下請求和響應是怎樣運作的况鸣。

HTTP 報文牢贸。

• 用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報文。 請求端（客戶端） 的 HTTP 報文叫做請求報文镐捧， 響應端（服務器端） 的叫做響應報文潜索。HTTP報文本身是由多行（用 CR+LF 作換行符） 數據構成的字符串文本臭增。HTTP 報文大致可分為報文首部和報文主體兩塊。 兩者由最初出現的空行（CR+LF） 來劃分帮辟。 通常速址， 并不一定要有報文主體。

[圖片上傳中...(image-9f354c-1586849894853-95)]

請求報文及響應報文的結構由驹。

[圖片上傳中...(image-a6266-1586849894853-94)]

[圖片上傳中...(image-2bc9e7-1586849894853-93)]

• 請求行 ： 包含用于請求的方法芍锚， 請求 URI 和 HTTP 版本。

• 狀態(tài)行 ： 包含表明響應結果的狀態(tài)碼蔓榄， 原因短語和 HTTP 版本并炮。

• 首部字段 ： 包含表示請求和響應的各種條件和屬性的各類首部。一般有 4 種首部甥郑， 分別是： 通用首部逃魄、 請求首部、 響應首部和實體首部澜搅。

• 其他 ： 可能包含 HTTP 的 RFC 里未定義的首部（Cookie 等）伍俘。

編碼提升傳輸速率。

• HTTP 在傳輸數據時可以按照數據原貌直接傳輸勉躺， 但也可以在傳輸過程中通過編碼提升傳輸速率癌瘾。 通過在傳輸時編碼， 能有效地處理大量的訪問請求饵溅。 但是妨退， 編碼的操作需要計算機來完成， 因此會消耗更多的 CPU 等資源蜕企。

• 報文主體和實體主體的差異咬荷。

• 報文（message） ： 是 HTTP 通信中的基本單位， 由 8 位組字節(jié)流（octet sequence轻掩，其中 octet 為 8 個比特） 組成幸乒， 通過 HTTP 通信傳輸。

• 實體（entity） : 作為請求或響應的有效載荷數據（補充項） 被傳輸唇牧， 其內容由實體首部和實體主體組成逝变。

• HTTP 報文的主體用于傳輸請求或響應的實體主體。通常奋构， 報文主體等于實體主體壳影。 只有當傳輸中進行編碼操作時， 實體主體的內容發(fā)生變化弥臼， 才導致它和報文主體產生差異宴咧。

• 向待發(fā)送郵件內增加附件時， 為了使郵件容量變小径缅， 我們會先用 ZIP 壓縮文件之后再添加附件發(fā)送掺栅。 HTTP 協(xié)議中有一種被稱為內容編碼的功能也能進行類似的操作烙肺。內容編碼指明應用在實體內容上的編碼格式， 并保持實體信息原樣壓縮氧卧。 內容編碼后的實體由客戶端接收并負責解碼桃笙。

[圖片上傳中...(image-6134ac-1586849894853-92)]

• 常用的內容編碼有以下幾種：

• gzip（GNU zip）

• compress（UNIX 系統(tǒng)的標準壓縮）

• deflate（zlib）

• identity（不進行編碼）

• 在 HTTP 通信過程中， 請求的編碼實體資源尚未全部傳輸完成之前沙绝，瀏覽器無法顯示請求頁面搏明。 在傳輸大容量數據時， 通過把數據分割成多塊闪檬， 能夠讓瀏覽器逐步顯示頁面星著。這種把實體主體分塊的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

[圖片上傳中...(image-902f6-1586849894853-91)]

• 分塊傳輸編碼會將實體主體分成多個部分（塊） 粗悯。 每一塊都會用十六進制來標記塊的大小虚循， 而實體主體的最后一塊會使用 “0(CR+LF)” 來標記。使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼样傍， 恢復到編碼前的實體主體横缔。HTTP/1.1 中存在一種稱為傳輸編碼（Transfer Coding） 的機制， 它可以在通信時按某種編碼方式傳輸衫哥， 但只定義作用于分塊傳輸編碼中茎刚。

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

[圖片上傳中...(image-178ce6-1586849894853-90)]

• 發(fā)送郵件時炕檩， 我們可以在郵件里寫入文字并添加多份附件。 這是因為采用了 MIME（Multipurpose Internet Mail Extensions捌斧， 多用途因特網郵件擴展） 機制笛质， 它允許郵件處理文本、 圖片捞蚂、 視頻等多個不同類型的53數據妇押。 例如， 圖片等二進制數據以 ASCII 碼字符串編碼的方式指明姓迅，就是利用 MIME 來描述標記數據類型敲霍。 而在 MIME 擴展中會使用一種稱為多部分對象集合（Multipart） 的方法， 來容納多份不同類型的數據丁存。相應地肩杈， HTTP 協(xié)議中也采納了多部分對象集合， 發(fā)送的一份報文主體內可含有多類型實體解寝。 通常是在圖片或文本文件等上傳時使用扩然。

• 多部分對象集合包含的對象如下：

[圖片上傳中...(image-155738-1586849894853-89)]

• multipart/byteranges ：

• multipart/form-data ： 在 Web 表單文件上傳時使用。

• multipart/byteranges ： 狀態(tài)碼 206（Partial Content聋伦， 部分內容） 響應報文包含了多個范圍的內容時使用夫偶。

• multipart/form-data ：

• 在 HTTP 報文中使用多部分對象集合時界睁， 需要在首部字段里加上 Content-type。 有關這個首部字段兵拢， 我們稍后講解翻斟。使用 boundary 字符串來劃分多部分對象集合指明的各類實體。 在 boundary 字符串指定的各個實體的起始行之前插入“--”標記（例如： --AaB03x说铃、 --THIS_STRING_SEPARATES） 访惜， 而在多部分對象集合對應的字符串的最后插入“--”標記（例如： --AaB03x--、 --THIS_STRING_SEPARATES--） 作為結束截汪。多部分對象集合的每個部分類型中疾牲， 都可以含有首部字段。 另外衙解， 可以在某個部分中嵌套使用多部分對象集合阳柔。

獲取部分內容的范圍請求。

• 以前蚓峦， 用戶不能使用現在這種高速的帶寬訪問互聯(lián)網舌剂， 當時， 下載一個尺寸稍大的圖片或文件就已經很吃力了暑椰。 如果下載過程中遇到網絡中斷的情況霍转， 那就必須重頭開始。 為了解決上述問題一汽， 需要一種可恢復的機制避消。 所謂恢復是指能從之前下載中斷處恢復下載。要實現該功能需要指定下載的實體范圍召夹。 像這樣岩喷， 指定范圍發(fā)送的請求叫做范圍請求（Range Request） 。對一份 10000 字節(jié)大小的資源监憎， 如果使用范圍請求纱意， 可以只請求 5001~10000 字節(jié)內的資源。

[圖片上傳中...(image-d51e35-1586849894853-88)]

• 執(zhí)行范圍請求時鲸阔， 會用到首部字段 Range 來指定資源的 byte 范圍偷霉。byte 范圍的指定形式如下：

• 5001~10 000 字節(jié) ： Range: bytes=5001-10000。

• 從 5001 字節(jié)之后全部的 ： Range: bytes=5001褐筛。

• 從一開始到 3000 字節(jié)和 5000~7000 字節(jié)的多重范圍 ： Range: bytes=-3000, 5000-7000类少。

• 針對范圍請求， 響應會返回狀態(tài)碼為 206 Partial Content 的響應報文渔扎。 另外瞒滴， 對于多重范圍的范圍請求， 響應會在首部字段 ContentType標明 multipart/byteranges 后返回響應報文。如果服務器端無法響應范圍請求妓忍， 則會返回狀態(tài)碼 200 OK 和完整的實體內容虏两。

內容協(xié)商返回最合適的內容。

• 同一個 Web 網站有可能存在著多份相同內容的頁面世剖。 比如英語版和中文版的 Web 頁面定罢， 它們內容上雖相同， 但使用的語言卻不同旁瘫。當瀏覽器的默認語言為英語或中文祖凫， 訪問相同 URI 的 Web 頁面時，則會顯示對應的英語版或中文版的 Web 頁面酬凳。 這樣的機制稱為內容協(xié)商（Content Negotiation）惠况。

[圖片上傳中...(image-d952f2-1586849894853-87)]

• 內容協(xié)商機制是指客戶端和服務器端就響應的資源內容進行交涉， 然后提供給客戶端最為適合的資源宁仔。 內容協(xié)商會以響應資源的語言稠屠、 字符集、 編碼方式等作為判斷的基準翎苫。包含在請求報文中的某些首部字段就是判斷的基準权埠。

• 內容協(xié)商技術有以下 3 種類型：

• 服務器驅動協(xié)商（Server-driven Negotiation） ： 由服務器端進行內容協(xié)商。 以請求的首部字段為參考煎谍， 在服務器端自動處理攘蔽。 但對用戶來說， 以瀏覽器發(fā)送的信息作為判定的依據呐粘， 并不一定能篩選出最優(yōu)內容满俗。

• 客戶端驅動協(xié)商（Agent-driven Negotiation） ： 由客戶端進行內容協(xié)商的方式。 用戶從瀏覽器顯示的可選項列表中手動選擇作岖。 還可以利用 JavaScript 腳本在 Web 頁面上自動進行上述選擇唆垃。 比如按 OS 的類型或瀏覽器類型， 自行切換成 PC 版頁面或手機版頁面鳍咱。

• 透明協(xié)商（Transparent Negotiation） ： 是服務器驅動和客戶端驅動的結合體降盹， 是由服務器端和客戶端各自進行內容協(xié)商的一種方法与柑。

返回結果的 HTTP 狀態(tài)碼谤辜。

• HTTP 狀態(tài)碼負責表示客戶端 HTTP 請求的返回結果、 標記服務器端的處理是否正常价捧、 通知出現的錯誤等工作丑念。

[圖片上傳中...(image-c1933a-1586849894853-86)]

• 狀態(tài)碼如 200 OK， 以 3 位數字和原因短語組成结蟋。數字中的第一位指定了響應類別脯倚， 后兩位無分類。 響應類別有以下 5 種。

[圖片上傳中...(image-12cad5-1586849894853-85)]

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

• 僅記錄在 RFC2616 上的 HTTP 狀態(tài)碼就達 40 種植榕， 若再加上 WebDAV（Web-based Distributed Authoring and Versioning再沧， 基于萬維網的分布式創(chuàng)作和版本控制）和附加 HTTP 狀態(tài)碼 （RFC6585） 等擴展， 數量就達 60 余種尊残。 別看種類繁多炒瘸， 實際上經常使用的大概只有 14 種。 接下來寝衫， 我們就介紹一下這些具有代表性的 14 個狀態(tài)碼顷扩。

2XX 成功，表明請求被正常處理了慰毅。

• 200 OK ： 表示從客戶端發(fā)來的請求在服務器端被正常處理了隘截。在響應報文內， 隨狀態(tài)碼一起返回的信息會因方法的不同而發(fā)生改變事富。 比如技俐， 使用 GET 方法時， 對應請求資源的實體會作為響應返回统台； 而使用 HEAD方法時雕擂， 對應請求資源的實體首部不隨報文主體作為響應返回（即在響應中只返回首部， 不會返回實體的主體部分） 贱勃。

[圖片上傳中...(image-97512-1586849894853-84)]

• 204 No Content : 該狀態(tài)碼代表服務器接收的請求已成功處理井赌， 但在返回的響應報文中不含實體的主體部分。另外贵扰， 也不允許返回任何實體的主體仇穗。 比如，當從瀏覽器發(fā)出請求處理后戚绕， 返回 204 響應纹坐， 那么瀏覽器顯示的頁面不發(fā)生更新。一般在只需要從客戶端往服務器發(fā)送信息舞丛， 而對客戶端不需要發(fā)送新信息內容的情況下使用耘子。

[圖片上傳中...(image-3b62db-1586849894853-83)]

• 206 Partial Content : 該狀態(tài)碼表示客戶端進行了范圍請求， 而服務器成功執(zhí)行了這部分的 GET 請求谷誓。 響應報文中包含由 Content-Range 指定范圍的實體內容。

[圖片上傳中...(image-858c79-1586849894853-82)]

3XX 重定向韧献，表明瀏覽器需要執(zhí)行某些特殊的處理以正確處理請求渊啰。

• 301 Moved Permanently : 永久性重定向。 該狀態(tài)碼表示請求的資源已被分配了新的 URI队询， 以后 應使用資源現在所指的 URI。 也就是說晒奕， 如果已經把資源對應的 URI 保存為書簽了坑律， 這時應該按 Location 首部字段提示的 URI 重新保存。像下方給出的請求 URI坤次， 當指定資源路徑的最后忘記添加斜杠“/”骚露， 就會產生 301 狀態(tài)碼育瓜。

[圖片上傳中...(image-64f6d4-1586849894853-81)]

• 302 Found : 臨時性重定向栽烂。 該狀態(tài)碼表示請求的資源已被分配了新的 URI躏仇， 希望用戶（本次） 能使用新的 URI 訪問恋脚。和 301 Moved Permanently 狀態(tài)碼相似， 但 302 狀態(tài)碼代表的資源不是被永久移動焰手，只是臨時性質的糟描。 換句話說， 已移動的資源對應的 URI 將來還有可能發(fā)生改變书妻。 比如船响， 用戶把 URI 保存成書簽， 但不會像 301 狀態(tài)碼出現時那樣去更新書簽躲履， 而是仍舊保留返回 302 狀態(tài)碼的頁面對應的 URI见间。

[圖片上傳中...(image-a31a89-1586849894853-80)]

• 303 See Other : 該狀態(tài)碼表示由于請求對應的資源存在著另一個 URI， 應使用 GET 方法定向獲取請求的資源工猜。303 狀態(tài)碼和 302 Found 狀態(tài)碼有著相同的功能缤剧， 但 303 狀態(tài)碼明確表示客戶端應當采用 GET 方法獲取資源， 這點與 302 狀態(tài)碼有區(qū)別域慷。比如荒辕， 當使用 POST 方法訪問 CGI 程序， 其執(zhí)行后的處理結果是希望客戶端能以 GET 方法重定向到另一個 URI 上去時， 返回 303 狀態(tài)碼。 雖然 302 Found 狀態(tài)碼也可以實現相同的功能丑孩， 但這里使用 303 狀態(tài)碼是最理想的。

當 301李皇、 302、 303 響應狀態(tài)碼返回時宙枷， 幾乎所有的瀏覽器都會把 POST 改成 GET掉房， 并刪除請求報文內的主體， 之后請求會自動再次發(fā)送慰丛。301卓囚、 302 標準是禁止將 POST 方法改變成 GET 方法的， 但實際使用時大家都會這么做诅病。

[圖片上傳中...(image-133596-1586849894853-79)]

• 304 Not Modified : 該狀態(tài)碼表示客戶端發(fā)送附帶條件（附帶條件的請求是指采用 GET方法的請求報文中包含 If-Match哪亿， If-ModifiedSince， If-None-Match贤笆， If-Range蝇棉， If-Unmodified-Since 中任一首部。）的請求時芥永， 服務器端允許請求訪問資源篡殷， 但未滿足條件的情況。 304 狀態(tài)碼返回時埋涧， 不包含任何響應的主體部分板辽。 304 雖然被劃分在 3XX 類別中奇瘦， 但是和重定向沒有關 系。

[圖片上傳中...(image-8345ee-1586849894853-78)]

• 307 Temporary Redirect ： 臨時重定向戳气。 該狀態(tài)碼與 302 Found 有著相同的含義。 盡管 302 標準禁止 POST 變換成 GET巧鸭， 但實際使用時大家并不遵守瓶您。307 會遵照瀏覽器標準， 不會從 POST 變成 GET纲仍。 但是呀袱， 對于處理響應時的行為， 每種瀏覽器有可能出現不同的情況郑叠。

4XX 客戶端錯誤夜赵，表明客戶端是發(fā)生錯誤的原因所在。

• 400 Bad Request : 該狀態(tài)碼表示請求報文中存在語法錯誤乡革。 當錯誤發(fā)生時寇僧， 需修改請求的內容后再次發(fā)送請求。 另外沸版， 瀏覽器會像 200 OK 一樣對待該狀態(tài)碼嘁傀。

[圖片上傳中...(image-1cd50f-1586849894852-77)]

• 401 Unauthorized : 該狀態(tài)碼表示發(fā)送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證） 的認證信息视粮。 另外若之前已進行過 1 次請求细办， 則表示用戶認證失敗。返回含有 401 的響應必須包含一個適用于被請求資源的 WWW-Authenticate 首部用以質詢（challenge） 用戶信息蕾殴。 當瀏覽器初次接收到 401 響應笑撞， 會彈出認證用的對話窗口。

[圖片上傳中...(image-a91f9-1586849894852-76)]

• 403 Forbidden : 該狀態(tài)碼表明對請求資源的訪問被服務器拒絕了钓觉。 服務器端沒有必要給出拒絕的詳細理由茴肥， 但如果想作說明的話， 可以在實體的主體部分對原因進行描述荡灾， 這樣就能讓用戶看到了炉爆。例如，未獲得文件系統(tǒng)的訪問授權卧晓，訪問權限出現某些問題（從未授權的發(fā)送源 IP 地址試圖訪問） 等情況芬首。

[圖片上傳中...(image-b2aa7-1586849894852-75)]

• 404 Not Found ： 該狀態(tài)碼表明服務器上無法找到請求的資源。 除此之外逼裆， 也可以在服務器端拒絕請求且不想說明理由時使用郁稍。

[圖片上傳中...(image-19d6f6-1586849894852-74)]

5XX 服務器錯誤 ： 表明服務器本身發(fā)生錯誤。

• 500 Internal Server Error ： 該狀態(tài)碼表明服務器端在執(zhí)行請求時發(fā)生了錯誤胜宇。 也有可能是 Web 應用存在的 bug 或某些臨時的故障耀怜。

[圖片上傳中...(image-8e3b7-1586849894852-73)]

• 503 Service Unavailable ： 該狀態(tài)碼表明服務器暫時處于超負載或正在進行停機維護恢着， 現在無法處理請求。 如果事先得知解除以上狀況需要的時間财破， 最好寫入 RetryAfter 首部字段再返回給客戶端掰派。

[圖片上傳中...(image-ce1f80-1586849894852-72)]

狀態(tài)碼和狀況的不一致，不少返回的狀態(tài)碼響應都是錯誤的左痢， 但是用戶可能察覺不到這點靡羡。比如 Web 應用程序內部發(fā)生錯誤， 狀態(tài)碼依然返回 200 OK俊性， 這種情況也經常遇到略步。

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

• 一臺 Web 服務器可搭建多個獨立域名的 Web 網站定页， 也可作為通信路徑上的中轉服務器提升傳輸效率趟薄。

用單臺虛擬主機實現多個域名。

• HTTP/1.1 規(guī)范允許一臺 HTTP 服務器搭建多個 Web 站點典徊。 比如杭煎， 提供 Web 托管服務（Web Hosting Service） 的供應商， 可以用一臺服務器為多位客戶服務卒落， 也可以以每位客戶持有的域名運行各自不同的網站岔帽。 這是因為利用了虛擬主機（Virtual Host， 又稱虛擬服務器） 的功能导绷。即使物理層面只有一臺服務器犀勒， 但只要使用虛擬主機的功能， 則可以假想已具有多臺服務器妥曲。

[圖片上傳中...(image-3cf8c3-1586849894852-71)]

• 客戶端使用 HTTP 協(xié)議訪問服務器時贾费， 會經常采用類似 www.hackr.jp 這樣的主機名和域名。在互聯(lián)網上檐盟， 域名通過 DNS 服務映射到 IP 地址（域名解析） 之后訪問目標網站褂萧。 可見， 當請求發(fā)送到服務器時葵萎， 已經是以 IP 地址形式訪問了导犹。所以， 如果一臺服務器內托管了 www.tricorder.jp 和 www.hackr.jp 這兩個域名羡忘， 當收到請求時就需要弄清楚究竟要訪問哪個域名谎痢。在相同的 IP 地址下， 由于虛擬主機可以寄存多個不同主機名和域名的 Web 網站卷雕， 因此在發(fā)送 HTTP 請求時节猿， 必須在 Host 首部內完整指定主機名或域名的 URI。

[圖片上傳中...(image-6a762a-1586849894852-70)]

通信數據轉發(fā)程序 ： 代理、 網關滨嘱、 隧道峰鄙。

• HTTP 通信時， 除客戶端和服務器以外太雨， 還有一些用于通信數據轉發(fā)的應用程序吟榴， 例如代理、 網關和隧道囊扳。 它們可以配合服務器工作吩翻。這些應用程序和服務器可以將請求轉發(fā)給通信線路上的下一站服務器， 并且能接收從那臺服務器發(fā)送的響應再轉發(fā)給客戶端宪拥。

• 代理 ： 代理是一種有轉發(fā)功能的應用程序仿野， 它扮演了位于服務器和客戶端“中間人”的角色铣减， 接收由客戶端發(fā)送的請求并轉發(fā)給服務器她君， 同時也接收服務器返回的響應并轉發(fā)給客戶端。

[圖片上傳中...(image-63aa78-1586849894852-69)]

• 代理服務器的基本行為就是接收客戶端發(fā)送的請求后轉發(fā)給其他服務器葫哗。 代理不改變請求 URI缔刹， 會直接發(fā)送給前方持有資源的目標服務器。持有資源實體的服務器被稱為源服務器劣针。 從源服務器返回的響應經過代理服務器后再傳給客戶端校镐。

[圖片上傳中...(image-8f0389-1586849894852-68)]

• 每次通過代理服務器轉發(fā)請求或響應時， 會追加寫入 Via 首部信息捺典。在 HTTP 通信過程中鸟廓， 可級聯(lián)多臺代理服務器。請求和響應的轉發(fā)會經過數臺類似鎖鏈一樣連接起來的代理服務器襟己。 轉發(fā)時引谜， 需要附加 Via 首部字段以標記出經過的主機信息。

[圖片上傳中...(image-9a19d2-1586849894852-67)]

• 使用代理服務器的理由有： 利用緩存技術（稍后講解） 減少網絡帶寬的流量擎浴， 組織內部針對特定網站的訪問控制员咽， 以獲取訪問日志為主要目的。代理有多種使用方法贮预， 按兩種基準分類贝室。 一種是是否使用緩存， 另一種是是否會修改報文:

• 緩存代理 : 代理轉發(fā)響應時仿吞， 緩存代理（Caching Proxy） 會預先將資源的副本（緩存） 保存在代理服務器上滑频。當代理再次接收到對相同資源的請求時， 就可以不從源服務器那里獲取資源唤冈， 而是將之前緩存的資源作為響應返回误趴。

• 透明代理 : 轉發(fā)請求或響應時， 不對報文做任何加工的代理類型被稱為透明代理（Transparent Proxy） 务傲。 反之凉当， 對報文內容進行加工的代理被稱為非透明代理枣申。

• 網關 ： 網關是轉發(fā)其他服務器通信數據的服務器， 接收從客戶端發(fā)送來的請求時看杭， 它就像自己擁有資源的源服務器一樣對請求進行處理忠藤。 有時客戶端可能都不會察覺， 自己的通信目標是一個網關楼雹。

[圖片上傳中...(image-a7907-1586849894852-66)]

• 利用網關可以由 HTTP 請求轉化為其他協(xié)議通信網關的工作機制和代理十分相似模孩。 而網關能使通信線路上的服務器提供非 HTTP 協(xié)議服務。利用網關能提高通信的安全性贮缅， 因為可以在客戶端與網關之間的通信線路上加密以確保連接的安全榨咐。 比如， 網關可以連接數據庫谴供， 使用 SQL 語句查詢數據块茁。 另外， 在 Web 購物網站上進行信用卡結算時桂肌，網關可以和信用卡結算系統(tǒng)聯(lián)動数焊。

• 隧道 ： 隧道是在相隔甚遠的客戶端和服務器兩者之間進行中轉， 并保持雙方通信連接的應用程序崎场。

[圖片上傳中...(image-15eb5c-1586849894852-65)]

• 隧道可按要求建立起一條與其他服務器的通信線路佩耳， 屆時使用 SSL 等加密手段進行通信。 隧道的目的是確碧房纾客戶端能與服務器進行安全的通信干厚。隧道本身不會去解析 HTTP 請求。 也就是說螃宙， 請求保持原樣中轉給之后的服務器蛮瞄。 隧道會在通信雙方斷開連接時結束。通過隧道的傳輸污呼， 可以和遠距離的服務器安全通信裕坊。 隧道本身是透明的， 客戶端不用在意隧道的存在燕酷。

保存資源的緩存籍凝。

[圖片上傳中...(image-731a15-1586849894852-64)]

• 緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。 利用緩存可減少對源服務器的訪問苗缩， 因此也就節(jié)省了通信流量和通信時間饵蒂。緩存服務器是代理服務器的一種， 并歸類在緩存代理類型中酱讶。 換句話說退盯， 當代理轉發(fā)從服務器返回的響應時， 代理服務器將會保存一份資源的副本。緩存服務器的優(yōu)勢在于利用緩存可避免多次從源服務器轉發(fā)資源渊迁。 因此客戶端可就近從緩存服務器上獲取資源慰照， 而源服務器也不必多次處理相同的請求了。

• 即便緩存服務器內有緩存琉朽， 也不能保證每次都會返回對同資源的請求毒租。 因為這關系到被緩存資源的有效性問題。當遇上源服務器上的資源更新時箱叁， 如果還是使用不變的緩存墅垮， 那就會演變成返回更新前的“舊”資源了。即使存在緩存耕漱， 也會因為客戶端的要求算色、 緩存的有效期等因素， 向源服務器確認資源的有效性螟够。 若判斷緩存失效灾梦， 緩存服務器將會再次從源服務器上獲取“新”資源。

[圖片上傳中...(image-dc991e-1586849894852-63)]

• 緩存不僅可以存在于緩存服務器內齐鲤， 還可以存在客戶端瀏覽器中斥废。 以 Internet Explorer 程序為例椒楣， 把客戶端緩存稱為臨時網絡文件（Temporary Internet File） 给郊。瀏覽器緩存如果有效， 就不必再向服務器請求相同的資源了捧灰， 可以直接從本地磁盤內讀取淆九。另外， 和緩存服務器相同的一點是毛俏， 當判定緩存過期后炭庙， 會向源服務器確認資源的有效性。 若判斷瀏覽器緩存失效煌寇， 瀏覽器會再次請求新資源焕蹄。

[圖片上傳中...(image-c70982-1586849894852-62)]

HTTP 首部。

• HTTP 協(xié)議的請求和響應報文中必定包含 HTTP 首部阀溶， 只是我們平時在使用 Web 的過程中感受不到它腻脏。

HTTP 報文首部。

[圖片上傳中...(image-3c06a3-1586849894852-61)]

• HTTP 協(xié)議的請求和響應報文中必定包含 HTTP 首部银锻。 首部內容為客戶端和服務器分別處理請求和響應提供所需要的信息永品。 對于客戶端用戶來說， 這些信息中的大部分內容都無須親自查看击纬。報文首部由幾個字段構成：

[圖片上傳中...(image-5c3983-1586849894852-60)]

• HTTP 響應報文 ： 在響應中鼎姐， HTTP 報文由 HTTP 版本、 狀態(tài)碼（數字和原因短語） 、HTTP 首部字段 3 部分構成炕桨。

• HTTP 請求報文 ： 在請求中饭尝， HTTP 報文由方法、 URI献宫、 HTTP 版本芋肠、 HTTP 首部字段等部分構成。

• 在報文眾多的字段當中遵蚜， HTTP 首部字段包含的信息最為豐富帖池。 首部字段同時存在于請求和響應報文內， 并涵蓋 HTTP 報文相關的內容信息吭净。

HTTP 首部字段睡汹。

• HTTP 首部字段傳遞重要信息 ： HTTP 首部字段是構成 HTTP 報文的要素之一。 在客戶端與服務器之間以 HTTP 協(xié)議進行通信的過程中寂殉， 無論是請求還是響應都會使用首部字段囚巴， 它能起到傳遞額外重要信息的作用。使用首部字段是為了給瀏覽器和服務器提供報文主體大小友扰、 所使用的語言彤叉、 認證信息等內容。

[圖片上傳中...(image-61c698-1586849894852-59)]

• HTTP 首部字段結構 ： HTTP 首部字段是由首部字段名和字段值構成的村怪， 中間用冒號 “:” 分隔秽浇。

[圖片上傳中...(image-df44ec-1586849894852-58)]

• 例如， 在 HTTP 首部中以 Content-Type 這個字段來表示報文主體的對象類型甚负。

[圖片上傳中...(image-79d54f-1586849894852-57)]

• 就以上述示例來看柬焕， 首部字段名為 Content-Type， 字符串 text/html 是字段值梭域。另外斑举， 字段值對應單個 HTTP 首部字段可以有多個值， 如下所示病涨。

[圖片上傳中...(image-85ffab-1586849894851-56)]

當 HTTP 報文首部中出現了兩個或兩個以上具有相同首部字段名時會怎么樣富玷？ 這種情況在規(guī)范內尚未明確， 根據瀏覽器內部處理邏輯的不同既穆， 結果可能并不一致赎懦。 有些瀏覽器會優(yōu)先處理第一次出現的首部字段， 而有些則會優(yōu)先處理最后出現的首部字段循衰。

4 種 HTTP 首部字段類型铲敛。

• 通用首部字段（General Header Fields） ： 請求報文和響應報文兩方都會使用的首部。

• 請求首部字段（Request Header Fields） ： 從客戶端向服務器端發(fā)送請求報文時使用的首部会钝。 補充了請求的附加內容伐蒋、 客戶端信息工三、 響應內容相關優(yōu)先級等信息。

• 響應首部字段（Response Header Fields） ： 從服務器端向客戶端返回響應報文時使用的首部先鱼。 補充了響應的附加內容俭正， 也會要求客戶端附加額外的內容信息。

• 實體首部字段（Entity Header Fields） ： 針對請求報文和響應報文的實體部分使用的首部焙畔。 補充了資源內容更新時間等與實體有關的信息掸读。

HTTP/1.1 47 種首部字段一覽。

• 通用首部字段:

[圖片上傳中...(image-3959bb-1586849894851-55)]

• 請求首部字段:

[圖片上傳中...(image-ced821-1586849894851-54)]

• 響應首部字段:

[圖片上傳中...(image-3db536-1586849894851-53)]

• 實體首部字段:

[圖片上傳中...(image-30a622-1586849894851-52)]

非 HTTP/1.1 首部字段宏多。

• 在 HTTP 協(xié)議通信交互中使用到的首部字段儿惫， 不限于 RFC2616 中定義的 47 種首部字段。 還有 Cookie伸但、 Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段肾请， 它們的使用頻率也很高。

End-to-end 首部和 Hop-by-hop 首部更胖。

• HTTP 首部字段將定義成緩存代理和非緩存代理的行為铛铁， 分成 2 種類型。

• 端到端首部（End-to-end Header） ： 分在此類別中的首部會轉發(fā)給請求 / 響應對應的最終接收目標却妨， 且必 須保存在由緩存生成的響應中饵逐， 另外規(guī)定它必須被轉發(fā)。

• 逐跳首部（Hop-by-hop Header） ： 分在此類別中的首部只對單次轉發(fā)有效彪标， 會因通過緩存或代理而不再轉發(fā)倍权。 HTTP/1.1 和之后版本中， 如果要使用 hop-by-hop 首部捐下， 需提供 Connection 首部字段账锹。下面列舉了 HTTP/1.1 中的逐跳首部字段萌业。 除這 8 個首部字段之外坷襟，其他所有字段都屬于端到端首部：

• Connection

• Keep-Alive

• Proxy-Authenticate

• Proxy-Authorization

• Trailer

• TE

• Transfer-Encoding

• Upgrade

HTTP/1.1 通用首部字段。

• 通用首部字段是指生年， 請求報文和響應報文雙方都會使用的首部婴程。

Cache-Control。

• 通過指定首部字段 Cache-Control 的指令抱婉， 就能操作緩存的工作機制档叔。

[圖片上傳中...(image-144f2f-1586849894851-51)]

• 首部字段 Cache-Control 能夠控制緩存的行為指令的參數是可選的， 多個指令之間通過“,”分隔蒸绩。 首部字段 CacheControl 的指令可用于請求及響應時衙四。

[圖片上傳中...(image-7c7557-1586849894851-50)]

• Cache-Control 可用的指令按請求和響應分類如下所示：

[圖片上傳中...(image-a05113-1586849894851-49)]

[圖片上傳中...(image-2afe45-1586849894851-48)]

• 表示是否能緩存的指令 ：

• public 指令 ：當指定使用 public 指令時， 則明確表明其他用戶也可利用緩存患亿。

• private 指令 : 當指定 private 指令后传蹈， 響應只以特定的用戶作為對象押逼， 這與 public 指令的行為相反。緩存服務器會對該特定用戶提供資源緩存的服務惦界， 對于其他用戶發(fā)送過來的請求挑格， 代理服務器則不會返回緩存。

• no-cache 指令 ： 使用 no-cache 指令的目的是為了防止從緩存中返回過期的資源沾歪∑客戶端發(fā)送的請求中如果包含 no-cache 指令， 則表示客戶端將不會接收緩存過的響應灾搏。 于是挫望， “中間” 的緩存服務器必須把客戶端請求轉發(fā)給源服務器。如果服務器返回的響應中包含 no-cache 指令狂窑， 那么緩存服務器不能對資源進行緩存士骤。 源服務器以后也將不再對緩存服務器請求中提出的資源有效性進行確認， 且禁止其對響應資源進行緩存操作蕾域。由服務器返回的響應中拷肌， 若報文首部字段 Cache-Control 中對 no-cache 字段名具體指定參數值， 那么客戶端在接收到這個被指定參數值的首部字段對應的響應報文后旨巷， 就不能使用緩存巨缘。 換言之， 無參數值的首部字段可以使用緩存采呐。 只能在響應指令中指定該參數若锁。

[圖片上傳中...(image-17b57a-1586849894849-47)]

[圖片上傳中...(image-d1c96d-1586849894849-46)]

[圖片上傳中...(image-35a3ae-1586849894849-45)]

• 控制可執(zhí)行緩存的對象的指令 ：

• no-store 指令 ： 當使用 no-store 指令時， 暗示請求（和對應的響應） 或響應中包含機密信息斧吐。因此又固， 該指令規(guī)定緩存不能在本地存儲請求或響應的任一部分。

• s-maxage 指令 ： s-maxage 指令的功能和 max-age 指令的相同煤率， 它們的不同點是 s-maxage 指令只適用于供多位用戶使用的公共緩存服務器仰冠。 也就是說， 對于向同一用戶重復返回響應的服務器來說蝶糯， 這個指令沒有任何作用洋只。另外说庭， 當使用 s-maxage 指令后纸泄， 則直接忽略對 Expires 首部字段及 max-age 指令的處理。

• max-age 指令 ： 當客戶端發(fā)送的請求中包含 max-age 指令時误算， 如果判定緩存資源的緩存時間數值比指定時間的數值更小妒茬， 那么客戶端就接收緩存的資源担锤。另外， 當指定 max-age 值為0乍钻， 那么緩存服務器通常需要將請求轉發(fā)給源服務器肛循。當服務器返回的響應中包含 max-age 指令時蛛株， 緩存服務器將不對資源的有效性再作確認， 而 max-age 數值代表資源保存為緩存的最長時間育拨。應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的情況時谨履， 會優(yōu)先處理 max-age 指令， 而忽略掉 Expires 首部字段熬丧。 而 HTTP/1.0 版本的緩存服務器的情況卻相反笋粟， max-age指令會被忽略掉。

[圖片上傳中...(image-c91a08-1586849894849-44)]

• 從字面意思上很容易把 no-cache 誤解成為不緩存析蝴， 但事實上 no-cache 代表不緩存過期的資源害捕， 緩存會向源服務器進行有效期確認后處理資源， 也許稱為 do-notserve-from-cache-without-revalidation 更合適闷畸。 no-store 才是真正地不進行緩存

[圖片上傳中...(image-1069b0-1586849894849-43)]

[圖片上傳中...(image-b8c2c5-1586849894849-42)]

[圖片上傳中...(image-fcae2f-1586849894849-41)]

• min-fresh 指令 ： min-fresh 指令要求緩存服務器返回至少還未過指定時間的緩存資源尝盼。比如， 當指定 min-fresh 為 60 秒后佑菩， 過了 60 秒的資源都無法作為響應返回了盾沫。

• max-stale 指令 : 使用 max-stale 可指示緩存資源， 即使過期也照常接收殿漠。如果指令未指定參數值赴精， 那么無論經過多久， 客戶端都會接收響應绞幌。如果指令中指定了具體數值蕾哟， 那么即使過期， 只要仍處于 max-stale 指定的時間內莲蜘， 仍舊會被客戶端接收谭确。

[圖片上傳中...(image-9f131a-1586849894849-40)]

• only-if-cached 指令 ： 使用 only-if-cached 指令表示客戶端僅在緩存服務器本地緩存目標資源的情況下才會要求其返回。 換言之票渠， 該指令要求緩存服務器不重新加載響應逐哈， 也不會再次確認資源有效性。 若發(fā)生請求緩存服務器的本地緩存無響應庄新， 則返回狀態(tài)碼 504 Gateway Timeout鞠眉。

• must-revalidate 指令 ： 使用 must-revalidate 指令， 代理會向源服務器再次驗證即將返回的響應緩存目前是否仍然有效择诈。若代理無法連通源服務器再次獲取有效資源的話， 緩存必須給客戶端一條 504（Gateway Timeout） 狀態(tài)碼出皇。另外羞芍， 使用 must-revalidate 指令會忽略請求的max-stale 指令（即使已經在首部使用了 max-stale， 也不會再有效果）郊艘。

• proxy-revalidate 指令 : proxy-revalidate 指令要求所有的緩存服務器在接收到客戶端帶有該指令的請求返回響應之前荷科， 必須再次驗證緩存的有效性唯咬。

[圖片上傳中...(image-bfd88-1586849894849-39)]

[圖片上傳中...(image-e4f01e-1586849894849-38)]

[圖片上傳中...(image-ac67ef-1586849894849-37)]

[圖片上傳中...(image-4d9dd9-1586849894849-36)]

• no-transform 指令 : 使用 no-transform 指令規(guī)定無論是在請求還是響應中， 緩存都不能改變實體主體的媒體類型畏浆。這樣做可防止緩存或代理壓縮圖片等類似操作胆胰。

• Cache-Control 擴展。

• cache-extension token ： 通過 cache-extension 標記（token） 刻获， 可以擴展 Cache-Control 首部字段內的指令蜀涨。如鞋面的例子， Cache-Control 首部字段本身沒有 community 這個指令蝎毡。 借助 extension tokens 實現了該指令的添加厚柳。 如果緩存服務器不能理解 community這個新指令， 就會直接忽略沐兵。 因此别垮， extension tokens 僅對能理解它的緩存服務器來說是有意義的。

[圖片上傳中...(image-842379-1586849894849-35)]

Connection扎谎。

• Connection 首部字段具備如下兩個作用：

• 控制不再轉發(fā)給代理的首部字段碳想。

• 管理持久連接。

• 控制不再轉發(fā)給代理的首部字段 ： 在客戶端發(fā)送請求和服務器返回響應內毁靶， 使用 Connection 首部字段移袍， 可控制不再轉發(fā)給代理的首部字段（即 Hop-by-hop 首部）。

[圖片上傳中...(image-b432b2-1586849894849-34)]

• 管理持久連接 ： HTTP/1.1 版本的默認連接都是持久連接老充。 為此葡盗， 客戶端會在持久連接上連續(xù)發(fā)送請求。當服務器端想明確斷開連接時啡浊， 則指定 Connection 首部字段的值為 Close觅够。HTTP/1.1 之前的HTTP 版本的默認連接都是非持久連接。 為此巷嚣， 如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接喘先， 則需要指定 Connection 首部字段的值為 Keep-Alive。

[圖片上傳中...(image-e0a732-1586849894849-33)]

[圖片上傳中...(image-f3b4ce-1586849894849-32)]

Date廷粒。

• 首部字段 Date 表明創(chuàng)建 HTTP 報文的日期和時間窘拯。

[圖片上傳中...(image-b93a35-1586849894849-31)]

• HTTP/1.1 協(xié)議使用在 RFC1123 中規(guī)定的日期時間的格式， 如下示例：

[圖片上傳中...(image-e261c3-1586849894849-30)]

• 之前的 HTTP 協(xié)議版本中使用在 RFC850 中定義的格式坝茎， 如下所示：

[圖片上傳中...(image-5d250c-1586849894849-29)]

• 除此之外涤姊， 還有一種格式。 它與 C 標準庫內的 asctime() 函數的輸出格式一致：

[圖片上傳中...(image-9a051f-1586849894849-28)]

Pragma嗤放。

• Pragma 是 HTTP/1.1 之前版本的歷史遺留字段思喊， 僅作為與 HTTP/1.0 的向后兼容而定義。規(guī)范定義的形式唯一次酌， 如下所示：

[圖片上傳中...(image-82b8ba-1586849894849-27)]

• 該首部字段屬于通用首部字段恨课， 但只用在客戶端發(fā)送的請求中舆乔。 客戶端會要求所有的中間服務器不返回緩存的資源。

[圖片上傳中...(image-3a993c-1586849894849-26)]

• 所有的中間服務器如果都能以 HTTP/1.1 為基準剂公， 那直接采用 CacheControl: no-cache 指定緩存的處理方式是最為理想的希俩。 但要整體掌握全部中間服務器使用的 HTTP 協(xié)議版本卻是不現實的。 因此纲辽， 發(fā)送的請求會同時含有下面兩個首部字段颜武。

[圖片上傳中...(image-b2393d-1586849894849-25)]

Trailer。

[圖片上傳中...(image-2b9722-1586849894849-24)]

• 首部字段 Trailer 會事先說明在報文主體后記錄了哪些首部字段文兑。 該首部字段可應用在 HTTP/1.1 版本分塊傳輸編碼時盒刚。

[圖片上傳中...(image-b0e964-1586849894849-23)]

以上用例中， 指定首部字段 Trailer 的值為 Expires 绿贞， 在報文主體之后（分塊長度 0 之后） 出現了首部字段Expires 因块。

Transfer-Encoding。

[圖片上傳中...(image-36d1f2-1586849894849-22)]

• 首部字段 Transfer-Encoding 規(guī)定了傳輸報文主體時采用的編碼方式籍铁。HTTP/1.1的傳輸編碼方式僅對分塊傳輸編碼有效涡上。

[圖片上傳中...(image-2b22d0-1586849894849-21)]

以上用例中， 正如在首部字段 Transfer-Encoding 中指定的那樣拒名， 有效使用分塊傳輸編碼吩愧， 且分別被分成3312 字節(jié)和 914 字節(jié)大小的分塊數據。

Upgrade增显。

• 首部字段 Upgrade 用于檢測 HTTP 協(xié)議及其他協(xié)議是否可使用更高的版本進行通信雁佳， 其參數值可以用來指定一個完全不同的通信協(xié)議。

[圖片上傳中...(image-e9ba8c-1586849894849-20)]

• 上圖用例中同云， 首部字段 Upgrade 指定的值為 TLS/1.0糖权。 請注意此處兩個字段首部字段的對應關系，Connection 的值被指定為 Upgrade炸站。Upgrade 首部字段產生作用的 Upgrade 對象僅限于客戶端和鄰接服務器之間星澳。 因此， 使用首部字段 Upgrade 時旱易， 還需要額外指定 Connection:Upgrade禁偎。對于附有首部字段 Upgrade 的請求， 服務器可用 101 Switching Protocols 狀態(tài)碼作為響應返回阀坏。

Via如暖。

• 使用首部字段 Via 是為了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。報文經過代理或網關時全释， 會先在首部字段 Via 中附加該服務器的信息装处， 然后再進行轉發(fā)。 這個做法和 traceroute 及電子郵件的 Received 首部的工作機制很類似浸船。首部字段 Via 不僅用于追蹤報文的轉發(fā)妄迁， 還可避免請求回環(huán)的發(fā)生。所以必須在經過代理時附加該首部字段內容李命。

[圖片上傳中...(image-85d35e-1586849894849-19)]

• 上圖用例中登淘， 在經過代理服務器 A 時， Via 首部附加了“1.0 gw.hackr.jp (Squid/3.1)”這樣的字符串值封字。 行頭的 1.0 是指接收請求的服務器上應用的 HTTP協(xié)議版本黔州。 接下來經過代理服務器 B 時亦是如此， 在 Via 首部附加服務器信息阔籽， 也可增加 1 個新的 Via 首部寫入服務器信息流妻。Via 首部是為了追蹤傳輸路徑， 所以經常會和 TRACE 方法一起使用笆制。 比如绅这， 代理服務器接收到由 TRACE 方法發(fā)送過來的請求（其中 Max-Forwards: 0） 時， 代理服務器就不能再轉發(fā)該請求了在辆。 這種情況下证薇， 代理服務器會將自身的信息附加到 Via 首部后， 返回該請求的響應匆篓。

Warning浑度。

• HTTP/1.1 的 Warning 首部是從 HTTP/1.0 的響應首部（Retry-After） 演變過來的。 該首部通常會告知用戶一些與緩存相關的問題的警告鸦概。

[圖片上傳中...(image-b1894-1586849894849-18)]

• Warning 首部的格式如下箩张。 最后的日期時間部分可省略。

[圖片上傳中...(image-b06d94-1586849894849-17)]

• HTTP/1.1 中定義了 7 種警告窗市。 警告碼對應的警告內容僅推薦參考先慷。另外， 警告碼具備擴展性谨设， 今后有可能追加新的警告碼熟掂。

[圖片上傳中...(image-ab6c9d-1586849894849-16)]

響應首部字段。

[圖片上傳中...(image-660ce6-1586849894849-15)]

• 響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段扎拣，用于補充響應的附加信息赴肚、 服務器信息， 以及對客戶端的附加要求等信息二蓝。

Accept-Ranges誉券。

[圖片上傳中...(image-1ce88b-1586849894849-14)]

當不能處理范圍請求時， Accept-Ranges: none

[圖片上傳中...(image-7221cd-1586849894849-13)]

• 首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理范圍請求刊愚， 以指定獲取服務器端某個部分的資源踊跟。可指定的字段值有兩種商玫， 可處理范圍請求時指定其為 bytes箕憾， 反之則指定其為 none。

Age。

[圖片上傳中...(image-cefc6d-1586849894849-12)]

• 首部字段 Age 能告知客戶端蹂季， 源服務器在多久前創(chuàng)建了響應。 字段值的單位為秒隘谣。若創(chuàng)建該響應的服務器是緩存服務器逗概， Age 值是指緩存后的響應再次發(fā)起認證到認證完成的時間值弟晚。 代理創(chuàng)建響應時必須加上首部字段 Age忘衍。

ETag。

[圖片上傳中...(image-77429d-1586849894849-11)]

• 首部字段 ETag 能告知客戶端實體標識卿城。 它是一種可將資源以字符串形式做唯一性標識的方式枚钓。 服務器會為每份資源分配對應的 ETag 值。另外瑟押， 當資源更新時搀捷， ETag值也需要更新。 生成 ETag 值時多望， 并沒有統(tǒng)一的算法規(guī)則嫩舟， 而僅僅是由服務器來分配。

[圖片上傳中...(image-ee9f62-1586849894849-10)]

• 資源被緩存時怀偷， 就會被分配唯一性標識家厌。 例如， 當使用中文版的瀏覽器訪問http://www.google.com/ 時椎工， 就會返回中文版對應的資源饭于， 而使用英文版的瀏覽器訪問時， 則會返回英文版對應的資源维蒙。 兩者的 URI 是相同的掰吕， 所以僅憑 URI指定緩存的資源是相當困難的。 若在下載過程中出現連接中斷颅痊、 再連接的情況殖熟， 都會依照 ETag 值來指定資源。

• ETag 中有 強 ETag 值 和 弱 ETag 值 之分：

• 強 ETag 值 : 不論實體發(fā)生多么細微的變化都會改變其值斑响。

• 弱 ETag 值 : 弱 ETag 值 只用于提示資源是否相同菱属。 只有資源發(fā)生了根本改變， 產生差異時才會改變 ETag 值恋捆。 這時照皆， 會在字段值最開始處附加 W/。

[圖片上傳中...(image-908658-1586849894849-9)]

[圖片上傳中...(image-e8b346-1586849894849-8)]

Location沸停。

[圖片上傳中...(image-248894-1586849894849-7)]

• 使用首部字段 Location 可以將響應接收方引導至某個與請求 URI 位置不同的資源膜毁。基本上， 該字段會配合 3xx ： Redirection 的響應瘟滨， 提供重定向的 URI候醒。幾乎所有的瀏覽器在接收到包含首部字段Location 的響應后， 都會強制性地嘗試對已提示的重定向資源的訪問杂瘸。

Proxy-Authenticate倒淫。

[圖片上傳中...(image-49929-1586849894849-6)]

• 首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發(fā)送給客戶端。它與客戶端和服務器之間的 HTTP 訪問認證的行為相似败玉， 不同之處在于其認證行為是在客戶端與代理之間進行的敌土。 而客戶端與服務器之間進行認證時， 首部字段 WWW-Authorization 有著相同的作用运翼。

Retry-After返干。

[圖片上傳中...(image-133594-1586849894849-5)]

• 首部字段 Retry-After 告知客戶端應該在多久之后再次發(fā)送請求。 主要配合狀態(tài)碼 503 Service Unavailable 響應血淌， 或 3xx Redirect 響應一起使用矩欠。字段值可以指定為具體的日期時間（Wed, 04 Jul 2012 06： 34： 24 GMT 等格式） ， 也可以是創(chuàng)建響應后的秒數悠夯。

Server癌淮。

[圖片上傳中...(image-a71d35-1586849894849-4)]

• 首部字段 Server 告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。 不單單會標出服務器上的軟件應用名稱沦补， 還有可能包括版本號和安裝時啟用的可選項乳蓄。

[圖片上傳中...(image-d778db-1586849894849-3)]

Vary。

[圖片上傳中...(image-ef3835-1586849894849-2)]

當代理服務器接收到帶有 Vary 首部字段指定獲取資源的請求時策彤， 如果使用的 Accept-Language 字段的值相同栓袖， 那么就直接從緩存返回響應。 反之店诗， 則需要先從源服務器端獲取資源后才能作為響應返回

[圖片上傳中...(image-696df0-1586849894849-1)]

• 首部字段 Vary 可對緩存進行控制裹刮。 源服務器會向代理服務器傳達關于本地緩存使用方法的命令。從代理服務器接收到源服務器返回包含 Vary 指定項的響應之后庞瘸， 若再要進行緩存捧弃， 僅對請求中含有相同Vary 指定首部字段的請求返回緩存。 即使對相同資源發(fā)起請求擦囊， 但由于 Vary 指定的首部字段不相同违霞， 因此必須要從源服務器重新獲取資源。

WWW-Authenticate瞬场。

• 首部字段 WWW-Authenticate 用于 HTTP 訪問認證买鸽。 它會告知客戶端適用于訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest） 和帶參數提示的質詢（challenge） 。 狀態(tài)碼 401 Unauthorized 響應中贯被，肯定帶有首部字段 WWW-Authenticate眼五。

[圖片上傳中...(image-cd9381-1586849894848-0)]

realm 字段的字符串是為了辨別請求 URI 指定資源所受到的保護策略妆艘。