各層協(xié)議

1.HTTP協(xié)議

• HTTP（超文本傳輸協(xié)議）是應(yīng)用層協(xié)議，并且是無狀態(tài)協(xié)議，協(xié)議本身并不會保存用戶的任何信息，每次請求都是獨立的。
• 獨立的請求可以減小服務(wù)器的壓力，支持更大的并發(fā)請求。

1. RTT

   • 請求往返時間。從請求一個發(fā)送開始到接收到接收端的確認(rèn)信息所經(jīng)歷的的時間就是一個RTT。
   • 一個完整的請求需要2個RTT和文件傳輸?shù)臅r間.

2. HTTP/1.0 

   • 缺點：非持續(xù)性連接（短連接） ，每次請求都需要2個RTT的開銷（每次都三次握手）。
   • 服務(wù)器負擔(dān)很重，但是瀏覽器可以同時多個并行的TCP連接，每個連接處理一個請求，這樣可以縮短響應(yīng)時間。

3. HTTP/1.1

   1. 持續(xù)性連接（長連接），發(fā)送請求之后一段時間里獲得持續(xù)連接，之后的請求可以通過該鏈接持續(xù)發(fā)送，并且不局限于同一頁面，只要是對同一服務(wù)器請求即可。
   2. 1.1默認(rèn)流水線（管道）方式：在收到響應(yīng)報文之前，可以持續(xù)發(fā)送請求報文，這樣所有的請求只用一個RTT。
   3. 非流水線方式：只有收到前一個報文的響應(yīng)報文才會發(fā)送下一個請求報文，這樣每一個請求都要用一個RTT。 
   4.  POST不支持流水線，如刷新頁面就會被提示重定向。GET 支持流水線方式。

2.HTTP報文結(jié)構(gòu)

1. 請求報文

1. 1. 請求報文有3部分組成：

      1. 請求行： 請求方法  URL  版本號
      2. 首部行： 首部字段：value  （可以有若干項，信息最豐富）
      3. 實體主體： 存儲資源信息（請求的信息），請求報文中一般不用，響應(yīng)報文也有可能不用。
      • 請求行和首部行組成了報文首部（報文頭）

   2. 請求方法有8種

      1. GET : 從服務(wù)器請求指定頁的信息，并返回實體主體。
      2. POST : 向服務(wù)器提交數(shù)據(jù)，并進行處理。
      3. HEAD ： 類似于GET，但只獲得響應(yīng)報文頭信息。
      4. PUT : 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
      5. DELETE : 請求服務(wù)器刪除指定的頁面。
      6. CONNECT : HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
      7. OPTIONS : 允許客戶端查看服務(wù)器的性能。
      8. TRACE ： 回顯服務(wù)器收到的請求，主要用于測試或診斷。

   3. 自定義方法

      • 請求方法可以自定義  了解WebDAV

   4. 首部行

      • 首部行信息最為豐富，可以在HTTP協(xié)議通信過程中傳遞額外重要的信息。
      • 存儲有關(guān)服務(wù)器和客戶端的重要信息或者相關(guān)參數(shù)。

      1. 首部行有四種類型

         1. 通用首部：請求報文和響應(yīng)報文兩方都會使用的首部。
         2. 請求首部：請求報文時使用的首部。補充了請求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級等信息。
         3. 響應(yīng)首部：響應(yīng)報文時使用的首部。補充了響應(yīng)的附加內(nèi)容，也會要求客戶端附加額外的內(nèi)容信息。
         4. 實體首部：針對請求報文和響應(yīng)報文的實體部分使用的首部。補充了資源內(nèi)容更新時間等與實體有關(guān)的信息。
         • 請求頭和響應(yīng)頭都可以自定義信息，這個特性在web中經(jīng)常用到

      2. HTTP/1.1規(guī)范定義的首部

         • HTTP/1.1規(guī)范定義了很多首部信息如 Date,Host等。《圖解HTTP》一書舉例的非常詳細。

      3. 不在HTTP/1.1規(guī)范定義的首部

         • Cookie、Set-Cookie 最常用的2個首部但他們卻不是HTTP/1.1協(xié)議規(guī)定的，他們由別的協(xié)議規(guī)定。

