高頻交易軟硬件是怎么架構的
首先，高頻交易不一定是套利算法。事實上HFT做的最多的業務是做市（market making），可以是把商品從一個交易所倒賣到另一個交易所，也可以是在同一個交易所內部提供某種商品的流動性。這兩種方式的共同點都是讓人們可以特定 地點買到本來買不到的商品，所以本身就是有價值的，收服務費就可以盈利。
二，延遲和流量是不同的概念。低延遲不等于高數據量，事實上大部分時間交易數據流量并不大，一個market一天最多也就幾個GB。但HFT系統需 要在流量高峰時也能快速響應，所以更看重延遲。這也是HFT系統和互聯網系統最大的區別所在，HFT系統的精髓在于把單機的軟硬件系統的性能發揮到極致， 而不是像互聯網那樣強調高負載和延展性，動輒用幾千臺機器搭集群的做法在這里是不適用的。用互聯網系統的性能指標來認知HFT系統也是沒有意義的，像淘寶 這樣的應用需要保證交易的正確和一致性，包括從終端用戶的瀏覽器到淘寶后臺到銀行接口之間一系列復雜的事務性數據操作，這個場景和HFT直接對接交易所走 高速線路收發交易指令有天壤之別，不能用同樣的思維去理解。
三，一個HFT業務包括從主機到交易所的整條通信線路，在這條線路上有很多段不同的延遲，是需要分開討論的。如果是做跨交易所的交易，首先需要考慮 的是兩個交易所之間的網絡延遲。當數據通過網絡到達主機的時候，有一個最基本的tick-to-trade延遲，是指主機接收到數據到做出響應所需的時 間。但這個東西的測量很有技術含量，根據不同的測量方式，它可能包括或不包括網卡及網絡棧的處理時間。所以拿到一個HFT系統的延遲數據時，首先要搞清楚 它指的是什么，然后再來討論。
題主提到從一個直連計算節點的router的角度來觀測，這是一個理論上看起來可行但實際仍然很模糊的概念，因為一般router本身是不做存儲和 處理的，一個router會收發大量不同的數據，要理解一個接收到的包是對之前發出去的某個包的“回應”，是需要相當的處理邏輯的，一般很難這樣測。比較 合理的測試仍然是在主機端做記錄，測試從收到市場數據（tick）的TCP/UDP包到發送交易指令（trade）包的時差。目前（2014）的情況是， 這個延遲如果平均控制在個位數字微秒級就是頂級了。因為網絡傳輸才是延遲的大頭，如果網絡上的平均延遲是1毫秒（1000微秒）以上，你的單機延遲是2微 秒還是20微秒其實是沒有區別的。一般單機比網絡低一個數量級就可以了，比如網絡上需要100微秒（很現實的數字），單機控制在10微秒足以保證速度上沒 有劣勢。至于公眾報道，有時是為搏人眼球，難免有夸大的成分，不必太當真。
接下來說說做為一名從業者，我對各個層面的理解
首先網絡架設上光纖肯定是最差的方案。國外幾個主要的交易所（同一洲內）之間基本上都有微波（microwave/milliwave）線路，比光 纖的延遲要低很多，延遲敏感的應用一定要選擇這種線路。這個差距首先受制于光在光纖中的傳播速度只有在空氣中的2/3左右，另外在大城市建筑密集地區（也 正是一般交易所的所在地），光纖的復雜布線會進一步增大延遲，差距可能增至2到3倍。要想對此有一個具象的概念，只要看Quincy Data的這張線路圖：
但微波技術有兩個主要的缺點，第一是微波在空氣里傳播受天氣影響很大，刮風下雨都會導致通信受損，有時直接故障，所以需要備用的光纖線路，以及監控 天氣…… 這方面進一步的發展可能是激光技術；第二是帶寬太小，如果是跨交易所的業務，不可能通過微波來轉移大流量的市場數據，只能用來收發下單指令，這方面有一些 潛在發展空間，比如可以做一點有損壓縮，傳一個縮減版的市場數據，也能起到加快信息傳遞作用。這塊網絡服務本身就是一個獨立的業務了，一般所說的 colocation也是由服務商負責的，HFT主要需要的是選擇適合自己的服務商。
網絡線路確定以后，數據就送到了HFT主機。這時候需要決定網卡的方案，專用的網卡除了自身硬件的設計外，一定需要的是切換掉系統自帶的 kernel space TCP/IP stack，避免昂貴的context switching。網絡棧上的I/O延遲，收包發包加起來做到2～3微秒是可以的。這個層面上FPGA是很有應用價值的，因為可以做一些額外的邏輯處 理，進一步解放CPU。
對于FPGA，業務邏輯燒到硬件里的開發，調試成本和周期都是很難承受的，不看好做為長期發展的路線，這個東西其實和套利，數學模型一樣是賺外行眼 球的東西。但做專用的網絡I/O設備卻是比較有優勢的。（這里可以另舉一個例子以供思考FPGA的特點和適用性，目前很多主流交易所的技術架構上，為了適 應高速交易的需要，市場數據是采取UDP雙通道的方式發放的，即同一份數據發到兩個UDP broadcast channel上。客戶端需要自行收發排序，大家可以思考一下這種數據要如何編程才能高效穩定的處理，開發過程需要如何調試測試，如果數據協議發生變化要 如何處理？FPGA在這種場景中又該如何應用？這當然是開放問題，但是應該有助于理解真實的需求。）
網絡部分的問題解決以后，最后就是核心的業務邏輯的處理。這部分也許會用到一些數學建模，但是沒有什么神話，不是什么菲爾茲獎得主才能搞的東西（那 些人的用武之地更多是去投行那邊做衍生品，那才是真正需要高等數學的東西）。很多時候核心的還是延遲，這個在計算機內部分兩個部分，一是core的使用 率，比如irq balance，cpuisol，affinity等，主要是要盡可能的獨占core；另一個是cache invalidation，從L1/L2/L3 cache到TLB，page fault，memory locality之類都要仔細考慮，這個更多考驗的是對體系結構的理解和程序設計的功力，跟語言的關系不大。
具體選擇那種語言，首先是取決于公司的技術積累和市場上的技術人員供給。函數式語言（erlang/ocaml等）的好處是語言表達能力強，開發速 度快，邏輯不容易出錯，但相對的對機器底層的控制差一些，有時候他們的編譯器或運行時干了什么不太容易搞清楚，所以在性能上的調優會比在C++之類投入更 多一點，這里面有一個取舍問題，要根據公司情況來具體分析。
業務邏輯部分其實相當簡單。做這種高速交易肯定不會有什么凸優化，解微分方程之類復雜的運算。核心的部分一般就是加加減減，比比大小什么的。業務邏輯本身的處理完全可以做到納秒級，如果看到有人宣稱他們的延遲是納秒級，一般是指這種。
操作系統同樣是一個不需要神話的東西，普通的linux已經有足夠的空間用來做性能優化。簡單說，一個企業級的linux（如redhat）加上通用的架構（intel主流處理器）足以做到市面上已知的最低延遲，不必幻想有什么奇妙的軟硬件可以做到超出想像的事情。
另外需要提醒大家注意的是，其實做一個低延遲系統，首先需要考慮的不一定是延遲能降到多低，而是怎么測量系統的延遲？對一個HFT系統來說，所謂的 tick-to-trade延遲，一定要有既精確又不影響系統性能的測試方法才有意義。可以想像一下，最理想的測試場景一定是你的系統真正運行在直連交易 所，有真實的市場數據傳入的情況下，并且測試的代碼就是真正的交易算法時，得到的數據才有意義。如何得到這個苛刻的測試環境，以及如何測量系統的各個部分 的延遲，是一個非常有技術含量的工程，難度往往并不亞于系統設計本身。
最后說點題外話，技術發展是非常快的，在這個時代沒有什么秘密能永久保鮮，HFT/low latency trading也不例外。現在歐美在這方面的市場已經逐漸趨近飽和，畢竟軟硬件的性能都是有上限的，當大家都能達到微秒甚至納秒級時，僅僅靠拼速度就沒那 么大優勢了。目前雖然拼速度仍然有盈利空間，但是長遠來看一定需要在保證速度的基礎上增加算法智能性和系統穩定性，從這個角度上說像把全部算法都燒進 FPGA的做法是很難維持的，開發周期和成本都太高了。接下來真正有挑戰的應該是高速系統和大數據的結合，這應該是一個很有想像力的空間。