エンジニア2年目となったので通信の仕組みについて体系的に整理してみた。

5cb64d08b24b9c2f95ed5cbce9462f9e.png

こんにちわ久野です!

未経験からフロッグポッドに入社して2年目となり、以前よりは技術的な説明する機会が増えたのですが、自分の言葉で説明するって知識を整理できていないと伝えることが難しいですよね。。

なので、自分の言葉で技術的な内容も伝えられるように、「インターネットの通信の仕組みについて」、自分なりに体系化して振り返る記事を書いていこうと思います!!

今回は、どのように通信が行われているかを仕組化したモデルである

下記の図のOSI参照モデルについて第一層から第四層までふれて整理していこうと思います!

hyo1.jpg

参照:第10回 OSI基本参照モデル――7階層による道案内で,データを迷わせない | 日経クロステック(xTECH) (nikkei.com)

とっつきやすく説明するためにも、ネット通販で利用する「物流」を例にしてみて通信の流れを説明しまーす!

まず初めにお客さんから注文が来たら、荷物をどのような手段で運びますか???

       main.gif

インターネット的答え : Ethernet(イーサネット)、ハブを通して運びます!

       computer_lan_cable.png  hub-illust01-eyecatch.png 

このEthernet(イーサネット)が属しているのが第一層の【物理層】となります!

(物理層とは上位層から送られてきたデータを「電気信号」や「光信号」などに変換するための手段が定義されている層となります!)

そして、ハブが属しているのが第二層の【データリンク層】となります!

(データリンク層とは、隣接する機器間の通信を可能にする層となります!)

これらの第一層の【物理層】と第二層の【データリンク層】を通して、通信信号が物理的な機器を通じて運ばれます!!

次に、注文された荷物はどこに運べばよいですか??

  japan.jpg

インターネット的答え : この「IPアドレス」に運んでください!!

「IPアドレス」がいわゆる通信における届け先の住所のようなものになります!!

そして、このIPアドレスが属するのが第三層の【ネットワーク層】となります!

(ネットワーク層のざっくりとした役割は目的地までデータを届ける層という役割です。)

  250px-Ipv4_address_ja.svg.png

参照:IPアドレス - Wikipedia

【補足①】

IPアドレスにも大きく2種類のアドレスがあり、

「192.168.0.1」のような見た目のIPアドレスは「IPv4」と言います。

このIPv4は、約43億個しかIPアドレスが使用できず、一見非常に多い数に見えるのですが実際には数が足りず

次にできたのが、IPv6となります。「fd00:12:11af:1:21b:8bff:fe9b:b3c8」のような見た目で

約340澗(340兆の1兆倍の1兆倍)個のIPアドレスが使用できます!

ちなみに、「澗」という漢字は「かん」と読むらしいです!

【補足②】

どうやってIPアドレスが取得できるの??

  img_dns.png

参照:DNSサーバーレンタル | レンタルサーバーなら【CPI】

普段のサイトのURLでは、ドメイン(yahoo.co.jpのような分かりやすい形)で表示されていて、誰にとっても分かりやすいURLになっていますが、「DNSサーバー」というサーバーを通じて「ドメイン」から「IPアドレス」へと変換されます!

ざっくりと「ドメイン」→「DNSサーバー」→「IPアドレス」という流れでIPアドレスが取得できると覚えておきたいですね!

荷物を届ける住所(IPアドレス)はわかりました!!!

次に、お荷物は何号室に届ければ良いですかー??

          201579153358.png

インターネット的答え : 80番のお部屋に届けてください!

この番号が割り振られた「ポート番号」というものが属するのが第4層の【トランスポート層】ですね!

(トランスポート層はデータ送受信に関しての取り決めを行う役割を果たします。)

通信を行う際には、たくさんあるポート番号のどれかを通って通信がされます!

しかしながら下記の図のようにポート番号によって通信方法が全く違います!

    prptocol.png

