- PR -

TCPの再送処理について

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-07-23 17:58
>cn009さんへ

tcp_retries1 と tcp_synack_retriesの違いでいいのでしょうか？
引用には、tcp_syn_retriesとtcp_retries1の説明がのせてあったので。



cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2004-07-23 19:17
引用:

tcp_retries1 と tcp_synack_retriesの違いでいいのでしょうか？
引用には、tcp_syn_retriesとtcp_retries1の説明がのせてあったので。


はい、tcp_retries1 と tcp_synack_retries の違いでした。
間違えて tcp_syn_ack と書いたのに気付いて慌ててしまい、
頭が混乱していたようです。

yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-07-24 23:15
>cn099さんへ

/proc/sys/net/ipv4にあるtcp_synack_retiresとtcp_retries1tcp_synack_retires
について調べてみました。

まず、tcp_synack_retries1はコネクションを確立する際の受信側の話です。
また、tcp_retriesは、コネクションが接続された後のデータ配送における話です。

・tcp_synack_retries
TCPにおいてコネクションを確立するためには、送信側からSYNパケットを送り、
　受信側にSYNパケットが届いたら受信側ではSYNACKパケットを送信側に送ります。
　そして、送信側にSYNACKパケットが届くと、送信側はACKパケットを受信側に送る
　ことによりコネクションが確立されます。
　もし、受信側が SYNACKパケットを送信した後，送信側が ACKパケットを送らない
　とどうなるでしょうか?受信側は、一定時間待ってもACKパケットが帰ってこない
と、SYNACKパケットが途中で失われたと判断して SYNACKパケットを再送します。
　tcp_synack_retriesは、TCP コネクションを試みるために、このSYNACKを再送する
　回数です。値は255未満にする必要があり、既定値は5で、約180秒に相当します。

・tcp_retries1
　コネクションが確立されている接続上において、TCPがネットワーク層（IP層）
　にエラーの原因を報告せずに同じ再送方法で再送を試みる回数である。再送回数
　がtcp_retries1を越えると、まず最初に、新しい再送を送る前に、可能ならば、
　ネットワーク層（ネットワーク層は、パケットのルーティングを行っている。）に
　経路を更新させる。デフォルトは3です。
　
tcp_synack_retriesはあっていると思うんですが、tcp_retires1の
「ネットワーク層へのエラー報告」というのが少しあいまいです。

あまりお役に立てなくてすみません。

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

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

[ メッセージ編集済み 編集者: yshita 編集日時 2004-07-24 23:23 ]
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2004-07-28 22:49
引用:

・tcp_synack_retries
TCPにおいてコネクションを確立するためには、送信側からSYNパケットを送り、
　受信側にSYNパケットが届いたら受信側ではSYNACKパケットを送信側に送ります。
　そして、送信側にSYNACKパケットが届くと、送信側はACKパケットを受信側に送る
　ことによりコネクションが確立されます。
　もし、受信側が SYNACKパケットを送信した後，送信側が ACKパケットを送らない
　とどうなるでしょうか?受信側は、一定時間待ってもACKパケットが帰ってこない
と、SYNACKパケットが途中で失われたと判断して SYNACKパケットを再送します。
　tcp_synack_retriesは、TCP コネクションを試みるために、このSYNACKを再送する
　回数です。値は255未満にする必要があり、既定値は5で、約180秒に相当します。

・tcp_retries1
　コネクションが確立されている接続上において、TCPがネットワーク層（IP層）
　にエラーの原因を報告せずに同じ再送方法で再送を試みる回数である。再送回数
　がtcp_retries1を越えると、まず最初に、新しい再送を送る前に、可能ならば、
　ネットワーク層（ネットワーク層は、パケットのルーティングを行っている。）に
　経路を更新させる。デフォルトは3です。


わざわざ日本語訳ありがとうございます。
そして、返信が遅くなってすみません。

引用:

tcp_synack_retriesはあっていると思うんですが、tcp_retires1の
「ネットワーク層へのエラー報告」というのが少しあいまいです。

