泳げないたいやきの日記

メモとして残していきます。誤字脱字や、誤った記事などがあればご教授いただますと幸いです。

S3を使用した静的Webサイトを公開するまで

始めに

HTML+CSSJavaScriptを使い静的なWebサイトを作成しS3で公開したので、手順を忘れないように書き残しておこうと思いこの記事を書きました。

S3とは

S3とは、Amazon Simple Storage Serviceの略称であり、高機能で耐久性が高いストレージサービスです。

S3の主な機能は、ファイルのアップロードやダウンロード、Webサーバの作成となっている。

 

S3でバケットを作成する手順

1.AWSマネジメントコントールからS3を探す。

 

2.S3のバケットにある「バケットを作成」を押す。

 

 

3.バケットを作成のページ内の「バケット名」、「リージョン」、「ブロックパブリックアクセスのバケット設定」の欄を埋める。

バケット名」:自身が使いたいドメインの名前を入力する。

「リージョン」:私は東京を選択した。

「ブロックパブリックアクセスのバケット設定」:全てのチェックを外す。

f:id:OyogenaiTaiyak1:20201202101056p:plain

バケットの作成

 

4.バケット作成のページ内の最後にある「バケットの作成」を押す。

この段階でバケットは作成される。

 

作成したバケットの静的ウェブホスティングの設定の手順

1.S3のコンソールから作成したバケットを選択する。

 

2.プロパティを選択する。

 

3.「プロパティ」内の「静的ウェブホスティング」の編集ボタンを押し、「有効にする」を選択する。

 

4.「インデックスドキュメント」と「エラードキュメント」を公開したい自身のHTMLファイルの名前を入力し、変更の保存を行う。

f:id:OyogenaiTaiyak1:20201202101211p:plain

静的ウェブサイトホスティングの編集

 

作成したバケットのアクセス許可の手順

1.「アクセス許可」を選択する

 

2.「ブロックパブリックアクセス(アクセス設定)」のチェックボックスが全て外れている事を確認する。

 

3.「バケットポリシー」の編集を行う。

バケットポリシーはJSONで記述するのですが、今回はAmzonさんが提供している例のJSONを使用します。

(例として提供されているバケットポリシーでは、セキュリティが緩くなってしまうので、後にバケットポリシーを書き直した方が良いと思います。)

docs.aws.amazon.com

 

Resourceの箇所は、公開するバケット名を入力します。

 

4.最後に「変更の保存」ボタンを押してアクセス許可設定は終了です。

 

 

公開するバケットにファイルをアップロードする手順  

1.オブジェクトを選択する

 

2.「オブジェクト」内の「アップロード」ボタンを押す。

 

3.「アップロード」内の「ファイルを追加」ボタンを押し、公開するHTMLファイルを選択する。

f:id:OyogenaiTaiyak1:20201202101409p:plain

バケットへのアップロード

 

4.アップロードが完了後、「プロパティ」の「静的ウェブサイトホスティング」のURLを押すと、自身が公開したHTMLファイルが閲覧できるようになっています。

 

 

最後に

 今回は、HTML+CSSJavaScriptを使った静的なWebサイトを公開したかったのでS3を使いました。今後、現在公開しているWebサイトにPHPSQLを追加して動的なWebサイトを

作成した時に、EC2を使いたいと思います。

 

※誤字や脱字、誤っている内容などがありましたら、コメントをいただけると幸いです。

 

参考文献

 

 

 

Route 53 ドメイン取得

始めに

 Webシステムを作りたいと考え、Route53でドメインを取得しました。

Route 53とは

 Route 53はDNSであり、Amazon EC2Amazon S3などの接続点に結び付けることができる。

さらにドメイン取得も行うことができる。

DNSについてはこちらをご覧ください。

DNSについて - 泳げないたいやきの日記

 

Route 53でドメイン取得する手順 

1:AWSのマネジメントコントロールにログインする。

 

2:マネジメントコントロールからRoute 53を探す。

 

3:Route 53のダッシュボードのドメイン登録内の「ドメイン名の入力」に欲しいドメイン名を入力する。

f:id:OyogenaiTaiyak1:20201124225508p:plain

Route 53のダッシュボード

 

 

