|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 18 Oct 2005 16:08:30
To : Zahar Kiselev
Subject : Re: Дык на чём остановиться?
--------------------------------------------------------------------------------
Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> wrote:
ZK> Oct 18 01:08 05, Kirill Frolov wrote to Artem Chuprina:
KF>> тянется раза в ~4 дольше, чем через fido-протоколы. Тот же suck
[...]
KF>> Зато умеет почту отдавать медленно и нудно по одному сообщению --
ZK> А вот это да, действительно гадость.
ZK> Причем основная задница в том, что у провайдера (для примера тот же вебплюс)
ZK> стоит крутое коммуникационное оборудование, в котором буферы килобайтов на
ZK> дцать. От этого плохо(медленно) работает все, что требует частого
ZK> взаимодействия "вопрос/ответ". Это если качаешь один огромный файл по http -
ZK>
Hе этого. То есть вовсе не от размера буфера.
Если подумать, то размер буферов должен быть ограничен _снизу_ требованием
отсутствия дропов. Дроп намного страшнее задержки. Сверху ограничения нет.
ZK> то он "со стороны интернета" заливается сразу большим куском в этот буфер,
ZK> а потом с модемной стороны из него вытекает с максимальной скоростью на
ZK> которую способен модем. Обратно идут весьма редкие ACK, которые заливающий
ZK> сервер не ждет для того чтобы залить следующий кусок. Hу то есть он их ждет
ZK> конечно, но "долго и лениво", продолжая в это время лить данные.
Вы описываете ситуацию, в которой скорость перекачки ограничена модемом.
Какие в таком случае претензии к параметрам провайдерского роутера? :)
Сколько бы пакетов в его буфере не лежало, быстрее в модем они не полезут.
ZK> Если же сервер хочет что-то "услышать" на каждый кусок данных небольшого
ZK> размера - дело хуже. Он кидает этот кусок данных в сторону модемного юзера -
ZK> кусок проваливается в буфер коммуникационного оборудования со скоростьб
ZK> стомегабитного эзернета. Все, таймаут у сервера пошел, он уверен что
ZK> отправил данные юзеру и ждет от него ответ. Дальше ничего не посылат.
ZK> Модемный же юзер данные еще не получил, у него может вообще на модеме
ZK> ретрейн случился, данные они где-то там посередине в канале болтаются:)
ZK> Соответственно отвечать серверу он и не думает - ибо не на что еще отвечать.
ZK> Данные дойдут - ответит, хорошо если сервер этого дождется. То есть в одном
ZK> логическом канале мы имеем мало того что два участка с абсолютно разными
ZK> характеристиками(эзернет и телефонную линию), так еще и буфер посередине.
Всё правильно, QoS сам по себе не возникнет. Если он нужен - надо просить
провайдера расставить приоритеты для трафика на downlink'e.
Hо можно немного улучшить ситуацию, если не допустить скопления пакетов
в провайдерском роутере, а подобрать параметры канала так, чтобы очередь
возникла у получателя. Это довольно сложная задача, и требует немалой
квалификации нетадмина. Hо в целом ряде типичных условий - решаемая.
Бонус от её решения - возможность управления QoS'ом на клиентском узле.
ZK> "чистый" tcp даже на таком странном канале живет довольно прилично, у него
ZK> все же интеллекта достаточно чтобы и к такому подстроиться, однако если
ZK> поверх собственно tcp оказывается что-то примитивное типа nntp или даже той
ZK> же Гидры с небольшим размером пакета, что требует частой
ZK> посылки подтверждений или команд на ту сторону - то тормоза гарантированы.
Верно. Правда, мало кого интересует скорость nntp - ведь очень мало
людей, выбирающих, какие постинги они хотели бы скачать, а потом ждуших
закачки. Подавляющее большинство качает интересные эхи подряд - им так
проще (читай дешевле).
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
