萬字長文爆肝 DNS 協議！

試想一個問題，我們人類可以有多少種識別自己的方式？可以通過身份證來識別，可以通過社保卡號來識別，也可以通過駕駛證來識別，盡管我們有多種識別方式，但在特定的環境下，某種識別方法可能比另一種方法更為適合，因特網上的主機和人類一樣，可以使用多種識別方式進行標識，互聯網上主機的一種標識方法是使用它的 主機名(hostname) ，如 www.facebook.com、 www.google.com 等，但是這是我們人類的記憶方式，路由器不會這么理解，路由器喜歡定長的、有層次結構的 IP地址，

如果你還不理解 IP 的話，可以翻閱一下我的這篇文章計算機網路層

IP 地址現在簡單表述一下，就是一個由 4 位元組組成，并有著嚴格的層次結構，例如 121.7.106.83 這樣一個 IP 地址，其中的每個位元組都可以用 . 進行分割，表示了 0 - 255 的十進制數字，

然而，路由器喜歡的是 IP 地址進行決議，我們人類卻便于記憶的是網址，那么路由器如何把 IP 地址決議為我們熟悉的網址地址呢？這時候就需要 DNS 出現了，

DNS 的全稱是 Domain Name System,DNS ，它是一個由分層的 DNS 服務器（DNS server）實作的分布式資料庫；它還是一個使得主機能夠查詢分布式資料庫的應用層協議，DNS 服務器通常是運行 BIND(Berkeley Internet Name Domain) 軟體的 UNIX 機器，DNS 協議運行在 UDP 之上，使用 53 埠，

DNS 基本概述

與 HTTP、FTP 和 SMTP 一樣，DNS 協議也是應用層的協議，DNS 使用客戶-服務器模式運行在通信的端系統之間，在通信的端系統之間通過下面的端到端運輸協議來傳送 DNS 報文，但是 DNS 不是一個直接和用戶打交道的應用，DNS 是為因特網上的用戶應用程式以及其他軟體提供一種核心功能，

DNS 通常不是一門獨立的協議，它通常為其他應用層協議所使用，這些協議包括 HTTP、SMTP 和 FTP，將用戶提供的主機名決議為 IP 地址，

下面根據一個示例來描述一下這個 DNS 決議程序，這個和你輸入網址后，瀏覽器做了什么操作有異曲同工之處

你在瀏覽器鍵入 www.someschool.edu/index.html 時會發生什么現象？為了使用戶主機能夠將一個 HTTP 請求報文發送到 Web 服務器 www.someschool.edu ，會經歷如下操作

• 同一臺用戶主機上運行著 DNS 應用的客戶端
• 瀏覽器從上述 URL 中抽取出主機名 www.someschool.edu ，并將這臺主機名傳給 DNS 應用的客戶端
• DNS 客戶向 DNS 服務器發送一個包含主機名的請求，
• DNS 客戶最侄訓收到一份回答報文，其中包含該目標主機的 IP 地址
• 一旦瀏覽器收到目標主機的 IP 地址后，它就能夠向位于該 IP 地址 80 埠的 HTTP 服務器行程發起一個 TCP 連接，

除了提供 IP 地址到主機名的轉換，DNS 還提供了下面幾種重要的服務

• 主機別名(host aliasing)，有著復雜的主機名的主機能夠擁有一個或多個其他別名，比如說一臺名為 relay1.west-coast.enterprise.com 的主機，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種情況下，relay1.west-coast.enterprise.com 也稱為 規范主機名，而主機別名要比規范主機名更加容易記憶，應用程式可以呼叫 DNS 來獲得主機別名對應的規范主機名以及主機的 IP地址，
• 郵件服務器別名(mail server aliasing)，同樣的，電子郵件的應用程式也可以呼叫 DNS 對提供的主機名進行決議，
• 負載分配(load distribution)，DNS 也用于冗余的服務器之間進行負載分配，繁忙的站點例如 cnn.com 被冗余分布在多臺服務器上，每臺服務器運行在不同的端系統之間，每個都有著不同的 IP 地址，由于這些冗余的 Web 服務器，一個 IP 地址集合因此與同一個規范主機名聯系，DNS 資料庫中存盤著這些 IP 地址的集合，由于客戶端每次都會發起 HTTP 請求，所以 DNS 就會在所有這些冗余的 Web 服務器之間回圈分配了負載，

