HTTP協議 - 重學計算機網絡系列(3)

前言

• 學習資料來源於《圖解HTTP》。
• 部份內容參考於： 前端基礎篇之HTTP協議
• 本篇文章性質爲筆記，總結。

Web及網絡基礎

WWW

1989年3月,HTTP誕生了。

CERN（歐洲核子研究組織）的蒂姆·伯納斯-李（TimBerners-Lee）博士提出了一種能讓遠隔兩地的研究者們共享知識的設想。

最初設想的基本理念是：藉助多文檔之間相互關聯造成的超文本（HyperText），連成可相互參閱的WWW（World Wide Web，萬維網）。
複製代碼

WWW這一名稱，是Web瀏覽器當年用來瀏覽超文本的客戶端應用程序時的名稱。如今則用來表示這一系列的集合，也可簡稱爲Web。

如今已提出了3項WWW構建技術，分別是：頁面的文本標記語言的HTML（HyperText Markup Language，超文本標記語言）；做爲文檔傳遞協議的HTTP；指定文檔所在地址的URL（Uniform Resource Locator，統一資源定位符）。
複製代碼

總結：WWW = Web = HTML + HTTP + URL。

HTTP

• HTTP/0.9 HTTP於1990年問世。那時的HTTP並無做爲正式的標準被創建。這時的HTTP其實含有HTTP/1.0以前版本的意思，所以被稱爲HTTP/0.9。

• HTTP/1.0 HTTP正式做爲標準被公佈是在1996年的5月，版本被命名爲HTTP/1.0，並記載於RFC1945。雖然說是初期標準，但該協議標準至今仍被普遍使用在服務器端。

• HTTP/1.1 1997年1月公佈的HTTP/1.1是目前主流的HTTP協議版本。當初的標準是RFC2068，以後發佈的修訂版RFC2616就是當前的最新版本。

HTTP/2.0 下一篇會講到。

網絡基礎TCP/IP

TCP/IP是互聯網相關的各種協議族的總稱。而不是單指TCP和IP兩個協議。

應用層

應用層決定了向用戶提供應用服務時通訊的活動。

傳輸層

傳輸層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。

在傳輸層有兩個性質不一樣的協議：TCP（Transmission Control Protocol，傳輸控制協議）和UDP（User Data Protocol，用戶數據報協議）。

網絡層

網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎樣的路徑（所謂的傳輸路線）到達對方計算機，並把數據包傳送給對方。

與對方計算機之間經過多臺計算機或網絡設備進行傳輸時，網絡層所起的做用就是在衆多的選項內選擇一條傳輸路線。

鏈路層

用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內。

與HTTP關係密切的協議：IP、TCP和DNS

負責傳輸的IP協議

IP協議位於網絡層。
TCP/IP協議族中的IP指的就是網際協議。
可能有人會把「IP」和「IP地址」搞混，「IP」實際上是一種協議的名稱。
複製代碼

IP協議的做用是把各類數據包傳送給對方。可是IP協議用什麼來肯定傳輸的數據包要發到誰手中在呢？要保證確實傳送到對方那裏，則須要知足各種條件。其中兩個重要的條件是IP地址和MAC地址（Media Access ControlAddress）。

IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。
IP地址能夠和MAC地址進行配對。IP地址可變換，但MAC地址基本上不會更改。
複製代碼

使用ARP協議憑藉MAC地址進行通訊

ARP是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。

確保可靠性的TCP協議

TCP位於傳輸層，提供可靠的字節流服務。

所謂的字節流服務是指，爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。而可靠的傳輸服務是指，可以把數據準確可靠地傳給對方。一言以蔽之，TCP協議爲了更容易傳送大數據才把數據分割，並且TCP協議可以確認數據最終是否送達到對方。

如何保證數據能到達目標？TCP協議採用了三次握手策略。

三次握手

用TCP協議把數據包送出去後，TCP不會對傳送後的狀況置之不理，它必定會向對方確認是否成功送達。握手過程當中使用了TCP的標誌（flag）——SYN（synchronize）和ACK（acknowledgement）。

