Проблемы с форумом

[mevial]

Зап, мой трэйс:
8  mp2-gw1-te9-1.msk.anders.ru (81.91.177.50)  25.007 ms  24.166 ms  24.089 ms
9  ovzhost17.vps.reg.ru (31.31.198.2)  24.910 ms  24.546 ms  24.238 ms
10  electrotransport.ru (31.31.199.149)  24.301 ms  24.295 ms  24.788 ms

Может m9-gw4-te3-1 и правда чудит?
Давайте каждый, кто заглянет в эту тему запустит cmd, и в нём напишет tracert electrotransport.ru и скопипастит последние 3 адреса сюда с комментом глючит или нет.

[nikvic]

 7    20 ms    18 ms    17 ms  ttk-m9.msk.stream-internet.net [195.34.36.46]
  8    18 ms    18 ms    22 ms  mskn02.transtelecom.net [217.150.61.74]
  9    20 ms    18 ms    22 ms  Anders-gw.transtelecom.net [217.150.61.73]
10    21 ms    22 ms    18 ms  mp2-gw1-te9-1.msk.anders.ru [81.91.177.50]
11    20 ms    22 ms    23 ms  ovzhost17.vps.reg.ru [31.31.198.2]
12    21 ms    23 ms    23 ms  31-31-199-149.ovz.vps.reg.ru [31.31.199.149]

[mevial]

10    21 ms    22 ms    18 ms  mp2-gw1-te9-1.msk.anders.ru [81.91.177.50]

Шлюз отметаем, можно больше не постить. А что с ФФ или оперой?

[nikvic]

А что с ФФ или оперой?

Ничего такова

[mevial]

Ничего такова

Ну и как мы выясним кто виноват? Может у вас ещё и каспер стоит? Нет в использовании ФФ или оперы ничего зазорного, зато плюшек хоть отбавляй.

[zap]

6-го ноября админ проапгрейдил на сервере PHP. Увидел в логах апача какие-то ругательства PHP на битые JPEG файлы (видимо, кто-то заливал неполностью итп) и решил, что дело в этом.
Насколько я вижу, ничего не изменилось.

Ну очень, просто очень нужен технически грамотный человек, у которого проявляется эта проблема.
Можно было бы устроить сеанс отладки, например, я бы на сервере бы дампил все TCP пакеты, уходящие на его адрес, а он бы затребовал картинку.
А дальше мы бы сравнили - что ушло с сервера, а что пришло к клиенту.
Если есть компутерно-грамотные с проблемой, напишите мне на жаббер zap@jabber.cobra.ru
Для отладки в реальном времени личка не годится.
В воскресенье меня дома не будет, правда. Где-то с понедельника лучше.

P.S. Интересно, картинка с котэ

https://electrotransport.ru/index.php?action=dlattach;topic=15742.0;attach=60135;image

по-прежнему такая же битая, или уже по-другому битая, или уже нормально скачивается?

[Электроник]

Что с форумом? Только у меня все изображения обрезанными наполовину загружаются?

[vpk8]

Только у меня все изображения обрезанными наполовину загружаются?

Неверное, да. У меня все ОК.

[ReSharVladimir]

У меня без изменений. Как и была.

[zap]

Что с форумом? Только у меня все изображения обрезанными наполовину загружаются?

Добро пожаловать в клуб неудачнегофф
Пытаюсь решить проблему, но проблема не на сервере а где-то в промежутке между сервером и некоторыми форумчанами.
К сожалению, приходится полагаться на службу поддержки хостинга.
Как крайний вариант - очередная смена хостинга.

[Электроник]

Что с форумом? Только у меня все изображения обрезанными наполовину загружаются?

К сожалению, приходится полагаться на службу поддержки хостинга.
Как крайний вариант - очередная смена хостинга.

Попробуйте Beget. У нас на работе те клиенты, у которых Бегет, меньше всех обращаются в техподдержку по поводу проблем на хостинге. И настроено там все сразу корректно, в частности, наша CMS-ка встает без проблем (не приходится лазать в конфигурационных файлах).

[zap]

Спасибо коллеге по работе, прояснил проблему.

Скорее всего, дело в так называемой проблеме "чёрная дыра MTU".
MTU это максимальная длина пакета для физической среды передачи. На протяжении маршрута от сервера до клиента эта самая среда передачи, естественно, можеть меняться несколько раз. И, соответственно, если где-то используется канал, через которые пакеты той длины, которую пересылает сервер, "не пролезают", они разбиваются на два пакета. При этом ставится соответствующая метка на пакет, а если на пакете стоит метка "не разбивать пакет на фрагменты", то отославшему пакет посылается, соответственно, специальное сообщение об ошибке.

Некоторые роутеры "проглатывают" такие сообщения об ошибке. Соответсвенно, пакеты с длиной больше чем надо тупо "теряются".

Чтобы проверить, в этом ли проблема, надо выполнить в Windows команду:

Код Выделить Развернуть

ping -f -l 1472 electrotransport.ru
(в Linux, соответственно, ping -M do -s 1472 electrotransport.ru).

