2012-01-14 11 views
1

私は自分自身で、または研究の量を問わず解決できないようなHTTPSに問題があります。場合によっては、HTTPS要求がタイムアウトし、「受信したデータがありません」というエラーが発生することがあります。これは一般的に、HTTPからHTTPSへの仮想ホストのリダイレクトを使用している場合に発生します。それは毎回起こるわけではなく、ボットはおそらく8回に1回、タイムアウトするまで座っているだけです。 これをAmazon Load Balancerに渡してから、Ubuntu 10.04でApache 2を実行しているサーバー(EC2)に渡します。 これはリダイレクトの問題かどうかはわかりませんが、そうは思われません。これはセットアップの問題の可能性が高いので、私はあなたがそれを見ることができるように私の設定を下に置くつもりです。HTTPS受信したデータがありません

私はできるだけ早くこの問題を解決したいと思います。どんな助けでも大歓迎です。 ありがとうございます!

サイト内の仮想ホストファイルで、「myurl.com」が有効になっています。これにより、deploy.phpを除くすべてのHTTPSが強制されます。

<VirtualHost *:80> 
ServerName myurl.com 
RewriteEngine On 
RewriteCond %{HTTPS} !=on 
RewriteCond %{THE_REQUEST} !^[A-Z]+\s/deploy.php [NC] 
RewriteRule !^deploy.php https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L] 
</VirtualHost> 

サイト対応の「myurl-ssl」の仮想ホストファイル。

<VirtualHost *:80> 
     ServerName www.myurl.com 
     RewriteCond %{HTTPS} !=on 
    RewriteCond %{THE_REQUEST} !^[A-Z]+\s/deploy.php [NC] 
    RewriteRule !^depoy.php https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L] 
    NameVirtualHost *:443 
    </VirtualHost> 

    <IfModule mod_ssl.c> 
    <VirtualHost *:443> 
     SSLEngine on 
     ServerAdmin [email protected] 
     ServerName myurl.com 
     SSLCertificateFile /etc/apache2/certs/myurl.pem 
     SSLCertificateKeyFile /etc/apache2/certs/private.key 
     SSLCertificateChainFile /etc/apache2/certs/AddTrustExternalCARoot.crt 
    SSLProtocol all 
    SSLCipherSuite HIGH:MEDIUM 
     DocumentRoot /var/www 

     ErrorLog /var/log/apache2/error.log 
     LogLevel info 
     CustomLog /var/log/apache2/access.log combined 
    </VirtualHost> 

ここでも、問題は、私は、エラー(Chromeで324、しかし、この問題はすべてのブラウザで発生する)「いいえ、データを受信」を得るよHTTPSを強制的に私のセットアップや私のリダイレクトの中の何かのように見えます。私はどこかに私たちのHTTPSセットアップと関係があると信じていますが、私はそれが何であるか把握できません。

ありがとうございます!

答えて

1

私はこの問題を長年抱えており、ブラウザに依存していません。どんなブラウザでも再現するのは比較的簡単です。

NATルータテーブルが非常に簡単にオーバーフローするため、非常に多くの同時接続しか処理できないため、問題があります。 FacebookやTwitterなどの最新のAJAXサイトは、たくさんの接続を使用しています。この問題は、現在ほとんどのそのようなサイトがSSL接続を使用しているという事実によって悪化しています。

なぜこの問題が悪化しますか?

がNATルータによって廃棄された場合、SSL接続は実際には処理できず、NO DATAなどのエラーで長いSSLタイムアウトが発生します。しかし、SSLハンドシェイクが非常に遅いため、ブラウザは、NATルーティングに関連することを理解することなく、既存の接続をできるだけ再利用しようとするため、このタイムアウトでも主要なブラウザでSSL接続を適切に再接続して再ハンドシェークするようには見えませんもう接続は存在しません。

さらに、同じSSLサーバーに複数のタブが同じTCP接続を再利用しているように見えるので、1つのタブのみを閉じると実際に接続を閉じることはありません。

SSL NO DATAタイムアウトを何らかの形で減らし、既存のSSL接続に関するすべての知識を実際に消去して完全に新しいTCP接続を開いてNATを作成するようにブラウザを修正する可能性がありますルータは幸せでリフレッシュされます。

この問題を解決する実際の方法はまだ見つかりませんでしたが、上記のバグは間違いなく関連していますが、Chromeエンジニアが根本的な原因を理解しているようには見えません。

関連する問題