一敞映、HTTP協(xié)議

1.簡介

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫, 是用于從萬維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議边臼。

HTTP協(xié)議就是服務(wù)器（Server）和客戶端（Client）之間進(jìn)行數(shù)據(jù)交互/傳輸數(shù)據(jù)的一種形式。我們可以將Server 和 Client進(jìn)行擬人化侍咱，該協(xié)議就是 Server 和 Client 這兩伙伴間指定的一種交互溝通方式。

超文本傳輸協(xié)議（英文：Hyper Text Transfer Protocol密幔，HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議胯甩。HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)昧廷。HTTP有很多應(yīng)用，但最著名的是用于web瀏覽器和web服務(wù)器之間的雙工通信****偎箫。

通常木柬，由HTTP客戶端發(fā)起一個(gè)請(qǐng)求，創(chuàng)建一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接淹办。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽客戶端的請(qǐng)求眉枕。一旦收到請(qǐng)求，服務(wù)器會(huì)向客戶端返回一個(gè)狀態(tài)，比如"HTTP/1.1 200 OK"速挑，以及返回的內(nèi)容谤牡，如請(qǐng)求的文件、錯(cuò)誤消息梗摇、或者其它信息。

2.工作原理

HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上想许。瀏覽器作為HTTP客戶端伶授，通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請(qǐng)求。Web服務(wù)器根據(jù)接收到的請(qǐng)求流纹，向客戶端發(fā)送響應(yīng)信息糜烹。遵從相同的協(xié)議，就可以進(jìn)行會(huì)話漱凝，進(jìn)行數(shù)據(jù)交互/通訊疮蹦。

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁面，以及服務(wù)器如何把Web頁面?zhèn)魉徒o客戶端茸炒。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型愕乎。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文壁公，請(qǐng)求報(bào)文包含請(qǐng)求的方法感论、URL、協(xié)議版本紊册、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)比肄。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本囊陡、成功或者錯(cuò)誤代碼芳绩、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)撞反。

3.特點(diǎn)

(1) 基于TCP/IP
　　http協(xié)議是基于TCP/IP協(xié)議之上的應(yīng)用層協(xié)議妥色。

(2) 基于請(qǐng)求－響應(yīng)模式
　　HTTP協(xié)議規(guī)定,請(qǐng)求從客戶端發(fā)出,最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。換句話說,肯定是先從客戶端開始建立通信的,服務(wù)器端在沒有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)遏片。

(3) 無狀態(tài)保存
　　HTTP是一種不保存狀態(tài),即無狀態(tài)(stateless)協(xié)議垛膝。HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說在HTTP這個(gè)級(jí)別,協(xié)議對(duì)于發(fā)送過的請(qǐng)求或響應(yīng)都不做持久化處理丁稀。

（4）無連接
　　無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求吼拥。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后线衫，即斷開連接凿可。采用這種方式可以節(jié)省傳輸時(shí)間。

4.HTTP 請(qǐng)求/響應(yīng)的步驟：

（1）客戶端連接到Web服務(wù)器
一個(gè)HTTP客戶端，通常是瀏覽器枯跑，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接惨驶。例如，http://www.luffycity.com敛助。

（2）發(fā)送HTTP請(qǐng)求
通過TCP套接字粗卜，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行纳击、請(qǐng)求頭部续扔、空行和請(qǐng)求數(shù)據(jù)4部分組成。

（3）服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)
Web服務(wù)器解析請(qǐng)求焕数，定位請(qǐng)求資源纱昧。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取堡赔。一個(gè)響應(yīng)由狀態(tài)行识脆、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成善已。

（4）釋放連接TCP連接
若connection 模式為close灼捂，則服務(wù)器主動(dòng)關(guān)閉TCP連接，客戶端被動(dòng)關(guān)閉連接换团，釋放TCP連接;若connection 模式為keepalive纵东，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;

（5）客戶端瀏覽器解析HTML內(nèi)容
客戶端瀏覽器首先解析狀態(tài)行啥寇，查看表明請(qǐng)求是否成功的狀態(tài)代碼偎球。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集辑甜∷バ酰客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語法對(duì)其進(jìn)行格式化磷醋，并在瀏覽器窗口中顯示猫牡。

在瀏覽器地址欄鍵入U(xiǎn)RL，按下回車之后會(huì)經(jīng)歷以下流程：

