Специальный обзор протокола компьютерной сети и транспортного уровня (часть 1)

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

Выше приведена ментальная карта этой статьи. Я предлагаю рецензентам составить ее для собственного обзора~

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

первый

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

Подробная разница:

1. tcp основан на соединении и имеет высокую надежность, udp не требует соединения и имеет низкую надежность;

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

3. При передаче данных одинакового размера накладные расходы tcp-заголовка составляют 20 байт, служебные данные udp-заголовка составляют всего 8 байт, а tcp-заголовок сложнее, чем udp, поэтому фактически содержит меньше пользовательских данных. TCP не имеет потери пакетов, в то время как udp имеет потерю пакетов, поэтому tcp имеет большие накладные расходы, а udp имеет небольшие накладные расходы;

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

Различия в сценариях применения:

Из-за характеристик TCP и UDP, UDP необходимо использовать в сценариях с высокими требованиями к реальному времени и высокой скоростью передачи;
Если вам нужно передать большой объем данных и требуется высокая надежность данных, используйте TCP;
Используйте UDP, когда требования к надежности невелики и преследуется цель эффективности;

Три ядра TCP:

ориентированный на соединение;Так называемое ориентированное на соединение относится к соединению между клиентом и сервером.Перед тем, как две стороны свяжутся друг с другом, TCP требует возобновления соединения с трехсторонним рукопожатием, в то время как UDP не имеет соответствующего процесса возобновления соединения.
надежность; Надежность TCP в основном отражается на1 Статус 2 Контролируемый
байтовый поток;Передача данных UDP основана на дейтаграммах и наследует только характеристики уровня IP, в то время как TCP изменяет IP-пакет в поток байтов для статуса обслуживания.

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

而UDP不可靠原因：无状态，不可控

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

Один процесс рукопожатия и изменения, почему не дважды, почему не четыре раза, могут ли данные передаваться в процессе рукопожатия, и что происходит, когда волна инициируется одновременно

Процесс трехстороннего рукопожатия TCP

Трехстороннее рукопожатие подтверждает две возможности обеих сторон: возможность отправки и возможность получения.Изначально обе стороны находятся в состоянии ЗАКРЫТО. Затем сервер начинает прослушивать определенный порт и переходит в состояние LISTEN.

Клиент обращает внимание на инициирование соединения, отправку SYN, и оно переходит в состояние SYN-SENT.
Сервер получает его, возвращает SYN и ACK (соответствует SYN, отправленному клиентом) и сам становится SYN-RECD.
Клиент отправляет ACK на сервер, и он становится ESTABLISHED (установленным) состоянием; после того, как сервер получает ACK, он также становится этим состоянием

Почему не дважды?

Основная причина: невозможно подтвердить возможность получения клиентом. Возможная проблема заключается в том, что два рукопожатия, пока сервер получает, а затем отправляет соответствующий пакет данных,默认连接 , но на самом деле клиент сейчас мог быть отключен, что также приводит к трате ресурсов соединения ``

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

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

Могут ли данные передаваться во время трехэтапного рукопожатия?

Да, но только в третий раз, на этот разestablishedСтатус относительно безопасен и достаточен для подтверждения способности сервера получать и отправлять.

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

Четыре волны для отключения

Сначала клиент активно завершает работу и отправляет сообщение на сервер.FINсообщение
После того, как сервер его получает, он уведомляет процесс приложения и отправляет его клиенту.ACKподтверждать
После того, как сервер закончил обработку, он пассивно закрывается и снова отправляется клиенту.FINтак же какACK,ВойтиLAST-ACKусловие,
Клиент получает сообщение от сервераFINпосле отправкиACKна сервер. ожидающий2MSLпосле входаCLOSEDусловие

Обратите внимание, что в это время клиенту нужно подождать дваMSL(Maximum Segment Lifetime, максимальное время жизни сообщения), если клиент не получает запрос на повторную передачу от сервера в течение этого периода, это означает, чтоACK Если он приходит успешно, волна завершается, в противном случае клиент повторно отправляет ACK.

Зачем ждать 2 MSL?

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

Зачем махать четыре раза вместо трех?

