[[422375]]

一.TCP/IP 網(wǎng)絡(luò)模型有幾層?分別有什么用?

TCP/IP網(wǎng)絡(luò)模型總共有五層

1.應(yīng)用層:我們能接觸到的就是應(yīng)用層了，手機(jī)，電腦這些這些設(shè)備都屬于應(yīng)用層。

2.傳輸層:就是為應(yīng)用層提供網(wǎng)絡(luò)支持的，當(dāng)設(shè)備作為接收⽅時(shí)，傳輸層則要負(fù)責(zé)把數(shù)據(jù)包傳給應(yīng)⽤，但是⼀臺(tái)設(shè)備上可能會(huì)有很多應(yīng)⽤在接收或者傳輸數(shù)據(jù)，因此需要⽤⼀個(gè)編號(hào)將應(yīng)⽤區(qū)分開(kāi)來(lái)，這個(gè)編號(hào)就是端⼝。所以 TCP 和 UDP 協(xié)議就是在這一層的

3.網(wǎng)絡(luò)層:是負(fù)責(zé)傳輸數(shù)據(jù)的，最常使用的 ip 協(xié)議就在該層，⽹絡(luò)層負(fù)責(zé)將數(shù)據(jù)從⼀個(gè)設(shè)備傳輸?shù)搅?#12032;個(gè)設(shè)備，世界上有很多設(shè)備，⽹絡(luò)層需要有區(qū)分設(shè)備的編號(hào)。我們⼀般⽤ IP 地址給設(shè)備進(jìn)⾏編號(hào)

4.數(shù)據(jù)鏈路層:每⼀臺(tái)設(shè)備的⽹卡都會(huì)有⼀個(gè) MAC 地址，它就是⽤來(lái)唯⼀標(biāo)識(shí)設(shè)備的。路由器計(jì)算出了下⼀個(gè)⽬的地 IP 地址，再通過(guò) ARP 協(xié)議找到該⽬的地的 MAC 地址，這樣就知道這個(gè) IP 地址是哪個(gè)設(shè)備的了。路由器就是通過(guò)數(shù)據(jù)鏈路層來(lái)知道這個(gè) ip 地址是屬于哪個(gè)設(shè)備的，它主要為⽹絡(luò)層提供鏈路級(jí)別傳輸?shù)姆?wù)。

5.物理層:當(dāng)數(shù)據(jù)準(zhǔn)備要從設(shè)備發(fā)送到⽹絡(luò)的時(shí)候，需要把數(shù)據(jù)包轉(zhuǎn)換成電信號(hào)，讓其可以在物理介質(zhì)中傳輸，它主要是為數(shù)據(jù)鏈路層提供⼆進(jìn)制傳輸?shù)姆?wù)。

二.介紹一下 HTTP 協(xié)議吧

HTTP 協(xié)議是基于 TCP 協(xié)議實(shí)現(xiàn)的，它是一個(gè)超文本傳輸協(xié)議，其實(shí)就是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議，它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。

它主要是負(fù)責(zé)點(diǎn)對(duì)點(diǎn)之間通信的。

超文本就是用超鏈接的方法，將各種不同空間的文字信息組織在一起的網(wǎng)狀文本。比如說(shuō)html，內(nèi)部定義了很多圖片視頻的鏈接，放在瀏覽器上就呈現(xiàn)出了畫(huà)面。

協(xié)議就是約定俗稱的東西，比如說(shuō) moon 要給讀者送一本書(shū)，讀者那里只接受順豐快遞，那么 moon 覺(jué)得可以，發(fā)快遞的時(shí)候選擇的順豐，那么我們彼此之間共同約定好的就叫做協(xié)議。

傳輸這個(gè)就很好理解了，比如剛才舉的例子，將書(shū)發(fā)給讀者，要通過(guò)騎車或者飛機(jī)的方式，傳遞的這個(gè)過(guò)程就是運(yùn)輸。

三.GET 和 POST有什么區(qū)別?

GET 和 POST 本質(zhì)上就是 TCP 鏈接，并無(wú)差別。

但是由于 HTTP 的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們?cè)趹?yīng)用過(guò)程中體現(xiàn)出一些不同。

