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

Введение в протоколы транспортного уровня

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

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

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

Двумя ключевыми элементами протокола IP являются IP-адрес источника и IP-адрес получателя. И мы только что сказали, что основная роль транспортного уровня заключается в том, чтобыРеализовать связь между приложениями. Поэтому в протокол транспортного уровня добавляются три элемента: номер исходного порта, номер порта назначения и номер протокола. С помощью этих пяти частей информации сообщение может быть однозначно идентифицировано.

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

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

Подводя итог: «Исходный IP-адрес, целевой IP-адрес, номер исходного порта, номер целевого порта и номер протокола». Эти пять сведений считаются разными коммуникациями.

UDP-заголовок

Самая большая функция протокола UDP проста, его первая часть, как показано ниже:

TCP-заголовок

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

Некоторые из этих ключевых полей описаны ниже:

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

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

• Смещение данных: длина заголовка TCP в 4 байтах. Если необязательных полей нет, значение здесь равно 5. Указывает, что длина заголовка TCP составляет 20 байт.

• Управляющие биты: изменена длина 8-битного поля, у каждого по восемь флагов. Далее следуют CWR, ECE, URG, ACK, PSH, RST, SYN и FIN. В следующей статье вы продолжите контролировать доступ к некоторым его частям.

• Размер окна: используется для указания того, сколько 8-битных байтов можно принять из номера ответа. Оконные зонды могут быть отправлены, если размер окна равен 0.

• Срочный указатель: Действителен, только если управляющий бит URG равен 1. Указывает позицию конца срочных данных в разделе данных TCP. Обычно используется при временном прерывании связи (например, при нажатии Ctrl + C).

TCP-рукопожатие

1. (Клиент): Я хочу установить соединение.
2. (Сервер): Я знаю, что вы собираетесь установить соединение, у меня нет проблем.
3. (Клиент): Я знаю, вы знаете, что я собираюсь установить связь, и тогда мы официально начнем общаться.

Почему трехстороннее рукопожатие

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

Это потому, что в сетевых запросах мы всегда должны помнить: «Сеть ненадежна, и пакеты могут быть потеряны». Предполагая, что третьего подтверждения нет, клиент отправляет SYN на сервер, чтобы запросить соединение. Из-за задержки сервер не получил пакет вовремя. Таким образом, клиент повторно отправляет пакет SYN. Вспомните порядковые номера, упомянутые во введении к заголовку TCP, порядковые номера этих двух пакетов, очевидно, одинаковы.

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

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

Что делать, если пакет подтверждения ACK потерян?

Трехстороннее рукопожатие фактически решает проблему потери пакетов на втором этапе. Итак, как протокол TCP справляется с потерей подтверждения ACK на третьем этапе?

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

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

Четырехстороннее рукопожатие закрывает соединение

Этот процесс можно представить следующими четырьмя образными диалогами:

1. (клиент): Я закрываю соединение.
2. (Сервер): Соединение с вашей стороны может быть закрыто.
3. (Сервер): Здесь я тоже должен закрыть соединение.
4. (Клиент): Соединение с вашей стороны может быть закрыто.

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