萬字長文拿下HTTP

時間 2020-06-22

標籤萬字長文拿下 http 欄目 HTTP/TCP 简体版

原文原文鏈接

本文將從如下幾個方面進行分享。其中包括HTTP發展史，HTTP緩存代理機制，經常使用的web攻擊，HTTP和HTTPS的流量識別，網絡協議學習的工具推薦以及高頻HTTP與HTTPS的高頻面試題題解等，開工。html

提綱python

1989年，蒂姆·伯納斯 - 李（Tim Berners-Lee）在論文中提出能夠在互聯網上構建超連接文檔，並提出了三點.nginx

URI：統一資源標識符。互聯網的惟一IDweb

HTML：超文本文檔面試

HTTP:傳輸超文本的文本傳輸協議redis

1 HTTP應用在哪兒

學習一門知識，採用五分鐘時間看看這個知識是幹啥的可能會更加有目的性。HTTP可謂無處不在，這裏例舉出幾個。算法

HTTP應用場景docker

2 HTTP是什麼

HTTP(hypertext transport protocol)翻譯過來爲"超文本傳輸協議"，文本能夠理解爲簡單的字符文字組合，也能夠理解爲更爲複雜的音頻或者圖像等。那麼將這個詞語拆分爲三個部分。數據庫

超文本傳輸協議編程

"超文本"和"文本"相比多了一個字"超"，這樣看來比文本豐富，由於它能夠將多種文本/圖像等進行混合，更重要的是能夠從一個文本跳轉到另外一個文本(文本鏈接)。

"傳輸"，傳輸的過程當中須要溝通，溝通便可能一對一溝通也可能一對多溝通(進行內容協商)，不管怎麼樣，參加溝通的人數>1，想盡一切一切辦法更快更好的完成相應的任務。

"協議"，無規矩不成方圓，作機密項目以前須要簽署保密協議，找工做要籤"三方協議"，三方協議是學校，公司，和我的組成的協議，都是爲了讓你們受必定的約束，違反了即有相應的懲罰。

三方協議

3 不一樣版本的HTTP

HTTP/0.9

當時網絡資源匱乏，0.9版本相對簡單，採用純文本格式，且設置爲只讀，因此當時只能使用"Get"的方式從服務器獲的HTML文檔，響應之後則關閉。以下圖所示

GET /Mysite.html

響應中只包含了文檔自己。響應內容無響應頭，無錯誤碼，無狀態碼，能夠說是"裸奔"。

<HTML>
Hello world
</HTML>
HTTP/1.0

此時HTTP/0.9請求過程以下

應用層的HTTP創建在傳輸層的TCP之上並運用TCP可靠性等特性，先三次握手創建鏈接
客戶端請求創建鏈接(此時只有GET)
服務端響應請求，數據以 ASCII 字符流返回給客戶端
傳輸完成，斷開鏈接。

HTTP 0.9

HTTP1.0

隨着時代的進步，僅僅文本的傳輸沒法知足需求，更多狀況須要採用圖文的方式才能生動的表達出本身的觀點。隨着1995年開發出Apache，同時其它的多媒體等技術發展迅速，從而進一步的促使HTTP新功能的出現。HTTP1.0在1996年誕生，增長了一下幾個方面：

以前只有Get方法，如今增長Post(加參數)，Head方法
加入協議版本號，同時添加文件處理類型
加入HTTP Header，讓HTTP處理請求更加靈活
增長響應狀態碼，標記出錯的緣由
提供國際化(不一樣語言)支持

典型的請求過程

GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)

200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML> 
一個包含圖片的頁面
  <IMG SRC="/image.gif">
</HTML>

HTTP1.0通訊過程

HTTP1.0

HTTP /1.1

1995年是不平凡的一年，網景公司和微軟開啓瀏覽器大戰，誰都想當老大。1999年HTTP/1.1發佈併成爲標準，寫入RFC，覺得之後無論是網關仍是APP等，只要你要使用HTTP，就得遵照這個標準。

繼續增長了PUT等方法
容許持久鏈接

隨着文件愈來愈大，圖片等信息愈來愈複雜，若是每一次上傳下載文件都須要創建鏈接斷開鏈接的過程將增長大量的開銷。爲此，提出了持久鏈接，也就是一次TCP鏈接能夠具備多個HTTP請求。固然持久鏈接是可選擇的，若是考慮關閉，只須要使用Connecttion:close關閉便可。長鏈接以下圖所示

