Sakiのプログラミング学習ブログ

プログラミングについて学んだことや、学習の振返りを書いています。

『Web技術の基本』を読んで学んだこと

読書ノート 輪読会

f:id:Saki-Htr:20210228162526p:plain


フィヨルドブートキャンプで、「Webを支える技術 -HTTP、URI、HTML、そしてREST」(以下、「Webを支える技術」)を読むという課題があったが、必要な前提知識に不足があり、理解が難しかった。

この本が難しい場合は『イラスト図解式 この一冊で全部わかるWeb技術の基本』(以下、「Web技術の基本」)が、イラストが多く最初にイメージを掴むのに最適とアドバイスをいただいたので、そちらを先に読むことにした。

www.amazon.co.jp

読み終わったので、読んだ中で学んだこと・調べたこと、感想を書いた。


<<無断転載にならないよう気をつけて書いたつもりですが、もしご指摘等ありましたら修正あるいは削除させていただくつもりです>>


本の構成

ch1. Web技術とは
ch2. Webとネットワーク技術
ch3. HTTPでやりとりする仕組み
ch4. Webのさまざまなデータ形式
ch5. Webアプリケーションの基本
ch6. Webのセキュリティと認証
ch7. Webシステムの構築と運用

ch1. Web技術とは

学んだこと

  • HTMLを人が見やすいように変換しているのは、Webサーバーではなく、Webブラウザ。

Webページが表示される流れ

  • 一度のコンテンツ転送で送られてくるファイルは1つ。
  • 画像など他のファイルがそのコンテンツに埋め込まれていて、転送が必要になったときはもう一度Webサーバーに要求してファイルを取得する。
  • 疑問:例えば、そのWebページに画像のファイルが１０枚あったら、コンテンツに1回要求+画像ファイルの要求10回で11回要求するということか？
    →以下の記事によれば、読み込むファイル1つにつき、HTTPリクエストが1回増えてしまうため、ファイル数が多いほど、表示までの時間が遅くなってしまう とあるので、やはり、ファイルの数の分リクエストとレスポンスが行われているようだ。

なぜ全てのサイトがSSL化しないのか？

調べたこと

教わったこと

この疑問についてtechplay女子部のエンジニアの方が答えてくださったので、以下にまとめた。

→まとめると、今はSSL化することが当たり前で、していないサイトはほとんど無い。

CGIの仕組み

普通のホームページはスーパーで売っているお寿司と同じです。作り置きです。CGIでは、注文が入ってからホームページのファイルを作ります。
１．ホームページを見る人の注文をWebサーバ上にあるプログラムが受ける
２．注文を受けたプログラムが何かお仕事をする
３．注文を受けたプログラムがホームページのファイルを作って、ホームページを見る人に渡してあげる
の流れですね。
この流れを実現するためのあれやこれやがCGIです。

  • 注意:CGIはWebサーバ上でプログラムを動かすための「仕組み」であって、プログラム自体を表す言葉ではない

クライアントサイド・スクリプト

どんなプログラムかイメージしづらかったので、パスワードを登録する時に例えて考えた

  • 新しいWebサービスを使うために新規ユーザー登録をするとき、大抵は「パスワードの文字数は8文字以上、大文字小文字を混ぜる」などの条件がある。
  • クライアントがその条件を満たしてパスワードを設定できたかどうかは、誰が判断しているのか?
  • Webは同時に何百人もの人がアクセスしてくるので、サーバにやらせるのは非効率。
  • Google Chrome、Internet Explorerなどのブラウザが、送られたプログラムを解析し、ユーザが入力したデータなどをチェックしてからサーバへ送信している。
    つまり、ユーザーがパスワードを条件通りに入力したかチェックしているのは、ブラウザ。
  • このチェックしているプログラムが、クライアントサイド。スクリプト。

