Я просматривал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статуса сокета вам все равно понадобится четыре пакета (рукопожатие, а затем данные в каждом случае). Я не знаю, как они сокращают количество до трех, и как это обеспечивает значимое улучшение.
Итак, мой вопрос в следующем: это просто устаревшая опция или у нее есть реальный вариант использования?
решение1
(подводя итог моим комментариям по ОП)
Трехстороннее рукопожатие, о котором они говорят, является частью установления TCP-соединения, рассматриваемая опция не относится конкретно к этому. Также обратите внимание, что обмен данными не является частью трехстороннего рукопожатия, это просто создает TCP-соединение в открытом/установленном состоянии.
Что касается наличия этой опции, то это не является традиционным поведением сокета. Обычно поток обработчика сокета пробуждается, когда соединение принимается (что происходит после завершения трехстороннего рукопожатия), и для некоторых протоколов активность начинается именно здесь (например, SMTP-сервер отправляет строку приветствия 220), но для HTTP первым сообщением в диалоге является отправка веб-браузером своей строки GET/POST/etc, и пока этого не произойдет, HTTP-сервер не заинтересован в соединении (кроме тайм-аута). Таким образом, пробуждение процесса HTTP после завершения приема сокета является бесполезной деятельностью, поскольку процесс немедленно снова заснет в ожидании необходимых данных.
Хотя, конечно, есть аргумент, что пробуждение бездействующих процессов может сделать их «готовыми» к дальнейшей обработке (я особенно помню, как пробуждал терминалы входа в систему на очень старых машинах и заставлял их подключаться из подкачки), но вы также можете утверждать, что любая машина, которая выгрузила указанный процесс, уже предъявляет требования к его ресурсам, а дальнейшие ненужные требования могут в целом снизить производительность системы — даже если кажущаяся производительность вашего отдельного потока улучшится (чего может и не быть, поскольку у чрезвычайно загруженной машины возникнут узкие места в дисковом вводе-выводе, что замедлит другие процессы, если вы подкачаете, а если она настолько загружена, то немедленный переход в спящий режим может сразу же выгрузить его обратно). Кажется, что это азартная игра, и в конечном итоге «жадная» игра не обязательно окупится на загруженной машине и, безусловно, приведет к дополнительной ненужной работе на машине, на которой процесс уже был подкачен. Ваш подход оптимизируется для машины с большим набором памяти процессов, которые в основном находятся в состоянии покоя, и подмена одного состояния покоя другим не представляет большой проблемы. Однако машина с большим набором памяти активных процессов будет страдать от дополнительного ввода-вывода, и страдает любая машина, не ограниченная памятью, любая машина, ограниченная в ресурсах ЦП, будет в худшем положении.
Мой общий совет относительно этого уровня настройки производительности — не принимать программных решений о том, что лучше всего, а позволить системному администратору и операционной системе работать вместе, чтобы решать проблемы управления ресурсами — это их работа, и они гораздо лучше подходят для понимания рабочих нагрузок всей системы и за ее пределами. Дайте варианты и выбор конфигурации.
Если отвечать конкретно на вопрос, то эта опция полезна для всех конфигураций, не до такой степени, которую вы когда-либо, вероятно, заметите, за исключением случаев экстремальной нагрузки HTTP-трафика, но теоретически это «правильный» способ сделать это. Это опция, потому что не все разновидности Unix (даже не все Linux) имеют такую возможность, и поэтому для переносимости ее можно настроить так, чтобы она не была включена.
решение2
Я не совсем понимаю, в чем преимущество ожидания завершения трехстороннего рукопожатия.
Трехстороннее рукопожатие — распространенный протокол в голосовой телефонии:
- Сервер: «Добрый день, Epiphyte Corp.»
- Звонящий: «Привет, это Рэнди».
- Сервер: «Да, чем я могу вам помочь?»
- Звонящий:тело звонка начинается с запроса шутки
Они важны в TCP для обеспечения того, что канал установлен. Если клиент начал отправлятьтело вызовадо прослушивания (3) есть вероятность, что Сервер не слушает или не готов. Прослушивание (3) не гарантирует, что Сервер не подвергся немедленному самовозгоранию после передачи, но это увеличивает уверенность в том, что Сервер готов к приему.
Как отмечено вВикипедия о рукопожатии:
- Алиса [Сервер] отвечает подтверждающим сообщением с номером подтверждения y + 1, которое получает Боб [Клиент] ина которые ему не нужно отвечать.
Так что если вы готовы отказаться от небольшой дополнительной уверенности в том, что сервер готов, Server может пропустить шаг (3), и клиент просто предположит, что сервер готов. Это превращает протокольный обмен выше в:
- Сервер: «Добрый день, Epiphyte Corp.»
- Звонящий: «Привет, это Рэнди».
- Звонящий: «Знаете ли вы какие-нибудь анекдоты об Имельде Маркос?»