2. 響應(yīng)報文

1. 1. 響應(yīng)報文也由三部分組成

      1. 狀態(tài)行： 版本號 ，狀態(tài)碼，短語
      2. 首部行：
      3. 實體主體：存放表單數(shù)據(jù)

   2. 狀態(tài)碼由三位數(shù)組成

      • 第一個數(shù)字代表了響應(yīng)的類別后兩位無明顯分類。

      1. 1XX : 通知信息，如請求收到了，或者正在處理。
      2. 2XX : 表示成功，請求正常處理完畢。
      3. 3XX ：重定向狀態(tài)，需要附加操作以完成請求。
      4. 4XX ： 客戶端錯誤，請求無法正常處理，如請求的資源不存在。
      5. 5XX : 服務(wù)器內(nèi)部錯誤，處理請求時出錯。

      • 常見的幾個狀態(tài)碼和對應(yīng)短語

        1. 200 請求成功
        2. 301 永久性重定向。該狀態(tài)碼表示請求的資源已被分配了新的URI，新的URL存放在響應(yīng)頭的Location中，瀏覽器會直接跳轉(zhuǎn)到此URL。 求如果得到的響應(yīng)是301那么，那么刷新瀏覽器再次響應(yīng)就會發(fā)現(xiàn)不是301，因為新的URL已經(jīng)被瀏覽器記錄了下來，下一訪問原URL會自動訪問新URL。
        3. 302 臨時性重定向。資源臨時性改變了URL ,新URL同樣放在響應(yīng)頭的Location中，瀏覽器會會直接跳轉(zhuǎn)。如果的到的響應(yīng)是302，那么訪問原來URL一直是302，新URL不會被瀏覽器記住。
        4. 400 請求報文中存在語法錯誤。
        5. 403 該狀態(tài)碼表明對請求資源的訪問被服務(wù)器拒絕了
        6. 404 找不到資源
        7. 503 服務(wù)器暫時處于超負載或正在進行停機維護

3.POST 和 GET

1. post 比 get 更加安全，get請求是明文傳輸。
2. post 比 get 傳輸?shù)臄?shù)據(jù)量更大，因為get受限于瀏覽器地址欄的字符數(shù)量限制，而post則不受限制。
3. post 可以使用更多數(shù)據(jù)類型，而get 只能使用 ASCII碼。
4. post 比 get 慢，因為post先發(fā)送頭部信息，再發(fā)送數(shù)據(jù)。相當(dāng)于三次握手2個RTT和一個發(fā)送數(shù)據(jù)（實體主體）的RTT,一個三個RTT, 而get無實體主體，數(shù)據(jù)都在url中所以只需三次握手2個RTT, get/post = 2/3。

4.TCP報文格式

TCP 位于運輸層，提供可靠的字節(jié)流服務(wù)。

1. 1. TCP報文首部

      • 如圖，首部和TCP數(shù)據(jù)部分組成了TCP報文。
      • 序號：Seq用來表示報文段中數(shù)據(jù)每個字節(jié)的順序。建立TCP連接后該序號隨機產(chǎn)生一個初始標(biāo)號，不一定從0開始。
      • 確認(rèn)號：用小寫ack表示，與標(biāo)志字段的ACK區(qū)分，表示期望收到下一個報文段的第一個字節(jié)序號。

      • 6bit的標(biāo)志字段，這6個控制字段來說明報文的性質(zhì)

        1. URG : 
        2. ACK : 用來指示  確認(rèn)號  是否有效,1有效0無效。
        3. PSH ：指示報文存在 緊急數(shù)據(jù)
        4. PST 
        5. SYN ：同步序列編號
        6. FIN :  他和 PST，SYN 共同用于連接建立和拆除

5.三次握手

