• ベストアンサー

ethereal内のメッセージの意味について

現在、etherealを勉強中なのですが、 以下不明の箇所があります。 1:[TCP Dup Ack]の意味は何でしょうか? 2:[TCP Retransmission] Request STATとは、   TCPパケットを再送する事でしょうか?   また、このメッセージが複数出ている場合は、   連続してパケットを再送、で宜しいのでしょうか? お分かりの方がいたしたら、 宜しくお願いします。

  • su-ta
  • お礼率54% (128/234)

質問者が選んだベストアンサー

  • ベストアンサー
回答No.1

>1:[TCP Dup Ack]の意味は何でしょうか? TCP Dup Ack=TCP Duplicate ACKのことです。Etherealのコメントでは、データの送信側が受信側から同じACK番号が入ったACKを受け取った場合に、このコメントが表示されます。 2:[TCP Retransmission] Request STAT TCPによる再送要求があったことを意味します。 これらのコメントが多発している場合、通信経路において、パケットのロスが発生し、TCPの再送制御が行われていることになります。小数でしたら問題はありませんが、多発している場合は通信効率が著しく低下します。

su-ta
質問者

お礼

早々のご回答、ありがとうございました! この辺のメッセージ集とかが あればいいのですが…

その他の回答 (1)

回答No.2

No.1です。 Etherealのメッセージ集は私も以前探したことがあるのですが、これといったものは見つけられませんでした。 ただ、現在では、そのメッセージの意味は初めて見るものでも、ほぼ意味を理解できるようになりました。Etherealで表示されるInfoの部分には、イーサネット、各種アプリケーションプロトコル、TCPを理解すれば大体のことは分かります。 Etherealを使いこなすのは、先にこれらを理解するのが順序として正しいのだと思い知らされました。 なので、Etherealのコメントからではなく、まずこれらの事を理解することが先だと思いますので、まずこちらを先に勉強されたほうが、Etherealをよりうまく使いこなせると思います。逆に、これらの動きや仕組みを理解していないと、Infoのメッセージでどういうことが起こっていて、何が問題があるのかを理解できないと思います。 もしかしたら、英語だったら詳しく説明しているサイトがあるかもしれませんが、当方英語は苦手なので探し当てることが出来ませんでした。

