Тема: Решения: Проблемы с Сетью/Интернетом

Кнопка Пуск->пункт Выполнить->набрать cmd->нажать Enter

В открывшемся окне пишем:

Код:

C:\>ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 10.100.1.150
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.100.1.254

Определяем "Default Gateway" (в русскоязычной версии Windows - "Шлюз по-умолчанию").
Дальше посылаем на шлюз - эхореквест:

Код:

ping 10.100.1.254 -n 100

Данный вариант ping'а пошлет 100 пакетов и выведет статистику по своей работе. Тут есть одна рекомендация:

• Если первые несколько ping'ов не прошли и выдали "Request timed out." (в русскоязычной версии Windows - "Превышен интервал ожидания для запроса."), останавливаем выполнение (Ctrl+C) и запускаем заново. Потеря первой пары-тройки ping'ов может отзначать задержку по резолву в обратной зоне службы DNS, так что не есть факт, что это потери именно по layer 3. Конечно-же если потеряно больше чем пара-тройка первых пакетов, то тут уже проблемы другого рода.

После того как вышеприведенная команда закончит свою работу, не надо отсылать всю "простыню", достаточно выделить несколько первых ping'ов, а потом последний и суммарную статистику:

Код:

C:\>ping 10.100.1.254 -l 1500 -n 100

Pinging 10.100.1.254 with 32 bytes of data:

Reply from 10.100.1.254: bytes=32 time=1ms TTL=255
Reply from 10.100.1.254: bytes=32 time=1ms TTL=255
...
Reply from 10.100.1.254: bytes=32 time=1ms TTL=255

Ping statistics for 10.100.1.254:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

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

Код:

C:\> ping 10.100.1.254 -n 100 -l 1500 -f

Опция -f указывает на то, чтобы отослынне пакеты не фрагментировались по MTU. Объяснение физики этого процесса выходит за рамки этого очерка. Опция -l 1500 указывает на то, что мы будем отсылать пакеты размером 1500 байт. Итак Enter. Если пакеты прошли - ура! Значит все хорошо и мы выделяем ту-же статистику, что и в первом варианте (см.выше).
Но так-же вы можете увидеть в ответ "Packet needs to be fragmented but DF set". В этом случае укоротите размер пакета в опции -l. Если опять пакеты не прошли, сделайте это ещё раз. В определённй момент времени покеты начнут идти! У себя я экспериментально установил, что максимальный не фрагментируемый размер пакета - 1472 байт. Запомните это значение (не 1472, а то которое Вы найдёте для себя). Это важно! Можете записать его маркером на своём мониторе (шутка;)), но не забудьте его, чтобы не мучатся в следующий раз. Ну теперь опять пускаем ping:

Код:

C:\>ping 10.100.1.254 -n 100 -l 1472 -f

Pinging 10.100.1.254 with 1472 bytes of data:

Reply from 10.100.1.254: bytes=1472 time=1ms TTL=255
...
Reply from 10.100.1.254: bytes=1472 time=1ms TTL=255

Ping statistics for 10.100.1.254:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

Теперь пустите ping на хост 10.100.100.1, сначала стандартные для Windows 32 байта, а затем найденным размером с опцией -f, и отошлите собранную статистику.

Потом можете попробовать пропинговать таким-же образом сайты в Интернете (например google.com, ya.ru).

В случае проблем с доступом на сайты желательно проверить его доступность с помощью программы WinMTR. В строке Host пишем адрес сайта и жмем Start.

"Момент истины". Зачастую для ethernet карточек размер MTU устанавливается в 1500 байт. Но, как видим выше, в моём случае маршрутизатор не пропустил не фрагментируемые пакеты размером больше чем 1472 байта. Т.е. имеет смысл снизить для сетевой карты размер MTU для 1472 байт, так как маршрутизатор все равно не пропускает целиком пакеты больше этого значения, и фрагментирует их на несколько частей, после чего отсылает. Естественно, что это создает лишнюю нагрузку на маршрутизатор, и плюс к этому, в случае реальных потерь, никому ненужную нагрузку на сеть.

