<em>你好,我是 Maneshwar,我正在打造 LiveReview——一個具備爆炸半徑感知的 AI 程式碼審查工具,專為你的關鍵業務系統而設計。歡迎 幫我們按星,讓更多開發者發現這個專案,並試用後分享你的回饋,幫助我們持續改進產品。</em>
你打開一支影片,大約一秒後它就開始播放。
在你的拇指與第一個畫面之間,請求可能穿越了大約十五家不同公司的設備,還可能跨越了整個海洋,最後再回來。沒有人協調這件事。
這正是我覺得網際網路真正奇怪的地方,而大多數解釋都會跳過這一段。
它們會告訴你,網際網路是「一個全球性的網路之網路」,這句話雖然沒錯,但其實什麼也沒說。所以我們來真的拆開看。
先理解一件最有用的事:網際網路不是任何人單獨建造出來的一個東西。
它大致上是 75,000 個彼此獨立的網路,大家約定好如何互相轉送流量。
你的 ISP 是一個。你的大學是一個。Cloudflare 也是一個。
它們擁有自己的電纜和路由器,對任何特定物件都不負責,並且自願彼此互連。
一旦你從這個角度去看,網際網路上所有奇怪的事情就開始說得通了。
整個架構大致分成三個部分:

邊緣是所有真正想表達些什麼的東西。你的手機、筆電、機櫃裡的伺服器,甚至越來越常見的門鈴。
這些稱為 主機(hosts)或 終端系統(end systems),大致可分成提出請求的客戶端,以及回應請求的伺服器。
存取網路是你的上網入口。家裡的光纖或有線網路、辦公室網路、你口袋裡的 5G。
它唯一的工作,就是把你送到第一台路由器。
而且它幾乎總是整段旅程中最慢的一部分,所以下次你抱怨某個網站很慢時,這點值得記住。
核心就是中間那張網狀結構。
路由器以及它們之間的連線,除此之外沒有別的。
沒有控制室,沒有總伺服器,也沒有哪家公司擁有它。
這裡就是設計變巧妙的地方。
在網際網路出現之前,連接兩個東西意味著建立一條電路。
打電話時,網路會替你保留一條從頭到尾的實體路徑,整通電話期間都專屬於你,不管你是在說話還是在沉默。
網際網路把這種方式丟掉了。你的資料會被切成封包,每個封包都標上來源和目的地,然後把它丟進網路裡,讓它自己想辦法走完。

第三個封包可能經由法蘭克福,第四個封包則經由阿姆斯特丹。它們可能亂序抵達。有些甚至可能根本沒到。
這聽起來比保留一條線路還糟,對單次對話來說某種程度上確實如此。但你換來的是非常巨大的好處:
重新組裝、重試、把東西排回正確順序,這些都發生在兩端。
中間那段保持著令人愉快的「笨」。這個原則有個名字,叫做 端到端原則,而且可以說正是它讓網際網路能夠以今天這種方式成長。
那麼,一坨位元組要怎麼知道該往哪裡去?
它會被包裝起來,包四次。

你的瀏覽器會在應用層發出請求。像 HTTP,或是郵件用的 SMTP,或是查詢用的 DNS。
傳輸層會替它加上埠號與序號。
如果你要可靠且有順序,就用 TCP;如果你想要速度快、願意接受部分遺失,就用 UDP。
網路層再把 IP 位址包上去。
來源與目的地,就像郵寄地址一樣。
鏈結層則再包上一層,也就是下一跳裝置的硬體位址,通常就是幾公尺外的路由器。
到了另一端,每一層都會拆掉自己的信封,然後把剩下的內容往上交。這就是往下傳時的封裝,往上傳時的解封裝。
為什麼這很重要,而不只是冷知識?因為:每一層只知道它下面那一層。 下載到一半時,從 Wi‑Fi 換到乙太網路,只有最底層的信封會變。TCP 根本不會注意到。
你的瀏覽器當然更不會注意。你可以把整整一代的實體網路技術換掉,而完全不用改任何一行應用程式碼;這正是世界從光纖轉向 5G 時發生的事。
你可以自己看到這些信封:
# 從你到某個主機之間的每一台路由器,每行一台
traceroute -q1 dev.to

# 或即時觀察單一請求如何被包起來
sudo tcpdump -n -i any -c 5 'host dev.to and port 443'

traceroute 更有趣一些。每一行都是真實存在的機器、真實存在的建築、真實存在的公司所擁有,而它們同意幫你的封包接力轉送。
這兩個詞常常被混著用,連那些本來應該知道的人也是。它們其實是完全不同的工作。

轉送是本地而且快速的。封包到達路由器後,路由器查看目的地位址,查 forwarding table 裡最長前綴相符的專案,然後把它從正確的埠口送出去。就這樣。這是在專用硬體裡以奈秒級完成、每秒數百萬次的工作。路由器完全不知道整段旅程的其他部分,也不在乎。
路由則是全域而且緩慢的。它是先建立那些表格的過程,意思是地球上的每個網路都持續向鄰居告訴自己能到達哪些地方。
一個是在看地圖。另一個是在爭論地圖應該怎麼畫。
各個網路會透過 邊界閘道協定(Border Gateway Protocol, BGP)來宣告自己的可達性。
你的 ISP 會說:「這些位址可以經由我到達」,它的鄰居再把這件事傳出去,幾分鐘內全世界就都更新了。