私もこの部分がよく分からなかったんです。

IP等のL3実装コンポーネント等に連絡して、ルーティングの変更を試みるんですね。

ところで、その原文はどこにあるのでしょうか？
私の手元の /usr/src/linux-2.4.18/Documentation/networking/ip-sysctl.txt
ではそれほど詳しく書かれていません。

（追記）
http://ktarn.www.linux.or.jp/JM/html/LDP_man-pages/man7/tcp.7.html
でしょうか？

# 手元のは man-pages-1.38-1 と man-pages-ja-20011215-1 と古かったのが
# 悪かったみたいです。すみません。

[ メッセージ編集済み 編集者: cn009 編集日時 2004-07-28 23:12 ]

[ メッセージ編集済み 編集者: cn009 編集日時 2004-07-28 23:41 ]
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-08-01 19:32
返信が遅くなってごめんなさい。

tcp_retries1、tcp_synack_retriesについては、cn009さんが書いてあるとおり
以下を参考にしました。

http://ktarn.www.linux.or.jp/JM/html/LDP_man-pages/man7/tcp.7.html

また、SYNACKパケットがどのようなときに再送されるか知りたかったので、
以下のURLの「SYN フラッディング」という題目で書かれている一文を参考
にしました。

http://www.gcd.org/sengoku/docs/NikkeiLinux00-10/tcp-attack.ja.html

コネクション確立の際のの３ハンドシェイクの方法が
わかれば、tcp_synack_retriesについては理解できると思います。

tcp_retries1は、いろいろ調べても、良い資料がないため、
理解がいまだに少しあいまいです。

おやくにたてないでごめんなさい。
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-08-26 20:45
ネットワーク上でTCPによりパケットがどのように再送されるか調べ
る必要があり、tcpdumpを用いて観測したところ理解ができないこと
があったので投稿させていただきました。

Aが送信元でありBが送信先です。
送信先でtcpdumpを起動しました。

・再送ケース1
A > B:. 1074297:1075745(1448) ack 1 win 57920
B > A:. ack 1075745 win 63712
A > B:. 1078641:1080089(1448) ack 1 win 57920
B > A:. ack 1075745 win 63712
A > B:. 1080089:1081537(1448) ack 1 win 57920
B > A:. ack 1075745 win 63712
A > B:. 1075745:1077193(1448) ack 1 win 57920
A > B:. 1077193:1078641(1448) ack 1 win 57920
B > A: .ack 1078641 win 60816

この場合、1075745〜1078641まで2つのパケットがロスして
いるため2つのパケットだけが再送がかかっています。

・再送ケース2
A > B:. 3886465:3887913(1448) ack 1 win 57920
B > A:. ack 3887913 win 14480
A > B:. 3893705:3895153(1448) ack 1 win 57920
B > A:. ack 3887913 win 14480
A > B:. 3895153:3896601(1448) ack 1 win 57920
B > A: . ack 3887913 win 14480
A > B:. 3896601:3898049(1448) ack 1 win 57920
B > A: . ack 3887913 win 14480
B > A: . ack 3887913 win 28960
B > A: . ack 3887913 win 59368
A > B:. 3887913:3889361(1448) ack 1 win 57920
B > A: . ack 3889361 win 60816
A > B:. 3889361:3890809(1448) ack 1 win 57920
B > A: . ack 3890809 win 60816
A > B:. 3890809:3892257(1448) ack 1 win 57920
B > A: . ack 3892257 win 60816
A > B:. 3892257:3893705(1448) ack 1 win 57920
B > A: . ack 3898049 win 60816
A > B:. 3893705:3895153(1448) ack 1 win 57920
B > A: . ack 3898049 win 63712
A > B:. 3895153:3896601(1448)ack1 win 57920

この場合、3887913〜3893705まで4つのパケットが
再送されています。
これはわかるのですが、その後何故、届いているはずの
3893705〜3896601も続けて送っているのでしょうか？
この後、普通に3896601からデータを続けて送ります。
上記の再送ケース1では、ロスしたパケットだけ再送して
いるのに、ケース2では届いたはずのパケットまでもう一度
送っているのでしょうか？

