40 картинок помогут вам понять TCP и UDP

задняя часть внешний интерфейс

предисловие

Добро пожаловать в статью «Программист cxuan», отныне вы будете моим читателем.

Мой github bestJavaer включил эту статью, каталог находится в

GitHub.com/Next Day Picks/Не голоден…

Я надеюсь, что вы можете дать мне звезду!

Эта статья является четвертой в серии статей о компьютерной сети, пожалуйста, прочитайте историческую статью

Я случайно нарисовал 24 картинки для анализа сетевого протокола прикладного уровня!

Основы TCP/IP

Краткое изложение базовых знаний о компьютерной сети

Давайте начнем эту статью.

运输层Расположенный между прикладным и сетевым уровнями, он является четвертым уровнем многоуровневой системы OSI и важной частью сетевой архитектуры. Транспортный уровень в первую очередь отвечает за сквозную связь в сети.

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

Обзор транспортного уровня

Транспортный уровень компьютерной сети очень похож на шоссе.Шоссе отвечает за транспортировку людей или предметов с одного конца на другой, а транспортный уровень компьютерной сети отвечает за транспортировку пакетов с одного конца на другой. конец относится к端系统. В компьютерной сети любая среда, которая может обмениваться информацией, может быть названа конечной системой, например, мобильные телефоны, сетевые носители, компьютеры и операторы.

В процессе транспортировки пакетов на транспортном уровне соблюдаются определенные спецификации протокола, такие как лимит данных для одной передачи и выбор транспортного протокола. Транспортный уровень позволяет двум несвязанным узлам逻辑通信Похоже, он соединяет два хоста.

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

Как TCP определяет, какой это порт?

Помните структуру пакета данных, вот обзор

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

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

На стороне отправителя транспортный уровень переводит пакеты, полученные от прикладного процесса-отправителя, на транспортный уровень.分组, группировка также называется в компьютерной сети报文段(segment). Транспортный уровень обычно делит сегмент на более мелкие фрагменты, добавляет заголовок транспортного уровня к каждому фрагменту и отправляет его в пункт назначения.

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

Предварительные требования TCP и UDP

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

TCP называется传输控制协议(TCP，Transmission Control Protocol),по названию можно примерно узнать,что протокол TCP имеет функцию управления передачей,что в основном отражается в его управляемости,а управляемость означает надежность.Это действительно так.TCP обеспечиваетНадежный, ориентированный на подключениеОн может надежно передавать пакеты на сервер.

UDP называется用户数据报协议(UDP，User Datagram Protocol), как видно из названия, UDP фокусируется на дейтаграммах, что предоставляет прикладному уровню способ отправлять дейтаграммы напрямую, без установления соединения.

Почему термины в компьютерной сети описывают так много данных?

В компьютерной сети существуют разные описания между разными уровнями. Выше мы упоминали, что группировка транспортного уровня называется сегментом.Кроме того, группировка в TCP также называется сегментом.Однако группировка UDP называется дейтаграммой, а сетевой уровень также называется сегментом. называются дейтаграммами

Но для унификации, как правило, в компьютерной сети мы собирательно называем пакеты TCP и UDP как报文段, это эквивалентно соглашению, и не нужно слишком беспокоиться о том, как его вызывать.

разъем

Прежде чем TCP или UDP отправит определенную информацию о сообщении, он должен пройти через вентилятор.门, дверь есть套接字(socket), сокет подключен к прикладному уровню вверх и вниз к сетевому уровню. В операционной системе операционная система предоставляет приложения и оборудование соответственно.接口(Application Programming Interface). В компьютерной сети сокет также является интерфейсом, и он также имеет API интерфейса.

При использовании связи TCP или UDP широко используется API сокетов, и этот API используется для установки IP-адреса и номера порта для отправки и получения данных.

Теперь мы знаем, что между Socket и TCP/IP нет необходимой связи, появление Socket просто для облегчения использования TCP/IP, как им удобно пользоваться? Вы можете напрямую использовать эти методы Socket API ниже.

метод описывать
create() создать сокет
bind() Идентификатор сокета, обычно используемый для привязки номера порта
listen() готовы принимать соединения
connect() готов выступить в качестве отправителя
accept() готов стать получателем
write() отправить данные
read() Получить данные
close() закрыть соединение

тип розетки

Есть три основных типа сокетов, давайте представим их отдельно.

  • 数据报套接字(Datagram sockets): сокеты дейтаграмм обеспечивают无连接Сервис, а надежность передачи данных не может быть гарантирована. Данные могут быть потеряны или дублироваться во время передачи, и нет никакой гарантии, что данные будут получены в порядке. Использование Datagram SocketUDP( User DatagramProtocol)协议Осуществить передачу данных. Поскольку дейтаграммный сокет не может гарантировать надежность передачи данных, необходимо бороться с возможной потерей данных в программе.
  • 流套接字(Stream sockets): Потоковые сокеты используются для предоставления ориентированных на соединение надежных услуг передачи данных. Это может обеспечить надежность и порядок данных. Причина, по которой потоковые сокеты могут предоставлять надежные услуги передачи данных, заключается в том, что они используют протокол управления передачей, которыйTCP(The Transmission Control Protocol)协议
  • 原始套接字(Raw sockets): необработанные сокеты позволяют отправлять и получать IP-пакеты напрямую без какого-либо формата транспортного уровня, специфичного для протокола, необработанные сокеты могут читать и записывать IP-пакеты, которые не были обработаны ядром.

обработка сокетов

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

  1. API в сокете используется для создания конечной точки в канале связи.После завершения создания он возвращает описание сокета.套接字描述符.

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

  1. Когда приложение имеет дескриптор сокета, оно может привязать к сокету уникальное имя, сервер должен привязать имя, чтобы быть доступным в сети.
  2. API прослушивания будет вызываться после того, как серверу будет назначен сокет, и имя будет привязано к сокету с помощью bind .listenУказывает на готовность клиента ждать соединения, перед принятием API необходимо вызвать listen.
  3. Клиентское приложение вызывает потоковый сокет (на основе TCP)connectИнициировать запрос на подключение к серверу.
  4. использование серверного приложенияacceptAPI принимает запросы на подключение от клиентов. Сервер должен успешно вызвать привязку и прослушивание перед вызовом accept api.
  5. После установления соединения между потоковыми сокетами клиент и сервер могут инициировать вызовы API чтения/записи.
  6. Когда сервер или клиент хочет остановить операцию, она вызываетсяcloseAPI освобождает все системные ресурсы, полученные сокетом.

Хотя API сокетов находится в модели связи между прикладным и транспортным уровнями, API сокетов не является частью модели связи. API сокетов позволяет приложениям взаимодействовать с транспортным и сетевым уровнями.

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

