http & https & http/2 & SPDY & WebSocket

參考文章：

http https ：https://www.jianshu.com/p/d286d097e56b

https & ssl:https://www.jianshu.com/p/29a90d057510?utm_campaign=maleskine&utm_content=note&utm_medium=seo_notes&utm_source=recommendation

證書：http://blog.csdn.net/liweisnake/article/details/40074321

HTTP是什麼

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。
HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

HTTP主要特色

1.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
2.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
3.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
5.支持B/S及C/S模式

HTTP & SPDY & WebSocket
HTTP的不足

HTTP協議通過多年的使用，發現了一些不足，主要是性能方面的，包括：

• HTTP的短鏈接問題，HTTP客戶端和服務器之間的交互是採用請求/應答模式，在客戶端請求時，會創建一個HTTP鏈接，而後發送請求消息，服務端給出應答消息，而後鏈接就關閉了。（後來的HTTP1.1支持持久鏈接）
• 由於TCP鏈接的創建過程是有開銷的，若是使用了SSL/TLS開銷就更大
• 在瀏覽器裏，一個網頁包含許多資源，包括HTML，CSS，JavaScript，圖片等等，這樣在加載一個網頁時要同時打開鏈接到同一服務器的多個鏈接
• HTTP消息頭問題，如今的客戶端會發送大量的HTTP消息頭，因爲一個網頁可能須要50-100個請求，就會有至關大的消息頭的數據量
• HTTP通訊方式問題，HTTP的請求/應答方式的會話都是客戶端發起的，缺少服務器通知客戶端的機制，在須要通知的場景，如聊天室，遊戲，客戶端應用須要不斷地輪詢服務器

    而SPDY和WebSocket是從不一樣的角度來解決這些不足中的一部分。除了這兩個技術，還有其餘技術也在針對這些不足提出改進

SPDY
SPDY的主要目的是減小50%以上的頁面加載時間，可是呢不增長部署的複雜性，不影響客戶端和服務端的Web應用，只須要瀏覽器和Web服務器支持SPDY。主要有如下幾點：

• 多路複用，一個TCP鏈接上同時跑多個HTTP請求。請求可設定優先級
• 去除不須要的HTTP頭，壓縮HTTP頭，以減小須要的網絡帶寬
• 使用了SSL做爲傳輸協議提供數據安全
• 對傳輸的數據使用gzip進行壓縮
• 提供服務方發起通訊，並向客戶端推送數據的機制

實質上，SPDY就是想不影響HTTP語義的狀況下，替換HTTP底層傳輸的協議來加快頁面加載時間。
SPDY的解決辦法就是設計了一個會話層協議--幀協議，解決多路複用，優先級等問題，而後在其上實現了HTTP的語義
WebSocket

WebSocket則提供使用一個TCP鏈接進行雙向通信的機制，包括網絡協議和API，以取代網頁和服務器採用HTTP輪詢進行雙向通信的機制。
本質上來講，WebSocket是不限於HTTP協議的，可是因爲現存大量的HTTP基礎設施，代理，過濾，身份認證等等，WebSocket借用HTTP和HTTPS的端口
因爲使用HTTP的端口，所以TCP鏈接創建後的握手消息是基於HTTP的，由服務器判斷這是一個HTTP協議，仍是WebSocket協議。 WebSocket鏈接除了創建和關閉時的握手，數據傳輸和HTTP沒丁點關係了。WebSocket也有本身一套幀協議。

HTTP/1.X VS HTTP/2

(HTTP/2解決的問題相似SPDY)

是二進制的而非文本的

有別於 HTTP/1.1 中的明文請求，HTTP/2 將一個 TCP 鏈接分爲若干個流 (stream)，每一個流中能夠傳輸若干消息 (message)，每一個消息由若干最小的二進制幀 (frame) 組成。這樣更利於高效地解析，並且不容易出錯，畢竟 HTTP/1.x 的 header 中有空白行、大小寫、換行、空行之類的規定。

是徹底多路複用而非按順序和阻塞的

HTTP/1.x 有一個 head-of-line blocking 的問題，它會讓一個鏈接一次只能發送一個請求。多路複用容許多個請求和響應消息同時發出，甚至能夠混合一個消息的一部分和另外一個消息。

只開一個鏈接用於併發的請求

HTTP/1.x 中爲了加載資源會同時打開多個 TCP 鏈接，每一個鏈接在響應時又都會發送大量數據，存在中間網絡 (intervening network) 緩衝區溢出的危險，致使網絡阻塞和重發 ( retransmits)。並且，使用那麼多的 TCP 鏈接也是一種大量佔用網絡資源的行爲。

壓縮頭部

