網絡是怎樣連接的

想知道當你從瀏覽器輸入一個網址後按下回車鍵，到瀏覽器顯示出你想看的內容，這一過程發生了什麼嗎？那就來讀一讀這本書吧，深入淺出計算機網絡，帶你瞭解計算機內部0和1的世界[機智] 下面我整理一些考研複試和找工作面試常會被問到的經典問題，方便自己複習，也方便他人蔘考。（以下四個都是我考研複試被問到的） 一、從輸入網址到獲得網頁的過程 1 瀏覽器查詢DNS，獲取域名對應的ip地址，具體包括瀏覽器搜索自身DNS緩存，搜索操作系統DNS緩存，讀取本地host文件，向本地DNS服務器進行查詢。 2 瀏覽器獲得域名對應的ip地址以後，瀏覽器向服務器請求建立連接，發起三次握手。 3 TCP/IP連接建立後，瀏覽器想服務器發送HTTP請求。 4 服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果及相應的視圖返回給瀏覽器。 5 瀏覽器解析並渲染視圖，若遇到對js文件，css文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源。 6 瀏覽器根據其請求到的資源和數據渲染問好，最終向用戶呈現一個完整的頁面。 二、計算機網絡的體系結構和作用 1 第一層物理層，用於通信信道上的原始比特流傳輸。主要設備爲集線器和中繼器，協議數據單元爲比特。 2 第二層數據鏈路層，物理尋址，數據的成幀，流量控制，數據的檢錯和重發。協議數據單元爲幀，主要設備爲網橋和交換機。 3 第三層網絡層。將網絡地址翻譯成對應的物理地址，並決定如何將數據從發送方路由到接收方。協議數據單元爲包，主要設備包括路由器。主要協議是IP和ARP。 4  第四層傳輸層，負責將上層數據分段並提供端到端的，可靠的或者不可靠的傳輸，還要處理端到端的差錯控制和流量控制問題。協議數據單元爲數據段，主要協議爲TCP,UDP 5 第五層會話層，不同機器上的用戶之間建立及會話管理。 6 第六層表示層，信息的語法語義以及他們的關聯，如加密解密，轉換翻譯。 7 第七層應用層，負責爲操作系統或者網絡應用提供網絡服務的接口。主要設備爲網關。提供的服務包括文件傳輸，文件管理等。主要協議爲HTTP和FTP。 三、TCP和UDP的區別 tcp是面向連接的，可靠的，udp是無連接的，不可靠的。tcp只支持點對點通信，udp支持一對一，一對多，多對一和多對多。tcp是面向字節流的，udp是面向報文的。 四、什麼時候用TCP，什麼時候用UDP 對某些實時性要求比較高的時候，選擇udp，比如遊戲，媒體通信和實時視頻流，即出現傳輸錯誤也可以容忍。其他大部分情況，HTTP都是用TCP，因爲要求傳輸內容可靠，不出現丟失。

