為什麼要學HTTP？

我們絕大多數的Web應用都是基於HTTP來進行開發的。我們對Web的操作都是通過HTTP協議來進行傳輸數據的。

簡單來說，HTTP協議就是客戶端和伺服器交互的一種通迅的格式。

HTTP的誕生主要是為了能夠讓文檔之間相互關聯，形成超文本可以互相傳閱

可以說，Http就是Web通信的基礎，這是我們必學的。

HTTP基礎概念

我們學計算機網絡的時候就知道，我們把計算機網絡分層了5層，一般我們現在用的都是TCP/IP這麼一個分層結構。

雖然官方的是ISO 提出的7層結構，但是僅僅是理論基礎，在實際上大多人都是使用TCP/IP的分層結構

首先，我們先得知道，為什麼我們要在計算機網絡中分層次？？？

因為如果兩台計算機能夠相互通信的話，實際實現起來是非常困難操作的…我們分層的目的就是為了將困難的問題簡單化，並且如果我們分層了，我們在使用的時候就可以僅僅關注我們需要關注的層次，而不用理會其他層。

如果需要改動設計的時候，我們只需要把變動的層替換即可，並不用涉及到其他的層次。這與我們程序設計中的低耦合是一個概念。

而我們的HTTP協議是在最上層，也就是應用層。這是最貼近我們的程式設計師的層次。

網站通信粗略過程

我們知道HTTP是在應用層中的，顯然，我們在Web通信的過程中，不僅僅是需要HTTP協議的，還會涉及到其他的協議的。

DNS：負責解析域名

• 我們訪問一個網頁的時候，往往是通過域名來訪問的www.zhongfucheng.site,而計算機通信只認的是我們的主機地址(192.168.xxx.xxx)，因此，當我們輸入域名的時候，需要DNS把域名解析成主機來進行訪問。

HTTP：產生請求報文數據

• 當我們對Web頁面進行操作的時候，就會產生HTTP報文數據，請求對應的服務端進行響應。

這裡寫圖片描述

TCP協議：分割HTTP數據，保證數據運輸

• TCP協議採用了三次握手的方式來保證數據的準確運輸，在運輸的數據的時候，發送標識過去給伺服器，伺服器也返回標識給客戶端，而客戶端收到消息後再次返回標識給伺服器。這樣一來就保證了數據運輸是可靠的。

IP協議：傳輸數據包，找到通信目的地地址。

• IP協議把我們的產生的數據包發送給對方，IP位址指明了節點被分配的地址，但IP位址可能會變換，我們可以使用ARP協議來將IP位址反射為MAC地址。MAC地址是不會更改的，是網卡所屬的固定地址。
• 在找到通信目的地之前，我們是需要不斷的中轉的，這過程我們稱作為：「路由中轉」，我們並不知道路由中轉了多少次的。因此是不能全面了解到網際網路中的傳輸狀況的。

接下來就離我們比較遠了，屬於硬體相關的了，也就是鏈路層和物理層。以後複習到計算機網絡的時候再來補充吧！

我們網頁上請求數據就是上邊這麼一個流程。

告知伺服器請求的意圖

我們如果開發過Web程序的話，我們知道常用的提交方式有POST和GET方法

我們也知道GET是用來獲取數據的，POST是用來提交數據的。

其實HTTP協議中還支持著其他的方法，比如：Input、Delete、OPTIONS很多這樣的方法。而由於常用，於是我們也可能僅僅知道GET和POST方法了。

HTTP提供方法的目的就是為了告知伺服器該客戶端想進行什麼操作。當HTTP是OPTIONS方法的時候，伺服器端就會返回它支持什麼HTTP方法。

當然了，現在RESTful盛行，也就是充分利用了HTTP協議的這些方法。

HTTP是不保存狀態的協議

HTTP是無狀態的，也就是說，它是不對通信狀態進行保存的。它並不知道之前通信的對方是誰。這樣設計的目的就是為了讓HTTP簡單化，能夠快速處理大量的事務！

但是，我們經常是需要知道訪問的人是誰，於是就有了Cookie技術了。

• 要是伺服器端想要記住客戶端是誰，那麼就頒發一個cookie給客戶端
• 客戶端把Cookie保存在硬碟中，當下次訪問伺服器的時候，瀏覽器會自動把客戶端的cookie帶過去。
• 就這樣，伺服器就能夠知道這傢伙是誰了。

持久連接

