Re: проблемы в связке squid + TSO + windows 98

From

Alexander Kolesnikoff (2:5020/400)

To

Alex Semenyaka

Date

2007-01-15T15:35:42Z

Area

RU.UNIX.BSD

From: Alexander Kolesnikoff <ak@hvv.uku.com.ru>

Alex Semenyaka <Alex.Semenyaka@p640.f640.n461.z2.fidonet.org> wrote:
> Hello Alexander!
> 
> 15 Jan 07 04:23, you wrote to me:
> 
> >> Смешное заключается в том, что сессия закрывается _клиентом_, а не
> >> сервером. То есть, твоя сессия описывается на уровне логики так: 1)
> >> Прошёл TCP-handshake, инициированный клиентом. У сервера окно закрыто.
> >> 2) Сервер открыл окно приёма. Сделал он это мгновенно после handshake
> >> (через половину миллисекунды после получения ACK!), так что вряд ли
> >> тут какая-то проблема с анонсированным нулевым окном. Больше это
> >> похоже на защиту от попыток прислать данные в момент handshake. Надо
> >> бы в исходниках посмотреть, но я уверен, что проблема не в этом.
> AK>    Если кто-то хочет прислать данные в момент хэндшейка - он их пришлёт,
> AK> независимо от анонсированного приёмной стороной размера окна.
> 
> Хм. Ну так он может их прислать и вообще просто так, наобум. Точно также,
> как некто может не сбрасывать скорость при задержке пакетов, не соблюдать
> таймауты, не пользоваться slow start... Однако это же не повод не
> "сообщать" (косвенно) другой стороне о том, что нужно вот это всё сделать?
> Протокол TCP by design предполагает кооперативность сторон.
> 
> Конечно, это только гипотеза - надо посмотреть, как оно всё-таки в коде.
> Жаль, мне сейчас сделать это негде (точнее, это потребует больших усилий).
> 
> AK> Полагаю, что если это и защита, то криво как-то сделанная. А ты не
> AK> наблюдал реакцию FreeBSD на анонсированное ей окно нулевого размера
> AK> ? ;-)
> 
> А что с ней не так? Специально не изучал, но в случаях, когда такое
> наблюдалось - отправитель честно переставал передавать данные.

   Всё так, только вот если и дальше окно не открывать, сессия стоит
мертвая. В отличии от фряхи, у виндюка таймауты гораздо меньше и сессию она
завершает раньше (в моём случае это был телнет). Кстати, не помню сейчас,
отвалился ли сам вообще в этом тесте телнет на фряхе.

> 
> Да собственно в этой эхе недавно совсем был пример с cvsupом (кажется, у
> Виктора Судакова). Когда на клиенте закрывалось окно, и сервер переставал
> отдавать данные - из-за чего средняя скорость была как-то довольно невелика.
> 
> >> 3) А вот тут зачем-то клиент соединение закрывает.
> >>
> >> Что-то мне подсказывает, что сначала искать надо на клиенте :)
> AK>   Скорее всего так и есть. Например, не так давно win98 клиенту помогла
> AK> ... переустановка системы. Симптомы примерно те же: отказ устанавливать
> AK> соединение (в моём случае это был PPP) по непонятной причине.
> 
> Подождём от Дениса результата двух экспериментов, которые я описал...

  В связи с вновь открывшимися обстоятельствами (pf) всё ясно. Только вот
зачем же так издеваться над своими же клиентами? ;-) Сквид ставят в
локальной сети для ускорения, а тут клинтов нулевым окном в самом начале ...
Понятно, что это сделано было не специально. Полагаю, надо эту фичу
выключить. Может и проблема с клиентами win98 решиться.

 Alexander
--- ifmail v.2.15dev5.3
 * Origin: UKU (2:5020/400)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5019/26 5020/18 175 194 400 545 982 1057 1909 1922 2238 2395 2871
SEEN-BY: 5020/4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080 1957 5034/10 13
SEEN-BY: 5035/38 5036/1 5045/7 5049/1 5051/15 5054/1 4 8 9 11 28 35 36 37 45
SEEN-BY: 5054/66 67 70 75 84 85 5059/9 5060/88 5061/15 5062/10 5063/3 5064/7
SEEN-BY: 5066/18 5075/5 5076/1 5077/70 5084/9 5085/13 5095/20 5096/18 6001/10

PATH: 5020/400 545 5054/1 37