Tôi có một trang web sử dụng https để truyền tệp javascript đến máy khách. Trang web này được getimpl Ứng dụng.com .

Hóa ra tệp này đang tải chậm hơn 52 lần với https (20,08 giây - 29,08 giây) với http (380ms).

Trang chủ của trang web chia sẻ sự chậm chạp giống như tệp javacript.

• http://getsimpl Ứng dụng.com
• https://getsimpl Ứng dụng.com

Gần đây tôi đã chuyển từ dreamhost sang linode và đã hack để SSL hoạt động trên máy chủ mới cho đến khi nó hoạt động. Tôi đã không làm bất kỳ cấu hình điên rồ.

Các linode đang chạy Ubuntu 12.04 và trang web nằm trên cùng của ngăn xếp (LAMP).

Câu hỏi của tôi đối với cộng đồng tràn stack là: Làm cách nào để sửa lỗi SSL & HTTPS trên máy chủ của tôi? Tôi biết rằng tràn ngăn xếp bị lấp đầy bởi các câu hỏi liên quan đến sự chậm chạp của HTTPS nhưng không có giải pháp thực sự nào được đưa ra. Một hướng dẫn ubfox hoặc hướng dẫn cấu hình sẽ là lý tưởng.

tập tin: /etc/apache2/sites-enables/getsimpl Ứng dụng.com

<VirtualHost *:80>
     ServerAdmin admin@getsimpleapps.com
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

<VirtualHost 50.116.58.18:443>
     SSLEngine On
     #SSLCertificateFile /etc/apache2/ssl/www.getsimpleapps.com.crt
     #SSLCertificateKeyFile /etc/apache2/ssl/www.getsimpleapps.com.key
     #SSLCACertificateFile /etc/apache2/ssl/comodo.crt
     SSLCertificateFile /etc/apache2/ssl/dreamhost/dh.crt
     SSLCertificateKeyFile /etc/apache2/ssl/dreamhost/dh.key
     SSLCACertificateFile /etc/apache2/ssl/dreamhost/dh.cer

     ServerAdmin admin@getsimpleapps.com
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

Curl từ máy trạm địa phương

thomas@workstation:~$ time curl -Iv https://getsimpleapps.com/
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* Connected to getsimpleapps.com (50.116.58.18) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:31:39 GMT
Date: Thu, 02 Aug 2012 20:31:39 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html
Content-Type: text/html

< 
* Connection #0 to host getsimpleapps.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m29.078s
user    0m0.018s
sys 0m0.005s

Curl từ máy chủ linode (thông qua ssh)

thomas@vannevar:~$ time curl -Iv https://getsimpleapps.com/happy-ending/api/script.js?shop=holstee.myshopify.com
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD /happy-ending/api/script.js?shop=holstee.myshopify.com HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:43:30 GMT
Date: Thu, 02 Aug 2012 20:43:30 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
< Content-Type: text/javascript
Content-Type: text/javascript
* no chunk, no close, no size. Assume close to signal end

< 
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m25.991s
user    0m0.015s
sys 0m0.022s

Tôi có cùng một vấn đề, với sự khác biệt về thời gian phản hồi gần như giống hệt nhau giữa HTTP và HTTPS. Hóa ra vấn đề như trong câu trả lời của @htmltiger : Apache2 chỉ đơn giản là hết quy trình worker.

Điều này khiến các yêu cầu mới được xếp hàng cho đến khi một nhân viên trở nên tự do và có thể xử lý [ nguồn ] tiếp theo . Tôi cho rằng lý do tại sao điều này chỉ ảnh hưởng đến HTTPS chứ không phải HTTPS là vì gần như tất cả lưu lượng truy cập của bạn đều qua HTTP và Apache cung cấp cho các yêu cầu HTTP và HTTPS cùng một ưu tiên, lần lượt lấy một yêu cầu từ mỗi hàng đợi. Vì vậy, khi hàng đợi HTTPS dài hơn nhiều, yêu cầu chờ đợi lâu hơn. Thật vậy, có hai hàng đợi, vì hàng đợi chỉ đơn giản là cơ chế hàng đợi kết nối TCP TCP và Linux cung cấp một hàng đợi trên mỗi cổng.

