- 締切済み
パケットドロップの発生について
こんにちは。 現在、専用線にて他社とEDIを行っています。 こちらからデータを全銀TCP/IPにて送信しています。 まれに通信障害が発生し、先方からはパケットがドロップしている と回答がありました。 提示された通信トレースをみると、確かにTCPでフラグメントされた 最後の数バイトが欠けていました。 こうした障害はどのような場合に起こるのでしょうか？ 通信途中に壊れてしまったり、形を変えてしまったりして、正しく ないパケットになってしまうことがあることは認識しておりますが、 定期的に発生するわけではなく、月に2、3度です。 まず、何を疑い、どのような改善を施せばよいのでしょうか？ 原因を追究できる良い手段はありますか？ 情報有りましたら、よろしくお願いします。
- YT0925
- お礼率56% (21/37)
- その他([技術者向] コンピューター)
- 回答数4
- ありがとう数5
- みんなの回答 （4）
- 専門家の回答
みんなの回答
- junkUser
- ベストアンサー率56% (218/384)
- junkUser
- ベストアンサー率56% (218/384)
●回答の前提条件 フラグメントの後ろのパケットが先に届いてドロップするのは、通信障害の原因として考えられる１つではありますが、今回の件もこれが原因と確定したわけではありません。 原因調査は別途行う必要があります。 ●本題 > 現在、アプリ側で設定しているテキスト長がイーサネット標準MTU > の1500を上回っています。（実際は5000以上） えーと・・・テキスト長が 5000 で、MTUを上回っていた場合、OS自身が複数のパケットに分けるので問題ありませんよ。（これはフラグメントではありません。） OSの送信したMTU 1500 のパケットが通信経路を通過する過程で分割されるのがフラグメントです。 >>「フラグメント化した後ろのパケットのほうが先に届いている」 > この件について、下記のサイトでは、到着順が前後しても相手先の > コンピュータで再構成される（「IPパケットの再構成」）ようなこと > が書かれていますが、どうなのでしょうか？ たとえば、フラグメント パケットを許容しないルーターが経路中にあったり、数年前の Firewall-1 のようにパケットを再構成させずに打ち落とす間抜けなファイアウォールであれば、フラグメント パケットの後部が打ち落とされます。したがって「必ず再構成される保障は無い」と思っていたほうがいいです。 送信元が Windows Server 2003 ならば MTU の変更は簡単ですね。 具体的な値については環境によるとしか言えませんが、たとえばですが、Googleでは通信障害を起こさないようにするため、MTU 値を 1400 に設定しています。なので、Microsoft にはつながらないのに Google だけは表示されるといった現象がまま発生します。
補足
どうもありがとうございます。 先方から提示されたトレースでは、 当方から約4500バイトのデータを送信し、 パケット1 約1400バイト受信 パケット2 約1400バイト受信 パケット3 約1400バイト受信 パケット4 約300バイト受信 このうちパケット1とパケット2が数バイト欠けているというものでした。 先方も私もOSがMTUに合わせて複数のパケットに分けることを フラグメントと誤って解釈して、話が進んでいたようです。 そうですね、原因調査はいずれ時間を絞ってやらなければならないと 思います。 最後の質問となりますが、 先方にはパケット1から4まで届いています。 ですが、パケット1で全てのデータが届かなかったということならば そこでTCPのエラーとなり、通信が異常終了する気がします。 正確にはパケットトレースを見ない限り分からないと思いますが、 ウインドウサイズの影響で、パケット1から4までが途中で異常となら ず送信されていると考えられるでしょうか？ よろしくお願いいたします。
- junkUser
- ベストアンサー率56% (218/384)
> フラグメントが発生することで、通信エラーが起こりやすくなることはあるのでしょうか？ よくあります。 No.1 で例示した、「フラグメント化した後ろのパケットのほうが先に届いている」がそれです。 フラグメント化した後ろのパケットの方が先に届いてもOSは処理できないので無視しますし、ファイアウォールでも遮断してしまいます。 余談ですが、フラグメントの仕様は1990年代から問題視されており、IPv6からはフラグメントを廃止し、初めから最適なパケットサイズで送信するよう仕様が変更されました。したがって、IPv6ではこのような通信障害が起きません。 > フラグメントが発生しないように適切なパケットサイズとするよう、アプリで制御した方が良いような内容のものを見つけました。 MTU 調整、やMTU 変更で検索してみてください。 MTUを調整することでフラグメント化しないパケットサイズにすることができます。 OSが何か分からないので回答はできませんが、どんなOSでも設定方法があるはずです。
補足
どうもありがとうございます。 受け側はWindows 2003 Serverです。 現在、アプリ側で設定しているテキスト長がイーサネット標準MTU の1500を上回っています。（実際は5000以上） ですのでTCPフラグメントが確実に発生している状況です。 このあたりも見直す必要がありそうです。 今まで同一LAN上のPCとのEDIがメインでした。 TCPフラグメントは基本的にルータが行うということのようですので、 テキスト長を大きくしても問題にならなかったのかもしれません。 >「フラグメント化した後ろのパケットのほうが先に届いている」 この件について、下記のサイトでは、到着順が前後しても相手先の コンピュータで再構成される（「IPパケットの再構成」）ようなこと が書かれていますが、どうなのでしょうか？ もし、補足等あればお願いします。 http://www.atmarkit.co.jp/fwin2k/network/baswinlan010/baswinlan010_03.html よろしくお願いいたします。
- junkUser
- ベストアンサー率56% (218/384)
地道に問題の通信経路を絞り込んでいくしかないでしょう。 最低2地点を同時にモニターして、どこまでは通った・通っていないを抑えていきます。 月に2,3度しか無いので時間がかかりそうです。 後は、本当に「月に2,3度しか無いのか？」という点です。 問題が顕在化したのが2,3度ということではないでしょうか？ TCP/IPは通信に異常があれば数回再送リクエストをおくるため 多少遅くなっても正常に通信できる仕様になっています。 つまり、数回の再送リクエストを超えて失敗していると考えることができるため、パケットのドロップはもっと頻繁にあるのではないかと思われます。 ＞こうした障害はどのような場合に起こるのでしょうか？ 羅列すると ・フラグメント化した後ろのパケットのほうが先に届いている ネットワークの負荷が上がると回復するという事象が起きます。 ・コンピュータ自身のドライバーに問題がある ・経路中のケーブル、HUBに問題がある ケーブルに問題があったら、フラグメントに関係なく発生しそうですが・・・ ・ルーターのファームウェアに問題がある たとえば、Yamaha RT 1000 の一時期のファームで、通信が輻輳するとキューに溜め込みすぎてドロップしてしまう不具合がありました。 ファームウェアのアップデートで解決しました。 とりあえず、フラグメントパケットが発生しないように、送信元のコンピュータでMTUを調整してみてはいかがでしょうか。
補足
どうもありがとうございます。 双方でトレースを仕掛ける必要があるということで、合意はしている のですが、時間帯などが絞りきれず、なかなか実現できていません。 ところで、フラグメントが発生することで、通信エラーが起こりやす くなることはあるのでしょうか？ ネットで情報を集めていると、フラグメントが発生しないように 適切なパケットサイズとするよう、アプリで制御した方が良いような 内容のものを見つけました。 もし、情報がありましたらよろしくお願いいたします。
関連するQ&A
- ブロック長について
こんばんは。 TCP/IPの世界ではデータはパケットととして転送され、1回の手続きで 転送が完了しない場合は、分割されて転送されると思います。 アプリケーションによっては、固定長のブロック長を指定でき、 ブロック単位でデータ転送が行われます。 現在、全銀TCP/IPを使用し、通信を行っていますが、稀に通信エラー が発生します。 どうもパケットロスが原因のようなのですが、ブロック長を長くすれ ばするほど、パケットロスと言うのは起こりやすくなるものなのでしょうか？ 現在、全銀推奨の2048以上を指定してます。 他の業務でも全銀TCP/IPを使用していますが、このようなエラーは 発生しておりません。違いがあるのはブロック長の長さです。 回線はISDNを使用しています。
- 締切済み
- その他([技術者向] コンピューター)
- IPフラグメントの結合について
こんにちは。 ネットワーク通信において、IPフラグメントが発生した場合、受信側では、IPヘッダ内の「フラグメントオフセット」フィールドから、受信したパケットが分割されたパケットのどの部分かを特定し、「フラグ」フィールドから、最後のフラグメントかフラグメントの途中かを判定すると思います。 そこで質問なのですが、フラグメント化されたパケットを受信側で再構築する際に、分割されたパケットを全て受信し終えたことを、どこで判断するのでしょうか。 仮に受信したパケットの「フラグ」フィルードが最後のフラグメントだとしても、それ以降に受信順番が逆転してしまったパケットが残っている可能性があります。 また、IPヘッダ内の「ヘッダ長」フィールドは、分割されたサイズが格納されているようなので、分割前の合計サイズは分かりません。 以上、よろしくお願いします。
- ベストアンサー
- ネットワーク
- ＴＣＰヘッダのチェックサムについて
通信エラーが発生し、 エラーが発生した時のパケットのＴＣＰヘッダの チェックサムが"FFFF"だったのですが チェックサムで"FFFF"はありえるのでしょうか？
- ベストアンサー
- その他([技術者向] コンピューター)
- 富士通製EDIソフト Trademasterでエラー
富士通製EDIソフト 「Trademaster V3.0L10 Win NT ワークステーション版」を利用しています。利用環境は、Win NT4 SP4 Workstation+ISDNダイヤルアップ+TA MN128+プロバイダーOCNです。これで、親会社と全銀TCP/IPプロトコルを利用して、データ授受を行おうとしているのですが、送受信しようとするとエラー（コードF002）が発生してしまいます。エラーコードの意味自体は、Helpファイル等で確認したところ、全銀TCP/IPプロトコルサービスの未起動の意味でしたが、コンパネのサービスを確認すると正常に起動しています。親会社の担当者に見てもらっても、設定等や環境は、別の子会社で既に稼動しているものと同様で、原因不明とのことです。まったくハマリ状態です。どなたか、おわかりになる人いらっしゃいますか？
- 締切済み
- その他(業務ソフトウェア)
- WINSOCKでTCPのステータスを調べたい
通信異常が発生するのでwiresharkでパケットモニタするとRetransmissionが発生していました。 そのデータには肯定応答コマンドとモニタコマンドが重複して送信されていました。単純に考えるとRetransmissionのパケットデータはそのままKEEPされてモニタコマンドのパケットとは区別されるような気がするんですが・・・。 そこでTCPが再送状態にあるならば上位からは新たなコマンドを出さないように修正したいと考えていますがいろいろ調べてもステータス取得出来るような物が見つかりません。 ご教授願います。
- 締切済み
- C・C++・C#
- ソフトバンク パケット通信料の課金について
1月20日に911SHを購入しホワイトプランで契約しました。 私は、メールとソフトバンク同士の通話しかしない為 980円+315円+メール料金程度の支払いで済むと思っていました。 しかし、まだ7日しか経過していないのに パソコンからマイソフトバンクでパケット通信料を確認すると500円も使用していました。 パケット通信をした覚えがないのですが、一体どこで課金されているのでしょうか？ 私の行った操作を箇条書きにします。 ・メール送受信 ・メールの新着メール受信 ・サーバーメール操作→メール全削除 ・メール・アドレス設定→メールアドレスの変更 ・Y!ボタンを誤って押した為に、YAHOO!のTOPページが表示される (iMODEメニューのようにTOPページは無料ですよね？) ・データフォルダー→ピクチャー→ピクチャーダウンロード→TOP画面表示 (データフォルダーにある ＸＸＸダウンロードってのを誤ってクリックしTOP画面を表示した事が数回あり) YAHOO!のTOPページやＸＸＸダウンロードのTOPページは誤って表示しましたが それ以上にクリックせずに画面を終了させています。 あと、１度ケータイからマイソフトバンクで料金を確認したのみです。 Webなんて見れなくてもいいんですが、他社とメールする為には契約しないといけないし このままでは必要のないものに、2000円払わないといけなくなります。 詳しい方、どの操作でパケット通信量が発生しているのか教えてください。よろしくお願いします。
- ベストアンサー
- その他（スマートフォン・携帯・タブレット）
- メール使いホーダイのトラブル（スマートフォン）
現在、SC-01B（Windows Mobile）を使用しています。 メールの使用が主で、時々家でWiFiでネットに繋ぐくらいです。 月々の料金を抑えるため、６月からメール使いホーダイにしました。 ６月と７月は期待通りパケット通信料が０円になり喜んでいたのですが なぜか８月はパケット通信料が８００円ほど発生していました。 使い方は変わっていないのになぜ急にパケット通信料が発生するのかわかりません。 ドコモショップではバックグラウンドで通信をしている可能性が高いと言われましたが それだと６、７月もいくらかの通信料が発生すると思うので納得できませんでした。 ８月にSPモードで大規模な障害が発生したこともあり 課金に間違いがないのか疑問を持っています。 スマートフォンでパケホーダイにしていない人は少ないと思いますが 同じようなトラブルを抱えた方、または何か原因がわかる方いませんか？ よろしくお願いします。
- 締切済み
- docomo
- ネットワークの瞬断について
TCP/IPのネットワークにおいて、メンテナンスなどの際によく「瞬断が発生する」と言いますが、瞬断とはどの程度のことを言うのか気になっており、考え方など教えていただきたいです。試しに聞いてみた人は、感覚的に ・1秒程度の断は通信にほとんど影響がない。通信にほとんど影響のない断を瞬断という。 ・分単位だと通信に影響があり、通信がエラーで終了することもあり、瞬断といわない。 というようなイメージをもっているようですが、もう少し具体的にイメージしたいです。 【質問(1)】 今のところは、TCPの再送タイムアウト（RTO）を超えないような程度の通信断のことを瞬断というのかと考えているのですが、正しいでしょうか？また、RTOはOSにより計算方法が異なったり、カスタムできるようなので、一般にはどの程度なのかも教えていただきたいです。 ※UDPはロストするが、TCPならデータロストの起こらないような通信断のことを瞬断というのかと考えています。 【質問(2)】 通信断の時間がRTOを超えた場合、応答のないパケットは再送されなくなるかと思いますが、その時点でそのTCPコネクションは終了するのでしょうか？ あるいは、次のパケットから転送が続くのでしょうか（最終的に転送完了したデータは抜けのあるデータになるのでしょうか）？ 【質問(3)】 瞬断程度でエラーが起こらないようにアプリ側でコントロールすべき、という話も聞くのですが、アプリ側でコントロールとは具体的にどのようにするのでしょうか？
- 締切済み
- ネットワーク
- SQLサーバをTCP/IPレベルで操作したい
MySQLを使ってデータベースの勉強をしています。 SQLサーバへのアクセス手段を提供するAPIは言語ごとに沢山公開されていますが、ちょっと必要に駆られまして、TCP/IPのレベルでMySQLのサーバと通信する必要が出てきてしまいました。 そこで、文献で通信プロトコルを調べようとしたのですが、見事に挫折。Port3306に届くパケットをダンプして眺めてみたのですが、複雑すぎてこれも挫折。 量が多くて英文のオンラインマニュアルから探すのもできない状態なのですが、書籍などで解説しているものはありませんでしょうか。
- 締切済み
- その他(データベース)
- docomoのパケット通信料が異常に高い
今月の初めに、docomoの機種変更と、プランの変更をしました。 普段、通常の通信料もパケット通信料もほとんどかかっておらず、無料通話分をほぼ次の月に繰り越すほど安かったため、プランをMからSSにしました。 買ったばかりの携帯が物珍しく、いろいろ触っていたのですが、購入から４日後に、 「通信料が短期間で高くなっている」という旨の通知を受け、料金を確かめたところ、なんと３万円の請求額が提示されていました。 私が閲覧したiモードのサイトは、着信メロディのサイト（着うたなどではない、着信音によくあるようなメロディを３曲ダウンロード）、グルメサイト、鉄道の乗り換えサイトです。 今までの携帯でも見ていた程度だと思います。 更に、パソコンから写真を３０枚ほど送っています。（もしかしたらこれが原因なのかもしれないと思います。。。） 動画等のダウンロードはしていません。 この使用状況で、３万円の請求はありえるのでしょうか？ それから、「OSアップデートを自動で更新するようになっていると、高額な料金が発生する可能性がある」 と、docomoの説明書に記載してあったのですが、通常の料金とどれくらいの差が出るのでしょうか。 また、OSアップデートの自動更新の解除はどうやったら出来るのでしょうか。 docomoの説明書から解除の方法を探し出すことが出来なかったので、教えていただけると幸いです。
- ベストアンサー
- docomo
補足
どうもありがとうございます。 エラーの発生は、通信時、アプリケーションが通信エラーコード を返したことで判明しました。 （相手から強制的に切断された） このエラーがTCPタイムアウトだったかどうかは、残念ながら不明 です。 そして、先方から前述の回答がありました。 先方からは「パケット1から4までの長さと、アプリケーションの制御 ヘッダ部分に格納されている、全体のレコード長と差異があるため にエラーとなった」とのことでした。 どこでパケットが欠けてしまったかは、原点に戻り、TCPなのかアプリ なのか、それぞれのトレースを双方で確認したいと思っています。