[Примечания по компьютерной сети 3] Транспортный уровень

порт

Как отметить процесс в сети?

• Транспортный уровень системы TCP/IP использует [номер порта] для обозначения различных прикладных процессов на прикладном уровне.
• Упомянутый здесь порт является логической концепцией, а не реальным физическим портом.
  
  

Номер порта представлен 16 битами, диапазон значений —0 ~ 65535 , а номер порта разделен на следующие три категории:

• ① Известный номер порта (для сервера)
• ② Зарегистрировать номер порта (для сервера)
• ③ Кратковременный номер порта (для клиента)

Известный номер порта

Общеизвестные номера портов или номера системных портов, численно 0 ~ 1023присвоенные IANA некоторым наиболее важным приложениям TCP/IP, чтобы их знали все пользователи .

При появлении нового приложения IANA должна назначить ему известный порт, иначе другие процессы приложения в Интернете не смогут с ним взаимодействовать.

Зарегистрировать номер порта

Зарегистрируйте номер порта со значением 1024 ~ 49151.Этот тип номера порта используется приложениями , у которых нет общеизвестных номеров портов .

Использование таких номеров портов должно быть зарегистрировано в IANA в соответствии с предписанными процедурами для предотвращения дублирования, например, номер порта по умолчанию Oracle1521 , номер порта по умолчанию MySQL3306 и номер порта по умолчанию tomcat в Java WEB.8080

временный номер порта

Номер порта, используемый клиентом . Значение 49152 ~ 65535: .

Поскольку этот тип номера порта выбирается динамически только во время работы клиентского процесса , его также называют эфемерным номером порта . Этот тип номера порта зарезервирован для клиентских процессов и может быть выбран для временного использования. Теоретически эти порты не должны назначаться серверу, на практике машине обычно 1024с самого начала назначаются динамические порты.

Когда серверный процесс получает сообщение от клиентского процесса, он знает номер порта, используемый клиентским процессом, поэтому он может отправить данные клиентскому процессу.

После завершения связи только что использованный номер клиентского порта больше не существует, и этот номер порта может быть повторно использован другими клиентскими процессами .

протокол транспортного уровня

• TCP : протокол управления передачей
• UDP : Протокол пользовательских дейтаграмм ( Протокол пользовательских дейтаграмм )
  

Каждый протокол предназначен для решения конкретной задачи:

• Протокол CSMA/CD : координирует работу компьютеров на шине.
• Протокол ARP : Получите MAC- адрес соответствующей сетевой карты хоста на основе IP-адреса.
• Протокол IP : решение проблем соединения нескольких гетерогенных сетей.
• Протокол ICMP : для более эффективной пересылки IP- дейтаграмм и повышения шансов на успешную доставку.
• Протокол TCP : обеспечивает надежные услуги сквозной передачи данных.
• Протокол UDP : обеспечивает ненадежные, но эффективные услуги передачи.

• RIP DNS TFTP SNMP DHCP на уровне приложений соответствует протоколу UDP на транспортном уровне .
• SMTP FTP BGP HTTP HTTPS на уровне приложений соответствует протоколу TCP на транспортном уровне.
• В IP- дейтаграмме сетевого уровня есть поле протокола. Значение используется для указания протокола транспортного уровня, используемого текущим сообщением . Это число.

UDP против TCP

UDP-заголовок:

• (1) Исходный порт : номер исходного порта. Используйте его, когда вам нужен ответ от другой стороны. Используйте все 0, когда они не нужны
• (2) Порт назначения : номер порта назначения. Это необходимо использовать при доставке сообщений в конечную точку.
• (3) Длина : длина пользовательской дейтаграммы UDP, минимальное значение — 8 (только заголовок).

TCP-заголовок:

Заголовок TCP включает порт источника, порт назначения, порядковый номер (seq), номер подтверждения (ack) и т. д.

• UDP не требует установления соединения, а TCP ориентирован на соединение.

• UDP поддерживает одноадресную, многоадресную и широковещательную рассылку, тогда как TCP поддерживает только одноадресную рассылку.

• UDP ориентирован на пакеты приложений и не объединяет и не разделяет пакеты; TCP ориентирован на потоки байтов, что также является основой TCP для достижения надежной передачи, управления потоками и контроля перегрузки.

