大家好！我是LINE GAME台灣技術組的Rex。在LINE GAME台灣技術組，最主要的工作是各項LINE GAME相關技術推廣，我們需要瞭解或甚至開發LINE GAME軟體開發套件（Software Development Kit；簡稱SDK），也需要幫忙與外部開發者溝通，包括向開發者介紹如何使用SDK來整合LINE GAME平台，或協助架設與管理遊戲伺服器。這次我想從技術層面介紹我們LINE GAME使用的Content Delivery Network（簡稱CDN）。
我們LINE GAME使用Akamai的CDN服務。LINE GAME台灣技術組在台灣除了幫開發者規劃與執行CDN patch流程之外，另外需要測試各區域的Akamai服務與其最適合的設定方式，並提供開發者在使用CDN時的各項方針與注意事項。
我們先前針對CDN的使用方針在東南亞各地區執行了一次實地測試。在這次大規模的測試當中，我們特別針對了: 額外請求時間（request overhead）、HTTP/2通訊協定、同時連線數（request concurrency）對遊戲內容等較大檔案的下載效能的影響做了測試。 這些與效能有關因素的正反理論相信大家都相當清楚，由於LINE的文化是資料與指標導向的，任何結論都會透過實際的測試以及資料的收集來做驗證。另外我們也想知道各個要素的重要性與效益，好讓我們為各項方針定義優先權。
我們在如何測試的實務上有很大的空間與自由，也不限定使用的網路函式庫（network library）。但因為我們想了解用戶端底層的設定與各項效能指標的相關細節，所以使用了近幾年在手機遊戲開發中較不常見的C++語言，另外我們也使用了常用的libcurl與libevent作為底層的library。
我們架設了一個測試網站來收集測試資料，並在這網站中用chart.js將各地的測試案例結果以圖表的方式呈現，便於後續的分析來建立更可靠的方案。LINE在衡量專案各重要里程碑時，相當重視如何把結果以視覺化方式呈現，因此如何將資料分析並以圖表方式顯示是每個專案都必須仔細評估的一環。
我們在最後的結果中發現如下：
Request overhead
關於request overhead，在測試中我們特別針對request跟response的RTT（round-trip time）做測試，我們在固定的下載payload總量下設計了不同的request count（例如：256KB * 40 req、1MB * 10 req等），然後在request concurrency為1的狀況下比較整體的download rate。我們發現request count在網路延遲（latency）較高的環境中有較大影響，由於網路latency依然是主要瓶頸，所以我們認為將內容封裝來減少Request量能有效優化CDN效能。但是依各個遊戲的規劃或內容格式而不同，某些遊戲內容較難打包，這種狀況下，我們發現多加使用concurrent request對這方面是有幫助的，在較高request concurrency的狀況下request count的多寡較無明顯影響。
Concurrent request
在concurrent request測試中，我們的test application把request queue起來，並能夠動態設定不同的request concurrency來處理request queue，針對http1在concurrent request造成的connection overhead，我們使用libevent優化I/O，可以無差別的用單一thread處理數百個connection，在以上優化確保應用端沒有任何瓶頸之下，我們設計了有固定Payload與request count的test case，然後比較download rate在不同request concurrency下的差別，最後我們發現相較之下request concurrency到達某個程度對CDN效能的提升有一定程度的影響。尤其在某些網路資源較好，有較大頻寬的區域會有更大的影響。這符合理論：相比之下在bandwidth-delay product較高的地方，等待發送下一個request或response會造成較多未充分使用的頻寬，所以我們認為對自己的library多加確認這塊功能或許會有幫助。
HTTP/2
最後就是HTTP/2了，Akamai近期已支援HTTP/2。HTTP/2最主要的功能就是multiplexing，也就是HTTP/2使用單一connection即可傳送concurrent request。對比HTTP/1.1的concurrent request則會產生相同數量的connection，我們想試試看HTTP/2在僅使用單一connection對個人下載performance是否真有比較好的結果，又或者HTTP/2對整體的網路環境，TCP congestion control是否有正面影響。我們設計了各個不同的request concurrency搭配了固定的payload並比較這些不同的concurrency在HTTP1.1跟HTTP2下傳送的差別，我們也用多個device在同時間進行測試並觀察整體的下載量，從大部份的測試結果中，我們認為持平來說對內容大部分為大型檔案的CDN環境或使用app與web service的遊戲影響不大，有時候甚至有較差的結果。HTTP/2大部份的作用對瀏覽器運作較有益，如被限制的連線數與有較大容量標頭（header），如cookie的request，但在較差的網路環境，我們發現HTTP/2 download rate較為穩定，整體throughput較高，這或許可證明較少的連線可能對整體網路環境有幫助。這一點request concurrency也是如此：我們發現Akamai在較差的環境下高concurrency並無幫助。
綜合以上就是我們這次的Akamai CDN方針，從過程上來看，這雖然是個測試專案，但我們在這樣的專案中，除了結論與方針外，意外地也有很大的空間決定想要測試的指標或技術（例如HTTP/2），也能自由的討論或設計測試案例，自由使用想要的語言跟想要的library實作。當然測試方式與設定都有經過嚴格的討論與檢查，所以也需要碰觸到更多的細節。LINE是一個對細節非常重視的地方，但身為engineer能有機會深入了解每個細節是很開心的，也正因為如此可以學習到更多東西。
對我們LINE Game台灣技術組與LINE的文化有興趣嗎？ 歡迎加入LINE engineer。