参照:セキュリティの基本 ポートとポートスキャンとは? (eng-entrance.com)

特に、ポート番号の80番(HTTP)と443番(HTTPS)は覚えておきたいですねー!

【補足】

下記の図のように、HTTPリクエストをする際には、リクエストメソッドにおいてメソッド定義がされます(GETや POST等)。この時、HTTPはヘッダとボディがセットとなった形状で通信が行われます!

APIを利用する際に、HTTPリクエストでデータを送る際には、メッセージヘッダにURLを指定して、メッセージボディに渡すデータを記載するといった形で利用してレスポンスを返してもらいます!

     http_message.gif

参照:第6回 インターネット広告の配信と測定の仕組み(1) | マーケティングオートメーションのアクティブコア (activecore.jp)

また、「HTTPリクエスト」には以下の図のような種類のリクエストがあります。

       tcpip2_9.gif

参照:「HTTP」の仕組みをおさらいしよう(その1):リトライ! 触って学ぶTCP/IP(2)(3/3 ページ) - @IT (itmedia.co.jp)

そして、「HTTPレスポンス」も同様に複数の種類のステータスが存在してます。

代表的なステータスコードは下記のようになります。

  ki1-1.png

参照:よく見かけるステータスコードの意味を解説 | クロスウォーク (crosswalk-seo.com)

ざっくりと、

200番台は成功レスポンス。

300番台はリダイレクション。

400番台はクライアントエラー。

500番台はサーバーエラー。

という感じのステータスコードになるということは覚えておきたいですね!

そして、注文した中身(約束事)は何ですかー??

           nakamio.jpg

インターネット的答え : HTTPです!

このHTTPというのが通信プロトコル(コンピュータでデータをやりとりするために定められた手順や規約)というものになります!!

このプロトコルがお互いに合っていないと、意思の疎通ができません!

   prptocol.png

参照:セキュリティの基本 ポートとポートスキャンとは? (eng-entrance.com)

【補足】

代表的なプロトコルにHTTPとHTTPSがあるのですが、この両者の違いには

「SSL」で暗号化がされているかどうかという違いがあります。

    http_https.png

参照:HTTPとは?HTTPSとの違いをサイト移行で実施するリダイレクト設定などをもとに解説 | ITコラム|アイティーエム株式会社 (itmanage.co.jp)

SSL化されていない通信だと中身が容易に解読されてしまうのでセキュリティ的に危険な状態となります。

そのため、インターネット上の通信を暗号化するためのSSLという仕組みがあるのですが、

それは下記のように仕組みで行われます。

    1.jpg

参照:安全な接続方法「SSL」や「TLS」とは? | サイバーセキュリティ情報局 (canon-its.jp)

上の図では大きく4つの鍵が登場します。

クライアント側が通信を暗号化するための「共通鍵」

クライアント側にて共通鍵と組み合わせることで「暗号化された共通鍵」を作成するための「公開鍵」

サーバー側が通信の暗号化された共通鍵を解除するための「秘密鍵」が出てきます。

流れとして、初めにサーバーから「サーバー証明書」と「公開鍵」が送られます。

この公開鍵は共通鍵を暗号化するために使われ、②のようにサーバーへと送付されます。

そして、サーバー側では秘密鍵(解除する鍵)を使用し、共通鍵へと復号(元のデータに戻すこと)します。

その後、共通鍵を使い再度暗号化させてクライアント側にデータを送信します。

ここでは「共通鍵暗号方式」と「公開鍵暗号方式」という二つの暗号方式を併用して、SSL化がされているのですが理解するには、少し複雑かもしれません。

詳しくは下記のサイトが非常にわかりやすかったのでよければ見てみてくださいね!

参照:SSLとは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 (i-3-i.info)

また、HTTPとHTTPSでは、ステートレスとステートフルという違いもあります。

    zu02.png

参照:セッションハイジャックでユーザーになりすます | 日経クロステック(xTECH) (nikkei.com)

