クライアントサーバプログラムでの通信の不安定さ

Question

クライアントサーバプログラムで
client のリクエストをTCP
serverのレスポンスをUDP
で行っています.

研究施設からL2で大学まで疎通しているのですが, リクエストを1秒間に60回近く出しています.
帯域も十分な値を用意しています
ですがなぜかリクエストの数が非常にまばらになってしまい, きちんと連続的に受信できていません.(マルチスレッドでリクエストを送っています)

なぜ思うように連続的にデータ送信ができていないのでしょうか？

Comments

[BlueMoon]

環境面について詳しく書かれれば回答が得やすいかと思います。
OS（client、serverとも）
ネットワーク構成
　例えば Server - L2HUB - 1000BaseT(xxメートル) /Wifi - L2HUB/WifiAP - PC
　クライアントの台数など
プログラム環境　
　言語や使用しているライブラリなど
またテスト状況に関する詳細情報など
　単発はうまく行っているが、連続にしてからNG
　Client単体はOKだが複数にしてからNG

Answer 1

通信方法とデータの詳細が分からないので違っているかもしれませんが、TCP接続されたsocketで数バイト～数十バイト程度の小さなデータを送っているのでしたら、TCPの正常な振る舞いとしてリクエストの送出タイミングがばらけることはあり得ます。

詳しくは「TCP send buffer window size」などで検索すると詳しい解説を得られると思いますが、ざっくりとこの振る舞いの原因を列挙すると・・・

• アプリケーションがsend()/write()したデータはTCPの内部でバッファリングされます。
• TCPは宛先ホストからの「次のデータ受信できます」という反応があるまでバッファリングしたデータを送出しません。
• 宛先ホストは「次のデータ受信できます」の反応を送るときに、受信可能なデータの最大値も通知します。

このように、TCP接続されたソケット通信では、宛先ホストと協調しながらデータを送出するタイミングや一度に送出するデータサイズを常に変化させているのです。

このとき、宛先ホストの反応が「データをもっと大量に送ってOK」になったり、「ちょっと少な目でお願い」になったりする原因は、受信側コンピュータの処理が重くなっていたり、ネットワークが高負荷状態になっていてルーターが通信経路や通信量を変化させていたり、といったことが考えられます。

なお、TCPが送信データをバッファリングする振る舞いは、SO_SNDBUFというソケットオプションで変更できます。また、UDPであればTCPのようなバッファリングや宛先ホストとのきめ細かい協調動作を一切行いませんので、アプリが送出したメッセージはそのメッセージ境界を保持したまま宛先に届くことが期待できます。ただし、ネットワークが高負荷状態の場合UDPメッセージは遺失する（相手に届かない）ことがある点に留意してください。

以上、ご参考になれば。

Answer 2

L2で接続とのことですが、物理的に線を一本引いているわけではないですよね？研究施設と大学間とこのことですから、SINETのL2VPNを使っているということでしょうか？そういった構成であるという前提でお話しします。

TCP/IPにおいてIPパケットが順番に届く保証は一切ありません。特に基幹系の経路は冗長化されています。冗長化されている経路ではほぼ同時に送ったパケットが前後することはよくあることです。極端な例では、サーバとスイッチを2本の線で冗長化(チーミング)しているだけでもパケットが前後することがあります(昔、これのせいでUDPのTFTPがうまく動作しなくて嵌まった事がある)。この前後するかしないかは帯域に関係ありません。もし、パケットが前後した場合、UDPはそのまま渡しますが、TCPはまだ来ていない本来は前に届くはずのパケットを待ってからもう来てしまった本来は後になるパケットを処理します。なので、OSに渡されるタイミングはさらに順不同になります。保証されるのは一つのTCPセッション内での順番だけです。OSから見るとUDPや複数のTCPセッションが不連続になる場合があります。

さらにそこにVPNが間にあったりすると、VPN自体の処理速度などの影響もあり、断続的な通信になる場合があります。直接繋いだときと同じような連続性は得られないでしょう。

また、フレームサイズがオーバーしている可能性もあります。もしタグVLAN等を利用しているなら、途中の経路でタグVLANに対応していないところがある可能性があります。その場合、1500ちょうどぐらいのパケットだと、フレームサイズがオーバーして、そのパケットだけ分割または再送が求められ、そこの部分だけが遅延やロストします。

経路構成(ネットワーク機器や回線の種類)などがわかれば、もう少し詳しいところがわかるかも知れません。