1. 基礎概念篇
1.1介紹
HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。
HTTP協議（HyperText Transfer Protocol，超文字傳輸協議）是用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。
HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型。HTTP是一個無狀態的協議。
1.2 在TCP/IP協議棧中的位置
HTTP協議通常承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了我們常說的HTTPS。如下圖所示：
首先，糾正一下我以前一直誤解的概念，我一直以為Http和Tcp是兩種不同的，但是地位對等的協議，雖然知道TCP是傳輸層，而http是應用層。今天學習了下，知道了 http是要基於TCP連線基礎上的，簡單的說，TCP就是單純建立連線，不涉及任何我們需要請求的實際資料，簡單的傳輸。http是用來收發資料，即實際應用上來的。
預設HTTP的埠號為80，HTTPS的埠號為443。
1.3 HTTP的請求響應模型
HTTP協議永遠都是客戶端發起請求，伺服器回送響應。見下圖：
這樣就限制了使用HTTP協議，無法實現在客戶端沒有發起請求的時候，伺服器將訊息推送給客戶端。
HTTP協議是一個無狀態的協議，同一個客戶端的這次請求和上次請求是沒有對應關係。
注意：客戶端與伺服器的角色不是固定的，一端充當客戶端，也可能在某次請求中充當伺服器。這取決與請求的發起端。HTTP協議屬於應用層，建立在傳輸層協議TCP之上。客戶端通過與伺服器建立TCP連線，之後傳送HTTP請求與接收HTTP響應都是通過訪問Socket介面來呼叫TCP協議實現
1.4 工作流程
一次HTTP操作稱為一個事務，其工作過程可分為四步：
1）首先客戶機與伺服器需要建立連線。只要單擊某個超級連結，HTTP的工作開始。
2）建立連線後，客戶機傳送一個請求給伺服器，請求方式的格式為：統一資源識別符號（URL）、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。
3）伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的程式碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。
4）客戶端接收伺服器所返回的資訊通過瀏覽器顯示在使用者的螢幕上，然後客戶機與伺服器斷開連線。
如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到客戶端，有螢幕輸出。對於使用者來說，這些過程是由HTTP自己完成的，使用者只要用滑鼠點選，等待資訊顯示就可以了。
1.5http發展歷史
HTTP/1.0 標準於 1996 年 5 月作為第一份標準被公佈，它被記載於 RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0
HTTP/1.1 標準於 1999 年 6 月被公佈，截止到目前它應該是最主流的 HTTP 協議版本，它被記載於 RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1
HTTP/2 標準於 2015 年 5 月被正式釋出，它被記載於 RFC7540 - Hypertext Transfer Protocol -- HTTP/2
它的特點是
① 採用二進位制而非明文來打包，
② 多路複用，
③ 修復隊頭堵塞，
④ 允許設定設定請求優先順序，
⑤ 伺服器推送，
⑥ WebSocket 等等。
HTTP/2為什麼是二進位制？
比起像HTTP/1.x這樣的文字協議，二進位制協議解析起來更高效、“線上”更緊湊，更重要的是錯誤更少。
為什麼 HTTP/2 需要多路傳輸?
HTTP/1.x 有個問題叫線端阻塞(head-of-line blocking), 它是指一個連線(connection)一次只提交一個請求的效率比較高, 多了就會變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個問題, 但是效果並不理想(資料量較大或者速度較慢的響應, 會阻礙排在他後面的請求). 此外, 由於網路媒介(intermediary )和伺服器不能很好的支援流水線, 導致部署起來困難重重。而多路傳輸(Multiplexing)能很好的解決這些問題, 因為它能同時處理多個訊息的請求和響應; 甚至可以在傳輸過程中將一個訊息跟另外一個摻雜在一起。所以客戶端只需要一個連線就能載入一個頁面。
訊息頭為什麼需要壓縮?
假定一個頁面有80個資源需要載入（這個數量對於今天的Web而言還是挺保守的）, 而每一次請求都有1400位元組的訊息頭（著同樣也並不少見，因為Cookie和引用等東西的存在）, 至少要7到8個來回去“線上”獲得這些訊息頭。這還不包括響應時間——那只是從客戶端那裡獲取到它們所花的時間而已。這全都由於TCP的慢啟動機制，它會基於對已知有多少個包，來確定還要來回去獲取哪些包 – 這很明顯的限制了最初的幾個來回可以傳送的資料包的數量。相比之下，即使是頭部輕微的壓縮也可以是讓那些請求只需一個來回就能搞定——有時候甚至一個包就可以了。這種開銷是可以被節省下來的，特別是當你考慮移動客戶端應用的時候，即使是良好條件下，一般也會看到幾百毫秒的來回延遲。
伺服器推送的好處是什麼？
當瀏覽器請求一個網頁時，伺服器將會發回HTML，在伺服器開始傳送JavaScript、圖片和CSS前，伺服器需要等待瀏覽器解析HTML和傳送所有內嵌資源的請求。伺服器推送服務通過“推送”那些它認為客戶端將會需要的內容到客戶端的快取中，以此來避免往返的延遲。
2. http請求
下圖是在網上找的一張圖，覺得能很好的表達HTTP請求的所傳送的資料格式。
由上圖可以看到，http請求由請求行，訊息報頭，請求正文三部分構成。
HTTP請求狀態行
請求行由請求Method, URL 欄位和HTTP Version三部分構成, 總的來說請求行就是定義了本次請求的請求方式, 請求的地址, 以及所遵循的HTTP協議版本例如：
GET /example.html HTTP/1.1 (CRLF)
複製程式碼未完待續。。。
3.HTTP的五大特點
- 支援客戶/伺服器模式。
- 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
- 靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
- 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。早期這麼做的原因是請求資源少，追求快。後來通過Connection: Keep-Alive實現長連線
- 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
非持久連線和持久連線
在實際的應用中，客戶端往往會發出一系列請求，接著伺服器端對每個請求進行響應。對於這些請求|響應，如果每次都經過一個單獨的TCP連線傳送，稱為非持久連線。反之，如果每次都經過相同的TCP連線進行傳送，稱為持久連線
非持久連線在每次請求|響應之後都要斷開連線，下次再建立新的TCP連線，這樣就造成了大量的通訊開銷。例如前面提到的往返時間(RTT) 就是在建立TCP連線的過程中的代價。
非持久連線給伺服器帶來了沉重的負擔，每臺伺服器可能同時面對數以百計甚至更多的請求。持久連線就是為了解決這些問題，其特點是一直保持TCP連線狀態，直到遇到明確的中斷要求之後再中斷連線。持久連線減少了通訊開銷，節省了通訊量。
HTTP優化方案
- TCP複用，TCP連線複用是將多個客戶端的HTTP請求複用到一個伺服器端的TCP連線上，HTTP複用是指一個一個客戶端的多個HTTP請求通過一個TCP連線進行處理。
- 內容快取。將經常用到的內容進行快取起來，那麼客戶端就可以直接在記憶體中獲取相應的資料了。
- 壓縮，將文字資料進行壓縮，減少寬頻
- SSL加速。使用SSL協議對HTTP協議進行加密，在通道內加密並加速
- TCP緩衝：通過TCP緩衝技術，可以提高伺服器端響應事件和處理效率，減少由於通訊鏈路問題給伺服器造成連線負擔.
4.HTTP和HTTPS
HTTP的不足
- 通訊使用明文(不加密),內容可能會被竊聽
- 不驗證通訊方的身份,因此有可能遭遇偽裝
- 無法證明報文的完整性,所以有可能已遭篡改
HTTPS介紹
HTTP 協議中沒有加密機制,但可以通過SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協議)的組合使用,加密 HTTP 的通訊內容。屬於通訊加密，即在整個通訊線路中加密。
HTTP + 加密 + 認證 + 完整性保護 = HTTPS（HTTP Secure ）
複製程式碼HTTPS 採用共享金鑰加密（對稱）和公開金鑰加密（非對稱）兩者並用的混合加密機制。若金鑰能夠實現安全交換,那麼有可能會考慮僅使用公開金鑰加密來通訊。但是公開金鑰加密與共享金鑰加密相比,其處理速度要慢。
所以應充分利用兩者各自的優勢, 將多種方法組合起來用於通訊。 在交換金鑰階段使用公開金鑰加密方式,之後的建立通訊交換報文階段 則使用共享金鑰加密方式。
HTTPS握手過程的簡單描述如下：
1，瀏覽器將自己支援的一套加密規則傳送給網站。
伺服器獲得瀏覽器公鑰
2，網站從中選出一組加密演算法與HASH演算法，並將自己的身份資訊以證照的形式發回給瀏覽器。證照裡面包含了網站地址，加密公鑰，以及證照的頒發機構等資訊。
瀏覽器獲得伺服器公鑰
3，獲得網站證照之後瀏覽器要做以下工作：
- 驗證證照的合法性（頒發證照的機構是否合法，證照中包含的網站地址是否與正在訪問的地址一致等），如果證照受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證照不受信的提示。
- 如果證照受信任，或者是使用者接受了不受信的證照，瀏覽器會生成一串隨機數的密碼（接下來通訊的金鑰），並用證照中提供的公鑰加密（共享金鑰加密）。
- 使用約定好的HASH計算握手訊息，並使用生成的隨機數對訊息進行加密，最後將之前生成的所有資訊傳送給網站。
4，網站接收瀏覽器發來的資料之後要做以下的操作：
- 使用自己的私鑰將資訊解密取出密碼，使用密碼解密瀏覽器發來的握手訊息，並驗證HASH是否與瀏覽器發來的一致。
- 使用密碼加密一段握手訊息，傳送給瀏覽器。
HTTPS的不足
加密解密過程複雜，導致訪問速度慢
加密需要認向證機構付費
整個頁面的請求都要使用HTTPS