RFC 7540「Hypertext Transfer Protocol Version 2（HTTP/2）」がリリースされる 60
ストーリー by hylom
ついに登場 部門より
ついに登場 部門より
RFC 7540「Hypertext Transfer Protocol Version 2（HTTP/2）」が公開された。
HTTP/2はHTTPの新規格で、今年2月に、Internet Engineering Task Force（IETF）による承認が完了していた。Google ChromeやFirefoxなどではすでにHTTP/2のサポートが進められている。
HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:5, 参考になる)
HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット（Googleにとっては最大限のメリットであることから）が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。
まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox（Firefox の最大のスポンサーは残念なことに Google です）の実装においては TLS 必須のため、事実上 HTTP/2 では TLS が必須ですから、プロキシやVPN（Android における広告ブロックによく用いる仮想VPNを含む）等による広告ブロックが完全にできなくなります。勿論、広告配信サーバのIPアドレスが違えばできますが、高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば（コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする）通信内容の書き換えによる広告ブロックが完全にできなくなります（HTTP/2 の速度向上効果は同一サーバからのデータ送信の方が高いという大義名分があります）。
そして、今までの HTTP 1.1 では、まず html ファイルを取得して、それからクライアントが画像なり JavaScript 外部ファイルなりをリクエストする形式でしたが、HTTP/2 ではサーバプッシュ (RFC 7540 - 8.2. Server Push) という機能があり、サーバ側が html ファイルと同時に画像なり JavaScript 外部ファイルなりを一方的にまとめてバイナリ形式で送り付けることが可能です。これにより、広告画像・広告JavaScriptを受信しないことができなくなります。ブラウザのプラグインで広告を非表示にしたとしても、広告データを受信して無駄な通信が発生することを回避できないのです。広告ブロックを導入している環境で Webブラウジング（動画鑑賞を除く）のみで 所謂7GB制限に引っかかっている人は、HTTP/2 の世界においてはその10分の1以下のWebページしか見ることができなくなるでしょう（例えば、スラドの1ページあたりの通信量のうち、大部分は広告の通信です）。勿論、既にキャッシュしているファイルのサーバプッシュを拒否することはできますが、初めてアクセスするサイトではファイル名等が分からないので不可能ですし、広告画像等のファイル名等をランダムな文字列にするなどで、サーバプッシュ拒否を完全に妨害することができます。
次に問題となるのは、プライバシー上の問題です。サーバプッシュ (RFC 7540 - 8.2. Server Push) 機能で既にブラウザがキャッシュしている画像等を再送信することを防ぐため、クライアント側は既にキャッシュしているファイルの一覧をサーバに送信することになりますが、ファイル名等をランダムにすることで Cookie を無効にしていてもユーザをトラッキングすることが容易にできてしまいます。まぁ、今でも Cookie 無しでトラッキングする方法は山のようにありますから、それが1つ増えただけのことで、これについてはたいした問題はないかもしれません。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:3)
現在は、ほとんどが広告プラットフォームによる広告配信だと思いますが、このような、別ドメイン・別サーバによる広告データの配信でもサーバプッシュできるのでしょうか。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
なるほど非表示は可能なので最大の問題はモバイル端末での受信なのか。
とはいえiPhoneでの広告ブロックは現状一般的とは思えないので、テザリングで使用する場面だろうか。
PC用の大サイズ広告を拒否できないのは確かに困る。
Re: (スコア:0)
やりたければ、サーバにリバースプロキシを設定するだけで出来る。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:2)
広告ブロック対策をやりたくて、そのためだけに掲載側サーバに手を加えることをアリとするなら、現状でもやりようはあると思うんです。
ドメインでブロック判定をするものなら、それこそリバースプロキシで掲載側ドメインのものとしちゃえばいいわけで。
なんなら、掲載ページのhtmlファイルに直接書き込んじゃってもいい。
Re: (スコア:0)
未だにHTTPSを使わないスラドは大丈夫でしょう。
Re: (スコア:0)
HTTP/2なんて話題をApache1.3が動いているサーバーで議論している違和感
最新トレンドを全部追えとは言わないけど、どうにかならないの？
少なくとも技術者系サイトとは思えないトレンドの低さ
最新ネタとかやめて、PC9800シリーズとかの回顧記事を中心mに取り扱った方が身の丈にあってるかもしれませんね。
Re: (スコア:0)
>広告ブロックが困難というか事実上不可能になるというデメリット
Googleだけが悪いっぽく言われてるけど、趣味も含めたサイト運営者の少しの足しになると思うけどなぁ。
（広告以外のマネタイズするのが望ましいかもしれないけど）
Re: (スコア:0)
広告ブロックの定義にもいろいろあって、例えば、私はiframeをCSSで切っていますが、コンテンツはダウンロードしているはずです。単に表示されないだけなので。
Re: (スコア:0)
消費者が広告や帯域消費を受け入れたら、
サイト主も広告主も儲かってより良いコンテンツが生まれるんだから、
それくらいは我慢してあげてもいーじゃんと思うけどね。
Re: (スコア:0)
Amazonのおすすめシステムのように、正確かつ受け入れられやすい広告サジェストシステムであれば、ユーザーも拒否することはないでしょうが、見たくもない肌色成分多めの広告や下劣な広告を見せつけられていれば、こういう反応になるのが至極当然。
それに、
> サイト主も広告主も儲かってより良いコンテンツが生まれる
のくだりがよく理解できないのですが。儲かれば(運営者に収入が発生すれば)、必ずより良いコンテンツが生まれますかね？そもそも、広告収入を受けているサイトが良いコンテンツを提供している、という前提が間違っているのではないでしょうか。
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
>儲かれば必ずより良いコンテンツが生まれますかね？
必ず生まれますよ。
世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
良い仕事をする人の殆どは職業としてそれをやっています。
お店は儲けようとして良い商品を用意するんです。
サイトは設けようとして良いコンテンツを作るんです。
良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
作ろうというモチベーションは大体が報酬を得るためなのです。
Re: (スコア:0)
芸術等では手弁当でとにかく自分の作りたい(良い)物を作ろうとする人もいるので、「適切な対価が得られる方が継続して良いものを作りやすい」、「収入があればコンテンツ制作で機材・資材・資料集めに費用をかけられる」の2点を追加してもらったほうが分かりやすい気がします。
>世の中の良いコンテンツを作っている人の大多数はそれで儲けようとしていた人です。
>良い仕事をする人の殆どは職業としてそれをやっています。
>サイトは設けようとして良いコンテンツを作るんです。
>良いコンテンツを作ろうとせずに良くなってしまうのは極まれです。
>作ろうというモチベーションは大体が報酬を得るためなのです。
Re: (スコア:0)
大筋の考えは同意するところだけど、そこまで強く肯定できる程の真理ではないと思う。
スマホゲーや、このサイトのストーリーの採用傾向にも感じることなのだが、
最近はとにかく人を集める事を是とし、徒に利用者の情を煽って利益を捻り出そうとする事例が目立つ。
良いか悪いかで言って、良いものと言えないものでも利益は生成できる現実があり、
殊に広告主が抽象化された報酬システムでは、雇い主への配慮を鑑みずに下劣な内容でページビューを稼ぐ手法が珍しくない。
あるいはページビューを稼げるものを「良いもの」と定義する人もいるだろうが、一般の感性と必ずしも一致するものではないだろう。
Re: (スコア:0)
いいえ、そのためにトラッキングをすると「プライバシーが－」と文句を言われます。
相手の行動様式や興味対象が判ればサジェストも可能ですが、現状ではそれはそれで否定されてしまうわけです。
Re: (スコア:0)
広告設置してるなら金が欲しいってことだろうから普段から利用しているサイトが邪魔にならない程度に広告設置するのならなんら問題ないです。
なんでもかんでもただで利用できて当然だって思ってません？
Re: (スコア:0)
自分もそう思う。そこまで必死に拒絶しないといけないものじゃないでしょう。何かを作るには費用が掛かるのだし。
Re: (スコア:0)
TLSを使ってるからってプロキシでブロックできなくなるわけじゃないでしょ
プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
Re: (スコア:0)
> プロキシで生成したCA証明書をブラウザにインストールして中間者攻撃って方法もあるわけだし
スマートフォンではわからんがPCではLenovo事件の反応を見るに許されることじゃないでしょ
Re: (スコア:0)
別に広告垂れ流すのは構わんけど、もっと通信量を抑えろといいたい。
通信料が増えれば増えるほどISPやキャリア側の負担が重くなるんだぞ。
Re: (スコア:0)
Google は得てして通信量の増大には無頓着ですからなぁ。
Android 使っていて、通信量の上位が片っ端から Google アプリ（しかも多くがバックグラウンド通信）ってのはよくある話。
Re: (スコア:0)
何がそんなに憎いかわからんが広告は悪ではないよ
広告を悪用するやつが悪なんだけどな
＃それに受信しても見ない方法はいくらでもあるじゃん
Re: (スコア:0)
世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
まあ、Win10 / IE11 or Edgeからってのは確かですが(そっちはPUSH対応してそうっぽい...)、それ言ってもしょうがない気が。
# Push Promiseは帯域的とかよりは、クライアント側からNAKすれば(予約を通知されたストリームIDでの応答でリセットかける)とか
# たとえ押しこまれてもレンダリングしないはあるよな、とかもうちょっとやりようはありそう
# すくなくとも完全に無理矢理ではない気がする。
M-FalconSky (暑いか寒い)
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
そもそもアドサーバと本サーバが同じ(or リダイレクト的にあれこれする設定がされてる)とか本格的にアレじゃないとこの想定は機能しないような
M-FalconSky (暑いか寒い)
Re: (スコア:0)
>広告ブロックを導入している環境で Webブラウジング（動画鑑賞を除く）のみで 所謂7GB制限に引っかかっている人
一体どんなサイトを見たらそうなるのか知りたい。
しかも動画抜き、って・・・
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
2ch全体をクロールでもしてるのかなぁ…
Re: (スコア:0)
Facebookとか写真貼りまくる人がいると結構ヤバイですね。
Re: (スコア:0)
スマホでTumblrのダッシュボード見てると、1時間で100MBくらい行ってますね。
gifアニメは入ってるけどいわゆる動画鑑賞は無しで。
モバイル回線しか無かったら、7GB超えてるでしょう。
Re: (スコア:0)
> 高速化という名目のもと Google Adsense のコードを php などにして、コンテンツと同一のサーバから送信するようにすれば（コンテンツを提供する Webサーバが Google の広告サーバと通信する形式にする）通信内容の書き換えによる広告ブロックが完全にできなくなります
これをされたら 1.1 で通信しててもブロックできないと思うけど、最近の広告ブロックはウィルススキャン並みにファイル解析処理を行って判定してるの？
広告ブロッカーは結構賢い (スコア:2)
HTTP 1.1 であれば、普通にブロックできます。
JavaScript の広告コードはこんな感じです。この場合、"googlesyndication.com" というドメインの JavaScript のロードを阻止することで、広告の読み込み（受信）をブロックができます。
そして、サーバサイドで広告コードをhtml化して注入するシステムだと、下記のような感じのHTMLソースになります。その場合は、広告画像がコンテンツと同一のサーバから配信される仕組み (サーバサイドスクリプトでGoogleの広告サーバから受信したものを配信) であっても、広告クリック時のリンク先はサイト管理者がクリック数を不正に増やすことを防止するためにGoogleのドメインになるでしょうから、広告ブロッカーはa要素のhref属性に "googlesyndication.com" が含まれていた場合、a要素に包括されるimg要素を含めて受信をブロックします。
しかし、HTTP/2 のサーバプッシュで広告画像とコンテンツhtmlをまとめてバイナリデータとして送信する仕組みにしてしまえば、広告ブロッカーで広告を非表示にしたとしても、広告データの受信を阻止することができなくなり、広告ブロッカーを導入するメリットが半減することになり（邪魔な広告を見たくないという要求を満たすことはできるが、通信量を減らしたりページのロードを早くしたりしたいといった要求を満たすことができなくなる）、広告ブロッカーの導入率を下げることができます。
ちなみに、最近の広告配信システムではサイト管理者がページに貼り付けるコードが JavaScript なのが一般的ですが、昔の広告配信システムでは Perl や php のコードが用いられているところも結構ありました。
特に i-mode などのモバイル向けでは、100% サーバサイドスクリプトでした（JavaScript 非対応端末が一般的であったため）。
従って、HTTP/2 が普及したら、広告表示の高速化と、広告ブロック妨害（サーバプッシュの利用）の為、昔のようにサーバサイドスクリプトの広告コードに戻る可能性もあると思います。
Re: (スコア:0)
2番目の例だとhtmlをパースした後でないとブロックできないから，imgをBASE64に変換されて埋め込まれたら，現状でも対応できない。
こんな議論は pgp/gpg や s/mine の暗号メールにおけるスパムでも議論がありましたが，暗号メールはなかなか普及しないな。
Re: (スコア:0)
JS殺すことで通信料低下と表示速度向上してる私にとってきついんだよなあ。数倍違うんで。
でもま、最大の欠点はセキュリティじゃないかな。
data-uriもそうだったけどね。
Re: (スコア:0)
AdBlockはブラウザがページをデコードした結果に介入しているのだから普通にブロックできますが。
むしろ中間の土管にそんな介入許すほうが恐ろしい。広告をブロックできるということは自社の広告に差し替えもできるということ
ここの住民なら (スコア:1)
自宅やVPSに立てた自前の串なりVNCなりで対応可能かも
sshトンネルで張れば経路も安全になるし
一般民は泣き寝入りかもしくは
同様のサービスをキャリアが有料化して
提供側Win-Win(ウマウマ)になるかもしれませんね
# 手がないのは手が見えないだけなのかも
Re: (スコア:0)
モバイルの通信量減らしたいなら
よく見るサイトからコンテンツ引っこ抜いて整形するサーバ立てるのがよいかもね
ラズパイとかの低消費電力サーバ使えばランニングコストもあまりかからないし
＃ちょうどKobo用にそういうサーバ作ってるところ
Thumbsense (スコア:0)
ブラウザアドオンが使えるなら、指定サーバには強制的にHTTP1でアクセスさせるようにすればいいのでは
Re: (スコア:0)
NSS（Firefox）やBoringSSL（Chrome）の実装レベルでそういうドメイン指定でのHTTP/2、1.1の切り替え機能が存在しない限りは無理
Re: (スコア:0)
NSSやBoringSSLはTLS(トランスポート層かセッション層)の実装で、その上のアプリケーション層がどんなプロトコルを使っているかなど知ったことではないのだがいったい何言ってるの
スローガン (スコア:0)
Don't be evilはどこへいったんでしょうかね？
Re:スローガン (スコア:1)
多分、
We're not evil.
We're simply careless.
と答えるんじゃないかな…
(Careless about not being evil..)
fjの教祖様
Re: (スコア:0)
単に「Googleのやってることだからevilに決まってる」って馬鹿が騒いでるだけじゃん
Re: (スコア:0)
スローガンってのは，「実際はそうじゃない」ときに使われる，とよく聞くなあ…
# 清廉潔白，という単語が一番使われるのは政治の世界だと思うww そりゃないぜセニョリータ．
リニューアルしてから初めて書き込むけど (スコア:0)
こんなばかばかしい陰謀論が「スコア:5, 参考になる」だったり
そこにぶら下がってるべきコメントがルート直下になってたり
もう目茶苦茶だな…
Re:リニューアルしてから初めて書き込むけど (スコア:1)
なんかスラドになってからコメントツリーがバグってるらしくてコメントを付けたつもりのところと全然別のところについちゃう
Re: (スコア:0)
要するにSSLを使うと覗き見ができなくなります、と言っているだけだよなあ。
SSLってそのためのものなんだから、そりゃそうだろうと。
Re:リニューアルしてから初めて書き込むけど (スコア:2)
コネクションひとつ張って、その中でやりとりしましょう。
そのトンネルとしてTLS使うよってことだと。
インターネットのプロトコルの話なのに、
個人的な「広告見たくない」ヒステリーに持って行くなんて、
いったい広告にどんなひどい仕打ちをさせられたのか。
Re: (スコア:0)
G社員は帰れ
Re:リニューアルしてから初めて書き込むけど (スコア:2)
えっちい画像を効率よくダウンロードするために決まってるじゃん。
ありがとう。脳みそは大丈夫だ。
まだだ。まだ終わらんよ。 (スコア:0)
HTTP/2がだめなら、HTTP/1.1にフォールバックすればいいじゃない。
同時接続数は1で結構です。それがだめな鯖は用がないですたぶん。
まあ、なんだかんだでHTTP/2対応串がオプソで出るでしょうけど。
顔本からおあつらえ向けなライブラリ出てましたよね。
このくらいの車輪は演習として自作にしようと思って未評価なんですけど。