- PR -

TCPの再送処理について

«前のページへ 1|2|3
投稿者投稿内容
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-09-07 23:53
すみませんもう一つ質問があります。
おねがいします。

A送信元、B送信先

Bでtcpdumpを起動しました。
前回投稿させていただきとときのケース2と同じです。
時刻が抜けてたので付け加えました。

・再送ケース2
(1)15:13:35.927604 A > B: . 3886465:3887913(1448) ack 1 win 57920
(2)15:13:37.183372 A > B: . 3890809:3892257(1448) ack 1 win 57920
(3)15:13:35.965065 B > A: . ack 3887913 win 14480
(4)15:13:35.977221 A > B: . 3893705:3895153(1448) ack 1 win 57920
(5)15:13:35.977248 B > A: . ack 3887913 win 14480
(6)15:13:35.977770 A > B: . 3895153:3896601(1448) ack 1 win 57920
(7)15:13:35.977784 B > A: . ack 3887913 win 14480
(8)15:13:35.978568 A > B: . 3896601:3898049(1448) ack 1 win 57920
(9)15:13:35.978581 B > A: . ack 3887913 win 14480
(10)15:13:36.353164 B > A: . ack 3887913 win 28960
(11)15:13:36.353599 B > A: . ack 3887913 win 59368
(12)15:13:37.170826 A > B: . 3887913:3889361(1448) ack 1 win 57920
(13)15:13:37.170955 B > A: . ack 3889361 win 60816
(14)15:13:37.182798 A > B: . 3889361:3890809(1448) ack 1 win 57920
(15)15:13:37.182834 B > A: . ack 3890809 win 60816
(16)15:13:37.183407 B > A: . ack 3892257 win 60816
(17)15:13:37.194835 A > B: . 3892257:3893705(1448) ack 1 win 57920
(18)15:13:37.194874 B > A: . ack 3898049 win 60816
(19)15:13:37.195842 A > B: . 3893705:3895153(1448) ack 1 win 57920
(20)15:13:37.195876 B > A: . ack 3898049 win 63712
(21)15:13:37.196753 A > B: . 3895153:3896601(1448) ack 1 win 57920


(2),(4),(6),(8),(9),(10),(11)と同一のackを7回連続して出しています。

http://www.atmarkit.co.jp/fnetwork/rensai/tcp12/02.html

などでは、同一ackが3回届くと再送するとかかれているのですが、
今回は、7回出しています。他にも、5回、9回、12回、いろいろなack数
の後再送しています。
3回同一ackが届いたら送信元から要求されたパケットを再送するのでは
ないのでしょうか？(12)は(7)の後に送信されるんじゃないのでしょうか？
時刻を見ると、今回は、遅延は考えられないのですが、どうなのでしょうか？

よろしくお願いします。


[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-07 23:55 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-07 23:56 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-07 23:57 ]
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2004-09-11 01:12
同一のACKパケットは (3), (5), (7), (9), (10), (11) ではないでしょうか？

A送信元、B送信先、という事ですが、ACKパケットはBからAへと送信されます。
ですから、これらのパケットは受信したものではなく、送信したものです。

伝送時の遅延というのは、送信元Aからの（送信先のBのWindowsサイズに余裕がある場合の）
連続して送られてくるパケットの時間間隔の長さや揺らぎではありません。

TCPの再送処理を考えるときに一番重要なのは、送信元Aが送信し始めてから
（すると決定してから）、送信先Bが受信し終わるまでに要する時間です。

http://www.atmarkit.co.jp/fnetwork/rensai/tcp12/02.html
のイラストは伝送遅延も分かりやすくてとてもいいと思います。

自宅のクロスケーブルで直結した100M Full-DuplexのWindows XP (Home) と
Linux 2.4 の間でpingを使ってRTTを測定してみました。
Windowsのpingでは1m秒以下としか表示されませんでしたが、
Linuxのpingでは平均220μ秒程度でした。

100M Full-Duplex の帯域をすべて使った場合、1448バイトのデータを含む
TCP/IPパケットを送信するのにかかる時間が120μ秒なので、
TCPにおける伝送遅延の影響が分かってもらえると思います。
（人間の感覚からするとごく短時間ですが ）

受信側も100M Full-Duplexであれば、受信し始めてから受信し終わるまでに
120μ秒かかりますし、ストア・アンド・フォワードのハブやルータが
途中にあればさらに伝送遅延が生じます。
チェックサムの計算も必要なので受信し終わるまで上位層に渡す事ができません。