болтать об IP

IPдаInternet Protocol（网际互连协议）Аббревиатура для системы TCP/IP网络层протокол. Первоначальная цель разработки IP в основном состоит в том, чтобы решить два типа проблем.

  • Улучшите масштабируемость сети: обеспечьте крупномасштабное сетевое взаимодействие
  • Разделение прикладного уровня и уровня ссылок, чтобы позволить им развиваться независимо.

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

Мы знаем, что следующим уровнем протокола TCP является уровень протокола IP.Поскольку IP ненадежен, как гарантировать, что данные будут поступать точно и без ошибок?

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

Номер порта

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

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

Когда наша программа хочет использовать сеть, ей необходимо использовать соответствующую операцию ядра операционной системы и устройство сетевой карты, чтобы мы могли обратиться к операционной системе, а затем система создаст для нас сокет и вернет идентификатор сокета. , в дальнейшем, если наша программа захочет использовать сетевые ресурсы, нам нужно оперировать только ID этого Socket. И каждый из наших сетевых коммуникационных процессов соответствует хотя бы одному сокету. Запись данных в Socket ID эквивалентна отправке данных в сеть, а чтение данных в Socket эквивалентно получению данных. И эти сокеты имеют уникальный идентификатор — файловый дескриптор fd.

номер порта16Неотрицательное целое число битов в диапазоне от 0 до 65535, которое разделено на три разных диапазона номеров портов, назначенных Управлением по присвоению номеров в Интернете IANA.

  • Общеизвестный/стандартный номер порта, он находится в диапазоне от 0 до 1023.
  • Зарегистрируйте номер порта, диапазон 1024 - 49151
  • Номер частного порта в диапазоне 49152 - 6553

На компьютере может работать несколько приложений Когда сегмент поступает на хост, какому приложению его следует передать? Откуда вы знаете, что этот сегмент передается на HTTP-сервер, а не на SSH-сервер?

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

Например, чтобы опровергнуть cxuan, как отличить два данных, поступающих на сервер с 80-го порта? Другими словами, два порта данных, поступающих на сервер, одинаковы, но протоколы разные, как их отличить?

Поэтому явно недостаточно определить конкретный пакет только по номеру порта.

Общее использование в ИнтернетеIP-адрес источника, IP-адрес назначения, номер порта источника, номер порта назначенияотличить. Если один из них отличается, он считается другим сегментом. это также多路分解和多路复用Основы.

Определяем номер порта

Перед фактической связью вам необходимо сначала определить номер порта.Есть два способа определить номер порта:

  • Стандартный установленный номер порта

Стандартные установленные номера портов назначаются статически, каждая программа будет иметь свой собственный номер порта, и каждый номер порта имеет свое назначение. Номер порта представляет собой 16-разрядное число, размер которого находится в диапазоне от 0 до 65535. Номера портов в диапазоне от 0 до 1023 являются динамически назначаемыми номерами портов.Например, HTTP использует для идентификации порт 80, а FTP использует для идентификации порт 21. SSH использует 22 для идентификации. Эти номера портов имеют специальное имя, называемое周知端口号(Well-Known Port Number).

  • Timing назначен номер порта

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

Мультиплексирование и демультиплексирование

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

Существует два типа мультиплексирования и демультиплексирования, а именно:无连接Мультиплексирование (демультиплексирование) и面向连接мультиплексирование (демультиплексирование)

Мультиплексирование и демультиплексирование без установления соединения

Разработчик пишет код, чтобы определить, является ли номер порта общеизвестным номером порта или номером порта, назначенным временным рядом. Если порт 10637 на узле A хочет отправить данные на порт 45438 на узле B, транспортный уровень используетUDPпротокол, после того, как данные сгенерированы на прикладном уровне, они будут обработаны на транспортном уровне, а затем данные будут инкапсулированы на сетевом уровне для получения IP-дейтаграмм.Номер порта в сегменте сообщения определяет, к какому сокету он принадлежит. , Эта серия процессов выглядит следующим образом

Сокет UDP представляет собой двойку, содержащую IP-адрес назначения и номер порта назначения.

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

Вот вопрос для рассмотрения, хост A отправляет сообщение хосту B, зачем вам знать номер исходного порта? Например, если я передаю сестре сообщение о том, что ты мне интересна, нужно ли девушке еще знать, какой мой орган посылает это сообщение? Разве ты не знаешь, что это я интересуюсь тобой? На самом деле это необходимо, потому что если девушка хочет выразить, что вы ей интересны, она, скорее всего, поцелует вас, поэтому она должна знать, куда целовать?

То есть в сегменте от A до B номер исходного порта будет использоваться как返回地址часть , то есть, когда B должен отправить сегмент обратно в A, B должен получить значение из номера исходного порта в A в B, как показано на следующем рисунке.

Мультиплексирование и демультиплексирование с установлением соединения

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

На приведенном выше рисунке показан процесс мультиплексирования и демультиплексирования с установлением соединения.На этом рисунке узел C инициирует два HTTP-запроса к узлу B, а узел A инициирует HTTP-запрос к узлу C. У него есть собственный уникальный IP-адрес. отправляет HTTP-запрос, хост B может разложить два HTTP-соединения, потому что два исходных номера порта запроса, отправленного хостом C, различны, поэтому для хоста B это два запроса, хост B может разложить. Для хоста A и хоста C два хоста имеют разные IP-адреса, поэтому для хоста B это также может быть разрешено.

UDP

Наконец-то мы начали обсуждать протокол UDP, поехали!

Полное название UDP用户数据报协议(UDP，User Datagram Protocol), UDP предоставляет приложениям无需建立连接способ отправки инкапсулированных IP-пакетов. Если разработчик приложения выбирает UDP вместо TCP, то приложение имеет дело непосредственно с IP.

Данные, переданные из приложения, будут дополнены полями номера порта источника и получателя для мультиплексирования/демультиплексирования и другими полями, а затем результирующее сообщение будет передано на сетевой уровень, который отправит сегмент транспортного уровня. Он инкапсулирован в IP-датаграмма и доставляется целевому хосту по мере возможности. Наиболее важным моментом является то, что когда дейтаграмма доставляется на целевой хост с использованием протокола UDP, связь между объектами транспортного уровня отправителя и получателя отсутствует.握手из. Из-за этого UDP известен как无连接соглашение.

Возможности UDP

