mod_spdyの問題と推測
Mod_spdyを試していますが、問題が発生しました-AJAXリクエストおよびmod_phpと互換性がないようです： https：//www.modspdy。 com/blog/2012/04/15/using-mod_spdy-with-php /
解決策は、fastCGIを介してphpスクリプトを実行することのようです。さて、私の最初の質問は、それはなぜですか？何らかの回避策はありますか？この非互換性は一時的なものですか？このため、本番サーバー全体をfastCGIに切り替えたくありません。その長所/短所は何でしょうか？
また、なぜhttpsが必要なのかわかりません。単純な、たとえば静的なWebサイトがmod_spdyから速度を上げることができないのはなぜですか？私はここで明白な推測を探しています-mod_spdyはmod_ssl要件なしでいつか利用可能になると思いますか、それともアーキテクチャが非常に異なっているので、いつでもそれを期待するべきではありませんか？
自分の考えをはっきりと表現できればと思います。ご意見ありがとうございます。
Mod_spdyを試していますが、問題が発生しました-AJAXリクエストおよびmod_phpと互換性がないようです： https：//www.modspdy。 com/blog/2012/04/15/using-mod_spdy-with-php /
解決策は、fastCGIを介してphpスクリプトを実行することのようです。さて、私の最初の質問は、それはなぜですか？何らかの回避策はありますか？この非互換性は一時的なものですか？
AJAXに関してあなたが何を意味するのか明確にできますか？
mod_phpはmod_spdyでうまく機能しません。これは、SPDYが複数のリクエストをスレッド化された単一の接続に多重化し、mod_phpで問題を引き起こす可能性があるためです。 mod_spdyドキュメント にうまく収まっています：
Apache Worker MPMと同様に、mod_spdyは（SPDY多重化を実装するために）内部スレッドプールを使用してリクエストを処理します。これは、スレッドセーフではないApacheモジュールとの相互作用が悪い場合があります。 特に、mod_spdyを介してPHPを提供する場合は、mod_phpではなくmod_fcgidを使用することを強くお勧めします。 -）、一部のPHPライブラリはスレッドセーフではありません。mod_fcgidを使用すると、別のプロセスでPHPが実行されるため、スレッドセーフの問題が回避されます。
その長所/短所は何でしょうか？
その主題の議論については このスタックオーバーフローの質問 を参照してください。
また、なぜhttpsが必要なのかわかりません。単純な、たとえば静的なWebサイトがmod_spdyから速度を上げることができないのはなぜですか？私はここで明白な推測を探しています-mod_spdyはmod_ssl要件なしでいつか利用可能になると思いますか、それともアーキテクチャが非常に異なっているので、いつでもそれを期待するべきではありませんか？
いいえ-SPDYはSSLを必要とするように意図的に構築されています。もちろん、SSL要件が決して下がらないと言うのも推測です。しかし、それがどこにも行かない大きな理由がいくつかあります。
プロトコルの動作に必要です。
TLS Next Protocol Negotiation拡張機能は、クライアントとサーバーが両方ともSPDYをサポートしていることを相互に通知するために必要です。
それはインターネットにとって良いことです。
Googleを含め、インターネット上の多くの大手企業は、クレジットカード番号をその瞬間に提供していなくても、サイトでSSLを実行する必要があるという考えに出くわしました。
Firesheepにより、Cookieのハイジャックが簡単になりました。そのため、最近ではFacebookまたはTwitterの接続が常に暗号化されていることに気付くでしょう。あなたがこれを読んでいるのと同じ リクエストが行われた スタックエクスチェンジネットワークの。また、インターネットの無料使用を許可しない体制下に住む人々にとって、接続のセキュリティはさらに懸念事項です。