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

15

Я просматривал руководство по 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состояния сокета, вам все равно понадобится четыре пакета (рукопожатие, затем данные в каждом случае). Я не знаю, как они уменьшают счет до трех, и как это обеспечивает значимое улучшение.

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

Bratchley
источник
Я не понимаю, что вы имеете в виду под «уменьшить счет до трех», что заставляет меня подозревать, что вы неправильно поняли трехстороннее рукопожатие. Это транзакция TCP "открытое соединение" и состоит из 3 переданных пакетов. До тех пор, пока эти 3 не будут завершены, нет данных и нет действующего соединения. Поскольку такие данные никогда не влияют на затраты на рукопожатие. Повышение эффективности, которое будет достигнуто за счет TCP_DEFER_ACCEPT, станет разрывом между завершением трехстороннего рукопожатия «принять» и первым пакетом данных (я полагаю, в основном здесь, чтобы прокомментировать рукопожатие 3 против 4)
iain
Кроме того, речь идет не о том, чтобы избежать «обмена», а о том, чтобы не тратить ресурсы. Если обмен должен был стать фактором активизации работника HTTP, то вы заставляете своего работника преждевременно обмениваться в точке принятия до того, как данные будут готовы ... и если обмен происходит, это означает, что вы вытесняете что-то еще из ram ... что-то, что, возможно, что-то делало и переставлялось обратно между вашей частью accept / data ... каким бы ни был ресурс - CPU, diskIO, встроенные страницы, если нет данных, то нет смысла вызывать работу.
13
Если рабочий процесс уже находится в памяти, разве это не довольно низкая задержка по сравнению с возможным переходом на диск? «До трех» - это ссылка на статью, в которой говорится, что каким-то образом это могло бы сделать так, чтобы первый пакет данных от клиента был в третьем пакете.
Братчли
Кроме того, теоретическая замена произойдет в любом случае, это не изменится с этой опцией TCP. Я не понимаю, как выгодно сократить разрыв в формировании TCP-соединения и использовать его при передаче данных. По крайней мере, когда вы делаете это во время формирования TCP-соединения, существует вероятность того, что они будут происходить параллельно (уменьшая количество времени).
Братчли
Надо было просто написать ответ ... Что касается того, что это вариант, ну, это не то, как работают "нормальные" стандарты Unix ... В частности, в отношении HTTP ключевым моментом является то, что клиент (веб-браузер) инициирует диалог с GET line ... Таким образом, сервер не заботится о реальном соединении, только о первых данных. В отличие от SMTP, который требует от клиента ожидания, пока сервер не выдаст свое сообщение «220 welcome banner». Т.е. ЭТО сервер должен знать при подключении, а не о данных.
13

Ответы:

14

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

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

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

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

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

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

Iain
источник
Спасибо за большое резюме. Хотя загрузка сервера и процесс перестановки / пробуждения являются одним потенциальным преимуществом (с нюансами, как вы уже упоминали), есть очевидные преимущества, если вы посмотрите на HTTP-сервер, обслуживающий клиентов с высокой и низкой задержкой. Например, при работе веб-сервера Apache доступно фиксированное количество серверных процессов / потоков, что означает, что в любой момент может быть обслужено фиксированное количество клиентов. Таким образом, не «использование» серверного процесса, пока пакет «данных» от клиента не прибыл, может означать, что серверный процесс может в то же время обслуживать другого клиента.
Рам
-1

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

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

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

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

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

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

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

  1. Сервер : «Добрый день, Epiphyte Corp.»
  2. Абонент : «Привет, это Рэнди».
  3. Звонящий : «Ты знаешь какие-нибудь анекдоты про Имельду Маркоса?»
MSW
источник
Это больше, чем просто уверенность, вы отправляете до завершения 3way и ваши данные складываются. При настройке TCP-соединений в современных стеках ОС фактически отсутствуют данные о соединениях, зарегистрированные в таблицах до 3-й части соединения, требование 3-го сообщения перед использованием любых ресурсов выполняется с помощью «Syn Cookies» и предотвращает "Syn Attacks" (которые представляют собой пакет 1 рукопожатия forged-source-ip, его пакет 3, который подрывает этот поддельный IP-адрес источника). Следовательно, выясните, что до этого момента не существует никакой связи или записи.
2013 года
Слушание (3) не гарантирует, что Сервер сразу же не перенес самовозгорание после передачи, но повышает уверенность в том, что Сервер готов к приему.
MSS
Увеличение? С нуля? Ну да, я думаю, буквально это правда, но большинство людей предполагает, что до 3-го пакета был / некоторый / шанс на увеличение. И нет. Мне просто не нравится фраза «повысить доверие», и я не думаю, что факторинг по 0,001% «основных проблем реального мира» помогает прояснить проблему. Конечно, ядерная война может произойти до того, как сервер получит пакет, может случиться много вещей.
Иэн
Также я только что поднял последний абзац, где вы подразумеваете, что шаг 3 является необязательным. Это не совсем так. Перечитайте абзац, шаг 3 «Алиса отвечает подтверждением». это не обязательно. Боб отвечает на это (теоретический 4-й шаг).
Иэн