一镇饮、簡(jiǎn)介

TCP、UDP箕母、HTTP储藐、HTTPS 都是通信協(xié)議俱济，也就是通信時(shí)所遵守的規(guī)則，只有雙方按照這個(gè)規(guī)則“說話”钙勃，對(duì)方才能理解或?yàn)橹?wù)蛛碌。

二、TCP辖源、UDP蔚携、HTTP、HTTPS 之間的關(guān)系

TCP/IP 是個(gè)協(xié)議組克饶，可分為四個(gè)層次：網(wǎng)絡(luò)接口層酝蜒、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層矾湃。

在網(wǎng)絡(luò)層亡脑，有 IP 協(xié)議、ICMP 協(xié)議邀跃、ARP 協(xié)議霉咨、RARP 協(xié)議等。
在傳輸層拍屑，有 TCP 協(xié)議與 UDP 協(xié)議途戒。
在應(yīng)用層，有 WebSocket丽涩、FTP、HTTP裁蚁、TELNET矢渊、SMTP、DNS 等協(xié)議枉证。
而 HTTPS 可以理解為更安全的 HTTP 協(xié)議矮男。

因此，TCP室谚、UDP毡鉴、HTTP、HTTPS 都是通信協(xié)議秒赤，只不過它們所在的層級(jí)不同猪瞬，負(fù)責(zé)的工作也不同，并且 HTTP 是基于 TCP 實(shí)現(xiàn)的入篮。

三陈瘦、Socket 通信

Socket 是為了實(shí)現(xiàn)以上的通信過程而建立成來的通信管道，其真實(shí)的代表是客戶端和服務(wù)器端的一個(gè)通信進(jìn)程潮售，雙方進(jìn)程通過 Socket 進(jìn)行通信痊项，而通信的規(guī)則采用指定的協(xié)議锅风。Socket 只是一種連接模式，不是協(xié)議鞍泉。TCP皱埠、UDP，簡(jiǎn)單的說（雖然不準(zhǔn)確）是兩個(gè)基本的協(xié)議咖驮，很多其它協(xié)議都是基于這兩個(gè)協(xié)議边器，如 HTTP 就是基于 TCP 的。用 Socket 可以創(chuàng)建 TCP 連接游沿，也可以創(chuàng)建 UDP 連接饰抒，這意味著，用 Socket 可以創(chuàng)建任何協(xié)議的連接诀黍，因?yàn)槠渌鼌f(xié)議都是基于此的袋坑。

四、TCP 協(xié)議

TCP 的建立連接協(xié)議又稱之為“三次握手”：

第一次握手：建立連接時(shí)眯勾，客戶端發(fā)送 SYN 包(syn=i)到服務(wù)器枣宫，并進(jìn)入 SYN_SEND 狀態(tài)，等待服務(wù)器確認(rèn)吃环。

第二次握手：服務(wù)器收到客戶端發(fā)來的 SYN 包也颤，必須對(duì)客戶端進(jìn)行確認(rèn) ACK (ack=i+1)，同時(shí)服務(wù)器也發(fā)送一個(gè) SYN 包(syn=j)到客戶端郁轻，即服務(wù)器會(huì)發(fā)送 SYN+ACK 包翅娶，此時(shí)服務(wù)器進(jìn)入 SYN_RECV 狀態(tài)。

第三次握手：客戶端收到服務(wù)器發(fā)送的 SYN+ACK 包好唯，向服務(wù)器發(fā)送確認(rèn)包 ACK(ack=j+1)竭沫，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)骑篙，完成三次握手蜕提。

TCP 三次握手

為什么需要“三次握手”

第一個(gè)原因：初始化 Seq，TCP 通信是有序的靶端，通信雙方要通知對(duì)方自己的 Seq 值谎势，也就是上圖中的 X 和 Y，這個(gè)值要作為之后數(shù)據(jù)通信的序號(hào)杨名，以保證應(yīng)用層接受到數(shù)據(jù)不會(huì)因網(wǎng)絡(luò)延時(shí)等原因而亂序脏榆，TCP 會(huì)用 Seq 來拼接數(shù)據(jù)。

第二個(gè)原因：在謝希仁版《計(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)長(zhǎng)時(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)掉了况鸣。

“四次揮手”過程

由于 TCP 連接是全雙工的牢贸，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè) FIN 來終止這個(gè)方向的連接镐捧。收到一個(gè) FIN 只意味著這一方向上沒有數(shù)據(jù)流動(dòng)潜索，而對(duì)方仍能發(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ù)傳送玩焰。
2. 服務(wù)器收到這個(gè) FIN由驹，發(fā)回一個(gè) ACK芍锚，確認(rèn)序號(hào)為收到的序號(hào)加 1昔园。和 SYN 一樣，一個(gè) FIN 將占用一個(gè)序號(hào)并炮。
3. 服務(wù)器關(guān)閉客戶端的連接默刚，發(fā)送一個(gè) FIN 給客戶端。
4. 客戶段發(fā)回 ACK 報(bào)文確認(rèn)逃魄，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1荤西。

