Chaosnet 簡史 | Linux 中國

如果你輸入 dig 命令對 google.com 進行 DNS 查詢，你會得到如下答覆：

1. $ dig google.com
3. ; <<>> DiG 9.10.6 <<>> google.com
4. ;; global options: +cmd
5. ;; Got answer:
6. ;; ->>HEADER< opcode: QUERY, status: NOERROR, id: 27120
7. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
9. ;; OPT PSEUDOSECTION:
10. ; EDNS: version: 0, flags:; udp: 512
11. ;; QUESTION SECTION:
12. ;google.com. IN A
14. ;; ANSWER SECTION:
15. google.com. 194 IN A 216.58.192.206
17. ;; Query time: 23 msec
18. ;; SERVER: 8.8.8.8#53(8.8.8.8)
19. ;; WHEN: Fri Sep 21 16:14:48 CDT 2018
20. ;; MSG SIZE rcvd: 55

這個輸出一部分描述了你的問題（google.com 的 IP 地址是什麼？），另一部分則詳細描述了你收到的回答。在答案區段ANSWER SECTION裡，dig 為我們找到了一個包含五個欄位的記錄。從左數第四個欄位 A 定義了這個記錄的型別 —— 這是一個地址記錄。在 A 的右邊，第五個欄位告知我們 google.com 的 IP 地址是 216.58.192.206。第二個欄位，194 則代表這個記錄的快取時間是 194 秒。

那麼，IN 欄位告訴了我們什麼呢？令人尷尬的是，在很長的一段時間裡，我都認為這是一個介詞。那時候我認為 DNS 記錄大概是表達了“在 A 記錄裡，google.com 的 IP 地址是 216.58.192.206。”後來我才知道 IN 是 “internet” 的簡寫。IN 這一個部分告訴了我們這個記錄分屬的類別class。

那麼，除了 “internet” 之外，DNS 記錄還會有什麼別的類別嗎？這究竟意味著什麼？你怎麼去搜尋一個不位於 internet 上的地址？看起來 IN 是唯一一個可能有意義的值。而且的確，如果你嘗試去獲得除了 IN 之外的，關於 google.com 的記錄的話，DNS 伺服器通常不能給出恰當的回應。以下就是我們嘗試向 8.8.8.8（谷歌公共 DNS 伺服器）詢問在 HS 類別裡 google.com 的 IP 地址。我們得到了狀態為 SERVFAIL 的回覆。

1. $ dig -c HS google.com
3. ; <<>> DiG 9.10.6 <<>> -c HS google.com
4. ;; global options: +cmd
5. ;; Got answer:
6. ;; ->>HEADER< opcode: QUERY, status: SERVFAIL, id: 31517
7. ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
9. ;; OPT PSEUDOSECTION:
10. ; EDNS: version: 0, flags:; udp: 512
11. ;; QUESTION SECTION:
12. ;google.com. HS A
14. ;; Query time: 34 msec
15. ;; SERVER: 8.8.8.8#53(8.8.8.8)
16. ;; WHEN: Tue Sep 25 14:48:10 CDT 2018
17. ;; MSG SIZE rcvd: 39

所以說，除了 IN 以外的類別沒有得到廣泛支援，但它們的確是存在的。除了 IN 之外，DNS 記錄還有 HS（我們剛剛看到的）和 CH 這兩個類別。HS 類是為一個叫做 Hesiod[1] 的系統預留的，它可以利用 DNS 來儲存並讓使用者訪問一些文字資料。它通常在本地環境中作為 LDAP[2] 的替代品使用。而 CH 這個類別，則是為 Chaosnet 預留的。

如今，大家都在使用 TCP/IP 協議族。這兩種協議（TCP 及 UDP）是絕大部分電腦遠端連線採用的協議。不過我覺得，從網際網路的垃圾堆裡翻出了一個佈滿灰塵，絕跡已久，被人們遺忘的系統，也是一件令人愉悅的事情。那麼，Chaosnet 是什麼？為什麼它像恐龍一樣，走上了毀滅的道路呢？

在 MIT 的機房裡

Chaosnet 是在 1970 年代，由 MIT 人工智慧實驗室的研究員們研發的。它是一個宏偉標的的一部分 —— 設計並製造一個能比其他通用電腦更高效率執行 Lisp 程式碼的機器。

