|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
есть клиент(192.168.3.20) ws(arduino) он отсылает северу(192.168.3.4) (tomcat) данные. всё работает. но при просмотре обмена в WireShark возник вопрос - почему на каждые два отправления клиента есть отправление клиенту? это нормально или что-то надо поправить? и если не нормально - что надо смотреть? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:32 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
вот из WireSark ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:34 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
TCP, вообще-то протокол с гарантированной доставкой. Поэтому подтверждения доставки должны быть как минимум. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:35 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
BlazkowiczTCP, вообще-то протокол с гарантированной доставкой. Поэтому подтверждения доставки должны быть как минимум.тогда на каждое отправление должен быть ответ, тут такого нет ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 11:37 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
https://networkengineering.stackexchange.com/questions/12485/window-size-and-ack-number https://serverfault.com/questions/348666/when-the-tcp-engine-decides-to-send-an-ack То как тебе кажется TCP должен работать и от как он работает на самом деле это немного разные вещи. За деталями в описание стандарта TCP. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 12:04 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
автортогда на каждое отправление должен быть ответ, тут такого нет https://docs.oracle.com/javase/8/docs/technotes/guides/net/socketOpt.html] TCP_NODELAY Disable Nagle's algorithm. Valid for (client) Sockets. Nagle's algorithm ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 12:09 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 12:43 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Cheblinавтортогда на каждое отправление должен быть ответ, тут такого нет https://docs.oracle.com/javase/8/docs/technotes/guides/net/socketOpt.html] TCP_NODELAY Disable Nagle's algorithm. Valid for (client) Sockets. Nagle's algorithm Имеет косвенное отношение к вопросу. В том смысле, что его выключение никаким образом не гарантирует наличие пары пакетов запрос-подтверждение (но возможно немного увеличивает вероятность). ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 13:25 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Локшин Марк, В том смысле, что его выключение я гдето писал о ВЫключении? я просто цитировал мануал. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 14:14 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
CheblinЛокшин Марк, В том смысле, что его выключение я гдето писал о ВЫключении? я просто цитировал мануал. А к чему тогда вообще эта ссылка на мануал? Причина того, что количество тикетов с подтверждением не соответствует количеству отправлений клиента вовсе не в алгоритме Нейгла. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 15:12 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Локшин Марк, причина ... вовсе не в алгоритме Нейгла. хорошо. это был мой неправильный ответ. вероятно есть правильный? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2018, 17:26 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
CheblinЛокшин Марк, причина ... вовсе не в алгоритме Нейгла. хорошо. это был мой неправильный ответ. вероятно есть правильный? Выглядит так: точного ответа я не знаю, но возьмите вот хоть какой-нибудь. Мы же тут не туфли покупаем. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 08:24 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Выглядит так: уже второй говорит что я не прав. (и я легко с этим соглашусь.) но правильного ответа от "критиков" так и не прозвучало. Ы? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 09:04 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Cheblin...правильного ответа... ответ уже прозвучал. если вы знаете "правильный ответ" - напишите. проанализируйте в чём правильность его. напишите отличия от тех ответов что прозвучали. а то уже ваш вопрос сваливается в какую-то викторину. если по сути: пакеты подтверждения отсылаются по нескольким критериям. и один из - временной интервал. За этот интервал могут прийти на приём много чего. Всё зависит от скорострельности обработки на каждом из хостов, от загрузки сети, от маршрута прохождения, от алгоритмов(могут например IP пакеты менять очерёдность) на промежуточных и конечных узлах. самое главное, что Вы как юзверь(по отношению к TCP/IP) должны знать - что это ПОТОК. Это самое главное. А как оно бегает внутри - если вы никогда не писали сами сетевой стэк - поверьте, Вы многое чего не поймёте... с уважением (круглый) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 10:09 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
CheblinВыглядит так: уже второй говорит что я не прав. (и я легко с этим соглашусь.) но правильного ответа от "критиков" так и не прозвучало. Ы? Работа TCP построена на таймерах. В частности есть таймер, который отвечает за повторную отправку. Когда какое-то сообщение отправляется, то принимающая сторона может сразу не отправить подтверждение. В каждом заголовке TCP пакета есть поле, в котором лежит номер последнего подтвержденного пакета. Подтвердить пакет - это эквивалентно отправке пакета с пустыми данными, что достаточно расточительно. Поэтому, если есть данные для отправки в обратную сторону, то попутно с ними будет отправлено подтверждение последнего принятого пакета, если нет, то получатель будет ждать некоторое время (пока не появятся данные в обратном направлении или не придут еще пакеты - подтверждение пакета с номером N подтверждает все пакеты с номером до N). Когда нужно закончить ожидание? До того, как у отправителя сработает таймер повторной отправки, с учетом времени на доставку пакета с подтверждением в обратном направлении. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 11:05 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Локшин МаркCheblinпропущено... уже второй говорит что я не прав. (и я легко с этим соглашусь.) но правильного ответа от "критиков" так и не прозвучало. Ы? Работа TCP построена на таймерах. В частности есть таймер, который отвечает за повторную отправку. Когда какое-то сообщение отправляется, то принимающая сторона может сразу не отправить подтверждение. В каждом заголовке TCP пакета есть поле, в котором лежит номер последнего подтвержденного пакета. Подтвердить пакет - это эквивалентно отправке пакета с пустыми данными, что достаточно расточительно. Поэтому, если есть данные для отправки в обратную сторону, то попутно с ними будет отправлено подтверждение последнего принятого пакета, если нет, то получатель будет ждать некоторое время (пока не появятся данные в обратном направлении или не придут еще пакеты - подтверждение пакета с номером N подтверждает все пакеты с номером до N). Когда нужно закончить ожидание? До того, как у отправителя сработает таймер повторной отправки, с учетом времени на доставку пакета с подтверждением в обратном направлении. перевожу на наглийский Nagle's algorithm is a means of improving the efficiency of TCP/IP networks by reducing the number of packets that need to be sent over the network. It was defined by John Nagle while working for Ford Aerospace. It was published in 1984 as a Request for Comments (RFC) with title Congestion Control in IP/TCP Internetworks (see RFC 896). The RFC describes what he called the "small-packet problem", where an application repeatedly emits data in small chunks, frequently only 1 byte in size. Since TCP packets have a 40-byte header (20 bytes for TCP, 20 bytes for IPv4), this results in a 41-byte packet for 1 byte of useful information, a huge overhead. This situation often occurs in Telnet sessions, where most keypresses generate a single byte of data that is transmitted immediately. Worse, over slow links, many such packets can be in transit at the same time, potentially leading to congestion collapse. Nagle's algorithm works by combining a number of small outgoing messages and sending them all at once. Specifically, as long as there is a sent packet for which the sender has received no acknowledgment, the sender should keep buffering its output until it has a full packet's worth of output, thus allowing output to be sent all at once. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 12:35 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Cheblin, И что? Алгоритм Нейгла - это пакетирование со стороны отправителя. А подтверждения - со стороны получателя. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 12:54 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
это пакетирование со стороны отправителя. А подтверждения - со стороны получателя. вот в этом месте у меня произошла путаница. спасибо Локшин Марк Вы внесли ясность. Я был неправ. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 13:13 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Локшин МаркРабота TCP построена на таймерах. В частности есть таймер, который отвечает за повторную отправку. Когда какое-то сообщение отправляется, то принимающая сторона может сразу не отправить подтверждение. В каждом заголовке TCP пакета есть поле, в котором лежит номер последнего подтвержденного пакета. Подтвердить пакет - это эквивалентно отправке пакета с пустыми данными, что достаточно расточительно. Поэтому, если есть данные для отправки в обратную сторону, то попутно с ними будет отправлено подтверждение последнего принятого пакета, если нет, то получатель будет ждать некоторое время (пока не появятся данные в обратном направлении или не придут еще пакеты - подтверждение пакета с номером N подтверждает все пакеты с номером до N). Когда нужно закончить ожидание? До того, как у отправителя сработает таймер повторной отправки, с учетом времени на доставку пакета с подтверждением в обратном направлении. и https://networkengineering.stackexchange.com/questions/12485/window-size-and-ack-number как-то не сочетаются или я что-то не понял? в одном месте время в другом размер окна ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 14:08 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
вадяЛокшин МаркРабота TCP построена на таймерах. В частности есть таймер, который отвечает за повторную отправку. Когда какое-то сообщение отправляется, то принимающая сторона может сразу не отправить подтверждение. В каждом заголовке TCP пакета есть поле, в котором лежит номер последнего подтвержденного пакета. Подтвердить пакет - это эквивалентно отправке пакета с пустыми данными, что достаточно расточительно. Поэтому, если есть данные для отправки в обратную сторону, то попутно с ними будет отправлено подтверждение последнего принятого пакета, если нет, то получатель будет ждать некоторое время (пока не появятся данные в обратном направлении или не придут еще пакеты - подтверждение пакета с номером N подтверждает все пакеты с номером до N). Когда нужно закончить ожидание? До того, как у отправителя сработает таймер повторной отправки, с учетом времени на доставку пакета с подтверждением в обратном направлении. и https://networkengineering.stackexchange.com/questions/12485/window-size-and-ack-number как-то не сочетаются или я что-то не понял? в одном месте время в другом размер окна Что с чем не сочетается? из ссылкиThe Window Size does not determine how often the Receiver should be sending ACKnowledgements. Originally, the TCP protocol called for an acknowledgement to be sent after each segment was received. Later, TCP was optimized to allow the Receiver to skip ACKs and send an ACKnowledgment every other packet (or more). Кроме того, это было общее описание "на пальцах" части идей протокола. За более подробным для интересующихся - например к Таненбауму, там все гораздо более подробно и доступно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 14:51 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
т.е. если пакеты большие - работает одно правило, если маленькие - другое? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 15:09 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
вадя, Если я правильно понимаю, что подразумевается под "правилами", то они применяются одновременно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 16:48 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
Локшин Маркто они применяются одновременно.в моём случае размер окна не будет превышен никогда, поэтому вероятность применения "правила" по размеру равна нулю. и ответ от сервера очень редкий. скажем так - у меня работает вот это "правило": Локшин МаркКогда нужно закончить ожидание? До того, как у отправителя сработает таймер повторной отправки, с учетом времени на доставку пакета с подтверждением в обратном направлении. но тут есть вопрос - что с нумерацией пакетов? почему номер ответа от сервера совпадает с номером последующего отправления серверу? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2018, 19:57 |
|
Вопрос к знатокам протоколов
|
|||
---|---|---|---|
#18+
вадяно тут есть вопрос - что с нумерацией пакетов? почему номер ответа от сервера совпадает с номером последующего отправления серверу? Википедия Transmission Control ProtocolAcknowledgment Number (ACK SN) (32 бита) — если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2018, 10:04 |
|
|
start [/forum/topic.php?fid=59&msg=39674818&tid=2121903]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
160ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 272ms |
0 / 0 |