怎樣才能詳細(xì)了解TCP/IP協(xié)議細(xì)節(jié)呢？

01

在Cisco平臺(tái)上有一個(gè)很有用的Tracebacklog功能，實(shí)時(shí)記錄當(dāng)前Code運(yùn)行到特定模塊、特定函數(shù)，這樣一旦系統(tǒng)崩潰、死機(jī)的時(shí)候，可以有效記錄機(jī)器是在哪個(gè)模塊、哪個(gè)函數(shù)里崩潰的。只要將此Traceback輸入解析器，就可以定位是哪個(gè)模塊出了問題，提交Bug的時(shí)候就可以Assign給負(fù)責(zé)此模塊的Team，避免部門之間的推諉。

其實(shí)Traceback的原理也很簡單，即每進(jìn)入一個(gè)模塊，就記錄一下實(shí)時(shí)位置，類似于Debug。

TCP/IP協(xié)議如果也擁有類似的traceback日志信息，那么只要用packet觸發(fā)一下，就可以實(shí)時(shí)看一個(gè)packet如何在TCP/IP內(nèi)部函數(shù)流轉(zhuǎn)，在packet被遞交給網(wǎng)卡之前，打印出每一個(gè)函數(shù)的名稱，然后進(jìn)入TCP/IP源碼，按照函數(shù)調(diào)用的先后次序（流水線）依次進(jìn)入閱讀，只有這樣才能詳細(xì)了解TCP/IP細(xì)節(jié)。

但是這樣的學(xué)習(xí)門檻很高，源碼也不是那么可以輕易看懂。對(duì)于大多數(shù)讀者來說，更容易的方法是先易后難，在開始TCP/IP學(xué)習(xí)之前，先問自己一個(gè)問題，為什么要有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)件類似于汽車界的標(biāo)準(zhǔn)輪胎、汽車穩(wěn)定系統(tǒng)ESP，即使看似牛叉的Tesla汽車生產(chǎn)商，也不是所有汽車零部件都是自己生產(chǎn)。除了電池、外殼、軟件是自己生產(chǎn)的除外，其他的標(biāo)準(zhǔn)件全部是采購而來。通過使用標(biāo)準(zhǔn)件，平均只要幾分鐘即可生產(chǎn)一輛汽車。如果不使用標(biāo)準(zhǔn)件而全部采用自研，那生產(chǎn)的周期要大大加長。

既然TCP/IP是標(biāo)準(zhǔn)件，是不是也要像汽車輪胎一樣提供標(biāo)準(zhǔn)的接口？否則怎么安裝呢？ 是的，TCP/IP提供了諸多的標(biāo)準(zhǔn)接口，通過這些標(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），然后輸入回車，瀏覽器使用的TCP/IP第一個(gè)標(biāo)準(zhǔn)件是什么呢？

讀者說，瀏覽器與知乎服務(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來說身份是服務(wù)員，盡管TCP身份低微，但是卻有鮮明個(gè)性。就是任何人差遣自己干活，必須使用IP地址。瀏覽器不能使用網(wǎng)址（zhihu.com）這個(gè)字符串來差遣自己，罷工。

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ì)說，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地址。

讀者又說，ARP這個(gè)標(biāo)準(zhǔn)件使用的也是以太網(wǎng)卡標(biāo)準(zhǔn)件，沒有接收方的MAC地址，以太網(wǎng)卡不是恕不接待的嘛？ 是的。 但是ARP使用廣播MAC地址（FFFFFFFFFFFF）來查詢啊，所以以太網(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沒有關(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查詢過程，瀏覽器其實(shí)只直接使用了DNS標(biāo)準(zhǔn)件，并沒有直接使用其它標(biāo)準(zhǔn)件，其他標(biāo)準(zhǔn)件的使用都是由DNS標(biāo)準(zhǔn)件（進(jìn)程）間接觸發(fā)使用。 有讀者會(huì)說，DNS標(biāo)準(zhǔn)件、ARP標(biāo)準(zhǔn)件功能非常清晰也很有必要，多出來的那兩個(gè)標(biāo)準(zhǔn)件IP、UDP看起來非常多余，為什么要有它們啊？

05

標(biāo)準(zhǔn)件之IP

問讀者一個(gè)問題，瀏覽器查詢得到知乎的IP地址，是留給自己看的嗎？

很顯然不是，IP地址肯定是給互聯(lián)網(wǎng)看的，準(zhǔn)確地說是給互聯(lián)網(wǎng)上的IP路由器看的，IP路由器看了知乎的IP地址，才能將IP報(bào)文快遞到知乎服務(wù)器，不是嗎？

知乎的IP地址寫在什么地方呢？

寫在packet的IP報(bào)文頭。

由誰來寫？

IP標(biāo)準(zhǔn)件，IP標(biāo)準(zhǔn)件所做的工作遠(yuǎn)不是在包裹的外層添加一個(gè)IP封裝，并在外包裝上寫下知乎的IP地址（目的IP）、瀏覽器主機(jī)的IP地址（源IP）那么簡單，還需要查詢路由表，尋找合適的出口。否則一個(gè)主機(jī)有多個(gè)網(wǎng)卡，連接內(nèi)網(wǎng)和互聯(lián)網(wǎng)，主機(jī)怎么將訪問知乎的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)件，先不寫，等寫完TCP再寫。

06

標(biāo)準(zhǔn)件之TCP

再返回第一個(gè)問題，瀏覽器擁有了知乎的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，這將決定接下來是否需要使用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)在也沒有糾正，是因?yàn)橛⒅蟹g這樣最順口。 需要指出的是，TCP盡管有很多怪癖，但是connect環(huán)節(jié)以及之后的環(huán)節(jié)還是非常友好的。

