柚子快報激活碼778899分享：網(wǎng)絡(luò)協(xié)議 HTTP和HTTPS

http://yzkb.51969.com/

目錄

HTTP和HTTPS的基本概念(應(yīng)用層協(xié)議）

HTTP的版本

HTTP狀態(tài)碼

HTTP請求報文

GET和POST請求

GET和POST請求的區(qū)別

條件GET方法

HTTP與HTTPS有什么區(qū)別？

HTTP的工作原理

HTTP的長鏈接?

http1.1長鏈接判斷一個請求已經(jīng)結(jié)束了

HTTP管線化

HTTPS的工作原理

HTTPS的優(yōu)點

HTTPS的缺點：

HTTPS的優(yōu)缺點（總結(jié)）

對稱加密

非對稱加密

證書

HTTPS的加密

HTTP和HTTPS的基本概念(應(yīng)用層協(xié)議）

HTTP（HyperText Transfer Protocol：超文本傳輸協(xié)議）：是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，是一個客戶端和服務(wù)器端請求和應(yīng)答的標(biāo)準(zhǔn)（TCP），用于從Web服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。

HTTPS（HyperText Transfer Protocol Secure：超文本傳輸安全協(xié)議）：是以安全為目標(biāo)的HTTP通道，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL。HTTPS 開發(fā)的主要目的，是提供對網(wǎng)站服務(wù)器的身份認證，保護交換數(shù)據(jù)的隱私與完整性。

HTTP的版本

HTTP協(xié)議主要有1.0,1.1,2.0三個版本:

HTTP/1.0:

0.9版本,第一次定義HTTP基本功能。1.0版本,增加內(nèi)容類型信息。定義了GET、POST、HEAD等方法。

HTTP/1.1：

增加Host請求頭,支持同時連接多個主機。新增緩存處理機制。增加Range請求頭,支持斷點續(xù)傳。增加PUT和DELETE方法。增加流水線的概念,支持在同一個TCP連接上發(fā)起多個請求。

HTTP/1的長連接：

? ? ? ? HTTP長連接（long connection）與短連接（short connection）本質(zhì)上是TCP長連接和短連接：短連接是指在一次HTTP請求和響應(yīng)之后立即關(guān)閉本次TCP連接，下次請求響應(yīng)重建一個新的TCP連接；而長連接是指請求響應(yīng)之后并不立即關(guān)閉本次TCP連接，下次請求響應(yīng)繼續(xù)重用該TCP連接。HTTP/1.0默認短連接，HTTP/1.1起默認長連接，長連接通過請求頭Connection: keep-alive啟用長連接、通過Keep-Alive: timeout=20設(shè)置長連接的超時時間（秒）。

HTTP/1的長輪詢：?

而HTTP長輪詢（long polling）是指服務(wù)端收到請求后若有數(shù)據(jù)立即返回，若無數(shù)據(jù)則保持到有數(shù)據(jù)或一段時間后超時，瀏覽器收到響應(yīng)后立即重新發(fā)送相同的請求；HTTP短輪詢（short polling）是指服務(wù)端收到請求后無論是否有數(shù)據(jù)都立即返回，瀏覽器收到響應(yīng)后間隔一段時間后重新發(fā)送相同的請求。輪詢建立在連接基礎(chǔ)上，輪詢是長是短與連接是長是短無關(guān)。

?HTTP長輪詢主要用于實現(xiàn)需要實時獲取數(shù)據(jù)的地方，例如：即時消息、實時股票價格等，其主要技術(shù)要點在于服務(wù)端無數(shù)據(jù)時如何保持到有數(shù)據(jù)或超時。另外在請求發(fā)生頻率上，長輪詢也可以在入短連接一樣收到響應(yīng)后間隔一段時間后才發(fā)送，只是會不夠?qū)崟r；短輪詢也可以如長連接一樣在收到響應(yīng)后立即發(fā)送，只是會給服務(wù)器端造成過大壓力。

HTTP/2.0:

二進制協(xié)議,更高效。全雙工:客戶端和服務(wù)器之間可以同時發(fā)送數(shù)據(jù)。數(shù)據(jù)流:可以在一個連接中交替使用多個流進行數(shù)據(jù)傳輸。首部壓縮:發(fā)送相同的首部只發(fā)送一次。服務(wù)端推送:服務(wù)器可以在客戶端請求時主動推送數(shù)據(jù)。

HTTP/2的隊頭阻塞：

HTTP1.1中引入了長連接，允許多個連接復(fù)用一個TCP連接。

當(dāng)多個請求先后調(diào)用HTTP發(fā)送的時候，如果前一個請求不響應(yīng)的話，后一個請求是不會發(fā)送的。 所以如果前一個響應(yīng)阻塞的話，后邊的請求也會被迫阻塞，叫做隊頭阻塞。

HTTP2.0時，引入了幀、流的概念。

HTTP2是基于TCP的。HTTP2允許多個請求不按照先后順序發(fā)送數(shù)據(jù)，并允許穿插的發(fā)送數(shù)據(jù)，也就是每次發(fā)送一個幀。

那么怎么區(qū)分幀屬于哪個HTTP請求呢？

會對每個HTTP請求進行編號，然后再幀中插入對應(yīng)的HTTP編號和其在HTTP請求中的位置序號，然后發(fā)送到服務(wù)器，服務(wù)器根據(jù)HTTP編號和位置序號來將幀重組，然后同時亂序的發(fā)送應(yīng)答，客戶端也通過HTTP編號和位置序號來重組幀。

這樣就避免了HTTP層面的隊頭阻塞。

但是仍無法解決TCP的隊頭阻塞。

TCP由于引入了滑動窗口，并且每次可以發(fā)送多個數(shù)據(jù)，并且可以亂序接受。當(dāng)序號大的數(shù)據(jù)先到達后，仍然不能被應(yīng)用程序讀取，需要等到序號靠前的數(shù)據(jù)到了之后，才能被應(yīng)用程序讀取，這也出現(xiàn)了隊頭阻塞。

這個隊頭阻塞是TCP實現(xiàn)可靠傳輸?shù)母弊饔?，無法解決。

