一、HTTP

HTTP（HyperText Transfer Protocol：超文本傳輸協(xié)議）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。 簡(jiǎn)單來(lái)說(shuō)就是一種發(fā)布和接收 HTML 頁(yè)面的方法，被用于在 Web 瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息。

HTTP 默認(rèn)工作在 TCP 協(xié)議 80 端口，另外還有 8000 和 8080 也很常用。用戶訪問(wèn)網(wǎng)站 http:// 打頭的都是標(biāo)準(zhǔn) HTTP 服務(wù)。

HTTP 協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號(hào)、密碼等支付信息。

HTTP會(huì)話分為三個(gè)階段：

1. 客戶端建立一條 TCP 連接（如果傳輸層不是 TCP，也可以是其他適合的連接）。
2. 客戶端發(fā)送請(qǐng)求并等待應(yīng)答。
3. 服務(wù)器處理請(qǐng)求并送回應(yīng)答，回應(yīng)包括一個(gè)狀態(tài)碼和對(duì)應(yīng)的數(shù)據(jù)。

從 HTTP/1.1 開(kāi)始，連接在完成第三階段后不再關(guān)閉，客戶端可以再次發(fā)起新的請(qǐng)求。這意味著第二步和第三步可以連續(xù)進(jìn)行數(shù)次。

一個(gè)HTTP請(qǐng)求一般由四個(gè)部分組成：

1).HTTP請(qǐng)求的方法或動(dòng)作，比如是GET請(qǐng)求還是POST請(qǐng)求。
2).正在請(qǐng)求的URL，就是請(qǐng)求的地址（我們輸入的一般是網(wǎng)址）。
3).請(qǐng)求頭，包含一些客戶端環(huán)境信息，身份驗(yàn)證信息等。
4).請(qǐng)求體，也就是請(qǐng)求正文，請(qǐng)求正文中可以包含客戶提交的查詢字符信息，表單信息等等。

HTTP請(qǐng)求的兩種方式：

• GET請(qǐng)求：一般用于信息獲取，使用URL傳遞參數(shù)，對(duì)所發(fā)送信息的數(shù)量也有限制，一般在2000個(gè)字符，GET請(qǐng)求一般用于獲取信息，換句話說(shuō)，就是查詢，查詢不會(huì)影響數(shù)據(jù)本身。但是GET請(qǐng)求發(fā)送的信息對(duì)任何人都是可見(jiàn)的，這樣對(duì)數(shù)據(jù)的保密性就比較低了。
• POST請(qǐng)求：一般用于修改服務(wù)器上的資源。對(duì)所發(fā)送信息的數(shù)量無(wú)限制。通過(guò)POST方法一般用來(lái)從表單發(fā)送數(shù)據(jù)，這些對(duì)數(shù)據(jù)對(duì)其他人是不可見(jiàn)的，所以相對(duì)于GET請(qǐng)求來(lái)說(shuō)保密性就高得多。

一個(gè)HTTP響應(yīng)一般由三部分組成：

1）一個(gè)數(shù)字和文字組成的狀態(tài)碼，用來(lái)顯示請(qǐng)求是成功還是失敗。
2）響應(yīng)頭，響應(yīng)頭也和請(qǐng)求頭一樣包含許多有用的信息，例如服務(wù)器類型，日期時(shí)間，內(nèi)容類型和長(zhǎng)度等等。
3）相應(yīng)體，也就是響應(yīng)正文。

HTTP狀態(tài)碼由3位數(shù)字構(gòu)成：

首位數(shù)字定義了狀態(tài)碼的類型
1XX：信息類，表示收到Web瀏覽器請(qǐng)求，正在進(jìn)一步的處理中。
2XX：成功，表示用戶請(qǐng)求被正確接收，理解和處理。例如：200 OK。
3XX：重定向，表示請(qǐng)求沒(méi)有成功，客戶必須采取進(jìn)一步的動(dòng)作。
4XX：客戶端錯(cuò)誤，表示客戶端提交的請(qǐng)求有錯(cuò)誤。例如：404NOT Found，意味著請(qǐng)求中所引用的文檔不存在。
5XX：服務(wù)器錯(cuò)誤，表示服務(wù)器不能完成對(duì)請(qǐng)求的處理。

