聲明：本文不是官方文檔，亦不是某種形式的斷言或結論，本文僅僅是技術討論性質的文章，無論是否用了確定性的語氣，作者都不保證內容的準確性和完整性，亦不明示或暗示此文章不是在胡說八道。（事實上，作者過去常常胡說八道並樂此不彼）。因此，所有因採用本文章涉及的方法、數據或其他任何信息，所造成的直接或間接損害，包括但不限於生命和財產損失，作者、撰寫團隊和平台概不負責。
這一篇本來是想講幾何光學，因為我們的校準參數，還留了一個尾巴。
幾何光學就是個怪物，複雜到令人絕望，幸好這兩個參數用初中數學就可以說得通，不過我遇到的問題是畫圖，我既沒有 Zemax，也沒有 LightTools 這種天價軟體（有我也不會用），只能手繪。
汽車之心從老闆到員工，他們的大腦前額葉皮質，仿佛都被睪酮溶液浸泡過，工作起來沒日沒夜，他們昨天深夜打電話警告我，我的文章必須按時交，否則我就看不到明天的太陽了。
驚恐之下，我臨時決定，把畫了一半的光路圖放一放，暫時換個主題，一個更加糟糕的主題：無人車的乙太網絡交換問題。
睪酮結構式
睪酮分泌豐富的人，比如汽車之心的 CEO，他大概長這個樣子。
睪酮分泌不足的人，比如其他公司的男 CEO 們，他們大概長這個樣子。
你是說肌肉？No，No，No，睪酮跟肌肉一點關係都沒有，我是說頭髮，睪酮只會讓人掉頭髮。
當前在無人駕駛汽車上：
二層基於乙太網接口承載的傳感器並不多，除了汽車上本來就有的傳感器，後裝的要麼是 CAN 口，要麼是 USB 或者 232，485，UART 等串口，只有大帶寬的需求時，比如工控機、4/5G 模塊，監控系統，它們的通訊一般使用商用乙太網口。
三層掛在 IP 上的通訊接口就更少了。
當然還有其他很多莫名其妙的接口。看著這些七國八制，五光十色的接口，你常常會懷疑，無人駕駛系統的真正商用，真的能在 150 年內實現麼？
主機廠們都有一個遠大的抱負，面對未來智能汽車，就是把車內能統一的東西，都統一到車載乙太網上去，至少雷射雷達、攝像頭等大流量的玩意應該這樣。
車載乙太網真的是好處多多，實時性秒殺讓人提心弔膽的商用乙太網，CSMA/CD 光聽名字就覺得不靠譜。
而且，車載乙太網有優秀的 EMC，還帶全局時鐘同步這些特技，要是所有的重要傳感器和計算平台，都能使用車載乙太網進行統一交換，那真是太完美了……
不過要我說，回到現實吧，親們～摸摸你們手裡能買到的雷射雷達，攝像頭，工控機，或者毫米波，不管哪個牌子的，告訴我，車載乙太網，你在哪裡啊？
現實總是很殘酷的，你的無人車下個月就要參展了，到頭來，它的高帶寬通訊部分，大機率還得用這些上古時期的玩意：
上圖布線真的很整潔美觀，不是麼？
所以，當我在一輛無人車裡，發現一台 H3C 或者 Cisco 的交換機，或者發現有人用博通的晶片，焊一個綜合網關的板子連接一堆傳感器，並對外自豪的宣稱，這是他們自主研發的，擁有完全智慧財產權的「核心*GW」，我的內心充滿了尊敬，這是一群多麼務實的理想主義者啊！
但是，既然是商用乙太網，你就繞不開三大傳統網絡困境「延抖丟」：
延時（delay）、 抖動（jitter）和丟包（packet loss），一旦延抖丟，再高級的算法，再牛*的傳感器，統統會抓瞎。
所以本文的主旨，圍繞著這三個問題展開。
這個延抖丟的效果真是相當的感人。
車上的環境，跟普通商用乙太網截然不同，商用乙太網那一套，很多並不適用車上，基於此，我們略加提煉，得到如下幾個使用原則：
1、使用優秀的，經過歷史檢驗的商用硬體：
商用乙太網非常成熟，所以，對於交換機而言，請購買商用的穩定型號，如 Cisco，H3C，Huawei 之類，請立刻忽略你們家裡用的那種路由器。
商用的一般長這樣：
家用的一般長這樣：
家用的路由器，顯然是鎮不住這輛車的：
2、No Broadcast，Some Multicast, Always Unicast
有些傳感器，會把自己的目標地址定義為四個 255，這是一個典型的廣播地址，任何時候，都不要廣播。
因為乙太網交換機工作在二層，它有個非常糟糕的特性，就是不隔離廣播，收到廣播包後，直接對全網所有埠泛洪。
其他傳感器，如果也連接到這個交換機上，這個傳感器就杯具了，它稚嫩的小網卡多半會掛掉。因為接收了太多本不屬於它自己的東西。
還需要注意的一點就是，廣播分二層廣播和三層廣播，一般情況下，修改廣播至組播或單播，只需要改三層 IP 即可。
但是，傳感器畢竟不是電腦，有的改了 IP，二層依然改不掉，這就變成了一個尷尬的假單播。
這真的很尷尬，究其原因，可能是傳感器廠家的 FPGA 在實現乙太網絡功能時，並未按照 ITU-T 的 RFC 嚴格定義。
所以，它依然會衝掉其他傳感器。
這個問題的解決，要依賴網絡交換機的廣播隔離，但是二層交換機廣播可以隔離麼？
當然不可以。
所以，你整個網絡，要提到三層去，方法多種多樣，做 VLAN 或者起單臂路由。所以你一看到廣播，想都不想，直接斃掉；
組播是一個部分廣播的情形，配置相對也比較複雜，總的來說它適用於多個接收者，而單播，適合一個接收者。
大部分情況下，我們都推薦使用單播，這使得帶寬占用最小。
但有人會在整個無人車感知系統上，再掛一個監控組件，這就要求傳感器發出的消息，需要 2 個以上的接收者同時接收，如果不讓用廣播，那麼，組播就是唯一的選擇。
組播一般的交換機都有默認配置，如果你只有一套組播流量，那無需配置，即插即用。
但多個組播流量，那可能也需要進行配置，無人車應用相對還是比較簡單，但可能需要對 Ubuntu 的內核中統一組管理協議（IGMP）版本，這裡就不展開了。
另外，無人車常常還需要安裝一個 4/5G 網關或者 WiFi 熱點，用於對外界的通訊，最通常的做法，是工控機另外安裝網卡，單獨處理這個通道的數據。
然而，也有一部分人直接復用交換網絡，這真是個糟糕的主意。
不用廣播，用單播，這就可以了麼？
差得遠呢，你還得有個重要的思想，這個思想必須貫穿始終，這就是 QoS。
3、不要偷懶，儘量部署 QoS
商用乙太網為什麼在無人車上感覺很挫？
就是因為它的哲學——「盡力而為」，絕大多數流量都是發出去就行，愛誰誰。
為了保證可靠性，不得以在四層搞了一個重傳機制（TCP），收不到，就反覆要求重傳，但這樣可靠性上去了，實時性又降下來了。
傳感器但凡使用乙太網，為了保證實時性，數據傳輸就絕無可能使用 TCP，一定要用面向無連接的 UDP，這時，數據是否可靠，整個網絡是否有擁塞等「延抖丟」問題，一定不在傳感器廠商的考慮之列，這些，就需要無人車自身的網絡軟硬體加以保證。
提升交換和傳輸質量的一個最重要的方法，就是部署 QoS。QoS 在各個交換設備上設置都不太一樣，實現的子功能也很複雜，好在無人車的網絡很簡單，我們可以用到如下幾個簡單功能：
（1）通信速率管理。
對於非重要節點發來的異常流量進行整形和丟棄，防止其對重要流量產生衝擊，比如，永遠限制監控系統的輸出流量至一合理水平；
（2）資源分配。
改變「盡力而為」的 FIFO 粗糙機制，改成各種隊列（Queue），隊列的種類千奇百怪，根據不同的流量，進入不同的隊列，最簡單的隊列機制是 PQ（Priority Queue），我們可以把重要傳感器，如雷射雷達的數據，調度進最高優先級隊列，無論網絡是否擁塞，雷射雷達的數據，總是優先轉發。
（3）擁塞避免和分組丟棄策略。
在各個 Queue 中，如果丟棄擁塞的數據包，比如隨機尾丟棄之類；
剛開始，你的 QoS 也許布置的不太好，這個是個反覆磨合的過程，常常有經驗因素在裡面，部署 QoS 需要反覆調試，最終會接近一個比較理想的狀態。
4、Socket 寫法有講究
在工控機上，socket 存在大量參數，要根據發送端和自身條件進行調整，延抖丟有可能發生在接收系統上，而且常常是因為 Socket 寫得不規範造成的。
在上層看，你會以為是傳感器質量不好。
比如接收數據前的輪詢，防止接收端卡死的小技巧：
比如 buf 的大小等，buf 需要根據自身的設備情況進行平衡選擇，但是如果選擇太小，則在作業系統上層繁忙時，buf 可能被填滿，進而導致丟包發生。
關於 Socket，沒有什麼書，比這套聖經更管用了：
此書分卷一卷二卷三，作者 W.Richard Stevens，一個生於尚比亞，成長於南非的白人。生的神秘，死得更神秘的一位大神。你要的答案，就在裡面。
對了，如果你希望更多了解 QoS，這本書也值得一讀，當然，你需要知道如何操控一般商用乙太網的路由交換設備。
是的，「得救之道, 就在其中」(Salvation lies within)。