「ステートフル」だと、やり取りした情報を覚えていてくれて、

「ステートレス」だと、やり取りされた情報が消えてしまいます。

この便利なステートフルという仕組みには「Cookie」が使用されています。

      cookie.gif

参照:基礎知識 Cookieの仕組み (soumu.go.jp)

Cookieを使用することで、サーバーから取得した情報を

ブラウザに保存することができます(ドメインごとに異なるCookieでデータを保持できます)。

ただし!! CookieはPCから中身の情報を見えたり、変更できてしまうので

Cookieには重要は情報(クレジットカードの情報等)を保存してはいけません。

そこで、より重要な情報を利用する際にはサーバー側で保存する「Session」という仕組みを使用します。

   スクリーンショット 2022-03-24 173916.png

参照:セッションIDとは | 分かりやすく図解で解説 - ITを分かりやすく解説 (medium-company.com)

CookieにセッションIDだけを保存して、再度サーバーにアクセスする際には

セッションIDを鍵のように利用して、以前やり取りしていた情報を再取得します。

ログアウト時には、セッション情報(鍵の情報)を削除して安全に接続を遮断します。

   スクリーンショット 2022-03-24 174450.png

参照:セッションIDとは | 分かりやすく図解で解説 - ITを分かりやすく解説 (medium-company.com)

大切な情報はSessionに保存するべしと覚えておけばよいですね!

ただ、補足として「セッションハイジャック」という攻撃もあります!

    スクリーンショット 2022-03-31 140535.png

参照:セッションハイジャックとは | 分かりやすく図解で解説

セッションIDを盗聴する攻撃なのですが、このセッションハイジャックへの対策としては

ログインしたユーザーが急に異なるIPアドレスから接続してきた場合は、

強制的にログアウトさせるといった作りにしておくことも有効です!

【補足】

Cookieやセッションを詐取する「クロスサイトスクリプティング」という攻撃もあります。

   スクリーンショット 2022-03-31 143954.png

参照:クロスサイトスクリプティング(XSS)とは?攻撃の被害例や対策

上記の図の場合でいうと、

ユーザーが掲示板サイトBを閲覧する。

→掲示板サイトB内でスクリプト(ウイルス)実行される。

→ユーザーはスクリプト情報を持ったままA社のページに移動(クロスサイト)する。

→スクリプトの効果により「A社のサイトとして」表示された偽サイトにジャンプする。

→騙されたユーザーが情報を入力した結果、スクリプトが悪さをする。

→攻撃者Cの手により、ユーザーに対して様々な被害が発生。

といった流れで「クロスサイトスクリプティング」攻撃が発生します。

このクロスサイトスクリプティングへの対策として、下記の2種類の方法があります。

①エスケープ処理を行う(サニタイジング)

HTMLやJavaScriptのコードが埋め込まれてしまい、そのまま読み取って処理してしまうことが問題なので、特定の文字を無効化する等の処理をして、実際に埋め込まれたスクリプトは実行はされないようにする対策。

②WAF(Web Application FIrewall) を利用する。

WAFは、Webアプリケーションに特化しているファイアウォールです。Webアプリケーションの前面やネットワークに配置し、脆弱性を悪用した攻撃を検出・低減する対策。

  firewall_60-0023.png

参照:【2022年版】ファイアウォールおすすめ製品比較!失敗しないポイントも解説

少し脇道に逸れてセキュリティ等にも触れて記事を書きましたが、ざっくりと通信の流れについて自分なりに体系化して記事を書いてみました!

今回の記事の作成を通じて、自分の知識が整理できたのでいい機会となりましたー!定期的なアウトプットは大切ですね!

以上久野の記事でしたー!

お気軽にご依頼・ご相談ください

前へ

Azure DevOpsでPower AppsのGit管理をするぞ。

次へ

Lottieで簡単にSVGアニメーションを実装!After Effects初見からWEBページ設置までの流れをまとめました