3.登錄協議Tcp-IPHTTPS

登錄和授權的區別

• 登錄：身份認證，確認【你是你】的過程
• 授權：由身份或持有的令牌確認享有某些權限（例如獲取用戶信息）。登錄實質上的目地也是爲了確認權限

在實際的應用中，多數場景下“登錄”和“授權”界限是模糊的

HTTP 中確認授權的兩種方式

1. 通過Cookie

2. 通過Authorization Header

   Cookie

   • 起源：“購物車”功能的需求，由Netscape 瀏覽器的開發團隊打造

   • 工作機制

     1. 服務器需要客戶端保存的內容，放在Set-CookieHeader裏返回，客戶端會自動保存。

     2. 客戶端保存的 Cookies，會在之後的所有請求裏都攜帶到 Cookie header 裏發回到服務器。

     3. 客戶端保存 Cookie 是按照服務器域名來分類的，例如 shop.com 發回的 Cookie 保存下倆後只會在請求 shop.com 時攜帶，請求其他***域名***的網站時不會攜帶

     4. 客戶端保存的 Cookie 在超時後會被刪除

        沒有設置超時時間的 Cookie（稱作 Session Cookie）在瀏覽器關閉後就會自動刪除

        服務器可以主動刪除還未過期的客戶端Cookie

   • 作用：

     • 會話管理：登錄狀態、購物車等
     • 個性化：用戶偏好、主題
     • Tracking：分析用戶行爲（很少用）

   • XSS（Cross-site scripting）（瞭解即可）：跨站腳本攻擊。即使用 JavaScript 拿到瀏覽器的 Cookie 之後，發送到自己的網站，以這種方式來盜取用戶的 Cookie。

     應對方式：Server 在發送 Cookie 時，敏感的 Cookie 加上 HttpOnly。

     HttpOnly–這個 Cookie 只能用於 HTTP 請求，不能被 JavaScript 調用。它可以防止本地代碼濫用 Cookie。

   • XSRF（Cross-site request -forgery）（瞭解即可）：跨站請求僞造。即在用戶不知情的情況下訪問已經保存了 Cookie 的網站，依次來越權操作用戶賬戶（例如盜用賬戶轉賬）。應對方式主要是從服務器安全角度考慮例如用Referer校驗。

     Referer校驗：Referer 一個header，用於告訴服務器該請求是從哪個頁面鏈接過來的，服務器因此可以獲得一些信息用於判斷處理。

   Authorization

   主要有兩種方式：Basic 和 Bearer

   • Basic：格式Authorization: Basic <Base64(username:password)>

   • Bearer:

     • 格式：Authorization: Beater <bearer token>
     • bearer token 的獲取方式：通過OAuth2 的授權方式

     OAuth2 的流程

     0. 第三方網站（你在訪問的網站）向授權方網站（例如QQ或微信）申請第三方合作，拿到 client id 和 client secret

     1. 授權方網站根據 client id，將第三方網站的信息和第三方網站需要的用戶權限展示給用戶，並詢問用戶是否同意授權

     2. 用戶點擊 “同意授權” 按鈕後，授權方網站將頁面跳轉回 第三方網站，並傳入Authorization code 作爲用戶認可的憑證。

     3. 第三方網站將 Authorization code 發送回自己的服務器

     4. 服務器將 Authorization code 和自己的 client secret 一併發送給授權方的服務器，授權方服務器在驗證通過後，放回 access token。注意，這一步需要加密傳輸

        – 以上 OAuth 流程結束。

     上面的過程結束之後，第三方網站的服務就可以使用 access token 作爲用戶授權的令牌，向授權方網站發送請求來獲取或操作用戶賬號。但這已經是 OAuth 流程之外了

     爲了安全 OAuth 引入Authorization code，並需要申請權限的第三方將 Authorization code發送回自己的服務器，再從服務器來獲取 access token ，而不是直接返回 access token 。OAuth 不強制授權流程必須使用 HTTPS，因此需要保證當通信路徑中存在竊聽者時，access token 不會被竊取到

     第三方 App 通過微信登錄的流程也是一個 OAuth2 的流程

     0. 第三方 App 向騰訊申請第三方授權合作，拿到 client id 和 client secret
     1. 用戶在使用第三方 App 時，點擊 “通過微信登錄“ ，第三方 App 使用微信 SDK 跳轉到微信，並傳入自己的 client id 作爲自己的身份標識
     2. 微信通過和服務器交互，拿到第三方 App 的信息，並顯示在界面中，然後詢問用戶是否同意授權該 App 使用微信來登錄
     3. 用戶點擊 ”使用微信登錄“ 後，微信將授權信息提交回服務器，然後跳轉回第三方 App，並傳入 Authorization code 作爲用戶認可的憑證
     4. 第三方 App 調用自己服務器的 ”微信登錄“ Api ，並傳入 Authorization code，然後等待服務器的響應
     5. 服務器收到客戶端的登錄請求後，拿收到的 Authorization code 和自己的 client secret 去向微信的第三方授權接口發送請求，微信在驗證通過後，返回 access token
     6. 服務器在收到 access token 後，立即拿着 access token 去向微信的用戶信息查詢接口 發送請求，微信通過驗證後，返回用戶信息
     7. 服務器收到用戶信息後，在自己的數據庫中爲用戶創建一個賬號，並使用從微信拿來的用戶信息填入自己的數據庫，以及將用戶的 id 和微信的 id 做關聯
     8. 用戶創建完成後，服務器向客戶端響應剛創建好的用戶信息
     9. 客戶端收到服務器響應，用戶登錄成功

   • Refresh token

     access token 有失效時間，在它失效後，調用 refresh token 的接口，傳入 refresh token 來獲取新的 access token

     Refresh token 是和 access token 同時返回的，類似於下面

     {	
      "token_type": "Bearer",
      "access_token": "xxxxx",
      "refresh_token": "xxxxx",
      "expires_time": "xxxxx"
      }
     

     使用 Refresh token 目的：安全

     由於 access token 有失效時間，即使 有人 偷竊到了 access token，他也只能使用一段時間；同時，由於 refresh token 永遠只存在與 第三方服務的房屋起中，因此refresh token 幾乎沒有失竊的風險

