アカウント名:
パスワード:
HTTPS化が解決策なんていうのは、大昔の古い知識です。
HTTPSでも所謂「通信の最適化」はできますし、今は普通にモバイル回線ではほとんどだれも読まない重要事項説明書や契約書の小さな文字等で同意をとったという名目のもとで行われています。
TLSのハンドシェイクのSNIに関わる平文のハンドシェイク、あるいはその直前に発生するDNSリクエストからFQDNを特定し、YouTubeなどの動画配信サイトに係わるパケットを遅延もしくはパケットロスを発生させると、YouTubeアプリやJavaScriptが自動的にビットレートを下げる（画質を下げる）ことになり、それにより止まらず再生できる環境を維持しつつ、画質を下げと帯域幅を減らすことができるのです。
というか、今時は静的画像が使う帯域なんてどうでもよく殆どが動画関係ですし、YouTubeとかネトフリとかPrimeVideoとかは全部HTTPSですので、その動画を制御できない「通信の最適化」は意味がないので事業者側も導入しません。
この場合肝心なのはできるかどうかではなく、やってるかどうかだけどな
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
SSL/HTTPS化すればいいだけ (スコア:-1)
ケツ丸出しで歩いててレイプされても文句は言えない
HTTPSでも「通信の最適化」はできますが (スコア:0, 興味深い)
HTTPS化が解決策なんていうのは、大昔の古い知識です。
HTTPSでも所謂「通信の最適化」はできますし、今は普通にモバイル回線ではほとんどだれも読まない重要事項説明書や契約書の小さな文字等で同意をとったという名目のもとで行われています。
TLSのハンドシェイクのSNIに関わる平文のハンドシェイク、あるいはその直前に発生するDNSリクエストからFQDNを特定し、YouTubeなどの動画配信サイトに係わるパケットを遅延もしくはパケットロスを発生させると、
YouTubeアプリやJavaScriptが自動的にビットレートを下げる（画質を下げる）ことになり、それにより止まらず再生できる環境を維持しつつ、画質を下げと帯域幅を減らすことができるのです。
というか、今時は静的画像が使う帯域なんてどうでもよく殆どが動画関係ですし、YouTubeとかネトフリとかPrimeVideoとかは全部HTTPSですので、その動画を制御できない「通信の最適化」は意味がないので事業者側も導入しません。
Re:HTTPSでも「通信の最適化」はできますが (スコア:0)
この場合肝心なのはできるかどうかではなく、やってるかどうかだけどな