4:ドメイン名の使用可否の判定が表示されるので、使用可能なドメイン名であればカートに入れ、ページ下部にある続行を押す。

f:id:OyogenaiTaiyak1:20201124230124p:plain

Route 53のドメイン使用可否の判決

 

 

5:自分の個人情報を入力する

f:id:OyogenaiTaiyak1:20201128164730p:plain

個人情報の登録

 

6:個人情報とドメインの自動更新の確認とメールアドレスの認証を行う。

(私は、更新を忘れてドメイン名を使えなくなるのが嫌なので自動更新にしました)

 

 

7:個人情報で登録したメールアドレスに認証メールが届くので承認する。

f:id:OyogenaiTaiyak1:20201124231902p:plain

Route 53から送られてくる認証メール

 

 

8:承認するとEmail address verificationというページに移動する。

f:id:OyogenaiTaiyak1:20201124232311p:plain

認証完了画面

 

 

9:メールでの認証が完了すると6での個人情報の確認画面の「登録者の連絡先のEメールアドレスの確認」の場所に緑色のチェックマークが付きます。

最後に注文完了ボタンを押す。

 

f:id:OyogenaiTaiyak1:20201124230953p:plain

個人情報の確認

 

 

 

10:再びRoute 53のダッシュボードに入ると、ドメインの登録が1となっておりドメインの取得が完了する。

f:id:OyogenaiTaiyak1:20201124232712p:plain

ドメイン取得後のRoute53のダッシュボード

 

最後に

 少し記憶があやふやなのですが、Route 53でのドメインの取得までの大まかな流れは上記の手順の通りです。

 

 

PCについて

初めに

 普段使用しているPCの中身がどのようになっているのか知りたいと思い、簡単にまとめてみました。

PCの中身

 PCは、主に「HDD」、「SSD」、「CPU」、「SATAケーブル」、「ビデオカード」、「マザーボード」、「メインメモリ」、「BIOS」により構成されている。

 

HDD (Hard Disk Drive / 補助記憶装置)について

  HDDは、たくさんのデータを保存することができ、更に価格が安い。

メモリだけでは、電源が切れた時などにデータが消えてしまうので補助記憶装置や外部記憶装置と呼ばれるHDDやSSDが必要とされる。

SSD (Solid State Drive / 補助記憶装置)について

 SSDは、データのアクセスが早い

SSDとHDDは、データの読み取り速度はほぼ同じだが、データがある目的地までに掛かる速さがSSDの方が早い。

 

CPU (Central Processing Unit / 中央処理装置)について

 CPUは、「ALU (Arithmetric Logic Unit / 算術論理演算装置)」、「レジスタ(記憶装置)」、「制御ユニット」から構成されており、PCの頭脳の役割を持ち、ほとんどの計算はCPUが行っている。(人間の脳みそようなもの)

 

ビデオカードについて

 ビデオカードは、「ジオメトリエンジン」、「物理エンジン」、「シェーダー」などの部品から構成されており、PCが処理した結果を画像としてディスプレイに表示する役割を持つ

 

マザーボードについて

 マザーボードは、さまざまなデバイスのソケット、コネクタ、スロットを装備しており、マザーボード内の回路を通してデバイス間の情報交換を行う。

 ※主なコネクタには、「メモリスロット」、「電源コネクタ」、「バッテリ」、「BIOS」、「SATAコネクタ」、「CPUソケット」、「ポート」、「イーサネットポート」、「USB」などが挙げられる。

SATAケーブルについて

 SATAケーブルは、HDDとマザーボードを接続する役割を持つ

SATA:HDDで使用されている「ATA (AT Attachment)」という規格を1ビットずつ伝送する方法であるシリアル化をしたもので、「SATA (Serial AT Attachment)」と呼ばれる。

メインメモリ(主記憶装置)について

 メインメモリは、プログラムやデータが処理される時の一時的な保存場所である。

 

BIOSBasic Input Output System)について

 BIOSは、PCに電源が入った時に起動される最初のプログラムであり、「HDD」、「CPU」、「メモリ」の種類の確認と設定を行うソフトウェア

 

