摘要：從輸入到發(fā)送請(qǐng)求經(jīng)歷了一些事情，今天我們來(lái)總結(jié)一下。在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議，分別是，傳輸控制協(xié)議和，用戶數(shù)據(jù)報(bào)協(xié)議網(wǎng)絡(luò)層網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。

從輸入url到發(fā)送請(qǐng)求經(jīng)歷了一些事情，今天我們來(lái)總結(jié)一下。 簡(jiǎn)單來(lái)說，共有以下幾個(gè)過程

DNS域名解析
發(fā)起TCP連接
發(fā)送HTTP請(qǐng)求
服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文
瀏覽器解析渲染頁(yè)面
連接結(jié)束

什么是域名解析

域名系統(tǒng)（英文：DomainNameSystem，縮寫：DNS）是互聯(lián)網(wǎng)的一項(xiàng)服務(wù)。它作為將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，能夠使人更方便地訪問互聯(lián)網(wǎng)

域名解析過程

系統(tǒng)會(huì)檢查瀏覽器緩存中有沒有這個(gè)域名對(duì)應(yīng)的解析過的 IP 地址，如果緩存中有，這個(gè)解析過程就將結(jié)束。瀏覽器緩存是受這個(gè)域名的失效時(shí)間和緩存的空間大小控制的。
如果用戶的瀏覽器緩存中沒有，瀏覽器會(huì)查找操作系統(tǒng)緩存中即為本地的 Host 文件
路由器也可能會(huì)有緩存。
操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器， 本地域名服務(wù)器查詢自己的 DNS 緩存，查找成功則返回結(jié)果，失敗則發(fā)起一個(gè)迭代 DNS 解析請(qǐng)求

1、本地域名服務(wù)器 向 根域名服務(wù)器，其雖然沒有每個(gè)域名的的具體信息，但存儲(chǔ)了負(fù)責(zé)每個(gè)域，如 com、net、org等的解析的頂級(jí)域名服務(wù)器的地址）發(fā)起請(qǐng)求，此處，根域名服務(wù)器 返回 com 域的頂級(jí)域名服務(wù)器的地址；

2、本地域名服務(wù)器  向 com 域的頂級(jí)域名服務(wù)器發(fā)起請(qǐng)求，返回 baidu.com 域名服務(wù)器地址；

3、本地域名服務(wù)器向 baidu.com 域名服務(wù)器發(fā)起請(qǐng)求，得到 www.baidu.com 的 IP 地址；
本地域名服務(wù)器 將得到的 IP 地址返回給操作系統(tǒng)，同時(shí)自己也將 IP 地址緩存起來(lái)；
操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將 IP 地址緩存起來(lái)；
至此，瀏覽器已經(jīng)得到了域名對(duì)應(yīng)的 IP 地址。

TCP/IP 五層協(xié)議

應(yīng)用層：決定向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)。TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)。比如：FTP、DNS、HTTP 協(xié)議。
傳輸層：傳輸層對(duì)上層應(yīng)用層，提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸。在傳輸層有兩個(gè)性質(zhì)不同的協(xié)議，分別是 TCP (Transmission Control Protocol，傳輸控制協(xié)議) 和 UDP (User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議)
網(wǎng)絡(luò)層：網(wǎng)絡(luò)層用來(lái)處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包。數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位。該層規(guī)定了通過怎樣的路徑到達(dá)對(duì)方計(jì)算機(jī)，并把數(shù)據(jù)包傳送給對(duì)方。與對(duì)方計(jì)算機(jī)通過多臺(tái)計(jì)算機(jī)或網(wǎng)絡(luò)設(shè)備進(jìn)行傳輸時(shí)，網(wǎng)絡(luò)層所起的作用就是在眾多的選項(xiàng)內(nèi)選擇一條傳輸路線。
數(shù)據(jù)鏈路層: 在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路，通過差錯(cuò)控制提供數(shù)據(jù)幀 (Frame)在信道上無(wú)差錯(cuò)的傳輸，并進(jìn)行各電路上的動(dòng)作系列。數(shù)據(jù)的單位稱為幀 (frame)
物理層：物理層建立在物理通信介質(zhì)的基礎(chǔ)上，作為系統(tǒng)和通信介質(zhì)的接口，用來(lái)實(shí)現(xiàn)數(shù)據(jù)鏈路實(shí)體間透明的比特 (bit) 流傳輸。只有該層為真實(shí)物理通信，其它各層為虛擬通信。

TCP協(xié)議

TCP協(xié)議全稱是傳輸控制協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由 IETF 的RFC 793定義。TCP 是面向連接的、可靠的流協(xié)議。流就是指不間斷的數(shù)據(jù)結(jié)構(gòu)，你可以把它想象成排水管中的水流。

TCP連接過程（三次握手)

1、第一次握手：客戶端發(fā)送syn包(Seq=x)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
2、第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=x+1），同時(shí)自己也發(fā)送一個(gè)SYN包（Seq=y），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
3、第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=y+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，TCP 連接都將被一直保持下去。

為什么會(huì)采用三次握手，若采用二次握手可以嗎？ 四次呢？

建立連接的過程是利用客戶服務(wù)器模式，假設(shè)主機(jī)A為客戶端，主機(jī)B為服務(wù)器端。
采用三次握手是為了防止失效的連接請(qǐng)求報(bào)文段突然又傳送到主機(jī)B，因而產(chǎn)生錯(cuò)誤。失效的連接請(qǐng)求報(bào)文段是指：主機(jī)A發(fā)出的連接請(qǐng)求沒有收到主機(jī)B的確認(rèn)，于是經(jīng)過一段時(shí)間后，主機(jī)A又重新向主機(jī)B發(fā)送連接請(qǐng)求，且建立成功，順序完成數(shù)據(jù)傳輸。考慮這樣一種特殊情況，主機(jī)A第一次發(fā)送的連接請(qǐng)求并沒有丟失，而是因?yàn)榫W(wǎng)絡(luò)節(jié)點(diǎn)導(dǎo)致延遲達(dá)到主機(jī)B，主機(jī)B以為是主機(jī)A又發(fā)起的新連接，于是主機(jī)B同意連接，并向主機(jī)A發(fā)回確認(rèn)，但是此時(shí)主機(jī)A根本不會(huì)理會(huì)，主機(jī)B就一直在等待主機(jī)A發(fā)送數(shù)據(jù)，導(dǎo)致主機(jī)B的資源浪費(fèi)。

采用兩次握手不行，原因就是上面說的失效的連接請(qǐng)求的特殊情況。而在三次握手中， client和server都有一個(gè)發(fā)syn和收ack的過程， 雙方都是發(fā)后能收， 表明通信則準(zhǔn)備工作OK.

為什么不是四次握手呢？ 大家應(yīng)該知道通信中著名的藍(lán)軍紅軍約定， 這個(gè)例子說明， 通信不可能100%可靠， 而上面的三次握手已經(jīng)做好了通信的準(zhǔn)備工作， 再增加握手， 并不能顯著提高可靠性， 而且也沒有必要。

TCP協(xié)議的特點(diǎn)

面向連接

面向連接，是指發(fā)送數(shù)據(jù)之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數(shù)據(jù)的可靠傳輸打下了基礎(chǔ)。

僅支持單播傳輸

每條TCP傳輸連接只能有兩個(gè)端點(diǎn)，只能進(jìn)行點(diǎn)對(duì)點(diǎn)的數(shù)據(jù)傳輸，不支持多播和廣播傳輸方式。

面向字節(jié)流

TCP不像UDP一樣那樣一個(gè)個(gè)報(bào)文獨(dú)立地傳輸，而是在不保留報(bào)文邊界的情況下以字節(jié)流方式進(jìn)行傳輸。

可靠傳輸

對(duì)于可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號(hào)以及確認(rèn)號(hào)。TCP為了保證報(bào)文傳輸?shù)目煽浚徒o每個(gè)包一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的字節(jié)發(fā)回一個(gè)相應(yīng)的確認(rèn)(ACK)；如果發(fā)送端實(shí)體在合理的往返時(shí)延(RTT)內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)（假設(shè)丟失了）將會(huì)被重傳。

提供擁塞控制

當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞的時(shí)候，TCP能夠減小向網(wǎng)絡(luò)注入數(shù)據(jù)的速率和數(shù)量，緩解擁塞

TCP提供全雙工通信

TCP允許通信雙方的應(yīng)用程序在任何時(shí)候都能發(fā)送數(shù)據(jù)，因?yàn)門CP連接的兩端都設(shè)有緩存，用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)。當(dāng)然，TCP可以立即發(fā)送一個(gè)數(shù)據(jù)段，也可以緩存一段時(shí)間以便一次發(fā)送更多的數(shù)據(jù)段（最大的數(shù)據(jù)段大小取決于MSS）

