Компьютерный форум NoWa.cc Здесь может быть Ваша реклама
Правила Форума
редакция от 22.06.2020
Форум .::NoWa.cc::.
Вернуться   Компьютерный форум NoWa.cc > Компьютеры и Интернет > Спутниковый приём > Спутниковый интернет

Уважаемые пользователи nowa.cc. Мы работаем для вас более 20 лет и сейчас вынуждены просить о финансовой помощи по оплате за сервер.
Окажите посильную поддержку, мы очень надеемся на вас. Реквизиты для переводов ниже.
Webmoney Webmoney WMZ: 826074280762 Webmoney WME: 804621616710
Кошелёк для вашей помощи YooMoney 4100117770549562
YooMoney Спасибо за поддержку!
Ответ
 
Опции темы Опции просмотра Language
Старый 07.05.2006, 12:51   #1
ViP
 
Аватар для ANGEL OF FIRE
 
Пол:Мужской
Регистрация: 09.05.2005
Адрес: Планета земля
Сообщений: 2,063
Репутация: 8694
По умолчанию O факторах, влияющих на скорость приема данных при использовании интернет через спутн

Внимание!!!

[IMG]http://img171.**************/img171/6761/lucifer2ta2.gif[/IMG]


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

Если после нарушения Вы решите создать новый аккуант на форуме и снова нарушите правила, оба аккуанта будут заблокированы, поэтому не следует усложнять своё положение.

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


[IMG]http://img187.**************/img187/8364/el1dq12zfin6.gif[/IMG]

Статус

Инструкция по форуму

Правила раздела Спутниковый приём
ANGEL OF FIRE вне форума
 
Ответить с цитированием Вверх
Здесь может быть Ваша реклама
Здесь может быть Ваша реклама


Реклама: thinkpad x1 carbon gen 12туры на валаам из москвы на теплоходе цены туда и обратноequipe harmonyрекламные вывески в москведиван офисный до-23


Старый 31.07.2006, 01:25   #2
ANGEL OF FIRE
ViP
 
Аватар для ANGEL OF FIRE
 
Пол:Мужской
Регистрация: 09.05.2005
Адрес: Планета земля
Сообщений: 2,063
Репутация: 8694
По умолчанию O факторах, влияющих на скорость приема данных при использовании интернет через спутн

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



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

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

Пропускная способность TCP/IP соединения ограничена двумя пунктами:
1) временем возвращения - RTT round trip time
2) размером TCP окна.

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

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

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

Как видно из следующего примера, чем больше объектов имеет запрашиваемая страница, тем выше будет скорость передачи.
Количество объектов_______ 2 ____ 4 _____ 8 ______16 _____ 32
Скорость передачи, Кбит/сек 34 ____ 83 ___ 140 ____ 295 ___ 560
Время передачи__________ 3 sec__ 3 sec__ 3 sec__ 3 sec__ 3 sec

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

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

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

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

Наиболее оптимальные значения MTU и MaxRcvWindow является:
MTU: 1020 и выше.
MaxRcvWindow: 32768
ANGEL OF FIRE вне форума
 
Ответить с цитированием Вверх
Эти 4 пользователя(ей) сказали cпасибо за это полезное сообщение:
Старый 11.03.2008, 15:34   #3
KiberDen
Неактивный пользователь
 
Аватар для KiberDen
 
Регистрация: 24.07.2007
Сообщений: 18
Репутация: 0
По умолчанию Ответ: O факторах, влияющих на скорость приема данных при использовании интернет чер

ANGEL OF FIRE,опешите поподробнее куда именно подставлять эти значения заранее спосибо

Последний раз редактировалось KiberDen; 11.03.2008 в 15:39..
KiberDen вне форума
 
Ответить с цитированием Вверх
Ответ


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Как ограничить скорость интернет? m_sergey Архив 10 04.08.2013 19:29
Скорость закачки торрентс через VPN Fotiniys Безопасность 2 09.01.2009 11:53
Проблема приема пакета через TClientSocket S_lip Delphi 1 26.08.2007 06:18

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 23:02. Часовой пояс GMT +3.


Copyright ©2004 - 2025 NoWa.cc

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2025, vBulletin Solutions, Inc. Перевод: zCarot
Время генерации страницы 0.10788 секунды с 11 запросами