為什麼我們稱它為「接合」（splice）
通過代理程式的每一條 TLS 連線，都是一次「接合」（splice）。這是我們試的第三個名字。在 splice 之前是 bridge，再之前是 split—而 git 歷史仍記得我們切換的那一刻，以及那些被我們丟棄的名字所留下的化石。為它命名花了三次嘗試，因為這個東西實在不尋常，而前兩個詞各對它說了一個小謊。
那個需要被命名的東西
當代理程式坐在一條 TLS 路徑上時，它做的事情是大多數網路設備不做的。它不是一個轉送位元組的 proxy，也不是一個透明的轉發器。它跑兩次獨立的 TLS 交握—一次與客戶端、一次與上游—並把它們接合成單一條邏輯流，同時在中間轉換密碼學（譬如把一個傳統客戶端升級到與伺服器之間的後量子交握）。兩端各自看到的，都是一次完整、有效的交握。它的運作機制本身是另一個故事；這一篇談的是該怎麼稱呼它。
split—第一個名字，錯在兩個地方
最早的白板名字，而它從未進入任何一次提交。它指錯了方向：你是把兩條連線接成一條，不是把一條切成兩條。而且這個詞早已在別處忙著—在封包層，我們確實會切分東西，因為一個後量子 ClientHello 會被切分到多個 TCP 區段，而且還有一整套測試在跑那條路徑。把 split 拿來指這個工作階段，會與一個真實、獨立的概念相撞。它很快就被沖掉了。
bridge—更接近了，但太被動
第二個名字，也是 git 真正記錄到的第一個：它出現在那次接好網路層的提交裡。bridge 的方向是對的—橋接會把兩端接起來。但它太被動了。網路上的 bridge 原封不動地轉發訊框；橋接這個詞暗示中間那個東西是透明的，對穿過它的東西什麼也不做。我們的東西恰恰相反：它存在的全部理由，就是在中間改變密碼學。bridge 悄悄地低估了最重要的那一部分。
splice—第三個名字，以及它為何留了下來
不久之後，工作階段類別被命名為 Splice_session，這個詞也上了首頁。splice 來自繩索與纜線的工藝：你把兩條線各自解開股繩、再互相編織起來，好讓那個接點承載全部的負載—與繩索本身一樣強韌，且沒有一個臃腫的繩結。這正是我們需要一個詞去捕捉的特性：不是一個栓進中間的轉送器（一個繩結），而是一個接合—每一端都仍是一條結構完整、全強度的 TLS 連線。而接合不只是接起來—你還能把新材料接進去。電影的接片剪入一格新的畫格；基因的接合插入一段新的編碼。那正是 bridge 缺少的「轉換」。接起來、無縫、全強度，還能轉換—全在一個詞裡。
那些化石
被捨棄的名字並沒有完全死去。這棵樹是沉積層，你仍能把它們挖出來—那些被丟棄的名字仍活在程式碼裡，各自做著它真正的工作。bridge 以「AEAD bridge」之名，存活在跨版本的那個情境裡—那是「轉發、外加一個小改動」這個比喻唯一真正貼合的地方。而 split 拿到了它一直最適合的工作：把 ClientHello 切分到各區段。每個詞最終都找到了它正確的意義。splice 只是得先把工作階段的名字搶下來。
命名是理解一個東西的一部分—在你知道它的本質之前，你不會有那個對的詞，而那些錯的詞，是以富有啟發的方式錯著。splice 之所以勝出，是因為它是唯一同時道出「接起來、無縫、全強度、能轉換」的那一個。那個「轉換」為什麼重要，是後量子遷移的事；而它，是我們賴以為生的工作。
← 所有文章