UDP協(xié)議

UDP協(xié)議全稱是用戶數(shù)據(jù)報(bào)協(xié)議，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無(wú)連接的協(xié)議。在OSI模型中，在第四層——傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對(duì)數(shù)據(jù)包進(jìn)行排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無(wú)法得知其是否安全完整到達(dá)的。

UDP協(xié)議的特點(diǎn)

面向無(wú)連接

首先 UDP 是不需要和 TCP一樣在發(fā)送數(shù)據(jù)前進(jìn)行三次握手建立連接的，想發(fā)數(shù)據(jù)就可以開始發(fā)送了。并且也只是數(shù)據(jù)報(bào)文的搬運(yùn)工，不會(huì)對(duì)數(shù)據(jù)報(bào)文進(jìn)行任何拆分和拼接操作。具體來(lái)說就是：

在發(fā)送端，應(yīng)用層將數(shù)據(jù)傳遞給傳輸層的 UDP 協(xié)議，UDP 只會(huì)給數(shù)據(jù)增加一個(gè) UDP 頭標(biāo)識(shí)下是 UDP 協(xié)議，然后就傳遞給網(wǎng)絡(luò)層了
在接收端，網(wǎng)絡(luò)層將數(shù)據(jù)傳遞給傳輸層，UDP 只去除 IP 報(bào)文頭就傳遞給應(yīng)用層，不會(huì)任何拼接操作

有單播，多播，廣播的功能

UDP 不止支持一對(duì)一的傳輸方式，同樣支持一對(duì)多，多對(duì)多，多對(duì)一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。

UDP是面向報(bào)文的

發(fā)送方的UDP對(duì)應(yīng)用程序交下來(lái)的報(bào)文，在添加首部后就向下交付IP層。UDP對(duì)應(yīng)用層交下來(lái)的報(bào)文，既不合并，也不拆分，而是保留這些報(bào)文的邊界。因此，應(yīng)用程序必須選擇合適大小的報(bào)文

不可靠性

首先不可靠性體現(xiàn)在無(wú)連接上，通信都不需要建立連接，想發(fā)就發(fā)，這樣的情況肯定不可靠。
并且收到什么數(shù)據(jù)就傳遞什么數(shù)據(jù)，并且也不會(huì)備份數(shù)據(jù)，發(fā)送數(shù)據(jù)也不會(huì)關(guān)心對(duì)方是否已經(jīng)正確接收到數(shù)據(jù)了。
再者網(wǎng)絡(luò)環(huán)境時(shí)好時(shí)壞，但是 UDP 因?yàn)闆]有擁塞控制，一直會(huì)以恒定的速度發(fā)送數(shù)據(jù)。即使網(wǎng)絡(luò)條件不好，也不會(huì)對(duì)發(fā)送速率進(jìn)行調(diào)整。這樣實(shí)現(xiàn)的弊端就是在網(wǎng)絡(luò)條件不好的情況下可能會(huì)導(dǎo)致丟包，但是優(yōu)點(diǎn)也很明顯，在某些實(shí)時(shí)性要求高的場(chǎng)景（比如電話會(huì)議）就需要使用 UDP 而不是 TCP。UDP只會(huì)把想發(fā)的數(shù)據(jù)報(bào)文一股腦的丟給對(duì)方，并不在意數(shù)據(jù)有無(wú)安全完整到達(dá)。

頭部開銷小，傳輸數(shù)據(jù)報(bào)文時(shí)是很高效的。

UDP 頭部包含了以下幾個(gè)數(shù)據(jù)：

兩個(gè)十六位的端口號(hào)，分別為源端口（可選字段）和目標(biāo)端口
整個(gè)數(shù)據(jù)報(bào)文的長(zhǎng)度
整個(gè)數(shù)據(jù)報(bào)文的檢驗(yàn)和（IPv4 可選 字段），該字段用于發(fā)現(xiàn)頭部信息和數(shù)據(jù)中的錯(cuò)誤

TCP和UDP的比較

HTTP

HTTP（超文本傳輸協(xié)議） 是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。HTTP 是互聯(lián)網(wǎng)數(shù)據(jù)通信的基礎(chǔ)。它是由萬(wàn)維網(wǎng)協(xié)會(huì)（W3C）和互聯(lián)網(wǎng)工程任務(wù)組（IETF）進(jìn)行協(xié)調(diào)制定了 HTTP 的標(biāo)準(zhǔn)，最終發(fā)布了一系列的 RFC，并且在1999年6月公布的 RFC 2616，定義了 HTTP 協(xié)議中現(xiàn)今廣泛使用的一個(gè)版本——HTTP 1.1。