長鏈接

強制要求Host頭

咱們知道，在電商系統中，常常會由於促銷活動致使流量飆升，爲了緩解流量，其中有種方法即加緩存或者加服務器。若是是單臺服務器負載過大，數據庫可能分庫分表。數據結構算法中分而治之方法亦是如此。那麼HTTP中，一樣的道理，若是文件太大，就大文件切分爲小文件塊發送。

HTTP /2

HTTP/1.1的出現，幾年間出來大量牛掰的互聯網公司，發展實在是太快，可是HTTP1.1中這幾點成爲詬病

緣由1 TCP自帶慢啓動

顧名思義，"慢啓動"從0到1循循漸進。轎車啓動不會按下按鈕就直接起飛，而是緩慢調節到適合的速度。這不是挺好的？爲何會帶來性能問題呢。咱們知道一個頁面有靜態數據，動態頁面，不少小文件在加載的過程當中就會直接發起請求，這樣致使太多的請求都會經歷慢啓動過程，花費時間太多。

緣由2 多條TCP鏈接帶寬競爭

帶寬固定，多條TCP鏈接同時發起競爭帶寬資源，因爲各個TCP鏈接之間沒有通訊機制，也沒法得知哪些資源優先級更高，從而致使想快速下載的資源反而延遲下載。

緣由3 頭部阻塞

阻塞，在網絡編程中，咱們採用異步，多路複用(epoll)方式儘可能讓cpu少等待多幹事。在HTTP1.1中，雖然你們共用了一條TCP通道，可是第一個請求沒有結束，第二請求就可能阻塞等待，也就是說不能同時發送接收數據。那麼一個網頁不少數據文件，若是可以同時發出請求，讓部分數據文件可以獲得響應並預處理，這樣就大大的利用了帶寬和cpu的資源。基於這些因素，在HTTP2中出現了新的方案

如何解決頭部阻塞呢？

HTTP是一問一答的模式，你們都在這個隊列排隊致使堵塞，那就多個隊列併發進行，也就是"對同一個域名發起多個長鏈接"。舉個例子，在火車站排隊買票的時候，若是隻有一個窗口可用，你們只能苦等，多開幾個窗口就可緩解這個問題。

這個時候用戶數 * 併發數(上限6-8)已經不錯得效果，可是互聯網速度太快，火車站就這麼大，窗口也就這麼多，怎麼辦，建新的火車站進行分流(大部分城市都有什麼東站西站)。在這裏叫作"域名分片"，使用多個域名，這些域名指向同一服務器。

HTTP/3

HTTP/2看似很完美了吧，可是Google輪子哥可不服，其餘人在研究HTTP/2的時候，它們就在琢磨QUIC。那QUIC有啥牛掰的地方呢

QUIC是Google開發的一個基於UDP且能像TCP同樣具備可靠性特色的協議。具有像HTTP/2同樣的應用數據二進制分幀傳輸。其主要解決的問題有兩個。

進一步解決線頭阻塞問題。經過獨立不一樣流，讓各個流之間實現相互獨立傳輸，互不干擾
切換網絡時的鏈接保持。wifi和3G/4G常常須要來回切換。基於TCP的協議，會由於網絡的切換致使IP地址的改變。而基於UDP的QUIC協議，及時切換也能夠恢復以前與服務器的鏈接。(這裏推薦你們能夠去看看MPTCP)

4 HTTP報文詳解

客戶端與服務端進行交互的信息爲報文。客戶端爲請求報文，服務端爲響應報文。咱們先用wireshark抓一個博客看看

報文層次結構

GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip

請求報文

請求報文一般由三部分組成：

起始行：描述請求或者響應的基本信息

頭部字段集合：key-value形式說明報文

消息正文：實際傳輸諸如圖片等信息。具體以下圖試試

1 請求方法：一共有八種方法選擇，以下圖所示。採用不一樣的方法獲取不一樣的資源

HTTP請求方法詳解

說一下很是常見的幾種請求方法

Get：從服務器中取資源。能夠請求圖片，視頻等

HEAD:和Get相似，可是從服務器請求的資源不會反悔請求的實體數據，只會反悔響應頭