常見(jiàn)狀態(tài)碼：
301：被請(qǐng)求的資源已永久移動(dòng)到新位置
400： 1、語(yǔ)義有誤，當(dāng)前請(qǐng)求無(wú)法被服務(wù)器理解。2、請(qǐng)求參數(shù)有誤。
403：服務(wù)器已經(jīng)理解請(qǐng)求，但是拒絕執(zhí)行它。
404：請(qǐng)求失敗，請(qǐng)求所希望得到的資源未被在服務(wù)器上發(fā)現(xiàn)。
408： 請(qǐng)求超時(shí)。
500： 服務(wù)器遇到了不知道如何處理的情況。
501： 此請(qǐng)求方法不被服務(wù)器支持且無(wú)法被處理。
503：服務(wù)器沒(méi)有準(zhǔn)備好處理請(qǐng)求。 常見(jiàn)原因是服務(wù)器因維護(hù)或重載而停機(jī)。
504：當(dāng)服務(wù)器作為網(wǎng)關(guān)，不能及時(shí)得到響應(yīng)時(shí)返回此錯(cuò)誤代碼。
505：服務(wù)器不支持請(qǐng)求中所使用的HTTP協(xié)議版本。

了解了上面的內(nèi)容之后，那么問(wèn)題來(lái)了，當(dāng)我們?cè)趙eb瀏覽器的地址欄中輸入： www.baidu.com，然后回車，到底發(fā)生了什么？
1.對(duì)www.baidu.com這個(gè)網(wǎng)址進(jìn)行DNS域名解析，得到對(duì)應(yīng)的IP地址
2.根據(jù)這個(gè)IP，找到對(duì)應(yīng)的服務(wù)器，發(fā)起TCP的三次握手
3.建立TCP連接后發(fā)起HTTP請(qǐng)求
4.服務(wù)器響應(yīng)HTTP請(qǐng)求，瀏覽器得到html文件
5.瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js、css圖片等）（先得到html代碼，才能去找這些資源）
6.瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶
注：

• DNS域名解析采用的是遞歸查詢的方式，過(guò)程是，先去找DNS緩存->緩存找不到就去找根域名服務(wù)器->根域名又會(huì)去找下一級(jí)，這樣遞歸查找之后，找到了，給我們的web瀏覽器

• 為什么HTTP協(xié)議要基于TCP來(lái)實(shí)現(xiàn)？ TCP是一個(gè)端到端的可靠的面相連接的協(xié)議，HTTP基于傳輸層TCP協(xié)議不用擔(dān)心數(shù)據(jù)傳輸?shù)母鞣N問(wèn)題（當(dāng)發(fā)生錯(cuò)誤時(shí)，會(huì)重傳）

• 最后一步瀏覽器是如何對(duì)頁(yè)面進(jìn)行渲染的？
  a）解析html文件構(gòu)成 DOM樹(shù)，
  b）解析CSS文件構(gòu)成渲染樹(shù)，
  c）邊解析，邊渲染 ，
  d）JS 單線程運(yùn)行，JS有可能修改DOM結(jié)構(gòu)，意味著JS執(zhí)行完成前，后續(xù)所有資源的下載是沒(méi)有必要的，所以JS是單線程，會(huì)阻塞后續(xù)資源下載

下面我們來(lái)詳細(xì)看看這幾個(gè)過(guò)程的具體細(xì)節(jié)：

1.域名解析

a）首先會(huì)搜索瀏覽器自身的DNS緩存（緩存時(shí)間比較短，大概只有1分鐘，且只能容納1000條緩存）

b）如果瀏覽器自身的緩存里面沒(méi)有找到，那么瀏覽器會(huì)搜索系統(tǒng)自身的DNS緩存

c）如果還沒(méi)有找到，那么嘗試從 hosts文件里面去找

d）在前面三個(gè)過(guò)程都沒(méi)獲取到的情況下，就遞歸地去域名服務(wù)器去查找，具體過(guò)程如下

image.png

DNS優(yōu)化：兩個(gè)方面：DNS緩存、DNS負(fù)載均衡

2.TCP連接（三次握手）