感謝這本書 一定程度串聯起來我的網絡知識 ##### 一個 URL 的網絡之旅 1. 用戶在地址欄輸入內容，瀏覽器判斷後生成相應的 URL 並傳給網絡進程 1. 如果是普通的字符，那瀏覽器會使用默認的搜索引擎去對於輸入的內容生成 URL 2. 如果輸入的是網址，那瀏覽器會拼接協議名形成完整的 URL2. 網絡進程先查詢本地緩存，沒有則解析 URL 並向 DNS 發送請求，得到 IP 1. 客戶端在進行 DNS 解析之前，會先查看瀏覽器和操作系統是否有緩存域名對應的 IP 地址 2. 如果沒有就會向本地 DNS 服務器發出查詢請求，根 DNS 服務器收到請求後就會返回頂級域名服務器的 IP 地址 3. 然後本地 DNS 服務器再向頂級域名服務器發出查詢請求，頂級域名服務器收到請求後就會返回權威域名服務器的 IP 地址 4. 然後本地 DNS 服務器在向權威域名服務器發出查詢請求，權威域名服務器收到請求後，就會返回域名對應的 IP 地址了3. 網絡進程先與目標服務器進行 TCP、TLS 多次握手，建立 TCP、TLS 安全連接 1. 首先剛開始雙方處於關閉連接狀態，服務端首先創建 socket、綁定端口、然後監聽端口，監聽端口後處於 Listen 狀態，如果沒有 Listen，服務端收到客戶端的報文就會回覆 RST 報文，還想要發生三次握手方式就是客戶端自連接，需要開啓全局 hash 1. 服務端調用 Listen 時，內核會計算半連接的長度，然後據此計算出半連接隊列的長度，開始申請用於關於半連接對象的內存，因爲半連接隊列需要快速查找，所以內核是用哈希表來管理半連接隊列的， 2. 最後會將半連接隊列掛到了接收隊列 queue，當然也會初始化全連接隊列頭，它是一個鏈表的形式，在 listen 這裏因爲沒有連接，所以將全連接隊列頭設置成 NULL 2. 第一次握手： 1. 設置 socket 狀態爲 TCP_SYN_SENT 2. 動態選擇一個端口 1. bind 的時候，如果傳了端口，那麼 bind 就會嘗試使用該端口號，但是默認下一個端口只會被使用一次，所以對於客戶端角色的 socket，不建議使用 bind 2. 如果端口號傳的是 0，則會自動選擇一個端口號 1. 自動選擇一個端口的流程是：會隨機地從 ip_local_port_range 選擇一個位置開始循環判斷，直到找到可用端口，可用端口默認是 28232 2. 如果端口查找失敗，會報錯 "Can not assign requested address"，這個時候應該去檢查一下服務器上的 net.ipv4.ip_locals_port_range 3. 如果因爲某種原因不希望某些端口被使用到，可以把它們寫到 ip_local_reserved_ports 這個內核中就可以啦，內核在選擇的時候會跳過這些端口 3. 構建一個 syn 報文：客戶端首先生成隨機初始化序列號seq = x，並放到 TCP 頭部的32位序號字段中，同時將 SYN 標誌設置爲 1，表示這是一個 SYN 報文，添加到發送隊列，然後發送給服務端並且啓動重傳定時器，該定時器的作用是等到一定時間後收不到服務端的反饋的時候來開啓重傳，在 3.10 版本中首次超時時間是 1s，再 2.6 中是 3 s 3. 第二次握手：服務端收到客戶端發送過來的 SYN 報文後， 1. 首先判斷半連接隊列是否滿了，如果滿了的話進入 tcp_syn_flood_action 去判斷是否開啓了 tcp_syncookies 內核參數，如果隊列滿了，且未開啓 tcp_syncookies，那麼該握手將直接被丟棄 2. 接着判斷全連接隊列是否滿了，因爲全連接隊列滿了也會導致握手異常的，那麼幹脆就在第一次握手的時候也判斷了，如果全連接隊列滿了，且有 young_ack 的話，那麼同樣也是被丟棄，young ack 是半連接隊列裏保持的一個計數器，記錄的是剛有 syn 到達，沒有被 SYN_ACK 重傳定時器重傳過 SYN_ACK，同時也沒有完成過三次握手的 socket 數量 3. 如果未滿的話，就會生成隨機初始化序列號seq = y，並放到 TCP 頭部的32位序號字段中, 並對客戶端的序列化 seq = x + 1 作未確認應答號，然後放到 TCP 頭部的確認應答字段中，同時將 SYN 和 ACK 標誌設置爲 1，表示這是一個 SYN-ACK 報文。把該報文發送給客戶端後並申請 request_sock 添加到半連接隊列啓動計時器，服務端處於 SYC_RCVD 4. 第三次握手：客戶端收到服務端發送過來的 SYN_ACK 報文，會清除第一次握手設置的重傳定時器，把當前 socket 狀態設置爲 ESTABLISHED，開啓保活計時器，然後會發送確認報文給服務端，這個確認報文是對服務端的初始序列化 seq = y + 1, 客戶端進入 ESATBLISH 狀態 5. 服務端收到後，會把對應半連接隊列對象刪除，創建新的 sock 後加入到全連接隊列中，最後將新連接狀態設置爲 ESTABLISHED，也進入 ESTABLISHED 狀態 6. Accept 從已經建立好的全連接隊列中取出一個返回給用戶進程 7. TCP 三次握手完成之後，緊接着進行 TLS 四次握手 1. 客戶端首先會發一個 client Hello 消息，消息裏面有客戶端使用的 TLS 版本號，支持的密碼套件列表、客戶端生成的隨機數，這個隨機數是用來後面生成對稱密鑰之一 2. 當服務端收到客戶端的消息後，會返回 Server Hello 消息給客戶端，消息裏面有服務端確認的 TLS 版本號、密碼套件、服務端生成的隨機數，接着服務端爲了證明自己的身份，會發送 Server Certificate 給客戶端，這個消息含有數字證書，隨後，服務端發送 Server Hello Done 消息，目的是告訴客戶端，我已經把該給你的東西都給你了，本次握手完畢 3. 校驗證書：客戶端收到服務端發送過來的數字證書，會校驗數字證書是否合法，如果合法的則會用 CA 機構的公鑰去解密數字證書拿到服務端的公鑰 4. 客戶端再次生成隨機數，用服務端的公鑰加密後，通過 Client Key Exchange 消息傳給服務端，服務端收到後，用服務端的私鑰解密得到客戶端的第二個隨機數，到這裏，服務端和客戶端都有三個隨機數，雙方根據已經得到的三個隨機數，會根據算法生成對稱密鑰，生成完對稱密鑰後，客戶端會發一個消息告訴服務端開始使用對稱加密方式發送消息，並且還會對之前所有發送的數據做個摘要，再用對稱加密加密一下，讓服務器做個驗證，驗證對稱密鑰是否可用，以及之前握手信息是否有被中途修改 5. 服務器也是同樣的操作，發送消息告訴客戶端開始用對稱加密方式，並且也會對數據做個摘要，並用對稱密鑰加密一下，讓客戶端做個校驗，如果雙方都驗證加密和解密沒問題，那麼 TSL 四次握手正式完成了 6. 最後，就用對稱密鑰加解密 HTTP 請求和響應4. 緊接着組裝請求報文，並由各個分層對數據進行封裝，最終轉爲 0、1 格式5. 基於建立好的連接，利用物理介質傳輸數據，通過路由器控制數據的傳輸方向6. 請求會先去到 CDN 查詢是否有緩存的內容，如果沒有則繼續向下請求7. 請求來到 LVS 後被轉發到 Nginx，再由 Nginx 轉發到 GateWay 網關8. Gateway 網關根據配置好的 API 分發規則，將請求分發到具體服務9. 緊接着在從 Nacos 註冊中心內，查詢出該服務的具體服務實例 IP10. 請求來到具體的服務器後，先通過端口號找到具體的 WEB 服務進程 Tomcat11. Tomcat 基於 SpringMVC 的工作流程爲請求定位到具體的 Java 後端方法 1. 用戶發起請求，請求先被 Servlet 攔截給 Spring MVC 框架 2. Spring MVC 裏面的 DispatcherServlet 核心控制器，會接收到請求並轉發給給 HandlerMapping 3. HandlerMapping 負責解析請求，根據請求信息和配置找到匹配的 Controller 類，不過這裏如果有配置攔截器，就會按照順序執行攔截器裏面的 preHandle 方法 4. 找到匹配的 Controller 以後，把請求參數傳遞給 Controller 裏面的方法 5. Controller 中的方法執行完以後，會返回 一個 ModelAndView，這裏面會包括視圖名稱和需要傳遞給視圖的模型數據 6. 視圖解析器根據名稱找到視圖，然後把數據模型填充到視圖裏面再渲染給 HTML 內容返回給客戶端12. 線程執行 Java 方法時，先去 Redis 中查詢是否有數據，沒有則查詢 MySQL13. 查詢 DB 前先通過 MyBatis 生成 SQL 語句，然後通過 DB 連接執行 SQL 1. 爲了避免每次去查詢數據庫，MyBatis 把查詢出來的數據保存到 sqlSession 的本地緩存中，後續的 SQL 如果命令緩存，就直接從本地緩存讀取了，如果想要實現跨 SqlSession 級別的緩存，那麼一級緩存就無法實現了，所以在 MyBatis 裏面引入了二級緩存，就是當多個用戶在查詢數據的時候，只有任何一個 sqlSession 拿到了數據就會放入到二級緩存裏面，其他的 SqlSession 就可以從二級緩存加載數據 * 一級緩存的具體實現原理是 * 在 SqlSession 裏面持有一個 Executor，每個 Executor 中有一個 LocalCache 對象，當用戶發起查詢的時候，MyBatis 會根據執行語句在 LocalCache 裏面進行查詢，如果沒有命中，再去數據庫查詢並寫入到 LocalCache，否則直接返回，所以一級緩存的生命週期的 SqlSession，而且在多個 SqlSession 或者分佈式環境下，可能會導致數據庫出現髒數據 * 二級緩存的具體實現原理是： * 使用 CacheingExecutor 裝飾了 Executor，所以在進入一級緩存的查詢流程之前，會先通過 CachingExecutor 進入二級緩存的查詢 * 開啓二級緩存以後，會被多個 SqlSesssion 共享，所以它是一個全局緩存，因此它的查詢流程是先查二級緩存，再查一級緩存，最後再查數據庫 * 另外，MyBatis 的二級緩存相對於一級緩存來說，實現了 SqlSession 之間緩存數據的共享，同時緩存粒度也能夠到達 namespace 級別，並且還可以通過 Cache 接口實現類不同的組合，對 Cache 的可控性也更強 2. MyBatis 生成 SQL 語句的流程： 1. 讀取 MyBatis 配置文件：mybatis-config 爲 mybatis 的全局配置文件，配置了 mybatis 的運行環境等信息，例如數據庫連接等信息。 2. 加載映射文件：映射文件即 SQL 映射文件，該文件中配置了操作數據庫的 SQL 語句，需要在 MyBatis 配置文件 mybatis-config.xml 中加載，mybatis-config.xml 文件可以加載多個映射文件，每個文件對應數據庫的一張表 3. 構建會話工廠：通過 mybatis 的環境等配置信息構建會話工廠 SqlSessionFactory 4. 創建會話對象：由會話工廠創建 SqlSession 對象，該對象包含了執行 SQL 的所有方法 5. Executor 執行器：MyBatis 底層定義了一個 Executor 接口來操作數據庫，它將根據 SqlSession 傳遞的參數動態地生成需要執行的 SQL 語句，同時負責查詢緩存的維護 6. MappedStatement 對象：在 Executor 接口的執行方法中有一個 MappedStatement 類型的參數，該參數是對映射信息的封裝，用於要存儲映射 SQL 的 id、參數等信息 7. 輸入參數映射：輸入參數類型可以是 Map、List 等集合類型，也可以是基本數據類型和 POJO 型，輸入參數映射過程類似於 JDBC 對 preparedStatement 對象設置參數的過程 8. 輸出結果映射：輸出結果類型可以是 Map、List 等集合類型，也可以是基本數據類型和 POJO 類型，輸出結果映射類似於 JDBC 對結果集的解析過程 14. 請求根據已配置的數據源地址，來到 MySQL， 並執行 SQL 語句，從而獲得數據 1. 首先會驗證客戶端的用戶名和密碼是否正確 1. 如果用戶名不存在或者密碼錯誤，則拋出 1045 的錯誤即錯誤碼信息 2. 如果用戶名和密碼驗證通過，則進入第 2 步 2. 判斷 MySQL 連接池是否存在空閒線程 1. 存在：直接從連接池中分配一條空閒線程維護當前客戶端的連接 2. 不存在：創建一條新的線程 3. 工作線程會先查詢 MySQL 自身的用戶權限表，獲取當前登錄用戶的權限信息並授權 4. 如果是查詢語句 1. 先將 SQL 語句發送給 SQL 接口，SQL 接口會對 SQL 語句進行哈希處理 2. SQL 接口在緩存中根據哈希值檢索數據，如果緩存中有數據則直接返回 3. 緩存中未命中會將 SQL 交給解析器，解析器會判斷 SQL 語句是否正確 1. 錯誤，拋出 1064 錯誤碼以及相關的語法錯誤信息 2. 正確，將 SQL 語句交給優化器處理，進入往下執行 4. 優化器根據 SQL 制定出不同的執行方案，並選擇最優的執行計劃 5. 工作線程根據執行計劃，調用存儲引擎所提供的 API 獲取數據 6. 存儲引擎根據 API 調用方的操作，去磁盤中檢索數據 7. 發生磁盤 IO 後，對於磁盤中符合要求的數據逐條返回給 SQL 接口 8. SQL 接口會對所有符合要求的結果集進行處理並返回 5. 如果是寫語句 1. 先將 SQL 發送給 SQL 接口，SQL 接口會對 SQL 語句進行哈希處理 2. 在緩存中根據哈希值檢索數據，如果緩存中有數據則將對應表的所有緩存全部刪除 3. 經過緩存後會將 SQL 交給解析器，解析器會判斷 SQL 語句是否正確 1. 錯誤，拋出 1064 錯誤碼以及相關的語法錯誤信息 2. 正確，將 SQL 語句交給優化器處理，繼續往下處理 4. 優化器根據 SQL 制定出不同的執行方案，並選擇出最優的執行計劃 5. 在執行開始之前，先記錄下 undo-log 日誌和 redo-log 日誌 6. 在緩衝區中查找是否存在當前要操作的行記錄或者表數據 1. 存在 1. 直接對緩衝區的數據進行寫操作 2. 然後利用 checkpoint 機制刷寫到磁盤 2. 不存在 1. 根據執行計劃，調用存儲引擎的 API 2. 發生磁盤 IO，對磁盤中的數據做寫操作 7. 寫操作完成後，記錄 bin-log 日誌，同時將 redo-log 日誌中的記錄改爲 commit 狀態 8. 將 SQL 執行耗時及操作成功的結果返回給 SQL 接口，再由 SQL 接口返回給客戶端15. 當結果集處理好了之後，會直接通過 Host 中記錄的地址，經過報文組裝、數據封裝、請求轉發等操作，向客戶端響應數據，16. 應答報文經物理介質傳輸後，最終抵達客戶端網絡進程 1. 網絡數據幀通過(物理介質)**網絡傳輸**到達網卡時，網卡會將網絡數據幀通過 DMA 的方式放到環形緩衝區 RingBuffer 中 2. 當 DMA 操作完成時，網卡會向 CPU 發起一個硬中斷，告知 CPU 有網絡數據到達，CPU 調用網卡驅動註冊的**硬中斷響應程序**。網卡硬中斷響應程序會爲網絡數據幀創建內核數據結構 sk_buffer，並將網絡數據幀拷貝到 sk_buffer 中，然後發起軟中斷請求，通知內核有新的網絡數據幀到達 3. 內核線程 ksoftirqd 發現有軟中斷請求到來，隨後調用網卡驅動註冊的 poll函數，poll 函數 將 sk_buffer 中的網絡數據包送到內核協議棧中註冊的 ip_rcv 函數 中 4. ip_rcv 函數也就是網絡層，取出數據包的 IP 頭，判斷該數據包下一跳的走向，如果數據包是發送給本機的，則取出傳輸層的協議類型，並去掉數據包的 IP 頭，將數據包交給傳輸層處理 5. 當我們採用的是 TCP 協議，數據包到達傳輸層時，會在內核協議棧中的 tcp_rcv 函數處理，在 tcp_rcv 函數中去掉 TCP 頭，根據四元組(源 IP，源端口，目標 IP，目標端口)查找 對應的 Socket，如果找到對應的 Socket 則將網絡數據包中的傳輸數據拷貝到 Socket 中的接受緩衝區中，如果沒有找到，則發送一個目標不可達的 icmp 包17. 網絡進程將數據交給瀏覽器後，根據情況做 TCP 四次揮手，斷開連接 1. 客戶端主動調用關閉連接的函數，於是就會發送 FIN 報文，這個 FIN 報文代表客戶端不會再發送數據了，進入 FIN_WAIT_1 狀態； 2. 服務端收到了 FIN 報文，然後馬上回復一個 ACK 確認報文，此時服務端進入 CLOSE_WAIT 狀態。在收到 FIN 報文的時候，TCP 協議棧會爲 FIN 包插入一個文件結束符 EOF 到接收緩衝區中，服務端應用程序可以通過 read 調用來感知這個 FIN 包，這個 EOF 會被**放在已排隊等候的其他已接收的數據之後**，所以必須要得繼續 read 接收緩衝區已接收的數據； 3. 接着，當服務端在 read 數據的時候，最後自然就會讀到 EOF，接着 **read() 就會返回 0，這時服務端應用程序如果有數據要發送的話，就發完數據後才調用關閉連接的函數，如果服務端應用程序沒有數據要發送的話，可以直接調用關閉連接的函數**，這時服務端就會發一個 FIN 包，這個 FIN 報文代表服務端不會再發送數據了，之後處於 LAST_ACK 狀態； 4. 客戶端接收到服務端的 FIN 包，併發送 ACK 確認包給服務端，此時客戶端將進入 TIME_WAIT 狀態； 5. 服務端收到 ACK 確認包後，就進入了最後的 CLOSE 狀態； 6. 客戶端經過 2MSL 時間之後，也進入 CLOSE 狀態；18. 瀏覽器創建渲染子進程，然後根據數據生成渲染樹，最後繪製並顯示頁面