説明が長くなりましたが、伝送遅延はコンピュータ同士の通信の時間感覚では
結構影響が大きいという事に注意してください。


そのため、再送処理を詳細に調べようとすると、
送受信の両方でパケットキャプチャを行う必要があります。
（伝送遅延だけでなく、パケットが途中で破棄されていないとも限りませんし）

また、3回同じACKパケットを受信すると、再送するというのは実装や
設定パラメータに依存するのではないでしょうか？？

yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-09-11 11:19
cn099さん

>同一のACKパケットは (3), (5), (7), (9), (10), (11) ではないでしょうか？
私の間違いでした申し訳ございません。
詳しく説明していただきありがとうございました。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

2つ質問させていただきたいんですがお願い致します。

1.
http://www.atmarkit.co.jp/fnetwork/rensai/tcp12/02.html
では、受信側において、パケットの順序がそろうまでバッファで保持
されていますが、一体どのくらいまで保持するのでしょうか？

あるパケットがロスして受信側のバッファで順序がそろわないためバッファにパケット
がためられています。そして再送を何回も繰り返しても、その抜けているパケット
が届かない場合、コネクションが切れます。
私の考えは、コネクションが切れるまで順序がそろっていないパケットバッファで
保持されると思うのですがどうなのでしょうか？

2.
>>http://www.atmarkit.co.jp/fnetwork/rensai/tcp12/02.html
>>などでは、同一ackが3回届くと再送するとかかれているのですが、
>>今回は、7回出しています。他にも、5回、9回、12回、いろいろなack数
>>の後再送しています。
>また、3回同じACKパケットを受信すると、再送するというのは実装や
>設定パラメータに依存するのではないでしょうか？？

これなんですが、ある1つのコネクションをはっている間に
起こっているので、設定や実装は、あまり考えられないのです。
他の原因は考えられますでしょうか？

どちらかでもわかる方は教えていただけないでしょうか。

よろしくお願いいたします。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2004-09-11 14:46
引用:

これなんですが、ある1つのコネクションをはっている間に
起こっているので、設定や実装は、あまり考えられないのです。
他の原因は考えられますでしょうか？


送信元Aが送信先Bから規定回数（大抵の実装のデフォルトは3回？）
同一のACKパケットを受け取るとパケットのロスがあったと判断するわけですが、
気をつけなければいけないのは、あくまでもAが同一ACKを受信した回数であり、
Bが同一ACKを送信した回数ではないという点です。

そのため、送信先Bでキャプチャしたデータだけを見ても
送信先AのTCP再送処理の詳細は判断できません。

同一コネクションの同じような（PSHやURGフラグが立っていない）パケットで
伝送遅延にばらつきが出るのは、IPネットワークがバースト的な通信が多く
伝送路の混み具合が急激に変わるからだと思います。

また、CPU使用率が高かったり、ネットワークの負荷が高いと
フレームやパケットの処理がキューにたまり、TCPパケットの
処理が完了するまでの時間が変動する可能性もあります。
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-09-11 21:05
cn009さんいつもありがとうございます。
送信元のデータをとっていないのに質問ばかりしてごめんなさい。

送信元と送信先の両方でパケットをキャプチャしたら質問させていただくことが
あるかもしれません。
またよろしくお願いします。

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-13 20:46 ]
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-09-29 01:21
cn009さんいつもありがとうございます。

また疑問が出たのでわかる方がいたら教えていただけないでしょうか。
受信元でしかtcpdumpを起動できない測定だったのでまた推測になって
しまうかもしれませんがお願いします。
(ftpサイトからデータをダウンロードした際のデータなので受信側でしか
キャプチャーできませんでした。)

送信側と受信側がsackが機能している状態でのTCPの再送処理
について疑問があります。
送信元S、受信側D　(受信側でtcpdumpを起動)

・①通常の再送ケース
(1)S > D: P 2671329:2672697(1368) ack 1 win 5792
(2)S > D: . 2672697:2674065(1368) ack 1 win 5792
(3)D > S: . ack 2674065 win 62928

2674065:2675433がロス

(4)S > D: . 2675433:2676801(1368) ack 1 win 5792
(5)D > S: . ack 2674065 win 62928 sack sack 1 {2675433:2676801}
(6)S > D: . 2676801:2678169(1368) ack 1 win 5792
(7)D > S: . ack 2674065 win 62928 sack sack 1 {2675433:2678169}
(8)S > D: . 2678169:2679537(1368) ack 1 win 5792
・
・
・
(9)D > S: . ack 2674065 win 62928 sack sack 1 {2675433:2691849}
(10)S > D: . 2691849:2693217(1368) ack 1 win 5792
(11)D > S: . ack 2674065 win 62928 sack sack 1 {2675433:2693217}
(12)S > D: .2674065:2675433(1368) ack 1 win 5792 再送
(13)D > S: . ack 2693217 win 46512
(14)S > D: . 2693217:2694585(1368) ack 1 win 5792


