Я исследую проблему, из-за которой приложение (на основе Java) не получало все сообщение, которое было разделено на два сегмента TCP. У меня есть след, который доказывает, что оба сегмента были отправлены на сервер.
В ходе расследования я не обнаружил отброшенных пакетов на сетевых адаптерах, но заметил следующее в netstat -s:
16 packets pruned from receive queue because of socket buffer overrun
845 packets collapsed in receive queue due to low socket buffer
Я предполагаю, что потерянный сегмент TCP может быть одним из этих 16 сокращенных пакетов.
Вопрос (ы) здесь следующий:
Есть ли смысл попробовать настроить tcp_rmem? Должен ли я ожидать, что на хорошо настроенном сервере / сети сокращенные пакеты будут равны 0?
Маловероятно, что проблему нужно решать на системном уровне, а не на уровне приложений. Если что-то теряется в TCP, одноранговый узел повторно отправляет это - так устроен TCP.
Более вероятно, что есть неправильные предположения о том, как работает TCP в приложении Java. Например, распространенной ошибкой является трактовка TCP как протокола на основе сообщений, а не потока байтов, и предположение, что одно чтение получит все данные, которые были только что отправлены. Поскольку это не гарантируется, это приведет к тому, что приложение Java иногда будет читать только часть сообщения, даже если остальная часть в конечном итоге будет доступна для чтения приложением.