1. 客戶端發(fā)送一個SYN報文，設(shè)SYN = 1，并隨機設(shè)置一個數(shù)字放置在序號Seq中。
2. 服務(wù)器發(fā)送允許連接的報文，SYN = 1, ACK = 1, 把確認(rèn)號ack設(shè)為 收到的報文中的序號Seq + 1。服務(wù)器在隨機設(shè)置一個序號Seq值。
3. 客戶端收到服務(wù)器發(fā)送的確認(rèn)報文 設(shè)置 SYN = 0,ACK = 1，在之后的傳輸中SYN = 0，ACK = 1。

• 為什么要三次握手，2次行不行？
  • 因為網(wǎng)絡(luò)中存在延遲的重復(fù)分組（序號相同），重發(fā)的分組已經(jīng)失效，如果沒有第三次握手就會和這些失效的分組建立連接，造成服務(wù)器資源浪費。
• 客戶端有7種狀態(tài)，服務(wù)器有7種狀態(tài)，他們會在不同狀態(tài)之間循環(huán)。
• 第二次握手之后客戶端進入ESTABLISHED（已建立連接）狀態(tài)就可已發(fā)送數(shù)據(jù)了，所以第三次握手可以攜帶數(shù)據(jù)。

6.四次揮手

1. FIN = 1 ，終止報文，表示報文發(fā)送方數(shù)據(jù)發(fā)送完畢。注意：FIN 報文是不帶數(shù)據(jù)的，但是它會消耗一個序號。
2. 確認(rèn)報文 發(fā)送，服務(wù)器進入CLOSE-WAIT狀態(tài)。此時客戶端到服務(wù)器方向的連接斷開了，而服務(wù)器到客戶端的連接還沒斷開，如果服務(wù)器給客戶端發(fā)送數(shù)據(jù)那么客戶端還要接受該數(shù)據(jù)
3. 服務(wù)器再次發(fā)送終止報文FIN = 1。這是服務(wù)器請求斷開連接。
4. 客戶端收到終止報文后發(fā)送確認(rèn)報文給服務(wù)器，并進入定時等待狀態(tài)TIME-WAIT，時間到后關(guān)閉連接，服務(wù)器收到之后立刻關(guān)閉連接。

• 斷開連接可以看成客戶端和服務(wù)器分別都 “發(fā)送終止報文，并且作出回應(yīng)”
• MSL : 報文段最長壽命，2MSL就是經(jīng)過2倍最長壽命時間再關(guān)閉連接，一般有 30秒，1分鐘或者2分鐘。
• TIME-WAIT 狀態(tài)保障了2點
  1. 保證最后一個報文到達服務(wù)器。如果客戶端最后一個確認(rèn)丟失，服務(wù)器會再次發(fā)送一個FIN= 1報文，這個時間段內(nèi)客戶端就會收到這個報文，再次發(fā)送確認(rèn)報文。
  2.  2MSL 的時間足使以在本次連接中的所有報文都從網(wǎng)絡(luò)中消失，這樣就下一個新的連接中就不會出現(xiàn)舊連接中出現(xiàn)延遲的報文。
• 為什么握手需要三次而揮手需要四次？
  • 他兩過程不一樣，斷開連接是需要雙向斷開的所以，斷開時要四次。深層次原因就是FIN報文不能攜帶數(shù)據(jù)，第二次握手時可以把SYN和ACK是一起發(fā)送的，而斷開時服務(wù)器FIN不能攜帶數(shù)據(jù)這樣就不能和響應(yīng)報文一起發(fā)送，因為響應(yīng)報文有可能攜帶數(shù)據(jù)。

7.HTTP響應(yīng)報文中的分塊傳送

