關於 版本控管概念 ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://www.hwchiu.com/ping-implementation.html

本篇文章是難得的自產文章，該文章分享一下自己觀察不同 ping 指令與不同發行版本下的實作方式，主要探討的點是 ICMP 封包是如何產生的。
就我目前認知，目前至少有三種常見方式來設定 ping 指令讓其能夠順利收送 ICMP 封包。
常見的 TCP/UDP 應用程式實際上都是讓 Kernel 幫忙處理底層的 L3/L4 封包，使用者的應用程式則是專注於資料的交換與處理，簡單的說法就是專心處理 L7 資料。
但是 ICMP 封包不同於上述的 TCP/UDP 封包，一種方式就是透過 RAW Socket 的形式自行去拼湊組裝 ICMP 格式，自行處理一切封包的處理。
RAW Socket 本身也不允許每個使用者都能輕易開啟，必須要有相關的權限才可以執行，因此一種 PING 的實作方式就是透過 SetUID 的方式，讓所有能夠執行 ping 指令的使用者會短暫瞬間提權變成 Root 的身份
也因為是 Root 就可以順利的開啟 RAW Socket。
SetUID 強大且方便，簡簡單單就可以讓使用者瞬間變成 Root，但是也因為簡單好像就安全角度來看會覺得不太嚴謹，畢竟我想要的只是一個能夠開啟 RAW Socket 的權限，你去把整個 Root 都送給我。
因此第二種實作方式就是透過 Linux Capability 來達到更細緻化的權限控管，讓任何可以執行 ping 指令的使用者都可以短暫獲得 cap_net_raw 的權限，最終順利的開啟 RAW Socket
而第三種方式則是跳脫的權限的概念，與其透過 RAW Socket 來自行打造 ICMP 封包，不如讓 Linux Kernel 幫忙處理 ICMP 封包，ping 的程式只要跟 Kernel 要求建立一個基於 ICMP 協定的 socket 即可。
透過第三種方式最終可以達到 setuid-less 的架構，ping 的應用程式再也不需要任何的特殊權限，每個使用者都可以順利執行來收送 ICMP 封包。

文章內會針對三種方式進行實驗跟觀察，對 PING 指令有興趣別忘了參考看看