DNS 作業概述

假設運行在用戶主機上的某些應用程式（如 Web 瀏覽器或郵件閱讀器） 需要將主機名轉換為 IP 地址，這些應用程式將呼叫 DNS 的客戶端，并指明需要被轉換的主機名，用戶主機上的 DNS 收到后，會使用 UDP 通過 53 埠向網路上發送一個 DNS 查詢報文，經過一段時間后，用戶主機上的 DNS 會收到一個主機名對應的 DNS 回答報文，因此，從用戶主機的角度來看，DNS 就像是一個黑盒子，其內部的操作你無法看到，但是實際上，實作 DNS 這個服務的黑盒子非常復雜，它由分布于全球的大量 DNS 服務器以及定義了 DNS 服務器與查詢主機通信方式的應用層協議組成，

DNS 最早的設計是只有一臺 DNS 服務器，這臺服務器會包含所有的 DNS 映射，這是一種集中式的設計，這種設計并不適用于當今的互聯網，因為互聯網有著數量巨大并且持續增長的主機，這種集中式的設計會存在以下幾個問題

• 單點故障(a single point of failure)，如果 DNS 服務器崩潰，那么整個網路隨之癱瘓，
• 通信容量(traaffic volume)，單個 DNS 服務器不得不處理所有的 DNS 查詢，這種查詢級別可能是上百萬上千萬級
• 遠距離集中式資料庫(distant centralized database)，單個 DNS 服務器不可能 鄰近 所有的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會經過低速和擁堵的鏈路，造成嚴重的時延，
• 維護(maintenance)，維護成本巨大，而且還需要頻繁更新，

所以 DNS 不可能集中式設計，它完全沒有可擴展能力，因此采用分布式設計，所以這種設計的特點如下

分布式、層次資料庫

首先分布式設計首先解決的問題就是 DNS 服務器的擴展性問題，因此 DNS 使用了大量的 DNS 服務器，它們的組織模式一般是層次方式，并且分布在全世界范圍內，沒有一臺 DNS 服務器能夠擁有因特網上所有主機的映射，相反，這些映射分布在所有的 DNS 服務器上，

大致來說有三種 DNS 服務器：根 DNS 服務器、 頂級域(Top-Level Domain, TLD) DNS 服務器 和 權威 DNS 服務器 ，這些服務器的層次模型如下圖所示

假設現在一個 DNS 客戶端想要知道 www.amazon.com 的 IP 地址，那么上面的域名服務器是如何決議的呢？首先，客戶端會先根服務器之一進行關聯，它將回傳頂級域名 com 的 TLD 服務器的 IP 地址，該客戶則與這些 TLD 服務器之一聯系，它將為 amazon.com 回傳權威服務器的 IP 地址，最后，該客戶與 amazom.com 權威服務器之一聯系，它為 www.amazom.com 回傳其 IP 地址，

DNS 層次結構

我們現在來討論一下上面域名服務器的層次系統

• 根 DNS 服務器 ，有 400 多個根域名服務器遍及全世界，這些根域名服務器由 13 個不同的組織管理，根域名服務器的清單和組織機構可以在 https://root-servers.org/ 中找到，根域名服務器提供 TLD 服務器的 IP 地址，
• 頂級域 DNS 服務器，對于每個頂級域名比如 com、org、net、edu 和 gov 和所有的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務器或服務器集群，所有的頂級域串列參見 https://tld-list.com/ ，TDL 服務器提供了權威 DNS 服務器的 IP 地址，
• 權威 DNS 服務器，在因特網上具有公共可訪問的主機，如 Web 服務器和郵件服務器，這些主機的組織機構必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址，一個組織機構的權威 DNS 服務器收藏了這些 DNS 記錄，

DNS 查詢步驟

下面我們描述一下 DNS 的查詢步驟，從 DNS 決議 IP 再到 DNS 回傳的一系列流程，

注意：通常情況下 DNS 會將查找的資訊快取在瀏覽器或者計算機本地中，如果有相同的請求到來時，就不再會進行 DNS 查找，而會直接回傳結果，

通常情況下，DNS 的查找會經歷下面這些步驟

1. 用戶在瀏覽器中輸入網址 www.example.com 并點擊回車后，查詢會進入網路，并且由 DNS 決議器進行接收，

