一.HTTP協議

　　1.官方概念：

　　　　HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。（雖然童鞋們將這條概念都看爛了，但是也沒辦法，畢竟這就是HTTP的權威官方的概念解釋，要想徹底理解，請客觀目移下側......）

　　2.白話概念：

　　　　HTTP協議就是服務器（Server）和客戶端（Client）之間進行數據交互（相互傳輸數據）的一種形式。我們可以將Server和Client進行擬人化，那么該協議就是Server和Client這兩兄弟間指定的一種交互溝通方式。

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：服務器將這份數字證書發送給客戶端，因為客戶端也認可證書機構，客戶端可以通過數字證書中的數字簽名來驗證公鑰的真偽，來確保服務器傳過來的公開密鑰是真實的。一般情況下，證書的數字簽名是很難被偽造的，這取決于認證機構的公信力。一旦確認信息無誤之后，客戶端就會通過公鑰對報文進行加密發送，服務器接收到以后用自己的私鑰進行解密。