這個(gè)問題是檢驗(yàn)web和計(jì)網(wǎng)學(xué)習(xí)程度的經(jīng)典問題。

網(wǎng)站訪問流程：

1.域名->ip地址

1) 在輸入完一個(gè)域名之后，首先是檢查瀏覽器自身的DNS緩存是否有相應(yīng)IP地址映射，如果沒有對(duì)應(yīng)的解析記錄，瀏覽器會(huì)查找本機(jī)的hosts配置文件（一般是C:\Windows\System32\drivers\etc\hosts，這個(gè)文件是用于在操作系統(tǒng)級(jí)別上主機(jī)名和IP地址的映射。在這個(gè)文件中，可以手動(dòng)添加自定義的主機(jī)名和對(duì)應(yīng)的IP地址，當(dāng)操作系統(tǒng)進(jìn)行域名解析時(shí)，會(huì)首先查找hosts文件，如果找到匹配的主機(jī)名，就會(huì)直接使用對(duì)應(yīng)的IP地址進(jìn)行訪問，而不再通過DNS進(jìn)行解析）。

?hosts文件中的映射關(guān)系優(yōu)先級(jí)比DNS解析高。如果在hosts文件中有映射關(guān)系，瀏覽器會(huì)直接使用該映射關(guān)系中的IP地址進(jìn)行訪問

2) 如果以上都沒有查到，才進(jìn)行DNS解析。

a.在進(jìn)行DNS解析時(shí)，首先會(huì)檢查本地DNS緩存中是否存在對(duì)應(yīng)的解析結(jié)果。如果已經(jīng)存在，則直接使用緩存中的結(jié)果，不再向遠(yuǎn)程DNS服務(wù)器發(fā)送查詢請(qǐng)求。

如果本地DNS服務(wù)器緩存中沒有對(duì)應(yīng)的解析記錄，則本地DNS服務(wù)器會(huì)向根DNS服務(wù)器發(fā)起遞歸查詢請(qǐng)求。

• Windows DNS客戶端服務(wù)會(huì)在解析域名時(shí)自動(dòng)將域名解析的結(jié)果存儲(chǔ)在本地DNS緩存中，以便在后續(xù)的請(qǐng)求中能夠快速獲取解析結(jié)果，提高解析的速度和效率。存儲(chǔ)在本地DNS緩存中的解析記錄包括域名和對(duì)應(yīng)的IP地址。本地DNS緩存的域名解析記錄存儲(chǔ)在Windows DNS客戶端服務(wù)（DNS Client Service）管理的緩存數(shù)據(jù)庫中，不是一個(gè)特定的文件。該緩存位于系統(tǒng)內(nèi)存中，而不是磁盤上的文件。
• 解析記錄的存儲(chǔ)時(shí)間是有限的，具體的存活時(shí)間由服務(wù)器的TTL（Time-to-Live）時(shí)間決定。TTL是DNS服務(wù)器在返回解析結(jié)果時(shí)附加的一個(gè)時(shí)間值，表示該解析結(jié)果的有效生命周期。一般情況下，解析記錄的存活時(shí)間為TTL值減去DNS查詢的耗時(shí)。
• 當(dāng)解析記錄的存活時(shí)間過期后，下一次需要解析該域名時(shí)，DNS客戶端服務(wù)會(huì)重新發(fā)送解析請(qǐng)求給DNS解析器，并更新本地DNS緩存中的解析記錄。因此，本地DNS緩存中的解析記錄是動(dòng)態(tài)的，會(huì)根據(jù)TTL值進(jìn)行自動(dòng)更新。
• Windows系統(tǒng)中，可以通過命令行ipconfig /displaydns執(zhí)行以下命令來顯示本地DNS緩存的詳細(xì)信息：
• 

b.如果本地DNS服務(wù)器緩存中沒有對(duì)應(yīng)的解析記錄，瀏覽器會(huì)向由你的網(wǎng)絡(luò)服務(wù)提供商（ISP，如中國(guó)移動(dòng)中國(guó)電信等）提供的DNS服務(wù)器發(fā)起解析請(qǐng)求（除了ISP提供，也可以是組織內(nèi)部建立的DNS服務(wù)器），傳遞需要解析的域名給這個(gè)DNS服務(wù)器。?