HTTP 訪問過程

HTTP 屬于 TCP/IP 模型中的應(yīng)用層協(xié)議，當(dāng)瀏覽器與服務(wù)器進(jìn)行互相通信時(shí)，需要先建立TCP 連接，之后服務(wù)器才會(huì)接收瀏覽器的請(qǐng)求信息，當(dāng)接收到信息之后，服務(wù)器返回相應(yīng)的信息。最后瀏覽器接受對(duì)服務(wù)器的信息應(yīng)答后，對(duì)這些數(shù)據(jù)進(jìn)行解釋執(zhí)行（下圖http 1.0 請(qǐng)求模式）

HTTP 1.0 時(shí)，瀏覽器每次訪問都要多帶帶建立連接，這會(huì)造成資源的浪費(fèi)。

后來(lái)HTTP 1.1管線化(pipelining)理論，客戶端可以同時(shí)發(fā)出多個(gè)HTTP請(qǐng)求，可以在一次連接中處理多個(gè)請(qǐng)求，并且將多個(gè)請(qǐng)求重疊進(jìn)行

注意：這個(gè)pipelining僅僅是限于理論場(chǎng)景下，大部分桌面瀏覽器仍然會(huì)選擇默認(rèn)關(guān)閉HTTP pipelining！

所以現(xiàn)在使用HTTP1.1協(xié)議的應(yīng)用，都是有可能會(huì)開多個(gè)TCP連接的！

HTTP Pipelining其實(shí)是把多個(gè)HTTP請(qǐng)求放到一個(gè)TCP連接中一一發(fā)送，而在發(fā)送過程中不需要等待服務(wù)器對(duì)前一個(gè)請(qǐng)求的響應(yīng)；只不過，客戶端還是要按照發(fā)送請(qǐng)求的順序來(lái)接收響應(yīng)！

在HTTP1.0中，發(fā)送一次請(qǐng)求時(shí)，需要等待服務(wù)端響應(yīng)了才可以繼續(xù)發(fā)送請(qǐng)求。

在HTTP1.1中，發(fā)送一次請(qǐng)求時(shí)，不需要等待服務(wù)端響應(yīng)了就可以發(fā)送請(qǐng)求了，但是回送數(shù)據(jù)給客戶端的時(shí)候，客戶端還是需要按照響應(yīng)的順序來(lái)一一接收

所以說，無(wú)論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會(huì)出現(xiàn)阻塞的情況。從專業(yè)的名詞上說這種情況，叫做線頭阻塞（Head of line blocking）簡(jiǎn)稱：HOLB

SPDY：HTTP1.x的優(yōu)化

2012年google如一聲驚雷提出了SPDY的方案，優(yōu)化了HTTP1.X的請(qǐng)求延遲，解決了HTTP1.X的安全性。具體如下：

降低延遲 針對(duì)HTTP高延遲的問題，SPDY優(yōu)雅的采取了多路復(fù)用（multiplexing）。多路復(fù)用通過多個(gè)請(qǐng)求stream共享一個(gè)tcp連接的方式，解決了HOL blocking的問題，降低了延遲同時(shí)提高了帶寬的利用率。

請(qǐng)求優(yōu)先級(jí)（request prioritization） 多路復(fù)用帶來(lái)一個(gè)新的問題是，在連接共享的基礎(chǔ)之上有可能會(huì)導(dǎo)致關(guān)鍵請(qǐng)求被阻塞。SPDY允許給每個(gè)request設(shè)置優(yōu)先級(jí)，這樣重要的請(qǐng)求就會(huì)優(yōu)先得到響應(yīng)。比如瀏覽器加載首頁(yè)，首頁(yè)的html內(nèi)容應(yīng)該優(yōu)先展示，之后才是各種靜態(tài)資源文件，腳本文件等加載，這樣可以保證用戶能第一時(shí)間看到網(wǎng)頁(yè)內(nèi)容。

header壓縮 前面提到HTTP1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。

基于HTTPS的加密協(xié)議傳輸 大大提高了傳輸數(shù)據(jù)的可靠性

