最近不太順,以前學(xué)過(guò)的很多東西都忘記了.這段時(shí)間好好沉淀一下,把看過(guò)的基礎(chǔ)知識(shí)做一個(gè)大匯總.
本文起了一個(gè)開(kāi)頭,業(yè)務(wù)來(lái)了,忙的不可開(kāi)交,幾天之后繼續(xù)來(lái)寫,發(fā)現(xiàn)之前看過(guò)的都忘的差不多,剛好又在新春之際,提前祝大家新年快樂(lè).
下面開(kāi)始我們的正文吧.
先從http開(kāi)始吧!

http大家耳熟能詳,用的也比較多.本文將從版本的角度對(duì)比一下各個(gè)版本(http1.0, http1.1, http2.0, https)的不同和區(qū)別.
? ?1. http1.0?
????http1.0在1996年就出來(lái)了,最初的目的是為了一種發(fā)布和接受html的方法,從www 服務(wù)器傳輸超文本到瀏覽器的傳輸協(xié)議.默認(rèn)端口80.
? ? http是基于tcp的可靠傳輸.HTTP使用TCP而不是UDP的主要原因在于 TCP 是可靠鏈接,每次鏈接之前都要進(jìn)行三次握手, 可以保證數(shù)據(jù)的完整和正確,而UDP?是不可靠的,只管自己發(fā) 不管對(duì)方收.所以常用的網(wǎng)頁(yè)都是基于tcp,而QQ 等實(shí)時(shí)通訊工具?和視頻等下載傳輸使用?UDP.
? ? 既然http是基于TCP的,所以大部分http的優(yōu)化手段和技巧都是基于tcp的特性.在http1.0最大的一個(gè)問(wèn)題就是鏈接無(wú)法復(fù)用,每次傳輸都必須重新來(lái)一次三次握手,?TCP建立連接時(shí)三次握手有1.5個(gè)RTT（round-trip time）的延遲,并且還有慢啟動(dòng)的特性,所以我們前端在優(yōu)化又一條就是減少請(qǐng)求數(shù). 因?yàn)樯厦娴娜秉c(diǎn)出現(xiàn)了http1.1.

? ? 2.http1.1
? ? 1. http1.1在1.0后的半年就出現(xiàn)了,也是現(xiàn)行使用最廣泛的協(xié)議.http1.1繼承了1.0的優(yōu)點(diǎn)做了大量的改動(dòng).最主要的一個(gè)就是默認(rèn)keep-alive長(zhǎng)鏈接,因?yàn)槊看挝帐侄紟?lái)巨大的開(kāi)銷,長(zhǎng)連接（PersistentConnection) 允許用戶在一次tcp上面發(fā)送多個(gè)http,減少了大量不必要的開(kāi)銷.

? ? 2. 增加了host字段,在http1.0中默認(rèn)每個(gè)服務(wù)器只有一個(gè)ip地址,所以請(qǐng)求中不帶host,但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個(gè)IP地址。所以現(xiàn)在全都請(qǐng)求都需要設(shè)置一個(gè)host.

3.cache 緩存

在HTTP/1.0中，使用Expire頭域來(lái)判斷資源的fresh或stale，并使用條件請(qǐng)求（conditional request）來(lái)判斷資源是否仍有效。例如，cache服務(wù)器通過(guò)If-Modified-Since頭域向服務(wù)器驗(yàn)證資源的Last-Modefied頭域是否有更新，源服務(wù)器可能返回304（Not Modified），則表明該對(duì)象仍有效；也可能返回200（OK）替換請(qǐng)求的Cache對(duì)象。

此外，HTTP/1.0中還定義了Pragma:no-cache頭域，客戶端使用該頭域說(shuō)明請(qǐng)求資源不能從cache中獲取，而必須回源獲取。

HTTP/1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變?yōu)閟tale對(duì)象，cache不需要直接拋棄stale對(duì)象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。

