- PR -

FTP通信の信頼性について

1
投稿者投稿内容
osariban
会議室デビュー日: 2003/05/16
投稿数: 2
投稿日時: 2003-05-16 20:29
はじめまして、FTP(TCP)について疑問なところがあります。
ネットワークに詳しい方が居られそうなので、返信頂けたら有り難いです。

疑問点は、皆さん経験があると思いますが、
WEBからのFTP(TCP)でのダウンロード失敗することがあります。
(開いてみたら文字化けを起こしていた等)
なぜ失敗したか?の理由です。

私のTCP(FTP)通信の信頼性についての理解のなのですが、
チェックサム、ARQ、トランスポート層のビットエラーチェック
(PPPにしてもIEEE802.3にしても)等の機能によって
TCPのコネクションが途中で切れなければビットエラーは
起こらず100%正確な通信ができるプロトコルと認識しております。

現在私の失敗原因の考えは
TCPのコネクションが途中で切れた為だと思っていますが、
間違ってる!ほかの原因がある等ご意見頂けたらと思っております。

長くなりましたが、よろしくお願い致します。



郵便来たす
会議室デビュー日: 2003/04/04
投稿数: 5
投稿日時: 2003-05-16 21:10
詳しくはないですが...

>疑問点は、皆さん経験があると思いますが、
>WEBからのFTP(TCP)でのダウンロード失敗することがあります。
>(開いてみたら文字化けを起こしていた等)

転送モード(ASCII/IMAGE)が違ってるとか漢字コード違ってるとかない
ですか?

>なぜ失敗したか?の理由です。

ここでいう失敗とはFTPではデータの転送が完了していてそのファイル
が壊れている場合の話ですか?それともTCP接続が途中で切れる話ですか?

どちらにしても、TCPだから100%間違いないというのはないと思って
いますが。実用上は問題にならないでしょうが、理論的にはTCPでも
データが壊れることがあると思っています。(2バイトデータの入れ
替えとか)>識者の方、間違ってたら指摘願います。

あとはFTPアプリケーションのバグとか。
osariban
会議室デビュー日: 2003/05/16
投稿数: 2
投稿日時: 2003-05-16 21:51
こんばんは。
お忙しいところ返信頂き有難うございました!

>転送モード(ASCII/IMAGE)が違ってるとか漢字コード違ってるとかない?

 転送モードの間違いは無い場合でです。

>ここでいう失敗とはFTPではデータの転送が完了していてそのファイル
>が壊れている場合の話ですか?それともTCP接続が途中で切れる話ですか?

 「FTPではデータの転送が完了していてそのファイルが壊れている場合の話」で
 お願い致します。

>理論的にはTCPでも データが壊れることがあると思っています。
>(2バイトデータの入れ 替えとか)>識者の方、間違ってたら指摘願います。

  「2バイトデータの入れ替え」ですか。
  すみません勉強不足で初耳です。
  これは、トランスポート層のビットエラー検知機能、
  TCP又はIPヘッダーのチェックサムでエラーと認識
  されないものなのでしょうか?

返信頂けると有り難いです、よろしくお願いいたします。

 
郵便来たす
会議室デビュー日: 2003/04/04
投稿数: 5
投稿日時: 2003-05-17 00:30
>  「2バイトデータの入れ替え」ですか。
>  すみません勉強不足で初耳です。
>  これは、トランスポート層のビットエラー検知機能、
>  TCP又はIPヘッダーのチェックサムでエラーと認識
>  されないものなのでしょうか?
表現が不適切ですみません。

計算の詳細を忘れてしまいいい加減ですが、TCPやUDPやIPの
チェックサムは確か同じ計算方法だったと思います。

16ビット単位の計算を行っていて、データ列中のある部分と
別の部分を16ビット単位で入れ替え(16ビット境界)を行って
もチェックサムの値(16ビット)は同じになると思います。

またIPはヘッダのみのチェックサムなのでデータ部分はチェック
出来ません。(IPv6は知りませんが)

「トランスポート層のビットエラー検知機能」というのは
TCPやUDPのチェックサムにならないですか?

EthernetのFCSの場合はもう少し強力なチェックがかかると思い
ますが、これでも100%ではないでしょう。(所詮、32ビット値で
すから同じ値になる場合が存在するはず)
TCPやUDPのチェックサムと組み合わせればかなりのものは検出で
きると思います。実際の組み合わせを考えたことはないですが。

Uchikoshi
@ITエディタ
会議室デビュー日: 2001/07/27
投稿数: 197
投稿日時: 2003-05-18 22:51
 FTPやTCPプロトコルの定義に問題があってデータが化ける、というような