四.PING 的作用?

PING 主要的作用就是測(cè)試在兩臺(tái)主機(jī)之間能否建立連接，如果 PING 不通就無(wú)法建立連接。

它其實(shí)就是向目的主機(jī)發(fā)送多個(gè) ICMP 回送請(qǐng)求報(bào)文

• 如果沒(méi)有響應(yīng)則無(wú)法建立連接
• 如果有響應(yīng)就可以根據(jù)目的主機(jī)返回的回送報(bào)文的時(shí)間和成功響應(yīng)的次數(shù)估算出數(shù)據(jù)包往返時(shí)間及丟包率

五.常見(jiàn)的 HTTP 狀態(tài)碼有哪些

六.HTTP1.1 和 HTTP1.0 的區(qū)別有哪些?

1.長(zhǎng)鏈接

早期 HTTP1.0 的每一次請(qǐng)求都伴隨著一次三次握手的過(guò)程，并且是串行的請(qǐng)求，增加了不必要的性能開(kāi)銷

HTTP1.1 新增了長(zhǎng)鏈接的通訊方式，減少了性能損耗

2.管道

HTTP1.0 只有串行發(fā)送，沒(méi)有管道

HTTP1.1 增加了管道的概念，使得在同一個(gè) TCP 鏈接當(dāng)中可以同時(shí)發(fā)出多個(gè)請(qǐng)求

3.斷點(diǎn)續(xù)傳

HTTP1.0 不支持?jǐn)帱c(diǎn)續(xù)傳

HTTP1.1 新增了 range 字段，用來(lái)指定數(shù)據(jù)字節(jié)位置，開(kāi)啟了斷點(diǎn)續(xù)傳的時(shí)代

4.Host頭處理

HTTP1.0 任務(wù)主機(jī)只有一個(gè)節(jié)點(diǎn)，所以并沒(méi)有傳 HOST

HTTP1.1 時(shí)代，虛擬機(jī)技術(shù)越來(lái)越發(fā)達(dá)，一臺(tái)機(jī)器上也有可能有很多節(jié)點(diǎn)，故增加了 HOST 信息

5.緩存處理

在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)

HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略。

6.錯(cuò)誤狀態(tài)響應(yīng)碼

在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如410(Gone)表示服務(wù)器上的某個(gè)資源被永久性的刪除等。

七.HTTPS 和 HTTP 的區(qū)別是什么?

1.SSL安全協(xié)議

HTTP 是超⽂本傳輸協(xié)議，信息是明⽂傳輸，存在安全⻛險(xiǎn)的問(wèn)題。

HTTPS 則解決 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹絡(luò)層之間加⼊了 SSL/TLS 安全協(xié)議，使得報(bào)⽂能夠加密傳輸。

2.建立連接

HTTP 連接建⽴相對(duì)簡(jiǎn)單， TCP 三次握⼿之后便可進(jìn)⾏ HTTP 的報(bào)⽂傳輸。

HTTPS 在 TCP 三次握⼿之后，還需進(jìn)⾏ SSL/TLS 的握⼿過(guò)程，才可進(jìn)⼊加密報(bào)⽂傳輸。

3.端口號(hào)

HTTP 的端⼝號(hào)是 80。

HTTPS 的端⼝號(hào)是 443。

4.CA證書(shū)

HTTPS 協(xié)議需要向 CA(證書(shū)權(quán)威。機(jī)構(gòu))申請(qǐng)數(shù)字證書(shū)來(lái)保證服務(wù)器的身份是可信的。

八.HTTP2 和 HTTP1.1 的區(qū)別是什么?

1.頭部壓縮

在 HTTP2 當(dāng)中，如果你發(fā)出了多個(gè)請(qǐng)求，并且它們的頭部(header)是相同的，那么 HTTP2 協(xié)議會(huì)幫你消除同樣的部分。(其實(shí)就是在客戶端和服務(wù)端維護(hù)一張索引表來(lái)實(shí)現(xiàn))

2.二進(jìn)制格式

HTTP1.1 采用明文的形式

HTTP/2 全⾯采⽤了⼆進(jìn)制格式，頭信息和數(shù)據(jù)體都是⼆進(jìn)制

