現在這個社會，我們都離不開網路，那麼網路的工作流程是怎麼樣的呢？從http發起請求到完成請求，網路到底給我們做了什麼事情？ 
今天我們主要來分析下http請求的過程： 
在Http工作之前，Web瀏覽器通過網路和Web伺服器建立鏈連線，該連線是通過Tcp來完成的，該協議和Ip共同組成了Internet，即著名的Tcp/Ip協議族，因此Internet也被稱為Tcp/Ip網路，Http是比Tcp更高的應用層協議，一般Tcp介面的埠好是80。

Web瀏覽器想Web伺服器傳送請求命令，這個命令中包含： 

Web伺服器傳送響應資料給Web瀏覽器，這個包含： 
 
然後Web伺服器關閉連線。

以上就是基本的http請求。 
在這個過程中，http建立連線，Tcp經過了3次握手，下面我們來講講具體的3次握手的過程，首先我們來看一張圖： 

1：客戶端傳送了一個帶有SYN的Tcp報文到伺服器，這個三次握手中的開始。表示客戶端想要和服務端建立連線。 
2：服務端接收到客戶端的請求，返回客戶端報文，這個報文帶有SYN和ACK標誌，詢問客戶端是否準備好。 
3：客戶端再次響應服務端一個ACK，表示我已經準備好。

那麼為什麼要三次握手呢，有人說兩次握手就好了。的確，為什麼呢，這個可以從計算機網路中得到答案，舉一個例子：已失效的連線請求報文段， 
client傳送了第一個連線的請求報文，但是由於網路不好，這個請求沒有立即到達服務端，而是在某個網路節點中滯留了，知道某個時間才到達server，本來這已經是一個失效的報文，但是server端接收到這個請求報文後，還是會想client發出確認的報文，表示同意連線。假如不採用三次握手，那麼只要server發出確認，新的建立就連線了，但其實這個請求是失效的請求，client是不會理睬server的確認資訊，也不會向服務端傳送確認的請求，但是server認為新的連線已經建立起來了，並一直等待client發來資料，這樣，server的很多資源就沒白白浪費掉了，採用三次握手就是為了防止這種情況的發生，server會因為收不到確認的報文，就知道client並沒有建立連線。這就是三次握手的作用。

當終止協議的時候，tcp進行了4次握手，那這4次握手有是怎麼回事呢？

由於Tcp連線是進行全雙工工作的，因此每個方向都必須單獨進行關閉，這個原則是當一方完成他的資料傳送的時候就傳送一個FIN來終止這個方向的連線，收到這個FIN意味著這個方向上沒有資料的流動，一個TCP連線在收到這個FIN之後還能傳送訊息，首先執行關閉的一方進行主動的關閉，而另一方進行被動的關閉。 
1：TCP傳送一個FIN，用來關閉客戶到服務端的連線。 
2：服務端收到這個FIN，他發回一個ACK，確認收到序號為收到序號+1，和SYN一樣，一個FIN將佔用一個序號。 
3：服務端傳送一個FIN到客戶端，服務端關閉客戶端的連線。 
4：客戶端傳送ACK報文確認，並將確認的序號+1，這樣關閉完成。

那麼為什麼是4次揮手呢？ 
可能有人會有疑問，tcp我握手的時候為何ACK和SYN是一起傳送。揮手的時候為什麼是分開的時候傳送呢，原因是TCP的全雙工模式，接收到FIN意味著沒有資料傳送過來了，但是還可以繼續傳送資料。

3次握手過程的狀態： 
listener:這個很好理解，就是服務端的某個socket處於監聽狀態，可以接收連線了。

syn_send:當某個socket執行connect的時候，首先發送SYN報文，因此也進入了SYN_SEND狀態，並等待服務端傳送過來的報文，syn_send表示客戶端已傳送SYN報文。 
syn_rcvd:這個狀態與SYN_SEND狀態差不多，表示接收了SYN報文，這個狀態是伺服器端的socket在建立tcp連線是的三次握手中的一箇中間狀態，很短暫，當客戶端收到ACK報文的時候，表示連線確立，進入established狀態。

4次揮手的狀態： 
FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）

FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你(ACK資訊)，稍後再關閉連線。（主動方）

TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）

CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN報文後，按理來說是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時傳送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。

CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以close這個 
SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。（被動方）

LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）

CLOSED: 表示連線

#####################################################################################################

#####################################################################################################

HTTP與TCP/IP區別？

TPC/IP協議是傳輸層協議，主要解決資料如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝資料。WEB使用HTTP協議作應用層協議，以封裝HTTP 文字資訊，然後使用TCP/IP做傳輸層協議將它發到網路上。

下面的圖表試圖顯示不同的TCP/IP和其他的協議在最初OSI（Open System Interconnect）模型中的位置：

PS：表格來自網上資料

CA證書是什麼？

CA（Certificate Authority）是負責管理和簽發證書的第三方權威機構，是所有行業和公眾都信任的、認可的。

CA證書，就是CA頒發的證書，可用於驗證網站是否可信（針對HTTPS）、驗證某檔案是否可信（是否被篡改）等，也可以用一個證書來證明另一個證書是真實可信，最頂級的證書稱為根證書。除了根證書（自己證明自己是可靠），其它證書都要依靠上一級的證書，來證明自己。

HTTP三次握手

HTTP（HyperText Transfer Protocol)超文字傳輸協議是網際網路上應用最為廣泛的一種網路協議。由於資訊是明文傳輸，所以被認為是不安全的。而關於HTTP的三次握手，其實就是使用三次TCP握手確認建立一個HTTP連線。

如下圖所示，SYN（synchronous）是TCP/IP建立連線時使用的握手訊號、Sequence number（序列號）、Acknowledge number（確認號碼），三個箭頭指向就代表三次握手，完成三次握手，客戶端與伺服器開始傳送資料。

PS：圖片來自網上資料

第一次握手：客戶端傳送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；

第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

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

HTTPS握手過程

HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，併為瀏覽器和伺服器之間的通訊加密。具體是如何進行加密，解密，驗證的，且看下圖，下面的稱為一次握手。

1. 客戶端發起HTTPS請求

2. 服務端的配置

採用HTTPS協議的伺服器必須要有一套數字證書，可以是自己製作或者CA證書。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用CA證書則不會彈出提示頁面。這套證書其實就是一對公鑰和私鑰。公鑰給別人加密使用，私鑰給自己解密使用。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨即值，然後用證書對該隨機值進行加密。

5. 傳送加密資訊

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。

6. 服務段解密資訊

服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。

7. 傳輸加密後的資訊

這部分資訊是服務段用私鑰加密後的資訊，可以在客戶端被還原。

8. 客戶端解密資訊

客戶端用之前生成的私鑰解密服務段傳過來的資訊，於是獲取瞭解密後的內容。

PS: 整個握手過程第三方即使監聽到了資料，也束手無策。

總結

為什麼HTTPS是安全的？

在HTTPS握手的第四步中，如果站點的證書是不受信任的，會顯示出現下面確認介面，確認了網站的真實性。另外第六和八步，使用客戶端私鑰加密解密，保證了資料傳輸的安全。

HTTPS和HTTP的區別

1. https協議需要到ca申請證書或自制證書。

2. http的資訊是明文傳輸，https則是具有安全性的ssl加密。

3. http是直接與TCP進行資料傳輸，而https是經過一層SSL（OSI表示層），用的埠也不一樣，前者是80（需要國內備案），後者是443。

4. http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

注意https加密是在傳輸層 

https報文在被包裝成tcp報文的時候完成加密的過程，無論是https的header域也好，body域也罷都是會被加密的。

當使用tcpdump或者wireshark之類的tcp層工具抓包，獲取是加密的內容，而如果用應用層抓包，使用Charels(Mac)、Fildder(Windows)抓包工具，那當然看到是明文的。

PS：HTTPS本身就是為了網路的傳輸安全。

例子，使用wireshark抓包：

http，可以看到抓到是明文的：

https，可以看到抓到是密文的：

附錄

HTTPS一般使用的加密與HASH演算法如下：

非對稱加密演算法：RSA，DSA/DSS

對稱加密演算法：AES，RC4，3DES

HASH演算法：MD5，SHA1，SHA256