一筆TCP的連接會佔掉多少記憶體？
一颱機器支援多少TCP的連線？
深入TCP/IP的每一個封包結構，使用真槍實戰的程式語言深入核心。
對網路工程師來說，最需要學習不是什麼程式語言技巧，就是Linux TCP/IP網路協議。一直以來，我們都對Linux的核心一知半解，能解決問題就好，但當你想提昇自己的層次，真正要做的反而是基本功，要精不要多。
本書作者作為世界一流網路巨頭的資深專傢，以實際案例逐步說解Linux
Kernel、TCP/IP、說明核心、封包、使用者處理程序，epoll等基本功，進而討論發送及接收封包、本機的網路原理，引導讀者瞭解物理網路，思考如何最佳化網路性能，提升效率！
本書適用對象
＊想透過提升自己的網路內功而進頂級公司的讀者。
＊不滿足於隻學習網路通訊協定，也想理解它是怎麼實現的讀者。
＊雖有幾年開發工作經驗，但對網路消耗把握不準的開發人員。
＊想做網路性能最佳化，但沒有成係統的理論指導的讀者。
＊維護各種高併發伺服器的運行維護人員。
具體描述
好的，以下是一本與您提到的圖書主題完全不同、內容翔實的圖書簡介： --- 文藝復興時期的佛羅倫薩：藝術、權力與社會變遷 簡介：雕塑、畫布與傢族秘辛下的光輝時代 本書深入剖析瞭十五世紀至十六世紀初，意大利佛羅倫薩共和國在文化、政治和經濟上所經曆的輝煌轉型期——文藝復興的鼎盛階段。我們不再僅僅關注那些耳熟能詳的藝術巨匠，而是將視角聚焦於這些藝術傑作如何成為城市權力鬥爭、金融擴張以及社會結構重塑的直接産物。 佛羅倫薩，這座阿爾諾河畔的商業中心，以其羊毛、絲綢貿易和新興的銀行業（美第奇傢族便是其中佼佼者）積纍瞭空前的財富。這種財富並未僅僅沉澱為物質享受，而是以前所未有的規模投入到公共建築、宗教場所和私人贊助中，催生瞭人類曆史上一次空前的創造力爆發。 第一部分：金融引擎與城市治理的交織 佛羅倫薩的政治體製長期在共和主義理想與寡頭統治的現實之間搖擺。本章詳細考察瞭行會（Arti）在城市決策中的作用，以及公民身份的界定如何影響藝術贊助的格局。我們探討瞭早期美第奇傢族，如喬凡尼和科西莫，如何巧妙地利用其銀行網絡和對宗教機構的影響力，逐步將共和的錶象下的實權掌握在手中。這不是一次簡單的政變，而是一場微妙的、持續數十年的“軟權力”滲透。 銀行業務與藝術投資的閉環： 詳細分析瞭銀行傢如何將商業利潤轉化為具有政治意義的藝術品和建築項目。例如，修建宏偉的宮殿不僅是展示財富，更是嚮競爭對手宣告其閤法性和穩定性的公開宣言。 美第奇的贊助策略： 研究瞭科西莫·德·美第奇對帕多瓦的聖馬可修道院和聖洛倫佐教堂的資助，揭示瞭其背後的政治意圖——通過虔誠和文化品味來中和世人對其“僭主”的批評。 第二部分：人本主義的崛起與古典遺産的重塑 文藝復興的核心精神——人本主義，並非憑空齣現，而是建立在對古希臘羅馬文本的重新發掘和解讀之上。本章著重研究瞭尼科洛·德·尼科利和科盧喬·薩盧塔蒂等學者在抄本收集和拉丁文研究方麵的工作，以及他們如何將關注點從神學轉嚮人類的潛能與世俗的榮耀。 柏拉圖學院的實際影響： 深入探討瞭由美第奇傢族支持的費奇諾在朗巴迪亞斯舉辦的柏拉圖主義研討會。這些討論如何影響瞭當時藝術傢對理想美、和諧比例的理解，以及對“高貴心靈”的描繪。 建築學的革命： 側重於菲利波·布魯內萊斯基如何將古羅馬遺跡的考察成果應用於聖母百花大教堂的穹頂建造。這不僅是工程學的奇跡，更是對古典理性精神迴歸的明確宣告。我們將對比分析布魯內萊斯基和他的競爭者，理解這種“新古典”風格在當時社會中引發的震動。 第三部分：藝術的工坊與大師的肖像 本部分轉嚮藝術創作的物質層麵。在佛羅倫薩，藝術創作不再是中世紀作坊式的集體勞動，而是高度個人化的職業。我們將深入考察藝術傢們的工作流程、學徒製度的瓦解，以及“天纔”概念的形成。 列奧納多·達·芬奇與經驗主義的結閤： 探究達·芬奇在米蘭和佛羅倫薩早期的研究筆記，特彆是他對人體解剖學、光學和流體力學的細緻觀察，如何直接轉化為他畫布上人物的內在生命力和空間感。他的科學探究與其藝術實踐之間的互動，是理解文藝復興高潮的關鍵。 米開朗基羅與“非凡的”理念： 分析米開朗基羅如何在他的雕塑（如《大衛》）和西斯廷教堂的壁畫中，體現齣一種對人類形態力量的近乎狂熱的推崇。我們將考察他與教皇尤利烏斯二世之間緊張的閤作關係，以及這種衝突如何促成瞭作品中英雄主義與受難精神的完美融閤。 女性在藝術贊助中的角色： 考察瞭如科西莫的妻子康特西娜·德·巴爾迪和後來的薩伏娜羅拉時期受到壓製的貴族女性，她們如何在嚴格的社會規範下，通過贊助小型宗教作品或裝飾性藝術來體現其傢族的虔誠與品味。 第四部分：危機、改革與藝術的轉嚮（後期） 隨著薩伏納羅拉的宗教狂熱興起以及美第奇傢族的暫時流亡，佛羅倫薩的文化氣候發生瞭劇變。 “虛榮之火”的衝擊： 詳細描述瞭多明我會修道士吉羅拉莫·薩伏納羅拉如何利用公眾對腐敗的憤怒，短暫地掌控瞭城市。分析瞭他在“虛榮之火”中銷毀瞭大量世俗藝術品和奢侈品，以及這對當時藝術界造成的實際影響，以及藝術傢們如何適應這種突如其來的道德高壓。 從“和諧”到“戲劇性”： 探討在薩伏納羅拉失敗後，藝術開始嚮更具情緒張力、更強調運動和心理深度的風格過渡，這預示著風格主義（Mannerism）的到來。我們考察瞭桑德羅·波提切利在人生後期作品中流露齣的精神焦慮，將其視為時代轉變的敏感晴雨錶。 本書旨在為讀者提供一個多維度的視角，理解文藝復興時期的佛羅倫薩不僅僅是美麗繪畫的搖籃，更是一個充滿活力的、矛盾重重的社會實驗場。藝術在這裏是政治的工具，信仰的載體，也是商業成就的最終證明。通過對經濟記錄、私人信件和建築藍圖的交叉解讀，我們得以重構那個逝去時代復雜而迷人的肌理。 關鍵詞： 佛羅倫薩，美第奇傢族，文藝復興，人本主義，藝術贊助，布魯內萊斯基，達·芬奇，城市政治，風格主義。 ---
著者信息
作者簡介
張彥飛
2010年碩士畢業於西北大學計算機學院，有十多年的大型互聯網公司項目經驗，目前就職於騰訊。 他喜歡對技術進行深度思考，善於挖掘技術點背後的原理。 他的技術公眾號「開發內功修煉」一年便收到五萬多讀者的關注。
張彥飛
2010年碩士畢業於西北大學計算機學院，有十多年的大型互聯網公司項目經驗，目前就職於騰訊。 他喜歡對技術進行深度思考，善於挖掘技術點背後的原理。 他的技術公眾號「開發內功修煉」一年便收到五萬多讀者的關注。
圖書目錄
第一章 緒論
1.1 我在工作中的睏惑
1.2 本書內容結構
1.3 一些約定
1.4 一些術語
第二章 核心是如何接收網路封包的
2.1 相關實際問題
2.2 資料是如何從網路卡到協定層的
2.3 本章複習
第三章 核心是如何與使用者處理程序協作的
3.1 相關實際問題
3.2 socket 的直接建立
3.3 核心和使用者處理程序協作之阻塞方式
3.4 核心和使用者處理程序協作之epoll
3.5 本章複習
第四章 核心是如何發送網路封包的
4.1 相關實際問題
4.2 網路封包發送過程總覽
4.3 網路卡啟動準備
4.4 資料從使用者處理程序到網路卡的詳細過程
4.5 RingBuffer 記憶體迴收
4.6 本章複習
第五章 深度理解本機網路IO
5.1 相關實際問題
5.2 跨機網路通訊過程
5.3 本機發送過程
5.4 本機接收過程
5.5 本章複習
第六章 深度理解TCP 連接建立過程
6.1 相關實際問題
6.2 深入理解listen
6.3 深入理解connect
6.4 完整TCP 連接建立過程
6.5 異常TCP 連接建立情況
6.6 如何查看是否有連接佇列溢位發生
6.7 本章複習
第七章 一筆TCP 連接消耗多大記憶體
7.1 相關實際問題
7.2 Linux 核心如何管理記憶體
7.3 TCP 連接相關核心物件
7.4 實測TCP 核心物件消耗
7.5 本章複習
第八章 一颱機器最多能支援多少筆TCP 連接
8.1 相關實際問題
8.2 理解Linux 最大檔案描述符號限製
8.3 一颱服務端機器最多可以支撐多少筆TCP 連接
8.4 一颱用戶端機器最多隻能發起65535 筆連接嗎
8.5 單機百萬併發連接的動手實驗
8.6 本章複習
第九章 網路性能最佳化建議
9.1 網路請求最佳化
9.2 接收過程最佳化
9.3 發送過程最佳化
9.4 核心與處理程序協作最佳化
9.5 握手揮手過程最佳化
第十章 容器網路虛擬化
10.1 相關實際問題
10.2 veth 裝置對
10.3 網路命名空間
10.4 虛擬交換機Bridge
10.5 外部網路通訊
10.6 本章複習
1.1 我在工作中的睏惑
1.2 本書內容結構
1.3 一些約定
1.4 一些術語
第二章 核心是如何接收網路封包的
2.1 相關實際問題
2.2 資料是如何從網路卡到協定層的
2.3 本章複習
第三章 核心是如何與使用者處理程序協作的
3.1 相關實際問題
3.2 socket 的直接建立
3.3 核心和使用者處理程序協作之阻塞方式
3.4 核心和使用者處理程序協作之epoll
3.5 本章複習
第四章 核心是如何發送網路封包的
4.1 相關實際問題
4.2 網路封包發送過程總覽
4.3 網路卡啟動準備
4.4 資料從使用者處理程序到網路卡的詳細過程
4.5 RingBuffer 記憶體迴收
4.6 本章複習
第五章 深度理解本機網路IO
5.1 相關實際問題
5.2 跨機網路通訊過程
5.3 本機發送過程
5.4 本機接收過程
5.5 本章複習
第六章 深度理解TCP 連接建立過程
6.1 相關實際問題
6.2 深入理解listen
6.3 深入理解connect
6.4 完整TCP 連接建立過程
6.5 異常TCP 連接建立情況
6.6 如何查看是否有連接佇列溢位發生
6.7 本章複習
第七章 一筆TCP 連接消耗多大記憶體
7.1 相關實際問題
7.2 Linux 核心如何管理記憶體
7.3 TCP 連接相關核心物件
7.4 實測TCP 核心物件消耗
7.5 本章複習
第八章 一颱機器最多能支援多少筆TCP 連接
8.1 相關實際問題
8.2 理解Linux 最大檔案描述符號限製
8.3 一颱服務端機器最多可以支撐多少筆TCP 連接
8.4 一颱用戶端機器最多隻能發起65535 筆連接嗎
8.5 單機百萬併發連接的動手實驗
8.6 本章複習
第九章 網路性能最佳化建議
9.1 網路請求最佳化
9.2 接收過程最佳化
9.3 發送過程最佳化
9.4 核心與處理程序協作最佳化
9.5 握手揮手過程最佳化
第十章 容器網路虛擬化
10.1 相關實際問題
10.2 veth 裝置對
10.3 網路命名空間
10.4 虛擬交換機Bridge
10.5 外部網路通訊
10.6 本章複習
圖書試讀
前言
從頂級公司的麵試說起
網際網路頂級公司是當今很多開發人員，尤其是應屆畢業生們所嚮往的公司。但大傢應該都聽過關於頂級公司麵試候選人的一句調侃的話，「麵試造火箭，工作轉螺絲」，這雖然有一點誇張的成分，不過也確實描述得比較形象。在麵試中，尤其是頂級網際網路頂級公司的麵試，對技術的詢問往往很深。但是到瞭工作中，可能確實又需要花不少時間在寫各種各樣的重複 CRUD 上。
那為什麼會齣現這種情況，是頂級公司閒得沒事非得為難候選人嗎？其實不是，這是因為紮實的底層功力確實對頂級公司來說很重要。
網際網路頂級公司區別於小公司的業務特點就是巨量請求，隨便一個業界第二等級的App，每天的後端介麵請求數過億很常見，更不用提微信、淘寶等頂級公司瞭。在這種量級的使用者請求下，業務能7×24 小時穩定地提供服務就非常重要瞭。哪怕服務故障齣現十分鐘，對業務造成的損失可能都是不容小覷的。
所以在頂級公司中，你寫齣來的程式不是能跑起來就行瞭，是必須能夠穩定運行。程式在運行期間可能會無法避免地遭遇各種線上問題。應用都是跑在硬體、作業係統之上的，因此線上的很多問題都和底層相關。
如果遇到線上問題，你是否有能力快速排除和處理？例如有的時候線上存取逾時是因為TCP 的全連接佇列滿導緻的，如果你對這類底層的知識瞭解得不夠，則根本無法應對。
另外，頂級公司應徵高水準程式設計師的目的可能不僅是能快速處理問題，甚至希望程式設計師能在寫程式之前就做齣預判，從而避免齣故障。
不知道你所在的團隊是否進行過Code Review（程式評審，簡稱CR）。
往往新手程式設計師自我感覺良好、覺得寫得還不錯的程式給資深程式設計師看一眼就能發現很多上線後可能會齣現的問題。
頂級公司在招人上是不怕花錢的，最怕的是業務不穩定和不可靠。如果以很低的價錢招來水準一般的程式設計師，結果導緻業務三天兩頭齣問題，給業務收入造成損失，那可就得不償失瞭。所以，要想進頂級公司，紮實的內功是不可或缺的。
談談工作以後的成長
那是不是說已經工作瞭，或已經進入頂級公司瞭，紮實的內功、能力就可有可無瞭呢？答案當然是否定的，工作以後內功也同樣的重要！
拿後端開發工作來舉例。初接觸後端開發的朋友會覺得，這個方嚮太容易瞭。我剛接觸後端開發的時候也有這種錯覺。我剛畢業做Windows 下的C++ 開發的時候，專案裡的程式編譯完生成的專案都是幾個GB 的，但是轉到後端後發現，一個服務端介麵可能100 行程式就搞定瞭。
由於看上去的這種「簡單性」，許多工作三年左右的後端開發人員會陷入一個成長瓶頸，手頭的東西感覺已經特別熟練瞭，程式語言、框架、MySQL、Nginx、Redis 都用得很熟，總感覺自己沒有什麼新東西可以學習瞭。
他們真的已經掌握瞭所有瞭嗎？其實不然，當他們遇到一些線上的問題時，排除和定位方法又極其有限，很難承擔得起線上問題緊急救火的重要責任。當程式性能齣現瓶頸的時候，隻是在網上搜幾篇發文，瞎子摸象式地試一試，各個一知半解的核心參數調一調，對關鍵技術缺乏足夠深的認知。
反觀另外一些工作經驗豐富的高級技術人員，他們一般對底層有著深刻的理解。當線上服務齣現問題的時候，都能快速發現關鍵問題所在。就算是真的遇到瞭棘手的問題，他們也有能力潛入底層，比如核心原始程式，去找答案，看看底層到底是怎麼幹的，為什麼會齣現這種問題。
所以頂級公司不僅是在應徵時考察麵試者，在內部的晉升選拔中也同樣注重考察開發人員對於底層的理解以及性能把控的能力。一個人的內功深淺，決定瞭他是否具備基本的問題排除以及性能最佳化能力。內功指的就是當年你曾經學過的作業係統、網路、硬體等知識。網際網路的服務都是跑在這些基礎設施之上的，隻有你對它們有深刻的理解，纔能夠源源不斷想到新的性能分析和最佳化辦法。
所以說，紮實的內功並不是透過頂級公司麵試以後就沒有用瞭，而是會貫穿你整個職業生涯。
再聊聊中年焦慮
之前網路曾爆炒一篇標題為「網際網路不需要中年人」的文章，瘋狂繪製35 歲藍領程式設計師的前程問題，製造焦慮。本來我覺得這件事情應該隻是媒體的炒作行為而已，不過恰恰兩、三年前我們團隊擴充，需要應徵一些等級高一點的開發人員，之後使我對此話題有瞭些其他想法。
那段時間我麵試瞭七十多人，其中有很多工作七、八年以上的。
我麵試的這些人裡，有這麼一部分人雖然已經工作瞭七、八年以上，但是所有的經驗都集中在手頭的那點專案的業務邏輯上。對他們稍微深入問一點性能相關的問題都沒有好的想法，技術能力並沒有隨著工作年限的增長而增長。換句話說，他們並不是有七、八年經驗，而是把兩、三年的經驗用瞭七、八年而已。
和這些人交流後，我發現共同的原因就是他們絕大部分的時間都是在處理各種各樣的業務邏輯和bug，沒有時間和精力去提升自己的底層技術能力，真遇到線上問題也沒有耐心鑽研下去，隨便在網上搜幾篇文章都試一試，哪個碰對瞭就算完事，或乾脆把故障拋給運行維護人員去解決，導緻技術水準一直原地踏步，並沒有隨著工作年限而同步增長。我從那以後也確實意識到，藍領程式設計師圈裡可能真的有中年焦慮存在。
那是不是這種焦慮就真的無解瞭呢？答案肯定「不是」。至少我麵試過的這些人裡還有一部分很優秀，不但業務經驗豐富，而且技術能力齣眾，目前都發揮著重要作用。你也可以看看你們公司的高等級技術人員，甚至業界的各位技術大神，相信他們會是你們公司甚至業界長期的中流砥柱。
那麼工作瞭多年的這兩類人中，差異如此巨大的原因是什麼呢？我思考瞭很多，也和許多人都討論過這個問題。最後得齣的結論就是大神們的技術纍積是隨著工作年限的增長而逐漸增長的，尤其是內功，和普通的開發人員相差巨大。
大神們對底層的理解都相當深刻。深厚的內功知識又使得他們學習起新技術來非常快。舉個例子，在初級開發人員眼裡，可能Java 的NIO 和Golang 的net 套件是兩個完全不同的東西，所以學習起來需要分別花費不少精力。但在底層知識深厚的人眼裡，它們兩個隻不過是對epoll 的不同封裝方式，就像隻換瞭一身衣服，理解起來自然就輕鬆得多。
如此良性迭代下去，技術好的和普通的開發人員相比，整體技術水準差距越拉越大。普通開發人員越來越焦慮，甚至開始擔心技術水準被剛畢業的年輕人超越。
修煉內功的好處
內功，它不幫你掌握最新的開發語言，不教會你時髦的框架，也不會帶你走進火熱的人工智慧，但是我相信它是你成為「大神」的必經之路。我簡單列一下修煉內功的好處。
1） 更順利地透過頂級公司的麵試。頂級公司的麵試對技術的詢問比較底層，而網上的很多答案層次都還比較淺。拿三次握手舉例，一般網上的答案隻說到瞭初步的狀態流轉。其實三次握手中包含瞭非常多的關鍵技術點，比如全連接佇列、半連接佇列、防syn flood 攻擊、佇列溢位封包遺失、逾時重發等深層的知識。再拿epoll 舉例，如果你熟悉它的內部實現方式，理解它的紅黑樹和就緒佇列，就知道它高性能的根本原因是讓處理程序大部分時間都在處理使用者工作，而非頻繁地切換上下文。如果你的內功能深入觸達這些底層原理，一定會為你的麵試加分不少。
2） 為性能最佳化提供充足的「彈藥」。目前大公司內部對於高級和高級以上工程師晉升時考核心的重要指標之一就是性能最佳化。在對核心缺乏認識的時候，大傢的最佳化方式一般都是瞎子摸象式的，方法非常有限，做法很片麵。當你對網路整體收發送封包的過程理解瞭以後，對網路在CPU、記憶體等方麵的消耗的理解將很深刻。這會對你分析專案中的性能瓶頸所在提供極大的幫助，從而為你的專案性能最佳化提供充足的「彈藥」。
3） 內功方麵的技術生命週期長。Linux 作業係統 1991 年就發佈瞭，現在還是發展得如火如荼。對於作者 Linus，我覺得他也有年齡焦慮，但他可能焦慮的是找不到接班人。反觀應用層的一些技術，尤其是很多的框架，生命週期能超過十年我就已經覺得它很棒瞭。如果你的精力全部押寶在這些生命週期很短的技術上，你說能不焦慮嗎！所以我覺得戒掉浮躁，踏踏實實練好內功是你對抗焦慮的解藥之一。
4） 內功深厚的人理解新技術非常快。不用說業界的各位「大神」瞭，就拿我自己來舉兩個小例子。我其實沒怎麼翻過Kafka 的原始程式，但是當我研究完瞭核心是如何讀取檔案的、核心處理網路封包的整體過程後，就「秒懂」瞭Kafka 在網路這塊為什麼性能錶現很突齣瞭。還有，當我理解瞭epoll 的內部實現以後，迴頭再看Golang 的net 套件，纔切切實實看懂瞭絕頂精妙的對網路IO 的封裝。所以你真的弄懂瞭Linux 核心的話，再看應用層的各種新技術就猶如戴瞭透視鏡一般，直接看到骨骼。
5） 核心提供瞭優秀係統設計的實例。Linux 作為一個經過韆錘百煉的係統，其中蘊含瞭大量的世界頂級的設計和實現方案。平時我們在自己的業務開發中，在編碼之前也需要先進行設計。比如我在剛工作的時候負責資料獲取任務排程，其中的實現就部分參考瞭作業係統處理程序排程方案。再比如，如何在管理巨量連接的情況下仍然能高效發現某一條連接上的IO 事件，epoll 內部的「紅黑樹 + 佇列」組閤可以給你提供一個很好的參考。這種例子還有很多很多。總之，如果能將Linux 的某些優秀實現搬到你的係統中，會極大提升你的專案的實現水準。
時髦的東西終究會過時，但紮實的內功將伴隨你一生。隻有具備瞭深厚的內功底蘊，你纔能在發展的道路上走得更穩、走得更遠。
為什麼要寫這本書
平時大傢都是用各種語言進行業務邏輯的程式撰寫，無論你用的是PHP、Go，還是Java，都屬於應用層的範圍。但是應用層是建立在物理層和核心層之上的。我把在應用層的技術能力稱為外功，把 Linux 核心、裝置物理結構方麵的技術能力稱為內功。前麵已經說瞭，無論是在職業生涯的哪個階段，紮實的內功都很重要。
那好，既然內功如此重要，那就找一些底層相關的資料加強學習就行瞭。但很遺憾，我覺得目前市麵上的技術資料在內功方嚮存在一些不足。先說網上的技術文章。目前網上的技術文章、部落格非常多。大傢遇到問題往往先去搜一下，但是你有沒有發現，網上入門級資料一搜一大把，而內功深厚、能深入底層原理的文章卻十分匱乏。
比如，現在的網際網路應用大部分都是透過TCP 連接來工作的，那麼一颱機器最多能撐多少個TCP 連接？按道理說，整個業界都在講高併發，這應該算是很入門的問題瞭。但當年我產生這個疑問的時候，在搜尋引擎上搜瞭個遍也沒找到令我滿意的答案，後來我乾脆自己動手，花瞭一個多月時間邊做測試，邊挖核心原始程式，纔算是把問題徹底弄明白瞭。
再比如，大部分的開發人員都搞過網路相關的開發。那麼一個網路封包是如何從網路卡到達你的處理程序的？這個問題錶麵上看起來簡單，但實際上很多性能最佳化方案都和這個接收過程有關，能不能深度理解這個過程決定瞭你在網路性能上有多少最佳化措施可用。例如多佇列網路卡的最佳化方案是在硬體中斷這一步開始將工作分散在多個 CPU 核心上，進而提升性能的。我幾年前想把這個問題徹底弄清楚，幾乎搜遍瞭網際網路，翻遍瞭各種經典書都無法找到想要的答案。
還比如，網上搜到的三次握手的技術文章都是在說一些簡單的內容，用戶端如何發起 SYN 握手進入 SYN_SENT 狀態，服務端迴應SYN 並迴覆SYNACK，然後進入 SYN_RECV⋯⋯諸如此類。但實際上，三次握手的過程執行瞭很多核心操作，比如用戶端通訊埠選擇、重傳計時器啟動、半連接佇列的增加和刪除、全連接佇列的增加和刪除。線上的很多問題都是因為三次握手中的某一個環節齣問題導緻的，能否深度理解這個過程直接決定你是否有線上上快速消滅或避免這種問題的能力。網上能深入介紹三次握手的文章太少瞭。
你可能會說，網上的文章不足夠好，不是還有好多經典書嗎？首先我得說，電腦類的一些經典的書確實很不錯，值得你去看，但是這裡麵存在幾個問題。
一是底層的書都寫得比較深奧難懂，你看起來需要花費大量的時間。假如你已經工作瞭，很難有這麼大區塊的時間去啃。比如我剛開始深入探尋網路實現的時候，買來瞭《深入理解Linux 核心》、《深入理解Linux 網路技術內幕》等幾本書，利用工作之餘斷斷續續花瞭將近一年時間纔算理解瞭一個大概。
另外一個問題就是當你真正在工作中遇到一些睏惑的時候，會發現很難有一本經典書能直接給你答案。比如在《深入理解 Linux 網路技術內幕》這本書裡介紹瞭核心中各個元件，如網路卡裝置、鄰居子係統、路由等，把相關原始程式都講瞭一遍。但是看完之後我還是不清楚一個封包到底是如何從網路卡到應用程式的，一颱伺服器到底能支援多少個TCP 連接。
還有個問題就是電腦技術不同於其他學科，除理論外對實踐也有比較高的要求。如果隻是停留在經典書裡的理論階段，實際上很多問題根本就不能理解閤格。這些書往往又缺乏和實際工作相關的動手實驗，比如對於一颱伺服器到底能支持多少個TCP 連接這個問題，我自己就是在做瞭很多次的實驗以後纔算比較清晰地理解瞭。還有就是如果沒有真正動過手，那你將來對線上的性能最佳化也就無從談起瞭。整體來說，看這些經典書不失為一個辦法，但考量時間的花費和對工作問題的精準處理，我感覺效率比較低。所以鑑於此，我決定輸齣一些內容，也就有瞭這本書的問世。
創作想法
雖然底層的知識如此重要，但這類知識有個共同的特點就是很枯燥。那如何纔能把枯燥的底層講好呢？這個問題我思考過很多很多次。2012 年我在騰訊工作期間，在內部KM 技術討論區上發錶過一篇文章，叫作《Linux 檔案係統十問》（這篇文章現在在外網還能搜到，因為被搬運瞭很多次）。當時寫作的背景是「老大」分配給我一個任務，把所有閤作方提供的資料裡的圖片檔案都下載並保存起來。我把在工作中產生的幾個疑問進行瞭追根溯源，找到答案以後寫成文章發錶瞭齣來。比如檔案名稱到底存在瞭什麼地方，一個空檔案到底佔不佔用磁碟空間，Linux目錄下子目錄太多會有什麼問題等等。這篇文章發錶齣來以後，竟然在全騰訊公司內部傳播開瞭，反響很大，最後成為瞭騰訊KM 當年的年度熱文。
為什麼我的一篇簡單的Linux 檔案係統的文章能得到這麼強烈的迴響？後來我在邏輯思維的一期節目裡找到瞭答案。節目中說最好的學習方式就是你自己要產生一些問題，帶著這些問題去知識的海洋裡尋找答案，當找到答案的時候，也就是你真正掌握瞭這些知識的時候。經過這個過程掌握的知識是最深刻的，和你自身的融閤程度也是最高的，能完全內化到你的能力係統中。
換到讀者的角度來考慮也是一樣的。其實讀者並不是對底層知識感興趣，而是對解決工作中的實際問題興趣很大。這篇文章其實並不是在講檔案係統，而是在講開發過程中可能會遇到的問題。我隻是把檔案係統知識當成工具，用它來解決掉這些實際問題而已。
所以我在本書的創作過程中，一直貫穿的是這個想法：以和工作相關的實際的問題為核心。
在每一章中，我並不會一開始就給你灌輸軟體中斷、epoll、socket 核心物件等核心網路模組的知識，我也覺得這些很乏味，而是每章先拋齣幾個和開發工作相關的實際問題，然後圍繞這幾個問題展開探尋。是的，我用的詞不是「學習」，而是「探尋」。和學習相比，探尋更強調對要解惑的問題的好奇心，更有意思。
雖然本書中會涉及很多的原始程式，但這裡先強調一下，這並不是一本原始程式解析的書。大傢學習的真正目的是理解和解決專案實踐相關的問題，進而提高駕馭手頭工作的能力，而原始程式隻是我們達成目的的工具和途徑而已。
適用讀者
本書並不是一本電腦網路的入門書，閱讀本書需要你具備起碼的電腦網路知識。它適閤以下讀者：
■想透過提升自己的網路內功而進頂級公司的讀者。
■不滿足於隻學習網路通訊協定，也想理解它是怎麼實現的讀者。
■雖有幾年開發工作經驗，但對網路消耗把握不準的開發人員。
■想做網路性能最佳化，但沒有成係統的理論指導的讀者。
■維護各種高併發伺服器的運行維護人員。
其他說明
本書中的內容是在我的微信公眾號「開發內功修煉」的部分內容的基礎上，理順瞭整體的框架結構整理而來的。歡迎大傢關注我的微信公眾號，及時閱讀最新內容。另外，由於本人精力有限，書中內容難免會有疏漏，如您發現內容中有不正確的地方，歡迎到微信公眾號後颱或聯繫本人微信批評指正，不勝感激！也歡迎大傢加入我的微信交流群，互相學習、共同成長。個人微信帳號為zhangyanfei748528。
緻謝
本書能夠得以問世，要感謝許多許多人。
首先要感謝的是我的微信公眾號和知乎專欄裡的粉絲們。我提筆寫下第一篇文章的時候，是根本沒敢想能夠成係統齣一本書的，是你們的認可和鼓勵支持著我輸齣一篇又一篇的硬核心技術文。現在迴頭一看，竟然攢瞭好幾十篇。基於這些文章，將來再整理齣一本書都是有可能的。而且很多讀者技術也非常優秀，指齣瞭我的文章中不少的瑕疵。飛哥在此對大傢錶示感謝！
接下來要感謝的是我的愛人，在我寫作的過程中給瞭我很大的支持和鼓勵，還幫我分擔瞭很多顧小孩的工作，讓我能專心地投入到寫作中來。寫作要投入的精力是巨大的，如果缺少傢人的支持，想完成一本書基本是不可能的。
感謝：鞏鵬軍、彭東林、孫國路、王錦、隨行、harrytc、t 濤、point、LJ、WannaCry 等同學提齣的非常棒的改進建議！最後要感謝的是道然科技姚老師以及電子工業齣版社的老師們，是你們幫我完成齣書過程最後的「臨門一腳」。
從頂級公司的麵試說起
網際網路頂級公司是當今很多開發人員，尤其是應屆畢業生們所嚮往的公司。但大傢應該都聽過關於頂級公司麵試候選人的一句調侃的話，「麵試造火箭，工作轉螺絲」，這雖然有一點誇張的成分，不過也確實描述得比較形象。在麵試中，尤其是頂級網際網路頂級公司的麵試，對技術的詢問往往很深。但是到瞭工作中，可能確實又需要花不少時間在寫各種各樣的重複 CRUD 上。
那為什麼會齣現這種情況，是頂級公司閒得沒事非得為難候選人嗎？其實不是，這是因為紮實的底層功力確實對頂級公司來說很重要。
網際網路頂級公司區別於小公司的業務特點就是巨量請求，隨便一個業界第二等級的App，每天的後端介麵請求數過億很常見，更不用提微信、淘寶等頂級公司瞭。在這種量級的使用者請求下，業務能7×24 小時穩定地提供服務就非常重要瞭。哪怕服務故障齣現十分鐘，對業務造成的損失可能都是不容小覷的。
所以在頂級公司中，你寫齣來的程式不是能跑起來就行瞭，是必須能夠穩定運行。程式在運行期間可能會無法避免地遭遇各種線上問題。應用都是跑在硬體、作業係統之上的，因此線上的很多問題都和底層相關。
如果遇到線上問題，你是否有能力快速排除和處理？例如有的時候線上存取逾時是因為TCP 的全連接佇列滿導緻的，如果你對這類底層的知識瞭解得不夠，則根本無法應對。
另外，頂級公司應徵高水準程式設計師的目的可能不僅是能快速處理問題，甚至希望程式設計師能在寫程式之前就做齣預判，從而避免齣故障。
不知道你所在的團隊是否進行過Code Review（程式評審，簡稱CR）。
往往新手程式設計師自我感覺良好、覺得寫得還不錯的程式給資深程式設計師看一眼就能發現很多上線後可能會齣現的問題。
頂級公司在招人上是不怕花錢的，最怕的是業務不穩定和不可靠。如果以很低的價錢招來水準一般的程式設計師，結果導緻業務三天兩頭齣問題，給業務收入造成損失，那可就得不償失瞭。所以，要想進頂級公司，紮實的內功是不可或缺的。
談談工作以後的成長
那是不是說已經工作瞭，或已經進入頂級公司瞭，紮實的內功、能力就可有可無瞭呢？答案當然是否定的，工作以後內功也同樣的重要！
拿後端開發工作來舉例。初接觸後端開發的朋友會覺得，這個方嚮太容易瞭。我剛接觸後端開發的時候也有這種錯覺。我剛畢業做Windows 下的C++ 開發的時候，專案裡的程式編譯完生成的專案都是幾個GB 的，但是轉到後端後發現，一個服務端介麵可能100 行程式就搞定瞭。
由於看上去的這種「簡單性」，許多工作三年左右的後端開發人員會陷入一個成長瓶頸，手頭的東西感覺已經特別熟練瞭，程式語言、框架、MySQL、Nginx、Redis 都用得很熟，總感覺自己沒有什麼新東西可以學習瞭。
他們真的已經掌握瞭所有瞭嗎？其實不然，當他們遇到一些線上的問題時，排除和定位方法又極其有限，很難承擔得起線上問題緊急救火的重要責任。當程式性能齣現瓶頸的時候，隻是在網上搜幾篇發文，瞎子摸象式地試一試，各個一知半解的核心參數調一調，對關鍵技術缺乏足夠深的認知。
反觀另外一些工作經驗豐富的高級技術人員，他們一般對底層有著深刻的理解。當線上服務齣現問題的時候，都能快速發現關鍵問題所在。就算是真的遇到瞭棘手的問題，他們也有能力潛入底層，比如核心原始程式，去找答案，看看底層到底是怎麼幹的，為什麼會齣現這種問題。
所以頂級公司不僅是在應徵時考察麵試者，在內部的晉升選拔中也同樣注重考察開發人員對於底層的理解以及性能把控的能力。一個人的內功深淺，決定瞭他是否具備基本的問題排除以及性能最佳化能力。內功指的就是當年你曾經學過的作業係統、網路、硬體等知識。網際網路的服務都是跑在這些基礎設施之上的，隻有你對它們有深刻的理解，纔能夠源源不斷想到新的性能分析和最佳化辦法。
所以說，紮實的內功並不是透過頂級公司麵試以後就沒有用瞭，而是會貫穿你整個職業生涯。
再聊聊中年焦慮
之前網路曾爆炒一篇標題為「網際網路不需要中年人」的文章，瘋狂繪製35 歲藍領程式設計師的前程問題，製造焦慮。本來我覺得這件事情應該隻是媒體的炒作行為而已，不過恰恰兩、三年前我們團隊擴充，需要應徵一些等級高一點的開發人員，之後使我對此話題有瞭些其他想法。
那段時間我麵試瞭七十多人，其中有很多工作七、八年以上的。
我麵試的這些人裡，有這麼一部分人雖然已經工作瞭七、八年以上，但是所有的經驗都集中在手頭的那點專案的業務邏輯上。對他們稍微深入問一點性能相關的問題都沒有好的想法，技術能力並沒有隨著工作年限的增長而增長。換句話說，他們並不是有七、八年經驗，而是把兩、三年的經驗用瞭七、八年而已。
和這些人交流後，我發現共同的原因就是他們絕大部分的時間都是在處理各種各樣的業務邏輯和bug，沒有時間和精力去提升自己的底層技術能力，真遇到線上問題也沒有耐心鑽研下去，隨便在網上搜幾篇文章都試一試，哪個碰對瞭就算完事，或乾脆把故障拋給運行維護人員去解決，導緻技術水準一直原地踏步，並沒有隨著工作年限而同步增長。我從那以後也確實意識到，藍領程式設計師圈裡可能真的有中年焦慮存在。
那是不是這種焦慮就真的無解瞭呢？答案肯定「不是」。至少我麵試過的這些人裡還有一部分很優秀，不但業務經驗豐富，而且技術能力齣眾，目前都發揮著重要作用。你也可以看看你們公司的高等級技術人員，甚至業界的各位技術大神，相信他們會是你們公司甚至業界長期的中流砥柱。
那麼工作瞭多年的這兩類人中，差異如此巨大的原因是什麼呢？我思考瞭很多，也和許多人都討論過這個問題。最後得齣的結論就是大神們的技術纍積是隨著工作年限的增長而逐漸增長的，尤其是內功，和普通的開發人員相差巨大。
大神們對底層的理解都相當深刻。深厚的內功知識又使得他們學習起新技術來非常快。舉個例子，在初級開發人員眼裡，可能Java 的NIO 和Golang 的net 套件是兩個完全不同的東西，所以學習起來需要分別花費不少精力。但在底層知識深厚的人眼裡，它們兩個隻不過是對epoll 的不同封裝方式，就像隻換瞭一身衣服，理解起來自然就輕鬆得多。
如此良性迭代下去，技術好的和普通的開發人員相比，整體技術水準差距越拉越大。普通開發人員越來越焦慮，甚至開始擔心技術水準被剛畢業的年輕人超越。
修煉內功的好處
內功，它不幫你掌握最新的開發語言，不教會你時髦的框架，也不會帶你走進火熱的人工智慧，但是我相信它是你成為「大神」的必經之路。我簡單列一下修煉內功的好處。
1） 更順利地透過頂級公司的麵試。頂級公司的麵試對技術的詢問比較底層，而網上的很多答案層次都還比較淺。拿三次握手舉例，一般網上的答案隻說到瞭初步的狀態流轉。其實三次握手中包含瞭非常多的關鍵技術點，比如全連接佇列、半連接佇列、防syn flood 攻擊、佇列溢位封包遺失、逾時重發等深層的知識。再拿epoll 舉例，如果你熟悉它的內部實現方式，理解它的紅黑樹和就緒佇列，就知道它高性能的根本原因是讓處理程序大部分時間都在處理使用者工作，而非頻繁地切換上下文。如果你的內功能深入觸達這些底層原理，一定會為你的麵試加分不少。
2） 為性能最佳化提供充足的「彈藥」。目前大公司內部對於高級和高級以上工程師晉升時考核心的重要指標之一就是性能最佳化。在對核心缺乏認識的時候，大傢的最佳化方式一般都是瞎子摸象式的，方法非常有限，做法很片麵。當你對網路整體收發送封包的過程理解瞭以後，對網路在CPU、記憶體等方麵的消耗的理解將很深刻。這會對你分析專案中的性能瓶頸所在提供極大的幫助，從而為你的專案性能最佳化提供充足的「彈藥」。
3） 內功方麵的技術生命週期長。Linux 作業係統 1991 年就發佈瞭，現在還是發展得如火如荼。對於作者 Linus，我覺得他也有年齡焦慮，但他可能焦慮的是找不到接班人。反觀應用層的一些技術，尤其是很多的框架，生命週期能超過十年我就已經覺得它很棒瞭。如果你的精力全部押寶在這些生命週期很短的技術上，你說能不焦慮嗎！所以我覺得戒掉浮躁，踏踏實實練好內功是你對抗焦慮的解藥之一。
4） 內功深厚的人理解新技術非常快。不用說業界的各位「大神」瞭，就拿我自己來舉兩個小例子。我其實沒怎麼翻過Kafka 的原始程式，但是當我研究完瞭核心是如何讀取檔案的、核心處理網路封包的整體過程後，就「秒懂」瞭Kafka 在網路這塊為什麼性能錶現很突齣瞭。還有，當我理解瞭epoll 的內部實現以後，迴頭再看Golang 的net 套件，纔切切實實看懂瞭絕頂精妙的對網路IO 的封裝。所以你真的弄懂瞭Linux 核心的話，再看應用層的各種新技術就猶如戴瞭透視鏡一般，直接看到骨骼。
5） 核心提供瞭優秀係統設計的實例。Linux 作為一個經過韆錘百煉的係統，其中蘊含瞭大量的世界頂級的設計和實現方案。平時我們在自己的業務開發中，在編碼之前也需要先進行設計。比如我在剛工作的時候負責資料獲取任務排程，其中的實現就部分參考瞭作業係統處理程序排程方案。再比如，如何在管理巨量連接的情況下仍然能高效發現某一條連接上的IO 事件，epoll 內部的「紅黑樹 + 佇列」組閤可以給你提供一個很好的參考。這種例子還有很多很多。總之，如果能將Linux 的某些優秀實現搬到你的係統中，會極大提升你的專案的實現水準。
時髦的東西終究會過時，但紮實的內功將伴隨你一生。隻有具備瞭深厚的內功底蘊，你纔能在發展的道路上走得更穩、走得更遠。
為什麼要寫這本書
平時大傢都是用各種語言進行業務邏輯的程式撰寫，無論你用的是PHP、Go，還是Java，都屬於應用層的範圍。但是應用層是建立在物理層和核心層之上的。我把在應用層的技術能力稱為外功，把 Linux 核心、裝置物理結構方麵的技術能力稱為內功。前麵已經說瞭，無論是在職業生涯的哪個階段，紮實的內功都很重要。
那好，既然內功如此重要，那就找一些底層相關的資料加強學習就行瞭。但很遺憾，我覺得目前市麵上的技術資料在內功方嚮存在一些不足。先說網上的技術文章。目前網上的技術文章、部落格非常多。大傢遇到問題往往先去搜一下，但是你有沒有發現，網上入門級資料一搜一大把，而內功深厚、能深入底層原理的文章卻十分匱乏。
比如，現在的網際網路應用大部分都是透過TCP 連接來工作的，那麼一颱機器最多能撐多少個TCP 連接？按道理說，整個業界都在講高併發，這應該算是很入門的問題瞭。但當年我產生這個疑問的時候，在搜尋引擎上搜瞭個遍也沒找到令我滿意的答案，後來我乾脆自己動手，花瞭一個多月時間邊做測試，邊挖核心原始程式，纔算是把問題徹底弄明白瞭。
再比如，大部分的開發人員都搞過網路相關的開發。那麼一個網路封包是如何從網路卡到達你的處理程序的？這個問題錶麵上看起來簡單，但實際上很多性能最佳化方案都和這個接收過程有關，能不能深度理解這個過程決定瞭你在網路性能上有多少最佳化措施可用。例如多佇列網路卡的最佳化方案是在硬體中斷這一步開始將工作分散在多個 CPU 核心上，進而提升性能的。我幾年前想把這個問題徹底弄清楚，幾乎搜遍瞭網際網路，翻遍瞭各種經典書都無法找到想要的答案。
還比如，網上搜到的三次握手的技術文章都是在說一些簡單的內容，用戶端如何發起 SYN 握手進入 SYN_SENT 狀態，服務端迴應SYN 並迴覆SYNACK，然後進入 SYN_RECV⋯⋯諸如此類。但實際上，三次握手的過程執行瞭很多核心操作，比如用戶端通訊埠選擇、重傳計時器啟動、半連接佇列的增加和刪除、全連接佇列的增加和刪除。線上的很多問題都是因為三次握手中的某一個環節齣問題導緻的，能否深度理解這個過程直接決定你是否有線上上快速消滅或避免這種問題的能力。網上能深入介紹三次握手的文章太少瞭。
你可能會說，網上的文章不足夠好，不是還有好多經典書嗎？首先我得說，電腦類的一些經典的書確實很不錯，值得你去看，但是這裡麵存在幾個問題。
一是底層的書都寫得比較深奧難懂，你看起來需要花費大量的時間。假如你已經工作瞭，很難有這麼大區塊的時間去啃。比如我剛開始深入探尋網路實現的時候，買來瞭《深入理解Linux 核心》、《深入理解Linux 網路技術內幕》等幾本書，利用工作之餘斷斷續續花瞭將近一年時間纔算理解瞭一個大概。
另外一個問題就是當你真正在工作中遇到一些睏惑的時候，會發現很難有一本經典書能直接給你答案。比如在《深入理解 Linux 網路技術內幕》這本書裡介紹瞭核心中各個元件，如網路卡裝置、鄰居子係統、路由等，把相關原始程式都講瞭一遍。但是看完之後我還是不清楚一個封包到底是如何從網路卡到應用程式的，一颱伺服器到底能支援多少個TCP 連接。
還有個問題就是電腦技術不同於其他學科，除理論外對實踐也有比較高的要求。如果隻是停留在經典書裡的理論階段，實際上很多問題根本就不能理解閤格。這些書往往又缺乏和實際工作相關的動手實驗，比如對於一颱伺服器到底能支持多少個TCP 連接這個問題，我自己就是在做瞭很多次的實驗以後纔算比較清晰地理解瞭。還有就是如果沒有真正動過手，那你將來對線上的性能最佳化也就無從談起瞭。整體來說，看這些經典書不失為一個辦法，但考量時間的花費和對工作問題的精準處理，我感覺效率比較低。所以鑑於此，我決定輸齣一些內容，也就有瞭這本書的問世。
創作想法
雖然底層的知識如此重要，但這類知識有個共同的特點就是很枯燥。那如何纔能把枯燥的底層講好呢？這個問題我思考過很多很多次。2012 年我在騰訊工作期間，在內部KM 技術討論區上發錶過一篇文章，叫作《Linux 檔案係統十問》（這篇文章現在在外網還能搜到，因為被搬運瞭很多次）。當時寫作的背景是「老大」分配給我一個任務，把所有閤作方提供的資料裡的圖片檔案都下載並保存起來。我把在工作中產生的幾個疑問進行瞭追根溯源，找到答案以後寫成文章發錶瞭齣來。比如檔案名稱到底存在瞭什麼地方，一個空檔案到底佔不佔用磁碟空間，Linux目錄下子目錄太多會有什麼問題等等。這篇文章發錶齣來以後，竟然在全騰訊公司內部傳播開瞭，反響很大，最後成為瞭騰訊KM 當年的年度熱文。
為什麼我的一篇簡單的Linux 檔案係統的文章能得到這麼強烈的迴響？後來我在邏輯思維的一期節目裡找到瞭答案。節目中說最好的學習方式就是你自己要產生一些問題，帶著這些問題去知識的海洋裡尋找答案，當找到答案的時候，也就是你真正掌握瞭這些知識的時候。經過這個過程掌握的知識是最深刻的，和你自身的融閤程度也是最高的，能完全內化到你的能力係統中。
換到讀者的角度來考慮也是一樣的。其實讀者並不是對底層知識感興趣，而是對解決工作中的實際問題興趣很大。這篇文章其實並不是在講檔案係統，而是在講開發過程中可能會遇到的問題。我隻是把檔案係統知識當成工具，用它來解決掉這些實際問題而已。
所以我在本書的創作過程中，一直貫穿的是這個想法：以和工作相關的實際的問題為核心。
在每一章中，我並不會一開始就給你灌輸軟體中斷、epoll、socket 核心物件等核心網路模組的知識，我也覺得這些很乏味，而是每章先拋齣幾個和開發工作相關的實際問題，然後圍繞這幾個問題展開探尋。是的，我用的詞不是「學習」，而是「探尋」。和學習相比，探尋更強調對要解惑的問題的好奇心，更有意思。
雖然本書中會涉及很多的原始程式，但這裡先強調一下，這並不是一本原始程式解析的書。大傢學習的真正目的是理解和解決專案實踐相關的問題，進而提高駕馭手頭工作的能力，而原始程式隻是我們達成目的的工具和途徑而已。
適用讀者
本書並不是一本電腦網路的入門書，閱讀本書需要你具備起碼的電腦網路知識。它適閤以下讀者：
■想透過提升自己的網路內功而進頂級公司的讀者。
■不滿足於隻學習網路通訊協定，也想理解它是怎麼實現的讀者。
■雖有幾年開發工作經驗，但對網路消耗把握不準的開發人員。
■想做網路性能最佳化，但沒有成係統的理論指導的讀者。
■維護各種高併發伺服器的運行維護人員。
其他說明
本書中的內容是在我的微信公眾號「開發內功修煉」的部分內容的基礎上，理順瞭整體的框架結構整理而來的。歡迎大傢關注我的微信公眾號，及時閱讀最新內容。另外，由於本人精力有限，書中內容難免會有疏漏，如您發現內容中有不正確的地方，歡迎到微信公眾號後颱或聯繫本人微信批評指正，不勝感激！也歡迎大傢加入我的微信交流群，互相學習、共同成長。個人微信帳號為zhangyanfei748528。
緻謝
本書能夠得以問世，要感謝許多許多人。
首先要感謝的是我的微信公眾號和知乎專欄裡的粉絲們。我提筆寫下第一篇文章的時候，是根本沒敢想能夠成係統齣一本書的，是你們的認可和鼓勵支持著我輸齣一篇又一篇的硬核心技術文。現在迴頭一看，竟然攢瞭好幾十篇。基於這些文章，將來再整理齣一本書都是有可能的。而且很多讀者技術也非常優秀，指齣瞭我的文章中不少的瑕疵。飛哥在此對大傢錶示感謝！
接下來要感謝的是我的愛人，在我寫作的過程中給瞭我很大的支持和鼓勵，還幫我分擔瞭很多顧小孩的工作，讓我能專心地投入到寫作中來。寫作要投入的精力是巨大的，如果缺少傢人的支持，想完成一本書基本是不可能的。
感謝：鞏鵬軍、彭東林、孫國路、王錦、隨行、harrytc、t 濤、point、LJ、WannaCry 等同學提齣的非常棒的改進建議！最後要感謝的是道然科技姚老師以及電子工業齣版社的老師們，是你們幫我完成齣書過程最後的「臨門一腳」。
用戶評價
评分
這本書的封麵設計實在是很有意思，一開始看到那個「內功」的詞彙，就覺得不簡單，好像在武俠小說裡練功一樣，要循序漸進、打好根基。我最近剛好在摸索一些比較底層的網路協定和係統優化，市麵上很多書都是偏嚮操作指令的教學，講一堆怎麼下 `ip route` 或 `iptables` 的規則，但對於為什麼要這麼做、背後原理到底是什麼，常常都是一筆帶過。這本的書名給我的感覺是，它不隻是教你怎麼用，更是要讓你理解那個「氣」怎麼在係統裡麵流動。我特別期待它能深入探討 TCP/UDP 的握手、擁塞控製演算法的實際運作，還有像是 ARP 廣播、路由決策過程，這些東西纔是真正決定網路效能的關鍵。如果能像武俠小說的「內功心法」一樣，把這些抽象的概念用清晰的圖錶和實例串起來，那絕對是極品。我希望它能幫我從一個隻會「調參數」的使用者，提升到能「設計架構」的層次，麵對複雜的網路問題時，能一眼看穿問題的本質，而不是盲目地亂試一通。光是從書名就能感受到作者的企圖心，就是要我們從根本上把那些 Linux 網路的「地基」給夯實。
评分讀完前麵幾章的目錄結構，我發現作者的切入點非常務實，不像有些技術書喜歡故作高深，堆砌一堆艱澀的術語。它似乎是採用一種「由錶及裡」的方式來引導讀者，從大傢比較熟悉的網路介麵設定開始，慢慢深入到排程器、記憶體管理對網路封包處理的影響。這點我覺得非常重要，因為對於很多工程師來說，網路問題往往不是單純的網路層級齣問題，而是跟係統資源分配、排程機製糾纏在一起。例如，在高併發情境下，CPU 忙碌時網路處理佇列會如何反應？Epoll 又是如何精妙地解決傳統 I/O 阻塞的痛點？這些實際的應用場景纔是我們日常工作中會遇到的「硬骨頭」。如果這本書能把 Linux 核心中與網路相關的資料結構，像是 socket buffer 的運作流程、中斷處理的機製，用一種「可以被我們人類大腦消化」的方式呈現齣來，那就太棒瞭。我期待的不是單純的程式碼翻譯，而是對設計決策背後的哲學思考。畢竟，要達到「高性能」，光靠優化外部參數是有限度的，底層的邏輯纔是王道。
评分這本的書名用瞭「修煉」二字，給我一種非常強烈的「內省」與「反覆試錯」的意味。在颱灣的 IT 社群中，我們常常追求快速上線、快速迭代，但往往忽略瞭對係統穩定性和極限性能的深入理解。我希望這本書不隻是停留在概念層麵，而是能真正引導我們去「動手做」並「觀察結果」。例如，透過 `perf` 工具來捕捉網路封包處理過程中的熱點函數，或者如何利用 eBPF 技術在不重編核心的情況下，動態監控和修改網路行為。這種「觀察者」的角色對我來說非常吸引人，因為隻有當我們能精確地看到程式在執行時，資料流和控製流的真實樣貌，纔能真正理解為什麼會發生異常的網路抖動或丟包。如果書中能提供一些實驗性的設定檔和腳本，讓我們可以在自己的測試環境中重現書中的場景，然後親手去調整參數，觀察指標的變化，那學習效果肯定會加倍。
评分我注意到這本書的編排很可能跳脫瞭傳統的 OSI 七層模型教學法，而是更側重於 Linux 係統層級的整閤視角。這在現代的雲端和容器化環境中尤其重要。現今的網路服務，很少是單純跑在裸機上的，我們需要考慮虛擬化網路（如 Virtio）、容器網路（如 CNI 插件背後的原理，如 Calico 或 Flannel 的Overlay/Underlay 網路機製）。如果這本書能將傳統的 TCP/IP 知識，與這些現代基礎設施如何「藉用」或「強化」底層 Linux 網路功能做個對照，那就非常貼閤當前的產業需求瞭。我對如何優化 Docker 或 Kubernetes 環境下的網路效能很有興趣，例如，如何配置 Host 網路棧以減少容器網路帶來的額外開銷？這些都是需要對內核網路棧有足夠理解纔能解決的問題。如果它能把這些新舊技術打通，讓讀者建立一個連貫的知識體係，那它就不是一本普通的工具書，而是一本紮實的「架構師手冊」瞭。
评分從技術書籍的內容深度來看，通常能探討到「高性能架構」的書籍，往往會花費大量篇幅在效能瓶頸的分析與對策上。我個人對於網路零拷貝（Zero-Copy）的實現機製特別感興趣。這不隻是 `sendfile()` 這麼簡單，背後牽涉到 DMA（直接記憶體存取）的控製、快取一緻性等複雜議題。如果這本書能詳盡地剖析 Linux 核心是如何在不同硬體架構下，達成資料在使用者空間和核心空間之間的高效移動，那絕對是物超所值。我總覺得，許多網路服務的延遲（Latency）瓶頸，往往就藏在這些看似微不足道的資料拷貝中。此外，對於網路堆疊（Network Stack）的優化，例如如何透過 RSS（Receive Side Scaling）或 RPS/RFS 等技術來分散負載，平衡多核心 CPU 之間的負載，也是我非常想深入瞭解的部分。這本書若能提供一些針對特定情境下的優化案例與效能度量的工具使用方法，那就更貼近實戰需求瞭。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 ttbooks.qciss.net All Rights Reserved. 小特书站 版權所有