TCP四次揮手

為什么需要“四次揮手”

那可能有人會(huì)有疑問，在 TCP 連接握手時(shí)為何 ACK 是和 SYN 一起發(fā)送，這里 ACK 卻沒有和 FIN 一起發(fā)送呢邪锌？

原因是因?yàn)?TCP 是全雙工模式勉躺，接收到 FIN 時(shí)意味將沒有數(shù)據(jù)再發(fā)來，但是還是可以繼續(xù)發(fā)送數(shù)據(jù)觅丰。同時(shí)發(fā)送雙方都需要發(fā)送 FIN 報(bào)文和 ACK 報(bào)文饵溅，加起來就是四次了。

TIME_WAIT 狀態(tài)
在四次揮手的最后一次揮手中妇萄，主動(dòng)斷開方在發(fā)送最后一個(gè) ACK 后蜕企，不能立刻關(guān)閉，而是需要等待 2MSL 后才能關(guān)閉冠句，這是為什么呢轻掩？同時(shí)這也是面試中常提到的一個(gè)問題。原因如下：

假設(shè)發(fā)起主動(dòng)關(guān)閉的一方(Client)最后發(fā)送的 ACK 在網(wǎng)絡(luò)中丟失懦底，由于 TCP 協(xié)議的重傳機(jī)制唇牧，被動(dòng)關(guān)閉的一方將會(huì)重發(fā) FIN，在該 FIN 到達(dá) Client之前基茵，Client 必須維護(hù)這條連接狀態(tài)奋构，也就說這條 TCP 連接所對(duì)應(yīng)的資源不能被立即釋放或重新分配，直到另一方重發(fā)的 FIN 達(dá)到之后拱层，Client 重發(fā) ACK 后弥臼，經(jīng)過 2MSL 時(shí)間周期沒有再收到另一方的 FIN 之后，該 TCP 連接才能 CLOSED根灯。

如果主動(dòng)關(guān)閉一方不維護(hù)這樣一個(gè) TIME_WAIT 狀態(tài)径缅，那么當(dāng)被動(dòng)關(guān)閉一方重發(fā)的 FIN 到達(dá)時(shí)，主動(dòng)關(guān)閉一方的 TCP 傳輸層會(huì)用 RST 包響應(yīng)對(duì)方烙肺，這會(huì)被對(duì)方認(rèn)為是有錯(cuò)誤發(fā)生纳猪，然而這事實(shí)上只是正常的關(guān)閉連接過程，并非異常桃笙。

TCP 粘包拆包
TCP是基于字節(jié)流的氏堤，雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無結(jié)構(gòu)的字節(jié)流搏明，沒有邊界鼠锈；另外從 TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒有表示數(shù)據(jù)長(zhǎng)度的字段星著，基于上面兩點(diǎn)购笆，在使用TCP傳輸數(shù)據(jù)時(shí)，才有粘包或者拆包現(xiàn)象發(fā)生的可能虚循。

粘包同欠、拆包發(fā)生原因
發(fā)生TCP粘包或拆包有很多原因样傍，現(xiàn)列出常見的幾點(diǎn)：

1. 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包铺遂。
2. 待發(fā)送數(shù)據(jù)大于MSS（最大報(bào)文長(zhǎng)度）衫哥，TCP在傳輸前將進(jìn)行拆包。
3. 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小襟锐，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去炕檩，將會(huì)發(fā)生粘包。
4. 接收數(shù)據(jù)端的應(yīng)用層沒有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)捌斧，將發(fā)生粘包笛质。

粘包拆包

粘包、拆包解決辦法
通過以上分析捞蚂，我們清楚了粘包或拆包發(fā)生的原因妇押，那么如何解決這個(gè)問題呢？解決問題的關(guān)鍵在于如何給每個(gè)數(shù)據(jù)包添加邊界信息姓迅，常用的方法有如下幾個(gè)：

1敲霍、發(fā)送端給每個(gè)數(shù)據(jù)包添加包首部，首部中應(yīng)該至少包含數(shù)據(jù)包的長(zhǎng)度丁存，這樣接收端在接收到數(shù)據(jù)后肩杈，通過讀取包首部的長(zhǎng)度字段，便知道每一個(gè)數(shù)據(jù)包的實(shí)際長(zhǎng)度了解寝。

2扩然、發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度（不夠的可以通過補(bǔ)0填充），這樣接收端每次從接收緩沖區(qū)中讀取固定長(zhǎng)度的數(shù)據(jù)就自然而然的把每個(gè)數(shù)據(jù)包拆分開來聋伦。

