AWS習得編 Amazon Web Service 基礎からのネットワーク&サーバー構築 Chapter5
こちらの書籍について学んだことです。
Chapter5 HTTPの動きを確認する
HTTPプロトコルについての解説
5-1 HTTPとは
直訳するとハイパーテキストを伝送するための通信規約
404 Not found
500 Internal Server Error
これらはHTTPで定義されたコード
404は対象のリソースが見つからない
500はサーバーで何かしらのエラーが発生した
てな感じ
HTTPはクライアントサーバー型のアーキテクチャ
2者間でリクエストとレスポンスをやり取りする方式を定めている
■リクエストとレスポンスの書式
リクエストとレスポンスがそれぞれ3つのパートで構成される。
①リクエスト
リクエストライン
ヘッダー
ボディ
で構成される
例
リクエスト
POST /HTTP/1.1
ヘッダー
Host: www.google.co.jp
Connection: keep-alive
User-Agent: Mozilla/5.0(Windows NT 6.2; WOW64)
Accept-Encoding: gzip,deflate
ボディ
Keyword=AWS
リクエストは要求コマンドのこと。
要求方法と要求URLが含まれる。
ヘッダーはブラウザから送信する追加情報
たとえば要求したいホスト名、ブラウザの種類、対応言語、Cookieの情報、直前に見ていたページのURLなどが含まれている。
多くの場合複数行。
ボディはHTMLフォーム(form要素)やAjaxなどで、POSTというメソッドを利用し、データをサーバーに送信するときに利用される。
ヘッダーとボディは開業で区切られる
②レスポンス
ステータス
ヘッダー
ボディで構成される
例
ステータス
HTTP/1.1 200 OK
ヘッダー
Date: Wed, 09 Apr 2014 06:38:47 GMT
Cache-Control: private, max-age=0;
Context-Type: text/html; charset=UTF-8
Server: gws
ボディ
<html><body>...
ステータスラインは、その要求の成否を返すもの。冒頭の1行。正常に終了すれば200 OKというステータスが返ってくる。
見つからないときは404 Not Found、サーバー側で何かしらエラーが発生したら500 Internal Server Errorが返される。
ヘッダーは追加情報を返すために利用される。
ボディ部の種類を示すContext-Typeヘッダー、ボディの長さを示すContent-Lengthヘッダーなどがある。
多くの場合複数行。
ボディは要求されたURLに対するコンテンツ
uniform resouce locater
HTMLのテキストや画像など、要求されたコンテンツデータそのもの。
ヘッダーとボディとは、空行で区切られる
5-2 ブラウザの開発者ツールでHTTPのやり取りをのぞいてみる
今回はsafariで頑張って見てみる
●ヘッダー部を確認する
開発のWebインスペクタを開いて、ネットワークの書類を開いて出てきたやつのヘッダタブを開くと見れる
●ボディ部を確認する
開発のWebインスペクタを開いて、ネットワークの書類を開いて出てきたやつのプレビュータブを開くと見れる
■リクエストとレスポンスの詳細
「HTTPメソッド」
「HTTPステータスコード」
「リクエスト/レスポンスヘッダー」
についてさらに詳細に見ていく。
●HTTPメソッド
コンテンツに対する操作コマンドのこと。
多くの場合、GETまたはPOSTが使われる。
GET リソースを取得
POST リソースにデータ送信したり、子リソースを作成したりする
HEAD リソースのヘッダー情報だけを得る。ボディは返ってこない。更新日時などのステータスだけ取得したい時とかに使う。
PUT リソースを更新したり、作成したりする。
DELETE リソースを削除する。
OPTIONS サーバーがサポートしているメソッドを取得する。
TRACE 自分宛にリクエストメッセージを返してループバックテストをする
CONNECT プロキシ動作のトンネル接続をする
一般的にGETメソッドが使われる
フォーム入力があるとPOSTメソッドが使われる
●HTTPステータスコード
結果の成否を示す値。3桁の数字。100の位で大まかな成否が決まり、残りの桁で詳細なステータスが決まる。
コード
1xx 処理中 処理中であることを伝える。あまり使われない。
2xx 成功 成功したことを伝える。200がよく使われる
3xx リダイレクト 別のURLにリダイレクトする。
301 Moved Permanently 永続的な移動
302 Found 一時的な移動
303 See Other 他を参照せよ
304 Not Modified コンテンツはif-Modified-Sinceヘッダーで指定された日時から更新されてない
4xx クライアントエラー クライアント側のリクエストにエラーがある
401 Unauthorized 認証が必要
403 Forbidden アクセス禁止
404 Not Found 指定されたリソースが見つからない
5xx サーバーエラー サーバー側のエラー
500 Internal Server Error 内部的なエラー。CGIのエラーでも使われる。
503 Service Unavailable 一時的に接続できないときや、サーバーが受け入れ可能な接続数を超えたときに使われる。
成功したら一般的に200 OK
リダイレクトは301,302,303が返る
301,302,303の応答を受け取った場合、ブラウザは自動的に指定されたリダイレクト先に再接続して、コンテンツを取得しようとする。
httpからhttpsへのリダイレクト
近年ではセキュリティを高めるためにhttp://でアクセスしてきたときにhttps://にリダイレクトする実装が流行。
そのように構成されたWebサーバーはhttp://でアクセスしたときに、次のように301 Moved Permanentlyというステータスコードを返すように実装されている。
リダイレクト先は、Locationヘッダーで示される。
●リクエストヘッダー
クライアントからサーバーに送信するときに送られるヘッダー
よく使われるのは以下の通り。
・HTTPヘッダー
要求を送ろうとするホスト名をhostで記述する。
HTTP1.0とHTTP1.1があるが、HTTP1.1で送信が必須
・User-Agentヘッダー
ブラウザの種類を示す
Webシステムを構築するとき、このUser-Agent文字列を元にブラウザやOSを判断して、処理分岐を実装する。
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Firefox/24.0
・Cookieヘッダー
Cookie情報を送信するもので、サーバー側から以前にSet-Cookieヘッダーで送信されてきたものと同じデータをそのまま返す役割をする。
Cookie: s_cc=true; s_sq=...;
ユーザーがログインしたときに、そのログイン情報を保存したりするときなどに使われる。
つまり、Cookieにはログインしたユーザーと結びつける情報が格納されていることがあり、Cookieが漏洩すると、第三者が自分になりすましてしまう危険がある。
●レスポンスヘッダー
サーバーからクライアントに返すときに送信される情報
よく使われるレスポンスヘッダーには次のものがある。
・Content-Typeヘッダー
ボディ部のコンテンツの種類を示す。
Content-Type: text/html;charset=UTF-8
text/htmlであれば、HTMLとしてユーザーに表示する。
画像ならimage/png
pdfならapplication/pdf
application/octet-streamが返されたら、多くのブラウザがファイルを保存するダイアログボックスを表示する。
このようなコンテンツの種類はMIMEタイプ(Multipurpose Internet Mail Extension Type)
と呼ばれ、その一覧はIANAのwebサイトで確認できる。
Internet Assigned Numbers Authorityとは、インターネットに関連する番号を管理する組織
Apacheを含む、ほどんどのWebサーバーは、静的なコンテンツを返すとき、そのファイルの拡張子によって、適切なContent-Typeヘッダーを返すように構成されている。この設定が間違っていると、クライアント側でファイルが開けなかったり、いつもと違うアプリケーションが起動してしまったりという問題が起きる。
・Dateヘッダー
コンテンツの日付を示す。
・Set-cookieヘッダー
Cookieを設定する
これがない場合もある。
これがあった場合、次同じサイトにアクセスしたときにブラウザはリクエストヘッダーにCookieをつけて要求を出す。
これによってサーバー側はアクセスしてきたユーザーを追跡できる。
5-3 Telnetを使ってHTTPをしゃべってみる
ここまでブラウザがHTTPプロトコルで通信するところを見てきたが、自らの手を動かしてHTTPプロトコルで通信することもできる。
そのために必要なものはTelnetクライアントのみ。
Telnetとは、汎用的な双方向8ビット通信を提供する端末間およびプロセス間通信プロトコルでリモートコンピュータとやり取りするための仕組み。暗号化されてないSSHだと思う。
ルーターにログインして各種設定をするときなどによく使われている。
Telnetクライアントは、単純にテキストをやり取りする機能だけを持つ。
ふつうの使い方では、接続先はTelnetサーバー。
TelnetサーバーはSSHサーバーと同様にログインおよび何らかのコマンドを受け付ける。
しかし、接続先を変更すると、任意のサービスに接続できる。
HTTPウェルノウンポート番号80に接続してHTTPプロトコルに従って文字列を送ればサーバーからHTTPのレスポンスを得ることができる。
Mac環境の場合、Telnetクライアントはデフォルトでインストールされている。
●WindowsのTeraTermでTelnet接続をする
省略
●MacのターミナルでTelnet接続をする
telnet www.nikkeibp.co.jp 80
----------------------------------------
zsh: command not found: telnet
----------------------------------------
いや使えへんやないかーい!!!!
macOS Catalina telnet インストール
で検索
https://weblabo.oscasierra.net/http-telnet-macos/
を参考にtelnetをインストールする
brew install telnet
だけでいいっぽい
早速実行!
----------------------------------------
zsh: command not found: brew
----------------------------------------
いやbrewも使えへんやないかーい!!!
一応インストールする方法あるけど労力の割に得られるもの少なそうなので、今回は座学のみで終わらす。
どうやらappleがtelnetの使用を推奨していないからだそうで、今後telnet使うなってことやろ多分。
macのデフォルトの改行コードは、デフォルトでは「LF」であり、HTTPプロトコルの規約である「CRLF」ではない。
もし正しい改行コードで通信したいなら、Telnetを起動したあと、[Ctrl]+[で>telnetというプロンプトが表示されるため、toggle crlfと入力する。そうすることで改行コードをCRLFに変更できる。
5-4 まとめ
本章では、HTTPプロトコルの概要を学んだ。
telnetで遊べなかったが、telnetで色々データやり取りできる。
通信プロトコルってなんだか難しそうと思うけど、実は簡単なテキストのやり取りをしてるだけ。
WebAPIを使った開発や、Webアプリケーション、API自体の開発をするにはHTTPの理解が必須。
開発者の多くはAPIを開発するときにFirefoxの開発者ツールなどを使って通信をのぞき見しながら開発している。
次の章で、インターネットから見えないプライベートなネットワークを構築してセキュリティを高める手法を学ぶ。
最後のコラムは、Telnetを使えず、Node.jsを使ってサーバーがなにか喋ったところで、その言葉を確認することもできないので、今回は一旦飛ばすことにした。
この記事が気に入ったらサポートをしてみませんか?