その原因を教えていただけないでしょうか？
よろしくお願いいたします。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2004-08-29 17:46
説明しやすくするために番号を振ってみました。

・再送ケース2
(1) A > B:. 3886465:3887913(1448) ack 1 win 57920
(2) B > A:. ack 3887913 win 14480
(3) A > B:. 3893705:3895153(1448) ack 1 win 57920
(4) B > A:. ack 3887913 win 14480
(5) A > B:. 3895153:3896601(1448) ack 1 win 57920
(6) B > A: . ack 3887913 win 14480
(7) A > B:. 3896601:3898049(1448) ack 1 win 57920
(8 ) B > A: . ack 3887913 win 14480
(9) B > A: . ack 3887913 win 28960
(10) B > A: . ack 3887913 win 59368
(11) A > B:. 3887913:3889361(1448) ack 1 win 57920
(12) B > A: . ack 3889361 win 60816
(13) A > B:. 3889361:3890809(1448) ack 1 win 57920
(14) B > A: . ack 3890809 win 60816
(15) A > B:. 3890809:3892257(1448) ack 1 win 57920
(16) B > A: . ack 3892257 win 60816
(17) A > B:. 3892257:3893705(1448) ack 1 win 57920
(18) B > A: . ack 3898049 win 60816
(19) A > B:. 3893705:3895153(1448) ack 1 win 57920
(20) B > A: . ack 3898049 win 63712
(21) A > B:. 3895153:3896601(1448)ack1 win 57920

引用:

その後何故、届いているはずの
3893705〜3896601も続けて送っているのでしょうか？


それは (19) や (21) の事でしょうか？
Aでキャプチャしたデータが無いので、あくまでも推測ですが
(18) のパケットがAに届く前に送信されたパケットだと思います。
また、(18) や (20) のACKパケットが途中で消えた可能性もあります。

Aが (19) や (21) を送信したときに (18) が届いていなければ
3898049 から送信すれば良いという事を知らないので
(17) の続きを送信する事になります。

(4) のACKパケットを送信した後、(5) や (7) のパケットを受信しているので
送信してから相手に届くまでタイムラグがあると推測されます。
空きWindowサイズも影響するはずですが、14480バイトあるので
あまり影響は無いと思います。


端末のドライバはフレームを受信し終わってから
上位層のIP層などに渡すのでケーブル直結でも遅延が生じます。
また、フレームの破損を検出できるストア・アンド・フォアード方式の
スイッチなどは受信し終わってから送信するのでここでも遅延が生じます。

余談ですが、10Mのイーサネットの場合、1ビットを送信する時間は
100ナノ秒なので、1448バイトのデータを含むTCP/IPパケットを
Ethernetフレームで送信する間隔は最短では
　{ 1448(データ) + 20(TCPヘッダ) + 20(IPヘッダ) + 14(MACヘッダ)
　　+ 4(FCS) + 8(プリアンブル) + 12(フレーム間ギャップ) } * 8(ビット) * 100ナノ秒
　= 1526(バイト) * 8(ビット) * 100(ナノ秒)
　= 約1.22ミリ秒
となります。
100Mのイーサネットの場合はこの1/10になります。
ギガビットの場合はジャンボフレームとかあるので
・・・省略です。（本当は勉強中です ）



[ メッセージ編集済み 編集者: cn009 編集日時 2004-08-29 17:49 ]

[ メッセージ編集済み 編集者: cn009 編集日時 2004-08-29 17:51 ]
yshita
常連さん
会議室デビュー日: 2004/07/05
投稿数: 34
投稿日時: 2004-08-30 14:23
cn099さんいつも教えていただきありがとうございます。
問題点が解消されました。

受信側では、(3),(5)と(19),(21)は同一パケットですが、
採用しているのは、(3),(5)の方で(19),(21)は破棄し
ているんですよね？

また、質問させていただくことがあるかもしれませんが
そのときはよろしくお願いいたします。
«前のページへ 1|2|3 次のページへ»

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