《網絡是怎麼連接的》一個互聯網大廠面試常考題： 你在瀏覽器輸入網址後獲得整個頁面的過程？ 瀏覽器接收到網址後，查詢DNS獲取域名對應的IP地址，然後向服務器發送請求，進行三次握手（三報文握手）建立連接。 連接建立後，瀏覽器向服務器發送HTTP請求。 服務器接收到HTTP請求後，根據路徑參數映射對應請求處理器處理，並將結果返回給瀏覽器。 瀏覽器接收到服務器的響應數據後解析並渲染到頁面上，對於圖片等靜態資源的引用，會先在頁面上；留出顯示空間，重複上面的步驟再向服務器發送請求。瀏覽器接收到靜態資源後繼續解析並渲染，得到最終的頁面內容。 本書就是圍繞這樣的過程展開，告訴你這個過程的細節是怎麼回事，幫助你構建計算機網絡的整體框架。 全書15.6萬字，完整閱讀9個半小時。一個字描述讀後感：爽！ 這是一本講述計算機網絡的書，但是不同於計算機領域大佬謝希仁的專著《計算機網絡》那樣自頂向下地教授計算機七層協議各個部分的內容，而是從最直接的應用場景起手——從瀏覽器中輸入網址開始，一直追蹤後續返回整個頁面的過程，告訴你這幾秒直接計算機網絡發生了什麼，屬於一本內容專業，但是不難讀的計算機網絡科普書。 綜述：全書六個章節。開篇先總體網絡的全貌，給你全書的路線圖： 1. 向瀏覽器輸入網址後，web瀏覽器查詢DNS解析網址，獲得域名對應的IP地址，生成HTTP消息交給操作系統的Socket庫。 2. Socket庫將接收到的HTTP消息作爲數據轉發給操作系統的協議棧。 3. 操作系統協議棧根據需要對HTTP消息進行分包，然後添加TCP頭，轉交給IP模塊。 4. IP模塊在TCP包前加上IP頭，然後查詢MAC地址並加上MAC頭部，然後將包轉交給網卡驅動，由網卡驅動轉交給網卡併發送指令進行傳輸。 5. 傳輸過程會經過集線器、交換機、路由器層層轉發，最後送達Web服務器的局域網。 6. 在Web服務器器的局域網中通過防火牆、緩存服務器（服務器不一定設置），web服務器接收到數據包，並通過web服務器的網卡、網卡驅動、協議棧、Socket庫“拆快遞”，最終連接到web服務器對應的應用程序完成連接。 7. 後續持續通過這個過程進行數據傳輸。 每個章節逐層分析：客戶端Web瀏覽器做了什麼， 協議棧和網卡做了什麼， 集線器+交換機+路由器做了什麼， 接入網、網絡運營商的數據傳遞邏輯， 防火牆、緩存服務器的控制作用， Web服務器接收請求、數據傳輸、關閉連接的全過程。 作爲學通信的學生，這樣一本好書比學校老師教授的內容好吸收很多。從概述部分就向你提供了計算機網絡傳輸的地圖。因爲本書的定位偏向於科普讀物，並沒有像專著一樣對各個技術進行深挖。並且譯者在文中多處提供了註釋輔助理解，並且在微信讀書的機制下會有各路大神留下高質量的評論爲你答疑解惑。 本書的語言風格偏口語化，並且每章開頭和結尾會提供小測試幫助讀者瞭解和總結本章內容。 提示：這終究是一本比較專業的科普書籍，所以在閱讀過程中會有一些計算機領域的專業術語，如：協議，cdn，ADLS。不要指望讀一遍就能夠完全瞭解計算機網絡。需要繼續深耕建議去讀《計算機網絡》 槽點：本書雖然只有15.6萬字，但是在使用了較多圖表輔助理解，需要多次翻閱，在電子書的機制下，頁面1的文字內容可能需要翻到頁面4查看。有一定障礙，但是如果你是雙設備閱讀或者紙質閱讀，那麼問題不大。

