現在這個社會，我們都離不開網絡，那么網絡的工作流程是怎么樣的呢？從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依靠證書來驗證服務器的身份，並為瀏覽器和服務器之間的通信加密。具體是如何進行加密，解密，驗證的，且看下圖，下面的稱為一次握手。
PS：圖片以下描述摘自：http://zhuqil.cnblogs.com
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