Rambler's Top100



     
  Rambler's Top100  
Спутниковый Интернет

В последнее время нам поступает очень много вопросов про спутниковый интернет.
Некоторое время назад, на российском рынке широкому кругу пользователей стала доступна новая провайдерская услуга - интернет через спутник. Условия для пользователей - весьма привлекательные - 21$ в месяц, никакого учета траффика и т.д. Однако, существует еще вторая сторона медали.

Вот какое впечатление создалось у наших специалистов от установок и работы с системой.


ПОЛОЖИТЕЛЬНЫЕ ВПЕЧАТЛЕНИЯ:

Высокая скорость (по сравнению с dial-up).

Нет учета траффика.

Возможность просмотра открытых теле и радиоканалов с Bonum'a прямо на компьютере. (хотя на данный момент открытый - только НТВ ;)) )

Тарелка подходит для приема НТВ+ на телевизоре с помощью обычного ресивера

ОТРИЦАТЕЛЬНЫЕ ВПЕЧАТЛЕНИЯ:

Асиметричность доступа (обязательно использовать еще и исходящий канал типа dial-up).

Общая неустойчивость работы системы (случаются падения, пожалуй, чаще чем у наземных провайдеров)

Не все протоколы работают (на данный момент только HTTP & FTP). Это значит, например, что фильмы из Сети не посмотришь ;((. Хотя НТВ обещает изменить ситуацию в скорости.

Не работают каналы односторонней загрузки информации (PUSH). Можно было бы составить расписание и в определенное время заказанные данные сыпались бы со спутника прямо на компьютер без вашего и dialup участия.

Сложность настройки (ПРОВЕРЕНО НА ОПЫТЕ). Только некоторые причины низкой скорости вы можете найти ниже.


СКОРОСТНЫЕ ФАКТОРЫ

В данный момент большинство пользователей спутникового интернета испытывает проблемы, связанные со скоростью получения данных. В связи с этим назрела необходимость дать краткие разъяснения, от каких параметров зависит скорость, а так же некоторые замечания по поводу работы TCP/IP в спутниковых системах.

Система передачи данных через спутник способна обеспечить однонаправленную передачу данных пользователю, обратная связь часто обеспечивается по наземным линиям связи, т.е. по обычному Dial-Up. Такой тип подключения приводит к тому, что мы имеем соединение с различной пропускной способностью к пользователю и от него. Большой процент пользователей (обычно около 85% от общего числа абонентов ISP) в основном получает информацию, нежели передает, поэтому такая асимметричность канала оправдана. Но высокая степень зависимости каналов (в большей степени это относится к обратному каналу) друг от друга становится критическим моментом для работы с подобной системой. Пропускная способность TCP/IP соединения ограничена двумя пунктами:


временем возвращения - RTT round trip time
размером TCP окна.

Производительность DVB-систем построена на возможности IP->DVB шлюза устанавливать максимальные размеры TCP окон, а именно делать их равным 65535 байт. Использование конечным пользователем TCP стеков, отвечающих всем современным стандартам, позволяет IP->DVB шлюзам выполнять RFC-1323, имеющей возможность запрашивать увеличение размера окна для повышения пропускной способности канала.
Ограничения, которые накладывает обратный канал, являются в подобных системах наиболее «узким» местом, т.к. весь исходящий трафик, который порождает удаленный клиент, должен быть получен и обработан прокси-сервером до посылки клиенту. Какие же негативные моменты порождает данный процесс?

Данный процесс особенно негативно отражается на работе с web-узлами, т.к. IP протокол имеет ряд «медленных» мест, а именно IP протокол начинает эффективно работать только тогда, когда от запрашиваемого узла получен основной «скелет» страницы, основной HTML код и начинается подгрузка остальных объектов (картинок, апплетов и т.п.). Любое соединение начинается с запросом клиентом TCP-соединения с Интернет, после чего клиент запрашивает требуемый HTML-документ, обычно это корневая страница сервера. Сервер подтверждает запрос и начинает передачу данных. Сначала он отсылает только один пакет и получает подтверждение о его приеме (ACK), но обычно страница имеет размер больший, нежели чем размер пакета, и сервер передает столько пакетов, сколько требуется для полной передачи запрашиваемой страницы и, соответственно, получает столько подтверждений, сколько необходимо. Если Вся страница передана, то сервер посылает пакет с информацией о конце передачи (FIN).

После получения основного «скелета» страницы, клиент, а точнее его броузер, анализирует поступивший код, на предмет наличия в нем ссылок на графические или еще какие либо объекты. После этого он открывает необходимое количество соединений и начинает получение этих объектов.

Как видно из следующего примера, чем больше объектов имеет запрашиваемая страница, тем выше будет скорость передачи.

Количество объектов Скорость передачи, Кбит/сек Время передачи
2 34 3 сек
4 83 3 сек
8 140 3 сек
16 295 3 сек
32 560 3 сек

Как видно из данной таблицы, наибольшая скорость была достигнута на страничке, имеющей 32 встроенных объекта, но на практике такая ситуация случается довольно редко и средняя скорость при серфинге обычно не превышает 30 – 100 Кбит\сек. Все вышесказанное имеет отношение только к получению WEB трафика, и никаким образом не относится к получению больших файлов.

В случае получения большого объема данных с использованием DVB системы приходится заниматься подстройкой TCP стека самостоятельно, соответствуя рекомендациям ISP.

Как было отмечено выше, на каждый полученный пакет клиент вынужден посылать подтверждение о его получении. Т.к. обратный канал зачастую имеет скорость 28.800 – 33.600, то большое количество подтверждений, значительно замедляют работу системы, т.к. обратное соединение не успевает справляться с тем количеством пакетов, которое необходимо отправить через него.

Выходом из данной ситуации является увеличение размера TCP окна, а именно приводу его к размеру 32768 байт или более. Но также необходимо учесть, что при скорости соединения ниже, чем 19.200 время на передачу пакетов начинает значительно возрастать, вследствие чего может потребоваться менять значения на другие, подобранные экспериментальным путем.

Наиболее оптимальные значения MTU и MaxRcvWindow является:

MTU: 1020 и выше.
MaxRcvWindow: 32768

 

Наши телефоны:

Написать нам

 

Веб Дизайн CuCumber Studio 2003 | Port Polaris 2000-2006