Как исправить ошибку «ssl-рукопожатие не удалось» с помощью ApacheBench?

#apache #https #apachebench

Вопрос:

Когда я использую ApacheBench для тестирования https, возвращается ошибка «не удалось выполнить ssl-квитирование».

Как я могу использовать ApacheBench для тестирования https?

Комментарии:

1. Заменил apachebench тег на apache-bench , чтобы соответствовать аналогичным тегам.

2. По-видимому, это вызвано плохим сертификатом. AB автоматически использует SSL.

Ответ №1:

ApacheBench, похоже, не способен игнорировать проблемы с сертификатами (по крайней мере, некоторые из них), поэтому я написал этот сценарий:

 #!/bin/bash
K=200;    
HTTPSA='https://192.168.1.103:443/'    
date  %M-%S-%N>wgetres.txt
for (( c=1; c<=$K; c   ))
do
    wget --no-check-certificate --secure-protocol=SSLv3 --spider $HTTPSA
done
date  %M-%S-%N>>wgetres.txt
 

Это не так точно, как AB, но дает представление. Хорошо справляется с сравнительными тестами.

Комментарии:

1. Вторая дата будет выполнена до завершения wgets, и поэтому бесполезна.

2. Вы правы. Я не убирал amp; в конце строки. Исправил это.

3. Это не сравнимо с AB

Ответ №2:

httperf также однопоточен, но на сегодняшний день (31 августа 2012 г.) он правильно обрабатывает SSL и даже имеет некоторые полезные дополнительные функции, связанные с SSL:

   --ssl  Specifies that all communication between httperf and the server
      should  utilize  the  Secure Sockets Layer (SSL) protocol.  This
      option is available only if httperf was compiled with  SSL  supâ€
      port enabled.

  --ssl-ciphers=L
      This  option  is  only  meaningful  if  SSL is in use (see --ssl
      option).  This option specifies the list L of cipher suites that
      httperf  may  use  in  negotiating  a secure connection with the
      server.  If the list contains more than one  cipher  suite,  the
      ciphers  must  be  separated by a colon.  If the server does not
      accept any of the listed cipher suites,  the  connection  estabâ€
      lishment  will  fail and httperf will exit immediately.  If this
      option is not specified when the --ssl option  is  present  then
      httperf  will use all of the SSLv3 cipher suites provided by the
      underlying SSL library.

 --ssl-no-reuse
      This option is only meaningful if SSL and sessions  are  in  use
      (see  --ssl,  --wsess,  --wsesslog).   When an SSL connection is
      established the client receives a  session  identifier  (session
      id)  from the server.  On subsequent SSL connections, the client
      normally reuses this session id in order to avoid the expense of
      repeating  the  (slow) SSL handshake to establish a new SSL sesâ€
      sion and obtain another session id (even if the client  attempts
      to re-use a session id, the server may force the client to reneâ€
      gotiate a session).  By default httperf reuses  the  session  id
      across  all  connections  in  a  session.  If the --ssl-no-reuse
      option is in effect, then httperf will not reuse the session id,
      and the entire SSL handshake will be performed for each new conâ€
      nection in a session.
 

Ответ №3:

Недавно я столкнулся с этой проблемой. В качестве обходного пути я использовал пакет loadtest npm, который имеет такие же опции, как ab:

https://www.npmjs.com/package/loadtest