TCP/IPでは転送されたデータの信頼性を保つためにchecksumを持っていますが、この値が「偶然」一致してしまいデータが欠損してしまう確率はどの程度でしょうか?


取引先のネットワークエンジニアから「7年前に勤めていたIDCでアメリカとTCP通信していたときにファイルが壊れたという事件があった。アメリカとの通信は回線の品質が悪い場合があるので信頼性がない(接続がなかなか終わらない等ではなく「送られてきたファイルが壊れていた」とのこと)」という話を聞き、それまでTCPプロトコルを信頼しきっていたので、疑問に思い調べています。

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2009/10/17 07:34:15
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:rafile No.2

回答回数662ベストアンサー獲得回数24

ポイント40pt

etherフレームについているCRCは32bitで、ここのチェックをすり抜ける確率はエラーが起こったetherパケットに対して40億分の1。

これをすり抜けるときにはデータは広範囲に変わっているはずなので、TCPのチェックサムの16bitsより十分長いデータが変わるとすると、チェックサムが偶然合う確率は単純に6万分の1。

したがって、etherパケットのエラー数に対して、250兆分の1程度じゃないでしょうか。

ですので、現在のインターネット通信で壊れる確率は相当低いと思います。そもそものエラー自体も少ないでしょうし。

パケットがEtherじゃない経路をとおる場合には、TCPそのものの信頼性はかなり低くなり、2bitエラーが起こっただけでchecksumはすり抜けられます。

こうしてみると、TCPの信頼性は、パケット落ちやパケットの入れ替えが起こったときにリカバリするだけで、基本的なビット誤りに対する信頼性は、物理層にたよってるんじゃないかと思いますですよ。

物理層:エラーがあった場合にパケットを落とす

IP層:なにもしない

TCP層:パケットが落ちたときにがんばる。

id:webrecdotjp

回答ありがとうございます。

etherとTCPのエラーチェックを合わせて250兆分の1なんですね。

TCPだけだと信頼性はかなり低いですね。

大変勉強になりました!

2009/10/17 07:33:40

その他の回答1件)

id:TRTr No.1

回答回数52ベストアンサー獲得回数13

ポイント30pt

http://portal.acm.org/citation.cfm?id=347561&dl=GUIDE&coll=GUIDE...

のabstructより


CRCは1/1100〜1/32,000程度でチェックサムに失敗し、

その場合1/40億の確率でCRCで捕まえられないエラーが発生することになるが、

実ケースではそれよりも遥かに多い1/400程度の確率でCRCのエラーが発生しているため

CRCで捕まらないエラーはもっと多いだろう、ということのようです。


その大部分はlink-levelではじかれるだろうけれども

大体1600万分の1〜100億分の1の間の確率でエラーが起きる(と予想できる)ので

アプリケーションレベルでもチェックサムを持つべきだと論じています。


あまり読み慣れた分野ではないので読み誤っている可能性もありますので

詳細は原文を参照して下さい。

id:webrecdotjp

回答ありがとうございます。参考になります。

2009/10/17 07:29:41
id:rafile No.2

回答回数662ベストアンサー獲得回数24ここでベストアンサー

ポイント40pt

etherフレームについているCRCは32bitで、ここのチェックをすり抜ける確率はエラーが起こったetherパケットに対して40億分の1。

これをすり抜けるときにはデータは広範囲に変わっているはずなので、TCPのチェックサムの16bitsより十分長いデータが変わるとすると、チェックサムが偶然合う確率は単純に6万分の1。

したがって、etherパケットのエラー数に対して、250兆分の1程度じゃないでしょうか。

ですので、現在のインターネット通信で壊れる確率は相当低いと思います。そもそものエラー自体も少ないでしょうし。

パケットがEtherじゃない経路をとおる場合には、TCPそのものの信頼性はかなり低くなり、2bitエラーが起こっただけでchecksumはすり抜けられます。

