|
|
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Помогите, пожалуйта внети ясность в вопрос. Мой коллега утверждает, что из-за действия шейпера могут потерятся данные в сети. Обмен по протоколу TCP. По суди дела утверждается следующие : мы устанавливаем связь между сокетами по TCP. Посылаем 3 блока данных : data1, data2, data3 по одному и тому же соеденению. При достаточной загрузке сети в результате действия шейпера может получить data1, data3 (без data2 !!!). Причем, ни приемник ни отправитель об этом не узнают! И мне был расписан механизм такого искажения: источник[SEQ=1][дата1] -> шейпер -> приемник приемник[ACK=1] -> шейпер -> источник источник[SEQ=2][дата2] -> шейпер (вот тут что-то случилось и шейпер 'сбросил' пакет) шейпер[ACK=2]->источник источник[SEQ=3][дата3] -> шейпер[SEQ=2][дата3] -> приемник приемник[ACK=2]->шейпер[ACK=3]->источник Т.е. шейпер преднамереноо исказил заголовки пакетов, чтоб мы не заметили пропажу данных! Может ли шейпер работать столь криминальным образом? Поясните, пожалуйста, взможно ли такое? Как же целостность данных, гарантированная TCP? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 10:21 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vlТ.е. шейпер преднамереноо исказил заголовки пакетов, чтоб мы не заметили пропажу данных! Может ли шейпер работать столь криминальным образом?По моему Вы смешиваете два вопроса в один. Да, конечно может. Если это и является целью шейпера — исказить заголовки пакетов и помешать нормальной TCP сессии :) Почитайте например про «Comcast против bittorrent» ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 11:21 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Спасибо, что откликнулись! Речь идет не о каких-нибудь злоумышленниках, а о реальных интернет провдерах! В общем дело такое, надо обеспечить взаимодействие программ, был предложен протокол TCP. И вот сейчас говорится, что нормальная работа невозможно, потому что при провисании линии в процессе обмена данные незримо теряются. Незримо для отправителя и приемника, по TCP! Я настаивал на больших задержках или обрыве связи - нет именно, что промежуточные данные могут потерятся. Могут ли так работать реальные провайдеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 11:34 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vl...Могут ли так работать реальные провайдеры? вообще то шейпер вроде как был для распределения ресурсов(т.е. пропускной способности канала), между пользователями. т.е. по идее должен понижать скорость. пути разные. но уж точно не за счёт умыкания данных. это уже не корректная работа. по крайней мере вам никто не запрещает по TCP гнать зашифрованный трафик, где пропажа данных (не пакетов а данных) будет равнозначна обрыву канала. кстати рассмотрите повнимательней заголовки которые формирует шэйпер. сдаётся мне вы не внимательно их рассмотрели. особенно обратиет внимание на поинты подтвёрждённых данных. не думаю что шэйпер (при подтверждении приёма второй пачки) оставил их без изменений. удачи вам (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 12:54 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
[quot kolobok0]vs_vl...М кстати рассмотрите повнимательней заголовки которые формирует шэйпер. сдаётся мне вы не внимательно их рассмотрели. особенно обратиет внимание на поинты подтвёрждённых данных. не думаю что шэйпер (при подтверждении приёма второй пачки) оставил их без изменений. Это цитата моего коллеги-оппонента, не данные, не мое мнение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 13:02 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vlРечь идет не о каких-нибудь злоумышленниках, а о реальных интернет провдерах!Comcast как раз реальный интернет провайдер, один из крупнейших в США :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 14:16 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Ёшvs_vlРечь идет не о каких-нибудь злоумышленниках, а о реальных интернет провдерах!Comcast как раз реальный интернет провайдер, один из крупнейших в США :) Но я не нашел информации, что он описанным способом действовал, что сужал дотуп - да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 15:28 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vlвот тут что-то случилось и шейпер 'сбросил' пакет На глючной системе пакеты могут теряться и безо всякого шейпера. Но если предположить, что шейпер работает ПРАВИЛЬНО - то для каждого узла (или сессии - в зависимости от настроек) он создаёт свою очередь пакетов, и отправляет из в пределах выделенной полосы строго в FIFO-порядке. (Это - точно. Далее - ЕМНИП.) Если количество задержанных пакетов превышает заданный предел - шейпер должен послать источнику стоп-пакет. Единственным источником потерь может служить случай, когда канал настолько узок, что некоторые пакеты "пересиживают" в очереди время своей жизни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 15:32 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vlЁшпропущено... Comcast как раз реальный интернет провайдер, один из крупнейших в США :) Но я не нашел информации, что он описанным способом действовал, что сужал дотуп - да.Если бы он просто сужал доступ, никто особо и не возмущался бы. Comcast именно что внедрялся в передаваемый через его сети трафик и портил TCP сессии: http://en.wikipedia.org/wiki/Comcast Comcast implemented measures using Sandvine hardware which sends forged TCP RST (reset) packets, disrupting multiple protocols used by peer-to-peer file sharing networks. This prevented most Comcast users from uploading files. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 16:40 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Ёшvs_vlпропущено... Но я не нашел информации, что он описанным способом действовал, что сужал дотуп - да.Если бы он просто сужал доступ, никто особо и не возмущался бы. Comcast именно что внедрялся в передаваемый через его сети трафик и портил TCP сессии: http://en.wikipedia.org/wiki/Comcast Comcast implemented measures using Sandvine hardware which sends forged TCP RST (reset) packets, disrupting multiple protocols used by peer-to-peer file sharing networks. This prevented most Comcast users from uploading files. Да, спасибо, не сразу это заметил. Но, ИМХО, это меньший криминал, по сравнению с вырезанием данных из потока. Я все-таи склонясь к мнению, что применение вырезния данных в потоке шейпером - плод фантазии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 18:06 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vl, нет. не возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2012, 19:19 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Всем спасибо! Будем считать, что никто из tcp потока данные не выбрасывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2012, 11:44 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Шейперы тоже не резиновые, не могут они буфферизовать и аккуратно задерживать траффик каждого клиента, без выкидывания пакетов не обойтись - не вижу в этом ничего страшного. Рассчитывать на гарантированную доставку пакета через дикий интернет вообще нельзя для серьёзных систем. Можно заюзать UDP, если не требуется передавать длинные потоки и самим обеспечивать контроль передачи, тем более, что этот контроль и при TCP придётся делать, TCP ничего не "гарантирует" как пишут в некоторых книжках, он только обеспечивает порядок в длинном потоке байтов и содержит механизм повторения передач, который нельзя назвать "гарантирует". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2012, 12:53 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
gidroturbinaШейперы тоже не резиновые, не могут они буфферизовать и аккуратно задерживать траффик каждого клиента, без выкидывания пакетов не обойтись - не вижу в этом ничего страшного. Рассчитывать на гарантированную доставку пакета через дикий интернет вообще нельзя для серьёзных систем. Можно заюзать UDP, если не требуется передавать длинные потоки и самим обеспечивать контроль передачи, тем более, что этот контроль и при TCP придётся делать, TCP ничего не "гарантирует" как пишут в некоторых книжках, он только обеспечивает порядок в длинном потоке байтов и содержит механизм повторения передач, который нельзя назвать "гарантирует". Выкидываение пакетов- да. Но TCP будет их перепосылать. Появятся задержки в доставке. Если уж совсем плохо возможен разрыв сокета. 'TCP ничего не "гарантирует"' ИМХО, правильнее сказать либо гарантирует, пускай и очень медленно, либо разрывается. 'он только обеспечивает порядок в длинном потоке байтов' - Если заметите, в старьтовом сообщении как раз теряется порядок(data1, потом data3), и по этому поводу и был задан вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2012, 19:12 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
vs_vlgidroturbinaШейперы тоже не резиновые, не могут они буфферизовать и аккуратно задерживать траффик каждого клиента, без выкидывания пакетов не обойтись - не вижу в этом ничего страшного. Рассчитывать на гарантированную доставку пакета через дикий интернет вообще нельзя для серьёзных систем. Можно заюзать UDP, если не требуется передавать длинные потоки и самим обеспечивать контроль передачи, тем более, что этот контроль и при TCP придётся делать, TCP ничего не "гарантирует" как пишут в некоторых книжках, он только обеспечивает порядок в длинном потоке байтов и содержит механизм повторения передач, который нельзя назвать "гарантирует". Выкидываение пакетов- да. Но TCP будет их перепосылать. Появятся задержки в доставке. Если уж совсем плохо возможен разрыв сокета. 'TCP ничего не "гарантирует"' ИМХО, правильнее сказать либо гарантирует, пускай и очень медленно, либо разрывается. 'он только обеспечивает порядок в длинном потоке байтов' - Если заметите, в старьтовом сообщении как раз теряется порядок(data1, потом data3), и по этому поводу и был задан вопрос. А-а-а, ничего себе. Выпадение данных из TCP-потока - это уже криминал какой-то глючный, а не пропадание пакетов. По идее если пришёл data3, но data2 пока отсутствует, ты из сокета их оба не прочтёшь. А из сокета валится data1 + data3, то это жесть... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.01.2012, 19:23 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
gidroturbina...этот контроль и при TCP придётся делать, TCP ничего не "гарантирует" как пишут в некоторых книжках, он только обеспечивает порядок в длинном потоке байтов и содержит механизм повторения передач, который нельзя назвать "гарантирует". это Вы батенька погорячились (по поводу TCP). названные вами книги - в пень. Либо читать внимательней. давайте от печки... т.е. с гарантий :) 1) UDP - гарантирует посылку данных в сеть. 2) TCP - гарантирует упорядоченную доставку переданных данных либо дисконнект. т.е. рекомендуют рассматривать канал TCP как трубу для передачи данных. всё. все ваши рассуждения по поводу гарантий и потерей пакетов - это путанье холодного с мягким. надо понимать, что говоря о TCP мы имеем пользовательский уровень, и MAC уровень. дык вот на MAC уровне пакеты имеют право приходить беспорядочно, теряться, фрагментироваться (есть всякие умные словосочетания - медленный старт, быстрый старт, потеря пакета и т.д.). а вот на пользовательском уровне - см. гарантии п.2.. всё остальное - (как говорили в одном советском фильме) - БРЯХНЯ!!! удачи вам (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2012, 13:44 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Чтобы понять, где у меня конкретно брехня, мне бы конкретные мои цитаты. Не нашёл у вас противоречий с собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.01.2012, 13:58 |
|
||
|
Возможна ли потерия данных по TCP из-за шейпера
|
|||
|---|---|---|---|
|
#18+
Прикольно. Ни один местный линупсятник в LARTC так и не разобрался, что ingress шейпер так и действует - дропает те пакеты, которые поступают слишком быстро, и - это абсолютно нормально для TCP (и совсем ненормально для UDP, конечно, но кто вам виноват - нефиг торрентом засирать каналы?). http://lartc.org/howto/lartc.cookbook.ultimate-tc.html Читайте, дети, много думайте. # filter *everything* to it (0.0.0.0/0), drop everything that's # coming in too fast: tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \ 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2012, 10:26 |
|
||
|
|

start [/forum/topic.php?fid=16&fpage=74&tid=1342503]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
45ms |
get topic data: |
8ms |
get forum data: |
4ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 347ms |

| 0 / 0 |