Протокол UDP обычно используется в качестве протокола транспортного уровня для приложений потокового мультимедиа, голосовой связи и видеоконференций.Все мы знаем, что нижний уровень протокола DNS также использует протокол UDP.Эти приложения или протоколы выбирают UDP в основном из-за следующие пункты

  • 速度快, При использовании протокола UDP, пока процесс приложения передает данные в UDP, UDP упаковывает данные в сегмент UDP и немедленно передает их на сетевой уровень, а затем TCP имеет функцию контроля перегрузки, он оценивает Интернет до Перегрузка, если Интернет сильно перегружен, то TCP-отправитель тормозится. Цель использования UDP — надеяться на работу в реальном времени.
  • 无须建立连接, протоколу TCP перед передачей данных необходимо выполнить операцию трехэтапного рукопожатия, в то время как протокол UDP может выполнять передачу данных без какой-либо подготовки. Таким образом, UDP не имеет задержки для установления соединения. Если использовать TCP и UDP как метафору для разработчиков: TCP — это такой инженер, которому нужно все хорошо спроектировать, а без дизайна он не может разрабатывать, ему нужно учесть все факторы перед началом! так очень靠谱; а UDP - это такая непосредственная работа, которая возникает, и начинает работу сразу после получения требований к проекту, независимо от дизайна или технического выбора, просто работа, такой тип разработчика очень不靠谱, но подходит для быстрой итеративной разработки, потому что можно сразу приступить к работе!
  • 无连接状态, TCP необходимо поддерживать в конечной системе连接状态, состояние соединения включает буферы приема и отправки, параметры управления перегрузкой и параметры порядковых номеров и номеров подтверждения, которые недоступны в UDP, а также буферы отправки и приема. Таким образом, некоторые серверы, предназначенные для определенного приложения, обычно могут поддерживать более активных пользователей, когда приложение работает по протоколу UDP.
  • 分组首部开销小, каждый сегмент TCP имеет 20 байтов служебных данных заголовка, в то время как UDP имеет только 8 байтов служебных данных.

Здесь следует отметить, что не все прикладные уровни, использующие протокол UDP,不可靠Да, приложения могут сами реализовать надежную передачу данных, добавив механизмы подтверждения и повторной передачи. Поэтому самой большой особенностью использования протокола UDP является скорость.

Структура UDP-пакета

Давайте посмотрим на структуру пакета UDP.Каждый пакет UDP делится на две части: заголовок UDP и область данных UDP. Заголовок состоит из четырех 16-битных (2 байта) полей, которые соответственно описывают исходный порт, порт назначения, длину пакета и контрольное значение пакета.

  • 源端口号(Source Port): это поле занимает первые 16 бит заголовка пакета UDP и обычно содержит порт UDP, используемый приложением, отправляющим дейтаграмму. Принимающее приложение использует значение этого поля в качестве адреса назначения для отправки ответа. Это поле является необязательным, и иногда номер исходного порта не указывается. По умолчанию используется значение 0 без номера исходного порта, обычно используемое при обмене данными, не требующем ответного сообщения.
  • 目标端口号(Destination Port): указывает принимающий порт, длина поля 16 бит.
  • 长度(Length): Это поле занимает 16 бит и указывает длину дейтаграммы UDP, включая заголовок UDP и длину дейтаграммы UDP. Поскольку длина заголовка пакета UDP составляет 8 байт, минимальное значение — 8, а максимальная длина — 65 535 байт.
  • 校验和(Checksum): UDP использует контрольную сумму для обеспечения безопасности данных, контрольная сумма UDP также обеспечивает функцию обнаружения ошибок, обнаружение ошибок используется для проверки того, изменилась ли целостность данных в процессе сегмента сообщения от источника к узлу назначения. UDP отправителя выполняет операцию дополнения к сумме 16-битных слов в сегменте сообщения, и переполнение битов, обнаруженное во время суммирования, будет игнорироваться.Например, в следующем примере добавляются три 16-битных числа.

Первые две суммы этих 16 бит равны

Затем добавьте приведенный выше результат к третьему 16-битному числу.

Последний добавленный бит будет переполнен, бит переполнения 1 будет отброшен, а затем будет выполнена операция дополнения, которая заменяет все 1 на 0 и 0 на 1. следовательно1000 0100 1001 0101Обратный код0111 1011 0110 1010,это контрольная сумма.Если нет ошибки в данных на стороне получателя, то вычисляются все четыре 16-битных значения, включая контрольную сумму.Если конечное значение результата не 1111 1111 1111 1111, то Указывает, что ошибка в данных при передаче.

Давайте подумаем над вопросом, почему в UDP предусмотрена функция обнаружения ошибок?

На самом деле это端到端 принцип конструкции, который гласит, чтоСнизить вероятность различных ошибок при передаче до приемлемого уровня.

файл с хостаAхозяинуB, то естьABЧтобы хост общался, ему нужно пройти по трем ссылкам: первая — это хостAЧтение файлов с диска и группировка данных в пакетыpacket,, то пакет проходит через подключающийся хостAи хозяинBпередача по сети на хостB, и, наконец, хозяинBПолучите пакет и запишите его на диск. В этом, казалось бы, простом, но сложном процессе нормальная коммуникация может быть нарушена по некоторым причинам. Например, ошибки чтения и записи файлов на диск, переполнение буфера, ошибки памяти, перегрузка сети и т. д. могут вызвать ошибки или потерю пакетов данных, что свидетельствует о ненадежности используемой для связи сети.

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

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

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

TCP

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

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

TCPПолное имяTransmission Control Protocol, который называется面向连接(connection-oriented)протокола, потому что прежде чем одно приложение сможет начать отправлять данные другому, два процесса должны握手рукопожатие — это логическое соединение, а не настоящее рукопожатие между двумя хостами.

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

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

TCP-соединения全双工服务(full-duplex service)Да, что значит полный дуплекс? Полный дуплекс означает, что существует TCP-соединение между хостом A и другим хостом B, после чего данные приложения могут передаваться с хоста B на хост A, а также с хоста A на хост B.

TCP может только点对点(point-to-point)связи, то так называемая多播, то есть не бывает ситуации, когда хост отправляет сообщения нескольким получателям, а TCP-соединение может соединять только две пары хостов.

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

TCP временно хранит данные о соединении发送缓存(send buffer), буфер отправки является одним из буферов, установленных между трехэтапным рукопожатием, а затем TCP отправляет данные из буфера отправки в буфер приема целевого хоста в соответствующее время.Фактически, каждый конец будет иметь буфер отправки и приемный буфер.

Отправка между хостами报文段(segment)Так что же такое сегмент?

TCP делит поток данных для передачи на несколько块(chunk), а затем добавьте заголовок TCP к каждому фрагменту, сформировав таким образом сегмент TCP, который является сегментом сообщения. Длина каждого сегмента, который может быть передан, ограничена и не может превышать最大数据长度(Maximum Segment Size), широко известный какMSS. В процессе нисходящей передачи сегмент сообщения будет проходить через канальный уровень, а канальный уровень имеетMaximum Transmission Unit, максимальная единица передачи MTU, то есть размер самого большого пакета данных, который может быть передан на канальном уровне.Максимальная единица передачи обычно связана с интерфейсом связи.

