Webページにアクセスしようとすると「サーバーへの接続がリセットされました」というエラー(Windowsネットワーク診断ツールによるHTTPエラー12031)がランダムに発生するという非常に奇妙な問題に苦しんでいます-これは、Webページかどうかに関係なく発生します私がアクセスしようとしているのは、外部インターネット上、またはlocalhostで実行されているローカルApacheインスタンスからのものであってもです。これは、Windows XPを実行しているローカルネットワーク(ワイヤレスではなくイーサネット)上のすべてのコンピューターに影響します。
ネットワークトラフィックで使用されるMTUに関係している可能性があることが示唆されました。 Pingテスト を実行して、断片化されていない最大のパケットを見つけると、1492バイト(ヘッダーの場合は+28バイト?)のパッケージでlocalhostにpingを実行できます。 1462バイト(28バイトのヘッダーを含めると1490バイト)のパッケージを持つルーター。 Googleのように外側で何かをpingしようとすると、1430(ヘッダー付きの1458)を超えるものは何も取得できません。
私はWindowsを更新するためにさまざまな一連の指示に従って試しましたXPこのMTU設定のレジストリ、更新HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU
。私は代替値の終わりを試していません:最も明白な正しい値は1490のようですが、1462、1458、1430なども試しました。変更を有効にするためにコンピューターを再起動すると、 数分間動作するようです(一貫性ではなく常にランダムであるため、特定するのは難しい)が、長く続くことはありません。
最初は、1430を値として試していたところ、数分正常に動作した後、Pingテストの結果が28バイト減少しました-突然、1402バイトのパッケージしかGoogleに渡せないことがわかりました。 MTUレジストリ設定を1402に更新した場合、再起動して数分待つと、1374、1346などになります。ネットワーク上の他のコンピューターは影響を受けず(1430のまま)、MTU設定を削除しましたレジストリからのものを正常に復元します(まだ壊れています)。
これをすべて診断するのが一番難しいのは、正しいレジストリ設定を使用しているかどうかを判断するのが非常に難しいことです。だから最も簡単に言えば、私の質問は次のようになります:Windowsが使用しようとしているMTU設定を確認するにはどうすればよいですか
また、MTUが28まで低下し続ける理由を知る方法がある場合は、それも役に立ちます(たとえば、値が変化した時点で何かを記録するWindowsログファイルがどこかにあるかどうか)。
最後に、私が使用しようとしているMTU設定を伝える方法を誰かが決定的に教えてくれるなら、それは素晴らしいことです!
Windows 7、Windows Vista、およびWindows XPの場合、さまざまなインターフェイスのMTUはnetsh
を使用してWindows自体から入手できます。
Windows 7またはWindows Vistaでコマンドプロンプトから現在の [〜#〜] mtu [〜#〜] を表示するには:
C:\Users\Ian>netsh interface ipv6 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
---------- --------------- --------- --------- -------------
1280 1 24321220 6455865 Local Area Connection
4294967295 1 0 1060111 Loopback Pseudo-Interface 1
1280 5 0 0 isatap.newland.com
1280 5 0 0 6TO4 Adapter
そしてIPv4インターフェースの場合:
C:\Users\Ian>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
---------- --------------- --------- --------- -------------
1500 1 146289608 29200474 Local Area Connection
4294967295 1 0 54933 Loopback Pseudo-Interface 1
注:この例では、ローカルエリア接続 IPv6 インターフェースは トンネルを使用しているため、MTU(1280)が非常に低くなっていますIPv6接続を取得するサービス 。
MTUを変更することもできます(Windows 7、Windows Vista)。 elevatedコマンドプロンプトから:
>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.
Windows 7 Service Pack 1でテスト済み
Windowsのnetsh
構文XPは少し異なります:
C:\Users\Ian>netsh interface ip show interface
Index: 1
User-friendly Name: Loopback
Type: Loopback
MTU: 32767
Physical Address:
Index: 2
User-friendly Name: Local Area Connection
Type: Etherenet
MTU: 1500
Physical Address: 00-03-FF-D9-28-B7
注: Windows XPでは、ルーティングとリモートアクセスサービスを開始してから詳細を確認する必要がありますインターフェースについて(MTUを含む):
C:\Users\Ian>net start remoteaccesss
Windows XPは、netsh
内からMTU設定を変更する方法を提供していません。そのために、次のことができます。
Windowsでテスト済みXP Service Pack 3
28バイトの送信元であるMTUとは何かについての短い議論。
ネットワークカード(イーサネット)の最大パケットサイズは1,500 bytes
:
+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+
TCP/IP のIP部分には、20バイトのヘッダーが必要です(12バイトのフラグ、4バイトの送信元IPアドレス、4バイトの宛先IPアドレス)。これにより、パケットで使用可能なスペースが少なくなります。
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |- IP header: 20 bytes
| 4 byte to address | /
|------------------------|
| 1480 byte payload |
| |
| |
| |
+------------------------+
これで、ICMP(ping)パケットには8バイトのヘッダー(1バイトtype
、1バイトcode
、2バイトchecksum
、4バイトの追加データ)があります:
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
| 1472 byte payload |
| |
| |
| |
+------------------------+
これが「欠落」の28バイトです。pingパケットを送信するために必要なヘッダーのサイズです。
Pingパケットを送信するときに、含める extra ペイロードデータの量を指定できます。この場合、1472バイトすべてを含めると、次のようになります。
>ping -l 1472 obsidian
次に、結果のethernetパケットがエラに満ちます。 1500バイトのパケットの最後のバイトがすべて埋められます。
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|........................|
|........................|
|. 1472 bytes of junk....|
|........................|
|........................|
|........................|
|........................|
+------------------------+
1バイトを送信しようとすると
>ping -l 1473 obsidian
ネットワークは、1501バイトのパケットを複数のパケットにフラグメント化する必要があります。
Packet 1 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|........................|
|........................|
|..1472 bytes of payload.|
|........................|
|........................|
|........................|
|........................|
+------------------------+
Packet 2 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address | |
| 4 byte to address | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header | /
|------------------------|
|. |
| 1 byte of payload |
| |
| |
| |
| |
| |
+------------------------+
この断片化は、理想的には知らないうちに舞台裏で起こります。
しかし、あなたは意地悪で、パケットの断片化が許可されていないことをネットワークに伝えることができます:
>ping -l 1473 -f obsidian
-f フラグは、フラグメント化しないことを意味します。ここで、ネットワークに適合しないパケットを送信しようとすると、エラーが発生します。
>ping -l 1473 -f obsidian
Packet needs to be fragmented but DF set.
パケットはフラグメント化する必要がありますが、Do not Fragmentフラグが設定されました。
回線のどこかにパケットをフラグメント化する必要がある場合、ネットワークは実際にICMPパケットを送信して、フラグメント化が発生したことを通知します。マシンはこのICMPパケットを受け取り、最大サイズが通知され、大きすぎるパケットの送信を停止するはずです。残念ながら、ほとんどのファイアウォールはこれらの「パスMTUディスカバリー」ICMPパケットをブロックするため、マシンはパケットがフラグメント化されていることに気付くことはありません(さらに悪いことに、フラグメント化できなかったためドロップされました)。
これがWebサーバーが機能しない原因です。最初の小さい(<1280バイト)応答を取得できますが、大きいパケットは通過できません。また、Webサーバーのファイアウォールが正しく構成されておらず、ICMPパケットがブロックされています。そのため、Webサーバーは、パケットを受け取ったことがないことに気づきません。
パケットの断片化はIPv6では許可されていません。ICMPmtu発見パケットを(正しく)許可するには、全員が必要です。
@ian netsh
が実際に現在使用されているMTUを実際に表示するかどうかはわかりません。私のWindowsでは、XP Pro SP3マシンでnetsh interface ip show interface
を実行すると、関連するインターフェイスのMTU値が1500
と報告されました。次に、次のレジストリキーを追加しました。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
value: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\MTU
value: various (e.g. 1200)
MicrosoftによるとEnablePMTUDiscovery
を0に設定すると、MTUは576に設定されます。
MTU
レジストリエントリを設定すると、MTUが手動で設定されます。 MTU
エントリの値をいくつか試しました(毎回再起動しています)。
どちらの場合でも、最初のエントリを追加し、次に2番目のエントリを追加すると、netsh
はMTUを1500として報告しました。pingを使用したテストでは、レジストリで構成されたMTU値が実際に使用しました。
また、私が自分のマシンでこれを最初に試したとき、ルーティングとリモートアクセスサービスが無効になっていたため、指示を使用してサービスを開始できませんでした。 [コントロールパネル]> [管理ツール]> [コンピューターの管理]> [サービスとアプリケーション]> [サービス]に移動して有効にしました。 「スタートアップの種類」を「無効」から「手動」に変更しました。次に、そのダイアログからもサービスを開始しました。
また、KB283165がMTUを変更するための正しい指示である必要があるかどうかもわかりません。 Windows PPPoE client?を実行している場合のみ、これらの手順は関係ありませんか?ルーターがPPPoEクライアントであるルーターを介してインターネットに接続する場合私の場合)、それらの指示は適切ではないでしょう?
レジストリに上記の変更を加えるために私が従った指示は次のとおりです KB900926:推奨されるTCP/IP設定WAN MTUサイズが576未満のリンク (方法2および3)。
あなたが正しいように見えます。 1,200に設定しますが、netsh
は1500
を報告します。
>ping -l 1173 -f obsidian
Packet needs to be fragmented but DF set.
だから私は元の質問への答えはWindowsではXPあなたはで試行錯誤を使用する必要があります)断片化しないでください送信できる最大のパケットを見つけるためのフラグは、MTUです。
試行錯誤的なアプローチでpingを使用してMTUを見つけることができます。
ping <address> -f -l nnnn
Ping:
-f:エコー要求メッセージがIPヘッダーのDo n't Fragmentフラグが1に設定されて送信されることを指定します。エコー要求メッセージは、宛先へのパスにあるルーターによってフラグメント化できません。このパラメーターは、パスの最大転送単位(PMTU)の問題のトラブルシューティングに役立ちます。
-lサイズ:送信されるエコー要求メッセージのデータフィールドの長さをバイト単位で指定します。デフォルトは32です。最大サイズは65,527です。
長さが長すぎると、「パケットをフラグメント化する必要がありますが、DFセット」というメッセージが表示されます。
Microsoft KB314496: さまざまなネットワークトポロジのデフォルトのMTUサイズ 。
通常のネットワーク設定では、MTU構成を試そうとしないでください。
ここにVBコード参照 があります。
DrTCP と呼ばれるツールもあります:
レジストリでは、
HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
に移動ServiceName
文字列をコピーしますHKLM\System
でその文字列を検索します。 NetCfgInstanceId
キーと一致しますMaxFrameSize
キーになります(鉱山では1514と表示されています)これをnetsh
コマンドで変更する方法もあります。
また、 パスMTUディスカバリー構成 も確認してください。
AdapterWatch を参照してください:
AdapterWatchは、ネットワークアダプターに関する有用な情報を表示します:IPアドレス、ハードウェアアドレス、WINSサーバー、DNSサーバー、MTU値、送受信されたバイト数、現在の転送速度など。さらに、 、ローカルコンピュータの一般的なTCP/IP/UDP/ICMP統計を表示します。