Web的工作方式

  • 對于普通的上網(wǎng)，系統(tǒng)是這樣做的：瀏覽器本身就是一個客戶端，當(dāng)你輸入URL的時候，首先瀏覽器會去請求DNS服務(wù)器，通過DNS獲取相應(yīng)域名的對應(yīng)的Ip地址，通過IP地址找到對應(yīng)IP對應(yīng)的服務(wù)器，要求建立TCP連接，等瀏覽器發(fā)送完HTTP Request包后，服務(wù)器接受到請求包之后才開始處理請求包，服務(wù)器調(diào)用自身服務(wù)，返回Http Response （響應(yīng)包）：客戶端收到來自服務(wù)器的響應(yīng)后開始渲染這個Response包里的主體（body）,等收到全部的內(nèi)容隨后斷開與該服務(wù)器之間的TCP連接。
用戶訪問一個Web站點(diǎn)的過程

  • Web服務(wù)器也被稱為HTTP服務(wù)器，它通過HTTP協(xié)議與客戶端通信（客戶端通常指的是Web瀏覽器，手機(jī)的客戶端也是瀏覽器實(shí)現(xiàn)的）

  • TCP/IP協(xié)議（來源于百度百科）：Transmission Control Protocol/Internet Protocol的簡寫，中譯名為傳輸控制協(xié)議/因特網(wǎng)互聯(lián)協(xié)議，又名網(wǎng)絡(luò)通訊協(xié)議，是Internet最基本的協(xié)議、Internet國際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)。協(xié)議采用了4層的層級結(jié)構(gòu)，每一層都呼叫它的下一層所提供的協(xié)議來完成自己的需求。通俗而言：TCP負(fù)責(zé)發(fā)現(xiàn)傳輸的問題，一有問題就發(fā)出信號，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡?。而IP是給因特網(wǎng)的每一臺聯(lián)網(wǎng)設(shè)備規(guī)定一個地址。

  • HTTP協(xié)議（來源于百度百科）：超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。1960年美國人Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。Ted Nelson組織協(xié)調(diào)萬維網(wǎng)協(xié)會（World Wide Web Consortium）和互聯(lián)網(wǎng)工程工作小組（Internet Engineering Task Force ）共同合作研究，最終發(fā)布了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1。

  • Web服務(wù)器的工作的原理：

    • 客戶端通過TCP/IP協(xié)議建立到服務(wù)器TCP連接
    • 客戶端想服務(wù)器發(fā)送HTTP協(xié)議請求包，請求服務(wù)器里的資源文檔
    • 服務(wù)器向客戶端發(fā)送發(fā)送HTTP協(xié)議應(yīng)答包，如果請求的資源包含有動態(tài)語言的內(nèi)容，那么服務(wù)器會調(diào)用動態(tài)語言的解析引擎負(fù)責(zé)處理動態(tài)內(nèi)容，并將處理得到的數(shù)據(jù)返回給客戶端
    • 客戶端與服務(wù)端斷開，由客戶端解釋HTML文檔，在客戶端屏幕上渲染圖形結(jié)果

需要注意的是：客戶端和服務(wù)器之間的通信是非持久連接的，也就是當(dāng)服務(wù)器發(fā)送了應(yīng)答后就與客戶端斷開連接了，等待下一次請求。

URL和DNS解析

  • URL(Uniform Resource Locator)是“統(tǒng)一資源定位符”的英文縮寫，用于描述一個網(wǎng)絡(luò)上的資源
  • URL由三部分組成：資源類型、存放資源的主機(jī)域名、資源文件名。
  • URL的一般語法格式為：(帶方括號[]的為可選項(xiàng))：scheme://host[:port#]/path/.../[?query-string][#anchor] 
scheme://host[:port#]/path/.../[?query-string][#anchor]
scheme         指定底層使用的協(xié)議(例如：http, https, ftp)
host           HTTP服務(wù)器的IP地址或者域名
port#          HTTP服務(wù)器的默認(rèn)端口是80，這種情況下端口號可以省略。如果使用了別的端口，必須指明，例如 http://www.cnblogs.com:8080/
path           訪問資源的路徑
query-string   發(fā)送給http服務(wù)器的數(shù)據(jù)
anchor         錨
  • DNS解析
  • DNS(Domain Name System)是域名系統(tǒng)的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)命名的系統(tǒng)，它用于TCP/IP網(wǎng)絡(luò)，它從事將主機(jī)名或者域名轉(zhuǎn)換成為實(shí)際的IP地址的工作。NDS就是一位翻譯官