3.數(shù)據(jù)流

HTTP/2 的數(shù)據(jù)包不是按順序發(fā)送的，同⼀個(gè)連接⾥⾯連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)。(對(duì)數(shù)據(jù)包做了標(biāo)記，標(biāo)志其屬于哪一個(gè)請(qǐng)求，其中規(guī)定客戶端發(fā)出的數(shù)據(jù)流編號(hào)為奇數(shù)，服務(wù)器發(fā)出的數(shù)據(jù)流編號(hào)為偶數(shù)?？蛻舳诉€可以指定數(shù)據(jù)流的優(yōu)先級(jí)，優(yōu)先級(jí)⾼的請(qǐng)求，服務(wù)器就先響應(yīng)該請(qǐng)求)

4.IO多路復(fù)用

如:在⼀個(gè)連接中，服務(wù)器收到了客戶端 A 和 B 的兩個(gè)請(qǐng)求，但是發(fā)現(xiàn)在處理 A 的過(guò)程中⾮常耗時(shí)，索性就先回應(yīng) A 已經(jīng)處理好的部分，再接著回應(yīng) B 請(qǐng)求，最后再回應(yīng) A 請(qǐng)求剩下的部分。

HTTP/2 可以在⼀個(gè)連接中并發(fā)多個(gè)請(qǐng)求或回應(yīng)。

5.服務(wù)器推送

服務(wù)器可以主動(dòng)向客戶端發(fā)送請(qǐng)求

九.HTTP3 和 HTTP2 的區(qū)別是什么?

1.協(xié)議不同

HTTP2 是基于 TCP 協(xié)議實(shí)現(xiàn)的

HTTP3 是基于 UDP 協(xié)議實(shí)現(xiàn)的

2.QUIC

HTTP3 新增了 QUIC 協(xié)議來(lái)實(shí)現(xiàn)可靠性的傳輸

3.握手次數(shù)

HTTP2 是基于 HTTPS 實(shí)現(xiàn)的，建立連接需要先進(jìn)行 TCP 3次握手，然后再進(jìn)行 TLS 3次握手，總共6次握手

HTTP3 只需要 QUIC 的3次握手

十.TCP 建立連接的過(guò)程是怎樣的?

第一次握手:A 的 TCP 進(jìn)程創(chuàng)建一個(gè) 傳輸控制塊 TCB ，然后向 B 發(fā)出連接請(qǐng)求報(bào)文段。之后將同步位 SYN 設(shè)置為 1，同時(shí)選擇一個(gè)初始序列號(hào) seq=x，這時(shí)客戶端 A 進(jìn)入到 SYN-SENT(同步已發(fā)送)狀態(tài)。

第二次握手:B 收到連接請(qǐng)求報(bào)文段，如果同意建立連接，則向 A 發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中 同步位 SYN=1、確認(rèn)位 ACK=1、確認(rèn)號(hào) ack=x+1，同時(shí)也為自己選擇一個(gè)初始序列號(hào) seq=y，這時(shí)服務(wù)器 B 進(jìn)入 SYN-RCVID 狀態(tài)。

第三次握手:A 收到 B 的確認(rèn)以后，再向 B 發(fā)出確認(rèn)。確認(rèn)報(bào)文 ACK=1、確認(rèn)號(hào)ack=y+1。這時(shí)A進(jìn)入到 ESTAB-LISHED 狀態(tài)。當(dāng)B接收到A的確認(rèn)后，也進(jìn)入 ESTAB-LISHED 狀態(tài)。連接建立完成

十一.為什么是三次握手???

1.為了防止已經(jīng)失效的連接請(qǐng)求報(bào)文段突然又傳到服務(wù)端，因而產(chǎn)生錯(cuò)誤

如果客戶端連續(xù)發(fā)送多次 SYN 建⽴連接的報(bào)⽂，如果出現(xiàn)了網(wǎng)絡(luò)擁堵，可能會(huì)有舊連接先于新連接到達(dá)的情況，就可能會(huì)出現(xiàn)連接覆蓋，要避免這種情況，最少需要三次握手

2.三次握⼿正好避免資源浪費(fèi)