Поскольку сервер получаетFIN, часто не возвращается сразуFIN, Вы должны дождаться, пока все сообщения на сервере не будут отправлены, прежде чем отправлятьFIN.
Таким образом, запуск ACK сказал, что клиент полученFIN, с задержкой на некоторое времяFIN. В результате получилось четыре волны.如果是三次挥手会有什么问题？Это означает, что сервер будетACKа такжеFINОтправки объединяются в одну волну, длительные задержки могут привести к ошибкам клиентовFINНе достигает клиента, так что клиент продолжает повторную передачуFIN.

волна в то же время

Когда отправитель отправляет сообщение SYN получателю, получатель также отправляет сообщение SYN отправителю.

На приведенном выше рисунке показано изменение состояния в случае одновременного открытия.

После отправки SYN состояние обоих становится SYN-SENT.
После того, как каждый получает SYN другого, состояние обоих становится SYN-REVD.
Затем будет получен соответствующий ответ ACK + SYN.После того, как сообщение получено другой стороной, два статуса становятся УСТАНОВЛЕННЫМИ вместе.

SYN Flood

Полусвязная очередь, полносвязная очередь, процесс атаки SYN Flood, как бороться с этой атакой

очередь полуобъединения

когда клиент отправляетSYNна сервер, сервер ответит после его полученияACKа такжеSYN, состояние задаетсяLISTENсталиSYN_RCVD, после чего соединение устанавливаетсяSYN-очередь, которая представляет собой полусоединенную очередь.

полностью подключенная очередь

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

Принцип атаки SYN Flood

SYN Flood принадлежитТипичная DoS/DDoS-атака. Принцип его атаки очень прост: использовать клиента для подделки большого количества несуществующих IP-адресов за короткий промежуток времени и лихорадочно отправлять SYN на сервер. Для сервера есть два опасных последствия:

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

Как бороться с атаками SYN Flood?

Увеличьте SYN-соединение, то есть увеличить емкость очереди полусоединений.
Уменьшить количество попыток SYN + ACK, чтобы избежать большого количества повторных передач по тайм-ауту.
Используйте технологию файлов cookie SYN, после получения SYN сервер не выделяет ресурсы соединения сразу, а вычисляет cookie на основе SYN и отвечает клиенту вместе со вторым рукопожатием, ресурсы соединения выделяются только после того, как cookie действителен.

Взаимосвязь между очередью полусоединения и атакой SYN-флуда

Перед трехэтапным рукопожатием статус сервера меняется сCLOSEDсталиLISTENи внутри создает две очереди: Полусвязные очереди и полносвязные очереди, а именно очереди SYN и очереди ACCEPT.
Полусвязная очередь — это когда клиент отправляетSYNна сервер, сервер ответит после его полученияACKа такжеSYN, состояние задаетсяLISTENсталиSYN_RCVD, после чего соединение устанавливаетсяSYN-очередь
SYN Flood подделывает большое количество несуществующих IP-адресов за короткий промежуток времени и лихорадочно отправляет SYN на сервер. Чтобы обработать большое количество пакетов SYN и вернуть соответствующий ACK, большое количество соединений должно находиться в состоянии SYN_RCVD, таким образом занимая всю очередь полусоединений и неспособные обрабатывать обычные запросы.

Разбор полей заголовка TCP

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

исходный порт, порт назначения

如何标识唯一标识一个连接？答案是 TCP 连接的四元组——源 IP、源端口、目标 IP 和目标端口。

那 TCP 报文怎么没有源 IP 和目标 IP 呢？这是因为在 IP 层就已经处理了 IP 。TCP 只需要记录两者的端口即可。

серийный номер То есть Sequence number, который относится к порядковому номеру первого байта этого сегмента.

序列号在 TCP 通信的过程中有两个作用:

在 SYN 报文中交换彼此的初始序列号。
保证数据包按正确的顺序组装。

即Initial Sequence Number（初始序列号）,在三次握手的过程当中，双方会用过SYN报文来交换彼此的 ISN。
ISN 并不是一个固定的值，而是每 4 ms 加一，溢出则回到 0，这个算法使得猜测 ISN 变得很困难。那为什么要这么做？
如果 ISN 被攻击者预测到，要知道源 IP 和源端口号都是很容易伪造的，当攻击者猜测 ISN 之后，直接伪造一个 RST 后，就可以强制连接关闭的，这是非常危险的。
而动态增长的 ISN 大大提高了猜测 ISN 的难度。