DNS工作原理

  • 更加詳細(xì)的工作流程如下：

    • 1、在瀏覽器中輸入'www.itdecent.cn'域名，操作系統(tǒng)會檢查自己本地的hosts文件是否有這個網(wǎng)址映射的關(guān)系，如果有機(jī)會調(diào)用這個IP地址映射，完成域名解析（這里有個騷操作，在雙十一的時候，把本地的hosts的文件指向你自己的靜態(tài)頁面，隨便寫個404的頁面，告訴你女朋友說，服務(wù)器掛了，買不了，哈哈哈哈哈哈?）

      hosts

    • 2、如果hosts沒有這個域名的映射，就會查找本地的DNS解析器緩存，是否有這個網(wǎng)址映射的關(guān)系，如果有，直接返回，完成域名解析。

    • 3、如果hosts于本地DNS解析器緩存都沒有相應(yīng)的網(wǎng)址映射關(guān)系，首先會找TCP/IP參數(shù)中設(shè)置的首選的DNS服務(wù)器（有時候我們翻墻就要改動這里），本地DNS服務(wù)器，此服務(wù)器收到查詢時候，如果要查詢的域名，它包含本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，這個解析具有權(quán)威性

      DNS設(shè)置

    • 4、如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已經(jīng)緩存了此網(wǎng)址的映射的關(guān)系，則調(diào)用這個IP地址映射，完成域名解析，此解析不具有權(quán)威性

    • 5、如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器設(shè)置（是否設(shè)置了轉(zhuǎn)發(fā)器）進(jìn)行查詢，如果沒有使用轉(zhuǎn)發(fā)模式，本地的DNS就把請求轉(zhuǎn)發(fā)到根DNS服務(wù)器，根服務(wù)器收到請求了會去判斷這個域名（.com）是誰來授權(quán)管理，并會返回一個負(fù)責(zé)該頂級域名服務(wù)器的一個IP。本地服務(wù)收到服務(wù)器的IP信息了，將會聯(lián)系負(fù)責(zé).com的這臺服務(wù)器。這臺服務(wù)器負(fù)責(zé).com域的服務(wù)器收到請求了，如果自己無法解析，它就會找一個管理.com域下一級DNS服務(wù)器地址(jianshu.com)給本地的DNS服務(wù)器。當(dāng)本地的DNS服務(wù)器收到這個地址后，就會找jianshu.com,重復(fù)上面的動作，進(jìn)行查詢，直到找到www.itdecent.cn這個地址。

    • 6、如果用的轉(zhuǎn)發(fā)的模式，此DNS服務(wù)器就會把這個請求轉(zhuǎn)發(fā)至上一級DNS服務(wù)器，由上一級服務(wù)器進(jìn)行解析，如果上一層服務(wù)器不能解析，或者是根DNS服務(wù)器吧請求轉(zhuǎn)至上上級。不管本地DNS服務(wù)器用的是轉(zhuǎn)發(fā)，還是根提示，左后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器在返回給客戶機(jī)


      DNS解析的整個流程

  • 所謂遞歸查詢過程：就是 “查詢的遞交者” 更替,查詢提交者不斷的更變,

  • 而迭代查詢過程： 則是 “查詢的遞交者”不變。

  • 舉個例子來說，你想知道某個一起上法律課的女孩的電話，并且你偷偷拍了她的照片，回到寢室告訴一個很仗義的哥們兒，這個哥們兒二話沒說，拍著胸脯告訴你，甭急，我替你查(此處完成了一次遞歸查詢，即，問詢者的角色更替)。然后他拿著照片問了學(xué)院大四學(xué)長，學(xué)長告訴他，這姑娘是xx系的；然后這哥們兒馬不停蹄又問了xx系的辦公室主任助理同學(xué)，助理同學(xué)說是xx系yy班的，然后很仗義的哥們兒去xx系yy班的班長那里取到了該女孩兒電話。(此處完成若干次迭代查詢，即，問詢者角色不變，但反復(fù)更替問詢對象)最后，他把號碼交到了你手里。完成整個查詢過程。

  • 通過上面的步驟，最終獲取IP地址，也就是瀏覽器最后發(fā)起請求的時候基于IP來和服務(wù)器做信息交換的

  • 根服務(wù)器主要用來管理互聯(lián)網(wǎng)的主目錄，全世界只有13臺（這13臺根域名服務(wù)器名字分別為“A”至“M”），1個為主根服務(wù)器在美國。其余12個均為輔根服務(wù)器，其中9個在美國，歐洲2個，位于英國和瑞典，亞洲1個位于日本。 [1]

