• 締切済み

WINSOCKでTCPのステータスを調べたい

通信異常が発生するのでwiresharkでパケットモニタするとRetransmissionが発生していました。 そのデータには肯定応答コマンドとモニタコマンドが重複して送信されていました。単純に考えるとRetransmissionのパケットデータはそのままKEEPされてモニタコマンドのパケットとは区別されるような気がするんですが・・・。 そこでTCPが再送状態にあるならば上位からは新たなコマンドを出さないように修正したいと考えていますがいろいろ調べてもステータス取得出来るような物が見つかりません。 ご教授願います。

みんなの回答

  • Wr5
  • ベストアンサー率53% (2177/4070)
回答No.1

本当にTCPの再送が原因ですか? TCPを使用するアプリケーションからは再送は見えない(気にしなくていい)ハズですが…… # TCPはそういうプロトコル…かと。 再送が繰り返された為にアプリ側でタイムアウト処理が走った…とか、そういうことはありませんか? # または、再送繰り返している間にエラーで切断されてしまったとか。

je2cco
質問者

お礼

Wr5さん遅くなってすみません。 TCPのシーケンス番号等が同じ再送になっています。 アプリ側は、モニタコマンド要求ー>ドライバがコマンド送信ー>受信解釈ー>肯定応答ー>アプリに戻る ような流れでネット上に他のPCからのUDP問い合わせ等が入るとたまに再送が発生します。 相手のウィンドウサイズ750バイトとが小さいからなのでしょうか?

je2cco
質問者

補足

SENDの送信サイズをByte数にお応じて変更する方法で逃げることにしました

全文を見る
すると、全ての回答が全文表示されます。