發送端首先發送一個帶SYN標誌的數據包給對方。接收端收到後，回傳一個帶有SYN/ACK標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶ACK標誌的數據包，表明「握手」結束。

若在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

除了上述三次握手，TCP協議還有其餘各類手段來保證通訊的可靠性。

DNS域名解析

DNS在系列2已經講過就不在贅述。

各類協議關係一目瞭然

URL

絕對URL格式

• 協議方案名。 使用http：或https：等協議方案名獲取訪問資源時要指定協議類型。不區分字母大小寫，最後附一個冒號（:）。 也可以使用data：或javascript：這類指定數據或腳本程序的方案名。
• 登陸信息（認證） 指定用戶名和密碼做爲從服務器端獲取資源時必要的登陸信息（身份認證）。此項是可選項。
• 服務器地址 使用絕對URI必須指定待訪問的服務器地址。地址能夠是相似hackr.jp這種DNS可解析的名稱，或是192.168.1.1這類IPv4地址名，還能夠是[0:0:0:0:0:0:0:1]這樣用方括號括起來的IPv6地址名
• 查詢字符串 針對已指定的文件路徑內的資源，可使用查詢字符串傳入任意參數。此項可選。
• 片斷標識符 使用片斷標識符一般可標記出已獲取資源中的子資源（文檔內的某個位置）。但在RFC中並無明確規定其使用方法。該項也爲可選項。

簡單的HTTP基礎

請求報文和響應報文

HTTP協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。

請求報文是由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

在起始行開頭的HTTP/1.1表示服務器對應的HTTP版本。緊挨着的200 OK 表示請求的處理結果的狀態碼和緣由短語）。下一行顯示了建立響應的日期時間，是首部字段內的一個屬性。接着以一空行分隔，以後的內容稱爲資源實體的主體。

無狀態的HTTP

HTTP協議自身不對請求和響應之間的通訊狀態進行保存。也就是說在HTTP這個級別，協議對於發送過的請求或響應都不作持久化處理。

爲何要這樣作？

使用HTTP協議，每當有新的請求發送時，就會有對應的新響應產生。
協議自己並不保留以前一切的請求或響應報文的信息。
這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把HTTP協議設計成如此簡單的。
複製代碼

HTTP/1.1雖然是無狀態協議，但爲了實現指望的保持狀態功能，因而引入了Cookie技術。有了Cookie再用HTTP協議通訊，就能夠管理狀態了。

請求URI定位資源

HTTP協議使用URI定位互聯網上的資源。正是由於URI的特定功能，在互聯網上任意位置的資源都能訪問到。

客戶請求資源的時候，請求報文須要指定URL，有如下幾種方法。

• 完整請求。 GET http://hacker.jp/index/html HTTP/1.1
• 在HOST寫明網絡域名或IP地址。 GET /index.htm HTTP/1.1 HOST:hacker.jp
• 此以外，若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個*來代替請求URI。 OPTIONS * HTTP/1.1

告知服務器意圖的HTTP方法

• GET：獲取資源。
  GET方法用來請求訪問已被URI識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；若是是像CGI（CommonGateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。

• POST：傳輸實體內容。
  雖然用GET方法也能夠傳輸實體的主體，但通常不用GET方法進行傳輸，而是用POST方法。雖然說POST的功能與GET很類似，但POST的主要目的並非獲取響應的主體內容。

• PUT：傳輸文件 PUT方法用來傳輸文件。就像FTP協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求URI指定的位置。

可是，鑑於HTTP/1.1的PUT方法自身不帶驗證機制，任何人均可以上傳文件，存在安全性問題，所以通常的Web網站不使用該方法。

• HEAD: 獲取報文首部
  HEAD方法和GET方法同樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。

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

可是，HTTP/1.1的DELETE方法自己和PUT方法同樣不帶驗證機制，因此通常的Web網站也不使用DELETE方法。當配合Web應用程序的驗證機制，或遵照REST標準時仍是有可能會開放使用的。

• OPTIONS：詢問支持的方法
  OPTIONS方法用來查詢針對請求URI指定的資源支持的方法。
  響應報文會返回當前服務器所支持的方法：好比 Allow:GET,POST,HEAD,OPTIONS

