Реальное использование TCP_DEFER_ACCEPT?

Я просматривал руководство по Apache httpd онлайн и наткнулся на директиву для включения этого. Нашел описание в справочной странице для tcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

Потом я нашел эту статью, но мне все еще неясно, для каких рабочих нагрузок это будет полезно. Я предполагаю, что если httpdесть опция специально для этого, она должна иметь отношение к веб-серверам. Я также предполагаю из того факта, что это вариант, а не только как httpdсетевые подключения, что есть варианты использования, где вы хотите, и другие, где вы этого не делаете.

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

Что касается статьи, мне также кажется, что независимо от TCP_DEFER_ACCEPTсостояния сокета, вам все равно понадобится четыре пакета (рукопожатие, затем данные в каждом случае). Я не знаю, как они уменьшают счет до трех, и как это обеспечивает значимое улучшение.

Итак, мой вопрос в основном: это просто старая устаревшая опция или есть реальная возможность использования этой опции?

(чтобы суммировать мои комментарии на ФП)

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

Что касается существования этой опции, это не традиционное поведение сокета, обычно поток обработчика сокета просыпается, когда соединение принято (что происходит после завершения трехстороннего рукопожатия), и для некоторых протоколов начинается действие здесь ( например, SMTP-сервер отправляет строку приветствия 220), но для HTTP первое сообщение в диалоге - это веб-браузер, отправляющий свою строку GET / POST / etc, и до тех пор, пока это не произойдет, HTTP-сервер не будет интересоваться соединением (кроме синхронизации). это), поэтому пробуждение процесса HTTP после завершения приема сокета является расточительным занятием, так как процесс сразу же снова заснет в ожидании необходимых данных.

Хотя, безусловно, есть аргумент, что пробуждение незанятых процессов может сделать их «готовыми» для дальнейшей обработки (я особенно помню, как разбудил терминалы входа в систему на очень старых машинах и заставил их загружаться из swap), но вы также можете утверждать, что любая машина, которая Выключенный упомянутый процесс уже предъявляет требования к своим ресурсам, и выполнение дополнительных ненужных требований может в целом снизить производительность системы - даже если улучшится кажущаяся производительность вашего отдельного потока (чего также может и не быть, у очень занятой машины будут узкие места на дисковых операциях ввода-вывода, которые могут замедлите другие вещи, если вы поменялись местами, и если он так занят, немедленный сон может поменять его обратно). Это похоже на игру, и в конечном итоге «жадная» игра не обязательно окупается на занятой машине,

Мой общий совет в отношении этого уровня настройки производительности заключается в том, чтобы не принимать программных решений о том, что лучше в любом случае, а позволить системному администратору и операционной системе работать вместе для решения проблем управления ресурсами - это их работа, и они очень лучше подходит для понимания рабочих нагрузок всей системы и за ее пределами. Дайте варианты и варианты конфигурации.

Чтобы конкретно ответить на вопрос, эта опция полезна для всех конфигураций, не до того уровня, который вы когда-либо заметили бы, за исключением чрезмерной нагрузки HTTP-трафика, но теоретически это «правильный» способ сделать это. Это вариант, потому что не все версии Unix (даже не все Linux) имеют такую ​​возможность, и, следовательно, для переносимости их можно настроить так, чтобы они не были включены.

Мне неясно, каким будет преимущество ожидания завершения трехстороннего рукопожатия.

Трехсторонние рукопожатия являются распространенным протоколом в голосовой телефонии:

1. Сервер : «Добрый день, Epiphyte Corp.»
2. Абонент : «Привет, это Рэнди».
3. Сервер : «Да, чем я могу вам помочь?»
4. Звонящий : тело звонка начинает просить шутку

Они важны в TCP для обеспечения того, что канал установлен. Если Клиент начал посылать тело звонка до как услышал (3), есть вероятность, что Сервер не прослушивает или не готов. Слушание (3) не гарантирует, что Сервер сразу же не перенес самовозгорание после передачи, но повышает уверенность в том, что Сервер готов к приему.

Как отмечено в Википедии о рукопожатии :

1. Алиса [Сервер] отвечает сообщением подтверждения с номером подтверждения y + 1, которое получает Боб [Клиент] и на которое ему не нужно отвечать .

Поэтому, если вы готовы отказаться от некоторой дополнительной уверенности в том, что сервер готов, сервер может пропустить шаг (3), и клиент просто предположит, что сервер был готов. Это превращает протокол обмена выше в:

1. Сервер : «Добрый день, Epiphyte Corp.»
2. Абонент : «Привет, это Рэнди».
3. Звонящий : «Ты знаешь какие-нибудь анекдоты про Имельду Маркоса?»