各層協(xié)議

1.HTTP協(xié)議

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

1. RTT

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

2. HTTP/1.0 

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

3. HTTP/1.1

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

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

1. 請(qǐng)求報(bào)文

1. 1. 請(qǐng)求報(bào)文有3部分組成：

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

   2. 請(qǐng)求方法有8種

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

   3. 自定義方法

      • 請(qǐng)求方法可以自定義  了解WebDAV

   4. 首部行

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

      1. 首部行有四種類型

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

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

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

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

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

2. 響應(yīng)報(bào)文

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

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

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

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

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

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

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

3.POST 和 GET

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

4.TCP報(bào)文格式

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

1. 1. TCP報(bào)文首部

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

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

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

5.三次握手

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

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

6.四次揮手

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

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

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

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

1. HTTP1.1  分塊傳輸編碼

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

   • 分塊傳輸好處

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

8.加密方式

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

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

9.HTTPS

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

4. HTTPS連接方式

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

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

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

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

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

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

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

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

10.SSL

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