Номер подтверждения А именно ACK (номер подтверждения). использовал кИнформировать другую сторону о следующем ожидаемом порядковом номере, все байты меньше ACK были получены.
бит флага Общие биты флага: SYN, ACK, FIN, RST, PSH.
SYN и ACK были упомянуты выше, последние три поясняются следующим образом:FIN: то есть Готово, указывающее, что отправитель готов отключиться.RST: Сброс, используемый для принудительного отключения.PSH: то есть Push, информирующий другую сторону о том, что эти пакеты данных должны быть переданы приложению верхнего уровня сразу после их получения и не могут кэшироваться.
размер окна На самом деле двух байтов недостаточно. Поэтому TCP вводит возможность масштабирования окна в качестве коэффициента масштабирования для масштабирования окна.Этот коэффициент масштабирования находится в диапазоне от 0 до 14. Коэффициент масштабирования может увеличить значение окна до исходной степени 2^n.
контрольная сумма Занимает два байта, чтобы предотвратить повреждение пакетов данных во время передачи.Если встречается пакет с ошибкой контрольной суммы, TCP напрямую отбрасывает его и ожидает повторной передачи.
необязательный Общие варианты следующие: TimeStamp: временная метка TCP, которая будет подробно описана позже. MSS: Относится к максимальному сегменту, который TCP разрешено получать от однорангового узла. SACK: выберите вариант подтверждения. Масштаб окна: параметры масштабирования окна.

不要死记，只要有个印象就行

Принцип быстрого открытия TCP (TFO)

Трехстороннее рукопожатие в первом раунде, трехстороннее рукопожатие после этого, преимущество TFO

процесс ТФО

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

就是第二次握手的时候不是立即返回SYN+ACK了，
而是返回计算得到的`SYN cookie`,
放在TCP报文的Fast Open（快速打开）选项中，
客户端拿到cookie将其缓存

первый клиентотправить СИННа сервер сервер его получает.
注意哦！现在服务端不是立刻回复 SYN + ACK, но черезрассчитатьполучить одинSYN Cookie, поместите этот файл cookie в пакет TCPFast Openварианты, прежде чем вернуться к клиенту.
клиент получает этоКэш значений cookieвниз. После этого трехстороннее рукопожатие завершается нормально.

Таким процессом является первое трехстороннее рукопожатие. И три рукопожатия сзади разные!

три рукопожатия позади

客户端发送Cookie+SYN+HTTP请求，
服务端验证合法，先确认，返回SYN+ACK，`返回HTTP响应`
客户端传ACK

В следующем трехэтапном рукопожатии клиентКэшированные файлы cookie, SYN и HTTP-запросы(Да, вы правильно прочитали) на сервер, на серверпроверятьПроверяется валидность куки, если она нелегальна, она будет отброшена напрямую, если легальна, то SYN+ACK будет возвращена нормально.
重点来了，现在服务端能向客户端发 HTTP 响应了！Это самое существенное изменение: трехстороннее рукопожатие еще не установлено, и HTTP-ответ может быть возвращен только после проверки легитимности куки.
Конечно, ACK клиента должен передаваться нормально, иначе что такое трехстороннее рукопожатие?

注意: 客户端最后握手的 ACK 不一定要等到服务端的 HTTP 响应到达才发送，两个过程没有任何关系。

Преимущества ТФО

拿到Cookie验证通过就能返回HTTP请求了，
利用了1个往返时延`RTT`提前进行数据传输

Преимуществом TFO является не трехстороннее рукопожатие в первом раунде, алежит за рукопожатием, после получения файла cookie клиента и его проверки вы можетеВернуть HTTP-ответ напрямую, полностью используя 1RTT(время приема-передачи, задержка приема-передачи) времяпередача данных заранее, накопление по-прежнему является относительно большим преимуществом.

Роль временной метки TCP

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

Алгоритм повторной передачи тайм-аута TCP

Классический метод
Алгоритм Якобсона/Карелса

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

Концепция скользящего окна TCP, процесс управления потоком

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

Как это делается? Например:

