Chaosnet 簡史

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

$ dig google.com

; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27120
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     194 IN  A   216.58.192.206

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 21 16:14:48 CDT 2018
;; 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 的回復。

$ dig -c HS google.com

; <<>> DiG 9.10.6 <<>> -c HS google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31517
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.            HS  A

;; Query time: 34 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Sep 25 14:48:10 CDT 2018
;; MSG SIZE rcvd: 39

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

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

在 MIT 的機房裡

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

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

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 通過了將 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 不是唯一一個能夠讓計算機們交流的協議。「萬維網」也遠遠不是我們這全球交流系統所能有的，最酷的名字。

1. LISP 1.5 Programmer』s Manual, The Computation Center and Research Laboratory of Electronics, 90, accessed September 30, 2018, http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf ↩
2. Lisp Machine Progress Report (Artificial Intelligence Memo 444), MIT Artificial Intelligence Laboratory, August, 1977, 3, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/5751/AIM-444.pdf. ↩
3. Lisp Machine Progress Report (Artificial Intelligence Memo 444), 4. ↩
4. 同上 ↩
5. Chaosnet (Artificial Intelligence Memo 628), MIT Artificial Intelligence Laboratory, June, 1981, 1, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/6353/AIM-628.pdf. ↩
6. 同上 ↩
7. Chaosnet (Artificial Intelligence Memo 628), 16. ↩
8. Chaosnet (Artificial Intelligence Memo 628), 9. ↩
9. Paul Mockapetris and Kevin Dunlap, 「The Design of the Domain Name System,」 Computer Communication Review 18, no. 4 (August 1988): 3, accessed September 30, 2018, http://www.cs.cornell.edu/people/egs/615/mockapetris.pdf. ↩
10. Chaosnet (Artificial Intelligence Memo 628), 1. ↩

via: https://twobithistory.org/2018/09/30/chaosnet.html

作者：Two-Bit History 選題：lujun9972 譯者：acyanbird 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive