どうも。つじけ（tsujikenzo）です。このシリーズでは「ノンプログラマーによるWeb周り基礎学習」について全4回でお送りします。今日は1回目です。
※このシリーズは、私が参加しているノンプロ研の定例イベント「ZoomIn6月度」でLTをさせていただいた資料です。LTの機会を頂きまして感謝申し上げます。
きっかけ
業務でそんなに使うわけじゃないけど、ときどきプログラミングをしていて目にする単語があります。それは、Webにまつわる以下のような単語です。
– GET/POST
– HTTPリクエスト/レスポンス
– OAuth
– API
コーディングの際は、メソッドの定型文の「ボディ」や「アクセストークン」を変更するだけで動きますので、とりあえず問題はありませｎ。
いわゆる 「コピペなら動く」 というギリギリの状態です。
コピペからの卒業
しかしながら、みなさんも経験があるかと思いますが「コピペなら動く」の反対語は 「自分で書いたら動かない」 です。泣
自分で書けない理由は恐らく、GET/POSTやAPIという単語を真から理解していないからでしょう。そして、なぜ理解できないかというと、 「体系的にとらえるのが難しいから」 もあるのではないでしょうか。
体系的な学習
2021年現在、Webは私たちの生活と切っても切れない存在になりました。学習に関しては、書籍なども数多く出版されています。
なのに、Web周りを体系的に学ぶのが難しいのはなぜでしょうか。
それは、1つ1つの知識の獲得に必要な前提条件が曖昧で、登場する単語も多いからだと思います。
インターネットが繋がることが当たり前になってしまい、個々の単語や技術の解説が多くなってしまっているのかもしれません。インターネットの土台となっている技術にはどのようなものがあるのでしょうか。
また、それぞれの単語や技術は、独立したものではなく、なにかに包括されているのでしょうか。
このシリーズでは、Web周りを体系的に学ぶことによって、「ひとつひとつの単語・技術を習得する為のサポート」 ができれば幸いです。
デベロッパーロードマップ
「ノンプログラマー」の辛いところは、エンジニア資格の勉強や、専門分野の基礎学習の時間がなかなか取れないところです。
そこで、Web周りのエンジニアを目指す人のために学習のロードマップを提供している 「デベロッパーロードマップ」 というサイトをご紹介します。
フロントエンド
バックエンド
開発保守
※日本語版提供者 木之村哲さん
今回の学習範囲
「どこから勉強を始めればいい」という答えは、人によって違います。とはいえ、Web周りを学ぶためには、どうしても外せないのが「フロントエンド」の基礎であるこの辺りです。
今回は、このような学習メニューを用意してみました。
1. ネットワークとHTTP
2. TCPとHTTPリクエスト
3. HTTPレスポンスとGET/POSTリクエスト
次回以降、順番にお届けします。
まとめ
以上で、「ノンプログラマーによるWeb周り基礎学習」 ということで、学習のきっかけと学習メニューを整理しました。
私にとっても、基礎ながら知らないことばかりです。
次回は、「ネットワークとHTTP」をお届けします。
このシリーズの目次
- [WEB]ノンプログラマーによるWeb周り基礎学習
- [WEB]ネットワークとHTTP
- [WEB]TCPとHTTPリクエスト
- [WEB]HTTPレスポンスとGET/POSTリクエスト
どうも。つじけ（tsujikenzo）です。このシリーズでは「ノンプログラマーによるWeb周り基礎学習」について全4回でお送りします。今日は2回目です。
前回のおさらい
前回は、「ノンプログラマーによるWeb周り基礎学習」 ということで、「デベロッパーロードマップ」をご紹介しました。何を学習するのかも、整理できたと思います。
今回は、 「ネットワークとHTTP」 をお届けします。
ネットワークとは
私の考える「デベロッパーロードマップ」の、最初のセクションの基礎は「ネットワーク」です。
Web周りの包括的な用語（図の？にあてはまる言葉）が「ネットワーク」ということです。
「ネットワーク」とは、「つながりを定義したもの」 です。
「つながり」の国際標準化
これから、離れたところにある「もの」と「もの」をつなぐことを考えます。まず、正しい説明をするためにも、言葉の定義をきちんと決めないといけません。言葉の意味が、受け取る人の感覚によってバラバラだと困るからです。
これを、世界中の学者とか頭のいい人たちが話し合って決めます。国際標準化 とか 国際規格 と呼ばれるものです。
「ネットワーク」は、1970年代後半、「階層構造を使って定義しよう」 と国際標準化されました。現実世界のパソコンなどの端末同士のつながりを「階層モデル」を使って定義しよう、ということです。
OSI参照モデル
具体的に言うと、その階層モデルとは「OSI（Open System Interconnection）参照モデル」というものです。 「ネットワークは7つの層で定義できる」 というものです。少し見ていきましょう。
7つの層はこのような構成になっています。下の層から順番に「なにかをやりたい」という要求が高度になっていくイメージをもつとわかりやすいです。
重要な点を抜粋してみましょう。下のかんたんな層から紹介します。
第1層－物理層
まずは、糸電話のように、「とりあえず一本の線でつながりたい」要求を満たします。こんなかんたんな要求でも、決めないといけないことはたくさんあります。
たとえば、
– 技術的には、デジタルデータと電気信号の変換を行う
– 有線でも無線でもいい
– 有線ケーブルの場合はコネクタの形状はどんなものが許されるか
– メーカーが違っても通信できるか
などの決まりごとの数や種類をきめます。（具体的なルールの中身を決めるわけではありません）
第2層－データリンク層
物理層では「誰かと誰かを線でつなぐ」というだけでした。その次は「誰から誰に転送されているのかをわかるようにしたい」という要求です。
プリンターとパソコンをつなぐ「MACアドレス」という決まりごとは、このデータリンク層で定義されている技術です。
第3層－ネットワーク層
さて、個々のパソコンが誰なのか特定できるようになると、1つのネットワーク内だけでなく、複数のネットワークや、LANケーブルで繋がれたネットワーク外のパソコンもつなげたくなります。
この、ネットワーク層の要求に答えるための決まりごとが 「インターネットプロトコル（Internet Protocol）」 です。略して「IP」です。
IPではデータを「IPパケット」という単位で送受信します。IPパケットのヘッダーには、送信元と宛先の両方のIPアドレスが格納されており、ヘッダー情報を元に、宛先にIPパケットが届けられます。（URLをIPアドレスに変換する役割をDNS（Domain Name System）と呼びますが、今回は割愛します。）
「パケット代無料」という言葉は一度でも耳にしたことがあるでしょう。私たちのスマホと携帯会社のサーバは、IPパケットをやりとりすることで通信しています。
このように、とても便利になってきたネットワーク層ですが、IPパケットは、宛先まで到着することを保証しません。また、送信した順序も保証しません。なので、一部でも届かないパケットが発生すると、データ不十分ということで、破棄されてしまいます。
1対1のような通信であれば、IPパケットが全部揃うまで、何度も通信をトライして構わないかもしれませんが（時間と通信費の許す限り）、WEBサーバのような多くの人が通信を望む環境では困ります。
第4層－トランスポート層
IPパケットが届かなかったら、送信元に再送を要求したり、順番が狂っていたら順番を整えて、「信頼性のある通信を保証しよう」という決まりごとが 「TCP（Transmission Contorol Protocol）」 です。
技術的には、「データを一度に送信できるサイズに分割しよう」 というものです。
TCPのおかげで、クライアントとサーバは、データの順番が変わったりすることなく、正しく送受信ができるのです。
第5層（セッション層）・第6層（プレゼンテーション層）は、飛ばします。
第7層－アプリケーション層
さあ、いよいよネットワークについて、やりたい要求が最高度になりました。
– WEBサイトを閲覧したい
– ファイルを転送したい
– メールを送受信したい
といった要求です。
「アプリケーション層」 では、それぞれの要求に応えるための決まりごとが標準化されています。
- WEBサイトを閲覧するための決まりごと・・・HTTP（Hyper Text Transfer Protocol）
- ファイル転送を行う決まりごと・・・FTP（File Transfer Protocol）
- メール送信を行う決まりごと・・・SMTP（Simple Mail Transfer Protocol）
- メール受信を行う決まりごと・・・POP（Post Office Protocol）
どれも、一度は聞いたことがある単語ではないでしょうか。
HTTPは、ネットワークでやりたいことをひとつずつ定義していくと、最上位のアプリケーション層に含まれました。「WEBサイトを閲覧する」ということは、さまざまな通信の決まりごとの上に成り立っているから です。
まとめ
以上で、「ネットワークとHTTP」 ということで、OSI参照モデルをもとにHTTPの位置付けをご紹介しました。
HTTPの具体的な決まりごとは「RFC7230～7235」というドキュメントで定義されています。日本語の翻訳もありますので、興味のあるかたは目を通してみましょう。
次回は、「TCPとHTTPリクエスト」をお届けします。
このシリーズの目次
- [WEB]ノンプログラマーによるWeb周り基礎学習
- [WEB]ネットワークとHTTP
- [WEB]TCPとHTTPリクエスト
- [WEB]HTTPレスポンスとGET/POSTリクエスト
どうも。つじけ（tsujikenzo）です。このシリーズでは「ノンプログラマーによるWeb周り基礎学習」について全4回でお送りします。今日は3回目です。
前回のおさらい
前回は、「ネットワークとHTTP」 ということで、ネットワークは7つの層で説明がつくということをご紹介しました。「WEBサイトを閲覧する」ということは、さまざまな通信の決まりごとの上に成り立っていましたね。
今回は、「TCPとHTTPリクエスト」 をお届けします。
サーバとクライアントのやりとり
身近な「サーバとクライアント」と言えば、「ブラウザとWebサーバ」ですが、この2つはネットワークのさまざまな通信の決まりごとに則ってやりとりをしています。
ブラウザとWebサーバの通信では、「信頼性のある通信を保証しよう」というTCP（Transmission Contorol Protocol）を使用しています。（第4層トランスポート層のきまりごとでしたね。）
今回は、TCPによる「ブラウザとWebサーバ」のやりとりを、Javaを使ってパソコン内で検証してみます。
ソケットライブラリ
TCPでは、データを双方向にやりとりするための出入口として「ソケット」を準備します。「ソケット」の作成は、まさに「ソケットライブラリ」で行います。これは、ほとんどのOS上のプログラミング言語で扱えるライブラリです。
今回は[8001番]というポート番号を持ったソケットを作成します。サーバ側（TcpServer.java）のコードはこのようになります。
new ServerSocket(8001);
一方で、クライアント側（TcpClient.java）のコードはこのようになります。
new Socket("localhost", 8001);
お互いにソケットのインスタンスを生成して、インスタンスの受け渡しを行います。※コードの全文は後ほどご紹介します。
サーバとクライアントのファイルのやりとり
今回のサンプルコードでは、サーバとクライアントで、テキストファイルのやりとりをします。（テキストファイルに意味はありません。）
コマンドプロンプトを2つ起動し、それぞれ、「TcpServer.java」と「TcpClient.java」を起動します。
//サーバ側
C:ファイルパス>java TcpServer
//クライアント側
C:ファイルパス>java TcpClient
それぞれのフォルダに「server_recv.txt」と「client_recv.txt」が作成されていれば成功です。
TCPクライアントをWebブラウザに変更する
それでは、いままでTCPクライアントだったクライアント側を、Webブラウザに交代してもらいましょう。
サーバが保存した「server_recv.txt」の中身をみると、「Webブラウザが通信の際にサーバになにを送っているのか」を確認できます。
Webブラウザからサーバへのアクセスの方法は、プログラミングではなく、ブラウザのアドレスバーに以下を入力します。
http://localhost:8001/index.html
接続が成功して、通信が完了すると、「server_recv.txt」が保存されますので、中身を確認してみます。
1: GET /index.html HTTP/1.1
2: Host: localhost:8001
3: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
4: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5: Accept-Language: ja,en-US;q=0.9,en;q=0.8
6: Accept-Encoding: gzip, deflate
7: Connection: keep-alive
これが、「HTTPリクエスト」の正体です。
HTTPリクエスト
HTTPの仕様書であるRFC7230では、クライアントから送信されるサーバへのメッセージ処理は、このように定められています。
– リクエストライン
– リクエストヘッダ
– 空行(CR+LF)
– メッセージボディ（もしあれば）
前節で取得したHTTPリクエストも、このような構造になっています。
//リクエストライン
1: GET /index.html HTTP/1.1
//リクエストヘッダ
2: Host: localhost:8001
3: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
4: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5: Accept-Language: ja,en-US;q=0.9,en;q=0.8
6: Accept-Encoding: gzip, deflate
7: Connection: keep-alive
//空行
8:
//ボディ無し
リクエストライン
リクエストラインは3つの要素から成り立っています。
– GET・・・メソッド（クライアントからサーバに対するリクエストの方法）
– /index.html・・・リクエストURI（リクエスト対象のリソース）
– HTTP/1.1・・・プロトコルバージョン（この通信で使うHTTPのバージョン）
リクエストURIの「/index.html」は「最初に訪問する住所」のようなイメージがあるのではないでしょうか。プロトコルバージョンの「HTTP/1.1」も、とくに深掘りする必要はないかもしれません。
残りの「GETメソッド」については、次回お届けします。
まとめ
以上で、「TCPとHTTPリクエスト」 ということで、TCPにおけるサーバとクライアントのファイルのやりとりを再現してみました。保存されたテキストを確認することで、HTTPリクエストの中身が明らかになりました。
また、HTTPリクエストの1行目に書かれている、「リクエストライン」もご紹介しました。
次回は、「HTTPレスポンスとGET/POSTリクエスト」 をお届けします。
このシリーズの目次
どうも。つじけ（tsujikenzo）です。このシリーズでは「ノンプログラマーによるWeb周り基礎学習」について全4回でお送りします。今日は最終回の4回目です。
前回のおさらい
前回は、「TCPとHTTPリクエスト」 ということで、TCPにおけるサーバとクライアントのファイルのやりとりで、HTTPリクエストの中身が明らかになりました。
今回は、「HTTPレスポンスとGET/POSTリクエスト」 をお届けします。
HTTPレスポンス
今回は、クライアントを「TcpClient.java」に戻して、サーバを「本物のWebサーバ」にしてファイルのやりとりを行ってみます。Webサーバから何が返ってくるでしょうか。
前回、サーバで保存された「server_recv.txt」は「ブラウザから送信されたHTTPリクエスト」でした。なので「server_recv.txt」を「client_send.txt」として、サーバに送付してみます。
接続が成功して、通信が完了すると、「server_recv.txt」が保存されますので、中身を確認してみます。
1: HTTP/1.1 200 OK
2: Date: Wed, 26 May 2021 17:47:09 GMT
3: Server: Apache/2.4.6 (Win32)
4: Last-Modified: Mon, 11 Jun 2007 11:53:14 GMT
5: ETag: "2e-432a0069dbe80"
6: Accept-Ranges: bytes
7: Content-Length: 46
8: Keep-Alive: timeout=5, max=100
9: Connection: Keep-Alive
10: Content-Type: text/html
11:
12:
<h1>It works!</h1>
これが、「HTTPレスポンス」の正体です。
HTTPレスポンス
HTTPの仕様書であるRFC7230では、サーバから応答されるへのメッセージは、このように定められています。
– ステータスライン
– レスポンスヘッダ
– 空行(CR+LF)
– ペイロード本体を含むメッセージボディ（もしあれば）
前節で取得したHTTPリクエストも、このような構造になっています。
//ステータスライン
1: HTTP/1.1 200 OK
//レスポンスヘッダ
2: Date: Wed, 26 May 2021 17:47:09 GMT
3: Server: Apache/2.4.6 (Win32)
4: Last-Modified: Mon, 11 Jun 2007 11:53:14 GMT
5: ETag: "2e-432a0069dbe80"
6: Accept-Ranges: bytes
7: Content-Length: 46
8: Keep-Alive: timeout=5, max=100
9: Connection: Keep-Alive
10: Content-Type: text/html
//空行
11:
//メッセージボディ
12:
<h1>It works!</h1>
ステータスライン
ステータスラインは3つの要素から成り立っています。
– HTTP/1.1・・・プロトコルバージョン（この通信で使うHTTPのバージョン）
– 200・・・状態コード（成功コードもしくはエラーコード）
– OK・・・リーズンフレーズ（状態コードの概観）
「ステータスコード」と「リーズンフレーズ」はみなさんもよく見かけると思います。「404 (Not Found)」というようなエラーコードです。
GETメソッドとPOSTメソッド
HTTPには、8種類のメソッドがあります。
– GET:ターゲットリソースの現在の表現を転送する。
– HEAD:GET と同じだが、状態行とヘッダ節のみを転送する。
– POST:要請ペイロードに対し、リソースに特有な処理を遂行する。
– PUT:ターゲットリソースの現在の表現すべてを、要請ペイロードに置換する。
– DELETE:ターゲットリソースの現在の表現すべてを、除去する。
– CONNECT:ターゲットリソースで識別されるサーバへ、トンネルを確立する。
– OPTIONS:ターゲットリソース用の通信オプションを述べる。
– TRACE:ターゲットリソースへの経路に沿ってメッセージループバックテストを遂行する。
前回、HTTPリクエストのGETメソッド（略してGETリクエストと呼ばれます）の中身を確認しました。
1: GET /index.html HTTP/1.1
2: Host: localhost:8001
3: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
4: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5: Accept-Language: ja,en-US;q=0.9,en;q=0.8
6: Accept-Encoding: gzip, deflate
7: Connection: keep-alive
同様に、HTTPリクエストのPOSTメソッド（略してPOSTリクエストと呼ばれます）はこのような中身になります。
1: POST /hoge/ HTTP/1.1
2: Host: localhost:8080
3: Connection: keep-alive
4: Content-Length: 22
5: Cache-Control: max-age=0
6: Origin: http://localhost:8080
7: Upgrade-Insecure-Requests: 1
8: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36
9: Content-Type: application/x-www-form-urlencoded
10: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
11: Referer: http://localhost:8080/hoge/
12: Accept-Encoding: gzip, deflate, br
13: Accept-Language: ja,en-US;q=0.8,en;q=0.6
14:
15: name=hoge&comment=hoge
よく見ると、GETリクエストと同様に、このような構造になっています。
– 1行目・・・リクエストライン
– 2行目以降・・・ヘッダ
– 空行
– リクエストボディ（クエリストリング）
GETとPOSTの使われどころ
GETやHEADなどのリクエストでは、送信されるのはヘッダのみです。POSTリクエストはHTTPレスポンスと同じように「ボディ部」があり、ここに送信したいデータを記述できます。
大きなデータやファイルをサーバに送る（データベースへのデータの格納など）のによく使われますので、以下のような機能に利用されます。
- ［ HTMLフォームに手入力された一連のフィールド ］などのデータブロックを、データ取り扱い処理に供する。
- ［ 掲示板、ニュースグループ、メーリングリスト、ブログ、その他同類の記事群 ］などへ、メッセージを投函する。
- 生成元サーバによりまだ識別されていない、新たなリソースを作成する。
- 既存のリソースの、いくつかの表現に、データを付加する。
これは、「GETリクエストは、POSTリクエストに必要な情報を取得するためにも利用される」 と言えるでしょう。
https://developer.freee.co.jp/tutorials/first-call
GETリクエストはURLで構成されるため、ブックマークとして保存することができますが、個人のパスワードを送信する必要がある場合は、POSTリクエストで送信した方がよいでしょう。
まとめ
以上で、「HTTPレスポンスとGET/POSTリクエスト」 ということで、HTTPレスポンスの構造を確認しました。
また、HTTPの8つのメソッドから、「GET/POSTリクエスト」を選出しました。
読者のみなさまには、ネットで拾ってきたコピペコードを動かすだけではなく、さまざまな言語でHTTPリクエストをコーディングできるようになっていただければ幸いです。
参考文献
このブログを書くにあたって、こちらの書籍とサイトを参考にさせていただきました。
大変勉強になりました。ありがとうございました。
Comments