参考文献

  • OS自作入門 川合秀美著
  • 作って理解するOS 林高勲著 川合秀美監修
  • コンピューター&テクノロジー解体新書 ロン・ホワイト著 ティモシー・エドワード・ダウンズ(イラスト) トップスタジオ訳
  • なるほどナットク!サーバがわかる本 小関祐明著 小野哲監修
  • 絵で見てわかるOS/ストレージ/ネットワーク 小田圭二著
  • Cプログラミング入門以前第2版 村山公保著

パケットキャプチャをしよう ④ (UDP)

初めに

  今回は、TCPと同じトランスポート層で動作しているUDPを解析しようと思いました。

UDP (User Datagram Protocol)

f:id:OyogenaiTaiyak1:20201001173911p:plain

図 UDP

 UDPは、「送信元ポート番号」、「宛先ポート番号」、「UDPデータグラム長」、「チェックサム」から構成されている。

 

Source Port(送信元ポート番号)について

 送信元ポート番号は16ビットで構成されており、送信元のポート番号を示す。

送信元のポート番号は、プロトコルに対しての返答が不必要な時に、値を「0」にすることができる。

 

 図では、「Source Port : 60000台の数値」と表示されていたので、Dynamic and/or Private PortsをOSがランダムに選んだ値が入っていることがわかる。

 

Destination Ports (宛先ポート番号)について

 宛先ポート番号は16ビットで構成されており、宛先のポート番号を示す。

 

 図では、「Destination Port : 400番台」と表示されていたので、System PortのHTTPSを使用していることがわかる。

 

 Length(パケット長)について

 パケット長は16ビットで構成されており、UDPのヘッダとデータの長さを足した値が示される。

 

 図では、「Length : 41」と表示されている。数値の単位はオクテットである。

※オクテットとは、8ビットのことである。1オクテット=8ビット

 

Checksum (チェックサム)について

 チェックサムは16ビットで構成されており、UDPのヘッダやデータが壊れていないかを示す。

 

最後に

  UDPは、TCPよりも構成要素が少なく、この構成要素の差が動作の速さや、通信の信頼性に関わるのかなと思いました。

 

参考文献

  • マスタリングTCP/IP 入門編 第5版 竹下隆史・村山公保・荒井 透・苅田幸雄共著
  • マスタリングTCP/IP 応用編 Philip Miller著 苅田幸雄監訳
  • パケットキャプチャの教科書 みやたひろし著

 

 

パケットキャプチャをしよう ③ (TCP)

前回まで

 ①データリンク層、②ネットワーク層と解析してきたので、この回ではトランスポート層TCPを解析していきます。

 

TCP(Transmission Control Protocol)

f:id:OyogenaiTaiyak1:20200917151801p:plain

図 TCP

 TCPは、「送信元ポート番号」、「宛先ポート番号」、「シーケンス番号」、「確認応答番号」、「データオフセット」、「予約」、「コントロールフラグ」、「ウィンドウサイズ」、「チェックサム」、「緊急ポインタ」、「オプション」、「パディング」により構成されている。

 

 Source Port(送信元ポート番号)について

  送信元ポートは16ビットで構成されており、送信元のポート番号を示す。

ポート番号は大きく3つに分けられており、

  • System Ports:     0 ~ 1023
  • User Ports :1024 ~ 49151
  • Dynamic and Private Ports:49152 ~ 65535

となっている。(より詳細なポート番号は省きます。)

 

 図では、「Source Port : 443」と表されているので、送信元ポート番号は、System Ports内の443番を使用していることがわかる。

また、System Portsの443番はHTTPSを表しているので、HTTPSを使用していることがわかる。

Distination Port(宛先ポート番号)について

 宛先ポート番号は16ビットで構成されており、宛先のポート番号を示す。

 

 図では、「Destination Port : 50000台の値」と表されていたので、Dynamic and Private Portsを使用していることがわかる。

Sequence Number(シーケンス番号)について

 シーケンス番号は32ビットで構成されており、TCPのセグメントを分裂させて送信している時に、分裂したデータを元に戻す時に使用する。

シーケンス番号は、「0」や「1」のような定まった数値ではなく、OSがランダムに決めた値をシーケンス番号として与えている。

 

 図では、「Sequence number : 328272」と表されている。

 

