輸入網(wǎng)址按回車會(huì)發(fā)生什么

這篇文章主要介紹“輸入網(wǎng)址按回車會(huì)發(fā)生什么”，在日常操作中，相信很多人在輸入網(wǎng)址按回車會(huì)發(fā)生什么問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”輸入網(wǎng)址按回車會(huì)發(fā)生什么”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

大致流程

•  URL 解析。

•  DNS 查詢。

•  TCP 連接。

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

•  客戶端接收 HTTP 報(bào)文響應(yīng)。

•  渲染頁(yè)面

重點(diǎn)來(lái)了：

•  如何理解 TCP 的三次握手與四次揮手？每次握手客戶端與服務(wù)端是怎樣的狀態(tài)？

•  為何揮手會(huì)出現(xiàn) 2MSL，遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態(tài)是什么問(wèn)題？

•  三次握手與四次揮手的過(guò)程是怎樣的？

•  HTTP 的報(bào)文格式又是怎樣的？

繼續(xù)閱讀本文，且聽(tīng)碼哥字節(jié)答疑解惑，微信搜索 “碼哥字節(jié)”，關(guān)注公眾號(hào)更多硬核。

URL 解析

地址解析：首先判斷你輸入的是一個(gè)合法的 URL 還是一個(gè)待搜索的關(guān)鍵詞，并且根據(jù)你輸入的內(nèi)容進(jìn)行自動(dòng)完成、字符編碼等操作。

HSTS 由于安全隱患，會(huì)使用 HSTS 強(qiáng)制客戶端使用 HTTPS 訪問(wèn)頁(yè)面。詳見(jiàn)：你所不知道的 HSTS[1]。

其他操作 瀏覽器還會(huì)進(jìn)行一些額外的操作，比如安全檢查、訪問(wèn)限制（之前國(guó)產(chǎn)瀏覽器限制 996.icu）。

檢查緩存

DNS 查詢

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  瀏覽器緩存：先檢查是否在緩存中，沒(méi)有則調(diào)用系統(tǒng)庫(kù)函數(shù)進(jìn)行查詢。

3.  操作系統(tǒng)緩存：操作系統(tǒng)也有自己的 DNS 緩存，但在這之前，會(huì)向檢查域名是否存在本地的 Hosts 文件里，沒(méi)有則向 DNS 服務(wù)器發(fā)送查詢請(qǐng)求。

4.  路由器緩存。

5.  ISP DNS 緩存：ISP DNS 就是在客戶端電腦上設(shè)置的首選 DNS 服務(wù)器，它們?cè)诖蠖鄶?shù)情況下都會(huì)有緩存。

根域名服務(wù)器查詢

在前面所有步驟沒(méi)有緩存的情況下，本地 DNS 服務(wù)器會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到互聯(lián)網(wǎng)上的根域，下面這個(gè)圖很好的詮釋了整個(gè)流程：

需要注意的的是：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  遞歸方式：一路查下去中間不返回，得到最終結(jié)果才返回信息（瀏覽器到本地 DNS 服務(wù)器的過(guò)程）

3.  迭代方式，就是本地 DNS 服務(wù)器到根域名服務(wù)器查詢的方式。

4.  什么是 DNS 劫持

5.  前端 dns-prefetch 優(yōu)化

TCP 連接建立與斷開(kāi)

TCP/IP 分為四層，在發(fā)送數(shù)據(jù)時(shí)，每層都要對(duì)數(shù)據(jù)進(jìn)行封裝：

應(yīng)用層：發(fā)送 HTTP 請(qǐng)求

瀏覽器從地址欄得到服務(wù)器 IP，接著構(gòu)造一個(gè) HTTP 報(bào)文，其中包括：

•  請(qǐng)求報(bào)頭(Request Header)：請(qǐng)求方法、目標(biāo)地址、遵循的協(xié)議等

•  請(qǐng)求主體，請(qǐng)求參數(shù)，比如 body 里面的參數(shù)

傳輸層：TCP 傳輸報(bào)文

傳輸層會(huì)發(fā)起一條到達(dá)服務(wù)器的 TCP 連接，為了方便傳輸，會(huì)對(duì)數(shù)據(jù)進(jìn)行分割（以報(bào)文段為單位），并標(biāo)記編號(hào)，方便服務(wù)器接受時(shí)能夠準(zhǔn)確地還原報(bào)文信息。在建立連接前，會(huì)先進(jìn)行 TCP 三次握手。