RESTful(RESTっぽい)とは

  • RESTは、「これが REST な実装である」という厳密な定義があるわけではない。
  • REST はアーキテクチャスタイル。スタイルなので、「REST っぽい」「REST っぽくない」といった語られ方をする。

考えたこと

  • HTMLを人が見やすいように変換してくれているのが誰かは考えたことがなかった。なんとなくWebサーバーがやっていると思っていた。
  • SSL化の背景についてここまで深く知ることは自力では不可能だったと思うので、教えてくださったエンジニアの方に深く感謝。今使われている技術がどういう背景で繁栄していったのかを知るのは楽しい。

ch2. Webとネットワーク技術

学んだこと

HTTP

TCP/IP

  • TCP/IP(プロトコルの集まり)は、役割ごとに4つの階層に分かれる。レイヤー1~4。
    クライアントとサーバーの両方にこの階層があり、同じ階層同士でプロトコルに従った処理をしている。
  • 処理の流れ:レイヤー1から処理が始まって、レイヤー1→2→3→4とデータが渡されていく
  • 階層を7つに分けた考え方もある=OSI参照モデル

IPアドレス/ドメイン

考えたこと

  • メンターさんに、TCP/IPの階層についてお聞きしたら、
    • Webエンジニアとして働く上では、「アプリケーション層/HTTP」の部分を理解していればOK
    • 他の階層については深く理解している必要はなく、階層になっているということが分かっていればOK

とのことだったので、今は、「階層に分かれている」ということを覚えておく。

ch3. HTTPでやりとりする仕組み

学んだこと

HTTPメッセージ

  • HTTPメッセージ=HTTPリクエストとHTTPレスポンスの2種類

HTTPリクエスト/HTTPレスポンス

  • HTTPリクエストの構成は、3つの構成でできている。
    リクエスト行/(メッセージ)ヘッダー/メッセージボディ
    • リクエスト行:どうしたい
    • ヘッダー:何を
    • メッセージボディ:どんな方法で
  • もし要求して応答されたwebページを解析したときに、画像のリンクがあったら、もう一度要求を送る。

f:id:Saki-Htr:20210227110159p:plain (HTTP入門 - とほほのWWW入門より引用)

HTTPメソッド

  • HTTPリクエストメソッド:簡単に言うと、WebブラウザからWebサーバに対しての命令(リクエスト)。
  • リクエスト(命令・お願い)には色んな種類がある。
  • Webサイト閲覧で主に使うのはGETとPOST
  • 主に使われるメソッド
メソッド 動作
GET ページの取得を要求。WebブラウザからWebサーバに渡す値をURLの後ろにくっつけて送るやり方
HEAD ヘッダのみの要求
POST データをwebサーバーに送信
PUT webサーバーが保管してるコンテンツのアップロード(書き換え)
DELETE 指定したデータを削除
CONNECT SSL

HTTPバージョンの変遷

HTTP/1.0以前

  • リクエストを送信するたびにコネクションを確立し、レスポンスでデータを送った時にコネクションを閉じていた。
  • つまり、画像が埋め込まれていたらそのたびにリクエストを送る仕様になってるので、たくさん画像が埋め込まれているとリクエストの回数分だけコネクションの確立&閉じるをしなければならなかった。=効率が悪かった!

HTTP/1.1~

  • コネクションを継続利用できる、「HTTPキープアライブ」ができた。
  • HTTPパイプライン:複数のリクエスト&レスポンスを同時並行で行う。