POST/PUT：對應於GET，向服務器發送數據

2 URI

統一資源標識符(Uniform Resource Identifier),嚴格來講不等於網址，它包含URL和URN，但是URL太出名了以至於URL="網址"。不管開發，測試運維配置都離不開URI,因此好好掌握。

網絡層的IP主要目的是解決路由和尋址。如今的IP地址按照"."分割，總共2的32次方大約42億。對於計算機來講比較方便，可是對於人類來講仍是不容易記憶，此時出現DNS了，他把IP地址映射爲咱們平時常見的"redis.org"，按照"."分割域名，從左到右級別越高，最右邊爲"頂級域名"。以下圖所示

域名體系

好了，如今TCP提供可靠(數據不丟失)且字節流(數據完整性)，並且也有方便咱們記憶的域名，可是互聯網資源千萬種，也不知道訪問什麼(圖片，文字，視頻一大堆)，這個時候URI(統一資源標識符)出現了，那長啥樣？

URI格式

協議名:HTTP協議，另外還有ftp等協議。告知訪問資源時使用什麼協議。

緊接着是分隔符:"://"

主機名：標記互聯網主機，能夠是IP也能夠是域名，若是不寫端口則使用默認端口，例如HTTP爲80，HTTPS爲443.

登陸認證信息：登陸主機時的用戶名密碼(不建議，直接告訴了別人你的隱私信息)

主機名：此處能夠是域名也能夠是IP，若是不寫端口號則是默認端口。好比HTTP默認端口爲80，HTTPS默認端口爲443

資源所在位置：資源在主機上的位置，使用「/」分隔多級目錄，在這裏是「/en/download.html」。注意，必須"/"開頭

參數：用"?"開始，表示額外的請求要求。一般使用"key=value"的方式存在，若是多個"key=value"則使用"&"相連。

看幾個例子

http://nginx.org/en/download.html

file:///E:/Demo/index/

這裏注意是三個"///"，由於前面"://"做爲分隔符，資源路徑按照"/"開頭。

既然規則這麼多，對於接收方而言須要完成的解析也須要遵照規則，全球用戶不少使用HTTP，每一個國家地區所使用語言不一樣，HTTP爲了能對其進行統一處理，引入了URI編碼，方法比較簡單，將非ASCII或者特殊字符所有轉換爲十六進制字節值，同時在前面加入"%"。好比空格被轉換爲"%20","中國"就編碼爲"%E4%B8%AD%E5%9B%BD%0A"。

3 請求體

響應報文

狀態行----服務器響應的狀態

<1> 版本號：使用的HTTP什麼版本

<2> 狀態碼：不一樣數字表明不一樣的結果，就如咱們在編碼時，經過返回不一樣的值表明不一樣的語義。

狀態碼一共分爲5類。

1××：處於中間狀態，還需後續操做

2××：成功收到報文並正確處理

"200 OK"

最多見的成功狀態碼，表示一切正常，客戶端得到期許的處理結果。若是不是Head請求，那麼在響應頭中一般會有body數據。

"204 No Content"

這個的含義和"200"很類似，不一樣之處在於它的響應頭中沒有body數據。

"206 Partial Content"

是 HTTP 分塊下載或斷點續傳的基礎，在客戶端發送「範圍請求」、要求獲取資源的部分數據時出現，它與 200 同樣，也是服務器成功處理了請求，但 body 裏的數據不是資源的所有，而是其中的一部分。狀態碼 206 一般還會伴隨着頭字段「Content-Range」，表示響應報文裏 body 數據的具體範圍，供客戶端確認，例如「Content-Range: bytes 0-99/5000」，意思是這次獲取的是總計 5000 個字節的前 100 個字節。

3××：重定向到其餘資源位置

"301 Moved Permanently"

「永久重定向」，意思是本地請求的資源以及不存在，使用新的URI再次訪問。

「302 Found」

「Moved Temporarily」，「臨時重定向」，臨時則所請求的資源暫時還在，可是目前須要用另外一個URI訪問。

301 和 302 經過在字段Location中代表須要跳轉的URI。二者最大的不一樣在於一個是臨時改變，一個是永久改變。舉個例子，有時候須要將網站所有升級爲HTTPS，這種永久性改變就須要配置永久的"301"。有時候晚上更新系統，系統暫時不可用，能夠配置"302"臨時訪問，此時不會作緩存優化，次日還會訪問原來的地址。

