HTTP

ラウンドトリップタイム (RTT) とは、データパケットが宛先に送信されるのにかかる時間と、そのパケットの確認応答が発信元で受信されるのにかかる時間の長さです。ネットワークとサーバー間の RTT は、ping コマンドを使用して計測できます。

Round Trip Time (ラウンドトリップタイム) - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN

media type。ファイルの種類。

メールやホームページのファイルにくっつけて送られる「このファイルは、こんな種類のファイルですよ」な情報

MIMEタイプ (マイムタイプ)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

MIMEではメールヘッダ中で内容のデータ型を指定するための標準形式であるMIMEタイプ（メディアタイプ）を定めており、“Content-Type:” ヘッダの中で「type/subtype」の形式でデータ形式を指定する。例えば、プレーンテキストは「text/plain」、HTML文書は「text/html」、JPEG画像は「image/jpeg」などと定められている。この仕組みはHTTPなどにも流用され、伝送内容のメディアの種類やデータ形式を指定する標準として広く用いられている。

MIMEとは - 意味をわかりやすく - IT用語辞典 e-Words

もともとはメールプロトコルの仕様だったが、HTTPにも流用された。

• 「Cookie」と「セッション」と「セッションCookie」の違い | 猫型iPS細胞研究所
  • CookieはWEBサーバが発行し、ブラウザが保持するキーと値。ブラウザのWEBコンソールで確認できる
  • sessionはWEBサーバで保持するキーと値
  • IDやパスワードを毎回ブラウザから送信しない。セキュリティ的に問題だから。
  • ログイン成功時にセッションとして値を保持し、ブラウザにはCookieを送信する。以降リクエストされるたびにサーバは保持されたセッションに含まれるIDと、送信されたCookieに含まれるIDを比較して認証状況を判断する。

ログインの流れ。

1. ブラウザ: ログイン成功
2. サーバ: クッキーにセッションID書き込み
3. サーバ: セッションIDをRedis等に保存
   • key: sessionID, value: {token, userID…}
4. ブラウザ: リクエスト時にクッキーを送信
5. サーバ: 送信されたクッキーに含まれるセッションIDと、Redisに保存されたセッションIDを比較。一致していればログイン成功

ログアウトの流れ。

1. ブラウザ: ログアウト実行
2. サーバ: RedisからセッションID

HTTPの解説。

• 機能が追加されたり修正されるのには理由がある。最初のコンセプトはシンプルであることが多い。その流れを知れば、全体を理解しやすくなる
• RFCはRequest For Comment。仕様書なのにこの言葉が使われているのは、軍事用としてスタートしたため。公開するためには意見を募るためという名目が必要だった
• 初期バージョンのHTTPにはバージョン番号がなかった
• MIMEタイプはファイルの種類を区別するための文字列で、電子メールのために作られ、HTTPでも流用された。ヘッダー名はContent-Type。当初の仕様にはなく、ドキュメントを送ることしかできなかった
• 電子メールとHTTPは基本は同じ。ヘッダー + 本文がある。HTTPの通信は高速で電子メールが往復しているのと同じようなもの
• HTTPはファイルシステムのような思想で作られている
• ブラウザによってはリダイレクトを行ったときにメソッドが変更されるものがある。そのため、メソッドが対応してないエラーが表示されることがある
• URNは名前。URLは住所。URLは住所なので、移動するとアクセスできない。いっぽうURNは名前でしかないので、どこにあるかの情報は別に必要
• URIにはURNという名前の付け方のルールも含まれる
• URLの # はフラグメントで、ブラウザ内部でのみ利用されるので、サーバーに送信されるのはフラグメントより前の部分だけ
• <link rel=“canonical” href=“…”> によって、正規のURLをサーバに教えられる。これによって、たとえばURLパラメータにトラッキングIDがついたURLが検索エンジンに登録されるのを防げる
  • あるいは、ソーシャルブックマークで別のURLと認識されることを防げる
• クッキーはHTTPヘッダーをベースにして実装されている。 Set-Cookie: LAST_ACCESS=12:04 とすると、サーバ側がクライアント(ブラウザ)に保存を指示する
  • クライアントは値を保存しておき、次回のアクセス時に Cookie: LAST_ACCESS=12:04 の形式で送信する。サーバ側はこの設定を読み取ることでクライアントが最後にアクセスした時刻を知ることができる
• オリジン … ブラウザはスキーム、ドメイン、ポートの3つの組が同じであれば同一のサイトと判断する
  • ほかのサイトにクッキーなどを使えたら、セキュリティが