2. DNS 決議器會向根域名發起查詢請求，要求回傳頂級域名的地址，

3. 根 DNS 服務器會注意到請求地址的前綴并向 DNS 決議器回傳 com 的頂級域名服務器(TLD) 的 IP 地址串列，

4. 然后，DNS 決議器會向 TLD 服務器發送查詢報文

5. TLD 服務器接收請求后，會根據域名的地址把權威 DNS 服務器的 IP 地址回傳給 DNS 決議器，

6. 最后，DNS 決議器將查詢直接發送到權威 DNS 服務器

7. 權威 DNS 服務器將 IP 地址回傳給 DNS 決議器

8. DNS 決議器將會使用 IP 地址回應 Web 瀏覽器

一旦 DNS 查找的步驟回傳了 example.com 的 IP 地址，瀏覽器就可以請求網頁了，

整個流程如下圖所示

DNS 決議器

進行 DNS 查詢的主機和軟體叫做 DNS 決議器，用戶所使用的作業站和個人電腦都屬于決議器，一個決議器要至少注冊一個以上域名服務器的 IP 地址，DNS 決議器是 DNS 查找的第一站，其負責與發出初始請求的客戶端打交道，決議器啟動查詢序列，最終使 URL 轉換為必要的 IP 地址，

DNS 遞回查詢和 DNS 遞回決議器不同，該查詢是指向需要決議該查詢的 DNS 決議器發出請求，DNS 遞回決議器是一種計算機，其接受遞回查詢并通過發出必要的請求來處理回應，

DNS 查詢型別

DNS 查找中會出現三種型別的查詢，通過組合使用這些查詢，優化的 DNS 決議程序可縮短傳輸距離，在理想情況下，可以使用快取的記錄資料，從而使 DNS 域名服務器能夠直接使用非遞回查詢，

1. 遞回查詢：在遞回查詢中，DNS 客戶端要求 DNS 服務器（一般為 DNS 遞回決議器）將使用所請求的資源記錄回應客戶端，或者如果決議器無法找到該記錄，則回傳錯誤訊息，

   

2. 迭代查詢：在迭代查詢中，如果所查詢的 DNS 服務器與查詢名稱不匹配，則其將回傳對較低級別域名空間具有權威性的 DNS 服務器的參考，然后，DNS 客戶端將對參考地址進行查詢，此程序繼續使用查詢鏈中的其他 DNS 服務器，直至發生錯誤或超時為止，

   

3. 非遞回查詢：當 DNS 決議器客戶端查詢 DNS 服務器以獲取其有權訪問的記錄時通常會進行此查詢，因為其對該記錄具有權威性，或者該記錄存在于其快取內，DNS 服務器通常會快取 DNS 記錄，查詢到來后能夠直接回傳快取結果，以防止更多帶寬消耗和上游服務器上的負載，

DNS 快取

DNS 快取(DNS caching) 有時也叫做 DNS 決議器快取，它是由作業系統維護的臨時資料庫，它包含有最近的網站和其他 Internet 域的訪問記錄，也就是說， DNS 快取只是計算機為了滿足快速的回應速度而把已加載過的資源快取起來，再次訪問時可以直接快速參考的一項技術和手段，那么 DNS 的快取是如何作業的呢？

DNS 快取的作業流程

在瀏覽器向外部發出請求之前，計算機會攔截每個請求并在 DNS 快取資料庫中查找域名，該資料庫包含有最近的域名串列，以及 DNS 首次發出請求時 DNS 為它們計算的地址，

DNS 快取方式

DNS 資料可快取到各種不同的位置上，每個位置均將存盤 DNS 記錄，它的生存時間由 TTL(DNS 欄位) 來決定，

瀏覽器快取

現如今的 Web 瀏覽器設計默認將 DNS 記錄快取一段時間，因為越靠近 Web 瀏覽器進行 DNS 快取，為檢查快取并向 IP 地址發出請求的次數就越少，發出對 DNS 記錄的請求時，瀏覽器快取是針對所請求的記錄而檢查的第一個位置，

在 chrome 瀏覽器中，你可以使用 chrome://net-internals/#dns 查看 DNS 快取的狀態，這是基于 Windows 下查詢的，我的 Mac 電腦輸入上面 url 后無法查看 DNS ，只能 clear host cache，我也不知道為啥，可能是哪里設定的原因？

