- - PR -
Rawソケット用いてパケット再送の測定
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2004-07-24 21:31
送信元ー＞インターネットー＞送信先
というネットワーク構成で、TCPを用いてパケットを 送り、どのくらいパケットの再送が起こるか、計る実験 したいと考えています。 Rawソケットを用いて、送信元で同じシーケンス番号を 複数送ったら再送がかかっていると考え、Rawソケット を用いたプログラムを作ろうと思っています。 この方式だとうまく測定できないのでしょうか？ もしくは、他にいい方法があるのでしょうか？ 知っている方がいたら教えていただけないでしょうか。 よろしくお願いします。 |
|
投稿日時: 2004-07-24 23:30
できると思いますよ。
UNIX系の前提でお話をしますが、 送信元で、観測対象となるSOCK_STREAMで通信するプログラム以外に、SOCK_RAWソケットを使うプログラムを起動させ該当TCPストリームのシーケンス番号を記録させればいいでしょう。 SOCK_RAWでなく、libpcap等を使った方が簡単かもしれません。 規模などにもよりますが、わざわざプログラムを作らなくても、tcpdumpやethereal等のソフトウェアを用いてパケットをモニタリングし、TCPコネクションごとに分析するだけでも良いかもしれません。 送信元で計測しても良いですし、送信先で計測しても良いです。途中のスイッチ等にミラーポートを設けて別のコンピュータで計測することもできます。 予算があれば、商用のネットワークアナライザやベンチマークハードウェアを買うという選択肢もあります。広帯域での計測に対応できるもの、負荷をかけながら計測できるものなど色々あります。 |
|
投稿日時: 2004-07-25 00:18
「ありゃ、TCP や UDP だったらカーネルは raw socket には渡さない
のでは？」と思いきや、2.2 以降（？）の Linux だと packet socket で 拾えるんですね。勉強になりました。 # 私と同様、知らない方へ： man 7 packet ## でもやっぱり、raw socket じゃないですよね。 ## socket_type は SOCK_RAW ですが。 楽にできるのは、やはり tcpdump を使う手ですね。 再送している様子はデフォルトオプションでもわかります。 [ メッセージ編集済み 編集者: ぽんす 編集日時 2004-07-25 00:24 ] |
|
投稿日時: 2004-07-25 16:32
きつねさん、ぽんすさん、いろいろ教えていただき
ありがとうございました。 tcpdumpを使うことにしました。こんないいものが あったとは知りませんでした。 [ メッセージ編集済み 編集者: yshita 編集日時 2004-07-26 01:09 ] |
|
投稿日時: 2004-07-27 12:46
たびたび質問して申し訳ないんですが、
送信元から送信先に指定したデータサイズを送信する プログラムをTCPソケットを用いて作成しました。 そして、送信元でtcpdumpを起動し、シーケンス番号 を確認し、再送が起こっているか確認しています。 送信元から60KBを越えるデータを送信すると、tcpdumpで tcpdump -n src host 192.168.1.106 12:28:08.297836 192.168.1.106.47330 > 192.168.1.56.9000: . ack 385152707 win 5840 <nop,nop,timestamp 7230328 706029> (DF) 12:28:08.346470 192.168.1.106.47330 > 192.168.1.56.9000: . 0:1448(1448) ack 1 win 5840 <nop,nop,timestamp 7230333 706029> (DF) ・ ・ ・ 12:28:08.703168 192.168.1.106.47330 > 192.168.1.56.9000: . 53576:55024(1448) ack 1 win 5840 <nop,nop,timestamp 7230369 706069> (DF) 12:28:08.704790 192.168.1.106.47330 > 192.168.1.56.9000: P 55024:56472(1448) ack 1 win 5840 <nop,nop,timestamp 7230369 706069> (DF) 12:28:08.823549 192.168.1.106.47330 > 192.168.1.56.9000: . 56472:57920(1448) ack 1 win 5840 <nop,nop,timestamp 7230381 706070> (DF) 12:28:08.823572 192.168.1.106.47330 > 192.168.1.56.9000: . 57920:59368(1448) ack 1 win 5840 <nop,nop,timestamp 7230381 706070> (DF) 12:28:08.827585 192.168.1.106.47330 > 192.168.1.56.9000: . 59368:60816(1448) ack 1 win 5840 <nop,nop,timestamp 7230381 706082> (DF) 12:28:09.082000 192.168.1.106.47330 > 192.168.1.56.9000: . ack 1 win 5840 <nop,nop,timestamp 7230407 706086> (DF) 12:28:09.521998 192.168.1.106.47330 > 192.168.1.56.9000: . ack 1 win 5840 <nop,nop,timestamp 7230451 706107> (DF) 12:28:10.401997 192.168.1.106.47330 > 192.168.1.56.9000: . ack 1 win 5840 <nop,nop,timestamp 7230539 706151> (DF) 12:28:12.161996 192.168.1.106.47330 > 192.168.1.56.9000: . ack 1 win 5840 <nop,nop,timestamp 7230715 706239> (DF) と結果が出てしまいます。 100KBを送信したとしても、60KBを少し越えたところで毎回、それ以降の データが送信されていないようなのです。 実験環境としては、 送信元-->ハブ-->送信先です。 機器の性能は悪くないので、原因が何か分からず困っています。 ソケットプログラムが間違っているのかもしれませんが。 どなたか教えて頂けないでしょうか。 宜しくお願いします。 [ メッセージ編集済み 編集者: yshita 編集日時 2004-07-27 12:48 ] |
|
投稿日時: 2004-07-27 14:58
Ｗｅｂ検索
パケット最大長 では？ |
|
投稿日時: 2004-07-27 16:27
TCPが再送しているかどうかどうかを知りたければ、
単に netstat -s で統計値を表示させ、TCPの中にある 「…retransmit…」 などという名前のカウンタの値を繰り返し表示させて、 その状態をモニタすればいいのではないでしょうか。 通信プログラムを動作させているときに、このカウンタの値が どんどん増えていくようならば、再送が発生しています。 が、実際には、フロー制御があるので、再送だらけになるという ことはないと思います。データが送られなくなるのは、 単に受信側がデータをうまく受け取っていないから、という ような気がしますが……。通信が「詰まっている」ときのトラフィック の状態などがもう少し詳しく分かるとよいのですが。 |
|
投稿日時: 2004-07-27 19:22
MMX,Uchikoshiさんへ
Uchikoshiさんの言う通り、受信側のプログラム が間違っており、データをうまくうけとっていない ためでした。 MMX,Uchikoshiさん、アドバイスをして頂 きありがとうございました。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。