一、HTTP1.0和HTTP1.1的區(qū)別
1：長連接
HTTP是基于TCP/IP協(xié)議的，創(chuàng)建一個TCP連接是需要經(jīng)過三次握手的,有一定的開銷，如果每次通訊都要重新建立連接的話，對性能有影響。因此最好能維持一個長連接，可以用個長連接來發(fā)多個請求。
HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認(rèn)開啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP1.0每次請求都要創(chuàng)建連接的缺點(diǎn)，HTTP1.1默認(rèn)支持長連接。
2：節(jié)約帶寬
HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
另外HTTP還支持傳送內(nèi)容的一部分。這樣當(dāng)客戶端已經(jīng)有一部分的資源后，只需要跟服務(wù)器請求另外的部分資源即可。這是支持文件斷點(diǎn)續(xù)傳的基礎(chǔ)。
3：Host域
在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
4:?緩存處理
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
5：錯誤通知的管理
在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。
二、HTTP2.0與HTTP1.1的區(qū)別
1：與HTTP 1.1相比，主要區(qū)別包括
HTTP/2采用二進(jìn)制格式而非文本格式
HTTP/2是完全多路復(fù)用的，而非有序并阻塞的——只需一個連接即可實(shí)現(xiàn)并行
使用報頭壓縮，HTTP/2降低了開銷
HTTP/2讓服務(wù)器可以將響應(yīng)主動“推送”到客戶端緩存中
2、HTTP/2為什么是二進(jìn)制？
比起像HTTP/1.x這樣的文本協(xié)議，二進(jìn)制協(xié)議解析起來更高效、“線上”更緊湊，更重要的是錯誤更少。
3、為什么 HTTP/2 需要多路傳輸?
HTTP/1.x 有個問題叫線端阻塞(head-of-line blocking), 它是指一個連接(connection)一次只提交一個請求的效率比較高, 多了就會變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個問題, 但是效果并不理想(數(shù)據(jù)量較大或者速度較慢的響應(yīng), 會阻礙排在他后面的請求). 此外, 由于網(wǎng)絡(luò)媒介(intermediary )和服務(wù)器不能很好的支持流水線, 導(dǎo)致部署起來困難重重。而多路傳輸(Multiplexing)能很好的解決這些問題, 因?yàn)樗芡瑫r處理多個消息的請求和響應(yīng); 甚至可以在傳輸過程中將一個消息跟另外一個摻雜在一起。所以客戶端只需要一個連接就能加載一個頁面。
4、消息頭為什么需要壓縮?
假定一個頁面有80個資源需要加載（這個數(shù)量對于今天的Web而言還是挺保守的）, 而每一次請求都有1400字節(jié)的消息頭（著同樣也并不少見，因?yàn)镃ookie和引用等東西的存在）, 至少要7到8個來回去“在線”獲得這些消息頭。這還不包括響應(yīng)時間——那只是從客戶端那里獲取到它們所花的時間而已。這全都由于TCP的慢啟動機(jī)制，它會基于對已知有多少個包，來確定還要來回去獲取哪些包 – 這很明顯的限制了最初的幾個來回可以發(fā)送的數(shù)據(jù)包的數(shù)量。相比之下，即使是頭部輕微的壓縮也可以是讓那些請求只需一個來回就能搞定——有時候甚至一個包就可以了。這種開銷是可以被節(jié)省下來的，特別是當(dāng)你考慮移動客戶端應(yīng)用的時候，即使是良好條件下，一般也會看到幾百毫秒的來回延遲。
5、服務(wù)器推送的好處是什么？
當(dāng)瀏覽器請求一個網(wǎng)頁時，服務(wù)器將會發(fā)回HTML，在服務(wù)器開始發(fā)送JavaScript、圖片和CSS前，服務(wù)器需要等待瀏覽器解析HTML和發(fā)送所有內(nèi)嵌資源的請求。服務(wù)器推送服務(wù)通過“推送”那些它認(rèn)為客戶端將會需要的內(nèi)容到客戶端的緩存中，以此來避免往返的延遲。
