一.HTTP協(xié)議

　　1.官方概念：

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

　　2.白話概念：

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

3.HTTP工作原理：

　　　　HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上。瀏覽器作為HTTP客戶端通過(guò)URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請(qǐng)求。Web服務(wù)器根據(jù)接收到的請(qǐng)求后，向客戶端發(fā)送響應(yīng)信息。

?

　　4.HTTP四點(diǎn)注意事項(xiàng)：

　　　　- HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

- HTTP是無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。

　　　　- HTTP是媒體獨(dú)立的：這意味著，只要客戶端和服務(wù)器知道如何處理的數(shù)據(jù)內(nèi)容，任何類型的數(shù)據(jù)都可以通過(guò)HTTP發(fā)送。客戶端以及服務(wù)器指定使用適合的MIME-type內(nèi)容類型。

　　　　- HTTP是無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

　　5.HTTP之URL：

HTTP使用統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers, URI）來(lái)傳輸數(shù)據(jù)和建立連接。URL是一種特殊類型的URI，包含了用于查找某個(gè)資源的足夠的信息

URL,全稱是UniformResourceLocator, 中文叫統(tǒng)一資源定位符,是互聯(lián)網(wǎng)上用來(lái)標(biāo)識(shí)某一處資源的地址。以下面這個(gè)URL為例，介紹下普通URL的各部分組成： http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name 從上面的URL可以看出，一個(gè)完整的URL包括以下幾部分：

　　　　- 協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁(yè)使用的是HTTP協(xié)議。在Internet中可以使用多種協(xié)議，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議。在"HTTP"后面的“//”為分隔符

　　　　- 域名部分：該URL的域名部分為“www.aspxfans.com”。一個(gè)URL中，也可以使用IP地址作為域名使用

　　　　- 端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個(gè)URL必須的部分，如果省略端口部分，將采用默認(rèn)端口

　　　　- 虛擬目錄部分：從域名后的第一個(gè)“/”開(kāi)始到最后一個(gè)“/”為止，是虛擬目錄部分。虛擬目錄也不是一個(gè)URL必須的部分。本例中的虛擬目錄是“/news/”

　　　　- 文件名部分：從域名后的最后一個(gè)“/”開(kāi)始到“？”為止，是文件名部分，如果沒(méi)有“?”,則是從域名后的最后一個(gè)“/”開(kāi)始到“#”為止，是文件部分，如果沒(méi)有“？”和“#”，那么從域名后的最后一個(gè)“/”開(kāi)始到結(jié)束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個(gè)URL必須的部分，如果省略該部分，則使用默認(rèn)的文件名

　　　　- 錨部分：從“#”開(kāi)始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個(gè)URL必須的部分

　　　　- 參數(shù)部分：從“？”開(kāi)始到“#”為止之間的部分為參數(shù)部分，又稱搜索部分、查詢部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個(gè)參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

　　6.HTTP之Request：

客戶端發(fā)送一個(gè)HTTP請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下組成部分：

　　　　報(bào)文頭：常被叫做請(qǐng)求頭，請(qǐng)求頭中存儲(chǔ)的是該請(qǐng)求的一些主要說(shuō)明（自我介紹）。服務(wù)器據(jù)此獲取客戶端的信息。

　　　　　　　　常見(jiàn)的請(qǐng)求頭：

accept:瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，它所支持的數(shù)據(jù)類型

　　　　　　　　Accept-Charset: 瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，它支持哪種字符集
　　　　　　　　Accept-Encoding：瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，支持的壓縮格式
　　　　　　　　Accept-Language：瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，它的語(yǔ)言環(huán)境
　　　　　　　　Host：瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，想訪問(wèn)哪臺(tái)主機(jī)
　　　　　　　　If-Modified-Since: 瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，緩存數(shù)據(jù)的時(shí)間
　　　　　　　　Referer：瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，客戶機(jī)是哪個(gè)頁(yè)面來(lái)的 防盜鏈
　　　　　　　　Connection：瀏覽器通過(guò)這個(gè)頭告訴服務(wù)器，請(qǐng)求完后是斷開(kāi)鏈接還是何持鏈接
　　　　　　　　X-Requested-With: XMLHttpRequest 代表通過(guò)ajax方式進(jìn)行訪問(wèn)

