Резюме интервью TCP и UDP

TCP/IP
Резюме интервью TCP и UDP

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

Оба протокола TCP и UDPтранспортный уровеньпротокол.

1. TCP-протокол

TCP (протокол управления передачей, протокол управления передачей)ориентированный на соединениесоглашение.

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

Основное внимание в этом протоколе уделяется ориентации соединения. Содержание, которое он содержит, связано с связью.установить соединениеиОтключитьпроцесс.

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

трехстороннее рукопожатиеФункция: перед коммуникацией определить отношения между клиентом и серверомполучать, отправлятьСпособность нормальная.

ВовлеченныйTCP-заголовок:

  • SYN
  • ACK: последовательность ACK равна x+1, что указывает на то, что были введены предыдущие x данных, и ожидается, что отправка начнется с x+1.
  • seq

1. Конкретный процесс трехэтапного рукопожатия

  • Хост A отправляет данные, содержащие бит флага порядкового номера синхронизации SYN, хосту B,
  • После того, как хост B получает его, он отправляет ACK и SYN хосту A.
  • После того, как хост A получает его, он отправляет подтверждение ACK хосту B. .

первое рукопожатие: Клиент отправляетСодержит SYN и seqСетевой пакет получен сервером.

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

второе рукопожатие: отправлено серверомСодержит SYN, ACK и seqЗатем сетевой пакет принимается клиентом.

  • Точка зрения клиента делает выводы:Возможности получения и отправки, клиентВозможности получения и отправкинормально.

третье рукопожатие: Клиент отправляетСодержит ACK и последовательностьСетевой пакет получен сервером.

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

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

2. Возможно ли двустороннее рукопожатие?

два рукопожатия: клиент отправляет запрос на соединение, содержащий SYN, сервер ответит ACK, и соединение будет установлено.

  1. Если клиент отправляет запрос на подключение, но не получает подтверждения, поскольку пакет запроса на подключение потерян, клиент повторно передает запрос на подключение.
  2. Позже было получено подтверждение, и соединение было установлено.
  3. После завершения передачи данных соединение разрывается.

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

  • Сервер поддерживает соединение и ждет, пока клиент отправит данные, что приводит к трате ресурсов.

3. Проблема сбоя трехэтапного рукопожатия

Сервер устанавливает соединение:

  • Третий ACK потерян в сети, статус TCP-соединения на стороне сервера — SYN_RECV, и в соответствии с механизмом повторной передачи тайм-аута TCP он будет ждать 3 секунды, 6 секунд и 12 секунд, чтобы повторно отправить пакет SYN+ACK. , чтобы повторно отправить пакет ACK. Если ответ ACK от клиента по-прежнему не получен после указанного количества повторных передач, сервер автоматически закроет соединение через определенный период времени.

Клиент устанавливает соединение:

  • В linux c клиент обычно подключается к серверу через функцию connect(), и connect() успешно возвращает значение после завершения второго рукопожатия трехэтапного рукопожатия TCP. То есть, когда клиент получает пакет SYN+ACK, его состояние TCP-соединения устанавливается (подключено), указывая на то, что соединение установлено. Затем, если пакет ACK в третьем рукопожатии потерян, клиент отправляет данные на сервер, а сервер отвечает пакетом RST, чтобы сервер мог воспринять ошибку.

син-флуд атака:

  • Когда третье рукопожатие не отправляет подтверждающую информацию, после ожидания в течение определенного периода времени хост отключает предыдущее полуоткрытое соединение и перерабатывает ресурсы, что таит в себе скрытую опасность для атак типа «отказ в обслуживании». активно отправляет большое количество пакетов syn data, но не отвечает на третье рукопожатие, сервер выделит ресурсы для этих пакетов syn (но не использует их), что приведет к тому, что сервер займет много памяти и истощит сервер среда подключения.Это атака Syn Hong Pan.

1.2 Отключение: четыре волны

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

Клиент отключается:

  • Клиент отправляет сетевой пакет, содержащий FIN, и сервер его получает.
  • Сервер отправляет сетевой пакет, содержащий ACK (здесь появляется close-wait), клиент его получает, и соединение в этом направлении закрывается.

Сервер отключен:

  • Сервер отправляет сетевой пакет, содержащий FIN, а клиент его получает.
  • Клиент отправляет сетевой пакет, содержащий ACK (время ожидания начинает отсчет времени), сервер его получает, а соединение в этом направлении в это время закрыто.

1. Роль времени ожидания

Время начала ожидания по tcp передается четыре раза.Активно закрыть соединениезакончил отправкупоследняя волна, то есть после окончания сигнала ACK=1 состояние, в котором соединение активно закрыто.

время ждетпродолжительностьза 2МСЛ.

  • MSL — максимальное время жизни сегмента, переводится какМаксимальное время жизни пакета, может быть 30 с, 1 мин или 2 мин. Инженерия 2мин, 2мсл 4мин.

просить: Почему так долго?отвечать:

  1. Чтобы гарантировать, что последний сегмент подтверждения, отправленный клиентом, может достичь сервера. Поскольку последний пакет подтверждения подтверждения может быть потерян, сервер через какое-то время повторно передаст сообщение fin третьей волны, а затем клиент повторно передаст сообщение подтверждения четвертой волны. Если 2msl нет, и клиент напрямую закрывает соединение после отправки последней ack-датаграммы, он не получит сообщение fin, повторно переданное сервером сверхурочно (здесь должно быть так, что клиент получает недопустимый сегмент и возвращает RST-дейтаграмму, указывающую что сообщение отклонено, а затем обе стороны генерируют исключение вместо того, чтобы не получать его.), то сервер не может войти в закрытое состояние в соответствии с обычными шагами. Тогда он будет потреблять ресурсы сервера. Когда в сети большое количество состояний ожидания, можно себе представить нагрузку на сервер.

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

2. close_wait

close_wait появляется на стороне пассивного закрытия

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

Быстрое решение на данный момент:

  1. Закройте запущенные программы в зависимости от деловой ситуации.
  2. Исправьте ошибки в программе как можно скорее, а затем отправьте тест на онлайн-сервер.

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

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

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

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

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

Порядковый номер подтверждения: это порядковый номер n следующего ожидаемого байта, и n означает, что приемник получил первые n-1 байтов данных.В это время, если приемник получает n+1-й байт данных вместо n-й байт Для данных получатель не будет отправлять ACK с порядковым номером n+2.

размер окна: Текущий размер окна m, чтобы отправитель мог рассчитать, сколько байтов данных может быть отправлено другой стороне после получения двух данных, содержащихся в ACK.Предполагая, что текущий отправитель отправил x-й байт, вы можете число отправленных байтов равно y=m-(xn) Это основной принцип потока управления скользящим окном.

Тупик, вызванный управлением потоком

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

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

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

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

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

Обычно используется следующий метод:

  1. Медленный старт, предотвращение заторов
  2. Быстрая ретрансляция и быстрое восстановление.

1. Медленный старт, предотвращение перегрузок

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

  • После столкновения с перегрузкой сети порог становится вдвое меньше, чем сейчас, а затем окно снова начинается с 1

Застой возникает:

  • Потеря пакетов (переполнение буфера маршрутизатора)
  • Задержка пакета слишком велика (поставлена ​​в очередь в кэше маршрутизатора)

2. Быстрая ретрансляция, быстрое восстановление

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

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

быстрое восстановление: Когда отправитель получает три последовательных повторных подтверждения, выполнитеуменьшение умноженияАлгоритм уменьшения вдвое порога окна перегрузки (для предотвращения перегрузки сети). Однако затем алгоритм медленного запуска не выполняется, а текущее окно отправки устанавливается равным значению после того, как пороговое значение окна перегрузки уменьшается вдвое, а затем выполняется алгоритм предотвращения перегрузки.

2. UDP-протокол

Протокол UDP: В службу IP-дейтаграмм добавлены только функции мультиплексирования и демультиплексирования, а также функция обнаружения ошибок.

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

3. Разница между TCP и UDP

1. На основе подключения или без подключения

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

2. Надежность

  • TCP обеспечивает гарантию доставки, в случае потери во время передачи он будет передан повторно.
  • UDP ненадежен и не дает никаких гарантий доставки. (Потеря пакетов онлайн-игр и видео)

3. Порядок

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

4. Границы данных

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

5. Скорость

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

6. Отправка потребления

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

7. Размер заголовка

  • Заголовок TCP большой.
    • Размер заголовка пакета TCP составляет 20 байт.
    • Заголовок TCP содержит порядковый номер, номер ACK, смещение данных, зарезервировано, управляющие биты, окно, срочный указатель, параметры, заполнение, контрольные биты, исходный порт и порт назначения.
  • Заголовок UDP маленький.
    • Заголовок дейтаграммы UDP составляет 8 байт.
    • Заголовок UDP содержит только длину, номер исходного порта, порт назначения и контрольную сумму.

8. Перегрузка или управление потоком

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

9. Применение

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

10. Протоколы, используемые верхними уровнями

  • На основе протоколов TCP: протоколы Telnet, FTP и SMTP.
  • На основе протокола UDP: DHCP, DNS, SNMP, TFTP, BOOTP.
Категории