Я пытаюсь понять, в чем разница между полуоткрытым соединением TCP и полуоткрытым соединением TCP. Кто-нибудь может сказать, что именно они?
13
4 ответа
20
Этот пост расширяется на полузакрытых соединениях. Для полуоткрытых соединений см. Правильное описание 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 сигнализирует "конец запроса".
7
Когда TCP устанавливает соединение, это считается гарантированным, поскольку происходит рукопожатие:
- Инициирующий компьютер отправляет запрос на соединение, отправляя SYN
- Отвечающий компьютер удовлетворяет запрос, отвечая с SYN-ACK
- Инициирующий компьютер отправляет подтверждение, отвечая ACK
В этот момент соединение установлено, и данные начинают поступать. В отличие от этого, UDP-пакет не гарантируется и просто отправляется в надежде получить его.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment
Официально, согласно RFC, полуоткрытое TCP-соединение - это когда одна сторона установленного соединения прервалась и не отправила уведомление о том, что соединение заканчивается. Это не обычное использование сегодня.
Неофициально, если можно сослаться на эмбриональную связь, которая является связью в процессе установления.
Полузакрытый является противоположностью этого неофициального определения. Это состояние где-то посередине, когда компьютеры разрушают установленное соединение.
6
Остальные ребята проделали довольно приличную работу по описанию , что полуоткрытые и полузакрытые соединения на самом деле, но идея полуоткрытых соединений также часто искали в контексте их быть проблемой.
В интернете есть аргументы относительно того, что должна представлять терминология "полуоткрытый" или "полузакрытый", но, насколько я понимаю, терминология просто семантическая. Некоторые говорят, что "полуоткрытые" соединения представляют собой "проблему", в то время как "полузакрытые" являются конструктивной особенностью, которая позволяет закрыть поток отправки, закрыв поток отправки до того, как загрузка файла завершится в полузакрытом состоянии ( как описали другие пользователи).
Однако, что касается другой ... "проблемы": для открытия TCP-соединения требуется трехстороннее рукопожатие и четырехстороннее рукопожатие для его закрытия.
У 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 сложнее, чем вы думаете, и я чувствую, что я всегда настраиваю его так, чтобы он был быстрее, умнее, с меньшими задержками, с меньшими заторами ... но, по крайней мере, мне больше не нужно иметь дело с полуоткрытыми соединениями;)
-1
Половинное закрытое соединение - это процесс, который устанавливается, когда один конец сервера и Клиент намерены разорвать соединение. TCP - это процесс, ориентированный на установление соединения, поэтому каждый сокет открывается для определенного приложения. В TCP нет давления для завершения приложения. Таким образом, процесс, ориентированный на соединение, продлевает завершение сигналами ожидания. это называется полузакрытым в TCP (соединение)