1.解析輸入的URL地址

http://www.zhufengpeixun.cn:80/index.html?lx=teacher#video

• 傳輸協(xié)議（把信息在客戶端和服務(wù)器端進(jìn)行傳遞，類似于快遞小哥）

  • http 超文本傳輸協(xié)議（傳輸?shù)膬?nèi)容除了文本，還有可能是其它類型：二進(jìn)制編碼、BASE64碼、文件流等等）
  • https 比HTTP更加安全的傳輸協(xié)議（傳輸通道設(shè)置加密算法SSL），一般支付類網(wǎng)站都是HTTPS協(xié)議
  • ftp 資源上傳協(xié)議，一般應(yīng)用于把本地文件直接上傳到服務(wù)器端

• 域名 zhufengpeixun.cn

  • 一級域名 www.zhufengpeixun.cn
  • 二級域名 video.zhufengpeixun.cn
  • 三級域名 webG.video.zhufengpeixun.cn
  • 常用域名性質(zhì)：.com國際 / .cn中國 / .gov政府 / .org官方 / .net系統(tǒng) / .io博客 / .vip ...

• 端口號 （根據(jù)端口號，找到當(dāng)前服務(wù)器上指定的服務(wù)）

  • 0~65535之間
  • 不同協(xié)議有自己默認(rèn)的端口號（也就是自己不用寫，瀏覽器會幫我們加上）
    • http => 80
    • https => 443
    • ftp => 21
    • 除這幾個在書寫的時候可以省略，其余的不能省

• 請求資源的路徑和名稱

  • /stu/index.html
    • 一般情況下，如果我們訪問的是index.html等，可以省略不寫（因為服務(wù)端一般會設(shè)置index.html為默認(rèn)文檔，當(dāng)然可以自定義）
  • 偽URL
    • SEO優(yōu)化 https://item.jd.com/100006038463.html
    • 數(shù)據(jù)請求的接口地址 /user/list

• 問號傳參部分 ?xxx=xxx

  • 客戶端基于GET系列請求，把信息傳遞會服務(wù)器，一般都會基于問號傳參的模式
  • 頁面之間跳轉(zhuǎn)，信息的一些通信也可以基于問號傳參的方式（單頁面中組件和組件跳轉(zhuǎn)之間的信息通信，也可能基于問號傳參）
  • 關(guān)于傳遞的內(nèi)容需要進(jìn)行編碼處理（處理特殊字符和中文）
    • encodeURI / decodeURI
    • encodeURIComponent / decodeURIComponent
    • escape / unescape
    • ...

• 設(shè)置哈希HASH #xxx

2.DNS解析

網(wǎng)站中，每發(fā)送一個TCP請求，都要進(jìn)行DNS解析（一但當(dāng)前域名解析過一次，瀏覽器一般會緩存解析記錄，緩存時間一般在1分鐘左右，后期發(fā)送的請求如果還是這個域名，則跳過解析步驟 =>這是一個性能優(yōu)化點）

真實項目中，一個大型網(wǎng)站，他要請求的資源是分散到不同的服務(wù)器上的（每一個服務(wù)器都有自己的一個域名解析）

• WEB服務(wù)器（處理靜態(tài)資源文件，例如：html/css/js等 的請求）
• 數(shù)據(jù)服務(wù)器（處理數(shù)據(jù)請求）
• 圖片服務(wù)器 （處理圖片請求）
• 音視頻服務(wù)器
• ......
  這樣導(dǎo)致，我們需要解析的DNS會有很多次

優(yōu)化技巧：DNS Prefetch 即 DNS 預(yù)獲取

讓頁面加載（尤其是后期資源的加載）更順暢更快一些

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" >
<link rel="dns-prefetch" >
<link rel="dns-prefetch" >
<link rel="dns-prefetch" >
<link rel="dns-prefetch" >
.......

3.基于TCP的三次握手，夠建客戶端和服務(wù)器端的連接通道

只有建立好連接通道，才能基于HTTP等傳輸協(xié)議，實現(xiàn)客戶端和服務(wù)器端的信息交互

4.發(fā)送HTTP請求

基于HTTP等傳輸協(xié)議，客戶端把一些信息傳遞給服務(wù)器

• HTTP請求報文（所有客戶端傳遞給服務(wù)器的內(nèi)容，統(tǒng)稱為請求報文）

  • 谷歌控制臺NetWork中可以看到
  • 請求起始行
  • 請求首部（請求頭）
  • 請求主體

• 強(qiáng)緩存 和 協(xié)商緩存（性能優(yōu)化：減少HTTP請求的次數(shù)）

  • 強(qiáng)緩存 ( Cache-Control 和 Expires )
  • 協(xié)商緩存 ( Last-Modified 和 Etag )

5.服務(wù)器接受到請求，并進(jìn)行處理，最后把信息返回給客戶端

• HTTP響應(yīng)報文（所有服務(wù)器返回給客戶端的內(nèi)容）
  • 響應(yīng)起始行
  • 響應(yīng)首部（響應(yīng)頭）
    • date存儲的是服務(wù)器的時間
    • ...
  • 響應(yīng)主體
  • 服務(wù)器返回的時候是：先把響應(yīng)頭信息返回，然后繼續(xù)返回響應(yīng)主體中的內(nèi)容（需要的信息大部分都是基于響應(yīng)主體返回的）

6.斷開TCP鏈接通道 （四次揮手）

• 當(dāng)客戶端把請求信息發(fā)送給服務(wù)器的時候，就揮第一次手：客戶端告訴服務(wù)器端，我已經(jīng)把請求報文都給你了，你準(zhǔn)備關(guān)閉吧
• 第二次揮手：由服務(wù)器發(fā)起，告訴瀏覽器，我接收完請求報文，我準(zhǔn)備關(guān)閉，你也準(zhǔn)備吧；
• 第三次揮手：由服務(wù)器發(fā)起，告訴瀏覽器，我響應(yīng)報文發(fā)送完畢，你準(zhǔn)備關(guān)閉吧；
• 第四次揮手：由瀏覽器發(fā)起，告訴服務(wù)器，我響應(yīng)報文接收完畢，我準(zhǔn)備關(guān)閉，你也準(zhǔn)備吧；

Connection: Keep-Alive 保持TCP不中斷（性能優(yōu)化點，減少每一次請求還需要重新建立鏈接通道的時間）

7.客戶端渲染服務(wù)器返回的結(jié)果