參考截取一部分：https://blog.csdn.net/ysu108/article/details/7764461

在linux下可以修改協議棧改變tcp緩沖相關參數：

修改系統套接字緩沖區

echo 65536 > /proc/sys/net/core/rmem_max
echo 256960 > /proc/sys/net/core/wmem_max
echo 65536 > /proc/sys/net/core/wmen_default

修改tcp接收/發送緩沖區
echo "4096 32768 65536" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 256960" > /proc/sys/net/ipv4/tcp_wmem

修改網絡設備接收隊列
echo 500 > /proc/sys/net/core/netdev_max_backlog

重傳次數
echo 5 > /proc/sys/net/ipv4/tcp_retries2

發現上面的參數都是改小了，既然大的時候視頻比較卡，改小了會好麽？首先一個問題是緩沖區越大越好麽？如果機器處理不過來tcp流量，那麽不管緩沖區有多大，早晚會溢出，這就導致，應用層知道的tcp未收到比較晚，因為在緩沖區裏面呆了一段時間，而且重傳的數據也較大，會早成網絡負擔比較大，其實看來並不利於整個網絡。那麽緩沖區改大有什麽好去呢？緩沖區改大可以處理突發的大流量數據，不至於畫面變化的時候，也就是流量突然增大的時候緩沖區滿。那回來看這個問題，既然大的時候視頻會卡，那麽改小了，讓應用層早點知道tcp沒有收到而已，對整個網絡也就是省了點流量，對實時視頻是否卡影響不大，自己的分析，待驗證。

如果懷疑是機器問題，或者是tcp配置問題，可以換一個機器（配置更好的）看看是不是處理不過來請求而造成的延遲，或者用wireshark抓包來統計流量。

以下來自網絡，原始出處已經找不到。。

計算機需要多大內存？當然是越大越好了，這是用戶的想法。但是計算機的設計者則必須在成本、實現難度、和取悅客戶等幾個因素之間進行折中，選取一個最佳平衡點。對計算機來說，其主要依據是產品的市場定位，高端商務PC至少配2G內存，低端學生機配256M就夠了。如果用256M RAM的學生機來作復雜的大規模FPGA仿真，可能會發現硬盤的燈一直是亮的，這說明內存已經不夠用了，操作系統正在不停的在內存和硬盤之間兌換數據，用大容量的低速硬盤來彌補內存太小的不足，但是代價是計算時間延長了很多倍。路由器是不是也向PC一樣，主要依據售價來決定內存配置的大小呢？會不會也是內存越大越好呢？路由器的設計者依據哪些因素來決定內存配置的大小？一般來說，路由器的內存主要用於一下這些方面：

（1）用於存儲路由器軟件指令和靜態數據，路由器跟PC不同，PC是只把當前運行的程序裝到RAM中，但多數路由器都是一開機就把全部程序都裝到 RAM中，一般來說，路由器的程序也不大（幾兆到幾十兆）；（註：此處主要指控制平面的程序，也就是Cisco和Juniper的路由引擎）

（2）用於存儲動態數據，例如：路由表、OSPF的鏈路狀態數據庫等。假如某路由器需要支持最多10萬條路由，按照每條路由256字節計算，那麽大約需要200M左右內存。

（3）用於緩沖數據報文，路由器的工作原理是存儲轉發。極端情況下，路由器的每個接口，至少需要緩沖一個報文，否則路由器根本不能工作。下面重點討論這個問題。

一般來說，路由器配置的報文緩沖區都不止一個報文。因為這樣也就意味著當有新報文到達的時候，如果前面一個報文正在發送，這個報文緩沖區尚未處於空閑狀態，那麽新的報文勢必將會被丟掉。等前面一個報文發送完了，鏈路處於空閑狀態，但是由於剛才報文已經被丟掉了，也無法利用鏈路空閑狀態。如果被丟掉的報文是TCP報文，那麽主機勢必將重傳這個報文（在該路由器前面的一段線路上傳輸兩次同樣的報文），並縮小自己的發送窗口，降低了TCP連接的速率。

也就是說，如果接口的報文緩沖區太小，將導致丟包率高，數據鏈路利用率低，TCP傳輸效率低。那麽是不是報文緩沖區越大越好呢？也不是，因為報文緩沖區大到一定程度，就不能繼續提高數據鏈路利用率和降低丟包率了。如果這臺路由器處於擁塞狀態，接收報文的速率遠遠大於接口的發送帶寬，無論多大的報文緩沖區都會被填滿，而報文緩沖區大了，那麽也就意味著擁塞狀態的時候，報文的轉發延遲時間會很長。延遲時間太長的報文，對於接收方來說，已經沒有意義了。以 TCP連接為例，當報文大於發送方的重傳時間的時候，發送方就會重傳該報文，也就是說，大於TCP的重傳時間的到達的報文，是沒有意義的。對VoIP等應用來說，對網絡延時更加敏感。

一般來說，路由器的接口緩沖區的大小有一個經驗法則（rule-of-thumb）：B = C * RTT，C是鏈路速率，RTT是平均報文往返之間。至於這個經驗法則源自哪裏，我沒有認真考證。但這個經驗法則的主要依據是最大化TCP效率，最大化網絡接口帶寬利用率。如果依據這個法則來設計路由器，對中低端路由器來說，問題不大。但是對於高端路由器，是有挑戰的。一般中高端Internet骨幹路由器上會假設RTT為250ms，那麽對於個 10GE接口，需要的內存是(10G bit/s * 0.25 s) / 8 約為300MB。也許大家會說，300M不大麽，但是可以預見，最近兩年核心路由器的容量必將發展到單槽位80 - 160G，也就是說單大約需要2.5G - 5G內存。雖然不是完全不可實現，但還是有一定難度。從 Juniper的一個白皮書（Characteristics of Switches and Routers）可以看出，Juniper也是按照這個經驗法則設計的。

但是最近的一些研究認為（sizing router buffers, Guido Appenzler, Isaac Keslassy, Nick McKeown），其實路由器不需要那麽大的內存，每個端口只需要緩沖幾十個報文就足夠了，這樣用NP或ASIC內嵌的RAM就夠了，不用配置外部RAM。他主要依據是以前的經驗法則是根據單TCP流來推算的，作者認為這個模型不對，實際的骨幹路由器上是有很多TCP流的，因此應該按照 B = C * RTT / sqrt(N)來計算，N是TCP流數量。但是另外一些研究則認為這個結論不對，路由器上不能只考慮TCP，還有很多急於 UDP的語音和視頻應用。反正在教授們之間，這個問題至今仍然沒有一致的意見。工程師已經不再爭論這個問題了，就按照B = C * RTT來設計，成本可以接受，而且也比較安全。

為了糾正網絡問題，有時候需要重新配置網卡的默認IP包大小。經常會發生路由的最大IP包大小比網卡的小。TCP協議可以自適應，但是UDP協議不行（會導致分片丟包，然後重傳）。所以NFS over UDP特別要註意設置MTU的大小。可以用命令*tracepath*來看網絡上的MTU值，用ifconfig命令來看網卡的MTU值，要使兩者匹配。（大部分網絡都是1500，除非設置了支持大包）時，IP包在用UDP協議傳輸時會分片。大量IP包分片會消耗網絡兩端大量的CPU資源，而且還會導致網絡通信更不穩定（因為完整的RPC在UDP分片的任何一個包丟失時都得整個RPC重傳）。在2.2和2.4內核中，默認的socket讀緩存rmem_default是64k，寫緩沖wmem_default是8k。這兩個值對有大量讀寫負載的情況很重要。

linux 網卡buffer大小