• 請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器無法顯示請求頁面。在傳輸大容量數(shù)據(jù)時，通過把數(shù)據(jù)分割成多塊，能夠讓瀏覽器逐步顯示頁面。
• 分塊傳送也叫斷點續(xù)傳，主要在應(yīng)答報文中，請求報文數(shù)據(jù)一般很小無需分塊傳送。
• 在HTTP1.1中需要在響應(yīng)頭設(shè)置 Content-length 表示整個消息數(shù)據(jù)的長度，這需要服務(wù)器提前計算出整個消息的長度。content-length是維持HTTP1.1 持久連接的一個關(guān)鍵點。
• 如果得到的content -length比實體中的數(shù)據(jù)小，那么就會截斷實體中的數(shù)據(jù)，如果比實體中的數(shù)據(jù)長那么就會等待下一個響應(yīng)數(shù)據(jù)直到全部數(shù)據(jù)傳輸完成。
• 這樣存在一個問題如果消息過大那么計算消息長度花費時間多，或者動態(tài)展示內(nèi)容時根本無法計算消息有多長。

1. HTTP1.1  分塊傳輸編碼

   • 分塊傳輸編碼可以將數(shù)據(jù)分成若干塊，并一個或者多個發(fā)送，在客戶端解碼后即可還原數(shù)據(jù)。
   • 分塊傳輸編碼會將實體主體分成多個部分（塊）。每一塊都會用十六進制來標(biāo)記塊的大小，而實體主體的最后一塊會使用“0(CR+LF)”來標(biāo)記。
   • 采用 分塊編碼 需要在響應(yīng)頭設(shè)置 Transfer-Encoding :chunked，設(shè)置了就不需要設(shè)置content-length，如果有也會被忽略。

   • 分塊傳輸好處

     1. 動態(tài)生成內(nèi)容時用來維持長連接。因為持久性連接需要服務(wù)器設(shè)置發(fā)送消息的大小，但對于動態(tài)生成的對象無法知道大小，分塊之后就可以知道每一塊的大小，通常數(shù)據(jù)塊的大小是一致的，但也不總是這種情況。
     2. 允許最后發(fā)送消息頭字段，如頭字段需要一些信息而這些信息必須要完整的數(shù)據(jù)給出。分塊可以最后發(fā)送頭字段，而不必緩沖全部數(shù)據(jù)后再發(fā)送。
     3. 可以一邊壓縮一邊發(fā)送數(shù)據(jù)。

8.加密方式

1. 對稱加密
   • 雙方都使用相同的秘鑰加密解密，也稱共享加密，秘鑰稱為 對稱秘鑰。
   • 存在的問題：如何將共享秘鑰安全的給對方？也許傳輸過程中會被別人截獲，獲得秘鑰解密文件。
2. 非對稱加密
   • 密文接收方產(chǎn)生2個不同的秘鑰，公鑰和私鑰。不對外公開的就是私鑰，放在網(wǎng)絡(luò)中的就是公鑰。他兩只能一個加密一個解密。
   • 接收方把公鑰發(fā)送給發(fā)送方，發(fā)送方使用公鑰來加密，這樣即使公鑰和密文被截獲，沒有私鑰也法破解密文。
   • 存在問題：接受公鑰方如何確認(rèn)接收到的就是正確的公鑰，而不是被黑客替換了自己偽造的公鑰？如果使用了偽造的公鑰加密，那么黑客就可以用自己的私鑰解密。
3. 數(shù)字簽名：為防止公鑰被替換
   • 數(shù)字證書機構(gòu) CA（Certificate Authority）使用自己的私鑰對 公開的 公鑰 加密，加密之后的就是數(shù)字證書它里面不僅僅有公鑰還有數(shù)字證書機構(gòu)服務(wù)器的相關(guān)信息。
   • 加密一方拿到數(shù)字證書后向數(shù)字證書機構(gòu)查詢是不是正確的公鑰并解密，再使用解密后的公鑰加密文件。

• 秘鑰就是加密算法的參數(shù)。

9.HTTPS

