1、DNS 的解析過程
- 訪問根服務器，他會告訴你 .com 的 頂級服務器
- 訪問 .com 頂級 服務器，他會告訴你 baidu.com的地址
- 最後訪問 baidi.com 域名 服務器，得到 www.baidu.com 的 地址
- 域名解析可以配置內部的策略，返回離客戶端最近的主機，或者返回當前服務質量最好的主機，這樣在 DNS 端把請求分發到不同的服務器，實現負載均衡。
- 通常來說，瀏覽器會先檢查自己有沒有對應的 DNS 緩存，
- 沒有的話去 操作系統 查找有沒有 對應的 DNS 緩存，
- 接着再去 hosts 文件裏面查找 有沒有對應的 DNS 配置，如下圖
在 Windows 裏是“C:\WINDOWS\system32\drivers\etc\hosts”，如果操作系統在緩存裏找不到 DNS 記錄，就會找這個文件
2、大文件傳輸
在一般的請求中，返回的頭部都會帶上 請求的返回值的大小 也就是 content-length
但是在大文件的傳輸過程中，就會出現分塊傳輸
分塊傳輸，一般的請求會攜帶 length 字段，但是 在 大文件的時候，就很難一次性發過來了，或者說有的請求時很難確定到底有多少長度的，所所以這個時候，傳輸就會 分塊，也就是 chunk，然後 瀏覽器對其進行拼接 Transfer-Encoding: chunked，而且一切在 chrome 的 network 是看不到的，相當於黑盒
3、長連接
在前面的 瀏覽器中輸入URL後會發生什麼事情--超級詳細版 中，我有寫到，在 http1.1 中，請求默認都是長連接的
服務器端通常不會主動關閉連接，但也可以使用一些策略。
- 拿 Nginx 來舉例，它有兩種方式：使用“keepalive_timeout”指令，設置長連接的超時時間，如果在一段時間內連接上沒有任何數據收發就主動斷開連接，避免空閒連接佔用系統資源。
- 使用“keepalive_requests”指令，設置長連接上可發送的最大請求次數。比如設置成 1000，那麼當 Nginx 在這個連接上處理了 1000 個請求後，也會主動斷開連接。
在這其中，充分利用了 網絡性能的同時，也會導致 其他的性能問題，也就是 隊頭阻塞，因爲對一個域名只支持 6 個長連接，其餘所有的請求都得排隊，遇到一個請求有問題，接下來的請求就都得等着
這裏可以使用域名分片，也就是多開幾個域名
4、cookie
- “HttpOnly”會告訴瀏覽器，此 Cookie 只能通過瀏覽器 HTTP 協議傳輸，禁止其他方式訪問
- 另一個屬性“SameSite”可以防範“跨站請求僞造”（XSRF）攻擊，設置成“SameSite=Strict”可以嚴格限定 Cookie 不能隨着跳轉鏈接跨站發送，而“SameSite=Lax”則略寬鬆一點，允許 GET/HEAD 等安全方法，但禁止 POST 跨站發送。
- 未來chrome80會默認(SameSite: lax)在跨域請求的情況下不允許跨域攜帶cookie給後端，這樣的話，未來廣告商就會遇到部分麻煩
- 還有一個屬性叫“Secure”，表示這個 Cookie 僅能用 HTTPS 協議加密傳輸，明文的 HTTP 協議會禁止發送。但 Cookie 本身不是加密的，瀏覽器裏還是以明文的形式存在。
4、緩存 cache-controll
- cache-control 中的 max-age 是從報文創建，離開服務器開始計算的，所以 包含了 在 鏈路上的傳播時間
- no-store：不允許緩存
- no-cache：它的字面含義容易與 no-store 搞混，實際的意思並不是不允許緩存，而是可以緩存，但在使用之前必須要去服務器驗證是否過期，是否有最新的版本；
- must-revalidate：又是一個和 no-cache 相似的詞，它的意思是如果緩存不過期就可以繼續使用，但過期瞭如果還想用就必須去服務器驗證