　　　　　　　　User-Agent：請(qǐng)求載體的身份標(biāo)識(shí)

　　　　報(bào)文體：常被叫做請(qǐng)求體，請(qǐng)求體中存儲(chǔ)的是將要傳輸/發(fā)送給服務(wù)器的數(shù)據(jù)信息。

　　7.HTTP之Response：

　　　　服務(wù)器回傳 一個(gè)HTTP響應(yīng)到客戶端的響應(yīng)消息包括以下組成部分：

　　　　狀態(tài)碼：以“清晰明確”的語(yǔ)言告訴客戶端本次請(qǐng)求的處理結(jié)果。

　　　　　　　　HTTP的響應(yīng)狀態(tài)碼由5段組成：?

• • • 　　1xx 消息，一般是告訴客戶端，請(qǐng)求已經(jīng)收到了，正在處理，別急...
    • 　　2xx 處理成功，一般表示：請(qǐng)求收悉、我明白你要的、請(qǐng)求已受理、已經(jīng)處理完成等信息.
    • 　　3xx 重定向到其它地方。它讓客戶端再發(fā)起一個(gè)請(qǐng)求以完成整個(gè)處理。
    • 　　4xx 處理發(fā)生錯(cuò)誤，責(zé)任在客戶端，如客戶端的請(qǐng)求一個(gè)不存在的資源，客戶端未被授權(quán)，禁止訪問(wèn)等。
    • 　　5xx 處理發(fā)生錯(cuò)誤，責(zé)任在服務(wù)端，如服務(wù)端拋出異常，路由出錯(cuò)，HTTP版本不支持等。

　　　　相應(yīng)頭：響應(yīng)的詳情展示

　　　　　　　　常見(jiàn)的相應(yīng)頭信息：

　　　　　　　　　　　　Location: 服務(wù)器通過(guò)這個(gè)頭，來(lái)告訴瀏覽器跳到哪里
　　　　　　　　　　　　Server：服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器服務(wù)器的型號(hào)
　　　　　　　　　　　　Content-Encoding：服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器，數(shù)據(jù)的壓縮格式
　　　　　　　　　　　　Content-Length: 服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器回送數(shù)據(jù)的長(zhǎng)度
　　　　　　　　　　　　Content-Language: 服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器語(yǔ)言環(huán)境
　　　　　　　　　　　　Content-Type：服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器回送數(shù)據(jù)的類型
　　　　　　　　　　　　Refresh：服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器定時(shí)刷新
　　　　　　　　　　　　Content-Disposition: 服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器以下載方式打數(shù)據(jù)
　　　　　　　　　　　　Transfer-Encoding：服務(wù)器通過(guò)這個(gè)頭，告訴瀏覽器數(shù)據(jù)是以分塊方式回送的
　　　　　　　　　　　　Expires: -1 控制瀏覽器不要緩存
　　　　　　　　　　　　Cache-Control: no-cache?
　　　　　　　　　　　　Pragma: no-cache

　　　　相應(yīng)體：根據(jù)客戶端指定的請(qǐng)求信息，發(fā)送給客戶端的指定數(shù)據(jù)

?

二.HTTPS協(xié)議　　　

　　1.官方概念：

　　　　HTTPS (Secure Hypertext Transfer Protocol)安全超文本傳輸協(xié)議，HTTPS是在HTTP上建立SSL加密層，并對(duì)傳輸數(shù)據(jù)進(jìn)行加密，是HTTP協(xié)議的安全版。

　　2.白話概念：

　　　　加密安全版的HTTP協(xié)議。

　　3.HTTPS采用的加密技術(shù)

　　　　3.1 SSL加密技術(shù)

　　　　　　　　SSL采用的加密技術(shù)叫做“共享密鑰加密”，也叫作“對(duì)稱密鑰加密”，這種加密方法是這樣的，比如客戶端向服務(wù)器發(fā)送一條信息，首先客戶端會(huì)采用已知的算法對(duì)信息進(jìn)行加密，比如MD5或者Base64加密，接收端對(duì)加密的信息進(jìn)行解密的時(shí)候需要用到密鑰，中間會(huì)傳遞密鑰，（加密和解密的密鑰是同一個(gè)），密鑰在傳輸中間是被加密的。這種方式看起來(lái)安全，但是仍有潛在的危險(xiǎn)，一旦被竊聽(tīng)，或者信息被挾持，就有可能破解密鑰，而破解其中的信息。因此“共享密鑰加密”這種方式存在安全隱患：

