姓名：唐來賓? 學(xué)號(hào)：17101223417

轉(zhuǎn)載http://mp.weixin.qq.com/s/yHGjxGfGT3-HFIfI6fPFhA

【嵌牛導(dǎo)讀】HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手橡卤，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息扮念。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議，更是一件經(jīng)過藝術(shù)家精心設(shè)計(jì)的藝術(shù)品碧库，TLS/SSL中使用了非對(duì)稱加密柜与，對(duì)稱加密以及HASH算法。

【嵌牛鼻子】HTTPS TCP協(xié)議

【嵌牛提問】如何提高傳輸安全性嵌灰？

【嵌牛正文】1弄匕、HTTPS的工作原理

HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息沽瞭。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議粘茄，更是一件經(jīng)過藝術(shù)家精心設(shè)計(jì)的藝術(shù)品，TLS/SSL中使用了非對(duì)稱加密，對(duì)稱加密以及HASH算法柒瓣。握手過程的具體描述如下：

1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站儒搭。

2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器芙贫。證書里面包含了網(wǎng)站地址搂鲫，加密公鑰，以及證書的頒發(fā)機(jī)構(gòu)等信息磺平。

3.瀏覽器獲得網(wǎng)站證書之后瀏覽器要做以下工作：

a)?驗(yàn)證證書的合法性（頒發(fā)證書的機(jī)構(gòu)是否合法魂仍，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任拣挪，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭擦酌，否則會(huì)給出證書不受信的提示。

b) 如果證書受信任菠劝，或者是用戶接受了不受信的證書赊舶，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼，并用證書中提供的公鑰加密赶诊。

c)?使用約定好的HASH算法計(jì)算握手消息笼平，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站舔痪。

4.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：

a) 使用自己的私鑰將信息解密取出密碼寓调，使用密碼解密瀏覽器發(fā)來的握手消息，并驗(yàn)證HASH是否與瀏覽器發(fā)來的一致锄码。

b) 使用密碼加密一段握手消息夺英，發(fā)送給瀏覽器。

5.瀏覽器解密并計(jì)算握手消息的HASH滋捶，如果與服務(wù)端發(fā)來的HASH一致痛悯，此時(shí)握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密炬太。

這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗(yàn)證，目的是為了保證雙方都獲得了一致的密碼驯耻，并且可以正常的加密解密數(shù)據(jù)亲族，為后續(xù)真正數(shù)據(jù)的傳輸做一次測(cè)試。另外可缚，HTTPS一般使用的加密與HASH算法如下：

非對(duì)稱加密算法：RSA霎迫，DSA/DSS

對(duì)稱加密算法：AES，RC4帘靡，3DES

HASH算法：MD5知给，SHA1，SHA256

HTTPS對(duì)應(yīng)的通信時(shí)序圖如下：

HTTPS協(xié)議和HTTP協(xié)議的區(qū)別： （具體HTTP協(xié)議的介紹可見參考資料2）

https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少涩赢，需要交費(fèi)戈次。

http是超文本傳輸協(xié)議，信息是明文傳輸筒扒，https 則是具有安全性的ssl加密傳輸協(xié)議怯邪。

http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。

http的連接很簡單,是無狀態(tài)的 花墩。

HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸悬秉、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全冰蘑。

2和泌、TCP3次握手，4次揮手過程

1祠肥、建立連接協(xié)議（三次握手）

（1）客戶端發(fā)送一個(gè)帶SYN標(biāo)志的TCP報(bào)文到服務(wù)器武氓。這是三次握手過程中的報(bào)文1。

（2）服務(wù)器端回應(yīng)客戶端的搪柑，這是三次握手中的第2個(gè)報(bào)文聋丝，這個(gè)報(bào)文同時(shí)帶ACK標(biāo)志和SYN標(biāo)志。因此它表示對(duì)剛才客戶端SYN報(bào)文的回應(yīng)工碾；同時(shí)又標(biāo)志SYN給客戶端弱睦，詢問客戶端是否準(zhǔn)備好進(jìn)行數(shù)據(jù)通訊。

（3）客戶必須再次回應(yīng)服務(wù)段一個(gè)ACK報(bào)文渊额，這是報(bào)文段3况木。

為什么需要“三次握手”

在謝希仁著《計(jì)算機(jī)網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”旬迹。在另一部經(jīng)典的《計(jì)算機(jī)網(wǎng)絡(luò)》一書中講“三次握手”的目的是為了解決“網(wǎng)絡(luò)中存在延遲的重復(fù)分組”的問題火惊。這兩種不用的表述其實(shí)闡明的是同一個(gè)問題。

謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》中的例子是這樣的奔垦，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒有丟失屹耐，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server椿猎。本來這是一個(gè)早已失效的報(bào)文段惶岭。但server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求犯眠。于是就向client發(fā)出確認(rèn)報(bào)文段按灶，同意建立連接。假設(shè)不采用“三次握手”筐咧，那么只要server發(fā)出確認(rèn)鸯旁，新的連接就建立了噪矛。由于現(xiàn)在client并沒有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)铺罢，也不會(huì)向server發(fā)送數(shù)據(jù)艇挨。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)畏铆。這樣雷袋，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生辞居。例如剛才那種情況楷怒，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)瓦灶，就知道client并沒有要求建立連接鸠删。”贼陶。 主要目的防止server端一直等待刃泡，浪費(fèi)資源。