HTTP協(xié)議詳解

  • HTTP是一種讓Web服務(wù)器與瀏覽器(客戶端)通過Internet發(fā)送與接收數(shù)據(jù)的協(xié)議,它建立在TCP協(xié)議之上，一般采用TCP的80端口。
  • 它是一個請求、響應(yīng)協(xié)議--客戶端發(fā)出一個請求，服務(wù)器響應(yīng)這個請求。
  • 在HTTP中，客戶端總是通過建立一個連接與發(fā)送一個HTTP請求來發(fā)起一個事務(wù)。
  • 服務(wù)器不能主動去與客戶端聯(lián)系，也不能給客戶端發(fā)出一個回調(diào)連接。客戶端與服務(wù)器端都可以提前中斷一個連接。例如，當(dāng)瀏覽器下載一個文件時，你可以通過點(diǎn)擊“停止”鍵來中斷文件的下載，關(guān)閉與服務(wù)器的HTTP連接。
  • HTTP協(xié)議是無狀態(tài)的，同一個客戶端的這次請求和上次請求是沒有對應(yīng)關(guān)系，對HTTP服務(wù)器來說，它并不知道這兩個請求是否來自同一個客戶端。為了解決這個問題， Web程序引入了Cookie機(jī)制來維護(hù)連接的可持續(xù)狀態(tài)。
  • Cookie意為“甜餅”，是由W3C組織提出，最早由Netscape社區(qū)發(fā)展的一種機(jī)制。目前Cookie已經(jīng)成為標(biāo)準(zhǔn)，所有的主流瀏覽器如IE、Netscape、Firefox、Opera等都支持Cookie。由于HTTP是一種無狀態(tài)的協(xié)議，服務(wù)器單從網(wǎng)絡(luò)連接上無從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務(wù)器就能從通行證上確認(rèn)客戶身份了。這就是Cookie的工作原理。
  • HTTP協(xié)議是建立在TCP協(xié)議之上的，因此TCP攻擊一樣會影響HTTP的通訊，例如比較常見的一些攻擊：SYN Flood是當(dāng)前最流行的DoS（拒絕服務(wù)攻擊）與DdoS（分布式拒絕服務(wù)攻擊）的方式之一，這是一種利用TCP協(xié)議缺陷，發(fā)送大量偽造的TCP連接請求，從而使得被攻擊方資源耗盡（CPU滿負(fù)荷或內(nèi)存不足）的攻擊方式。

HTTP請求包（瀏覽器信息）

  • Request包的結(jié)構(gòu), Request包分為3部分，第一部分叫Request line（請求行）, 第二部分叫Request header（請求頭）,第三部分是body（主體）。header和body之間有個空行，請求包的例子所示:
GET /domains/example/ HTTP/1.1      //請求行: 請求方法 請求URI HTTP協(xié)議/協(xié)議版本
Host：www.iana.org               //服務(wù)端的主機(jī)名
User-Agent：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4          //瀏覽器信息
Accept：text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  //客戶端能接收的MIME
Accept-Encoding：gzip,deflate,sdch       //是否支持流壓縮
Accept-Charset：UTF-8,*;q=0.5        //客戶端字符編碼集
//空行,用于分割請求頭和消息體
//消息體,請求資源參數(shù),例如POST傳遞的參數(shù)
  • 抓取簡書的首頁的信息
