# 2021-01-14 第1回メンターセッション

## HTTP/1.1とHTTP/2の違いについて

> ざっくりとした質問ですみません。
HTTP/2について、以下のような認識です。
HTTP/2では、並列でリクエスト・レスポンスを実行できること。
フレームというデータ形式？でデータを送信すること。
このフレームというデータの中身は、HTTP/1.1で送信するデータとは異なるのでしょうか？
また、HTTP/1.1とHTTP/2の違いについて説明していただきたいです。

- HTTP/1.1は、コネクションを貼れる数に制限があった（６個）→無制限に？
- HTTPSに対応していなければHTTP2は使えない
- ヘッダを圧縮してくれるので大容量のヘッダを送る際は効果が出る
- HTTP/1.1 文字列を読む⇨空行を読んで区切りを見つける
- HTTP/2 バイナリで送信できるので効率が良い
- サーバー側で対応されていれば、自動的にライブラリがHTTP/2を使ってくれる
- コネクションを貼るコストが入らないから、高速化される。
- ヘッダの書き方が少し違うくらいで、開発者がHTTP/1.1と/2のバージョン差を強く意識することはあまりない。
- 超大量のファイルの通信では高速化されるけど、データ量が少ないときはヘッダの区切りくらいでスピードに差があることはなさそう。
- Node.jsであれば、https://github.com/molnarg/node-http2 みたいにライブラリがHTTP通信の隠蔽をしているので、あまり意識しない。
- cookieの仕組みはそのまま使える。
- ブラウザがHTTP2対応の場合は、勝手にブラウザがHTTP2通信を始める
- それ以外の通信はCDNを使用するため、開発者が明示的にHTTP２対応をするケースは少ない（圧縮するにしてもJSONなどはもともと早い、画像はCDNから持ってくるのでCDN側がやってくれる）
- CDNを使わずに画像を扱う場合も、ストリームを扱うライブラリに内包されている

## リクエストのAcceptヘッダとレスポンスのContent-Typeが一致しない場合について

> Acceptヘッダで指定していないものがレスポンスのContent-Typeで返ってきた場合、どのような挙動を取りますか？
・実際に送られてきたデータの中身を確認し、データの種類を特定して処理を行う？
・ブラウザ依存でエラーになったりもする？

- 大半のブラウザではエラーにならない
- RFCとしては、サーバー側が対応できるコンテンツを返せない場合、ステータスコード406を返すことが推奨されている
- バグとして考える方が自然だと思う
- Content-Typeが一致しない場合、レスポンスのbodyからデータが取れない可能性があるが、これはフロントエンドのコードで考慮して作っておくべき
- 実際のサーバは"頑張って"返せるコンテントタイプで返すようになっていることが多い（ステータスコード406の実装はあまり見ない）
- 昔のブラウザ（IE）はcontent-sniffingといって、ファイルの最初数文字を読み取ってcontent-typeを判断する機能があった（pngなどは刻印してあるのでそれで読み取れる）
ただし、それを利用して、ファイルの先頭にスクリプトを埋め込む攻撃などがあるため、最近のブラウザでは`no-sniff`を指定してある。
IE対応などが必要な場合は、手動で以下のように記述するのが良い
`X-Content-Type-Options: nosniff`
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

## ホスト・ドメイン・FQDNについて

> 以下のようなURLがある。
https://www.example.com
それぞれの名前と示す場所は以下の通り。
ホスト -> www
ドメイン -> example.com
FQDN -> www.example.com
以下の認識であっているか？
ドメインが同じ ⇒ 同じIPアドレス
FQDNが異なる ⇒ 同じIPアドレスとは限らない

- wwwの部分はサブドメインとか言われることもある。
- .com や .co.jp はトップレベルドメイン(TLD)と言われている
- github.ioは.ioがTLDではなく、github.ioがTLD（public suffix）
- https://publicsuffix.org/ にTLDが載っている。
- ドメインが同じ ⇒ 同じIPアドレスとは限らない　が正
- FQDNが異なる ⇒ 同じIPアドレスとは限らない　⇒　True
- ドメインを取得したら、サブドメインは自由に階層をつけて取得できる。（例）www.api.std.hoge.com
- cnameで `www.example.com` と `example.com` を同じIPアドレスで指定しないと自動で同じIPアドレスを向くことはない。
- ドメイン名を取得した場合、同じドメイン名の異なるホスト名を他の人に取得されるということはない

## Cookieの件
>Cookieの件ですが、SameSite属性がNoneの場合と、Laxの場合は、ページ上のリンクをクリックした場合、遷移先のページ（サーバ）にはcookieが送られるという認識は合っていますでしょうか。
MDNで調べたらそのように書いてありましたが、危険ではないですか？

- SameSiteについて
英語版の方が分かりやすい？
元記事（https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie/SameSite）
Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (i.e. when following a link).

- SameSite=Laxの場合、トップレベルナビゲーション（ページ遷移）をした際にCookieが送信されるが、送信されるCookieはあくまで遷移先ドメインのCookieなので、遷移元のCookieが送信されることはない。

## 決定事項
- なし

## Action Items
- なし

###### tags: `Team-2`