HTTP/2

  • HTTP/2はgoogleが提案したSPDYという通信の高速化を目的としたプロトコルが土台。
    = HTTP/2の高速化を担う部分はほぼSPDYの機能を使っている。
  • 2での改良点①
    • 1.1のHTTPパイプラインは、HTTPリクエストの順番通りにレスポンスを返す。
    • つまり、1つのレスポンスの処理が重いと遅くなってしまう(高速道路で渋滞が起こっているイメージ)という問題があった。
    • この解決のために、コネクション上に仮想的な通信経路=ストリームを作った。
  • 2での改良点②
    • データのやりとりがテキスト形式→バイナリ形式に。前はテキスト形式だったので、バイナリ形式のデータを変換するのに負荷がかかっていた。
      • バイナリ形式のデータとは:コンピュータが直接的に処理するために２進数で表現されたデータ
    • そのため、ヘッダー情報を、2回目のやり取りからは追加情報(差分)だけ送るようにした。
  • 2での改良点③
    • 前はブラウザからリクエストが来たときに、画像が埋め込まれていたらその都度リクエスト&レスポンスのやり取りをしていた。
    • サーバーが、リクエストが来たときに必要なファイルを判別して、画像などのファイルもすべて返すようになった。(サーバープッシュ)

HTTP/3

  • 本には載っていなかったが、調べたら、HTTP/3がリリースされていた。
  • HTTPはステートレスなプロトコル。それをステートフルにしてくれるのがCookie。
    例:ショッピングサイトのカートに入れた商品を次にログインしたときにも覚えてくれる。
  • Cookieが使用される目的は大きく分けて次の２つ
    1. Webサイトでユーザー情報を保存し、利便性を向上する
    2. ユーザー情報を取得し、広告配信に利用する
  • 仕組み
    1. ブラウザが初めてサーバーへ接続
    2. サーバーが、ブラウザに対してレスポンスを返す時に、ブラウザに保存しておいてほしい情報をCookieとして返す。 HTTPレスポンスに、set-cookieヘッダーを含めることで、Cookieを送信できる。
    3. 2回目以降、ブラウザはサーバーへ接続した時、HTTPリクエストにCookieヘッダを含めることで、Cookieを送信する。

セッション

  • セッション:クライアントがWebサーバーに接続してから切断されるまでの一連の行動を表す。
    クライアントとサーバーで通信を行う場合、クライアントからサーバーへ接続した時点でセッションが始まり、サーバーから切断するとセッションが終了する。この一連の流れを管理することをセッション管理という。
  • 例えばECサイトには、商品を探し、カートに入れ、購入するという一連の流れがある。このように同一利用者からのアクセスを関連性のある一連のアクセスとして扱いたい場合、Cookieを使ってセッション管理が行われる。
  • セッションID:一連のやりとり（セッション）を識別するための一意の数字。銀行の受付番号と同じ。セッションIDをクッキーに格納してやりとりをすることによってステートフルな通信ができる。
  • 各セッションにはIDが割り振られている。
  • セッションのデータはサーバーに保存され、セッションIDはブラウザに保存される。
    ブラウザがサーバーにリクエストする時、セッションIDを渡す→サーバーがIDに対応したデータを返す。
  • Cookieでユーザーの判別が行われ、セッションによってそのユーザーがとった行動と結びつけられることで、「通販サイトのカート内商品の保持」といった機能が実現される。

Cookieの問題点

  • Cookieは便利だが、プライバシー面・セキュリティ面において注意しておくべき点もある。
  • Tracking Cookie（トラッキングクッキー）
  • セッションハイジャック
    Cookieの識別子が漏えいする:右矢印:CookieにはサイトのセッションIDとともに、ログイン情報が含まれていることがある:右矢印:情報自体がSSLなどで暗号化されていても、セッションIDさえわかってしまえばサーバーに送ることで、ログイン状態が再現されてしまう。

考えたこと

  • HTTPが登場したのは1990年代らしい。私が生まれたのが1995年なので、想像していたよりも最近で驚いた。
  • HTTPの進化に感動した。私が小学生の時に父が使っていたPCは、Webページを表示するのにとても時間がかかり、画像も少しずつジワジワと読み込んで表示されていた。今はそんなことは有り得ず、wifiなどのネット回線に問題がなければ、たくさん画像が使われたWebページでも一瞬で表示できる。今ネットを便利に使えているのは、HTTPの進化のおかげなのだな、と思った。
  • HTTPのバージョンを知る方法を調べた。
    デベロッパーツールを開き、networkタブのProtocolを見ると、バージョンが分かる。

f:id:Saki-Htr:20210227112606p:plain

ch4. Webのさまざまなデータ形式

学んだこと

スクリプト言語

フィード

  • webサイトなどの更新履歴を配信するためのファイル。中身はハイパーリンクの集まり。
  • ブログやニュースサイトで使われる
  • webサイトにアクセスすることなく、最新情報をチェックできる

フィードリーダー

  • フィードを取得&管理するためのソフトウェア
  • お気に入りのwebサイトを登録しておくことで、わざわざそのサイトにアクセスしなくても最新情報や更新情報をチェックできる便利な情報収集ツール
  • ウェブサイトの見出しや要約、更新情報を記述したフィードを巡回・受信し、一覧表示するソフトウエア。RSS形式のフィードを扱うRSSリーダーを指すことが多い。
    = RSSリーダー

フィードリーダーは現在は衰退している

YouTubeやニコニコはストリーミング配信ではないのか

  • 本では、

YouTubeやニコニコ動画などの多くの動画配信サービスはプログレッシブダウンロード配信

と説明されていたが、ストリーミング配信ではないのかと疑問に思ったため、調べた。

3つの配信方法の特徴・違い

  • 音声･動画の配信方法は3つある。
  • ダウンロード配信
    • ダウンロードを全部完了するまで再生できないが、完了すればいつでも再生できる
    • 例：Amazonプライムの動画をDLした時、途中までしかできていないと視聴することができない。
  • プログレッシブダウンロード配信
    • ダウンロードしながら再生
    • 疑似ストリーミング
    • 配信したファイルはユーザー側に残る
  • ストリーミング配信
    • ファイルを細かく分割し、細切れにしたデータをユーザーに配信して再生する
      例:ニコニコ生放送などのライブ配信
    • プログレッシブダウンロード配信との大きな違いは、動画データを端末にダウンロードさせない点。
    • 利用者のパソコンやタブレットに動画データが残らないから情報漏えいの心配がなく、セキュリティ的にとても安心な配信。

→YouTubeを視聴する時に、見たい動画のURLや配信ページにブラウザで接続した時にしか視聴できないので、「いつでも再生できる」という説明が理解できなかった。ストリーミング配信ではないのか？

YouTubeを調べてみた

  • YouTubeで動画を見ると、映像の下に赤いラインとグレーのラインがある。赤いラインは再生した部分を示し、グレーの部分はダウンロードした部分を示している。 →このグレーの部分は、ダウンロードしている部分だった。
    f:id:Saki-Htr:20210227124307p:plain

  • 濃いグレーの部分は、まだダウンロードが完了していない部分。ダウンロード配信では、全部ダウンロードが完了していないと、視聴することができないので、YouTubeはダウンロード配信ではない。

  • よって、YouTubeやニコニコ動画は、プログレッシブダウンロード配信であることが分かった。
  • プログレッシブダウンロード配信も動画データが一時的に端末へ保存されているので、目に見えづらかっただけで、YouTubeを視聴している時に、一時的にスマホやPCに動画が保存されていることが分かった。

考えたこと

  • このチャプターでは、webで使われている様々なデータ形式について学んだ。学習でさわったことのあるHTMLやCSSについてはすんなり理解できたが、この本で初めて知ったJSON,DOM,マイクロフォーマット,フィードなどは、触ったことがないので、読んでもイメージしづらかった。実際に学習や仕事でさわることになった時に、また読んで理解を深めたい。
  • 自分が使っていたAmazonプライム,Netfrix,YouTubeなどの動画配信サービスの配信方法が何かについて、考えるのが面白かった。

ch5. Webアプリケーションの基本

学んだこと

Webクライアント

  • Webクライアント = Webブラウザのみを指すと勘違いしていたので、調べて整理した。
  • Webクライアントとは
    • Webサーバー（Wepアプリケーション)にリクエストを投げるプログラム。
    • ブラウザ以外でも、http(s)で通信しているものは全Webクライアント。
      1番使われているものはWebブラウザだが、スマホアプリ、WIndowsやMacの専用アプリケーションなど、WebサーバーとやりとりしているものはWebクライアント。
    • つまり、Webブラウザ=Webクライアントでなく、WebブラウザはWebクライアントの(代表的な)一種。

クライアントプログラム

CDN

  • CDNが何か、本の説明だけでは理解できなかったので、調べたことを整理した。

  • インターネットの世界にも現実世界と同じように「距離」の概念がある

  • 自分の使っているwebブラウザと相手のwebサーバーの距離が近ければ、それだけwebページを早く見られる。
  • 世界各地にwebサーバーを設置し、大元のwebサーバーからwebページのファイルをコピーしておく(お互い連携している=1つのネットワーク)
  • これによって、ホームページを見る人は、自分の近くにあるWebサーバからホームページのファイルを受け取れる。
  • このwebサーバーが集まったネットワーク(世界各地に分散されたキャッシュサーバーの集合体)をCDNという！

Ajax

  • 同期通信には、「リクエストを送ってレスポンスがかえってくるまで、クライアントは待つことしかできない」という欠点がある。
  • Ajaxという技術では、JavaScriptがクライアントとして直接webサーバーと通信をする。必要なデータだけやり取りするため、同期通信よりもサーバーへの負担が少なく済む。
  • JavaScriptのおかげで非同期通信が可能。
  • レスポンスを待つ間も、レスポンスに左右されない箇所のHTMLを更新したり、ユーザーからの入力を受け付けられたりするなど、レスポンス待ちの時間を有効活用できる→ページの更新が早くなる。

Googleマップの地図の表示部分で使われている

  • 具体的にAjaxがどのように使われているか疑問に思ったので、調べた。

  • Googleマップ地図をスライドすると、その先の地図が表示される。

  • これは、スライドしている間に足りない地図のデータをAjaxでリクエストしているから、ぬるぬると地図を動かすことができる。
  • 1回目の通信はリクエスト⇔レスポンス(同期処理)で行い、2回目からはAjaxという技術をつかって、JavaScriptに必要なデータ分だけを取ってきてもらう、という流れ。
  • もしAjaxがなければ、スライドする度にページを再読み込みする必要がある。

Web API

  • 本では、
  • ユーザーではなくプログラムが直接サービスを利用できるための窓口
  • アプリケーションがWebサーバーの機能を利用するためのインターフェース(接点)

と説明されていたが、意味が理解できなかったので、実際にWebAPIが使われているサービスを見て調べた。

  • 例えば、connpassというWebサービスを利用してイベントに申し込んだ時に、参加コメントをTwitterに投稿できる機能がある。

f:id:Saki-Htr:20210227132622p:plain

  • これは、コンパスがTwitterが提供している「ツイートする」WebAPIを利用しているため、ユーザーの代わりに事前にTwitterのWebサーバー(が提供してるWebAPI)からデータを取得することで、実現できている。
  • ユーザーはこれのおかげで、わざわざTwitterというWebサービスに自分で接続しなくても、connpassというWebサービス内から参加コメントをツイートすることができる。
    = 本の「ユーザーがWebブラウザから操作しなくても、アプリケーションが直接Webサービスを利用できます」という説明は、このことを言っている。

考えたこと

  • Googleマップを快適に使えているのはAjaxのおかげだったとは知らなかった。地図を移動する度に、ページを再読み込みしていたら非常に使いづらいと思うので、感謝。
  • 新しいことを学んだ時に、イメージが湧かない時は、実際のWebサービスのどの機能に当たるか、どこに使われている技術かを調べることで、理解を深められた。

ch6. Webのセキュリティと認証

学んだこと

  • すべての驚異や脆弱性への対策をするのは難しいので、一般的にはリスクによる損失の度合いを算出し、それに応じて優先順位を決めた上で対策する。

ファイアーウォールはどこに設置するのか

  • ファイアーウォールとは:企業などの内部ネットワークをインターネットを通して侵入してくる不正なアクセスから守るための防火壁。

  • 本の説明で、ファイアーウォールがシステムのどこに設置されているのか分からなかったので、調べた。

  • 外部ネットワークとDMZ、DMZと内部ネットワーク、それぞれの間にファイアウォールが入るような構造を作り、通信を仕分ける。

  • DMZとは
    • 外部ネットワークと社内ネットワークの中間につくられるネットワーク上の区域
    • 外部ネットワークからも内部ネットワークからもファイアウォールなどによって隔離されている。
    • 外部に公開することが前提となるWebサーバは、常にリスクに晒されている。もし、Webサーバーを社内ネットワーク(=内部ねっと)に置くと万が一乗っ取られたり（リモートハッキング）、悪意のあるマルウェアなどを組み込まれたりした場合、社内ネットワークに接続されているその他のサーバやパソコンがすべて被害を受ける可能性がある。
    • 何のためにあるのか？→危険な地域のすぐそばに大切なものを置いておくのは危ないので、何かトラブルが起きても大丈夫なように緩衝地帯を設けて、そこに大切なものを置かないようにするためにある。
    • ファイアウォールはDMZを置かない状態でも設置できるが、Webサーバと外部ネットワークの間に設置されるファイアウォールは広く開放されている状態で、警戒が緩く、外部からの攻撃に対して脆弱な状態。Webサーバが内部ネットワークに置かれていると、乗っ取られたWebサーバを踏み台にして内部ネットワークも簡単に攻撃を受けてしまうので、DMZが必要。

考えたこと

  • 自分が被害を受けたことがないのもあって、セキュリティについて深く考えたことがなかったが、ドコモ口座の不正アクセスなど、かなり身近な問題。
  • これから消費者側ではなくサービスを開発して提供する側を目指すので、きちんと学んでセキュリティ面も考えて開発ができるエンジニアにならねばと思った。
  • 個人情報の漏洩がどれくらいの頻度で起こっているか気になったので調べたら、知らないだけで意外と結構あった。自分の個人情報も気づいてないだけで結構抜かれているのではと怖くなった。

ch7. Webシステムの構築と運用

考えたこと

  • アプリケーション設計は、機能の一覧、アプリケーションの構成図、画面レイアウトなど表面的な部分の設計らしい。
    エンジニアとして就職したら、おそらく全部を自分でやるのでなく、
    • サーバーやセキュリティなどインフラをどうするかはインフラエンジニア
    • 機能の洗い出しなどはRubyを書いたりDB設計をするサーバーサイドエンジニア
    • 画面のデザインはWebデザイナー、マークアップエンジニア、フロントエンドエンジニア

が主に決めたり各々同士が話し合ったりして設計ができるのだろうか。 これら全部を一人でする経験ができる、自作Webアプリ開発のカリキュラムが楽しみだと思った。

この事件はプログラムに問題があったわけではなく、伝達ミスによるもののようだが、気をつけないとこういう事態もあり得るのだな、と教訓になった。

全体の感想

  • この本はTECHPLAY女子部の方と2人で輪読会を行って読み進めた。
    輪読会についての感想は以下にまとめてある。

saki-htr.hatenablog.com

  • 一つ一つの用語を見開き1ページに丁寧に解説をしてくれており、ページの半分は図で解説してくれているので、初心者の私にとってとても読みやすかった。 Webを支える技術で分からない用語があった時に、この本を辞書代わりにして読むと良さそうだと思った。