網(wǎng)絡(luò)層：IP 協(xié)議查詢 MAC 地址

將數(shù)據(jù)段打包，并加入源及目標(biāo)的 IP 地址，并且負(fù)責(zé)尋找傳輸路線。判斷目標(biāo)地址是否與當(dāng)前地址處于同一網(wǎng)絡(luò)中，是的話直接根據(jù) Mac 地址發(fā)送，否則使用路由表查找下一跳地址，以及使用 ARP 協(xié)議查詢它的 Mac 地址。

鏈路層：以太網(wǎng)協(xié)議

根據(jù)以太網(wǎng)協(xié)議將數(shù)據(jù)分為以“幀”為單位的數(shù)據(jù)包，每一幀分為兩個(gè)部分：

•  標(biāo)頭：數(shù)據(jù)包的發(fā)送者、接受者、數(shù)據(jù)類型

•  數(shù)據(jù)：數(shù)據(jù)包具體內(nèi)容

Mac 地址

以太網(wǎng)規(guī)定了連入網(wǎng)絡(luò)的所有設(shè)備都必須具備“網(wǎng)卡”接口，數(shù)據(jù)包都是從一塊網(wǎng)卡傳遞到另一塊網(wǎng)卡，網(wǎng)卡的地址就是 Mac 地址。每一個(gè) Mac 地址都是獨(dú)一無(wú)二的，具備了一對(duì)一的能力。

主要的請(qǐng)求過(guò)程：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  瀏覽器從地址欄中獲取服務(wù)器的 IP 和端口號(hào)；

3.  瀏覽器有服務(wù)器之間通過(guò) TCP 三次握手建立連接；

4.  瀏覽器向服務(wù)器發(fā)送報(bào)文；

5.  服務(wù)器接收?qǐng)?bào)文處理，同時(shí)將響應(yīng)報(bào)文發(fā)給瀏覽器；

6.  瀏覽器解析報(bào)文，渲染輸出到頁(yè)面；

三次握手

在傳輸層傳輸數(shù)據(jù)之前需要建立連接，也就是三次握手創(chuàng)建可靠連接。

首先建立鏈接前需要 Server 端先監(jiān)聽(tīng)端口，因此 Server 端建立鏈接前的初始狀態(tài)就是 LISTEN 狀態(tài)，這時(shí) Client 端準(zhǔn)備建立鏈接，先發(fā)送一個(gè) SYN 同步包，發(fā)送完同步包后，Client 端的鏈接狀態(tài)變成了 SYN_SENT 狀態(tài)。Server 端收到 SYN 后，同意建立鏈接，會(huì)向 Client 端回復(fù)一個(gè) ACK。

由于 TCP 是雙工傳輸，Server 端也會(huì)同時(shí)向 Client 端發(fā)送一個(gè) SYN，申請(qǐng) Server 向 Client 方向建立鏈接。發(fā)送完 ACK 和 SYN 后，Server 端的鏈接狀態(tài)就變成了 SYN_RCVD。

Client 收到 Server 的 ACK 后，Client 端的鏈接狀態(tài)就變成了 ESTABLISHED 狀態(tài)，同時(shí)，Client 向 Server 端發(fā)送 ACK，回復(fù) Server 端的 SYN 請(qǐng)求。

Server 端收到 Client 端的 ACK 后，Server 端的鏈接狀態(tài)也就變成了的 ESTABLISHED 狀態(tài)，此時(shí)建連完成，雙方隨時(shí)可以進(jìn)行數(shù)據(jù)傳輸。

在面試時(shí)需要明白三次握手是為了建立雙向的鏈接，需要記住 Client 端和 Server 端的鏈接狀態(tài)變化。另外回答建連的問(wèn)題時(shí)，可以提到 SYN 洪水攻擊發(fā)生的原因，就是 Server 端收到 Client 端的 SYN 請(qǐng)求后，發(fā)送了 ACK 和 SYN，但是 Client 端不進(jìn)行回復(fù)，導(dǎo)致 Server 端大量的鏈接處在 SYN_RCVD 狀態(tài)，進(jìn)而影響其他正常請(qǐng)求的建連?？梢栽O(shè)置 tcp_synack_retries = 0 加快半鏈接的回收速度，或者調(diào)大 tcp_max_syn_backlog 來(lái)應(yīng)對(duì)少量的 SYN 洪水攻擊

