Перейти к содержимому
Калькуляторы

Бьются файлы в Сети Особенно раздражает, что почти все картинки битые

' timestamp='1414501514' post='1033571']

А если у них в сети завирусованный клиент который 100000 соединений через RT-N16 лезет?

Тогда соединение просто не будет установлено, и картинка даже не начнет грузиться. Вообще Современные браузеры прекрасно эту проблему решают через persistent connections, держа соединение с сервером столько, сколько нужно для загрузки всей страницы.

 

Т.е. при переполнении по соединениям соеиднение будет либо установлено, либо нет. Ничего там побиться не может.

 

К тому же в логе роутера в таком случае будет "conntrack table full, dropping packet", достаточно просто посмотреть в админке.

 

Согласен.

Тогда логи с RT-N16 покажите если возможно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1414488802' post=1033465] Скорее всего у провайдера (или где-то еще) стоит либо софт модификации трафика на лету, либо сетевуха с аппаратными TCP/UDP checksum в бридже, которая исправляет контрольную сумму неправильно принятого пакета на правильную.

Контрольная сумма в ip/tcp/udp ТОЛЬКО НА ЗАГОЛОВОК.

Данные можно сколько угодно менять.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1414488802' post=1033465]

контрольная сумма верна (иначе бы пакет был отброшен по пути, и картинка бы вообще не загрузилась никогда), но данные в нем не верны

 

Некоторые картинки бьются посередине

broken-2.png

 

пинг сразу же про это сообщит

Что-то ничего не сообщает, обычный пинг.

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

Повторюсь — это невозможно.

Обычно при словах "а у меня Linux и проблемы на Вашей стороне" трубка быстро передаётся админам....

В любом случае Вы можете вызвать мастера от провайдера, чтоб разобрался.

Это очень дешёвый полулегальный провайдер, я даже не уверена, что там вообще есть админ. Написало на мыло техподдержки (на мэйлру), там, разумеется молчат.

Изменено пользователем loly

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А покажите результат пинга до наностанции

и до mail.ru

 

именной такой командой:

ping mail.ru -s 1472 -A -c 10000

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Контрольная сумма в ip/tcp/udp ТОЛЬКО НА ЗАГОЛОВОК.

Данные можно сколько угодно менять.

Вобщем-то верно.

Но те же скачаные файлы у топикстартера скачиваются корректно, а это значит, что данные в них не повреждены, что наводит на мысль, что не в суммах вообще проблема.

Торрентом покачать, и посмотреть ошибки CRC, и все сразу станет ясно. Опять же, и в wifi тоже есть проверка CRC служебных данных пакета. Суммарная вероятность ошибки довольно низка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если проблема только на хттп, то есть вероятность что провайдер занимается прозрачным кешированием+проксированием веба, и где то у него в софте/железе проблема.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

идет передача данных картинки и на 70% соединение рвется. Картинка останется недогруженной

А во втором примере она сначала недогружается, а потом её задевает совесть и она догружается?

 

и нат на роутере клиента

Когда рутер просто в режиме точки доступа, а натит NanoStation, картина не меняется совершенно.

Когда клиентом выступает не wi-fi-адаптер, а другие точки доступа (проверяла две), то то же самое.

 

Много ли помимо вас пользователей работает через этот роутер?

Один живой человек на ноутбуке с актуальным антивирем, телевизор и штук пять-десять андроидов.

 

Может у кого то из этих пользователей вирус и он устанавливает гигантское кол-во соединений что в итоге приводит к переполнению памяти на роутере?

У него на мерлиновской текущей прошивке я выставила ограничение 150 000 соединений. Так он спокойно тянет и 300 000.

Но сейчас там в текущих соединениях всего 245 строк, это при том, что торренты раздаются.

 

' timestamp='1414501514' post=1033571]

К тому же в логе роутера в таком случае будет "conntrack table full, dropping packet", достаточно просто посмотреть в админке.

Если бы такое было, я бы заметила. Там обычные логи инициализации, запросы DHCP и вызов крона.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как вариант могу предложить построить туннель pptp,l2tp,openvpn от своего компьютера до ответной части и через него поработать (покачать). Конечно же при условии, что такая возможность есть. Может соседа к этому делу приобщить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пинг нужно было подольше подержать. Хотябы 1000 пакетов. Вдруг проблема имеет эпизодический характер.

А на наличие прокси сервера вы проверяли?

В интернете полно сайтов которые это показывают...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да сколько можно тут базарить.

ПРов режит вам тсп соединения по 80 порту. Уж по какому методу тут можно только догадываться. Отсюда и все эти недозагружаемые картинки, битые картинки, недозагруженные страницы.

У нас в подмосковье колибри-телеком любит этим заниматься, и в итоге точно такая же проблема.

Решилось всё путём создания пптп тунеля к одному из платных серверов hideme.ru

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.