Итак, какое отношение MSS имеет к MTU?

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

Структура сегмента TCP

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

Структура сегмента TCP содержит гораздо больше содержимого, чем структура пакета UDP. Но первые два 32-битных поля одинаковы. Они есть源端口号и目标端口号, мы знаем, что эти два поля используются для мультиплексирования и демультиплексирования. Кроме того, как и UDP, TCP также содержит校验和(checksum field), кроме того, заголовок TCP-сегмента имеет следующее

  • 32 бит序号字段(sequence number field)и 32-битный确认号字段(acknowledgment number field). Эти поля используются отправителями и получателями TCP для надежной передачи данных.

  • 4 бита首部字段长度字段(header length field), это поле указывает длину заголовка TCP в 32-битных словах. Длина заголовка TCP является переменной, но обычно поле параметров пусто, поэтому длина поля заголовка TCP составляет 20 байт.

  • 16 бит接受窗口字段(receive window field), это поле используется для управления потоком. Он используется для указания количества байтов, которые получатель может/готов принять.

  • Переменная选项字段(options field), это поле используется, когда отправитель и получатель согласовывают максимальную длину сообщения, то есть когда используется MSS

  • 6 бит标志字段(flag field),ACKФлаг используется для указания того, что значение в поле подтверждения допустимо, и этот сегмент включает в себя подтверждение того, что сегмент был успешно получен;RST,SYN,FINФлаги используются для установления и закрытия соединения;CWRиECEдля контроля заторов;PSHФлаг используется для указания того, что данные немедленно передаются на верхний уровень для обработки;URGФлаг используется для указания на необходимость обработки данных на верхнем уровне.срочныйданные. Последний байт срочных данных состоит из 16-битного紧急数据指针字段(urgeent data pointer field)указал. Как правило, PSH и URG не используются.

Различные функции и характеристики TCP отражены в структуре пакетов TCP.Поговорив о структуре пакетов TCP, давайте поговорим о функциях и характеристиках TCP.

Серийный номер, номер подтверждения для обеспечения надежности передачи

Два самых важных поля в заголовке TCP-сегмента:序号и确认号, эти два поля являются основой для достижения надежности TCP, поэтому вам должно быть любопытно, как добиться надежности? Чтобы понять это, мы должны сначала узнать, какой контент хранится в этих двух полях, верно?

Порядковый номер сегмента — это номер байта потока данных.. Поскольку TCP делит поток данных на поток байтов, а сам поток байтов упорядочен, номер байта каждого сегмента представляет собой поток байтов, указывающий, какой это сегмент. Например, хост А хочет отправить часть данных на хост Б. После того, как данные будут сгенерированы прикладным уровнем, будет серия потоков данных.Поток данных будет разделен TCP.Основой разделения является MSS.Предполагая, что данные составляют 10000 байт, а MSS – 2000 байт, затем TCP разделит данные на 0-1999, 2000-3999 и так далее.

Следовательно, номер первого байта первых данных 0–1999 равен 0, а номер первого байта 2000–3999 равен 2000. . . . . .

Затем каждый порядковый номер заполняется в поле порядкового номера в заголовке TCP-сегмента.

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

  • Симплексная связь: Симплексная передача данных поддерживает передачу данных только в одном направлении; только одна сторона может одновременно получать или отправлять информацию, и двусторонняя связь не может быть достигнута, например, по радио и телевидению.
  • Дуплексная связь — это двухточечная система, состоящая из двух или более подключенных сторон или устройств, которые обмениваются данными друг с другом в обоих направлениях. Существует две модели дуплексной связи:Полный дуплекс (FDX) и полудуплекс (HDX)
    • Полнодуплексный: в полнодуплексной системе две стороны соединения могут общаться друг с другом, одним из наиболее распространенных примеров является телефонная связь. Полнодуплексная связь представляет собой комбинацию двух методов симплексной связи, которая требует, чтобы и передающее, и принимающее устройства имели независимые возможности приема и отправки.
    • Полудуплекс: в полудуплексной системе две подключенные стороны могут общаться друг с другом, но не одновременно, например, в рации, только человек, который нажимает кнопку, может говорить, и только один человек может говорить после того, как другой человек закончил говорить.

Симплексная, полудуплексная и полнодуплексная связь показаны на рисунке ниже.

TCP — это полнодуплексный протокол связи, поэтому хост A также получает данные от хоста B в процессе отправки сообщений на хост B.Номер подтверждения, который хост A вставляет в сегмент, является порядковым номером следующего байта, который он ожидает получить от хоста B.. Небольшой экскурс, давайте посмотрим на примере. Например, хост А получает сегмент с номером 0 — 999 байт, отправленный от хоста Б, этот сегмент будет записан в порядковый номер, а затем хост А ожидает получить 1000 — остальные сегменты от хоста Б, поэтому номер подтверждения в сегмент, отправленный хостом A хосту B, равен 1000.

Совокупное подтверждение

Вот еще один пример: например, после того, как хост А отправил сегменты от 0 до 999, он ожидает получить сегменты после 1000, но хост Б отправляет сегмент после 1500 хосту А, будет ли хост А продолжать ждать?

Ответ, очевидно, да, потому что TCP будет подтверждать байты в потоке только до первого недостающего байта, потому что, хотя 1500 относится к байтам после 1000, хост B не отправлял слово между 1000 - 1499 на хост A строфу, поэтому хост А будет продолжать ждать.

Разобравшись с серийным номером и номером подтверждения, давайте поговорим о процессе отправки TCP. Ниже приведен обычный процесс отправки

TCP через утвердительный确认应答(ACK)Для обеспечения надежной передачи данных, когда хост A отправляет данные, он будет ждать ответа хоста B. Если есть подтверждение (ACK), это означает, что данные успешно достигли партнера. В противном случае данные могут быть потеряны.

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

Ответ от узла A к узлу B может быть недоступен из-за нестабильности сети и т. д., после чего через определенный интервал времени узел A повторно отправит сегмент.

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

Как показано на рисунке выше, ответ подтверждения, возвращенный хостом B, был потерян во время передачи из-за перегрузки сети и других причин и не достиг хоста A. Хост А будет ждать некоторое время. Если хост А по-прежнему не ожидает ответа от хоста Б в течение этого периода, то хост А повторно отправит сегмент.

Тогда возникает проблема. Если узел A отправляет сегмент сообщения узлу B, узел B получает ответ на отправку сегмента сообщения. В этот момент по сетевым причинам сегмент сообщения не прибыл. Через некоторое время узел A Сегмент отправляется повторно, а затем ответ, отправленный узлом B, поступает на узел A не по порядку после того, как узел A отправил его во второй раз.Так что же должен сделать узел A?

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

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