こうしてみると、TCPの信頼性は、パケット落ちやパケットの入れ替えが起こったときにリカバリするだけで、基本的なビット誤りに対する信頼性は、物理層にたよってるんじゃないかと思いますですよ。

物理層:エラーがあった場合にパケットを落とす

IP層:なにもしない

TCP層:パケットが落ちたときにがんばる。

id:webrecdotjp

回答ありがとうございます。

etherとTCPのエラーチェックを合わせて250兆分の1なんですね。

TCPだけだと信頼性はかなり低いですね。

大変勉強になりました!

2009/10/17 07:33:40
  • id:dev_zer0
    checksum自体の誤り訂正検出率は99.5%以上で実はあまり高くない
    が、データリンク層が頑張ってくれている「はず」
     
    > アメリカとの通信は回線の品質が悪い場合がある
    これはTCP/IPの責任ではなくもっと下位層(物理層)の責任だと思う。
  • id:b-wind
    >TCP通信していたときにファイルが壊れた
    その上のアプリケーションレイヤーの問題じゃないの?

    >> アメリカとの通信は回線の品質が悪い場合がある
    >これはTCP/IPの責任ではなくもっと下位層(物理層)の責任だと思う。
    物理層あたりが貧弱というのには同意するが、それでもまともに通信できるようにするために
    TCP というプロトコルがあるわけで。
    レイヤー3以下に責任を押しつけるのは間違いだと思う。
  • id:t-wata
    TCPはストリーミングなんで、送信側が1つのファイルを送っている間に、別のメッセージを送信しようとすると、
    受信側はそれぞれが別々のデータだと判別できないので、別のメッセージがマージされます。
    そういう可能性はないですか?
    TCPのチェックサム衝突より、アプリケーションのバグの可能性の方がずっと高いと思います。
  • id:dev_zer0
    > それでもまともに通信できるようにするために
    > TCP というプロトコルがあるわけで。
    > レイヤー3以下に責任を押しつけるのは間違いだと思う。
    いくら上位が頑張っても下位が誤ったデータを送りつけてきたら
    誤ったデータをそのまま送るしかないわけで...
    その為にHDLCとかのプロトコルがあるんでしょ?
     
    あと、
    > ファイルが壊れた
    通信以外にセクタ不良の可能性もある?
  • id:b-wind
    >いくら上位が頑張っても下位が誤ったデータを送りつけてきたら
    >誤ったデータをそのまま送るしかないわけで...
    いや、それを検知するためにチェックサムやら再送機能がTCPにあるのでそれは違う。
    http://www.atmarkit.co.jp/fnetwork/rensai/tcp12/01.html

    もちろん下位レイヤの信頼性が高いに超したことはないけど
    IP(レイヤー3)の段階ですでに信頼性は放棄してるから。
    http://ja.wikipedia.org/wiki/Internet_Protocol#.E6.A6.82.E8.A6.81
    >IPは自己のインタフェース(ネットワークカードやモデムのこと)からパケットを送出するだけであり、
    >相手まで確実にパケットが届くことに責任を持たない(保証しない)

    極端な話物理層・リンク層がノイズだらけの工場に配置されてようが何だろうが
    (速度はともかく)とりあえずある程度の信頼性を確保するためのプロトコルが TCP

    って、コメント欄ばっかのびて肝心の回答はつかないのな。

  • id:dev_zer0
    IPが放棄しているのは相手に指定した順番でパケットの欠落なしで送信することでしょ?
    TCPではデータの誤り訂正は必要最小限しかせず、
    イーサネットなどの下位レイヤーがデータの誤り訂正の責任を持つのが正しい姿ですし
    実装もそうなっているはずですが、物理層の責任まで負わす気ですか?
     
    > 極端な話物理層・リンク層がノイズだらけの工場に配置されてようが何だろうが
    > (速度はともかく)とりあえずある程度の信頼性を確保するためのプロトコル
    「ある程度」ですよね。
    部下が真面目に仕事してないのに上司がまともな成果を出せるはずが無い。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません