Вопрос о трехстороннем рукопожатии TCP и четырехсторонней волне — один из самых распространенных контрольных вопросов на собеседованиях. Многие читатели знают три и четыре раза, но если спросить немного глубже, они часто не могут дать точного ответа.
В этой статье делается попытка использовать анимацию для объяснения этого факта, надеясь, что читатели смогут легче понять природу взаимодействия TCP.
TCP/IP расшифровывается как Transmission Control Protocol/Internet Protocol и относится к серии протоколов.
Можно разделить на четыре уровня:
-
1. Канальный уровень, сетевой уровень, транспортный уровень и прикладной уровень.
-
2. На сетевом уровне: есть протокол IP, протокол ICMP, протокол ARP, протокол RARP и протокол BOOTP.
-
3. На транспортном уровне: есть протокол TCP и протокол UDP.
-
4. На прикладном уровне: есть FTP, HTTP, TELNET, SMTP, DNS и другие протоколы.
TCP и UDP используют протокол IP для передачи пакетов из одной сети в другую. Думайте об IP как о своего рода магистрали, которая позволяет другим протоколам проезжать по ней и находить выходы к другим компьютерам. TCP и UDP — это «грузовики» на шоссе, а груз, который они перевозят, — это такие протоколы, как HTTP, протокол передачи файлов FTP и т. д.
TCP и UDP — это протоколы транспортного уровня, используемые такими протоколами, как FTP, HTTP и SMTP. Хотя и TCP, и UDP используются для передачи других протоколов, у них есть одно существенное отличие: TCP обеспечивает гарантированную передачу данных, а UDP — нет. Это означает, что TCP имеет специальный механизм, обеспечивающий безошибочную передачу данных от одной конечной точки к другой, в то время как UDP не предоставляет такой гарантии.
Трехстороннее рукопожатие TCP
Трехстороннее рукопожатие TCP похоже на то, как два человека видят друг друга на расстоянии 50 метров друг от друга на улице, но они не могут быть подтверждены на 100% из-за смога и других причин, поэтому они должны подзывать друг друга, чтобы определить, знает ли их другая сторона.
обнять друг друга
Всего в этом процессе мы увидели четыре движения: махание рукой — кивание и улыбка — подзыв — кивание и улыбка. Среди них последовательно выполняются два действия, сначала кивок и улыбка (ответ собеседнику), а затем снова махание рукой (иск подтверждения).На самом деле эти два действия можно объединить в одно, кивок и улыбку (син. +ack) во время подзыва. Таким образом, четыре действия сводятся к трем действиям, помашите — кивните и улыбнитесь и помашите — кивните и улыбнитесь. В этом суть трехэтапного рукопожатия, где одно действие посередине представляет собой слияние двух действий.
Мы видим, что есть два промежуточных состояния, syn_sent и syn_rcvd.Эти два состояния называются «полуоткрытые» состояния, то есть они машут другой стороне, но не успели увидеть кивок и улыбку другой стороны. . syn_sent — это «полуоткрытое» состояние активного открывателя, а syn_rcvd — это «полуоткрытое» состояние пассивного открывателя. Клиент является активным открывателем, а сервер — пассивным открывателем.
-
syn_sent: syn package has been sent
-
syn_rcvd: syn package has been received
Передача данных TCP
Передача данных TCP — это разговор между двумя людьми в воздухе, на небольшом расстоянии, поэтому другой стороне необходимо неоднократно подтверждать, что они слышали свои собственные слова.
Клиент выкрикивает предложение (данные), и получатель ответит, услышав его (подтверждение).
Если вы кричите фразу и долго не слышите ответа собеседника, вы думаете, что ваши слова унесло сильным ветром, и вы его не слышите, поэтому вам нужно кричать еще раз, что является ретрансляцией tcp .
Также возможно, что сервер услышал слова клиента, но ответ сервера клиенту унесло ветром, так что клиент не услышал ответа сервера. Клиент не может определить, унесло ли его собственные слова сильным ветром или ответ сервера унесло сильным ветром, клиенту все равно, просто ретранслируйте его.
Клиент может кричать серверу, и сервер тоже может кричать клиенту, поскольку tcp-ссылка является «дуплексной», обе стороны могут активно инициировать передачу данных. Однако независимо от того, какая сторона звонит, ей необходимо получить подтверждение от другой стороны, чтобы считать, что другая сторона получила свой собственный вызов.
Клиент может быть зениткой.Он сказал восемь предложений подряд.В это время сервер не может отвечать предложение за предложением,но выслушав эти восемь предложений подряд,ответьте собеседнику вместе и скажите что я услышал все восемь предложений, которые вы сказали ранее. , что является пакетным подтверждением. Но клиент не может говорить слишком много за один раз. Мозг сервера может быть не в состоянии переварить слишком много за короткое время. Два человека должны согласовать соответствующую скорость отправки и получения. Это «размер окна TCP». ".
Сводка по трем TCP-соединениям
(1**) Первое рукопожатие: ** При установлении соединения клиент A отправляет SYN-пакет (SYN=j) на сервер B и переходит в состояние SYN_SEND, ожидая подтверждения от сервера B.
**(2) Второе рукопожатие: **Сервер B получает пакет SYN и должен подтвердить SYN клиента A (ACK=j+1), а также отправляет пакет SYN (SYN=k), т.е. SYN+ACK. момент, сервер B входит в состояние SYN_RECV.
**(3) Третье рукопожатие: **Клиент A получает пакет SYN+ACK от сервера B и отправляет пакет подтверждения ACK (ACK=k+1) на сервер B. После отправки пакета клиент A и сервер B войдите в состояние ESTABLISHED, завершите трехстороннее рукопожатие.
После завершения трехэтапного рукопожатия клиент и сервер начинают передавать данные.
ПТС махнул четыре раза
Процесс отключения TCP-соединения аналогичен процессу установления соединения, за исключением того, что две части посередине не всегда объединяются в один шаг, поэтому он разбит на 4 действия, Клиент машет (плавник) - Сервер грустно улыбается (ack ) — Сервер машет (fin) — Клиент грустно улыбается (ack).
Причина, по которой два действия в середине не объединены, заключается в том, что tcp имеет «полузакрытое» состояние, то есть одностороннее отключение. Клиент махнул рукой, но человек не ушел, он просто больше не говорит, но его уши могут продолжать слушать, а официант продолжает кричать. Дождавшись, пока сервер устанет и перестанет говорить, суперклиент махнул рукой, а клиент грустно улыбнулся, и на этом все закончилось.
Выше есть особое состояние time_wait, которое является долговременным состоянием, в которое входит сторона, которая активно закрылась после ответа на волну другой стороны.Стандартная продолжительность этого состояния составляет 4 минуты, и оно войдет в закрытое состояние через 4 минуты. минут, выпуская рукав. Доступ к ресурсам. Однако это время может быть скорректировано в конкретной реализации.
Это похоже на ответственность стороны, которая взяла на себя инициативу расстаться, это вы предложили расстаться, и вы должны заплатить цену. Следствием этого является состояние time_wait, которое длится 4 минуты, и ресурсы сокета (порты) не могут быть освобождены, как и период вдовства, в течение которого ресурсы сокета (порты) не могут быть перезапущены.
Его функция заключается в повторной передаче последнего сообщения подтверждения, чтобы убедиться, что другая сторона может его получить. Потому что, если другая сторона не получит подтверждение, сообщение fin будет передано повторно, и сокет в состоянии time_wait немедленно повторно передаст сообщение подтверждения другой стороне.
В то же время, в течение этого периода времени остаточные пакеты, генерируемые ссылкой в Интернете, маршрутизируются во время диалога (поскольку путь слишком труден, пакеты данных слишком долго путешествуют, все повторно переданные пакеты принимаются, и исходные пакеты все еще находятся в пути), они будут немедленно отброшены. 4 минут достаточно, чтобы эти остаточные пакеты полностью исчезли. В противном случае при повторном использовании нового порта эти остаточные пакеты могут мешать новому каналу.
4 минуты — это 2 MSL, каждый MSL — 2 минуты. MSL — это максимальное время жизни сегмента — максимальное время жизни сообщения. Это время указано в официальном протоколе RFC. Что касается того, почему есть 2 MSL вместо 1, я не видел очень удовлетворительного объяснения.
Четыре раза махать не всегда четыре раза. Иногда два действия в середине можно комбинировать и выполнять вместе. В это время это становится три раза махания, и активная закрывающая сторона напрямую переходит в состояние time_wait из состояния fin_wait_1. , пропустите состояние fin_wait_2.
Краткое изложение четырех распадов TCP
Поскольку соединения TCP являются полнодуплексными, каждое направление должно быть закрыто отдельно. Принцип заключается в том, что когда сторона завершает свою задачу по передаче данных, она может отправить FIN для разрыва соединения в этом направлении. Получение FIN означает только то, что в этом направлении нет потока данных, TCP-соединение все еще может отправлять данные после получения FIN. Сторона, которая выключится первой, выполнит активное выключение, а другая сторона выполнит пассивное выключение.
-
**Клиент A отправляет FIN, ** используемый для закрытия передачи данных от клиента A к серверу B (сегмент 4).
-
Сервер B получает этот FIN, который отправляет обратно ACK, подтверждающий, что порядковый номер равен полученному порядковому номеру плюс 1 (сегмент 5). Как и SYN, FIN занимает порядковый номер.
-
Сервер B закрывает соединение с клиентом A, отправьте FIN клиенту А (сегмент 6).
-
Клиент A отправляет обратно сообщение ACK для подтверждения, и установите порядковый номер подтверждения равным полученному порядковому номеру плюс 1 (сегмент 7).
Суммировать
Смена состояния TCP — очень сложный процесс, и в этой статье по аналогии объясняются лишь некоторые простые базовые моменты. Дополнительные знания о TCP также требуют от читателей поиска соответствующих технических статей для углубленного изучения. Если читатель хорошо разбирается в базовых знаниях TCP, продвинутые знания не будут слишком сложными для понимания.
Пополнить
Недавно, когда я проходил собеседование в качестве интервьюера, я обнаружил, что у многих людей есть сильные фреймворки, но основа Java немного слаба.Многие дети не очень хорошо понимают концепции HTTP, TCP, UDP и SOCKET, и они тупо непонятно.Здесь еще коротко упомянем
HTTP сам по себе является протоколом, транспортным протоколом для передачи гипертекста с веб-сервера в локальный браузер.
HTTP (протокол передачи гипертекста) — это протокол, который использует TCP для передачи информации между двумя компьютерами (обычно веб-сервером и клиентом). Клиент использует веб-браузер для инициирования HTTP-запроса к веб-серверу, и веб-сервер отправляет запрошенную информацию клиенту.
Протокол HTTP построен на модели запрос/ответ. Сначала клиент устанавливает TCP-соединение с сервером и отправляет серверу запрос, содержащий метод запроса, URL-адрес, версию протокола и соответствующие сообщения в стиле MIME. Сервер отвечает строкой состояния, содержащей версию протокола сообщения, код успеха и ошибки, а также соответствующее сообщение в стиле MIME.
HTTP/1.0 устанавливает новое TCP-соединение для каждого HTTP-запроса/ответа, поэтому страница, содержащая HTML-контент и изображения, должна будет установить несколько краткосрочных TCP-соединений. Для установления TCP-соединения потребуется 3 рукопожатия.
Кроме того, чтобы получить надлежащую скорость передачи, протокол TCP должен тратить дополнительное время соединения туда и обратно (RTT). Установление каждой ссылки требует такого рода повторяющихся накладных расходов, и это не несет реальных полезных данных, а только обеспечивает надежность ссылки Поэтому HTTP/1.1 предлагает метод реализации устойчивой связи. HTTP/1.1 устанавливает TCP-соединение только один раз и повторно использует его для передачи серии сообщений запроса/ответа.
Таким образом, количество установленных ссылок и повторяющиеся накладные расходы на ссылки уменьшаются.
Хотя HTTP сам по себе является протоколом, в конечном итоге он основан на TCP.
SOCKET: API для сетей TCP/IP.
Сокет — это связь между прикладным уровнем и набором протоколов TCP/IP.слой абстракции промежуточного программного обеспечения,этонабор интерфейсов. В режиме проектирования Socket фактически является фасадным режимом. Он скрывает сложное семейство протоколов TCP/IP за интерфейсом Socket. Пользователям достаточно набора простых интерфейсов. Пусть Socket организует данные в соответствии с указанными требования протокол.
Интерфейс Socket — это API сети TCP/IP.Интерфейс Socket определяет множество функций или подпрограмм для разработки приложений в сети TCP/IP.
Это коммуникационный конвейер, созданный для реализации вышеуказанного коммуникационного процесса. Его реальным представителем является коммуникационный процесс между клиентом и сервером. Два процесса взаимодействуют через сокеты, а правила связи принимают указанный протокол. Socket - это просто режим соединения, а не протокол, tcp, udp, просто (хотя и не точно) - это два самых основных протокола, многие другие протоколы основаны на этих двух протоколах, например,httpОн основан на tcp, а сокеты могут использоваться для создания tcp-соединений и udp-соединений**, что означает, что сокеты могут использоваться для создания соединений любого протокола, потому что на этом основаны другие протоколы.
**Подводя итог:** IP-протокол необходим для подключения к сети; TCP — это механизм, который позволяет нам безопасно передавать данные, а HTTP, который использует протокол TCP для передачи данных, — это специальный протокол, используемый веб-серверами. и клиенты. HTTP основан на протоколе TCP, но может использовать сокеты для установления соединения TCP.
больше ссылок
Приложение является синглтоном в Android, верно?
Android-приложение для похудения по новой осанке - Android App Bundle
Наконец, если вас больше интересуют технологии, обратите внимание на мой публичный аккаунт в WeChat: Terminal R&D Department, id: codeGooger, давайте продвигать технологии вместе.