【職場碎碎念】關於飛鳥文章「遊戲業究竟在小公司還是大公司比較好?」心得
.
昨天看到飛鳥大的文章「遊戲業究竟在小公司還是大公司比較好?」，優缺點我覺得文章和留言都很清楚，這邊主要想加入自己的工作經驗與心得，分享給各位。
.
🔎原文連結：https://bit.ly/3ATTCRK
.
✅我剛退伍後是先在小公司上班，最大優點是：直接上戰場，越級打怪
.
那時候一個人最多的時候負責4-5款端遊產品，寫巴哈新聞稿、寫roadmap跟原廠提案、規劃1-3個月活動企劃、寫設計工單、寫技術工單等，基本上能包的幾乎全包，而且剛退伍根本沒任何經驗下，很多東西是從零開始。
.
那時候印象很深刻，進去不到一個禮拜就被要求操作一個營運活動後台，我連「測試機」、「正式機」是什麼東西都還沒搞懂就被要求全權負責下，那次的活動後台算是被我搞得七零八落，有驚無險地撐過。
.
因為這樣的經歷，也讓我對遊戲營運建構起較為全面的概念。
.
我認為在小公司最大缺點有兩點：
.
❌第一、接觸廣但不深：由於自己一個人要負責那麼多工作，基本上拿到東西就是先做完就丟出去執行，經理也不會盯太細，看起來該有都有就給過了。加上每個企劃身上都背那麼多遊戲，公司沒有甚麼教育訓練，因此大家也不會特別交流工作上的事情，就是悶著頭各做各的，所以基本功不夠扎實，很多東西似懂非懂，也不曉得怎樣會更好。
.
印象最深刻是副總某天衝進來辦公室要求每個產品都要算出「ARPU」，那時候我們還在跟經理討論什麼是ARPU、然後該怎麼算，最後算法其實是算出「ARPPU」，但因為沒人知道這英文背後的涵義是甚麼，最後也不曉得這數字能拿來做甚麼，真得非常菜。
.
❌第二、小公司沒資源、操作沒底線：那時候負責的產品都沒有行銷預算，因此活動上要花錢的事一律不用想，滿腦子只是想方設法從既有玩家身上榨錢，滿額贈、加價購、各式禮包只是基本操作，最後遊戲末期時，一個月內開6-8個副本、虛寶武器直接拿出來賣或抽都有，根本沒在管平衡。
.
因為沒預算的關係，因此對於「在沒有資源底下還要達成營收目標」這件事情上，的確是能被逼出一些潛能，例如硬搞一個伺服器把所有人丟進去弄個天下第一武鬥大會，然後搭配禮包販售等。總之想辦法用各種方式讓玩家花錢，但因為沒資源的關係，坦白說就是花90%的心力去創造可能1%不到的成效，投報率非常差。
.
✅後來進了大公司，我認為最大的優點是：工作分配專業化
.
如果進去做版本控管，那就是專心做好版控的所有事項；做遊戲企劃那就是專心針對遊戲改版做活動規劃；做產品企劃，那就是專心把預估抓準、營收搞好，確保這個月能達標甚至超標。
.
再者一個產品基本上就是一個團隊負責（視營收規模而定），各產品的相同職位會互相討教學習，甚至交接手冊都做的蠻詳細，且大公司比較會有一套營運方法論與產品管理方式，因此專業能力能再被進一步挖深。
.
✅另一個優點就是：擁有更多的資源
.
在小公司時，雖然負責4-5款產品，但絕大多數產品是完全沒有後續開發內容，根本不會有改版，僅依賴遊戲現存的內容想辦法變現。而大公司內的產品不管是改版或是行銷預算上都有一定的資源，因此在企劃上會有更多發展空間，例如：如果你知道下個月有新改版，強度也夠的話，至少在活動提案上可以有更多操作，行銷預算也比較有機會爭取多些。
.
產品本身有完整的tool可以操作，數據分析上資源更充沛，每款遊戲都有相對完整的後台可以查詢，公司內部也有專屬的技術人員可以協助撈取會員資料進行比對，甚至公司教育訓練也更充足，除了部門內有分享會幫助各產品互相了解做了什麼好的營運操作外，人資不時會請公司經理級以上主管或是外部講師進行教育訓練，這些可能都是小公司無法獲得的寶貴資源。
.
❌缺點就是組織架構層層分明，有時候臨時要舉辦一個活動，可能光提案、追加預算、產序號等等，時間就搓掉一個禮拜以上，對每天都在跟錢賽跑的營運單位來講，有時候會感到無奈。其他還有KPI和績效考核，但這塊就不多說了，再說都是淚。
.
最後，由於我很少換工作，過去比較荒謬的工作狀況我相信在現在市場已經成熟下，肯定已經提升非常多，因此不管是在大公司還是小公司，我認為自己保持著「開放學習的心態」以及「時時自省」最重要。
.
要知道這間公司到底待不待得下去，我認為從以下兩點去檢視大概就能掌握70%以上了，分別是👉「數據分析」與「營運規劃」。
.
✅「數據分析」：如果所在的公司只有基本的遊戲營運後台，只能看到DAU、ARPU、營收這種最表面的東西，然後想要提出一些深入分析的需求，例如拉出當月所有玩家的消費金額、登入日期、遊戲歷程等資料進一步分析時，公司或原廠跟你說這要一個禮拜後甚至更久才能拿到數據，那基本上可以考慮換間公司了。
.
✅「營運規劃」；如果提出的營運規劃、遊戲校調建議或是人數、營收活動等，提出去後就跟打了水漂一樣沒下落，也沒收到任何同意或不同意的反饋，甚至做不做這件事情都沒人在乎的話，那也要好好思考是不是要繼續待在這間公司。
.
上面就像營運的兩條腿，一但都被打斷了，那可能營運在這間公司內就是個可有可無的存在(請看延伸閱讀)，一方面在這職務上會變得非常沒成就感，另一方面主管只會鑽牛角尖在「獎不完、領到手軟」這樣的文案很老套，以及「這張宣傳圖素的背景是要亮一些還是暗一些」，這樣的內耗只會讓人每天很累，但卻不知道學到了什麼。
.
最後一句話總結👉「不要讓自己在一個連犯錯機會都沒有的工作環境內上班」，一但發現「表現很好」的背後只是因為「毫無表現」時，請就好好思考自己到底為什麼還要待在這間公司了。
.
🔎延伸閱讀：營運的現況與挑戰
https://bit.ly/2UKQaIA
.
🔎文章同步部落格：https://bit.ly/3wxCqhd