3夫偶、可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號(hào)觉增，這樣兵拢，接收端通過這個(gè)邊界就可以將不同的數(shù)據(jù)包拆分開。

那么 UDP 是否會(huì)發(fā)生粘包或拆包的現(xiàn)象呢逾礁？
答案是：不會(huì)说铃。UDP 是基于報(bào)文發(fā)送的，從 UDP 的幀結(jié)構(gòu)可以看出嘹履，在 UDP 首部采用了 16bit 來指示 UDP 數(shù)據(jù)報(bào)文的長(zhǎng)度腻扇，因此在應(yīng)用層能很好的將不同的數(shù)據(jù)報(bào)文區(qū)分開，從而避免粘包和拆包的問題植捎。

五衙解、什么是HTTP協(xié)議

HTTP 全稱是 HyperText Transfer Protocal阳柔，即：超文本傳輸協(xié)議焰枢。從1990 年開始就在 WWW 上廣泛應(yīng)用，是現(xiàn)今在 WWW 上應(yīng)用最多的協(xié)議。HTTP 是應(yīng)用層協(xié)議济锄，當(dāng)你上網(wǎng)瀏覽網(wǎng)頁的時(shí)候暑椰，瀏覽器和 Web 服務(wù)器之間就會(huì)通過 HTTP 在 Internet 上進(jìn)行數(shù)據(jù)的發(fā)送和接收。HTTP 是一個(gè)基于請(qǐng)求/響應(yīng)模式的荐绝、無狀態(tài)的協(xié)議一汽，即我們通常所說的 Request/Response。

先看看請(qǐng)求(Request)報(bào)文：

HTTP_Request

請(qǐng)求(Request)報(bào)文 = 請(qǐng)求行 + 請(qǐng)求頭 + 空行 + 請(qǐng)求體

請(qǐng)求行中包含請(qǐng)求方法低滩，常見的請(qǐng)求方法有：

GET：獲取資源召夹，當(dāng)前網(wǎng)絡(luò)請(qǐng)求中，絕大部分使用的是 GET 方法恕沫。

POST：傳輸實(shí)體主體监憎，POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源婶溯。

PUT：上傳文件鲸阔，由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件迄委，因此存在安全性問題褐筛，一般不使用該方法。

DELETE：刪除文件叙身，與 PUT 功能相反渔扎，并且同樣不帶驗(yàn)證機(jī)制。

HEAD：獲取報(bào)文首部信轿，和 GET 方法類似赞警，但是不返回報(bào)文實(shí)體主體部分。主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間等虏两。

HTTP_Response

響應(yīng)(Response)報(bào)文 = 狀態(tài)行 + 響應(yīng)頭 + 空行 + 響應(yīng)體

其中愧旦，狀態(tài)行包含響應(yīng)的狀態(tài)，常見的狀態(tài)如下：

1XX 信息

• 100 Continue ：表明到目前為止都很正常定罢，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)笤虫。

2XX 成功

• 200 OK

• 204 No Content ：請(qǐng)求已經(jīng)成功處理，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分祖凫。一般在只需要從客戶端往服務(wù)器發(fā)送信息琼蚯，而不需要返回?cái)?shù)據(jù)時(shí)使用。

• 206 Partial Content ：表示客戶端進(jìn)行了范圍請(qǐng)求惠况，響應(yīng)報(bào)文包含由 Content-Range 指定范圍的實(shí)體內(nèi)容遭庶。

3XX 重定向

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時(shí)性重定向

• 303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源稠屠。

• 注：雖然 HTTP 協(xié)議規(guī)定 301峦睡、302 狀態(tài)下重定向時(shí)不允許把 POST 方法改成 GET 方法翎苫，但是大多數(shù)瀏覽器都會(huì)在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法榨了。

• 304 Not Modified ：如果請(qǐng)求報(bào)文首部包含一些條件煎谍，例如：If-Match，If-Modified-Since龙屉，If-None-Match呐粘，If-Range，If-Unmodified-Since转捕，如果不滿足條件作岖，則服務(wù)器會(huì)返回 304 狀態(tài)碼。

• 307 Temporary Redirect ：臨時(shí)重定向五芝，與 302 的含義類似鳍咱，但是 307 要求瀏覽器不會(huì)把重定向請(qǐng)求的 POST 方法改成 GET 方法。

4XX 客戶端錯(cuò)誤

• 400 Bad Request ：請(qǐng)求報(bào)文中存在語法錯(cuò)誤与柑。

• 401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC 認(rèn)證谤辜、DIGEST 認(rèn)證）。如果之前已進(jìn)行過一次請(qǐng)求价捧，則表示用戶認(rèn)證失敗丑念。

