要爭取足夠的頻寬，就要從兩個方面入手：1.伺服器單位時間傳送更多的資料過來；2.stb&tv平台能更快的處理資料
對於第乙個方面，具體到乙個tcp連線，就是伺服器一次傳送足夠多的資料出來。而一次應該傳送多少資料是由tcp傳送視窗決定，而傳送視窗又是由網路狀況和對端裝置的tcp接收視窗共同決定。網路狀況我們沒辦法決定，只能從對端裝置的tcp接收視窗入手，這裡的對端裝置是針對伺服器而言，具體來講就是stb&tv平台了。
在linux&android系統中，tcp接收視窗由/proc/sys/net/ipv4/tcp_rmem裡面的數值決定，數值越大，表示接收視窗越大，伺服器就能夠一次傳送更多的資料過來。
但是，數值也不適過大，因為這樣會導致網路擁塞，反而導致頻寬降低。
下面兩個圖分別是擴大接收視窗前和擴大後的對比圖，其中ip位址192.168.7.137為ms平台，192.168.7.135為海思平台
優化前ms接收視窗
對比機接收視窗
可以看得出，對比機接收視窗遠遠大於我們平台
優化前頻寬對比圖
紅線為ms平台，綠線為對比機平台
可以看出來差別不算太大，只是我們平台整體上資料沒對比機連續，峰值線沒對比機高
優化後ms接收視窗
此時ms接收視窗已經大於對比機接收視窗
優化後頻寬對比
紅線為ms平台，綠線為對比機平台
這裡可以看到經過優化後ms平台頻寬是高於對比機的
下面要講的是頻寬過大帶來的不利影響
優化前平均頻寬：
優化後平均頻寬
可以看到優化後總平均頻寬(ms+對比機)反而減小了，這就是因為視窗太大，導致網路阻塞，反而使總頻寬下降了
前面總結的是第乙個方面，就是通過加大tcp接收視窗讓伺服器端一次傳送更多資料。另外還有一種方法讓伺服器傳送更多資料，就是開啟多個執行緒向伺服器建立多個tcp連線拉資料
最後一種方法就是上層呼叫read或者recv函式的時候，請求的size可以稍微大一些，這樣一方面可以更好的發揮加大tcp接收視窗帶來的優勢，另一方面可以減少系統呼叫，減小耗時。
第二個方面，就是提高stb&tv的響應速度
在硬體配置確定的情況下，可以在程式中建立socket後使用setsockopt設定tcp_nodelay加快響應
網路頻寬的單位
sd2大會上，聽了錢巨集武的課，發現自己作了9年的 竟然連頻寬的單位都沒搞明白，汗顏。特收集整理這部分資訊如下 典型的誤解，包括之前的我 容易誤解的技術概念 kb是否等於kb 細心的讀者肯定會發現，我上面的兩個資料中，單位不同，乙個是mb，另外乙個是mb。具體的差別就是在這裡了。我們在日常的書寫中，...
網路頻寬的評估
根據併發使用者數評估所需網路頻寬 網路頻寬 band width 頁面平均大小 每使用者.每秒 併發使用者數 示例 併發使用者數 按照 來算 同一秒內 人同時發出請求 網路頻寬 300k 人 換算成 那就是 那麼說明只有頻寬超過 才能滿足我們的需求。上邊是乙個比較理論的計算模型 頁面的平均大小，這個...
網路頻寬的認識
1 定義 網路頻寬是指在單位時間 一般指的是1秒鐘 內能傳輸的資料量，網路和高速公路類似，頻寬越大，就類似高速公路的車道越多，其通行能力越強。2 單位 bps，kbps，mbps,gbps,tbps 數字資訊流的基本單位是bit 位元 時間的基本單位是s 秒 因此bit s 位元 秒 是描述頻寬的單...