🔥 จัดสรร IP Addresses บนระบบ Network ยังไงดีให้ไม่งง ?!
.
ต้องนี่เจอนี่ 👉 DHCP หนึ่งในโปรโตคอลสำคัญในระบบ Network ที่จะช่วยให้การจัดสรร IP เป็นเรื่องกล้วย ๆ 🍌 แล้ว DHCP มันคืออะไร มีรายละเอียดยังไง วันนี้แอดสรุปสั้น ๆ มาให้แล้ว ถ้าพร้อมแล้วไปอ่านกันโลดดดด !!
.
🌟 DHCP (Dynamic Host Configuration Protocol) คือ เครื่องมือการจัดการเครือข่ายที่ทำงานร่วมกันกับ TCP และ IP ที่ใช้เพื่อเชื่อมต่ออุปกรณ์ต่าง ๆ เข้าด้วยกัน
.
⚡ หน้าที่หลัก คือ การจัดการและกำหนดค่า IP Addresses แบบอัตโนมัติบนเครือข่าย
.
ดังนั้น IP Addresses ของแต่ละคนก็ไม่จำเป็นต้องได้รับการกำหนดด้วย Admin
.
และยังสามารถนำไปใช้ตรวจสอบ Default Gateway, DNS และ Subnet Masks สำหรับอุปกรณ์ที่มีการตั้งค่าเพื่อการใช้งานในระบบเครือข่ายได้อีกด้วย
.
🌈 ซึ่งโดยส่วนมากแล้วใน Internet Router ที่เราใช้งานกันตามบ้าน มักจะมี DHCP มาให้อยู่แล้ว แต่ถ้าเป็นธุรกิจขนาดใหญ่ อาจจะใช้ Computer หรือ Server ทำหน้าที่เป็น DHCP server โดยเฉพาะนั่นเอง !!
จบกันไปแล้วกับสรุปสั้น ๆ กับเรื่องของ DHCP หวังว่าจะชอบกันนะ ❤️
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#network #DHCP #BorntoDev
同時也有23部Youtube影片,追蹤數超過43萬的網紅Carl Ho卡爾 頻道,也在其Youtube影片中提到,▷ 背景音樂 BGM ◁ Conker's Bad Fur Day OST - Windy & Co. ヽ(∀゚ )人(゚∀゚)人( ゚∀)人(∀゚ )人(゚∀゚)人( ゚∀)ノ σ`∀´)σ 加入成為我的會員 :3 一起種瓜子: https://bit.ly/2LOqm6A (*´∀`)~♥ ...
「dns server」的推薦目錄:
- 關於dns server 在 BorntoDev Facebook 的最佳貼文
- 關於dns server 在 AppWorks Facebook 的精選貼文
- 關於dns server 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於dns server 在 Carl Ho卡爾 頻道 Youtube 的精選貼文
- 關於dns server 在 Wilson說給你聽 Youtube 的最讚貼文
- 關於dns server 在 aさん Youtube 的最佳貼文
- 關於dns server 在 自建Name Server | 卡斯伯Blog - 前端,沒有極限 的評價
- 關於dns server 在 Synology 區域網路DNS server架設 - Mobile01 的評價
dns server 在 AppWorks Facebook 的精選貼文
#NFTsummer Hi 大家好,我是本月值班編輯 Alyssa。還記得這個月我們主要探討 NFT 嗎?今天的受訪者,是我的同事、也是明日科技法律事務所的主持律師,王琍瑩 (Liying),她陪伴 AppWorks 以及許多區塊鏈新創,鑽研區塊鏈相關法律與應用多年,今年更躍升為 NFT 專業藏家。所以我特別邀請她,由不同的觀點切入她的觀察,文章以 Liying 第一人稱分享,歡迎花個 3 分鐘閱讀:
1. NFT的迷人之處:智能合約的各種延伸
2. 最喜歡的NFT專案:超展開的 EulerBeats
3. NFT的發展機會:把獨一無二的概念翻玩到極致
///
#NFT的迷人之處:智能合約的各種延伸
最早是身邊的大神朋友帶我認識 NFT,包括數位藝術、遊戲虛寶、卡牌收藏等。過程中常常聽到大家在爭執 NFT 的本質,有人說是權狀,有人說是名人認證,也有人說其實你連一個 jpeg 檔都沒有買到。
我覺得大家都對,也不能說別人有錯,因為 NFT 就是一種智能合約 (Smart Contract),當我們買一個 NFT,我們買到的就是這個智能合約 (包括關聯文件) 所規範的權利與義務。在法律上,無論是買賣、借貸、甚至叫不出名字的交易,只要你情我願,合約就成立了。智能合約也是如此,它的功能和樣貌,完全取決於需求和設計,自然會有成千上萬的變化。
律師寫的合約,無論多麼周延,還是可能被違約。而智能合約最迷人的特色,就在於能夠自動執行預設的任務。一個厲害的智能合約,不會輸給律師寫的合約,甚至幫助我們更有效率完成交易,這樣的想像空間,讓我十分著迷。
///
#最喜歡的NFT專案:超展開的 EulerBeats
我很喜歡 NFT 結合 Fungible Token (各種代幣) 或是 Semi-Fungible Token (例如票券) 的專案。
例如 #EulerBeats 將智能合約自動生成的音樂作品,透過 Original (母帶) 和 Print (專輯) 兩種形式來發行,每一張專輯的買賣,都透過智能合約自動執行權利金分潤。由於 Print 本身就是一種代幣,團隊還設計了「Bonding Curve」價格曲線,當需求愈多,價格就愈高,也允許「Stake」和「Burn」來鼓勵持有、同時解決流通性的問題。這些都是將 DeFi 世界熟悉的概念延續到 NFT 領域,運用智能合約的相容性,讓各種應用超展開。
後來許多專案也不斷學習前人經驗,像是 #PunksComic 從最接地氣的漫畫切入,發行可以讀、可以賣、可以「Stake」、也可以「Burn」的作品;而數位藝術家 Pak 則透過 Cube 和 Ash 各種不同的智能合約協定,進行了一場精彩的策展,也不著痕跡發行了受到社群追捧的社交代幣 (Social Token)。
///
#NFT的發展機會:把獨一無二的概念翻玩到極致
很多人認識 NFT 是從「獨一無二」的藝術品開始,會覺得「獨一無二」代表困難和珍貴。其實仔細想想,「獨一無二」或許才是萬事萬物最基本、最自然的現象。比方說,#UniswapV3 優化原先的自動造市商 (Automated Market Maker) 機制,讓流動性提供者 (Liquidity Provider) 自行盤算設定各種價格區間,使得每個人持有的部位 (Position) 都成了「客製化」的智能合約,自然而然就形成不同功能和樣貌的 NFT。
另外,像是 ENS 為錢包地址和網域設定域名,就像 DNS 域名一樣,必須與眾不同,因此也自然而然形成有特殊用途 (Utility) 的 NFT。光是對照三億六千萬個現行有效的 TLD 域名註冊,就可以想見未來 ENS 的龐大商機。有趣的是,ENS 是比 ERC-721 協定還早誕生的 NFT,直到 2019 年 5 月才移植到這個通用協定,以便與跨平台的服務相容。所以現在我們可以直接在 OpenSea 買賣 ENS 域名,就像交易 NFT 藝術品一樣。
創作者 (Creator) 靈活運用智能合約,更能貫徹自己「獨一無二」的藝術表達;而創業者 (Founder) 觀察 NFT 浪潮,則不妨試著去探索萬事萬物「無所不在」的「獨一無二」。隨著智能合約更為成熟、跨平台交易更為普及,令人興奮的虛擬宇宙 (Metaverse) 終將實現,但我更期待有那麼一天,NFT 會以再平凡不過的姿態,存在我們日常生活之中。
///
[與談嘉賓]
王琍瑩 (Liying),明日科技法律事務所主持律師,也擔任台北律師公會創新科技委員會的主任委員、和比特幣及虛擬通貨發展協會的常務監事。長期協助區塊鏈和新興科技產業的 Startups 處理相關法律問題,這陣子最常被問的題目是 NFT 的著作權。Discord 的 100 個 Server 都是 NFT 專案,為了零時差關注全球脈動只好犧牲睡眠,深刻體會 NFT 市場無國界。歡迎大家追蹤 Twitter (@wwwliying) 掌握 NFT 即時訊息。
明日科技法律事務所:https://nextandnexus.com
///
[同場提醒]
AppWorks Accelerator #23 正開放申請中,歡迎所有 AI、Blockchain、NFT、佈局東南亞的創業者們加入這個社群,一起切磋成長:https://bit.ly/3y1Oqc5
dns server 在 矽谷牛的耕田筆記 Facebook 的最佳解答
本篇文章是個經驗談,作者想要聊聊是如何將一個 4vCPU 的VM給調整到可以達到每秒處理 1.2M(120萬)個 JSON Reuqest,本篇文章非常的長,所以會分多天來介紹。
整篇文章探討的是各種 turning 的步驟,來聊聊如何從最初每秒 224k(22萬四千) 給調整到每秒 1.2M 的處理能力。
整個過程分成九大步驟,後面同時標示每個過程後的每秒請求能力
1. Application Optimizations (347k)
2. Speculative Execution Migtigations (446k)
3. Syscall Auditing/Blocking (495k)
4. Disabling iptables/netfilter (603k)
5. Perfect Locality (834k)
6. Interrypt Optimizations (1.06M)
7. The Case of the Nosy Neighbor (1.12M)
8. The Battle Against the Spin Lock (1.15M)
9. This Gost to Twelv (1.20M)
作者強調,上述的過程不一定適合你的應用程式,但是透過這些步驟能夠讓你更佳瞭解應用程式的運作行為,同時也有機會發現一些潛在的瓶頸問題。
環境介紹
1. 團隊使用 Techempower 來進行 JSON Serialization 的測試
2. 使用 libreactor(event-driven框架) 來搭建一個簡單的 API Server
3. HTTP 的解析使用 picohttpparser,同時使用 libclo 來處理 JSON 的編碼
4. 硬體環境
- Server: 4 vCPU, c5n.xlarge AWS VM
- Client: 16 vCPU, c5n.4xlarge AWS VM (clinet太弱會變成瓶頸)
- Network: Server/Client 屬於同一個可用區域(AZ)
5. 軟體環境
- 作業系統: Amazon Linux2 (Kernel 4.14)
- Server: 使用 libreactor (使用不同版本,分別是 Round18 以及 Round20)
- Client: 修改 wrk 這個知名的工具並重新命名為 twrk,詳細差異自己看文章內部,主要都跟顯示有關
6. 實驗方式
- 每個測試跑三次,取中間值
- 256 連線,16 threads,同時每個 thread 都會 pin 到一個固定的 CPU
- 每個實驗都有兩秒的暖機時間來建立連線
Ground Zero
第一個要探討的就是什麼最佳化都還沒有使用前,到底當前應用程式可能的瓶頸在哪裏
首先團隊將該應用程式與其他常見的應用程式或是開發框架比較,譬如 Netty, Nginx, Actix, aspcore 等, libreactor 的效能不錯,有中上水準。
接者作者使用火焰圖(Flame Graphs)來 Profile 該伺服器,作者很好心地將文章中所有的火焰圖都調整了一下,讓所有的 user-space 相關的 function call 都轉成藍色,而剩下跟 kernel 相關都維持紅色。
1. 大部分的時間都在 Kernel 處理
2. 主要是花費在收封包與送封包
3. 應用程式本身主要是分兩大部分,解析 HTTP 的封包以及處理請求與回應。
從上述兩點來看,作者認為目前的應用程式寫得算不錯,因為瓶頸很明顯是卡在 Kernel 端
接下來就正式進入到各種 Turning 的章節探討
Application Optimizations
長話短說:
- 作者基於 libreactor Round18 的框架進行修改,並且所有的修改都已經被合併到 Round20 的版本中,而這些修改主要是實作方面的強化以及整個框架的最佳化。
1. 作者首先透過 htop 觀察運行過程,發現 Server 只有使用 2vCPU 而已(系統有 4vCPU),因此這是作者進行的第一個修改,讓 Server 使用了 4vCPU,這個簡單調整就讓效能提升 25%
註: 作者特別強調,不要覺得從 2vCPU 變成 4vCPU 效能就可以變成兩倍,主要是1) 沒有使用的 vCPU 還有很多其他的工作要處理,因此不是完全都送給你應用程式處理。2)基於 hypter-thread vCPU 的架構,環境只有兩個真正的 CPU 而是透過邏輯的方式產生四個抽象的 CPU,所以全用一定會變快,但是基於很多資源還是要競爭與共用,數字不是單純翻倍
2. 作者自己的應用程式本身使用 gcc 建置時有使用 "-o3" 的方式來最佳化處理,然而框架本身卻沒有使用 "-o3" 的方式來弄,因此作者也針對這個部分來處理,讓建制框架時能夠使用 -o3
3. 從實作方面來看,作者觀察到 libreactor 1.0 版本使用的是 read/write 這兩個常見的方式來處理封包的送收,作者將其修改成 recv/send 整個效能就提升了將近 10%。
註: write(針對 FD,更全面廣泛的用法) 與 send(針對 Socket,更針對的用法) 使用上差異不大,但是 write 於底層 Kernel 最終還是會呼叫到 send 來處理,所以基本上可以理解就是在沒有特別參數需求時,可以直接跳過幾個 kernel function 來達到加速的效果。
write kernel 內的走向: sys_write -> vfs_write -> __vfs_write -> sock_write_iter -> sock_sendmsg
send kernel 內的走向: sendto -> sock_sendmsg
4. 作者觀察到火焰圖中有一些 pthread 相關的資料,進而發現 libreactor 會創造一個 thread pool 來處理非同步的 DNS 名稱解析問題。對於一個 HTTP Client 來說,如果今天要發送請求到多個不同的 domain,而每個 domain 都會需要進行一個 blocking 的解析過程,透過這種方式可以減少 DNS 解析造成的 blocking 問題。然而對於 HTTP Server 來說,這個使用情境帶來的效益似乎就稍微低了些,畢竟 Server 只有 Bind Socket 之前可能會需要去解析一次 DNS 而已。
大部分的情境下, thread pool 都是應用程式初期會去創造而接者就不太會管她,但是對於錙銖必較的效能除錯人來說,任何能夠調整的部分都可能是個值得探討的地方。
作者透過修改 Server 端(準確來說是 libreactor 框架內的程式碼)關於 Thread Pool 的一些用法,成長的讓整個效能提升了 2~3%
結論來說,透過上述四個概念來提升的程式碼效能。
1. vCPU 盡量使用: 25%-27%
2. 使用 gcc -O3 來建置框架的程式碼: 5%-10%
3. 使用 march=native 等參數來建置最後的 server 應用程式: 5%-10%
4. 使用 send/recv 而非 write/read: 5%-10%
5. 修改 pthread 的用法: 2%-3%
註: 作者強調每個最佳化的結果並非是單純累積的概念,反而還會有互補的效果。
可能前述的操作實際上也會讓後續的操作達到更好的效果,
譬如如果先跑 vCPU 的調整,效能大概提升 25%,但是如果先執行別的最佳化過程,最後再來調整 vCPU,就可以達到 40% 的效果,主要是 CPU 可以共有效率的去執行程式。
最後,這個部分讓整個處理封包能力從 224k 提升了 55% 到 347k (req/s)。
從火焰圖來看,整個 user-space 的範圍縮小許多,同時 send/recv 的處理也有使得整體的高度下降一點點(大概四格..)
為了避免文章過長,本篇文章就探討第一個最佳化的過程,剩下的就敬請期待後續!
https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/
dns server 在 Carl Ho卡爾 頻道 Youtube 的精選貼文
▷ 背景音樂 BGM ◁
Conker's Bad Fur Day OST - Windy & Co.
ヽ(∀゚ )人(゚∀゚)人( ゚∀)人(∀゚ )人(゚∀゚)人( ゚∀)ノ
σ`∀´)σ 加入成為我的會員 :3 一起種瓜子:
https://bit.ly/2LOqm6A
(*´∀`)~♥
更多關於我 More About Me
實用 Useful:
▷ 生活妙招 Life skills ◁ https://goo.gl/ZTLG18
▷ 手作 DIYs Guide ◁ https://goo.gl/u4ENC7
▷ 煮食 http://bit.ly/2L74I0v ◁
搞笑 Fun:
▷ 趣味話題系列 Funny Video ◁ https://goo.gl/SrmBPm
▷ 惡搞混音 Parody Remix ◁https://goo.gl/sdbRM4
▷ 挑戰 Challenges ◁ https://goo.gl/IGt6Kg
▷ 智障劇場 ◁ https://goo.gl/RKDPQM
▷ 我們都一樣 ◁ http://bit.ly/39lEOOT
實測 Practice:
▷ 文具開箱評測 Stationary Unboxing ◁ http://bit.ly/2Xwkq9F
▷ 各種開箱系列 Product Unboxing ◁ https://goo.gl/CE6MpC
▷ 實驗系列 Experiments ◁ https://goo.gl/MzwL7f
▷ 路遊記 ◁ http://bit.ly/3rYln78
▷ 試食 ◁ http://bit.ly/35hyAOB
寵物 Pet:
▷ 我的搞笑倉鼠 My Funny Hamsters ◁ https://goo.gl/8sNzHy
▷ 倉鼠養育教學 Hamster Care Guide ◁ https://goo.gl/zZWYF7
放鬆 Relax:
▷ ASMR系列 ◁ https://goo.gl/KSvmVF
---------------------------------------------------------------
▷ 臉書粉絲專頁 Facebook Fanpage ◁ https://goo.gl/699CdS
▷ Instagram ID ◁ CarlHo117
▷ Mewe 群組 ◁ https://mewe.com/join/carlhohk
![post-title](https://i.ytimg.com/vi/_AluboqUENc/hqdefault.jpg)
dns server 在 Wilson說給你聽 Youtube 的最讚貼文
網路慢! 教你修改DNS(Domain name service)? 網路加速 WiFi分享器 路由器 - Wilson說給你聽
常常大家都在說要把DNS設定成8.8.8.8或是1.1.1.1之類的 那到底什麼是DNS(Domain name service) 又另外如何尋找最適合的DNS來使用呢? 這一集就來分享這個給大家喔
![post-title](https://i.ytimg.com/vi/Mk9rsBitJYU/hqdefault.jpg)
dns server 在 aさん Youtube 的最佳貼文
近頃コメント欄に宣伝目的でURLを貼り付ける人が多くなりましたね。しかも中々狡猾でつい押してしまうような状況を作られがちです。
Youtubeのアカウントというのは実はいくらでも作成できるので、そういった悪質なユーザーをブロックしようが通報しようが焼け石に水なんですね。
今までのGoogleの対策を鑑みると、恐らくコメント欄にURLを貼り付けるのを無効化されるかと思います。
こうやって規制というものが増えていくのです。正直者が馬鹿を見るとはこの事ですね。
前回出した狐式の動画のを、なぜか動画のコメント欄で宣伝しまくる謎のアンチがいるのですが(それか頭の悪いファン)、彼は一体何をどう思ってその行動に至ったのか気になりますね。因みにagehaさんも被害にあったようです。
こちら側からはどうすることも出来ないので困った事です。
#aさん #Agario #大和田常務 #堺雅人すこ
ぜひ見てほしい動画👇👇
【Tiktokの闇】
https://youtu.be/3FA_gJ_DCsM
【冷静に見るコロナウイルス】
https://youtu.be/W_cP-HoBnvE
【おすすめのゲーム実況動画】
https://www.youtube.com/playlist?list=PLyqbsa8y8gNsFPZD5_1UdVxERYNFKmLf4
【今までのアガリオ実況まとめ】
https://www.youtube.com/playlist?list=PLyqbsa8y8gNspuo9oxQN0Y2UgWaod9aJy
![post-title](https://i.ytimg.com/vi/2hICzFE_6D8/hqdefault.jpg)
dns server 在 Synology 區域網路DNS server架設 - Mobile01 的推薦與評價
記得把DNS伺服器指向這台,不然會找不到.... zaas.za wrote: 話不多說直接切入正題...(恕刪). ... <看更多>
dns server 在 自建Name Server | 卡斯伯Blog - 前端,沒有極限 的推薦與評價
本篇教學是延續「大神來六角」的“網址管理與DNS 託管全攻略”,目的是讓參與的學員更了解DNS 在轉址的過程觀念。 對於Name Serve 的概念可以參考AWS ... ... <看更多>