Отклонение соединения TCP, прежде чем это будет принято?
1) в Linux это - функция Вашей настольной среды, а не самой OS.
2) GNOME и KDE имеют различные методы для выполнения этого.
3) нет ничего мешающего Вам делать его оба пути.
2 ответа
Когда соединение установлено, удаленная сторона отправляет пакет с установленным флагом SYN . Сервер отвечает пакетом SYN, ACK , и после этого удаленная сторона отправляет пакет ACK , который может уже содержать данные.
Есть два способа разорвать TCP соединение от формирования. Первый - это сброс соединения - это то же самое, что и обычное сообщение «соединение отклонено», которое появляется при подключении к порту, который никто не слушает. В этом случае, на исходный пакет SYN отвечает пакет RST , который немедленно завершает соединение и не имеет состояния. Если SYN отправляется повторно, RST будет генерироваться из каждого полученного пакета SYN .
Второй закрывает соединение, как только оно было сформировано . На уровне TCP нет возможности немедленно закрыть соединение в обоих направлениях - единственное, что вы можете сказать, это: «Я не собираюсь больше отправлять данные». Это происходит так, что по завершении первоначального обмена SYN , SYN, ACK , ACK сервер отправляет пакет FIN на удаленный конец. В большинстве случаев сообщение другому концу с помощью FIN , что «Я больше не собираюсь отправлять данные» заставляет другой конец также закрыть соединение и отправить свой собственный пакет FIN . Соединение, прерванное таким образом, ничем не отличается от обычного соединения, когда по какой-то причине данные не были отправлены. Это означает, что отслеживание нормального состояния для TCP-соединений и сохраняющиеся закрытые состояния будут сохраняться, как и для обычных соединений.
Теперь, на стороне C API, это выглядит немного иначе. При вызове listen () на порту ОС начинает принимать соединения на этом порту. Это означает, что он начинает отвечать на пакеты SYN, ACK на соединения, независимо от того, вызвал ли код C accept () . Таким образом, на стороне TCP не имеет значения, закрывается ли соединение до или после подтверждения. Единственная дополнительная проблема заключается в том, что у прослушивающего сокета есть отставание, что означает количество неприемлемых соединений, которые он может ожидать, прежде чем он начнет сообщать RST удаленному концу.
Однако в Windows вызов SO_CONDITIONAL_ACCEPT позволяет приложению взять под контроль очередь невыполненных работ. Это означает, что сервер не ответит ни на что на пакет SYN , пока приложение не сделает что-нибудь с соединением. Это означает, что отклонение соединений на этом уровне может фактически отправить RST пакетов в сеть без создания состояния.
Итак, если вы не можете каким-либо образом включить функциональность SO_CONDITIONAL_ACCEPT в сокете если вы используете AcceptEx , он будет отображаться в сети иначе. Однако, не во многих местах на самом деле используется непосредственная функциональность RST , поэтому я думаю, что требование для этого должно означать действительно очень специализированную систему. В большинстве случаев нормальным является принятие сокета и его закрытие.
I can't comment on the Windows side of things but as far as TCP is concerned, rejecting a connection is a bit different than disconnecting from it.
For one, disconnecting from a connection means there were more resources already "consumed" (e.g. ports state maintained in Firewalls & end-points, forwarding capacity used in switches/routers etc.) in both the network and the hosts. Rejecting a connection is less resource intensive.