Aknowledgment number(応答確認番号)について

 応答確認番号は32ビットで構成されており、TCPのセグメントが分裂して送られてきたと時に、次に送信してもらいたいセグメントの番号を示す。

※応答確認番号は、ACKフラグが「1」の時のみ有効となる。

 

 図では、「Aknowledgment number : 157708」となっており、シーケンス番号と比較するとかなり数値が違いますが、今のところ理由はわかりません。(わかり次第更新します)

 

Header Length(データオフセット)について

 データオフセットは4ビットで構成されており、TCPのヘッダの長さを示す。

 ※ネットワーク層IPv4のHeader Lengthと同じ動きをする。

 

 図では、「0101 . . . . = Header Length : 20 bytes (5) 」と表されており、TCPのヘッダが20バイトということがわかる。

 

Flags(コントロールフラグ)について

 コントロールフラグは現在使用されていない予約のビットを含めると12ビットで構成されており、意味が設定されているビットに「1」が入ると、意味に沿った機能が動く。

  • Reserved:将来使用するための拡張用ビット
  • Nonce:実験用のビット
  • Congestion Window Reduced(CWR):TCPのふくそう通知に使用される
  • ECN-Echo:CWRと同様にTCPのふくそう通知に使用される。
  • Urgent:緊急に処理したいデータが含まれている時に使用される。
  • Acknowledgment:確認応答番号が有効の時に使用される。
  • Push:受信したデータをアプリケーションに渡すときに使用される。
  • Reset:TCPコネクションを強制的に切りたい時に使用される。
  • Syn:TCPコネクションを確立したい時に使用される。
  • FIN:TCPコネクションを切りたい時に使用される。

 

 図では、「Acknoeledgment」のビットのみが「1」となっているので、確認応答を返していることがわかる。

 

Window size(ウィンドウサイズ)について

 ウィンドウサイズは16ビットで構成されており、受信側のPCやサーバーが受け取れるデータの大きさを示す。

 

Checksum(チェックサム)について

 チェックサムは16ビットで構成されており、TCPが壊れていないかや、欠損部分が無いか等を調べるために使用される。

 

Urgent pointer(緊急ポインタ)について

 緊急ポインタは16ビットで構成されており、コントロールフラグのUrgentが「1」の時のみ有効となる。

緊急で処理を行いたいデータが存在するときに、データがどこの場所にあるかを示す。

 

まとめ

 今回、①データリンク層、②ネットワーク層、③トランスポート層TCPまでのパケットを見てきたことにより、今日、私たちが当たり前のように使用しているインターネットの中に多くの知識が詰め込まれていることが少し理解できたと思う。

 今後、機会があればIPv6DNSUDPHTTPSSSL(TLS)などの様々なプロトコルWiresharkでキャプチャを行い、パケットの解析を行いたいと思いました。

 

参考文献

  • マスタリングTCP/IP 入門編 第5版 竹下隆史・村山公保・荒井 透・苅田幸雄共著
  • マスタリングTCP/IP 応用編 Philip Miller著 苅田幸雄監訳
  • パケットキャプチャの教科書 みやたひろし著

パケットキャプチャをしよう ② (IPv4)

前回

 前回の記事では、データリンク層を解析したので、今回はネットワーク層IPv4を解析していこうと思います。

 

ネットワーク層

 

f:id:OyogenaiTaiyak1:20201001174427p:plain

図 IPv4

  ネットワーク層IPv4のフレームは、「バージョン」、「ヘッダー長」、「ToS(Type of Service)」、「パケット長」、「識別子」、「フラグ」、「フラグメントオフセット」、「TTL (Time To Live)」、「プロトコル番号」、「ヘッダーチェックサム」、「送信元IPアドレス」、「宛先IPアドレス」から構成されている。

 

 

バージョンについて

 バージョンは4ビットで構成されており、IPのバージョンを表している。

バージョンは現時点で、

  • 4 : IPv4 (2進数表記で0100)
  • 5 : ST Datagram Mode
  • 6 : IPv6 (2進数表記で0110)
  • 7 : TP/IX
  • 8 : PIP (The P Internet Protocol)
  • 9 : TUBA

の6種類となっている。

 図では、「0100 = Version 4」となっているので、IPv4を使用していることがわかる。

※バージョンがIPv6になるとパケットのフォーマットもIPv6仕様になる。

 

