跳到主要內容

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

使用GCP Cloud Builder建置CI/CD Flow

服務的建置通常是持續性的作業,而部署則一般是專案初期建置一次,未來可以沿用該部署設定... 這樣的流程走向自動化,在Container的環境又更是重要... 本篇介紹一下,在Google雲端,我們可以搭配Source Repository與Build Trigger等服務來完成服務的自動建置與部屬,讓封裝Container與部署到Container Engine的動作可以一氣呵成...
首先幾單瞭解一下一個Container Engine服務的建置與部屬過程...
使先,建立Container Engine Cluster,透過GCP Winzard可以很快速地開立您的GKE Cluster…

假設您的cluster是叫做demo-cluster,則可以透過下面的指令來跟GKE建立連線
$ gcloud container clusters get-credentials demo-cluster --zone asia-east1-a
這串指令不用記ㄛ~可以在Cluster的頁面找到他...

點選複製,即可貼到您的Terminal執行...

跟GKE建立鏈結後,接下來可以部署您的城市,這邊我們以我的一個範例程式Demoweb (https://github.com/peihsinsu/demoweb) 為例,

這個專案中,包含幾個重要結構:
app/ : 放置您的程式,在Dockerfile中會將該資料匣複製到Docker Image中 k8s/ : 放置k8s的deployment與service描述檔 Dockerfile : 封裝docker的描述檔,會以node.js的image為基礎來建置執行環境 cloudbuild.yaml : Google Cloud Build Trigger的步驟描述檔

使用 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是否正常運作....