• TCP отправителя рассматривает данные, доставленные прикладным уровнем, как серию неструктурированных потоков байтов . TCP сначала сохраняет байты в своем собственном кэше. Согласно стратегии отправки, часть байтов отправляется первой; получатель извлекает байты. раздел и храниться в собственном кэше; принимающий процесс приложения должен иметь возможность идентифицировать полученный поток байтов и восстановить его в значимые данные приложения.

• UDP предоставляет услуги ненадежной передачи без установления соединения на верхний уровень (подходит для приложений реального времени, таких как IP-телефония и видеоконференции), тогда как TCP предоставляет ориентированные на соединение и надежные услуги передачи на верхний уровень (подходит для приложений, требующих надежной передачи, таких как как передача файлов).

Подведем итог:

TCP-заголовок

Реализация надежной передачи TCP:

• Надежная передача TCP реализована с помощью протокола выборочной повторной передачи (SR) ( два скользящих окна: окно отправки + окно приема ) .
• Скользящее окно TCP измеряется в байтах
• Поля, относящиеся к надежной передаче в заголовке TCP, следующие:
  

seqПоле серийного номера ( ): занимает 4байты.

• То есть для нумерации используются 32[0, 2^32 - 1] бита, а диапазон размеров серийного номера представляет собой сумму 2^32серийных номеров (то есть 4 294 967 296).

• Когда порядковый номер увеличивается 2^32 - 1до , возвращается следующий порядковый номер 0.

• TCP ориентирован на поток байтов , и каждый байт в потоке байтов, передаваемый по TCP-соединению, нумеруется последовательно .

• Начальный порядковый номер всего передаваемого потока байтов должен быть установлен при установке соединения .

• seqЗначение поля в заголовке относится к порядковому номеру первого байта данных, отправляемых в этом сегменте .

Поле номера подтверждения ( ack): занимает 4байты

• Указывает порядковый номер первого байта данных, который, как ожидается, будет получен из следующего сегмента сообщения другой стороны.
  
• Если номер подтверждения = N, это означает, что все данные до порядкового номера N – 1 были получены правильно.

Поле ACK (Подтверждение, подтверждение):

• Поле номера подтверждения действительно только тогда, когда ACK=1.
• Когда ACK = 0, номер подтверждения недействителен.
• TCP предусматривает, что все передаваемые сегменты сообщений должны иметь ACK, установленный в 1 после установления соединения.

Поле окна: занимает 2байты

• Значение окна представляет собой [0, 2^16 - 1]целое число между ними.

• Окно относится к окну приема стороны, отправляющей этот сегмент (а не к собственному окну отправки).

• Значение окна сообщает другой стороне: начиная с номера подтверждения в заголовке этого сегмента сообщения ack, объем данных, который получатель в настоящее время разрешает отправить другой стороне. Причина этого ограничения заключается в том, что пространство кэша данных получателя ограничено. (Простое понимание: когда я отправляю вам данные, я сообщу вам в них, насколько велик мой приемный буфер, и когда вы ответите мне с данными, вы не дадите мне знать, что они выходят за пределы диапазона)

• Короче говоря, значение окна служит основой для того, чтобы получатель мог позволить отправителю установить свое окно отправки. Значение окна часто динамически меняется.

Трехстороннее рукопожатие TCP

Первое рукопожатие: клиент → сервер

• SYN = 1, указывая, что это сообщение запроса TCP-соединения.

• В поле порядкового номера seqустановлено начальное значение, соответствующее исходному порядковому номеруx , выбранному процессом TCP-клиента.

• Правила TCP: SYN = 1сегмент сообщения не может переносить данные, но необходимо использовать порядковый номер.

Второе рукопожатие: сервер → клиент

• SYN = 1，ACK = 1, указывая, что это подтверждающее сообщение для запроса TCP-соединения.
• В поле порядкового номера seqустанавливается начальное значение в качестве начального порядкового номераy , выбранного процессом службы TCP (TCP — это полнодуплексная связь, и как клиент, так и сервер могут получать и получать данные).
• ack = x + 1, что является подтверждением начального порядкового номера, выбранного процессом TCP-клиента.

Третье рукопожатие: клиент → сервер

• ACK = 1, указывая, что это обычный сегмент подтверждающего сообщения
• seq = x + 1, добавляется в качестве текущего значения серийного номера xна основе исходного серийного номера, выбранного в последний раз.1
• ack = y + 1, что является подтверждением начального порядкового номера сервера.

