- PR -

FTP DATA転送について

投稿者投稿内容
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-07-24 01:32
もしかすると、NAPTルータでFTPのPORTコマンドを書き換えたりする処理のために
データ・コネクションを利用するコマンドが遅いのかとも思いましたが、
見落としていることがありました。

引用:

・LISTやXPWD等のFTPコマンドの応答が遅い(3〜10sec待たされます)



とありますが、LISTやNLSTだけでなく、XPWD等でも応答が遅いのでしょうか?
そうだとすると、ネットワーク以外に遅い理由がありそうです。

また、LIST等が遅いというのはどの段階で遅いのでしょうか?
データ・コネクションが確立するまで(PORTに「200 Data port connected」等が返ってくるまで)でしょうか?
それとも、LISTコマンドそのもの(LISTに「226 Transfer finished successfully」等が返ってくるまで)でしょうか?

やはり
引用:

・頻繁に「425 Unable to build data connection: Address already in use」が出ます


は気になりますね。
standaloneモードなのにこのエラーが出るのは何ででしょうかねぇ。
bind()したファイル・ディスクリプタを複数の送信先へのconnect()に使った場合の
挙動が違ったりするんでしょうかね。

p.s.
2005-07-23 21:14 の私の書き込みの「Address already use」は
「Address already in use」の間違いです。
wiz
会議室デビュー日: 2005/07/23
投稿数: 11
お住まい・勤務地: 東京:恵比寿
投稿日時: 2005-07-24 12:02
おはようございます。(徹夜明けなのでこんばんわ?)

いろいろと試した結果、クライアント側のMRUという設定値が1414になっていたので1454にした所、
「425 Unable to build data connection: Address already in use」
が出なくなりました。
他の場所からの通信のテストはまた後ほどやってみます。

□遅い通信
FTP-dataポートを使う通信全般的に遅いみたいです。
・LIST、XPWD、TYPE A等の反応が遅い
・RETR等の転送系は転送速度が極端に落ちる物とそうでない物とがあります。

□遅くなるタイミング
>LIST
>150 Opening ASCII mode data connection for file list
ここが遅い
>226 Transfer complete.

実際に転送する部分が遅いみたいです。
cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-07-24 14:19
こんにちは。

引用:

いろいろと試した結果、クライアント側のMRUという設定値が1414になっていたので1454にした所、
「425 Unable to build data connection: Address already in use」
が出なくなりました。



試されたのは、ルータ1台をはさんだだけの環境ですか?
MRUはMTUのtypoでしょうか?
MTUの設定が影響するとは意外です。
エラーが出たときにnetstatで見るとFIN_WAIT等が大量に残っていたり・・・しませんよねぇ。
bind()とは関係なく、コネクション管理用のテーブルの関係だったりするのでしょうかねぇ。

引用:

FTP-dataポートを使う通信全般的に遅いみたいです。
・LIST、XPWD、TYPE A等の反応が遅い
・RETR等の転送系は転送速度が極端に落ちる物とそうでない物とがあります。



XPWDはデータ・コネクションを使用しませんし、TYPEもそれ自体は使用しませんよ。

転送系で転送速度が物によって異なるというのは規則性のようなものがあるのでしょうか?
バイナリ転送なら速いけど、アスキー転送なら遅いとかでしょうか?

引用:

>LIST
>150 Opening ASCII mode data connection for file list
ここが遅い
>226 Transfer complete.



転送が遅いのかリストの生成が遅いのかが分からないですが、
XPWDやTYPEが遅いというのを考えると、リストの生成も時間かかっていそうな気がします。
wiz
会議室デビュー日: 2005/07/23
投稿数: 11
お住まい・勤務地: 東京:恵比寿
投稿日時: 2005-07-24 14:30
>試されたのは、ルータ1台をはさんだだけの環境ですか?
違います。Internet経由の環境です。

>MRUはMTUのtypoでしょうか?
違います。
「Maximum Receive Unit」
の略でMTUとは別物です。

>MTUの設定が影響するとは意外です。
>エラーが出たときにnetstatで見るとFIN_WAIT等が大量に残っていたり・・・しませんよねぇ。
MTU値が少ない場合はMTUブラックホール現象みたいになるみたいですよ

