「プロになるためのWeb技術入門」書籍内容まとめ Part1
この記事では、書籍「プロになるためのWeb技術入門」に基づいて、Webアプリケーションの基礎技術や重要なキーワードについてまとめています。
この書籍では、Webアプリケーション基礎技術を、手軽に学べる非常に読みやすい書籍だと思います！！
フレームワークなどの技術が発展している中で、新人や即戦力として活躍するためにフレームワークだけを覚えて開発現場に参画する方もいますが、根本的な仕組みを理解していないと、課題を解決することやより良いサービスを作成することは難しいです。この書籍は、その根本的な仕組みを理解するためのスタートになるような内容を提供しています。
記事を読んだ後に得られること
この記事を読めば、Webアプリケーションで使用される基礎的な技術や内容を理解できるようになります。読者は「聞いたことあった」から「なんとなくわかった or 理解できる」とレベルに到達できるでしょう。
より深く理解するためには実践で試したり、特定のキーワードでさらに調べてみたりしてみると理解度が深まると思います！！
対象読者
- WEBアプリケーション開発を始めてみたい人
- WEBアプリケーション開発の経験はあるけど、どのような仕組みで動作しているのか自分で説明できない人
- WEBアプリケーション開発の現場を管理しているが、現場で使われている技術がいまいち把握できていないと感じている人
書籍紹介
「プロになるためのWeb技術入門」
目次
0.プロローグ
インターネットが一般的に利用されるようになり、Webを利用した買い物や銀行取引、SNS、Twitterのようなサービスが登場しました。さらに、行政サービスもWebを通じて利用できるようになってきました。
そんなWebシステムをなぜ、あなたは開発開発できないのか。Webアプリケーションの難しさ、Web技術について記載していきます。
Webアプリケーション開発の難しさの理由
-
幅広い知識
Webアプリケーションを開発するためには、非常に幅広い知識が必要です。Webアプリケーション自体がさまざまな技術を利用して成り立っているため、プログラミング言語やネットワーク、アプリケーションサーバー、データベース、OSの知識まで身につけることが求められます。 -
スキルの習得
この知識を身につけるためには、書籍や動画から学んだり、現場での経験を通じて先輩エンジニアから教えてもらったりすることが重要です。少しずつ実践を積み重ねることで、必要なスキルを習得していくしかありません。
1.「Webアプリケーション」とは何か
デスクトップアプリケーション
デスクトップアプリケーションは、ユーザーのコンピュータにインストールされ、ローカル環境で動作するソフトウェアです。
代表例として、Microsoft社のWord、Excel、Outlookなどのオフィスアプリケーションが挙げられます。
主な特徴
- 主な処理は手元のPC環境上で行われる
- 画面はOSの機能を利用して表示される
- アプリケーションをPCにインストールする必要がある
Webアプリケーション
Webアプリケーションは、インターネットを介してアクセスされ、ブラウザ上で動作するアプリケーションです。データはサーバー上で管理され、クライアントとサーバー間で通信を行います。
代表例として、YoutubeやGmail、Amazonなどが挙げられます。
主な特徴
- 主な処理は手元のPCではなくサーバー上で行われる
- 画面はHTMLで表現され、Webブラウザ上に表示される
- アプリケーションをPCにインストールする必要がない
デスクトップアプリケーションとWebアプリケーションの特徴の違い
| 特徴 | デスクトップアプリケーション | Webアプリケーション |
|---|---|---|
| 処理の主体 | 手元のPC | サーバ |
| 画面の表示 | OS上で表示 | Webブラウザ上で表示 |
| インストール | 必要 | 不要 |
2.Webはどのように発展したか
2-1.WWWの誕生と普及
世界中のコンピュータを結ぶインターネット
インターネットとは、「世界中のコンピューターを相互に接続し、通信できるようにしたネットワーク網」。
もう少し身近な例で「電話」を思い浮かべていただくと分かりやすいかもしれません。電話番号さえわかれば世界中の人に電話をかけ、話すことができます。これは世界中に電話網が張り巡らされていて、世界中の電話が電話線で繋がっているからこそ実現されているものです。
この電話をコンピューターに置き換えるとインターネットのイメージになります。
インターネットは。世界中のコンピュータを接続するネットワーク網のことを指します。もともと世界規模で構築されたものではなく、誕生からこれまで数十年の間に、さまざまなコンピュータネットワークを相互接続することで発展してきました。
電話では、基本的に音声信号しかやりとりできません。しかし、インターネットではデジタル化された情報をやりとりできます。電子メール、Webサイトの閲覧、画像や映像の送受信など、コンピュータ上で扱えるさまざまな情報を送ることができます。
インターネットの語源
インタネット（Internet）の「インター（Inter）」は「〜の間」とか「相互」という意味を表す言葉でなので、「インターネット」は「ネットを相互につなぐもの」という意味から名付けられている。
インターネット普及の立役者・World-Wide WebとMosaic
1969年にARPANET（アーパネット）と呼ばれるアメリカ国防総省が研究・調査目的のために構築したネットワークが現在のインターネットの原型となり生まれました。
当初20年近くは限られた人だけが利用するものでした。
WWWの誕生
限られた人だけが利用する、このような状況を変えるきっかけとなったのが、「World-Wide Web（ワールド・ワイド・ウェブ）」と、現在私たちが利用しているWebブラウザの原型である「NCSA Mosaic（エヌシーエスエー・モザイク）」と呼ばれるソフトウェアの登場でした。
World-Wide Webは現在では「WWW」や単に、「Web」（ウェブ）と省略されて呼ばれています。
どういう考え方でWWWが生まれたのか？
生まれたのは素粒子物理学の研究所から生まれ、当時、欧州原子核研究機関（CERN）という組織の中で、核素粒子の実験結果を全世界の研究者で共有しようという話になりました。しかし、当時利用可能だった電子メールやファイル転送といった技術ではどうにも使い勝手が悪く、もっと良い方法はないだろうか...というところから試行錯誤を重ねティム・バーナーズ＝リー博士によって情報共有のために提案・開発したのがWWWだったのです。
まず研究成果を「HTML（Hyper Text Markup Language）」と呼ばれる統一された形式で表現することを考えました。研究成果を表現するには文章だけではなく、図表や参考文献などが必要です。これらをテキストファイルだけで表現できるようにしたものが、HTMLです。
HTMLは徐々に仕様が固められていき、現在でもWebサイトの記述に使用されています。
ここで画期的だったのは、「Hyper Text（ハイパー・テキスト）」と呼ばれる仕組みで文書間の参照が「Hyper Link（ハイパー・リンク）」という、コンピュータが理解できる形式で記述されているため、瞬時に参照先の文章を閲覧できます。
これによって、今まで手作業で参照が必要だった参考文献や資料を、ネットワーク経由で簡単に閲覧できるようになったのです。
余談
ちなみに、そのCERNについて言及しているのが日本のアニメ【STEINS;GATE（シュタインズ・ゲート）】です。
そのアニメの中で実名で【SERN】が登場します。シュタインズ・ゲートには実在する「CERN」の名称をもじった研究機関として「SERN」が登場しています！笑
面白いので是非見てみてください
現代Webブラウザの祖先・NCSA Mosaic
NCSA Mosaicは、1993年にリリースされた初期のWebブラウザで、グラフィカルユーザーインターフェイスとして、当初はテキスト表現によるWebページでしたが、現在のように文字と画像を混在させて表示できるようにしたものを提供し、Webの普及に大きく貢献しました。
2-2.Webを支える技術の発明
WebサーバとWebクライアント
Webによるファイルの公開と閲覧は、具体的には「webサーバー」と「Webクライアント」というソフトウェアで表現されています。
語源として、「client（お客様）」と「server（仕える人）」という英語がそのまま語源となっています。
- Webサーバ...クライアントからのリクエストに応じてWebページを提供するソフトウェアです。
- Webクライアント...通常はブラウザは、ユーザーがWebページを閲覧するためのソフトウェアです。
Webでは、Webサーバーがネットワーク上に公開するファイルを蓄積し、Webクライアントの要求に従って必要なファイルを渡してあげる仕組みなっています。
クライアントからサーバに対する要求を「リクエスト（request）」、サーバからクライアントに対する応答を「レスポンス（response）」と呼びます。
Webサーバ用のソフトウェアとして、オープンソースで公開されている「Apache HTTP Server（アパッチ）」やMicrosoft社の「Internet Information Servives（IIS）」が幅広く利用されています。
Webクライアントとは、GoogleChromeやSafariなどのWebブラウザのことです。
なぜ，クライアントとサーバに分けるのか
さまざまなコンテンツを不特定多数の人に公開するためには、コンテンツをできるだけ一箇所にまとめた方が管理が楽になります。WWWを実現するには、Webサーバのように一つのコンピューターに情報を集めておく方が管理しやすいのです。
一方で、WWWでは多くの人が自由にコンテンツを閲覧できなければいけません。利用者がそのコンテンツを保管しているWebサーバを直接操作するのは非現実的です。そのため、利用者の手元にあるPCをWebクライアントとして利用し、遠隔地にあるWebサーバとWebクライアントをインターネットで接続することで、WWWを実現しました。
この不特定多数の人にWebコンテンツを提供する仕組みをWWWで実現するためにクライアントとサーバを分けることが必然となりました。
「そのリソースはどこにある？」- URL
どのようにしてWebブラウザがWebサーバから目的のコンテンツを取得するのか？
クライアント（利用者）がサーバーに対して、具体的に要求を伝えなければいけません。「どこどこにあるコンテンツが読みたい」と指定する方法が必要となります。
例えば、小学生が図書館で本を借りるときを考えてみましょう。図書館に行って「面白い本を借りたい」と言っても、どの本を指しているのか分かりません。そこで、特定の本のタイトルや著者名を伝えることで、図書館員はその本を探して提供することができます。
これと同じ考え方で、インターネット上のコンテンツを一意（ユニーク）の値にする必要があります。
その仕組みが 「URL（Uniform Resource Locator）」です。
URLは、Web上のリソースの位置を示すアドレスです。これにより、特定のWebページやファイルにアクセスできます。
URLがどのようにしてインターネット上のリソースを指しているのか。
例
http://www.hogehoge.jp/webtext/index.html
- スキーム...http
- ホスト名...www.hogehoge.jp
- パス名...webtext/index.html
URLは大きく分けて3つ
- スキーム
スキームはリソースを取得するための方法を表します。
| スキーム名 | 特徴 |
|---|---|
| http | ハイパーテキスト転送プロトコル。Webページを取得するために使用される。 |
| https | 暗号化されたHTTP通信。Webサイト間のセキュアなデータ転送を行うために使用される。 |
| mailto | 電子メールの宛先を指定する。メールクライアントを開いて、新しいメールを作成するために使用される。 |
| ftp | ファイル転送プロトコル。サーバーとクライアント間でファイルを転送するために使用される。 |
| file | ファイルシステム内のファイルやディレクトリを参照する。ローカルファイルへのアクセスに使用される。 |
- ホスト名
リソースが存在しているホスト（コンピュータ）名を表します。
ネットワークに接続されて他のコンピュータからの要求を受け取り、処理した結果を返すようなコンピュータのことを一般的に「ホストコンピュータ」と呼びます。「ホスト名」とはホストコンピュータの名前のことを指します。
さらに、ホスト名は下記の「ローカル名」と「親ドメイン名」に分かれます。
例
www.hogehoge.jp
- ローカル名...www
- 親ドメイン名...hogehoge.jp
上記のホスト名は下記のような意味を表します。
- "jp"...日本の
- "hogehoge"...hogehogeという組織の
- "www"...WWWサーバというコンピュータ
親ドメイン名はそのホストが存在する組織を表し、ローカル名が組織のコンピュータに付けられた名前を表します。ローカル名は一般的にサブドメインと呼ばれます。
Tips
サブドメインの有無について
サブドメイン（例: www）は、ホスト名の一部としてオプションであり、ドメインの管理者が必要に応じて設定します。例えば、次のようにサブドメインがないURLとあるURLの両方が有効です。
サブドメインなし
https://example.com/
サブドメインあり
https://www.example.com/
リダイレクトの設定
多くのウェブサイトは、ユーザーの利便性のためにサブドメインありとなしの両方のURLをサポートし、一方から他方へのリダイレクトを設定することが一般的です。
例
https://www.example.com/ にアクセスすると https://example.com/ にリダイレクトされる。
- パス名
ホスト名で指定されたコンピュータ上のリソースの位置を示します。
webtextというディレクトリのindex.htmlというファイルを示しています。
このようにURLを利用することで、ドメイン→コンピュータ→ディレクトリ→ファイル名というようにインターネット上のリソースを特定できるようになります。
HTTP
WWWの実現にはもう1つ障壁があり、それはコンテンツを異なるコンピュータでどのように送受信するのかという問題。
インターネットにはさまざまな種類のコンピュータが繋がっていて、WebサーバとWebクライアントが通信を行うためは、どのように情報をやりとりするのかっていう取り決めが必要。この取り決めを「通信プロトコル」と呼びます。
そしてHTMLの転送に適したプロトコルが作成され、そのプロトコルが「HTTP（HyperText Transfer Protocol）」となります。
HTTPは、WebブラウザとWebサーバの間でデータを送受信するためのプロトコルです。
よく使用されるプロトコル
| プロトコル名 | 特徴 |
|---|---|
| HTTP | ハイパーテキスト転送プロトコル。WebブラウザとWebサーバ間でデータを送受信するために使用される。 |
| HTTPS | 暗号化されたHTTP通信。Webサイト間のセキュアなデータ転送を行うために使用される。 |
| FTP | ファイル転送プロトコル。サーバーとクライアント間でファイルを転送するために使用される。 |
| SMTP | シンプルメール転送プロトコル。電子メールの送信に使用される。 |
| IMAP | インターネットメッセージアクセスプロトコル。電子メールの受信に使用される。 |
| POP3 | ポストオフィスプロトコルバージョン3。電子メールの受信に使用されるが、IMAPと異なりメールをローカルにダウンロードする。 |
| SSH | セキュアシェル。リモートコンピュータに安全にアクセスするために使用される。 |
| DNS | ドメインネームシステム。ドメイン名をIPアドレスに変換するために使用される。 |
コラム インターネットに公開された技術仕様・RFC
RFC（Request for Comments）について
RFCは、インターネットの技術仕様や標準を定める文書で、インターネット技術の発展において重要な役割を果たしています。以下に、RFCについての詳細を示します。
RFCの概要
定義: RFCは「Request for Comments」の略で、インターネット標準を策定するための公式な文書です。IETF（Internet Engineering Task Force）によって発行されます。
目的: インターネット技術の仕様を広く公開し、コミュニティからのフィードバックを得て標準化すること。
種類: プロトコル仕様、技術標準、ベストプラクティスなど。
Tips
HTTPのバージョンと主要なRFC
| HTTPバージョン | RFC | 概要 | 特徴 |
|---|---|---|---|
| HTTP/0.9 | 非公式 | 最初のバージョンで、非常にシンプルなプロトコル。GETリクエストのみをサポートし、ヘッダーフィールドが存在しない。 | テキストファイルの転送のみ。 |
| HTTP/1.0 | RFC 1945 | 1996年に標準化。ヘッダーフィールドが導入され、GET、POST、HEADのリクエストメソッドが追加。 | 基本的なウェブ通信機能が整備。 |
| HTTP/1.1 | RFC 2068、RFC 2616 | 1997年に標準化され、その後RFC 2616にアップデート。現在でも広く使用されているバージョン。 | 持続的接続（Keep-Alive）やパイプライン化が導入され、効率的な通信が可能。その他、多くの改善点が含まれる。 |
| HTTP/2 | RFC 7540 | 2015年に標準化。GoogleのSPDYプロトコルを基にしており、パフォーマンスと効率性が大幅に向上。 | バイナリフレーミングレイヤー、ヘッダー圧縮、マルチプレキシング、サーバープッシュなどの機能が追加。 |
| HTTP/3 | RFC 9114 | 2020年に標準化。QUICプロトコル上で動作。 | TCPではなくUDPを使用し、接続の確立速度とパケットロスへの耐性が向上。さらなるパフォーマンス向上とセキュリティ強化。 |
2-3.CGIの誕生
動的なコンテンツへの要求
静的なHTMLページだけではなく、ユーザーの入力に応じて動的に生成されるコンテンツが求められるようになりました。しかし、コンテンツを常に人が更新するのは非常に大変です。
CGIの誕生
そこでコンピューターが動的に生成してくれればという考えになり、「CGI（Common Gateway Interface）」という仕組みが誕生しました。
CGIは、Webサーバが外部プログラムを実行して動的コンテンツを生成するための仕組みです。
実際に「Perl（パール）」と呼ばれるプログラミング言語が動的コンテンツの生成するために使用されました。
大規模なものや高速処理が必要な場合は「C言語」で作成されたプログラムが活躍しました。
Webの爆発的な普及
CGIにより、Webは単なる情報閲覧ツールからインタラクティブなプラットフォームへと進化し、急速に普及しました。
検索サイトや掲示板システム、ECサイトなど。Webアプリケーションの始まり。
2-4.サーブレットの登場
CGIにまつわる問題点
CGIはリクエストごとに新しいプロセスを生成するため、効率が悪く、スケーラビリティの問題がありました。
また、Perl言語での開発は大規模アプリケーションを使用に向いていなかった。
Java／サーブレットの誕生
このWebアプリケーション開発における問題があった時に登場したのが「Java（ジャバ）」でした。
Javaはオブジェクト指向の機能をサポートしているため、大規模開発がしやすく、マルチスレッドやセキュリティなども標準装備されていたため適していた。ただ、Webアプリケーション向けに開発された言語ではなかった。
そこで、JavaEE（企業システム向けJava）の一部として、サーブレット（Servlet）というWebアプリケーション開発をサポートする機能が提供されるようになった。
Javaサーブレットは、CGIを経由して起動されるPerlやC言語のJava版。JavaプログラムとしてWebサーバ上で動作し、CGIの問題を解決しました。プロセスではなくスレッドを利用するため、CGIの課題を解決し効率的に動作します。
Javaでアプリケーションを開発することの利点
Javaは特定のOSやハードウェアに依存しないため、異なる環境でも同じプログラムが動作します。
C言語のようにソースコードを直接コンピュータの機械語にコンパイルするのではなく、「JavaVM」と呼ばれる仮想的なコンピュータの言語にコンパイルして実行するため。
デスクトップアプリケーションは、「Windows用」、「Mac OS用」、「Linux用」と分かれていて異なる環境では動作しない。
2-5.JSPの誕生
サーブレットの問題点
サーブレットはコードが複雑化しやすく、デザインを変更するたびにプログラムの変更が発生するという問題がありました。
発想の逆転！JSPの誕生
「JSP（JavaServer Pages）」は、HTMLをベースとして、変更される部分だけをJavaで記述できるようになり誕生した。開発者はJavaコードの部分に集中し、デザイナーはHTML部分に集中するというアプリケーション開発における分業が可能となった。
2-6.Webアプリケーションフレームワークの時代
サーブレットやJSPの問題点
サーブレットやJSPを利用した開発は、コードの再利用性や保守性に課題がありました。
軽いシステムなら作成できるが、大規模なシステムになってくると結合がうまくできず不整合が起きたり...言った問題が起こり始める。またゼロから作成していると、たくさんの時間とお金がかかってしまう。
Webアプリケーションフレームワークの誕生
これらの課題を解決するために、再利用するという考え方からよく使用される処理はライブラリと呼ばれるプログラムの部品として、再利用できる部分を増やして開発しやすくするための土台としてできたのが、フレームワークです。
StrutsやSpringなどのWebアプリケーションフレームワークが登場しました。これにより、効率的な開発が可能になりました。
3.HTTPを知る
3-1.HTTPの知識はなぜ必要か
HTTPはWebアプリケーションの基盤となるプロトコルです。これを理解することで、アプリケーションの動作やトラブルシューティングが容易になります。正しく仕組みを知っていないと動かなくなった時の原因を理解できないため基盤となるHTTPを知っておく必要があります。
3-2.WebブラウザとWebサーバの通信をのぞいてみよう
HTTP通信をのぞいてみよう
これらのツールを使って、実際のHTTP通信を観察してみましょう。
HTTPリクエストをのぞく
HTTPリクエストは、クライアントがサーバに送信するメッセージです。リクエストライン、ヘッダー、ボディから構成されます。
参照元：TCP/IP - HTTP
リクエストラインは下記の3つから構成
- メソッド...リクエストの種類。上記例では「GET」つまり「URIで指定した情報を送ってください」という意味になる
- URI...「何が欲しいのか？」を示すのがURIの部分
- HTTPバージョン...HTTPのバージョン。利用できるメソッドの種類やリクエスト・ヘッダの種類が変わる
メッセージヘッダの代表的な構成要素
- Accept...Webクライアントが受け取ることのできるデータの種類
- データの形式はContent-Typeという形式で表され、クラインとで受け取ることのできるContent-Typeをカンマ区切りで指定します
- Accept-Launguage...Webクライアントが受け取ることのできる自然言語の種類。自然言語とは人間が使用する言語のことで、ここでは日本語であることを指している
- 同じコンテンツの英語版と日本語版が存在する場合、このヘッダによってWebサーバがクライアントの言語に合わせてコンテンツを返すということができる
- User-Agent...利用しているWebブラウザの種類やバージョン
- スマホアクセス時の判定や統計をとるのにも使用されている
- Host...リクエストの送信先ホスト名やポート番号を指定
Tips
HTTPメソッドの種類
| メソッドの種類 | 説明 |
|---|---|
| GET | データを取得することをWebサーバに要求 |
| HEAD | データそのものは要求せず、メッセージヘッダだけを取得することをWebサーバに要求 |
| POST | Webサーバにデータを送信 |
| PUT | Webサーバにファイルをアップロード |
| DELETE | Webサーバ上にあるデータを削除することを要求 |
| CONNECT | 例えばプロキシサーバなどに、トンネルの確立を要求 |
| OPTIONS | Webサーバがサポートしているメソッドの一覧を取得することを要求 |
| TRACE | Webサーバへのリクエストの経路を追跡することを要求 |
| PATCH | Webサーバ上のデータの部分更新を要求 |
コラム URL とURI は何が違うのか？
URI（Uniform Resource Identifier）は、リソースを識別するための文字列です。リソースがどこにあるかだけでなく、リソースが何であるかを識別します。
URLはURIの一種です。URIはURLに加えてURN（Uniform Resource Name）を含む、リソースを一意に識別するためのより拡張された概念です。
例: urn:isbn:0451450523
この例では、urn がスキームで、isbn:0451450523 が特定の本を識別するURNです。
URL：リソースの場所（住所）を示す。リソースが「どこにあるか」を示す
URI：リソースの識別子（ID）を示す。URLとURNの両方を含む。リソースが「何であるか」を識別する。
このように、URLはURIの一部ですが、URIはURLよりも広い概念で、リソースを識別するための包括的な方法を提供します。
HTTPレスポンスをのぞく
HTTPレスポンスは、サーバがクライアントに返すメッセージです。ステータスライン、ヘッダー、ボディから構成されます。
参照元：TCP/IP - HTTP
ステータスラインは下記の3つから構成
- HTTPバージョン...HTTPのバージョン。
- ステータスコード...リクエストが成功したかどうかを判別するためのコード
- レスポンスフレーズ...ステータスコードの簡易説明、人間が見てすぐにわかる内容
メッセージヘッダ
HTTPリクエストのメッセージヘッダと同じ形式で、レスポンスに関する付加情報が入っている。
メッセージボディ
HTTPレスポンスのデータ部分であり、クライアントとサーバー間で実際に転送されるコンテンツが含まれます。メッセージボディには、HTML、画像、動画、JSONデータなど、さまざまな種類のデータが含まれる可能性があります。
今回の例で言うとHTMLファイルの内容が入っています。
Tips
HTTPステータスコードの種類
ステータスコードは3桁の数字とそれに続くメッセージで表されていて、最初の1桁目の数字がカテゴリとなっている。
| ステータスコード | 意味 | 説明 |
|---|---|---|
| 1xx | 情報 | リクエストが受け取られ、処理が継続されていることを示す。 |
| 2xx | 成功 | リクエストが成功し、サーバーがリクエストされた処理を完了した。 |
| 3xx | リダイレクト | リクエストが別の場所に移動したことを示す。 |
| 4xx | クライアントエラー | クライアント側に起因するエラーがあり、リクエストが失敗した。 |
| 5xx | サーバーエラー | サーバー内部でエラーが発生し、リクエストが失敗した。 |
Tips
代表的なステータスコード
| ステータスコード | 意味 | 説明 |
|---|---|---|
| 200 | OK | リクエストが成功し、正常に処理されたことを示す。 |
| 301 | Moved Permanently | リクエストされたリソースが恒久的に新しいURLに移動した。 |
| 302 | Found | リクエストされたリソースが一時的に別のURLに移動した。 |
| 400 | Bad Request | リクエストが不正であるため、サーバーが理解できない。 |
| 401 | Unauthorized | リクエストされたリソースに対する認証が必要。 |
| 403 | Forbidden | サーバーがリクエストを拒否している。 |
| 404 | Not Found | リクエストされたリソースが見つからない。 |
| 500 | Internal Server Error | サーバー内部で予期しないエラーが発生した。 |
| 503 | Service Unavailable | サーバーが一時的に過負荷やメンテナンスで利用不可能。 |
HTTPでは1回で1つのリソースを取得
HTTPでは、1回のリクエストで1つのリソースを取得します。
HTMLにimgタグを含んでいると、imgタグを認識し、src属性に指定されたURLの画像を再度取得します。
HTTPでは一度のリクエストで1つのリソースしか取得することができないため、多くの画像を含むページでは画像の数だけHTTPリクエストが発行されてしまいます。
ファイル名を省略した場合のリクエスト
ファイル名を省略すると、通常はサーバのデフォルトファイル（index.htmlなど）が返されます。
webサーバの設定にもよるが、デフォルトのファイルを返すように設定されている。
3-3.情報はどうやってインターネットの大海原を越えるのか
もう少し踏み込んでHTTPによる通信がどのようにして相手のコンピュータに届けられるのか。
インターネット上の住所・IPアドレス
HTTPによるリクエストでは、リクエスト先のWebサーバはURLの中のホスト名の部分で示されます。
例
http://www.hogehoge.jp/webtext/index.html
「www.hogehoge.jp」がホスト名で要求先のWebサーバを示す。
インターネットに接続されたすべてのコンピュータは「IPアドレス」という数値によって識別されている。
IPアドレスは、インターネット上のコンピュータを一意に識別するための番号です。IPアドレスは、ピリオドで区切られた4組の数字で表されます。それぞれの数字は0〜255の範囲で、合計で約43億通りの組み合わせがあります（256 * 256 * 256 * 256 = 4,294,967,296）。
例えば、192.168.0.1のような形式で表されます。この形式はIPv4（Internet Protocol version 4）と呼ばれ、現在でも広く使用されています。
IPv6
IPアドレスの枯渇問題を解決するために、IPv6（Internet Protocol version 6）が導入されました。IPv6アドレスは、コロンで区切られた8組の16進数の数字で表され、より多くのアドレス空間を提供します。例えば、2001:0db8:85a3:0000:0000:8a2e:0370:7334のような形式です。
Tips
- IPv4: 32ビットのアドレス空間を持ち、4組の8ビットの数値で表される
- IPv6: 128ビットのアドレス空間を持ち、8組の16進数で表される
-
使用できないIPアドレス: プライベートIPアドレス、ループバックアドレス、リンクローカルアドレス、ブロードキャストアドレスなど。特定のIPアドレスは、特定の用途のために予約されており、一般的なインターネット通信では使用できません
-
プライベートIPアドレス
- これらのアドレスは、内部ネットワークでの使用を目的として予約されています。インターネット上では直接使用できません
- 10.0.0.0 〜 10.255.255.255（クラスA）
- 172.16.0.0 〜 172.31.255.255（クラスB）
- 192.168.0.0 〜 192.168.255.255（クラスC）
- 例.
192.168.1.1
- これらのアドレスは、内部ネットワークでの使用を目的として予約されています。インターネット上では直接使用できません
-
ループバックアドレス
- このアドレスは、自分自身を指すために使用されます。ネットワーク通信のテストやデバッグに使用されます
- 127.0.0.0 〜 127.255.255.255
- 例.
127.0.0.1
- このアドレスは、自分自身を指すために使用されます。ネットワーク通信のテストやデバッグに使用されます
-
リンクローカルアドレス
- これらのアドレスは、特定のネットワークセグメント内でのみ有効で、自動IPアドレス設定に使用されます
- 169.254.0.0 〜 169.254.255.255
- これらのアドレスは、特定のネットワークセグメント内でのみ有効で、自動IPアドレス設定に使用されます
-
ブロードキャストアドレス
- ネットワーク内のすべてのホストにパケットを送信するために使用されます。
- 255.255.255.255
- ネットワーク内のすべてのホストにパケットを送信するために使用されます。
-
ネットワークアドレスとホストアドレス
- 特定のサブネットのネットワークアドレスやホストアドレスとして予約されるアドレスもあります
- 192.168.1.0 （ネットワークアドレス）
- 192.168.1.255 （ブロードキャストアドレス）
-
IPアドレスを頼りに情報を届けるTCP/IP
TCP/IPは、IPアドレスを利用して情報を転送するプロトコルです。
IPアドレスがわかると宛先のホストが特定できるため、そのホストへ任意の情報を届けることができます。
その役割を担うのが「TCP/IP（ティーシピー・アイピー）」と呼ばれるプロトコル。
インタネットにおけるTCP/IPの位置付けは、郵便配達の位置付けと似ています。
封筒に入れ住所と宛名を書いてポストに投函して、その後は郵便局が住所と宛名から宛先の人へ届けてくれます。
この時に私たちはポストの投函後にどのように封筒が届くのかを意識する必要がありません。同じように、インターネットの世界でもIPアドレスだけ指定しておけば、どのように情報が届けらるかは意識しなくても良いのです。
実際にはHTTPリクエストをTCP/IPがパケットと呼ばれる小さい単位に分割して送信し、受け取り側のTCP/IPで元のように組み立ててからWebサーバなどのアプリケーションへ渡していく。
IPアドレスは誰が決めるのか
IPアドレスは、インターネットの健全な運用を確保するために、特定の機関によって管理されています。IPアドレスの割り当ては、以下の階層的な組織構造で行われます。
-
ICANN（Internet Corporation for Assigned Names and Numbers）
ICANNは、インターネットの安定性とセキュリティを確保するために設立された非営利法人で、全体的な管理と調整を行っています。IPアドレスの管理もその一環です。ICANNの下で、具体的なアドレスの割り当てはIANAに委任されています。 -
IANA（Internet Assigned Numbers Authority）
IANAは、IPアドレス、DNSルートゾーン、その他のインターネットプロトコルリソースの割り当てと管理を行う部門です。IANAは、ICANNの一部門として機能し、IPアドレスのグローバルな管理を担当します。IANAは大規模なアドレスブロックを各地域インターネットレジストリ（RIR）に割り当てます。 -
RIR（Regional Internet Registries）
地域インターネットレジストリは、特定の地域に対してIPアドレスを管理し、割り当てを行います。 -
ISP（Internet Service Providers）
ISPは、地域インターネットレジストリから割り当てられたIPアドレスをエンドユーザー（個人や企業）に提供します。ISPは、自身のネットワーク内でIPアドレスの管理と再割り当てを行います。
グローバルIPアドレスとプライベートIPアドレス
「グローバルIPアドレス」...インターネット上で一意のアドレスです。
「プライベートIPアドレス」...ローカルネットワーク内で使用されるアドレスです。ある一定範囲のIPアドレスをプライベートネットワークで自由に利用できるように予約したもの。
「プライベートネットワーク」...インターネットなどほかのネットワークに接続されていないネットワーク。
IPアドレスは、ネットワークに接続されたホストを識別するためのもの。そのため、プライベートネットワーク上でグローバルIPを使用する必要はありません。あるプライベートネットワーク上で使用されているIPアドレスが、ほかのプライベートネットワーク上で重複して使用されていたとしても、お互いのネットワークは接続されていないため全く問題にならない。
グローバルIPアドレスとプライベートIPアドレスを身近な例で例える
電話番号と内線番号の違いを想像するとわかりやすいと思います。
グローバルIPアドレスは、日本全国で通用する固定電話番号の電話番号に相当します。
プライベートIPアドレスは、オフィスや学校などで使用される電話の内線番号に相当します。
ホスト名をIPアドレスに変換するDNS
「DNS（Domain Name System）」は、ホスト名をIPアドレスに変換するためのシステムです。
インターネット上では、IPアドレスで通信相手のコンピュータを識別するということがわかりました。私たちがブラウザのアドレスバーにIPを入力しているわけではないので、DNSでドメイン名からIPアドレスに変換する仕組みをになっています。
DNSは、ドメイン名とIPアドレスの対応表を持ったコンピュータ（DNSサーバ）をインターネット上に配置し、DNSサーバへ問い合わせることでドメイン名に対応するIPアドレスを教えてもらえるというものです。
実際にコマンドを入力して実験
# GoogleのグローバルIPを取得
nslookup www.google.com
# 結果
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: www.google.com
Address: 142.251.42.164
Server: DNSリクエストが送信されたDNSサーバーのIPアドレスを示します。この場合、192.168.0.1は私のネットワークのルーターまたは内部DNSサーバーのIPアドレスです。
Address: DNSサーバーのIPアドレスとポート番号（#53）。ポート番号53はDNSの標準ポートです。
Name: ここでは、"www.google.com" のドメイン名を示します。
Address: "www.google.com" に関連付けられたIPアドレス。
ドメインの代わりに142.251.42.164をブラウザで入力してもGoogleのページを開くことができます。
DNSはどのようにして実現されるのか
DNSは、ドメイン名とIPアドレスを対応させるシステムであり、インターネット上の多数のDNSサーバによって分散管理されています。DNSは階層構造を持ち、各階層に対応するDNSサーバが存在します。これにより、ドメイン名の解決（ドメイン名をIPアドレスに変換すること）が効率的に行われます。
DNSの階層構造
- ルートDNSサーバ...最上位に位置し、全てのDNSクエリの出発点となります。13のルートDNSサーバが世界中に分散して配置されています。
- トップレベルドメイン（TLD）DNSサーバ...ルートDNSサーバから委任されたDNSサーバで、トップレベルドメイン（例：.com、.org、.net、.jpなど）を管理します。
- セカンドレベルドメインDNSサーバ...TLD DNSサーバから委任されたDNSサーバで、特定のドメイン名（例：example.com）のDNS情報を管理します。
- 下位ドメインDNSサーバ...サブドメインやさらに下位のドメイン名を管理します（例：www.example.comのwww部分）。
DNSクエリの流れの例
例えば、www.example.comにアクセスする際のDNSクエリの流れは以下のようになります。
- ルートDNSサーバへの問い合わせ
クライアント（例：ブラウザ）が www.example.com にアクセスするために、まずルートDNSサーバに問い合わせます。
ルートDNSサーバは、 .com のTLD DNSサーバのアドレスを返します。 - TLD DNSサーバへの問い合わせ
クライアントは、 example.com の情報を得るために、 .com TLD DNSサーバに問い合わせます。
.com TLD DNSサーバは、 example.com のセカンドレベルドメインDNSサーバのアドレスを返します。 - セカンドレベルドメインDNSサーバへの問い合わせ
クライアントは、 www.example.com の情報を得るために、 example.com のDNSサーバに問い合わせます。
example.com のDNSサーバは、 www.example.com のIPアドレスを返します。 - クライアントの接続
クライアントは、得られたIPアドレスを使って www.example.com に接続します。
ホスト内の宛先を決定するポート番号
「Port（ポート）」は、特定のサービスやアプリケーションを識別するために使用されます。ポート番号を利用することで、受信側のTCP/IPスタックがどのプロトコルに基づく通信であり、どのアプリケーションがその通信を処理すべきかを識別できます。例えば、SMTP、SSH、FTPなどのプロトコルがそれぞれ異なるポート番号を使用しています。
ポートは0〜65,535までの数字でまでの数字で表され、同じポートで複数のアプリケーションが利用することはできません。
ポート番号の考え方は、以下のように説明できます。
-
サービスの識別...各サービスやアプリケーションにはデフォルトのポート番号が割り当てられています。例えば、HTTPはポート80、HTTPSはポート443、SMTPはポート25、SSHはポート22を使用します。
-
待受ポート...サーバー側は、特定のポート番号で待機して、クライアントからの接続要求を受け付けます。この待受ポートによって、どのサービスが接続要求を処理するかが決まります。
-
通信の振り分け...受信側のTCP/IPスタックは、到着したパケットのポート番号を確認し、その番号に対応するアプリケーションにパケットを渡します。これにより、同じホスト上で複数のサービスが同時に動作できるようになります。
■具体例
-
HTTP通信...クライアントがウェブサイトにアクセスすると、HTTPリクエストはデフォルトでポート80に送信されます。サーバーのTCP/IPスタックは、このポート80で待機しているウェブサーバー（例：ApacheやNginx）にリクエストを渡します。
-
SSH通信...クライアントがリモートサーバーにSSH接続を行う場合、リクエストはデフォルトでポート22に送信されます。サーバーのTCP/IPスタックは、このポート22で待機しているSSHサーバー（例：OpenSSH）にリクエストを渡します。
インターネットで情報を届けるには、実際にはIPアドレスに加えてポート番号まで指定する必要があるということです。そうしなければ。届いた情報をどのアプリケーションが処理すべきかがわからないため。
URLにはポート番号が表されていませんが、これは本当は指定する必要があるものが省略されているだけです。
ホスト名（またはIPアドレス）:ポート番号
例
www.littleforest.jp:80
192.168.1.1:80
なぜ、今までポートを省略してもHTTPリクエストがWebサーバの元へ届いていたのか。
それはよく使われるポートは標準で使用されるポート番号を取り決められているため。このような取り決めがあるおかげで普段ポート番号を意識せずに使用できるのです。
Tips
ウェル・ノウン・ポート番号（well-known ports）
ウェル・ノウン・ポート番号は、0から1023までの範囲にあるポート番号で、広く使用されている標準的なネットワークプロトコルに予約されています。これらのポート番号は、特定のサービスやアプリケーションに対応しており、インターネット上で一貫した通信を可能にするために使用されます。
| ポート番号 | プロトコル | 説明 |
|---|---|---|
| 20, 21 | FTP（ファイル転送プロトコル） | ファイルの転送を行うプロトコル |
| 22 | SSH（セキュアシェル） | リモートログインおよびコマンド実行を行う |
| 23 | Telnet | リモートログインのためのプロトコル |
| 25 | SMTP（シンプルメール転送プロトコル） | メール送信を行うプロトコル |
| 53 | DNS（ドメインネームシステム） | ドメイン名とIPアドレスの変換を行う |
| 80 | HTTP（ハイパーテキスト転送プロトコル） | ウェブページの転送を行うプロトコル |
| 110 | POP3（ポストオフィスプロトコルバージョン3） | メール受信を行うプロトコル |
| 143 | IMAP（インターネットメッセージアクセスプロトコル） | メール受信を行うプロトコル |
| 443 | HTTPS（セキュアハイパーテキスト転送プロトコル） | セキュアなウェブページの転送を行うプロトコル |
3-4.Webサーバへの要求をどのように伝えるか
GETメソッドによるパラメータ渡し
GETメソッドは、URLの一部としてパラメータを渡します。簡単なデータの送信に適しています。
URLの後ろに?がついており、この部分を「クエリ文字列（Query String）」と呼び、フォームに入力された文字列などをWebサーバへ渡すために使用されます。
クエリ文字列の中では、さらに「&（アンパサンド）」で区切られて、それぞれの部分は「パラメータ名=値」の形式で表されています。
# 例.Xで記事をwebというキーワードで検索したときのURL
https://x.com/search?q=web&src=typed_query
Tips
クエリ文字列パラメーターの制約
| 制約項目 | 内容 |
|---|---|
| URLの長さ制限 | URLの長さは一般的に最大2,083文字（ブラウザ依存）を超えないようにする。 |
| エンコード | 特殊文字はURLエンコードする（例: 空白は %20 または +）。 |
| パラメーターの順序 | 通常は順序は重要ではないが、一部のシステムでは順序に依存する場合がある。 |
| サイズ制限 | 大きなデータはGETリクエストではなくPOSTリクエストで送信する。 |
| セキュリティ | クエリ文字列に機密情報を含めない（例: パスワード、クレジットカード番号）。 |
| 大文字・小文字の区別 | キーや値の大文字・小文字を統一する。 |
| 空白文字 | 空白文字は %20 または + にエンコードする。 |
これらの制約を守ることで、安全かつ効果的にクエリ文字列パラメーターを使用することができます。
アプリケーション側でのパラメータの受け取り
サーバ側では、GETメソッドで送られたパラメータを解析して処理します。
PHPでは、$_GETという連想配列にパラメータ名と値のセットが格納されているため、パラメータ名を指定して取り出すことができます。
後のPOSTメソッドで送られた際のパラメータの取得方法は、$_GETから$_POSTに変更になるのみで変わりません。
POSTメソッドによるパラメータ渡し
POSTメソッドは、リクエストボディにパラメータを含めて送信します。
GETメソッドでは、URLにパラメータが含まれるため、機密性の高い情報などは入れると第三者に見られてしまう可能性がありますが、POSTメソッドではリクエストボティにパラメータを含めて送信するため、長さの制限がなく大量のデータや機密データの送信に適しています。
# POSTリクエスト例
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 35
name=John+Doe&email=john.doe%40example.com
GETとPOSTどちらを使えばよい？
GETはデータの取得に、POSTはデータの送信に使うのが一般的です。
Tips
GETリクエストとPOSTリクエストの違い
| GETリクエスト | POSTリクエスト | |
|---|---|---|
| 利用するメソッド | GET | POST |
| パラメータの格納場所 | URLのクエリ文字列として | リクエストボディ内に格納 |
| セキュリティ | パラメータがURLに含まれるため、ブラウザの履歴やサーバーログに残る | パラメータはリクエストボディ内に含まれ、より安全（ただし暗号化が必要） |
| パラメータの長さ | URLの長さに依存し、制限がある（一般的に最大2,083文字） | 実質的な制限はなく、サーバー設定に依存する |
| パラメータの保存・再現 | URLに含まれるため、ブックマークやキャッシュに保存可能 | ブラウザの履歴には残らず、再現が難しい |
| 副作用が発生しないこと | 副作用が発生しない操作に適している（データの取得） | データの変更や送信に使用され、副作用が発生する操作に適している |
日本語はどのようにして渡せばよいか
日本語などの非ASCII文字は、URLエンコード（パーセントエンコードとも呼ばれる）して送信する必要があります。URLエンコードは、非ASCII文字やURLに使用できない文字をASCII文字に変換する方法です。
非ASCII文字とは？
-
非ASCII文字: ASCII（American Standard Code for Information Interchange）文字セットに含まれない文字。ASCIIは、英数字（A-Z, a-z, 0-9）や一部の記号（- _ . ~）を含む127文字のセットです。
- 例：日本語（さとう）、アクセント付きの文字（é、ñ）、その他の国際文字（中文、한글）など。
UTF-8との違い
-
UTF-8: Unicode文字を可変長のビットシーケンスでエンコードする方法。1〜4バイトで1文字を表現でき、世界中のすべての文字を扱える。
- 例：日本語の「さ」はUTF-8で
E3 81 95とエンコードされます。
- 例：日本語の「さ」はUTF-8で
URLに使用できる文字と使用できない文字
- 使用できる文字: 英数字（A-Z, a-z, 0-9）、一部の記号（- _ . ~）
- 使用できない文字: 空白、非ASCII文字（日本語など）、予約文字（例: ?, =, &, #）
URLエンコード（パーセントエンコード）とは？
URLエンコード（パーセントエンコード）は、非ASCII文字や使用できない文字を % 記号と16進数のコードに変換します。例えば、空白は %20、日本語の「さ」は %E3%81%95 とエンコードされます。
具体例: 「さとう」と検索した場合
-
検索クエリの例:
- 日本語の「さとう」を検索クエリとして送信する場合
-
URLエンコードの適用:
- 「さとう」をURLエンコードすると、
%E3%81%95%E3%81%A8%E3%81%86になります。
- 「さとう」をURLエンコードすると、
-
GETリクエストの例:
- 検索クエリを含むGETリクエストURL
https://example.com/search?q=%E3%81%95%E3%81%A8%E3%81%86
まとめ
Part1ということで前半部分のまとめを行いました。
Webの誕生の歴史やWebアプリケーション、HTTPといった基本的な概念についても触れられており、Webという幅広い知識の入門書として優れた内容が提供されています。
ある程度実践していないとイメージがつきにくい部分もあるかと思いますが、この書籍とこの記事が、Web技術の基礎を理解し、実際の開発に役立つことを願っています。