本文延續前篇效能校正的經驗談，上篇文章探討了關於應用程式本身可以最佳化的部分，包含了應用程式以及框架兩個部分。本篇文章將繼續剩下最佳化步驟的探討。

Speculative Execution Mitigations
接下來探討這個最佳化步驟對於效能有顯著的提升，但是本身卻是一個非常具有爭議性的步驟，因為其涉及到整個系統的安全性問題。
如果大家對前幾年非常著名的安全性漏洞 Spectre/Meltdown 還有印象的話，本次這個最佳化要做的就是關閉這類型安全性漏洞的處理方法。
標題的名稱 Speculative Execution Migitations 主要跟這漏洞的執行概念與 Pipeline 有關，有興趣理解這兩種漏洞的可以自行研究。

作者提到，大部分情況下這類型的防護能力都應該打開，不應該關閉。不過作者認為開關與否應該是一個可以討論的空間，特別是如果已經確認某些特別情境下，關閉防護能力帶來的效能如果更好，其實也是一個可以考慮的方向。

舉例來說，假設今天你運行了基於 Linux 使用者權限控管與 namespaces 等機制來建立安全防護的多使用者系統，那這類型的防護能力就不能關閉，必須要打開來防護確保整體的 Security Boundary 是完整的。 但是如果今天透過 AWS EC2 運行一個單純的 API Server，假設整個機器不會運行任何不被信任的程式碼，同時使用 AWS Nitro Enclaves 來保護任何的機密資訊，那這種情況下是否有機會可以關閉這類型的檢查?

作者根據 AWS 對於安全性的一系列說明認為 AWS 本身針對記憶體的部分有很強烈的保護，包含使用者之間沒有辦法存取 Hyperviosr 或是彼此 instance 的 Memory。
總之針對這個議題，有很多的空間去討論是否要關閉，以下就單純針對關閉防護能力帶來的效能提升。

作者總共關閉針對四種攻擊相關的處理能力，分別是

Spectre V1 + SWAPGS
Spectre V2
Spectre V3/Meltdown
MDS/Zombieload, TSX Anynchronous Abort
與此同時也保留剩下四個，如 iTLB multihit, SRBDS 等
這種設定下，整體的運作效能再次提升了 28% 左右，從 347k req/s 提升到 446k req/s。

註: 任何安全性的問題都不要盲從亂遵循，都一定要評估判斷過

Syscall Auditing/Blocking
大部分的情況下，Linux/Docker 處理關於系統呼叫 Auditing/Blocking 兩方面所帶來的效能影響幾乎微乎其微，不過當系統每秒執行數百萬個系統呼叫時，這些額外的效能負擔則不能忽視，如果仔細觀看前述的火焰圖的話就會發線 audit/seccomp 等數量也不少。