HTTP/3.0:

實現(xiàn)了類似TCP的流量控制，傳輸可靠性的功能。實現(xiàn)了快速握手功能（QUIC基于UDP，UDP是面向無連接的，不需要握手和揮手，比TCP快集成了TLS加密功能多路復(fù)用，徹底解決TCP中隊頭阻塞的問題（單個“流”是有序的，可能會因為丟包而阻塞，但是其他流不會受到影響）

總結(jié)

HTTP1.1的缺點：安全性不足和性能不高；HTTP2.0完全兼容HTTTP1.0，是“更安全的HTTP，更快的HTTPS”，頭部壓縮，多路復(fù)用等技術(shù)充分利用了帶寬，降低了延遲。HTTP3.0的底層支撐協(xié)議QUIC基于UDP實現(xiàn)，又含TCP的特點，實現(xiàn)了又快又可靠的協(xié)議。 ?

HTTP狀態(tài)碼

HTTP狀態(tài)碼的職責(zé)：

當(dāng)客戶端向服務(wù)器端發(fā)送HTTP請求后，用于描述服務(wù)器端返回的請求結(jié)果。

HTTP狀態(tài)碼的分類：

（1）1xx 信息性狀態(tài)碼

（2）2xx 成功狀態(tài)碼

（3）3xx?重定向狀態(tài)碼

（4）4xx 客戶端錯誤狀態(tài)碼

（5）5xx 服務(wù)器端錯誤狀態(tài)碼

常用的狀態(tài)碼：

2打頭：

