- - PR -
SYNパケットが再度送られてくる
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2004-04-08 15:03
TCP/IPについて、ど素人なのですが、業務で通信エラーが発生して困っており、質問します。なにかヒントでも教えてください。
INS64経由で、サーバ(Win2000Server)とパソコン(WinNT4.0WS)で、通信をしています。パソコンから、ダイヤリング＆接続し、データをサーバーに送信しています。時々、通信エラーが発生します。サーバ側のLANトレースから問題があることは見えたのですが、問題箇所の検討をつけることが出来ません。 ＜LANトレースのキャプチャー結果＞ ● 正常に通信できたとき サーバ クライアント（パソコン） ← SYN → SYNACK ← ACK ← PSHACK → PSHACK ← ACK ← PSHACK → PSHACK ← ACK 繰り返し ← FINACK → ACK → FINACK ← ACK ← RSTACK ● 通信エラーが発生したとき サーバ クライアント（パソコン） ← SYN※ → SYNACK ← ACK ← SYN （※のSYNと同じSEQ number、acknowledgementが届く） → ACK ← SYN （※のSYNと同じ） → ACK ← SYN （※のSYNと同じ） → ACK 通信エラー後、クライアントでリブートも何もせずに再実行すると問題なく通信できます。 LANカード等ハードなのか、ソフト（ＯＳ？）なのか、どの部分に問題があると検討をつけたらよいのでしょうか。因みに、パソコン側LANトレースは、採取できていません。 | ||||
|
投稿日時: 2004-04-13 09:11
まず、クライアント自身でトレースを仕掛けてみるのが良いと感じます。 クライアント自身で問題がなければクライアントのソフトは問題なく、クライアントのハード若しくはその先になります。 また、クライアントが1台なのか複数台なのかで次の調査ポイントの判断が分かれると思います。 見当をつけるためにはもう少し情報が必要ですね。 | ||||
|
投稿日時: 2004-04-23 16:14
サーバ(Win2000Server)とパソコン(WinNT4.0WS)の両方で通信トレースを取る必要があります
ちなみに、通信ソフトはどうようなものを使っているのでしょうか？ | ||||
|
投稿日時: 2004-04-28 15:59
こんにちは。
ふと思ったのですが、ご提示頂いた「＜LANトレースのキャプチャー結果＞」が サーバ側で取得されたものであれば、つまりサーバにクライアントからのACKが 届いていることになると思われます。 であれば、ACKが届いているにも関わらずSYNを再送するサーバ側に問題が あるように感じるのは私だけでしょうか？ （ACKを返せていないのであればクライアントのOS（TCP/IPソフト）のバグや NIC（ドライバ含む）のバグなどが考えられると思いますが･･･） と、書いている内に 「でもACKの内容（SEQ No.やACK No.など）がおかしければサーバは 適切なACKではないと判断してSYN再送するから、誤ったACKをクライ アントが送信している可能性があるわけか･･･」 と思い直しました。 とりあえず、サーバ側で取得されたであろう「＜LANトレースのキャプチャー結果＞」より ACKの内容（SEQ No.やACK No.など）が適正か否かをお調べ頂くのも手かと思われます。 ただ、厳密な調査にはきゅ〜じゅさんや未記入さんのおっしゃる通りの 情報収集が必要であることは間違いないですね。 お役に立てれば何よりです。 [ メッセージ編集済み 編集者: むー 編集日時 2004-04-28 16:03 ] | ||||
|
投稿日時: 2004-04-30 10:30
SYNはクライアント側からの送信であり、再送ですよ。 問題はサーバからのSYNACKを受け取った事を示すACKが、クライアントより送出されているにも関わらず通信確立されていない事にありそうですが。 サーバ − クライアント間にL7SW(Proxy等含む)でも入っていれば、先にそちらを調べてみるのも良いのですが、少なくともSYN-SYNACK-ACK迄が問題ないのであればサーバ側に(この段階での)問題は無く、サーバから見てクライアント側にありそうです。 | ||||
|
投稿日時: 2004-04-30 13:07
あっ、本当だ。
ごまさんごめんなさい。勘違いしてしまいました。 となると、確かにクライアント側に焦点を絞ってもよさそうですね。 | ||||
|
投稿日時: 2004-05-14 14:20
問題はサーバ側ではないでしょうか？
サーバーのCPUに負荷がかかっていて、← ACK （クライント側からの）が正しく受け取れていないのではないでしょうか？トレースを取った場所にもよりますが。 | ||||
|
投稿日時: 2004-05-14 22:29
3番目のパケット（クライアントからのACK）をサーバが取りこぼしていると
5、7、9番目のパケットはACKではなく、SYN/ACKになるはずです。 クライアント側でのパケットキャプチャをしてみないとはっきりしないのですが、 ESTABLISHEDになった直後に、何らかの理由でクライアントがエラーを（誤？）検出しているのではないでしょうか？ 3番目と4番目のパケットの間隔が極端に短ければ クライアント側で何らかの不調が起きていると思います。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。