四次揮手

我們只要關(guān)注 80 端口與 13743 端口建立的連接斷開(kāi)過(guò)程，瀏覽器通過(guò) 13747 端口發(fā)送 [FIN, ACK] 這里是不是跟很多網(wǎng)上看到的不一樣？

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  其實(shí)是客戶端在發(fā)送 [FIN] 報(bào)文的時(shí)候順帶發(fā)了一個(gè) [ACK] 確認(rèn)上次傳輸確認(rèn)。

3.  接著服務(wù)端通過(guò) 80 端口響應(yīng)了 [ACK] ，然后立馬響應(yīng) [FIN, ACK] 表示數(shù)據(jù)傳輸完了，可以關(guān)閉連接。

4.  最后瀏覽器通過(guò) 13743 端口 發(fā)送 [ACK] 包給服務(wù)端，客服端與服務(wù)端連接就關(guān)閉了。

具體流程如下圖抓包所示：

三次握手與四次揮手

客戶端：

•  SYN_SENT - 客戶端發(fā)起第 1 次握手后，連接狀態(tài)為 SYN_SENT ，等待服務(wù)端內(nèi)核進(jìn)行應(yīng)答，如果服務(wù)端來(lái)不及處理（例如服務(wù)端的 backlog 隊(duì)列已滿）就可以看到這種狀態(tài)的連接。

•  ESTABLISHED - 表示連接處于正常狀態(tài)，可以進(jìn)行數(shù)據(jù)傳送?？蛻舳耸盏椒?wù)器回復(fù)的 SYN+ACK 后，對(duì)服務(wù)端的 SYN 單獨(dú)回復(fù)（第 3 次握手），連接建立完成，進(jìn)入 ESTABLISHED 狀態(tài)。服務(wù)端程序收到第 3 次握手包后，也進(jìn)入 ESTABLISHED 狀態(tài)。

•  FIN_WAIT_1 - 客戶端發(fā)送了關(guān)閉連接的 FIN 報(bào)文后，等待服務(wù)端回復(fù) ACK 確認(rèn)。

•  FIN_WAIT_2 - 表示我方已關(guān)閉連接，正在等待服務(wù)端關(guān)閉?？蛻舳税l(fā)了關(guān)閉連接的 FIN 報(bào)文后，服務(wù)器發(fā)回 ACK 應(yīng)答，但是沒(méi)進(jìn)行關(guān)閉，就會(huì)處于這種狀態(tài)。

•  TIME_WAIT - 雙方都正常關(guān)閉連接后，客戶端會(huì)維持 TIME_WAIT 一段時(shí)間，以確保最后一個(gè) ACK 能成功發(fā)送到服務(wù)器端。停留時(shí)長(zhǎng)為 2 倍的 MSL (報(bào)文最大生存時(shí)間)，Linux 下大約是 60 秒。所以在一個(gè)頻繁建立短連接的服務(wù)器上通常可以看到成千上萬(wàn)的 TIME_WAIT 連接。

服務(wù)端：

•  LISTEN - 表示當(dāng)前程序正在監(jiān)聽(tīng)某個(gè)端口時(shí)。

•  SYN_RCVD - 服務(wù)端收到第 1 次握手后，進(jìn)入 SYN_RCVD 狀態(tài)，并回復(fù)一個(gè) SYN+ACK（第 2 次握手），再等待對(duì)方確認(rèn)。

•  ESTABLISHED - 表示連接處于正常狀態(tài)，可以進(jìn)行數(shù)據(jù)傳送。完成 TCP3 次握手后，連接建立完成，進(jìn)入 ESTABLISHED 狀態(tài)。

•  CLOSE_WAIT - 表示客戶端已經(jīng)關(guān)閉連接，但是本地還沒(méi)關(guān)閉，正在等待本地關(guān)閉。有時(shí)客戶端程序已經(jīng)退出了，但服務(wù)端程序由于異?；?BUG 沒(méi)有調(diào)用 close()函數(shù)對(duì)連接進(jìn)行關(guān)閉，那在服務(wù)器這個(gè)連接就會(huì)一直處于 CLOSE_WAIT 狀態(tài)，而在客戶機(jī)已經(jīng)不存在這個(gè)連接了。

