adron2 Опубликовано 28 октября, 2014 · Жалоба ' timestamp='1414501514' post='1033571'] А если у них в сети завирусованный клиент который 100000 соединений через RT-N16 лезет? Тогда соединение просто не будет установлено, и картинка даже не начнет грузиться. Вообще Современные браузеры прекрасно эту проблему решают через persistent connections, держа соединение с сервером столько, сколько нужно для загрузки всей страницы. Т.е. при переполнении по соединениям соеиднение будет либо установлено, либо нет. Ничего там побиться не может. К тому же в логе роутера в таком случае будет "conntrack table full, dropping packet", достаточно просто посмотреть в админке. Согласен. Тогда логи с RT-N16 покажите если возможно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 28 октября, 2014 · Жалоба ' timestamp='1414488802' post=1033465] Скорее всего у провайдера (или где-то еще) стоит либо софт модификации трафика на лету, либо сетевуха с аппаратными TCP/UDP checksum в бридже, которая исправляет контрольную сумму неправильно принятого пакета на правильную. Контрольная сумма в ip/tcp/udp ТОЛЬКО НА ЗАГОЛОВОК. Данные можно сколько угодно менять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
loly Опубликовано 29 октября, 2014 (изменено) · Жалоба ' timestamp='1414488802' post=1033465]контрольная сумма верна (иначе бы пакет был отброшен по пути, и картинка бы вообще не загрузилась никогда), но данные в нем не верны Некоторые картинки бьются посередине пинг сразу же про это сообщит Что-то ничего не сообщает, обычный пинг. Повторюсь -- проверяйте прямое подключение проводом, в обход азуса. Повторюсь — это невозможно. Обычно при словах "а у меня Linux и проблемы на Вашей стороне" трубка быстро передаётся админам.... В любом случае Вы можете вызвать мастера от провайдера, чтоб разобрался. Это очень дешёвый полулегальный провайдер, я даже не уверена, что там вообще есть админ. Написало на мыло техподдержки (на мэйлру), там, разумеется молчат. Изменено 29 октября, 2014 пользователем loly Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 29 октября, 2014 · Жалоба А покажите результат пинга до наностанции и до mail.ru именной такой командой: ping mail.ru -s 1472 -A -c 10000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 29 октября, 2014 · Жалоба Контрольная сумма в ip/tcp/udp ТОЛЬКО НА ЗАГОЛОВОК. Данные можно сколько угодно менять. Вобщем-то верно. Но те же скачаные файлы у топикстартера скачиваются корректно, а это значит, что данные в них не повреждены, что наводит на мысль, что не в суммах вообще проблема. Торрентом покачать, и посмотреть ошибки CRC, и все сразу станет ясно. Опять же, и в wifi тоже есть проверка CRC служебных данных пакета. Суммарная вероятность ошибки довольно низка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 29 октября, 2014 · Жалоба Если проблема только на хттп, то есть вероятность что провайдер занимается прозрачным кешированием+проксированием веба, и где то у него в софте/железе проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
loly Опубликовано 29 октября, 2014 · Жалоба ' timestamp='1414589412' post=1033995]Но те же скачаные файлы у топикстартера скачиваются корректно Только на серверах с поддержкой докачки, например, Вконтакте. Для картинок на nginx и apache она по-дефолту отключена, поэтому на львиной доли сайтов они бьются. А покажите результат пинга loly@ubuntu:~$ ping mail.ru -s 1472 -A -c 10000 PING mail.ru (217.69.139.201) 1472(1500) bytes of data. 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=1 ttl=52 time=212 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=2 ttl=52 time=40.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=3 ttl=52 time=41.5 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=4 ttl=52 time=43.3 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=5 ttl=52 time=41.1 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=6 ttl=52 time=40.7 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=7 ttl=52 time=43.3 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=8 ttl=52 time=41.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=9 ttl=52 time=40.2 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=10 ttl=52 time=41.3 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=11 ttl=52 time=43.7 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=12 ttl=52 time=43.8 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=13 ttl=52 time=49.2 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=14 ttl=52 time=41.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=15 ttl=52 time=41.7 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=16 ttl=52 time=46.5 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=17 ttl=52 time=41.1 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=18 ttl=52 time=41.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=19 ttl=52 time=51.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=20 ttl=52 time=43.5 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=21 ttl=52 time=47.4 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=22 ttl=52 time=45.7 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=23 ttl=52 time=46.4 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=24 ttl=52 time=47.1 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=25 ttl=52 time=41.8 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=26 ttl=52 time=39.4 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=27 ttl=52 time=41.0 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=28 ttl=52 time=46.3 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=29 ttl=52 time=39.6 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=30 ttl=52 time=39.3 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=31 ttl=52 time=43.9 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=32 ttl=52 time=41.0 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=33 ttl=52 time=45.4 ms 1480 bytes from ko.mail.ru (217.69.139.201): icmp_seq=34 ttl=52 time=40.0 ms ^C --- mail.ru ping statistics --- 34 packets transmitted, 34 received, 0% packet loss, time 6709ms rtt min/avg/max/mdev = 39.341/48.150/212.041/28.683 ms, ipg/ewma 203.325/44.817 ms loly@ubuntu:~$ ping 192.168.0.1 -s 1472 -A -c 10000 PING 192.168.0.1 (192.168.0.1) 1472(1500) bytes of data. 1480 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=6.45 ms 1480 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2.29 ms 1480 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=2.10 ms 1480 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=2.06 ms 1480 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=2.47 ms 1480 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=4.90 ms 1480 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=2.56 ms 1480 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=2.04 ms 1480 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=7.18 ms 1480 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=2.53 ms 1480 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=7.33 ms 1480 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=5.79 ms 1480 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=4.17 ms 1480 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=2.30 ms 1480 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=2.46 ms 1480 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=3.24 ms 1480 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=4.50 ms 1480 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=1.99 ms 1480 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=4.76 ms 1480 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=2.06 ms 1480 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=1.94 ms 1480 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=3.38 ms 1480 bytes from 192.168.0.1: icmp_seq=23 ttl=63 time=5.45 ms 1480 bytes from 192.168.0.1: icmp_seq=24 ttl=63 time=2.16 ms 1480 bytes from 192.168.0.1: icmp_seq=25 ttl=63 time=2.04 ms 1480 bytes from 192.168.0.1: icmp_seq=26 ttl=63 time=2.45 ms 1480 bytes from 192.168.0.1: icmp_seq=27 ttl=63 time=2.09 ms 1480 bytes from 192.168.0.1: icmp_seq=28 ttl=63 time=3.24 ms 1480 bytes from 192.168.0.1: icmp_seq=29 ttl=63 time=2.54 ms 1480 bytes from 192.168.0.1: icmp_seq=30 ttl=63 time=2.03 ms 1480 bytes from 192.168.0.1: icmp_seq=31 ttl=63 time=2.02 ms 1480 bytes from 192.168.0.1: icmp_seq=32 ttl=63 time=1.97 ms 1480 bytes from 192.168.0.1: icmp_seq=33 ttl=63 time=2.80 ms ^C --- 192.168.0.1 ping statistics --- 33 packets transmitted, 33 received, 0% packet loss, time 6435ms rtt min/avg/max/mdev = 1.942/3.256/7.330/1.596 ms, ipg/ewma 201.119/2.715 ms Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
loly Опубликовано 29 октября, 2014 · Жалоба идет передача данных картинки и на 70% соединение рвется. Картинка останется недогруженной А во втором примере она сначала недогружается, а потом её задевает совесть и она догружается? и нат на роутере клиента Когда рутер просто в режиме точки доступа, а натит NanoStation, картина не меняется совершенно.Когда клиентом выступает не wi-fi-адаптер, а другие точки доступа (проверяла две), то то же самое. Много ли помимо вас пользователей работает через этот роутер? Один живой человек на ноутбуке с актуальным антивирем, телевизор и штук пять-десять андроидов. Может у кого то из этих пользователей вирус и он устанавливает гигантское кол-во соединений что в итоге приводит к переполнению памяти на роутере? У него на мерлиновской текущей прошивке я выставила ограничение 150 000 соединений. Так он спокойно тянет и 300 000.Но сейчас там в текущих соединениях всего 245 строк, это при том, что торренты раздаются. ' timestamp='1414501514' post=1033571] К тому же в логе роутера в таком случае будет "conntrack table full, dropping packet", достаточно просто посмотреть в админке. Если бы такое было, я бы заметила. Там обычные логи инициализации, запросы DHCP и вызов крона. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saiko Опубликовано 30 октября, 2014 · Жалоба Как вариант могу предложить построить туннель pptp,l2tp,openvpn от своего компьютера до ответной части и через него поработать (покачать). Конечно же при условии, что такая возможность есть. Может соседа к этому делу приобщить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adron2 Опубликовано 30 октября, 2014 · Жалоба Пинг нужно было подольше подержать. Хотябы 1000 пакетов. Вдруг проблема имеет эпизодический характер. А на наличие прокси сервера вы проверяли? В интернете полно сайтов которые это показывают... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rc7 Опубликовано 30 октября, 2014 · Жалоба Да сколько можно тут базарить. ПРов режит вам тсп соединения по 80 порту. Уж по какому методу тут можно только догадываться. Отсюда и все эти недозагружаемые картинки, битые картинки, недозагруженные страницы. У нас в подмосковье колибри-телеком любит этим заниматься, и в итоге точно такая же проблема. Решилось всё путём создания пптп тунеля к одному из платных серверов hideme.ru Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...