《圖解HTTP》之要點提煉

IP、TCP、DNS協議

負責傳輸的IP協議

IP協議的作用是把各種數據包傳送給對方。其中有兩個最重要的條件是IP地址與MAC地址。

IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址可以和MAC地址進行配對。ARP是一種解析地址的協議，根據通信方的IP地址可以反查處對應的MAC地址。

下圖爲路由選擇。

確保可靠性的TCP協議

TCP處於傳輸層，提供可靠的字節流服務。爲確保數據能到達目標，TCP協議採用了三次握手策略，同時還有確認應答，重傳超時，滑動窗口，流傳輸（窗口長度），快重傳（三次重傳），慢啓動，擁塞窗口（慢啓動閾值），普通恢復與快恢復，延遲應答，捎帶應答等多種機制來保證流量與防止擁塞等問題。

負責域名解析的DNS服務

DNS（Domain Name System）服務是和HTTP協議一樣位於應用層的協議，它提供域名到IP地址之間的解析。
用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過IP地址，但計算機需要IP地址，就由DNS協議提供該服務。

整個流程中各個協議的作用：
（1）DNS協議將主機/域名（hackr.jp）解析成對應的IP地址；
（2）HTTP協議將生成HTTP請求報文；
（3）TCP協議，將請求報文分割並可靠的傳輸給對方；
（4）IP協議，搜索對方的地址，一邊中轉一邊傳送；
（5）TCP協議：將請求報文重組，併發送回應用層；
（6）HTTP協議對請求的內容進行處理，並由服務器返回請求內容。

URI

URI用字符串來標識某處的互聯網資源，而URL則是互聯網資源的具體地址。

HTTP協議

HTTP是應用層協議，定義的是傳輸數據的內容的規範。HTTP的連接使用**“請求-響應”**方式。基於TCP協議傳輸，默認端口號是80。

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

HTTP協議規定，由客戶端發出請求，由服務端返回響應。

請求報文與響應報文

HTTP 協議和 TCP/IP 協議族內的其他衆多的協議相同，用於客戶端和服務器之間的通信。

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

而響應報文是由協議版本，狀態嗎，狀態嗎的原因短語以及響應首部字段以及實體主體構成的。

HTTP是一種不保存的協議，HTTP 協議自身不具備保存之前發送過的請求或響應的功能。

HTTP協議通過URI定位互聯網上的資源。

GET方法與Post方法

get方法：當客戶端想要向服務器讀取數據時使用GET， 指定的資源經服務器端解析後返回響應內容。get方法的參數通過URL傳遞，由於服務器對URL長度的限制，允許發送的數據量較小，且由於信息直接暴露在URL中，因此不能傳遞敏感信息。

post方法：當客戶端給服務器提供信息較多時可以使用POST；POST會附帶用戶數據，一般用於更新資源信息；POST將請求參數封裝在HTTP 請求數據中，可以傳輸大量數據，傳參方式比GET更安全。

Cooike

Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。當客戶端第一次向服務端發送請求報文後，服務端會在響應保文中寫入Cookie信息，當客戶端第二次向服務端發送請求報文時，該報文中帶有Cookie，服務端就可以通過該Cookie找到之前的狀態信息。

返回結果的HTTP狀態嗎

狀態碼用於表示HTTP請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤。狀態嗎的類別如下。

1XX

1XX表示服務器已接收了客戶端請求，客戶端可繼續發送請求。

2XX成功

2XX代表請求被正常處理了。

1. 200 OK
   表示從客戶端發來的請求在服務器端被正常處理了。
   
2. 204 No Content
   該狀態碼代表服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。
   一般在只客戶端往服務端發送消息，而對客戶端不需要發送新消息內容時使用。（理解爲post）
   
3. 206 Partial Content
   該狀態碼錶示客戶端進行了範圍請求，而服務器成功執行了這部分的GET 請求。
   

3XX

表示服務器要求客戶端重定向。

1. 301 Moved Permanently
   永久性重定向，該狀態碼錶示當前URI所指向的資源已經被分配其他URI，在請求時應該使用新的URI。例如：當指定資源路徑的最後忘記添加斜槓“/”，就會產生 301 狀態碼。
   
2. 302 Found
   臨時性重定向，該狀態碼錶示請求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問。
   
3. 304 Not Modified
   **該狀態碼錶示客戶端發送附帶條件的請求時，服務器端允許請求訪問資源，但未滿足條件的情況。**比如沒有滿足get的條件。
   

4XX客戶端錯誤

4XX 的響應結果表明客戶端是發生錯誤的原因所在，客戶端請求的有非法內容。

1.400 Bad Request
該狀態碼錶示請求報文中存在語法錯誤。

2.401 Unauthorized
該請求碼代表發送的請求需要有HTTP認證，同時如果這是第二次發出401，則代表認證沒有被通過。同時該請求碼必須包含一個適用於被請求資源的 WWW.Authenticate首部用以質詢（challenge）用戶信息。

3.403 Forbidden
表示訪問資源的請求被服務端禁止了。

4.404 Not Found
表示服務器無法找到請求的資源。

5XX 服務器端錯誤

表示服務器未能正常處理客戶端的請求而出現意外錯誤。

1.500 Internal Server Error
表示服務端內部在處理請求時出現了錯誤。

