Много сегментов размера обновления окна tcp

#websocket #tcp

#websocket #tcp

Вопрос:

Я тестирую связь с websocket, отправляя небольшие сообщения (180 байт) за 15 миллисекунд. Я всегда получаю на некоторое время (10 или 21 секунду) большую задержку (даже 250 миллисекунд). Я проверил это в wireshark и увидел, что за эти конкретные секунды я получил много сегментов обновления окна tcp. Как на этом экране.

введите описание изображения здесь

Это немного странно, потому что вычисляемый размер окна довольно большой (около 258944 байт). Пример времени для связи:

введите описание изображения здесь

Если я увеличу размер сообщения, у меня не возникнет этой проблемы, и я не получу эти сегменты.

введите описание изображения здесь

Комментарии:

1. Для меня это похоже на потерю пакетов и, следовательно, на контроль перегрузки. Обратите внимание, что все пакеты, помеченные Wireshark как «обновления окна», имеют код 67993 (в то время как SLE и SRE указывают, что он получил данные намного раньше этого). В пакете 2929 67993, наконец, повторно передается, но помечен как «не в порядке», что указывает на то, что Wireshark никогда не видел, что передано раньше. Так что, возможно, захват также неполный.

2. Почему я не получил обычный «ДУБЛИРУЮЩИЙ ACK» вместо сегментов обновления окна? Почему мое окно tcp увеличивается, когда размер довольно большой? У меня никогда не было сегмента полного размера окна.

3. Я не знаю точного определения, используемого Wireshark для повторяющихся подтверждений. Вполне вероятно, что они не считаются дубликатами, потому что окно и SRE меняются. Размер окна увеличивается, скорее всего, потому, что приложение использует данные из очереди RECV.

4. Я также отмечаю, что размер окна увеличился с 62 КБ до 82 КБ за небольшой промежуток времени, что указывает на то, что приложение прочитало около 20 тыс. байт за этот интервал времени, что составляет большое количество сообщений в 180 байт. Возможно, приложение было медленным потребителем, который теперь догоняет, возможно, потому, что это java-приложение, которое нуждалось в GC.

5. Кроме того, обратите внимание, что SEQ увеличивается довольно быстро в «обновлениях окна», но мы не видим никаких поступающих данных, что странно.