• 這個(gè)DNS服務(wù)器稱為本地DNS服務(wù)器，它是用戶主機(jī)在進(jìn)行域名解析時(shí)的第一站，它會(huì)查找自己的緩存，看是否存在對(duì)應(yīng)的解析記錄，如果沒有，則本地DNS服務(wù)器會(huì)向根DNS服務(wù)器發(fā)起遞歸查詢請(qǐng)求。
• 根DNS服務(wù)器是互聯(lián)網(wǎng)域名系統(tǒng)（DNS）的最高層級(jí)服務(wù)器，它存儲(chǔ)了所有頂級(jí)域名（如.com、.net、.org等）的DNS記錄。根DNS服務(wù)器的作用是將域名解析請(qǐng)求轉(zhuǎn)發(fā)到下一級(jí)的DNS服務(wù)器。本地DNS服務(wù)器將結(jié)果返回給用戶主機(jī)，用戶主機(jī)操作系統(tǒng)接收到DNS解析器返回的結(jié)果后，將結(jié)果存儲(chǔ)到本地DNS緩存中，并將IP地址返回給瀏覽器。
• 完成域名解析過程。

2.瀏覽器根據(jù)解析得到的IP地址，與服務(wù)器建立TCP連接

瀏覽器通過DNS解析獲取到目標(biāo)服務(wù)器的IP地址之后，使用TCP的三次握手來確保連接的可靠性。

1. 瀏覽器向目標(biāo)服務(wù)器發(fā)起連接請(qǐng)求（SYN包），其中包含自己的初始序列號(hào)。
2. 目標(biāo)服務(wù)器接收到連接請(qǐng)求后，會(huì)回復(fù)一個(gè)確認(rèn)連接請(qǐng)求的ACK包，其中包含自己的初始序列號(hào)和對(duì)瀏覽器初始序列號(hào)的確認(rèn)。
3. 瀏覽器收到目標(biāo)服務(wù)器的ACK包后，會(huì)向目標(biāo)服務(wù)器發(fā)送一個(gè)確認(rèn)ACK包，同時(shí)會(huì)發(fā)送自己所期望的下一個(gè)序列號(hào)。
4. 目標(biāo)服務(wù)器收到瀏覽器的確認(rèn)ACK包后，連接建立成功，可以開始進(jìn)行數(shù)據(jù)傳輸。

     瀏覽器                              目標(biāo)服務(wù)器
         -------------- SYN包 -------------->
         <--------------ACK包 (對(duì)SYN的確認(rèn)，以及自己的序列號(hào))
         -------------- ACK包 -------------->

   三次握手的目的是確保雙方都能正確接收到對(duì)方的連接請(qǐng)求和確認(rèn)，以建立一個(gè)可靠的連接。在握手過程中，雙方交換了初始序列號(hào)，這是為了后續(xù)的數(shù)據(jù)傳輸進(jìn)行序列號(hào)的管理和確認(rèn)。

5. 思考：三次握手是什么，為什么嗎，為什么不多或者少次數(shù)？

1. 為什么不是兩次?

防止已失效的連接請(qǐng)求被服務(wù)器接受：如果握手只進(jìn)行兩次，客戶端發(fā)出的連接請(qǐng)求可能會(huì)在網(wǎng)絡(luò)中因?yàn)檠舆t而被延遲到達(dá)服務(wù)器，而服務(wù)器此時(shí)可能會(huì)誤認(rèn)為該連接請(qǐng)求是新的有效請(qǐng)求而接受，從而導(dǎo)致資源浪費(fèi)。通過第三次握手，服務(wù)器可以確認(rèn)客戶端確實(shí)發(fā)送了連接請(qǐng)求，并且是之前沒有成功建立連接的請(qǐng)求，從而避免了上述情況。

如果只進(jìn)行兩次握手，客戶端發(fā)出連接請(qǐng)求后，服務(wù)器已經(jīng)接受并且發(fā)送了確認(rèn)，此時(shí)連接就會(huì)建立起來。但是可能因?yàn)榫W(wǎng)絡(luò)問題，客戶端并沒有收到服務(wù)器發(fā)出的確認(rèn)，此時(shí)客戶端可能會(huì)錯(cuò)誤地認(rèn)為連接已經(jīng)建立成功，開始向服務(wù)器發(fā)送數(shù)據(jù)。但是，由于服務(wù)器并沒有收到連接請(qǐng)求的確認(rèn)，服務(wù)器會(huì)拒絕接受這些數(shù)據(jù)。

? ? ? ? 2.為什么不是更多次？更多次會(huì)更安全可靠嗎？