你只要調(diào)用一次connect即可，至于瀏覽器是發(fā)2個(gè)packet連接成功，還是多次重傳連接成功，這都是connect接口內(nèi)部的實(shí)現(xiàn)，瀏覽器無需關(guān)心。Connect只會(huì)告知瀏覽器兩個(gè)結(jié)果，成功或者失敗。 讀者有點(diǎn)急不可耐了，TCP連接建立成功，http request是否就可以發(fā)送出去了？

Send（）

如果瀏覽器連接的是知乎TCP 端口80，是的，瀏覽器需要將httprequest數(shù)據(jù)通過調(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依賴于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ù)字證書合法雙方協(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)用的過程中，最值得研究的就是TCP，只有它對(duì)來自瀏覽器的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，通過多次重傳以應(yīng)對(duì)可能丟包對(duì)瀏覽器數(shù)據(jù)的影響，這也是TCP可靠性的真正含義。瀏覽器一梭子打出去之后就不管數(shù)據(jù)死活了，TCP接管數(shù)據(jù)的重傳重任。

08

標(biāo)準(zhǔn)件之UDP

最后說到UDP，看了上文的TCP發(fā)數(shù)據(jù)的過程，是不是覺得很繁瑣？是的，不光繁瑣而且非常耗時(shí)，如果連DNS查詢也要使用TCP傳輸，意味著用戶需要等待更長的時(shí)間才能開始傳輸真正的數(shù)據(jù)，需要用戶有更長久的延遲滿足，很顯然耐心不夠的用戶會(huì)直接放棄。

而有了UDP就沒有那么繁瑣了，用戶使用UDP發(fā)送數(shù)據(jù)數(shù)據(jù)，無需等待、無需建立連接，直接嗖得一聲，數(shù)據(jù)就UDP、IP、以太網(wǎng)走起，緊湊整潔，節(jié)省了用戶大量時(shí)間。

比如基于IP的實(shí)時(shí)語音以及視頻，為了良好的用戶體驗(yàn)，通常需要50ms收發(fā)一個(gè)包裹，要到達(dá)這個(gè)低延遲，使用TCP很顯然是無法完成的，剩下的唯一選擇就是使用UDP來承載。

TCP/IP做為計(jì)算機(jī)網(wǎng)絡(luò)標(biāo)準(zhǔn)件的集中營，每一個(gè)標(biāo)準(zhǔn)件都可以直接調(diào)用，而不全是上文的間接調(diào)用。比如用戶可以直接使用IP標(biāo)準(zhǔn)件、ICMP標(biāo)準(zhǔn)件寫程序，甚至直接調(diào)用以太網(wǎng)卡標(biāo)準(zhǔn)件，而不僅僅局限于TCP、UDP、DNS、TLS。

審核編輯：劉清