一.HTTP協議html
1.官方概念：ajax
HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。（雖然童鞋們將這條概念都看爛了，可是也沒辦法，畢竟這就是HTTP的權威官方的概念解釋，要想完全理解，請客觀目移下側......）算法
2.白話概念：瀏覽器
HTTP協議就是服務器（Server）和客戶端（Client）之間進行數據交互（相互傳輸數據）的一種形式。咱們能夠將Server和Client進行擬人化，那麼該協議就是Server和Client這兩兄弟間指定的一種交互溝通方式。你們都看過智取威虎山中楊子榮和土匪們之間說的黑話吧：緩存
- 土匪：蘑菇，你哪路？什麼價？（什麼人？到哪裏去？）安全
- 楊子榮：哈！想啥來啥，想吃奶來了媽媽，想孃家的人，孩子他舅舅來了。（找同行）服務器
- 楊子榮：拜見三爺！網絡
- 土匪：天王蓋地虎！（你好大的膽！敢來氣你的祖宗？）架構
- 楊子榮：寶塔鎮河妖！（要是那樣，叫我從山上摔死，掉河裏淹死。）
- 土匪：野雞悶頭鑽，哪能上天王山！（你不是正牌的。）
- 楊子榮：地上有的是米，喂呀，有根底！（老子是正牌的，老牌的。）
- 土匪：拜見過阿媽啦？（你從小拜誰爲師？）
- 楊子榮：他房上沒瓦，非否非，否非否！（不到正堂不能說。）
- 土匪：嘛哈嘛哈？（之前獨幹嘛？）
- 楊子榮：正晌午說話，誰尚未家？（許大馬棒山上。）
- 土匪：好叭噠！（內行，是把老手）
- 楊子榮：天下大耷拉！（不吹牛，闖過大隊頭。）
- 座山雕：臉紅什麼？
- 楊子榮：神采飛揚！
- 座山雕：怎麼又黃了？
- 楊子榮：防冷，塗的蠟！
- 座山雕：曬噠曬噠。（誰指點你來的？）
- 楊子榮：一座玲瓏塔，面向青寨背靠沙！（是個道人。）ide
是否是看到這裏，有得童鞋終於知道了傳說中的‘天王蓋地虎’是真正含義了吧。此黑話其實就是楊子榮和土匪之間進行交互溝通的方式（協議）。
3.HTTP工做原理：
HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。
4.HTTP四點注意事項：
- HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
- HTTP是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
- HTTP是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
- HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
5.HTTP之URL：
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息
URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。如下面這個URL爲例，介紹下普通URL的各部分組成：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name從上面的URL能夠看出，一個完整的URL包括如下幾部分：
- 協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符
- 域名部分：該URL的域名部分爲「www.aspxfans.com」。一個URL中，也可使用IP地址做爲域名使用
- 端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口
- 虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/news/」
- 文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「index.asp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名
- 錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分
- 參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「boardID=5&ID=24618&page=1」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符。
6.HTTP之Request：
客戶端發送一個HTTP請求到服務器的請求消息包括如下組成部分：
報文頭：常被叫作請求頭，請求頭中存儲的是該請求的一些主要說明（自我介紹）。服務器據此獲取客戶端的信息。
常見的請求頭：
accept:瀏覽器經過這個頭告訴服務器，它所支持的數據類型
Accept-Charset: 瀏覽器經過這個頭告訴服務器，它支持哪一種字符集
Accept-Encoding：瀏覽器經過這個頭告訴服務器，支持的壓縮格式
Accept-Language：瀏覽器經過這個頭告訴服務器，它的語言環境
Host：瀏覽器經過這個頭告訴服務器，想訪問哪臺主機
If-Modified-Since: 瀏覽器經過這個頭告訴服務器，緩存數據的時間
Referer：瀏覽器經過這個頭告訴服務器，客戶機是哪一個頁面來的 防盜鏈
Connection：瀏覽器經過這個頭告訴服務器，請求完後是斷開連接仍是何持連接
X-Requested-With: XMLHttpRequest 表明經過ajax方式進行訪問
User-Agent：請求載體的身份標識
報文體：常被叫作請求體，請求體中存儲的是將要傳輸/發送給服務器的數據信息。
7.HTTP之Response：
服務器回傳一個HTTP響應到客戶端的響應消息包括如下組成部分：
狀態碼：以「清晰明確」的語言告訴客戶端本次請求的處理結果。
HTTP的響應狀態碼由5段組成：
-
-
- 1xx 消息，通常是告訴客戶端，請求已經收到了，正在處理，別急...
- 2xx 處理成功，通常表示：請求收悉、我明白你要的、請求已受理、已經處理完成等信息.
- 3xx 重定向到其它地方。它讓客戶端再發起一個請求以完成整個處理。
- 4xx 處理髮生錯誤，責任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被受權，禁止訪問等。
- 5xx 處理髮生錯誤，責任在服務端，如服務端拋出異常，路由出錯，HTTP版本不支持等。
-
相應頭：響應的詳情展現
常見的相應頭信息：
Location: 服務器經過這個頭，來告訴瀏覽器跳到哪裏
Server：服務器經過這個頭，告訴瀏覽器服務器的型號
Content-Encoding：服務器經過這個頭，告訴瀏覽器，數據的壓縮格式
Content-Length: 服務器經過這個頭，告訴瀏覽器回送數據的長度
Content-Language: 服務器經過這個頭，告訴瀏覽器語言環境
Content-Type：服務器經過這個頭，告訴瀏覽器回送數據的類型
Refresh：服務器經過這個頭，告訴瀏覽器定時刷新
Content-Disposition: 服務器經過這個頭，告訴瀏覽器如下載方式打數據
Transfer-Encoding：服務器經過這個頭，告訴瀏覽器數據是以分塊方式回送的
Expires: -1 控制瀏覽器不要緩存
Cache-Control: no-cache
Pragma: no-cache
相應體：根據客戶端指定的請求信息，發送給客戶端的指定數據
二.HTTPS協議
1.官方概念：
HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協議，HTTPS是在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。
2.白話概念：
加密安全版的HTTP協議。
3.HTTPS採用的加密技術
3.1 SSL加密技術
SSL採用的加密技術叫作「共享密鑰加密」，也叫做「對稱密鑰加密」，這種加密方法是這樣的，好比客戶端向服務器發送一條信息，首先客戶端會採用已知的算法對信息進行加密，好比MD5或者Base64加密，接收端對加密的信息進行解密的時候須要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。這種方式看起來安全，可是仍有潛在的危險，一旦被竊聽，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。所以「共享密鑰加密」這種方式存在安全隱患：
3.2 非對稱祕鑰加密技術
「非對稱加密」使用的時候有兩把鎖，一把叫作「私有密鑰」，一把是「公開密鑰」，使用非對象加密的加密方式的時候，服務器首先告訴客戶端按照本身給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密之後，服務器接受到信息再經過本身的私有密鑰進行解密，這樣作的好處就是解密的鑰匙根本就不會進行傳輸，所以也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，由於解密過程是對離散對數求值，這可不是垂手可得就能作到的事。如下是非對稱加密的原理圖：
可是非對稱祕鑰加密技術也存在以下缺點：
第一個是：如何保證接收端向發送端發出公開祕鑰的時候，發送端確保收到的是預先要發送的，而不會被挾持。只要是發送密鑰，就有可能有被挾持的風險。
第二個是：非對稱加密的方式效率比較低，它處理起來更爲複雜，通訊過程當中使用就有必定的效率問題而影響通訊速度
4.https的證書機制
在上面咱們講了非對稱加密的缺點，其中第一個就是公鑰極可能存在被挾持的狀況，沒法保證客戶端收到的公開密鑰就是服務器發行的公開密鑰。此時就引出了公開密鑰證書機制。數字證書認證機構是客戶端與服務器均可信賴的第三方機構。證書的具體傳播過程以下：
1：服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公開密鑰的申請，數字證書認證機構在認清申請者的身份，審覈經過之後，會對開發者申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將密鑰放在證書裏面，綁定在一塊兒
2：服務器將這份數字證書發送給客戶端，由於客戶端也承認證書機構，客戶端能夠經過數字證書中的數字簽名來驗證公鑰的真僞，來確保服務器傳過來的公開密鑰是真實的。通常狀況下，證書的數字簽名是很難被僞造的，這取決於認證機構的公信力。一旦確認信息無誤以後，客戶端就會經過公鑰對報文進行加密發送，服務器接收到之後用本身的私鑰進行解密。
備註：本文中採用了https://www.cnblogs.com/wyq178/p/7129232.html