三次握⼿就已經(jīng)是理論上建立可靠連接的最小次數(shù)了，所以不需要更多的連接

3.同步雙⽅初始序列號(hào)

同步序列號(hào)(可以鑒別重復(fù)數(shù)序，按序接受等)其實(shí)并不要三次握手，只要一來(lái)一回兩次就可以了

十二.TCP 斷開(kāi)連接的過(guò)程是怎樣的?

第一次揮手:A 先發(fā)送連接釋放報(bào)文段，段首部的終止控制位 FIN=1，序號(hào)seq=u(等于A前面發(fā)送數(shù)據(jù)的最后一個(gè)序號(hào)加1);然后 A 進(jìn)入 FIN-WAIT-1(終止等待1)狀態(tài)，等待 B 的確認(rèn)。

第二次揮手:B 收到 A 的連接釋放報(bào)文段后，立刻發(fā)出確認(rèn)報(bào)文段，確認(rèn)號(hào) ack=u+1，序號(hào) seq=v(等于 B 前面發(fā)送數(shù)據(jù)的最后一個(gè)序號(hào)加1);然后 B 進(jìn)入 CLOSE-WAIT(關(guān)閉等待)狀態(tài)。

第三次揮手:A 收到 B 的確認(rèn)報(bào)文段后進(jìn)入到 FIN-WAIT-2(終止等待2)狀態(tài)，繼續(xù)等待 B 發(fā)出連接釋放報(bào)文段;

若 B 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送，B 就會(huì)向 A 發(fā)送連接釋放報(bào)文段，段首部的終止控制位 FIN=1，序號(hào) seq=w(半關(guān)閉狀態(tài)可能又發(fā)送了一些數(shù)據(jù))，確認(rèn)號(hào) ack=u+1，這時(shí)B進(jìn)入 LAST-ACK(最后確認(rèn))狀態(tài)，等待A的確認(rèn)。

第四次揮手:A收到B的連接釋放報(bào)文段并發(fā)出確認(rèn)，確認(rèn)段中 確認(rèn)位 ACK=1，確認(rèn)號(hào) ack=w+1，序號(hào) seq=u+1;然后 A 進(jìn)入到TIME-WAIT(時(shí)間等待)狀態(tài)。當(dāng) B 再接收到該確認(rèn)段后，B 就進(jìn)入 CLOSED 狀態(tài)。

十三.第四次揮手為什么要等待2MSL(60s)

首先 2MSL 的時(shí)間是從客戶端(A)接收到 FIN 后發(fā)送 ACK 開(kāi)始計(jì)時(shí)的。如果在 TIME-WAIT 時(shí)間內(nèi)，因?yàn)榭蛻舳?A)的 ACK 沒(méi)有傳輸?shù)椒?wù)端(B)，客戶端(A)又接收到了服務(wù)端(B)重發(fā)的 FIN 報(bào)文，那么 2MSL 時(shí)間會(huì)被重置。等待 2MSL 原因如下

1.得原來(lái)連接的數(shù)據(jù)包消失

1)如果B沒(méi)有收到自己的ACK，會(huì)超時(shí)重傳FiN那么A再次接到重傳的FIN，會(huì)再次發(fā)送ACK

2)如果B收到自己的ACK，也不會(huì)再發(fā)任何消息，

在最后一次揮手后 A 并不知道 B 是否接到自己的 信息

包括 ACK 是以上哪兩種情況，A 都需要等待，要取這兩種情況等待時(shí)間的最大值，以應(yīng)對(duì)最壞的情況發(fā)生，這個(gè)最壞情況是：去向ACK消息最大存活時(shí)間(MSL) + 來(lái)向FIN消息的最大存活時(shí)間(MSL)。這剛好是2MSL，這個(gè)時(shí)間，足以使得原來(lái)連接的數(shù)據(jù)包在網(wǎng)絡(luò)中消失。

2.保證 ACK 能被服務(wù)端接收到從而正確關(guān)閉鏈接