（請求成功）表示成功處理了請求的狀態(tài)代碼。 200 （成功） 服務(wù)器已成功處理了請求。 通常，這表示服務(wù)器提供了請求的網(wǎng)頁。 201 （已創(chuàng)建） 請求成功并且服務(wù)器創(chuàng)建了新的資源。 202 （已接受） 服務(wù)器已接受請求，但尚未處理。 203 （非授權(quán)信息） 服務(wù)器已成功處理了請求，但返回的信息可能來自另一來源。 204 （無內(nèi)容） 服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。 205 （重置內(nèi)容） 服務(wù)器成功處理了請求，但沒有返回任何內(nèi)容。 206 （部分內(nèi)容） 服務(wù)器成功處理了部分 GET 請求。

3打頭：

（請求被重定向）表示要完成請求，需要進一步操作。 通常，這些狀態(tài)代碼用來重定向。 300 （多種選擇） 針對請求，服務(wù)器可執(zhí)行多種操作。 服務(wù)器可根據(jù)請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。 301 （永久移動） 請求的網(wǎng)頁已永久移動到新位置。 服務(wù)器返回此響應(yīng)（對 GET 或 HEAD 請求的響應(yīng)）時，會自動將請求者轉(zhuǎn)到新位置。 302 （臨時移動） 服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進行以后的請求。 303 （查看其他位置） 請求者應(yīng)當(dāng)對不同的位置使用單獨的 GET 請求來檢索響應(yīng)時，服務(wù)器返回此代碼。 304 （未修改） 自從上次請求后，請求的網(wǎng)頁未修改過。 服務(wù)器返回此響應(yīng)時，不會返回網(wǎng)頁內(nèi)容。 305 （使用代理） 請求者只能使用代理訪問請求的網(wǎng)頁。 如果服務(wù)器返回此響應(yīng)，還表示請求者應(yīng)使用代理。 307 （臨時重定向） 服務(wù)器目前從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進行以后的請求。

4打頭： （請求錯誤）這些狀態(tài)代碼表示請求可能出錯，妨礙了服務(wù)器的處理。 400 （錯誤請求） 服務(wù)器不理解請求的語法。 401 （未授權(quán)） 請求要求身份驗證。 對于需要登錄的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)。 403 （禁止） 服務(wù)器拒絕請求。404 （未找到） 服務(wù)器找不到請求的網(wǎng)頁。405 （方法禁用） 禁用請求中指定的方法。 406 （不接受） 無法使用請求的內(nèi)容特性響應(yīng)請求的網(wǎng)頁。 407 （需要代理授權(quán)） 此狀態(tài)代碼與 401（未授權(quán)）類似，但指定請求者應(yīng)當(dāng)授權(quán)使用代理。 408 （請求超時） 服務(wù)器等候請求時發(fā)生超時。 409 （沖突） 服務(wù)器在完成請求時發(fā)生沖突。 服務(wù)器必須在響應(yīng)中包含有關(guān)沖突的信息。 410 （已刪除） 如果請求的資源已永久刪除，服務(wù)器就會返回此響應(yīng)。 411 （需要有效長度） 服務(wù)器不接受不含有效內(nèi)容長度標(biāo)頭字段的請求。 412 （未滿足前提條件） 服務(wù)器未滿足請求者在請求中設(shè)置的其中一個前提條件。 413 （請求實體過大） 服務(wù)器無法處理請求，因為請求實體過大，超出服務(wù)器的處理能力。 414 （請求的 URI 過長） 請求的 URI（通常為網(wǎng)址）過長，服務(wù)器無法處理。 415 （不支持的媒體類型） 請求的格式不受請求頁面的支持。 416 （請求范圍不符合要求） 如果頁面無法提供請求的范圍，則服務(wù)器會返回此狀態(tài)代碼。 417 （未滿足期望值） 服務(wù)器未滿足"期望"請求標(biāo)頭字段的要求。