服務(wù)端推送（server push） 采用了SPDY的網(wǎng)頁(yè)，例如我的網(wǎng)頁(yè)有一個(gè)sytle.css的請(qǐng)求，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)，服務(wù)端會(huì)將sytle.js的文件推送給客戶端，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到，不用再發(fā)請(qǐng)求了。SPDY構(gòu)成圖：

HTTP2

HTTP/2（超文本傳輸協(xié)議第2版，最初命名為HTTP 2.0），是HTTP協(xié)議的的第二個(gè)主要版本，使用于萬(wàn)維網(wǎng)。HTTP/2是HTTP協(xié)議自1999年HTTP 1.1發(fā)布后的首個(gè)更新，主要基于SPDY協(xié)議（是Google開發(fā)的基于TCP的應(yīng)用層協(xié)議，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗(yàn)）

HTTP2.0和SPDY的區(qū)別：

HTTP2.0 支持明文 HTTP 傳輸，而 SPDY 強(qiáng)制使用 HTTPS
HTTP2.0 消息頭的壓縮算法采用 HPACK http2.github.io/http2-spec/… SPDY 采用的 DEFLATE zh.wikipedia.org/wiki/DEFLAT…

HTTP1.0 、HTTP1.1和HTTP2.0的對(duì)比

HTTP 協(xié)議特點(diǎn)

簡(jiǎn)單、快速、靈活：當(dāng)用戶想服務(wù)器發(fā)送請(qǐng)求時(shí)，只需傳送請(qǐng)求方法和路徑即可，HTTP 允許傳輸任意類型的數(shù)據(jù)對(duì)象。并且HTTP協(xié)議簡(jiǎn)單易用，HTTP 服務(wù)器規(guī)模小，保證了網(wǎng)絡(luò)通信的速度；
無(wú)連接、無(wú)狀態(tài)：HTTP協(xié)議限制每次連接只處理單個(gè)請(qǐng)求，當(dāng)服務(wù)器收到用戶請(qǐng)求后就會(huì)斷開連接，保證了傳輸時(shí)間的節(jié)省。同時(shí)HTTP協(xié)議對(duì)事務(wù)處理沒有記憶能力，如果后續(xù)的請(qǐng)求需要使用前面的信息就必須重傳數(shù)據(jù)；
管線化和內(nèi)容編碼：隨著管線化技術(shù)的出現(xiàn)，HTTP 請(qǐng)求比持久性連接速度更快，并且當(dāng)某些報(bào)文的內(nèi)容過大時(shí)，為了減少傳輸?shù)臅r(shí)間，HTTP 會(huì)采取壓縮文件的方式；
HTTP 支持客戶/服務(wù)器模式

從 HTTP 到 HTTPS

HTTP 協(xié)議由于其簡(jiǎn)單快速、占用資源少，一直被用于網(wǎng)站服務(wù)器和瀏覽器之間進(jìn)行數(shù)據(jù)傳輸。但是在數(shù)據(jù)傳輸?shù)倪^程中也存在很明顯的問題，由于 HTTP 是明文協(xié)議，不會(huì)對(duì)數(shù)據(jù)進(jìn)行任何方式的加密。當(dāng)黑客攻擊竊取了網(wǎng)站服務(wù)器和瀏覽器之間的傳輸報(bào)文的時(shí)，可以直接讀取傳輸?shù)男畔ⅲ斐删W(wǎng)站、用戶資料的泄密。因此 HTTP 不適用于敏感信息的傳播，這個(gè)時(shí)候需要引入 HTTPS（超文本傳輸安全協(xié)議）。

HTTPS

HTTPS（Hypertext Transfer Protocol Secure ）是一種以計(jì)算機(jī)網(wǎng)絡(luò)安全通信為目的的傳輸協(xié)議。在HTTP下加入了SSL/TLS層，從而具有了保護(hù)交換數(shù)據(jù)隱私和完整性和提供對(duì)網(wǎng)站服務(wù)器身份認(rèn)證的功能，簡(jiǎn)單來(lái)說它就是安全版的 HTTP 。

HTTPS 訪問過程

HTTPS在進(jìn)行數(shù)據(jù)傳輸之前會(huì)與網(wǎng)站服務(wù)器和Web瀏覽器進(jìn)行一次握手，在握手時(shí)確定雙方的加密密碼信息。具體過程如下：