「304 Not Modified」

運用於緩存控制。它用於 If-Modified-Since 等條件請求，表示資源未修改，能夠理解成「重定向已到緩存的文件」（即「緩存重定向」）。

4××：請求報文有誤，服務器沒法處理

"400 Bad Request」

通用錯誤碼，表示請求報文有錯誤，可是這個錯誤過於籠統。不知道是客戶端仍是哪裏的錯誤，因此在實際應用中，一般會返回含有明確含義的狀態碼。

「403 Forbidden」

注意了，這一個是表示服務器禁止訪問資源。緣由好比涉及到敏感詞彙、法律禁止等。固然，若是能讓客戶端有一個清晰的認識，能夠考慮說明拒絕的緣由並返回便可。

「404 Not Found」

這多是咱們都知道且都不想看到的狀態碼之一，它的本意是想要的資源在本地未找到從而沒法提供給服務端，可是如今，只要服務器"耍脾氣"就會給你返回 404，而咱們也無從得知後面究竟是真的未找到，仍是有什麼別的緣由，

"405 Method Not Allowed"

獲取資源的方法好幾種，咱們能夠對某些方法進行限制。例如不容許 POST 只能 GET；

"406 Not Acceptable"

客戶端資源沒法知足客戶端請求的條件，例如請求須要中文但只有英文；

"408 Request Timeout"

請求超時，服務器等待了過長的時間；

"409 Conflict"：

多個請求發生了衝突，能夠理解爲多線程併發時的競態；

413 Request Entity Too Large：

請求報文裏的 body 太大；

414 Request-URI Too Long：請求行裏的 URI 太大；

429 Too Many Requests：客戶端發送了太多的請求，一般是因爲服務器的限連策略；

431 Request Header Fields Too Large：請求頭某個字段或整體太大；

5××：服務器錯誤，服務器對請求出的時候發生內部錯誤。

「500 Internal Server Error」

和400 相似，屬於一個通用的錯誤碼，可是服務器究竟是什麼錯誤咱們不得而知。其實這是好事，儘可能少的將服務器資源暴露外網，儘可能保證服務器的安全。

「502 Bad Gateway」

一般是服務器做爲網關或者代理時返回的錯誤碼，表示服務器自身工做正常，訪問後端服務器時發生了錯誤，但具體的錯誤緣由也是不知道的。

「503 Service Unavailable」

表示服務器當前很忙，暫時沒法響應服務，咱們上網時有時候遇到的「網絡服務正忙，請稍後重試」的提示信息就是狀態碼 503。

503 是一個「臨時」的狀態，

暫時比較忙，稍後提供服務。在響應報文中的「Retry-After」字段，指示客戶端能夠在多久之後再次嘗試發送請求。

4 請求體

上面大部分都是涉及到header部分，還有很是重要的body，everybody

頭字段注意事項

<1> 字段名不區分大小寫，例如「Host」也能夠寫成「host」，但首字母大寫的可讀性更好；

<2> 字段名裏不容許出現空格，可使用連字符「-」，但不能使用下劃線"_"。例如，「test-name」是合法的字段名，而「test name」「test_name」是不正確的字段名；

<3> 字段名後面必須緊接着「:」，不能有空格，而":"後的字段以前能夠有多個空格；

<4> 字段的順序是沒有意義的，能夠任意排列不影響語義；

<5> 字段原則上不能重複，除非這個字段自己的語義容許，例如 Set-Cookie。

HTTP的body經常被分爲這幾種的類別

<1> text:超文本text/html,純文本text/plain

<2> audio/video:音視頻數據

<3> application: 多是文本，也多是二進制，交給上層應用處理

<4> image: 圖像文件。image/png等

可是帶寬必定，數據大了一般考慮使用壓縮算法進行壓縮，在HTTP中使用Encoding type表示，經常使用的壓縮方式有下面幾種

<1> gzip:

一種數據格式，默認且目前僅使用deflate算法壓縮data部分

<2> deflate:

deflate是一種壓縮算法，是huffman編碼的一種增強

<3> br:

br經過變種的LZ77算法、Huffman編碼以及二階文本建模等方式進行數據壓縮，其餘壓縮算法相比，它有着更高的壓塑壓縮效率

