Проблемы с skype

[Ervin]

При подключении напрямую тебе выдаёт белый ип, а через роутер нат ?

Не понял. Что такое нат? Прошу написать тоже без сленга.
При передергивании кабеля из роутера в ноут и обратно на сайте провайдера приходилось подтверждать что адрес изменился (я так понимаю идет речь о мас адресах). Изменить адрес можно один раз в час.

[lach]

Ирвин, не парься с адресом
Ребята, топикстартер же написал что ВАЙФАЙ доступ глючит...
Если бы ему девайс лочили - он бы вобще не работал

[Stalker]

аффтар, одолжи у кого-нить другую WiFi-точку и попробуй с ней.
если тормоза в Skype исчезнут - то проблема в твоей Asus RT-10N.
если в данной железке никаких таких спецнастроек на Skype нет - однозначно фтопку!

[Ervin]

Ирвин, не парься с адресом

Я Эрвин*
Спасибо за советы. Попробую с open точкой, другой точкой и возможно притарабаню другой ноут.

[Freelancer]

Если используется "wide channel"/40Mhz канал выключи, с ним получается медленнее чем без него, поиграйся с каналами, выключи торренты.

[Freelancer]

И не слушай никого, асус хорошие роутеры.

[Ervin]

Если используется "wide channel"/40Mhz канал выключи, с ним получается медленнее чем без него, поиграйся с каналами, выключи торренты.

wide channel - такого у себя не нашел. Ширина канала 40Mhz. Торренты не юзаю вприницпе.

И не слушай никого, асус хорошие роутеры.

Я знаю, ибо очень серьезно подошел к выбору и считаю что взял лучшее в соотношении цена/качество.

[Freelancer]

поставь 20 Mhz, у меня 40 Mhz работало на много медленнее чем 20.
Ещё возможно это проблемма с тем что твой канал используют другие wifi точки у соседей, можешь посмотреть кто рядом с помощью утилиты inssider.

[Freelancer]

wide channel = 40 Mhz

[bach]

У скайпа часто тормоза бывают при работе через нат, а без него всё норм.
Почитай как скайп нат обходи http://ru.wikipedia.org/wiki/Skype#.D0. ... 0.B8.D1.8F
и про сам нат http://ru.wikipedia.org/wiki/NAT .
Если ип натовый то он будет выглядеть так 192.168.х.х или 10.х.х.х
Вот топик о тормозах в скайпе при передаче файлов http://forum.skype.com/index.php?showtopic=87494 (правда он старый).
Попробуй через точку доступа поговорить с кем-то с белым ип адресом и без фаервола , если тормоза останутся то это не от ната.

[lach]

Bach, ну при чем тут НАТ ?
Не бывает адресов белых и черных, серых ит.п. Есть маршрутизируемые (публичные) и кажется 3 диапазона приватных.
Трансляция адресов - нормальна практика которая успешно используется на протяжении десятилетий и ни о какой нагрузке речь не идет... Да практически все компьтеры, да и сервера в подавляющем кол-ве организаций находятся за NAT-ом, и как правило далеко не за одним... И это ни как не сказывается на передаче данных...
Ну как можно настолько безумные вещи говорить

[bach]

Белый ип и тд это конечно выдуманная (в оф документах нету её) терминология, но всё-таки достаточно популярная. Адресов приватных немного больше есть ещё 172.16.0.0/12 но её редко используют, есть ещё адреса АПИПА 169.254.x.x . А линк на сайте скайпа вы наверно не читали, а там написано :

A relayed transfer means that you are unable to make a direct connection to the other party because of your firewall or NAT (Network Address Translation / router) configuration or that of the remote party. In this case, the file transfer is relayed though other peers on the network. When a transfer is relayed, Skype will limit the file transfer speed to 1.0 kB/second. Only peers with plenty of available bandwidth are used for relay purposes.

Пост конечно старый но лимит есть и сейчас только чуть больше (и для видео тоже). Не понятно почему вы стали о нагрузке говорить я о ней ни слова не сказал. Порты серверов которые работают через нат пробрасывают, что со скайпом не происходит. А насчёт того что это распространённая практика так от неё сейчас с приходом ipv6 хотят отказаться и выдавать каждому клиенту подсеть /64 . И то что нат никак не сказывается на передачи данных, я бы так не сказал. К примеру пров даёт вам натовый ип, а вы подняли веб сервер и кто его сможет посетить ?
И чего же я такого безумного сказал, я ведь сказал лишь то - что если оба клиента за натом, то скайп может тормозить, но об этом они сами на своём форуме писали ?

[bach]