1、Web 瀏覽器將支持的加密信息發(fā)送給網(wǎng)站服務(wù)器
2、網(wǎng)站服務(wù)器會(huì)選擇出一套加密算法和哈希算法，將驗(yàn)證身份的信息以證書（證書發(fā)布CA機(jī)構(gòu)、證書有效期、公鑰、證書所有者、簽名等）的形式發(fā)送給Web瀏覽器；
3、當(dāng) Web 瀏覽器收到證書之后首先需要驗(yàn)證證書的合法性，如果證書受到瀏覽器信任則在瀏覽器地址欄會(huì)有標(biāo)志顯示，否則就會(huì)顯示不受信的標(biāo)識(shí)。當(dāng)證書受信之后，Web 瀏覽器會(huì)隨機(jī)生成一串密碼，并使用證書中的公鑰加密。之后就是使用約定好的哈希算法握手消息，并生成隨機(jī)數(shù)對(duì)消息進(jìn)行加密，再將之前生成的信息發(fā)送給網(wǎng)站；
4、當(dāng)網(wǎng)站服務(wù)器接收到瀏覽器發(fā)送過來(lái)的數(shù)據(jù)后，會(huì)使用網(wǎng)站本身的私鑰將信息解密確定密碼，然后通過密碼解密Web瀏覽器發(fā)送過來(lái)的握手信息，并驗(yàn)證哈希是否與Web瀏覽器一致。然后服務(wù)器會(huì)使用密碼加密新的握手信息，發(fā)送給瀏覽器；
5、最后瀏覽器解密并計(jì)算經(jīng)過哈希算法加密的握手消息，如果與服務(wù)發(fā)送過來(lái)的哈希一致，則此握手過程結(jié)束后，服務(wù)器與瀏覽器會(huì)使用之前瀏覽器生成的隨機(jī)密碼和對(duì)稱加密算法進(jìn)行加密交換數(shù)據(jù)。

HTTPS 加密算法

為了保護(hù)數(shù)據(jù)的安全，HTTPS 運(yùn)用了諸多加密算法：

1、對(duì)稱加密：有流式、分組兩種，加密和解密都是使用的同一個(gè)密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305 等。
2、非對(duì)稱加密：加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對(duì)稱加密算法性能較低，但是安全性超強(qiáng)，由于其加密特性，非對(duì)稱加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE 等。
3哈希算法：將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值，通常其長(zhǎng)度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等
4、數(shù)字簽名：簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過 hash 后的值），可以證明信息沒有被修改過。hash 值一般都會(huì)加密后（也就是簽名）再和信息一起發(fā)送，以保證這個(gè) hash 值不被修改。

從 HTTPS 到 HSTS

但是當(dāng)網(wǎng)站傳輸協(xié)議從 HTTP 到 HTTPS 之后，數(shù)據(jù)傳輸真的安全了嗎？

由于用戶習(xí)慣，通常準(zhǔn)備訪問某個(gè)網(wǎng)站時(shí)，在瀏覽器中只會(huì)輸入一個(gè)域名，而不會(huì)在域名前面加上 http:// 或者 https://，而是由瀏覽器自動(dòng)填充，當(dāng)前所有瀏覽器默認(rèn)填充的都是http://。一般情況網(wǎng)站管理員會(huì)采用了 301/302 跳轉(zhuǎn)的方式由 HTTP 跳轉(zhuǎn)到 HTTPS，但是這個(gè)過程總使用到 HTTP 因此容易發(fā)生劫持，受到第三方的攻擊。

這個(gè)時(shí)候就需要用到 HSTS（HTTP 嚴(yán)格安全傳輸）

HSTS

HSTS是國(guó)際互聯(lián)網(wǎng)工程組織 IETF 正在推行一種新的 Web 安全協(xié)議，網(wǎng)站采用 HSTS 后，用戶訪問時(shí)無(wú)需手動(dòng)在地址欄中輸入 HTTPS，瀏覽器會(huì)自動(dòng)采用 HTTPS 訪問網(wǎng)站地址，從而保證用戶始終訪問到網(wǎng)站的加密鏈接，保護(hù)數(shù)據(jù)傳輸安全。

HSTS原理

HSTS 主要是通過服務(wù)器發(fā)送響應(yīng)頭的方式來(lái)控制瀏覽器操作：

1、首先在服務(wù)器響應(yīng)頭中添加 HSTS 響應(yīng)頭： Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload] 此響應(yīng)頭只有在 https 訪問返回時(shí)才生效，其中[ ]中的參數(shù)表示可選 2、設(shè)置 max-age 參數(shù)，時(shí)間設(shè)置不宜過長(zhǎng)，建議設(shè)置時(shí)間為 6 個(gè)月；