　　　　3.2 非對(duì)稱秘鑰加密技術(shù)

?　　　　　　　　“非對(duì)稱加密”使用的時(shí)候有兩把鎖，一把叫做“私有密鑰”，一把是“公開(kāi)密鑰”，使用非對(duì)象加密的加密方式的時(shí)候，服務(wù)器首先告訴客戶端按照自己給定的公開(kāi)密鑰進(jìn)行加密處理，客戶端按照公開(kāi)密鑰加密以后，服務(wù)器接受到信息再通過(guò)自己的私有密鑰進(jìn)行解密，這樣做的好處就是解密的鑰匙根本就不會(huì)進(jìn)行傳輸，因此也就避免了被挾持的風(fēng)險(xiǎn)。就算公開(kāi)密鑰被竊聽(tīng)者拿到了，它也很難進(jìn)行解密，因?yàn)榻饷苓^(guò)程是對(duì)離散對(duì)數(shù)求值，這可不是輕而易舉就能做到的事。以下是非對(duì)稱加密的原理圖：

　　　　　　但是非對(duì)稱秘鑰加密技術(shù)也存在如下缺點(diǎn)：

　　　　　　　　第一個(gè)是：如何保證接收端向發(fā)送端發(fā)出公開(kāi)秘鑰的時(shí)候，發(fā)送端確保收到的是預(yù)先要發(fā)送的，而不會(huì)被挾持。只要是發(fā)送密鑰，就有可能有被挾持的風(fēng)險(xiǎn)。

　　　　　　　　第二個(gè)是：非對(duì)稱加密的方式效率比較低，它處理起來(lái)更為復(fù)雜，通信過(guò)程中使用就有一定的效率問(wèn)題而影響通信速度

　　4.https的證書機(jī)制

　　　　在上面我們講了非對(duì)稱加密的缺點(diǎn)，其中第一個(gè)就是公鑰很可能存在被挾持的情況，無(wú)法保證客戶端收到的公開(kāi)密鑰就是服務(wù)器發(fā)行的公開(kāi)密鑰。此時(shí)就引出了公開(kāi)密鑰證書機(jī)制。數(shù)字證書認(rèn)證機(jī)構(gòu)是客戶端與服務(wù)器都可信賴的第三方機(jī)構(gòu)。證書的具體傳播過(guò)程如下：

　　　　　　1：服務(wù)器的開(kāi)發(fā)者攜帶公開(kāi)密鑰，向數(shù)字證書認(rèn)證機(jī)構(gòu)提出公開(kāi)密鑰的申請(qǐng)，數(shù)字證書認(rèn)證機(jī)構(gòu)在認(rèn)清申請(qǐng)者的身份，審核通過(guò)以后，會(huì)對(duì)開(kāi)發(fā)者申請(qǐng)的公開(kāi)密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開(kāi)密鑰，并將密鑰放在證書里面，綁定在一起

?

?

? ?

　　　　　　　2：服務(wù)器將這份數(shù)字證書發(fā)送給客戶端，因?yàn)榭蛻舳艘舱J(rèn)可證書機(jī)構(gòu)，客戶端可以通過(guò)數(shù)字證書中的數(shù)字簽名來(lái)驗(yàn)證公鑰的真?zhèn)危瑏?lái)確保服務(wù)器傳過(guò)來(lái)的公開(kāi)密鑰是真實(shí)的。一般情況下，證書的數(shù)字簽名是很難被偽造的，這取決于認(rèn)證機(jī)構(gòu)的公信力。一旦確認(rèn)信息無(wú)誤之后，客戶端就會(huì)通過(guò)公鑰對(duì)報(bào)文進(jìn)行加密發(fā)送，服務(wù)器接收到以后用自己的私鑰進(jìn)行解密。