Для установки MTU можно либо вручную подправить реестр (страшно, да? ;)) либо воспользоваться утилитами сторонних разработчиков, например DrTCP. Кстати, определить размер MTU можно и не вручную, как описано выше, а опять таки с помощью специализированых утилит, например mturoute.

И ещё. Чуть было не забыл. Если удалённый хост не отвечает на ping'и (не шлет Ech-Reply), то это не всегда означает, что этот ресурс недоступен. Иногда, для снижения нагрузки на сервер, или ещё по каким либо религиозным причинам, ответы на Echo-Requiest'ы просто отлучаются администраторами, либо просто заблокированы запросы из нашей/вашей сети. Так что критически анализируйте так называемую "недоступность хоста" :)

Панель управления -> Сетевые подключения. Дальше выбираем Вашу сетевую карту. Правая кнопка мышки, жмем Свойства -> Протокол Интернета TCP/IP (Свойства) -> Дополнительно -> WINS -> Параметры NetBIOS...
Где там у Вас отметочка-то стоит? Если у Вас не отмечено "Отключить NetBIOS через TCP/IP", то это значит, что NetBIOS у Вас все-таки включён. Выбираем "Отключить NetBIOS через TCP/IP" и применяем изменения.

Ну и конечно-же, удалите из свойств сетевой карты "Клиент для сетей Microsoft" и "Служба доступа к файлам и принтерам сетей Microsoft" - для работы в Интернет они совсем не нужны.

1. Находим на рабочем столе "Мой компьютер", жмем по нему правой клавишей мыши и выбираем "Свойства";
2. Открываем закладку "Оборудование";
3. Нажимаем кнопку "Диспетчер устройств";
4. Находим категорию "Сетевые платы" (обычно где-то внизу списка), кликаем двойным щелчком по категории, появляется чуть ниже строчка, содержащая название Вашей сетевой платы. кликаем по ней правой клавишей мыши, выбираем "Свойства";
5. Открываем закладку "Дополнительно";
6. Находим в окошке "Свойство:" "Скорость линии или режим дуплекса" либо "Тип носителя" (в зависимости от производителя платы может быть указано что-то иное). Выбираем нужное нам свойство. Правее находится выпадающий список, именуемый "Значение:" Кликнув по нему, выберете 10 Мбит. Поля "Свйоство:" и "Значение:" взаимосвязаны, поэтому если слева выберете что-то не то, справа будет выпадающий список уже с другими значениями.

Выбрать надо именно 10Мбит. Или Вы реально, для работы в Интернете, используете 100Мбит? "Так зачем платить больше?"

Из положительных моментов, снижение скорости до 10Мбит/с:

1. Снизит нагрузку на коммутатор (свич).
2. Улучшит характеристики соотношения сигнал/шум в кабеле, на длинном плече.