在大型網站中，一個頁面每每要請求大量資源並獲得相應，算上那些往返的話，那麼頭部就會佔據至關大的開銷，因此壓縮頭部的好處便變得顯而易見了。

容許服務器主動推送資源給客戶端

在 HTTP/1.x 中，當瀏覽器請求了一個頁面，服務器發送了 HTML 頁面的響應，而後服務器須要等待瀏覽器解析了 HTML 文件後再發起嵌入在 HTML 頁面中的多個資源的請求，想一想都以爲慢。而服務器端推送避免了這種往返的延遲，服務器會主動推送它認爲的客戶端會須要緩存的資源。要當心的是，這個功能濫用的話，會損害性能。

URI & URL

URL：(Uniform/Universal Resource Locator 的縮寫，統一資源定位符)。
URI：(Uniform Resource Identifier 的縮寫，統一資源標識符)（表明一種標準）。
URI 屬於 URL 更高層次的抽象，一種字符串文本標準。
就是說，URI 屬於父類，而 URL 屬於 URI 的子類。URL 是 URI 的一個子集。
兩者的區別在於，URI 表示請求服務器的路徑，定義這麼一個資源。而 URL 同時說明要如何訪問這個資源（http://）

HTTP通訊機制是在一次完整的HTTP通訊過程當中，Web瀏覽器與Web服務器之間將完成下列7個步驟：

（1）    創建TCP鏈接
在HTTP工做開始以前，Web瀏覽器首先要經過網絡與Web服務器創建鏈接，該鏈接是經過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，所以Internet又被稱做是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議創建以後才能，才能進行更層協議的鏈接，所以，首先要創建TCP鏈接，通常TCP鏈接的端口號是80
（2）    Web瀏覽器向Web服務器發送請求命令
一旦創建了TCP鏈接，Web瀏覽器就會向Web服務器發送請求命令
例如：GET/sample/hello.jsp HTTP/1.1
（3）    Web瀏覽器發送請求頭信息
瀏覽器發送其請求命令以後，還要以頭信息的形式向Web服務器發送一些別的信息，以後瀏覽器發送了一空白行來通知服務器，它已經結束了該頭信息的發送。
（4）    Web服務器應答
客戶機向服務器發出請求後，服務器會客戶機回送應答，
HTTP/1.1 200 OK
應答的第一部分是協議的版本號和應答狀態碼
（5）    Web服務器發送應答頭信息
正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同應答向用戶發送關於它本身的數據及被請求的文檔。
（6）    Web服務器向瀏覽器發送數據
Web服務器向瀏覽器發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據
（7）    Web服務器關閉TCP鏈接
通常狀況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP鏈接，而後若是瀏覽器或者服務器在其頭信息加入了這行代碼
Connection:keep-alive
TCP鏈接在發送後將仍然保持打開狀態，因而，瀏覽器能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。　　

HTTP請求格式

當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求信息，HTTP請求信息由3部分組成：
   請求方法URI協議/版本
   請求頭(Request Header)
   請求正文

下面是一個HTTP響應的例子：

GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
 
（1）請求方法URI協議/版本
請求的第一行是「方法URL議/版本」：GET/sample.jsp HTTP/1.1
以上代碼中「GET」表明請求方法，「/sample.jsp」表示URI，「HTTP/1.1表明協議和協議的版本。
根據HTTP標準，HTTP請求可使用多種請求方法。例如：HTTP1.1支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中，最經常使用的方法是GET和POST
URL完整地指定了要訪問的網絡資源，一般只要給出相對於服務器的根目錄的相對目錄便可，所以老是以「/」開頭，最後，協議版本聲明瞭通訊過程當中使用HTTP的版本

         GET方法
GET方法是默認的HTTP請求方法，咱們平常用GET方法來提交表單數據，然而用GET方法提交的表單數據只通過了簡單的編碼，同時它將做爲URL的一部分向Web服務器發送，所以，若是使用GET方法來提交表單數據就存在着安全隱患上。例如
Http://127.0.0.1/login.jsp?Name=zhangshi&Age=30&Submit=%cc%E+%BD%BB
從上面的URL請求中，很容易就能夠辯認出表單提交的內容。（？以後的內容）另外因爲GET方法提交的數據是做爲URL請求的一部分因此提交的數據量不能太大
         POST方法
POST方法是GET方法的一個替代方法，它主要是向Web服務器提交表單數據，尤爲是大批量的數據。POST方法克服了GET方法的一些缺點。經過POST方法提交表單數據時，數據不是做爲URL請求的一部分而是做爲標準數據傳送給Web服務器，這就克服了GET方法中的信息沒法保密和數據量過小的缺點。所以，出於安全的考慮以及對用戶隱私的尊重，一般表單提交時採用POST方法。
　　從編程的角度來說，若是用戶經過GET方法提交數據，則數據存放在QUERY＿STRING環境變量中，而POST方法提交的數據則能夠從標準輸入流中獲取。

