網絡之HTTP/HTTPS

夜闌臥聽風吹雨
鐵馬冰河入夢來

前言

大學老師曾經說過，計算機界有三本天書，分別是：數據結構、計算機組成原理、計算機網絡。因此網絡也是咱們從事計算機開發必須瞭解且掌握的一門技術，本文我將覺得所理解的網絡知識來用通俗的語言描述網絡

網絡七層模型

• 應用層

  訪問網絡服務的端口，如HTTP傳輸 ‘hello，world’

• 表示層

  提供數據格式轉換

• 會話層

  創建端鏈接並提供訪問驗證 如SSL/TLS認證

• 傳輸層

  UDP/TCP + ‘hello，world’

• 網絡層

  IP + UDP/TCP + ‘hello，world’

• 數據鏈路層

  MAC地址 + IP + UDP/TCP + ‘hello，world’ + 幀尾

• 物理層

  傳輸二進制 01010101001

HTTP

• 請求/相應報文

  **請求報文包括:**
        請求方法
        URL
        協議版本HTTP1.0
        首部字段名
        請求體 （POST請求）
    **響應報文包括:**
        版本
        狀態碼
        短語
        首部字段名
        響應實體

• 請求方法
  GET：

  表明獲取資源
     特色：
         安全：不該該引發Server端的任何狀態變化
         冪等：請求屢次的結果同樣
         可緩存：代理服務器能夠緩存

  POST：

  表明處理資源
     特色：
         不安全
         不冪等
         不可緩存

  HEAD
  OPTION
  PUT

• 狀態碼
  200：

  請求成功

  300：

  請求重定向

  400：

  因爲客戶端請求地址和參數引用的失敗

  500：

  服務端緣由

• 鏈接接創建流程
  TCP:

  三次握手、四次揮手

• HTTP特色
  無鏈接：

  每次請求都須要創建TCP鏈接

  無狀態

  不會保存記錄用戶的信息和狀態

• 解決HTTP無鏈接問題
  在同一條TCP上面產生屢次HTTP請求
  頭部字段（Header）：

  Connection:keep-live
     Time: 20 在必定時間內不須要再次創建TCP鏈接
     Max： 在創建鏈接時間內最多請求次數

  判斷一個請求的結束？

  Content-length
     空chunked

• 解決HTTP無狀態問題
  解決方案：Cookie / Session

HTTPS與HTTP的區別

HTTPS=HTTP+SSL/TLS：

在應用層和傳輸層之間增長了 SSL/TLS認證
查閱多方資料：SSL/TLS認證在會話層

HTTPS連接創建流程

• Client->Server：發送支持的TLS版本號，支持的加密算法，random number C
• Server->Client：商定的加密算法，random number S，server 證書（包括公鑰）
• Client驗證證書
• Client組裝會話密鑰
• Client經過server的公鑰對預主密鑰進行加密傳輸
• Server經過密鑰解密得要預主密鑰
• Server組裝會話密鑰
• Client發送加密的握手消息 （驗證）
• Server發送加密的握手消息 （驗證）

HTTPS的加密手段

• 創建鏈接的過程使用非對稱加密（耗時）
• 後續通訊過程使用對稱加密

非對稱加密

• 私鑰加密公鑰解密
• 公鑰加密私鑰解密
• 公鑰：在網絡中傳輸，密鑰保存在服務端，因此非對稱加密相對安全

對稱加密

• 一把祕鑰在網絡中傳遞，不安全

TCP 控制傳輸協議

特色：

• 面向鏈接

  數據開始傳輸以前創建鏈接（三次握手）
    數據傳輸以後釋放鏈接（四次揮手）

• 可靠傳輸

  無差錯、不丟失、不重複、按序到達、超時重傳

• 面向字節流

  會自動根本TCP自身狀況傳輸字節大小，不受發送方控制，
    最大傳輸單元 = 1500 =20個IP頭+20個tcp頭+data

• 流量控制

  滑動窗口協議

• 擁塞控制

  慢開始、擁塞避免
        指數規律增加（報文個數：一、二、四、八、16） 
        達到門限初始值：開始加法增大
        網絡擁塞的時候：乘法減少到新的門限值
    快恢復、快重傳

滑動窗口協議

發送窗口以很快的速率去發送消息時，因爲服務端接收窗口比較小，
此時接收窗口經過向TCP的報文首部字段去更改窗口值去更正或者調整發送端的發送速率

UDP 用戶數據協議

特色

無鏈接：不須要創建鏈接流程
最大能力傳輸： 不保證按序到達
面向報文：不合並 不拆分

功能

複用、分用

DNS解析

域名到IP地址的映射，解析請求採用UDP數據報且明文的形式
使用DNS協議向DNS服務器的53端口進行請求

DNS解析過程

- Client經過DNS協議向DNS服務器請求相應域名的解析 
- DNS服務器返回給客戶端相應的IP
- 客戶端拿到IP再向服務端發送網絡請求

DNS解析查詢方式

• 遞歸查詢

  依次詢問返回：Client->本地DNS->根域DNS->頂級DNS->權限DNS

• 迭代查詢

  Client：  本地DNS、根域DNS、頂級DNS、權限DNS互相詢問

DNS劫持

**緣由在公網中存在第三方釣魚DNS服務器攔截咱們的DNS解析請求，返回給咱們錯誤的IP**

怎樣解決DNS劫持

httpDNS

DNS解析：使用DNS協議向DNS服務器的53端口進行請求
   HTTPDNS解析：使用HTTP協議向DNS服務器的80端口進行解析，不會產生DNS解析就不會有DNS劫持
   http://119.29.29.29/d?dn=www.xiaozhu.com&ip=172.18.134.109

長鏈接

Client <-(長連通道)>長連server(代理服務器) <-> API server
Client的HTTP請求是經過代理服務器經過內網專線進行內網的DNS解析這樣就規避了公網DNS解析劫持的問題

DNS劫持和HTTP的關係？

沒有關係

由於DNS解析發生在HTTP創建鏈接以前
由於DNS解析請求使用的UDP數據報，端口號53

DNS解析轉發

Client->中國移動DNS->中國電信DNS->中國聯通DNS ，因爲協議限制，致使各個DNS解析商互相推脫，形成DNS解析緩慢，從而致使網絡請求慢

Session/Cookie

對HTTP無狀態的補償，例如client發送請求以後，再次請求 沒法記住用戶

Cookie

用來記錄用戶狀態，區分用戶，狀態保存在客戶端
怎樣保證cookie安全？

對cookie進行加密處理
只在HTTPS上攜帶cookie（推薦）
設置cookie爲HTTPonly ，防止跨站腳本攻擊

怎樣修改cookie

新cookie覆蓋舊cookie
覆蓋規則：name、path、domian須要與原cookie一致

怎樣刪除cookie

新cookie覆蓋舊cookie
覆蓋規則：name、path、domian須要與原cookie一致
設置cookie的expire=過去的某個時間點或者設置maxAge=0

session
用來記錄用戶狀態，區分用戶，狀態保存在服務端端

工做流程
    Client向server發送消息，server記錄用戶狀態生成sessionID
    經過存在cookie中傳給client