文字與二進位協定（text vs. binary protocols）
當兩支程式交換訊息時，設計者必須選擇這些訊息在線路上長什麼樣。一個選項是把它們做成人類可讀的文字——一行行你能印出來閱讀的字母與數字，像「GET /index.html」或「MAIL FROM:<[email protected]>」。另一個是二進位協定，其中訊息是緊湊的原始位元組序列，帶著固定寬度的欄位與數字碼，肉眼看毫無意義，對機器卻意義重大。這個「文字對二進位」的抉擇貫穿了幾乎每一個曾被設計出來的協定。
文字協定（HTTP/1.1、SMTP、傳統 FTP）對除錯與學習極為友善：你能用肉眼讀那段對話、親手打命令來測試一台伺服器、不靠特殊工具就檢視一份擷取紀錄。代價是效率——文字很冗長。數字 1000000 當文字要七個字元，當二進位整數卻只佔四個位元組；剖析文字（找換行、把數字字元轉成數值）也耗 CPU。二進位協定（HTTP/2、許多資料庫與遊戲協定）反轉了這個取捨：它們緊湊、剖析快，因為欄位在已知的偏移量、已有已知的大小，但你沒有解碼器就讀不懂，而單一個位置擺錯的位元組，診斷起來可能困惑得多。
現代協定設計的趨勢，是隨系統成熟與擴展，從文字走向二進位。HTTP 起初純為文字，後來 HTTP/2 把完全相同的方法與標頭，重新框成一種緊湊的二進位編碼以求速度與壓縮——保留 HTTP 文字時代的語意，卻把它打包成二進位。誠實的結論是：文字不天真，二進位也不總是更優。文字在「給人看、要易於互通」的協定上勝出；二進位在「頻寬、延遲與剖析成本當道」之處勝出。好的設計者依協定必須服務的對象與用途來選，而且也有中間地帶，例如 JSON（文字、有結構）與 Protocol Buffers（緊湊的二進位、以結構描述定義）。
要除錯一個郵件問題，你可以真的在終端機裡親手打 SMTP、並讀每一句回覆，因為它是文字。你對 HTTP/2 辦不到：它的編碼是二進位，所以你需要像 Wireshark 這樣的工具把位元組解碼成可讀的東西——這是 HTTP/2 為了緊湊與快速所付的代價。
文字：人類可讀、易除錯、冗長。二進位：緊湊、剖析快、沒有解碼器就看不懂。
文字協定並不自動就更簡單或更安全——文字剖析有它自己的陷阱（注入、空白歧義、編碼臭蟲）。二進位也不自動就端對端更快；在一條快速連結上，瓶頸可能根本在別處。