• 瀏覽器向 DNS 服務(wù)器請(qǐng)求解析該 URL 中的域名所對(duì)應(yīng)的 IP 地址;
• 解析出 IP 地址后邓线，根據(jù)該 IP 地址和默認(rèn)端口 80淌友，和服務(wù)器建立TCP連接;
• 瀏覽器發(fā)出讀取文件(URL中域名后面部分對(duì)應(yīng)的文件)的HTTP 請(qǐng)求，該請(qǐng)求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器;
• 服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)骇陈，并把對(duì)應(yīng)的 html 文本發(fā)送給瀏覽器;
• 釋放 TCP連接;
• 瀏覽器將該 html 文本并顯示內(nèi)容;

5.HTTP之URL

HTTP使用統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers, URI）來傳輸數(shù)據(jù)和建立連接震庭。URL是一種特殊類型的URI，包含了用于查找某個(gè)資源的足夠的信息你雌。URL,全稱是Uniform Resource Locator,中文叫統(tǒng)一資源定位符, 是互聯(lián)網(wǎng)上用來標(biāo)識(shí)某一處資源的地址器联。

超文本傳輸協(xié)議（HTTP）的統(tǒng)一資源定位符將從因特網(wǎng)獲取信息的五個(gè)基本元素包括在一個(gè)簡單的地址中：

• 傳送協(xié)議二汛。
• 層級(jí)URL標(biāo)記符號(hào)(為[//],固定不變)
• 訪問資源需要的憑證信息（可省略）
• 服務(wù)器。（通常為域名拨拓，有時(shí)為IP地址）
• 端口號(hào)肴颊。（以數(shù)字方式表示，若為HTTP的默認(rèn)值“:80”可省略）
• 路徑渣磷。（以“/”字符區(qū)別路徑中的每一個(gè)目錄名稱）
• 查詢婿着。（GET模式的窗體參數(shù)，以“?”字符為起點(diǎn)醋界，每個(gè)參數(shù)以“&”隔開竟宋，再以“=”分開參數(shù)名稱與數(shù)據(jù)，通常以UTF8的URL編碼物独，避開字符沖突的問題）
• 片段袜硫。以“#”字符為起點(diǎn)氯葬。錨點(diǎn)

以 http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name 為例挡篓，介紹下普通URL的各部分組成
　　-協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁使用的是HTTP協(xié)議帚称。在Internet中可以使用多種協(xié)議官研，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議闯睹。在"HTTP"后面的“//”為分隔符
　　- 域名部分：該URL的域名部分為“www.aspxfans.com”戏羽。一個(gè)URL中亿昏，也可以使用IP地址作為域名使用夺艰；
　　- 端口部分：跟在域名后面的是端口蝇摸，域名和端口之間使用“:”作為分隔符字管。端口不是一個(gè)URL必須的部分辫愉，如果省略端口部分高职，將采用默認(rèn)端口或粮；
　　- 虛擬目錄部分：從域名后的第一個(gè)“/”開始到最后一個(gè)“/”為止器虾，是虛擬目錄部分躬窜。虛擬目錄也不是一個(gè)URL必須的部分浇垦。本例中的虛擬目錄是“/news/”
　　- 文件名部分：從域名后的最后一個(gè)“/”開始到“？”為止荣挨，是文件名部分男韧，如果沒有“?”, 則是從域名后的最后一個(gè)“/”開始到“#”為止，是文件部分默垄，如果沒有“此虑？”和“#”，那么從域名后的最后一個(gè)“/”開始到結(jié)束口锭，都是文件名部分寡壮。本例中的文件名是“index.asp”。文件名部分也不是一個(gè)URL必須的部分，如果省略該部分况既，則使用默認(rèn)的文件名这溅；
　　- 錨部分：從“#”開始到最后，都是錨部分棒仍。本例中的錨部分是“name”悲靴。錨部分也不是一個(gè)URL必須的部分；
　　- 參數(shù)部分：從“莫其？”開始到“#”為止之間的部分為參數(shù)部分癞尚，又稱搜索部分、查詢部分乱陡。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”浇揩。參數(shù)可以允許有多個(gè)參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符憨颠。

6.HTTP請(qǐng)求方法

HTTP/1.1協(xié)議中共定義了八種方法（也叫“動(dòng)作”）來以不同方式操作指定的資源：

GET
　　向指定的資源發(fā)出“顯示”請(qǐng)求胳徽。使用GET方法應(yīng)該只用在讀取數(shù)據(jù)，而不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中爽彤，例如在Web Application中养盗。其中一個(gè)原因是GET可能會(huì)被網(wǎng)絡(luò)蜘蛛等隨意訪問。

HEAD
　　與GET方法一樣适篙，都是向服務(wù)器發(fā)出指定資源的請(qǐng)求往核。只不過服務(wù)器將不傳回資源的本文部分。它的好處在于嚷节，使用這個(gè)方法可以在不必傳輸全部內(nèi)容的情況下聂儒，就可以獲取其中“關(guān)于該資源的信息”（元信息或稱元數(shù)據(jù)）。

POST
　　向指定資源提交數(shù)據(jù)硫痰，請(qǐng)求服務(wù)器進(jìn)行處理（例如提交表單或者上傳文件）衩婚。數(shù)據(jù)被包含在請(qǐng)求本文中。這個(gè)請(qǐng)求可能會(huì)創(chuàng)建新的資源或修改現(xiàn)有資源碍论，或二者皆有谅猾。

PUT
　　向指定資源位置上傳其最新內(nèi)容。

DELETE
　　請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源鳍悠。

TRACE
　　回顯服務(wù)器收到的請(qǐng)求税娜，主要用于測(cè)試或診斷。

OPTIONS
　　這個(gè)方法可使服務(wù)器傳回該資源所支持的所有HTTP請(qǐng)求方法藏研。用'*'來代替資源名稱敬矩，向Web服務(wù)器發(fā)送OPTIONS請(qǐng)求，可以測(cè)試服務(wù)器功能是否正常運(yùn)作蠢挡。

CONNECT
　　HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器弧岳。通常用于SSL加密服務(wù)器的鏈接（經(jīng)由非加密的HTTP代理服務(wù)器）凳忙。

注意事項(xiàng)：

• 方法名稱是區(qū)分大小寫的。當(dāng)某個(gè)請(qǐng)求所針對(duì)的資源不支持對(duì)應(yīng)的請(qǐng)求方法的時(shí)候禽炬，服務(wù)器應(yīng)當(dāng)返回狀態(tài)碼405（Method Not Allowed）涧卵，當(dāng)服務(wù)器不認(rèn)識(shí)或者不支持對(duì)應(yīng)的請(qǐng)求方法的時(shí)候，應(yīng)當(dāng)返回狀態(tài)碼501（Not Implemented）腹尖。
• HTTP服務(wù)器至少應(yīng)該實(shí)現(xiàn)GET和HEAD方法柳恐，其他方法都是可選的。當(dāng)然热幔，所有的方法支持的實(shí)現(xiàn)都應(yīng)當(dāng)匹配下述的方法各自的語義定義乐设。此外，除了上述方法绎巨，特定的HTTP服務(wù)器還能夠擴(kuò)展自定義的方法近尚。例如PATCH（由 RFC 5789 指定的方法）用于將局部修改應(yīng)用到資源。

http請(qǐng)求協(xié)議與響應(yīng)協(xié)議
　　http協(xié)議包含由瀏覽器發(fā)送數(shù)據(jù)到服務(wù)器需要遵循的請(qǐng)求協(xié)議與服務(wù)器發(fā)送數(shù)據(jù)到瀏覽器需要遵循的請(qǐng)求協(xié)議场勤。用于HTTP協(xié)議交互的信被為HTTP報(bào)文戈锻。請(qǐng)求端(客戶端)的HTTP報(bào)文做請(qǐng)求報(bào)文,響應(yīng)端(服務(wù)器端)的做響應(yīng)報(bào)文。HTTP報(bào)文本身是由多行數(shù)據(jù)構(gòu)成的字文本却嗡。

請(qǐng)求頭是key value形式舶沛，請(qǐng)求頭和請(qǐng)求數(shù)據(jù)之間有2個(gè)\r\n是為了做區(qū)分

get請(qǐng)求是沒有請(qǐng)求數(shù)據(jù)的,post請(qǐng)求才有

請(qǐng)求方式: get與post請(qǐng)求比較

• GET提交的數(shù)據(jù)會(huì)放在URL之后嘹承，以?分割URL和傳輸數(shù)據(jù)窗价，參數(shù)之間以&相連，如EditBook?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的請(qǐng)求體中.

• GET提交的數(shù)據(jù)大小有限制（因?yàn)闉g覽器對(duì)URL的長度有限制）叹卷，而POST方法提交的數(shù)據(jù)沒有限制.

• GET與POST請(qǐng)求在服務(wù)端獲取請(qǐng)求數(shù)據(jù)方式不同撼港。

一般情況下，瀏覽器為我們自動(dòng)生成請(qǐng)求行和請(qǐng)求頭部, 響應(yīng)數(shù)據(jù)在response里面骤竹，瀏覽器會(huì)自動(dòng)解釋響應(yīng)

6.HTTP之Request：

客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下組成部分：

image

報(bào)文頭：存儲(chǔ)的是****該請(qǐng)求的一些主要說明帝牡，服務(wù)器據(jù)此獲取客戶端的信息。
　　　　　常見的請(qǐng)求頭：
　　　　　　　　accept:瀏覽器通過這個(gè)頭告訴服務(wù)器蒙揣，它所支持的數(shù)據(jù)類型
　　　　　　　　Accept-Charset: 瀏覽器通過這個(gè)頭告訴服務(wù)器靶溜，它支持哪種字符集
　　　　　　　　Accept-Encoding：瀏覽器通過這個(gè)頭告訴服務(wù)器，支持的壓縮格式
　　　　　　　　Accept-Language：瀏覽器通過這個(gè)頭告訴服務(wù)器懒震，它的語言環(huán)境
　　　　　　　　Host：瀏覽器通過這個(gè)頭告訴服務(wù)器罩息，想訪問哪臺(tái)主機(jī)
　　　　　　　　If-Modified-Since: 瀏覽器通過這個(gè)頭告訴服務(wù)器，緩存數(shù)據(jù)的時(shí)間
　　　　　　　　Referer：瀏覽器通過這個(gè)頭告訴服務(wù)器个扰，客戶機(jī)是哪個(gè)頁面來的 防盜鏈
　　　　　　　　Connection：瀏覽器通過這個(gè)頭告訴服務(wù)器瓷炮，請(qǐng)求完后是斷開鏈接還是何持鏈接
　　　　　　　　X-Requested-With: XMLHttpRequest 代表通過ajax方式進(jìn)行訪問
　　　　　　　　User-Agent：請(qǐng)求載體的身份標(biāo)識(shí)

報(bào)文體：常被叫做請(qǐng)求體，****請(qǐng)求體中存儲(chǔ)的是將要傳輸/發(fā)送給服務(wù)器的數(shù)據(jù)信息递宅。

7.HTTP之Response：

服務(wù)器回傳一個(gè)HTTP響應(yīng)到客戶端的響應(yīng)消息包括以下組成部分：

　　　　　3xx 重定向到其它地方。它讓客戶端再發(fā)起一個(gè)請(qǐng)求以完成整個(gè)處理糯笙；
　　　　　4xx 處理發(fā)生錯(cuò)誤贬丛，責(zé)任在客戶端，如客戶端請(qǐng)求一個(gè)不存在的資源给涕，客戶端未被授權(quán)等豺憔；
　　　　　5xx 處理發(fā)生錯(cuò)誤，責(zé)任在服務(wù)端够庙，如服務(wù)端拋出異常恭应，路由出錯(cuò)，HTTP版本不支持等耘眨。

　　響應(yīng)頭：響應(yīng)的詳情展示昼榛。常見的相應(yīng)頭信息：
　　　　Location: 服務(wù)器通過這個(gè)頭，來告訴瀏覽器跳到哪里
　　　　Server：服務(wù)器通過這個(gè)頭剔难，告訴瀏覽器服務(wù)器的型號(hào)
　　　　Content-Encoding：服務(wù)器通過這個(gè)頭胆屿，告訴瀏覽器，數(shù)據(jù)的壓縮格式
　　　　Content-Length: 服務(wù)器通過這個(gè)頭偶宫，告訴瀏覽器回送數(shù)據(jù)的長度
　　　　Content-Language: 服務(wù)器通過這個(gè)頭非迹，告訴瀏覽器語言環(huán)境
　　　　Content-Type：服務(wù)器通過這個(gè)頭，告訴瀏覽器回送數(shù)據(jù)的類型
　　　　Refresh：服務(wù)器通過這個(gè)頭纯趋，告訴瀏覽器定時(shí)刷新
　　　　Content-Disposition: 服務(wù)器通過這個(gè)頭憎兽，告訴瀏覽器以下載方式打數(shù)據(jù)
　　　　Transfer-Encoding：服務(wù)器通過這個(gè)頭，告訴瀏覽器數(shù)據(jù)是以分塊方式回送的
　　　　Expires: -1 控制瀏覽器不要緩存
　　　　Cache-Control: no-cache
　　　　Pragma: no-cache

　　響應(yīng)體：根據(jù)客戶端指定的請(qǐng)求信息吵冒，發(fā)送給客戶端的指定數(shù)據(jù)

二纯命、HTTPS協(xié)議

HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協(xié)議，HTTPS是在HTTP上建立SSL加密層桦锄，并對(duì)傳輸數(shù)據(jù)進(jìn)行加密扎附，是HTTP協(xié)議的安全版。****加密安全版的HTTP協(xié)議结耀。

HTTPS的工作原理

我們都知道了HTTPS能夠加密信息留夜，以免敏感信息被第三方獲取匙铡，所以很多銀行網(wǎng)站或電子郵箱等安全級(jí)別較高的服務(wù)都會(huì)采用HTTPS協(xié)議
客戶端在使用HTTPS方式與WEB服務(wù)器通信時(shí)有以下幾個(gè)步驟:

• 1. 客戶使用https的URL訪問web服務(wù)器，要求與web服務(wù)器建立SSL連接
• 2. web服務(wù)器收到客戶端請(qǐng)求后碍粥，會(huì)將網(wǎng)站的證書信息（證書中包含公鑰）傳送一份給客戶端
• 3. 客戶端的瀏覽器與WEB服務(wù)器開始協(xié)商SSL連接的安全等級(jí)鳖眼，也就是信息加密的等級(jí)
• 4. 客戶端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話秘鑰嚼摩，然后利用網(wǎng)站的公鑰將會(huì)話秘鑰加密钦讳，并傳送給網(wǎng)站
• 5. web服務(wù)器利用自己的私鑰解密出會(huì)話秘鑰
• 6. web服務(wù)器利用會(huì)話秘鑰加密與客戶端之間的通信

HTTPS的優(yōu)點(diǎn)

盡管HTTPS并非絕對(duì)安全，掌管根證書的機(jī)構(gòu)枕面、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊愿卒，但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下好處：

• 1. 使用HTTPS協(xié)議可認(rèn)證用戶和服務(wù)器潮秘，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器琼开；
• 2. HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議枕荞，要比http協(xié)議安全柜候，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變躏精，確保數(shù)據(jù)的完整性渣刷。
• 3. HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全矗烛，但它大幅增加了中間人攻擊的成本辅柴。
• 4. 谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站高诺，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會(huì)更高”

HTTPS的缺點(diǎn)

雖然說HTTPS有很大的優(yōu)勢(shì)碌识，但其相對(duì)來說碾篡，還是存在不足之處的：

• 1. HTTPS協(xié)議握手階段比較費(fèi)時(shí)虱而，會(huì)使頁面的加載時(shí)間延長近50%，增加10%到20%的耗電开泽；
• 2. HTTPS連接緩存不如HTTP高效牡拇，會(huì)增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會(huì)因此而受到影響穆律；
• 3. SSL證書需要錢惠呼，功能越強(qiáng)大的證書費(fèi)用越高，個(gè)人網(wǎng)站峦耘、小網(wǎng)站沒有必要一般不會(huì)用剔蹋。
• 4. SSL證書通常需要綁定IP，不能在同一IP上綁定多個(gè)域名辅髓，IPv4資源不可能支撐這個(gè)消耗泣崩。
• 5. HTTPS協(xié)議的加密范圍也比較有限少梁，在黑客攻擊、拒絕服務(wù)攻擊矫付、服務(wù)器劫持等方面幾乎起不到什么作用凯沪。最關(guān)鍵的，SSL證書的信用鏈體系并不安全买优，特別是在某些國家可以控制CA根證書的情況下妨马，中間人攻擊一樣可行。

HTTPS采用的加密技術(shù)

• SSL加密技術(shù) （密文和秘鑰一起傳送）

SSL采用的加密技術(shù)叫做“共享密鑰加密”杀赢，也叫作“對(duì)稱密鑰加密”烘跺，這種加密方法是這樣的，比如客戶端向服務(wù)器發(fā)送一條信息脂崔，首先客戶端會(huì)采用已知的算法對(duì)信息進(jìn)行加密液荸，比如MD5或者Base64加密，接收端對(duì)加密的信息進(jìn)行解密的時(shí)候需要用到密鑰脱篙，中間會(huì)傳遞密鑰娇钱，（加密和解密的密鑰是同一個(gè)），密鑰在傳輸中間是被加密的绊困。這種方式看起來安全文搂，但是仍有潛在的危險(xiǎn)，一旦被竊聽秤朗，或者信息被挾持煤蹭，就有可能破解密鑰，而破解其中的信息取视。因此“共享密鑰加密”這種方式存在安全隱患：

image

image

• 非對(duì)稱秘鑰加密技術(shù)（服務(wù)器制定加密規(guī)則硝皂，客戶端傳送密文，服務(wù)端解密）

“非對(duì)稱加密”使用的時(shí)候有兩把鎖作谭，一把叫做“私有密鑰”稽物，一把是“公開密鑰”，使用非對(duì)象加密的加密方式的時(shí)候折欠，服務(wù)器首先告訴客戶端按照自己給定的公開密鑰進(jìn)行加密處理贝或，客戶端按照公開密鑰加密以后，服務(wù)器接受到信息再通過自己的私有密鑰進(jìn)行解密锐秦，這樣做的好處就是解密的鑰匙根本就不會(huì)進(jìn)行傳輸咪奖，因此也就避免了被挾持的風(fēng)險(xiǎn)。就算公開密鑰被竊聽者拿到了酱床，它也很難進(jìn)行解密羊赵，因?yàn)榻饷苓^程是對(duì)離散對(duì)數(shù)求值，這可不是輕而易舉就能做到的事扇谣。

image

但是非對(duì)稱秘鑰加密技術(shù)也存在如下缺點(diǎn)：

1）如何保證接收端向發(fā)送端發(fā)出公開秘鑰的時(shí)候昧捷，發(fā)送端確保收到的是預(yù)先要發(fā)送的揖闸，而不會(huì)被挾持。只要是發(fā)送密鑰料身，就有可能有被挾持的風(fēng)險(xiǎn)汤纸。

2）非對(duì)稱加密的方式效率比較低，它處理起來更為復(fù)雜芹血，通信過程中使用就有一定的效率問題而影響通信速度

• https的證書機(jī)制（防偽標(biāo)識(shí)贮泞，確認(rèn)是服務(wù)端制定的加密規(guī)則）

在上面我們講了非對(duì)稱加密的缺點(diǎn)，其中第一個(gè)就是公鑰很可能存在被挾持的情況幔烛，無法保證客戶端收到的公開密鑰就是服務(wù)器發(fā)行的公開密鑰啃擦。此時(shí)就引出了公開密鑰證書機(jī)制。數(shù)字證書認(rèn)證機(jī)構(gòu)是客戶端與服務(wù)器都可信賴的第三方機(jī)構(gòu)饿悬。證書的具體傳播過程如下：

1）服務(wù)器的開發(fā)者攜帶公開密鑰令蛉，向數(shù)字證書認(rèn)證機(jī)構(gòu)提出公開密鑰的申請(qǐng)，數(shù)字證書認(rèn)證機(jī)構(gòu)在認(rèn)清申請(qǐng)者的身份狡恬，審核通過以后珠叔，會(huì)對(duì)開發(fā)者申請(qǐng)的公開密鑰做數(shù)字簽名（防偽標(biāo)識(shí)），然后分配這個(gè)已簽名的公開密鑰弟劲，并將密鑰放在證書里面祷安，綁定在一起

2）服務(wù)器將這份數(shù)字證書發(fā)送給客戶端，因?yàn)榭蛻舳艘舱J(rèn)可證書機(jī)構(gòu)兔乞，客戶端可以通過數(shù)字證書中的數(shù)字簽名來驗(yàn)證公鑰的真?zhèn)位惚蓿瑏泶_保服務(wù)器傳過來的公開密鑰是真實(shí)的。一般情況下庸追，證書的數(shù)字簽名是很難被偽造的霍骄，這取決于認(rèn)證機(jī)構(gòu)的公信力。一旦確認(rèn)信息無誤之后淡溯，客戶端就會(huì)通過公鑰對(duì)報(bào)文進(jìn)行加密發(fā)送读整，服務(wù)器接收到以后用自己的私鑰進(jìn)行解密。

備注：本文參考：https://www.cnblogs.com/bobo-zhang/p/9645715.html