•  LAST_ACK - 表示正在等待客戶端對(duì)服務(wù)端的關(guān)閉請(qǐng)求進(jìn)行最終確認(rèn)。

TIME_WAIT 狀態(tài)存在的理由：

劃重點(diǎn)了

•  可靠地實(shí)現(xiàn) TCP 全雙工連接的終止 在進(jìn)行關(guān)閉連接四路握手協(xié)議時(shí)，最后的 ACK 是由主動(dòng)關(guān)閉端發(fā)出的，如果這個(gè)最終的 ACK 丟失，服務(wù)器將重發(fā)最終的 FIN，因此客戶端必須維護(hù)狀態(tài)信息允 許它重發(fā)最終的 ACK。如 果不維持這個(gè)狀態(tài)信息，那么客戶端將響應(yīng) RST 分節(jié)，服務(wù)器將此分節(jié)解釋成一個(gè)錯(cuò)誤（ 在 java 中會(huì)拋出 connection reset 的 SocketException)。因而，要實(shí)現(xiàn) TCP 全雙工連接的正常終 止，必須處理終止序列四個(gè)分節(jié)中任何一個(gè)分節(jié)的丟失情況，主動(dòng)關(guān)閉 的客戶端必須維持狀 態(tài)信息進(jìn)入 TIME_WAIT 狀態(tài)。

•  允許老的重復(fù)分節(jié)在網(wǎng)絡(luò)中消逝 TCP 分節(jié)可能由于路由器異常而“迷途”，在迷途期間，TCP 發(fā)送端可能因確認(rèn)超時(shí)而重發(fā)這個(gè) 分節(jié)，迷途的分節(jié)在路由器修復(fù)后也會(huì)被送到最終目的地，這個(gè) 原來(lái)的迷途分節(jié)就稱為 lost duplicate。在關(guān)閉一個(gè) TCP 連接后，馬上又重新建立起一個(gè)相同的 IP 地址和端口之間的 TCP 連接，后一個(gè)連接被稱為前一個(gè)連接的化身 （ incarnation)，那么有可能出現(xiàn)這種情況，前一 個(gè)連接的迷途重復(fù)分組在前一個(gè)連接終止后出現(xiàn)，從而被誤解成從屬于新的化身。為了避免 這個(gè)情 況，TCP 不允許處于 TIME_WAIT 狀態(tài)的連接啟動(dòng)一個(gè)新的化身，因?yàn)?TIME_WAIT 狀 態(tài)持續(xù) 2MSL，就可以保證當(dāng)成功建立一個(gè) TCP 連接的時(shí) 候，來(lái)自連接先前化身的重復(fù)分組已 經(jīng)在網(wǎng)絡(luò)中消逝。

另外回答斷鏈的問(wèn)題時(shí)，可以提到實(shí)際應(yīng)用中有可能遇到大量 Socket 處在 TIME_WAIT 或者 CLOSE_WAIT 狀態(tài)的問(wèn)題。一般開(kāi)啟 tcp_tw_reuse 和 tcp_tw_recycle 能夠加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE_WAIT 可能是被動(dòng)關(guān)閉的一方存在代碼 bug，沒(méi)有正確關(guān)閉鏈接導(dǎo)致的。

簡(jiǎn)單地說(shuō)就是

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  保證 TCP 協(xié)議的全雙工連接能夠可靠關(guān)閉；

3.  保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失，防止端口被重用時(shí)可能產(chǎn)生數(shù)據(jù)混淆；

服務(wù)器處理請(qǐng)求并響應(yīng) HTTP 報(bào)文

深入分析下 HTTP 報(bào)文到底是什么玩意。數(shù)據(jù)傳輸都是通過(guò) TCP/IP 協(xié)議負(fù)責(zé)底層的傳輸工作， HTTP 協(xié)議基本不用操心，所謂的 “超文本傳輸協(xié)議” 似乎不怎么例會(huì) “傳輸” 這個(gè)事情，那 HTTP 的核心又是什么呢？