作業系統內核快取

在瀏覽器快取查詢后，會進行作業系統級 DNS 決議器的查詢，作業系統級 DNS 決議器是 DNS 查詢離開你的計算機前的第二站，也是本地查詢的最后一個步驟，

DNS 報文

共同實作 DNS 分布式資料庫的所有 DNS 服務器存盤了資源記錄(Resource Record, RR)，RR 提供了主機名到 IP 地址的映射，每個 DNS 回答報文中會包含一潭訓多條資源記錄，RR 記錄用于回復客戶端查詢，

資源記錄是一個包含了下列欄位的 4 元組

(Name, Value, Type, TTL)

RR 會有不同的型別，下面是不同型別的 RR 匯總表

DNS 有兩種報文，一種是查詢報文，一種是回應報文，并且這兩種報文有著相同的格式，下面是 DNS 的報文格式

上圖顯示了 DNS 的報文格式，其中事務 ID、標志、問題數量、回答資源記錄數、權威名稱服務器計數、附加資源記錄數這六個欄位是 DNS 的報文段首部，報文段首部一共有 12 個位元組，

報文段首部

報文段首部是 DNS 報文的基礎結構部分，下面我們對報文段首部中的每個位元組進行描述

• 事務 ID: 事務 ID 占用 2 個位元組，它是 DNS 的標識，又叫做 識別符號，對于請求報文和回應報文來說，這個欄位的值是一樣的，通過識別符號可以區分 DNS 應答報文是對哪個請求進行回應的，
• 標志：標志欄位占用 2 個位元組，標志欄位有很多，而且也比較重要，下面列出來了所有的標志欄位，

每個欄位的含義如下

• QR(Response): 1 bit 的 QR 標識報文是查詢報文還是回應報文，查詢報文時 QR = 0，回應報文時 QR = 1，
• OpCode: 4 bit 的 OpCode 表示操作碼，其中，0 表示標準查詢，1 表示反向查詢，2 表示服務器狀態請求，
• AA(Authoritative): 1 bit 的 AA 代表授權應答，這個 AA 只在回應報文中有效，值為 1 時，表示名稱服務器是權威服務器；值為 0 時，表示不是權威服務器，
• TC(Truncated): 截斷標志位，值為 1 時，表示回應已超過 512 位元組并且已經被截斷，只回傳前 512 個位元組，
• RD(Recursion Desired): 這個欄位是期望遞回欄位，該欄位在查詢中設定，并在回應中回傳，該標志告訴名稱服務器必須處理這個查詢，這種方式被稱為一個遞回查詢，如果該位為 0，且被請求的名稱服務器沒有一個授權回答，它將回傳一個能解答該查詢的其他名稱服務器串列，這種方式被稱為迭代查詢，
• RA(Recursion Available): 可用遞回欄位，這個欄位只出現在回應報文中，當值為 1 時，表示服務器支持遞回查詢，
• zero: 保留欄位，在所有的請求和應答報文中，它的值必須為 0，
• AD: 這個欄位表示資訊是否是已授權，
• CD: 這個欄位表示是否禁用安全檢查，

• rcode（Reply code）：這個欄位是回傳碼欄位，表示回應的差錯狀態，當值為 0 時，表示沒有錯誤；當值為 1 時，表示報文格式錯誤（Format error），服務器不能理解請求的報文；當值為 2 時，表示域名服務器失敗（Server failure），因為服務器的原因導致沒辦法處理這個請求；當值為 3 時，表示名字錯誤（Name Error），只有對授權域名決議服務器有意義，指出決議的域名不存在；當值為 4 時，表示查詢型別不支持（Not Implemented），即域名服務器不支持查詢型別；當值為 5 時，表示拒絕（Refused），一般是服務器由于設定的策略拒絕給出應答，如服務器不希望對某些請求者給出應答，

相信讀者跟我一樣，只看這些欄位沒什么意思，下面我們就通過抓包的方式，看一下具體的 DNS 報文，

現在我們可以看一下具體的 DNS 報文，通過 query 可知這是一個請求報文，這個報文的識別符號是 0xcd28，它的標志如下

