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 指令有興趣別忘了參考看看

科科們已經了解到OpenFlow是SDN控制器與交換器之間的互動協定，具體定義了交換器在資料轉發面(Data Plane)的功能，並規範封包的種類和格式，目前最新的實用化版本是1.5.1。

支援OpenFlow的交換晶片，在邏輯上主要由2部份組成：端口(Port)和流表(Flow Table)，所謂的Flow意指「在同一段時間內，經過同一段網路，並具有相同屬性(如相同的TCP port)的訊息」，每個流表項目(Flow Entry)對應網路中傳輸的一條流，也是OpenFlow中最核心的元素，可謂以簡馭繁。

上集在此：https://www.cool3c.com/article/158140

[專欄]物聯網帶來的減肥運動

【作者 陸向陽】
2015年10月26日 星期一

電子工程、半導體、資通訊產業為了儘快讓物聯網時代到來，已對現有多種主流技術作了許多調整設定，筆者觀察檢視了這些改變後，大體可以用「減肥、輕量化Light Weight」等字詞來形容。

例如ZigBee打從2004年就開始發展，但原有傳輸設計一次最多只能傳遞128Bytes的封包資料，如此無法支援IPv6協定，而IPv6幾乎是物聯網的必備，因為IPv4幾乎用盡，要讓東西（Thing）可以上網，肯定要更多的IP。

針對此，業界提出6LoWPAN（IPv6 over Low power Wireless Personal Area Networks），將原有的IPv6協定進行減肥，把一些比較細膩的表達資訊捨棄，把一些重複表達的資訊捨棄，終於能擠入128Bytes的現有傳輸模式中，進行傳遞。

在6LoWPAN之後有人提出uIP的微型化IP協定（主要為Cisco與Atmel所提），以及lwIP的輕量化IP協定，同樣是著眼於嵌入式系統需求，而後因物聯網觀念興起而更被看重，如近期知名的ESP8266晶片即宣布支援lwIP。

類似的，LTE過往總追求高資料傳輸率，不斷推出更快速的終端裝置類別（Category），從Category 1一路到Category 15，但為了因應物聯網，開始訂立退化性標準的Category 0，速率從10.3Mbps～3,916.6Mbps降至1Mbps，後續更將降至200kbps。

協定方面還有更多的輕量化工作，例如業界提出CoAP（Constrained Application Protocol）協定，也是一種輕量化的作法，其傳輸上採行UDP（User Datagram Protocol）協定，而非TCP（Transmission Control Protocol）協定，此也有助於減少資料傳輸量，雖然這些輕量化也帶來一些犧牲，例如UDP協定不似TCP具備連線狀態，但對於不是很嚴謹的應用，這些犧牲尚能接受。

往CoAP的更上層，是應用資料的傳遞，此方面一樣有輕量化的工程，過往是以XML（eXtensible Markup Language）格式來傳遞各種不同欄位、屬性的資料，但XML格式使封包量大增，1MB原生實質資料，改以XML格式表達後，可能增至4～10MB資料量。

因此，業界提出JSON（JavaScript Object Notation）格式，以便在某些應用場合取代XML，有效減少傳輸量，目前許多新的物聯網技術也積極支援JSON格式，如Google提出的Weave協定也支援JSON格式，MediaTek的雲端物聯網服務MCS（MediaTek Cloud Services）也支援JSON。

另外，為了管理物聯網的裝置，OMA（Open Mobile Alliance）提出其M2M的裝置管理協定，稱為OMA Lightweight M2M，從協定名稱也已看到「Lightweight，輕量」字樣，簡稱LWM2M。

再者，由IBM內部研究提出的MQTT（MQ Telemetry Transport）協定，也因為輕量特性而在近年來受到重視，很多雲端大廠多開始支援MQTT，例如Facebook的傳訊功能Facebook Messenger即採行MQTT，或2015年10月Amazon的AWS （Amazon Web Services）也支援MQTT。

由此可知，物聯網協定不單只有產業聯盟的相互較勁，如AllSeen、OIC、Apple HomeKit、ECHONET Lite（由名稱也可看出已進行輕量化）、Google Weave等的叫戰之外，還需要對現行協定進行簡化，而越是輕量則越有潛在普及機會，因為再初階入門規格的硬體也能採行。

幸運的是，這些輕量化的標準，是針對各環節進行輕量化，相互之間的衝突性不高，或即便是屬於同一類型、同一取向的協定，至目前為止也沒有高度的敵對競爭態勢。

即便克服了運算負荷、傳輸負荷問題，挑戰也還沒結束，現行傳輸站能否負荷，也是個問題，所謂傳輸站包含LTE基地台、家用Wi-Fi路由器等，Google為此提出高價、高規格的OnHub路由器，宣稱同時間可服務128個裝置的連線。

而LTE後續的5G，也明訂每平方公尺的覆蓋範圍內都能支援服務，也就是每平方公里要能支援100萬個裝置節點連線傳輸，這將成為下一個重要挑戰。

附圖：在6LoWPAN之後有人提出uIP的微型化IP協定，以及lwIP的輕量化IP協定，同樣是著眼於嵌入式系統需求...

資料來源：https://www.ctimes.com.tw/…/%E7%89%…/MQTT/1510261752UN.shtml