拿到域名對(duì)應(yīng)的IP地址之后，User-Agent（一般指瀏覽器）會(huì)以一個(gè)隨機(jī)端口（1024<端口<65535）向服務(wù)器的WEB程序（常用的有httpd，nginx）等的80端口。這個(gè)連接請(qǐng)求（原始的http請(qǐng)求經(jīng)過(guò)TCP/IP4層模型的層層封包）到達(dá)服務(wù)器端后（這中間有各種路由設(shè)備，局域網(wǎng)內(nèi)除外），進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧（用于識(shí)別連接請(qǐng)求，解封包，一層一層的剝開(kāi)），還有可能要經(jīng)過(guò)Netfilter防火墻（屬于內(nèi)核的模塊）的過(guò)濾，最終達(dá)到WEB程序，最終建立了TCP/IP的連接

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。
在運(yùn)用此協(xié)議進(jìn)行數(shù)據(jù)傳輸前都會(huì)進(jìn)行連接的建立工作（三次握手）
當(dāng)數(shù)據(jù)傳輸完畢，連接的雙方都會(huì)通知對(duì)方要釋放此連接（四次揮手）
tcp標(biāo)志位有6種標(biāo)志位
1.SYN（synchronous ）建立聯(lián)機(jī)

2.ACK（acknowledgement）確認(rèn)

3.PSH（push）傳送

4.FIN（finsh）結(jié)束

5.RST（reset）重置

6.URG（urgent）緊急

圖解TCP與UDP的三次握手與四次揮手過(guò)程

image.png

三次握手過(guò)程：

第一次握手：Client將標(biāo)志位SYN置為1，ACK=0，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給Server。

第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接，Server將標(biāo)志位SYN和ACK都置為1，確認(rèn)號(hào)ack =J+1，隨機(jī)產(chǎn)生序列號(hào)seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求。

第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，可以開(kāi)始傳輸數(shù)據(jù)了。

image.png

四次揮手過(guò)程：

第一次揮手：當(dāng)傳輸?shù)臄?shù)據(jù)到達(dá)尾部時(shí)，Client向Server發(fā)送FIN = 1標(biāo)志位，seq = x,用來(lái)關(guān)閉Client到Server的數(shù)據(jù)傳送。(Client進(jìn)入FIN_WAIT_1狀態(tài))

第二次揮手：Server收到FIN后，發(fā)送ACK = 1，確認(rèn)序號(hào)ack = x+1，seq=y給Client，Server進(jìn)入CLOSE_WAIT狀態(tài)。

第三次揮手：數(shù)據(jù)傳輸完成后，Server發(fā)送FIN = 1，ACK=1,ack=x+1,seq=z用來(lái)關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。

第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送ACK=1,ack=z+1,seq=x+1給Server，Server進(jìn)入CLOSED狀態(tài)，完成四次揮手。

為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢？
因?yàn)楫?dāng)Server端收到Client端的SYN連接請(qǐng)求報(bào)文后，可以把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。(其中ACK報(bào)文是用來(lái)應(yīng)答的，SYN報(bào)文是用來(lái)同步的。)但是關(guān)閉連接時(shí)，當(dāng)Server端收到FIN報(bào)文時(shí)，僅僅表示Client不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，Server也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，很可能并不會(huì)立即關(guān)閉SOCKET，所以ACK和FIN一般都會(huì)分開(kāi)發(fā)送。會(huì)先回復(fù)一個(gè)ACK報(bào)文，告訴Client端，"你發(fā)的FIN報(bào)文我收到了"。只有等到我Server端所有的報(bào)文都發(fā)送完了，我才能發(fā)送FIN報(bào)文。

3.建立TCP連接之后，發(fā)起HTTP請(qǐng)求

HTTP請(qǐng)求報(bào)文由三部分組成：請(qǐng)求行，請(qǐng)求頭和請(qǐng)求正文

請(qǐng)求行：用于描述客戶端的請(qǐng)求方式，請(qǐng)求的資源名稱以及使用的HTTP協(xié)議的版本號(hào)（例：GET/books/java.html HTTP/1.1）

請(qǐng)求頭：用于描述客戶端請(qǐng)求哪臺(tái)主機(jī)，以及客戶端的一些環(huán)境信息等

注：這里提一個(gè)請(qǐng)求頭 Connection，Connection設(shè)置為 keep-alive用于說(shuō)明 客戶端這邊設(shè)置的是，本次HTTP請(qǐng)求之后并不需要關(guān)閉TCP連接，這樣可以使下次HTTP請(qǐng)求使用相同的TCP通道，節(jié)省TCP建立連接的時(shí)間

請(qǐng)求正文：當(dāng)使用POST, PUT等方法時(shí)，通常需要客戶端向服務(wù)器傳遞數(shù)據(jù)。這些數(shù)據(jù)就儲(chǔ)存在請(qǐng)求正文中（GET方式是保存在url地址后面，不會(huì)放到這里）

