首先列出七層協(xié)議（惡補了大學所逃的計算機網絡??）
計算機七層協(xié)議：物理層 數據鏈路層 網絡層 傳輸層 會話層 表示層 應用層
HTTP是應用層協(xié)議 ，他無需操心網絡通信的細節(jié)，把聯(lián)網細節(jié)都交給了因特網傳輸協(xié)議TCP/IP

http網絡協(xié)議棧

HTTP 協(xié)議位于 TCP 的上層。HTTP 使用 TCP 來傳輸其報文數 據。與之類似，TCP 則位于 IP 的上層

1.DNS: 域名服務器

是進行域名和相應IP地址相互轉換的服務器，DNS保存了一張域名和與之相對應的IP地址表，以解析消息的域名，一般和后端聯(lián)調的時候，后端會讓我們訪問一個ip地址加上一個端口號的東東，之后發(fā)布時候要申請并換成域名，因為一個ip地址89.12.21.221:9090一堆數字，不便于記憶，我們需要到服務器申請一個類似www.baidu.com的域名方便記憶，相當于在服務器上面花錢放上自己投射的域名

當用戶輸入一個www.baidu.com的時候
瀏覽器會去本地緩存尋找dns解析的記錄，如果緩存沒有，則會去一個本地的hosts文件查看是否有改dns記錄，有則返回（在該項目的終端輸入vim /etc/hosts）

2.http請求發(fā)起和響應

通過下面一個問題來解釋
用戶輸入url，到瀏覽器呈現用戶，經過的流程

1.用戶輸入URL，瀏覽器獲取到URL
2.瀏覽器(應用層)進行DNS解析（如果輸入的是IP地址，此步驟省略）
3.根據解析出的ip地址+端口號，瀏覽器（應用層）發(fā)出http請求，請求中攜帶請求頭header，請求體body

header包括：

• 請求的方法（get、post、put..）
• 協(xié)議（http、https、ftp、sftp…）
• 目標url（具體的請求路徑已經文件名）
• 一些必要信息（緩存、cookie之類）如果您在cookie中設置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊

HttpOnly的設置樣例
javaEE
response.setHeader("Set-Cookie", "cookiename=value;
Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

4.請求到達傳輸層，tcp協(xié)議為傳輸報文提供可靠的字節(jié)流傳輸服務，它通過三次握手等手段來保證傳輸過程中的安全可靠。通過對大塊數據的分割成一個個報文段的方式提供給大量數據的便攜傳輸。
5.到網絡層，網絡層通過ARP尋址得到接收方的mac地址，IP協(xié)議把在傳輸層被分割成一個個數據包傳送接收方

6. 到達數據鏈路層 請求階段完成
   7.接收方在數據鏈路層收到數據之后，層層傳遞到應用層，接收方程序就獲得到請求報文
7. 接受方收到發(fā)送方的http請求后，進行請求文件資源的尋找并響應報文
   9.發(fā)送方收到響應報文后，如果報文中的狀態(tài)碼表示請求成功，則接受返回的資源（如HTML文件），進行頁面

3.TCP/IP協(xié)議

HTTP是一個應用層協(xié)議，它無須操心網絡通信的具體細節(jié)，把聯(lián)網細節(jié)都交給了通用可靠的因特網傳輸協(xié)議：TCP /IP

負責傳輸的TCP協(xié)議：
提供可靠的字節(jié)流服務，字節(jié)流服務指為了方便傳輸，將大塊數據分割成報文段為單位的數據包進行管理?？煽康膫鬏敺帐侵改軌虬褦祿蚀_可靠的傳給對方，tcp為了傳輸大數據才把數據進行分割，而且TCP協(xié)議能夠確認數據是否送達到達對方
為了確保數據準確送達，TCP采用三次握手策略，用TCP協(xié)議把數據包送出之后不會置之不理，他會向對方確認，握手過程中使用SYN和ACK標志

參考《圖解HTTP》

TCP做的事情:

• 無差錯的數據傳輸
• 按序傳輸(數據總是會按照發(fā)送的順序到達);
• 未分段的數據流(可以在任意時刻以任意尺寸將數據發(fā)送出去)。

負責傳輸的IP協(xié)議：
按協(xié)議分，IP網絡協(xié)議位于網絡層，所有網絡系統(tǒng)都會用到IP協(xié)議，IP協(xié)議主要的作用就是將各種數據包傳送給對方，確保傳送到對方那里就是要滿足各種條件，最重要的兩個條件就是IP地址和MAC地址

• IP地址指明了節(jié)點被分配到的地址
• mac地址指的是網卡所屬的固定地址
  IP地址可以和MAC地址進行配對，IP地址可以改變，MAC地址基本上不會更改

參考《圖解HTTP》

4.頁面的渲染

當一個請求發(fā)起和響應都完成了之后，瀏覽器就會收到響應內容，但是瀏覽器收到的是一串串代碼和url鏈接，怎么把這些代碼轉化成用戶能看見的就是瀏覽器所做的工作了

1. 瀏覽器接收到 HTML 文件并轉換為 DOM 樹,這一過程會遇到css代碼以及js代碼，瀏覽器也會下載并解析這些文件

2.將 CSS 文件轉換為 CSSOM 樹

這一過程會遞歸整個樹，是很消耗資源的
div > a > span { color: red; }這樣的代碼會一直查找到每個節(jié)點 所以避免寫過于具體的css選擇器，減少復雜的遞歸過程 值得注意的是，CSSOM運算是一個非常復雜的過程，性能消耗會比較大

• 盡量使用class和id，保證層級扁平 減少過度層疊，而且越是通用的CSS樣式，執(zhí)行速度越快，越是具體（選擇器）的CSS樣式，則執(zhí)行速度越慢。
• 使用內聯(lián)樣式 外鏈的JS和CSS文件以前CSS的@import，在頁面渲染的過程中，都會重新去服務器端請求。這其實，和我們常說的減少http請求量（合并http請求）類似，但是我么從渲染路徑的角度來理解這樣一種性能的消耗。

3. 得到DOM樹以及CSSOM之后將兩者整合為渲染樹

當生成渲染樹之后 瀏覽器就會根據渲染樹進行布局（回流)