增加TCP連接握手的次數(shù)并不一定會(huì)使連接更加可靠和安全。在基于TCP的網(wǎng)絡(luò)通信中，通過三次握手已經(jīng)可以提供足夠的可靠性和安全性，再增加握手的次數(shù)可能帶來以下問題：

• 延遲：每次握手都需要一定的時(shí)間，多次握手意味著增加了連接建立的時(shí)間。這會(huì)導(dǎo)致連接建立的延遲，尤其是在高延遲的網(wǎng)絡(luò)環(huán)境中。

• 資源消耗：更多的握手意味著更多的資源消耗，包括計(jì)算資源和網(wǎng)絡(luò)帶寬。這可能會(huì)對(duì)系統(tǒng)性能和網(wǎng)絡(luò)負(fù)載產(chǎn)生不利影響。

• 可擴(kuò)展性差：如果連接過程需要更多的握手，對(duì)于網(wǎng)絡(luò)中的大量并發(fā)連接來說，可能會(huì)導(dǎo)致連接請(qǐng)求超時(shí)、資源耗盡和連接失敗等問題。

此外，增加握手次數(shù)并不能完全解決網(wǎng)絡(luò)安全問題。握手過程主要用于建立連接，而不是用于加密和認(rèn)證數(shù)據(jù)的安全傳輸。在實(shí)際應(yīng)用中，通常需要使用其他的安全機(jī)制，如TLS/SSL來加密數(shù)據(jù)和進(jìn)行身份驗(yàn)證。TCP連接采用三次握手是為了在保持較高性能和較低延遲的同時(shí)提供基本的可靠性和安全性，不是通過增加握手次數(shù)來提高可靠性和安全性。

3.建立連接后，瀏覽器發(fā)送請(qǐng)求,服務(wù)器處理請(qǐng)求

建立連接后，用戶的請(qǐng)求會(huì)發(fā)送給本地網(wǎng)絡(luò)中的網(wǎng)關(guān)設(shè)備，網(wǎng)關(guān)會(huì)根據(jù)目標(biāo)服務(wù)器的IP地址和本地網(wǎng)絡(luò)的路由表來選擇到達(dá)目標(biāo)服務(wù)器的下一跳。網(wǎng)關(guān)會(huì)檢查請(qǐng)求的目標(biāo)IP地址，然后查找本地網(wǎng)絡(luò)的路由表，確定該請(qǐng)求需要通過哪個(gè)接口發(fā)送出去，經(jīng)過一系列路由的選擇，最終到達(dá)目標(biāo)服務(wù)器（當(dāng)用戶主機(jī)與服務(wù)器位于同一個(gè)局域網(wǎng)或子網(wǎng)中時(shí)，用戶主機(jī)可以直接與服務(wù)器建立連接，不需要經(jīng)過網(wǎng)關(guān)或路由器。在這種情況下，用戶主機(jī)會(huì)通過ARP（Address Resolution Protocol，地址解析協(xié)議）獲取目標(biāo)服務(wù)器的MAC地址，直接發(fā)送數(shù)據(jù)包到目標(biāo)服務(wù)器）。

請(qǐng)求包括：

• 請(qǐng)求方法（Get，Post，HEAD，DELETE，PUT，TRACT…）
• 請(qǐng)求URL（包含主機(jī)名、路徑等）
• 請(qǐng)求頭部（包括用戶代理、語言、內(nèi)容類型、Cookie等）
• 請(qǐng)求正文（POST請(qǐng)求時(shí)包含表單數(shù)據(jù)等）

Accept: //告訴服務(wù)器它所支持的數(shù)據(jù)類型
Accept-Encoding: //支持哪種編碼格式：GBK，UTF-8，GB2312，ISO8859-1
Accept-Language: //告訴服務(wù)器它的語言環(huán)境
Cache-Control: //緩存控制
Connection: //告訴服務(wù)器，請(qǐng)求完成是斷開還是保持連接
HOST: //主機(jī)
...

思考：GET和POST請(qǐng)求區(qū)別？

GET：一次請(qǐng)求可以攜帶的參數(shù)比較少，大小有限制，會(huì)在瀏覽器的URL地址欄顯示數(shù)據(jù)內(nèi)容，不安全，但高效。
POST：一次請(qǐng)求可以攜帶的參數(shù)沒有限制，大小沒有限制，不會(huì)在瀏覽器的URL地址欄顯示數(shù)據(jù)內(nèi)容，安全，但不高效。

