01

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

其實Traceback的原理也很簡單，即每進入一個模塊，就記錄一下實時位置，類似于Debug。

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

但是這樣的學習門檻很高，源碼也不是那么可以輕易看懂。對于大多數(shù)讀者來說，更容易的方法是先易后難，在開始TCP/IP學習之前，先問自己一個問題，為什么要有TCP/IP協(xié)議？

02

計算機網(wǎng)絡的標準件

TCP/IP是計算機網(wǎng)絡世界的標準件，這些標準件類似于汽車界的標準輪胎、汽車穩(wěn)定系統(tǒng)ESP，即使看似牛叉的Tesla汽車生產(chǎn)商，也不是所有汽車零部件都是自己生產(chǎn)。除了電池、外殼、軟件是自己生產(chǎn)的除外，其他的標準件全部是采購而來。通過使用標準件，平均只要幾分鐘即可生產(chǎn)一輛汽車。如果不使用標準件而全部采用自研，那生產(chǎn)的周期要大大加長。

既然TCP/IP是標準件，是不是也要像汽車輪胎一樣提供標準的接口？否則怎么安裝呢？ 是的，TCP/IP提供了諸多的標準接口，通過這些標準接口可以有效使用標準件，如DNS、TCP、UDP、IP、ICMP、IGMP、ARP、DHCP等等標準件。當然如果一一介紹這些標準件如何使用，這些標準件內(nèi)部的工作原理是非常枯燥的，還是以小例子看看這些標準件是如何協(xié)作的。

03

一個小例子

在瀏覽里輸入知乎的網(wǎng)址（zhihu.com），然后輸入回車，瀏覽器使用的TCP/IP第一個標準件是什么呢？

讀者說，瀏覽器與知乎服務器通信使用http，而http通常是使用標準件TCP的，那么第一個標準件應該是TCP，對嗎？ 不對。 TCP這個標準件，對于http來說身份是服務員，盡管TCP身份低微，但是卻有鮮明個性。就是任何人差遣自己干活，必須使用IP地址。瀏覽器不能使用網(wǎng)址（zhihu.com）這個字符串來差遣自己，罷工。

04

標準件之DNS

所以，瀏覽器使用第一個TCP/IP標準件是DNS。DNS其實就是將知乎的網(wǎng)址（zhihu.com）解析成一個IP地址。有了知乎的IP地址，才能使用TCP這個標準件。

讀者會說，DNS域名查詢，會使用UDP這個標準件，UDP標準件會使用IP標準件，IP標準件直接會使用以太網(wǎng)卡標準件，對嗎？ 不對。 以太網(wǎng)卡標準件，作為IP標準件的服務員，盡管身份卑微，但是個性鮮明，凡是讓自己干活的客人，必須提供接收方的MAC地址，否則恕不接待。所以IP標準件需要先使用ARP標準件，查詢接收方的MAC地址。

讀者又說，ARP這個標準件使用的也是以太網(wǎng)卡標準件，沒有接收方的MAC地址，以太網(wǎng)卡不是恕不接待的嘛？ 是的。 但是ARP使用廣播MAC地址（FFFFFFFFFFFF）來查詢啊，所以以太網(wǎng)卡不得不執(zhí)行查詢?nèi)蝿瞻　?假設一切順利，ARP得到了回復答案，將ARP答案返回IP標準件。

既然IP標準件擁有了接收方的MAC地址，就可以使用以太網(wǎng)卡標準件，將packet提交給以太網(wǎng)卡，packet的進一步處理就和TCP/IP沒有關系了。 不一會DNS查詢結(jié)果報文返回，按照時間先后次序進入網(wǎng)卡物理層、MAC層、IP標準件、UDP標準件、DNS標準件，由DNS標準件將查詢結(jié)果告知瀏覽器。

以上的DNS查詢過程，瀏覽器其實只直接使用了DNS標準件，并沒有直接使用其它標準件，其他標準件的使用都是由DNS標準件（進程）間接觸發(fā)使用。 有讀者會說，DNS標準件、ARP標準件功能非常清晰也很有必要，多出來的那兩個標準件IP、UDP看起來非常多余，為什么要有它們啊？

05

標準件之IP

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

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

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

寫在packet的IP報文頭。

由誰來寫？

IP標準件，IP標準件所做的工作遠不是在包裹的外層添加一個IP封裝，并在外包裝上寫下知乎的IP地址（目的IP）、瀏覽器主機的IP地址（源IP）那么簡單，還需要查詢路由表，尋找合適的出口。否則一個主機有多個網(wǎng)卡，連接內(nèi)網(wǎng)和互聯(lián)網(wǎng)，主機怎么將訪問知乎的packet發(fā)給連接互聯(lián)網(wǎng)的網(wǎng)卡，而不是連接內(nèi)網(wǎng)的網(wǎng)卡呢？