1472 это длина данных в пакете; если приплюсовать к этому ещё 28 байт IP + ICMP заголовка, получаем 1500 байт - это стандартный MTU для Ethernet сети. При этом опция -f просит устанавливать на эти пакеты флажок "не разбивать на фрагменты". Таким образом, если пакет сумеет "пролезть" туда и обратно, значит с каналом всё в порядке. При этом ответ от ping должен выглядеть как-то так:

Код Выделить Развернуть

# ping -M do -s 1472 electrotransport.ru
PING electrotransport.ru (31.31.199.149) 1472(1500) bytes of data.
1480 bytes from 31-31-199-149.ovz.vps.reg.ru (31.31.199.149): icmp_req=1 ttl=54 time=18.0 ms
1480 bytes from 31-31-199-149.ovz.vps.reg.ru (31.31.199.149): icmp_req=2 ttl=54 time=18.2 ms
1480 bytes from 31-31-199-149.ovz.vps.reg.ru (31.31.199.149): icmp_req=3 ttl=54 time=17.3 ms


Если Вы видите таймауты, или ответы типа такого:

From xxx.yyy.zzz (192.168.1.1) icmp_seq=1 Frag needed and DF set (mtu = 1500)

Это значит, что указанный шлюз xxx.yyy.zzz получил пакет, увидел что его надо разбить, иначе не пролезет в канал, потом увидел флажок "не фрагментировать" и послал Вам обратно сообщение об ошибке.

Если же вообще никаких ответов не получаете, значит это та самая "чёрная дыра". Пакеты уходят и теряются в глубинах космоса. Тогда можете попытаться подобрать такой размер данных (опция -l xxx, соответственно -s xxx в Linux)  при котором пакет проходет через канал в обе стороны (ping посылает пакет к адресату, затем тот же самый пакет адресат отправляет в обратную сторону).

К сожалению, сейчас не могу заняться диагностикой более глубоко (можно попробовать продиагностировать канал с обратной стороны - от сервера до "жертв"). Приеду в понедельник из Масквы, займусь.

Кто конкретно виноват тоже пока неясно. Может быть провайдер, а может хостер, а может даже настройки файрвола на сервере (но это вряд ли, настройки давно не менялись).

[tony16]

ping -f -l 1472 electrotransport.ru

у меня пинги проходят только до длинны 1464 байта, форум отображается корректно.

[dimad63]

Пинг проходит кортинок больше нет вообще .

[mevial]

Скорее всего, дело в так называемой проблеме "чёрная дыра MTU".
...
Чтобы проверить, в этом ли проблема, надо выполнить в Windows команду:

Код Выделить Развернуть

ping -f -l 1472 electrotransport.ru
(в Linux, соответственно, ping -M do -s 1472 electrotransport.ru).


Кто конкретно виноват тоже пока неясно. Может быть провайдер, а может хостер, а может даже настройки файрвола на сервере (но это вряд ли, настройки давно не менялись).

Знакомая глюка. У тех кто использует pppoe обычно mtu ограничено 1492, т.е. проходят 1464 байта данных. Но дело даже не в этом, вряд ли у хостера в заголовках пакетов принудительно стоит запрет на фрагментацию. В настройках винды есть несколько параметров отвечающих за работу с большими пакетами. MTU discovery, который спрашивает у провайдера максимальный mtu, глючит с некоторыми провайдерами и роутерами, лучше отключить. Black hole detection, работает лучше, заставляет винду снижать MTU, но сильно тормозит инет если снижение потребуется, из-за постоянной перепосылки пакетов, но с тотальным глюком может помочь. А вот насильственно снизить MTU(кстати есть парный параметр - MRU) в винде это то самое решение, которое вы найдёте на форумах всяких геймеров, качальщиков и прочих медийных пользователей. Существует как методика правки реестра, так и огромное число всяких твикеров, некоторые даже сами пингуют и подбирают значения. На шлюзе можно насильную дробилку пакетов устроить, как например я делал у себя на работе, т.к. провайдер использует пппое, а винды сотрудников в упор не хотели снижать МТУ до правильных 1492, но в моём случае не ограничивалось электротранспортом, ни одна тяжёлая страничка не грузилась до конца. Но доступа к ПО шлюза у большинства нет, так что остаётся править свои винды.
Остаётся только один вопрос почему у одного хостера всё в порядке, а у другого нет? Zap, может стоит MTU прирезать на стороне сервера, если конечно vds?

[zap]

Снизил на сервере MTU до 1492.
У кого-нибудь вылечилась, например, эта картинка?
https://electrotransport.ru/index.php?action=dlattach;topic=15742.0;attach=60135;image
Или хоть какие-то изменения с ней произошли?

[nikvic]

Или хоть какие-то изменения с ней произошли?

Нет.
Полагаю, это проблема расположения и логиста толстых каналов. Оба моих провайдера здесь, на ЮЗ, дают плохую картинку, как и у Решивара.

[zap]

Снизил MTU до 500. Не помогло?
Кстати, проверил файрфокс - нифига F5 не помогает, сколько ни нажимай. Отправляет запрос на сервер, а тот ему тупо отвечает что кортинко не изменилось. Так что реальные данные картинки можно скачать только каким-нибудь менеджером загрузок, без кэширования.