Для Windows 7, Windows Vista и Windows XP MTU для различных интерфейсов доступен из самой Windows с использованием netsh
.
Windows 7, Windows Vista
Чтобы показать текущий MTU в Windows 7 или Windows Vista, воспользуйтесь интерпретатором команд:
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
Note: В данном примере мой интерфейс Local Area Connection IPv6 имеет такой низкий MTU (1280), потому что я использую туннельную службу для получения IPv6-подключения .
Вы также можете изменить свой MTU (Windows 7, Windows Vista). Из командной строки elevated:
>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.
Tested with Windows 7 Service Pack 1
Windows XP
Синтаксис netsh
для Windows 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): 0x2 и 0x2 и 0x1 и 0x2 и 0x2 и 0x2 и Windows XP не предоставляет способ изменить настройки MTU с 0x6 и 0x2. Для этого вы можете:
Tested with Windows XP Service Pack 3
См. также
Краткая дискуссия о том, что такое MTU, откуда идет 28 байт.
Ваша сетевая карта (Ethernet) имеет максимальный размер пакета netsh
:
C:\Users\Ian>net start remoteaccesss
IP-адрес TCP/IP требует 20-байтного заголовка (12 байт флагов, 4 байта для IP-адреса источника, 4 байта для IP-адреса получателя). Это оставляет меньше места в пакете:
+---------+
| 1500 |
| byte |
| payload |
| |
| |
| |
+---------+
Теперь ICMP (ping) пакет имеет 8-байтный заголовок (1 байт 1,500 bytes
, 1 байт type
, 2 байта code
, 4 байта дополнительных данных):
+------------------------+
| 12 bytes control flags | \
| 4 byte from address | |- IP header: 20 bytes
| 4 byte to address | /
|------------------------|
| 1480 byte payload |
| |
| |
| |
+------------------------+
Вот где “недостающие” 28 байт - это размер заголовков, необходимых для отправки ping пакета.
Когда вы посылаете ping пакет, вы можете указать, сколько данных extra полезной нагрузки вы хотите включить. В этом случае, если вы включите все 1472 байта:
+------------------------+
| 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 |
| |
| |
| |
+------------------------+
Тогда результирующий ethernet пакет будет полон до жабргонов. Будет заполнен каждый последний байт пакета размером 1500 байт:
>ping -l 1472 obsidian
Если вы попытаетесь послать one more byte
+------------------------+
| 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....|
|........................|
|........................|
|........................|
|........................|
+------------------------+
сеть должна будет фрагментировать этот 1501-байтовый пакет на несколько пакетов:
>ping -l 1473 obsidian
Эта фрагментация произойдет за кулисами, в идеале без вашего ведома.
Но вы можете быть подлым и сказать сети, что пакет не может быть фрагментирован:
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 |
| |
| |
| |
| |
| |
+------------------------+
Флаг -f означает do not fragmgment. Теперь, когда вы пытаетесь отправить пакет, который не помещается в сети, вы получаете ошибку:
>ping -l 1473 -f obsidian
Пакет должен быть фрагментирован, но установлен флаг Do not Fragment.
Если где-то в линии пакет должен быть фрагментирован, сеть на самом деле посылает ICMP пакет, говорящий вам, что произошла фрагментация. Ваша машина получает этот ICMP пакет, получает информацию о самом большом размере и должна перестать посылать пакеты слишком большого размера. К сожалению, большинство брандмауэров блокируют эти ICMP пакеты “Path MTU discovery”, поэтому ваша машина никогда не понимает, что пакеты фрагментируются (или, что еще хуже: отсылаются, потому что не могут быть фрагментированы).
Это то, что заставляет веб-сервер не работать. Вы можете получить начальные небольшие (<1280 байт) ответы, но большие пакеты не могут пройти. А брандмауэры веб-сервера неправильно настроены, блокируя ICMP пакеты. Поэтому веб-сервер не понимает, что вы так и не получили пакет.
Фрагментация пакетов не разрешена в IPv6, все required, чтобы (правильно) разрешить ICMP mtu-пакеты обнаружения.