Гарантируется ли TCP в порядке?

Если я отправляю два сообщения TCP, нужно ли мне обрабатывать случай, когда последний приходит до первого? Или это гарантирует, что вы прибудете в том порядке, который я пришлю? Я предполагаю, что это не пример с Twisted-specific, потому что он должен соответствовать стандарту TCP, но если кто-нибудь, кто знаком с Twisted, может предоставить ответ Twisted для моего собственного душевного спокойствия, это было бы оценено 🙂

  • Как закрыть сокет, оставленный открытым убитой программой?
  • Как я могу иметь несколько клиентов на TCP Python Chat Server?
  • Python, отправляющий словарь через TCP
  • pcap python library?
  • Каково фактическое воздействие вызова socket.recv с bufsize, который не является силой 2?
  • Извлечение полученных данных в сокет tcp в Python
  • Получить флаги TCP с помощью Scapy
  • Twisted transport.write
  • 4 Solutions collect form web for “Гарантируется ли TCP в порядке?”

    Пока два сообщения отправляются по одному и тому же TCP-соединению , заказ будет сохранен. Если между одной и той же парой процессов открываются несколько соединений, у вас могут быть проблемы.

    Что касается Twisted или любой другой асинхронной системы событий: я ожидаю, что вы получите сообщения с dataReceived в порядке получения байтов. Однако, если вы начнете отжимать работу на отложенные вызовы, вы можете, erm … «перевернуть» ваш поток управления до неузнаваемости.

    TCP ориентирован на соединение и предлагает клиентам доставку по заказу . Конечно, это относится к уровню соединения: индивидуальные соединения независимы.

    Следует отметить, что мы обычно называем «TCP-потоки» и «UDP-сообщения».

    Какую бы клиентскую библиотеку вы не использовали (например, Twisted), базовое TCP-соединение не зависит от нее. TCP будет предоставлять «сообщения протокола» для вашего клиента. Под «протокольным сообщением» я, конечно, ссылаюсь на протокол, который вы используете на уровне TCP.

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

    TCP «гарантирует», что получатель получит восстановленный поток байтов, поскольку он был первоначально отправлен отправителем. Однако между конечными точками отправки / приема TCP (т. Е. Физической сетью) данные могут быть получены не в порядке, они могут быть фрагментированы, могут быть повреждены и могут даже быть потеряны. TCP учитывает эти проблемы, используя механизм рукопожатия, который приводит к повторной передаче плохих пакетов. Стек TCP на приемнике помещает эти пакеты в том порядке, в котором они были переданы, так что, когда вы читаете из своего сокета TCP, вы получаете данные, поскольку они были первоначально отправлены.

    Когда вы вызываете метод doRead в Twisted, данные считываются из сокета до размера буфера. Эти данные могут представлять собой одно сообщение, частичное сообщение или несколько сообщений. Вы должны извлечь сообщения из буфера, но вам гарантировано, что байты находятся в их переданном порядке в этот момент.

    Извините за грязную воду с моим предыдущим сообщением …

    TCP – это поток, UDP – это сообщение. Вы смешиваете условия. Для TCP верно, что поток поступит в том же порядке, в каком он был отправлен. В TCP нет никаких сообщений об ограничении, появляются байты по мере их поступления, интерпретируя их как сообщения до вас.

    Python - лучший язык программирования в мире.