Я не говорю, что этот момент сразу-же поможет и настанет райская жизнь. Но если скорость сначала снизите Вы, потом Ваш сосед, потом сосед соседа, потом... Так рано или поздно можно снизить нагрузку на коммутаторы сети. Другой вопрос, что никто этого делать не собирается, а жаль.... :(

Определяющий момент: в договоре указывается максимальное ограничение по скорости на порту клиента. Скорость Интернета и скорость доступа в Интернет - суть разные понятия. Договором определяется именно скорость доступа в Интернет, т.е. скорость на порту оборудования провайдера.

Скорость же входящего трафика из Сети зависит не только от провайдера, но также еще и от нагрузки на удалённый сервер, с которого идет закачка, и ограничения скорости сессии скачивания самим сервером.

Хочется также отметить, что указанная скорость "ДО некоторого значения" означает, что больше этого значения не будет, а ниже, по независящим от провайдера причинам, вполне вероятно.

Т.е. скорость скачивания ЛЮБОЙ информации из Интернета в один и тот же момент времени, но с разных серверов может кардинально отличаться.

Попытаться более-менее объективно оценить скорость Вашего соединения могут помочь тесты.

А вот эхо-реквесты (читай ping'и) предназначены для того чтобы определить доступность удалённого хоста, а также промониторить потери на третьем уровне модели OSI. Всегда радовала способность некоторых клиентов определять скорость по ping'ам... Блин, я так не умею... Научите, а? ;)

По умолчанию QoS (Quality of Service) резервирует для своих нужд 20 % от пропускной способности канала.
Причём, даже если удалить службу Планировщик пакетов QoS из свойств соединения, этот канал не освобождается. Освободить канал, или просто настроить QoS, можно таким образом. Запускаем апплет Групповая политика (gpedit.msc).
В Групповой политике находим Конфигурация компьютера и нажимаем на Административные шаблоны. Выбираем пункт Сеть -- Диспетчер пакетов QoS. Выбираем Ограничить резервируемую пропускную способность.
Теперь уменьшаем Ограничение пропускной способности с 20% до 0, или просто отключаем его.
При желании в Диспетчере пакетов QoS можно настроить и другие параметры QoS. Для активации произведённых изменений остаётся только перезагрузиться.



PS: Для справки, в Windows XP Home Edition нет gpedit.msc, так что по-умолчанию пользователям этой ОС данный рецепт не подходит... Для любопытствующих - может попробовать скопировать gpedit.msc из Windows XP Professional и попробовать таки реализовать этот сценарий. Сам я такого не пробовал, но мало ли... ;)


18.11.2008
Как справедливо намекнули в соседнем топике: "В некоторых публикациях и группах новостей заявлялось, что Windows XP всегда резервирует под нужды механизма QoS 20 % доступной полосы пропускания. Данное утверждение неверно."
Верить или не верить в данном случае Микрософту? Отсылаю к оригинальной статье, а решение принимайте самостоятельно - никто ни к чему не обязывает.

Есть ещё один неприятный момент при работе в Интернете, когда у Вас есть ограничение по скорости. Я не даром приводил задачу для начальных классов школы о втекающей и вытекающей в бассейн воде. Дело в том, что такая-же "петрушка" происходит и с тем трафиком которых является исходящим от Вас.

Предположим, что Вы покупаете канал в Интернет 256Кбит/с, а Ваша сетевая карта настроена в режиме 100Мбит/с (ну или 10Мбит/с - тут это не принципиально). Т.е. Вы будете отдавать на шлюз трафик со скоростью заведомо большей (и во много раз большей!) чем от Вас ожидают. Что при этом произойдёт? Ответ: ванная (стек ip) очень быстро заполнится и вода начнёт выливаться за края (трафик начнёт просто теряться. "лишний" трафик просто перестанет обрабатываться). Безусловно, что в механизме ip существуют механизмы которые контролируют передачу и если что-то где-то потерялось, то потерянный пакет будет отправлен заново - продублируется. Если пакет будет продублирован - это вызовет ненужную нагрузку на Ваш канал, так как этот трафик Вам реально не нужен, он-же был отправлен раньше и т.д. Пока все данные не будут отправлены этот "снежный ком" будет "катиться" и иногда приобретать лавинообразный характер.

Ну не знаю как там в "форточках" (Windows) но в Linux одно из решений этой "проблемы" - ограничить свой исходящий (egress) трафик самостоятельно, в пределах оговорённого Вашим тарифным пакетом, тем согласовав скорость с той, которую ожидает провайдер (оператор услуги):

Код:

# $1 - интерфейс, на котором ограничиваем пропускную способность
# удаляем дисциплины обработки очередей с интерфейса - переводим в состояние pfifo
tc qdisc del dev $1 root
# устанавливаем значение ds
tc qdisc add dev $1 handle 1:0 root dsmark indices 1 default_index 0
# ограничиваем исходящую скорость дисциплиной tbf на 1024Кбит/с (1Мбит/с)
tc qdisc add dev $1 handle 2:0 parent 1:0 tbf burst 3072 limit 20480 mtu 1408 rate 125000bps

Этот код надо вставить куда нибудь, где он будет выполняться после "подъема" интерфейса смотрящего в сторону оператора связи. Безусловно, что вместо $1 необходимо прописать свой реальный интерфейс :)

