HTTP請求/響應報文結(jié)構(gòu)

上海網(wǎng)站建設公司成都創(chuàng)新互聯(lián),上海網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為上海上1000家提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設公司要多少錢，請找那個售后服務好的上海做網(wǎng)站的公司定做！

一、HTTPS解決了哪些問題？

竊聽風險，通訊鏈路上被第三方獲取通信內(nèi)容，用戶賬號容易丟失；
篡改風險，通訊數(shù)據(jù)被篡改，強制執(zhí)行廣告等；
冒充風險，冒充服務器網(wǎng)站，如冒充淘寶造成財產(chǎn)損失；

針對竊聽風險——混合加密

建立通信前采用非對稱密鑰的方式交換會話密鑰；
通信過程中全部使用對稱加密的會話密鑰的方式加密明文數(shù)據(jù)；

針對篡改風險——數(shù)字簽名+摘要(哈希)算法

• 數(shù)字簽名中包含服務器端對數(shù)據(jù)的哈希運算值A，服務器采用私鑰加密數(shù)字簽名，并發(fā)送給客戶端；
• 客戶端采用服務器的公鑰對數(shù)字簽名進行解密，獲哈希運算值A,并對數(shù)據(jù)進行哈希運算獲得哈希運算值B；
• 比較哈希值A==哈希值B可以判斷數(shù)據(jù)是否被篡改。

針對冒充風險——數(shù)字證書

為了避免客戶端的公鑰不是服務器發(fā)送的，而是第三方偽造的。導致第三方數(shù)據(jù)可以被客戶端接收。用于驗證服務器端的合法性，此時采用數(shù)字證書機制：

• 服務器將公鑰注冊到CA(數(shù)字認證機構(gòu))；
• 客戶端拿到數(shù)字證書后進行CA認證證書合法性，合法，則用服務器發(fā)送來的公鑰對數(shù)字簽名進行解密并校驗數(shù)據(jù)是否被篡改；
• 之后客戶端使用該服務器公鑰對報文進行加密后發(fā)送給服務器；

服務器公鑰+數(shù)字簽名==數(shù)字證書

二、HTTPS的應用數(shù)據(jù)是如何保證完整性的？

TLS記錄協(xié)議主要負責消息(HTTP數(shù)據(jù))的壓縮，加密及數(shù)據(jù)的認證：

三、HTTPS一定安全可靠嗎？

這個問題的場景是這樣的：客戶端通過瀏覽器向服務端發(fā)起 HTTPS 請求時，被「假基站」轉(zhuǎn)發(fā)到了一個「中間人服務器」，于是客戶端是和「中間人服務器」完成了 TLS 握手，然后這個「中間人服務器」再與真正的服務端完成 TLS 握手。

從客戶端的角度看，并不知道網(wǎng)絡中存在中間人服務器這個角色。中間人服務器可以解開瀏覽器發(fā)起的HTTPS請求里的數(shù)據(jù)，也可以解開服務器端響應給瀏覽器的HTTPS響應數(shù)據(jù)。

***但是要發(fā)生上述情況的前提是，瀏覽器端接受了中間人服務器的數(shù)字證書(數(shù)字簽名+公鑰)。

中間人服務器與客戶端在TLS握手過程中，實際上發(fā)送了自己偽造的證書給瀏覽器，而這個偽造的證書是能被瀏覽器識別的出非法的，會提醒用戶該證書是非法的。如果用戶執(zhí)意點擊「繼續(xù)瀏覽此網(wǎng)站」，相當于用戶接受了中間人偽造的證書，那么后續(xù)整個 HTTPS 通信都能被中間人監(jiān)聽了。

抓包工具能夠抓包的關(guān)鍵是客戶端會往系統(tǒng)受信任的根證書列表中導入抓包工具生成的證書，而這個證書會被瀏覽器信任，也就是抓包工具給自己創(chuàng)建了一個認證中心 CA，客戶端拿著中間人簽發(fā)的證書去中間人自己的 CA 去認證，當然認為這個證書是有效的。

HTTPS 協(xié)議本身到目前為止還是沒有任何漏洞的，即使你成功進行中間人攻擊，本質(zhì)上是利用了客戶端的漏洞（用戶點擊繼續(xù)訪問或者被惡意導入偽造的根證書），并不是 HTTPS 不夠安全。

參考：3.1 HTTP 常見面試題 | 小林coding

四、HTTP/1.1優(yōu)化——避免發(fā)送 HTTP 請求——緩存機制

五、HTTP/1.1優(yōu)化——減少 HTTP 請求次數(shù)

1.減少重定向工作

