LINUX.ORG.RU

seek для tcp-потока в условиях шейпинга


0

0

Пришла в голову такая идея: пусть сервер отсылает некотрый длинный поток данных по tcp, при этом клиент точно знает что первая половина данных ему не нужна, а вторая нужна как можно быстрее. При этом ограничение скорости определяется наиболее узким местом канала - шейпером у провайдера клиента (или технологией последний мили до клиента(модем)). Также, предполагая худшее, положим что протокол верхнего уровня тупой и не поддерживает seek (например http с отключённым range). Таким образом, единственная возможность получить данные второй части быстрее - это извращения на уровне tcp. А именно предлагается следующее: поскольку причиной того, что сервер отправитель отсылает данные с реальной скоростью канала клиента, а не быстрее является то, что клиентом установлен малый размер tcp-окна и что подтверждения о доставке от клиента приходят не слишком быстро.

Что будет, если клиент установит большое tcp-окно и на те данные которые ему не нужны, будет присылать подтверждения ранее их получения? Насколько я понимаю канал сервера на отдачу будет работать в полную силу и, поскольку канал клиента не может принять столько данных, часть (ненужных клиенту) входящих пакетов будет дропаться (или буферизоваться, но после переполнения буфера опять дропаться).

То есть получится, что первая часть потока будет пропущена "вникуда" на скорости канала сервера, после этого начнётся нормальная закачка нужных данных клиентом на его скорости.

Вопрос скорее теоретический, нежели практический, ибо сейчас ситуация модем + сервер без докачки уже малоактуальна. Однако всё же интересно узнать о том, насколько реалистично выглядит такая реализация "forward seek" для tcp, и какие могут быть проблемы? Возможно кто-то имел опыт с подобными приёмами тогда, когда это было действительно актуально на практике?

★★

Чисто теоретические соображения:

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

Не исключено, что удастся даже как-то схитрить - скажем, подождав, пока отправитель выстрелил всё окно, и пока шейпер успокоится, подтвердить первый сегмент, чтобы наверняка узнать положение окна и подтвердить его целиком. Эффект от таких хитростей сильно зависит от тонкостей TCP.

В остальном, imho, не стоит нарушать протокол, подтверждая данные, в существовании которых ты не уверен.

Если тебе нужен seek на практике, лучше подними прокси и оберни поток, добавив нужную функциональность.

alexsaa
()

Сама концепция TCP подразумевает, что данные будут получены полностью и в правильном порядке.
В реальной жизни это значит, что приложение читает данные из соединения исключительно последовательно, в результате чего никак не может получить второй байт раньше первого.
А может быть я просто не понял идеи?

ShprotX
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.