TCP就像汽車，我們用TCP來運(yùn)輸數(shù)據(jù)，它很可靠，從來不會(huì)發(fā)生丟件少件的現(xiàn)象。但是如果路上跑的全是看起來一模一樣的汽車，那這個(gè)世界看起來是一團(tuán)混亂，送急件的汽車可能被前面滿載貨物的汽車攔堵在路上，整個(gè)交通系統(tǒng)一定會(huì)癱瘓。為了避免這種情況發(fā)生，交通規(guī)則HTTP誕生了。HTTP給汽車運(yùn)輸設(shè)定了好幾個(gè)服務(wù)類別，有GET, POST, PUT, DELETE等等一共8類，HTTP規(guī)定，當(dāng)執(zhí)行GET請(qǐng)求的時(shí)候，要給汽車貼上GET的標(biāo)簽（設(shè)置method為GET），而且要求把傳送的數(shù)據(jù)放在車頂上（url中）以方便記錄。如果是POST請(qǐng)求，就要在車上貼上POST的標(biāo)簽，并把貨物放在車廂里。

還有另一個(gè)重要的角色：運(yùn)輸公司。不同的瀏覽器（發(fā)起http請(qǐng)求）和服務(wù)器（接受http請(qǐng)求）就是不同的運(yùn)輸公司。 雖然理論上，你可以在車頂上無限的堆貨物（url中無限加參數(shù)）。但是運(yùn)輸公司可不傻，裝貨和卸貨也是有很大成本的，他們會(huì)限制單次運(yùn)輸量來控制風(fēng)險(xiǎn)，數(shù)據(jù)量太大對(duì)瀏覽器和服務(wù)器都是很大負(fù)擔(dān)。如果你用GET服務(wù)，在request body偷偷藏了數(shù)據(jù)，不同服務(wù)器的處理方式也是不同的，有些服務(wù)器會(huì)幫你卸貨，讀出數(shù)據(jù)，有些服務(wù)器直接忽略，所以，雖然GET可以帶request body，也不能保證一定能被接收到。

總結(jié)：HTTP只是個(gè)行為準(zhǔn)則，HTTP的底層是TCP/IP，所以可以理解為GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP鏈接。GET和POST能做的事情從本質(zhì)上說是一樣的。

傳輸數(shù)據(jù)方式存在區(qū)別：

傳送方式：get通過地址欄傳輸，post通過報(bào)文傳輸(request body)。

get方式的安全性較Post方式要差些，包含機(jī)密信息的話，建議用Post數(shù)據(jù)提交方式，在做數(shù)據(jù)查詢時(shí)，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時(shí)，建議用Post方式。

傳送長(zhǎng)度：get有長(zhǎng)度限制，一般限制在 2kb 左右；post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。 get和post的傳送數(shù)據(jù)大小跟各個(gè)瀏覽器、操作系統(tǒng)以及服務(wù)器的限制有關(guān)。

因?yàn)镚ET是通過URL提交數(shù)據(jù)，那么GET可提交的數(shù)據(jù)量就跟URL的長(zhǎng)度有直接關(guān)系 了。而實(shí)際上，URL不存在參數(shù)上限的問題，HTTP協(xié)議規(guī)范沒有對(duì)URL長(zhǎng)度進(jìn)行限制。這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制。IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2KB+35)。用apache測(cè)試，使用get方式，url最長(zhǎng)可達(dá)8167b。

get請(qǐng)求的過程：

（1）瀏覽器請(qǐng)求tcp連接（第一次握手）

（2）服務(wù)器答應(yīng)進(jìn)行tcp連接（第二次握手）

（3）瀏覽器確認(rèn)，并發(fā)送get請(qǐng)求頭和數(shù)據(jù)（第三次握手，這個(gè)報(bào)文比較小，所以http會(huì)在此時(shí)進(jìn)行第一次數(shù)據(jù)發(fā)送）

（4）服務(wù)器返回200 OK響應(yīng)

而對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。

post請(qǐng)求的過程：

（1）瀏覽器請(qǐng)求tcp連接（第一次握手）

（2）服務(wù)器答應(yīng)進(jìn)行tcp連接（第二次握手）

（3）瀏覽器確認(rèn)，并發(fā)送post請(qǐng)求頭（第三次握手，這個(gè)報(bào)文比較小，所以http會(huì)在此時(shí)進(jìn)行第一次數(shù)據(jù)發(fā)送）

（4）服務(wù)器返回100 Continue響應(yīng)