使用相應的壓縮方法在帶寬必定的狀況下確實有不錯的效果，可是gzip等主要針對文件壓縮效果不錯，可是對視頻就不行了。這個時候是否是可使用數據結構中經常使用的分而治之，大化小再合併的方式呢，

文件拆分

ok，在報文中使用"Transer-Encoding:chunked"表示，表明body部分數據是分塊傳輸的。另外在body中存在一個content-length字段表示body的長度，二者不能共存，另外不少時候是流式數據，body中沒有指明content-length，這個時候通常就是chunked傳輸了。

如今能夠經過採用分塊的方式加強帶寬的利用率，那他的編碼規則如何呢

<1> 每個分塊包含長度和數據塊

<2> 長度頭按照CRLF結束

<3> 數據塊在長度快後，且最後CRLF結尾

<4> 使用長度0表示結束，"0\r\n\r\n"

咱們仍是看圖加深印象

chunked分塊

分塊解決了咋們一部分問題，可是有的時候咱們想截斷髮送怎麼辦呢。在HTTP中提供了使用字段「Accept - Ranges: bytes」，明確告知客戶端：「我是支持範圍請求的」。那麼Range範圍是怎樣的呢，Range從0開始計算，好比Range:0-5則讀取前6個字節，服務器收到了這個請求，將如何迴應呢

<1> 合法性檢查。好比一共只有20字節，可是請求range：100-200。此時會返回416----"範圍請求有誤"

<2> 範圍正常，則返回216，表示請求數據知識一部分

<3> 服務器端在相應投資端增長Content-Range,格式"bytes x-y/length"。

敲黑板：斷點續傳怎麼操做？

<1> 查看服務器是否支持範圍請求並記錄文件大小

<2> 多個線程分別負責不一樣的range

<3> 下載同時記錄進度，即便由於網絡等緣由中斷也沒事，Range請求剩餘便可

如今咱們經過MIME-TYPE和Encoding-type能夠知道body部分的類型，下一步將是對內容進行協商。HTTP中，請求體中使用Accept告訴服務端須要什麼類型數據(我能處理哪些類型數據)，響應頭中使用Content代表發送了什麼類型數據，具體以下圖所示

好了，爲了各個國家民族順利友好的溝通和明確的區分。HTTP請求頭中使用"type-subtype"，注意此時分隔符是"-"。好比en-GB表示英式英語，zh-CN表示經常使用的漢語，那對於客戶端而言，它經過Accept-Language來標記本身能夠理解的天然語言，對應的服務端使用Content-Language代表實體數據使用的語言類型，以下圖所示。

字符集和編碼

Cookie機制

HTTP是無狀態、無記憶的，Cookie機制的出現讓其有記憶功能，是怎麼個實現呢

從上圖咱們能夠知道Cookie是由瀏覽器負責存儲，並非操做系統負責，咱們換個瀏覽器打開一樣的網頁，服務就認不出來了。

Cookie常見的應用一個是身份識別，一個是廣告追蹤，好比咱們在訪問網頁視頻或者圖片的時候，廣告商會悄悄給咱們Cookie打上標記，方便作關聯分析和行爲分析，從而給我推薦一些相關內容。

HTTP代理

以前介紹的都是一問一答的情景，可是在大部分的狀況下都會存在多臺服務器進行通訊服務。其中比較常見的就是在請求方與應答方中間增長一箇中間代理。

代理

代理做爲中間位置，相對請求方爲服務端，至關於後端服務端爲請求方。代理常見的功能爲負載均衡。在負載均衡中須要區分正向代理與反向代理，其中也就會涉及調度算法，好比輪詢，一致性哈希等。

正向代理與反向代理

那麼問題來了，代理做爲隱藏身份，至關於隱藏了真實的客戶端與服務端，那在是否是

5 HTTPS

好人佔多數，壞人也很多。總有些要搞壞事，由於HTTP是明文，因此須要想辦法保護明文，從而出現了https。

安全是什麼

安全四要素

機密性

對信息進行保密，只能可信的人能夠訪問(讓我想起時間管理者)。

完整性

數據在傳輸過程當中內容不被"篡改"。雖然機密性對數據進行保密了，可是有上策也有下策(hack)

身份認證

證實本身的身份是本人，保證其消息發給可信的人