Как правило, используется второй подход.

управление передачей

Ускорьте работу с помощью оконных элементов управления

Ранее мы представили, что TCP отправляется в виде сегментов данных.Если узел A не может дождаться ответа от узла B в течение определенного периода времени, узел A повторно отправит сегмент, получит ответ от узла B и продолжит отправку Теперь мы видим, что в этой форме вопросов и ответов по-прежнему много условий, таких как неполучение ответа, ожидание ответа и т. д., поэтому для Интернета, который выступает за производительность, производительность этой формы не должна быть очень хорошо. высокий.

Итак, как повысить производительность?

Для решения этой проблемы TCP ввел窗口Эта концепция, которая может контролировать ухудшение производительности сети, даже когда время приема-передачи большое и частота много, звучит потрясающе, так как же она реализована?

Как показано ниже

Раньше мы отправляли каждый запрос в виде сегментов.После введения окна каждый запрос может отправлять несколько сегментов, то есть одно окно может отправлять несколько сегментов. Размер окна — это максимальный размер сегмента, который можно продолжать отправлять, не дожидаясь подтверждения.

В этом оконном механизме широко используются缓冲区, с помощью функции одновременного подтверждения нескольких сегментов.

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

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

В случае получения подтверждения окно будет перемещено на позицию номера подтверждения в ответе на подтверждение, как показано на рисунке выше, так что несколько сегментов могут быть отправлены одновременно для улучшения производительности связи. , Этот вид окна также называется滑动窗口(Sliding window).

Управление окном и повторная отправка

Отправка и получение сегментов сообщения должны сопровождаться потерей и повторной передачей сегментов сообщения, и то же самое верно для окон Что делать, если сегмент сообщения потерян в процессе отправки в окне?

Сначала рассмотрим случай, когда ответ подтверждения не возвращается. В этом случае сегмент, отправленный хостом А, достигает хоста Б и не нуждается в повторной передаче. Это не то же самое, что отправка одного сегмента, если отправляется один сегмент,Повторная передача, даже если подтверждение не возвращается.

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

Мы знаем, что если хост-получатель не получит запрос из-за потери отправленного сегмента или ответ, возвращенный хостом, не дойдет до клиента, сообщение будет передано повторно через определенный период времени. Так что же происходит с потерей сегмента при использовании Windows?

Как показано на рисунке ниже, после потери сегмента 0 - 999, но узел А не будет ждать, узел А продолжит отправлять оставшиеся сегменты, но ответ подтверждения, отправленный узлом Б, всегда будет 1000, ответ с тем же номер подтверждения Сообщение будет постоянно возвращаться. Если хост-отправитель получает одно и то же подтверждение три раза подряд, он повторно отправит соответствующие данные. Этот механизм более эффективен, чем упомянутая выше повторная передача по тайм-ауту. Этот механизм также называется高速重发控制. Это повторно переданное подтверждение также называется冗余 ACK(响应).

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

управление потоком

Ранее я говорил об управлении передачей, а дальше с вами поговорит Ксюан.流量控制. Мы знаем, что хост на одной стороне каждого TCP-соединения будет иметь буфер сокета, и буфер будет устанавливать буфер приема и буфер отправки для каждого соединения.Когда TCP-соединение установлено, данные, сгенерированные приложением, поступят в В приемном буфере приложение получателя не обязательно сразу считывает данные из буфера, ему необходимо дождаться, пока операционная система выделит квант времени. Если приложение отправителя в это время генерирует данные слишком быстро, а получатель считывает данные в приемном буфере относительно медленно, данные в буфере получателя будут溢出.

Но, к счастью, TCP流量控制服务(flow-control service)Используется для устранения условий переполнения буфера. Управление потоком — это служба согласования скорости, при которой скорость отправки отправителя соответствует скорости чтения приложения-получателя.

TCP с помощью接收窗口(receive window)переменная для управления потоком. Окно принятия даст отправителю указаниеСколько места в кэше еще доступно. Отправитель будет контролировать количество отправляемых данных в соответствии с фактическими возможностями приема получателя.

Принимающий конечный хост информирует отправляющий конечный хост о размере данных, которые он может получить, и отправляющая сторона будет отправлять данные, которые не превышают этот предел.Это ограничение размера является размером окна.Помните заголовок TCP, есть принимающий window, когда мы говорили выше. Допустим, это поле используется для управления потоком. Он используется для указания количества байтов, которое получатель может/желает принять.

Тогда только знайте, что это поле используется для управления потоком, так как же им управлять?

Хост-отправитель будет периодически отправлять窗口探测包, этот пакет используется для определения того, может ли хост на принимающей стороне по-прежнему принимать данные.Когда буфер принимающей стороны сталкивается с риском переполнения данных, значение размера окна также устанавливается на меньшее значение, чтобы уведомить отправляющую конец, чтобы контролировать объем отправленных данных.

Ниже приведена схема управления потоком.

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

Как показано на рисунке выше, когда хост B получает сегменты 2000–2999, буфер заполняется и должен временно прекратить прием данных. Затем хост A отправляет пакет оконного зонда, который очень мал и содержит всего один байт. Затем узел B обновляет размер окна приема буфера и отправляет уведомление об обновлении окна на узел A, после чего узел A продолжает отправлять сегменты.

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

управление соединением

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

  • Во-первых, клиент сначала отправляет на сервер специальный TCP-сегмент. Заголовок этого сегмента не содержит данных прикладного уровня, но естьSYN 标志位устанавливается на 1. Следовательно, этот специальный сегмент также можно назвать сегментом SYN. Затем клиент случайным образом выбирает один初始序列号(client_isn), и поместите этот номер в поле порядкового номера начального сегмента TCP SYN, который, в свою очередь, инкапсулируется в сегмент данных IP и отправляется на сервер.

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

    Распределение этих буферов и переменных делает TCP уязвимым для атаки типа «отказ в обслуживании», называемой SYN-флудом.

    • Сначала бит SYN устанавливается в 1.
    • Затем номер подтверждения заголовка TCP-сегмента устанавливается равнымclient_isn + 1.
    • Наконец, сервер сам выбирает初始序号(server_isn)и поместите его в поле порядкового номера заголовка TCP-сегмента.

    Если говорить на простом языке, то я получил SYN-сегмент, который вы инициировали для установления соединения, в этом сегменте есть поле заголовка client_isn. Я согласен установить соединение, мой начальный порядковый номер — server_isn. Этот сегмент, разрешающий соединение, называетсяSYNACK 报文段

  • На третьем шаге, после получения сегмента SYNACK, клиент также выделяет буферы и переменные для соединения. Хост-клиент отправляет серверу еще один сегмент, и последний сегмент подтверждает ответное сообщение, отправленное сервером.Стандарт подтверждения заключается в том, что номер подтверждения в сегменте данных, отправленном клиентом, равен server_isn + 1, поскольку соединение было установлено. , поэтому бит SYN установлен в 0. Выше приведен процесс отправки трех сегментов данных для TCP для установления соединения, также известный как三次握手.

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

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

