01
在Cisco平臺(tái)上有一個(gè)很有用的Tracebacklog功能,實(shí)時(shí)記錄當(dāng)前Code運(yùn)行到特定模塊、特定函數(shù),這樣一旦系統(tǒng)崩潰、死機(jī)的時(shí)候,可以有效記錄機(jī)器是在哪個(gè)模塊、哪個(gè)函數(shù)里崩潰的。只要將此Traceback輸入解析器,就可以定位是哪個(gè)模塊出了問(wèn)題,提交Bug的時(shí)候就可以Assign給負(fù)責(zé)此模塊的Team,避免部門(mén)之間的推諉。
其實(shí)Traceback的原理也很簡(jiǎn)單,即每進(jìn)入一個(gè)模塊,就記錄一下實(shí)時(shí)位置,類(lèi)似于Debug。
TCP/IP協(xié)議如果也擁有類(lèi)似的traceback日志信息,那么只要用packet觸發(fā)一下,就可以實(shí)時(shí)看一個(gè)packet如何在TCP/IP內(nèi)部函數(shù)流轉(zhuǎn),在packet被遞交給網(wǎng)卡之前,打印出每一個(gè)函數(shù)的名稱(chēng),然后進(jìn)入TCP/IP源碼,按照函數(shù)調(diào)用的先后次序(流水線)依次進(jìn)入閱讀,只有這樣才能詳細(xì)了解TCP/IP細(xì)節(jié)。
但是這樣的學(xué)習(xí)門(mén)檻很高,源碼也不是那么可以輕易看懂。對(duì)于大多數(shù)讀者來(lái)說(shuō),更容易的方法是先易后難,在開(kāi)始TCP/IP學(xué)習(xí)之前,先問(wèn)自己一個(gè)問(wèn)題,為什么要有TCP/IP協(xié)議?
02
計(jì)算機(jī)網(wǎng)絡(luò)的標(biāo)準(zhǔn)件
TCP/IP是計(jì)算機(jī)網(wǎng)絡(luò)世界的標(biāo)準(zhǔn)件,這些標(biāo)準(zhǔn)件類(lèi)似于汽車(chē)界的標(biāo)準(zhǔn)輪胎、汽車(chē)穩(wěn)定系統(tǒng)ESP,即使看似牛叉的Tesla汽車(chē)生產(chǎn)商,也不是所有汽車(chē)零部件都是自己生產(chǎn)。除了電池、外殼、軟件是自己生產(chǎn)的除外,其他的標(biāo)準(zhǔn)件全部是采購(gòu)而來(lái)。通過(guò)使用標(biāo)準(zhǔn)件,平均只要幾分鐘即可生產(chǎn)一輛汽車(chē)。如果不使用標(biāo)準(zhǔn)件而全部采用自研,那生產(chǎn)的周期要大大加長(zhǎng)。
既然TCP/IP是標(biāo)準(zhǔn)件,是不是也要像汽車(chē)輪胎一樣提供標(biāo)準(zhǔn)的接口?否則怎么安裝呢? 是的,TCP/IP提供了諸多的標(biāo)準(zhǔn)接口,通過(guò)這些標(biāo)準(zhǔn)接口可以有效使用標(biāo)準(zhǔn)件,如DNS、TCP、UDP、IP、ICMP、IGMP、ARP、DHCP等等標(biāo)準(zhǔn)件。當(dāng)然如果一一介紹這些標(biāo)準(zhǔn)件如何使用,這些標(biāo)準(zhǔn)件內(nèi)部的工作原理是非??菰锏?,還是以小例子看看這些標(biāo)準(zhǔn)件是如何協(xié)作的。
03
一個(gè)小例子
在瀏覽里輸入知乎的網(wǎng)址(zhihu.com),然后輸入回車(chē),瀏覽器使用的TCP/IP第一個(gè)標(biāo)準(zhǔn)件是什么呢?
讀者說(shuō),瀏覽器與知乎服務(wù)器通信使用http,而http通常是使用標(biāo)準(zhǔn)件TCP的,那么第一個(gè)標(biāo)準(zhǔn)件應(yīng)該是TCP,對(duì)嗎? 不對(duì)。 TCP這個(gè)標(biāo)準(zhǔn)件,對(duì)于http來(lái)說(shuō)身份是服務(wù)員,盡管TCP身份低微,但是卻有鮮明個(gè)性。就是任何人差遣自己干活,必須使用IP地址。瀏覽器不能使用網(wǎng)址(zhihu.com)這個(gè)字符串來(lái)差遣自己,罷工。
04
標(biāo)準(zhǔn)件之DNS
所以,瀏覽器使用第一個(gè)TCP/IP標(biāo)準(zhǔn)件是DNS。DNS其實(shí)就是將知乎的網(wǎng)址(zhihu.com)解析成一個(gè)IP地址。有了知乎的IP地址,才能使用TCP這個(gè)標(biāo)準(zhǔn)件。
讀者會(huì)說(shuō),DNS域名查詢,會(huì)使用UDP這個(gè)標(biāo)準(zhǔn)件,UDP標(biāo)準(zhǔn)件會(huì)使用IP標(biāo)準(zhǔn)件,IP標(biāo)準(zhǔn)件直接會(huì)使用以太網(wǎng)卡標(biāo)準(zhǔn)件,對(duì)嗎? 不對(duì)。 以太網(wǎng)卡標(biāo)準(zhǔn)件,作為IP標(biāo)準(zhǔn)件的服務(wù)員,盡管身份卑微,但是個(gè)性鮮明,凡是讓自己干活的客人,必須提供接收方的MAC地址,否則恕不接待。所以IP標(biāo)準(zhǔn)件需要先使用ARP標(biāo)準(zhǔn)件,查詢接收方的MAC地址。
讀者又說(shuō),ARP這個(gè)標(biāo)準(zhǔn)件使用的也是以太網(wǎng)卡標(biāo)準(zhǔn)件,沒(méi)有接收方的MAC地址,以太網(wǎng)卡不是恕不接待的嘛? 是的。 但是ARP使用廣播MAC地址(FFFFFFFFFFFF)來(lái)查詢啊,所以以太網(wǎng)卡不得不執(zhí)行查詢?nèi)蝿?wù)啊。 假設(shè)一切順利,ARP得到了回復(fù)答案,將ARP答案返回IP標(biāo)準(zhǔn)件。
既然IP標(biāo)準(zhǔn)件擁有了接收方的MAC地址,就可以使用以太網(wǎng)卡標(biāo)準(zhǔn)件,將packet提交給以太網(wǎng)卡,packet的進(jìn)一步處理就和TCP/IP沒(méi)有關(guān)系了。 不一會(huì)DNS查詢結(jié)果報(bào)文返回,按照時(shí)間先后次序進(jìn)入網(wǎng)卡物理層、MAC層、IP標(biāo)準(zhǔn)件、UDP標(biāo)準(zhǔn)件、DNS標(biāo)準(zhǔn)件,由DNS標(biāo)準(zhǔn)件將查詢結(jié)果告知瀏覽器。
以上的DNS查詢過(guò)程,瀏覽器其實(shí)只直接使用了DNS標(biāo)準(zhǔn)件,并沒(méi)有直接使用其它標(biāo)準(zhǔn)件,其他標(biāo)準(zhǔn)件的使用都是由DNS標(biāo)準(zhǔn)件(進(jìn)程)間接觸發(fā)使用。 有讀者會(huì)說(shuō),DNS標(biāo)準(zhǔn)件、ARP標(biāo)準(zhǔn)件功能非常清晰也很有必要,多出來(lái)的那兩個(gè)標(biāo)準(zhǔn)件IP、UDP看起來(lái)非常多余,為什么要有它們啊?
05
標(biāo)準(zhǔn)件之IP
問(wèn)讀者一個(gè)問(wèn)題,瀏覽器查詢得到知乎的IP地址,是留給自己看的嗎?
很顯然不是,IP地址肯定是給互聯(lián)網(wǎng)看的,準(zhǔn)確地說(shuō)是給互聯(lián)網(wǎng)上的IP路由器看的,IP路由器看了知乎的IP地址,才能將IP報(bào)文快遞到知乎服務(wù)器,不是嗎?
知乎的IP地址寫(xiě)在什么地方呢?
寫(xiě)在packet的IP報(bào)文頭。
由誰(shuí)來(lái)寫(xiě)?
IP標(biāo)準(zhǔn)件,IP標(biāo)準(zhǔn)件所做的工作遠(yuǎn)不是在包裹的外層添加一個(gè)IP封裝,并在外包裝上寫(xiě)下知乎的IP地址(目的IP)、瀏覽器主機(jī)的IP地址(源IP)那么簡(jiǎn)單,還需要查詢路由表,尋找合適的出口。否則一個(gè)主機(jī)有多個(gè)網(wǎng)卡,連接內(nèi)網(wǎng)和互聯(lián)網(wǎng),主機(jī)怎么將訪問(wèn)知乎的packet發(fā)給連接互聯(lián)網(wǎng)的網(wǎng)卡,而不是連接內(nèi)網(wǎng)的網(wǎng)卡呢?
這就是IP標(biāo)準(zhǔn)件的另外一項(xiàng)主要工作。而要完成種種復(fù)雜的工作,最好的方式就是以一個(gè)實(shí)例instance形式(進(jìn)程)存在。 至于UDP標(biāo)準(zhǔn)件,先不寫(xiě),等寫(xiě)完TCP再寫(xiě)。
06
標(biāo)準(zhǔn)件之TCP
再返回第一個(gè)問(wèn)題,瀏覽器擁有了知乎的IP地址,是否就可以將http request用TCP標(biāo)準(zhǔn)件發(fā)出了呢?
依然不行。 TCP這個(gè)怪癖狂,非常有個(gè)性,要想使用它必須遵守它的怪癖。這個(gè)怪癖是什么呢?
Create()
需要先要調(diào)用TCP標(biāo)準(zhǔn)件一個(gè)Create指定,該指令其實(shí)就是在本地內(nèi)存創(chuàng)建一個(gè)結(jié)構(gòu)體(內(nèi)存),用于緩存TCP連接所有相關(guān)的變量、數(shù)據(jù),最最重要的是這個(gè)結(jié)構(gòu)體有一個(gè)全局唯一的ID,瀏覽器以后要與TCP標(biāo)準(zhǔn)件溝通,只能使用這個(gè)唯一的ID(FD)。 Okay,TCP結(jié)構(gòu)體創(chuàng)建成功,是不是就可以發(fā)送http request了? 依然不行。
Connect()
TCP需要先建立連接,因?yàn)樯衔牡慕Y(jié)構(gòu)體是空白的,需要建立連接將關(guān)鍵參數(shù)進(jìn)行初始化,雙方的ISN,MSS、Window Size、SACK、Scaling Window等等。 建立TCP連接,使用TCP標(biāo)準(zhǔn)件的connect接口,填入合適的參數(shù),最重要的是知乎IP地址以及知乎端口,是80還是443,這將決定接下來(lái)是否需要使用TLS標(biāo)準(zhǔn)件,前者不需要,后者需要。
這就是大名鼎鼎的TCP三次握手,其實(shí)三次握手一點(diǎn)也不準(zhǔn)確。真實(shí)的含義是三個(gè)packet完成連接,瀏覽器發(fā)2個(gè)packet,知乎服務(wù)器發(fā)1個(gè)packet。之所以一直就這樣以訛傳訛到現(xiàn)在也沒(méi)有糾正,是因?yàn)橛⒅蟹g這樣最順口。 需要指出的是,TCP盡管有很多怪癖,但是connect環(huán)節(jié)以及之后的環(huán)節(jié)還是非常友好的。
你只要調(diào)用一次connect即可,至于瀏覽器是發(fā)2個(gè)packet連接成功,還是多次重傳連接成功,這都是connect接口內(nèi)部的實(shí)現(xiàn),瀏覽器無(wú)需關(guān)心。Connect只會(huì)告知瀏覽器兩個(gè)結(jié)果,成功或者失敗。 讀者有點(diǎn)急不可耐了,TCP連接建立成功,http request是否就可以發(fā)送出去了?
Send()
如果瀏覽器連接的是知乎TCP 端口80,是的,瀏覽器需要將httprequest數(shù)據(jù)通過(guò)調(diào)用TCP標(biāo)準(zhǔn)件send()接口發(fā)送出去,瀏覽器調(diào)用接口時(shí)需要攜帶FD唯一ID。 如果瀏覽器連接的是知乎TCP 端口443,即https服務(wù),依然不能發(fā)送數(shù)據(jù)。瀏覽器需要使用TLS標(biāo)準(zhǔn)件,與知乎服務(wù)器完成TLS安全加密連接才能發(fā)送http request。
07
標(biāo)準(zhǔn)件之TLS
盡管TLS是一個(gè)標(biāo)準(zhǔn)件,但是它卻工作于TCP之上,即TLS依賴(lài)于TCP為自己提供服務(wù)。所以TLS不是傳統(tǒng)意義上的TCP/IP標(biāo)準(zhǔn)件。
TLS安全連接,使用上文創(chuàng)建的唯一文件標(biāo)識(shí)符FD,使用TCP標(biāo)準(zhǔn)件的Send()、Receive()完成雙向數(shù)據(jù)的收發(fā),當(dāng)瀏覽器認(rèn)證知乎服務(wù)器數(shù)字證書(shū)合法雙方協(xié)商出加密/解密參數(shù),至此TLS標(biāo)準(zhǔn)件通知安全連接創(chuàng)建成功或者失敗。
瀏覽器的http request終于可以發(fā)出了,先流經(jīng)TLS標(biāo)準(zhǔn)件,添加TLS 報(bào)文頭,數(shù)據(jù)加密+數(shù)據(jù)完整性保護(hù)。再流轉(zhuǎn)到TCP標(biāo)準(zhǔn)件,添加TCP報(bào)文頭并發(fā)出,等待對(duì)方確認(rèn),啟動(dòng)超時(shí)重傳定時(shí)器。再流轉(zhuǎn)到IP標(biāo)準(zhǔn)件,查路由找出口,添加IP報(bào)文頭。
最后到達(dá)網(wǎng)卡,使用IP標(biāo)準(zhǔn)件提供的參數(shù),完成以太網(wǎng)封裝,進(jìn)入發(fā)送隊(duì)列。一旦輪到該報(bào)文,由物理層添加Preamble+ SFD + CRC將信號(hào)發(fā)送出去。 上文標(biāo)準(zhǔn)件調(diào)用的過(guò)程中,最值得研究的就是TCP,只有它對(duì)來(lái)自瀏覽器的http request進(jìn)行了數(shù)據(jù)緩存,并啟動(dòng)了定時(shí)器。
假設(shè)第一次發(fā)出的http request在互聯(lián)網(wǎng)被丟了,對(duì)該http request重傳的,既不是瀏覽器、也不是TLS、也不是IP、更不是以太網(wǎng)卡,而是那個(gè)有諸多怪癖的TCP,通過(guò)多次重傳以應(yīng)對(duì)可能丟包對(duì)瀏覽器數(shù)據(jù)的影響,這也是TCP可靠性的真正含義。瀏覽器一梭子打出去之后就不管數(shù)據(jù)死活了,TCP接管數(shù)據(jù)的重傳重任。
08
標(biāo)準(zhǔn)件之UDP
最后說(shuō)到UDP,看了上文的TCP發(fā)數(shù)據(jù)的過(guò)程,是不是覺(jué)得很繁瑣?是的,不光繁瑣而且非常耗時(shí),如果連DNS查詢也要使用TCP傳輸,意味著用戶需要等待更長(zhǎng)的時(shí)間才能開(kāi)始傳輸真正的數(shù)據(jù),需要用戶有更長(zhǎng)久的延遲滿足,很顯然耐心不夠的用戶會(huì)直接放棄。
而有了UDP就沒(méi)有那么繁瑣了,用戶使用UDP發(fā)送數(shù)據(jù)數(shù)據(jù),無(wú)需等待、無(wú)需建立連接,直接嗖得一聲,數(shù)據(jù)就UDP、IP、以太網(wǎng)走起,緊湊整潔,節(jié)省了用戶大量時(shí)間。
比如基于IP的實(shí)時(shí)語(yǔ)音以及視頻,為了良好的用戶體驗(yàn),通常需要50ms收發(fā)一個(gè)包裹,要到達(dá)這個(gè)低延遲,使用TCP很顯然是無(wú)法完成的,剩下的唯一選擇就是使用UDP來(lái)承載。
TCP/IP做為計(jì)算機(jī)網(wǎng)絡(luò)標(biāo)準(zhǔn)件的集中營(yíng),每一個(gè)標(biāo)準(zhǔn)件都可以直接調(diào)用,而不全是上文的間接調(diào)用。比如用戶可以直接使用IP標(biāo)準(zhǔn)件、ICMP標(biāo)準(zhǔn)件寫(xiě)程序,甚至直接調(diào)用以太網(wǎng)卡標(biāo)準(zhǔn)件,而不僅僅局限于TCP、UDP、DNS、TLS。
審核編輯:劉清
-
DNS
+關(guān)注
關(guān)注
0文章
214瀏覽量
19751 -
DHCP
+關(guān)注
關(guān)注
0文章
103瀏覽量
19635 -
TCPIP協(xié)議
+關(guān)注
關(guān)注
0文章
35瀏覽量
11912
原文標(biāo)題:如何能夠看懂TCP/IP 協(xié)議細(xì)節(jié)?
文章出處:【微信號(hào):良許Linux,微信公眾號(hào):良許Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論