不能否認

君子一言駟馬難追，說話算數，說過的話作過的事要有所保證

HTTPS

HTTP和HTTPS

從上圖咱們知道HTTPS無非是在傳輸層和應用層中間加了一層TLS，正是TLS緊跟當代密碼學的步伐，盡全力的保障用戶的安全。老規矩，咱們用wireshark看看長什麼樣子。

TLS

能夠看出在交互的過程當中多了很多新東西，瞭解TLS,TLS由SSL握手協議，SSL修改密碼規範協議，SSL警報協議，SSL記錄協議組成。

TLS組成

SSL握手協議：

相對於三次握手

記錄協議

記錄爲TLS發送接收數據的基本單位。它的自協議須要經過記錄協議發出。若是多個紀錄數據則能夠一個TCP包一次性發出。

警報協議

相似HTTP狀態碼，經過反饋不一樣的消息進行不一樣的策略。

變動密碼規範協議

告訴對方，今後刻開始，後續的數據將使用加密算法進行加密再傳輸。

對稱加密與非對稱加密

對稱加密

對稱加密，顧名思義，加密方與解密方使用同一鑰匙(祕鑰)。具體一些就是，發送方經過使用相應的加密算法和祕鑰，對將要發送的信息進行加密；對於接收方而言，使用解密算法和相同的祕鑰解鎖信息，從而有能力閱讀信息。

對稱加密

非對稱加密

在對稱加密中，發送方與接收方使用相同的祕鑰。那麼在非對稱加密中則是發送方與接收方使用的不一樣的祕鑰。其主要解決的問題是防止在祕鑰協商的過程當中發生泄漏。好比在對稱加密中，小藍將須要發送的消息加密，而後告訴你密碼是123balala,ok,對於其餘人而言，很容易就能劫持到密碼是123balala。那麼在非對稱的狀況下，小藍告訴全部人密碼是123balala,對於中間人而言，拿到也沒用，由於沒有私鑰。因此，非對稱密鑰其實主要解決了密鑰分發的難題。以下圖

非對稱加密

其實咱們常常都在使用非對稱加密，好比使用多臺服務器搭建大數據平臺hadoop，爲了方便多臺機器設置免密登陸，是否是就會涉及到祕鑰分發。再好比搭建docker集羣也會使用相關非對稱加密算法。

混合加密

非對稱加密算法，大多數是從數學問題演變而來，運算速度較慢。混合加密所謂取長補短。通訊過程當中使用RSA等解決密鑰交換問題，而後使用隨機數產生的在對稱算法中的會話密鑰，最後使用加密。對方使用私鑰解密獲得的密文取出會話祕鑰，這樣就實現了密鑰交換。

混合加密

經過混淆加密等方式完成了機密性任務，做爲Hack只須要僞造發佈公鑰或者做爲之間人竊聽密文。可是咱們知道安全是四要素，還須要保證數據的完整性，身份認證等。

摘要

摘要算法能夠理解爲一種特殊的"單向"加密算法，無密鑰，不可逆。在平時項目中，應該你們都是用過MD5，SHA-1。可是在TLS中使用SHA-2。

假設小A轉帳5000給小C，小A加上SHA-2摘要。網站計算摘要並對比，若是一致則完整可信。

摘要可信

此時小B想修改小A給的money，這個時候網站計算摘要就會發現不同，不可信

摘要不可信

HTTPS請求創建鏈接過程

HTTP握手過程

注意：

首先經過非對稱加密創建通訊過程
在握手階段，爲何使用3個隨機數，一方面防止「隨機數 C」被猜出，另外一方增長Session key隨機性
Client發出支持的「對稱/非對稱加密」算法
server返回選用的「對稱/非對稱加密」算法
Client對算法進行確認
Server對算法進行確認

根據wireshak結果，對TLS進一步剖析。TCP三次握手創建鏈接，做爲禮貌，Client先打招呼"Client Hello"。裏面包含了Client的版本號、所支持的密碼套件和隨機數，以下圖所示

Client Hello

Server端表示尊重，回覆"Server Hello",同時進行版本校對，給出隨機數(Server Random)，從Client算法列表中選擇一個密碼套件，在這裏選擇的"
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。

cipher Suite

這裏的"
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什麼意思呢

