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