リアルタイムの音声通信サービスでnet.ipv4.tcp_tw_reuseを有効化するとどういうことが起き得るのかを考えてみる
前提として音声をやりとるする際にTCPを使うケースはほぼないはず。VoIPはIPだしWebRTCはUDP(とTCP)。リアルタイムでやり取りする上でTCPは非効率出しメタデータの送信とかでTCPが使われるケースはありそうだがメインデータの送受信で使うメリットはほぼない
それだと元も子もないのでもしもTCPでやり取りする音声サーバがあったらどうなるだろうか？TIME-WAIT状態のソケットに意図しないデータが届くことにはなる。
net.ipv4.tcp_tw_reuseが有効になっている場合、TIME_WAIT状態のソケットが新しい接続で再利用されることがある。この設定が有効の場合、TIME_WAITソケットが即座に解放され、受け取ったデータが新しい接続として処理される可能性がある。
例を挙げると
- ユーザー1が喋る
- 音声パケットが遅延する
- プロセスAが接続終了をする
- プロセスBがプロセスAが使っていたのと同様のポートを使おうとする
- ユーザー2がプロセスBに喋る
- ユーザー2のパケットが届く
- プロセスBが読み取る
- 遅延してたユーザー1のパケットが届く
- プロセスBが読み取る
という感じの事象が起き得る。ユーザー2とプロセスBが話していたら突然ユーザー1の声が入ってくる。単純にペイロードを読み込むだけだとそのデータが正しいのか正しくないのかが判別できないので意図しない音声データとしてアプリケーションが処理してしまう可能性がある。
UDPでも同じでは？
同じことが起きる。UDPのペイロードに何らかの制御コードを入れてアプリで無視するようにしてるはず。なのでTCPでもそれをやってあげれば良いはず。パケットにタイムスタンプやシーケンス番号を付与する方法あたりが思い浮かぶが実際はどうなんだろう。(Forward Error Correctionとかそういうのも出てくるはず)
