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