Linux Kernel Audit 子系統提供了一個機制來收集與紀錄任何跟安全性有關的事件，譬如存取敏感的機密檔案或是呼叫系統呼叫。透過這些內容可以幫助使用者去除錯任何不被預期的行為。
Audit 子系統於 Amazon Linux2 的環境下預設是開啟，但是本身並沒有被設定會去紀錄系統呼叫的資訊。

即使 Audit 子系統沒有真的去紀錄系統呼叫的資訊，該子系統還是會對每次的系統呼叫產生一點點的額外處理，所以作者透過 auditctl -a never,task 這個方式來將整體關閉。

註: 根據 Redhat bugzilla issue #1117953, Fedora 預設是關閉這個行為的

Docker/Container 透過一連串 Linux Kernel 的機制來隔離與控管 Container 的執行權限，譬如 namespace, Linux capabilities., cgroups 以及 seccomp。
Seccomp 則是用來限制這些 Container 能夠執行的系統呼叫類型

大部分的容器化應用程式即使沒有開啟 Seccomp 都能夠順利的執行，執行 docker 的時候可以透過 --security-opt seccomp=unconfined 這些參數告訴系統運行 Container 的時候不要套用任何 seccomp 的 profile.

將這兩個機制關閉後，系統帶來的效能提升了 11%，從 446k req/s 提升到 495k req/s。

從火焰圖來看，關閉這兩個設定後，syscall_trace_enter 以及 syscall_slow_exit_work 這兩個系統呼叫也從火焰圖中消失，此外作者發現 Amazon Linux2 預設似乎沒有啟動 Apparmor 的防護，因為不論有沒有關閉效能都沒有特別影響。

Disabling iptables/netfilter
再來的最佳化則是跟網路有關，大名鼎鼎的 netfilter 子系統，其中非常著名的應用 iptables 可以提供如防火牆與 NAT 相關功能。根據前述的火焰圖可以觀察到，netfilter 的進入 function nf_hook_slow 佔據了大概 18% 的時間。

將 iptables 關閉相較於安全性來說比較沒有爭議，反而是功能面會不會有應用程式因為 iptables 關閉而不能使用。預設情況下 docker 會透過 iptables 來執行 SNAT與 DNAT(有-p的話)。
作者認為現在環境大部分都將 Firewall 的功能移到外部 Cloud 來處理，譬如 AWS Security Group 了，所以 Firewall 的需求已經減少，至於 SNAT/DNAT 這類型的處理可以讓容器與節點共享網路來處理，也就是運行的時候給予 “–network=host” 的模式來避免需要 SNAT/DNAT 的情境。

作者透過修改腳本讓開機不會去預設載入相關的 Kernel Module 來達到移除的效果，測試起來整體的效能提升了 22%，從 495k req/s 提升到 603k req/s

註: 這個議題需要想清楚是否真的不需要，否則可能很多應用都會壞掉

作者還特別測試了一下如果使用 iptables 的下一代框架 nftables 的效能，發現 nftables 的效能好非常多。載入 nftables 的kernel module 並且沒有規則的情況下，效能幾乎不被影響(iptables 則相反，沒有規則也是會影響速度)。作者認為採用 nftables 似乎是個更好的選擇，能夠有效能的提升同時也保有能力的處理。

不過 nftables 的支援相較於 iptables 來說還是比較差，不論是從 OS 本身的支援到相關第三方工具的支援都還沒有這麼完善。就作者目前的認知， Debian 10, Fedora 32 以及 RHEL 8 都已經轉換到使用 nftables 做為預設的處理機制，同時使用 iptables-nft 這一個中介層的轉換者，讓所有 user-space 的規則都會偷偷的轉換為底層的 nftables。
Ubuntu 似乎要到 20.04/20.10 的正式版本才有嘗試轉移到的動作，而 Amazon Linux 2 依然使用 iptables 來處理封包。

下篇文章會繼續從剩下的五個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/