моя контактная информация
Почтамезофия@protonmail.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Протокол TCP обладает характеристиками соединения, надежной передачи, ориентированности на поток байтов, полнодуплексного режима и т. д. Надежная передача является его основной частью.
Рисунок 1
На рисунке выше показана структура заголовка TCP.
(1) Порт источника и порт назначения не нужно вводить слишком подробно. Это программы, используемые для указания отправляющей стороны и принимающей стороны.
(2) Порядковый номер и порядковый номер подтверждения используются для механизма ответа на подтверждение в TCP, представленного позже.
(3) 4 бита в части смещения данных фактически используются здесь для указания длины заголовка TCP. Из-за 4 битов максимальное представленное число равно 15, но поскольку единица измерения составляет 4 байта, максимальная длина. TCP-заголовок имеет длину 60 байт.
(4) Мы все знаем, что максимальная длина пакетов данных UDP составляет 64 КБ, что очень ограничено, поэтому, чтобы избежать этой ситуации, в заголовке TCP предусмотрены 6 зарезервированных битов, которые можно использовать, если функция TCP расширена. позже. Представлено с использованием зарезервированных битов.
(5) 6-байтовый английский идентификатор связан с механизмом TCP, представленным позже, и здесь не будет представлен.
(6) Контрольная сумма имеет ту же функцию, что и контрольная сумма в UDP, а также используется для проверки того, изменились ли данные в процессе передачи.
(7) Окно будет обсуждаться позже, когда будет представлен механизм.
(8) Указатель аварийной ситуации будет введен позже.
(9) Среди опций есть несколько дополнительных/дополнительных опций.
Протокол TCP должен решить очень важную задачу — надежную передачу. Так называемая надежная передача не означает, что отправитель может отправить данные получателю на 100%, но он сделает все возможное, чтобы сообщить отправителю, знает ли получатель.
фигура 2
Как показано на рисунке 2, каждый раз, когда вы отправляете сообщение богине, богиня отправляет вам ответ. Это также имеет место в TCP. Клиент отправляет пакет данных, и сервер отправляет его. вернуть пакет данных ответа. В это время флаг ACK пакета на рисунке 1 будет установлен в значение 1.
изображение 3
Как показано на рисунке 3, когда мы отправляем богине несколько сообщений, поскольку богиня отвечает на сообщения с разной скоростью, мы можем легко запутаться. Мы подумаем, что богиня согласна быть моей девушкой. Богиня говорит, чтобы ты заблудился. Это Интернет. Проблема «последним пришел первым обслужен» объективно существует в Китае. Очевидно, что при отправке клиенту нескольких пакетов данных и ответе клиента на несколько пакетов данных ответа нам также необходимо различать, какой ответ соответствует тому, какой пакет данных был отправлен. Эту проблему можно решить, используя порядковый номер и порядковый номер подтверждения на рисунке 1. .
Каждый отправленный пакет данных имеет порядковый номер, но порядковый номер подтверждения отсутствует, или поле порядкового номера подтверждения недействительно. Подтверждение ответного на него пакета данных равно 1. В это время поле порядкового номера подтверждения действительно. а также порядковый номер отправленного пакета данных и ответ. Порядковые номера подтверждения пакетов данных соответствуют друг другу, так что можно определить, кто кому ответил, и можно решить вышеупомянутую проблему «последним пришел первым обслужен» в сети. .
Порядковый номер фактического пакета данных TCP нумеруется в соответствии с байтами. Каждому байту будет присвоен порядковый номер. Значение порядкового номера в заголовке TCP — это номер первого байта в полезной нагрузке, например номер. первого байта в части полезной нагрузки. Номер байта равен 1, а длина полезной нагрузки составляет 1000 байт, тогда порядковый номер подтверждения в заголовке пакета данных ответа равен 1001. Это связано с тем, что порядковый номер подтверждения для Для пакета ответных данных, соответствующего пакету данных, установлено значение. Номер последнего байта полезной нагрузки увеличивается на 1. Фактически, это легче понять. Возврат 1001 означает, что отправленная полезная нагрузка размером 1000 байт была получена, и запрашиваются данные после 1001, как показано на рисунке 4.
Рисунок 4
Для последующих отправленных пакетов данных порядковый номер увеличивается, но следует отметить, что хотя он и увеличивается, порядковый номер не начинается с 0 или 1.
Надежная передача может быть достигнута главным образом за счет использования механизма «подтверждающего ответа». Через ответное сообщение он может сообщить отправителю, все ли в порядке и происходит ли потеря пакетов. Что делать, если происходит потеря пакетов (данные теряются в процессе передачи и не могут дойти до противоположного конца, объективное случайное событие)?
Повторная передача по тайм-ауту используется для устранения проблем с потерей пакетов в сети.
Здесь в основном встречаются две ситуации:
(1) Переданные пакеты данных теряются.
В это время B не будет отправлять ответный пакет, если он не получит пакет данных A. Когда ожидаемое событие A превысит определенный порог, он определит, что возникла проблема с потерей пакета, и повторно передаст пакет данных.
(2) Пакет ответных данных потерян.
Когда A не получает ответный пакет данных, он все равно повторно передает пакет данных, но в это время B получил пакет данных. При повторной передаче пакета данных он получит два одинаковых пакета данных. Это очень ненаучно. , особенно для таких вопросов, как переводы, когда будут происходить повторные переводы.
Для решения вышеуказанных проблем получатель TCP дедупликаирует полученные данные в соответствии с порядковым номером. Уровень TCP не заботится о проблеме дублирования. Ключевым моментом является то, что уровень приложения не может читать повторяющиеся данные. Независимо от того, сколько раз они передаются, необходимо гарантировать, что уровень приложения читает только одну копию данных.
В ядре принимающей операционной системы есть структура данных — приемный буфер. Эта структура данных аналогична очереди блокировки приоритетов. Когда B получает пакет данных и проходит через уровни на транспортный уровень, возникает очередь. блокирующая очередь для размещения данных. Введите ее, и очередь определит, существуют ли данные, на основе порядкового номера пакета данных. Если он существует (наличие означает, что один и тот же пакет данных был получен и прочитан один раз). прикладной уровень), он будет сразу отброшен. Еще одна особенность буфера приема заключается в том, что он может решить проблему «последним пришел первым обслужен» в сети. Отправленные данные будут сортироваться в соответствии с порядковым номером, а затем по порядку использоваться программой прикладного уровня.
Как показано на рисунке выше, данные, поступающие в приемный буфер, будут отсортированы по порядковому номеру. Это не только решает проблему «последними отправлены — первыми пришли», но также решает проблему получения дублирующихся пакетов данных. на этот раз, если повторно переданный пакет данных будет получен с порядковым номером 500, он будет отброшен напрямую, поскольку минимальный порядковый номер буфера приема равен 1000, что означает, что 500 уже прочитано прикладной программой.
Потеря пакетов сама по себе является событием с небольшой вероятностью. Когда количество потерь пакетов увеличится, сеть станет большой проблемой. По мере увеличения количества повторных передач временной интервал между повторными передачами продолжает увеличиваться, поскольку большее количество повторных передач указывает на наличие проблемы в сети, а частые повторные передачи будут потреблять ресурсы. Когда количество повторных передач достигнет порогового значения, будет отправлено сообщение сброса с битом флага RST, установленным в 1, чтобы очистить промежуточное состояние обоих концов. Если на сообщение сброса не ответили, соединение на обоих концах будет удалено.
Повторная передача по тайм-ауту является дополнением к ответу-подтверждению.
Рисунок 5
Установление соединения означает, что обе взаимодействующие стороны сохраняют информацию другого конца. Для конкретного завершения требуется три сетевых взаимодействия, как показано на рисунке 5.
Первое трехстороннее рукопожатие должно быть инициировано клиентом. Тот, кто инициирует трехстороннее рукопожатие, является клиентом. Конкретный процесс показан на рисунке 5. Сначала клиент отправляет пакет SYN, то есть флаг SYN в заголовке устанавливается равным 1. Затем сервер возвращает ответный пакет. Флаги ACK и SYN ответного пакета равны. оба установлены в 1, поскольку ACK и SYN. Пакеты данных с битами флагов отправляются ядром операционной системы одновременно, поэтому их можно отправлять вместе для повышения производительности. Наконец, клиент отправляет ответный пакет на сервер, и трехстороннее рукопожатие завершается. Пакеты данных, передаваемые во время этого процесса, не содержат бизнес-данных.
Значение трехстороннего рукопожатия:
(1) Бросать камни, чтобы спросить дорогу.
Подтвердите, является ли связь гладкой
(2) Согласовать некоторые важные параметры
Например, порядковый номер передаваемого пакета данных
(3) Подтвердите возможности приема и отправки обеих сторон.
Почему три рукопожатия? Четыре рукопожатия или два — это нормально?
Хотя четырехстороннее подтверждение не повлияет на нормальные функции, оно снизит производительность. Двустороннее подтверждение не может полностью подтвердить возможности приема и отправки сервера.
Кроме того, здесь задействованы еще два важных состояния. Первое — это состояние прослушивания, что означает, что сервер в данный момент связал порт и ожидает отправки клиентом пакета SYN. Второе — установлено. легко понять и означает, что трехстороннее рукопожатие завершено. Состояние после установления соединения.
В отличие от трехэтапного рукопожатия, которое может быть инициировано только клиентом, и сервер, и клиент могут инициировать четырехэтапное рукопожатие.
Рисунок 6
Конкретный процесс четырехкратного махания показан на рисунке 6. Когда метод socket.close() вызывается в клиентском коде или когда процесс завершается, на сервер будет отправлено сообщение о завершении FIN. Сервер немедленно отправит сообщение. Сообщение ACK возвращается, но ему придется дождаться кода сервера. Только после вызова кода, такого как Socket.close(), клиенту может быть отправлено сообщение завершения FIN. После этого клиент отправляет сообщение ACK на сервер и процесс завершается четырехкратным взмахом руки.
ACK и FIN посередине здесь не могут быть объединены, поскольку ACK отправляется ядром системы, поэтому оно будет отправлено немедленно, когда сервер получит сообщение FIN, но сообщение FIN должно будет дождаться, пока код на стороне сервера выполняет сокет. Его можно отправить после close(), и между ними существует разница во времени. Но есть способ объединить эти два варианта. В особых случаях подтверждение ACK может отправляться с задержкой, чтобы его можно было отправлять вместе с FIN.
Кроме того, в четырех процессах отправки сообщений участвуют два состояния: первое — состояние close_wait. Это состояние, в котором находится получатель после получения сообщения FIN отправителя. Второе состояние — состояние time_wait. что сторона должна дождаться получения FIN, отправленного получателем, а затем отправить ACK получателю. Соединение не может быть разорвано немедленно, поскольку необходимо предотвратить потерю и потерю последнего ACK, отправленного отправителем получателю. получатель повторно передает FIN. Чтобы гарантировать, что отправитель все еще может получить этот FIN, время в этом состоянии обычно составляет 2MSI (MSI: максимальное время передачи данных на обоих концах), что обычно составляет 2 минуты.
Если на получателе обнаружено большое количество close_wait, это означает, что метод close() был забыт. Если на сервере обнаружено большое количество time_wait, это означает, что сервер инициировал большое количество активных отключений TCP. операции.
TCP необходимо обеспечить надежную передачу, но в то же время он также хочет, чтобы передача данных была максимально эффективной. Скользящее окно — это механизм повышения эффективности. На самом деле это способ компенсировать это, поскольку для обеспечения надежности TCP жертвует большой производительностью. Как бы вы ни сдвигали окно, скорость передачи данных не может быть выше, чем UDP.
Рисунок 7
Как показано на рисунке 7, это процесс передачи данных, но процесс отправки пакета данных и получения ответного пакета данных все еще относительно медленный.
Рисунок 8
Как показано на рисунке 8, это происходит после введения механизма скользящего окна. Вместо одновременной отправки одного пакета данных и нескольких пакетов данных время ожидания возвращаемых пакетов данных ответа перекрывается. Без ожидания ACK объем данных, отправляемых пакетами, равен размеру окна.
Рисунок 9
Процесс скользящего окна показан на рисунке 9. Предположим, что размер окна составляет 4 группы. Когда одна группа получает ACK, в дополнение к ней будут отправлены новые данные, что эквивалентно скользящему процессу. Если отправитель получает подтверждение 3001, это означает, что данные с 1001 по 3001 были получены, поэтому окно может переместиться на два пробела вправо.
Что делать, если в скользящем окне происходит потеря пакетов? Есть две ситуации:
(1) Отправленный пакет данных потерян.
Если определенная группа отправленных дейтаграмм утеряна, хотя вы отправляете получателю множество групп данных в пакетном режиме, порядковый номер подтверждения полученного ACK по-прежнему будет таким же, как и у потерянной группы, пока отправитель не передаст дейтаграмму повторно. Например, дейтаграммы 1001–2000 на рисунке выше теряются. Даже если позже будет передано несколько наборов данных, подтверждение 1001 будет возвращено до тех пор, пока отправитель не повторит передачу и получатель не получит его, а затем ответит подтверждением 7001. .
(2) Ответ ACK потерян.
Если ответный ACK потерян, вам не нужно об этом беспокоиться, потому что вы можете просто подождать, пока не будет возвращен ACK других групп данных. Например, если ACK 1001 на рисунке выше потерян, он потерян. не имеет значения. Отправитель следующего подтверждения 2001 года получил его. Предыдущие данные были получены, и то же самое происходит, если подтверждение последующих данных потеряно.
Вышеупомянутая обработка потери пакетов по-прежнему очень эффективна. Если пакет данных потерян, просто заполните пробел и повторно передайте данные. Если ACK потерян, просто проигнорируйте его. Такая операция называется быстрой повторной передачей.
Повторная передача по тайм-ауту и быстрая повторная передача — это разные стратегии, применяемые в разных средах. Если ваш TCP передает мало и нечасто данных, будет активирована повторная передача по тайм-ауту. Если вашему TCP необходимо передать большой объем данных за короткий период времени, появится скользящее окно. активируется быстрая повторная передача, быстрая повторная передача эквивалентна варианту повторной передачи по таймауту под скользящим окном.
Как упоминалось ранее о скользящем окне, размер окна является переменным. Вы можете контролировать скорость отправки отправителя, изменяя размер окна. Чем больше окно, тем больше данных отправляется в единицу времени и тем выше эффективность. Чем меньше окно, тем больше данных отправляется в единицу времени. Чем меньше данных, тем менее эффективно. Обычно, конечно, мы надеемся, что эффективность будет максимально высокой, но предпосылкой высокой эффективности является обеспечение надежности. Если отправитель отправляет слишком быстро, а получатель не может с этим справиться, то может произойти потеря пакетов. Более разумный подход. Получатель сообщает отправителю, что скорость отправки слишком высока. Это «управление потоком».
Как показано на рисунке выше, как упоминалось ранее, в ядре есть буфер приема структуры данных, и получатель вернет размер свободного места в буфере приема в качестве размера окна. Предыдущий заголовок TCP имеет 16-битное поле размера окна, которое использует ACK для сохранения и возврата этой информации. Поле размера окна вступит в силу только в ACK.
Как показано на рисунке выше, ACK вернет размер окна для достижения цели управления потоком. Когда размер окна возвращается к 0, отправитель будет периодически отправлять пробные сообщения, которые не содержат бизнес-данных, чтобы инициировать ACK, чтобы узнать. состояние буфера. Есть ли свободное место.
Управление перегрузкой очень похоже на управление потоком: оба механизма работают в паре со скользящими окнами.
Как показано на рисунке выше, ссылки в сети очень сложны, и любой узел ссылки может ограничивать скорость отправителя. Идея контроля перегрузки состоит в том, чтобы рассматривать ее как единое целое, какой бы сложной ни была ваша промежуточная структура, а затем путем экспериментов найти наиболее подходящий размер окна.
На рисунке выше показан процесс контроля перегрузки. Сначала попробуйте его с относительно небольшим размером окна (медленный старт), поскольку вы не знаете ситуацию с перегрузкой в сети. После этого размер окна будет расти в геометрической прогрессии, и когда он достигнет этого значения. определенного порога, оно начнет расти линейно, а затем, когда окно вырастет до определенной степени, происходит потеря пакетов. В это время окно сразу уменьшается. Есть два способа уменьшить размер.
(1) Непосредственно опуститесь вниз, вернитесь к началу медленного старта, а затем повторите предыдущий процесс (уже заброшенный)
(2) Сократиться вдвое, а затем линейно вырасти (используемый фактический метод)
Контроль перегрузки заключается в использовании экспериментов для поиска подходящего размера окна. Если происходит большая потеря пакетов, уменьшите размер окна. Если потерь пакетов нет, увеличьте размер окна.
Задержанный ответ, как следует из названия, означает некоторое ожидание перед возвратом ACK. На самом деле это также связано с проблемой размера окна, поскольку отложенный ответ ACK дает получателю больше времени для использования данных в буфере приема, тем самым увеличивая его. размер свободного буфера увеличивается, размер окна, возвращаемого ACK, и отправитель может отправлять больше данных пакетами.
Существует два метода отложенного ответа:
(1) Укажите задержку в зависимости от определенного времени
(2) В зависимости от объема полученных данных
Две вышеуказанные стратегии используются в сочетании.
Комбинированные ответы на самом деле появлялись и раньше как механизм, используемый для повышения эффективности передачи. Это тот случай, когда ACK и SYN возвращаются с использованием одного и того же пакета данных при трехстороннем подтверждении связи. Существует также ситуация, аналогичная той, что была в «Четырех волнах». Поскольку ACK и FIN отправляются в разное время, комбинированные ответы не могут быть сделаны. Однако при отложенном ответе ACK не нужно отправлять отправителю так быстро, и это происходит. могут быть объединены с двумя FIN. Вторичные передачи объединяются в одну передачу путем объединения ответов.
Ориентированный на поток байтов механизм TCP. Одной из проблем, на которую следует обратить внимание, является проблема прилипания пакетов. Эта проблема вызвана невозможностью различать границы между различными пакетами данных прикладного уровня. байтовый поток, сервер может прочитать несколько байтов, а также прочитать один байт, что может легко вызвать эту проблему.
Есть два решения описанной выше проблемы с липким пакетом:
(1) Используйте разделители
Можно использовать любой символ, если он не существует в пакете запроса.
(2) Согласуйте длину пакета данных.
Однако в большинстве случаев Java-программисты не используют TCP напрямую. Вместо этого они используют готовые протоколы, такие как http, или реализуют сетевую связь на основе таких инструментов, как protobuffer или dubbo. Эти методы решили проблему липких пакетов внутри. Потерянный.
(1) На обоих концах соединения произошел сбой процесса на одном конце.
Операционная система выполняет четыре волны и обрабатывает печатную плату.
(2) Определенный хост выключен (нормальный процесс).
Первая возможность заключается в том, что операционная система завершила четыре волны. Вторая возможность заключается в том, что получатель не имеет ответа ACK после отправки FIN. Он выполняет повторную передачу много раз, а затем в одностороннем порядке удаляет соединение. Что касается отправителя, он также является стороной. который отключается, так как все они отключены. Сохраненная информация (память) естественно исчезла.
(3) Питание определенного хоста отключено.
Когда выключенный хост является сервером, пакет данных, отправленный клиентом, будет повторно передан без ACK. Если после нескольких повторных передач не будет получен результат, соединение будет удалено.
Когда выключенный хост является клиентом и сервер не получает пакет данных в течение длительного времени, он будет периодически отправлять пакет пульса без полезной нагрузки, просто чтобы вызвать ACK. Если клиент в порядке, он вернется. ACK, иначе он его не получит. Если после многократной отправки ответа от клиента не получено, но ответа нет, можно считать, что клиент не работает, и информация о соединении удаляется.
Кроме того, хотя TCP реализует пакеты Heartbeat, цикл является длительным. Часто требуется несколько минут, чтобы определить, что клиент не работает через этот пакет Heartbeat. В реальной разработке пакеты Heartbeat будут реализованы на уровне приложения с более высокой частотой и более коротким периодом (отправляются пакеты Heartbeat второго уровня/миллисекундного уровня). A->B отправляет пинг, а B->A отвечает пингом. . После определенного случая зависания устройства можно быстро найти проблему.
(4) Сетевой кабель отсоединен.
По сути, это третий случай. Если отправитель не получает ACK, он истечет и повторит передачу, затем отправит RST, а затем в одностороннем порядке удалит соединение. Если получатель не получит пакет данных, он отправит контрольный пакет. Если он не получит ACK, он просто отправит контрольный пакет Удалить информацию.
В структуре заголовка TCP есть два бита флага, а именно PSH и URG. PSH призывает другую сторону вернуть ответ как можно скорее. URG связан с полем аварийного указателя заголовка пакета TCP и используется вместе для управления внеполосной передачей данных TCP.
Внеполосная передача данных означает, что помимо бизнес-данных существуют специальные пакеты данных, используемые для управления рабочим механизмом самого TCP.
Он посвятил себя исследованию технологий более 30 лет и владеет различными языками, такими как Java, Linux, Javascript, php, css и т. д. Он внес большой вклад в область открытого исходного кода. Станция документации для разработчиков, где можно поделиться некоторыми проблемами в разработке технологий для дальнейшего использования. Все ознакомьтесь.
Почтамезофия@protonmail.com