跳到主要內容

Rate Shaping

最近遇到一個網路專有名詞:Rate Shaping,查找了一下網路,發現滿有趣的,跟大家分享。(以下節錄自原文章:http://www.ezfiber.com.tw/resources/resources01.htm)

頻寬管理機制,共有 TCP Rate Shaping 、 Class-based Queuing 、 Fail Allocation of Bandwidth 及 Packet-size Optimization 等四種;完整的架構出最佳化的頻寬控管功能: 

A. TCP Rate Shaping : 
TCP Rate Shaping 為一專為 TCP/IP 交通設計的管理法則,它會告知資料傳送者適時的減少資料傳輸量,來使得 TCP 資料流 (TCP Flow) 傳送更加平順,以便達到將 TCP 交通的瞬間巨量 (Burst) 情形降至最低。這些突如其來的巨量交通會造成路由器的交通阻塞,嚴重影響到一些無法接受傳輸延遲的網路應用 (Latency-Sensitive Application) 。 

然而, TCP Rate Shaping 只是很粗略的控制傳輸的訊框大小 (Window Size) ,對於低速的專線並無法有效的達到準確的頻寬管理。同時,一般所謂重要的應用 (Mission-Critical Application) 的封包均是相當短而快的傳輸連結, TCP Rate Shaping 無法對其有所幫助。此外, TCP Rate Shaping 只能控制 TCP 的交通,對於 Non-TCP 的交通則無法管理;而根據統計,網路上的交通約有 48% 為 TCP 的交通,約有 52% 為 Non-TCP 的交通。 

B. Class-based Queuing (CBQ) 
Class-based Queuing(CBQ) 乃依據不同的 Class 等級提供不同的 Traffic Queuing ,它可補足 TCP Rate Shaping 只能管理 TCP 交通的問題,支援 TCP 及 Non-TCP 的交通管理,並且能管控到網路交通的封包階層 (Packet Level) ,故能更有效的控制低速頻寬的傳輸。 

C. Fail Allocation of Bandwidth 
CBQ 雖能補強 TCP Rate Shaping 之不足,然而仍有其問題所在。因為 CBQ 只針對 Class 來作頻寬的分配,並不能保證同一 Class 中的不同交通傳輸 (Traffic Flow) 能獲得相等的頻寬資源;所以仍可能產生某些屬於高優先權 (High Priority) 的使用者依然得不到頻寬的現象。為確保對同一 Class 中所有使用者的公平對待,需要有法則來將一個 Class 所制定的頻寬平均分配到每個交通流。 

D. Packet-size Optimization 
Packet-size Optimization 能將傳輸的 Packet -size 最佳化,例如將 e-mail 傳遞大檔案的 Packet -size 縮小,來避免這些大檔案將頻寬佔住,使一些小封包傳不出去;以確保如 TN3270 、 VoIP 等無法接受傳輸延遲的網路應用 (Latency-Sensitive Application) 交通的品質保障。 

這個網誌中的熱門文章

Oracle LISTAGG

同事介紹的一個Oracle的好用查詢:LISTAGG
SELECT A.GROUP_ID,A.KEY, LISTAGG(A.VALUE,'; ')WITHINGROUP(ORDERBYA.VALUE)as GG  fromSYS_PROPERTIESaGROUP byA.GROUP_ID,A.KEY
LISTAGG可以將group後的結果會總顯示於一個欄位 上述SQL原本A.VALUE會是一個row一個row的排列 使用LISTAGG之後,可以將A.VALUE顯示在同一個row中 並且可以指定間隔符號(在此設定為';') 針對某一些報表查詢非常有用唷 :D

使用 minikube 輕鬆上手 kubernetes

安裝minikube
macOS只需要透過brew即可快速安裝...
brew cask install minikube
Linux環境可以直接下載執行檔,放到環境變數可以吃到的路徑即可...
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && \ chmod +x minikube && \
sudo mv minikube /usr/local/bin/
Windows的下載網址如下: https://storage.googleapis.com/minikube/releases/latest/minikube-windows-amd64.exe
如果您的kubectl尚未安裝,可以直接使用google cloud sdk來安裝:
curl https://sdk.cloud.google.com | bash
gcloud components install kubectl
安裝完成後,原則上minikube會在本地端加入minikube的k8s context,我們可以透過下面指令來使用該context…
kubectl config use-context minikube
然後,可檢查一下您的minikube node是否正常運作....

新一代LB - Traefik

新一代LB-Traefik Traefik突破以往我們對loadbalancer的觀點,他是一套直接與docker整合的loadbalancer套件...透過Traefik,我們可以使用label的方式將後面啟動的dockerinstance掛載到loadbalancer中,且無需重新啟動Traefik,可直接生效... Traefik基本介紹 Traefik是以動態重載新加入的dockerinstance的方式來替有附加相同domainlabel的dockerinstance建立網路附載平衡的關聯...因此,設定上,與一般我們建立reverseproxy的過程剛好相反(一般我們會先建立服務,再建立reverseproxy將服務串連起來)... Step1-建立Traefik服務 下面我們用官方的composefile來說明... File:docker-compose.yaml version: '2' services: proxy: image: traefik command: --api --docker --docker.domain=docker.localhost --logLevel=DEBUG networks: - webgateway ports: - "80:80" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock - /dev/null:/traefik.toml networks: webgateway: driver: bridge 其中traefik啟動時候,我們需要指定docker.domain來告訴taefik要聆聽的domain是哪一個,然後要事先開啟對應的port,讓外部服務可以連到traefik...,另外,我們將dockersocket掛載進來,這是必要的設定,讓traefik可以透過dockersocket來操控一些東西...,最後,traefik.toml檔案,我們保留空的,讓treafik自己建立... 啟動: docker-compose -f docker…