Кстати оригинальный вариант для tcng выглядит так:

Код:

#define IFACE0  eth3
#define MTU     1408B
#define RATE    1Mbps
#define BURST   3kB
#define LIMIT   20kB

dev IFACE0 {
    egress {
        tbf (mtu MTU,limit LIMIT,rate RATE,burst BURST);
    }
}

Сохраняем в какой нибудь файл. Затем говорим:

Код:

~$ tcng filename.tcng

и получаем результат приведённый выше.

Конечно-же при помощи tcng и tc можно "нарисовать" более сложные политики/решения с дисциплинами htb и т.п., но данный топик для такого рода обсуждений не предназначен ;)

О! Чуть не забыл. Посмотреть какими дисциплинами в данный момент обрабатывается Ваша очередь можно так:

Код:

~$ sudo tc -s qdisc ls dev eth3
qdisc dsmark 1: indices 0x0001 default_index 0x0000 
 Sent 2040274 bytes 4253 pkt (dropped 10, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc tbf 2: parent 1: rate 1000Kbit burst 3Kb lat 136.0ms 
 Sent 2039684 bytes 4250 pkt (dropped 10, overlimits 1942 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
~$ sudo tc -s -d qdisc ls dev eth1
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 119707 bytes 1087 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0

Обратите внимание на dropped - это тот трафик которого от нас, в общем-то, не ждали и мы его не дали в сеть. Тем самым мы снизили нагрузку на оборудование сети, за что, наверное получили виртуальную "спасибу" от администраторов :)

Собственно, в связи с тем, что сеть Датасвит поддерживает функционал QoS:

Сообщение от Fire

DSCP to 802.1p
IP TOS Precedence to Priority Queue Mapping
802.1P Priority to Priority Queue Mapping
TOS/Differentiated Service Enable
Flow Control
Port Priority

Попытаться реализовать "под себя" этот функционал можно переопределив значения поля DSCP, через iptables в таблице mangle. Вот пример с этого форума:

Код:

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A OUTPUT -j DSCP --set-dscp 0x12 
-A OUTPUT -p tcp -m tcp --sport 20 -j DSCP --set-dscp 0x22 
-A OUTPUT -p tcp -m tcp --sport 21 -j DSCP --set-dscp 0x22 
-A OUTPUT -p tcp -m tcp --sport 22 -j DSCP --set-dscp 0x26 
-A OUTPUT -p tcp -m tcp --dport 22 -j DSCP --set-dscp 0x26 
-A OUTPUT -p tcp -m tcp --sport 53 -j DSCP --set-dscp 0x0e 
-A OUTPUT -p udp -m udp --sport 53 -j DSCP --set-dscp 0x0e 
-A OUTPUT -p tcp -m tcp --dport 53 -j DSCP --set-dscp 0x0e 
-A OUTPUT -p udp -m udp --dport 53 -j DSCP --set-dscp 0x0e 
-A OUTPUT -p tcp -m tcp --sport 80 -j DSCP --set-dscp 0x1e 
-A OUTPUT -p tcp -m tcp --dport 80 -j DSCP --set-dscp 0x1e 
-A OUTPUT -p icmp -j DSCP --set-dscp 0x0a 
COMMIT

Естественно, что значения поля dscp и условия для его установки могут отличаться от предложенных выше. На вкус и цвет, как говориться... ;) Только помните, что если весь Ваш поток "закинуть" в EF, то он перестанет быть "гарантированным", надеюсь понимаете почему? ;)
Отдельно хочется отметить, что инструкция -j DSCP --set-dscp не является терминирующей, как DROP, ACCEPT или REJECT, поэтому наиболее общие условия для установки DSCP необходимо описывать раньше, чем частные решения.

PS: Ну и опять таки - это не панацея от всех бед, а лишь один из кирпичиков в Вашем тетрисе :)

Спасибо , некоторые манипуляции действительно ефективные .. качество нета несколько улучшилось
3.Ы Заведующие разделом - прикрипите тему !