• 403 Forbidden ：請(qǐng)求被拒絕。

• 404 Not Found

5XX 服務(wù)器錯(cuò)誤

• 500 Internal Server Error ：服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤结蟋。

• 503 Service Unavailable ：服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)脯倚，現(xiàn)在無法處理請(qǐng)求。

HTTP 通信機(jī)制是在一次完整的 HTTP 通信過程中嵌屎，Web 瀏覽器與 Web 服務(wù)器之間將完成下列7個(gè)步驟：

1. 建立 TCP 連接
   在 HTTP 工作開始之前推正，Web 瀏覽器首先要通過網(wǎng)絡(luò)與 Web 服務(wù)器建立連接，該連接是通過 TCP 來完成的宝惰，該協(xié)議與 IP 協(xié)議共同構(gòu)建 Internet植榕，即著名的 TCP/IP 協(xié)議族，因此 Internet 又被稱作是 TCP/IP 網(wǎng)絡(luò)尼夺。HTTP 是比 TCP 更高層次的應(yīng)用層協(xié)議尊残，根據(jù)規(guī)則，只有低層協(xié)議建立之后才能淤堵，才能進(jìn)行更層協(xié)議的連接寝衫，因此，首先要建立 TCP 連接拐邪，一般 TCP 連接的端口號(hào)是 80
2. Web 瀏覽器向 Web 服務(wù)器發(fā)送請(qǐng)求命令
   一旦建立了TCP連接慰毅，Web瀏覽器就會(huì)向Web服務(wù)器發(fā)送請(qǐng)求命令。例如：GET/sample/hello.jsp HTTP/1.1扎阶。
3. Web 瀏覽器發(fā)送請(qǐng)求頭信息
   瀏覽器發(fā)送其請(qǐng)求命令之后汹胃，還要以頭信息的形式向 Web 服務(wù)器發(fā)送一些別的信息婶芭，之后瀏覽器發(fā)送了一空白行來通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送统台。
4. Web 服務(wù)器應(yīng)答
   客戶機(jī)向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器會(huì)客戶機(jī)回送應(yīng)答啡邑，HTTP/1.1 200 OK贱勃，應(yīng)答的第一部分是協(xié)議的版本號(hào)和應(yīng)答狀態(tài)碼
5. Web 服務(wù)器發(fā)送應(yīng)答頭信息
   正如客戶端會(huì)隨同請(qǐng)求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會(huì)隨同應(yīng)答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請(qǐng)求的文檔谤逼。
6. Web 服務(wù)器向?yàn)g覽器發(fā)送數(shù)據(jù)
   Web 服務(wù)器向?yàn)g覽器發(fā)送頭信息后贵扰，它會(huì)發(fā)送一個(gè)空白行來表示頭信息的發(fā)送到此為結(jié)束，接著流部，它就以 Content-Type 應(yīng)答頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)
7. Web 服務(wù)器關(guān)閉 TCP 連接
   一般情況下戚绕，一旦 Web 服務(wù)器向?yàn)g覽器發(fā)送了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉 TCP 連接枝冀，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行Connection:keep-alive舞丛，TCP 連接在發(fā)送后將仍然保持打開狀態(tài)，于是果漾，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請(qǐng)求球切。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬绒障。

六吨凑、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)行加密范嘱。

HTTPS 通信過程

簡(jiǎn)單的說：HTTPS 使用對(duì)稱加密的方法通信送膳，秘鑰為 Key。但是為了安全的把秘鑰 Key 發(fā)送給對(duì)方丑蛤，于是在通信前肠缨，使用非對(duì)稱加密的方法加密 Key。

這樣做的目的是：非對(duì)稱加密的安全性更強(qiáng)盏阶，但是加解密過程復(fù)雜耗時(shí)晒奕，對(duì)稱加密的加解密過程簡(jiǎn)單，但安全性不強(qiáng)名斟，于是 HTTPS 綜合兩種加密方式脑慧，既保證了安全性，又保證了效率砰盐。

HTTPS協(xié)議和HTTP協(xié)議的區(qū)別：

1. HTTPS 協(xié)議需要到 ca 申請(qǐng)證書闷袒，一般免費(fèi)證書很少，需要交費(fèi)岩梳。
2. HTTP 是超文本傳輸協(xié)議囊骤，信息是明文傳輸，HTTPS 則是具有安全性的 SSL 加密傳輸協(xié)議冀值。
3. HTTP和HTTPS使用的是完全不同的連接方式用的端口也不一樣也物，前者是 80，后者是 443列疗。
4. HTTP 的連接很簡(jiǎn)單滑蚯，是無狀態(tài)的 。
5. HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議告材，要比 HTTP 協(xié)議安全坤次。