HTTP詳解

大家比較瞭解三次握手所以簡略說明：
在TCP/IP協議中，TCP協議提供可靠的連線服務，採用三次握手建立一個連線。 
第一次握手：建立連線時，客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認； 
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)，此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。 完成三次握手，客戶端與伺服器開始傳送資料.

四次揮手：

TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。TCP是全雙工 模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2， 它的資料已經全部發送完畢了;但是，這個時候主機1還是可以接受來自主機2的資料;當主機2返回ACK報文 段時，表示它已經知道主機1沒有資料傳送了，但是主機2還是可以傳送資料到主機1的;當主機2也傳送了FIN 報文段時，這個時候就表示主機2也沒有資料要傳送了，就會告訴主機1，我也沒有資料要傳送了，之後彼此 就會愉快的中斷這次TCP連線。如果要正確的理解四次揮手的原理，就需要了解四次揮手過程中的狀態變化。 
ACK ： TCP協議規定，只有ACK=1時有效，也規定連線建立後所有傳送的報文的ACK必須為1。 
FIN （finis）即完，終結的意思， 用來釋放一個連線。當 FIN = 1 時，表明此報文段的傳送方的資料已經發送完畢，並要求釋放連線。 
傳送序列號：Sequence Number 
確認序列號：Acknowledgment Number

FIN_WAIT_1：表示等待對方的FIN報文。當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET進入到FIN_WAIT_1 狀態 
FIN_WAIT_2：也表示等待對方的FIN報文。FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你，稍後再關閉連線。 
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。你回覆一個ACK給對方，並進入CLOSE_WAIT狀態。接下來就是檢視你是否還有資料要傳送給對方，如果沒有，就可以close這個socket，併發送FIN給對方，即關閉連線。 
CLOSING：表示主機1給主機2傳送FIN後，並沒有收到主機2迴應的ACK，而收到了主機2傳送的FIN。表示雙方同時close一個socket，出現同時傳送FIN現象。 
LAST_ACK: 傳送FIN報文後，等待對方的ACK報文，當收到ACK報文後，進入到CLOSED狀態。 
TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK確認，等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態。

第一次揮手：主機1向主機2，傳送FIN報文段，表示關閉資料傳送，並主機1進入FIN_WAIT_1狀態，表示沒有資料要傳輸了 
第二次揮手：主機2收到FIN報文段後進入CLOSE_WAIT狀態（被動關閉），然後傳送ACK確認，表示同意你關閉請求了，主機到主機的資料鏈路關閉，主機進入FIN_WAIT_2狀態 
第三次揮手：主機2等待主機1傳送完資料，傳送FIN到主機1請求關閉，主機2進入LAST_ACK狀態 
第四次揮手：主機1收到主機2傳送的FIN後，回覆ACK確認到主機2，主機1進入TIME_WAIT狀態。主機2收到主機1的ACK後就關閉連線了，狀態為CLOSED。主機1等待2MSL，仍然沒有收到主機2的回覆，說明主機2已經正常關閉了，主機1關閉連線。

HTTPS詳解

在目前大家正在研究的如何防止竊聽保護資訊的幾種對策中，最為普及的就是加密技術。加密的物件可以有這麼幾個。
通訊的加密
一種方式就是將通訊加密。HTTP 協議中沒有加密機制，但可以通過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport LayerSecurity，安全層傳輸協議）的組合使用，加密 HTTP 的通訊內容。
用 SSL 建立安全通訊線路之後，就可以在這條線路上進行 HTTP 通訊了。
與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文字傳輸安全協議）或 HTTP over SSL。

內容的加密
還有一種將參與通訊的內容本身加密的方式。由於 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容本身加密。即把 HTTP 報文裡所含的內容進行加密處理。

在這種情況下，客戶端需要對 HTTP 報文進行加密處理後再發送請求。

誠然，為了做到有效的內容加密，前提是要求客戶端和伺服器同時具備加密和解密機制。主要應用在 Web 服務中。有一點必須引起注意，由於該方式不同於 SSL 或 TLS 將整個通訊線路加密處理，所以內容仍有被篡改的風險。稍後我們會加以說明。

不驗證通訊方的身份就可能遭遇偽裝

HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在“伺服器是否就是傳送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端”等類似問題。

任何人都可發起請求