2碉怔、連接終止協(xié)議（四次揮手）

由于TCP連接是全雙工的烘贴，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接撮胧。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)桨踪，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉芹啥，而另一方執(zhí)行被動(dòng)關(guān)閉锻离。

（1） TCP客戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報(bào)文段4）墓怀。

（2） 服務(wù)器收到這個(gè)FIN汽纠，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1（報(bào)文段5）傀履。和SYN一樣虱朵，一個(gè)FIN將占用一個(gè)序號(hào)。

（3） 服務(wù)器關(guān)閉客戶端的連接钓账，發(fā)送一個(gè)FIN給客戶端（報(bào)文段6）碴犬。

（4） 客戶段發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（報(bào)文段7）官扣。

為什么需要“四次揮手”

那可能有人會(huì)有疑問翅敌，在tcp連接握手時(shí)為何ACK是和SYN一起發(fā)送羞福，這里ACK卻沒有和FIN一起發(fā)送呢惕蹄。原因是因?yàn)閠cp是全雙工模式，接收到FIN時(shí)意味將沒有數(shù)據(jù)再發(fā)來，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)卖陵。

握手遭顶，揮手過程中各狀態(tài)介紹（詳見wiki：TCP）

3次握手過程狀態(tài)：

LISTEN: 這個(gè)也是非常容易理解的一個(gè)狀態(tài)，表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)泪蔫，可以接受連接了棒旗。

SYN_SENT: 當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時(shí)，它首先發(fā)送SYN報(bào)文撩荣，因此也隨即它會(huì)進(jìn)入到了SYN_SENT狀態(tài)铣揉，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)文餐曹。（發(fā)送端）

SYN_RCVD: 這個(gè)狀態(tài)與SYN_SENT遙想呼應(yīng)這個(gè)狀態(tài)表示接受到了SYN報(bào)文逛拱，在正常情況下，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會(huì)話過程中的一個(gè)中間狀態(tài)台猴，很短暫朽合，基本上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個(gè)客戶端測(cè)試程序饱狂，故意將三次TCP握手過程中最后一個(gè)ACK報(bào)文不予發(fā)送曹步。因此這種狀態(tài)時(shí)，當(dāng)收到客戶端的ACK報(bào)文后休讳，它會(huì)進(jìn)入到ESTABLISHED狀態(tài)讲婚。（服務(wù)器端）

ESTABLISHED：這個(gè)容易理解了，表示連接已經(jīng)建立了衍腥。

4次揮手過程狀態(tài)：（可參考上圖）

FIN_WAIT_1: 這個(gè)狀態(tài)要好好解釋一下磺樱，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)婆咸，它想主動(dòng)關(guān)閉連接竹捉，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)尚骄。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后块差，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下倔丈，無論對(duì)方何種情況下憨闰，都應(yīng)該馬上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的需五，而FIN_WAIT_2狀態(tài)還有時(shí)常仇亩可以用netstat看到。（主動(dòng)方）

FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)宏邮，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET泽示，表示半連接缸血，也即有一方要求close連接，但另外還告訴對(duì)方械筛，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你(ACK信息)捎泻，稍后再關(guān)閉連接。（主動(dòng)方）

TIME_WAIT: 表示收到了對(duì)方的FIN報(bào)文埋哟，并發(fā)送出了ACK報(bào)文笆豁，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下赤赊，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)闯狱，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)抛计。（主動(dòng)方）

CLOSING（比較少見）: 這種狀態(tài)比較特殊扩氢，實(shí)際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)爷辱。正常情況下录豺，當(dāng)你發(fā)送FIN報(bào)文后，按理來說是應(yīng)該先收到（或同時(shí)收到）對(duì)方的ACK報(bào)文饭弓，再收到對(duì)方的FIN報(bào)文双饥。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒有收到對(duì)方的ACK報(bào)文弟断，反而卻也收到了對(duì)方的FIN報(bào)文咏花。什么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下阀趴，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一個(gè)SOCKET的話昏翰，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)文的情況，也即會(huì)出現(xiàn)CLOSING狀態(tài)刘急，表示雙方都正在關(guān)閉SOCKET連接棚菊。

CLOSE_WAIT: 這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉。怎么理解呢叔汁？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己统求，你系統(tǒng)毫無疑問地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)据块。接下來呢码邻，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒有的話另假，那么你也就可以close這個(gè)SOCKET像屋，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接边篮。所以你在CLOSE_WAIT狀態(tài)下己莺，需要完成的事情是等待你去關(guān)閉連接因苹。（被動(dòng)方）

LAST_ACK: 這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后篇恒，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后凶杖，也即可以進(jìn)入到CLOSED可用狀態(tài)了胁艰。（被動(dòng)方）

CLOSED: 表示連接中斷。

TCP的具體狀態(tài)圖可參考：

擴(kuò)展資料：

1智蝠、HTTPS那些事（一）HTTPS原理

2腾么、HTTP協(xié)議詳解

3、Wiki：TCP

4杈湾、HTTP協(xié)議及其POST與GET操作差異