Процесс клиентского приложения выдает команду закрытия, и клиентский TCP отправляет серверному процессу специальный TCP-сегмент.Флаг заголовка FIN этого специального сегмента устанавливается в 1. Когда сервер получает этот сегмент, он отправляет отправителю сегмент подтверждения. Затем сервер отправляет свой собственный сегмент завершения с битом FIN, установленным в 1. Клиент подтверждает этот сегмент завершения. В этот момент все ресурсы, используемые для соединения на обоих хостах, освобождаются, как показано на следующем рисунке.

В течение срока действия TCP-соединения протокол TCP, работающий на каждом хосте, будетTCP 状态(TCP State)Изменения между состояниями TCP в основном включают:ПРОСЛУШИВАТЬ, SYN-ОТПРАВИТЬ, SYN-ПОЛУЧИТЬ, УСТАНОВИТЬ, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT и CLOSED. Эти состояния объясняются следующим образом

  • LISTEN: Указывает на ожидание любого запроса на подключение от удаленного TCP и порта.
  • SYN-SEND: указывает на ожидание соответствующего запроса на подключение после отправки запроса на подключение.
  • SYN-RECEIVED: Указывает, что запрос на подключение получен и отправлен и ожидает подтверждения подключения, что является состоянием сервера после второго шага трехэтапного рукопожатия TCP.
  • ESTABLISHED: Указывает, что соединение установлено и данные приложения могут быть отправлены на другие хосты.

Вышеупомянутые четыре состояния участвуют в трехстороннем рукопожатии TCP.

  • FIN-WAIT-1: Указывает на ожидание запроса на завершение соединения от удаленного TCP или подтверждения ранее отправленного запроса на завершение соединения.

  • FIN-WAIT-2: Указывает на ожидание запроса на завершение соединения от удаленного TCP.

  • CLOSE-WAIT: указывает на ожидание запроса на завершение соединения от локального пользователя.

  • CLOSING: Указывает на ожидание подтверждения запроса на завершение соединения от удаленного TCP.

  • LAST-ACK: Указывает на ожидание подтверждения запроса на завершение соединения, ранее отправленного на удаленный TCP (включая подтверждение его запроса на завершение соединения).

  • TIME-WAIT: Указывает на достаточное время ожидания, чтобы удаленный TCP получил подтверждение своего запроса на завершение соединения.

  • CLOSED: Указывает, что соединение закрыто и состояние соединения отсутствует.

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

Состояние соединения TCP будет подвергаться различным переключениям, и эти переключения TCP-соединений осуществляются по событиям, которые вызываются пользователем:ОТКРЫТЬ, ОТПРАВИТЬ, ПОЛУЧИТЬ, ЗАКРЫТЬ, ПРЕРВАТЬ и СТАТУС. Флаги, задействованные в сегменте TCP:SYN, ACK, RST и FIN, и, конечно же, есть тайм-ауты.

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

Трехстороннее рукопожатие для установления соединения

На следующем рисунке показан процесс установления TCP-соединения. Предположим, что левый конец рисунка — это клиентский хост, а правый — серверный.CLOSED（关闭）государство.

  1. Серверный процесс готов принимать TCP-соединения извне, обычно вызывая три функции bind, listen и socket. Этот способ открытия считается被动打开(passive open). Затем серверный процесс находится вLISTENСтатус, ожидание запроса на подключение клиента.
  2. клиент черезconnectположить начало主动打开(active open), отправить запрос на подключение к серверу, бит синхронизации заголовка в запросе равен SYN = 1, и выбрана начальная последовательность порядковых номеров, сокращенно seq = x. Сегмент SYN не может передавать данные и использует только порядковый номер. В этот момент клиент входитSYN-SENDгосударство.
  3. После того, как сервер получает соединение от клиента, ему необходимо подтвердить сегмент клиента. В сегменте подтверждения установите биты SYN и ACK в 1. Номер подтверждения равен ack = x + 1, а также выбирает для себя начальный порядковый номер seq = y. Обратите внимание, что этот сегмент также не может передавать данные, но также использует порядковый номер. В этот момент TCP-сервер входитSYN-RECEIVED(同步收到)государство.
  4. После получения ответа от сервера клиенту также необходимо подтвердить соединение. ACK в подтверждающем соединении устанавливается равным 1, порядковый номер — seq = x + 1, а подтверждающий номер — ack = y + 1. TCP определяет, может ли этот сегмент нести данные или нет.Если он не несет данных, порядковый номер следующего сегмента данных по-прежнему будет seq = x + 1. В этот момент клиент входитESTABLISHED (已连接)государство
  5. После того, как сервер получает подтверждение от клиента, он также входитESTABLISHEDгосударство.

TCP требуется три сегмента для установления соединения и четыре сегмента для разрыва соединения.

помахал четыре раза

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

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

  1. Клиентское приложение отправляет сегмент сообщения, чтобы освободить соединение, прекращает отправку данных и активно закрывает TCP-соединение. Хост-клиент отправляет сегмент сообщения, чтобы разорвать соединение, первый бит FIN в сегменте сообщения равен 1, не содержит данных, а бит порядкового номера seq = u, в это время хост-клиент вводитFIN-WAIT-1(终止等待 1)сцена.

  2. После того, как хост-сервер получает сегмент, отправленный клиентом, он отправляет ответное сообщение с подтверждением, подтверждает, что ACK = 1 в ответном сообщении, и генерирует свой собственный бит порядкового номера seq = v, ack = u + 1, а затем сервер хозяин входитCLOSE-WAIT(关闭等待)В это время соединение в направлении хост-клиент -> хост-сервер освобождается, и хост-клиент не имеет данных для отправки.В это время хост-сервер находится в полуподключенном состоянии, но хост-сервер все еще может отправить данные.

  3. После того как хост-клиент получает ответ с подтверждением от хоста-сервера, он входит вFIN-WAIT-2(终止等待2)статус. Сегмент, ожидающий, пока клиент освободит соединение.

  4. Когда у хоста сервера нет данных для отправки, процесс приложения уведомит TCP о разрыве соединения. В это время хост-сервер отправит отключенный сегмент. В этом сегменте ACK = 1, а порядковый номер seq = w. Поскольку между ними могут быть отправлены некоторые данные, seq не обязательно равен v + 1. ack = u + 1, после отправки сообщения запроса на отключение хост-сервер входит вLAST-ACK(最后确认)сцена.

  5. После того, как клиент получает запрос на отключение от сервера, клиент должен ответить, и клиент отправляет отключенный сегмент.В сегменте ACK = 1, порядковый номер seq = u + 1, потому что клиент больше не отправляет данные после соединение разорвано, ack=w+1, а потом энтер вTIME-WAIT(时间等待)Статус, обратите внимание, что в настоящее время TCP-соединение не разорвано. Настройка, которая должна ждать некоторое время, т.е.2MSLПосле этого клиент войдетCLOSEDсостояние, время MSL называется最长报文段寿命（Maximum Segment Lifetime）.

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