• TRACE: 追蹤路徑
  發送請求時，在Max-Forwards首部字段中填入數值，每通過一個服務器端就將該數字減1，當數值恰好減到0時，就中止繼續傳輸，最後接收到請求的服務器端則返回狀態碼200 OK的響應。

客戶端經過TRACE方法能夠查詢發送出去的請求是怎樣被加工修改/篡改的。這是由於，請求想要鏈接到源目標服務器可能會經過代理中轉，TRACE方法就是用來確認鏈接過程當中發生的一系列操做。

可是，TRACE方法原本就不怎麼經常使用，再加上它容易引起XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會用到了。

• CONNECT：要求用隧道協議鏈接代理
  CONNECT方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用SSL（SecureSockets Layer，安全套接層）和TLS（Transport LayerSecurity，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

持久鏈接節省通訊量

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。以當年的通訊狀況來講，由於都是些容量很小的文本傳輸，因此即便這樣也沒有多大問題。可隨着HTTP的普及，文檔中包含大量圖片的狀況多了起來。好比，使用瀏覽器瀏覽一個包含多張圖片的HTML頁面時，在發送請求訪問HTML頁面資源的同時，也會請求該HTML頁面裏包含的其餘資源。所以，每次的請求都會形成無謂的TCP鏈接創建和斷開，增長通訊量的開銷。

爲解決上述TCP鏈接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接（也稱爲HTTP keep-alive）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使HTTP請求和響應可以更早地結束，這樣Web頁面的顯示速度也就相應提升了。

在HTTP/1.1中，全部的鏈接默認都是持久鏈接。HTTP/1.0 則不必定。

Cookie

HTTP是無狀態協議，它不對以前發生過的請求和響應的狀態進行管理。也就是說，沒法根據以前的狀態進行本次的請求處理。

Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態,用來讓服務端記住客戶端。

Cookie會根據從服務器端發送的響應報文內的一個叫作Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。 服務器端發現客戶端發送過來的Cookie後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

過程：

• 請求報文(首次請求)

GET /reader/ HTTP/1.1
HOST: hacker.jp
* 首部字段內沒有Cookie的相關信息
複製代碼

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

HTTP/1.1 200 OK
.....
server: Apache <Set-Cookie: sid=12313123121; path=/; .......>
複製代碼

• 請求報文(第二次請求)

GET /image/ HTTP/1.1
Host: hacker.jp
Cookie: sid=12313123121
這樣二次請求的時候，服務端經過cookie會記住上一次訪問的是誰
複製代碼

狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。藉助狀態碼，用戶能夠知道服務器端是正常處理了請求，仍是出現了錯誤。

只要遵照狀態碼類別的定義，即便改變RFC2616中定義的狀態碼，或服務器端自行建立狀態碼都沒問題。

僅記錄在RFC2616上的HTTP狀態碼就達40種，若再加上WebDAV和附加HTTP狀態碼等擴展，數量就達60餘種。別看種類繁多，實際上常用的大概只有14種。

2XX成功

• 200 OK
  表示從客戶端發來的請求在服務器端被正常處理了。
• 204 No Content
  表示請求處理成功，但沒有資源能夠返回。(響應報文中並無主體資源，或者並不容許返回任何資源)好比，當從瀏覽器發出請求處理後，返回204響應，那麼瀏覽器顯示的頁面不發生更新。

通常在只須要從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用。

• 206 Partial Content
  該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定範圍的實體內容。

3XX 重定向

3XX響應結果代表瀏覽器須要執行某些特殊的處理以正確處理請求。

• 301 永久性重定向。
  該狀態碼錶示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。也就是說，若是已經把資源對應的URI保存爲書籤了，這時應該按Location首部字段提示的URI從新保存。

• 302 臨時性重定向
  該狀態碼錶示請求的資源已被分配了新的URI，但願用戶（本次）能使用新的URI訪問。

和301 Moved Permanently狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的URI未來還有可能發生改變。好比，用戶把URI保存成書籤，但不會像301狀態碼出現時那樣去更新書籤，而是仍舊保留返回302狀態碼的頁面對應的URI。