對於不是科班出身的童鞋來說，是一本很好的網絡基礎入門書籍，穿插專業術語的解釋和插圖，對複雜的網絡通信世界有了些微的瞭解，第一次看，一下子全部吸收不大可能，需要循序漸進，提出自己的疑問 試着去書中尋找答案，我覺得下次再看時配合紙質筆記手繪網絡通信流程可能會取得更好的效果。

大學時沒學會的計算機網絡。在這裏學會了。 數據進來時，路由器可以根據MAC地址判斷是不是給自己的。如果是給自己的，那麼會根據數據包裏面的IP查找下一跳，決定好下一跳時，會重新封裝數據包裏面的源、目的MAC地址。隨後發出。 ﹉﹉﹉ 緩存服務器部署在客戶端網絡中，那麼服務端不能控制了，好處是可以加速、減輕服務端負載、網絡流量穩定（減少了網絡節點的阻塞，因爲部署在客戶端網絡中，少走互聯網了）；如果部署在服務端，服務端可控制，可以加速、減輕服務端負載，但無法減少互聯網流量，可能會發生網絡擁塞的情況。所以結合二者的有點。將其部署在互聯網邊界，也就是客戶端接入網的服務商那裏，這樣服務端可控制緩存服務器，而且也能減少網絡擁塞了。這就是CDN