將重定向工作交給代理服務器來完成。

2.合并請求

合并請求的方式就是合并資源，以一個大資源的請求替換多個小資源的請求。

3.延遲發(fā)送請求

通過「按需獲取」的方式，來減少第一時間的 HTTP 請求次數(shù)。請求網(wǎng)頁的時候，沒必要把全部資源都獲取到，而是只獲取當前用戶所看到的頁面資源，當用戶向下滑動頁面的時候，再向服務器獲取接下來的資源，這樣就達到了延遲發(fā)送請求的效果。

六、HTTP/1.1優(yōu)化——減少 HTTP 響應的數(shù)據(jù)大小

對于 HTTP 的請求和響應，通常 HTTP 的響應的數(shù)據(jù)大小會比較大，也就是服務器返回的資源會比較大?？紤]對響應的資源進行壓縮，這樣就可以減少響應的數(shù)據(jù)大小，從而提高網(wǎng)絡傳輸?shù)男省?/p>

• 無損壓縮；
• 有損壓縮；

客戶端支持的壓縮算法，會在 HTTP 請求中通過頭部中的Accept-Encoding字段告訴服務器：

Accept-Encoding: gzip, deflate, br

服務器收到后，會從中選擇一個服務器支持的或者合適的壓縮算法，然后使用此壓縮算法對響應資源進行壓縮，最后通過響應頭部中的content-encoding字段告訴客戶端該資源使用的壓縮算法。

content-encoding: gzip

附加：HTTP/1.1優(yōu)化——使用長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷。

七、數(shù)字證書的作用？

用于驗證服務器端的合法性！

第三方中間人服務器如果偽造服務端，將其偽造的數(shù)字證書發(fā)送給客戶端，將無法被CA認證數(shù)字證書的合法性，因此可以判斷其不是服務端發(fā)來的數(shù)字證書。

從而保證客戶端獲得的公鑰是目的服務端私鑰對應的公鑰。

八、HTTPS——RSA加密算法

RSA加密，由于客戶端和服務器的隨機數(shù)都是公開的，一旦服務端的私鑰被泄露，第三方中間服務器就可以獲得客戶端發(fā)來的第三個隨機數(shù)，最終算出會話密鑰，導致會話密鑰泄露（RSA不具備前向安全性）。

九、HTTPS——ECDHE加密算法

防止第三方中間服務器的關(guān)鍵內(nèi)容在于，數(shù)字證書可以保證客戶端收到的公鑰是服務端發(fā)來的合法公鑰，其服務端合法。

RSA加密，由于客戶端和服務器的隨機數(shù)都是公開的，一旦服務端的私鑰被泄露，第三方中間服務器就可以獲得客戶端發(fā)來的第三個隨機數(shù)，最終算出會話密鑰，導致會話密鑰泄露（RSA不具備前向安全性）。

ECDHE加密中，服務器生成一個橢圓曲線公鑰Q2使用私鑰加密后發(fā)送給客戶端，客戶端生成一個橢圓曲線公鑰Q1使用公鑰加密發(fā)送給服務器。

即使第三方服務器破解了服務器端的私鑰，最終也只能獲得客戶端發(fā)送的橢圓曲線公鑰Q1，由于不知道服務器和客戶端的隨機數(shù)私鑰d1,d2，因此仍無法破解會話密鑰。

參考：
使用ECDHE加密算法的TLS握手流程_windsofchange的博客-博客_ecdhe算法
分分鐘讓你理解HTTPS - 掘金

十、數(shù)字證書機制可以防止第三方冒充服務器嗎？

在第二次握手的時候，服務器會下發(fā)用于證明自己身份的證書，這個證書會用預設在設備上的公鑰來解密。所以要么是經(jīng)過認證的證書用權(quán)威機構(gòu)的私鑰加密，再用權(quán)威機構(gòu)的公鑰解密。要么是使用非權(quán)威機構(gòu)的私鑰加密，找不到公鑰解密。

如果不小心安裝過非權(quán)威機構(gòu)的根證書，比如黑客提供的惡意證書，此時設備上多了一個預設的公鑰，那么用惡意私鑰加密的證書就能被正常解析出來。所以千萬不要隨便安裝根證書。

你是否還在尋找穩(wěn)定的海外服務器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調(diào)度確保服務器高可用性，企業(yè)級服務器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

當前文章：計算機網(wǎng)絡——HTTP/HTTPS-創(chuàng)新互聯(lián)
文章來源：http://jinyejixie.com/article30/dsiipo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、響應式網(wǎng)站、標簽優(yōu)化、網(wǎng)站改版、營銷型網(wǎng)站建設、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)