layout：根據得到的render tree來計算所有節(jié)點在屏幕的位置。
paint：遍歷render樹，并調用硬件圖形API來繪制每個節(jié)點。

我們要減少重繪和回流

• 使用 transform 替代 top

CSS的最終表現分為以下四步：Recalculate Style -> Layout -> Paint Setup and Paint -> Composite Layers
按照中文的意思大致是 查找并計算樣式 -> 排布 -> 繪制 -> 組合層這上面的幾個步驟有點類似于上文說到的重排必定導致重繪，而查詢屬性會強制發(fā)生重排。所以上文提到的重排重繪內容可以結合這里進行理解。由于transform是位于Composite Layers層，而width、left、margin等則是位于Layout層，在Layout層發(fā)生的改變必定導致Paint Setup and Paint -> Composite Layers，所以相對而言使transform實現的動畫效果肯定比top這些更加流暢。

• 使用 visibility 替換 display: none ，因為前者只會引起重繪，后者會引發(fā)回流（改變了布局`
• 不要使用 table 布局，可能很小的一個小改動會造成整個 table 的重新布局
• CSS 選擇符從右往左匹配查找，避免節(jié)點層級過多

這一部分就是渲染原理中講解到的內容 在下載文件時，也可以說下通過 HTTP/2 協(xié)議可以解決隊頭阻塞的問題 比如 遇到文件下載的會去下載文件，這里如果使用 HTTP/2 協(xié)議的話會極大的提高多圖的下載效率。

get和post終極區(qū)別

GET和POST最大的區(qū)別主要是GET請求是冪等性的，POST請求不是。這個是它們本質區(qū)別，上面的只是在使用上的區(qū)別。

• 副作用：副作用指當你發(fā)送完一個請求以后，網站上的資源狀態(tài)沒有發(fā)生修改，即認為這個請求是無副作用的。比如注冊用戶這個請求是有副作用的，獲取用戶詳情可以認為是無副作用的。

• 冪等：指發(fā)送 M 和 N 次請求（兩者不相同且都大于 1），服務器上資源的狀態(tài)一致，比如注冊 10 個和 11 個帳號是不冪等的，對文章進行更改 10 次和 11 次是冪等的。因為前者是多了一個賬號（資源），后者只是更新同一個資源。

HTTP的GET/POST/DELETE/PUT方法冪等的情況：

GET是冪等的，無副作用
比如我想要獲得訂單ID為2的訂單：http://localhost/order/2，使用GET多次獲取，這個ID為2的訂單(資源)是不會發(fā)生變化的！
DELETE/PUT是冪等的，有副作用
比如我想要刪除或者更新ID為2的訂單：http://localhost/order/2，使用PUT/DELETE多次請求，這個ID為2的訂單(資源)只會發(fā)生一次變化(是有副作用的)！但繼續(xù)多次刷新請求，訂單ID為2的最終狀態(tài)都是一致的
POST是非冪等的，有副作用的
比如我想要創(chuàng)建一個名稱叫3y的訂單：http://localhost/order，使用POST多次請求，此時可能就會創(chuàng)建多個名稱為3y的訂單,這個訂單(資源)是會多次變化的，每次請求的資源狀態(tài)都會變化！

HTTP2和HTTP1的區(qū)別

HTTP2新特性

• 多路復用 復用一個tcp鏈接傳輸所有請求數據
• 壓縮header：使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減少了 header 的大小
• HTTP2 中所有加強性能的核心點在于此。在之前的 HTTP 版本中，我們是通過文本的方式傳輸數據。在 HTTP2 中引入了新的編碼機制，所有傳輸的數據都會被分割，并采用二進制格式編碼。
• 服務端PUSH：服務端可以在客戶端某個請求后，主動推送其他資源。

HTTP1.0和HTTP1.1區(qū)別

• HTTP1.0 規(guī)定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。
• HTTP1.1持續(xù)連接，也需要增加新的請求頭來幫助實現，例如，Connection請求頭的值為Keep-Alive時，客戶端通知服務器返回本次請求結果后保持連接；Connection請求頭的值為close時，客戶端通知服務器返回本次請求結果后關閉連接。HTTP 1.1還提供了與身份認證、狀態(tài)管理和Cache緩存等機制相關的請求頭和響應頭。