Lisp 是 MIT 教授 John McCarthy 的造物，他亦是人工智慧領域的先驅者。在 1960 年釋出的一篇論文[3]中，他首次描述了 Lisp 這個語言。在 1962 年，Lisp 的編譯器和直譯器誕生了。Lisp 引入了非常多的新特性，這些特性在現在看來是每一門程式語言不可或缺的一部分。它是第一門擁有垃圾回收器的語言，是第一個有 REPL（Read-eval-print-loop：互動式解析器）的語言，也是第一個支援動態型別的語言。在人工智慧領域工作的程式員們都十分喜愛這門語言，比如說，大名鼎鼎的 SHRDLU[4] 就是用它寫的。這個程式允許人們使用自然語言，向機器下達挪動玩具方塊這樣的命令。

Lisp 的缺點是它太慢了。跟其它語言相比，Lisp 需要使用兩倍的時間來執行相同的操作。因為 Lisp 在執行中仍會檢查變數型別，而不僅是編譯過程中。在 MIT 的 IBM 7090 上，它的垃圾回收器也需要長達一秒鐘的時間來執行。¹ 這個效能問題急需解決，因為 AI 研究者們試圖搭建類似 SHRDLU 的應用。他們需要程式與使用者進行實時互動。因此，在 1970 年代的晚期，MIT 人工智慧實驗室的研究員們決定去建造一個能更高效執行 Lisp 的機器來解決這個問題。這些“Lisp 機器”們擁有更大的儲存和更精簡的指令集，更加適合 Lisp。型別檢查由專門的電路完成，因此在 Lisp 執行速度的提升上達成了質的飛躍。跟那時流行的計算機系統不同，這些機器並不支援分時，整臺電腦的資源都用來執行一個單獨的 Lisp 程式。每一個使用者都會得到他自己單獨的 CPU。MIT 的 Lisp 機器小組Lisp Machine Group在一個備忘錄裡提到，這些功能是如何讓 Lisp 執行變得更簡單的：

Lisp 機器是個人電腦。這意味著處理器和主記憶體並不是分時復用的，每個人都能得到單獨屬於自己的處理器和記憶體。這個個人運算系統由許多處理器組成，每個處理器都有它們自己的記憶體和虛擬記憶體。當一個使用者登入時，他就會被分配一個處理器，在他的登入期間這個處理器是獨屬於他的。當他登出，這個處理器就會重新可用，等待被分配給下一個使用者。透過採取這種方法，當前使用者就不用和其他使用者競爭記憶體的使用，他經常使用的記憶體頁也能儲存在處理器核心裡，因此頁面換出的情況被顯著降低了。這個 Lisp 機器解決了分時 Lisp 機器的一個基本問題。²

這個 Lisp 機器跟我們認知的現代個人電腦有很大的不同。該小組原本希望今後使用者不用直接面對 Lisp 機器，而是面對終端。那些終端會與位於別處的 Lisp 機器進行連線。雖然每個使用者都有自己專屬的處理器，但那些處理器在工作時會發出很大的噪音，因此它們最好是位於機房，而不是放在本應安靜的辦公室裡。³ 這些處理器會透過一個“完全分散式控制”的高速本地網路共享訪問一個檔案系統和裝置，例如印表機。⁴ 這個網路的名字就是 Chaosnet。

Chaosnet 既是硬體標準也是軟體協議。它的硬體標準與乙太網類似，事實上 Chaosnet 軟體協議是執行在乙太網之上的。這個軟體協議在網路層和傳輸層之間互動，它並不像 TCP/IP，而總是控制著本地網路。Lisp 機器小組的一個成員 David Moon 寫的另一個備忘錄中提到，Chaosnet “目前並不打算為低速連結、高信噪連結、多路徑、長距離連結做特別的最佳化。” ⁵ 他們專註於打造一個在小型網路裡表現極佳的協議。

因為 Chaosnet 連線在 Lisp 處理器和檔案系統之間，所以速度十分重要。網路延遲會嚴重拖慢一些像開啟文字檔案這種簡單操作的速度，為了提高速度，Chaosnet 結合了在Network Control Program網路控製程式中使用的一些改進方法，隨後的 Arpanet 專案中也使用了這些方法。據 Moon 所說，“為了突破諸如在 Arpanet 中發現的速率瓶頸，很有必要採納新的設計。目前來看，瓶頸在於由多個連結分享控制連結，而且在下一個資訊傳送之前，我們需要知道本次資訊已經送達。” ⁶ Chaosnet 協議族的批次 ACK 包跟當今 TCP 的差不多，它減少了 1/3 到一半的需要傳輸的包的數量。