因?yàn)檫@個(gè) ACK 是有可能丟失的，會(huì)導(dǎo)致服務(wù)器收不到對(duì) FIN-ACK 確認(rèn)報(bào)文。假設(shè)客戶端不等待 2MSL ，而是在發(fā)送完 ACK 之后直接釋放關(guān)閉，一但這個(gè) ACK 丟失的話，服務(wù)器就無(wú)法正常的進(jìn)入關(guān)閉連接狀態(tài)。

十四.為什么是四次揮手?

因?yàn)?tcp 可以在發(fā)送數(shù)據(jù)的同時(shí)也能接受數(shù)據(jù)，要實(shí)現(xiàn)可靠的連接關(guān)閉，A 發(fā)出結(jié)束報(bào)文 FIN，收到 B 確認(rèn)后 A 知道自己沒(méi)有數(shù)據(jù)需要發(fā)送了，B 知道 A 不再發(fā)送數(shù)據(jù)了，自己也不會(huì)接收數(shù)據(jù)了，但是此時(shí) A 還是可以接收數(shù)據(jù)，B 也可以發(fā)送數(shù)據(jù);當(dāng) B 發(fā)出 FIN 報(bào)文的時(shí)候此時(shí)兩邊才會(huì)真正的斷開(kāi)連接，讀寫(xiě)分開(kāi)。

十五.TCP 滑動(dòng)窗⼝是什么?

TCP 是每發(fā)送⼀個(gè)數(shù)據(jù)，都要進(jìn)⾏⼀次確認(rèn)應(yīng)答。只有上一個(gè)收到了回應(yīng)才發(fā)送下一個(gè)，這樣效率會(huì)非常低，因此引進(jìn)了滑動(dòng)窗口的概念.

其實(shí)就是在發(fā)送方設(shè)立一個(gè)緩存區(qū)間，將已發(fā)送但未收到確認(rèn)的消息緩存起來(lái)，假如一個(gè)窗口可以發(fā)送 5 個(gè) TCP 段，那么發(fā)送方就可以連續(xù)發(fā)送 5 個(gè) TCP 段，然后就會(huì)將這 5 個(gè) TCP 段的數(shù)據(jù)緩存起來(lái)，這 5 個(gè) TCP 段是有序的，只要后面的消息收到了 ACK ，那么不管前面的是否有收到 ACK,都代表成功，窗⼝⼤⼩是由接收方?jīng)Q定的。

窗⼝⼤⼩就是指不需要等待應(yīng)答，還可以發(fā)送數(shù)據(jù)的大小。

十六.發(fā)送方一直發(fā)送數(shù)據(jù)，但是接收方處理不過(guò)來(lái)怎么辦?(流量控制)

如果接收方處理不過(guò)來(lái)，發(fā)送方就會(huì)觸發(fā)重試機(jī)制再次發(fā)送數(shù)據(jù)，然而這個(gè)是有性能損耗的，為了解決這個(gè)問(wèn)題，TCP 就提出了流量控制，為的就是讓發(fā)送方知道接受方的處理能力。

也就是說(shuō)，每次接收方接受到數(shù)據(jù)后會(huì)將剩余可處理數(shù)據(jù)的大小告訴發(fā)送方。

比如接受方滑動(dòng)窗口可用大小為400字節(jié)，發(fā)送方發(fā)送過(guò)來(lái)100字節(jié)的數(shù)據(jù)，那么接收方剩余可用滑動(dòng)窗口大小就為300字節(jié)，這是發(fā)送方就知道下次返送數(shù)據(jù)的大小范圍了。

但是這里有一個(gè)問(wèn)題，數(shù)據(jù)會(huì)存放在緩沖區(qū)，但是這個(gè)緩沖區(qū)是操作系統(tǒng)控制的，當(dāng)系統(tǒng)繁忙的時(shí)候，會(huì)縮減緩沖區(qū)減小，可能就會(huì)造成丟包的問(wèn)題。

