簡介《計算機基礎(chǔ).pdf》是代碼隨想錄知識星球「最強八股文」第五版的計算機基礎(chǔ)分冊面向準備后端、前端及全棧崗位技術(shù)面試的開發(fā)者聚焦計算機網(wǎng)絡這一高頻考點。內(nèi)容圍繞三次握手與四次揮手、HTTP 與 HTTPS 的區(qū)別、HTTP 強緩存與協(xié)商緩存、DNS 域名系統(tǒng)展開并以「瀏覽器輸入 URL 后發(fā)生了什么」為主線串起 URL 解析、DNS 查詢、TCP 建連、請求響應到頁面渲染的完整鏈路DNS 章節(jié)還延伸到集中式設(shè)計的單點故障與遠程延遲問題、域名層級結(jié)構(gòu)、遞歸查詢與迭代查詢的差異便于按面試問答的粒度記憶。資源為單個 pdf 文件壓縮包約 37.83MB已整理成體系化文檔可直接打印或按章節(jié)精讀。目前已有 778 人學習適合需要系統(tǒng)梳理網(wǎng)絡基礎(chǔ)、補齊面試答題要點、從零散博客轉(zhuǎn)向結(jié)構(gòu)化復習的初中級開發(fā)者。1. 先搞懂一件事計算機基礎(chǔ)這門課到底在教你什么很多人第一次認真看「計算機基礎(chǔ)」這四個字是在招聘要求上十條里有八條寫著「熟悉計算機網(wǎng)絡」。心里一緊翻開教材滿眼都是縮寫和協(xié)議名越看越發(fā)怵覺得自己是不是漏學了什么。其實這門課沒那么玄。它講的事情很樸素兩臺電腦之間怎么把一句話準確送到又怎么確認對方真的收到了。你點開一個網(wǎng)頁、發(fā)一條消息、掃一次碼付款底下跑的都是這套流程?！队嬎銠C基礎(chǔ).pdf》這一篇就是從「在瀏覽器里輸入一個網(wǎng)址按下回車之后發(fā)生了什么」這道題起步把網(wǎng)絡這條線上的關(guān)鍵節(jié)點一個個講開域名怎么變成地址、連接怎么建立、數(shù)據(jù)怎么傳、連接又怎么斷開。它不要求你先會寫代碼適合完全沒接觸過、又想在面試和日常排查里少翻車的新手先當成一張地圖看一遍。2. 從敲下回車那一刻拆起一次網(wǎng)頁訪問的七個步驟這是整個計算機網(wǎng)絡里出現(xiàn)頻率最高的一道題也是新手最值得先啃下來的一塊。原因很簡單它不是孤零零一個知識點而是一根繩把 URL、DNS、TCP、HTTP、緩存、渲染全串在了一條線上。你把這條線捋順了后面學什么都像往鉤子上掛東西有地方掛。我習慣用打電話來類比。你要找一個人辦事先得知道他的號碼DNS撥過去等對方接建立連接接通了說事發(fā)請求、對方回你響應事情說完要掛電話斷開連接。網(wǎng)頁訪問一模一樣只是把「說話」換成了數(shù)據(jù)包。七個步驟分別是解析 URL、DNS 域名解析、TCP 三次握手、發(fā)送 HTTP 請求、服務器處理并返回響應、瀏覽器渲染頁面、TCP 四次揮手。下面三小節(jié)按順序走一遍。2.1 前三步URL 拆包、DNS 找地址、三次握手第一步瀏覽器拿到你輸入的網(wǎng)址先拆件。它會把協(xié)議http 還是 https、主機名、端口、路徑分別摳出來然后拼成一個 HTTP 請求。在真正發(fā)出去之前瀏覽器還會翻一下自己的緩存這個資源我是不是剛拿過、還沒過期如果有直接就用連網(wǎng)絡都不用走。這一步看著不起眼但后面 HTTP 緩存那一大塊內(nèi)容全是從這兒分叉出去的。第二步是 DNS 解析。人能記住www.example.com機器只認192.0.2.1這樣一串數(shù)字。DNS 干的就是翻譯的活。翻譯不是一次到位的中間要問好幾個人先看瀏覽器自己的緩存里有沒有沒有就問操作系統(tǒng)的 hosts 文件還沒有就去找本地 DNS 服務器通常是網(wǎng)絡服務提供商給的那個本地 DNS 服務器沒緩存就去問根服務器「.com該找誰」根服務器不負責具體域名只告訴你去問哪個頂級域服務器頂級域服務器同樣只指路告訴你去找哪個權(quán)威服務器權(quán)威服務器才是真正存著「這個域名對應哪個 IP」的地方把結(jié)果給回來本地 DNS 拿到結(jié)果返回給瀏覽器順手緩存一份。這里有個新手很容易混的點遞歸查詢和迭代查詢。用大白話說遞歸就是「我托你辦你幫我跑完全程最后把結(jié)果給我」迭代就是「我問你一句你只告訴我下一站去哪兒我自己接著跑」。客戶端對本地 DNS 服務器用的是遞歸本地 DNS 服務器對根、頂級、權(quán)威服務器用的是迭代。把這個「誰替誰跑腿」分清楚這兩個詞就不會再打架。第三步拿到 IP 了該建立連接了。TCP 的三次握手表格列出來更清楚次數(shù)誰發(fā)起發(fā)了什么這一步確認了什么第一次客戶端SYN帶上自己的初始序號服務器知道客戶端能發(fā)第二次服務器SYN ACK帶上自己的初始序號并確認對方的客戶端知道服務器能收也能發(fā)第三次客戶端ACK確認服務器的序號服務器知道客戶端能收面試官最愛追問的是「為什么是三次不是兩次也不是四次」。兩次的問題在于服務器發(fā)完自己的 SYNACK 之后并不知道客戶端到底收沒收到。如果這次回應在半路丟了服務器已經(jīng)單方面認為連接建立好了白白占著資源等一個永遠不會來的數(shù)據(jù)。三次剛好讓雙方都完成「我發(fā)的你能收、你發(fā)的我也能收」的互相確認。至于四次純屬多余第三次已經(jīng)把話說完了。還有一個常問的第一次握手丟了會怎樣答案不復雜——客戶端等不到回應會按超時時間重發(fā) SYN重發(fā)幾次還不行就報連接超時。服務器那邊因為根本沒收到不會分配任何資源所以不會有什么損失。這也正是三次握手而不是兩次的實際價值所在。2.2 第四、五、六步請求發(fā)出去、服務器回話、頁面畫出來連接建好第四步就是把 HTTP 請求發(fā)出去。一個請求報文的結(jié)構(gòu)是「請求行 請求頭 空行 請求體」。請求行里寫著方法GET、POST 這些和路徑請求頭是一堆鍵值對告訴服務器我想要什么格式、我?guī)Я耸裁?Cookie、我支持什么壓縮方式。這一步能岔出去的問題特別多HTTP 和 HTTPS 差在哪兒HTTPS 在 HTTP 和 TCP 之間加了一層 SSL/TLS把明文變成密文、GET 和 POST 有什么區(qū)別、常見的狀態(tài)碼都是什么意思。狀態(tài)碼按開頭數(shù)字分組記最省事2 開頭是成功3 開頭是重定向4 開頭是客戶端的問題比如 404 找不到、403 沒權(quán)限5 開頭是服務器自己出了狀況。第五步服務器收到請求交給對應的處理程序處理完拼一個響應報文回來。響應報文里除了網(wǎng)頁內(nèi)容本身還有幾個頭部字段值得留意Content-Type說明返回的是什么類型Content-Encoding說明用了什么壓縮方式Cache-Control和ETag決定這個資源能被緩存多久、下次怎么驗證Set-Cookie則是服務器往你瀏覽器里塞的身份憑證。第六步瀏覽器拿到內(nèi)容開始畫頁面。大致的流程是解析 HTML 生成 DOM 樹解析 CSS 生成 CSSOM 樹兩棵樹合起來算布局最后繪制到屏幕上。這里有個前端同學必會的區(qū)分布局位置變了叫回流重排只改顏色背景叫重繪。回流的代價比重繪大得多所以寫樣式時盡量別頻繁改動寬高和位置。順帶說一句 HTTP 的「無狀態(tài)」。服務器天生不記得你是誰上一次請求和這一次請求在它眼里毫無關(guān)系。這事兒有好處——不用為每個用戶存一堆狀態(tài)服務器輕松壞處是登錄這類連續(xù)操作沒法做。解決辦法就是 Cookie服務器在響應里寫一個標識瀏覽器之后每次請求都自動帶上服務器一看就認出來了。2.3 第七步四次揮手以及為什么不能少一次事情辦完要掛電話。TCP 斷開連接用的是四次揮手客戶端發(fā) FIN我這邊沒數(shù)據(jù)要發(fā)了服務器回 ACK知道了你先等著服務器發(fā) FIN我這邊也發(fā)完了客戶端回 ACK好那我關(guān)了。為什么是四次不是三次因為 TCP 是全雙工的兩個方向的數(shù)據(jù)通道要分別關(guān)。服務器收到客戶端的 FIN 時可能手里還有數(shù)據(jù)沒發(fā)完所以不能把「我收到了」和「我也發(fā)完了」合并成一條消息發(fā)回去只能先 ACK等自己真的發(fā)完了再單獨發(fā) FIN。這就是比握手多一次的根本原因。主動關(guān)閉的那一方在發(fā)完最后一個 ACK 之后還會進入一個叫 TIME_WAIT 的狀態(tài)等上一小段時間才真正關(guān)閉。入門階段不用深挖它到底等多久、為什么是那個數(shù)知道有這回事、知道它是為了確保最后那個 ACK 能到達對方就行了等以后排查端口占用問題時自然會回頭找它。3. 為什么新手要優(yōu)先啃網(wǎng)絡這塊三個繞不開的理由知道了流程長什么樣下一個問題自然是為什么偏偏是這塊而不是操作系統(tǒng)、數(shù)據(jù)庫、算法這些當然也重要但對零基礎(chǔ)的人來說起步順序很關(guān)鍵。先把網(wǎng)絡拿下理由有三個一個比一個實際。3.1 它是面試里出現(xiàn)頻率最高的一道篩子不管投后端還是前端網(wǎng)絡題幾乎躲不掉。三次握手、四次揮手、HTTPS、HTTP 緩存、TCP 和 UDP 的區(qū)別這幾樣屬于「不問才奇怪」的級別。面試官盯著這些問不是想聽你背定義而是想看你能不能把一件事從頭到尾講明白。這道「輸入網(wǎng)址到頁面顯示」的題之所以金貴在于它是一道可以自己控制走向的題。你答得好可以主動把話頭引到自己熟的地方想聊緩存就說「這里瀏覽器會先查緩存」想聊 HTTPS 就說「這里建立的是 TLS 連接」想聊渲染就說「這里會牽扯回流重繪」。面試節(jié)奏就握在你手里了。反過來如果這條主線是斷的被追問兩句就只能是支支吾吾地蹦詞兒。而且這類問題有個特點答案短追問長。你答「三次握手是為了防止失效的連接請求」面試官下一句就是「那第一次握手丟了會怎樣」。只背結(jié)論的人第二層就掉下去了。3.2 出問題的時候它是最省時間的那張排查地圖拋開面試不談網(wǎng)絡知識在日常工作里的回報也很直接。一個頁面打不開原因可能有十幾種瞎試是最費時間的。但如果你腦子里有那張流程圖排查就是順著鏈條走域名解析對不對查一下 DNS 記錄就知道解析對了但連不上看看端口通不通、防火墻攔沒攔連上了但返回的東西不對看狀態(tài)碼和響應頭內(nèi)容對但每次都是舊的八成是緩存沒清干凈。這套順序的價值在于「排除法」。每走一步就砍掉一批可能性而不是東一榔頭西一棒子。我?guī)н^的新人里進步最快的那個不是代碼寫得最多的而是遇到問題會先說「我先確認一下是解析問題還是連接問題」的那個。3.3 零基礎(chǔ)最怕碎片得先立一根主干零基礎(chǔ)學計算機最容易掉進的坑是把知識點當成一堆互不相干的卡片去背。背了三次握手又去背 HTTP 版本再去看 DNS每一塊都似懂非懂合起來還是一團漿糊。網(wǎng)絡這塊的好處是它天然有一條主干一次訪問流程。所有知識點都能掛在這條主干的某個位置上。DNS 掛在第二步握手掛在第三步緩存掛在第一步和第六步之間HTTP 版本演進掛在第四步和第五步。掛上去之后你腦子里存的不是十張卡片而是一棵樹。以后學新東西也知道往哪個枝丫上接。這也是這份《計算機基礎(chǔ).pdf》編排上的一個用心之處它沒有一上來就羅列協(xié)議定義而是先用那道超高頻題把整條鏈路走一遍再往每個節(jié)點上填細節(jié)。對新手來說這種「先看地圖再走路」的順序比「先背概念再拼圖」友好太多。4. 第一個動手練習用開發(fā)者工具和一條命令把請求拆開看光看流程圖永遠隔著一層。真正的理解發(fā)生在你親眼看到一條請求從發(fā)出去到回來的那一刻。好消息是這件事不需要裝任何環(huán)境瀏覽器里就自帶工具。整個練習大概十分鐘跟著做一遍前面講的那些名詞會立刻變得具體。4.1 打開 Network 面板先認四列就夠隨便打開一個網(wǎng)頁按下 F12找到 Network網(wǎng)絡面板然后刷新頁面。你會看到一長串請求刷出來第一眼確實有點嚇人。別慌先只看四列Name請求的資源名字通常是一個文件Status狀態(tài)碼200 是成功304 是用了緩存404 是找不到Type資源類型document 是網(wǎng)頁本身script 是腳本stylesheet 是樣式Time這一條花了多久。點第一條一般是那個 document右邊會彈出一個詳情面板。里面有 Headers、Preview、Response、Timing 幾個標簽。先看 Headers你會發(fā)現(xiàn)它分成三塊General請求地址、方法、狀態(tài)碼、Response Headers服務器回的、Request Headers你發(fā)出去的。前面講的「請求頭和響應頭」在這兒變成了一屏能看到的東西。提示勾上「Disable cache」再刷新你會發(fā)現(xiàn)請求變多了、時間變長了。這就是緩存的作用直觀得有點殘忍。再切到 Timing 標簽你能看到這條請求的時間被拆成了好幾段排隊、DNS 查詢、建立連接、等響應、下載內(nèi)容。如果某一段特別長問題基本就在那兒。這是新手排查慢請求最快的一招。4.2 親手發(fā)一次請求一條命令和十行代碼瀏覽器把很多東西藏起來了想看得更裸一點用命令行。下面這條命令只取響應頭不下載網(wǎng)頁正文# -I 表示只要響應頭-s 表示靜默模式不打印進度條 curl -I -s https://www.example.com跑完你會看到類似這樣的輸出狀態(tài)行、Content-Type、Cache-Control、ETag、Last-Modified。這幾個字段就是后面緩存那一節(jié)的實物。參數(shù)說明-I是「只要頭部」-s是「安靜點」實際用的時候把網(wǎng)址換成你要查的那個站點就行。想看得更細加上-v# -v 打印全過程DNS 解析、TCP 連接、TLS 握手、請求頭、響應頭 # -o /dev/null 把正文丟掉只看過程 curl -v https://www.example.com -o /dev/null輸出里帶*的那些行就是連接的建立過程先解析出 IP再連上去如果是 https 還要多一步握手然后才把請求頭發(fā)出去。前面講的三次握手你在這看不到原始報文那是傳輸層的事被系統(tǒng)藏起來了但「連接建立」這一步是實打?qū)嵞芸匆姷?。再往下走一層?Python 自己發(fā)一次把狀態(tài)碼和響應頭打出來import urllib.request url https://www.example.com req urllib.request.Request(url, methodGET) # 默認的 User-Agent 是 Python-urllib有些站點會直接拒絕這里換成常見瀏覽器標識 req.add_header(User-Agent, Mozilla/5.0 (Windows NT 10.0; Win64; x64)) with urllib.request.urlopen(req, timeout10) as resp: print(狀態(tài)碼:, resp.status) # 200 表示成功 for key, value in resp.headers.items(): print(f{key}: {value}) # 逐條打印響應頭這段代碼干的事和瀏覽器一模一樣構(gòu)造請求、加上請求頭、發(fā)出去、拿回響應。timeout10是超時時間超過十秒還沒回應就拋異常避免程序卡死。resp.status是狀態(tài)碼resp.headers是一個大小寫不敏感的字典取Content-Type時不用管大小寫。跑通它你就從「看別人發(fā)請求」變成了「自己發(fā)請求」。順便把 DNS 也驗證一下# 查詢域名的 A 記錄short 只輸出結(jié)果 IP dig www.example.com A short # Windows 上通常沒有 dig換成nslookup www.example.com如果這里查出來的 IP 和瀏覽器訪問的對不上或者干脆查不到那問題就出在解析環(huán)節(jié)后面的都不用看了。4.3 從響應頭里讀出緩存策略強緩存和協(xié)商緩存前面反復提到緩存現(xiàn)在可以拿真實數(shù)據(jù)看一看了。HTTP 緩存分兩類判斷依據(jù)全在響應頭里。第一類叫強緩存。服務器返回Cache-Control: max-age3600意思就是「這個資源一小時內(nèi)別來問我了直接用你手里的」。在這一小時內(nèi)瀏覽器連請求都不會發(fā)狀態(tài)碼那一列可能顯示(from disk cache)或者干脆沒有網(wǎng)絡記錄。這是最快的一檔也是新手最容易翻車的一檔——你改了服務器上的文件刷新頁面卻還是舊的八成就是它。第二類叫協(xié)商緩存。強緩存過期之后瀏覽器不會直接重新下載而是先去問一句「我手里這份還能用嗎」。它帶的憑證有兩種If-None-Match對上服務器給的ETag或者If-Modified-Since對上服務器給的Last-Modified。服務器一看沒變回一個 304意思是「沒改你繼續(xù)用」。304 的響應體是空的省下的是流量和時間。驗證方法很直接在 Network 面板里勾掉 Disable cache正常刷新一次記下某條請求的ETag再刷新一次看狀態(tài)碼是不是變成了 304。如果是說明協(xié)商緩存生效了。想強行繞過緩存用 curl 加一句# 帶上 no-cache強制走一次協(xié)商看服務器是不是回 304 curl -I -s -H Cache-Control: no-cache https://www.example.com-H是自定義請求頭這里塞了一個Cache-Control: no-cache。注意它不是說「不要緩存」而是說「用之前必須先跟服務器確認一下」語義上屬于協(xié)商緩存那一檔這個區(qū)別新手特別容易搞錯。5. 新手避坑五個最容易翻車的理解誤區(qū)學這塊內(nèi)容最怕的不是看不懂而是「以為自己看懂了」。下面五條是我見過的翻車率最高的每條都按「現(xiàn)象 → 原因 → 解決」寫對號入座看看有沒有中招。5.1 概念上的三個坑把「背過」當成「懂了」坑一回答三次握手只會背那一句話?，F(xiàn)象被問「為什么是三次不是兩次」張口就是「為了防止已失效的連接請求報文段突然又傳到服務端」面試官再問一句「那具體是怎么防的」就答不上來了。原因這句話是從別處抄來的結(jié)論中間的推理過程你并沒有走過。結(jié)論可以背推理不行。解決別背句子畫時序圖。拿張紙把客戶端和服務器畫成兩條豎線把三次報文各帶什么、每一步之后雙方分別確認了什么一格一格寫出來。寫完你會發(fā)現(xiàn)「為什么不是兩次」根本不用背因為它自己就浮出來了?？佣詾?HTTP/1.1 的管道化是默認開啟的。現(xiàn)象講 HTTP/1.1 優(yōu)化的時候信誓旦旦說「管道化讓請求可以連著發(fā)性能提升明顯」。原因看到「管道」兩個字想當然地認為瀏覽器都在用。解決記住兩個事實——它不是默認開啟的而且主流瀏覽器基本都沒支持。真正讓 HTTP/1.1 難受的是隊頭阻塞服務器必須按請求順序回前一個卡住了后面全得排隊。管道化只解決了「請求能不能連著發(fā)」沒解決「響應能不能亂序回」所以它沒能救場?？尤詾?HTTP/2 把隊頭阻塞徹底解決了。現(xiàn)象很流利地說出「HTTP/2 用多路復用解決了隊頭阻塞」然后被追問「那 HTTP/3 為什么還要換 UDP」就沉默了。原因只記住了「多路復用」這個詞沒記住 HTTP/2 底下跑的還是 TCP。解決把隊頭阻塞拆成兩層看。HTTP 層的隊頭阻塞HTTP/2 確實解決了靠的是 Stream一個連接里多個流各走各的誰先準備好誰先發(fā)接收端按 Stream ID 重新組裝。但 TCP 層的隊頭阻塞還在——TCP 是字節(jié)流協(xié)議它必須保證數(shù)據(jù)完整且連續(xù)前面丟了一個字節(jié)后面的數(shù)據(jù)只能在內(nèi)核緩沖區(qū)里等著。HTTP/3 之所以把下層換成基于 UDP 的方案就是為了繞開這一層。5.2 動手上的兩個坑只看結(jié)論不看過程坑四DNS 只背流程分不清遞歸和迭代。現(xiàn)象解析順序那八步背得挺順一問「遞歸查詢和迭代查詢有什么區(qū)別」就開始含糊其辭。原因兩個概念被合在一起記了沒有分清「誰在替誰跑腿」。解決站在本地 DNS 服務器的視角問自己一句這一趟是我自己跑完的還是我只拿到下一站地址客戶端把活整個托給本地 DNS 服務器那是遞歸本地 DNS 服務器每次只從上層拿到「下一站去哪兒」然后自己去問那是迭代。抓住「誰負責跑完全程」這一條兩個詞就再也不會混?？游甯牧司彺媾渲脜s怎么都看不到效果。現(xiàn)象在服務器上把Cache-Control改短了瀏覽器里刷新還是舊的懷疑自己改錯了地方。原因強緩存還沒過期瀏覽器壓根就沒發(fā)請求出去服務器那邊根本不知道你來過。解決三招任選——在 Network 面板勾上 Disable cache開一個無痕窗口測或者用 curl 帶上Cache-Control: no-cache強制走協(xié)商。另外記住一個順序改完配置先別急著懷疑代碼先確認「請求到底有沒有發(fā)出去」這一步能省掉一半的排查時間。注意這五條里最耗時間的是坑五。它不屬于知識沒學會而是觀測手段沒跟上。養(yǎng)成「先確認現(xiàn)象再猜原因」的習慣比多背十個知識點管用。6. 下一步學什么從網(wǎng)絡地基往上的四步走法把這一篇過完之后很多人會問同一個問題接下來該學什么。我的建議是別急著橫向鋪開去啃操作系統(tǒng)和數(shù)據(jù)庫先把網(wǎng)絡這條線夯實因為它是最容易驗證、也最容易在面試里立刻兌現(xiàn)的一塊。下面是一個可以參考的順序。順序?qū)W什么學到什么程度算過關(guān)1一次完整訪問流程合上資料能不看提示口述七個步驟2TCP 連接的建立與斷開能畫出三次握手和四次揮手說出每一步報文的作用3HTTP 與緩存能看懂響應頭里的緩存字段講清強緩存和協(xié)商緩存的區(qū)別4HTTP 版本演進與 DNS能說清每個版本解決了上一版的什么問題DNS 解析鏈路能講完整這四步里第一步和第二步最值錢。它們占了面試里這類問題的絕大多數(shù)也決定了你后面學東西時有沒有地方掛。第三步和第四步屬于加分項面試官問到你能答上來問不到你也不虧。方法上我給三個具體建議。第一個是合上資料復述每學完一塊合上電腦用大白話講一遍講卡殼的地方就是沒懂的地方回去補那一塊別從頭再看一遍。第二個是動手驗證凡是能用 curl 或者 F12 看到的就別只停留在看書前面那幾段命令多跑幾遍比讀十頁解釋都管用。第三個是建一張自己的圖不用畫得多好看就把七個步驟和對應的知識點畫在一張紙上學一點補一筆一個月后這張紙就是你的復習提綱。最后說個我自己的教訓。我第一次準備這塊內(nèi)容的時候把答案抄了滿滿幾頁合上本子覺得穩(wěn)了。結(jié)果被問了句「第一次握手丟包之后服務器會分配資源嗎」當場愣住。從那以后我每次學新知識點都強制走一遍「合上資料講給一個完全不懂的人聽」——講得下去才算會講不下去就說明還欠火候。這個習慣笨是笨了點但它救過我很多次。希望幫到你。本文還有配套的精品資源點擊獲取