Во-первых, обе стороны трижды обмениваются рукопожатием, чтобы инициализировать свои соответствующие размеры окон, которые оба200байт.
Если текущий отправитель отправляет получателю100байт, то для отправителя в это времяДоступные окна уменьшены на 100байт.
Теперь 100 достигли приемника и помещены вБуферная очередь получателясередина. Однако из-за большой нагрузки в это время принимающая сторона не может обработать такое количество байтов.выдерживает только 40байты, остальное60байтыв буферной очередисередина.
Вышеописанное относится к случаю, когда вычислительной мощности недостаточно, а это означает, что отправитель отправляет мне меньше баллов, поэтому окно приема получателя должно быть уменьшено в это время.Уменьшить 60байт, с 200 байт до 140 байт, потому чтоБуферная очередь осталась 60байты не были взяты.
следовательно,Получатель будет указан в заголовке сообщения ACK.Принесите уменьшенное скользящее окно140байт, отправительнастроить соответственноРазмер окна отправки140байт.
На данный момент ситуация на стороне отправителя следующая:Часть, которая была отправлена и подтверждена, увеличивается на 40байт,Сдвиг вправо 40байт, покаОкно отправки уменьшено до 140байт.
Следующий рисунок:раздвижное окноструктура (отправитель) 还是搞不清，那你写一下画一下就想得明白了

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

Проблемы, связанные с медленным запуском, предотвращением перегрузки, быстрой повторной передачей и быстрым восстановлением, а также контрольными точками перегрузки на основе потери пакетов — алгоритм управления перегрузкой Google BBR

Говорите о контроле перегрузки TCP?

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

在这里插入图片描述

`对于拥塞控制来说，TCP每条连接都需要维护两个核心状态:`

Окно перегрузки(Окно перегрузки, cwnd):

 是指目前自己还能传输的数据量大小;
	接收窗口(rwnd)是接收端给的限制
	拥塞窗口(cwnd)是发送端的限制 发送窗口大小 = min(rwnd, cwnd)

Порог медленного запуска(Порог медленного запуска, ssthresh)

`涉及到的算法有这几个:`

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

Используя консервативный алгоритм для медленной адаптации ко всей сети, этот алгоритм называется медленным стартом;

Обработать: 1. Сначала три рукопожатия, обе стороны объявляют размер окна приема

2. Обе стороны инициализируют собственный размер окна перегрузки (cwnd).

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

Если начальное окно равно 10, то после первой передачи 10 пакетов и получения отправителем ACK окно перегрузки становится равным 20. Второй раунд становится 40, третий раунд становится 80 и так далее. пока не будет достигнут порог медленного пуска

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

После достижения порога, как контролировать размер окна перегрузки; Получается, что каждый раз при получении ACK окно перегрузки увеличивается на 1. Теперь, когда порог достигнут, окно перегрузки можно только добавить: 1/окно перегрузки В предыдущем раунде RTT cwnd удваивался, а теперь cwnd увеличивается только на 1.

慢启动和拥塞避免是一起作用的，是一体的。

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

быстрая ретрансляцияЕсли происходит потеря пакета, данные не приходят последовательно, и получатель повторяет предыдущий ACK. Например, если 5-й пакет потерян, даже если 6-й и 7-й пакеты дойдут до получателя, получатель всегда будет возвращать ACK 4-го пакета. Получите 3 дубликата ACK, осознайте потерю пакета и немедленно повторите передачу;выборочная ретрансляцияАтрибут SACK сообщения ACK, интервал получен через левый край и правый крайбыстрое восстановлениеПосле того, как отправитель получит три повторных ACK, он обнаружит, что пакет потерян, и почувствует, что сеть уже перегружена, и перейдет в стадию быстрого восстановления. Отправитель меняется следующим образом: Порог перегрузки уменьшается до половины cwnd, размер cwnd становится порогом перегрузки, а cwnd увеличивается линейно.

В сочетании с картинками для лучшего понимания:

在这里插入图片描述

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

Справочная статья

Возможно, есть некоторые, на которые я забыл сослаться, я перечислю все, что помню, еще раз спасибо~

сто шоколад:GitHub.com/chocolate19…

CavsZhouyou:github.com/CavsZhouyou

Бог Троица: (рекомендуемый сборник) Вопрос о душе протокола TCP, укрепление фундамента вашей сети (рекомендуемый сборник) Вопрос о духе протокола TCP, укрепление фундамента вашей сети

ЛинДайДай_ЛинДайДай: Серия статей об отключении HTTP

⭐️⭐️ Я видел это, пожалуйста, поставьте мне палец вверх, было бы еще лучше, если бы я мог подключиться три раза одним кликом ❀, ваша поддержка является движущей силой для меня, чтобы продолжать писать Напоследок добавлю свое запоздалое новогоднее поздравление: Желаю всем крепкого здоровья, счастья каждому дню, чтобы все шло хорошо, все, что вы хотите, сбудется, и вы станете богатым~~