本書通過先拋出一些開發、運維等技術人員在工作中經常遇見的問題，激發讀者的思考。從這些問題出發，深入地對網絡底層實現原理進行拆解，帶領讀者看清楚問題的核心，理解其背後的技術本質，提高大家的技術功力。例如網絡包是如何被接收和發送的？阻塞到底在內部是如何發生的？epoll的底層工作原理又是啥？TCP連接在底層上是如何支持和實現的？書中對這些內容都有深度的闡述。本書旨在通過帶領讀者修煉底層內功，進而幫助大家深度掌握網絡高性能原理。
張彥飛，2010年碩士畢業於西北大學計算機學院，有十多年的大型互聯網公司項目經驗，目前就職於騰訊。他喜歡對技術進行深度思考，善於挖掘技術點背後的原理。他的技術公眾號“開發內功修煉”一年便收到五萬多讀者的關注。
200幅底層原理全彩插圖，
48個高頻工程實踐問題解決方案，
24條打造高性能應用的硬核建議。
Java、C++、PHP實驗代碼，助你——
清掃性能誤區，探尋底層原理，應對校招、社招、晉升考核，用底層內功對抗中年焦慮。
時髦的東西終究過時，但扎實的內功將會伴隨你一生。只有具備了深厚的內功底蘊，才能在發展的道路上走得更穩、走得更遠。
騰訊技術副總監張勇、小米科技技術總監黃學青等技術專家齊贊。
從大廠的面試說起
互聯網大廠是當今很多開發人員，尤其是應屆畢業生們所向往的公司。但大家應該都聽過關於大廠面試候選人的一句調侃的話，“面試造火箭，工作擰螺絲”。這雖然有一點兒夸張的成分，不過也確實描述得比較形象。在面試中，尤其是頂級互聯網大廠的面試，對技術的考查往往都很深。但是到了工作中，可能確實又需要花不少時間在寫各種各樣的重復 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 內核物件等內核網絡模塊的知識，我也覺得這些很乏味，而是每章先拋出幾個和開發工作相關的實際問題，然後圍繞這幾個問題展開探尋。是的，我用的詞不是“學習”，而是“探尋”。和學習相比，探尋更強調對要解惑的問題的好奇心，更有意思。
雖然本書中會涉及很多的源碼，但這裡先強調一下，這並不是一本源碼解析的書。大家學習的真正目的是理解和解決項目實踐相關的問題，進而提高駕馭手頭工作的能力，而源碼只是我們達成目的的工具和途徑而已。
致謝
本書能夠得以問世，要感謝許多許多人。
首先要感謝的是我的微信公眾號和知乎專欄裡的粉絲們。我提筆寫下第一篇文章的時候，是根本沒敢想能夠成體系出一本書的，是你們的認可和鼓勵支持著我輸出一篇又一篇的硬核技術文。現在回頭一看，竟然攢了好幾十篇。基於這些文章，將來再整理出一本書都是有可能的。而且很多讀者技術也非常優秀，指出了我的文章中不少的瑕疵。飛哥在此對大家表示感謝！
接下來要感謝的是我的愛人，在我寫作的過程中給了我很大的支持和鼓勵，還幫我分擔了很多遛娃、看娃的任務，讓我能專心地投入到寫作中來。寫作要投入的精力是巨大的，如果缺少家人的支持，想完成一本書基本是不可能的。
最後要感謝的是道然科技姚老師以及電子工業出版社的老師們，是你們幫我完成出書過程最後的“臨門一腳”。
第1章 緒論 / 1
1.1 我在工作中的困惑 / 2
1.1.1 過多的TIME_WAIT / 2
1.1.2 長連接開銷 / 2
1.1.3 CPU被消耗光了 / 3
1.1.4 為什麼不同的語言網絡性能差別巨大 / 4
1.1.5 訪問127.0.0.1過網卡嗎 / 4
1.1.6 軟中斷和硬中斷 / 5
1.1.7 零拷貝到底是怎麼回事 / 5
1.1.8 DPDK / 5
1.2 本書內容結構 / 6
1.3 一些約定 / 7
1.4 一些術語 / 8
第2章 內核是如何接收網絡包的 / 9
2.1 相關實際問題 / 10
2.2 數據是如何從網卡到協議棧的 / 11
2.2.1 Linux網絡收包總覽 / 12
2.2.2 Linux啟動 / 13
2.2.3 迎接數據的到來 / 23
2.2.4 收包小結 / 33
2.3 本章總結 / 34
第3章 內核是如何與用戶進程協作的 / 41
3.1 相關實際問題 / 42
3.2 socket的直接創建 / 43
3.3 內核和用戶進程協作之阻塞方式 / 46
3.3.1 等待接收消息 / 47
3.3.2 軟中斷模塊 / 52
3.3.3 同步阻塞總結 / 57
3.4 內核和用戶進程協作之epoll / 59
3.4.1 epoll內核物件的創建 / 60
3.4.2 為epoll添加socket / 62
3.4.3 epoll_wait之等待接收 / 68
3.4.4 數據來了 / 71
3.4.5 小結 / 79
3.5 本章總結 / 80
第4章 內核是如何發送網絡包的 / 84
4.1 相關實際問題 / 85
4.2 網絡包發送過程總覽 / 86
4.3 網卡啟動準備 / 90
4.4 數據從用戶進程到網卡的詳細過程 / 92
4.4.1 send系統調用實現 / 92
4.4.2 傳輸層處理 / 94
4.4.3 網絡層發送處理 / 99
4.4.4 鄰居子系統 / 103
4.4.5 網絡設備子系統 / 105
4.4.6 軟中斷調度 / 109
4.4.7 igb網卡驅動發送 / 111
4.5 RingBuffer內存回收 / 114
4.6 本章總結 / 115
第5章 深度理解本機網絡IO / 119
5.1 相關實際問題 / 120
5.2 跨機網絡通信過程 / 120
5.2.1 跨機數據發送 / 120
5.2.2 跨機數據接收 / 125
5.2.3 跨機網絡通信匯總 / 127
5.3 本機發送過程 / 127
5.3.1 網絡層路由 / 127
5.3.2 本機IP路由 / 130
5.3.3 網絡設備子系統 / 131
5.3.4 “驅動”程序 / 133
5.4 本機接收過程 / 135
5.5 本章總結 / 137
第6章 深度理解TCP連接建立過程 / 139
6.1 相關實際問題 / 140
6.2 深入理解listen / 141
6.2.1 listen系統調用 / 141
6.2.2 協議棧listen / 142
6.2.3 接收隊列定義 / 143
6.2.4 接收隊列申請和初始化 / 145
6.2.5 半連接隊列長度計算 / 146
6.2.6 listen過程小結 / 148
6.3 深入理解connect / 148
6.3.1 connect調用鏈展開 / 149
6.3.2 選擇可用端口 / 151
6.3.3 端口被使用過怎麼辦 / 153
6.3.4 發起syn請求 / 155
6.3.5 connect小結 / 156
6.4 完整TCP連接建立過程 / 157
6.4.1 客戶端connect / 159
6.4.2 服務端響應SYN / 160
6.4.3 客戶端響應SYNACK / 162
6.4.4 服務端響應ACK / 164
6.4.5 服務端accept / 167
6.4.6 連接建立過程總結 / 167
6.5 異常TCP連接建立情況 / 169
6.5.1 connect系統調用耗時失控 / 169
6.5.2 第一次握手丟包 / 171
6.5.3 第三次握手丟包 / 176
6.5.4 握手異常總結 / 178
6.6 如何查看是否有連接隊列溢出發生 / 179
6.6.1 全連接隊列溢出判斷 / 179
6.6.2 半連接隊列溢出判斷 / 181
6.6.3 小結 / 183
6.7 本章總結 / 183
第7章 一條TCP連接消耗多大內存 / 187
7.1 相關實際問題 / 188
7.2 Linux內核如何管理內存 / 188
7.2.1 node劃分 / 189
7.2.2 zone劃分 / 191
7.2.3 基於伙伴系統管理空閑頁面 / 192
7.2.4 slab分配器 / 194
7.2.5 小結 / 197
7.3 TCP連接相關內核物件 / 198
7.3.1 socket函數直接創建 / 198
7.3.2 服務端socket創建 / 206
7.4 實測TCP內核物件開銷 / 207
7.4.1 實驗準備 / 207
7.4.2 實驗開始 / 208
7.4.3 觀察ESTABLISH狀態開銷 / 209
7.4.4 觀察非ESTABLISH狀態開銷 / 211
7.4.5 收發緩存區簡單測試 / 214
7.4.6 實驗結果小結 / 215
7.5 本章總結 / 216
第8章 一臺機器最多能支持多少條TCP連接 / 218
8.1 相關實際問題 / 219
8.2 理解Linux最大文件描述符限制 / 219
8.2.1 找到源碼入口 / 220
8.2.2 尋找進程級限制nofile和fs.nr_open / 221
8.2.3 尋找系統級限制fs.file-max / 223
8.2.4 小結 / 224
8.3 一臺服務端機器最多可以支撐多少條TCP連接 / 225
8.3.1 一次關於服務端並發的聊天 / 225
8.3.2 服務器百萬連接達成記 / 228
8.3.3 小結 / 232
8.4 一臺客戶端機器最多只能發起65 535條連接嗎 / 232
8.4.1 65 535的束縛 / 232
8.4.2 多IP增加連接數 / 234
8.4.3 端口復用增加連接數 / 236
8.4.4 小結 / 243
8.5 單機百萬並發連接的動手實驗 / 243
8.5.1 方案一，多IP客戶端發起百萬連接 / 244
8.5.2 方案二，單IP客戶端機器發起百萬連接 / 248
8.5.3 最後多談一點 / 250
8.6 本章總結 / 251
第9章 網絡性能優化建議 / 253
9.1 網絡請求優化 / 254
9.2 接收過程優化 / 256
9.3 發送過程優化 / 262
9.4 內核與進程協作優化 / 268
9.5 握手揮手過程優化 / 269
第10章 容器網絡虛擬化 / 272
10.1 相關實際問題 / 273
10.2 veth設備對 / 274
10.2.1 veth如何使用 / 274
10.2.2 veth底層創建過程 / 276
10.2.3 veth網絡通信過程 / 278
10.2.4 小結 / 281
10.3 網絡命名空間 / 281
10.3.1 如何使用網絡命名空間 / 282
10.3.2 命名空間相關的定義 / 284
10.3.3 網絡命名空間的創建 / 287
10.3.4 網絡收發如何使用網絡命名空間 / 295
10.3.5 結論 / 296
10.4 虛擬交換機Bridge / 297
10.4.1 如何使用Bridge / 298
10.4.2 Bridge是如何創建出來的 / 301
10.4.3 添加設備 / 303
10.4.4 數據包處理過程 / 305
10.4.5 小結 / 308
10.5 外部網絡通信 / 310
10.5.1 路由和NAT / 311
10.5.2 實現外部網絡通信 / 313
10.5.3 小結 / 318
10.6 本章總結 / 319
大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大，除封面破損、內頁脫落等較嚴重的狀態，其餘商品將正常出貨。
特別提醒：部分書籍附贈之內容(如音頻mp3或影片dvd等)已無實體光碟提供，需以QR CODE 連結至當地網站註冊“並通過驗證程序”，方可下載使用。
無現貨庫存之簡體書，將向海外調貨：
海外有庫存之書籍，等候約45個工作天;
海外無庫存之書籍，平均作業時間約60個工作天，然不保證確定可調到貨，尚請見諒。
為了保護您的權益，「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。
若要辦理退貨，請在商品鑑賞期內寄回，且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。
