三次握手的過程

關於http請求，一直都不是很明白，此次決定系統的整理一下。
在這以前先先整理一下SSL/TLS的運行機制：
在網絡通訊中，有竊聽風險、篡改風險、冒充風險，因此SSL/TLS的設計目的就是爲了達到：加密傳播、檢驗機制、配備身份證書。

三次握手的基本過程

在這實現的過程當中，最常聽到的就是3次握手，握手階段的基本過程就是：
1.客戶端向服務器索要並驗證公鑰；
2.雙方協商生成「對話祕鑰」；
3.雙方採用「對話祕鑰」進行加密通訊；

他們的具體過程是：

1.客戶端發出請求客戶端向服務端發出一個ClientHello

他主要包括的信息有

• 客戶端支持協議的版本

• 生成一個隨機數，用於「對話祕鑰」

• 客戶端支持加密的方法

• 客戶端支持壓縮的方法

2.服務器迴應（ServerHello）

他主要包括的信息有

• 確認使用協議的版本，須要跟客戶端一致。若是不一致，致使服務器關閉加密通道

• 生成一個隨機數，用於「對話祕鑰」

• 確認加密的方法（須要跟客戶端一致）

• 服務器證書（有可能會多一步，須要客戶端提供「客戶端證書」，像那些銀行的token）

3.客戶端迴應

判斷服務器證書，若是不是可信機關，或證書的域名和實際域名不一致，或者已通過期，則向訪問者提出警告，選擇是否繼續通訊；若是可靠，則從證書中取出服務器的公鑰，而後向服務器發出信息，這些信息包括：

• 一個隨機數，用於服務器公鑰加密，防止竊聽

• 編碼通知，表示隨後的信息都將用上方協定的加密方法和祕鑰發送

• 客戶端握手結束通知，也把以前發送的全部內容的hash值，而後傳遞給服務器

4.服務器最後的迴應

收到了客戶端的三個隨機數，pre-master key,會生成本次會話所用的「會話祕鑰」,而後發送內容

• 編碼改變通知，表示隨後的信息都將用來雙方商定的加密方法和祕鑰發送

• 服務器握手結束通知，表示服務器的握手階段已經結束，也發送前面內容全部內容的hash值，用於客戶端的校驗

握手結束，接下來是客戶端和服務端進入加密通訊，就徹底使用普通的Http協議，只不過「會話密鑰」加密內容（若是是http的話，沒有密鑰，這是http和https的區別）

爲何要有三個隨機數，來生成「會話密鑰」
由於SSL協議中的證書是靜態的，必須引入一種隨機數來保證密鑰的隨機性。pre master 不信任每一個主機都能產生徹底隨機的隨機數，可是三個隨機數就可能接近每增長一個自由度，隨機性也就會增長。

請求中經常使用到的code
400： Bad Request
401 Unauthorized
402
403 Forbidden
404 Not found

500 Internal Server Error501 Not Implemented502 Bad Gateway503 Service Unavailable504 Gateway Timeout505 HTTP version not supported