筆記-HTTP及HTTPS
筆記-HTTP及HTTPS
1. HTTP
1.1. 簡介
HTTP:hyper text transfer protocol 超文字傳輸協議
http常用請求方式，method get,post,head,put,delete
1.2. HTTP協議版本更替
HTTP/0.9：HTTP協議的最初版本，功能簡陋，僅支援請求方式GET，並且僅能請求訪問HTML格式的資源。
HTTP/1.0：在0.9版本上做了進步，增加了請求方式POST和HEAD；不再侷限於0.9版本的HTML格式，根據Content-Type可以支援多種資料格式，即MIME多用途網際網路郵件擴充套件，例如text/html、image/jpeg等；同時也開始支援cache，就是當客戶端在規定時間內訪問統一網站，直接訪問cache即可。
但是1.0版本的工作方式是每次TCP連線只能傳送一個請求，當伺服器響應後就會關閉這次連線，下一個請求需要再次建立TCP連線，就是不支援keepalive。
HTTP/1.1：解決了1.0版本的keepalive問題，1.1版本加入了持久連線，一個TCP連線可以允許多個HTTP請求； 加入了管道機制，一個TCP連線同時允許多個請求同時傳送，增加了併發性；新增了請求方式PUT、PATCH、DELETE等。
但是還存在一些問題，服務端是按佇列順序處理請求的，假如一個請求處理時間很長，則會導致後邊的請求無法處理，這樣就造成了隊頭阻塞的問題；同時HTTP是無狀態的連線，因此每次請求都需要新增重複的欄位，降低了頻寬的利用率。
HTTP/2.0：為了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增加雙工模式，即不僅客戶端能夠同時傳送多個請求，服務端也能同時處理多個請求，解決了隊頭堵塞的問題；HTTP請求和響應中，狀態行和請求/響應頭都是些資訊欄位，並沒有真正的資料，因此在2.0版本中將所有的資訊欄位建立一張表，為表中的每個欄位建立索引，客戶端和服務端共同使用這個表，他們之間就以索引號來表示資訊欄位，這樣就避免了1.0舊版本的重複繁瑣的欄位，並以壓縮的方式傳輸，提高利用率。
另外也增加伺服器推送的功能，即不經請求服務端主動向客戶端傳送資料。
當前主流的協議版本還是HTTP/1.1版本。
1.3. 請求報文
訊息結構
請求行：包括請求方式Method、資源路徑URL、協議版本Version；
請求頭：包括一些訪問的域名、使用者代理、Cookie等資訊；
請求正文：就是HTTP請求的資料。
get的請求比較簡單，一般沒有什麼正文，post的內容會較多
1.3.1. 請求方法
根據HTTP標準，HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法
| 序號 |
方法 |
描述 |
| 1 |
GET |
請求指定的頁面資訊，並返回實體主體。 |
| 2 |
HEAD |
類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 |
| 3 |
POST |
向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 |
| 4 |
PUT |
從客戶端向伺服器傳送的資料取代指定的文件的內容。 |
| 5 |
DELETE |
請求伺服器刪除指定的頁面。 |
| 6 |
CONNECT |
HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。 |
| 7 |
OPTIONS |
允許客戶端檢視伺服器的效能。 |
| 8 |
TRACE |
回顯伺服器收到的請求，主要用於測試或診斷。 |
1.4. 響應報文
HTTP響應報文也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文
1.5. HTTP狀態碼
瀏覽器向網頁伺服器發出請求，網頁伺服器會返回一個包含HTTP狀態碼的資訊頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文為HTTP Status Code。
下面是常見的HTTP狀態碼：
200 - 請求成功
301 - 資源（網頁等）被永久轉移到其它URL
404 - 請求的資源（網頁等）不存在
500 - 內部伺服器錯誤
HTTP狀態碼分類
HTTP狀態碼由三個十進位制數字組成，第一個十進位制數字定義了狀態碼的型別，後兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：
| HTTP狀態碼分類 |
|
| 分類 |
分類描述 |
| 1** |
資訊，伺服器收到請求，需要請求者繼續執行操作 |
| 2** |
成功，操作被成功接收並處理 |
| 3** |
重定向，需要進一步的操作以完成請求 |
| 4** |
客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** |
伺服器錯誤，伺服器在處理請求的過程中發生了錯誤 |
2. HTTPS
HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer）安全套接字層超文字傳輸協議。
HTTP協議以明文方式傳送內容，不提供任何方式的資料加密。為了解決這一缺陷，出現了HTTPS，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，併為瀏覽器和伺服器之間的通訊加密。
網景在1994年建立了HTTPS，並應用在網景導航者瀏覽器中。 最初，HTTPS是與SSL一起使用的；在SSL逐漸演變到TLS時，最新的HTTPS也由在2000年五月公佈的RFC 2818正式確定下來。
它是由Netscape開發並內置於其瀏覽器中，用於對資料進行加密和解密操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全套接層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是像HTTP那樣使用埠80來和TCP/IP進行通訊。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證，如果需要的話使用者可以確認傳送者是誰。
也就是說它的主要作用可以分為兩種：一種是建立一個資訊保安通道，來保證資料傳輸的安全；另一種就是確認網站的真實性，凡是使用了 https 的網站，都可以通過點選瀏覽器位址列的鎖頭標誌來檢視網站認證之後的真實資訊，也可以通過 CA 機構頒發的安全簽章來查詢 。
2.1. HTTPS與HTTP的區別
HTTPS和HTTP的區別主要為以下四點：
一、https協議需要到ca申請證書，一般免費證書很少，需要交費。
二、http是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
三、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
四、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。
2.2. HTTPS實現方式
信任主機：
採用https的伺服器必須從CA （Certificate Authority）申請一個用於證明伺服器用途型別的證書。該證書只有用於對應的伺服器的時候，客戶端才信任此主機。所以所有的銀行系統網站，關鍵部分應用都是https 的。客戶通過信任該證書，從而信任了該主機。其實這樣做效率很低，但是銀行更側重安全。這一點對區域網對內提供服務處的伺服器沒有任何意義。區域網中的伺服器，採用的證書不管是自己釋出的還是從公眾的地方釋出的，其客戶端都是自己人，所以該區域網中的客戶端也就肯定信任該伺服器。
資料傳輸安全
1． 一般意義上的https，就是伺服器有一個證書。
a) 主要目的是保證伺服器就是他聲稱的伺服器，這個跟第一點一樣。
b)服務端和客戶端之間的所有通訊，都是加密的。
i. 具體講，是客戶端產生一個對稱的金鑰，通過伺服器的證書來交換金鑰，即一般意義上的握手過程。
ii. 接下來所有的資訊往來就都是加密的。第三方即使截獲，也沒有任何意義，因為他沒有金鑰，當然篡改也就沒有什麼意義了。
2． 少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。
a) 這裡客戶端證書，其實就類似表示個人資訊的時候，除了使用者名稱/密碼，還有一個CA 認證過的身份。因為個人證書一般來說是別人無法模擬的，所有這樣能夠更深的確認自己的身份。
b) 目前大多數個人銀行的專業版是這種做法，具體證書可能是拿U盤（即U盾）作為一個備份的載體。
2.2.1. 具體通訊過程及圖示
客戶端在使用HTTPS方式與Web伺服器通訊時有以下幾個步驟，如圖所示。
1．客戶使用https的URL訪問Web伺服器，要求與Web伺服器建立SSL連線。
2．Web伺服器收到客戶端請求後，會將網站的證書資訊（證書中包含公鑰）傳送一份給客戶端。
3．認證伺服器。瀏覽器內建一個受信任的CA機構列表，並儲存了這些CA機構的證書，如果認證該伺服器證書的CA機構，存在於瀏覽器的受信任CA機構列表中，並且伺服器證書中的資訊與當前正在訪問的網站（域名等）一致，那麼瀏覽器就認為服務端是可信的，並從伺服器證書中取得伺服器公鑰，用於後續流程。否則，瀏覽器將提示使用者，根據使用者的選擇，決定是否繼續。當然，可以管理這個受信任CA機構列表，新增想要信任的CA機構，或者移除不信任的CA機構。
4．客戶端的瀏覽器與Web伺服器開始協商SSL連線的安全等級，也就是資訊加密的等級。
5．客戶端的瀏覽器根據雙方同意的安全等級，建立會話金鑰，然後利用網站的公鑰將會話金鑰加密，並傳送給網站。
6．Web伺服器利用自己的私鑰解密出會話金鑰。
7．Web伺服器利用會話金鑰加密與客戶端之間的通訊。
2.3. HTTPS的優缺點
https最主要的優點就是安全性。
但其也有一些不足：
- HTTPS協議握手階段比較費時，會使頁面的載入時間延長近50%，增加10%到20%的耗電；
- HTTPS連線快取不如HTTP高效，會增加資料開銷和功耗，甚至已有的安全措施也會因此而受到影響；
- SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
- SSL證書通常需要繫結IP，不能在同一IP上繫結多個域名，IPv4資源不可能支撐這個消耗。
- HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
客觀的講，上面的不足都只能是不足，安全總是需要代價的。
2.4. 使用https的流程
如果一個伺服器開發者想使用Https來保護自己的服務和使用者資料安全，你可以按照以下流程來操作。