関連するQ&A

  • 【WINDOWS7】ネットワークアクセスなし

    詳しくは http://okwave.jp/qa/q7760518.html を見ていただきたいのですが、 一部訂正 インターネットアクセスなし→ネットワークアクセスなし 未だに解決していないので、再度質問です。 前回の質問から新たに パケットキャプチャーソフトWIRESHARKを利用して パケットのログを補足してみました。 ネットワークアクセスなしが起きる前兆のパターンとして [TCP Retransmission] が10行くらいまとめて発生し ARP who has ルーターのip? tell 自機のip が延々と続く。 とくに、決まった通信で起こるのではなく、 ストりーミングラジオの再生中だったり、ウィルスソフトの自動アクセス(更新?)だったり。。。 要するにパケットの再送に失敗し、ネットワーク遮断。 ルーターとも通信できないという状況。 Retransmissionパケットの宛先ipおよび送信元ipともに 再送が発生するまでに正常にやり取りしていたipで もちろん、覚えのあるもの。 前触れもなくRetransmissionが発生し ネットワークが遮断されるのですから訳が分かりません。 ネットワークアダプタの設定をいじっていくしかないのですかね・・・・・ 自分のpcではwindows7機だけで起こるので 何かwin7独自の設定が邪魔をしているのでしょうか?

  • wiresharkでパケットモニタするとRetransmissionが多発しているという意味は?

    現在、自分で作成したパケット送信クライアントプログラムをテストしており、3秒に1回のタイミングでインターネット上にあるサーバのグローバルipアドレスに対し、TCPパケットを発信させて受信するというテストを行っています。 しかし、3秒に一回データを送っているはずなのに、その間隔10秒とか20秒とか間隔が開いてしまう時があります。 wiresharkというパケットモニタソフトで送信側、受信側共にパケットモニタを行ってみたところ、”Retransmission”が多発しているということがわかりました。(tcp.analysis.retransmissionというフィルタ設定で検索)この現象はある時とない時があります。テストして10日ぐらい経つのですが、このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか? わかる方いらっしゃいましたらご教授よろしくお願いいたします。

  • TCP/IPで同じパケットが2つ送信される。なぜ?

    Windows8 PC上のブラウザから、LAN上の機器(HTTPサーバ)にアクセスしようとしています。 Wiresharkでそのときの通信を覗いてみると、PCから送信されるパケットはなぜか2回同じものが短時間の間に連続して送信されているようです。その理由に心当たりがある方がいらっしゃいましたら、教えて下さいませんか? また、設定で回避できるのであれば、その設定項目などもわかるとありがたいです。 詳しい状況です。Wiresharkのキャプチャ画像と合わせて見て下さい。 *PC側IPは192.168.0.12、HTTPサーバは192.168.0.18です。 *Wiresharkでは、パケット6と7、9と11、10と12、14と15は内容的に同じパケットのようです(seqとackが同じ) *同じパケットのうち、前の方のパケットではIPパケットのチェックサムが0000hとなっているようです(チェックサムオフロード?)。後の方のパケットには、具体的なチェックサムの値が入っています。 *前のパケットが短い場合(54バイトとか)、後のパケットにはパディングとして00hが追加されて、60バイト長となるようです。それ以上の長さのパケットは、前述のチェックサム以外には違いは見られません。 *同じ2つのパケットは、極短い期間で連続して送信されているので、HTTPサーバからの応答タイムアウトで再送しているという風には思えないです。 *PC側のブラウザは、ChromeでもIEでも同じように2つの同じパケットが送信されていました。しかし、LANの外(ルーター外のインターネット)に接続するときは、このように2つの同じパケットはWiresharkで見ると出ていないようです。 *ちなみに、PC側のLANはRealtekのGigabit Ether(有線)です。 よろしくお願いいたします。

  • TCP/IP通信3ハンドシェイクについて

    TCP/IPのTCP通信の3ハンドシェイク通信に関して質問なのですが、インターネットを使ったある端末でセンターのサーバーと6秒に1度程度3ハンドシェイク通信を行ってインターネット回線が正常かどうかを判定する機能を持っているそうなのですが、その時に1回の通信でどの程度のパケットをやり取りしているのかということを質問してみたら、約1.2kbyte程度のパケットをやり取りしていると業者の方が言っていました。 ちょっと興味があってWireSharkでこの端末とサーバ間のパケット通信をのぞいてみたところ、端末が1.2kbyte送信していたのですが、サーバからのACKと思われるパケットが1.2kbyteのパケットを返してきていて、再度端末が60バイト程度のパケットをサーバのIPアドレスに送信していました。 私はてっきり、端末とサーバー間のこの3ウェイハンドシェイクのパケットの総量が1.2kbyteだと思っていたのですが、これだと1.2k + 1.2k + 60 = 2.46kbyteとなると思うのですが、パケットのやり取りとしては正しいのでしょうか? サーバー側が受信したら同じ容量の1.2kbyteのデータをACKとして返してきているように思うのですが、Wiresharkで見ても全く同じデータでは無いようでした。サーバはデータを受け取ったら、ちゃんと受信したという1 or 0のデータみたいなものを返せばよいだけだと思うのですが、理由はあるのでしょうか?

  • パケットキャプチャについて

    パケットキャプチャについて wiresharkでパケットキャプチャをやっております。tcpでsynのパケットのみを収集したいのですが、現在では、 (1)ファイルの読み込み (2)フィルタの条件でtcp.flag.fin == 0 and tcp.fla.syn ==1 and tcp.flg.ack == 0 と入れフィルタリング。 (3)結果のファイルを保存 となって大変時間がかかります。cuiでコマンドライン上で一発ですませられる方法はありませんか?

  • WinsockによるUDP通信にて

    WinsockでUDP通信を行うプログラムを作っているのですが、 原因不明の問題が発生していて困っています。 通信手順は以下のとおりです。 (1) クライアントからサーバへ要求パケット送信 (2) 要求パケットを受け取ったサーバは、クライアントへACKを送信 (3) サーバが要求に対する応答パケットをクライアントへ送信 (4) 応答パケットを受け取ったクライアントは、サーバへACKを送信 クライアント-サーバ間でやりとりするデータは最大で992バイト、 それ以上になる場合は、分割して送信します。 パケットの分割が発生しない場合は、(1)~(3)がパケットの損失もなく通信できるのですが、 パケットの分割が発生する場合には、2回目以降の(4)のパケットがクライアントに届きません。再現率は今のところ100%です。 クライアント側のselect関数でもソケットを検出しません。 たしかにUDPは信頼性が低いですが、パケット分割が発生しないパターンでは100%届くので、UDPの仕様とは関係ないような気がします。 原因がさっぱりわからないので、アドバイスをお願いいたします。 ちなみに、クライアント、サーバともに同一端末内にあります(双方がループバックアドレスに対してパケットを送信)が、 これはテスト段階だからであって、本来はそれぞれ別々の端末で動作します。

  • パケットロスと遅延について

    (1)パケットロスって何でしょうか? (2)パケットロスが10%でも、回線品質は良くないのでしょうか?WAN間でも必ずパケットロスは0%でないと品質は良いとは言えないのでしょうか? (3)パケットロスが発生しても、データは遅くても完全に届くものでしょうか?それともパケットロス分のみ捨てられて、相手に届くのでしょうか? (4)パケットロスが発生すると、遅延も必ず起きているのでしょうか? (5)パケットロスと遅延がネットワーク側に問題があると判明した場合、どのような措置を講ずるのでしょうか? (6)TCPパケットはパケットロスがあると再送しますが、UDPパケットは再送しないで破棄されるのでしょうか? 以上、ネットワークに精通されておる方、お願い申し上げます。

  • ネットワークの瞬断について

    TCP/IPのネットワークにおいて、メンテナンスなどの際によく「瞬断が発生する」と言いますが、瞬断とはどの程度のことを言うのか気になっており、考え方など教えていただきたいです。試しに聞いてみた人は、感覚的に ・1秒程度の断は通信にほとんど影響がない。通信にほとんど影響のない断を瞬断という。 ・分単位だと通信に影響があり、通信がエラーで終了することもあり、瞬断といわない。 というようなイメージをもっているようですが、もう少し具体的にイメージしたいです。 【質問(1)】 今のところは、TCPの再送タイムアウト(RTO)を超えないような程度の通信断のことを瞬断というのかと考えているのですが、正しいでしょうか?また、RTOはOSにより計算方法が異なったり、カスタムできるようなので、一般にはどの程度なのかも教えていただきたいです。 ※UDPはロストするが、TCPならデータロストの起こらないような通信断のことを瞬断というのかと考えています。 【質問(2)】 通信断の時間がRTOを超えた場合、応答のないパケットは再送されなくなるかと思いますが、その時点でそのTCPコネクションは終了するのでしょうか? あるいは、次のパケットから転送が続くのでしょうか(最終的に転送完了したデータは抜けのあるデータになるのでしょうか)? 【質問(3)】 瞬断程度でエラーが起こらないようにアプリ側でコントロールすべき、という話も聞くのですが、アプリ側でコントロールとは具体的にどのようにするのでしょうか?

  • TCP/IP フィルタリングで許可するポート

    EP-805Aを有線LAN接続で使用した場合に、TCP/IP フィルタリングで設定すべき許可するポートを教えてください WindowsXPでの設定です 現在「TCP/IP フィルタリング」で TCPポート 137,139,445 UDPポート 137.138.445 のみを許可しています この状態で、有線LAN接続されたEP-805Aに印刷ができません「ネットワークでエラー云々のメッセージ」 「TCP/IP フィルタリング」を無効にすれば印刷できるのは当然なのですが、XPのサポート打ち切りに合わせてXPのPCの外部への接続を遮断する必要が生じました TCPに515,9100を許可しても、プリンターのステータスも読めないようです パケットモニターで見てみると、1125,3289などの他のポートも使用されているようです どなたか、許可すべきポートの一覧を教えていただけませんでしょうか? ※OKWaveより補足:「EPSON社製品」についての質問です。

  • ネットワークトラフィックのモニタ

    SNMP対応機器にミラーリングの設定をし、ミラーポートに接続したパソコンで受信もしくは送信パケットをキャプチャし、TCP monitor Plusで出るようなグラフでトラフィックを測定したいのですができません。Wiresharkでパケットを受信しているのは確認できました。良い方法は無いでしょうか? ※cactiなどの方法は今回考えていません。

このQ&Aのポイント
  • Pixel6aでエレコムAD-C35CBKは使えますか?アナログのオーディオアクセサリが検出されたエラーが発生し、認識されません。
  • Pixel6aのイヤホン端子を使用してエレコムAD-C35CBKを接続した際に、アナログのオーディオアクセサリが検出されたエラーが表示され、認識されません。
  • Pixel6aでエレコムAD-C35CBKを使用する際に、アナログのオーディオアクセサリが検出されたエラーが発生し、正しく認識されません。
回答を見る