3、當(dāng)用戶下次使用 HTTP 訪問，客戶端就會(huì)進(jìn)行內(nèi)部跳轉(zhuǎn)，并且能夠看到 307 Redirect Internel 的響應(yīng)碼；

4、網(wǎng)站服務(wù)器變成了 HTTPS 訪問源服務(wù)器。

開啟 HSTS 后網(wǎng)站可以有效防范中間人的攻擊，同時(shí)也會(huì)省去網(wǎng)站 301/302 跳轉(zhuǎn)花費(fèi)的時(shí)間，大大提升安全系數(shù)和用戶體驗(yàn)。

發(fā)送 HTTP 請(qǐng)求

發(fā)送HTTP請(qǐng)求的過程就是構(gòu)建HTTP請(qǐng)求報(bào)文并通過TCP協(xié)議中發(fā)送到服務(wù)器指定端口 請(qǐng)求報(bào)文由請(qǐng)求行，請(qǐng)求頭，請(qǐng)求體組成

請(qǐng)求行（Request Line）分為三個(gè)部分：請(qǐng)求方法、請(qǐng)求地址和協(xié)議及版本，以CRLF(rn)結(jié)束。 HTTP/1.1 定義的請(qǐng)求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE,最常的兩種GET和POST，如果是RESTful接口的話一般會(huì)用到GET、POST、DELETE、PUT。

請(qǐng)求頭

HTTP代理原理

普通代理

HTTP 客戶端向代理發(fā)送請(qǐng)求報(bào)文，代理服務(wù)器需要正確地處理請(qǐng)求和連接（例如正確處理 Connection: keep-alive），同時(shí)向服務(wù)器發(fā)送請(qǐng)求，并將收到的響應(yīng)轉(zhuǎn)發(fā)給客戶端。

客戶端通過代理訪問 A 網(wǎng)站，對(duì)于 A 來(lái)說，它會(huì)把代理當(dāng)做客戶端，完全察覺不到真正客戶端的存在，這實(shí)現(xiàn)了隱藏客戶端 IP 的目的。當(dāng)然代理也可以修改 HTTP 請(qǐng)求頭部，通過 X-Forwarded-IP 這樣的自定義頭部告訴服務(wù)端真正的客戶端 IP。但服務(wù)器無(wú)法驗(yàn)證這個(gè)自定義頭部真的是由代理添加，還是客戶端修改了請(qǐng)求頭，所以從 HTTP 頭部字段獲取 IP 時(shí)，需要格外小心。
對(duì)于客戶端來(lái)說，實(shí)際上訪問的是代理，代理收到請(qǐng)求報(bào)文后，再向真正提供服務(wù)的服務(wù)器發(fā)起請(qǐng)求，并將響應(yīng)轉(zhuǎn)發(fā)給瀏覽器。這種情況一般被稱之為反向代理，它可以用來(lái)隱藏服務(wù)器 IP 及端口。一般使用反向代理后，需要通過修改 DNS 讓域名解析到代理服務(wù)器 IP，這時(shí)瀏覽器無(wú)法察覺到真正服務(wù)器的存在，當(dāng)然也就不需要修改配置了。反向代理是 Web 系統(tǒng)最為常見的一種部署方式。

隧道代理

HTTP 客戶端通過 CONNECT 方法請(qǐng)求隧道代理創(chuàng)建一條到達(dá)任意目的服務(wù)器和端口的 TCP 連接，并對(duì)客戶端和服務(wù)器之間的后繼數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)。

客戶端通過代理訪問 A 網(wǎng)站，瀏覽器首先通過 CONNECT 請(qǐng)求，讓代理創(chuàng)建一條到 A 網(wǎng)站的 TCP 連接；一旦 TCP 連接建好，代理無(wú)腦轉(zhuǎn)發(fā)后續(xù)流量即可。所以這種代理，理論上適用于任意基于 TCP 的應(yīng)用層協(xié)議，HTTPS 網(wǎng)站使用的 TLS 協(xié)議當(dāng)然也可以。這也是這種代理為什么被稱為隧道的原因。對(duì)于 HTTPS 來(lái)說，客戶端透過代理直接跟服務(wù)端進(jìn)行 TLS 握手協(xié)商密鑰，所以依然是安全的