ヘッダー長について

  ヘッダー長(Internet Header Length)は4ビットで構成されており、IPヘッダの長さを32ビット単位に変換した値を表している。

 ヘッダー長を見ることにより、IPヘッダの終了する位置やIPデータの開始位置を知ることが可能となる。

 図では、「Heder Length 20 Bytes (5)」と表示されており、IPヘッダーの長さが20バイトということを知らせてくれている。

 

Different Service Field (ToS)について

 ToS(Type of Service)は、8ビットで構成されており、送信しているIPの品質や、優先度を表している。

Wiresharkでは、ToS(Type of Service)ではなく、Different Service Fieldと表されている。

  • 0、1、2ビット:「優先度」
  • 3、4、5ビット:D、T、Rと呼ばれ パケットに対しての「必要な遅延」、「スループット」、「信頼性」を提供する
  • 6ビット:RFCでは設定されているがまだ使用は不可
  • 7ビット:将来の予備用のビット

 

 図では、0~7ビットまで全て「0」となっているので、優先度も低く、さらに、パケットへのサービスも通常通りに処理を行うことを表している。

 

Total Length(パケット長)について

 パケット長は、16ビットで構成されており、ヘッダとデータを含めたデータグラム全体の長さを表している。

パケット長は16ビットなので、2の16乗=65535オクテットまでIPパケットを送信することが可能。

 

Identification(識別子)について

  識別子は、16ビットで構成されており、データを分裂させて(フラグメント)送信した後に、再びデータをくっつける際に識別子として使用する。

  識別子は、送信元のPCやサーバーが割り当てるので、途中で変更されることはない。

 

 図では、「Identification :  0x3363 (13155)」と表されている。

 

Flags(フラグ)について

 フラグは、3ビットで構成されており、データグラムを分裂(フラグメント)する時に使用する。

 

  • 先頭1ビット目:未使用
  • 中間2ビット目:DFビット「Don't Fragment」とされており、データグラムを分裂させたくない時に「1」を、分裂させたい時に「0」を指定する。
  • 最終3ビット目:MFビット「More Fragment」とされており、分裂したデータグラムを送信している時に、残りのデータがまだ送られてくるなら「1」を、送らてこなければ「0」を指定する。

 

 図のFlagsでは、

  • 先頭1ビット目:未使用なので「0」
  • 中間2ビット目:データグラムを分裂させたくないので「1」
  • 最終3ビット目:このデータの後ろに送られてくるデータが無いので「0」

と表示されている。

 

Flagment offset(フラグメントオフセット)について

 フラグメントオフセットは、13ビットで構成されており、分裂されたデータが、分裂前のデータのどこの部分に存在したかを宛先のPCやサーバーに指示する役割を持つ。

 

 図のパケットでは、データを分裂させていないので「Flagment offset 0」と表されている。

 

TTL(Time to live)について

 TTLは、8ビットで構成されており、このパケットがネットワーク内に存在できる最大時間を表示する。

 TTLは、ネットワーク内のルータ等を経由した際に、「1」ずつ減算され、「0」に到達しるとネットワーク内からパケットが消去され、送信元のPCやサーバにICMPメッセージが送信される。

 図では、「Time to live : 117」と表されており、後117個のネットワーク内のルータ等を経由すると、パケットが消去され、ICMPメッセージが送信元に送られる。

 

Protocol(プロトコル番号)について

 プロトコル番号は、8ビットで構成されており、パケットを運ぶ際に、上位の層のでどのプロトコルを使用しているかを表している。

 

主なプロトコル番号

  • 1:ICMP(Internet Contorol Message Protocol)
  • 4:IP
  • 6:TCP(Transmission Contorol Protocol)
  • 17:UDP(User Datagram Protocol)

 図では、「Protocol : TCP (6)」と表記されているので、このパケットの上位層ではTCPが使用されていることがわかる。

 

 Header checksum(ヘッダチェックサム)について

  ヘッダチェックサムは16ビットで構成されており、IPヘッダのチェックサムを表し、IPヘッダが壊れていないかを教えてくれる。

 

 図では、「Header checksum : 0x75xx [validation disabled] 」と表示されていた。

