Фрагментация и размер пакета, с помощью tcpdump
Я не знаю то, что ОС Вы используете, но можно добавить, что строка к/etc/hosts на *отклоняет системы и c:\Windows\System32\Drivers\etc\hosts that allow you to map mywebsite.com (или dev.mywebsite.com) к 127.0.0.1.
Или лучшая идея состояла бы в том, если Вы управляете DNS, просто создают субдомен запись как dev.mywebsite.com и указывают на него на 127.0.0.1.
Да, используя tcpdump с опцией -s, результат теперь правильный. По вашему результату мы насчитываем 45 пакетов. 44 пакета по 1500 байтов, 1 пакет 415 байтов.
44 * 1500 + 415 = 66415
66415 - 65507 = 908
908/45 = 20 плюс 8
Как видите, каждый пакет добавляет 20 байт для заголовка ip + 8 байт заголовка icmp для первого пакета.
Просто чтобы добавить к ответу Гнука .
Вы отправляете 65507 байт данных.
Сюда не входят заголовки ICMP, которые составляют 8 байтов.
Наиболее распространенный размер MTU - 1500 . Этот размер соответствует размеру уровня 3, поэтому вы видите ethertype IPv4 (0x0800), длина 1514: , что означает, что общий размер кадра на самом деле составляет 1514 байтов.
Эти 14 байтов составляют заголовок Ethernet. 12 байт на MAC-адрес + 2 для типа.
Минимальный и очень распространенный размер для IP-заголовка - это его минимальный размер 20 байтов (максимум 60 байтов).
Итак, у нас есть
1514 bytes - Ethernet header = 1500 bytes
1500 - IP header = 1480 bytes
1480 - ICMP header = 1472 bytes
Вы можете отправить по адресу максимум 1472 байта без фрагментации.
НО способ, которым IP фрагментирует пакеты, не требует отправки заголовка для каждого пакета, а только для первого пакета.
С фрагментацией максимальное количество байтов, которое вы можете отправить при MTU 1500 составляет 1480 байт.
Мы знаем общий размер ваших данных и максимальный размер, который вы можете отправить.
Таким образом, потребуется не менее 65507/1480 ~ = 44,2 пакета . Т.е. 44 пакета из 1514, а затем последний пакет размером менее половины.
Что случилось с остальными пакетами?
Но почему 31 пакет? Ну это В конце вашего tcpdump вы должны увидеть
31 packets captured
57 packets received by filter
14 packets dropped by kernel
. Если вы добавите захваченные пакеты + пакеты, отброшенные ядром, вы получите правильный ответ, и это то, что -s изменяет длину снимка.
Из руководства tcpdump.
-s Snarf снимает байты данных из каждого пакета, а не 65535 байтов по умолчанию. Пакеты обрезаны из-за ограниченного снимок обозначается в выходных данных как «[| proto]», где proto - имя уровня протокола, на котором произошло усечение. Обратите внимание, что создание снимков большего размера увеличивает время требуется для обработки пакетов и, по сути, уменьшает количество буферизация пакетов. Это может привести к потере пакетов. Вы должны ограничить snaplen до наименьшего числа, которое захватит протокол информация, которая вас интересует. Установка snaplen в 0 устанавливает его в по умолчанию 65535 , для обратной совместимости с недавними более старыми версии tcpdump.
Почему ядро в первую очередь отбрасывает пакеты?
Снова из справочной страницы tcpdump
пакеты, отброшенные ядром (это количество пакетов, которые были сброшено из-за нехватки буферного пространства при захвате пакета механизм в ОС, на которой запущен tcpdump, если ОС сообщает эта информация для приложений; в противном случае будет сообщено как 0).