首先說壞話 這絕對不是一本「輕鬆的科普書」，閱讀難度就我自己親身體驗，是那種需要讀後認真做筆記消化纔有意義的書，單純的閱讀只會讓你頭昏腦脹不明所以。 書中巨量的生詞也是個閱讀難點，大部分時間你都會處在「雖然不知道這玩意是什麼但是必須看下去」的狀態，部分互聯網機制要到很後面才揭曉，這就需要你不停地回看。所以我覺得這本書更適合紙質，線上特別是微信讀書的跳轉做得不好，來回翻看難度很高。作爲計算機專業的學生，讀完後反覆觀看或者立即進入進深閱讀都很有必要，遺忘的速度太快了 - 然後說好的方面。雖然過程讓我一度想放棄，但 21 天后我還是讀完了它，並且確定我是相對滿意的。這裏提出另一個閱讀要點「不要中途停下」，對於這本生詞多得能當水喝的書來說真的很重要，就算我是連續閱讀也有很多次感覺完全不記得之前讀了啥。 在渡過痛苦期之後，你會突然看得懂這些文字在說什麼了，這種感覺很奇妙。不想談論中間的總結因爲像又上了一次課，總之在最後有一張過程表，發現自己可以讀懂那張表的時候是很驚喜的。TCP IP相關的內容第一次出現時其實沒太看懂，但因爲後面講網絡包反覆提及，慢慢也就明白了IP發送、TCP端口之類的東西（原諒我只能寫出自己看得懂的文字） 總體推薦專業人士入門閱讀，但不推薦給純想了解一下互聯網的人，會把自己痛苦到，還是找一些視頻慢慢看得好