※他にも、「 [Header checksum status : Unverified] 」と表示されているので、この図のパケットではチェックサムを検証していないのかもしれません。

 

Source(送信元のIPアドレス)について

 送信元のIPアドレスは、32ビットで構成されている。

 

 Destination(宛先IPアドレス)について

  宛先のIPアドレスは、32ビットで構成されている。

 

まとめ

 ネットワーク層でのIPv4は、約12個の要素で構成されており、その1つ1つがとても奥深くまで考えられながら開発されてきたのだなと解析しながら思いました。

 個人的に、ToSの7ビット目の将来の予備としてのビットが、今後どのように使用されていくのかがとても楽しみです。

 

参考文献

  • マスタリングTCP/IP 入門編 第5版 竹下隆史・村山公保・荒井 透・苅田幸雄共著
  • マスタリングTCP/IP 応用編 Philip Miller著 苅田幸雄監訳
  • パケットキャプチャの教科書 みやたひろし著

パケットキャプチャをしよう ① (Ethernet)

初めに

 前回のWiresharkのインストールの記事から1週間経ち、Wiresharkの使い方も少しずつ理解してきたので、パケットキャプチャを行い解析をしてみようと思いました。

 今回解析を行うのは、Windowsの初期画面からgoogleを検索したときにキャプチャを行った約830個の中の1つのTCP通信のパケットです。

 この記事では、データリンク層を解析します。

 

データリンク層

f:id:OyogenaiTaiyak1:20200912144803p:plain

図1, Ethernet2

Ethernet2のフレームは、「プリアンブル」、「宛先/送信元MACアドレス」、「タイプ」、「Ethernetペイロード」、「FCS」から構成されている。

Wiresharkでは「プリアンブル」と「FCS」は見れません。

Destinationについて

 Destinationは、宛先(送りたいPC、サーバー)のMACアドレスが記載されている。

Chongqin_3b:cf:25 (ac:d5:64:3b:cf:25)となっており、Chongqinと調べると中国の重慶市がヒットするので、重慶市にあるサーバーに送信しているのかなと考えました。

Sourceについて

 Sourceは、送信元(送ったPC、サーバー)のMACアドレスが記載されている。

Sourceの送信元MACアドレスはセキュリティのため伏せさせていただきます。

L/G Bitについて

 L/G Bitは、記載されているMACアドレスがグローバルアドレスか、ローカルアドレスかを表している。

「0」 : グローバルアドレス

「1」 : ローカルアドレス

 図1では、宛先MACアドレスと送信元MACアドレスの両方が「0」を表しているので、どちらもグローバルアドレスとなっている。

I/G Bitについて

  I/G Bitは、記載されているMACアドレスがユニキャストアドレスか、マルチキャストアドレスかを表している。

「0」 : ユニキャストアドレス

「1」 : マルチキャストアドレス

※ 宛先のMACアドレスがすべて「1」の状態である「ff:ff:ff:ff:ff:ff」かつ、I/G Bitがマルチキャストを表す「1」の時は、ブロードキャストを表している。

 図1では、宛先MACアドレスと送信元MACアドレスの両方が「0」を表しているので、どちらもユニキャストとなっている。

 

タイプについて

 タイプには、ネットワーク層で使用しているプロトコルを表している。

図1では、IPv4(0x0800)と表記されているので、ネットワーク層IPv4を使っていると表されている。

IPv4以外にも、IPv6(0x86DD)や、ARP(0x0806)などもある。

イーサネットではなく、IEEE802.3を使用するとタイプには、LLC(Logical Link Control)または、SNAP(Sub Network Access Protocol)などの情報が表示される。

 

 最後に

  今回の記事では、0と1の数字の列を意味のあるフレームに分けて、複数のシステムを経由した先にある宛先のシステムまでのパスのうちの隣接するシステムとの間の情報の流れの制御を行なうデータリンク層のパケットを解析してみました。

 次回では、ネットワーク層のパケットを解析したいと思います。

 

参考文献

  • マスタリングTCP/IP 入門編 第5版 竹下隆史・村山公保・荒井 透・苅田幸雄共著
  • マスタリングTCP/IP 応用編 Philip Miller著 苅田幸雄監訳
  • パケットキャプチャの教科書 みやたひろし著