接下來這段你應該會稍微警覺一下。
BGP 沒有內建機制去驗證某個宣告是真是假。
它是一個建立在「網路營運商誠實且專業」這個假設上的協定。
如果某個網路宣告了它根本不擁有的位址空間,而它的鄰居又相信了,那麼全世界原本要送往那些位址的流量,就會開始流向錯的地方。
這不是假設性的。2008 年,Pakistan Telecom 想在國內封鎖 YouTube,卻不小心把 YouTube 的位址範圍宣告給上游供應商,結果讓全球大部分地區的 YouTube 離線大約兩小時。
2018 年,類似的劫持也被用來竊取加密貨幣,方法是把流量重新導向到 DNS 服務。
像 RPKI 這類的努力,正逐步加入密碼學驗證,讓網路能證明自己確實擁有它所宣告的內容。
目前採用率仍然不完整,而 isbgpsafeyet.com 可以告訴你你自己的 ISP 有沒有認真做這件事。
還有一件事常讓人意外:路由其實不太是在找最快的路徑。
BGP 大多是依照商業關係來挑路徑,因為承載流量是要花錢的,而網路通常偏好那些能收錢的路由,而不是自己要付錢的路由。
你的封包走的不是最短的路,而是某個人同意、而且成本最低的那條路。

把整件事放到一次請求裡來看。
flowchart TD
A[你按下 Enter] --> B{快取裡有位址嗎?}
B -->|有| IP[手上已有 IP 位址]
B -->|沒有| DNS[向 DNS 解析器詢問]
DNS --> ROOT[根節點,接著 .com,再來是網域]
ROOT --> IP
IP --> TCP[TCP 三向交握:SYN、SYN-ACK、ACK]
TCP --> TLS{使用 HTTPS 嗎?}
TLS -->|是| HS[TLS 握手,協商金鑰]
TLS -->|否| REQ
HS --> REQ[送出 HTTP 請求]
REQ --> HOP[封包逐跳經過路由器]
HOP --> SRV[伺服器回應]
SRV --> PAINT[瀏覽器繪製頁面]
值得注意的是,前置作業佔了多大一部分。真正頁面的第一個位元組還沒開始傳之前,你已經做了名稱查詢、三向交握,通常還會再加上一輪 TLS 協商。
這就是為什麼對一般瀏覽來說,延遲比頻寬痛得多。管道變粗,並不會讓往返時間變短,而在任何內容出現之前,你就已經付出了好幾趟往返時間。
升級你的連線速度,對於伺服器遠在天邊的網站,幾乎沒有幫助。

還有最後一件事值得內化,因為它解釋了很多架構上的決策。
在光纖中,光的傳播速度大約是真空中光速的三分之二。倫敦到紐約大約是 5,500 公里。
如果電纜能完美筆直,那麼單程大約需要 28 毫秒,但實際上不可能,所以可以抓 35 到 40 毫秒。
單一次 HTTPS 請求,在第一個位元組回來之前,通常需要好幾次往返。
在任何事情發生之前,你看到的延遲大概是 150 毫秒上下,而且再多錢也改不了這個數字,因為這是物理問題,不是工程問題。
這就是 CDN 存在的全部理由。你無法讓封包更快,那就把內容放得更近。
你聽過的每一種「邊緣運算」提案,本質上都是在繞過光速這個限制。

它不是那些電纜。那些只是玻璃。
它也不是網頁本身;網頁只是跑在上面的一種應用,而且是晚了二十年才加入這場派對的那一個。
網際網路是一種協議。
它是一套協定,讓數以萬計彼此獨立、互不完全信任的網路,能在不需要任何授權、契約,甚至連一通電話都不用打的情況下,把封包互相轉交。
它之所以能運作,是因為中間層保持足夠「笨」,而邊緣層則被允許變得更聰明。
這是 1970 年代由一群不可能想像到視訊通話的人所做出的設計決策,而它撐住了。
<em>
你團隊的注意力是有限的,而 AI 生成程式碼的洪流,正讓我們更難在不拖慢速度的情況下,確保正式環境的程式碼安全。
我正在打造 <strong>LiveReview</strong>,一個具備爆炸半徑感知的 AI 程式碼審查工具,專為你的關鍵業務系統設計。
<strong>LiveReview 不會把每個 diff 都用同樣的權重看待,而是根據爆炸半徑——也就是變更對呼叫圖影響能擴散多遠——來為每個變更打分,讓你把注意力集中在真正重要的地方。</strong>
把程式碼審查的心力花在業務風險最高的地方,而不是平均分散到每一個 diff。
<b>在你的程式碼庫上試試 LiveReview:</b>
</em>
<a href="https://hexmos.com/livereview"><img src="https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/vls0pq7nymbrll98je6s.png" alt="LiveReview Banner" /></a>
原文出處:https://dev.to/lovestaco/how-the-internet-actually-works-and-why-nobody-is-in-charge-of-it-3im8