我叫TCP（Transmission Control Protocol）也叫傳輸控制協議。不覺回憶1983年，親手將NCP協議淘汰，取而代之的是我，成了火遍大江南北的網絡紅人之一。

現如今，我感受到前所未有的恐懼，因為我一生的敵人UDP正在趕超我，甚至將我取而代之。

我的生平

我在1974年被我的父親羅伯特·卡恩和溫特·瑟夫設計出來，和我一同出生的也是如今的網絡紅人IP，我們是一對親密無間的組合——TCP/IP，我在網絡七層模型里的4層——傳輸層，而IP兄弟是負責網絡層。

我的作用就是負責傳輸數據，并代替NCP協議的工作，因為它不能跨系統通訊，怎么說呢，就是如果大家用了Windos操作系統，就沒法和MacOs操作系統進行通訊，這非常不利于互聯網的發展，我很抱歉NCP一時被拋棄，但是我們依然堅信“物競天擇，適者生存”的道理。

起初出生時，我們并沒有大家想象的那么容易。剛出生時的我是非常簡陋的，我的IP兄弟負責每個機器分配一個IP地址標識。IP兄弟像是為我鋪好了康莊大道，而我只需要將數據包運輸到目的地。而我們也比較爭氣，我的父親卡恩和瑟夫為我做了一個實驗，將一個數據包從一端發出，經過10萬千米的旅程后到達服務端。這個傳輸過程，數據包沒有丟失一個字節！

但是，我們的命運和其他伙伴一樣，新技術或新標準起初總是會受到強烈的抵制。特別是標準化組織ISO推出了著名的ISO七層模型，那時我又被強烈的鄙視了一番。

不得不說，父愛是偉大的，他們經過4年時間的不斷對我們改進，為我和IP兄弟完成了基礎框架的搭建。

盡管阻礙重重，我的父親卡恩和瑟夫進行了長期的斗爭。

終于，在1983年被美國國防部高級研究計劃局決定淘汰NCP協議，我和IP兄弟取而代之。

這個過程，整整過去了10年的時間。我和我的親兄弟IP終于站穩了腳跟，分別負責七層模型里的傳輸層，網絡層。

現如今，接觸計算機的朋友們對我一定不陌生。我在網絡中扮演著重要角色，你們發送的信息基本上都是我在負責的，每時每刻都在處理成千上萬用戶的信息，還要安全且無誤的傳輸到指定的地方。

這時候你可能反應過來了，你用手機，電腦等設備對你戀人或者親人說的話，語音，視頻都是我負責幫你們成功抵達，而且是準確無誤，因為至今正常情況下我沒有收到你們錯誤信息的抱怨。

我可以自信地說是印度洋和太平洋之間重要樞紐——馬六甲海峽。

當然我的親兄弟IP也是功不可沒，它為我連通了各個設備搭建好了橋梁，那么我根據IP我就能找到準確的人給他發送。而且還劃分了網段，這樣你在浙江給在北京的愛人發信息，那我一定是往北走，而不是往西，或者往南走。

你可能會好奇，我是怎么做到每時每刻處理成千上萬的信息安全且無誤地傳輸到目的地。這得歸因于我父親對我的設計了，他們致力于讓我成為一個安全且靠譜的“運輸卡車”。

三次握手機制

第一次握手，做了什么？

這第一個安全的設計，就是連接機制，為了確保能夠建立正確的連接，大部分情況下我需要三次連接才能建立安全可靠的傳輸通道。也就是你們常說的“三次握手”連接。

首先客戶端要和服務端建立TCP連接，也就是建立通訊管道。會先發一個SYN報文，這是一個請求同步連接的報文，發送之后此時的客戶端會進入到SYN-SENT狀態。

如果客戶端遲遲收不到服務端的SYN-ACK（同步應答）報文，就會觸發超時重傳機制，重新把剛才的SYN報文重新發送，而且重傳的SYN報文的序列號都是一樣的。

你可能會好奇客戶端沒有收到應答之后，多久才會觸發重傳且需要重傳幾遍才肯罷手。

