01
在Cisco平臺上有一個很有用的Tracebacklog功能,實時記錄當前Code運行到特定模塊、特定函數,這樣一旦系統崩潰、死機的時候,可以有效記錄機器是在哪個模塊、哪個函數里崩潰的。只要將此Traceback輸入解析器,就可以定位是哪個模塊出了問題,提交Bug的時候就可以Assign給負責此模塊的Team,避免部門之間的推諉。
其實Traceback的原理也很簡單,即每進入一個模塊,就記錄一下實時位置,類似于Debug。
TCP/IP協議如果也擁有類似的traceback日志信息,那么只要用packet觸發一下,就可以實時看一個packet如何在TCP/IP內部函數流轉,在packet被遞交給網卡之前,打印出每一個函數的名稱,然后進入TCP/IP源碼,按照函數調用的先后次序(流水線)依次進入閱讀,只有這樣才能詳細了解TCP/IP細節。
但是這樣的學習門檻很高,源碼也不是那么可以輕易看懂。對于大多數讀者來說,更容易的方法是先易后難,在開始TCP/IP學習之前,先問自己一個問題,為什么要有TCP/IP協議?
02
計算機網絡的標準件
TCP/IP是計算機網絡世界的標準件,這些標準件類似于汽車界的標準輪胎、汽車穩定系統ESP,即使看似牛叉的Tesla汽車生產商,也不是所有汽車零部件都是自己生產。除了電池、外殼、軟件是自己生產的除外,其他的標準件全部是采購而來。通過使用標準件,平均只要幾分鐘即可生產一輛汽車。如果不使用標準件而全部采用自研,那生產的周期要大大加長。
既然TCP/IP是標準件,是不是也要像汽車輪胎一樣提供標準的接口?否則怎么安裝呢? 是的,TCP/IP提供了諸多的標準接口,通過這些標準接口可以有效使用標準件,如DNS、TCP、UDP、IP、ICMP、IGMP、ARP、DHCP等等標準件。當然如果一一介紹這些標準件如何使用,這些標準件內部的工作原理是非常枯燥的,還是以小例子看看這些標準件是如何協作的。
03
一個小例子
在瀏覽里輸入知乎的網址(zhihu.com),然后輸入回車,瀏覽器使用的TCP/IP第一個標準件是什么呢?
讀者說,瀏覽器與知乎服務器通信使用http,而http通常是使用標準件TCP的,那么第一個標準件應該是TCP,對嗎? 不對。 TCP這個標準件,對于http來說身份是服務員,盡管TCP身份低微,但是卻有鮮明個性。就是任何人差遣自己干活,必須使用IP地址。瀏覽器不能使用網址(zhihu.com)這個字符串來差遣自己,罷工。
04
標準件之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看起來非常多余,為什么要有它們啊?
05
標準件之IP
問讀者一個問題,瀏覽器查詢得到知乎的IP地址,是留給自己看的嗎?
很顯然不是,IP地址肯定是給互聯網看的,準確地說是給互聯網上的IP路由器看的,IP路由器看了知乎的IP地址,才能將IP報文快遞到知乎服務器,不是嗎?
知乎的IP地址寫在什么地方呢?
寫在packet的IP報文頭。
由誰來寫?
IP標準件,IP標準件所做的工作遠不是在包裹的外層添加一個IP封裝,并在外包裝上寫下知乎的IP地址(目的IP)、瀏覽器主機的IP地址(源IP)那么簡單,還需要查詢路由表,尋找合適的出口。否則一個主機有多個網卡,連接內網和互聯網,主機怎么將訪問知乎的packet發給連接互聯網的網卡,而不是連接內網的網卡呢?
這就是IP標準件的另外一項主要工作。而要完成種種復雜的工作,最好的方式就是以一個實例instance形式(進程)存在。 至于UDP標準件,先不寫,等寫完TCP再寫。
06
標準件之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,是的,瀏覽器需要將httprequest數據通過調用TCP標準件send()接口發送出去,瀏覽器調用接口時需要攜帶FD唯一ID。 如果瀏覽器連接的是知乎TCP 端口443,即https服務,依然不能發送數據。瀏覽器需要使用TLS標準件,與知乎服務器完成TLS安全加密連接才能發送http request。
07
標準件之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接管數據的重傳重任。
08
標準件之UDP
最后說到UDP,看了上文的TCP發數據的過程,是不是覺得很繁瑣?是的,不光繁瑣而且非常耗時,如果連DNS查詢也要使用TCP傳輸,意味著用戶需要等待更長的時間才能開始傳輸真正的數據,需要用戶有更長久的延遲滿足,很顯然耐心不夠的用戶會直接放棄。
而有了UDP就沒有那么繁瑣了,用戶使用UDP發送數據數據,無需等待、無需建立連接,直接嗖得一聲,數據就UDP、IP、以太網走起,緊湊整潔,節省了用戶大量時間。
比如基于IP的實時語音以及視頻,為了良好的用戶體驗,通常需要50ms收發一個包裹,要到達這個低延遲,使用TCP很顯然是無法完成的,剩下的唯一選擇就是使用UDP來承載。
TCP/IP做為計算機網絡標準件的集中營,每一個標準件都可以直接調用,而不全是上文的間接調用。比如用戶可以直接使用IP標準件、ICMP標準件寫程序,甚至直接調用以太網卡標準件,而不僅僅局限于TCP、UDP、DNS、TLS。
審核編輯:劉清
-
DNS
+關注
關注
0文章
217瀏覽量
19803 -
DHCP
+關注
關注
0文章
104瀏覽量
19676 -
TCPIP協議
+關注
關注
0文章
35瀏覽量
11924
原文標題:如何能夠看懂TCP/IP 協議細節?
文章出處:【微信號:良許Linux,微信公眾號:良許Linux】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論