• QR = 0 實錘了這就是一個請求，
• 然后是四個位元組的 OpCode，它的值是 0，表示這是一個標準查詢，
• 因為這是一個查詢請求，所以沒有 AA 欄位出現，
• 然后是截斷標志位 Truncated，表示沒有被截斷，
• 緊隨其后的 RD = 1，表示希望得到遞回回答，
• 請求報文中沒有 RA 欄位出現，
• 然后是保留欄位 zero，
• 緊隨其后的 0 表示未經身份驗證的資料是不可接受的，
• 沒有 rcode 欄位的值

然后我們看一下回應報文

可以看到，標志位也是 0xcd28，可以說明這就是上面查詢請求的回應，

查詢請求已經解釋過的報文我們這里就不再說明了，現在只解釋一下請求報文中沒有的內容

• 緊隨在 OpCode 后面的 AA 欄位已經出現了，它的值為 0 ，表示不是權威 DNS 服務器的回應
• 最后是 rcode 欄位的回應，值為 0 時，表示沒有錯誤，

問題區域

問題區域通常指報文格式中查詢問題的區域部分，這部分用來顯示 DNS 查詢請求的問題，包括查詢型別和查詢類

這部分中每個欄位的含義如下

• 查詢名：指定要查詢的域名，有時候也是 IP 地址，用于反向查詢，
• 查詢型別：DNS 查詢請求的資源型別，通常查詢型別為 A 型別，表示由域名獲取對應的 IP 地址，
• 查詢類：地址型別，通常為互聯網地址，值為 1 ，

同樣的，我們再使用 wireshark 查看一下問題區域

可以看到，這是對 mobile-gtalk.l.google.com 發起的 DNS 查詢請求，查詢型別是 A，那么得到的回應型別應該也是 A

如上圖所示，回應型別是 A ，查詢類的值通常是 1、254 和 255，分別表示互聯網類、沒有此類和所有類，這些是我們感興趣的值，其他值通常不用于 TCP/IP 網路，

資源記錄部分

資源記錄部分是 DNS 報文的最后三個欄位，包括回答問題區域、權威名稱服務器記錄、附加資訊區域，這三個欄位均采用一種稱為資源記錄的格式，如下圖所示

資源記錄部分的欄位含義如下

• 域名：DNS 請求的域名，
• 型別：資源記錄的型別，與問題部分中的查詢型別值是一樣的，
• 類：地址型別、與問題中的查詢類值一樣的，
• 生存時間：以秒為單位，表示資源記錄的生命周期，
• 資源資料長度：資源資料的長度，
• 資源資料：表示按查詢段要求回傳的相關資源記錄的資料，

資源記錄部分只有在 DNS 回應包中才會出現，下面我們就來通過回應報文看一下具體的欄位示例

其中，域名的值是 mobile-gtalk.l.google.com ，型別是 A，類是 1，生存時間是 5 秒，資料長度是 4 位元組，資源資料表示的地址是 63.233.189.188，

SOA 記錄

如果是權威 DNS 服務器的回應的話，會顯示記錄存盤有關區域的重要資訊，這種資訊就是 SOA 記錄，所有 的DNS 區域都需要一個 SOA 記錄才能符合 IETF 標準， SOA 記錄對于區域傳輸也很重要，

SOA 記錄除具有 DNS 決議器回應的欄位外，還具有一些額外的欄位，如下

具體欄位含義

• PNAME：即 Primary Name Server，這是區域的主要名稱服務器的名稱，
• RNAME：即 Responsible authority’s mailbox，RNAME 代表管理員的電子郵件地址，@ 用 . 來表示，也就是說 admin.example.com 等同于 admin@example.com，
• 序列號： 即 Serial Number ，區域序列號是該區域的唯一識別符號，
• 重繪間隔：即 Refresh Interval，在請求主服務器提供 SOA 記錄以查看其是否已更新之前，輔助服務器應等待的時間（以秒為單位），
• 重試間隔：服務器應等待無回應的主要名稱服務器再次請求更新的時間，
• 過期限制：如果輔助服務器在這段時間內沒有收到主服務器的回應，則應停止回應對該區域的查詢，

上面提到了主要名稱服務器和服務名稱服務器，他們之間的關系如下