1. 安全的HTTP協(xié)議，使用443端口
2. SSL套接字在應(yīng)用層HTTP和運輸層之間，SSL套接字接收到應(yīng)用層數(shù)據(jù)加密后傳遞給TCP套接字。接收方一樣可以從TCP套接字中讀取后解密在提交個應(yīng)用層。
3. HTTPS采用對稱加密和非對稱加密混合加密方式。
   1. 客戶端向服務(wù)器端發(fā)起SSL連接請求
   2. 服務(wù)器把公鑰發(fā)送給客戶端，并且服務(wù)器端保存著唯一的私鑰（存在隱患，可以使用數(shù)字證書解決）
   3. 客戶端用公鑰對雙方通信的對稱秘鑰進行加密，并發(fā)送給服務(wù)器
   4. 服務(wù)器利用自己唯一的私鑰對客戶端發(fā)來的對稱秘鑰進行解密
   5. 進行數(shù)據(jù)傳輸，服務(wù)器和客戶端雙方用公有的相同的對稱秘鑰對數(shù)據(jù)進行加密解密，可以保證在數(shù)據(jù)收發(fā)過程中的安全，即是第三方獲得數(shù)據(jù)包，也無法對其進行加密，解密和篡改。

4. HTTPS連接方式

   1. TCP連接建立，客戶端發(fā)送請求報文開始SSL通信，報文中包含客戶端支持的SSL版本，加密組件列表（幾組可以使用的加密算法及密鑰長度等）。
   2. 服務(wù)器可進行SSL通信時會發(fā)送響應(yīng)報文，報文中包括選擇的一個加密算法和秘鑰長度。
   3. 之后服務(wù)器發(fā)送包含公開密鑰證書的報文你給客戶端。（服務(wù)器要已經(jīng)在CA做了認(rèn)證）
   4. 最后服務(wù)器發(fā)送報文通知客戶端第一次SSL握手結(jié)束。
   5. SSL第一次握手結(jié)束后，客戶端會用服務(wù)器的公開密鑰加密 共享秘鑰 并傳輸給服務(wù)器.
   6. 接著客戶端會繼承發(fā)送報文提示服務(wù)器，在此報文以后的通信將使用之前發(fā)送過去的  共享秘鑰  進行加密處理。
   7. 最后客戶端發(fā)送結(jié)束報文?！。ǖ诙蜸SL握手結(jié)束）　
   8. 服務(wù)器同樣發(fā)送報文提示客戶端，在此報文以后的通信將使用客戶端之前發(fā)送過來的  共享秘鑰  進行加密處理。
   9. 服務(wù)器發(fā)送結(jié)束報文?！。ǖ谌蜸SL握手結(jié)束）　
   10. 服務(wù)器和客戶端的結(jié)束報文交換完后，SSL連接建立完成，開始HTTP請求
   • 對于HTTPS應(yīng)用層發(fā)來的數(shù)據(jù)會加一個MAC的報文摘要。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性；

   • 總結(jié)HTTPS的三次握手

     1.  建立TCP連接，通過非對稱加密方式將公鑰交給客戶端。
     2. 客戶端使用公鑰加密共享秘鑰并發(fā)送個給服務(wù)器。
     3. 服務(wù)器對使用共享秘鑰加密作出回應(yīng)。

5.  HTTP與HTTPS的區(qū)別 

   1. HTTPS協(xié)議需要到ca申請證書，一般免費證書很少，需要交費。     

   2. HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS則是具有安全性的ssl加密傳輸協(xié)議。     

   3. HTTP和HTTPS使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。   

   4. HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全。

10.SSL

• SSL協(xié)議有三個特性
  1. 私密性：第一次握手之后指定了秘鑰，之后通信都會使用這個秘鑰加密解密。
  2. 確認(rèn)性：服務(wù)器和客戶都會被認(rèn)證，客戶的認(rèn)證是可選的。
  3. 可靠性：SSL協(xié)議會使用MAC對傳送的數(shù)據(jù)進行完整性檢查。
• TLS 運輸層安全協(xié)議
  • TSL協(xié)議是運輸層的協(xié)議，SSL是安全套接字層他兩有所區(qū)別。