HTTP/1.0中，If-Modified-Since頭域使用的是絕對(duì)時(shí)間戳，精確到秒，但使用絕對(duì)時(shí)間會(huì)帶來(lái)不同機(jī)器上的時(shí)鐘同步問(wèn)題。而HTTP/1.1中引入了一個(gè)ETag頭域用于重激活機(jī)制，它的值entity tag可以用來(lái)唯一的描述一個(gè)資源。請(qǐng)求消息中可以使用If-None-Match頭域來(lái)匹配資源的entitytag是否有變化。

為了使caching機(jī)制更加靈活，HTTP/1.1增加了Cache-Control頭域（請(qǐng)求消息和響應(yīng)消息都可使用），它支持一個(gè)可擴(kuò)展的指令子集：例如max-age指令支持相對(duì)時(shí)間戳；private和no-store指令禁止對(duì)象被緩存；no-transform阻止Proxy進(jìn)行任何改變響應(yīng)的行為。

Cache使用關(guān)鍵字索引在磁盤中緩存的對(duì)象，在HTTP/1.0中使用資源的URL作為關(guān)鍵字。但可能存在不同的資源基于同一個(gè)URL的情況，要區(qū)別它們還需要客戶端提供更多的信息，如Accept-Language和Accept-Charset頭域。為了支持這種內(nèi)容協(xié)商機(jī)制(content negotiation mechanism)，HTTP/1.1在響應(yīng)消息中引入了Vary頭域，該頭域列出了請(qǐng)求消息中需要包含哪些頭域用于內(nèi)容協(xié)商。

4.Chunked transfer-coding ,HTTP應(yīng)答消息中發(fā)送的數(shù)據(jù)是整個(gè)發(fā)送的，Content-Length消息頭字段表示數(shù)據(jù)的長(zhǎng)度。數(shù)據(jù)的長(zhǎng)度很重要，因?yàn)榭蛻舳诵枰滥睦锸菓?yīng)答消息的結(jié)束，以及后續(xù)應(yīng)答消息的開(kāi)始。然而，使用分塊傳輸編碼，數(shù)據(jù)分解成一系列數(shù)據(jù)塊，并以一個(gè)或多個(gè)塊發(fā)送

http2.0

? ? 1: 多路傳輸:HTTP/1.x 有個(gè)問(wèn)題叫線端阻塞(head-of-line blocking), 它是指一個(gè)連接(connection)一次只提交一個(gè)請(qǐng)求的效率比較高, 多了就會(huì)變慢。 HTTP/1.1 試過(guò)用流水線(pipelining)來(lái)解決這個(gè)問(wèn)題, 但是效果并不理想(數(shù)據(jù)量較大或者速度較慢的響應(yīng), 會(huì)阻礙排在他后面的請(qǐng)求). 此外, 由于網(wǎng)絡(luò)媒介(intermediary )和服務(wù)器不能很好的支持流水線, 導(dǎo)致部署起來(lái)困難重重。而多路傳輸(Multiplexing)能很好的解決這些問(wèn)題, 因?yàn)樗芡瑫r(shí)處理多個(gè)消息的請(qǐng)求和響應(yīng); 甚至可以在傳輸過(guò)程中將一個(gè)消息跟另外一個(gè)摻雜在一起。所以客戶端只需要一個(gè)連接就能加載一個(gè)頁(yè)面。

2.spdy 二進(jìn)制傳輸
在應(yīng)用層與傳輸層之間增加一個(gè)二進(jìn)制分幀層，以此達(dá)到“在不改動(dòng)HTTP的語(yǔ)義，HTTP 方法、狀態(tài)碼、URI及首部字段的情況下，突破HTTP1.1的性能限制，改進(jìn)傳輸性能，實(shí)現(xiàn)低延遲和高吞吐量。”在二進(jìn)制分幀層上，HTTP2.0會(huì)將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶?并對(duì)它們采用二進(jìn)制格式的編碼，其中HTTP1.x的首部信息會(huì)被封裝到Headers幀，而我們的request body則封裝到Data幀里面。

