dns 找到了地址，spf 確定了路徑，如何運輸數(shù)據(jù)呢？今天講 tcp。

計算機網(wǎng)絡(luò)領(lǐng)域的特定技術(shù)是最后當你干這個事時才要用的，我對孩子們這樣說，實際上你可以隨便看一個快遞單子來理解端到端傳輸協(xié)議。

源地址，目標地址一定要有，一個地址可能有不同住戶，也就是 port 指示的，一系列相關(guān)聯(lián)包裹的順序編號也是必須，總共多少件，這是第幾件等等，此外，一個包裹能不能被拆分運輸，也要被標識，三噸大米可以拆分運輸，而三噸大象就不行，能收多少，這個也要告知對方。哪些是 tcp，哪些是 ip，我是不區(qū)分的，因為本來它們就沒有區(qū)分。

和快遞包裹類似，tcp 不管具體運輸路徑，所以它是端到端的。

和快遞包裹不同的是，tcp 指示一個雙向的交互運輸，如何在 “運輸單” 上緊湊地控制這個雙向運輸過程是 tcp 協(xié)議的設(shè)計目標之一，序號 和 接收能力 標識本端信息，而 “ack” 則捎帶對方的需求，但如果沒有本端報文需要遞送，ack 也能單獨發(fā)送，這些信息在雙向交互初始化時通過四次握手協(xié)商清楚，由于 ack 可稍帶，四次握手合并為三次。

雙向交互協(xié)議最自然的方式是 “單字節(jié)停等”，若果然如此，tcp 就是個再簡單不過的協(xié)議，但為了效率，單字節(jié)停等擴展為單報文停等，報文子節(jié)流可拆分，最終是窗口停等，窗口內(nèi)報文可丟可亂序，一次發(fā)送一窗數(shù)據(jù)就不得不有效處理丟包亂序問題。優(yōu)化總是引入復雜。

如何檢測丟包，一開始只有超時，后來有了更 trick 的方式，即快速重傳。對于孩子而言，解釋為什么三次重復 ack 標識丟包很輕松，他們可以自然理解為什么是三次，如果要解釋，就是事不過三。沒必要進一步引申 reordering，因為這不是重點。

tcp 影響了所有傳輸協(xié)議。

如果一開始的 tcp 不是現(xiàn)在這個 tcp，現(xiàn)在的互聯(lián)網(wǎng)就會是另一番景象。

從 tcp 滑動窗口停等 中可以看到一些歷史，另一些歷史可以從編碼和交互的視角來理解。

1970 年代典型的文件傳輸和遠程登錄(包括文件傳輸?shù)?ftp 以及 email 交互命令)兩類應(yīng)用確實影響了 tcp 必須是流式停等協(xié)議。

首先，文件傳輸?shù)膶Χ诵枰_拷貝，其次，遠程登錄實際上是自己跟自己交互，這就很有趣，傳輸?shù)膶Χ瞬皇侨?#xff0c;無法腦補糾錯，而交互的本端卻是自己。自己與自己交互不存在腦補的空間，比如輸入一個 “s”，顯然希望馬上回顯一個 “s”，“anderson” 是我自己輸入的，回顯 “andersoX” 時我會懷疑自己輸入錯了，而不是字母傳丟了。

假想另一種平行歷史，如果 1970 年代的核心應(yīng)用是用一個傳輸協(xié)議向遠端放電影，流式停等就再無必要，nack 可能會被用來提示關(guān)鍵數(shù)據(jù)丟失，也會有一個偶爾的指令反饋，但大部分時間，receiver 可能根本不會有任何反饋。擁塞控制大概會傾向于 receiver 的主動行為。

接下來可以想象，不會有如今樣式的慢啟動，也不會有內(nèi)置的 reno aimd 策略，因為稀疏的反饋不足以驅(qū)動這些機制運行。如果 ack 不是 tcp 的必須字段，有關(guān)擁塞控制的所有機制都將改變，并且也不會出現(xiàn) ack 過多導致的資源搶占問題，特別是在 wifi 環(huán)境下。

說說 aimd，這實際上是一個并不需要干預(yù)的自然過程，也印證了主動干預(yù)的合理性。

大片牧場承載著小規(guī)模羊群，但羊群規(guī)模會逐漸變大，當羊群規(guī)模略微超過牧場承載能力，羊群就會出現(xiàn)內(nèi)卷性競爭，比如降低代謝率，接下來就會出現(xiàn)大規(guī)模爭奪資源的纏斗，二者相斗必有一傷，在統(tǒng)計學意義上，羊群規(guī)模會快速減半，這就是 aimd。同理，當城市人口緩慢增加到人與人之間距離小于臨界值，傳染病就會肆虐從而快速減少人口，所以城市化進程達到一定程度必須停止。在理論上，統(tǒng)計復用資源不可能實現(xiàn) 100% 的利用率，這是需要用直感而不是數(shù)學講明白的。

但不管怎樣，tcp 依然重要。

浙江溫州皮鞋濕，下雨進水不會胖。