如果有人問我推薦技術(shù)類書籍，我個人首選一定是【TCP/IP 詳解】原版。這種大部頭的經(jīng)典之作里所包含的知識，說是浩如煙海也不為過，每次重新翻起總會有一些新的體悟和收益。經(jīng)典的好處在于，它描述的一般是通用的計算機問題，可以幫助讀者形成通用的計算機思維，而不局限于某一領(lǐng)域或某一場景，?？闯Ｐ隆?/p>
當(dāng)然這本書的厚度也到了讓人望而生畏的程度，如果著急短時間內(nèi)啃完，多半會由于無法完成目標的沮喪半途而廢。我在前面的文章中也提到過，獲取知識的時候容易陷入「越看越餓」的焦慮感，這種情形下應(yīng)該放慢節(jié)奏，指定長期的閱讀計劃，放眼于較長時間跨度的收益。書和文章并不是越多越好，看了多少，能消化多少，是個人的事情，沒有比較的意義。知識營養(yǎng)，點滴皆是財富，積跬步而至千里方為正途。
一般來說，看一手技術(shù)書籍比看技術(shù)文章更有意義。但好的技術(shù)文章，如果能做到高屋建瓴，提綱挈領(lǐng)，對于初學(xué)者入門也是具備價值的。直接啃英文原版，沒有交流和正向反饋，最后能否讀完十分考驗讀者的意志力。
我打算寫一個 TCP/IP 的系列文章，目的在于以通俗易懂的語言和比喻，讓讀者能預(yù)先形成一個初步的知識大綱，之后再能有針對性的逐個知識模塊去攻破。即使最后無法通讀【TCP/IP 詳解】全本，也能對網(wǎng)絡(luò)協(xié)議棧形成大致完整的框架理解，以后在項目中遇到問題，至少知道如何下手，從哪個方向去深入突破。感興趣的讀者在閱讀這個系列文章之時，最好能同時翻閱下【TCP/IP 詳解】，療效更佳。
打算寫這個系列的另一個原因，是我在平時閱讀英文書籍的過程中，深感中西方思維方式的差別，會讓一些原本簡單清晰的概念模型變得晦澀費解，一些關(guān)鍵點如果無法攻克，會阻礙進一步學(xué)習(xí)的興趣。另外，我會以 iOS 程序員的視角，盡量結(jié)合一些實際應(yīng)用中的具體場景來講解，不至于太過枯燥，感覺不到學(xué)習(xí)的意義所在。
這個系列會在后續(xù)的時間里，夾雜著其他文章一起寫，可能會耗時較長，又或者會一直寫下去。我現(xiàn)在感覺公眾號越來越像「讀者群」，留下來堅持讀文章的多半和我「品性相投」，不論我寫技術(shù)還是寫心得都會堅持閱讀。于我，寫文章是一件樂事，于讀者，看文章多少有些收獲。一場雙方都覺得愉快的聊天豈不是妙事一件。
接下來進入正題。
TCP/IP 初印象
當(dāng)我們聊 TCP/IP 的時候，一般是在說整個網(wǎng)絡(luò)協(xié)議棧。也就是大家熟知的 OSI 七層模型。我們先拋開七層協(xié)議和三次握手這些生硬的知識點，簡單聊聊網(wǎng)絡(luò)協(xié)議棧到底是做什么的。
網(wǎng)絡(luò)協(xié)議要解決的問題很簡單，打個比方，就是讓身處不同地方的兩個人，能完成聊天通訊。無論我們談及哪一方面的網(wǎng)絡(luò)知識點，最后都不會脫離這個最基本的場景模型。
首先我們需要分清楚流和包的概念，這也是不少初學(xué)者容易混淆的問題。當(dāng)我們以 iPhone 上的 App 客戶端，向我們的 Server 發(fā)數(shù)據(jù)的時候，我們可以用 Charles、MITMProxy 這類工具抓包，但我們同時也知道 TCP 是基于流的協(xié)議，這二者的區(qū)別和聯(lián)系在哪呢？
0 和 1 是計算機世界的基礎(chǔ)粒子，大量的 0 和 1 組合在一起就形成了一個流（Stream），客戶端向服務(wù)器發(fā)送數(shù)據(jù)的時候，說白了就是一堆 0 和 1 的組合。一次完整的 http 會話是建立在一個 TCP 連接之上，這個 TCP 連接的生命周期內(nèi)所有發(fā)送的數(shù)據(jù)最后可以看做是一個流。而在這個流里，我們可以按照某種規(guī)則把它切割成一個個的包（packet）。比如 TCP 三次握手里就包含了 SYN，SYN+ACK，ACK 三個包，而這三個包，不過是整個 TCP Stream 最開始的部分數(shù)據(jù)而已。
所以簡單來說，一個 TCP 連接里，是既有流的概念，又有包的存在，有些問題場景下會談?wù)摿?，另一些則會說起包，端看具體的場景如何。
在開始學(xué)習(xí) TCP/IP 之前，最好能在腦中形成一幅 Gif 動態(tài)圖像，客戶端和服務(wù)器之間有兩根管道，一根上行（從客戶端到服務(wù)器），一根下行（從服務(wù)器到客戶端），管道里流動著無數(shù)的 0 和 1，有時候管道里是滿的，有時候管道里則空空如也，每次發(fā)送數(shù)據(jù)，都會有大量的 0 和 1 從一端涌向另一端。
有了這個基本的抽象理解，就可以進一步填補一些圖像細節(jié)。
比如 0 和 1 是以什么形式流動的呢？這個在不同時代里，所用的物理硬件不同，原理自然也不同，現(xiàn)在大多用的是光纖，光纖里的 0 和 1 流動可以用下圖表示：
物理層離應(yīng)用層較遠，深入學(xué)習(xí)的意義無法立竿見影，遇到實在費解的，可以先跳躍式的閱讀，但有些基礎(chǔ)的細節(jié)還是需要明白的。比如，我們知道光速大致是 300000 km/s ，而光在光纖中的物理傳播速度大概是光速的 ?，這個知識點可以幫助我們大概估算一個 TCP 連接中的 RTT 值。RTT 即 Round Trip Time，表示一個包從發(fā)送方發(fā)出，到收到接收方的反饋，一共耗時多少。RTT 值反應(yīng)的網(wǎng)絡(luò)延時的狀況，在很多場景下分析問題都有意義，比如 TCP 重發(fā)機制中的 RTO 就跟 RTT 有關(guān)，后面的文章我們會細說。一些知識點往往是環(huán)環(huán)相扣的，跳過的內(nèi)容過多，后面學(xué)習(xí)起來會更費解。
延遲
再說下延遲的概念，延遲和帶寬是我們談及網(wǎng)絡(luò)狀況的兩個重要指標。延遲看上去很好理解，延遲對應(yīng)的英文術(shù)語是 Latency，不少人會覺得延遲主要跟通訊雙方的物理距離相關(guān)，距離越遠，自然延遲越高。其實網(wǎng)絡(luò)延遲嚴格來說，是由兩部分組成的，其一是 Transmission Delay，另一個是 Propagation Delay。這里出現(xiàn)了一個新單詞 Delay，Delay 和 Lantency 的含義在中文語境里很難區(qū)分，但在英文語境下，二者的使用卻是有明顯的場景差別的，這也是為什么讀英文原版很重要，可以讓被描述的問題細節(jié)更清晰。
先說 Transmission Delay。計算機世界里的 0 和 1， 最后要能在光纖中傳輸，需要在 Physical Layer 將數(shù)字信號轉(zhuǎn)化為物理信號，這個轉(zhuǎn)化也是存在速度瓶頸的，我們用 Rate (bits/seconds) 來描述這個轉(zhuǎn)化的速度，Rate 表示每一秒鐘里，硬件設(shè)備能將多少 bits 轉(zhuǎn)化為光信號放入光纖中，那么 Transmission Delay 就可以用如下公式表示：
Transmission Delay = M / Rate
M 表示有多少 bits。
Transmission Delay 描述的是硬件轉(zhuǎn)化信號的延遲，這一步里信號還沒有正式進入光纖中傳播，這種延遲和通訊雙方的物理距離是沒有關(guān)系的。
再來是 Propagation Delay。這才是大部分人所理解的傳播延遲，和距離直接相關(guān)。也可以用如下公式表示：
Propagation Delay = L / S
L 表示兩地的物理距離，S 表示光纖中的傳播速度，即為 ? 光速。
最后我們才是所說的網(wǎng)絡(luò)延遲：
Latency = Transmission Delay + Propagation Delay
像這種知識細節(jié)，如果不去看書，是很難形成準確認知的，這種細節(jié)豐滿的認知不是快餐式技術(shù)文章可得，需要靜下心來，花時間慢慢啃，一旦形成之后，就牢固的沉淀在記憶里，這樣才算真正掌握了這方面的知識。
管道容量
再說個有意思的知識點。我們經(jīng)常將網(wǎng)絡(luò)通道比作自來水管道，這種比喻其實很貼切，網(wǎng)絡(luò)管道和自來水管道一樣，也是存在容量限制的。也就是說，光在光纖中傳播的時候，會像自來水一樣，填滿整個光纖，光纖也存在管道容量的限制。有時候，光纖管道會變得很擁擠，一旦擁擠起來，有些包就要排隊等待，延遲就會增加，丟包率也會隨之上升，整個網(wǎng)絡(luò)狀況就會變差，這也是為什么 TCP 要做 Flow Control（流控），F(xiàn)low Control 也是個很經(jīng)典且有趣的問題，后面會專門寫文章介紹。
網(wǎng)絡(luò)管道的容量也是可以通過上面提到的元素，用公式計算的：
BD = Rate * Propagation Delay
大家可以思考下這個公式為什么會是這樣。
好啦，序篇就到這，后面的文章里，我會逐個講解一些關(guān)鍵且重要的知識點。一同進步吧！
