應屆生馬上畢業了，總免不了求職面試這個環節。身為網絡工程師，在面試時，難免都會被問到TCP/IP這玩意兒。

對于TCP/IP，很多網絡工程師又愛又恨。

學網工，肯定都逃不開這個概念，要學的細致。但是實際工作中，很少能用到這類的理論概念，這不只是一個網工在吐槽。

但是，這個情況不只是網工一個人有，任何一個行業、崗位都是要從理論開始學起的。

職場發展到后期，不少人會接觸到管理，要學管理，也得是從一堆理論學起，晦澀難懂，大多數在實際工作中一樣沒法發揮啥真正效用。

那為什么要學？必須是有理由的。

學習管理學理論，是為了讓你更好理解管理到底是什么；

學習網絡基礎知識，也是為了讓你理解網絡到底是什么。

只有理解了“是什么”，你才能進一步深究“為什么”，最后反饋到你的工作層面，折射出來的每個“怎么做”，就是你在學習過程中成果展示了。

想要系統學習TCP/IP的小友，也歡迎私信老楊，網絡基礎其實在HCIA/CCNA認證課程中就有系統涉及到。

如果對考證有很多疑惑，苦于沒有人詢問的小友，也歡迎私信老楊，獲得我的解答。

既然，了解網絡基礎是每個網絡工程師職業發展的必然要求，那么，你的TCP/IP了解到什么程度，需要補充哪些部分，你又知道嗎？

今天這篇老文重溫，再為你梳理一遍關于TCP/IP那些事兒。

01 到底啥是TCP？

TCP的中文名叫做傳輸控制協議，是供已經連接因特網的計算機進行通信的通信協議

計算機通信協議是對那些計算機必須遵守以便彼此通信的的規則的描述。TCP是互聯網協議之一，也是主要的協議之一

為啥？

因為它起源于最初的網絡實施，在網絡實施中，它對互聯網協議起到了重要的補充作用。因此，整個套件通常被人稱呼為TCP/IP。

TCP/IP 定義了電子設備（比如計算機）如何連入因特網，以及數據如何在它們之間傳輸的標準。

TCP主要是給在用IP網絡通信的主機上運行的應用程序之間，提供一種可靠、有序且經過錯誤檢查的八位字節流傳遞。萬維網、文件傳輸、遠程管理等主要互聯網應用都依賴于TCP。

如果是那種不需要靠數據流服務的應用程序，就可以使用UDP（用戶數據報協議），它和TCP（傳輸控制協議）不同，前者強調降低延遲，后者強調可靠有序。

再說一點：TCP負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而IP則是給因特網的每一臺電腦規定一個地址。

有小白看到這里會問，那為啥計算機里一定要用到“xx協議”來傳輸信息呢？

因為單一的計算機并沒有辦法為人類發揮出最大的效用，只有把一臺又一臺的電腦連接起來，才能發揮出我們現在的功效。

這個連接不僅僅是單純的網絡連接，連起來也并不是簡單的用電線把你的心和我的心串一串就可以解決的，那咋整？

舉個例子：

每個電腦都運行著不同的操作系統，來給你提供對應的服務，對吧？

那么，電腦基于不同的系統，它們對于同個信息的表達是完全不一樣的，就想美國人說Good Morning，日本人說哦害喲，我說早啊大兄弟。

那語言不通，不能友好交流，就得想個辦法，我們一起制定一個共通的規則來進行交流就行了嘛。

于是TCP/IP這樣的協議就出現了。

計算機因為有了這類型的很多協議，就像人類學了多門外語一樣，就終于可以和其他的計算機終端放飛自我的交流了。

今日文章閱讀福利：《TCP-IP詳解卷一：協議》

如果你想更加系統的TCP/IP技術 ，也歡迎私信老楊，發送暗號“TCP”，我會把老網工?？吹腡CP/IP經典入門書籍發送給你，以作參考。

02 TCP是啥時候出現的？

講到TCP的誕生，就要回顧到1974年的那個夏天。

卡恩描述了一種使用網絡節點間分組交換來共享資源的互聯網協議，這就是TCP/IP的雛形

1974年的那個冬天，卡恩和瑟夫的第一份tcp協議詳細說明正式發表。

當時，他們做了一個試驗，將信息包通過點對點的衛星網絡，通過陸地電纜，再通過衛星網絡，然后由地面傳輸，貫串歐洲和美國，經過各種電腦系統，全程9.4萬公里，竟然沒有丟失一個數據位！