После трехстороннего рукопожатия TCP-соединение между клиентом и сервером установлено, и данные можно отправлять друг другу:

Почему нам нужно в конце отправить обычное подтверждающее сообщение?

Использование трехпакетного рукопожатия вместо двухпакетного для установления TCP-соединения предназначено для предотвращения внезапного прибытия сегмента запроса на соединение с истекшим сроком действия на TCP-сервер.В это время сервер отправит сообщение с запросом подтверждения на TCP-сервер. client., и клиент не может ответить серверу, поскольку он закрыт, сервер будет продолжать отправлять сообщения с запросом подтверждения клиенту, поскольку он не знает, что клиент закрыт, тем самым тратя ресурсы сервера.

Краткое описание трехстороннего рукопожатия

• Первое рукопожатие: клиент отправляет серверу SYN=1 seq=x .

  SYN = 1 указывает, что это сообщение запроса TCP-соединения.

  seq = x означает, что клиентский процесс использует порядковый номер x в качестве начального порядкового номера.

  Правила TCP: сообщение, для которого установлено значение, не может передавать данные, но будет использовать порядковый номер SYN.1

• Второе рукопожатие: сервер отправляет клиенту SYN = 1 ACK = 1 seq = y ack = x + 1 .

  SYN = 1 ACK = 1 указывает, что текущее сообщение является сообщением подтверждения от сервера предыдущему сообщению запроса на соединение, отправленному клиентом.

  ack = x + 1 подтверждает последний начальный порядковый номер x клиентского процесса и ожидает, что начальный порядковый номер следующего сообщения, отправленного клиентом, будет x + 1.

  seq = y означает, что серверный процесс выбирает y в качестве начального порядкового номера.

  И TCP, и UDP представляют собой полнодуплексную связь, и как клиент, так и сервер могут отправлять и получать данные.

• Третье рукопожатие: клиент отправляет серверу ACK = 1 seq = x + 1 ack = y + 1 .

  ACK = 1 означает, что текущее сообщение является обычным сообщением подтверждения в последний раз.

  seq = x + 1 означает, что текущее сообщение выбирает использование последнего начального порядкового номера xплюс 1, который является порядковым номером, ожидаемым сервером.

  ack = y + 1 означает подтверждение порядкового номера y последнего сообщения, отправленного сервером , и ожидание, что начальный порядковый номер следующего сообщения, отправленного сервером, будет y + 1.

Понимание человеческой версии:

• Первый раз (наша сторона): я прошу ( SYN = 1) использовать начальный порядковый номер x( seq = x)
• Второй раз (другая сторона): я подтверждаю получение вашего запроса ( ), в следующий раз вам следует начинать SYN = 1 ACK = 1с серийного номера ( ), я прошу использовать начальный серийный номер в данный момент ( )x + 1ack = x + 1yseq = y
• Третий раз (наша сторона): я подтверждаю получение вашего ответа ( ), в следующий раз вам следует начинать ACK = 1с серийного номера ( ), в настоящее время я использую серийный номер, который вы ожидаете от меня ( )y + 1ack = y + 1x + 1seq = x + 1
  

Понимание дерзкой версии:

Понимание взаимовредной версии:

Почему в конце необходимо отправить обычное подтверждающее сообщение/Почему TCP требуется трехстороннее рукопожатие вместо двустороннего?

• TCP — это надежный протокол управления передачей, а трехстороннее рукопожатие — это минимальное количество раз, чтобы обеспечить надежную передачу данных и повысить эффективность передачи.

Почему? В RFC793, протоколе TCP, указана причина в RFC. Это происходит потому, что:

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

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

3. Чтобы предотвратить внезапное поступление на сервер сообщения с запросом на соединение, срок действия которого истек (например, повторная передача по тайм-ауту), трата ресурсов сервера. Если используется двустороннее рукопожатие, сервер подтверждает, что соединение установлено после первого запроса. В это время, если клиент закрывает соединение и сервер получает ранее истекший запрос TCP-соединения клиента, он отправит запрос клиенту. Отправьте сообщение с запросом на подтверждение. В настоящее время клиент не может ответить серверу, поскольку он закрыт. Сервер продолжит отправлять клиенту сообщения с запросом на подтверждение, поскольку он не знает, что клиент закрыт, в результате чего в отходах.ресурсы .

