Comments 15
Потестила. Все зелененькое, кроме DNS — а DNS у меня гугловский прописан… Кто-нибудь может пояснить, что значит «Your ISP's DNS resolver follows CNAMEs regardless of their location. This is very unusual.»?
Uplink/downlink буферы слишком большие. Можно ли регулировать этот параматр? И надо ли?
«Unfortunately, this is a difficult problem to solve. A more expensive modem or faster internet connection can help, but neither is a guaranteed solution.» ©
чрезмерно большие uplink буферы
Если я правильно понимаю, чаще всего причина этого — включенный веб-модуль антивируса, который проходящую информацию кеширует и анализирует.
подмена результатов DNS запросов некоторыми провайдерами и OpenDNS
Тут ещё проще — когда DNS не находит имени для рессолва, в случае OpenDNS и некоторый провайдерских возвращается не стандартный ответ, а веб-страничка, у OpenDNS — с их поисковым движком. Авторы апплета считают это некорректным. Ну тут найдутся и сторонники и противники :)
Если я правильно понимаю, чаще всего причина этого — включенный веб-модуль антивируса, который проходящую информацию кеширует и анализирует.
Нет, авторы имеют в виду физические буферы в модеме.
Тут ещё проще — когда DNS не находит имени для рессолва, в случае OpenDNS и некоторый провайдерских возвращается не стандартный ответ, а веб-страничка, у OpenDNS — с их поисковым движком.
Да, этот эффект имеет место, авторы называеют его NXDOMAIN wildcarding. Проблема в том, что некоторые приложения могут зависеть от корректного ответа на несуществующий домен в виде статуса NXDOMAIN. Кроме того, такая замена на свою страничку предполагает, что DNS запрос был послан браузером, который сможет в итоге отобразить полученную страничку. А что есть запрос послал не браузер, а другое приложение, не знающее ничего об http?
Кроме того, под «подменой результатов DNS запросов» я имел в виду именно это — подмену. Например OpenDNS при DNS запросе на имя www.google.com возвращает не адрес гугла, а адрес своего прокси. То есть все ваши запросы к гуглу будут идти через их прокси. Ну и плюс авторы обнаружили, что некоторые инфецированные машины в ответ на запрос windowsupdate.microsoft.com получают левый адрес, что избежать апдейтов.
Нет, авторы имеют в виду физические буферы в модеме.
А каким образом они могут их различать?
авторы называеют его NXDOMAIN wildcarding
Вы абсолютно правы в этом, потому я и написал: тут могут быть и сторонники и противники :)
Например OpenDNS при DNS запросе на имя www.google.com возвращает не адрес гугла, а адрес своего прокси. То есть все ваши запросы к гуглу будут идти через их прокси.
Это чрезвычайно странно, потому что я сейчас сам проверил (через 208.67.220.220) — выдало www.l.google.com [74.125.87.104]
Если бы ситуация наблюдалась, как у Вас, то Гугль бы не смог выдавать локализованную страницу, поскольку все запросы шли бы не от конкретного IP, а через OpenDNS-проксю.
А каким образом они могут их различать?
В общем случае их действительно никак не различить. Но это можно сделать детектировав присутствие антивируса (авторы это делают путем посылания тестового вируса). Кроме того авторы обнаружили, что размеры буферов чаще всего равняются 64, 128 и 256 KB, что очень типично для сетевых устройств, в то время как антивирус в принципе может иметь буфер гораздо большего размера. Ну и плюс, авторы для замера размера буфера посылали не HTTP пакеты по TCP, а UDP пакеты с мусором, так что веб-модуль тут не при чем.
Это чрезвычайно странно, потому что я сейчас сам проверил (через 208.67.220.220) — выдало www.l.google.com [74.125.87.104]
А возможно OpenDNS делают подмену только в США, чтобы народ это не замечал по локализованной странице. Кстати, авторы обнаружили, что помимо OpenDNS, такими подменами помимо OpenDNS балуется один из штатовских провайдеров.
Проанализировал, нужно для джавы открывать порты для нормальной работы…
Подскажите, пожалуйста, кто-нибудь, как вот это расценивать:
Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1492 bytes. The bottleneck is at IP address x.x.x.x [тут похоже шлюз моего прова].
Подскажите, пожалуйста, кто-нибудь, как вот это расценивать:
Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1492 bytes. The bottleneck is at IP address x.x.x.x [тут похоже шлюз моего прова].
NOD 32 на него ругается и кидает в карантин
Network buffer measurements (?): Uplink 2600 ms, Downlink 1300 ms
We estimate your uplink as having 2600 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
We estimate your downlink as having 1300 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large downloads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large downloads at the same time.
Гм… это у всех так?
We estimate your uplink as having 2600 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
We estimate your downlink as having 1300 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large downloads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large downloads at the same time.
Гм… это у всех так?
Хороший сервис. Только зря он ругается на закрытые порты RPC, NetBIOS и SMB.
Sign up to leave a comment.
Netalyzr — тест интернет подключения