在 HTTP 協議通訊時，由於不存在確認通訊方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會返回一個響應（但也僅限於傳送端的 IP 地址和埠號沒有被 Web 伺服器設定限制訪問的前提下）。

HTTP 協議的實現本身非常簡單，不論是誰傳送過來的請求都會返回響應，因此不確認通訊方，會存在以下各種隱患。
1、無法確定請求傳送至目標的 Web 伺服器是否是按真實意圖返回響應的那臺伺服器。有可能是已偽裝的 Web 伺服器。
2、無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
3、無法確定正在通訊的對方是否具備訪問許可權。因為某些Web 伺服器上儲存著重要的資訊， 只想發給特定使用者通訊的許可權。
4、無法判定請求是來自何方、出自誰手。

5、即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS 攻擊（ Denial of Service， 拒絕服務攻擊） 。

查明對手的證書

雖然使用 HTTP 協議無法確定通訊方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用於確定方。證書由值得信任的第三方機構頒發，用以證明伺服器和客戶端是實際存在的。另外，偽造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通訊方（伺服器或客戶端）持有的證書，即可判斷通訊方的真實意圖。

通過使用證書，以證明通訊方就是意料中的伺服器。這對使用者個人來講，也減少了個人資訊洩露的危險性。
另外，客戶端持有證書即可完成個人身份的確認，也可用於對 Web 網站的認證環節。

無法證明報文完整性， 可能已遭篡改

所謂完整性是指資訊的準確度。若無法證明其完整性，通常也就意味著無法判斷資訊是否準確。

接收到的內容可能有誤

由於 HTTP 協議無法證明通訊的報文完整性，因此，在請求或響應送出之後直到對方接收之前的這段時間內，即使請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求 響應和接收到的請求 響應是前後相同的。

比如，從某個 Web 網站上下載內容，是無法確定客戶端下載的檔案和伺服器上存放的檔案是否前後一致的。檔案內容在傳輸途中可能已經被篡改為其他的內容。即使內容真的已改變，作為接收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱為中間人攻擊（Man-in-the-Middle attack，MITM）。

如何防止篡改

雖然有使用 HTTP 協議確定報文完整性的方法，但事實上並不便捷、可靠。其中常用的是 MD5 和 SHA-1 等雜湊值校驗的方法，以及用來確認檔案的數字簽名方法。

提供檔案下載服務的 Web 網站也會提供相應的以 PGP（Pretty GoodPrivacy，完美隱私）建立的數字簽名及 MD5 演算法生成的雜湊值。PGP 是用來證明建立檔案的數字簽名，MD5 是由單向函式生成的雜湊值。不論使用哪一種方法，都需要操縱客戶端的使用者本人親自檢查驗證下載的檔案是否就是原來伺服器上的檔案。瀏覽器無法自動幫使用者檢查。
可惜的是，用這些方法也依然無法百分百保證確認結果正確。因為 PGP 和MD5 本身被改寫的話，使用者是沒有辦法意識到的。
 

為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是非常困難的，因此通過和其他協議組合使用來實現這個目標。下節我們介紹 HTTPS 的相關內容。

確保 Web 安全的 HTTPS

在 HTTP 協議中有可能存在資訊竊聽或身份偽裝等安全問題。使用 HTTPS 通訊機制可以有效地防止這些問題。

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS
如果在 HTTP 協議通訊過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來說，伺服器也好，客戶端也好，都是沒有辦法確認通訊方的。
因為很有可能並不是和原本預想的通訊方在實際通訊。並且還需要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱為 HTTPS （HTTP Secure）。

經常會在 Web 的登入頁面和購物結算介面等使用 HTTPS 通訊。使用 HTTPS 通訊時，不再用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web網站時，瀏覽器的位址列內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並非是應用層的一種新協議。只是 HTTP 通訊介面部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協議代替而已。
通常，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL 是獨立於 HTTP 的協議，所以不光是 HTTP 協議，其他執行在應用層的 SMTP和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最為廣泛的網路安全術。

相互交換金鑰的公開金鑰加密技術

在對 SSL 進行講解之前，我們先來了解一下加密方法。SSL 採用一種叫做公開金鑰加密（Public-key cryptography）的加密處理方式。

近代的加密方法中加密演算法是公開的，而金鑰卻是保密的。通過這種方式得以保持加密方法的安全性。
加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說，任何人只要持有金鑰就能解密了。如果金鑰被攻擊者獲得，那加密也就失去了意義。

