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