SSL/TLSには若干のオーバーヘッドがあります。 GoogleがGmailをHTTPSに切り替えたとき（オプション機能からデフォルト設定に）、CPUオーバーヘッドが約+ 1％、ネットワークオーバーヘッドが+ 2％であることがわかりました。詳細は this text を参照してください。ただし、これはGmailを対象としています。Gmailはプライベートで動的な非共有データで構成され、Googleのシステムでホストされており、非常に低いレイテンシでどこからでもアクセスできます。 HTTPと比較したHTTPSの主な効果は次のとおりです。
接続の開始には、追加のネットワークラウンドトリップが必要です。このような接続は「維持」され、可能な限り再利用されるため、特定のサイトが繰り返されるやり取りで使用されている場合（Gmailの場合と同様）、この余分な遅延は無視できます。主に静的なコンテンツを提供するシステムでは、ネットワークのオーバーヘッドが無視できないものであることがわかります。
プロキシサーバーは、HTTPSで提供されるページをキャッシュできません（それらのページが表示されないため）。ここでも、Gmailでキャッシュする静的なものはありませんが、これは非常に特殊なコンテキストです。 ISPは、ネットワーク帯域幅がライフサイクルであるため、キャッシュが非常に好きです。
HTTPSはSSL/TLS内のHTTPです。 TLSハンドシェイク中に、サーバーは証明書を表示します。これにより、目的のサーバー名を指定する必要があります-これはbeforeの前に発生し、HTTP要求自体がサーバ。 サーバー名表示 と呼ばれるTLS拡張が使用されない限り、これにより仮想ホスティングが防止されます。これにはクライアントからのサポートが必要です。特に、Internet ExplorerはWindowsでのサーバー名表示をサポートしないXP（IE 7.0以降ではサポートしていますが、 VistaとWin7のみ。WinXPを使用するデスクトップシステムの現在の市場シェアを考えると、「誰も」がサーバー名表示をサポートしているとは限りません。代わりに、HTTPSサーバーはサーバー名ごとに1つのIPを使用する必要があります。IPv6展開とIPv4の現在のステータスアドレス不足はこれを問題にします。
HTTPSは、次の意味でHTTPよりも「安全」です。データは名前付きサーバーから送信されたものとして認証され、転送は回線を盗聴する可能性のある人物に関して機密です。これは、多くの状況では意味をなさないセキュリティモデルです。たとえば、YouTubeからの動画を見ても、その動画が実際にyoutube.comから送信されたものなのか、または（慎重に）送信したハッカーから送信されたものなのかは特に気にしません。あなたが見たいビデオ;とにかくそのビデオは公開データなので、ここでは機密性の関連性は低いです。また、認証はサーバーの証明書に対してのみ行われます。サーバーの証明書は、クライアントブラウザーが知っている証明機関から発行されます。証明書のポイントはCAによる証明書の所有者の物理的な識別を伴うということなので、証明書は無料ではありません（商業CAが証明書を公正に価格設定するとは言いませんが、仏陀自身が運営する最も公正なCAでさえ、まだ証明書の料金を請求する必要があります）。商用CAは、loveHTTPSを「デフォルト」にするだけです。さらに、X.509証明書によって具体化されたPKIモデルが、インターネット全体に対して「デフォルトで」「本当に」必要なものであるかどうかは明確ではありません（特に、証明書とDNSの関係に関しては）。サーバー証明書は、ドメインの作成時に登録事業者が発行する必要があります）。
多くの企業ネットワークでは、HTTPSは盗聴者がデータを見ることができないことを意味し、そのカテゴリにはあらゆる種類のコンテンツフィルターとウイルス対策ソフトウェアが含まれます。 HTTPSをデフォルトにすると、多くのシステム管理者は非常に不満になります。
これらはすべて、HTTPSがWebのデフォルトプロトコルとして必ずしも良い考えではない理由です。ただし、HTTPSが現在のところWebのデフォルトのプロトコルではない理由ではありません。 HTTPが最初にあったからといって、HTTPSはデフォルトではありません。
すでにすばらしい答えは出ていますが、私は今のところ見落とされている側面があると思います。
ここにあります：Web上の情報の大部分はセキュリティを必要としないため、プレーンHTTPがWebのデフォルトプロトコルです
質問や、一部のWebサイト/アプリケーションのセキュリティ上の懸念を軽視するつもりはありません。しかし、ウェブトラフィックの量を忘れることがあります。
- 完全に公開された情報のみが含まれます
- またはほとんどまたはまったく価値がない
- または、より多くの訪問者がいることがサイトの価値を高めると見られている場合（ニュースメディア、 ネットワーク効果 サイト）
いくつかの簡単な例を挙げれば、すぐにもっと多くのことを頭に浮かぶことができると思います。
- ほとんどすべての会社のWebサイトは、「パンフレットウェアサイト」と呼ばれることもあり、会社に関する公開情報を掲載しています。
- 主要な収益化戦略として広告サポートを選択したほとんどすべてのニュースメディア、ブログ、テレビ局など。
- ログインと追加のパーソナライズを提供できるが、匿名で閲覧している人（YouTube fx）にコンテンツを無料で提供するサービス。
- 特に静的コンテンツの場合、サーバーのCPU負荷が大幅に増加します。
- パケットキャプチャでデバッグするのが難しい
- 名前ベースの仮想サーバーはサポートしていません
Httpは常にデフォルトでした。最初はhttpsは何も必要ではありませんでした。状況によってはセキュリティが必要であることが明らかになったため、これはかなりの追加作業でした。
現在でも、httpsを必要としないWebサイトが非常に多く、httpを完全に置き換えることはまだ説得力のある議論ではありません。
TLSで保護された接続を実行するためのこれまで以上に効果的なメカニズムにより、CPUオーバーヘッドの問題ははるかに少なくなっています。
Httpsではなくhttpをデフォルトとして使用することから生じる明確な問題を指摘した人はいません。
さまざまな目的で暗号化および/または署名が必要なリソースを要求するときに、完全なURIを書くことに煩わされることはほとんどありません。
例としてgmailを取り上げます。ユーザーがgmail.comにアクセスしている場合、実際にはhttpsではなくhttpのデフォルトプロトコルにアクセスしています。この時点で、攻撃者がトラフィックを傍受しているシナリオでは、セキュリティが失敗しています。どうして？ httpsリクエストからhtmlを取り除き、それらをhttpにポイントすることが可能だからです。
Httpsが実際にデフォルトのプロトコルだった場合、ウェブサイトへのセッションは保護されていたでしょう。
Httpsではなくhttpが選択される理由については、上記のさまざまな答えが当てはまります。世界はまだ暗号化の広範な使用の準備ができていません。
他の人がすでに与えた理由に加えて：
サーバーでHTTPSを設定するために必要な追加作業
サーバー管理者は、ドメインごとに証明書を構成する必要があります。これには、認証局と対話して、ドメインの真の所有者であることを証明し、証明書の更新を取得することが含まれます。これは、手動で証明書署名要求を生成して更新を購入するか、それを行うための自動プロセスを設定することを意味する場合があります（Let's Encryptを使用するcertbotなど）。どちらの場合も、HTTPSを使用しない場合よりも作業が多くなります。
追加のIPアドレスが必要
ブラウザとSSLクライアントライブラリでSNI（サーバー名識別）サポートが広まったため、これは実際には問題ではありません。
ただし、従来は、特定のサーバーとポートでSSLを使用して、サイトごとに異なるIPアドレスを使用する必要がありました。これは、名前ベースのホスティング（仮想ホスティング）を実行する機能と連動しています。これは、同じIPアドレスから多くの異なるドメインをホストできるようにするために広く使用されている方法です。 HTTPSでは、サーバーはSSL/TLS検証レイヤーに存在するhostnameを知る必要があるため、通常の名前ベースのホスティングは機能しませんbeforeを含むHTTPリクエストホスト名、復号化できます。
SSL/TLSレイヤーで名前ベースのホスティングを効果的に実装するサーバー名識別（SNI）は、この制限を取り除きます。
変化のペースが遅い
HTTPSは、既存のプロトコルであるHTTPの修正版でした。HTTPは、多くの人々がセキュリティについて考えるようになる前に、すでにかなり定着しています。テクノロジーが確立され、HTTPのようにユビキタスになると、変更の理由が説得力があるとしても、世界がその後継者に移行するのに非常に長い時間がかかる可能性があります。
Thomasはすでに優れた回答を書いていますが、HTTPSがそれほど広く使用されていない理由をもう2つ挙げたいと思います...
不要です。Jesperの回答では、洞察力をもって「Web上の情報の大部分はセキュリティを必要としない」と指摘されています。 ただし、検索エンジン、広告会社、国レベルのインターネットフィルター、およびその他の「ビッグブラザー」プログラム（NSAなど）によって追跡が増加しています。それはより大きなプライバシー対策の必要性を高めています。
速度。追加の往復と証明書失効リストへの追加の要求のため、遅いと感じることがよくあります（ [〜＃〜] ocsp [〜＃〜] など）。ありがたいことに [〜＃〜] spdy [〜＃〜] （Googleによって作成され、現在すべての主要なブラウザーでサポートされています）、そして CloudFlareからの興味深い作業 はこれをシフトするのに役立ちます。
証明書の価格。ほとんどの認証局は、証明書に対して法外な金額（数百ドル）を請求します。ありがたいことに 無料のオプションがあります ですが、あまり宣伝されていません（理由はわかりませんか？）。
IPアドレスの価格。IPv6が普及するまで、WebサイトはIPv4アドレスの不足（およびコスト）の増大に直面します。 [〜＃〜] sni [〜＃〜] は、単一のIPアドレスで複数の証明書を使用できるようにしますが、WindowsではSNIをサポートしていませんXPまたはIE 6、ほとんどのサイトでは、SSLを提供するために専用IPアドレスが必要です。
サーバーのCPU使用率の増加これは一般的な考えですが、Googleによると、「 SSL/TLSは、もはや計算コストがかかりません "。
私の同僚の中で最も簡単で最も合理的な説明は、常にHTTPで行われていたということです。なぜ今それを変更するのでしょうか。
壊れていない場合は修正しないでください。
本当の答えは、現在の形式のSSL証明書はコミカルに使用するのが難しいということです。人々はショートカットを使って物事を成し遂げるため、証明書のセキュリティを脅かすほど使用できない。私はこれを、双方向SSL（PKI証明書）、仕様の複雑さによって引き起こされるTLSスタックの非互換性、および構成の膨大な数の組み合わせ（暗号の制限、オプション、言語固有のライブラリのバグ）を日常的に扱っている人物と言いますなど）は「TLS」と呼ばれます。
これが真実であることの証拠としてLetsEncryptの台頭を見てください。
CaddyはLetsEncryptを使用するリバースプロキシプロジェクトです。サーバーの実行中に証明書を更新でき、更新は自動化されているため、ユーザーは非常に短い有効期限を使用します。