（5）瀏覽器發(fā)送數(shù)據(jù)

（6）服務(wù)器返回200 OK響應(yīng)

服務(wù)器處理請(qǐng)求：

• 服務(wù)器接收到HTTP請(qǐng)求后，會(huì)根據(jù)請(qǐng)求的內(nèi)容進(jìn)行處理。這可能包括查詢數(shù)據(jù)庫、讀取文件、執(zhí)行程序等。
• 服務(wù)器處理完請(qǐng)求后，生成一個(gè)HTTP響應(yīng)，包括響應(yīng)行（如狀態(tài)碼）、響應(yīng)頭部和響應(yīng)正文（所請(qǐng)求的資源）。

Session、Cookie和Token：

HTTP協(xié)議本身是無狀態(tài)的。什么是無狀態(tài)呢，即服務(wù)器無法判斷用戶身份。

什么是cookie

cookie是由Web服務(wù)器保存在用戶瀏覽器上的小文件（key-value格式），包含用戶相關(guān)的信息?？蛻舳讼蚍?wù)器發(fā)起請(qǐng)求，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個(gè)Cookie?？蛻舳藶g覽器會(huì)把Cookie保存起來。當(dāng)瀏覽器再請(qǐng)求該網(wǎng)站時(shí)，瀏覽器把請(qǐng)求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶身份。

什么是session

session是依賴Cookie實(shí)現(xiàn)的。session是服務(wù)器端對(duì)象

session 是瀏覽器和服務(wù)器會(huì)話過程中，服務(wù)器分配的一塊儲(chǔ)存空間。服務(wù)器默認(rèn)為瀏覽器在cookie中設(shè)置 sessionid，瀏覽器在向服務(wù)器請(qǐng)求過程中傳輸 cookie 包含 sessionid ，服務(wù)器根據(jù) sessionid 獲取出會(huì)話中存儲(chǔ)的信息，然后確定會(huì)話的身份信息。

cookie與session區(qū)別

存儲(chǔ)位置與安全性：cookie數(shù)據(jù)存放在客戶端上，安全性較差，session數(shù)據(jù)放在服務(wù)器上，安全性相對(duì)更高；

存儲(chǔ)空間：?jiǎn)蝹€(gè)cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie，session無此限制

占用服務(wù)器資源：session一定時(shí)間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多，占用服務(wù)器性能，考慮到服務(wù)器性能方面，應(yīng)當(dāng)使用cookie。

什么是Token

Token的引入：Token是在客戶端頻繁向服務(wù)端請(qǐng)求數(shù)據(jù)，服務(wù)端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進(jìn)行對(duì)比，判斷用戶名和密碼正確與否，并作出相應(yīng)提示，在這樣的背景下，Token便應(yīng)運(yùn)而生。

Token的定義：Token是服務(wù)端生成的一串字符串，以作客戶端進(jìn)行請(qǐng)求的一個(gè)令牌，當(dāng)?shù)谝淮蔚卿浐?，服?wù)器生成一個(gè)Token便將此Token返回給客戶端，以后客戶端只需帶上這個(gè)Token前來請(qǐng)求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。

使用Token的目的：Token的目的是為了減輕服務(wù)器的壓力，減少頻繁的查詢數(shù)據(jù)庫，使服務(wù)器更加健壯。

Token 是在服務(wù)端產(chǎn)生的。如果前端使用用戶名/密碼向服務(wù)端請(qǐng)求認(rèn)證，服務(wù)端認(rèn)證成功，那么在服務(wù)端會(huì)返回 Token 給前端。前端可以在每次請(qǐng)求的時(shí)候帶上 Token 證明自己的合法地位

session與token區(qū)別

session機(jī)制存在服務(wù)器壓力增大，CSRF跨站偽造請(qǐng)求攻擊，擴(kuò)展性不強(qiáng)等問題；

session存儲(chǔ)在服務(wù)器端，token存儲(chǔ)在客戶端

token提供認(rèn)證和授權(quán)功能，作為身份認(rèn)證，token安全性比session好；

session這種會(huì)話存儲(chǔ)方式方式只適用于客戶端代碼和服務(wù)端代碼運(yùn)行在同一臺(tái)服務(wù)器上，token適用于項(xiàng)目級(jí)的前后端分離（前后端代碼運(yùn)行在不同的服務(wù)器下）。

瀏覽器解析服務(wù)器的HTTP相應(yīng)：

