что такое TCP полуоткрытое соединение и TCP полуоткрытое соединение

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

Этот пост расширяется на полузакрытых соединениях. Для полуоткрытых соединений см. Правильное описание KContreau.

Что такое полузакрытые соединения? Или: это не ошибка - это особенность!

Каждое TCP-соединение состоит из двух половинных соединений, которые закрываются независимо друг от друга. Таким образом, если один конец отправляет FIN, то другой конец может просто подтвердить этот FIN (вместо FIN + ACK-его), который сигнализирует конечному отправляющему FIN, что у него все еще есть данные для отправки. Таким образом, оба конца оказываются в состоянии стабильной передачи данных, отличном от ESTABLISHED, а именно FIN_WAIT_2 (для принимающей стороны) и CLOSE_WAIT (для отправляющей стороны). Такое соединение называется полузакрытым, и TCP на самом деле предназначен для поддержки этих сценариев, поэтому полузакрытые соединения - это функция TCP.

История полузакрытой связи

В то время как RFC 793 описывает только необработанный механизм, даже не упоминая термин «полузакрытый», RFC 1122 подробно описывает этот вопрос в разделе 4.2.2.13. Вы можете задаться вопросом, кому, черт возьми, нужна эта функция. Разработчики TCP также реализовали TCP / IP для системы Unix и, как и любой пользователь Unix, любили перенаправление ввода / вывода. Согласно У. Стивенсу (проиллюстрирован TCP / IP, раздел 18.5), желание перенаправить потоки TCP ввода-вывода было мотивом для введения этой функции. Это позволяет FIN принимать роль или переводиться как EOF. Таким образом, это в основном функция, которая позволяет вам случайно создавать импровизированное взаимодействие типа запрос / ответ на уровне приложения, где FIN сигнализирует «конец запроса».

Когда TCP устанавливает соединение, это считается гарантированным, поскольку происходит рукопожатие:

1. Инициирующий компьютер отправляет запрос на соединение, отправляя SYN
2. Отвечающий компьютер удовлетворяет запрос, отвечая с SYN-ACK
3. Инициирующий компьютер отправляет подтверждение, отвечая ACK

В этот момент соединение установлено, и данные начинают поступать. В отличие от этого, UDP-пакет не гарантируется и просто отправляется в надежде получить его.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Официально, согласно RFC, полуоткрытое TCP-соединение - это когда одна сторона установленного соединения прервалась и не отправила уведомление о том, что соединение заканчивается. Это не обычное использование сегодня.

Неофициально, если можно сослаться на эмбриональную связь, которая является связью в процессе установления.

http://en.wikipedia.org/wiki/Embryonic_connection

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

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

В интернете есть аргументы относительно того, что должна представлять терминология «полуоткрытая» или «полузакрытая», но, насколько я понимаю, терминология просто семантическая. Некоторые говорят, что «полуоткрытые» соединения - это «проблема», в то время как «полузакрытые» являются конструктивной особенностью, которая позволяет вам закрыть поток отправки, закрыв поток отправки до того, как загрузка файла завершится в полузакрытом состоянии ( как описали другие пользователи).

Однако, что касается другой ... «проблемы»: для открытия TCP-соединения требуется 3-х стороннее рукопожатие и 4-х стороннее рукопожатие для его закрытия.

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

Операционные системы предпринимают попытки противостоять полуоткрытым атакам DDoS, ограничивая количество полуоткрытых / закрытых соединений, которые могут присутствовать в операционной системе в данный момент времени, и вводя максимальные промежутки времени, в течение которых соединения могут оставаться в полуоткрытое / закрытое состояние. Последнее, что я проверял, лично, однако, ограничение времени для Windows было довольно высоким (2 дня, если я помню).

Это условие дополнительно усугубляется необязательным характером средств поддержки активности TCP, которые, если они полностью реализованы, предназначались в качестве решения на уровне протокола (в отличие от уровня приложения) для обнаружения мертвых / зомби-соединений. Но когда разрабатывался протокол TCP, пропускная способность была значительно более ценной, чем сейчас, и были опасения, что таймеры обязательного поддержания активности для TCP будут слишком «болтливыми». Поэтому keep-alive является необязательным, обычно не используется и не гарантируется, что он будет передаваться маршрутизаторами в соответствии с RFC1122. Так что ... даже если вы включите keep-alive на уровне TCP в попытке обнаружить / обработать сценарий, вы можете обнаружить, что по мере движения вашего трафика по всему миру некоторые маршрутизаторы отбрасывают пакеты keep-alive ... создавая потенциально ДРУГОЙ редкий сценарий для тестирования.

Полуоткрытые соединения представляют собой небольшую инженерную проблему для программистов, которые пишут серверы на основе TCP, в частности, потому что они могут непреднамеренно появляться случайным образом, во время высокой нагрузки ... и, как правило, на производственных серверах ... и могут быть трудно заметить на этапах альфа / бета-тестирования. Исходя из моего опыта, я обнаружил, что они встречаются, может быть, в 1 из 40 000 подключений на серверах, обрабатывающих 2,5 миллиона подключений в день, но эти числа будут различаться в зависимости от условий вашего трафика и условий трафика на каждом участке Интернета между вашим сервером и клиентом. ,

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

Без 100% жизнеспособного решения для поддержки TCP TCP оставляет на уровне пользователя возможность определять, как обрабатываются полуоткрытые / закрытые соединения, поэтому у вашего кода должен быть план / механизм для обнаружения, тайм-аута и очистки. ресурсов, когда возникает это условие ... то есть ... при условии, что это придуманный вами протокол, а не один из многих (плохих) открытых стандартов, которые обычно используют программисты. Конечно, я имею в виду такие протоколы, как HTTP, которые работают исключительно по TCP. Эти протоколы чрезвычайно переоценены по мнению этого программиста.

Признавая слабые стороны TCP и его прискорбную популярность для передачи HTTP / веб-трафика, умные компании пытались найти замену. Например, Google экспериментировал с протоколом под названием QUIC, который передает HTTP по UDP. Существует также открытый протокол под названием TSCP. Однако ни один из этих протоколов не получил широкого распространения.

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

Лучшее объяснение прекращения TCP соединения

В TCP 3-way Handshake Process мы изучили, как установить соединение между клиентом и сервером в протоколе управления передачей (TCP) с использованием битовых сегментов SYN. В этой статье мы рассмотрим, как TCP закрывает соединение между клиентом и сервером. Здесь нам также необходимо отправить битовые сегменты на сервер, для которого бит FIN установлен в 1.

11

Как работает механизм в TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

больше о: https://www.geeksforgeeks.org/tcp-connection-termination/

Половинное закрытое соединение - это процесс, который устанавливается, когда один конец сервера и Клиент намерены разорвать соединение. TCP - это процесс, ориентированный на установление соединения, поэтому каждый сокет открывается для определенного приложения. В TCP нет давления для завершения приложения. Таким образом, процесс, ориентированный на соединение, продлевает завершение сигналами ожидания. это называется полузакрытым в TCP (соединение)