5打頭： （服務(wù)器錯誤）這些狀態(tài)代碼表示服務(wù)器在嘗試處理請求時發(fā)生內(nèi)部錯誤。 這些錯誤可能是服務(wù)器本身的錯誤，而不是請求出錯。 500 （服務(wù)器內(nèi)部錯誤） 服務(wù)器遇到錯誤，無法完成請求。501 （尚未實施） 服務(wù)器不具備完成請求的功能。 例如，服務(wù)器無法識別請求方法時可能會返回此代碼。 502 （錯誤網(wǎng)關(guān)） 服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。 503 （服務(wù)不可用） 服務(wù)器目前無法使用（由于超載或停機維護）。 通常，這只是暫時狀態(tài)。504 （網(wǎng)關(guān)超時） 服務(wù)器作為網(wǎng)關(guān)或代理，但是沒有及時從上游服務(wù)器收到請求。 505 （HTTP 版本不受支持） 服務(wù)器不支持請求中所用的 HTTP 協(xié)議版本。

HTTP請求報文

?http請求報文由三部分組成： 請求行、請求頭 、請求正文。請求行、每個請求頭與請求正文都由CRLF（回車換行，也即\r\n）分割開來，首行為請求行，余下的為請求頭和請求正文，而請求正文有可能會為空，也可能包含CRLF情況，因此不能通過一個CRLF與請求頭區(qū)別開來，所以采用兩個CRLF來間隔請求頭和請求正文1.請求行

請求行的格式為：Method Request-URI HTTP-version CRLF

method為大寫，有以下幾種：GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE、CONNECT。但是實際使用中一般使用GET和POST就可以任何需求了，其他的被設(shè)計出來主要是讓人從語義來直觀看出該怎么處理數(shù)據(jù)，但是即使使用了DELETE方法，具體的刪除還是得我們自己來實現(xiàn)。

Request-URI是一個統(tǒng)一資源標(biāo)識符

HTTP-version為請求的HTTP的協(xié)議版本

GET請求示例GET /form.html HTTP/1.1 (CRLF)

POST請求示例POST /reg.jsp HTTP/1.1 (CRLF) Accept:image/gif,image/x-xbit,... (CRLF)

2.請求頭

請求頭的格式為鍵值對。一般常見的請求頭如下：

User-Agent:PostmanRuntime/7.26.8 ? ? 表示產(chǎn)生請求的客戶端程序