這塊我們主要解釋了 RR 型別為 A(IPv4) 和 SOA 的記錄，除此之外還有很多型別，這篇文章就不再詳細介紹了，讀者朋友們可以閱讀 《TCP/IP 卷一 協議》和 cloudflare 的官網 https://www.cloudflare.com/learning/dns/dns-records/ 查閱，值得一提的是，cloudflare 是一個學習網路協議非常好的網站，

DNS 安全

幾乎所有的網路請求都會經過 DNS 查詢，而且 DNS 和許多其他的 Internet 協議一樣，系統設計時并未考慮到安全性，并且存在一些設計限制，這為 DNS 攻擊創造了機會，

DNS 攻擊主要有下面這幾種方式

• 第一種是 Dos 攻擊，這種攻擊的主要形式是使重要的 DNS 服務器比如 TLD 服務器或者根域名服務器過載，從而無法回應權威服務器的請求，使 DNS 查詢不起作用，
• 第二種攻擊形式是 DNS 欺騙，通過改變 DNS 資源內容，比如偽裝一個官方的 DNS 服務器，回復假的資源記錄，從而導致主機在嘗試與另一臺機器連接時，連接至錯誤的 IP 地址，
• 第三種攻擊形式是 DNS 隧道，這種攻擊使用其他網路協議通過 DNS 查詢和回應建立隧道，攻擊者可以使用 SSH、TCP 或者 HTTP 將惡意軟體或者被盜資訊傳遞到 DNS 查詢中，這種方式使防火墻無法檢測到，從而形成 DNS 攻擊，
• 第四種攻擊形式是 DNS 劫持，在 DNS 劫持中，攻擊者將查詢重定向到其他域名服務器，這可以通過惡意軟體或未經授權的 DNS 服務器修改來完成，盡管結果類似于 DNS 欺騙，但這是完全不同的攻擊，因為它的目標是名稱服務器上網站的 DNS 記錄，而不是決議程式的快取，
• 第五章攻擊形式是 DDoS 攻擊，也叫做分布式拒絕服務帶寬洪泛攻擊，這種攻擊形式相當于是 Dos 攻擊的升級版

那么該如何防御 DNS 攻擊呢？

防御 DNS 威脅的最廣為人知的方法之一就是采用 DNSSEC 協議，

DNSSEC

DNSSEC 又叫做 DNS 安全擴展，DNSSEC 通過對資料進行數字簽名來保護其有效性，從而防止受到攻擊，它是由 IETF 提供的一系列 DNS 安全認證的機制，DNSSEC 不會對資料進行加密，它只會驗證你所訪問的站點地址是否有效，

DNS 防火墻

有一些攻擊是針對服務器進行的，這就需要 DNS 防火墻的登場了，DNS 防火墻是一種可以為 DNS 服務器提供許多安全和性能服務的工具，DNS 防火墻位于用戶的 DNS 決議器和他們嘗試訪問的網站或服務的權威名稱服務器之間，防火墻提供 限速訪問，以關閉試圖淹沒服務器的攻擊者，如果服務器確實由于攻擊或任何其他原因而導致停機，則 DNS 防火墻可以通過提供來自快取的 DNS 回應來使操作員的站點或服務正常運行，

除了上述兩種防御手段外，本身 DNS 區域的運營商就會采取進步一措施保護 DNS 服務器，比如配置 DNS 基礎架構，來防止 DDoS 攻擊，

更多關于 DNS 的攻擊和防御就是網路安全的主題，這篇文章就不再詳細介紹了，

總結

這篇文章我用較多的字數為你介紹了 DNS 的基本概述，DNS 的作業機制，DNS 的查詢方式，DNS 的快取機制，我們還通過 WireShark 抓包帶你認識了一下 DNS 的報文，最后我為你介紹了 DNS 的攻擊手段和防御方式，

這是一篇入門 DNS 較全的文章，花了我一周多的時間來寫這篇文章，這篇文章了解清楚后，基本上 DNS 的大部分問題你應該都能夠回答，面試我估計也穩了，

如果這篇文章讀者們覺得還不錯，跪求點贊、留言，你的支持將是我繼續肝文的動力！

另外，添加我的微信 becomecxuan，加入每日一題群，每天一道面試題分享，更多內容請參見我的 Github，成為最好的 bestJavaer

我自己肝了六本 PDF，微信搜索「程式員cxuan」關注公眾號后，在后臺回復 cxuan ，領取全部 PDF，這些 PDF 如下

六本 PDF 鏈接