TCP четыре волны

Процесс подключения TCP-релиза

Первая волна:

• FIN = 1, указывая на сообщение с запросом на освобождение соединения TCP
• TCP предусматривает, что даже если сегмент FIN не несет данных, он использует порядковый номер.

Вторая волна:

Согласно стандарту TCP, ранее отправленный сегмент FIN потребляет порядковый номер, и соединение в направлении от A до B освобождается. В это время TCP-соединение находится в полузакрытом состоянии , то есть A не имеет требования к данным.Отправлено, но если B отправляет данные, A все равно должен их получить . Другими словами, соединение в направлении от Б к А не замыкается , и такое состояние может продолжаться некоторое время.

Третья волна:

Четвертая волна:

• Примечание. Только сторона, которая инициирует разрыв соединения, перейдет в состояние TIME_WAIT.

Стоит ли ждать 2MSL?

• Если сообщение, отправленное клиентом для подтверждения запроса на завершение соединения с сервером, потеряно и не доходит до сервера, это приведет к тому, что сервер будет повторно отправлять запросы на завершение соединения клиенту из-за задержек в получении подтверждения, что приведет к тому, что сервер был не может войти в состояние ЗАКРЫТО.

Что произойдет, если серверный процесс зависнет после установления соединения?

• Если серверный процесс зависает после установления соединения, пакет FIN будет отправлен клиенту, и клиент ответит пакетом ACK. В это время, если клиент продолжает записывать данные на сервер, сервер ответит с пакетом RST, а затем завершиться.
  
  

• Если серверный процесс зависает из-за сбоя питания, клиент продолжит записывать данные на сервер и не будет ждать ответа, пока не истечет время ожидания. Клиентскому процессу необходимо установить тайм-аут.
  
  

• Точно так же, если клиентский процесс зависает, ответ серверного процесса, продолжающего отправлять данные клиенту, аналогичен приведенному выше, с некоторыми изменениями.
  
  
  

Управление TCP-соединениями — таймер поддержания активности

1. Каждый раз, когда процесс TCP-сервера получает данные от процесса TCP-клиента, он сбрасывает и запускает таймер поддержания активности (2-часовой таймер).

2. Если в течение периода таймера поддержания активности от процесса TCP-клиента не получено никаких данных, процесс TCP-сервера отправит тестовый сегмент процессу TCP-клиента по истечении срока действия таймера поддержания активности.

3. В дальнейшем 75он будет отправляться каждые секунды. Если после последовательной отправки сегментов обнаружения ответа от процесса TCP-клиента по-прежнему нет 10, процесс TCP-сервера посчитает, что хост, на котором находится процесс TCP-клиента, неисправен, а затем закрыть соединение.

Проще говоря, таймер поддержания активности TCP — это механизм завершения, который ожидает истечения таймаута .

Итог четырех волн

• Первый раз: клиент отправляет на сервер FIN=1 ACK=1 seq=u ack=v . FIN = 1 указывает, что это сообщение TCP-запроса на разрыв соединения.

  Правила TCP: даже если сегмент FIN не несет данных, он использует порядковый номер.

• Второй раз: сервер отправляет клиенту ACK = 1 seq = v ack = u + 1 . Указывает на подтверждение первого сообщения с запросом на подключение к выпуску клиента.

  В это время соединение в направлении A → B освобождается, а TCP находится в полузакрытом состоянии . Хотя B подтверждает, что A больше не будет отправлять данные, B все равно может отправлять данные A.

• Третий раз: Сервер отправляет клиенту FIN = 1 ACK = 1 seq = w ack = u + 1 , указывая, что сервер выпускает сообщение с запросом на соединение.

• Четвертый раз: клиент отправляет серверу ACK = 1 seq = u + 1 ack = w + 1 .

  В это время A также подтверждает закрытое состояние B. B непосредственно переходит в закрытое состояние. A входит в состояние ожидания TIME_WAIT. Время ожидания составляет 2MSL, что в два раза превышает самый длинный жизненный цикл сообщения. Если нет сообщения от другой стороны. полученный за этот период, А наконец переходит в закрытое состояние .

В одном предложении обе стороны должны инициировать запрос на прекращение соединения, и обе стороны должны подтвердить запрос на прекращение соединения, отправленный другой стороной.

