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 指令有興趣別忘了參考看看
udp socket 在 軟體開發學習資訊分享 Facebook 的最佳解答
深入 TCP/UDP/HTTP Socket 程式設計,為初學者到專家準備的網路基礎概念課程
https://softnshare.com/network-programming-from-scratch/
udp socket 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
本文延續前篇效能校正的經驗談,上篇文章探討了關於Locality與中斷中可以最佳化的部分,。本篇文章將繼續剩下最佳化步驟的探討。
The Case of the Nosy Neighbor
從前述最後的火焰圖中,作者觀察到幾個跟網路有關的 kernel call,譬如 dev_queue_xmit_nit 以及 __netif_receive_skb_core 等有可能有成長的空間,於是輾轉前往這邊去研究。
作者觀察到 packet_rev 這個函式有不少的比例,而該函式的意思是有人嘗試透過使用 AF_PACKET 等方式開啟了 RAW socket 來處理封包。透過 ss 這個指令,作者觀察到系統中有其他的應用程式透過 AF_PACKET/SOCKET_RAW 也在處理封包,最後輾轉發現原來是系統上的 dhclient。
DHCP Client 必須要在系統有 IP 以前就有收送封包的能力,所以使用 AF_PACKET 也滿合理的。作者思考是否有辦法可以讓 DHCP Client 拿到 IP 之後就關閉 AF_PACKET,改使用純 UDP 的方式來進行後續的 DHCP Renewal 功能,可惜這個方向沒有辦法達成。
根據 AWS 的官方文件,當一個 IP 被分配到一個機器後,這個 IP 會跟該機器同生死,因此這種情況下 其實不需要透過 DHCP Renewal 來反覆取得 IP,只要取得一次 IP 即可。
作者變修改相關腳本,當 DHCP 取得 IP 後關閉 dhclient,此外還必須要記得去修改網卡層級關於該 IP 的記憶,預設期間是一小時,作者將其修改為永遠。
透過這樣簡單的設定,整體的效能又再度提升了 6%,從 1.06M req/s 提升到 1.12M req/s
The Battle Against the Spin Lock
作者陳述自己花了非常多時間與 Spin Lock(作者心魔的大白鯨) 奮戰,幾乎是茶不思飯不想的滿腦都在思考如何加速,然後再經歷過反反覆覆的失敗後,作者最後決定還是要寫出一些關於 Spin Lock 的嘗試與研究心得,算是一個很精彩的踩雷心得。
這部分的篇幅很長,而且內容也滿深的,最後的解決方式也只有提升 2%左右的效能,所以對這部分有興趣的讀者再自行閱讀囉
This Goes to Twelve
終於來到最後的最佳化步驟了,這個步驟中的範疇都只能勉強壓榨出些許的效能,包含了關閉 GRO, TCP壅塞控制以及靜態中斷處理。
(Generic Receive Offload)GRO 是一個網路相關的功能,目的是用來將 Kernel 層級的封包給聚合起來變成一個大封包,而 Kernel 收到這個封包後會把該大封包重新組合變成本來的小封包,對於使用者的應用程式來說不會有任何感覺,但是對於整體的封包傳輸來說能夠節省花費的並提升效能。大部分情況下這個功能都是開啟的,Amazon Linux 2 預設也是打開這個選項。
然而針對作者的測試情境,由於所有的封包基本上都是同一條連線且資料量也不大,因此 GRO 雖然可以帶來聚合的效果,但是也會拖延封包進入到 Linux Kernel Network Stack 的時間點,因此開啟 GRO 帶來的好處沒有很大。
TCP 壅塞控制有不同的演算法,Amazon Linux2 內建兩種演算法 Cubic 以及 Reno,除此這兩個之外常見的還有 Google 多年前貢獻的 BBR。根據作者測試,其實驗環境中有比較好效能的則是 Reno
註: 不同算法針對不同應用場景,所以要切換演算法前要先釐清自己的應用情境以及用哪種演算法比較合適。
全部零零總總的修改後提升了 4%,整體的效能服務來到了 1.2M reqs/s
這篇文章真的很長,有些最佳化的方式是針對該應用場景而特別去使用的,這也意味者並非所有的修正方式都可以套用到各位的應用程式。
本篇文章還是很值得一讀,整個分析的思路與想法都非常有趣,雖然不一定用得到但是也許未來有一天會有機會使用。
https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/
udp socket 在 TCP UDP Socket 概觀 - IBM 的相關結果
使用者資料封包通訊協定(UDP) 是一種無連線,因而不可靠的傳輸通訊協定。它會稍微執行錯誤檢查,且除了提供程序對程序通訊(而不是主機對主機通訊),不會對IP 服務增加 ... ... <看更多>
udp socket 在 TCP與UDP在socket程式設計中的區別- IT閱讀 的相關結果
具體程式設計時的區別socket()的引數不同. UDP Server不需要呼叫listen和accept. UDP收發資料用sendto/recvfrom函式. TCP:地址資訊在connect/accept ... ... <看更多>
udp socket 在 Android - 基於TCP和UDP Socket通訊講解 - 大大通 的相關結果
關鍵字:AndroidTCPUDPSocket簡易聊天室 ... 掌握的知識,TCP/IP 中最具代表性的傳輸層協議分別為TCP 與UDP,根據不同專案的功能需求使用TCP或UDP通訊 ... ... <看更多>