這樣的遠距離可靠數據傳輸，證明了TCP/IP協議的成功。

1983年元旦，運行了比較長時間的、曾被人們習慣了的NCP被停止使用，從此以后，TCP/IP協議就成了因特網上所有主機間的共同協議，被作為一種必須遵守的規則被肯定和應用。

03 TCP的“三次握手”是什么意思？

介紹完了TCP到底是個啥，現在我們來講講，TCP這個“握手”是怎么個回事兒。

“握手”你可以理解為是TCP發功時所需要的儀式。

因為TCP常常用來發送大批量的數據，所以，為了提供可靠的的傳送服務，TCP在發送數據之前，都需要用一種特定的順序將數據包編號，并將這些數據包傳送給目標，再確認消息。當對應的程序收到數據后，確認收到也需要用到TCP。

其實呢，三次握手就是為了對每次發送的數據量進行跟蹤與協商，確保數據段的發送和接收同步，根據所接收到的數據量而確認數據發送、接收完畢后何時撤消聯系，并建立虛連接。

那說了半天，到底握手是怎么握？

Step 1

TCP客戶端準備發送一個syn段，用來指明客戶打算鏈接的服務器端口以及isn（初始序號）。那么這個syn就被稱為“報文段1”。

Step 2

那么，接下來，TCP服務端就會發回包含TCP服務端isn的syn段（即報文段2）作為回應。與此同時，TCP服務端會將確認序號設置為TCP客戶端的isn+1，以對TCP客戶端的s y n報文段進行確認。

Step 3

最后，TCP客戶端也必須將確認的序號設置為TCP服務端的isn+1，作為對TCP服務端syn報文段的確認（即報文段3）這三個報文段就代表了連接的建立，而這個過程，就是TCP的三次握手（three-wayhandshake）。

04 TCP 為什么是三次握手，而不是兩次或四次？

當有人談論這個問題的時候，實則是在談論：

當 TCP 服務端發送連接請求確認報文段之后，當 TCP 客戶端收到這個報文，其實就算建立連接了，這個時候直接發送數據不就行了，為什么還要再次發送一個 TCP 普通確認報文段呢？這就這個問題的“真實翻譯”。

我們從兩個角度來解釋一下：

01 過程論證

我們就把這個過程簡單點說吧，別整的那么復雜。

我們假設一下，如果只握手兩次，會是什么情況？

假設，客戶端發送的第一個連接請求沒有成功，那服務端就沒辦法收到這個報文段，對吧？

你如果給女朋友發微信沒發出去，肯定會再發一次啊。那客戶端也是這么想的啊，它準備重新發送連接+請求報文段，那，服務器這下可算收到這個報文段了，進入連接建立好了狀態。

客戶端這個時候，也進入了連接，建立狀態，可以進行數據傳輸了對吧？

但是呢，第一次的請求報文發送失敗了，它悄咪咪的開始了超時重傳，但客戶端和服務端都早已建立好了鏈接，這個時候就導致TCP的服務端白白等待，浪費大量資源。

所以兩次握手性價比不高，穩定性不足。

再簡單一點舉個例子：小明給小紅發消息，小紅呢，收到小明消息后，回了個消息。

那么證明了一點，就是小明發送能力沒有問題，小紅接收能力也沒有問題。

那如果小明不回了，那小明到底看到沒看到消息就無法判斷了，小紅就會想：到底是啥原因他不回我消息??？我做錯了啥??？

所以啊，小明如果在再發一次消息給小紅的話，就確認了小明其實看到了小紅的消息，也確認了小明的接收能力是正常的。

同時，小紅也的確真的給小明發了消息，所以他才會回復，所以小紅的發送能力也是正常的。

這就是TCP非要握手三次不可的原因。

02 他人論證

還不懂得的，可以圍觀一下謝希仁版的《計算機網絡》，它全面介紹了計算機網絡的發展和原理體系結構、物理層、數據鏈路層等內容，應該沒有沒看過的IT人吧？

書里說過，TCP的握手，其實是為了保證雙方互相明確對方收發能力的最低值。兩次太少，四次太多，三次正正好。

而且啊，其實不論握手多少次都不能確認一條信道是“可靠”的，但通過3次握手可以至少確認它是“可用”的，再往上加握手次數，其實就不過是提高“它是可用的”這個結論的可信程度。

而且嚴格來說，三次握手其實是雙方各握手一次，然后各確認一次，其中，一次握手+確認是合并在一起的，這才是“三次”的由來。