Данные не по порядку в TCP

Question

У меня есть приложение, которое использует минскую библиотеку Apache для общения на основе TCP. Мина-библиотека apache обеспечивает обратный вызов с IOBuffer, который содержит данные, поступающие по сети, однако часто данные поступают не по порядку или с избыточностью. Я пролистал протокол TCP, и он говорит, что протокол всегда обеспечивает доставку данных в правильном порядке. Компания, предоставившая API-интерфейсы для своего сервера, заявляет, что они используют TCP/IP для отправки ответа, однако перед отправкой ответа их сервер не заботится о подтверждении клиента (в этом случае моя библиотека application / apache mina) подключен к серверу. Таким образом, сервер просто выключает сообщение и движется дальше.

Если я не ошибаюсь, это поведение протокола UDP. У меня вопрос, если сервер использует TCP для отправки ответа обратно:

1. Почему я получаю данные о заказе (это редко, но время от времени происходит)?
2. Как может машина, использующая протокол TCP, просто запустить и забыть о данных, не убедившись, что приемное устройство подключено к нему перед отправкой данных?
3. Это действительно TCP или UDP или какой-то вариант протокола TCP?

Answer 1

Apache Mina выполняет асинхронный обмен сообщениями поверх различных транспортов, включая TCP.

Поскольку Mina является асинхронной, следует ожидать доставки вне очереди.

Почему я получаю данные о заказе (это редко, но время от времени происходит)?

Одним из возможных объяснений является то, что используются несколько потоков TCP. Данные, доставленные с использованием одного потока TCP, будут доставляться по порядку, но если используется несколько потоков, данные в одном потоке могут "обогнать" данные в другом потоке, в стеках TCP на передающей или принимающей стороне, в сети или в клиентская библиотека.

Как может машина, использующая протокол TCP, просто запустить и забыть о данных, не убедившись, что приемное устройство подключено к нему перед отправкой данных?

Потому что... надежная доставка не является основным атрибутом Мины.

Если вы используете Mina для связи со службой с конкретным протоколом приложения, этот протокол определит, будет ли разрешена / будет работать "отправка данных до проверки подключения получателя" или нет. Например, это не относится к ответу HTTP, потому что ответ HTTP отправляется на соединение, которое было ранее установлено для отправки запроса.

На самом деле, кажется, что есть множество способов использовать Мину. Некоторые включают протокол приложения; например, см. HttpClientCodec а также HttpServerCodec, Другие нет.

Это действительно TCP или UDP или какой-то вариант протокола TCP?

Если они говорят, что TCP используется в качестве транспорта, то это так. Однако Мина не является ни TCP, ни UDP. Это Мина. Он скрывает детали транспорта.

---

Суть в том, что если вам нужны свойства надежности / порядка доставки TCP/IP, вам, вероятно, следует использовать их напрямую. Mina обеспечивает более высокую производительность, чем обычный TCP/IP, через синхронный сокет, ослабляя обычные свойства (одного) потокового транспорта.