>bind()とは関係なく、コネクション管理用のテーブルの関係だったりするのでしょうかねぇ。
その辺はよくわからないんですよ。。。

>転送系で転送速度が物によって異なるというのは規則性のようなものがあるのでしょうか?
>バイナリ転送なら速いけど、アスキー転送なら遅いとかでしょうか?
転送で遅い物には規則性はないですね。
ASCIIの物もBinaryの物も遅くなります。

>転送が遅いのかリストの生成が遅いのかが分からないですが、
>XPWDやTYPEが遅いというのを考えると、リストの生成も時間かかっていそうな気がします。
LIST対象物としてはディレクトリ一つ。とかなので検索に時間がかかる様な物でなくても同じようになります。

cn009
ベテラン
会議室デビュー日: 2004/05/13
投稿数: 72
投稿日時: 2005-07-24 22:26
引用:

>MRUはMTUのtypoでしょうか?
違います。
「Maximum Receive Unit」
の略でMTUとは別物です。



そのような設定が出来るものもあるのですね。勉強になります。
TCPだとコネクション確立時にMSSをやり取りするので不要なのではと思いましたが
http://www.atmarkit.co.jp/fnetwork/netcom/netcom02/netcom01.html
によると、PPP等では使われたりするのですね。

引用:

>MTUの設定が影響するとは意外です。
>エラーが出たときにnetstatで見るとFIN_WAIT等が大量に残っていたり・・・しませんよねぇ。
MTU値が少ない場合はMTUブラックホール現象みたいになるみたいですよ



実際に使えるよりも大きな値が設定されていて、特定のICMPが遮断されていればなるようですね。
ブラックホールになっていれば「Address already in use」のエラーの前に、
特定のディレクトリのファイルリストが得られず、タイムアウトになったりすると思います。
データが小さくてそうならない場合は、問題なく通信が完了するはずですし。

でも、ブラックホールにならなくてもデータ量がMSSより大きいと、
正常な通信開始までに多少時間がかかるかもしれません。
念のためにping等で実際の経路のMTUを調べてみた方が良いかもしれませんね。

引用:

>転送系で転送速度が物によって異なるというのは規則性のようなものがあるのでしょうか?
>バイナリ転送なら速いけど、アスキー転送なら遅いとかでしょうか?
転送で遅い物には規則性はないですね。
ASCIIの物もBinaryの物も遅くなります。



う〜ん、原因が思いつきません。

あまりお役に立てずすみません。
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-07-25 01:48
パケットをキャプチャして、TCP層・FTP層それぞれでどういう
動作をしているかひとつひとつ地道に追って行かないと、
なかなか分からなそうな気がするです。

# こういう症状ではないですが、TCP層が腐っていてFTPが
# *ときどき*失敗する、なんてのにぶつかった経験があります。
wiz
会議室デビュー日: 2005/07/23
投稿数: 11
お住まい・勤務地: 東京:恵比寿
投稿日時: 2005-07-28 23:00
こんばんわ。
まだまだいろいろ試し中なのですが原因が見つかっていません;;

今の構成は
Internet-----RT------Server
|
RT------PC
とし、サーバと同一回線を使うようにしてあります。
この状態でわかったことが「web表示も遅い」事です。

FTPだけでなくwebまで遅く。。。

プロバイダにも症状を伝えて確認をした所ルータかサーバでは?との事。
ローカルLANだったらサーバには全く問題ないんですけどね。。。(汗

で、今気になってるのが「pingのロスが発生している」です。
外部からサーバ等にpingをすると10〜20%のロスがあるみたいです。

もうルータの設定もサーバの設定も思いつくところは全部やりました。
もしこの症状の原因わかる方いらっしゃいましたらぜひぜひご教授下さい;;
ぽんす
ぬし
会議室デビュー日: 2003/05/21
投稿数: 1023
投稿日時: 2005-07-28 23:56
どういう構成なのかわからんですが。

「たいしてトラフィックもないのに大量にパケットロスする」
というのはほとんどの場合、full duplex / half duplex が
合っていないのが原因。
auto negotiation を信用してはダメ。実際にどういう設定に
なっているか確認することが必須。

スキルアップ/キャリアアップ(JOB@IT)