花了三天時間讀完圖解HTTP，今天花一點時間記錄一下自己的感悟，也練一下自己的表達能力。
首先我們需要知道，HTTP是一個應用層協議。這裡，我們是否想過為什麼HTTP是應用層協議，而不是網絡層協議，傳輸層協議，這些層協議的區別又是什麼。應用層
協議定義了在不同端操作系統上的應用程序進程如何互相傳遞報文，包括(1)交換報文的類型，如請求報文和回應報文，（2）各種報文類型的語法，如報文中各個字段的詳細描述，(3)字段的語義，即每種字段中信息的含義，(4)進程何時發送報文以及何時對報文進行響應。我們知道，在HTTP裡面定義一些請求報文的方法，比如get，post，這些字段用來告知以什麼方式去請求報文，而不去管報文如何在網絡中進行傳輸，也不用管報文到達沒有，這就說明HTTP只管如何去請求報文，請求報文的方式是什麼，所以HTTP是一個應用層協議，而不是傳輸層或網絡層協議。傳輸層的主要作用是提供兩臺機器進程之間的通信，其中也會有流量控制，擁塞控制等功能，網絡層主要是負責對路由包進行存儲和轉發，路由選擇等。
扯遠了，迴歸正題。HTTP是一個應用層協議，並且採用tcp傳輸數據。HTTP是怎麼產生的呢，在最開始互聯網還在萌芽階段的時候，蒂姆-伯納斯-李提出了一種能讓
遠隔兩地的學者共享知識的設想。最初的設想就是藉助多文檔之間相互關聯形成的超文本，連成可互相參閱的WWW（world wide web）。WWW包括三項技術，(1)把SGML(standard generalized markup language，標準通用標記語言)作為頁面的文本標記語言HTML(hypertext markup language)，(2)作為文本傳輸協議的HTTP，(3)指
定文檔地址的URL(uniform resource locator，統一資源定位符)。所以可以說最初HTTP是用來傳輸文本的，也正是這樣的一個功能，使得HTTP設計的非常簡單。
HTTP協議的設計方式如下：(1)用來服務器端和客戶端之間的通信，他能準確區分一條通信線路上的哪一端是服務器端和哪一端是客戶端。並且，他規定請求從客戶端
發出，服務器端響應該請求並返回，也就是從客戶端開始建立連接，服務器沒有收到請求就不響應，並且，客戶端不能接受除了響應以外的所有指令。(2)通過請求和響應的交換來達成通信，每次通信時都要建立一次TCP連接，通信完成之後就釋放tcp連接。這樣子的操作方式在早期傳送文本文檔的時候還挺方便，但是到了現在，網站裡面一般都會有很多圖片，訪問網站的時候也會訪問這些圖片，如果還按照以前的方式一次訪問建立一次連接，太浪費資源了，也會嚴重拖慢速度，所以到了後來，在HTTP1.1，添加了alive，也就是長連接。長連接也使多數請求以管線化方式發送成了可能，以前是發送一個請求並等待回應之後才能發送下一個請求，有了長連接就可以一個接一個的發請求，而不用等到服務器回應請求。(3)HTTP不保存狀態，每次有訪問過來的時候就處理，但是不知道是誰，這樣的好處就是節約CPU資源，但是這樣的缺點就是登錄需要身份驗證的網站時，每次跳轉頁面都要重新登錄。也是因為簡單，HTTP協議才會用到各種場景裡面。但是有時候又需要保存狀態，比如web購物網站，這樣就引入了cookie技術，客戶端首次登錄時，服務器對生成一個sid然後發送給客戶端，客戶端下次發送請求的時候就將sid包含在報文裡面，服務器收到之後對比服務器裡面的記錄，就可以知道這個客戶端是否登錄了。(4)通過URI來定位互聯網上的資源。(5)定義一些方法來告知服務器如何訪問他，比如post，get，put等。這裡可以講一下post和get的區別。post主要用於向服務器提交表單信息，器內容是放在報文主體裡面的，理論上長度沒有限制，而get主要是用來像服務器申請資源，他提交的數據會放在URL之後，以？進行分割，參數之間以&相連，長度有限制。post比get稍微安全一點。像服務器提交請求的方法除了post，get，還有head，類似get請求，但是返回的響應中沒有具體內容，用於獲取報頭，確認URI的有效性和資源更新時間等。這三個是HTTP1.0定義的，HTTP1.1新加了一下幾種，put，delete，connect，options，trace。connect方法要求在於代理服務器通信時建立隧道，實現用隧道協議進行TCP通信，主要只用SSL或者TLS協議將通信內容加密後經網絡隧道傳輸。options用來查詢針對請求URI指定的資源支持的方法。trace用來查詢發出的請求時怎樣被加工修改的，但是容易遭到跨站攻擊，所以也不常用。
從以上的HTTP設計方式可以看出，HTTP很簡單。他有三個缺點。(1)明文傳輸，這就容易被竊聽,(2)傳輸時不進行身份認證，容易被遭到偽裝攻擊，(3)無法保證報文
的完整性，所以會被篡改，因此出現了HTTPS。首先，HTTPS並不是新的協議，而是將HTTP協議加上加密，認證，完整性保護三個功能，即HTTPS=HTTP+加密+認證+完整性保護。他的實現方法是在HTTPS上套了一層ssl協議，本來HTTP直接和tcp通信的，HTTPS的做法是HTTP先和ssl通信，ssl再和tcp通信。那麼ssl協議有又是如何完成這些功能的呢？在瞭解這些問題之前，先了解加密方式。加密方式主要有兩種，一總是對稱加密，一種是非對稱加密，對稱加密又稱共享密鑰加密，這種加密方法的方式是加密和解密都用同一個密鑰，因此密鑰也會發給對方。但是這樣有一個問題，密鑰一旦對中間人截獲，就能獲取所有的信息，這和不加密沒兩樣，如果能保證密鑰能安全傳輸的話，那就說明信息也能安全傳輸。非對稱加密算法又稱為公開密碼加密法，這種加密方式有兩把密鑰，一把公鑰，一把私鑰。當用公鑰加密之後，只能用私鑰解開，就算中間人獲取了公鑰和密文，他也幾乎不可能解開，就現有的技術來說。這種加密方法很好的解決了共享密鑰的困境，但是他又有一個問題，如果公鑰被中間人截獲了，中間人發過來一個假的公鑰，那發送發用假的公鑰加密之後，密文被捕獲，中間人照樣可以用自己的私鑰解開密文。所以，這裡引入了一個認證機制。認證是由一個有權威的中間機構進行的，他是發送發和接受方都信任的一個機構，我們俗稱CA認證機構。首先，服務器端將自己的公鑰提交到CA認證機構，CA認證機構用自己的私鑰對服務器端的公鑰部署數字簽名，並頒發證書，這個證書和公鑰就綁定在一起。當客戶端要和服務器端進行通信時，服務器端將這個證書發給客戶端，客戶端通過CA認證機構的公鑰進行驗證證書上面的數字簽名，如果驗證通過，則說明一、認證服務器的公開密鑰是真實有效的數字證書認證機構，二、服務器的公開密鑰是值得信賴的。這裡，CA認證機構的公開密鑰需要安全的轉交給客戶端，如何轉交是一個麻煩事，所以很多瀏覽器就直接集成認證機構的公鑰。HTTPs採用兩種加密方式並用的方法，客戶端和服務器端先建立ssl連接，然後客戶端生成一個對稱加密密鑰，然後通過ssl傳輸這個密鑰，往後就用這個對稱加密密鑰來加密密文。
HTTPS的通信步驟大概如下：
1、客戶端發送client hello報文開始ssl通信。報文中包含客戶端支持的ssl的指定版本、加密組件列表(所使用的加密算法以及密鑰長度等)
2、服務器可進行ssl通信時，會以serverhello報文作為回應。客戶端一樣，在報文中包含ssl版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
3、服務器發送certificate報文。報文中包含公開密鑰證書。
4、服務器發送server hello done 報文通知客戶端，最初階段的ssl握手協商部分結束。
5、ssl第一次握手結束後，客戶端以client key exchange報文作為應答。報文中包含通信加密中使用的一種被稱為pre-master secret的隨機密碼串，改密碼串就是一個對稱加密密鑰，該密鑰被步驟三中的密鑰加密過了。
6、客戶端繼續發送chang cipher spec報文，該報文會提示服務器，在此報文之後的通信會採用pre-master secret密鑰加密。
7、客戶端發送finish報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以服務器能否正確解密該報文作為判定標準。
8、服務器同樣發送change cipher spec報文。
9、服務器同樣發送finish報文。
10、客戶端和服務器端的finish報文交換完畢之後，ssl連接就算建立完成，通信就會受到ssl保護，從此處開始就會進行應用層協議通信，及發送HTTP請求。以上的任何步驟出了問題，都不能建立HTTPS連接。
當然，HTTPS也有缺點，他比HTTP慢2-100倍。因為他要進行ssl通信，整體上通信量會增加，這是一種慢的方式。第二種慢是因為他要加密解密，會耗費大量cpu以及內存資源。
以上說的都是服務器端證書，當然，HTTPS還可以使用客戶端證書，以客戶端證書進行客戶端認證，證明服務器正在通信的對方始終是預料之內的客戶端，其作用和服務器證書一樣。但是客戶端證書要錢，每個客戶端都需要一張證書，這筆開銷不小。現狀是，安全性極高的認證機構可頒佈客戶端證書但僅用於特殊用途的業務，比如那些可支撐客戶端支出費用的業務，網上銀行就是其中一個例子。
為了保證報文的完整性，應用層在發送數據時會附加一種叫MAC（message authentication code）的報文摘要，這個可以查知報文是否遭到篡改。
閱讀更多 胖胖的小迪 的文章
