巨大なパケット損失とチェックサムエラー
2008サーバーは、2週間以内に非常にゆっくりと動作し始めました。当社のWebサイト（iis 7.5）の読み込みは非常に遅く、場合によってはフリーズします。私たちはwiresharkでテストを開始し、送信中にパケットが失われることを確認しました。クライアントが同じパケットを数回要求します。以下を確認してください。
（CLIENT）: 113.492500クライアントサーバーTCP 54 61220> http [ACK] Seq = 316 Ack = 5521 Win = 66240 Len = 0 （SERVER ）： 123.495204サーバークライアントTCP 1434 [TCP前のセグメントが失われました] [再構築されたPDUのTCPセグメント]
（クライアント）：133.495225クライアントサーバーTCP 66 [TCP Dup ACK 11＃1] 61220> http [ACK] Seq = 316 Ack = 5521 Win = 66240 Len = 0 SLE = 6901 SRE = 8281
****（SERVER）：*** 143.604038サーバークライアントTCP 1434 [再構築されたPDUのTCPセグメント]
**（CLIENT）：*** 153.604062クライアントサーバーTCP 66 [TCP Dup ACK 11＃2] 61220> http [ACK] Seq = 316 Ack = 5521 Win = 66240 Len = 0 SLE = 6901 SRE = 9661
**（SERVER）：*** 163.606074サーバークライアントTCP 1434 [TCP前のセグメントが失われました] [再構築されたPDUのTCPセグメント].。
**（CLIENT）：*** 233.714810クライアントサーバーTCP 74 [TCP Dup ACK 11＃6] 61220> http [ACK] Seq = 316 Ack = 5521 Win = 66240 Len = 0 SLE = 11041 SRE = 16561 SLE = 6901 SRE = 9661
**（SERVER）：*** 243.718211サーバークライアントTCP 1434 [TCP高速再送信] [再構築されたPDUのTCPセグメント]
フレームを詳細に確認したところ、エラーの大部分は「IPチェックサムオフロードエラー」であることがわかりました。ネットワークアダプタから「チェックサムオフロード」を無効にすると、「送信の疑い」が大量に受信され始め、サーバーはまだ低速です。興味深いのは、サーバー内のIPの1つでこのエラーが発生しておらず、そのIPを使用しているWebサイトが十分に高速であることです。
何が起こっているのか分かりますか？
多くのTCPパフォーマンスの問題は、一貫したパケット損失を伴う非常に単純な問題に帰着します。損失率が小さく見える（0.5％）場合でも、TCPに重大な問題を引き起こす可能性があります。
winmtr をダウンロードして、Windows2008サーバーにインストールしてください。これは、ホップごとのパケット損失を追跡する無料のユーティリティです。スループットの問題が発生する宛先に対してこれを実行します。あなたの目標は、少なくとも10分または15分間、一貫したパケット損失のベースラインを設定することです。ホップで断続的なパケット損失をキャッチするために、何時間も実行させることがあります。パケット損失が始まり、その後すべてのホップで続くホップを見つけたら、それが問題の検索を開始する場所です。
例：
このトレースでは、パケット損失はネットワークの最初のホップ（10.27.136.1）で始まるため、ウィンドウのマシンのイーサネットカード/ルーター上のリンクが原因である可能性があります。ファーストホップでの輻輳も考えられる原因です。
WinmtrはルーターからのICMPエラーメッセージに依存していることに注意してください。
- イーサネットスイッチはパスに明示的なホップとして表示されませんが、それでもパケット損失の原因となる可能性があります
- 一部のルーターはICMPエラーメッセージをレート制限（またはフィルター処理）するため、ルーターがレート制限に達した後（またはICMPエラーをフィルター処理するように構成された後）に一貫したパケット損失が表示されないホップ
- ファイアウォールは、ファイアウォールを介した可視性を妨げる可能性があります