Accept:*/* ? ? 表示可接受的響應(yīng)的類型為全部類型

Accept-Language:zh ? ? 表示可接受的響應(yīng)的語言為中文

Accept-Encoding:gzip ? ? 表示客戶端請求的壓縮方式

Cookie:value ? ? 值由登陸之后服務(wù)端下發(fā)

token:value ? ? 值由登陸之后服務(wù)端下發(fā)

3.請求正文 ?

?

HTTP的相應(yīng)也是由三部分組成：狀態(tài)行、響應(yīng)頭、響應(yīng)正文

狀態(tài)行的組成為HTTP-version Status-code Reason-phrase CRLF

HTTP-version 為HTTP的版本，Status-code為響應(yīng)狀態(tài)碼，Reason-phrase表示狀態(tài)碼的文本描述

狀態(tài)碼由三個數(shù)字組成，第一個數(shù)字表示響應(yīng)類別

GET和POST請求

get 和 post請求是http協(xié)議中的兩種請求方式。get一般用來獲取服務(wù)器的信息的，post一般是用來更新信息。

GET和POST請求的區(qū)別

GET可以存在cache(緩存)中，POST不可以GET請求在url中傳遞的參數(shù)是有長度限制的，POST對長度沒有限制。GET參數(shù)通過URL傳遞，POST放在Requestbody中。GET請求參數(shù)會完整的保留在瀏覽器的歷史記錄中，POST請求的參數(shù)不會保留原則上post肯定要比get安全，畢竟傳輸參數(shù)時url不可見GET產(chǎn)生一個TCP數(shù)據(jù)包，POST產(chǎn)生兩個TCP數(shù)據(jù)包。對于GET請求，瀏覽器會把http header和data一起發(fā)送出去，服務(wù)器響應(yīng)200，請求成功。對于POST請求，瀏覽器先發(fā)送header，服務(wù)器會響應(yīng)100（已經(jīng)收到請求的第一部分，正在等待其余部分），瀏覽器再次發(fā)送data，服務(wù)器返回200，請求成功。并不是所有瀏覽器都會在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次。

條件GET方法

盡管緩存可以減少用戶感知到的響應(yīng)時間，但是緩存引入了一個新的問題。 存儲在cache中的對象可能是陳舊的。換句話說，自從對象的副本被緩存到這個cache,存儲在web服務(wù)器端的對象可能被修改過。

幸運的是，HTTP提供了條件GET(conditional GET)機制，這個機制使得cache能夠確認它的對象是最新的。

什么樣的HTTP請求報文屬于條件請求報文呢？ （1）請求報文使用了GET方法 （2）請求報文包括了一個If-Modified-Since頭行

HTTP與HTTPS有什么區(qū)別？

1、HTTPS協(xié)議需要到CA（Certificate Authority，數(shù)字證書認證機構(gòu)）申請證書，一般免費證書較少，因而需要一定費用。

2、HTTP是超文本傳輸協(xié)議，信息是明文傳輸，數(shù)據(jù)是不加密的，而HTTPS則是具有安全性的SSL加密傳輸協(xié)議。

3、HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，HTTP是80端口，HTTPS是443端口。

4、HTTP的連接很簡單，是無狀態(tài)的，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，比HTTP協(xié)議安全。

HTTP的工作原理

1.客戶端與服務(wù)器建立TCP連接（三次握手） 2.連接成功后，客戶端發(fā)送請求給服務(wù)器 3.服務(wù)器接收到客戶端發(fā)送的請求后作出相應(yīng)，并將響應(yīng)信息發(fā)送給客戶端 4.服務(wù)器發(fā)送完響應(yīng)信息后，就會斷開TCP連接，因此HTTP是無狀態(tài)的，下一次訪問的時候不會知道之前訪問的過程 5.客戶端接收到響應(yīng)信息，瀏覽器進行解析，將html文件解析后呈現(xiàn)一個網(wǎng)頁在瀏覽器上

HTTP的長鏈接?

HTTP協(xié)議的長連接本質(zhì)上就是TCP的長連接。所以HTTP長連接的保持就是tcp的保活機制

http1.1長鏈接判斷一個請求已經(jīng)結(jié)束了

可以理解為判斷是否結(jié)束為判斷是否讀取完整個請求

-> 是否擁有請求體，有點的話 ? -> 判斷請求體大小判斷 ? ? -> 靜態(tài)判斷利用Content-Length ? ? -> 動態(tài)判斷利用Transfer-Encoding為chunked -> 判斷請求是否結(jié)束

判斷傳輸數(shù)據(jù)是否達到了?Content-Length?指示的大小動態(tài)生成的文件沒有Content-Length，它是分塊傳輸（chunked），這時候要根據(jù)chunked?編碼來判斷，chunked?編碼的數(shù)據(jù)在最后有一個空的?chunked?塊，表明本次傳輸數(shù)據(jù)結(jié)束。

HTTP管線化

http的管線化，也叫管道化，英文是HTTP Pipelining。管道化是指：客戶端可以發(fā)送多次請求到服務(wù)端，而不需要等待上一次請求得到響應(yīng)的時候才能進行下一次請求，這樣就可以實現(xiàn)并發(fā)。在等待上一個請求響應(yīng)的同時，發(fā)送下一個請求。HTTP Pipelining其實是把多個HTTP請求放到一個TCP連接中一一發(fā)送，因為http本質(zhì)還是基于tcp的，而在發(fā)送過程中不需要等待服務(wù)器對前一個請求的響應(yīng)；只不過，客戶端還是要按照發(fā)送請求的順序來接收響應(yīng)。這也是管道的特點，而不會出現(xiàn)一個前面的請求被后面的請求覆蓋的情況。

HTTPS的工作原理

1、客戶端發(fā)起HTTPS請求

這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。

2、服務(wù)端的配置

采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務(wù))。

這套證書其實就是一對公鑰和私鑰，如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3、傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等。

4、客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。

如果證書沒有問題，那么就生成一個隨機值，然后用證書對該隨機值進行加密，就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

5、傳送加密信息

這部分傳送的是用證書加密后的隨機值，目的就是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。

6、服務(wù)段解密信息

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

7、傳輸加密后的信息

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

8、客戶端解密信息

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

HTTPS的優(yōu)點

1、SEO方面

谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

2、安全性

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

（1）、使用HTTPS協(xié)議可認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；

（2）、HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

（3）、HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

HTTPS的缺點：

1、SEO方面

據(jù)ACM CoNEXT數(shù)據(jù)顯示，使用HTTPS協(xié)議會使頁面的加載時間延長近50%，增加10%到20%的耗電，此外，HTTPS協(xié)議還會影響緩存，增加數(shù)據(jù)開銷和功耗，甚至已有安全措施也會受到影響也會因此而受到影響。

而且HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。

最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

2、經(jīng)濟方面

（1）、SSL證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

（2）、SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。

（3）、HTTPS連接緩存不如HTTP高效，大流量網(wǎng)站如非必要也不會采用，流量成本太高。

（4）、HTTPS連接服務(wù)器端資源占用高很多，支持訪客稍多的網(wǎng)站需要投入更大的成本，如果全部采用HTTPS，基于大部分計算資源閑置的假設(shè)的VPS的平均成本會上去。

（5）、HTTPS協(xié)議握手階段比較費時，對網(wǎng)站的相應(yīng)速度有負面影響，如非必要，沒有理由犧牲用戶體驗。

HTTPS的優(yōu)缺點（總結(jié)）

1.優(yōu)點： （1）使用HTTPS協(xié)議可認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；

（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

（3）HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

（4）谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。

2.缺點： （1）HTTPS協(xié)議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；

（2）HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；

（3）SSL證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。

（5）HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。 ?

對稱加密

?采?單鑰密碼系統(tǒng)的加密?法，同?個密鑰可以同時?作信息的加密和解密，這種加密?法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所?的密鑰是相同的 常?對稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等 特點：算法公開、計算量?、加密速度快、加密效率? 對稱加密其實就是通過同?個 "密鑰" , 把明?加密成密?, 并且也能把密?解密成明?

?個簡單的對稱加密, 按位異或

假設(shè) 明? a = 1234, 密鑰 key = 8888 則加密 a ^ key 得到的密? b 為 9834. 然后針對密? 9834 再次進?運算 b ^ key, 得到的就是原來的明? 1234. (對于字符串的對稱加密也是同理, 每?個字符都可以表?成?個數(shù)字) 當(dāng)然, 按位異或只是最簡單的對稱加密. HTTPS 中并不是使?按位異或

非對稱加密

需要兩個密鑰來進?加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。 常??對稱加密算法(了解)：RSA，DSA，ECDSA 特點：算法強度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，?使得加密解密速度沒有對 稱加密解密的速度快。 ?對稱加密要?到兩個密鑰, ?個叫做 "公鑰", ?個叫做 "私鑰". 公鑰和私鑰是配對的. 最?的缺點就是運算速度?常慢，?對稱加密要慢很多. 通過公鑰對明?加密, 變成密? 通過私鑰對密?解密, 變成明? 也可以反著? 通過私鑰對明?加密, 變成密? 通過公鑰對密?解密, 變成明?

?對稱加密的數(shù)學(xué)原理?較復(fù)雜, 涉及到?些 數(shù)論 相關(guān)的知識. 這?舉?個簡單的?活上的例?.

A 要給 B ?些重要的?件, 但是 B 可能不在. 于是 A 和 B 提前做出約定:

B 說: 我桌?上有個盒?, 然后我給你?把鎖, 你把?件放盒???鎖鎖上, 然后我回頭拿著鑰匙來開鎖取?件.

在這個場景中, 這把鎖就相當(dāng)于公鑰, 鑰匙就是私鑰. 公鑰給誰都?(不怕泄露), 但是私鑰只有 B ??持有. 持有私鑰的?才能解密.

證書

中間?有沒有可能篡改該證書？

中間?篡改了證書的明? 由于他沒有CA機構(gòu)的私鑰，所以?法hash之后?私鑰加密形成簽名，那么也就沒法辦法對篡改后的證書形成匹配的簽名 如果強?篡改，客?端收到該證書后會發(fā)現(xiàn)明?和簽名解密后的值不?致，則說明證書已被篡改，證書不可信，從?終?向服務(wù)器傳輸信息，防?信息泄露給中間?

中間?整個掉包證書？

因為中間?沒有CA私鑰，所以?法制作假的證書(為什么？) 所以中間?只能向CA申請真證書，然后???申請的證書進?掉包 這個確實能做到證書的整體掉包，但是別忘記，證書明?中包含了域名等服務(wù)端認證信息，如果整體掉包，客?端依舊能夠識別出來。 永遠記住：中間?沒有CA私鑰，所以對任何證書都?法進?合法修改，包括??的

?為什么摘要內(nèi)容在?絡(luò)傳輸?shù)臅r候?定要加密形成簽名?

假設(shè)我們的證書只是?個簡單的字符串 hello, 對這個字符串計算hash值(?如md5), 結(jié)果為

BC4B2A76B9719D91

如果 hello 中有任意的字符被篡改了, ?如變成了 hella, 那么計算的 md5 值就會變化很?.

BDBD6F9CF51F2FD8

然后我們可以把這個字符串 hello 和 哈希值 BC4B2A76B9719D91 從服務(wù)器返回給客?端, 此時客?端如何驗證 hello 是否是被篡改過?

那么就只要計算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91

?但是還有個問題, 如果?客把 hello 篡改了, 同時也把哈希值重新計算下, 客?端就分辨不出來了呀

?

所以被傳輸?shù)墓Ｖ挡荒軅鬏斆?, 需要傳輸密?.

所以，對證書明?(這?就是“hello”)hash形成散列摘要，然后CA使???的私鑰加密形成簽名，將

hello和加密的簽名合起來形成CA證書，頒發(fā)給服務(wù)端，當(dāng)客?端請求的時候，就發(fā)送給客?端，中間 ?截獲了，因為沒有CA私鑰，就?法更改或者整體掉包，就能安全的證明，證書的合法性。

最后，客?端通過操作系統(tǒng)?已經(jīng)存的了的證書發(fā)布機構(gòu)的公鑰進?解密, 還原出原始的哈希值, 再進?校驗.

為什么簽名不直接加密，?是要先hash形成摘要?

縮?簽名密?的?度,加快數(shù)字簽名的驗證簽名的運算速度

HTTPS的加密

HTTPS ?作過程中涉及到的密鑰有三組.

第?組(?對稱加密): ?于校驗證書是否被篡改. 服務(wù)器持有私鑰(私鑰在形成CSR?件與申請證書時獲

得), 客?端持有公鑰(操作系統(tǒng)包含了可信任的 CA 認證機構(gòu)有哪些, 同時持有對應(yīng)的公鑰). 服務(wù)器在客

?端請求是，返回攜帶簽名的證書. 客?端通過這個公鑰進?證書驗證, 保證證書的合法性，進?步保

證證書中攜帶的服務(wù)端公鑰權(quán)威性。

第?組(?對稱加密): ?于協(xié)商?成對稱加密的密鑰. 客?端?收到的CA證書中的公鑰(是可被信任的)

給隨機?成的對稱加密的密鑰加密, 傳輸給服務(wù)器, 服務(wù)器通過私鑰解密獲取到對稱加密密鑰.

第三組(對稱加密): 客?端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個對稱密鑰加密解密.

其實?切的關(guān)鍵都是圍繞這個對稱加密的密鑰. 其他的機制都是輔助這個密鑰?作的.

第?組?對稱加密的密鑰是為了讓客?端把這個對稱密鑰傳給服務(wù)器.

第?組?對稱加密的密鑰是為了讓客?端拿到第?組?對稱加密的公鑰.

柚子快報激活碼778899分享：網(wǎng)絡(luò)協(xié)議 HTTP和HTTPS

http://yzkb.51969.com/

精彩內(nèi)容