関連するQ&A

  • etherealのinfo[RST ACK]について

    windowsXP SP2 ノートンインターネットセキュリティ2005 ethereal 0.10.12 WinPcap version 3.1 beta4 フレッツADSL―モデム―パソコン(ルーターつきではない) etherealでモニターしていると妙なログを記録します。 それが、RST ACKなのですが、それで検索したところステルススキャンが出てきました。 少し前から、中国のIPアドレスを発信源とするパケットが自分のパソコンの10000以上のポート番号(TCP)で受信され、そのinfoがRST ACKでした。 しかし、今日はいつもやってくるepmapTCP135での受信に対して、その発信源に対する送信を記録しました。自分の発信したものが、infoでRST ACKでした。しかも送信してきた相手にでした。 このような通信は、ノートンの接続ログには記録されません。 その通信はすぐに終わりましたが、ほかからも同じようなepmapがやってきてもこちらは反応しません。 これをどのように解釈したらよいでしょうか。発信源の大部分は、ノートンのネットワーク部分で遮断しています。 私のようなものがここのカテゴリーで質問するのは場違いですが、よろしくお願いします。

  • BBルータでTCP通信のデータ部が捨てられている?

    インターネット上のServerと自宅PC間でWebを併用したデータ交換をしているのですが、ある限られたデータ部のみ、自宅のBBルータにより毎回捨てられているようで受信できません。 Serverと自宅PC(Client)にEtherealを同時に仕掛けPacketをモニタリングしました。 Server側のLogを見る限り、Serverは該当データを正しく送り、BBルータも正しく受信しているようです。 しかし、Client側のLogを見ると、その部分は Len=0 になっており、ヘッダ部だけのPacketが送信されて来たかのようになっております。 BBルータの設定可能項目では、いたって通常の設定になっており、また、自宅PCはWindowsXP SP2でFirewallはOff、ウィルス対策ソフトもアンインストール状態で実験しております。今回のトラブル以外は全てにおいて不具合は発生しておりません。 何か単純なTCP規則違反に該当しているのではとRFC793も確認したのですが原因がわかりません。 該当部分のEtherealのLogは以下の通りです。 何か大事なことを忘れていそうなのですが、どなたかご教授をお願い致します。 <Server側Log> ※No.292~294は3way handshakeです。 ※()内はTCP詳細部の内容抜粋です。 ※Server側のPortはWeb併用なので80番をそのまま使用。 No. SRC  DIST  Prot  Info 295 Client Server HTTP Continuation or non-HTTP Trafic 296 Server Client HTTP Continuation or non-HTTP Trafic (http > 62327 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=90) 297 Server Client TCP http > 62327 [FIN,ACK] Seq=91 Ack=24 Win=65512 Len=0 298 Client Server TCP 62327 > http [ACK] Seq=24 Ack=92 Win=65535 Len=0 299 Client Server TCP 62327 > http [FIN,ACK] Seq=24 Ack=92 Win=65535 Len=0 300 Server Client TCP http > 62327 [ACK] Seq=92 Ack=25 Win=65512 Len=0 <Client側Log> ※No.295と297~300はServer側Logと矛盾はありません。 No. SRC  DIST  Prot  Info 296 Server Client TCP http > 1157 [PSH,ACK] Seq=1 Ack=24 Win=65512 Len=0 以上

  • SYNが2つ?

    質問が2つあります。    HTTPリクエストのパケットを観察してみたのですが、コードビットがSYNのものが、2つ連続で送信されていました。ACKをみるとレスは最初のパケットに対するものでした。2つも送信する意味はあるのでしょうか?  リクエストするIPアドレスがIPヘッダに含まれていません。 (Proxy使用)これはどうやって目的のホームページの情報を得ているのでしょうか?

    • ベストアンサー
    • ADSL
  • 【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独自の設定が邪魔をしているのでしょうか?

  • FIN,ACKとACKについて

    はじめまして。5月よりTCPソケット通信を勉強しているものです。 クライアントとサーバーのプログラムを作り試行錯誤しながら動かしているのですが一つ不思議な現象が起きたので質問させて頂きます。 処理が終わり、通信を切断する時なのですが、ソケット通信に関連する書籍やWebページを見ていると接続を切断するときにFIN,ACKを送信して相手側がACKを送信し、FIN,ACKを送信して最後にACKを送信するとなっています。図にすると以下のような感じでしょうか。 PCA       PCB FIN,ACK送信 → FIN,ACK受信 ACK受信   → ACK送信 FIN,ACK受信 → FIN,ACK送信 ACK送信   → ACK受信 この手順でPCA,PCBともに切断されるとあるのですが、自分が作ったプログラムを実行させて、etherealでパケットをモニタリングすると以下のような状態で終わってしまいます。 PCA       PCB FIN,ACK送信 → FIN,ACK受信 FIN,ACK受信 → FIN,ACK送信 ACK送信   → ACK受信 PCAからのFIN,ACK受信に対してのACKの送信が省略されて、いきなりFIN,ACKを送信してしまいます。その後PCAからはACKが返されて終了となります。 プログラム的には希望通り動作しているので問題は無いのですが、なぜ途中のACKが省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。

  • ソケット通信の送受信遅延-02 その後

    前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました ◇正常時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓          以下繰り返り ◇不具合時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  約130msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし ↓  約250msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか?是非アドバイスをおねがいします。

  • ネットワーク遅延について

    お世話になります。 ご面倒かけますが、ご回答頂ければ助かります。 状況を説明させて頂きますと あるプログラム(計算して結果を出力)をネットワーク上で共有フォルダにアクセスして 実行しております。 (1)スタンドアローンで実行(自分のPCにプログラムを保存)すると、実行時間が1~2分 (2)ネットワークの共有フォルダにアクセスして実行した場合 5分~10分かかります。 ※できるだけマスタ配布のような業務が入る為、スタンドアローンでは利用しない方針です なぜこんなに実行時間に差がでるのかという質問を頂いてます。 ネットワーク上のプログラムを実行しているのですから、ある程度遅くなるのは 当たり前です。とは回答しているのですが、理解してもらえません。 WireSharkを利用して、パケットを拾ったのですが ・ TCP Dup ACK ・ TCP Retransmission ・ TCP Previous segment lost 上記のようなパケットを拾いましたが、パケットを分割や再送信を行っているので 遅くなっていると話をしましたが、これがネットワークの問題なのかプログラムの問題か 確認(考え方)するにはどうしたらいいでしょうか? 参考程度でも結構ですので、お願いいたします。

  • パケットの偽装について

    今、ネットワークの勉強をしているのですが、 IPアドレスは偽装が可能だと知りました。 対抗策としてファイアウォールで、 TCP接続要求パケットを拒否すればいいと聞いたのですが、 IPアドレスの様に制御ビットを偽装することって出来ないのでしょうか。 例えば、はじめからACKビットをオンにして送信するとか。。。 どなたかお教えいただけないでしょうか。。。 よろしくお願いいたします。

  • 遅延確認応答について教えてください

    マスタリングtcp/ipという本で勉強しております。 遅延確認応答において、なぜ2パケット受信してから応答を返せば受信バッファが空くのかわかりません。 > ■遅延確認応答 > データを受信したホストがすぐに確認応答をすると小さなウィンドウを返す可能性があります。 > 受信したばかりのデータで受信バッファがいっぱいになっているからです。 この問題を回避するため、実機では2パケット受信するか0.2秒程度待ってから確認応答を出すようになっているようですが、 2パケット目を受信して応答を返しても受信バッファはいっぱいになったままではないでしょうか? 1パケット分ACKを遅延させることによって何が変わるのでしょうか? # ACKの数が減ってネットワーク効率が良くなる点は理解しております。

  • NAT環境で、リクエスト元端末情報はどこに格納されているのでしょうか

    クライアントがルーター経由でリクエストを行った場合、どのクライアントから リクエストが行われたかという情報はどこに格納されるのでしょうか? 例えば、家庭でブロードバンドルーターにパソコンA・パソコンBを接続した環境で、 パソコンAからWEBサイトを閲覧すると、相手のWEBサイトからリクエストが帰ってき ますが、ルーターがそのリクエストをパソコンAに振り分けるための情報がどこに格 納されているのでしょうか? TCPのパケット構造を見ると、ヘッダ部の送信元ポート番号、あて先ポート番号、 シーケンス番号、ACK番号、・・・のいずれにも該当すると思われる項目が見つかりま せん。 ご教示頂けますと幸いです。 よろしくお願いいたします。