1. 渲染頁面：
   a. 瀏覽器開始解析HTML響應(yīng)內(nèi)容，逐步構(gòu)建DOM樹（文檔對(duì)象模型）。當(dāng)解析到外部資源（如CSS和JavaScript）時(shí)，瀏覽器會(huì)發(fā)送額外的HTTP請(qǐng)求去獲取這些資源。
   b. 瀏覽器使用CSS解析器對(duì)頁面進(jìn)行樣式計(jì)算，并生成渲染樹。
   c. 瀏覽器進(jìn)行布局和繪制過程，將頁面元素?cái)[放在正確的位置，并根據(jù)樣式信息繪制頁面。

2. 顯示頁面：
   a. 瀏覽器將繪制好的頁面內(nèi)容顯示在瀏覽器窗口中，用戶可以看到頁面并與頁面進(jìn)行交互。

HTTP/1.0和HTTP/2.0在用戶主機(jī)與服務(wù)器建立連接方面有以下差異：

• 連接復(fù)用（Multiplexing）：HTTP/1.0是無狀態(tài)的，使用簡(jiǎn)單的請(qǐng)求-響應(yīng)模式，每個(gè)請(qǐng)求需要?jiǎng)?chuàng)建一個(gè)新的連接，在響應(yīng)完成后會(huì)自動(dòng)斷開TCP連接，導(dǎo)致大量延遲。而HTTP2.0使用多路復(fù)用技術(shù)，可以在單個(gè)TCP連接上同時(shí)發(fā)送多個(gè)請(qǐng)求和響應(yīng)，減少了連接建立的開銷。 1.0采用的是單向請(qǐng)求-響應(yīng)模式，即每個(gè)請(qǐng)求只能對(duì)應(yīng)一個(gè)響應(yīng)，請(qǐng)求和響應(yīng)是一一對(duì)應(yīng)的關(guān)系。2.0引入了Server Push機(jī)制，服務(wù)器可以在客戶端請(qǐng)求之前主動(dòng)推送相關(guān)資源，避免了客戶端重復(fù)請(qǐng)求的等待時(shí)間，提高了頁面加載速度。
• 頭部壓縮（Header Compression）：HTTP/1.0中的頭部信息沒有壓縮，每次請(qǐng)求都會(huì)重復(fù)發(fā)送頭部信息，增加了數(shù)據(jù)傳輸?shù)拈_銷。而HTTP/2.0使用HPACK壓縮算法對(duì)頭部信息進(jìn)行了壓縮，減少了數(shù)據(jù)傳輸?shù)拇笮　?/li>
• 優(yōu)先級(jí)和流控制（Request Prioritization）：HTTP/2.0引入了流的概念，可以將請(qǐng)求和響應(yīng)切分成多個(gè)流進(jìn)行處理，每個(gè)流都可以設(shè)置優(yōu)先級(jí)和流控制。這樣可以保證重要的請(qǐng)求優(yōu)先處理，提高了頁面加載的速度和性能。
• 服務(wù)器推送（Server Push）：http/1.0 中，客戶端需要明確請(qǐng)求服務(wù)器才能獲取資源。，而HTTP/2.0支持服務(wù)器主動(dòng)推送資源，服務(wù)器可以在客戶端請(qǐng)求之前主動(dòng)推送資源到客戶端緩存，提高頁面加載速度。
• 二進(jìn)制分幀（Binary framing）：HTTP/1.0使用文本協(xié)議，而HTTP/2.0使用二進(jìn)制協(xié)議進(jìn)行傳輸。二進(jìn)制協(xié)議更加高效，解析速度更快，并且可以采用二進(jìn)制壓縮和加密算法。

在整個(gè)過程中，還包括了一些優(yōu)化措施，如緩存機(jī)制（瀏覽器會(huì)緩存靜態(tài)資源，如圖片、CSS和JavaScript），以及一些安全機(jī)制（如HTTPS的加密通信）。。每個(gè)步驟都有其特定的協(xié)議和規(guī)范，以保證數(shù)據(jù)的傳輸和交互的可靠性、安全性和效率。

不準(zhǔn)確的地方懇請(qǐng)指正~文章來源地址http://www.zghlxwxcb.cn/news/detail-627051.html

到了這里，關(guān)于網(wǎng)站是如何進(jìn)行訪問的？在瀏覽器地址欄輸入網(wǎng)址并回車的一瞬間到頁面能夠展示回來，經(jīng)歷了什么？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！