3.header 壓縮.
http1.x的header很多時(shí)候都是重復(fù)多余的。選擇合適的壓縮算法可以減小包的大小和數(shù)量。SPDY對(duì)header的壓縮率可以達(dá)到80%以上，低帶寬環(huán)境下效果很大。

4.服務(wù)器推送.
在 HTTP2.0中，服務(wù)器推送是指在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。如果一個(gè)請(qǐng)求是由你的主頁(yè)發(fā)起的，服務(wù)器很可能響應(yīng)主頁(yè)內(nèi)容、logo以及樣式表，因?yàn)樗揽蛻舳藭?huì)用到這些東西。這相當(dāng)于在一個(gè) HTML 文檔內(nèi)集合了所有的資源，不過(guò)與之相比，服務(wù)器推送有一個(gè)很大的優(yōu)勢(shì)：可以緩存！

對(duì)優(yōu)化的影響：
因?yàn)椤八械腍TTP2.0的請(qǐng)求都在一個(gè)TCP鏈接上”，“資源合并減少請(qǐng)求”，比如CSS Sprites,多個(gè)JS文件、CSS文件合并等手段沒(méi)有效果，或者說(shuō)沒(méi)有必要。

因?yàn)椤岸嗦窂?fù)用”，采用“cdn1.cn,cdn2.cn,cdn3.cn，打開(kāi)多個(gè)TCP會(huì)話，突破瀏覽器對(duì)同一域名的鏈接數(shù)的限制”的手段是沒(méi)有必要的。因?yàn)橐驗(yàn)橘Y源都是并行交錯(cuò)發(fā)送，且沒(méi)有限制，不需要額外的多域名并行下載。

因?yàn)椤胺?wù)器推送”，內(nèi)嵌資源的優(yōu)化手段也變得沒(méi)有意義了。而且使用服務(wù)器推送的資源的方式更加高效，因?yàn)榭蛻舳诉€可以緩存起來(lái)，甚至可以由不同的頁(yè)面共享（依舊遵循同源策略）

https
https? 比較復(fù)雜 我盡量用自己的理解直白的說(shuō)出來(lái).

https 中的s 指的是 TSL/SSL , 在http 和tcp 之際加了一個(gè)加密層.

網(wǎng)上有很多對(duì)于https 的原理有大量的描述,我希望自己能用簡(jiǎn)潔直白的語(yǔ)言描述 出來(lái):

https 在請(qǐng)求的時(shí)候,服務(wù)端會(huì)返回一個(gè)ssl證書,
? ? 第一:證書中的信息使用了hash加密(防止篡改),通過(guò)證書拿到公鑰(非對(duì)稱加密)
? ? 第二: 使用公鑰對(duì)會(huì)話秘匙加密( 對(duì)稱加密)
? ? 第三:客戶端服務(wù)器雙方都有會(huì)話密鑰，之后傳輸?shù)乃蠬ttp數(shù)據(jù)，都通過(guò)會(huì)話密鑰加密。
上面只是簡(jiǎn)單的總結(jié),方便記憶.
最后在簡(jiǎn)單的總結(jié)一下http1.0? 》 http1.1 》 http2.0 中主要的區(qū)別區(qū)別點(diǎn).

http1.0因?yàn)檎?qǐng)求無(wú)法復(fù)用的問(wèn)題,
http1.1就有了keep-alive解決復(fù)用,同時(shí)增加了host字段(多host共享同一ip)和cache緩存更多字段.但是在http1.1中有頭部阻塞的問(wèn)題
所以在http2.0中出現(xiàn)了多路傳輸,同時(shí)使用header壓縮和二進(jìn)制傳輸進(jìn)行優(yōu)化.