・②問題のある再送
(1)S > D: . 6668921:6670289(1368) ack 1 win 5792
(2)D > S: . ack 6670289 win 62928

6670289～6671657,6671657～6673025,6673025～6674393,6675761～6677129
がパケットがロス

(3)S > D: . 6675761:6677129(1368) ack 1 win 5792 届いているパケット
(4)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6677129}
(5)S > D: . 6677129:6678497(1368) ack 1 win 5792　　届いているパケット
(6)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6678497}
(7)S > D: . 6678497:6679865(1368) ack 1 win 5792　　　届いているパケット
(8)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6679865}
(9)S > D: . 6679865:6681233(1368) ack 1 win 5792
(10)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6681233}

・
・
・
(11)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6688073}
(12)S > D: . 6688073:6689441(1368) ack 1 win 5792
(13)D > S: . ack 6670289 win 62928 sack sack 1 {6675761:6689441}
(14)S > D: . 6670289:6671657(1368) ack 1 win 5792 再送
(15)D > S: . ack 6671657 win 61560 sack sack 1 {6675761:6689441}
(16)S > D: . 6671657:6673025(1368) ack 1 win 5792 再送
(17)D > S: . ack 6673025 win 60192 sack sack 1 {6675761:6689441}
(18)S > D: . 6673025:6674393(1368) ack 1 win 5792 再送
(19)D > S: . ack 6674393 win 58824 sack sack 1 {6675761:6689441}
(20)S > D: . 6674393:6675761(1368) ack 1 win 5792 再送
(21)D > S: . ack 6689441 win 50616
(22)S > D: . 6675761:6677129(1368) ack 1 win 5792 無駄な再送
(23)D > S: . ack 6689441 win 62928 sack sack 1 {6675761:6677129}
(24)S > D: . 6677129:6678497(1368) ack 1 win 5792 無駄な再送
(25)D > S: . ack 6689441 win 62928 sack sack 1 {6677129:6678497}
(26)S > D: . 6678497:6679865(1368) ack 1 win 5792 無駄な再送
(27)D > S: . ack 6689441 win 62928 sack sack 1 {6678497:6679865}
(28)S > D: . 6689441:6690809(1368) ack 1 win 5792
(29)D > S: . ack 6690809 win 62928
(30)S > D: . 6690809:6692177(1368) ack 1 win 5792

sackは選択的に再送するので通常①のようなケースになると思います。
しかし、②のような受信側に届いているはずのパケット((3),(5),(7))が再び
届く((18),(20),(22))理由がわかりません。これが時々観測されます。
（通信距離が離れている場合に多く起こります。）
②の(17)のackが遅延なんかによってタイムアウトが発生した
りすと起こるのでしょうか？タイムアウトが発生したら再び(16)だけが再送されるような
気がします。

都合により受信側のデータしか取ることが出来ないのでないのですがわかる方
教えていただけないでしょうか？
よろしくお願いします。

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-29 01:24 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-29 01:30 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-29 01:31 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-29 01:36 ]

[ メッセージ編集済み 編集者: yshita 編集日時 2004-09-29 02:05 ]
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-10-07 17:27
このレスで少し前に上がったLinuxでの/proc/sys/net/ipv4/tcp_retries1
(デフォルト値3)について疑問があります。
(TCPによる再送について)

>/usr/src/linux-2.4.18/Documentation/networking/ip-sysctl.txt

>tcp_retries1 - INTEGER
>How many times to retry before deciding that something is wrong
>and it is necessary to report this suspection to network layer.
>Minimal RFC value is 3, it is default, which corresponds
>to ~3sec-8min depending on RTO.

これを読むと"tcp_retries1 回だけ再送してもダメだったら
IP層に問題を報告する"みたいなことを書いてあります。
IP層に問題を報告して経路を更新してるというのは
わかるのですが、そもそもTCP層がIP層にどのようにして報告
するのでしょうか？TCPヘッダとかを見てもそのような機能は
無いような気がするのですがどうなのでしょうか？
TCP／IPについての質問になってしまいましたが分かるかたは
ご教授お願いします。
«前のページへ 1|2|3

スキルアップ／キャリアアップ（JOB@IT）