TCPの多重アクセスでconnection reset by peerが起きる

Question

C++でプログラミングをしていますがconnection reset by peer がバーストで起こってしまいます。

状況としましては通常のTCPコネクションを一本貼りましてそこsocketを用いてサーバとの通信用のAPIをクライアントから多重化しながら呼びました。
1000スレッドまで作成し，同時に接続したのですがコネクション reset by peer が頻繁に起こります。
いつも同じところで起きるのではなく、毎回ランダムにおきます。
ちなみにサーバ側は1000スレッド同時アクセスに耐えられる設計になっており、テストもしています。
原因としてはどのようなことが考えられるでしょうか？

解決策として何が考えられるでしょうか？

Answer 1

Connectionが出来なくなる原因として、
Linuxの接続上限があります。
1秒間で20000 コネクションがあると、60秒間 再利用できなくなります。
そうなると、コネクションエラーが頻発します。

コネクションプールを使用し、接続をして、再接続せず
使いまわすと、大丈夫です。

再接続していないか、確認できるようになっていますか？

Answer 2

原因究明方法として、tcpdumpをとり、wiresharkなどで解析するといいと思います。

たとえば、
tcpdump -i ethx port xxxx -c 100000 -w /var/tmp/tcpdump.cap
と実行し、その間に通信を発生させてください。取得が終わったら
wireshark -r /var/tmp/tcpdump.cap
と実行してみてください。
そのあと、filterをかけて何が原因で落ちているか調べてみてください。

■ Wiresharkのディスプレイフィルタ － 基本的な使用方法から、よく使うフィルタまで －
http://troushoo.blog.fc2.com/blog-entry-108.html

また、netstat -s でキュー溢れでdropしていないかなども見ることができます。

同時接続数が多いなら、カーネルパラメータのsomax_connが十分な値になっているかとかbacklogの値が十分の値になっているかを確認する必要があります。

それ以外にも要因はいろいろ考えられますので違う可能性はありますが・・・・

小さいパケットを頻繁に送るのであれば、Nagleアルゴリズムと遅延ACKも関係してきますので、調べてみてください。

Answer 3

サーバ側は1000スレッド同時アクセスに耐えられる設計になっており、テストもしています。

であれば、経路上の問題ではないでしょうか。
スイッチングハブが輻輳を起こしてるとか。

Comments

[退会済みユーザー]

スイッチの輻輳ですか...

ですが動画受信のようなものではなくメタデータ程度の通信しかしていないのですがそのようなことはありえるのでしょうか？

[kozuchi]

自分も直接経験したことは無いので、絶対ある、とは言い切れません。
しかし、LANというのは速いように思えて１つのコンピュータ内でプロセス間通信に比べると、意外に脆くて鈍重なものですよ。
動画配信の場合は、間に合わないパケットは多少捨ててしまっても通信は継続しますが、コネクションリクエストは一つでも捨てられると、リクエスト元で接続が切られたというエラー事象となってしまいます。

また、単位時間あたりにさばかなければならないパケットの数ということを考えると、数本程度の動画配信よりも、1000スレッド同時接続要求の方が多いように思います。