Что такое ВРЕМЯ-ОЖИДАНИЕ

Я лишь вкратце упомянул, что такое состояние TIME-WAIT и 2MSL, давайте поговорим об этих двух понятиях.

MSLмаксимальное время, в течение которого TCP-сегмент может жить или находиться в сети. RFC 793 определяет время MSL как две минуты, но конкретная реализация должна быть указана программистом.В некоторых реализациях это максимальное время выживания составляет 30 секунд.

Так зачем ждать2MSLШерстяная ткань?

В основном по двум причинам

  • Чтобы гарантировать, что последний ответ может быть доставлен на сервер, поскольку в компьютерных сетях последний сегмент ACK может быть потерян, в результате чего клиент останется вLAST-ACKСтатус ожидания ответа клиента. Затем сервер повторит передачуFINACKОтключите сообщение, клиент повторно подтвердит его получение и перезапустит таймер. Если клиент не 2MSL, если клиент сразу закрывается после отправки ACK, если сообщение потеряно, то оба хоста не смогут войти в состояние CLOSED.
  • также предотвратить已失效сегмент сообщения. После отправки клиентом последнего ACK, после 2MSL, все сегменты, сгенерированные за время действия этой ссылки, могут исчезнуть из сети. От гарантии того, что в сети не останется пакетов, которые будут беспокоить сервер после закрытия соединения.

Здесь следует отметить одну вещь: таймер повторной передачи тайм-аута запускается сразу после того, как сервер отправляет FIN-ACK. Клиент запускает таймер ожидания сразу после отправки последнего ACK.

А РСТ?

мы согласилисьRST,SYN,FINФлаг используется для установки и закрытия соединения, потом появились SYN и FIN, а как же RST? Да, то, что мы обсудили выше, это идеальная ситуация, то есть и клиент, и сервер будут принимать сегмент передачи.Другая ситуация, когда хост получает сегмент TCP, его IP и номера портов различаются. Предположим, клиентский хост отправляет запрос, а серверный хост обнаруживает, что он не для этого сервера, судя по IP и номеру порта, тогда сервер отправит запрос.RSTСпециальный сегмент для клиента.

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

Приведенное выше обсуждение относится к TCP, а как насчет UDP?

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

SYN-флуд-атака

Давайте обсудим, что естьSYN-флуд-атака.

Мы видели в трехстороннем рукопожатии TCP, что сервер выделяет и инициализирует переменные соединения и кэширует в ответ на полученный SYN, затем сервер отправляет SYNACK в ответ, а затем ждет сообщения ACK от клиента. Если клиент не отправляет ACK для завершения последнего шага, то соединение находится в состоянии ожидания, т. е. в полуподключенном состоянии.

В этом случае злоумышленники обычно отправляют большое количество TCP-сегментов SYN, а сервер продолжает отвечать, но каждое соединение не может завершить трехэтапное рукопожатие. Поскольку SYN продолжает увеличиваться, сервер будет продолжать выделять ресурсы для этих полуоткрытых соединений, что в конечном итоге приведет к исчерпанию соединений сервера. Эта атака такжеDosСвоего рода атака.

Способ защиты от этой атаки заключается в использованииSYN cookie, ниже приведено введение в его рабочий процесс

  • Когда сервер получает SYN-сегмент, он не знает, откуда пришел этот сегмент, будь то с хоста атакующего или с хоста клиента (хотя атакующий тоже клиент, но разницу отличить проще). Таким образом, сервер не создает полуоткрытое соединение для сегмента. Напротив, сервер генерирует начальный порядковый номер TCP, представляющий собой сложную хеш-функцию, состоящую из четырех кортежей исходного и целевого IP-адресов и номеров портов сегмента SYN.SYN Cookie, который используется для кэширования запросов SYN. Затем сервер отправляет пакет SYNACK с файлом cookie SYN.Следует отметить, что сервер не запоминает этот файл cookie или другую информацию о состоянии SYN..
  • Если клиент не является злоумышленником, он вернет сегмент ACK. Когда сервер получает ACK, ему необходимо проверить, совпадает ли ACK с отправленным SYN Критериями проверки являются номер подтверждения и серийный номер в поле подтверждения, IP-адреса источника и получателя и номера портов. , и соответствуют ли они хеш-функции.Совпадает ли результат хеш-функции + 1 со значением подтверждения в SYNACK. (Примерно так, поправьте, пожалуйста, читателя, если он не прав). Заинтересованные читатели могут узнать больше об этом самостоятельно. Если допустимо, сервер создает полностью открытое соединение с сокетом.
  • Если клиент не возвращает ACK, то есть считается атакующим, то не беда, сервер не получит ACK, не будет выделять переменные и кэш-ресурсы и не причинит серверу вреда.

контроль перегрузки

Благодаря оконному управлению TCP два хоста в компьютерной сети больше не отправляются в виде одного сегмента данных, а могут непрерывно отправлять большое количество пакетов данных. Однако большое количество пакетов также связано с другими проблемами, такими как загрузка сети, перегрузка сети и т. д. Чтобы предотвратить такие проблемы, TCP использует拥塞控制Механизм управления перегрузкой ограничивает передачу данных отправителя в случае перегрузки сети.

Существует два основных метода контроля перегрузки

  • 端到端的拥塞控制: поскольку сетевой уровень не обеспечивает явную поддержку управления перегрузкой на транспортном уровне. Таким образом, даже если в сети есть перегрузка, конечные системы должны делать выводы из наблюдений за поведением сети.TCP использует сквозное управление перегрузкой. Уровень IP не предоставляет конечным системам информацию о перегрузке сети. Так как же TCP определяет перегрузку сети?Если тайм-аут или три избыточных подтверждения считаются перегрузкой сети, TCP уменьшит размер окна или увеличит задержку приема-передачи, чтобы избежать.
  • 网络辅助的拥塞控制: при управлении перегрузкой с помощью сети маршрутизатор предоставляет отправителю обратную связь о состоянии перегрузки в сети. Эта информация обратной связи представляет собой бит информации, указывающий на перегрузку канала.