• 303 See Other 該狀態碼錶示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。 303狀態碼和302 Found狀態碼有着相同的功能，但303狀態碼明確表示客戶端應當採用GET方法獲取資源，這點與302狀態碼有區別。

好比，當使用POST方法訪問CGI程序，其執行後的處理結果是但願客戶端能以GET方法重定向到另外一個URI上去時，返回303狀態碼。雖然302 Found狀態碼也能夠實現相同的功能，但這裏使用303狀態碼是最理想的。

• 304 Not Modified
  該狀態碼錶示客戶端發送附帶條件的請求時，服務器端容許請求訪問資源，但因發生請求未知足條件的狀況後，直接返回304 Not Modified。

304狀態碼返回時，不包含任何響應的主體部分。304雖然被劃分在3XX類別中，可是和重定向沒有關係。

附帶條件的請求是指採用GET方法的請求報文中包含if-Match,if-Modified-Since,if-None-Match,if-Range,if-Unmodified-Since中任一首部。

當30一、30二、303響應狀態碼返回時，幾乎全部的瀏覽器都會把POST改爲GET，並刪除請求報文內的主體，以後請求會自動再次發送。30一、302標準是禁止將POST方法改變成GET方法的，但實際使用時你們都會這麼作。

4XX 客戶端錯誤

4XX的響應結果代表客戶端是發生錯誤的緣由所在。

• 400 Bad Request
  狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像200 OK同樣對待該狀態碼。

• 401 Unauthorized
  該狀態碼錶示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。

  • 若第一次返回401，會彈出認證的對話框。
  • 第二次返回401，表示認證失敗。

• 403 Forbidden
  該狀態碼代表對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出拒絕的詳細理由，但若是想做說明的話，能夠在實體的主體部分對緣由進行描述，這樣就能讓用戶看到了。

未得到文件系統的訪問受權，訪問權限出現某些問題（從未受權的發送源IP地址試圖訪問）等列舉的狀況均可能是發生403的緣由。

• 404 Not Found 該狀態碼代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時使用。

5XX 服務器錯誤

5XX的響應結果代表服務器自己發生錯誤。

• 500 Internal Server Error
  該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。

• 503 Service Unavailable
  該狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入Retry-After首部字段再返回給客戶端。

很多返回的狀態碼響應都是錯誤的，可是用戶可能察覺不到這點。好比Web應用程序內部發生錯誤，狀態碼依然返回200 OK，這種狀況也常常遇到。

Web服務器

一臺Web服務器可搭建多個獨立域名的Web網站，也可做爲通訊路徑上的中轉度武器提高傳輸效率。

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

HTTP/1.1規範容許一臺HTTP服務器搭建多個Web站點。即一個服務器能夠爲每位客戶持有的域名運行各自不一樣的網站。這是由於利用了虛擬主機的功能。

即便物理層面只有一臺服務器，但只要使用虛擬主機的功能，則能夠假想已具備多臺服務器。

若www.baidu.com/ 和 www.cctv.com/同時部署在同一個服務器上，使用DNS解析域名後，二者的訪問IP地址會相同。

在相同的IP地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的Web網站，所以在發送HTTP請求時，必須在Host首部內完整指定主機名或域名的URI。

通訊數據轉發

HTTP通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序，例如代理、網關和隧道。它們能夠配合服務器工做。

這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器，而且能接收從那臺服務器發送的響應再轉發給客戶端。

代理

代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。代理不改變請求URI，會直接發送給前方持有資源的目標服務器。

持有資源實體的服務器被稱爲源服務器。從源服務器返回的響應通過代理服務器後再傳給客戶端。

爲何要使用代理？

• 利用緩存技術減小網絡帶寬的流量。
• 組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的

代理轉發響應時，緩存代理會預先將資源的副本（緩存）保存在代理服務器上。當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將以前緩存的資源做爲響應返回。

網關

網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非HTTP協議服務。

爲何要用網關？
利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。好比，網關能夠鏈接數據庫，使用SQL語句查詢數據。另外，在Web購物網站上進行信用卡結算時，網關能夠和信用卡結算系統聯動。

隧道

隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保客戶端能與服務器進行安全的通訊。