共享金鑰加密的困境

加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common key cryptosystem），也被叫做對稱金鑰加密。

以共享金鑰方式加密時必須將金鑰也發給對方。可究竟怎樣才能安全地轉交？在網際網路上轉發金鑰時，如果通訊被監聽那麼金鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的金鑰。

使用兩把金鑰的公開金鑰加密

公開金鑰加密方式很好地解決了共享金鑰加密的困難。
公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰（private key），另一把叫做公開金鑰（public key）。顧名思義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得。公開金鑰和私有金鑰是配對的一套金鑰。
使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。
另外，要想根據密文和公開金鑰，恢復到資訊原文是異常困難的，因為解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。退一步講，如果能對一個非常大的整數做到快速地因式分解，那麼密碼破解還是存在希望的。但就目前的技術來看是不太現實的。

HTTPS 採用混合加密機制

HTTPS 採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。

但是公開金鑰加密與共享金鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用公開金鑰加密方式，之後的建立通訊交換報文階段則使用共享金鑰加密方式。

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

遺憾的是，公開金鑰加密方式還是存在一些問題的。那就是無法證明公開金鑰本身就是貨真價實的公開金鑰。比如，正準備和某臺伺服器建立公開金鑰加密方式下的通訊時，如何證明收到的公開金鑰就是原本預想的那臺伺服器發行的公開金鑰。或許在公開金鑰傳輸途中，真正的公開金鑰已經被攻擊者替換掉了。
為了解決上述問題，可以使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開金鑰證書。
數字證書認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家非常有名的數字證書認證機構。我們來介紹一下數字證書認證機構的業務流程。

首先，伺服器的運營人員向數字證書認證機構提出公開金鑰的申請。數字證書認證機構在判明提出申請者的身份之後，會對已申請的公開金鑰做數字簽名，然後分配這個已簽名的公開金鑰，並將該公開金鑰放入公鑰證書後繫結在一起。
伺服器會將這份由數字證書認證機構頒發的公鑰證書傳送給客戶端，以進行公開金鑰加密方式通訊。公鑰證書也可叫做數字證書或直接稱為證書。接到證書的客戶端可使用數字證書認證機構的公開金鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：一，認證伺服器的公開金鑰的是真實有效的數字證書認證機構。二，伺服器的公開金鑰是值得信賴的。
此處認證機關的公開金鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商釋出版本時，會事先在內部植入常用認證機關的公開金鑰。

HTTPS 的安全通訊機制

為了更好地理解 HTTPS，我們來觀察一下 HTTPS 的通訊步驟。

步驟 1： 客戶端通過傳送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支援的 SSL 的指定版本、加密元件（Cipher Suite）列表（所使用的加密演算法及金鑰長度等）。
步驟 2： 伺服器可進行 SSL 通訊時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密元件。伺服器的加密元件內容是從接收到的客戶端加密元件內篩選出來的。
步驟 3： 之後伺服器傳送 Certificate 報文。報文中包含公開金鑰證書。
步驟 4： 最後伺服器傳送 Server Hello Done 報文通知客戶端，最初階段的SSL握手協商部分結束。

步驟 5： SSL 第一次握手結束之後，客戶端以 Client Key Exchange 報文作為迴應。報文中包含通訊加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開金鑰進行加密。
步驟 6： 接著客戶端繼續傳送 Change Cipher Spec 報文。該報文會提示伺服器，在此報文之後的通訊會採用 Pre-master secret 金鑰加密。
步驟 7： 客戶端傳送 Finished 報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準。

步驟 8： 伺服器同樣傳送 Change Cipher Spec 報文。
步驟 9： 伺服器同樣傳送 Finished 報文。

步驟 10： 伺服器和客戶端的 Finished 報文交換完畢之後，SSL 連線就算建立完成。當然，通訊會受到 SSL 的保護。從此處開始進行應用層協議的通訊，即傳送 HTTP請求。
步驟 11： 應用層協議通訊，即傳送 HTTP 響應。
步驟 12： 最後由客戶端斷開連線。斷開連線時，傳送 close_notify 報文。上圖做了一些省略，這步之後再發送 TCP FIN 報文來關閉與 TCP 的通訊。在以上流程中，應用層傳送資料時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。