4.服務(wù)器端響應(yīng)http請(qǐng)求，瀏覽器得到html代碼

HTTP響應(yīng)也由三部分組成：狀態(tài)碼，響應(yīng)頭和實(shí)體內(nèi)容

狀態(tài)碼：狀態(tài)碼用于表示服務(wù)器對(duì)請(qǐng)求的處理結(jié)果

列舉幾種常見(jiàn)的：200（沒(méi)有問(wèn)題） 302（要你去找別人） 304（要你去拿緩存） 307（要你去拿緩存） 403（有這個(gè)資源，但是沒(méi)有訪問(wèn)權(quán)限） 404（服務(wù)器沒(méi)有這個(gè)資源） 500（服務(wù)器這邊有問(wèn)題）

若干響應(yīng)頭：響應(yīng)頭用于描述服務(wù)器的基本信息，以及客戶端如何處理數(shù)據(jù)

實(shí)體內(nèi)容：服務(wù)器返回給客戶端的數(shù)據(jù)

注：html資源文件應(yīng)該不是通過(guò) HTTP響應(yīng)直接返回去的，應(yīng)該是通過(guò)nginx通過(guò)io操作去拿到的吧

5.瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源

瀏覽器拿到html文件后，就開(kāi)始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時(shí)，就向服務(wù)器端去請(qǐng)求下載（會(huì)使用多線程下載，每個(gè)瀏覽器的線程數(shù)不一樣），這是時(shí)候就用上 keep-alive特性了，建立一次HTTP連接，可以請(qǐng)求多個(gè)資源，下載資源的順序就是按照代碼里面的順序，但是由于每個(gè)資源大小不一樣，而瀏覽器又是多線程請(qǐng)求請(qǐng)求資源，所以這里顯示的順序并不一定是代碼里面的順序。

6.瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶

最后，瀏覽器利用自己內(nèi)部的工作機(jī)制，把請(qǐng)求的靜態(tài)資源和html代碼進(jìn)行渲染，渲染之后呈現(xiàn)給用戶

瀏覽器是一個(gè)邊解析邊渲染的過(guò)程。首先瀏覽器解析HTML文件構(gòu)建DOM樹(shù)，然后解析CSS文件構(gòu)建渲染樹(shù)，等到渲染樹(shù)構(gòu)建完成后，瀏覽器開(kāi)始布局渲染樹(shù)并將其繪制到屏幕上。這個(gè)過(guò)程比較復(fù)雜，涉及到兩個(gè)概念: reflow(回流)和repain(重繪)。DOM節(jié)點(diǎn)中的各個(gè)元素都是以盒模型的形式存在，這些都需要瀏覽器去計(jì)算其位置和大小等，這個(gè)過(guò)程稱為relow;當(dāng)盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來(lái)之后，瀏覽器便開(kāi)始繪制內(nèi)容，這個(gè)過(guò)程稱為repain。頁(yè)面在首次加載時(shí)必然會(huì)經(jīng)歷reflow和repain。reflow和repain過(guò)程是非常消耗性能的，尤其是在移動(dòng)設(shè)備上，它會(huì)破壞用戶體驗(yàn)，有時(shí)會(huì)造成頁(yè)面卡頓。所以我們應(yīng)該盡可能少的減少reflow和repain。

JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運(yùn)行，JS有可能修改DOM結(jié)構(gòu)，意味著JS執(zhí)行完成前，后續(xù)所有資源的下載是沒(méi)有必要的，所以JS是單線程，會(huì)阻塞后續(xù)資源下載

總結(jié)一次完整的HTTP請(qǐng)求過(guò)程：
　　域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請(qǐng)求 --> 服務(wù)器響應(yīng)http請(qǐng)求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶

二、HTTPS

HTTPS（Hypertext Transfer Protocol Secure：超文本傳輸安全協(xié)議）是一種透過(guò)計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議。HTTPS 經(jīng)由 HTTP 進(jìn)行通信，但利用 SSL/TLS 來(lái)加密數(shù)據(jù)包。HTTPS 開(kāi)發(fā)的主要目的，是提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性。
HTTPS 默認(rèn)工作在 TCP 協(xié)議443端口，它的工作流程一般如以下方式：