如: 發(fā)送方接收方窗口大小各為200字節(jié)，發(fā)送方發(fā)送100字節(jié)的給接收方，此時(shí)雙方各剩100字節(jié)，但是此時(shí)操作系統(tǒng)非常忙，將接收方的緩存區(qū)減少了50字節(jié)，這時(shí)接收方就會(huì)告訴發(fā)送方，我還有50字節(jié)可用，但是在接收方發(fā)送到達(dá)之前，發(fā)送方是不知道的，只會(huì)看到自己還有100字節(jié)可用，那么就繼續(xù)發(fā)送數(shù)據(jù)，如果發(fā)送了80字節(jié)數(shù)據(jù)，那么接收方緩存區(qū)大小為50字節(jié)，就會(huì)丟失30字節(jié)的數(shù)據(jù)，也就是會(huì)發(fā)生丟包現(xiàn)象。

我們會(huì)發(fā)現(xiàn)，這個(gè)問(wèn)題發(fā)生的原因就是減少了緩存，又收縮了窗口大小，所以 TCP 是不允許同時(shí)減少緩存⼜收縮窗⼝的。

十七.TCP 半連接隊(duì)列和全連接隊(duì)列是什么?

服務(wù)端收到客戶端發(fā)出的 SYN 請(qǐng)求后，會(huì)把這個(gè)連接信息存儲(chǔ)到半鏈接隊(duì)列(SYN 隊(duì)列)。

服務(wù)端收到第三次握⼿的 ACK 后，內(nèi)核會(huì)把連接從半連接隊(duì)列移除，然后創(chuàng)建新的完全的連接，并將其添加到全連接隊(duì)列(accept 隊(duì)列)，等待進(jìn)程調(diào)⽤ accept 函數(shù)時(shí)把連接取出來(lái)。

這兩個(gè)隊(duì)列都是有大小限制的，當(dāng)超過(guò)容量后就會(huì)將鏈接丟棄，或者返回 RST 包。

十八.粘包/拆包是怎么發(fā)生的?怎么解決這個(gè)問(wèn)題?

TCP 發(fā)送數(shù)據(jù)時(shí)會(huì)根據(jù) TCP 緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，一個(gè)完整的包可能會(huì)被 TCP 拆分成多個(gè)包進(jìn)行發(fā)送，也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是 TCP 粘包和拆包問(wèn)題。

發(fā)生 TCP 粘包的原因:

1.發(fā)送的數(shù)據(jù)小于 TCP 緩沖區(qū)大小，TCP將緩沖區(qū)中的數(shù)據(jù)(數(shù)據(jù)屬于多條業(yè)務(wù)內(nèi)容)一次發(fā)送出去可能就會(huì)發(fā)生粘包。

2.接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包。

發(fā)生 TCP 拆包的原因:

1.待發(fā)送數(shù)據(jù)大于最大報(bào)文長(zhǎng)度，TCP 在傳輸前將進(jìn)行拆包。

2.發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包。

解決方案:

1.發(fā)送端給每個(gè)數(shù)據(jù)包添加包首部，首部中包含數(shù)據(jù)包的長(zhǎng)度，這樣接收端在接收到數(shù)據(jù)后，通過(guò)該字段就可以知道每個(gè)數(shù)據(jù)包的實(shí)際長(zhǎng)度了。

2.發(fā)送端將每個(gè)數(shù)據(jù)包設(shè)置固定長(zhǎng)度，這樣接收端每次從讀取固定長(zhǎng)度的數(shù)據(jù)把每個(gè)數(shù)據(jù)包拆分開(kāi)。

3.可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號(hào)，接收端可以通過(guò)這個(gè)特殊符號(hào)來(lái)拆分包。

十九.瀏覽器地址欄輸入網(wǎng)站按回車后發(fā)生了什么?

1:解析網(wǎng)址,生成 HTTP 請(qǐng)求信息

2:根據(jù) DNS 服務(wù)器查詢真實(shí)請(qǐng)求的 IP 地址，如果本地服務(wù)器有緩存則直接返回

3:得到了 IP 以后，向服務(wù)器發(fā)送 TCP 連接，TCP 連接經(jīng)過(guò)三次握手。

4:接受 TCP 報(bào)文后，對(duì)連接進(jìn)行處理，對(duì) HTTP 協(xié)議解析

5:服務(wù)器返回響應(yīng)

6:瀏覽器接受響應(yīng)，顯示頁(yè)面，渲染頁(yè)面

本文轉(zhuǎn)載自微信公眾號(hào)「moon聊技術(shù)」