ことはほとんどないのではないでしょうか。チェックサムやFCSの計算原理上、
可能性は0ではありませんが、ほかの要因に比べれば、無視してもいいくらいの
確率だと思います(あっ、でもSLIP使ってたときは、よくやられてたという
気がしないでもないが ^^;;)。

そうではなく、TCP/IPのプロトコルスタックやFTPアプリケーションの実装が
おかしくて 化ける、というのはちょくちょくありますよね。
(経路途中のルータなどの)NATやNAPTの 実装ミスなどによって化けたりとかも
ありますし、ネットワークの混雑などによって コネクションが途中で切れ、
ファイルが短くなるとかいうのもよくある話です。
特に新しいファームウェアや新しいプロトコル・スタックのドライバなどは、
何があってもおかしくないですので、しばらくは様子を見たいところです。


でもファイルの内容が化ける一番の原因は、たぶんキャッシュ・サーバとか
キャッシュ・システム、そしてFTPのサーバやクライアントの不具合という
ところではないでしょうか? 特に高負荷時の。

現在では、単にFTPでファイルを取得しているつもりでも、実際には、経路の途中に
さまざまなキャッシュシステムが入っているのが普通です。ローカルのIEなどでも
キャッシュされているし、途中にプロキシサーバが(何段も)入っていたり、
サーバ側でも負荷分散や冗長性確保などのために(多数の分散)キャッシュ
システムなどが入っています。
もちろんアドレス変換などもたくさん使われています。だからどこかのキャッシュ・
システムやアドレス変換などで問題が発生すると、データが化けたりします。
またひょっとすると、FTPサーバが過負荷でバグってエラーのあるコンテンツを
返しているのかもしれません。場合によってはコンテンツの内容をチェックする
ウイルスチェッカが悪さしているかも知れませんし。

例えば昔使っていた、とあるUNIX上のキャッシュシステムは、コネクションが増えると
バグって、返されるファイルの内容が化けたりしてました(別にUNIXに限りませんし、
いまだってよく聞く話ですが)。
プロセスあたりのファイルのオープン数の制限やソケットの制限、ファイルや
フォルダ数の制限、利用できるメモリの制限など、いろいろな制限にひっかかった場合に、
バグが顕在化して、あらぬキャッシュ結果を返したりしていました。
ユーザーが増えると、トラフィックやタイムアウト待ちのコネクションも増え、
結果としていろいろなリソースが不足を起こして、状態が変になっていた
みたいです。

というわけで、データが化けるのはプロトコルの定義の問題じゃなくて、
システムやネットワークに過負荷がかかった場合に出るバグのせい、
というところではないでしょうか?
ぴーのすけ
会議室デビュー日: 2003/04/04
投稿数: 3
投稿日時: 2003-05-19 23:39
こんにちは。
私も以前FTPを使ってファイルのダウンロードは完了したが、実際にそのダウンロードしたデータが使えなかった経験があります。

ブロードバンドルータのNAPT処理は次のように行われると思います。
 1. サーバからTCPデータを受信する
 2. NAPT処理でアドレス・ポート番号の変換を行う
 3. IPヘッダ、TCPヘッダのチェックサムを計算する
 4. クライアントへ送信する

で、私の使っていたルータは以下の動作をしていたと推測しています。
 1.ではルーティングするパケットなのでチェックサムのチェックを行なわない。
 3.のチェックサムの計算をチェックサム対象領域すべてから再計算する。
つまり、1.でチェックサムエラーのパケットがあっても3.で再計算することでチェックサムが正しくなっていました。

1. の時点でチェックサムエラーのパケットを破棄する、あるいは3.の計算を変化したアドレス・ポート部分の差分だけをもともと受信したチェックサムに反映させるものであればこのような現象は発生しなかったと思います。


ヒデ
ベテラン
会議室デビュー日: 2002/12/12
投稿数: 76
お住まい・勤務地: 横浜
投稿日時: 2003-05-20 09:10
>そうではなく、TCP/IPのプロトコルスタックやFTPアプリケーションの実装が
>おかしくて 化ける、というのはちょくちょくありますよね。
 FTP ではありませんが、以前メールサーバーの不具合で添付ファイルの
 データ抜けを経験しています。
 <添付ファイルのベース64部分に抜けが発生>

 メールサーバなんてあまり疑わなかったのですが、他に原因が考えられず
 サーバーの前後でデータをキャプチャし、切り分けをしました。

 FTPやSMTPに限らず、途中のアプリで誤動作することは
 よくある話なんでしょうね。
1

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