欧美free性护士vide0shd,老熟女,一区二区三区,久久久久夜夜夜精品国产,久久久久久综合网天天,欧美成人护士h版

首頁綜合正文

評論

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

Submarino深海購物棧綜合2025-05-05240

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

http://yzkb.51969.com/

HTTP和HTTPS的基本概念(應用層協(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的基本概念(應用層協(xié)議）

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

HTTPS（HyperText Transfer Protocol Secure：超文本傳輸安全協(xié)議）：是以安全為目標的HTTP通道，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內(nèi)容就需要SSL。HTTPS 開發(fā)的主要目的，是提供對網(wǎng)站服務器的身份認證，保護交換數(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請求和響應之后立即關(guān)閉本次TCP連接，下次請求響應重建一個新的TCP連接；而長連接是指請求響應之后并不立即關(guān)閉本次TCP連接，下次請求響應繼續(xù)重用該TCP連接。HTTP/1.0默認短連接，HTTP/1.1起默認長連接，長連接通過請求頭Connection: keep-alive啟用長連接、通過Keep-Alive: timeout=20設置長連接的超時時間（秒）。

HTTP/1的長輪詢：?

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

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

HTTP/2.0:

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

HTTP/2的隊頭阻塞：

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

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

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

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

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

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

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

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

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

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

HTTP/3.0:

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

總結(jié)

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

HTTP狀態(tài)碼

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

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

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

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

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

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

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

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

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

2打頭：

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

3打頭：

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

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

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

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

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:*/* ? ? 表示可接受的響應的類型為全部類型

Accept-Language:zh ? ? 表示可接受的響應的語言為中文

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

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

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

3.請求正文 ?

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

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

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

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

GET和POST請求

get 和 post請求是http協(xié)議中的兩種請求方式。get一般用來獲取服務器的信息的，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ā)送出去，服務器響應200，請求成功。對于POST請求，瀏覽器先發(fā)送header，服務器會響應100（已經(jīng)收到請求的第一部分，正在等待其余部分），瀏覽器再次發(fā)送data，服務器返回200，請求成功。并不是所有瀏覽器都會在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次。

條件GET方法

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

幸運的是，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)絡協(xié)議，比HTTP協(xié)議安全。

HTTP的工作原理

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

HTTP的長鏈接?

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

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

HTTPS的工作原理

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

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

2、服務端的配置

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

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

3、傳送證書

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

4、客戶端解析證書

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

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

5、傳送加密信息

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

6、服務段解密信息

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

7、傳輸加密后的信息

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

8、客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，于是獲取了解密后的內(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é)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；

（2）、HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(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é)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。

最關(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ǎng)站需要投入更大的成本，如果全部采用HTTPS，基于大部分計算資源閑置的假設的VPS的平均成本會上去。

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

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

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

（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(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é)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。 ?

對稱加密

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

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

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

非對稱加密

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

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

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

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

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

證書

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

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

中間?整個掉包證書？

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

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

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

BC4B2A76B9719D91

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

BDBD6F9CF51F2FD8

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

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

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

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

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

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

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