• キャッシュしてほしいがされてない場合のチェック
  • GETとHEAD以外のべき等ではないメソッド
  • Cache-Controlヘッダーにprivateが設定されている
  • Cache-Controlヘッダーにno-storeが設定されている
  • Authorizationヘッダーがあるが、Cache-Controlヘッダーにpublicがない
• ETagは、キャッシュがフレッシュかを判断するのにファイルに関連するハッシュ値を使って比較する。これによって、動的な送信内容であってもキャッシュを利用できるか判断できる
• 同じURLでもクライアントに返す結果が異なることを示すヘッダーがVary
• referer はRFCに提案されたときのスペルミス
• 公開鍵 → 南京錠
• TLSの骨格になる、「サーバを認証し、鍵を交換して通信を行う」というフローはTLS1.0から1.3まで大きく変わらない。その一方で、鍵交換の方法、メッセージの暗号化、メッセージの署名方式などそれぞれの場面で使うアルゴリズムの組み合わせをリスト化して管理している。サーバ・クライアント間で共通に使えるものを選択する仕組みにすることで、新しいアルゴリズムを少しずつ導入したり、古いアルゴリズムを非推奨にするといったことを、バージョン間で行いやすくなっている。このアルゴリズムのセットを暗号スイートという
  • 暗号スイートの一覧を出す
  • $ openssl ciphers -v
• data:application/json,{"message": "hello"} をブラウザのURLバーに入れるとそのまま表示できる
• ブラウザがファイルをどのように処理するのか決めているのは、拡張子ではなくサーバから送られたMIMEタイプ
  • Content-Dispositionヘッダーの内容によって、ブラウザはこの動作を変更する
  • 次のヘッダーがサーバから返ってくると、ブラウザはレスポンスは表示用のものではなく、ダウンロードしてローカルに保存するためのものであると認識する
  • Content-Disposition: attachment; filename=filename.xlsx
• 自動ダウンロードの開始(はじまらない場合はクリック、みたいな)の実現方法
  • サーバは2つURLを提供する。ひとつは実際にファイルをダウンロードするページ。もうひとつはHTMLのページを返し、そこにはダウンロードありがとうメッセージと下記のヘッダーを含む
    • <meta http-equiv="refresh" content="0;URL=./download_file">
  • ブラウザがページを表示するときにContent-Dispositionヘッダーがあると、ページの表示をリセットせずにダウンロードだけを行う。まず完了ページをユーザに見せる。ブラウザはコンテンツを表示するときにメタタグを見つけるので、そのページにジャンプしようとする
• ダウンロードの中断、再開は大きなファイルの指定範囲を切り出してダウンロード、という形で可能になっている
  • サーバ側が指定範囲ダウンロードをサポートしている場合には、Accept-Rangesヘッダーをレスポンスに付与する
• ユーザエージェントは正規化されていない情報
• SNS等に貼り付けたときに記事の一部が引用され、画像も表示される
• GETはべき等で、何度実行しても副作用がない。例えばブラウザの挙動はこれに基づいているから、「よく開くページ」にはGETのページだけが表示される。クローラはGETのページだけをクローリングする
• サーバーレスと名付けたのは、アジャイル界隈で有名なマーチン・ファウラー。マーチン・ファウラーは必要以上にかっこいい名前をつけてバズらせてしまうことで有名
• CGIのデメリットは、リクエストを受けるたびにプロセスを起動して処理をさせたあとにプロセスが終了すること。プロセスの起動はOSの中でも重い処理。スクリプト言語であればライブラリロードのコストなどが毎回のリクエストに上乗せされる
  • プロセスを起動しっぱなしにして、ソケット通信でリクエストを処理プログラムに渡す方式のFastCGIが考案された
• Chrome 開発者ツールでの「copy as cURL」機能が面白い

今後新しいフレームワークが出てきたとしても、本章で触れた内容から大きく外れるものが生み出されることはおそらくなく、これらの技術に新しいアイディアが追加されたものになるでしょう。他の章と同様、未来を予測するものではありませんが、将来登場する未知の技術のキャッチアップを高速に行えるようになるはずです。

続々と登場する新機能も「まったく新しい破壊的イノベーション」ではなく、過去の機能では実現できないことや問題があり、それに対する連続的な進化の次の一歩として登場しています。各機能がどのような狙いを持って生み出されたのかを知れば、本書の出版後に出てくる技術も、その延長として、少ない努力で理解できるでしょう。

JSONの仕様。

WebRTCの事例集。

WebRTCの資料。

解説。