取引先のネットワークエンジニアから「７年前に勤めていたIDCでアメリカとTCP通信していたときにファイルが壊れたという事件があった。アメリカとの通信は回線の品質が悪い場合があるので信頼性がない（接続がなかなか終わらない等ではなく「送られてきたファイルが壊れていた」とのこと）」という話を聞き、それまでTCPプロトコルを信頼しきっていたので、疑問に思い調べています。
No.2
662
24
40pt
etherフレームについているＣＲＣは32bitで、ここのチェックをすり抜ける確率はエラーが起こったetherパケットに対して40億分の１。
これをすり抜けるときにはデータは広範囲に変わっているはずなので、TCPのチェックサムの16bitsより十分長いデータが変わるとすると、チェックサムが偶然合う確率は単純に6万分の1。
したがって、etherパケットのエラー数に対して、250兆分の１程度じゃないでしょうか。
ですので、現在のインターネット通信で壊れる確率は相当低いと思います。そもそものエラー自体も少ないでしょうし。
パケットがEtherじゃない経路をとおる場合には、TCPそのものの信頼性はかなり低くなり、2bitエラーが起こっただけでchecksumはすり抜けられます。
こうしてみると、TCPの信頼性は、パケット落ちやパケットの入れ替えが起こったときにリカバリするだけで、基本的なビット誤りに対する信頼性は、物理層にたよってるんじゃないかと思いますですよ。
物理層：エラーがあった場合にパケットを落とす
IP層：なにもしない
TCP層：パケットが落ちたときにがんばる。
No.1
5213
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の間の確率でエラーが起きる（と予想できる）ので
アプリケーションレベルでもチェックサムを持つべきだと論じています。
あまり読み慣れた分野ではないので読み誤っている可能性もありますので
詳細は原文を参照して下さい。
回答ありがとうございます。参考になります。
No.2
66224
ここでベストアンサー
40pt
etherフレームについているＣＲＣは32bitで、ここのチェックをすり抜ける確率はエラーが起こったetherパケットに対して40億分の１。
これをすり抜けるときにはデータは広範囲に変わっているはずなので、TCPのチェックサムの16bitsより十分長いデータが変わるとすると、チェックサムが偶然合う確率は単純に6万分の1。
したがって、etherパケットのエラー数に対して、250兆分の１程度じゃないでしょうか。
ですので、現在のインターネット通信で壊れる確率は相当低いと思います。そもそものエラー自体も少ないでしょうし。
パケットがEtherじゃない経路をとおる場合には、TCPそのものの信頼性はかなり低くなり、2bitエラーが起こっただけでchecksumはすり抜けられます。
こうしてみると、TCPの信頼性は、パケット落ちやパケットの入れ替えが起こったときにリカバリするだけで、基本的なビット誤りに対する信頼性は、物理層にたよってるんじゃないかと思いますですよ。
物理層：エラーがあった場合にパケットを落とす
IP層：なにもしない
TCP層：パケットが落ちたときにがんばる。
回答ありがとうございます。
etherとTCPのエラーチェックを合わせて250兆分の１なんですね。
TCPだけだと信頼性はかなり低いですね。
大変勉強になりました！
dev_zer0
2009/10/16 14:02:57
38
35
b-wind
t-wata
1
2
回答ありがとうございます。
etherとTCPのエラーチェックを合わせて250兆分の１なんですね。
TCPだけだと信頼性はかなり低いですね。
大変勉強になりました！