Slide 1

Slide 1 text

YouTube Live (2020.08.27 Thur. 21:00~)

Slide 2

Slide 2 text

話す人 現役のエンジニア二人 赤貝が好きな CTO と デザイン勉強中のエンジニア @mu_vpoe 最近は SwiftUI で macOS アプリづくりが 趣味 ムー zaru @zaru CTO, Love 赤貝, JavaScript, Firebase, Web Components. Twitter フォロー お願いします!

Slide 3

Slide 3 text

主な登場人物 ブラウザー君 ユーザ君 DNS さん ルーターさん ISP さん・IX さん サーバーさん

Slide 4

Slide 4 text

第一部 Web ページは どこにある? 第一部 Web ページは どこにある?

Slide 5

Slide 5 text

はーい 第一部 Web ページはどこにある? http://example.com/hoge っていうページを取ってきて〜 ブラウザー君 ユーザ君

Slide 6

Slide 6 text

ユーザ ブラウザ サーバ URL を指示 HTML をもらう HTML レンダリング ① ② ③ ④ サーバさんの ところに行けば いいんだ Web ページを見に行く流れ

Slide 7

Slide 7 text

http://example.com/hoge スキーマ ホスト パス トップレベルドメイン セカンドレベルドメイン URL は大きく 3つの構成に分かれる スキーマ : 通信方式の種類( https や ftp など) ホスト : サーバの識別名 パス : リソースの中の場所 サーバは どこにある の?

Slide 8

Slide 8 text

http://example.com/hoge なるほど サーバに辿り着く には IP アドレス が必要だよ 仮想的な場所 ホスト名 物理的な場所 IP アドレス ( 例 203.0.113.0.9 ) ホスト名だとサーバの 場所は分からない

Slide 9

Slide 9 text

DNS は全ての答えを知らない example.com の IP アドレス 教えて 僕は持って ないなぁ

Slide 10

Slide 10 text

担当 DNS に再起的に問い合わせ example.com の IP アドレス 教えて 知ってる? 知らんけど .com の情報を知っ てるサーバなら分か るから教える〜 example.com の情 報を知ってるサーバ なら分かるから教え る〜 exmaple.com は 203.0.113.0.9 だ よ〜 2LD 権威サーバ TLD 権威サーバ ルートサーバ ① ② ③

Slide 11

Slide 11 text

● dig ホスト名 ● nslookup ホスト名 ホスト名を IP アドレスに変換するコマンド 僕に聞いてね 小ネタ

Slide 12

Slide 12 text

DNS はキャッシュする 次、聞かれたときの ためにキャッシュし よう DNS のキャッシュ期間は、設定した TTL 値によっ て決まる。TTL が長いと DNS レコードを変更して も反映されるまでに時間がかかる。 小ネタ

Slide 13

Slide 13 text

IP アドレス 203.0.113.0.9

Slide 14

Slide 14 text

203.0.113.0.9 IP アドレスの場所は…? どこにあるの? 僕に聞いて〜 ルーターさん

Slide 15

Slide 15 text

こっちいったら あるかも〜 IP アドレス通信の経路 203.0.113.0.9 に行きたい〜 IPS・IX と言ったインターネット上 の回線が相互に接続しあい、持って いる経路表をもとに誘導する

Slide 16

Slide 16 text

● traceroute IP アドレス or ホスト名 指定 IP アドレスまでの経路を表示するコマンド 僕に聞いてね 小ネタ

Slide 17

Slide 17 text

どうやってサーバ と会話すればいい んだろう? … サーバとの会話は握手 サーバーさん

Slide 18

Slide 18 text

TCP 3way handshake で挨拶する 会話を3つの ステップで開始 ① SYN ② SYN + ACK ③ ACK SYN : Synchronize ACK : Acknowledge

Slide 19

Slide 19 text

S : SYN S. : SYN + ACK . : ACK ● tcpdump port 見たいポート番号 サーバとの会話の中身を見ることができるコマンド 小ネタ

Slide 20

Slide 20 text