2.503 Service Unavailable
表示服務器暫時處於超負荷或維護中，當前不能夠處理客戶端的請求，在一段時間之後，服務器可能會恢復正常。

HTTP與HTTPs

在 HTTP 協議中有可能存在信息竊聽或身份僞裝等安全問題。使用HTTPS 通信機制可以有效地防止這些問題。
HTTP具有以下缺點：
（1）通信使用明文，內容可能會被竊聽。
（2）不驗證通信方的身份，因此有可能遭遇僞裝。
（3）無法證明報文的完整性，所以有可能已遭篡改

HTTPS是披着SSL外殼的HTTP，它在通過HTTP與TCP通信之間先進行了SSL加密，可以說HTTPS就是實現了通信加密，身份驗證，完整性保護的HTTP。

HTTP的報文使用明文（指未經過加密的報文）方式發送，而SSL會對報文內容進行加密。
HTTP協議中的請求和響應不會對通信方進行確認，會發生服務器是否就是發送請求中URI真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端的問題。而SSL中通過第三方向發送端與接收端發放的證書來識別身份。

HTTP協議中常用MD5和SHA-1等散列值校驗的方式來確認文字的數字簽名以防止內容篡改，但如果篡改者將MD5與SHA-1都改變了的話，就無法判斷了。

除此之外，從端口來看：HTTP常用端口爲80，而HTTPS的常用端口爲443；

從資源來看：HTTPS由於加密和解密會消耗更多的CPU和資源；

從開銷上來看：HTTPS需要證書，需要向機構購買；

Https的加密算法

1.共享密鑰算法
解密和加密需要同一把祕鑰的算法，在傳輸過程中需要傳遞祕鑰。

2.公開祕鑰算法
包括兩把祕鑰：公開祕鑰與私有祕鑰。發送祕鑰的一方使用對方的祕鑰對報文進行加密，對方收到後使用自己的私有祕鑰解密。

Https安全通信（建立）的過程

1.客戶端會首先向服務端發一個ClientHello，包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
2.服務器會在可以進行SSL服務時，返回一個ServerHello，其中也是包含SSL的指定版本與加密組件
3.服務端會發送一個certificate，包含公開密鑰的證書
4.服務端會發送Server Hello Done通知客戶端的初始握手完成。
5.SSL第一次握手結束後，客戶端會發送一個Client Key Exchange來作爲迴應。報文中包含一種隨機密碼串Pre-master secret，該報文已經通過公開祕鑰進行加密。
6.客戶端繼續發生ChangeCipherSpec報文提示在此之後的報文都會通過Pre-master secret來加密；
7.客戶端發送Finished報文
8.服務端同樣返回ChangeCipherSpec
9.服務端返回Finished
10.當客戶端與服務端的Finished報文交換後，說明SSL連接成功，之後客戶端發送Http請求
11.服務端返回Http響應
12.由客戶端斷開連接，通過發送close_notify報文。

在地址欄打入URL會發生什麼

1.瀏覽器首先通過DNS服務器將URL中的主機域名解析成IP地址；
2.瀏覽器（根據IP地址與80端口）向服務器請求建立TCP連接，通過三次握手與服務端建立聯繫；
3.服務器根據URL中的內容返回對應的html文件；
4.傳輸結束後，服務器通過四次揮手與客戶端斷開連接；
5.瀏覽器將html文件解析並顯示出來。

DNS查詢：
它首先去找本地的hosts文件，檢查在該文件中是否有相應的域名、IP對應關係，如果有，則向其IP地址發送請求，如果沒有，再去找DNS服務器。

瀏覽器客戶端向本地DNS服務器發送一個含有域名www.cnblogs.com的DNS查詢報文。本地DNS服務器把查詢報文轉發到根DNS服務器，根DNS服務器注意到其com後綴，於是向本地DNS服務器返回comDNS服務器的IP地址。本地DNS服務器再次向comDNS服務器發送查詢請求，comDNS服務器注意到其www.cnblogs.com後綴並用負責該域名的權威DNS服務器的IP地址作爲迴應。最後，本地DNS服務器將含有www.cnblogs.com的IP地址的響應報文發送給客戶端。

從客戶端到本地服務器屬於遞歸查詢，而DNS服務器之間的交互屬於迭代查詢。

Http1.0,1.1,2.0的區別

Http1.0默認使用短連接，1.1使用長連接。
Http1.1相比1.0多加了一些響應頭，如身份認證、狀態管理和Cache緩存等。
Http2.0相比Http1.x
新的二進制格式：HTTP2.0的協議解析決定採用二進制格式，實現方便且健壯，不同於HTTP1.x的解析是基於文本。
多路複用：連接共享，即每一個request都是是用作連接共享機制的
服務端推送：服務器主動向客戶端推送消息。

HTTP的長連接和短連接本質上是TCP長連接和短連接。
短連接：瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
長連接：當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。

優缺點：長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶來說，較適用長連接。在長連接的應用場景下，存活功能的探測週期太長，還有就是它只是探測TCP連接的存活，client端一般不會主動關閉它們之間的連接，Client 與 server 之間的連接如果一直不關閉的話，會存在一個問題，隨着客戶端連接越來越多，server早晚有扛不住的時候，這時候 server 端需要採取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可 以避免一些惡意連接導致 server 端服務受損；如果條件再允許就可以以客戶端機器爲顆粒度，限制每個客戶端的最大長連接數，