1. TCP 三次同步握手
2. 客戶端驗(yàn)證服務(wù)器數(shù)字證書(shū)
3. DH 算法協(xié)商對(duì)稱加密算法的密鑰、hash 算法的密鑰
4. SSL 安全加密隧道協(xié)商完成
5. 網(wǎng)頁(yè)以加密的方式傳輸，用協(xié)商的對(duì)稱加密算法和密鑰加密，保證數(shù)據(jù)機(jī)密性；用協(xié)商的hash算法進(jìn)行數(shù)據(jù)完整性保護(hù)，保證數(shù)據(jù)不被篡改。

HTTPS 的工作原理

我們都知道 HTTPS 能夠加密信息，以免敏感信息被第三方獲取，所以很多銀行網(wǎng)站或電子郵箱等等安全級(jí)別較高的服務(wù)都會(huì)采用 HTTPS 協(xié)議。

image.png

1. 客戶端發(fā)起 HTTPS 請(qǐng)求
   用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，然后連接到 server 的 443 端口。

2. 服務(wù)端的配置
   采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書(shū)，可以自己制作，也可以向組織申請(qǐng)，區(qū)別就是自己頒發(fā)的證書(shū)需要客戶端驗(yàn)證通過(guò)，才可以繼續(xù)訪問(wèn)，而使用受信任的公司申請(qǐng)的證書(shū)則不會(huì)彈出提示頁(yè)面(startssl 就是個(gè)不錯(cuò)的選擇，有 1 年的免費(fèi)服務(wù))。
   這套證書(shū)其實(shí)就是一對(duì)公鑰和私鑰，如果對(duì)公鑰和私鑰不太理解，可以想象成一把鑰匙和一個(gè)鎖頭，只是全世界只有你一個(gè)人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個(gè)鎖把重要的東西鎖起來(lái)，然后發(fā)給你，因?yàn)橹挥心阋粋€(gè)人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來(lái)的東西。

3. 傳送證書(shū)
   這個(gè)證書(shū)其實(shí)就是公鑰，只是包含了很多信息，如證書(shū)的頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等。

4. 客戶端解析證書(shū)
   這部分工作是有客戶端的TLS來(lái)完成的，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書(shū)存在問(wèn)題。
   如果證書(shū)沒(méi)有問(wèn)題，那么就生成一個(gè)隨機(jī)值，然后用證書(shū)對(duì)該隨機(jī)值進(jìn)行加密，就好像上面說(shuō)的，把隨機(jī)值用鎖頭鎖起來(lái)，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

5. 傳送加密信息
   這部分傳送的是用證書(shū)加密后的隨機(jī)值，目的就是讓服務(wù)端得到這個(gè)隨機(jī)值，以后客戶端和服務(wù)端的通信就可以通過(guò)這個(gè)隨機(jī)值來(lái)進(jìn)行加密解密了。

6. 服務(wù)端解密信息
   服務(wù)端用私鑰解密后，得到了客戶端傳過(guò)來(lái)的隨機(jī)值(私鑰)，然后把內(nèi)容通過(guò)該值進(jìn)行對(duì)稱加密，所謂對(duì)稱加密就是，將信息和私鑰通過(guò)某種算法混合在一起，這樣除非知道私鑰，不然無(wú)法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個(gè)私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。

7. 傳輸加密后的信息
   這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原。

8. 客戶端解密信息
   客戶端用之前生成的私鑰解密服務(wù)段傳過(guò)來(lái)的信息，于是獲取了解密后的內(nèi)容，整個(gè)過(guò)程第三方即使監(jiān)聽(tīng)到了數(shù)據(jù)，也束手無(wú)策。

三、HTTP 與 HTTPS 區(qū)別

1. HTTP 明文傳輸，數(shù)據(jù)都是未加密的，安全性較差，HTTPS（SSL+HTTP） 數(shù)據(jù)傳輸過(guò)程是加密的，安全性較好。
2. 使用 HTTPS 協(xié)議需要到 CA（Certificate Authority，數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)） 申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。證書(shū)頒發(fā)機(jī)構(gòu)如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
3. HTTP 頁(yè)面響應(yīng)速度比 HTTPS 快，主要是因?yàn)?HTTP 使用 TCP 三次握手建立連接，客戶端和服務(wù)器需要交換 3 個(gè)包，而 HTTPS除了 TCP 的三個(gè)包，還要加上 ssl 握手需要的 9 個(gè)包，所以一共是 12 個(gè)包。
4. http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80，后者是 443。
5. HTTPS 其實(shí)就是建構(gòu)在 SSL/TLS 之上的 HTTP 協(xié)議，所以，要比較 HTTPS 比 HTTP 要更耗費(fèi)服務(wù)器資源。