И клиент, и сервер могут инициировать запрос на отключение FIN (TCP является полнодуплексным ), но только сторона, инициирующая завершение соединения, перейдет в состояние ожидания TIME_WAIT.

На практике второй и третий раз объединяются для передачи в одно сообщение.

Понимание версии четырехкратного расставания:

Почему волна TCP занимает четыре раза?

• TCP — это полнодуплексное соединение, и оба конца должны закрыть соединение одновременно, чтобы соединение было действительно закрыто .

  Если A готов прекратить запись, он все равно может прочитать данные, отправленные B. В это время А отправляет FINсообщение Б. Получив его, Б отвечает ACKна сообщение А.

  Когда B также готов прекратить запись, он отправляет FINсообщение A, и A отвечает ACKB. В это время оба конца закрыты, и TCP-соединение закрывается нормально.

  Таким образом, для полнодуплексного режима для полного выключения требуется четыре взаимодействия между двумя концами связи для подтверждения статуса выключения друг друга .

Почему инициатору следует ждать 2MSL? / Почему существует состояние TIME_WAIT?

1. Обеспечивает надежное завершение TCP-соединений .

   FINЕсли сообщение с подтверждением, отправленное клиентом на сервер в четвертый раз, потеряно, сервер истечет по тайм-ауту и ​​повторно передаст сообщение клиенту , поскольку он не получил сообщение с подтверждением .

   Однако, если клиент в это время закрыт, он не сможет ответить серверу, и сервер будет продолжать повторно передавать сообщения FIN, а это означает, что сервер никогда не получит подтверждения и в конечном итоге не сможет перейти в состояние ЗАКРЫТО. .

2. Убедитесь, что у поздних TCP-пакетов достаточно времени для распознавания и отбрасывания .

   В Linux порт TCP не может быть открыт несколько раз одновременно.Когда TCP-соединение находится в состоянии TIME_WAIT, мы не можем использовать порт соединения для установления нового соединения.

   Если подумать наоборот, то если TIME_WAITсостояния нет, приложение может немедленно установить соединение, подобное только что закрытому (здесь подобное означает, что у них одинаковый IP-адрес и номер порта). Это новое соединение, похожее на исходное, называется воплощением исходного соединения. Новое воплощение может получать TCP-сегменты (поздние сегменты), принадлежащие исходному соединению, несущему данные приложения, чего, очевидно, не должно происходить. Это TIME_WAITвторая причина существования государств.

Что произойдет, если процесс TCP на одном конце зависнет после установления соединения?

• Если процесс сервера зависает, пакет будет отправлен клиенту FIN, и клиент ответит пакетом ACK. В это время, если клиент продолжает записывать данные на сервер, сервер ответит пакетом, RSTа затем завершит работу.

• Если серверный процесс зависает из-за сбоя питания, клиент продолжит записывать данные на сервер и не будет ждать ответа, пока не истечет время ожидания. Клиентскому процессу необходимо установить тайм-аут.

• Точно так же, если клиентский процесс зависает, ответ серверного процесса, продолжающего отправлять данные клиенту, аналогичен приведенному выше, но был обратным.

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

TCP фиксируется/распаковывается

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

Липкий мешок

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

Причины липких посылок:

• ① Каждый раз, когда отправитель записывает данные <размер буфера ядра

• ② Приемник не читает буфер ядра достаточно вовремя.

половина упаковки

Полупакет означает, что сообщение получено несколько раз, и процесс приложения не может проанализировать данные из полупакета.

Причины половины упаковки :

• ① Отправитель записывает данные > размер буфера ядра ,
• ② Данные отправителя превышают MTU ( 1500байты по умолчанию для большой единицы передачи Ethernet) и должны быть распакованы.

решение

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

Как процесс приложения интерпретирует поток байтов? То есть как решить проблемы липких пакетов и полусумок?

Фундаментальное решение проблемы застревания и распаковки пакетов: определение границ сообщения

• ① Фиксированная длина
• ② Сепаратор
• ③ Поле фиксированной длины хранит информацию о длине контента.

Первый вариант: фиксированная длина

То есть каждый раз отправляются байты фиксированной длины. Например, каждый 3байт представляет сообщение:

Это решение простое, но недостатком является то, что оно требует лишнего пространства. Например, оговорено, что 10каждый байт представляет собой сообщение, но отправленное клиентом сообщение содержит только 1n байт, тогда оставшиеся 9n байт нужно заполнить или заполнить 0, что является пустой тратой.

