一、簡(jiǎn)介

TCP,、UDP,、HTTP、HTTPS 都是通信協(xié)議,，也就是通信時(shí)所遵守的規(guī)則,，只有雙方按照這個(gè)規(guī)則“說(shuō)話”，對(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é)議,，只不過(guò)它們所在的層級(jí)不同,，負(fù)責(zé)的工作也不同，并且 HTTP 是基于 TCP 實(shí)現(xiàn)的,。

三,、Socket 通信

Socket 是為了實(shí)現(xiàn)以上的通信過(guò)程而建立成來(lái)的通信管道，其真實(shí)的代表是客戶端和服務(wù)器端的一個(gè)通信進(jìn)程,，雙方進(jìn)程通過(guò) Socket 進(jìn)行通信,，而通信的規(guī)則采用指定的協(xié)議。Socket 只是一種連接模式,，不是協(xié)議,。TCP、UDP,，簡(jiǎn)單的說(shuō)（雖然不準(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ā)來(lái)的 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),，完成三次握手。

為什么需要“三次握手”

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

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

謝希仁版《計(jì)算機(jī)網(wǎng)絡(luò)》中的例子是這樣的，“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：Client 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失,，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了,，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá) Server。本來(lái)這是一個(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 并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬 Server 的確認(rèn),，也不會(huì)向 Server 發(fā)送數(shù)據(jù),。但 Server 卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待 Client 發(fā)來(lái)數(shù)據(jù),。這樣,，Server 的很多資源就白白浪費(fèi)掉了,。

“四次揮手”過(guò)程

由于 TCP 連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉,。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè) FIN 來(lái)終止這個(gè)方向的連接,。收到一個(gè) FIN 只意味著這一方向上沒(méi)有數(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,，用來(lái)關(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,。

為什么需要“四次揮手”

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

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

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

假設(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)，也就說(shuō)這條 TCP 連接所對(duì)應(yīng)的資源不能被立即釋放或重新分配，直到另一方重發(fā)的 FIN 達(dá)到之后,，Client 重發(fā) ACK 后,，經(jīng)過(guò) 2MSL 時(shí)間周期沒(méi)有再收到另一方的 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)閉連接過(guò)程，并非異常,。

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

粘包、拆包發(fā)生原因
發(fā)生TCP粘包或拆包有很多原因,，現(xiàn)列出常見(jià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將多次寫(xiě)入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去,，將會(huì)發(fā)生粘包,。
4. 接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包,。

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

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

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

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

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

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

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

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

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

請(qǐng)求行中包含請(qǐng)求方法,，常見(jiàn)的請(qǐng)求方法有：

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

POST：傳輸實(shí)體主體，POST 主要用來(lái)傳輸數(shù)據(jù),，而 GET 主要用來(lái)獲取資源,。

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

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

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

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

其中,，狀態(tài)行包含響應(yīng)的狀態(tài),，常見(jiàn)的狀態(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)文中存在語(yǔ)法錯(cuò)誤,。
• 401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC 認(rèn)證、DIGEST 認(rèn)證）,。如果之前已進(jìn)行過(guò)一次請(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)在無(wú)法處理請(qǐng)求。

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

1. 建立 TCP 連接
   在 HTTP 工作開(kāi)始之前,，Web 瀏覽器首先要通過(guò)網(wǎng)絡(luò)與 Web 服務(wù)器建立連接，該連接是通過(guò) TCP 來(lái)完成的,，該協(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ā)送了一空白行來(lái)通知服務(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è)空白行來(lái)表示頭信息的發(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ā)送后將仍然保持打開(kāi)狀態(tài)，于是,，瀏覽器可以繼續(xù)通過(guò)相同的連接發(fā)送請(qǐng)求,。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間,，還節(jié)約了網(wǎng)絡(luò)帶寬。

六,、HTTPS 的工作原理

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

1. 瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站,。
2. 網(wǎng)站從中選出一組加密算法與 HASH 算法，并將自己的身份信息以證書(shū)的形式發(fā)回給瀏覽器,。證書(shū)里面包含了網(wǎng)站地址,，加密公鑰，以及證書(shū)的頒發(fā)機(jī)構(gòu)等信息,。
3. 瀏覽器獲得網(wǎng)站證書(shū)之后瀏覽器要做以下工作：
   a) 驗(yàn)證證書(shū)的合法性（頒發(fā)證書(shū)的機(jī)構(gòu)是否合法,，證書(shū)中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等），如果證書(shū)受信任,，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭,，否則會(huì)給出證書(shū)不受信的提示。
   b) 如果證書(shū)受信任,，或者是用戶接受了不受信的證書(shū),，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼，并用證書(shū)中提供的公鑰加密,。
   c) 使用約定好的 HASH 算法計(jì)算握手消息，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密,，最后將之前生成的所有信息發(fā)送給網(wǎng)站,。
4. 網(wǎng)站接收瀏覽器發(fā)來(lái)的數(shù)據(jù)之后要做以下的操作：
   a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來(lái)的握手消息,，并驗(yàn)證 HASH 是否與瀏覽器發(fā)來(lái)的一致,。
   b) 使用密碼加密一段握手消息，發(fā)送給瀏覽器,。
5. 瀏覽器解密并計(jì)算握手消息的 HASH,，如果與服務(wù)端發(fā)來(lái)的 HASH 一致,，此時(shí)握手過(guò)程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密,。

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

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

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

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