NAT это скалка в одном месте для пиринговых сетей, а скайп как раз пиринговая сеть. Перед создателем пиринговой сети стоит задача предусмотреть методы обхода НАТ. К примеру проброс портов с помощью UPNP или начать передавать трафик пользователей через кого то ещё, или ещё что-то придумать (иногда способы действуют только для одного из видов НАТ). Если в конце концов никакими хитростями не получается обойти, то передают трафик через кого-то, а он может даже этого и не знает. Если у него платный трафик то ему будет потом очень весело Но этого кого-то надо ещё найти и желательно он не должен сильно увеличивать путь трафика, иначе при передачи будут заметные задержки. А что если он взял и загрузил свой канал по полной ? И этого кого-то должно быть несколько, так как один из них может вдруг пропасть из сети. После того как мы выбрали через кого будет идти трафик, мы должны дать знать всем остальным что-бы они его не перегрузили, ведь его трафик не безграничный. Но что если в тот момент как мы его выбрали, его выбрал кто-то ещё, и нам больше нету места ? А что если тех кто находится за нат намного больше чем тех кто имеет прямое подключение, тогда найти через кого можно пустить трафик может быть большой проблемой.
Скайп вполне мог тормозить из за НАТ, и такие жалобы часто случаются. По этому у него есть дополнительные настройки для того чтобы обойти его http://forum.skype.com/index.php?showtopic=683363.
Хотя нат может быть и не причём. Вот http://www.skypeclub.ru/viewtopic.php?t=6771 человек убедился что проброс портов через нат работает, но скайп всё равно тормозит, а роутер у него такой же.
Если причина не в нат, тогда остаётся только QoS или плохой wi-fi линк. Для того что-бы проверить линк пропингуй роутер через вайфай, сеть должна быть не нагруженной. Если пинг большой значит проблема в wi-fi соеденении.
Если это QoS, тогда можно попробовать не официальные прошивки (естественно на свой страх и риск).

[lach]

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

У нас в отделе сидит 10 человек которые пользуются скайпом, плюс еще немного рассыпаны по конторе, при этом я 100% знаю что траффик проходит НАТ дважды. Один раз на маршрутизаторе, который из-за отсутствия AS-ки тупо мониторит линки, за ним вырожденная сетка, которая натится, а между ней и локалкой стоит еще межсетевой экран, который также натит.

При этом скайп мало того что гоняет траффик в оба конца, но и файлы замечательно передает.
Порты внутрь ЛВС не проброшены ни для кого.

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

Кто-то дома, используя WIFI-роутер, заморачивался проброской портов для скайпа?

З.Ы. Бач, это к тому, что проблема в НАТ просто нереальна.

[People]

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

[Oasis]

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

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

Spoiler

Show

Path MTU discovery (RFC 1191). Суть технологии заключается в том, что при соединении двух хостов устанавливается параметр DF (don’t fragment, не фрагментировать), который запрещает фрагментацию пакетов. Это приводит к тому, что узел, значение MTU которого меньше размера пакета, отклоняет передачу пакета и отправляет сообщение ICMP (Internet Control Message Protocol) типа Destination is unreachable (Хост недоступен). К сообщению об ошибке прилагается значение MTU узла. Хост-отправитель уменьшает размер пакета и отсылает его заново. Такая операция происходит до тех пор, пока пакет не будет достаточно мал, чтобы дойти до хоста-получателя без фрагментации.
http://ru.wikipedia.org/wiki/MTU#.D0.A2 ... _discovery

[People]

я методом подбора. для моего провайдера (оптима технология ADSL через PPPOE) он составил 1452.
и там не то чтобы он поднимал скорость аплоада, а просто происходила стабилизация связи... уж почему так происходит я не наю, как правило если это обычная домашняя сеть то этим не заботишься, а вот Укртелеком, к примеру, и роутер ДЛИНК образовывали прикольную проблему в виде невозможности отправлять письма через РОР3 и аплоадить фотографии:)

Подбирал следующим методом: запускал пинг на шлюз провайдера с определенным размером пакета (MTU), постепенно уменьшая его с 1500 до тех пор, пока шлюз провайдера не ответил мне корректно на пинг. ping -l [MTU_Size] gateway_IP вроде так.

[lach]

Пипл,
MTU меняется от сегмента к сегменту.
Пересборка пакетов - это нормальное явление.
Искуственно занижая размер МТУ ты снижаешь скорость в своем сегменте сети.

[People]

ЛАЧ.
Всего лишь выполнял рекомендации производителя роутера (Cisco).
MTU меняется в том случае если используется Path MTU discovery, если используется соединение PPPoE то есть большая вероятность проблем из-за того что используется размер MTU отличный от стандартного.
Именно поэтому рекомендовал попробовал, а пока топик стартер не расскажет какой у него провайдер и какая технология подключения используется, думаю что бесполезно дискутировать на любые темы:)
З.Ы. в экзаменах от мелкомягких есть целая куча вопросов связаная с проблемами всяческих модемных соединений метод лечения тот же - изменение размера MTU