不同版本的操作系統可能超時時間不同，有的 1 秒的，也有 3 秒的，這個超時時間是寫死在內核里的，如果想要更改則需要重新編譯內核，比較麻煩。

在 Linux 里，客戶端的 SYN 報文最大重傳次數由 tcp_syn_retries?內核參數控制，這個參數是可以自定義的，默認值一般是 5，所以這個可以是由操作系統來設定的。

假如我們設置初始超時重傳1秒，最大重傳次數為5次。那么客戶端第一次超時重傳是在1秒，第二次超時重傳是在2秒，第三次超時重傳是在4秒，第四次超時重傳是在8秒，第五次超時重傳是在16秒。我們可以看到規律，每次超時時間是上一次的2倍。

當到了第五次重傳時，將繼續等待32秒之后服務端還是沒有響應ACK，客戶端將不再發送SYN包，然后斷開TCP連接。

▲圖/?第一次握手超時重傳機制

第二次握手，做了什么？

第二次握手，也就是客戶端發送的SYN報文，如果服務端收到了就會返回一個SYN-ACK報文給客戶端，并且服務端進入SYN_RCVD（同步已接收）狀態。

此時的SYN-ACK報文做了兩件事，一件是對第一次握手時做個回應確認報文已經收到。另一個是服務器既然收到了便會發起建立TCP通信管道的連接的報文，這個地方是一個發送請求時間，如果沒有得到ACK回應則會觸發超時重傳機制。

此時，如果服務端的SYN_ACK報文發送了之后，如果丟失或者某種原因導致客戶端沒有收到，只要客戶端沒有接收到就會觸發超時重傳機制（會有計時器，超過時間沒接收到就重傳），重傳SYN報文。

當然為了確保穩定，不僅客戶端會有重傳機制，服務器也會有超時重傳機制，重發SYN-ACK報文。

在 Linux 下，SYN-ACK 報文的最大重傳次數由 tcp_synack_retries內核參數決定，默認值是 5。

▲圖/?第二次握手超時重傳機制

第三次握手，做了什么？

這個時候，客戶端收到服務端的ACK應答報文并發起了TCP建立連接請求，此時客戶端收到并對TCP建立連接得請求發送一個ACK應答報文，并且客戶端進入ESTABLISH的建立連接狀態。

我們可以看到此時的第三次握手是基于第二次握手服務端發來的SYN的確認報文，如果客戶端沒有收到，那么服務端此時會觸發超時重傳機制，進行重發相同的ACK報文。

▲圖/?第三次握手超時重傳機制

由此，我們也可以總結出結論，ACK應答報文并不會有重傳機制，當ACK丟失了，由對方發來的SYN報文進行重傳。

以上就是我的建立連接機制了。你們可能會看起來比較麻煩，特別是當今世界如果聊天出現了三次握手的情況，你們一定是不耐煩的。然而，我這是犧牲了一定的速度來確保安全以及穩定的作用，我想人們更多情況下都是求安全且穩定的。

四次揮手機制

我雖然在一定程度上具有傳統且保守的態度，但是我一定是力爭求穩，且有始有終，是你們靠譜的伙伴。所以，在傳輸結束時，我也有一套安全穩定的斷聯機制。就是你們俗稱的“四次揮手”。

第一次揮手，做了什么？

第一次揮手，當客戶端所有的消息都發送完之后，會主動調用close函數，然后向服務器發送FIN（完成）報文，試圖和服務器斷開連接，并且狀態進入到FIN_WAIT_1狀態。

客戶端不管何種情況，只要沒有收到ACK報文，就會觸發超時重傳機制，重傳FIN報文，重傳次數也是由操作系統?tcp_orphan_retries 參數設置。

▲圖/?第一次揮手超時重傳機制

超時重傳到達?tcp_orphan_retries?的次數之后，就不再發送FIN報文，則會等待上一段時間的2倍之后還是沒有收到，則直接進入close狀態。

第二次揮手，做了什么？

第二次揮手，服務端收到客戶端的第一次揮手之后會回傳一個ACK確認報文，此時服務端的狀態進入到CLOSE_AWAIT狀態。

