最近遇到一個TCP通信的工程現象，一直沒有找到合理的解釋依據。請論壇大神幫助分析。
交代背景：
現場有一臺客戶端設備，經過通信網與遠方服務器實作連接。采用TCP/IP協議方式。
客戶端定時周期性發送資料給服務器，服務器接收資料，資料流量約1.2Mbps，通信網給客戶端分配的網路帶寬約2Mbps。
例外現象：
該通信網路頻繁會出現擁塞現象，客戶端發送的tcp資料幀RTT時間在擁塞期間，會達到200+ms，正常情況下在30ms左右。
客戶端應用程式每20ms寫一幀資料給tcp發送緩沖區（write socket），我的在應用程式里設定SO_SNDBUF為一個較大值（符合內核引數要求，確認生效了），根據我的估算，即使出現這種程度的網路擁塞，導致tcp發送視窗中的已發送資料由于收不到ack而無法清除，tcp發送緩沖區也能夠快取至少5秒的資料。
但是，實際上發現，當網路延遲較大時，僅僅過了幾百毫秒，客戶端的應用程式write socket就出錯了，列印 Resource temporarily unavailable（我的客戶端socket是非阻塞的），我認為這是因為tcp的發送緩沖區已經滿了，write出錯導致的。但是經過抓包計算，從write出錯計算往前推，發送緩沖區中應該只有40kB左右的資料（未發送的和未得到ack確認的），而設定的緩沖區大小為256KB。
為什么256KB大小的發送緩沖區，僅僅塞了40KB左右的資料，就滿了？
雖然發送緩沖區并不僅僅存盤應用資料內容，還有其它開銷，但是不至于占比這么大吧？還是我對TCP協議機制的理解有其它問題？
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/91145.html
標籤：網絡通信