Request URL:http://www.itdecent.cn/
Request Method:GET
Status Code:304 Not Modified
Remote Address:127.0.0.1:8888
Response Headers
view source
Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Security-Policy:script-src 'self' 'unsafe-inline' 'unsafe-eval' *.jianshu.com *.jianshu.io api.geetest.com static.geetest.com dn-staticdown.qbox.me zz.bdstatic.com *.google-analytics.com # push.zhanzhang.baidu.com res.wx.qq.com qzonestyle.gtimg.cn as.alipayobjects.com ;style-src 'self' 'unsafe-inline' *.jianshu.com *.jianshu.io api.geetest.com static.geetest.com ;
Date:Mon, 02 Jul 2018 09:10:04 GMT
ETag:W/"e5bf3f5c57dcac3addf979d6e74fa906"
Server:Tengine
Set-Cookie:locale=zh-CN; path=/
Strict-Transport-Security:max-age=31536000; includeSubDomains; preload
X-Content-Type-Options:nosniff
X-Dscp-Value:0
X-Frame-Options:DENY
X-Request-Id:01a51f5d-b6ea-45c2-91a7-5fdec3a8eb70
X-Runtime:0.022833
X-Via:1.1 PSfjfzdx2mj93:9 (Cdn Cache Server V2.0), 1.1 yangdianxin66:10 (Cdn Cache Server V2.0)
X-XSS-Protection:1; mode=block
Request Headers
view source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:__guid=163745081.662820947905634200.1526461023901.8958; signin_redirect=https%3A%2F%2Fwww.itdecent.cn%2F; read_mode=day; default_font=font2; monitor_count=5; sensorsdata2015jssdkcross=%7B%22distinct_id%22%3A%22163682ac930acd-0e49b894cda713-6b1b1279-2073600-163682ac9319a0%22%2C%22%24device_id%22%3A%22163682ac930acd-0e49b894cda713-6b1b1279-2073600-163682ac9319a0%22%2C%22props%22%3A%7B%22%24latest_traffic_source_type%22%3A%22%E7%9B%B4%E6%8E%A5%E6%B5%81%E9%87%8F%22%2C%22%24latest_referrer%22%3A%22%22%2C%22%24latest_referrer_host%22%3A%22%22%2C%22%24latest_search_keyword%22%3A%22%E6%9C%AA%E5%8F%96%E5%88%B0%E5%80%BC_%E7%9B%B4%E6%8E%A5%E6%89%93%E5%BC%80%22%7D%7D; Hm_lvt_0c0e9d9b1e7d617b3e6842e85b9fb068=1528795394,1530514591; Hm_lpvt_0c0e9d9b1e7d617b3e6842e85b9fb068=1530522699; locale=zh-CN
Host:www.itdecent.cn
If-None-Match:W/"e5bf3f5c57dcac3addf979d6e74fa906"
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
  • HTTP協(xié)議定義了很多與服務(wù)器交互的請求方法，最基本的有4種，分別是GET,POST,PUT,DELETE。
  • 一個URL地址用于描述一個網(wǎng)絡(luò)上的資源
  • 而HTTP中的GET, POST, PUT, DELETE就對應(yīng)著對這個資源的查，增，改，刪4個操作。
  • 最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。

由于簡書地址是https,我通過fiddler去抓一個不是http的，看起來比較好看

get請求
post請求
  • 可以得出GET和POST的區(qū)別:
    • GET提交的數(shù)據(jù)會放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456。POST方法是把提交的數(shù)據(jù)放在HTTP包的body中。
    • GET提交的數(shù)據(jù)大小有限制（因?yàn)闉g覽器對URL的長度有限制），而POST方法提交的數(shù)據(jù)沒有限制。
    • GET方式提交數(shù)據(jù)，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數(shù)據(jù)時，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機(jī)器，就可以從歷史記錄獲得該用戶的賬號和密碼。

HTTP響應(yīng)包（服務(wù)器信息）

HTTP/1.1 200 OK                     //狀態(tài)行
Server: nginx/1.0.8                 //服務(wù)器使用的WEB軟件名及版本
Date:Date: Tue, 30 Oct 2012 04:14:25 GMT        //發(fā)送時間
Content-Type: text/html             //服務(wù)器發(fā)送信息的類型
Transfer-Encoding: chunked          //表示發(fā)送HTTP包是分段發(fā)的
Connection: keep-alive              //保持連接狀態(tài)
Content-Length: 90                  //主體內(nèi)容長度
//空行 用來分割消息頭和主體
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"... //消息體
  • 獲取新浪首頁的數(shù)據(jù)如下
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 02 Jul 2018 09:21:33 GMT
Content-Type: text/html
Content-Length: 576063
Connection: keep-alive
Last-Modified: Mon, 02 Jul 2018 09:20:01 GMT
Vary: Accept-Encoding
X-Powered-By: shci_v1.03
Expires: Mon, 02 Jul 2018 09:22:28 GMT
Cache-Control: max-age=60
Age: 4
Via: http/1.1 ctc.ningbo.ha2ts4.97 (ApacheTrafficServer/6.2.1 [cHs f ]), http/1.1 ctc.xiamen.ha2ts4.41 (ApacheTrafficServer/6.2.1 [cHs f ])
X-Via-Edge: 153052329372561c48b773cd64cde73000845
X-Cache: HIT.41
X-Via-CDN: f=edge,s=ctc.xiamen.ha2ts4.34.nb.sinaedge.com,c=119.139.196.97;f=Edge,s=ctc.xiamen.ha2ts4.41,c=222.76.214.34