由于ACK報文是沒有重傳機制的，所以一旦服務端沒有把ACK回傳給客戶端且接收到，則由客戶端發送方來觸發超時重傳機制。這也是一問一答式的，必須有問有答才算一回合結束。

▲圖/?第二次揮手超時重傳機制

客戶端收到ACK報文，則狀態由FIN_WAIT_1變為FIN_WAIT_2的狀態。這個狀態需要等待服務端發送第三次揮手，也就是服務端的FIN報文。

這里，客戶端收到ACK進入到FIN_WAIT_2狀態之后，調用close關閉函數，之后便無法再發送和接收數據，所以這個FIN_WAIT_2狀態也不會持續很長，而 tcp_fin_timeout 控制了這個狀態下連接的持續時長，默認值是 60 秒。

▲圖/?close函數關閉機制

意味著如果在60秒后還沒有收到FIN報文，客戶端的連接就會直接關閉。

但是如果客戶端（主動方）關閉使用shutdown函數代替close函數關閉連接時，指定了只關閉發送方，而接收方并沒有關閉，那么主動關閉方還是可以接收數據的。

服務端（接收方）還在處于接收狀態就無法發送FIN報文，那么客戶端（主動方）就會一直處于FIN_WAIT_2狀態，你可能會想tcp_fin_timeout這個時間倒計時可以主動關閉狀態。很遺憾，tcp_fin_timeout這個參數只對close函數有用，對shutdown函數無效，并會處于一直等待中，沒有殺死這個線程甚至可能死等中。這是一個不到萬不得已的下策。

▲圖/?shutdown函數關閉機制

第三次揮手，做了什么？

到了這里，進入到第三次揮手。在上一輪服務端進入CLOSE_WAIT狀態后，進程主動調用close函數進入到內核，內核會發送一個FIN報文，同時進入LAST_ACK狀態，等待客戶端返回ACK來確認連接關閉。

▲圖/?第三次揮手超時重傳機制

這里，如果遲遲收不到客戶端返回的ACK報文，則依然會觸發重傳機制，重發次數仍然由tcp_orphan_retries 參數控制。

第四次揮手，做了什么？

服務端發送了FIN報文之后，就進入到第四次揮手了。當客戶端收到服務端的第三次揮手的FIN報文之后，就會回傳一個ACK報文，也就是第四次揮手，并且進入到TIME_WAIT 狀態。

TIME_WAIT狀態根據操作系統的不同，一般Linux系統是持續2MSL（2倍的最大生存時間）進入關閉狀態。

▲圖/?第四次揮手超時重傳機制

服務端若沒有收到客戶端發來的ACK報文，則依然處于LAST_ACK狀態。超時未接收到則客戶端會觸發超時重傳FIN報文，重發次數仍然由前面介紹過的 tcp_orphan_retries 參數控制。

時代的眼淚

你看，這是我有始有終的機制，對于我來說，每一步都不是多余，都是為了雙方能夠建立安全穩定的通道，不會在錯重復雜的通訊管道中將數據錯誤的傳達。

當然，這些是我在連接和斷開方向上的主要特點。我的主要功能不僅這些，?重傳、滑動窗口、流量控制、擁塞控制都是我的一套完整的高可用體系。

在我和應用層HTTP組合已經有四十年左右，在此期間我可以是撐起整個互聯網的元老之一，毫不夸張的自詡為互聯網的血脈。但是也難擋時代帶來的風霜，我有一個死對手UDP，這個將是我永遠過不去的坎，以前我從沒覺得它能夠趕超我甚至替代我，它的好處就是快，靠不靠譜我不說。

但是隨著時代的發展，人們對于速度的要求越來越高，人們不斷地改良網絡模型，我的兄弟也在升級，已經有了IPv6，而與我患難與共的HTTP，則是不斷的從1.0優化到了3.0，這個版本的出現徹底的讓我感到emo，因為http3.0版本已經使用我的死對頭來替換了我，他們將UDP的速度發揮起來，并且對于安全連接和數據校驗相關做了很好的控制。

這也是我為什么要開始emo和吐槽了。

👇?更多有趣內容，請多關注！👇