TCP / IP 協議族

概念

一系列協議組成的一個網絡分層模型

爲什麼要分層

因爲網絡的不穩定性

具體分層

• Application Layer 應用層：HTTP、FTP、DNS

  此層 定義數據格式 並按照對應的格式解讀數據

• Transport Layer 傳輸層：TCP、UDP

  此層 實現端口到端口的通信，保證數據傳輸的可靠性。進行包的分發（確認、重傳等）

• Internet Layer 網絡層：IP

  此層的主要工作是定義網絡地址、區分網段、子網內 Mac 尋址、對不同子網的數據包進行路由

• Link Layer 數據鏈路層：以太網、Wi-Fi

  此層的主要工作是對電信號進行分組並形成具有特定意義的數據幀，然後以廣播的形式通過物理介質發送給接口對網絡傳輸提供物理上的支持

TCP連接

什麼叫做連接

通信雙方建立確認【可以通信】，不會將對方的消息調起，即爲【建立連接】

TCP 連接的建立與關閉

• 連接：三次握手

  1. 客戶端向服務端發送TCP消息，表示自己要發送消息了–>

  2. 服務端收到消息後，發送消息表示，確認可以發送消息給自己，並告訴客戶端我也要給你發送消息了<–

  3. 客戶端收到消息後給服務到發送確認，表示服務端可以發送消息給自己–>

• 關閉：四次揮手

  1. 客戶端發送消息表示自己將不再發送消息–>
  2. 服務端收到關閉請求後，發送信息告訴客戶端自己知道了<–
  3. 服務端發送信息告訴客戶端自己將不在發送消息<–
  4. 客戶端收到關閉連接請求後，發送信息告訴服務端知道了–>

長連接

長連接就是不釋放的連接，強制不讓連接被關閉

爲什麼要長連接

以爲移動網絡並不在 Internet 中，而是在運營商的內網，並不具有真正的公網 IP ，因此當某個 TCP 連接在一段時間不通信之後，網關出於網絡性能考慮而關閉這條 TCP 連接和公網的的連接通道，導致這個 TCP 端口不能再收到外部通信消息，即 TCP 連接被動關閉

長連接的實現方式

心跳。在一定的間隔時間內，使用 TCP 連接發送超短無意義消息來讓網關不能將自己定義爲”空閒連接“，從而防止網關將自己的連接關閉

HPPS

• 定義

  HTTP over SSL 的簡稱，即工作在 SSL（或 TLS ）上的 HTTP。就是加密通信的的 HTTP

• 工作原理

  在客戶端和服務器只見協商出一套對稱密鑰，每次發送信息之前將內容加密，收到消息之後解密。打到內容的加密傳輸

• 爲什麼直接用非對稱加密？

  非對稱加密由於複雜的數學原理，因此計算相當複雜。如果完全使用非對稱加密來加密同喜內容，會嚴重影響網絡通信的性能。

• HTTPS 連接建立的過程

  1. Client Hello：客戶端發送簡單消息告訴服務器需要建立連接，包含有 可以接受的TLS版本、Cipher Suite（加密套件，可以接受的對稱加密算法、非對稱加密算法、hash算法）、客戶端隨機數

  2. Server Hello：服務器發送同意建立連接信息給服務器，包好服務器選擇的TLS版本、選擇的Cipher Suite和服務端隨機數

  3. 服務器發送證書給客戶端，包含有服務器公鑰、host、二級證書等。證書可以驗證服務端的身份。

  4. Per-master Secret：客戶端用服務器公鑰加密 Per-master Secret 信息給服務端。非對稱加密

     Master Secret：客戶端使用 客戶端隨機數、服務器隨機數、Per-master Secret 得到 Master Secret

     雙方使用 Master Secret計算出四個密鑰：客戶端加密密鑰、服務端加密密鑰、客戶端 MAC Secret、服務端 MAC Secret，MAC Secret用於簽名驗證身份

     HMAC （Hash-based Message Authenticate Code） 改良的 hash 算法，會先對 原消息 做一些操作後 再進行 hash。

  5. 客戶端發送信息表示要使用加密通信

  6. 客戶端發送：Finished，包含上述的所有（1-4）信息使用加密密鑰 加密，並用MAC Secret 簽名，服務器驗證通信的正確性

  7. 服務發送信息表示要使用加密通信

  8. 服務端發送：Finished，包含1-6的所有信息，使用加密密鑰 加密，並用MAC Secret 簽名，客戶端驗證通信的正確性

     以上後，客戶端開始發送HTTPS消息

Android中使用

• 正常情況下直接使用
• 需要自己寫證書驗證過程的場景
  • 用的是自簽名證書（例如只用於內網的 https ）
  • 證書信息不全，缺乏中間證書機構（可能性不大）
  • 手機操作系統較舊，沒有安裝最新加入的根證書