WInXP и MTU - А кто-же виноват?!

Форум развил эту тему, причем проскакивали замечания, что это я тут хрень какую-то написал.. Да и вообще.. Абыдно..
И так. Если положить руку на сердце - проблема кроется с двух сторон, как и везде в телекоммуникациях. Поднятая мысль Petr-ом имеет право на жизнь.

Когда общаются два компьютера в одной и той же сети, важным является MTU для этой сети. Однако, когда общаются два компьютера в разных сетях, каждый промежуточный канал может иметь различные MTU. В данном случае важным является не MTU двух сетей, к которым подключены компьютеры, а наименьший MTU любого канала данных, находящегося между двумя компьютерами. Он называется транспортным MTU (path MTU).
Транспортный MTU между любыми двумя хостами может быть не постоянным. MTU зависит от загруженности канала на настоящий момент. Также он зависит от маршрута. Маршрут может быть несимметричным (маршрут от A до B может быть совсем не тем, что маршрут от B к A), поэтому MTU может быть неодинаков для этих двух направлений.

GPRS так устроен, судя по ETSI, что везде и всюду использует туннели. Можно с большой вероятностью предположить, что один конец туннеля находится на GPRS узле, а второй на роутере, за которым интернет. И далее до веб-сайта тоже есть роутеры. Мысль правильная - где-то пакеты пропадают. Попробую развить мое видение проблемы.. Хотя и не претендую на точность..

По умолчанию MTU равен 1500 байт на винде. В процессе установления коннекта с вебсайтом, прозрачно пройдя все роутеры, винда сообщает ему, что использует МТУ=1500. Сервер вебсайта это принимает к сведению и устанавливает для этого соеднинения это значение. И начинает слать пакеты обратно с таким размером. Если по пути следования пакета обратно у всех роутеров МТУ равен или больше, то пакет достигает виндовоза. Если на пути следования пакета попадается роутер, у которого МТУ меньше (допустим 1450), то этот роутер посылает назад на сервер ICMP пакет с сообщением, что требуется фрагментация, или другими словами - шли пакеты поменьше. Сервер получает это сообщение и шлет еще раз пакет данных с МТУ, запрошенным этим роутером, разбивая его на две части 1450+50 байт. Это в идеале.
Теперь предположим, что прохождение IСMP пакетов запрещено на сервер брандмауэром. В этом случае сервер не знает, что нужна фрагментация и продолжает шпарить большие пакеты, которые просто теряются, поскольку не пролезают в MTU на промежуточном роутере.
Исходя из этого - симптомы довольно понятны. Понаблюдайте - после того как вы шлепнете по ентеру, сайт отрезолвится, пройдут запросы и после начала перекачки данных от сервера все останавливается. Все логично. Пока пакеты идущие от сервера малы - они проходят полный путь, а как только полился большой обьем данных, все встало колом.

Теперь осталось выяснить( или предположить..) - кто?!
Как и замечалось в начале этого опуса, проблемных сторон две. Или вебсайт принимает сообщения о необходимости фрагментации или роутер пропускает необходимые пакеты без фрагментации.
В первом случае все понятно - админы вебсайтов крутят гайки на файрволе.
Во втором случае - не однозначно. Если роутер с маленьким МТУ под управлением MTC - то они, если этот роутер стоит дальше, то соответственно админы этих роутеров. Однако, что чем дальше роутер от провайдера, тем большие скорости используются, соответственно используются и большие МТУ. Поэтому узкий роутер, это скорее всего туннель от GPRS-узла до роутера провайдера интернета.
Для тех, кто аппелирует по поводу " ..а ведь в МФ все было ОК! И ничего крутить не надо было" - скажу, что построение сети задача нетривиальная. Похожий частичный интернет наблюдался и у проводных провaйдеров, в частности ADSL. Так они вообще не нашли другого способа, как крутить MTU у клиентов!

Резюмируя все сказанное...Понятно, что проблема в настройках. Гномить половину интернета по поводу некоректной настройки их вебсерверов - гиблое дело.. Остается два пути, или три, как я говорил раньше.