這就是IP標準件的另外一項主要工作。而要完成種種復雜的工作，最好的方式就是以一個實例instance形式（進程）存在。 至于UDP標準件，先不寫，等寫完TCP再寫。

06

標準件之TCP

再返回第一個問題，瀏覽器擁有了知乎的IP地址，是否就可以將http request用TCP標準件發(fā)出了呢？

依然不行。 TCP這個怪癖狂，非常有個性，要想使用它必須遵守它的怪癖。這個怪癖是什么呢？

Create（）

需要先要調(diào)用TCP標準件一個Create指定，該指令其實就是在本地內(nèi)存創(chuàng)建一個結(jié)構(gòu)體（內(nèi)存），用于緩存TCP連接所有相關的變量、數(shù)據(jù)，最最重要的是這個結(jié)構(gòu)體有一個全局唯一的ID，瀏覽器以后要與TCP標準件溝通，只能使用這個唯一的ID（FD）。 Okay，TCP結(jié)構(gòu)體創(chuàng)建成功，是不是就可以發(fā)送http request了？ 依然不行。

Connect（）

TCP需要先建立連接，因為上文的結(jié)構(gòu)體是空白的，需要建立連接將關鍵參數(shù)進行初始化，雙方的ISN，MSS、Window Size、SACK、Scaling Window等等。 建立TCP連接，使用TCP標準件的connect接口，填入合適的參數(shù)，最重要的是知乎IP地址以及知乎端口，是80還是443，這將決定接下來是否需要使用TLS標準件，前者不需要，后者需要。

這就是大名鼎鼎的TCP三次握手，其實三次握手一點也不準確。真實的含義是三個packet完成連接，瀏覽器發(fā)2個packet，知乎服務器發(fā)1個packet。之所以一直就這樣以訛傳訛到現(xiàn)在也沒有糾正，是因為英中翻譯這樣最順口。 需要指出的是，TCP盡管有很多怪癖，但是connect環(huán)節(jié)以及之后的環(huán)節(jié)還是非常友好的。

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

Send（）

如果瀏覽器連接的是知乎TCP 端口80，是的，瀏覽器需要將httprequest數(shù)據(jù)通過調(diào)用TCP標準件send（）接口發(fā)送出去，瀏覽器調(diào)用接口時需要攜帶FD唯一ID。 如果瀏覽器連接的是知乎TCP 端口443，即https服務，依然不能發(fā)送數(shù)據(jù)。瀏覽器需要使用TLS標準件，與知乎服務器完成TLS安全加密連接才能發(fā)送http request。

07

標準件之TLS

盡管TLS是一個標準件，但是它卻工作于TCP之上，即TLS依賴于TCP為自己提供服務。所以TLS不是傳統(tǒng)意義上的TCP/IP標準件。

TLS安全連接，使用上文創(chuàng)建的唯一文件標識符FD，使用TCP標準件的Send（）、Receive（）完成雙向數(shù)據(jù)的收發(fā)，當瀏覽器認證知乎服務器數(shù)字證書合法雙方協(xié)商出加密/解密參數(shù)，至此TLS標準件通知安全連接創(chuàng)建成功或者失敗。

瀏覽器的http request終于可以發(fā)出了，先流經(jīng)TLS標準件，添加TLS 報文頭，數(shù)據(jù)加密+數(shù)據(jù)完整性保護。再流轉(zhuǎn)到TCP標準件，添加TCP報文頭并發(fā)出，等待對方確認，啟動超時重傳定時器。再流轉(zhuǎn)到IP標準件，查路由找出口，添加IP報文頭。

最后到達網(wǎng)卡，使用IP標準件提供的參數(shù)，完成以太網(wǎng)封裝，進入發(fā)送隊列。一旦輪到該報文，由物理層添加Preamble+ SFD + CRC將信號發(fā)送出去。 上文標準件調(diào)用的過程中，最值得研究的就是TCP，只有它對來自瀏覽器的http request進行了數(shù)據(jù)緩存，并啟動了定時器。

假設第一次發(fā)出的http request在互聯(lián)網(wǎng)被丟了，對該http request重傳的，既不是瀏覽器、也不是TLS、也不是IP、更不是以太網(wǎng)卡，而是那個有諸多怪癖的TCP，通過多次重傳以應對可能丟包對瀏覽器數(shù)據(jù)的影響，這也是TCP可靠性的真正含義。瀏覽器一梭子打出去之后就不管數(shù)據(jù)死活了，TCP接管數(shù)據(jù)的重傳重任。

08

標準件之UDP

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

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

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

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

審核編輯：劉清