密碼套件選擇橢圓曲線加RSA、AES、SHA256

雙方經過證書驗證身份。由於本機服務器選用了ECDHE算法，爲了實現密鑰交換算法，它會發送證書後把橢圓曲線的公鑰（Server Params）連帶"Server Key Exchange"消息發送出去。

Server Key Exchange

意思是，剛纔混合加密套件比較複雜，給你個算法參數，好好記住，別弄丟了。

ServerHelloDone

隨後服務端回覆"hello done"告知打招呼完畢

打完招呼完畢後，客戶端對證書進行覈實。而後根據密碼套件也生成橢圓曲線的公鑰，用"Client Key Exchange"消息發給服務器

Client Key Exchange

此時客戶端和服務端都有了密鑰交換的兩個參數(Client Params、ServerParams），而後經過 ECDHE 算法算出了一個新的值，叫「Pre-Master」

有了主密鑰和會話密鑰，客戶端發送「Change Cipher Spec」和「Finished」消息，最後將全部消息加上摘要發送給服務器驗證。

服務器一樣發送「Change Cipher Spec」和「Finished」消息，握手結束，開始進行HTTP請求與響應

4 初探域名

咱們知道域名的出現讓咱們更容易記憶，按照"."分割，越靠近右邊級別越高。域名本質是一個名字空間系統，採用多級域名的方式區分不一樣的國家，公司等，做爲一種身份的標識。

根域名服務器（Root DNS Server）：管理頂級域名服務器，返回「com」「net」「cn」等頂級域名服務器的 IP 地址；

頂級域名服務器（Top-level DNS Server）：管理各自域名下的權威域名服務器，好比com 頂級域名服務器能夠返回 apple.com 域名服務器的 IP 地址；

權威域名服務器（Authoritative DNS Server）：管理本身域名下主機的 IP 地址，好比apple.com 權威域名服務器能夠返回 www.apple.com 的 IP 地址**

6 HTTP特色小結

寫到這裏，說它簡單是假的，簡單的東西一般更具備擴展的可能性。根據需求的變動，愈來愈複雜。

1：靈活且易擴展，他的頭部字段不少都是可定製且可擴展

2：應用普遍。各個領域都有涉及。"跨平臺，跨語言"

3：無狀態。沒有記憶功能，少功能即少佔用資源。另外無狀態更容易搭建集羣，經過負載均衡將請求轉發到任意一臺服務器。缺點是沒法支持須要連續步驟的"事務"操做。咱們知道TCP協議有11種狀態，不一樣狀態表明通訊過程當中不一樣的含義。一樣操做系統中的進程也有執行，就緒，活動阻塞等多種狀態。可是HTTP全程都是"懵逼"無狀態。好比小華請求服務器獲取視頻X，服務器以爲可行就發給小華。小華還想獲取視頻Y，這時服務器不會記錄以前的狀態，也就不知道這兩個請求是不是同一個，因此小華還得告訴服務器本身的身份。

4：明文。優勢是能讓開發人員經過wireshark工具更直觀的調試。缺點即裸奔互聯網，沒隱私可言。

5:可靠傳輸。HTTP爲應用層協議，基於TCP/IP，而TCP爲「可靠」傳輸協議，所以HTTP能在請求應答中"可靠"傳輸數據。

6：應用層協議。應用層協議不少，其中經常使用的郵件協議SMTP，上傳下載文件ftp，默認端口22/23，SSH遠程登陸(XSHELL)。這些應用層協議都太專注，而HTTP經過各類頭部字段，實體數據的組合，並綜合緩存代理等功能，不得不說是網絡中的冠希哥。

7 HTTP識別(還原)

這裏說的識別，經過代碼層面(libpcap封裝)實現HTTP的識別，也能進一步體現TCP/IP協議棧的分層特性。先看回憶一下IP頭部格式。

IP頭部

注意頭部中的協議字段，若是此字段值爲0x0600則爲TCP分組。當知道了是TCP分組後，是否是能夠經過TCP頭部中端口(80)就能夠判斷爲HTTP呢，不能的，不少狀況都會使用動態端口的方式進行部署。此時能夠經過HTTP中的關鍵字進行判斷。若是爲HTTP，再經過頭部字段中的"Content-type"，charset等確認文本信息，編碼方式，最後採用解碼算法進行還原。