Второй вариант: разделитель

Например, используйте символ возврата каретки ( \n) в качестве разделителя:

Другой пример : символы возврата каретки и перевода строки используются в заголовке HTTP как границы протокола HTTP:

Это решение простое и не занимает много места, однако недостатком является то, что если разделитель появляется в самом содержимом сообщения, его необходимо экранировать, поэтому содержимое необходимо предварительно сканировать.

Третье решение: поле фиксированной длины хранит информацию о длине контента.

То есть к заголовку сообщения добавляется поле фиксированной длины для хранения длины содержимого сообщения . Например, поле фиксированной длины используется в заголовке каждого сообщения 4для представления длины содержимого сообщения :

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

Недостатки: длина содержимого данных ограничена, и необходимо заранее знать количество байтов самого длинного сообщения.

Обычно это решение рекомендуется, но оно также зависит от сценария.Иногда первый и второй варианты проще.

Понимание ориентации потока байтов TCP и порядка байтов в сети.

Понимание ориентации потока байтов TCP

Когда процесс приложения вызывает write()метод для socketотправки данных, данные фактически не отправляются из сети, а только копируются из приложения в буфер ядра.Что касается того, когда они действительно отправляются, это зависит от окна отправки, окна перегрузки и текущий буфер отправки.Размер области и другие условия.

Более того, не все write()данные, отправленные вызовом, будут отправлены полностью целиком. Сколько раз будут рассылаться данные, также неизвестно.

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

Когда TCP отправляет фрагмент данных, он может несколько раз вызывать запись для отправки небольших пакетов данных:

Итак, когда эти два пакета данных отправляются в сеть? Это зависит от потребностей принимающей стороны.

• ① Если принимающая сторона не допускает задержки , то передающая сторона должна отправлять пакет данных каждый раз, когда она вызывает запись , независимо от размера пакета данных.
• ② Если принимающая сторона допускает определенный период задержки , отправляющая сторона может подождать определенный период времени и отправить несколько небольших пакетов данных вместе, что может уменьшить количество пакетов в сети.

порядок сетевых байтов

Как TCP решает, какой байт отправлять первым, а какой последним при отправке потока байтов?

Сначала поймите, каков порядок байтов хоста:

• Большой порядок байтов (big endian): Байты хранятся в порядке от младших адресов памяти к старшим адресам памяти .
• Little endian: байты хранятся в порядке от старших адресов памяти к младшим адресам памяти.
  

Видно, что порядок с прямым порядком байтов больше соответствует интуиции человека при чтении (чтение слева направо, сохранение от нижнего к верхнему), но для компьютеров порядок с прямым порядком байтов часто легче обрабатывать.

Кроме того, разные операционные системы работают на разных процессорах, да и порядок байтов тоже разный, см. таблицу ниже.

процессор	Операционная система	Порядок байтов
Альфа	все	Маленький порядок байтов
HP-PA	НТ	Маленький порядок байтов
HP-PA	UNIX	Большой порядок байтов
Intelx86	все	Система x86 с прямым порядком байтов <-----система с прямым порядком байтов
Моторола680x()	все	Большой порядок байтов
МИПС	НТ	Маленький порядок байтов
МИПС	UNIX	Большой порядок байтов
PowerPC	НТ	Маленький порядок байтов
PowerPC	Не-NT	Big Endian ＜ ----- Система PPC представляет собой систему порядка байтов с прямым порядком байтов.
РС/6000	UNIX	Большой порядок байтов
СПАРК	UNIX	Большой порядок байтов
Ядро ARM IXP1200	все	Маленький порядок байтов

Сетевой протокол использует обратный порядок для отправки байтов.

Если на отправляющем хосте используется прямой порядок байтов, вам необходимо преобразовать его из прямого порядка байтов в прямой порядок перед отправкой данных. после чтения данных преобразование последовательности. Система Linux предоставляет некоторые функции, которые можно вызывать напрямую, чтобы облегчить преобразование между порядком байтов хоста и порядком байтов в сети:

При использовании этих функций нам не нужно заботиться о порядке байтов хоста. Нам нужно только использовать заданное значение функции для преобразования порядка байтов сети и порядка байтов хоста.

Если вы отправляете символы, вам не нужно учитывать преобразование порядка байтов, поскольку каждый символ занимает только 1 байт.