На следующем рисунке показаны эти два метода управления перегрузкой.

Контроль перегрузки TCP

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

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

Но есть три проблемы с этим подходом

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

Сначала обсудим первый вопрос,Как отправитель TCP ограничивает скорость, с которой он может отправлять сегменты другим соединениям??

Мы знаем, что TCP состоит из буферов приема, буферов отправки и变量(LastByteRead, rwnd，等)сочинение. Механизм управления перегрузкой TCP отправителя отслеживает переменную, а именно拥塞窗口(congestion window)переменная, окно перегрузки выражается какcwnd, который ограничивает объем данных, которые TCP может отправить в сеть до получения ACK. и接收窗口(rwnd)это объем данных, используемый, чтобы сообщить получателю, что он может принять.

Как правило, количество неподтвержденных данных отправителем не должно превышать минимальное значение cwnd и rwnd, которое

LastByteSent - LastByteAcked <= min(cwnd,rwnd)

Поскольку время прохождения каждого пакета туда и обратно равно RTT, мы предполагаем, что у получателя достаточно места в буфере для приема данных, нам не нужно учитывать rwnd, просто сосредоточьтесь на cwnd, тогда скорость отправки отправителя примерно равнаcwnd/RTT 字节/秒. Таким образом, настраивая cwnd, отправитель может настроить скорость, с которой он отправляет данные в соединение.

Как отправитель TCP воспринимает перегрузку сети??

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

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

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

  • Если при отправке сегмент теряется, это означает, что сеть перегружена, и скорость TCP-отправителя необходимо соответствующим образом снизить.
  • Сегмент подтверждения указывает, что отправитель доставляет сегмент получателю, тем самым увеличивая скорость отправителя, когда приходит подтверждение для ранее неподтвержденного сегмента. Зачем? Поскольку неподтвержденный сегмент поступает к получателю, это означает, что сеть не перегружена и может доставляться гладко, поэтому длина окна перегрузки отправителя станет больше, поэтому скорость отправки увеличится.
  • 带宽探测, датчик полосы пропускания сообщает, что TCP может увеличивать/уменьшать количество ACK, регулируя скорость передачи, и в случае потери пакетов скорость передачи будет снижена. Следовательно, чтобы определить, как часто возникает перегрузка, отправитель TCP должен увеличить скорость передачи. Затем медленно уменьшите скорость передачи и снова начните исследование, чтобы увидеть, изменилась ли скорость возникновения перегрузки.

Разобравшись с управлением перегрузкой TCP, давайте поговорим о TCP.拥塞控制算法(TCP congestion control algorithm). Алгоритм управления перегрузкой TCP в основном состоит из трех частей:Медленный старт, предотвращение перегрузок, быстрое восстановление, давайте посмотрим на

медленный старт

Когда TCP начинает устанавливать соединение, значение cwnd инициализируется меньшим значением MSS. Это делает начальную скорость отправки примерноMSS/RTT 字节/秒, например, для передачи 1000 байт данных и RTT 200 мс результирующая начальная скорость передачи составляет около 40 кбит/с. На практике доступная пропускная способность намного больше, чем этот MSS/RTT, поэтому, если TCP хочет найти наилучшую скорость отправки, он может пройти慢启动(slow-start)В режиме медленного пуска значение cwnd будет инициализировано до 1 MSS, и MSS будет добавляться после подтверждения каждого сообщения о передаче, а значение cwnd станет равным 2 MSS, эти два сегмента сообщения после успешной передачи каждый сегмент + 1 станет 4 MSS, и так далее, значение cwnd будет удваиваться для каждой успешной передачи. Как показано ниже

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

  • Если потеря пакетов происходит во время процесса медленного запуска, TCP установит cwnd отправителя в 1 и перезапустит процесс медленного запуска, что приведет кssthresh(慢启动阈值)Его начальным значением является значение cwnd, которое выдает потерю пакетов/2, то есть при обнаружении перегрузки значение ssthresh составляет половину значения окна.

  • Второй способ напрямую связан со значением ssthresh, так как при обнаружении перегрузки значение ssthresh равно половине значения окна, тогда при cwnd > ssthresh возможна потеря пакетов каждый раз, когда оно удваивается, поэтому лучший способ что значение cwnd = ssthresh, так что TCP переключится в режим управления перегрузкой и завершит медленный старт.

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

предотвращение перегрузки

Когда TCP входит в состояние управления перегрузкой, значение cwnd равно половине значения во время перегрузки, т. е. значения ssthresh. Поэтому невозможно удваивать значение cwnd каждый раз, когда приходит сегмент. Вместо этого родственник保守метод, увеличивайте значение cwnd только после завершения каждой передачи一个 MSS, например, получены 10 подтверждений сегмента, но значение cwnd увеличивается только на один MSS. Это режим линейного роста, и у него тоже будет порог роста.Порог его роста такой же, как и у медленного старта.При потере пакетов значение cwnd равно MSS, а значение ssthresh равно половине cwnd; или Получение 3 избыточных ответов ACK также останавливает рост MSS. Если TCP по-прежнему получает 3 избыточных ACK после уменьшения вдвое значения cwnd, он запишет значение ssthresh как половину значения cwnd и введет快速恢复государство.

быстрое восстановление

При быстром восстановлении значение cwnd увеличивается на один MSS для каждого избыточного ACK, полученного для отсутствующих сегментов, чтобы перевести TCP в состояние быстрого восстановления. Когда приходит ACK для отсутствующего сегмента, TCP переходит в состояние предотвращения перегрузки после снижения cwnd. Если тайм-аут происходит после состояния управления перегрузкой, происходит переход в состояние медленного запуска, когда для параметра cwnd установлено значение 1 MSS, а для параметра ssthresh установлено значение половины значения cwnd.

постскриптум

Если вы сможете смотреть сюда своим сердцем, я верю, что вы что-то приобретете.

Эта статья написана давно.Многие стили и цвета на картинках тщательно подобраны.Если внимательно прочитать,то видно,что у меня благие намерения.

Если вы считаете, что статья хорошо написана, вы можете помочь cxuan распространить ее. Это будет мотивацией для меня продолжать обновлять. Не покупайте даром, это обойдется вам дешево, а хорошими статьями стоит поделиться.

Пожалуйста, не забудьте поставить мне лайк!

Кроме того, я сам перелил шесть PDF-файлов.После того, как программист поиска WeChat cxuan обратил внимание на официальный аккаунт, он ответил cxuan в фоновом режиме, чтобы получить все PDF-файлы, эти PDF-файлы.

Категории