比圖 TCP 報(bào)文，它在實(shí)際要傳輸?shù)臄?shù)據(jù)之前附加了一個(gè) 20 字節(jié)的頭部數(shù)據(jù)，存儲(chǔ) TCP 協(xié)議必須的額外信息，例如發(fā)送方的端口號(hào)、接收方的端口號(hào)、包序號(hào)、標(biāo)志位等等。

有了這個(gè)附加的 TCP 頭，數(shù)據(jù)包才能夠正確傳輸，到了目的地后把頭部去掉，就可以拿到真正的數(shù)據(jù)。這個(gè)很容易理解，設(shè)置起點(diǎn)與終點(diǎn)，不同協(xié)議貼上不同的頭部，到了對(duì)應(yīng)目的地就拆下這個(gè)頭部，提取真正的數(shù)據(jù)。

與 TCP/UDP 類似需要在傳輸數(shù)據(jù)前設(shè)置一些請(qǐng)求頭，不同的是 HTTP 是一個(gè) “純文本” 的協(xié)議，所有的頭都是 ASCII 碼的文本，很容易看出來(lái)是什么。

再者就是他的請(qǐng)求報(bào)文與響應(yīng)報(bào)文的結(jié)構(gòu)基本一樣，主要三大部分組成：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  起始行(Start Line)：描述請(qǐng)求或者響應(yīng)的基本信息。

3.  Header：使用 key-value 的形式詳細(xì)說(shuō)明報(bào)文信息。

4.  空行。

5.  消息正文（Entity）：傳輸?shù)臄?shù)據(jù)，圖片、視頻、文本等都可以。

這其中前兩部分起始行和頭部字段經(jīng)常又合稱為“請(qǐng)求頭”或“響應(yīng)頭”，消息正文又稱為“實(shí)體”，但與“header”對(duì)應(yīng)，很多時(shí)候就直接稱為“body”。

敲黑板了

HTTP 協(xié)議規(guī)定報(bào)文必須包含 Header，而且之后必須有一個(gè) “空行”，也就是“CRLF”，十六進(jìn)制的“0D0A”，可以沒(méi)有 “body”。

報(bào)文結(jié)構(gòu)如下圖所示：

截取一段報(bào)文：

請(qǐng)求頭-起始行

請(qǐng)求行由請(qǐng)求方法字段、URL 字段和 HTTP 協(xié)議版本字段 3 個(gè)字段組成，它們用空格分隔。例如，GET / HTTP/1.1。

HTTP 協(xié)議的請(qǐng)求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

GET 是請(qǐng)求方法， “/” 是請(qǐng)求的目標(biāo)資源，“HTTP/1.1” 請(qǐng)求協(xié)議版本號(hào)。

GET / HTTP/1.1 翻譯成文字大概就是：“hello，服務(wù)器，我要請(qǐng)求根目錄下的默認(rèn)文件使用的是 HTTP 1.1 協(xié)議版本”。

頭部 Header

第二部分就是 Header，組成形式是 key：value，使用自定義頭需要注意事項(xiàng)：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  header 字段不區(qū)分大小寫(xiě)，通常是首字母大寫(xiě)；

3.  字段名不允許有空格，可以使用 “-”，不能使用 “_”；

4.  字段名必須緊接著 “:”，不能有空格，但是 “:” 后面可以有空格。

5.  字段名順序沒(méi)有意義；

瀏覽器接收響應(yīng)并渲染數(shù)據(jù)

瀏覽器接收到來(lái)自服務(wù)器的響應(yīng)資源后，會(huì)對(duì)資源進(jìn)行分析。首先查看 Response header，根據(jù)不同狀態(tài)碼做不同的事（比如上面提到的重定向）。如果響應(yīng)資源進(jìn)行了壓縮（比如 gzip），還需要進(jìn)行解壓。然后，對(duì)響應(yīng)資源做緩存。接下來(lái)，根據(jù)響應(yīng)資源里的 MIME[3] 類型去解析響應(yīng)內(nèi)容（比如 HTML、Image 各有不同的解析方式）。

接下來(lái)將接收到的數(shù)據(jù)渲染出來(lái)，不同的瀏覽器也不是完全相同，但是大致流程是一樣的：

到此，關(guān)于“輸入網(wǎng)址按回車會(huì)發(fā)生什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！