隧道自己不會去解析HTTP請求。也就是說，請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減小對源服務器的訪問，所以也就節省了通訊流量和通訊時間。

緩存服務器的優點在於利用緩存可避免屢次從源服務器轉發資源。所以客戶端可就近從緩存服務器上獲取資源，而源服務器也沒必要屢次處理相同的請求了。

緩存有效期

即使緩存服務器內有緩存，也不能保證每次都會返回對同資源的請求。由於這關係到被緩存資源的有效性問題。

當趕上源服務器上的資源更新時，若是仍是使用不變的緩存，那就會演變成返回更新前的「舊」資源了。

即便存在緩存，也會由於客戶端的要求、緩存的有效期等因素，向源服務器確認資源的有效性。若判斷緩存失效，緩存服務器將會再次從源服務器上獲取「新」資源。

客戶端的緩存

緩存不只能夠存在於緩存服務器內，還能夠存在客戶端瀏覽器中。

瀏覽器緩存若是有效，就沒必要再向服務器請求相同的資源了，能夠直接從本地磁盤內讀取。 好比在系列1中提到過，DNS解析的時候，當在瀏覽器輸入地址後，不會直接進行解析，會在本地緩存中對比是否有訪問對象的IP地址，有的話就不用DNS解析，直接就能夠拿到IP地址。

HTTP報文首部

請求報文首部組成
請求報文 = 報文首部 + 報文主體
報文首部 = (方法 + URI + HTTP版本) + (請求首部字段 + 通用首部字段 + 實體首部字段)

響應報文首部組成
響應報文 = 報文首部 + 主體
報文首部 = (HTTP版本 + 狀態碼) + (響應首部字段 + 通用首部字段 + 實體首部字段)

首部字段類型分類

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

首部字段概述

• 首部字段的做用：
  使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

• 首部字段的結構：
  HTTP首部字段是由首部字段名和字段值構成的，中間用冒號「:」分隔。

首部字段名： 字段值

例如表示報文主體的對象類型:
Content-Type: text/html
複製代碼

• 字段值對應單個HTTP首部字段能夠有多個值

Keep-Alive: timeout=15, max=100
複製代碼

若HTTP首部字段重複了會如何。 當HTTP報文首部中出現了兩個或兩個以上具備相同首部字段名時會怎麼樣？這種狀況在規範內還沒有明確，根據瀏覽器內部處理邏輯的不一樣，結果可能並不一致。有些瀏覽器會優先處理第一次出現的首部字段，而有些則會優先處理最後出現的首部字段。

請求首部字段

請求首部字段是從客戶端往服務器端發送請求報文中所使用的字段，用於補充請求的附加信息、客戶端信息、對響應內容相關的優先級等內容。

