整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
題，要實(shí)現(xiàn)樹葉在風(fēng)中搖擺的動(dòng)畫，首先準(zhǔn)備主體：樹葉。
這里準(zhǔn)備了兩張矢量的高清版 SVG 各式的不同種類的樹葉。
首先我們使用 img 標(biāo)簽來在網(wǎng)頁中顯示樹葉，然后給它一個(gè)名為 leaf 的類，好給它附加樣式。
<img class="leaf" src="/blog/virtual_safari_leaf.svg" alt="Leaf" />接下來就是編寫 CSS 動(dòng)畫代碼，這里利用了 tranform 屬性中的兩個(gè)變換，skew 將元素在二維平面上傾斜角度進(jìn)行拉伸，rotate 以中心為坐標(biāo)軸進(jìn)行旋轉(zhuǎn)。
.leaf {
transform: scale(0.8);
animation: leftRuffle 3s infinite alternate;
}
@keyframes leftRuffle {
50% {
transform: scale(0.8) skew(5deg) rotate(-5deg);
}
100% {
transform: scale(0.8) skew(0) rotate(0);
}
}我們先讓第一個(gè)樹葉動(dòng)起來
第二個(gè)樹葉我們將它左右翻轉(zhuǎn)下，利用 scaleX(-1)，然后同理
.leaf {
transform: scale(0.7) scaleX(-1);
animation: rightRuffle 3s infinite alternate;
}
@keyframes rightRuffle {
0% {
transform: scale(0.7) scalex(-1) skew(0) rotate(0);
}
50% {
transform: scale(0.7) scalex(-1) skew(5deg) rotate(-5deg);
}
100% {
transform: scale(0.7) scalex(-1) skew(0) rotate(0);
}
}動(dòng)是動(dòng)起來了，可單獨(dú)看是否覺得有點(diǎn)奇怪。
我們給它增加一個(gè)場景：
通常這種大樹葉的綠植要么生長在熱帶雨林，要么被我們放在室內(nèi)當(dāng)做風(fēng)景或者背景。
原文鏈接：https://juejin.cn/post/7320426329164496935
http0.9流程：
客戶端，構(gòu)建請求，通過DNS查詢IP地址，三次握手建立TCP連接，客戶端發(fā)起請求，服務(wù)器響應(yīng)，四次揮手，斷開TCP連接。（與服務(wù)器只有一個(gè)來回）
http1.0流程：
客戶端，構(gòu)建請求，通過DNS查詢IP地址，三次握手建立TCP連接，客戶端發(fā)起請求，服務(wù)器響應(yīng)，四次揮手，斷開TCP連接。（與服務(wù)器有兩個(gè)來回）
因?yàn)椴蛔闳毕荩陀辛薶ttp1.1。
http1.1中瀏覽器再也不用為每個(gè)請求重新發(fā)起TCP連接了，增加內(nèi)容有：緩存相關(guān)首部的擴(kuò)展，OPTIONS方法，Upgrade首部，Range請求，壓縮和傳輸編碼，管道化等。但還是滿足不了現(xiàn)在的web發(fā)展需求，so，就有了http.2版本。
http2解決了（管道化特性可以讓客戶端一次發(fā)送所有的請求，但是有些問題阻礙了管道化的發(fā)展，即使某個(gè)請求花了很長時(shí)間，那么隊(duì)頭阻塞會(huì)影響其他請求。）http中的隊(duì)頭阻塞問題。
使用http2會(huì)比http1.1在使用TCP時(shí)，用戶體驗(yàn)的感知多數(shù)延遲的效果有了量化的改善，以及提升了TCP連接的利用率（并行的實(shí)現(xiàn)機(jī)制不依賴與服務(wù)器建立多個(gè)連接）
所以需要學(xué)習(xí)http2，了解更過的內(nèi)容來掌握計(jì)算機(jī)網(wǎng)絡(luò)。
對于http2，你可以來運(yùn)行一個(gè)http2的服務(wù)器，獲取并安裝一個(gè)http2的web服務(wù)器，下載并安裝一張TLS證書，讓瀏覽器和服務(wù)器通過http2來連接。（從數(shù)字證書認(rèn)證機(jī)構(gòu)申請一張證書）。
了解http2的協(xié)議，先讓我們了解一下web頁面的請求，就是用戶在瀏覽器中呈現(xiàn)的效果，發(fā)生了些什么呢？
資源獲取的步驟：
把待請求URL放入隊(duì)列，判斷URL是否已在請求隊(duì)列，否的話就結(jié)束，是的話就判斷請求域名是否DNS緩存中，沒有的話就解析域名，有的話就到指定域名的TCP連接是否開啟，沒有的話就開啟TCP連接，進(jìn)行HTTPS請求，初始化并完成TLS協(xié)議握手，向頁面對應(yīng)的URL發(fā)送請求。
接收響應(yīng)以及頁面渲染步驟：
接收請求，判斷是否HTML頁面，是就解析HTML，對頁面引用資源排優(yōu)先級，添加引用資源到請求隊(duì)列。（如果頁面上的關(guān)鍵資源已經(jīng)接收到，就開始渲染頁面），判斷是否有還要繼續(xù)接收資源，繼續(xù)解析渲染，直到結(jié)束。
第一種GET方法：發(fā)送一個(gè)請求來獲取服務(wù)器上的某一些資源。
第二種POST方法：向URL指定的資源提交數(shù)據(jù)或附加新的數(shù)據(jù)。
第三種PUT方法：跟POST方法一樣，可以向服務(wù)器提交數(shù)據(jù)，但是它們之間也所有不同，PUT指定了資源在服務(wù)器的位置，而POST沒有哦。
第四種HEAD方法：指請求頁面的首部。
第五種DELETE方法：刪除服務(wù)器上的某資源。
第六種OPTIONS方法：它用于獲取當(dāng)前URL所支持的方法，如果請求成功，在Allow的頭包含類似GET,POST等的信息。
第七種TARCE方法：用于激發(fā)一個(gè)遠(yuǎn)程的，應(yīng)用層的請求消息回路。
第八種CONNECT方法：把請求連接轉(zhuǎn)換到TCP/TP通道。
簡單說說，瀏覽器根據(jù)請求的url交給dns域名解析，查找真正的ip地址，向服務(wù)器發(fā)起請求；服務(wù)器交給后臺(tái)處理后，返回?cái)?shù)據(jù)，瀏覽器會(huì)接收到文件數(shù)據(jù)，比如，html,js，css，圖像等；然后瀏覽器會(huì)對加載到的資源進(jìn)行語法解析，建立相應(yīng)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)；載入解析到的資源文件，渲染頁面，完成顯示頁面效果。
不夠清楚明白碼？
那就再次詳細(xì)一下，咳咳，從瀏覽器接收url，開始進(jìn)行網(wǎng)絡(luò)請求線程，發(fā)出一個(gè)完整的HTTP請求，從服務(wù)器端接收請求到對應(yīng)的后臺(tái)接收到請求，然后是后臺(tái)和前臺(tái)的http交互；其中的緩存問題（http的緩存），瀏覽器接收到http數(shù)據(jù)包后的解析流程，css的可視化格式模型，js引擎解析過程等；其他呈現(xiàn)頁面效果。
：這里就需要你對瀏覽器內(nèi)核的理解：其中主要的渲染引擎和JS引擎，這里了解一下你對瀏覽器內(nèi)核的理解。
瀏覽器的內(nèi)核的不同對于網(wǎng)頁的語法解釋會(huì)有不同，所以渲染的效果也不相同。其實(shí)最開始渲染引擎和JS引擎是沒有區(qū)分明確的，不過后來JS引擎越來越獨(dú)立，so，內(nèi)核就傾向于渲染引擎。
對于資源請求/獲取,資源響應(yīng)/頁面渲染，會(huì)給網(wǎng)絡(luò)帶寬和設(shè)備資源帶來壓力，這個(gè)時(shí)候就會(huì)考慮到web的性能優(yōu)化。
其中里面的性能關(guān)鍵：
什么是數(shù)據(jù)包 數(shù)據(jù)包（IP數(shù)據(jù)包），指封裝在固定結(jié)構(gòu)的一系列字節(jié)，它定義了數(shù)據(jù)包的長度，傳輸?shù)募?xì)節(jié)，以及其他與TCP相關(guān)的信息。
延遲：指IP數(shù)據(jù)包從一個(gè)網(wǎng)絡(luò)端點(diǎn)到另一個(gè)網(wǎng)絡(luò)端點(diǎn)所花費(fèi)的時(shí)間。（所花費(fèi)時(shí)間在于往返時(shí)延，是延遲的時(shí)間的兩倍）
帶寬：只要帶寬沒有飽和，兩個(gè)網(wǎng)絡(luò)端點(diǎn)的連接會(huì)一次處理盡可能多的數(shù)據(jù)量（所以帶寬可能會(huì)成為性能的瓶頸）
建立連接時(shí)間：在客戶端和服務(wù)器之間建立連接往返數(shù)據(jù)（三次握手）
TCP三次握手過程：客戶端向服務(wù)器發(fā)起一個(gè)SYN包，服務(wù)器端返回對應(yīng)的SYN的ACK響應(yīng)以及新的SYN包，然后客戶端返回對應(yīng)的ACK。（在客戶端和服務(wù)器之間建立正常的TCP網(wǎng)絡(luò)連接時(shí)，客戶端首先發(fā)出一個(gè)SYN消息，服務(wù)器使用SYN+ACK應(yīng)答表示接收了這個(gè)消息，最后客戶端再以ACK消息響應(yīng)。）
SYN是同步序列編號(hào)，是TCP/IP建立連接時(shí)使用的握手信息。ACK是確認(rèn)字符，在數(shù)據(jù)通信中，接收站發(fā)給發(fā)送站的一種傳輸類控制字符。表示發(fā)來的數(shù)據(jù)已確認(rèn)接收無誤。在TCP/IP協(xié)議中，如果接收方成功的接收到數(shù)據(jù)，那么會(huì)回復(fù)一個(gè)ACK數(shù)據(jù)。通過ACK信號(hào)有自己固定的格式，長度大小，由接收方回復(fù)給發(fā)送方。
詳解三次握手：
第一次握手，建立連接時(shí)，客戶端發(fā)送SYN包到服務(wù)器，并進(jìn)入SYN_SENT狀態(tài)，等待服務(wù)器確認(rèn)，其中SYN就是同步序列編號(hào)。
第二次握手，服務(wù)器收到SYN包，必須確認(rèn)客戶的SYN，同時(shí)自己也發(fā)送一個(gè)SYN包，即是SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)。
第三次握手，客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。
完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。
TLS協(xié)商時(shí)間（TLS會(huì)造成額外的往返傳輸）
除了網(wǎng)絡(luò)，還有頁面內(nèi)容本身或服務(wù)器性能，如首字節(jié)時(shí)間TTFB，內(nèi)容下載時(shí)間，開始渲染時(shí)間，文檔加載完成的時(shí)間等。
那么什么是TTFB，它是指客戶端從開始定位到web頁面，直接收到主體頁面響應(yīng)的第一字節(jié)所耗費(fèi)的時(shí)間。它是測量：從瀏覽器發(fā)起請求至收到其第一字節(jié)之間的耗時(shí)。
內(nèi)容下載時(shí)間是等同于被請求資源的最后字節(jié)到達(dá)時(shí)間。
開始渲染時(shí)間，從客戶看到空白頁面的時(shí)長。
優(yōu)化技術(shù)：
對于http1的問題，迎來了http2。其中http1的問題：
隊(duì)頭阻塞，大多數(shù)情況下，瀏覽器會(huì)希望同時(shí)獲取許多資源，但http1未提供機(jī)制來同時(shí)請求這些資源，如果僅是使用一個(gè)連接，需要發(fā)起請求，等待響應(yīng)，然后才能發(fā)起下一個(gè)請求。
在http1中要給特性為管道化，可以允許一次發(fā)送一組請求，但是需要按照發(fā)送順序依次接收響應(yīng)。所以在請求應(yīng)答過程中，如發(fā)生什么情況，剩下的工作都會(huì)被阻塞，這就是“隊(duì)頭阻塞”（阻塞在那次請求應(yīng)答發(fā)生錯(cuò)誤），阻礙網(wǎng)絡(luò)傳輸和web頁面的渲染，指導(dǎo)失去響應(yīng)。
低效的TCP利用，TCP協(xié)議作為最可靠的協(xié)議之一，其核心是擁塞窗口。
擁塞窗口，是衛(wèi)星通信在因特網(wǎng)中防止通信擁塞的一種措施，它是在發(fā)端采用了一種“擁塞避免”算法和“慢速啟動(dòng)”算法相結(jié)合的機(jī)制。“擁塞窗口”就是“擁塞避免”的窗口，它是一個(gè)裝在發(fā)送端的可滑動(dòng)窗口，窗口的大小是不超過接收端確認(rèn)通知的窗口。
擁塞窗口指在接收方確認(rèn)數(shù)據(jù)包之前，發(fā)送方可以發(fā)送的TCP包的數(shù)據(jù)。（如擁塞窗口指定為1的情況，那么發(fā)送方就發(fā)出1個(gè)數(shù)據(jù)包之后，只有接收方確認(rèn)了那個(gè)發(fā)出的數(shù)據(jù)包，才能發(fā)送下一個(gè)）
擁塞控制能防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，用于避免網(wǎng)絡(luò)過載，TCP中可以通過慢啟動(dòng)探索當(dāng)前連接對應(yīng)擁塞窗口的合適大小。即發(fā)送者發(fā)送數(shù)據(jù)的時(shí)候并非一開始注入大量數(shù)據(jù)到網(wǎng)絡(luò)中，而是發(fā)送一個(gè)數(shù)據(jù)包進(jìn)行測試，當(dāng)?shù)玫酱_認(rèn)回復(fù)后，額外發(fā)送一個(gè)未確認(rèn)包。
這意味著得到一個(gè)確認(rèn)回復(fù)，可以發(fā)送兩個(gè)數(shù)據(jù)包，得到兩個(gè)確認(rèn)回復(fù)，可以發(fā)送四個(gè)數(shù)據(jù)包，以幾何形式增長很快到達(dá)協(xié)議規(guī)定的擁塞窗口大小（發(fā)包數(shù)上限），這時(shí)候連接進(jìn)入擁塞避免階段，這種機(jī)制需要往返幾次才能得知最佳擁塞窗口大小，但往返幾次所需的時(shí)間成本不可忽略。
tcp中的慢啟動(dòng)概念，是用來探索當(dāng)前連接對應(yīng)擁塞窗口的合適大小。用來弄清楚新連接當(dāng)前的網(wǎng)絡(luò)情況。“慢速啟動(dòng)”是在連接建立后，每收到一個(gè)來自收端的確認(rèn)，就控制窗口增加一個(gè)段值大小，當(dāng)窗口值達(dá)到“慢速啟動(dòng)”的限值后，慢速啟動(dòng)便停止工作，避免了網(wǎng)絡(luò)發(fā)生擁塞。
TCP傳輸控制協(xié)議的設(shè)計(jì)思路是，對假設(shè)情況很保守情況下，能夠公平對待同一網(wǎng)絡(luò)的不同流量的應(yīng)用，它的避免擁塞機(jī)制被設(shè)計(jì)城即使在最差的網(wǎng)絡(luò)情況下也可以起作用。
臃腫的消息首部，HTTP/1.1能壓縮請求內(nèi)容，但是消息首部卻不能壓縮。它可能占據(jù)請求的絕大部分（也可能是全部）也是比較常見了。（在這里如果能壓縮請求首部，把請求變得更小，就能夠緩解帶寬壓力了，降低系統(tǒng)的總負(fù)載）
受限的優(yōu)先級設(shè)置，即如果瀏覽器針對指定域名開啟多個(gè)socket請求，若web頁面某些資源會(huì)比另外一些資源重要，會(huì)加重資源的排隊(duì)效應(yīng)，會(huì)延遲請求其他的資源，優(yōu)先級高的資源先獲取，優(yōu)先級低的資源會(huì)在資源高的資源處理完成，（在處理過程中，瀏覽器不會(huì)發(fā)起新的資源請求）等待高的完成后再發(fā)起請求，(這就會(huì)讓總的頁面下載時(shí)間延長)。
在請求優(yōu)先級高的資源的時(shí)間區(qū)間內(nèi)瀏覽器并不會(huì)發(fā)起優(yōu)先級較低的新請求
小結(jié)：HTTP1.1慢啟動(dòng)影響資源首次加載速度，TCP建立連接后，會(huì)開始請求傳輸，開始比較慢，然后不斷加快，為了防止出現(xiàn)網(wǎng)絡(luò)擁堵，會(huì)讓頁面的首次渲染時(shí)間變長。開始多個(gè)tcp，如出現(xiàn)網(wǎng)絡(luò)下降，無法識(shí)別資源的優(yōu)先級，會(huì)出現(xiàn)靜態(tài)問題。
數(shù)據(jù)壓縮，在瀏覽器中發(fā)送請求時(shí)會(huì)帶著Content-Encoding: gzip，里面時(shí)瀏覽器支持的壓縮格式列表，有多種如，gzip，deflate，br等。這樣服務(wù)器就可以從中選擇一個(gè)壓縮算法，放進(jìn)Content-Encoding響應(yīng)頭里，再把原數(shù)據(jù)壓縮后發(fā)給瀏覽器。
分塊傳輸，就是將傳輸?shù)奈募纸獬啥鄠€(gè)小塊，然后分發(fā)給瀏覽器，瀏覽器收到后再重新組裝復(fù)原。
每個(gè)分開包含兩個(gè)部分，分塊長度和分塊數(shù)據(jù)（長度頭和數(shù)據(jù)塊），長度頭以CRLF結(jié)尾的一行明文，數(shù)據(jù)塊緊跟在長度頭后面，也是用CRLF結(jié)尾，最后用一個(gè)長度為0的塊表示結(jié)束。
在響應(yīng)報(bào)文里用頭字段Transfer-Encoding:chunked表示報(bào)文里的body部分不是一次性發(fā)送過來的，而是分成了許多塊逐個(gè)發(fā)送的。
在Transfer-Encoding：chunked和Content-Length中，這兩個(gè)字段是互斥的。
一個(gè)響應(yīng)報(bào)文的傳輸長度要么已知，要么長度未知（chunked）。
Content-Length: 299
斷點(diǎn)續(xù)傳
要實(shí)現(xiàn)該功能需要制定下載的實(shí)體范圍，這種制定范圍發(fā)送請求叫做范圍請求。
Accept-Ranges：服務(wù)器使用http響應(yīng)頭Accept-Ranges標(biāo)識(shí)自身支持范圍請求，字段的具體值用于定義范圍請求的單位。
語法
Accept-Ranges: bytes,范圍請求的單位是 bytes （字節(jié)）
Accept-Ranges: none,不支持任何范圍請求單位范圍請求時(shí)用于不需要全部數(shù)據(jù)，只需要其中的部分請求時(shí)，可以使用范圍請求，允許客戶端在請求頭里使用專用字段來表示只獲取文件的一部分。
Range的格式，請求頭Range是HTTP范圍請求的專用字段，格式是“bytes=x-y”,以字節(jié)為單位的數(shù)據(jù)范圍。
示例：
執(zhí)行范圍時(shí)會(huì)使用頭部字段 Range 來指定資源 byte 的范圍。
Range格式：
5001-10000字節(jié)
Range : byte = 5001-10000
5000之后的
Range : byte = 5001-
0-3000字節(jié)，5001-10000字節(jié)
Range : byte=-3000,5001-10000
上圖表示服務(wù)器收到Range字段后，檢測范圍合法性，范圍越界，就會(huì)返回狀態(tài)碼416，如你的文件只有1000個(gè)字節(jié)，但請求范圍在20000-3000，就會(huì)導(dǎo)致這個(gè)狀態(tài)碼的出現(xiàn)。
如果成功讀取文件，范圍正確，返回狀態(tài)碼“206”。服務(wù)器要添加一個(gè)響應(yīng)頭字段Content-Range,告訴片段的實(shí)際偏移量和資源的總大小。
最后是發(fā)送數(shù)據(jù)，直接把片段用TCP發(fā)給客戶端，一個(gè)范圍請求就算是處理完了。
格式是“bytes x-y/length”,與Range頭區(qū)別在沒有“=”
Content-Range: bytes 0-4395719/4395720
多端數(shù)據(jù)，就是在Range頭里使用多個(gè)“x-y"，一次性獲取多個(gè)片段數(shù)據(jù)。使用一種特殊的MIME類型：“multipart/byteranges”，用來表示響應(yīng)報(bào)文包含了多個(gè)范圍時(shí)使用。多種范圍請求 響應(yīng)會(huì)在頭部 Content-Type 表明 multipart-byteranges。
多段數(shù)據(jù)圖：分隔標(biāo)記boundary來區(qū)分不同的分段
存儲(chǔ)的大小
cookie的數(shù)據(jù)大小不能超過4k；sessionStorage和localStorage雖然也有存儲(chǔ)大小的限制，但比cookie大得多，可以達(dá)到5M或者更大。
有限期時(shí)間
因?yàn)镃DN緩存更方便；突破瀏覽器并發(fā)限制；節(jié)約cookie帶寬；節(jié)約主域名得連接數(shù)，優(yōu)化頁面響應(yīng)速度；防止不必要得安全性問題。
http2是超文本傳輸協(xié)議的第二版，相比http1協(xié)議的文本傳輸格式，http2是以二進(jìn)制的格式進(jìn)行數(shù)據(jù)傳輸?shù)模哂懈〉膫鬏旙w積以及負(fù)載。
http2.0分層，分幀層（http2多路復(fù)用能力的核心部分),數(shù)據(jù)或http層（包含傳統(tǒng)上被認(rèn)為是 HTTP 及其關(guān)聯(lián)數(shù)據(jù)的部分）。
HTTP2.0：
HTTP/2較HTTP/1.1優(yōu)化亮點(diǎn)
多路復(fù)用的實(shí)現(xiàn)：
在單個(gè)域名下仍可以建立一個(gè)TCP管道，使用一個(gè)TCP長連接，下載整個(gè)資源頁面，只需要一次慢啟動(dòng)，并且避免了靜態(tài)，瀏覽器發(fā)起請求，分幀層會(huì)對每個(gè)請求進(jìn)行分割，將同一個(gè)請求的分割塊打上相同的id編號(hào)，然后通過協(xié)議棧將所有的分割體發(fā)送給服務(wù)器，然后通過服務(wù)器的分幀層根據(jù)id編號(hào)進(jìn)行請求組裝，服務(wù)器的分幀層將回應(yīng)數(shù)據(jù)分割按同一個(gè)回應(yīng)體進(jìn)行ID分割回應(yīng)給客戶端，客戶端拼裝回應(yīng)。
對于http2中的幀（frame），http1不是基于幀（frame）的，是文本分隔的。
GET/HTTP/1.1 <crlf>
這樣，對于http1的請求或者是響應(yīng)可能有的問題：
HTTP/1 的請求和響應(yīng)報(bào)文，是由起始行、首部和正文組成，換行符分隔；HTTP/2是將請求和響應(yīng)數(shù)據(jù)分割成更小的幀，采用二進(jìn)制編碼，易于解析的。
參考圖片：
幀結(jié)構(gòu)總結(jié) 所有的幀都包含一個(gè)9 byte的幀頭 + 可邊長的正文不同。根據(jù)幀的類型不同，正文部分的結(jié)構(gòu)也不一樣。
幀頭：
http2作為一個(gè)二進(jìn)制協(xié)議，擁有包含輕量型，安全和快速在內(nèi)的所有優(yōu)勢，保留了原始的http協(xié)議語義，對于http2更改了在系統(tǒng)之間傳輸數(shù)據(jù)的方式。
二進(jìn)制分幀層（binary framing layer），所有通信都在單個(gè)TCP連接上執(zhí)行，該連接在整個(gè)對話期間一直處于打開狀態(tài)，主要是二進(jìn)制協(xié)議將通信分解為幀的方式，這些幀交織在客戶端與服務(wù)器之間的雙向邏輯流中。
HTTP/2 連接的拓?fù)浣Y(jié)構(gòu)(展示了一個(gè)用于建立多個(gè)流的連接)
在流 1 中，發(fā)送了一條請求消息，并返回了相應(yīng)的響應(yīng)消息。
HTTP/2 幀結(jié)構(gòu)
前9個(gè)字節(jié)對于每個(gè)幀是一致的。解析時(shí)只需要讀取這些字節(jié)，就可以準(zhǔn)確地知道在整個(gè)幀中期望的字節(jié)數(shù)。
幀首部字段表格：
名稱長度描述length3字節(jié)表示幀負(fù)載的長度type1字節(jié)當(dāng)前幀類型Flags1字節(jié)具體幀類型的標(biāo)識(shí)R1位保留位，不要設(shè)置，否則會(huì)帶來嚴(yán)重后果Stream Identifier31位每個(gè)流的唯一IDFrame Payload長度可變真實(shí)的幀內(nèi)容,長度是在length字段中設(shè)置的
備注：流Id是用來標(biāo)識(shí)幀所屬的流。流看作在連接上的一系列幀，它們構(gòu)成了單獨(dú)的 HTTP 請求和響應(yīng)。
對于http1 的請求和響應(yīng)都分成消息首部和消息體兩部分；http2 從上面一張圖可以知道，http2的請求和響應(yīng)分成HEADERS 幀和 DATA 幀。
比較一下：
http2的一個(gè)重要特性是基于流的流量控制。提供了客戶端調(diào)整傳輸速度的能力。其中WINDOW_UPDATE 幀用來指示流量控制信息。
有了多路復(fù)用，客戶端可以一次發(fā)出多有資源的請求，不用像http1那樣，發(fā)出對新對象請求之前，需要等待前一個(gè)響應(yīng)完成。所以瀏覽器失去了在Http1中的默認(rèn)資源請求優(yōu)先級策略。
http的頭字段
頭字段類型含義Date表示請求和響應(yīng)生成的日期Pragma表示數(shù)據(jù)是否允許緩存的通信選項(xiàng)Cache-Control控制緩存的相關(guān)信息Connection設(shè)置發(fā)送響應(yīng)之后TCP連接是否繼續(xù)保持的通信選項(xiàng)Transfer-Encoding表示消息主體的編碼格式Via記錄途中經(jīng)過的代理和網(wǎng)關(guān)Authorization身份認(rèn)證數(shù)據(jù)From請求發(fā)送者的郵件地址Referer當(dāng)通過點(diǎn)擊超級鏈接進(jìn)入下一個(gè)頁面時(shí)，在這里會(huì)記錄下上一個(gè)頁面的URIUser-Agent客戶端軟件的名稱和版本號(hào)等相關(guān)信息Accept客戶端可支持的數(shù)據(jù)類型，以MIME類型來表示Accept-Charset客戶端可支持的字符集Accept-Language客戶端可支持的語言Host接收請求的服務(wù)器ip地址和端口號(hào)Range當(dāng)需要只獲取部分?jǐn)?shù)據(jù)而不是全部數(shù)據(jù)時(shí)，可通過這個(gè)字段指定要獲取的數(shù)據(jù)范圍Location表示信息的準(zhǔn)確位置Server服務(wù)器程序的名稱和版本號(hào)等相關(guān)信息Allow表示指定的URI支持Content-Encoding當(dāng)消息體經(jīng)過壓縮等編碼處理時(shí)，表示其編碼格式Content-Length表示消息體的長度Content-Type表示消息體的數(shù)據(jù)類型，以MIME規(guī)格定義的數(shù)據(jù)類型來表示Expires表示消息體的有效期Last-Modified數(shù)據(jù)的最后更新日期Content-Language表示消息體的語言Content-Location表示消息體在服務(wù)器上的位置Content-Range當(dāng)僅請求部分?jǐn)?shù)據(jù)時(shí)，表示消息體包含的數(shù)據(jù)范圍
HTTP消息示例：
IP 的基本思路
Ip地址的表示方法
IP地址的結(jié)構(gòu)-子網(wǎng)掩碼表示網(wǎng)絡(luò)號(hào)與主機(jī)號(hào)之間的邊界。
解析器的調(diào)用方法
DNS服務(wù)器的基本工作
DNS 服務(wù)器之間的查詢操作
數(shù)據(jù)通過類似管道的結(jié)構(gòu)來流動(dòng)
通常當(dāng)?標(biāo)滑動(dòng)到元素上的時(shí)候顯示
alt 是 的特有屬性，是圖?內(nèi)容的等價(jià)描述，?于圖??法加載時(shí)顯示、讀屏器 閱讀圖?。可提圖??可訪問性，除了純裝飾圖?外都必須設(shè)置有意義的值，搜索引擎會(huì) 重點(diǎn)分析。
發(fā)送?個(gè)請求來取得服務(wù)器上的某?資源
向 URL 指定的資源提交數(shù)據(jù)或附加新的數(shù)據(jù)
跟 POST ?法很像，也是想服務(wù)器提交數(shù)據(jù)。但是，它們之間有不同。 PUT 指定了資 源在服務(wù)器上的位置，? POST 沒有
只請求??的?部
刪除服務(wù)器上的某資源
它?于獲取當(dāng)前 URL 所?持的?法。如果請求成功，會(huì)有?個(gè) Allow 的頭包含類 似 “GET,POST” 這樣的信息
TRACE ?法被?于激發(fā)?個(gè)遠(yuǎn)程的，應(yīng)?層的請求消息回路
把請求連接轉(zhuǎn)換到透明的 TCP/IP 通道
基礎(chǔ)版本 瀏覽器根據(jù)請求的 URL 交給 DNS 域名解析，找到真實(shí) IP ，向服務(wù)器發(fā)起請求； 服務(wù)器交給后臺(tái)處理完成后返回?cái)?shù)據(jù)，瀏覽器接收?件（ HTML、JS、CSS 、圖象等）； 瀏覽器對加載到的資源（ HTML、JS、CSS 等）進(jìn)?語法解析，建?相應(yīng)的內(nèi)部數(shù)據(jù)結(jié)構(gòu) （如 HTML 的 DOM ）； 載?解析到的資源?件，渲染??，完成。
詳細(xì)版
1. 在瀏覽器地址欄輸?URL
2. 瀏覽器查看緩存，如果請求資源在緩存中并且新鮮，跳轉(zhuǎn)到轉(zhuǎn)碼步驟
3. 瀏覽器解析URL獲取協(xié)議，主機(jī)，端?，path
4. 瀏覽器組裝?個(gè)HTTP（GET）請求報(bào)?
5. 瀏覽器獲取主機(jī)ip地址，過程如下：
6. 打開?個(gè)socket與?標(biāo)IP地址，端?建?TCP鏈接，三次握?如下：
7. TCP鏈接建?后發(fā)送HTTP請求
8. 服務(wù)器接受請求并解析，將請求轉(zhuǎn)發(fā)到服務(wù)程序，如虛擬主機(jī)使?HTTP Host頭部判斷請 求的服務(wù)程序
9. 服務(wù)器檢查HTTP請求頭是否包含緩存驗(yàn)證信息如果驗(yàn)證緩存新鮮，返回304等對應(yīng)狀態(tài)碼 10. 處理程序讀取完整請求并準(zhǔn)備HTTP響應(yīng)，可能需要查詢數(shù)據(jù)庫等操作
11. 服務(wù)器將響應(yīng)報(bào)?通過TCP連接發(fā)送回瀏覽器
12. 瀏覽器接收HTTP響應(yīng)，然后根據(jù)情況選擇關(guān)閉TCP連接或者保留重?，關(guān)閉TCP連接的四 次握?如下： 1. 主動(dòng)?發(fā)送Fin=1， Ack=Z， Seq= X報(bào)? 2. 被動(dòng)?發(fā)送ACK=X+1， Seq=Z報(bào)? 3. 被動(dòng)?發(fā)送Fin=1， ACK=X， Seq=Y報(bào)? 4. 主動(dòng)?發(fā)送ACK=Y， Seq=X報(bào)?
13. 瀏覽器檢查響應(yīng)狀態(tài)嗎：是否為1XX，3XX， 4XX， 5XX，這些情況處理與2XX不同
14. 如果資源可緩存，進(jìn)?緩存
15. 對響應(yīng)進(jìn)?解碼（例如gzip壓縮）
16. 根據(jù)資源類型決定如何處理（假設(shè)資源為HTML?檔）
17. 解析HTML?檔，構(gòu)件DOM樹，下載資源，構(gòu)造CSSOM樹，執(zhí)?js腳本，這些操作沒有嚴(yán) 格的先后順序，以下分別解釋
18. 構(gòu)建DOM樹： 1. Tokenizing：根據(jù)HTML規(guī)范將字符流解析為標(biāo)記 2. Lexing：詞法分析將標(biāo)記轉(zhuǎn)換為對象并定義屬性和規(guī)則 3. DOM construction：根據(jù)HTML標(biāo)記關(guān)系將對象組成DOM樹
19. 解析過程中遇到圖?、樣式表、js?件，啟動(dòng)下載
20. 構(gòu)建CSSOM樹：
content ??
Server ??
Cookie ??
css ??
Javascript ??
圖???
每天來個(gè)5題就行，關(guān)注我，每天一起學(xué)一點(diǎn)點(diǎn)。
*請認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