在HTTP1.0的時候，每一次進行HTTP通信就會斷開一次連接。如果容量很少的文本傳輸是沒有問題的。但是如果我們訪問一個網頁，該網頁有非常多的圖片。一個圖片就算上一個HTTP請求了。那麼在中途中就不斷地建立TCP連接、獲取圖片、斷開TCP連接。

這樣是非常浪費資源的，因此在HTTP1.1版本，就是持久連接了。一次HTTP連接能夠處理多個請求。

持久連接為「管線化」方式發送成為了可能：在一次HTTP連接裡面，不需要等待伺服器響應請求，就能夠繼續發送第二次請求。

提升傳輸效率

在說明之前，首先我們要知道什麼是實體主體

• 實體主體就是作為數據在HTTP中傳輸的數據。

一般地，實體主體可以等價為報文主體，報文主體是HTTP中的一部分。

我們如果不使用任何手段，伺服器返回的數據實體主體是原樣返回的。我們可以使用兩種方式來提高傳輸效率

• 使用壓縮技術把實體主體壓小，在客戶端再把數據解析
• 使用分塊傳輸編碼，將實體主體分塊傳輸，當瀏覽器解析到實體主體就能夠顯示了。

我們如果在下載東西的過程中斷了，按照以前我們是需要重新下載的，但是現在可以在中斷中繼續下載。我們可以使用到獲取範圍數據，這種叫做範圍請求！

這種請求只會下載資源的一部分。

• 比如我的圖片下載到一半了，我們只需要下載另一半就可以組成一張完整的圖片了。那麼請求的時候請求沒有下載的一部分即可。

常用的狀態碼簡述

2XX

一般是請求成功

200 正常處理

204 成功處理，但伺服器沒有新數據返回，顯示頁面不更新

206 對伺服器進行範圍請求，只返回一部分數據

3XX

一般表示重定向

301 請求的資源已分配了新的URI中，URL地址改變了。【永久重定向】

302 請求的資源臨時分配了新的URI中，URL地址沒變【轉發】

303 與302相同的功能，但明確客戶端應該採用GET方式來獲取資源

304 發送了附帶請求，但不符合條件【返回未過期的緩存數據】

307 與302相同，但不會把POST請求變成GET

4XX

表示客戶端出錯了。

400 請求報文語法錯誤了

401 需要認證身份

403 沒有權限訪問

404 伺服器沒有這個資源

5XX

伺服器出錯了

500 內部資源出錯了

503 伺服器正忙

伺服器與客戶端之間的應用程式

首先要說的是，一個HTTP伺服器可以擁有多個站點，也就是說：HTTP下可以配置多個虛擬主機。當用戶訪問不同主機的時候，實際上都是訪問同一台HTTP伺服器。

在客戶端和伺服器中還有一些用於通信數據轉發的應用程式：

• 代理
• 可以用來緩存數據，當代理緩存了數據以後，客戶端就可以直接用代理獲取數據
• 可以用來對網站進行訪問控制，獲取訪問日誌記錄
• 網關
• 能夠提供非HTTP請求的操作，訪問資料庫什麼的
• 隧道
• 建立一條安全的通信路徑，可以使用SSL等加密手段進行通信。

HTTP首部簡述

HTTP請求報文

HTTP請求報文：在請求中，HTTP報文由方法、URI、HTTP版本、HTTP首部欄位等部分組成。

1. 請求行【描述客戶端的請求方式、請求的資源名稱，以及使用的HTTP協議版本號】
2. 首部欄位【描述客戶端請求哪台主機，以及客戶端的一些環境信息等】
3. 一個空行

首部欄位例子：