因為絕大多數 Lisp 機器使用較短的單線進行連線，所以 Chaosnet 可以使用較為簡單的路由演演算法。Moon 在 Chaosnet 路由方案中寫道“預計要適配的網路架構十分簡單，很少有多個路徑，而且每個節點之間的距離很短。所以我認為沒有必要進行複雜的方案設計。” ⁷ 因為 Chaosnet 採用的演演算法十分簡單，所以實現它也很容易。與之對比明顯，其實現程式據說只有 Arpanet 網路控製程式的一半。⁸

Chaosnet 的另一個特性是，它的地址只有 16 位，是 IPv4 地址的一半。所以這也意味著 Chaosnet 只能在區域網裡工作。Chaosnet 也不會去使用埠號；當一個行程試圖連線另一個機器上的另外一個行程時，需要首先初始化連線，獲取一個特定的標的“聯絡名稱contact name”。這個聯絡名稱一般是某個特定服務的名字。比方說，一個主機試圖使用 TELNET 作為聯絡名稱，連線另一個主機。我認為它的工作方式在實踐中有點類似於 TCP，因為有些非常著名的服務也會擁有聯絡名稱，比如執行在 80 埠上的 HTTP 服務。

在 1986 年，RFC 973[5] 透過了將 Chaosnet DNS 類別加入域名解析系統的決議。它替代了一個早先出現的類別 CSNET。CSNET 是為了支援一個名叫電腦科學網路Computer Science Network而被製造出來的協議。我並不知道為什麼 Chaosnet 能被域名解析系統另眼相待。很多別的協議族也有資格加入 DNS，但是卻被忽略了。比如 DNS 的主要架構師之一 Paul Mockapetris 提到說在他原本的構想裡，施樂Xerox的網路協議應該被包括在 DNS 裡。⁹ 但是它並沒有被加入。Chaosnet 被加入的原因大概是因為 Arpanet 專案和網際網路的早期工作，有很多都在麻省劍橋的博爾特·貝拉尼克—紐曼公司，他們的僱員和 MIT 大多有緊密的聯絡。在這一小撮致力於發展計算機網路人中，Chaosnet 這個協議應該較為有名。

Chaosnet 隨著 Lisp 機器的衰落漸漸變得不那麼流行。儘管在一小段時間內 Lisp 機器有實際的商業產品 —— Symbolics 和 Lisp Machines Inc 在 80 年代售賣了這些機器。但它們很快被更便宜的微型計算機替代。這些計算機沒有特殊製造的迴路，但也可以快速執行 Lisp。Chaosnet 被製造出來的目的之一是解決一些 Apernet 協議的原始設計缺陷，但現在 TCP/IP 協議族同樣能夠解決這些問題了。

殼中幽靈

非常不幸的是，在網際網路中留存的關於 Chaosnet 的資料不多。RFC 675 —— TCP/IP 的初稿於 1974 年釋出，而 Chasnet 於 1975 年開始開發。¹⁰ 但 TCP/IP 最終征服了整個網際網路世界，Chaosnet 則被宣佈技術性死亡。儘管 Chaosnet 有可能影響了接下來 TCP/IP 的發展，可我並沒有找到能夠支援這個猜測的證據。

唯一一個可見的 Chaosnet 殘留就是 DNS 的 CH 類。這個事實讓我著迷。CH 類別是那被遺忘的幽魂 —— 在 TCP/IP 廣泛部署中存在的一個替代協議 Chaosnet 的最後棲身之地。至少對於我來說，這件事情是十分讓人激動。它告訴我關於 Chaosnet 的最後一絲痕跡，仍然藏在我們日常使用的網路基礎架構之中。DNS 的 CH 類別是有趣的數碼考古學遺跡。但它同時也是活生生的標識，提醒著我們網際網路並非天生完整成型的，TCP/IP 不是唯一一個能夠讓計算機們交流的協議。“全球資訊網”也遠遠不是我們這全球交流系統所能有的，最酷的名字。