摘要:一端用私鑰加密,另一端用公鑰解密,也確保了來源目前現在好像使用了數字簽名就萬無一失了,其實還有問題。如果公鑰被偽造了,后面的數字簽名其實就毫無意義了。具有校驗機制,一旦被篡改,通信雙方會立刻發現。配備身份證書,防止身份被冒充。
一、前言
</>復制代碼
只有光頭才能變強
HTTP博文回顧:
PC端:HTTP就是這么簡單
PC端:HTTP面試題都在這里
微信公眾號端:HTTP就是這么簡單
微信公眾號端:HTTP面試題都在這里
本文力求簡單講清每個知識點,希望大家看完能有所收獲
二、HTTP協議的今生來世最近在看博客的時候,發現有的面試題已經考HTTP/2了,于是我就順著去了解一下。
到現在為止,HTTP協議已經有三個版本了:
HTTP1.0
HTTP1.1
HTTP/2
下面就簡單聊聊他們三者的區別,以及整理一些必要的額外知識點。
2.1HTTP版本之間的區別 2.1.1HTTP1.0和HTTP1.1區別HTTP1.0和HTTP1.1最主要的區別就是:
HTTP1.1默認是持久化連接!
在HTTP1.0默認是短連接:
簡單來說就是:每次與服務器交互,都需要新開一個連接!
試想一下:請求一張圖片,新開一個連接,請求一個CSS文件,新開一個連接,請求一個JS文件,新開一個連接。HTTP協議是基于TCP的,TCP每次都要經過三次握手,四次揮手,慢啟動...這都需要去消耗我們非常多的資源的!
在HTTP1.1中默認就使用持久化連接來解決:建立一次連接,多次請求均由這個連接完成!(如果阻塞了,還是會開新的TCP連接的)
相對于持久化連接還有另外比較重要的改動:
HTTP 1.1增加host字段
HTTP 1.1中引入了Chunked transfer-coding,范圍請求,實現斷點續傳(實際上就是利用HTTP消息頭使用分塊傳輸編碼,將實體主體分塊傳輸)
HTTP 1.1管線化(pipelining)理論,客戶端可以同時發出多個HTTP請求,而不用一個個等待響應之后再請求
注意:這個pipelining僅僅是限于理論場景下,大部分桌面瀏覽器仍然會選擇默認關閉HTTP pipelining!
所以現在使用HTTP1.1協議的應用,都是有可能會開多個TCP連接的!
參考資料:
https://www.cnblogs.com/gofighting/p/5421890.html
2.1.2HTTP2基礎在說HTTP2之前,不如先直觀比較一下HTTP2和HTTP1.1的區別:
https://http2.akamai.com/demo
上面也已經說了,HTTP 1.1提出了管線化(pipelining)理論,但是僅僅是限于理論的階段上,這個功能默認還是關閉了的。
管線化(pipelining)和非管線化的區別:
</>復制代碼
HTTP Pipelining其實是把多個HTTP請求放到一個TCP連接中一一發送,而在發送過程中不需要等待服務器對前一個請求的響應;只不過,客戶端還是要按照發送請求的順序來接收響應!
</>復制代碼
就像在超市收銀臺或者銀行柜臺排隊時一樣,你并不知道前面的顧客是干脆利索的還是會跟收銀員/柜員磨蹭到世界末日(不管怎么說,服務器(即收銀員/柜員)是要按照順序處理請求的,如果前一個請求非常耗時(顧客磨蹭),那么后續請求都會受到影響。
在HTTP1.0中,發送一次請求時,需要等待服務端響應了才可以繼續發送請求。
在HTTP1.1中,發送一次請求時,不需要等待服務端響應了就可以發送請求了,但是回送數據給客戶端的時候,客戶端還是需要按照響應的順序來一一接收
所以說,無論是HTTP1.0還是HTTP1.1提出了Pipelining理論,還是會出現阻塞的情況。從專業的名詞上說這種情況,叫做線頭阻塞(Head of line blocking)簡稱:HOLB
2.1.3HTTP1.1和HTTP2區別HTTP2與HTTP1.1最重要的區別就是解決了線頭阻塞的問題!其中最重要的改動是:多路復用 (Multiplexing)
多路復用意味著線頭阻塞將不在是一個問題,允許同時通過單一的 HTTP/2 連接發起多重的請求-響應消息,合并多個請求為一個的優化將不再適用。
(我們知道:HTTP1.1中的Pipelining是沒有付諸于實際的),之前為了減少HTTP請求,有很多操作將多個請求合并,比如:Spriting(多個圖片合成一個圖片),內聯Inlining(將圖片的原始數據嵌入在CSS文件里面的URL里),拼接Concatenation(一個請求就將其下載完多個JS文件),分片Sharding(將請求分配到各個主機上)......
使用了HTTP2可能是這樣子的:
HTTP2所有性能增強的核心在于新的二進制分幀層(不再以文本格式來傳輸了),它定義了如何封裝http消息并在客戶端與服務器之間傳輸。
看上去協議的格式和HTTP1.x完全不同了,實際上HTTP2并沒有改變HTTP1.x的語義,只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已
HTTP2連接上傳輸的每個幀都關聯到一個“流”。流是一個獨立的,雙向的幀序列可以通過一個HTTP2的連接在服務端與客戶端之間不斷的交換數據。
實際上運輸時:
HTTP2還有一些比較重要的改動:
使用HPACK對HTTP/2頭部壓縮
服務器推送
HTTP2推送資料:https://segmentfault.com/a/1190000015773338
流量控制
針對傳輸中的流進行控制(TCP默認的粒度是針對連接)
流優先級(Stream Priority)它被用來告訴對端哪個流更重要。
2.2HTTP2總結HTTP1.1新改動:
持久連接
請求管道化
增加緩存處理(新的字段如cache-control)
增加Host字段、支持斷點傳輸等
HTTP2新改動:
二進制分幀
多路復用
頭部壓縮
服務器推送
參考資料:
HTTP2 GitBook電子書(中文版):https://legacy.gitbook.com/book/ye11ow/http2-explained/details
HTTP/2.0 相比1.0有哪些重大改進?https://www.zhihu.com/question/34074946
HTTP/2 新特性淺析:https://segmentfault.com/a/1190000002765886
HTTP2學習資料:https://imququ.com/post/http2-resource.html
HTTP2簡介和基于HTTP2的Web優化:http://caibaojian.com/toutiao/6641
http2原理入門:https://blog.qingf.me/?p=600
HTTP/2 對現在的網頁訪問,有什么大的優化呢?體現在什么地方?https://www.zhihu.com/question/24774343/answer/96586977
HTTP/2筆記之流和多路復用:http://www.blogjava.net/yongboy/archive/2015/03/19/423611.aspx
2.3HTTPS再次回顧之前在面試的時候被問到了HTTPS,SSL這樣的知識點,也沒答上來,這里也簡單整理一下。
首先還是來解釋一下基礎的東東:
對稱加密:
加密和解密都是用同一個密鑰
非對稱加密:
加密用公開的密鑰,解密用私鑰
(私鑰只有自己知道,公開的密鑰大家都知道)
數字簽名:
驗證傳輸的內容是對方發送的數據
發送的數據沒有被篡改過
數字證書 (Certificate)
認證機構證明是真實的服務器發送的數據。
3y的通訊之路:
遠古時代:3y和女朋友聊天傳輸數據之間沒有任何的加密,直接傳輸
內容被看得一清二楚,毫無隱私可言
上古時期:使用對稱加密的方式來保證傳輸的數據只有兩個人知道
此時有個問題:密鑰不能通過網絡傳輸(因為沒有加密之前,都是不安全的),所以3y和女朋友先約見面一次,告訴對方密碼是多少,再對話聊天。
中古時期:3y不單單要跟女朋友聊天,還要跟爸媽聊天的哇(同樣不想泄漏了自己的通訊信息)。那有那么多人,難道每一次都要約來見面一次嗎?(說明維護多個對稱密鑰是麻煩的!)--->所以用到了非對稱加密
3y自己保留一份密碼,獨一無二的(私鑰)。告訴3y女朋友,爸媽一份密碼(這份密碼是公開的,誰都可以拿--->公鑰)。讓他們給我發消息之前,先用那份我告訴他們的密碼加密一下,再發送給我。我收到信息之后,用自己獨一無二的私鑰解密就可以了!
近代:此時又出現一個問題:雖然別人不知道私鑰是什么,拿不到你原始傳輸的數據,但是可以拿到加密后的數據,他們可以改掉某部分的數據再發送給服務器,這樣服務器拿到的數據就不是完整的了。
3y女朋友給3y發了一條信息”3y我喜歡你“,然后用3y給的公鑰加密,發給3y了。此時不懷好意的人截取到這條加密的信息,他破解不了原信息。但是他可以修改加密后的數據再傳給3y。可能3y拿到收到的數據就是”3y你今晚跪鍵盤吧“
現代:拿到的數據可能被篡改了,我們可以使用數字簽名來解決被篡改的問題。數字簽名其實也可以看做是非對稱加密的手段一種,具體是這樣的:得到原信息hash值,用私鑰對hash值加密,另一端用公鑰解密,最后比對hash值是否變了。如果變了就說明被篡改了。(一端用私鑰加密,另一端用公鑰解密,也確保了來源)
目前現在:好像使用了數字簽名就萬無一失了,其實還有問題。我們使用非對稱加密的時候,是使用公鑰進行加密的。如果公鑰被偽造了,后面的數字簽名其實就毫無意義了。講到底:還是可能會被中間人攻擊~此時我們就有了CA認證機構來確認公鑰的真實性!
對于數字簽名和CA認證還是不太了解參考一下
阮一峰:http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
什么是數字簽名和證書?https://www.jianshu.com/p/9db57e761255
回到我們的HTTPS,HTTPS其實就是在HTTP協議下多加了一層SSL協議(ps:現在都用TLS協議了)
HTTPS采用的是混合方式加密:
過程是這樣子的:
用戶向web服務器發起一個安全連接的請求
服務器返回經過CA認證的數字證書,證書里面包含了服務器的public key(公鑰)
用戶拿到數字證書,用自己瀏覽器內置的CA證書解密得到服務器的public key
用戶用服務器的public key加密一個用于接下來的對稱加密算法的密鑰,傳給web服務器
因為只有服務器有private key可以解密,所以不用擔心中間人攔截這個加密的密鑰
服務器拿到這個加密的密鑰,解密獲取密鑰,再使用對稱加密算法,和用戶完成接下來的網絡通信
所以相比HTTP,HTTPS 傳輸更加安全
(1) 所有信息都是加密傳播,黑客無法竊聽。
(2) 具有校驗機制,一旦被篡改,通信雙方會立刻發現。
(3) 配備身份證書,防止身份被冒充。
參考資料:
數字簽名、數字證書、SSL、https是什么關系?https://www.zhihu.com/question/52493697/answer/131015846
淺談SSL/TLS工作原理:https://zhuanlan.zhihu.com/p/36981565
HTTPS:https://tech.upyun.com/article/192/HTTPS%E7%B3%BB%E5%88%97%E5%B9%B2%E8%B4%A7%EF%BC%88%E4%B8%80%EF%BC%89%EF%BC%9AHTTPS%20%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3.html
網站HTTP升級HTTPS完全配置手冊:https://www.cnblogs.com/powertoolsteam/p/http2https.html
三、總結我只是在學習的過程中,把自己遇到的問題寫出來,整理出來,希望可以對大家有幫助。如果文章有錯的地方,希望大家可以在評論區指正,一起學習交流~
參考資料:
《圖解HTTP》
</>復制代碼
如果文章有錯的地方歡迎指正,大家互相交流。習慣在微信看技術文章,想要獲取更多的Java資源的同學,可以關注微信公眾號:Java3y。為了大家方便,剛新建了一下qq群:742919422,大家也可以去交流交流。謝謝支持了!希望能多介紹給其他有需要的朋友
文章的目錄導航:
https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/76567.html
摘要:摘要本文由阿里視頻云高級技術專家空見撰寫,主要介紹的歷史特性如何使用和使用之后的性能對比驗證。實踐證明解決了的一些頑疾,在性能上提升顯著,最終正式考慮制定的計劃,最后決定以為基礎起草,的部分設計人員也被邀請參與了的設計。 摘要: 本文由阿里視頻云高級技術專家空見撰寫,主要介紹HTTP2.0的歷史、特性、如何使用和使用之后的性能對比驗證。 背景介紹 要了解HTTP2.0,先了解一下HT...
摘要:所以說我們的線程最好是交由線程池來管理,這樣可以減少對線程生命周期的管理,一定程度上提高性能。線程池不接收新任務,不處理已添加的任務,并且會中斷正在處理的任務。當所有的任務已終止,記錄的任務數量為,線程池會變為狀態。線程池徹底終止的狀態。 前言 只有光頭才能變強 回顧前面: ThreadLocal就是這么簡單 多線程三分鐘就可以入個門了! 多線程基礎必要知識點!看了學習多線程事半功倍...
摘要:開發者可以通過查詢錢包來確認某個客戶的入賬或者訂單的付款情況。使用帶來的另一個好處是你可以直接提供所有支持的資產的收款。感覺買一送十,簡直是數字通貨支付的支付寶和。 EOS吹的這么牛,創始人這么厲害,感覺要超過比特幣,網站允許用戶支付EOS肯定很酷 于是程序員滿懷信心的去查找eos的api。發現了一個history 接口可以用來查詢任何一個賬戶的歷史記錄。簡直完美,DM果然靠譜。于是程...
摘要:開發者可以通過查詢錢包來確認某個客戶的入賬或者訂單的付款情況。使用帶來的另一個好處是你可以直接提供所有支持的資產的收款。感覺買一送十,簡直是數字通貨支付的支付寶和。 EOS吹的這么牛,創始人這么厲害,感覺要超過比特幣,網站允許用戶支付EOS肯定很酷 于是程序員滿懷信心的去查找eos的api。發現了一個history 接口可以用來查詢任何一個賬戶的歷史記錄。簡直完美,DM果然靠譜。于是程...
摘要:開發者可以通過查詢錢包來確認某個客戶的入賬或者訂單的付款情況。使用帶來的另一個好處是你可以直接提供所有支持的資產的收款。感覺買一送十,簡直是數字通貨支付的支付寶和。 EOS吹的這么牛,創始人這么厲害,感覺要超過比特幣,網站允許用戶支付EOS肯定很酷 于是程序員滿懷信心的去查找eos的api。發現了一個history 接口可以用來查詢任何一個賬戶的歷史記錄。簡直完美,DM果然靠譜。于是程...
閱讀 2374·2021-11-22 14:56
閱讀 1181·2019-08-30 15:55
閱讀 3211·2019-08-29 13:29
閱讀 1361·2019-08-26 13:56
閱讀 3500·2019-08-26 13:37
閱讀 567·2019-08-26 13:33
閱讀 3354·2019-08-26 13:33
閱讀 2235·2019-08-26 13:33