send（）の非常に長いブロックは、TCPに関係なく、スレッドに関連しているようです。

Question

RTPストリームをHTTPストリームに変換することを主な目的とするアプリケーションがあります。 1つのスレッドはRTPパケットを受信して​​循環バッファに書き込み、もう1つのスレッドはミニWebサーバとして動作し、そのバッファから読み取ることでHTTPリクエストに応答します（一度に1つのGET要求しか発生しません）。

このHTTPスレッドは、GETが受信されると循環バッファに何かがあるときにsend（）を呼び出す単純なループです。しかし時には、send（）ブロックが狂った時間（> 1秒）でブロックされ、オーディオドロップアウトが発生することがあります。

明確にするため、RTPパケットはリアルタイムで到着します。ここではオーバーフローまたはアンダーフローは発生しません。 HTTPソケットは、受信者がオーディオを必要としないときにTCPを使用してフローを調整することが期待されるため、目的に応じてブロックされます（独自のバッファで十分です）。しかし、RTPソースはリアルタイムでやっているので、HTTPクライアントはオーディオに圧倒されません。

しかし明らかに、何か他のことが起こり、Linux、MacOS、Windows（これらのコードはすべてこのコードで動作します）と2つの異なるネットワークトポロジーでそれを観察しました。

センド（）ロングブロックは、私が（送信中と、スレッドブロックを何が起こるかで欠けている何かのように、TCPフロー制御以外の何かによるものではない場合、私は）思ったんだけど

Answer 1

取得wiresharkのトレースは、どこでTCPストールが起きているかを見ることができます。私は何が起こっているのかは次のいずれかと考えられます：

1. 実際には、クライアントが消費しているよりも速く送信しています。私はあなたがすでにそれを排除していると思う...

2. IPパケットが失われている可能性があり、TCPがACKを待っているとタイムアウトしてから再送信する可能性があります。一方、あなたの送信スレッドは、ソケットにさらに多くのデータを蓄積しようとしており、バックアップされ、最終的にブロックされています。あなたが行うことができます

一つの簡単なものは、あなたが送ったソケットに送信バッファ（SO_SNDBUF）を大きくしようとすることです。この値は、ブロックする前にアプリケーションがソケットに書き込むことができる未送信バイト数を指定します。可能であれば、クライアント側の受信バッファ（SO_RCVBUF）を増やしてください。そうすれば、ネットワークが数秒間絡みつくと、ブロックする前にソケットがいっぱいになります。

int size = 512*1024; 
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));