本書講解了從瀏覽器輸入網址一直到顯示網頁內容的幾秒鐘的過程。對我這種小白而言，這本書的內容看的我是一愣一愣的，總得來說，就是啥也不懂。一天看一小節一點一點的啃完了。 總結一下本書內容網絡包的旅程： 一、 客戶端 瀏覽器—Socket庫—協議棧（TCP/IP）—網卡驅動—網卡 二、 客戶端局域網 雙絞線—集線器—交換機—互聯網接入路由器—ADSL Modem 三、 接入網 DSLAM（局端多路Modem）—BAS（寬帶接入服務器）—隧道—隧道專用路由器 四、 Web服務器端局域網 互聯網—防火牆—緩存服務器 五、 Web服務器 網卡—網卡驅動—協議棧（TCP/IP）—Socket庫—Web服務器

歷時18天，共16小時56分鐘，總算讀完此書。 雖然書中提到的少數技術在現今看來些許過時了，用於瞭解計算機網絡的總體架構和發展史，讀來還是頗爲有益的。 尤其適用於web開發者及計算機網絡初、中級學習者。 另，本書內容組織非常好，作爲技術類書籍，讀來竟然少見讓人漸入佳境、覺得很有趣味。

《網絡是怎樣連接的》目標：理解整個網絡的骨架。【s1 瀏覽器生成消息】重點：瀏覽器如何解析網址、請求消息實際的樣子、DNS幫助查詢IP地址、消息委託給操作系統發送給web服務器本章建立了“從輸入網址到發出請求”的完整邏輯1.生成http請求消息2.向dns服務器查詢ip地址3.DNS服務器大接力4.委託協議棧發送消息 核心：“瀏覽器不懂路，只負責打包，DNS負責指路，操作系統負責跑腿” 實戰預測：①DNS 解析排障場景：用戶反饋“微信能發消息（IP直連），但網頁打不開（依賴域名）”。知識點：這通常是 DNS 掛了。工具：使用 nslookup 或 dig 命令手動查詢域名。命令：nslookup www.baidu.com排查：如果超時或無返回，說明 DNS 服務器不可達，嘗試更換 DNS（如 114.114.114.114 或 8.8.8.8）。 ② 內外網域名解析不一致場景：在公司內部訪問 internal.company.com 應該解析到內網 IP（10.x.x.x），但在家訪問應該解析到公網 IP。知識點：DNS 解析結果取決於你詢問的 DNS 服務器。內網 DNS 知道內網 IP，公網 DNS 只知道公網 IP。操作：新員工入職電腦無法訪問內部倉庫，大概率是 DNS 設置爲了 114 或 8.8，而不是公司的內網 DNS 服務器。 【s2 用電信號穿書tcp/ip數據】重點：協議棧如何執行瀏覽器委託的發送任務，核心脈絡是，創建套接字→連接服務器→收發數據→斷開連接。連接和斷開時的三次握手，四次揮手。實戰預測：①排查端口衝突場景：啓動 Nginx 報錯 bind() failed: Address already in use。知識點：端口已被另一個進程佔用（也可能處於 TIME_WAIT 狀態）。操作：用 lsof -i :80 或 ss -tlnp | grep :80 找到佔用的進程，確認是否可以停止或更換端口。 【S3 從網絡到網絡】重點：數據包如何在互聯網那個中經過多個網絡跳轉到達服務器，核心脈絡是，ip模塊發送包→通過路由表選擇下一跳→使用ARP查詢mac→經過集線器/交換機/路由器轉發→到達目標“路由器看IP，交換機看MAC”，以及 “路由表決定下一跳，ARP找到下一跳的MAC” 【S4通過接入網進入互聯網那個內部】重點：數據包如何從家庭/公司網絡通過接入網進入互聯網內部，核心脈絡是接入網類型（ADSL/FTTH）→信號轉換與調製→用戶認證（PPPoE）→運營商網絡（BAS/DSLAM）→跨運營商路由（BGP./IXP） 【S5服務器端的局域網中有什麼玄機】重點：網絡包到達服務器所在的局域網後，如何通過防火牆、負載均衡器、緩存服務器等設備最終抵達服務器，核心脈絡是服務器部署位置→防火牆包過濾→負載均衡分發→緩存加速→CDN內容分發 【S6請求到達Web服務器，響應返回瀏覽器】重點：數據包抵達服務器後如何被處理、web服務器如何生成相應、瀏覽器如何渲染頁面的完整閉環。核心脈絡是硬件接收→協議棧處理→web應用解析→生成響應→瀏覽器渲染。 【全書總結】數據包的完整旅行你的電腦→局域網/家裏路由器→接入網（電話線/光纖）→運營商網絡→互聯網骨幹→目標機房→目標服務器→原路返回關鍵角色：DNS（把 www.baidu.com 變成 IP）TCP（保證數據可靠傳輸（三次握手、重傳））IP+路由（一跳一跳找下一站）交換機（同網段內根據 MAC 轉發）路由器/網關（跨網段轉發，連接內外網）防火牆（按規則放行或攔住包）負載均衡（多臺服務器分攤壓力）Web服務器（接收請求，返回網頁/接口）

五一4天都在啃這本書，留了個尾巴沒啃完，今天終於看完了。不得不說，這真的是一本瞭解網絡通信的優質書，能把複雜的東西講的清清楚楚，讓人一看就懂。看完除了對網絡通信有一個挺全面的理解，也非常佩服作者知識面之廣，之深。譯者也超級棒，翻譯質量非常高。自己還要讀第二遍，筆記纔剛剛記完第二章。強烈推薦IT業的人讀讀這本書。