請求首部字段	說明
Accept	text/html,image/jpeg,video/mpeg,application/octet-stream客戶端能夠接收的媒體類型(文本文件，圖片文件，視頻文件，二進制文件)
Accept-Charset	iso-8859-5,unicode-1-1;q=0.8能正確接收的字符集
Accept-Encoding	客戶端能支持的內容編碼（可多個）:gzip,compress,deflate
Accept-Language	zh-cn,zh;q=0.7,en-us,en;q=0.3客戶端可以處理的語言
Authorization	認證信息。當出現401時將其添加到請求頭中即可認證
Expect	期待服務端的指定行爲
From	告知服務器使用用戶代理的用戶的電子郵件地址。(使用目的就是爲了顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式)
Host	(必須存在於請求頭中) 告知服務器，請求的資源所處的互聯網主機名和端口號（當一個服務器下部署着多個域名的時候需指定，否則分不清請求的是哪個域名）
If-Match	形如if-xxx的格式，稱爲條件請求。服務器接收到條件後，只有判斷指定條件爲真，纔會接受請求
If-Modified-Since	告知服務器若If-Modified-Since字段值早於資源的更新時間，則但願能處理該請求。而在指定If-Modified-Since字段值的日期時間以後，若是請求的資源都沒有過更新，則返回狀態碼304 Not Modified的響應。
If-None-Match	資源未修改返回 304(經過對比ETag)
If-Range	告知服務器若指定的If-Range字段值（ETag值或者時間）和請求資源的ETag值或時間相一致時，則做爲範圍請求處理。反之，則返回全體資源。
If-Unmodified-Since	首部字段If-Unmodified-Since和首部字段If-Modified-Since的做用相反。它的做用的是告知服務器，指定的請求資源只有在字段值內指定的日期時間以後，未發生更新的狀況下，才能處理請求。若是在指定日期時間後發生了更新，則以狀態碼412 Precondition Failed做爲響應返回。
Max-Forwards	限制可被代理及網關轉發的次數
Proxy-Authorization	向代理服務器發送驗證信息（這個行爲是與客戶端和服務器之間的HTTP訪問認證相相似的，不一樣之處在於，認證行爲發生在客戶端與代理之間。客戶端與服務器之間的認證，使用首部字段Authorization可起到相同做用。）
Range	bytes=5001-10000請求某個內容的一部分，配合If-Range使用
Referer	告知服務器請求的原始資源的URI。(客戶端通常都會發送Referer首部字段給服務器。但當直接在瀏覽器的地址欄輸入URI，或出於安全性的考慮時，也能夠不發送該首部字段。由於原始資源的URI中的查詢字符串可能含有ID和密碼等保密信息，要是寫進Referer轉發給其餘服務器，則有可能致使保密信息的泄露。)
TE	gzip,deflate;q=0.5.告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。它和首部字段Accept-Encoding的功能很相像，可是用於傳輸編碼。
User-Agent	將發起請求的瀏覽器和用戶代理名稱等信息**傳達給服務器。

響應首部字段

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

響應首部字段	說明
Accept-Ranges	告知客戶端本身可否處理範圍請求。能bytes，否none
Age	告知客戶端，源服務器在多久前建立了響應。 若建立該響應的服務器是緩存服務器，Age值是指緩存後的響應再次發起認證到認證完成的時間值。(資源在代理緩存中存在的時間)
ETag	資源標識，資源發生變化時標識也會發生改變
Location	使用首部字段Location能夠將響應接收方引導至某個與請求URI位置不一樣的資源。基本上，該字段會配合3xx:Redirection的響應，提供重定向的URI。幾乎全部的瀏覽器在接收到包含首部字段Location的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。
Proxy-Authenticate	把由代理服務器所要求的認證信息發送給客戶端。
Retry-After	告知客戶端應該在多久以後再次發送請求。主要配合狀態碼503 Service Unavailable響應
Server	Apache/2.2.6 (Unix) PHP/5.2.5告知客戶端當前服務器上安裝的HTTP服務器應用程序的信息。不僅僅會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啓用的可選項。
Vary	對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。
WWW-Authenticate	用於HTTP訪問認證。它會告知客戶端適用於訪問請求URI所指定資源的認證方案（Basic或是Digest）和帶參數提示的質詢（challenge）。狀態碼401 Unauthorized響應中，確定帶有首部字段WWW-Authenticate。

通用首部字段

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

通用首部字段	說明(請求報文和響應報文都會用到)
Cache-Control	表示是否能緩存的指令。public(客戶端、代理服務器均可利用緩存),no-cache(防止從緩存中返回過時的資源),no-store(暗示包含機密信息，不容許緩存)，s-maxage,max-age(資源可緩存最大時間 秒)
Connection	再也不轉發的首部字段名(控制再也不轉發給代理的首部字段),close(關閉持續鏈接),Keep-Alive(在HTTP/1.0上開啓持續鏈接，1.1默認持續鏈接因此不須要)
Data	代表建立HTTP報文的日期和時間
Pragma	no-cache(只用於請求報文，客戶端要求中間服務器不返回緩存的資源)
Trailer	事先說明在報文主體後記錄了哪些首部字段
Transfer-Encoding	chunked(規定了傳輸報文主體時採用的編碼方式。)
Upgrade	檢測HTTP協議及其餘協議是否可以使用更高的版本進行通訊
Via	追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。報文通過代理或網關時，會先在首部字段Via中附加該服務器的信息，而後再進行轉發。首部字段Via不只用於追蹤報文的轉發，還可避免請求迴環的發生。因此必須在通過代理時附加該首部字段內容。
Warning	告知用戶一些與緩存相關的問題的警告。