Chẩn đoán

Nếu đây là vấn đề của bạn, các triệu chứng sau đây sẽ được áp dụng:

• Chỉ báo tốt nhất: trên máy chủ của bạn, apachectl statuscho thấy tất cả các quy trình công nhân được phép đang chạy. Đây là trường hợp khi không có dấu chấm .nào là shwon trong dòng bảng điểm quy trình, cho biết không còn "Khe mở không có quy trình hiện tại". Dòng này có thể trông như thế này chẳng hạn:

  KKKKKKRKKKRRCWKKKCCKWKKKKCRCKKKKKKKCKCKKKKWRKKKKWRWKKKKKKCWKKWKKK
  

• Bạn thấy các thông báo như thế này trong nhật ký lỗi chính của Apache2 ( /var/log/apache2/error.logchứ không phải các tên miền cụ thể):

  [mpm_prefork:error] [pid 4715] AH00161: server reached MaxRequestWorkers 
      setting, consider raising the MaxRequestWorkers setting
  

• Có nhiều quy trình trong hồ sơ tồn đọng Apache của bạn. Theo bài viết chuyên sâu này , bạn có thể thấy điều này từ unacked:giá trị trong ss -lti '( sport = :https )'đầu ra. Tùy thuộc vào phiên bản hoặc cấu hình của ss, giá trị đó có thể bị thiếu mặc dù.

• Hầu hết độ trễ (giả sử, 17 trong 20 giây) được hiển thị trong Bảng điều khiển mạng Firefox, trong tab "Thời gian" cho URL ban đầu được yêu cầu, dưới dạng "Chặn".

Giải pháp

Điều này giả sử bạn sử dụng mô đun máy chủ MPM prefork trong Apache. Nó tương tự cho các mô-đun MPM "sự kiện" và "công nhân" - chi tiết .

1. Chỉnh sửa /etc/apache2/mods-enabled/mpm_prefork.confvà tăng MaxRequestWorkerscài đặt.

2. Nếu bạn tăng nó vượt quá mặc định 256, bạn cũng phải đặt ServerLimit thành cùng giá trị để thay đổi của bạn có hiệu lực.

3. Áp dụng các thay đổi: service apache2 reload

4. Đảm bảo rằng trong đầu ra bảng điểm của cài đặt apachectl statusmới MaxRequestWorkerscó hiệu lực. Nó phải tương đương với độ dài của bảng điểm trong các ký tự.

5. Nếu cài đặt chưa hiệu quả, hãy tìm kiếm /etc/apache2các chỉ thị cấu hình cũ (và các từ đồng nghĩa không dùng nữa của chúng) có thể ghi đè lên thay đổi của bạn:

   grep -R MaxRequestWorkers /etc/apache2/*
   grep -R MaxClients /etc/apache2/*
   

Chẩn đoán phân biệt

Trong trường hợp bạn thấy HTTPS chậm hơn nhiều so với HTTP nhưng không phải mỗi lần trong một loạt tải lại trang (chỉ ở mức trung bình), thì bạn có thể có một biến thể của vấn đề lạ mắt này , với hai máy chủ Apache2 chạy trên cổng SSL 443.

Hãy thử thay đổi mật mã thành RC4-MD5 (cân bằng tốt về hiệu suất và bảo mật), nghĩa là:

SSLCipherSuite RC4-MD5

Chúc mừng

Tôi gặp vấn đề tương tự đối với một máy chủ bận rộn nhưng việc tăng MaxRequestWorkers lên 400 trong mpm_prefork.conf đã sửa nó.

Hóa ra vấn đề của tôi là chìa khóa của tôi là từ một máy chủ khác. Tôi cần phải có một chứng chỉ mới và thiết lập nó với các khóa mới.