|
這篇文章是我之前寫(xiě)的（2023年1月）,，也屬于計(jì)算機(jī)學(xué)習(xí)筆記一部分?，F(xiàn)在整理一下發(fā)上來(lái)， 作為一個(gè)涉世未深的服務(wù)端人員,，在日常的開(kāi)發(fā)工作中,，有時(shí)候會(huì)遇到一些這樣的“窘境”：比如在排查一個(gè)服務(wù)的故障的時(shí)候，前端感到很疑惑,，自己是照規(guī)范發(fā)的請(qǐng)求呀,，這還有請(qǐng)求的失敗記錄呢，而服務(wù)端也很疑惑,，從日志來(lái)看根本沒(méi)有收到請(qǐng)求呀,。最終可能一番折騰，發(fā)現(xiàn)是因?yàn)镹ginx超時(shí)了,，這個(gè)可憐的請(qǐng)求就像一艘小小的帆船,，葬身在網(wǎng)絡(luò)的汪洋大海之中。網(wǎng)絡(luò)確實(shí)像是大海,，平時(shí)風(fēng)平浪靜,，波瀾不興，讓你感覺(jué)不到它的存在,，但是可能不知道什么時(shí)候就突然陰風(fēng)怒號(hào),，濁浪排空了。而工作進(jìn)程,，也因此被耽誤,。 所以當(dāng)時(shí)我找了一本網(wǎng)絡(luò)相關(guān)的書(shū)來(lái)看：戶(hù)根勤的《網(wǎng)絡(luò)是怎樣連接的》,?？赐暧X(jué)得收獲挺大的，尤其覺(jué)得這本書(shū)寫(xiě)的特別好，篇幅不長(zhǎng),，定位是科普,、通俗讀物，但其實(shí)還是講的還挺細(xì)挺深的,，我覺(jué)得很適合有一定基礎(chǔ)的讀者,，作為復(fù)習(xí)和加深理解。于是對(duì)這本書(shū)的主要內(nèi)容進(jìn)行了梳理,，也加入了一些自己另外學(xué)到的內(nèi)容,。
連接的全流程瀏覽器生成請(qǐng)求消息讓我們從在瀏覽器中輸入一個(gè)網(wǎng)址后點(diǎn)擊回車(chē)開(kāi)始說(shuō)起。 首先,，瀏覽器會(huì)對(duì)你輸入的網(wǎng)址進(jìn)行解析并生成一個(gè)HTTP消息,。這個(gè)消息中包含了你要訪問(wèn)的服務(wù)器的域名，請(qǐng)求的類(lèi)型,，你傳過(guò)去的內(nèi)容,，你能接受的內(nèi)容等等。關(guān)于消息的結(jié)構(gòu)作用這一塊大家也都比較熟悉了,，我們就快速略過(guò),。直接往下，講講消息是怎么發(fā)出去的,。
DNS解析上面我們說(shuō)了瀏覽器會(huì)解析網(wǎng)址并生成HTTP消息,，但要注意的是：瀏覽器本身并不具備將消息發(fā)送到網(wǎng)絡(luò)中的功能。這一功能實(shí)質(zhì)上是瀏覽器委托操作系統(tǒng)實(shí)現(xiàn)的,。而在委托操作系統(tǒng)發(fā)送消息時(shí),，我們必須提供給操作系統(tǒng)通信對(duì)象的IP地址而不是域名。 因此我們需要先解決一個(gè)問(wèn)題：就是網(wǎng)址中服務(wù)器域名對(duì)應(yīng)的IP地址是什么,？那么這個(gè)問(wèn)題是如何解決的呢,？簡(jiǎn)單來(lái)說(shuō)就是：DNS服務(wù)器解決的。當(dāng)我們?nèi)ピ?xún)問(wèn)DNS服務(wù)器'www.baidu.com'的IP地址是什么的時(shí)候,，它就會(huì)告訴我們它的ip地址是168.1.1這樣,。 但我們不想止步于此，而是想再深入一些：瀏覽器是如何向DNS服務(wù)器發(fā)出查詢(xún)的呢,？ 首先,，對(duì)應(yīng)于DNS服務(wù)器，我們的計(jì)算機(jī)上有一個(gè)相應(yīng)的DNS客戶(hù)端的部分,，它的名字叫DNS解析器,。這個(gè)解析器實(shí)際上是一段程序，包含在操作系統(tǒng)的Socket庫(kù)中,。這個(gè)庫(kù)（以我的理解就和我們平時(shí)說(shuō)的jar包差不多含義）,，是一堆通用程序組件的集合,。Socket庫(kù)也是一種庫(kù)，其中包含的程序組件可以讓其他的應(yīng)用程序調(diào)用操作系統(tǒng)的網(wǎng)絡(luò)功能,，比如：創(chuàng)建Socket,， 鏈接Socket等等，而解析器則是這個(gè)庫(kù)中的一種程序組件,。
從圖中可以看到,，當(dāng)瀏覽器需要查詢(xún)一個(gè)域名對(duì)應(yīng)的IP的時(shí)候，它實(shí)際上是調(diào)用了操作系統(tǒng)的Socket庫(kù)中的一個(gè)gethostbyname()的方法,，在這個(gè)方法中,，操作系統(tǒng)會(huì)幫我們把這一系列事情做好（生成UDP消息，發(fā)給DNS服務(wù)器,，從響應(yīng)中取出IP地址放到內(nèi)存中）,，最后我們從內(nèi)存中取出我們要的ip地址就可以了。這里我們衍生出兩個(gè)問(wèn)題：
第一個(gè)問(wèn)題的答案其實(shí)很簡(jiǎn)單，就是這個(gè)DNS服務(wù)器的ip是事先設(shè)置好的,。解析器會(huì)根據(jù)這個(gè)ip地址來(lái)發(fā)送消息,。第二個(gè)問(wèn)題則相對(duì)復(fù)雜。為了理解這個(gè)過(guò)程,，我們需要先了解DNS服務(wù)器群的結(jié)構(gòu),。這個(gè)結(jié)構(gòu)有上下級(jí)的概念，其中最高一層是根域服務(wù)器,，在全世界僅有13個(gè),。而這些信息也會(huì)預(yù)先配置在計(jì)算機(jī)中。根域名服務(wù)器往下是如com, jp, cn這樣的層級(jí),，再往下是glasscom, baidu等層級(jí),。以此類(lèi)推。而當(dāng)我們要查詢(xún)某個(gè)域名對(duì)應(yīng)的IP的時(shí)候,，流程則如下圖（注意我們一開(kāi)始訪問(wèn)的其實(shí)是離我們最近的服務(wù)器）：
對(duì)DNS的查詢(xún)需求顯然是巨大的,，因此DNS服務(wù)器中有一個(gè)緩存功能（瀏覽器中也有），如果要查詢(xún)的域名已經(jīng)在緩存中,，就會(huì)直接返回響應(yīng),，而不必再每次從根域名開(kāi)始查找,。其中每個(gè)保存的信息都會(huì)設(shè)置一個(gè)有效期，超過(guò)有效期后數(shù)據(jù)會(huì)從緩存刪除以解決域名注冊(cè)信息改變的問(wèn)題,。 QQ登錄問(wèn)題在那個(gè)頭發(fā)能遮住左眼,，聊天中充滿(mǎn)了“我暈”,，“你是GG還是MM”的年代里,。有時(shí)會(huì)出現(xiàn)一種科學(xué)無(wú)法解釋的現(xiàn)象：就是瀏覽器無(wú)法上網(wǎng)，QQ卻能正常登陸,。 那么今天我們終于能理解這個(gè)背后的原因了：其實(shí)就是DNS配置錯(cuò)了,。瀏覽器無(wú)法獲得域名對(duì)應(yīng)的IP地址，自然也就無(wú)法訪問(wèn)了,。而QQ是直接通過(guò)IP連接服務(wù)器的,，因此可以正常登陸。
協(xié)議棧（通信）至此,，我們就獲得了目標(biāo)服務(wù)器的IP地址了,，接下來(lái)就可以委托操作系統(tǒng)內(nèi)部的協(xié)議棧向這個(gè)地址發(fā)消息了。這一步其實(shí)不僅限于瀏覽器,，對(duì)于各種使用網(wǎng)絡(luò)的應(yīng)用來(lái)說(shuō)都是共通的,。 發(fā)消息這個(gè)過(guò)程需要按照指定的順序來(lái)調(diào)用Socket庫(kù)的多個(gè)程序組件，以在兩臺(tái)計(jì)算機(jī)之間建立并維護(hù)一條數(shù)據(jù)通道,，我們可以把它想象成一條管道,，將數(shù)據(jù)從一端送入管道，數(shù)據(jù)就會(huì)到達(dá)另一端然后被取出,。這樣的管道兩端的出入口就叫socket,也叫套接字（我每次看到這個(gè)詞腦海中浮現(xiàn)的都是一只襪子(sock)...）,。我們大致捋一下收發(fā)數(shù)據(jù)操作的4個(gè)階段：
這一部分也是網(wǎng)絡(luò)連接的核心（尤其對(duì)于軟件工程師來(lái)說(shuō)）。接下來(lái)我們依次對(duì)這幾個(gè)階段進(jìn)行介紹 創(chuàng)建套接字階段計(jì)算機(jī)經(jīng)常會(huì)同時(shí)進(jìn)行多個(gè)數(shù)據(jù)的通信操作,。比如說(shuō)我們?cè)跒g覽器中打開(kāi)兩個(gè)窗口,，同時(shí)訪問(wèn)兩個(gè)web服務(wù)器，那么這就是兩套數(shù)據(jù)的收發(fā),。所以我們需要?jiǎng)?chuàng)建兩個(gè)不同的套接字來(lái)收發(fā)數(shù)據(jù),。 那么進(jìn)一步地，我們需要有一些信息來(lái)區(qū)分這些不同的套接字,，而這也是這個(gè)階段所做的事情,。調(diào)用socket庫(kù)中的socket方法后，會(huì)返回一個(gè)叫描述符的東西,，這個(gè)東西是用于識(shí)別特定的套接字的,，在后面的操作中，只要我們出示這個(gè)描述符,，協(xié)議棧就知道我們希望用哪一個(gè)套接字來(lái)連接或收發(fā)數(shù)據(jù)了,。 具體到物理層面,，協(xié)議棧首先會(huì)分配用于存放一個(gè)套接字所需的內(nèi)存空間，并往里面存入相關(guān)的控制信息,，至此,，創(chuàng)建套接字的操作就完成了。 連接階段客戶(hù)端應(yīng)用程序創(chuàng)建好套接字后,，就可以委托協(xié)議棧將客戶(hù)端創(chuàng)建的套接字與服務(wù)器那邊的套接字連接起來(lái)了,。這時(shí)候我們其實(shí)不知道要和誰(shuí)通信，也不知道對(duì)方的信息,。所以說(shuō)連接實(shí)際上是通信雙方交換控制信息（比如ip,， 端口等）。 應(yīng)用程序?qū)⑼ㄟ^(guò)調(diào)用Socket庫(kù)中的connect（）組件完成這一操作,。而調(diào)用這一組件需要提供三個(gè)信息：描述符,，服務(wù)器IP地址以及端口號(hào)。前兩個(gè)我們已經(jīng)有了,，那端口號(hào)從哪兒來(lái)呢,？這個(gè)端口號(hào)是事先約定的，比如http請(qǐng)求是80端口,，https是443端口,，電子郵件是25端口等等。 具體來(lái)看看：當(dāng)調(diào)用connect()時(shí),，傳入的信息會(huì)傳遞給協(xié)議棧中的TCP模塊,，然后TCP模塊就會(huì)與其中IP地址對(duì)應(yīng)的對(duì)象（也即服務(wù)器）的TCP模塊交換控制信息。這一交互過(guò)程就是我們常說(shuō)的三次握手,。三次握手成功后,，連接就成功建立起來(lái)了。
三次握手
所有TCP連接都要經(jīng)歷三次握手,。這一點(diǎn)對(duì)于使用TCP連接的應(yīng)用的性能產(chǎn)生了非常大的性能影響,，因?yàn)槊看蝹鬏攽?yīng)用程序，都必須經(jīng)歷一此完整的往返,。比如下圖中,，我從中國(guó)連接架設(shè)在美國(guó)的服務(wù)器，連接耗時(shí)就花去300ms,。
三次握手帶來(lái)的延遲使得每創(chuàng)建一個(gè)新的連接都要付出很大代價(jià),，因此想辦法重用連接能有效提高TCP應(yīng)用的性能。 在HTTP1.0中,，連接是不能復(fù)用的,，就是說(shuō)我點(diǎn)開(kāi)一個(gè)頁(yè)面，里面有3個(gè)http請(qǐng)求,，那就要建立3次TCP連接,。 到了HTTP1.1,，它是默認(rèn)開(kāi)啟持久連接的，同樣3個(gè)http請(qǐng)求,，可以只建立1次TCP連接,，可以看到我打開(kāi)這個(gè)頁(yè)面里的多個(gè)請(qǐng)求中，只有第一個(gè)請(qǐng)求有建立連接的時(shí)間損耗,。但是瀏覽器需要處理完一個(gè)HTTP請(qǐng)求才能才能發(fā)起下一個(gè),。就是比如我兩個(gè)tab同時(shí)訪問(wèn)網(wǎng)站A，那么這里也會(huì)建立兩次TCP連接,。所以這種復(fù)用應(yīng)該是串行的,。 再到了HTTP2.0中,，這一點(diǎn)再次得到了優(yōu)化,。實(shí)現(xiàn)了多路復(fù)用，可以只使用一個(gè)連接即可并行地發(fā)起多個(gè)請(qǐng)求和響應(yīng),。 此外在Linux 3.7以后的內(nèi)核支持一種叫TFO(TCP fast open)的東西,，可以提高頁(yè)面加載時(shí)間。 通信階段至此,，套接字就鏈接起來(lái)了,，接下來(lái)就可以調(diào)用Socket庫(kù)的write組件，傳入描述符和數(shù)據(jù)內(nèi)容就可以向?qū)Ψ桨l(fā)送數(shù)據(jù),。而當(dāng)消息返回后,，可以通過(guò)Socket庫(kù)的read組件委托協(xié)議棧來(lái)讀取響應(yīng)的數(shù)據(jù)。調(diào)用read時(shí)需指定用于存放響應(yīng)數(shù)據(jù)的內(nèi)存地址（接收緩沖區(qū)）,。這個(gè)接收緩沖區(qū)是一塊位于應(yīng)用程序內(nèi)部的內(nèi)存空間,，因此當(dāng)消息存放到此處時(shí)，其實(shí)相當(dāng)于已經(jīng)轉(zhuǎn)交給了應(yīng)用程序,。
TCP是可靠的連接,。而實(shí)現(xiàn)這一點(diǎn)的手段就在于消息的確認(rèn)和重傳機(jī)制。從圖中可以看到會(huì)通過(guò)ACK來(lái)確認(rèn)包被收到,。如果沒(méi)有收到對(duì)應(yīng)的ACK,，就認(rèn)為包沒(méi)有被收到，要重發(fā),。而這就涉及到兩個(gè)問(wèn)題： 第一個(gè)是對(duì)于等待ACK的時(shí)間設(shè)置,。 有時(shí)候網(wǎng)絡(luò)繁忙會(huì)發(fā)送擁塞，如果我們等待時(shí)間太短的話(huà),，可能我們以為包丟失了重傳了包,，結(jié)果ACK又到了，這就進(jìn)一步加重了網(wǎng)絡(luò)的堵塞,。但是等待時(shí)間太長(zhǎng)的話(huà),，包的重傳就會(huì)有很大的延遲,，也會(huì)影響速度。尤其考慮到服務(wù)器物理距離的遠(yuǎn)近,，ACK的返回時(shí)間會(huì)有很大的波動(dòng),。因此TCP沒(méi)有為等待時(shí)間設(shè)置一個(gè)固定的值，而是采用了動(dòng)態(tài)調(diào)整的方式：它會(huì)在發(fā)送數(shù)據(jù)的過(guò)程中持續(xù)測(cè)量ACK號(hào)返回的時(shí)間,，如果ACK號(hào)返回變慢,，則相應(yīng)地延長(zhǎng)等待時(shí)間，反之則縮短等待時(shí)間,。 第二個(gè)則是如何在帶確認(rèn)機(jī)制的情況下提高發(fā)送的效率 滑動(dòng)窗口如果每發(fā)送一個(gè)包就等待一個(gè)ACK號(hào),，等ACK號(hào)到了再發(fā)送下一個(gè)包，在等待的過(guò)程中什么都不錯(cuò),，那就太浪費(fèi)了,。因此TCP其實(shí)會(huì)采用一種叫滑動(dòng)窗口的機(jī)制來(lái)提高數(shù)據(jù)收發(fā)的效率，以將等待ACK號(hào)的這段時(shí)間利用起來(lái),。
從圖中可以看到,，使用滑動(dòng)窗口后，收發(fā)的效率大大提高了但是這樣就可能出現(xiàn)發(fā)送包的頻率超過(guò)對(duì)方接受處理的能力的情況,，因此在通信的過(guò)程中,，接受方需要告知發(fā)送方自己最多能接受多少數(shù)據(jù)，然后發(fā)送方根據(jù)這個(gè)值對(duì)數(shù)據(jù)發(fā)送操作進(jìn)行調(diào)整,。
（注意,，窗口有兩個(gè)，一個(gè)擁塞窗口,，一個(gè)流量窗口,，收發(fā)速度取這兩者的最小值） 有時(shí)候我們的流量控制窗口可能制約我們無(wú)法充分利用帶寬，所以要注意對(duì)流量控制窗口大小的觀察與調(diào)整,。比如假設(shè)流量窗口大小為16KB,，往返時(shí)間為100ms。那么不管兩端的實(shí)際帶寬有多大,，這個(gè)TCP連接的傳輸速率都不會(huì)超過(guò)1,，31Mbps。所以你的帶寬很高,，傳輸速度卻很慢,，那窗口大小可能就是主要原因。
還需要注意的一點(diǎn)是,，TCP的收發(fā)速度不僅有接收方接收能力決定,，還受到網(wǎng)絡(luò)狀況的影響。尤其在剛建立起連接時(shí)，TCP會(huì)采用一種“慢啟動(dòng)”的算法,。也即將窗口（擁塞窗口）大小設(shè)置在一個(gè)比較小的值（4個(gè)TCP端）,，然后在分組被確認(rèn)后成倍增長(zhǎng)，但一旦丟包率增加,，又會(huì)成倍減少再緩慢上升,。
無(wú)論帶寬多大，每個(gè)TCP連接都必須經(jīng)過(guò)慢啟動(dòng)階段,，所以我們其實(shí)無(wú)法一上來(lái)就完全利用連接的最大帶寬,。尤其在初始窗口是4段的情況下。但是現(xiàn)在很多操作系統(tǒng)已經(jīng)更新了內(nèi)核,，采用了增大后的值（RFC6928規(guī)定的10段） 斷開(kāi)階段想發(fā)的數(shù)據(jù)發(fā)完后,，就進(jìn)入斷開(kāi)階段。我們常說(shuō)的四次揮手也是發(fā)現(xiàn)在這一階段,。通信的其中一方會(huì)調(diào)用close來(lái)斷開(kāi)連接,，接下來(lái)另一端調(diào)用read執(zhí)行接收數(shù)據(jù)操作時(shí)，read會(huì)告知它通信階段已結(jié)束,，因此它也會(huì)調(diào)用close進(jìn)入斷開(kāi)階段,。至此,。整個(gè)通信過(guò)程就結(jié)束了,。 網(wǎng)卡前面我們一直提到的網(wǎng)絡(luò)包，直到協(xié)議棧的IP模塊這個(gè)環(huán)節(jié),，他們還都是存放在內(nèi)存中的一串?dāng)?shù)字信息,，沒(méi)法直接發(fā)送給對(duì)方。想要在網(wǎng)線(xiàn)上傳輸,，我們需要將數(shù)字信息轉(zhuǎn)換為電信號(hào)或光信號(hào),。而負(fù)責(zé)這個(gè)操作的是電腦中的網(wǎng)卡。當(dāng)我們打開(kāi)計(jì)算機(jī),，操作系統(tǒng)被啟動(dòng)后,，網(wǎng)卡驅(qū)動(dòng)程序會(huì)對(duì)網(wǎng)卡進(jìn)行初始化，然后網(wǎng)卡進(jìn)入可用的狀態(tài),。（網(wǎng)卡的相關(guān)結(jié)構(gòu)見(jiàn)下圖）
下面我們看下網(wǎng)卡是如何將包轉(zhuǎn)換成電信號(hào)并發(fā)送進(jìn)網(wǎng)線(xiàn)中的,。 網(wǎng)卡發(fā)送包首先網(wǎng)卡驅(qū)動(dòng)從IP模塊獲取包，將其復(fù)制到網(wǎng)卡內(nèi)的緩沖區(qū)中,，然后向MAC模塊發(fā)送發(fā)送包的命令,。 接下來(lái)MAC模塊從緩沖區(qū)將包取出，并在開(kāi)頭加上報(bào)頭和起始幀分界符,，在末尾加上用于檢測(cè)錯(cuò)誤的幀校驗(yàn)序列（FCS）,。這里我們停一下，解釋一下這幾個(gè)東西和他們的作用：
報(bào)頭是一串長(zhǎng)度為56比特像1010101010...這樣的1和0交替的比特序列，它的作用是確定包的讀取時(shí)機(jī),，接收方在收信號(hào)時(shí),，遇到這樣的波形就可以判斷讀取數(shù)據(jù)的時(shí)機(jī)（就像裁判員的：“各就位，預(yù)備...”） 而FCS則是一個(gè)通過(guò)公式對(duì)包中從頭到尾的所有內(nèi)容計(jì)算出的一串32比特的序列,，用于檢查包傳輸過(guò)程中因噪聲導(dǎo)致的波形紊亂,、數(shù)據(jù)錯(cuò)誤。如果原始數(shù)據(jù)中某一個(gè)比特發(fā)送變化,，那么接收方計(jì)算出的FCS和發(fā)送方計(jì)算出的FCS就會(huì)不一樣,。我們就能根據(jù)此判斷此包有沒(méi)有錯(cuò)誤，有則將其拋棄,。 然后我們講一下我們是如何通過(guò)電信號(hào)來(lái)讀取數(shù)據(jù)的： 用電信號(hào)表達(dá)數(shù)字信息時(shí),，我們需要讓0和1兩種比特分別對(duì)應(yīng)特定的電壓和電流，通過(guò)電信號(hào)來(lái)讀取數(shù)據(jù)的過(guò)程就是通過(guò)測(cè)量信號(hào)中的電壓和電流變化,，還原出0和1的兩種比特值,。然而有一個(gè)問(wèn)題是，當(dāng)出現(xiàn)連續(xù)一串的0或1時(shí),，如何判斷出比特的界限在哪里,？答案是將數(shù)據(jù)信號(hào)和時(shí)鐘信號(hào)疊加。由于時(shí)鐘信號(hào)是按固定頻率變化的,，可以根據(jù)時(shí)鐘周期和接收到的信號(hào)逆推出真實(shí)的數(shù)據(jù)信號(hào),。
接下來(lái)PHY模塊會(huì)將這些電信號(hào)轉(zhuǎn)為可在網(wǎng)線(xiàn)上傳輸?shù)母袷剑⑼ㄟ^(guò)網(wǎng)線(xiàn)發(fā)送出去（以太網(wǎng)規(guī)格中對(duì)不同的網(wǎng)線(xiàn)類(lèi)型和速率以及對(duì)應(yīng)的信號(hào)格式進(jìn)行了規(guī)定）,。 網(wǎng)卡接收包接下來(lái)我們說(shuō)一說(shuō)網(wǎng)卡接收網(wǎng)絡(luò)包時(shí)的操作過(guò)程,，過(guò)程會(huì)反過(guò)來(lái)：
其實(shí)我們的數(shù)據(jù)包從我們電腦網(wǎng)卡出來(lái)后,，并不是直接就進(jìn)入互聯(lián)網(wǎng)了。它需要由交換機(jī),、路由器等設(shè)備一步步轉(zhuǎn)發(fā),，從局域網(wǎng)到接入網(wǎng)再進(jìn)入到互聯(lián)網(wǎng)。但這篇文章已經(jīng)有點(diǎn)長(zhǎng)了,，關(guān)于這個(gè)的過(guò)程我們留到下一篇再做詳細(xì)介紹 |
|
|
