Здравствуйте, Pavel Dvorkin, Вы писали:
PD>На нашей машине (не сервер и не клиент) стоит сниффер, который их ловит. Естественно, ловит он не TCP, а IP пакеты. Выглядят они вполне прилично, и никаких отрицательных эмоций у меня не вызывают. Фильтр по протоколу и порту. PD>Вопросы такие.
Лично я бы не решал эту задачу "в лоб" реализацией снифера (или довеска к сниферу), понимающего все ньюансы TCP. Лучше реализовать эдакий простой прокси, который с точки зрения сервера выглядел бы как клиент, а с точки зрения клиента — как сервер. Тупо accept клиента — connect на сервер, recv от клиента — send на сервер, и recv от сервера — send на клиент. Между recv и send можно что угодно делать с данными. Клиенту вместо IP:порта настоящего сервера прописывам IP:порт нашего прокси и вуаля.
Извините, лень читать всё что было написано в этой ветке, может уже и предлагали.
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Лично я бы не решал эту задачу "в лоб" реализацией снифера (или довеска к сниферу), понимающего все ньюансы TCP. Лучше реализовать эдакий простой прокси, который с точки зрения сервера выглядел бы как клиент, а с точки зрения клиента — как сервер. Тупо accept клиента — connect на сервер, recv от клиента — send на сервер, и recv от сервера — send на клиент. Между recv и send можно что угодно делать с данными. Клиенту вместо IP:порта настоящего сервера прописывам IP:порт нашего прокси и вуаля.
Ни к серверу, ни к клиенту нет никакого доступа. Абсолютно никакого. Известно, что они шлют сообщения, формат сообщений уровня приложения известен, протокол TCP/IP, порт известен. Все. Никакие изменения ни сервера, ни клиента невозможны.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ни к серверу, ни к клиенту нет никакого доступа. Абсолютно никакого. Известно, что они шлют сообщения, формат сообщений уровня приложения известен, протокол TCP/IP, порт известен. Все. Никакие изменения ни сервера, ни клиента невозможны.
Хмм... Но должна же быть возможность изменения IP, на который подключается клиент?
И даже если нет, то можно их обмануть на более низком уровне. Изолируем сервер от клиента физически, VLAN'ами или подобным. Прокси будет смотреть в обе сети, двумя интерфейсами. Пусть клиент по-прежнему подключается на тот IP, который нельзя изменять, только фактически он будет подключаться на наш прокси. Сам прокси будет пересылать данные на другой интерфейс, в сеть сервера, и сервер тоже будет думать что имеет дело с настоящим клиентом. При необходимости на сетевых интерфейсах прокси даже можно поставить MAC-адреса, принадлежащие настоящим клиенту и серверу.
Re[11]: TCP пакеты
От:
Аноним
Дата:
21.01.08 19:37
Оценка:
а система не загнется обрабатывая десятк тысяч пакетов в секунду?
Здравствуйте, Michael Chelnokov, Вы писали:
MC>И даже если нет, то можно их обмануть на более низком уровне. Изолируем сервер от клиента физически, VLAN'ами или подобным. Прокси будет смотреть в обе сети, двумя интерфейсами. Пусть клиент по-прежнему подключается на тот IP, который нельзя изменять, только фактически он будет подключаться на наш прокси. Сам прокси будет пересылать данные на другой интерфейс, в сеть сервера, и сервер тоже будет думать что имеет дело с настоящим клиентом. При необходимости на сетевых интерфейсах прокси даже можно поставить MAC-адреса, принадлежащие настоящим клиенту и серверу.
Э-э-э-э... А ты уверен, что это реально сделать человеку, не имеющему особого опыта в сетях, да еще и за 2 недели?
Здравствуйте, Michael Chelnokov, Вы писали:
MC>Хмм... Но должна же быть возможность изменения IP, на который подключается клиент?
И этого нет.
MC>И даже если нет, то можно их обмануть на более низком уровне. Изолируем сервер от клиента физически, VLAN'ами или подобным.
За подобное предложение меня изолируют от проекта .
Еще раз — есть реально работающая система. Вмешиваться в ее работу не дано категорически. Если бы этого требования не было, все было бы проще.
>Прокси будет смотреть в обе сети, двумя интерфейсами.
Здравствуйте, Аноним, Вы писали:
А>а система не загнется обрабатывая десятк тысяч пакетов в секунду?
Ну десятков тысяч там все же не будет. Это во-первых. Но вообще-то да, именно в этом и проблема. Надо потерять как можно меньше пакетов. Именно поэтому я так и борюсь за быстродействие.
Здравствуйте, DOOM, Вы писали:
DOO>Э-э-э-э... А ты уверен, что это реально сделать человеку, не имеющему особого опыта в сетях, да еще и за 2 недели?
В чем я действительно уверен, так это в том что все ньюансы TCP реализовать ему будет на порядок сложнее.
А прокси на транспортном уровне — это на страницу кода, после прочтения первого же примера работы с сокетами.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — есть реально работающая система. Вмешиваться в ее работу не дано категорически.
Ладно, отставить прокси транспортного уровня. Хотя это был, IMHO, лучший вариант, и реализуемый всего за несколько дней с тестированием.
Вопрос следующий. Порт на сервере, как я понимаю, фиксирован. IP клиента и сервера — тоже. А порт на клиенте? Если тоже фиксирован, то можно упростить себе жизнь, подсунув PCAP'у соответствующий фильтр на пару IP_клиента:порт->IP_сервера:порт. Я бегло прочитал вашу дискуссию и вижу что вы пока учитывали только возможность повторной передачи. А возможность переустановки TCP-соединения? Железяки железяками, но кто сказал что они этого не умеют?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>А сложностей у меня никаких нет. Мне просто ответ на вопрос нужен — можно ли при определенных условиях быть уверенным, что 2 сообщения не попадут в один пакет. И если да — каковы эти условия. DOO>Ответ: можно быть почти уверенным в этом. DOO>Условия: выставлена опция TCP_NODELAY.
Здравствуйте, Изя Рнет, Вы писали:
ИР>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>А сложностей у меня никаких нет. Мне просто ответ на вопрос нужен — можно ли при определенных условиях быть уверенным, что 2 сообщения не попадут в один пакет. И если да — каковы эти условия. DOO>>Ответ: можно быть почти уверенным в этом. DOO>>Условия: выставлена опция TCP_NODELAY.
ИР>Нет. Прекратите распространять опасную дезинформацию. ИР>http://net-geek.org/dbg/2007/10/reading-tcp-socket.html
В общем-то это и вкладывалось в смысл слова почти
Многие из приведенных в статье по ссылке проблем в данном случае неактуальны.
MC>Вопрос следующий. Порт на сервере, как я понимаю, фиксирован. IP клиента и сервера — тоже.
Да.
>А порт на клиенте? Если тоже фиксирован,
Выбирается случайным образом. Алгоритм мне неизвестен. Но не меняется до SYN.
>то можно упростить себе жизнь, подсунув PCAP'у соответствующий фильтр на пару IP_клиента:порт->IP_сервера:порт.
Ну это и так делается.
>Я бегло прочитал вашу дискуссию и вижу что вы пока учитывали только возможность повторной передачи. А возможность переустановки TCP-соединения? Железяки железяками, но кто сказал что они этого не умеют?
Учтено. Вообще-то все оказалось проще, хотя и не 100% надежно. Исходим из того, что ловим пакет с юзеровским заголовком. Из него можно узнать длину всего сообщения (зашито в юзеровские данные). Тем самым известны все seq ожидаемых последующих пакетов этого сообщения. Если все они придут, пусть и с повтором — берем их. Если придет пакет с заголовком опять, а предыдущее сообщение не собралось — выкинуть его. Так что если переустановка TCP произойдет, то просто одно сообщение потеряем , может быть. Весь фокус в том, что я не фиксируюсь на установку соединения (ACK — SYNACK -ACK), а базируюсь только на юзеровском заголовке.
Кстати, у меня в сети этих повторов очень-таки много. А у заказчика вообще нет, по крайней мере не видать. Есть какие-то мысли, почему ? Софт один и тот же.
И еще один вопрос — всем, кто мне помогал своими советами (за что им моя благодарность).
Пусть мы уверены, что 2 "сообщения" не будут инкапсулироваться в один IP-пакет. То, что это в общем случае неверно, я понимаю, но пусть (предположение А). И вот шлется сообщение размером, скажем, 10000 байт. У меня на машине оно приходит пакетами в 1500 байт, то есть 6 пакетов по 1500 байт и последний в 1000 байт.
Вопрос — можно ли быть уверенным в том, что при выполнениии предположения А мы всегда будем иметь именно такую картину — то есть N пакетов с размером таким же, как у первого пакета и 1 последний неполный ? Или же могут быть любые размеры ?
Вопрос не академический. Если это верно — для учета поступивших пакетов хватит булевского массива. Если нет — придется считать длины. А время дорого...
Все происходит в локальной сети (но за однородность ее не ручаюсь, не исключено, что разные машины, с разными сетевыми картами).
PD>Учтено. Вообще-то все оказалось проще, хотя и не 100% надежно. Исходим из того, что ловим пакет с юзеровским заголовком. Из него можно узнать длину всего сообщения (зашито в юзеровские данные). Тем самым известны все seq ожидаемых последующих пакетов этого сообщения. Если все они придут, пусть и с повтором — берем их. Если придет пакет с заголовком опять, а предыдущее сообщение не собралось — выкинуть его. Так что если переустановка TCP произойдет, то просто одно сообщение потеряем , может быть. Весь фокус в том, что я не фиксируюсь на установку соединения (ACK — SYNACK -ACK), а базируюсь только на юзеровском заголовке.
В общем-то ты и вычленяешь поток Я примерно это и предлагал.
PD>Кстати, у меня в сети этих повторов очень-таки много. А у заказчика вообще нет, по крайней мере не видать. Есть какие-то мысли, почему ? Софт один и тот же.
Зависит от кучи параметров — качество проводов, сетевое оборудование, скорость передачи и т.п.
Кстати, именно на Java приложениях наблюдал очень сильные потери пакетов при передаче по гигабитному интерфейсу — стоило перевести интерфейс на 100 мб/с, все становилось в переделах допустимого
PD>Пусть мы уверены, что 2 "сообщения" не будут инкапсулироваться в один IP-пакет. То, что это в общем случае неверно, я понимаю, но пусть (предположение А). И вот шлется сообщение размером, скажем, 10000 байт. У меня на машине оно приходит пакетами в 1500 байт, то есть 6 пакетов по 1500 байт и последний в 1000 байт.
PD>Вопрос — можно ли быть уверенным в том, что при выполнениии предположения А мы всегда будем иметь именно такую картину — то есть N пакетов с размером таким же, как у первого пакета и 1 последний неполный ? Или же могут быть любые размеры ? PD>Вопрос не академический. Если это верно — для учета поступивших пакетов хватит булевского массива. Если нет — придется считать длины. А время дорого...
Не верно. Изя Рнет привел ссылку, в которой все очень хорошо расписано почему (хотя понимание изложенного там требует определенной подготовки).
PD>Все происходит в локальной сети (но за однородность ее не ручаюсь, не исключено, что разные машины, с разными сетевыми картами).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вопрос — можно ли быть уверенным в том, что при выполнениии предположения А мы всегда будем иметь именно такую картину — то есть N пакетов с размером таким же, как у первого пакета и 1 последний неполный ? Или же могут быть любые размеры ? PD>Вопрос не академический. Если это верно — для учета поступивших пакетов хватит булевского массива. Если нет — придется считать длины. А время дорого...
Не изобретайте велосипед. Возьмите tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/). Если не можете использовать код напрямую (как я понял, Вам надо на жаве), то перепишите, — кода, отвечающего за корректную сборку tcp-потока, там кот наплакал. За время не беспокойтесь, если приемник успевает собрать поток, то и вы успеете.
Здравствуйте, DOOM, Вы писали:
DOO>В общем-то ты и вычленяешь поток Я примерно это и предлагал.
.
DOO>Не верно. Изя Рнет привел ссылку, в которой все очень хорошо расписано почему (хотя понимание изложенного там требует определенной подготовки).
Прочитал. Как я понял, идея насчет размеров окна и накопления там невостребованной клиентом информации, вследствие чего серверу посылаются иные размеры окна и он начинает "безобразничать"
ИМХО все же это немного не та ситуация. У меня, похоже, сервер шлет сообщение целиком (разбив на пакеты, естественно), не дожидаясь подтверждения. Иначе откуда столько ресендов ? Букально примерно вот такое имеет место
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, DOOM, Вы писали:
DOO>>В общем-то ты и вычленяешь поток Я примерно это и предлагал.
PD>.
DOO>>Не верно. Изя Рнет привел ссылку, в которой все очень хорошо расписано почему (хотя понимание изложенного там требует определенной подготовки).
PD>Прочитал. Как я понял, идея насчет размеров окна и накопления там невостребованной клиентом информации, вследствие чего серверу посылаются иные размеры окна и он начинает "безобразничать"
PD>ИМХО все же это немного не та ситуация. У меня, похоже, сервер шлет сообщение целиком (разбив на пакеты, естественно), не дожидаясь подтверждения.
Дожидаться подтверждения это не есть задача сервера. Он шлет поток и не о чем не задумывается, а уже "транспортная сущность" выполняет грязную работу. Подтверждение идет не на каждый отдельный пакет (накладно было бы), а на окно — которое еще и имеет переменные размеры.
PD>Иначе откуда столько ресендов ? Букально примерно вот такое имеет место PD>id пакетов с сервера на клиент PD>100,101,102, 103, 104, 102,103, 104, 105, 106, 104, 105, 106, 107, 108PSH PD>Есть другое объяснение ?
Ну тут все более-менее понятно — отсылаются пакеты 100, 101, 102, 103, 104, получатель получает только 100 и 101, после чего все теряет. Потом, скорее всего, срабатывает таймаут на ожидание, он посылает ACK на 101-й пакет, в результате отправитель понимает, что начиная со 102-го надо пересылать.
Реально может быть несколько иное объяснение — тут надо видеть размер окна и ACK'и получателя, чтобы точнее описать происходящее.
Наличие PSH в последнем пакете должно сигнализировать приемнику, что пора бы уже передать данные приложению (до этого они могли копиться в буфере приемника) — так что приложение в результате может вообще все одним куском получить.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вопрос — можно ли быть уверенным в том, что при выполнениии предположения А мы всегда будем иметь именно такую картину — то есть N пакетов с размером таким же, как у первого пакета и 1 последний неполный ?
Я бы сказал что да. В драйвер сетевого интерфейса на передатчике поступают сверху IP-пакеты. Он их разбивает на Ethernet-кадры одинаково. Дополнительных буферов у него нет, разные IP-пакеты в один Ethernet-кадр он не склеит.
Предположение А куда более маловероятно, т.к. модулю TCP поступают порции данных, а не пакеты. Кроме того, у него точно есть буфер. Поэтому он может резать поток на IP-пакеты как ему будет угодно.
Да, кстати. Имейте в виду что последний Ethernet-кадр может быть больше чем требуется, у Ethernet есть ограничение на минимальный размер кадра.
Здравствуйте, Изя Рнет, Вы писали:
ИР>Здравствуйте, Pavel Dvorkin, Вы писали:
ИР>Не изобретайте велосипед. Возьмите tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/). Если не можете использовать код напрямую (как я понял, Вам надо на жаве), то перепишите, — кода, отвечающего за корректную сборку tcp-потока, там кот наплакал. За время не беспокойтесь, если приемник успевает собрать поток, то и вы успеете.
Спасибо, но как вот это понимать ?
However, it currently does not understand IP fragments; flows containing IP fragments will not be recorded properly
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Изя Рнет, Вы писали:
ИР>>Здравствуйте, Pavel Dvorkin, Вы писали:
ИР>>Не изобретайте велосипед. Возьмите tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/). Если не можете использовать код напрямую (как я понял, Вам надо на жаве), то перепишите, — кода, отвечающего за корректную сборку tcp-потока, там кот наплакал. За время не беспокойтесь, если приемник успевает собрать поток, то и вы успеете.
PD>Спасибо, но как вот это понимать ?
PD>However, it currently does not understand IP fragments; flows containing IP fragments will not be recorded properly
Как, как... Берем в руки напильник и... Причем, если речь идет о по сути прямом соединении клиента и сервера, то на такие страшные ошибки как изменение порядка следования пакетов и дублирование пакетов можно и забить, пока никто не заметил
. Я же ясно сказал, что пакет уровня приложения == нескольким IP пакетам. А ты мне опять — если равен ...