80 番ポートの /hoge っていうのください GET /hoge HTTP/1.0 Host: example.com User-Agent: curl/7.64.1 Accept: */* リクエストヘッダでページを要求 メソッド バージョン HTTP/1.1 や 2 などがある パス リクエストヘッダ : 区切りの key-value リクエストする側の情報 などを記載している

Slide 21

Slide 21 text

GET の /hoge に 該当するコンテン ツください アプリケーションサーバーさん (Web) サーバーさん ディスクくん メソッドとパスに応じた コンテンツを返す GET の /hoge な ら僕が持ってる〜 Web サーバ単体でコンテンツを返 すこともあるし、図解のようにアプ リケーションサーバが別にあり、そ こから返すこともある。サーバの構 成による。

Slide 22

Slide 22 text

アプリケーションサーバーさん Web サーバーさん Web サーバと アプリケーションサーバ 一部、重なっているところはあるが、一般的には静的コンテンツや ルーティングなどサーバの基本的なことを担うのが Web サーバ。 特定の言語を動かすものがアプリケーションサーバ。片方だけでやる 場合もあるし、両方連携してやる場合もある。 小ネタ

Slide 23

Slide 23 text

HTTP/1.0 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 1256 Connection: close レスポンスヘッダとボディ レスポンスヘッダ どうぞー : 区切りの key-value レスポンスしたページ の情報などを記載して いる ステータス 404 や 500 などエラーや ページの状態を伝える Example Domain ボディ ヘッダとボディに 1つの改行が区切 りとしてある

Slide 24

Slide 24 text

HTML

Slide 25

Slide 25 text

ありがとー でも、画像とか CSSがないなぁ HTML 持ってきた〜

Slide 26

Slide 26 text

画像とかも 持ってきて〜 HTML …

Slide 27

Slide 27 text

第二部 効率的に会話する 第二部 効率的に会話する

Slide 28

Slide 28 text

リクエスト レスポンス このやりとりを、HTML + リンクされている画像や CSS ファイルの数分、繰り返さないといけない x ファイルの数 第二部 効率的に会話する

Slide 29

Slide 29 text

KeepAlive する TCP 3way handshake が面倒くさいので、 HTTP1.1 で デフォルトになった HTTP KeepAlive して同じ接 続を使い回す 疲れた

Slide 30

Slide 30 text

① SYN ② SYN + ACK ③ ACK データもらう + 接続終了の通信 KeepAlive なし KeepAlive あり ① SYN ② SYN + ACK ③ ACK データもらう + 接続終了の通信 ① SYN ② SYN + ACK ③ ACK リクエスト データもらう + 接続終了の通信 また handshake しないといけない 接続を閉じずに再利用してい るので handshake は必要な い

Slide 31

Slide 31 text

サーバから返されるレスポンスヘッダにある Content-Type でファイル種類を判断する Content-Type で分類する 小ネタ http://example.com/photo.jpg 拡張子では判断しない HTTP/1.0 200 OK Content-Type: image/jpeg レスポンスヘッダ ( MIME )

Slide 32

Slide 32 text

GET /hoge HTTP/1.0 Host: example.com User-Agent: curl/7.64.1 Accept: */* 対応可能なコンテンツを提案 リクエストヘッダ ブラウザが対応可能なコン テンツの種類を MIME で伝 えることを、コンテンツネ ゴシエーションと呼ぶ accept: image/webp webp 対応してます webp あげます 小ネタ

Slide 33

Slide 33 text

うーん さっきのページをもう一回見せて

Slide 34

Slide 34 text

ブラウザキャッシュ HTTP/1.1 200 OK cache-control: public, max-age=600 etag: "de5659f2" レスポンスヘッダ キャッシュしていい期間や ルールなどを提示 コンテンツが更新されている かどうかの判断に使う ありがとう〜 これは 600 秒だ けキャッシュし ていいよ

Slide 35

Slide 35 text

cache-control: public, max-age=600 etag: "de5659f2" 600秒以内のリクエスト は、キャッシュを参照す る レスポンスヘッダ まず、サーバにファイルを取りに行く 再リクエストが 600 秒以内の場合 Cache-Control の動き

Slide 36

Slide 36 text

GET /hoge If-None-Match: "de5659f2" リクエストヘッダ HTTP/1.1 304 OK cache-control: public, max-age=600 etag: "de5659f2" コンテンツ更新 されてる? してないから、 またキャッシュ していいよ ステータス 304 の場合は、コンテ ンツをダウンロードせず、手元の キャッシュを利用する 再リクエストが 600 秒を超えた場合 レスポンスヘッダ ① ② ③ ETag の動き 送られてきた ETag を見 て、サーバが最新のファ イル状況と比較する

Slide 37

Slide 37 text

第三部 cookie で 状態を復元する 第三部 cookie で 状態を復元する

Slide 38

Slide 38 text

はーい 次は EC サイトに ログインしてきて〜 第三部 cookie で状態を復元する

Slide 39

Slide 39 text

POST /login HTTP/1.1 リクエストヘッダ id=zaru&pass=xxxx リクエストボディ ログインします zaru さんですね POST でデータ送信

Slide 40

Slide 40 text

はーい ありがとー、じゃあ商品 ページに行ってきて〜

Slide 41

Slide 41 text

あなたは誰? さっきログインした zaru です。 商品ページ見せて

Slide 42

Slide 42 text

HTTP はステートレス リクエスト1 リクエスト2 リクエスト同士は互い を知らない状態でサー バに受け取られる

Slide 43

Slide 43 text

Cookie でステートフルへ リクエスト1 リクエスト2 cookie と言う状態の情報が入った データをサーバに渡して、リクエ スト1 との関連を作る

Slide 44

Slide 44 text

HTTP/1.1 200 OK set-cookie: key=value; expires=Fri, 25-Sep-2020 22:21:50 GMT; path=/; domain=.example.com; Secure; SameSite=none レスポンスヘッダ ログイン情報を cookie に保存し ておいて cookie はサーバからもらう cookie 保存の指示 保存するキーと値 cookie の保存期間 やルールなどの情報

Slide 45

Slide 45 text

GET / HTTP/1.1 cookie: key=value; リクエストヘッダ ログイン情報の cookie を送ります cookie をサーバへ送る はい zaru さん ですね

Slide 46

Slide 46 text

第 n 部 Web の未来 第 n 部 Web の未来

Slide 47

Slide 47 text

XMLHttpRequest? Ajax? SSL/TLS? HTTP2? HTTP3? OAuth? JWT? fetchAPI? WebRTC? WebPush? webcoket? AMP? CDN? ロードバランサ? ブラウザー君の冒険は まだまだ続く…!(かも)

Slide 48

Slide 48 text

ありがとうございました! 次回は... コードレビューをやります! 木曜21時から30分 質問感想など呟いていただけると嬉しいです! - ハッシュタグ #mu_zaru - ツイッター情報 @mu_vpoe , @zaru チャンネル登録 Good ボタン お願いします! ムーザルちゃんねる