（2）請求頭(Request Header)

請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭能夠聲明瀏覽器所用的語言，請求正文的長度等。
Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.

（3）請求正文

請求頭和請求正文之間是一個空行，這個行很是重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中能夠包含客戶提交的查詢字符串信息：
username=jinqiao&password=1234
在以上的例子的HTTP請求中，請求的正文只有一行內容。固然，在實際應用中，HTTP請求正文能夠包含更多的內容

HTTP應答格式

協議狀態版本代碼描述
響應頭(Response Header)
響應正文
下面是一個HTTP響應的例子：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112
 
<html> <head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

（1）協議狀態代碼描述HTTP響應的第一行相似於HTTP請求的第一行，它表示通訊所用的協議是HTTP1.1服務器已經成功的處理了客戶端發出的請求（200表示成功）:
HTTP/1.1 200 OK

    HTTP應答碼
　也稱爲狀態碼，它反映了Web服務器處理HTTP請求狀態。HTTP應答碼由3位數字構成，其中首位數字定義了應答碼的類型：
　  1XX－信息類(Information),表示收到Web瀏覽器請求，正在進一步的處理中
　  2XX－成功類（Successful）,表示用戶請求被正確接收，理解和處理例如：200 OK
      3XX-重定向類(Redirection),表示請求沒有成功，客戶必須採起進一步的動做。
      4XX-客戶端錯誤(Client Error)，表示客戶端提交的請求有錯誤 例如：404 NOTFound，意味着請求中所引用的文檔不存在。
      5XX-服務器錯誤(Server Error)表示服務器不能完成對請求的處理：如 500
      對於咱們Web開發人員來講掌握HTTP應答碼有助於提升Web應用程序調試的效率和準確性。

（2）響應頭(Response Header)響應頭也和請求頭同樣包含許多有用的信息，例如服務器類型、日期時間、內容類型和長度等：

Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:13:33 GMT
Content-Type:text/html
Last-Moified:Mon,6 Oct 2003 13:23:42 GMT
Content-Length:112

（3）響應正文響應正文就是服務器返回的HTML頁面：

<html> <head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

HTTP的缺點

1）通訊內容爲明文，即未加密，內容可能會被竊聽

所以，須要對通訊進行加密以防止竊聽。
一種加密方式是將通訊加密。HTTP沒有加密機制，須要配合SSL（安全套接層）或TLS（安全傳輸層協議）來對通訊進行加密。配合SSL使用得HTTP則稱爲HTTPS。另外一種是經過對通訊報文的具體內容進行加密。
雖然咱們能夠對通訊的內容進行加密，但其僅僅是達到讓攻擊者難以破解報文的目的，可是加密後的報文自己仍是可以被截獲。目前獲取報文信息的軟件也有不少，如Sniffer和Wireshark等

2）通訊雙方的身份沒有進行驗證，可能出現假裝身份的狀況

全部人均可以對服務器發起請求

能夠看出，對於客戶端來講，沒法肯定這臺Web服務器是不是「真的」服務器，可能經過了假裝。對於服務器來講，也沒法肯定本身返回的報文是否被真正的客戶端接收到。
此外，服務器的全盤接收的缺點也會被利用來進行DOS攻擊。
所以，以客戶端爲例，客戶端在與服務器通訊以前須要肯定服務器的身份，該身份便是一份證書，該證書有值得信賴的第三方頒發，客戶端確認身份後才進行通訊

3）接受的報文完整性沒法肯定，可能中途被改動
咱們知道，服務器接收到請求後，會進行響應。但服務器和客戶端都沒法知道報文中途的傳輸是否出現了問題。頗有可能在傳輸時被其餘攻擊者進行了篡改，報文完整性遭到破壞

HTTPS是什麼

 

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL代表它使用了HTTPS，但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司進行，提供了身份驗證與加密通信方法，如今它被普遍用於萬維網上安全敏感的通信，例如交易支付方面


SSL會使通訊的效率下降
    通訊速率下降
       HTTPS 除了TCP鏈接，發送請求，響應以外，還須要進行SSL通訊。總體通訊信息量增長。
    加密過程消耗資源
       每一個報文都須要進行加密和解密的運算處理。比起HTTP會消耗更多的服務器資源。
    證書開銷
       若是想要經過HTTPS進行通訊，就必須向認證機構購買證書。

HTTPS和HTTP的區別

1）https協議須要到ca申請證書，通常免費證書不多，須要交費。2）http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議。3）http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。4）http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。