Zenn
Open10

Real World HTTPで学ぶWebの仕組み

nabetsunabetsu

クラウド時代のHTTP

単なるブラウザとサーバ間のやり取りを行うプロトコルを飛び越えて、様々なシステム間の通信プロトコルとして利用されている。

より大規模なウェブシステムの構成

DNSやロードバランサーを使って負荷分散する構成が一般的

DNS

リバースプロキシ

外の世界からリクエストが来た時にそのリクエストを最初に受ける存在。
ブラウザから見ると通常のウェブサーバと変わらず、存在を認識することはない。

リバースプロキシという概念としては上記の通りだが、実際に何を行うかはプロキシごとに大きく異なる。

  • CDN
    • エッジそばで稼働し、コンテンツをキャッシュ
  • ロードバランサー
    • リクエストを受け、負荷が均等になるように配下の複数のサーバに処理を振り分ける
  • Gateway?
nabetsunabetsu

HTTP1.1

1997年にRFC2068として最初のバージョンが策定され、2014年に策定が遅れていた箇所について現実に根ざした形で大きなバージョンアップが行われた。

HTTP/2の仕様は通信の高速化など低レイヤーに特化しているため、通信内容やブラウザとサーバー間のコミュニケーションの仕様はHTTP/1.1で策定されている内容が現役。

Keep-Aliveによる通信の高速化

TLS

PUTメソッドとDELETEメソッドの標準化

OPTIONS, TRACE, CONNECTメソッドの追加

OPTIONS

サーバが受け取り可能なメソッドの一覧を返す。

OPTIONSはブラウザが別のサーバにリクエストを送信する前に事前確認として使われることがある。

プロトコルのアップグレード

  • HTTPからTLSを使った安全な通信へのアップグレード
  • HTTPからWebSocketを使った双方向通信へのアップグレード
  • HTTPからHTTP/2へのアップグレード

現状プロトコルアップグレードはWebSocket用になっている。
アップグレードでTLSを使ってもセキュリティが守られない問題があり、TLSが持つハンドシェイク時のプロトコル選択機能(ALPN)を使うことが推奨されている。

そのため、HTTP/2ではこのアップグレード機能は削除されている。

バーチャルホストのサポート

一台のウェブサーバで複数のサービスを運用できるように。

チャンク

全体を一括で送信するのではなく小分けにして送る。

nabetsunabetsu

HTTP/2 、HTTP/3のシンタックス

変わらないこと

HTTP/2

ポイントは通信の高速化

HTTP/3

QUICというUDPソケット上で動作するプロトコルがもとになっている。

新たなJavaScript用の通信API

  • Fetch API
  • Server-Sent Events
  • Websocket
  • WebRTC

HTTPウェブプッシュ

nabetsunabetsu

HTTP1.0のセマンティック

クッキー

クッキーはウェブサイトの情報をブラウザ側に保存する仕組み。
データベースとは逆にクッキーの場合はサービス側がクライアント(ブラウザ)にこれを保存しておいてとクッキーの保存を指示する。

クッキーもHTTPのヘッダーを利用して実装されている。
サービス側は以下のようにキーバーリューの形式でサーバからのレスポンスヘッダーに指定する。

Set-Cookie: LAST_ACCESS_DATE=Jul/31/2016 
Set-Cookie: LAST_ACCESS_TIME=12:04

クライアントは保存した内容を次回のリクエスト時に送信することでサーバ側はこの設定を読み取ることで最後にアクセスした日時を知ることができる。

HTTPはステートレスを基本に開発されたが、クッキーを使うことであたかもステートフルのように見えるサービスを提供できる。

クッキーが設定されるのはサーバからHTMLページを読み出すブラウザのリクエスト時だけではなく、XMLHttpRequestやFetchAPIを使ったリクエストのレスポンスでもサーバ側がSet-Cookieヘッダーをつけてくるとクッキーとして保存される。

クッキーの間違った使い方

  • 永続性
    • クッキーはブラウザのローカル領域に保存される
    • デバイスを変えると過去のクッキー情報にはアクセスできなくなる
    • 確実に保存されるわけではない(シークレットモード等の理由により保存されないこともある)
    • そのため、なくなっても問題がない、またはサーバ側の情報から復元できるデータ以外を格納するには向いていない
  • データサイズ
    • クッキーはヘッダーとして常にHTTP通信に付与され、通信速度に影響を与えるためサイズに制約がある(目安として最大容量4キロバイト、ドメインごとに50クッキー、全部で300クッキー)
  • セキュリティ
    • センシティブな情報を保存するのには適していない

認証とセッション

BASIC認証とDigest認証

  • BASIC認証
    • ユーザ名とパスワードをbase64エンコーディングしたもの
    • base64エンコーディングは可逆変換であるため、サーバ側で元のユーザ名とパスワードに復元して取り出して比較することができる
    • SSL/TLS通信を使っていない状態で通信を傍受されると通信内容から簡単に認証情報が漏洩してしまう
  • Digest認証
    • ハッシュ関数を使っているため、簡単には元の値を復元できない

上記のどちらも現在はあまり使われていない。

  • 特定のフォルダ以下を見せないと言う使い方しかできない
  • リクエストごとに計算を行う必要がある
  • ログインした端末の識別ができない

クッキーを使ったセッション管理

フォームを使ったログインとクッキーを使ったセッション管理の組み合わせ。

2度目以降のアクセスではクッキーを再送することでログイン済みのクライアントであることがサーバ側でわかる。

6.4.1 セッション管理

署名付きクッキーによるセッションデータの保存

クライアント側にサーバから電子署名済みのデータを送る。

データはクライアント側で持たないので、同じユーザがスマホとPCなど別のブラウザからアクセスした場合、データは共有されない。

キャッシュ

リファラー

ユーザがどの経路からウェブサイトに到達したかをサーバが把握するためにクライアントがサーバに送るヘッダーのこと。

nabetsunabetsu

HTTP/2のセマンティクス

オープングラフプロトコル(OGP)

ソーシャルネットワークで使われるメタデータ。
OGPが設定されているウェブサイトのURLをSNS等に貼り付けると記事の一部が引用され、画像も表示される。URLだけが表示されるのと比べると他のユーザから興味を持ってもらえるチャンスが増える。

QRコード

AMP(Accelerated Mobile Pages)

AMPはモバイル高速化のための仕組み。

ネットワーク事業が悪い国であればユーザ体験の大きな向上が得られる。

nabetsunabetsu

JavaScriptによるブラウザからの動的なHTTPリクエスト

nabetsunabetsu

セキュリティ

従来型の攻撃

クロスサイトスクリプティング