• Accept: text/html,image/* 【瀏覽器告訴伺服器，它支持的數據類型】
• Accept-Charset: ISO-8859-1 【瀏覽器告訴伺服器，它支持哪種字符集】
• Accept-Encoding: gzip,compress 【瀏覽器告訴伺服器，它支持的壓縮格式】
• Accept-Language: en-us,zh-cn 【瀏覽器告訴伺服器，它的語言環境】
• Host: www.it315.org:80【瀏覽器告訴伺服器，它的想訪問哪台主機】
• If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT【瀏覽器告訴伺服器，緩存數據的時間】
• Referer: http://www.it315.org/index.jsp【瀏覽器告訴伺服器，客戶機是從那個頁面來的---反盜鏈】
• 8.User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)【瀏覽器告訴伺服器，瀏覽器的內核是什麼】
• Cookie【瀏覽器告訴伺服器，帶來的Cookie是什麼】
• Connection: close/Keep-Alive 【瀏覽器告訴伺服器，請求完後是斷開連結還是保持連結】
• Date: Tue, 11 Jul 2000 18:23:51 GMT【瀏覽器告訴伺服器，請求的時間】

HTTP響應報文

HTTP響應報文：在響應中，HTTP報文由HTTP版本、狀態碼（數字和原因短語）、HTTP首部欄位3部分組成。

1. 一個狀態行【用於描述伺服器對請求的處理結果。】
2. 首部欄位【用於描述伺服器的基本信息，以及數據的描述，伺服器通過這些數據的描述信息，可以通知客戶端如何處理等一會兒它回送的數據】
3. 一個空行
4. 實體內容【伺服器向客戶端回送的數據】

狀態行：

• 格式： HTTP版本號　狀態碼　原因敘述
• 狀態行：HTTP/1.1 200 OK
• 狀態碼用於表示伺服器對請求的處理結果，它是一個三位的十進位數。響應狀態碼分為5類

首部欄位例子：

• Location: http://www.it315.org/index.jsp 【伺服器告訴瀏覽器要跳轉到哪個頁面】
• Server:apache tomcat【伺服器告訴瀏覽器，伺服器的型號是什麼】
• Content-Encoding: gzip 【伺服器告訴瀏覽器數據壓縮的格式】
• Content-Length: 80 【伺服器告訴瀏覽器回送數據的長度】
• Content-Language: zh-cn 【伺服器告訴瀏覽器，伺服器的語言環境】
• Content-Type: text/html; charset=GB2312 【伺服器告訴瀏覽器，回送數據的類型】
• Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT【伺服器告訴瀏覽器該資源上次更新時間】
• Refresh: 1;url=http://www.it315.org【伺服器告訴瀏覽器要定時刷新】
• Content-Disposition: attachment; filename=aaa.zip【伺服器告訴瀏覽器以下載方式打開數據】
• Transfer-Encoding: chunked 【伺服器告訴瀏覽器數據以分塊方式回送】
• Set-Cookie:SS=Q0=5Lb_nQ; path=/search【伺服器告訴瀏覽器要保存Cookie】
• Expires: -1【伺服器告訴瀏覽器不要設置緩存】
• Cache-Control: no-cache 【伺服器告訴瀏覽器不要設置緩存】
• Pragma: no-cache 【伺服器告訴瀏覽器不要設置緩存】
• Connection: close/Keep-Alive 【伺服器告訴瀏覽器連接方式】
• Date: Tue, 11 Jul 2000 18:23:51 GMT【伺服器告訴瀏覽器回送數據的時間】

對於HTTP首部這一部分是非常龐大的一個章節，知識點也很多，我就沒有一一去記錄了。用到的時候再查吧。我看的是《圖解HTTP》。

HTTPS簡述

HTTP在安全上是不足的

• 通信使用明文【沒有加密過內容的】
• 不驗證通信方身份，無論是客戶端和伺服器，都是隨意通信的
• 無法證明報文的完整性【別人監聽後，可以篡改】

我們一般在上網時，使用抓包工具就很容易獲取到HTTP請求的信息了，這是TCP/IP在網絡通信中無法避免的。

假設我們對HTTP報文進行加密了， 那也僅僅是是內容的加密。別人獲取到了HTTP內容了，即使無法破解HTTP內容，還是能夠篡改的。

我們最好就是使用SSL建立安全的通信線路，就可以在這條線路上進行HTTP通信了。

其實HTTPS就是披著SSL的HTTP…

HTTPS使用的是共享密鑰和公開私有密鑰混合來進行加密的。由於公開私有密鑰需要太多的資源，不可能一直以公開私有密鑰進行通信。因此，HTTP在建立通信線路的時候使用公開私有密鑰，當建立完連接後，隨後就使用共享密鑰進行加密和解密了

對於認證方面，HTTPS是基於第三方的認證機構來獲取認受認可的證書、因此，可以從中認證該伺服器是否是合法的。

而客戶端方面則需要自己購買認證證書、這實施起來難度是很大的【認證證書需要錢】。

所以，一般的網站都是使用表單認證就算了，這是用得最廣泛的客戶端認證了。

原文地址：https://dwz.cn/Y5JClvg9作者：Java3y