實體首部字段

實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

在請求和響應兩方的HTTP報文中都含有與實體相關的首部字段。

實體首部字段	說明
Allow	GET,HEAD。通知客戶端可以支持Request-URI指定資源的全部HTTP方法。當服務器接收到不支持的HTTP方法時，會以狀態碼405 Method Not Allowed做爲響應返回。與此同時，還會把全部能支持的HTTP方法寫入首部字段Allow後返回。
Content-Encoding	gzip,compress,deflate,identity。告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。
Content-Language	告知客戶端，實體主體使用的天然語言（指中文或英文等語言）
Content-Length	代表了實體主體部分的大小（單位是字節）
Content-Location	返回數據的備用地址
Content-MD5	首部字段Content-MD5是一串由MD5算法生成的值，其目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。
Content-Range	bytes 5001-10000/10000。告知客戶端做爲響應返回的實體的哪一個部分符合範圍請求。
Content-Type	application/json;charset=UTF-8。說明了實體主體內對象的媒體類型。
Expires	緩存服務器在接收到含有首部字段Expires的響應後，表示能夠緩存到指定日期，到達指定日期，緩存服務器會向源服務器請求更新資源；同時也會告知客戶端
Last-Modified	指明資源最終修改的時間

爲Cookie服務的首部字段

管理服務器與客戶端之間狀態的Cookie，雖然沒有被編入標準化HTTP/1.1的RFC2616中，但在Web網站方面獲得了普遍的應用。

Cookie的工做機制是用戶識別及狀態管理。Web網站爲了管理用戶的狀態會經過Web瀏覽器，把一些數據臨時寫入用戶的計算機內。接着當用戶訪問該Web網站時，可經過通訊方式取回以前存放的Cookie。

調用Cookie時，因爲可校驗Cookie的有效期，以及發送方的域、路徑、協議等信息，因此正規發佈的Cookie內的數據不會因來自其餘Web站點和攻擊者的攻擊而泄露。

爲Cookie服務的首部字段	說明
Set-Cookie	name:賦予Cookie的名稱和其值；expires:Cookie的有效期(若不指定則默認爲瀏覽關閉前爲止)；path:將服務器上的文件目錄做爲Cookie的適用對象；domain = 域名：做爲Cookie適用對象的域名；secure:僅在HTTPS安全通行時纔會發送Cookie;HttpOnly:加以限制，使Cookie不能被JavaScript腳本訪問
Cookie	Cookie: status=enable:首部字段Cookie會告知服務器，當客戶端想得到HTTP狀態管理支持時，就會在請求中包含從服務器接收到的Cookie。接收到多個Cookie時，一樣能夠以多個Cookie形式發送。

其餘首部字段

HTTP首部字段是能夠自行擴展的。因此在Web服務器和瀏覽器的應用上，會出現各類非標準的首部字段。

其餘首部字段	說明
X-Frame-Options	DENY(拒絕);SAMEORIGIN(僅同源域名下許可)：用於控制網站內容在其餘Web網站的Frame標籤內的顯示問題。其主要目的是爲了防止點擊劫持（clickjacking）攻擊。
X-XSS-Protection	0:將XSS過濾設置成無效狀態;1 ：將XSS過濾設置成有效狀態。它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器XSS防禦機制的開關。
DNT	0 ：贊成被追蹤; 1 ：拒絕被追蹤:DNT是Do NotTrack的簡稱，意爲拒絕我的信息被收集，是表示拒絕被精準廣告追蹤的一種方法。因爲首部字段DNT的功能具有有效性，因此Web服務器須要對DNT作對應的支持。
P3P	經過利用P3P（ThePlatform for Privacy Preferences，在線隱私偏好平臺）技術，可讓Web網站上的我的隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的目的。

要進行P3P的設定，需按如下操做步驟進行。
步驟1： 建立P3P隱私
步驟2： 建立P3P隱私對照文件後，保存命名在/w3c/p3p.xml
步驟3： 從P3P隱私中新建Compact policies後，輸出到HTTP響應中

下一篇講HTTPS，HTTP追加協議，WEB安全的知識點