Http&Https

Http&Https

什麼是協議？

• 計算機之間爲了實現網絡通信而達成的一種“約定”或者“規則”。

HTTP協議是什麼？

• 超文本傳輸協議,它是從WEB服務器傳輸超文本標記語言(HTML)到本地瀏覽器的傳送協議。HTPP有多個版本，目前廣泛使用的是HTTP/1.1版本。
• 用於客戶端和服務器端之間的通信

TCP/IP 協議族

• TCP/IP 是互聯網相關的各類協議族的總稱
• HTTP協議屬於TCP/IP 協議族的子集

TCP/IP 的分層管理

• 應用層: 決定了向用戶提供應用服務時通信的活動。

• 傳輸層: 提供處於網絡連接中的兩臺計算機之間的數據傳輸

• 網絡層: 處理在網絡上流動的數據包,在衆多的路徑中選擇一條傳輸路線。

• 數據鏈路層: 用來處理連接網絡的硬件部分。

• TCP/IP層次化的好處: 如果互聯網只由一個協議統籌，某個地方需要改變設計時，就必須把所有部分整體替換掉。而分層之後只需把變動的層替換掉即可。把各層之間的接口部分規劃好之後，每個層次內部的設計就能夠自由改動了。

HTTP特點

• http協議支持客戶端/服務端模式，也是一種請求/響應模式的協議。
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。
• 靈活：HTTP允許傳輸任意類型的數據對象。傳輸的類型由Content-Type加以標記。
• 無連接：限制每次連接只處理一個請求。服務器處理完請求，並收到客戶的應答後，即斷開連接，但是卻不利於客戶端與服務器保持會話連接，爲了彌補這種不足，產生了兩項記錄http狀態的技術，一個叫做Cookie,一個叫做Session。(HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接, 持久連接的特點是，只要任意一端 沒有明確提出斷開連接，則保持TCP連接狀態。HTTP/1.1 中，所有的連接默認都是持久連接)
• 無狀態：HTTP 協議自身不對請求和響應之間的通信狀態進行保存。這是爲了 更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設 計成如此簡單的。於是引入了Cookie技術,使得Http具有保持狀態功能。(客戶端發起請求後, 服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的Cookie後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器上的記錄，最後得到之前的狀態信息。)

HTTP報文

請求報文

• 請求行(包含請求方法，請求URI和HTTP 版本)
• 請求頭(包含表示請求各種條件和屬性的各類首部。)
• 請求體

響應報文

• 響應行(HTTP 版本,狀態碼，狀態文字)
• 響應頭包含表示響應的各種條件和屬性的各類首部。
• 響應體

狀態碼

1XX Informational（信息性狀態碼） 接收的請求正在處理
2XX Success（成功狀態碼） 請求正常處理完畢
3XX Redirection（重定向狀態碼） 需要進行附加操作以完成請求
4XX Client Error（客戶端錯誤狀態碼） 服務器無法處理請求
5XX Server Error（服務器錯誤狀態碼） 服務器處理請求出錯

Https

• HTTP+ 加密(SSL) + 認證(CA證書) + 完整性保護(MD5加鹽散列) =HTTPS
• HTTPS 是身披 SSL 外殼的 HTTP
• HTTPS 並非是應用層的一種新協議。只是HTTP通信接口部分用SSL和TLS協議替而已。

HTTP 的缺點:

• 通信使用明文（不加密），內容可能會被竊聽
• 不驗證通信方的身份，因此有可能遭遇僞裝(CA證書)
• 無法證明報文的完整性，所以有可能已遭篡改;請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊(MD5 和 SHA-1 等散列值校驗的方法)

數據的加密

• 對稱加密：加密和解密數據使用同一個密鑰。這種加密方式的優點是速度很快。
• 非對稱加密：加密和解密使用不同的密鑰，叫公鑰和私鑰。數據用公鑰加密後必須用私鑰解密，數據用私鑰加密後必須用公鑰解密。一般來說私鑰自己保留好，把公鑰公開給別人，讓別人拿自己的公鑰加密數據後發給自己，這樣只有自己才能解密。 這種加密方式的特點是速度慢，CPU 開銷大，常見非對稱加密算法有RSA。
• Hash：hash是把任意長度數據經過處理變成一個長度固定唯一的字符串，但任何人拿到這個字符串無法反向解密成原始數據（解開你就是密碼學專家了），Hash常用來驗證數據的完整性。常見Hash算法有MD5、SHA1、SHA256。

HTTPS的原理

• 思路一(採用非對稱加密):
  A和B通信, B有一對密鑰(公鑰和私鑰),B把公鑰公開;
  A可以用B的公鑰對信息進行加密,B收到信息後用私鑰解密;
  同理,A也有一對密鑰(公鑰和私鑰),A把公鑰公開;
  B可以用A的公鑰對信息進行加密,B收到信息後用私鑰解密;
  這樣A和B可以愉快的交流;但是非對稱加密的效率特別低下;

• 思路二(對稱加密+非對稱加密):
  A和B通信,A有對稱密鑰;
  B有一對密鑰(公鑰和私鑰),B把公鑰公開;
  A用B的公鑰對自己的對稱密鑰進行加密,B收到加密後的密鑰後用私鑰解密,然後得到對稱密鑰;
  接下來,A和B就可以用對稱密鑰進行交流了;

• HTTPS 採用了混合加密機制(對稱加密+非對稱加密)

證明公開密鑰正確性的證書

• 公鑰加密方式還是存在着一些問題, 那就是無法證明公鑰本身就是貨真價實的公鑰。比如，正準備和某臺服務器建立非對稱加密方式下的通信時，如何證明收到的公鑰就是原本預想的那臺服務器發行的公鑰。或許在公鑰傳輸途中，真正的公鑰已經被攻擊者替換掉了。 爲了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公鑰證書。

• C(數字證書認證機構) 處於A與B雙方都可信賴的第三方機構的立場上。

• C公開了自己的公鑰。B找C做了一個證書，證書上有自己的名字、公鑰、公證人C的名字，同時把這些信息通過 Hash (sha256)處理後請求 C用自己的私鑰進行加密（爲什麼用 Hash 處理？因爲東西太多非對稱加密很費時）得到數字簽名，也放到證書上。於是B把證書(B的公鑰+C認證後的數字簽名)通報給所有人。A這次得到了證書，發現上面的公證人是C，於是先用C的公鑰對證書上被C 的私鑰加密後的字段進行解密，得到元素數據的 Hash。再對證書上的公鑰進行 Hash和剛剛解密的 Hash 進行比對。如果比對成功表示證書上的信息無誤，且是由C擔保的。這時候A確信證書上的公鑰就是B的。任何人因爲沒有C的私鑰都無法僞造證書。

爲什麼不一直使用 HTTPS ?

• 與純文本通信相比，加密通信會消耗更多的CPU及內存資源。如果每次通信都加密，會消耗相當多的資源。因此，非敏感信息則使用 HTTP 通信，包含個人信息等敏感數據時，才利用 HTTPS 加密通信。
• 證書必須向認證機構（CA）購買,價格高昂。