Насколько я понимаю, TCP берет часть данных и разрезает ее насегментыкоторые передаются по протоколу TCPсессия.
Теперь предположим, что у меня, как у клиента, есть два фрагмента данных A, Bкоторые я хочу отправить на сервер. Каждый фрагмент делится на 3 сегмента, образуя в общей сложности 6 сегментов.
Я отправлю эти 6 сегментов через Интернет, но я не могу гарантировать порядок, в котором сервер их получит. К счастью, TCP-сервер перестраивает для меня неупорядоченные сегменты.
Однако для моего приложения фрагменты Aи Bполностью независимы, поэтому я не хочу, чтобы сервер ждал Aсегменты, если все Bсегменты были получены, или наоборот. По сути, я хочу два независимых сеанса TCP для фрагментов Aи B.
Возможно ли, чтобы клиент и сервер имели параллельные, независимые сеансы TCP? Глядя на записи заголовка TCP, я не вижу "номер сеанса". Я вынужден использовать разные порты источника или назначения?
решение1
Конечно, вы можете иметь два параллельных, независимых сеанса TCP между одним и тем же клиентом и сервером. В противном случае, только для одного примера, веб-браузеры не смогли бы извлечь HTML-страницу и изображение, или два изображения с веб-сервера одновременно.
Дискриминатором для сеансов TCP является не «номер сеанса», а кортеж(локальный-адрес, локальный-порт, удаленный-адрес, удаленный-порт). Пока хотя бы один из них отличается, это другой сеанс TCP.
Так что в ответ на ваш вопрос, да, вы вынуждены использовать другой исходный ИЛИ целевой порт. Ваш стек TCP откажется устанавливать соединение (выдавая ошибку EADDRINUSE), если вы попытаетесь использовать один и тот же исходный И целевой порт. Все это предполагает, что локальный адрес и удаленный адрес везде одинаковы.
Но это не то, о чем обычно стоит беспокоиться. Обычно инициаторам TCP (клиентам) не нужно привязываться к определенному порту. Они позволяют ядру автоматически выбирать исходный порт, не вызывая его bind()до того, как они вызовут connect(). Ядро обязательно выберет другой исходный порт для второго соединения.
решение2
Принятый ответ правильный и отвечает на вопрос, но вопрос касается проблемы, решение которой отличается от использования нескольких потоков TCP.
Проблема "блокировки начала очереди", которую вы описываете, является одной из причин, побудивших использовать протокол Quick UDP Internet Connections (QUIC). Рекомендую посмотретьэта веб-трансляцияот Google о QUIC, если вам интересно, как он решает эту и другие проблемы.
Конечно, естьQUIC в Википедиислишком.