<!DOCTYPE html>
<!-- [ published at 2018-07-02 17:20:00 ] -->
<html>
<head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <title>新浪首頁</title>
    <meta name="keywords" content="新浪,新浪網(wǎng),SINA,sina,sina.com.cn,新浪首頁,門戶,資訊" />
    <meta name="description" content="新浪網(wǎng)為全球用戶24小時提供全面及時的中文資訊，內(nèi)容覆蓋國內(nèi)外突發(fā)新聞事件、體壇賽事、娛樂時尚、產(chǎn)業(yè)資訊、實(shí)用信息等，設(shè)有新聞、體育、娛樂、財經(jīng)、科技、房產(chǎn)、汽車等30多個內(nèi)容頻道，同時開設(shè)博客、視頻、論壇等自由互動交流空間。" />
    <link rel="mask-icon" sizes="any"  color="red">
    <meta name="stencil" content="PGLS000022" />
...

  • Response包中的第一行叫做狀態(tài)行，由HTTP協(xié)議版本號、狀態(tài)碼、狀態(tài)消息三部分組成

  • 狀態(tài)碼用來告訴HTTP客戶端，HTTP服務(wù)器是否產(chǎn)生了預(yù)期的Response。HTTP/1.1協(xié)議中定義了5類狀態(tài)碼，第一個數(shù)字定義了響應(yīng)的類別

    • 1XX：提示信息-表示請求已被成功接收，繼續(xù)處理
    • 2XX：成功 。表示請求已被成功接收，理解，接收
    • 3XX: 重定向：要完成請求必須進(jìn)行更進(jìn)一步的處理
    • 4XX：客戶端錯誤：請求語法錯誤或者是請求無法實(shí)現(xiàn)
    • 5XX：服務(wù)器錯誤，服務(wù)器未能夠?qū)崿F(xiàn)合法的請求

  • 當(dāng)輸入的簡書的地址為http://www.itdecent.cn/的時候，狀態(tài)碼為301

    image.png

  • 301 Moved Permanently
    被請求的資源已永久移動到新位置，并且將來任何對此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個 URI 之一。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動把請求的地址修改為從服務(wù)器反饋回來的地址

  • 使用網(wǎng)易云在聽歌的時候


    image.png

  • 206 Partial Content
    服務(wù)器已經(jīng)成功處理了部分 GET 請求。類似于 FlashGet 或者迅雷這類的 HTTP下載工具都是使用此類響應(yīng)實(shí)現(xiàn)斷點(diǎn)續(xù)傳或者將一個大文檔分解為多個下載段同時下載

HTTP協(xié)議是無狀態(tài)的和Connection: keep-alive的區(qū)別

  • 無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。
  • HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（面對無連接）。
  • 從HTTP/1.1起，默認(rèn)都開啟了Keep-Alive保持連接特性，簡單地說，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的TCP連接。
  • Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同服務(wù)器軟件（如Apache）中設(shè)置這個時間。
一次請求的request和response
  • 一次URL請求但是左邊欄里面為什么會有那么多的資源請求？
    • 這個就是瀏覽器的一個功能，第一次請求url，服務(wù)器端返回的是html頁面，然后瀏覽器開始渲染HTML：當(dāng)解析到HTML DOM里面的圖片連接，css腳本和js腳本的鏈接，瀏覽器就會自動發(fā)起一個請求靜態(tài)資源的HTTP請求，獲取相對應(yīng)的靜態(tài)資源，然后瀏覽器就會渲染出來，最終將所有資源整合、渲染，完整展現(xiàn)在我們面前的屏幕上。
  • 最后說明一點(diǎn) ：網(wǎng)頁優(yōu)化方面有一項(xiàng)措施是減少HTTP請求次數(shù)，就是把盡量多的css和js資源合并在一起，目的是盡量減少網(wǎng)頁請求靜態(tài)資源的次數(shù)，提高網(wǎng)頁加載速度，同時減緩服務(wù)器的壓力。
  • 鑒于本人的能力有限，如有錯誤還望指出，tks
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容