はじめに
最近TCP/IP階層モデルというものを学びました。
しかし学んだのはいいものの実際の通信がどうかは想像がつきません。
なので最近メジャーであろうAWSEC2にその通信の構造を当てはめて勉強していきます。
まだまだ理解が浅いところもあると思いますのでそこだけはご理解ください。
TCP/IP階層モデルとは
この記事を見る時点である程度理解はあるかと思いますが一応。
TCP/IP階層モデルとはネットワーク通信の仕組みである。
その階層は4層に分かれており、それぞれに対して役割とそれを遂行するプロトコルが存在する。
またTCP/IP階層モデルは上層から処理していくため上から表記されることが多い。
4層：アプリケーション層
実際のデータを送信する層である。
例えばLaravelやReactでサーバーを構築しているとするとこのLaravelからのレスポンスの値やReactのHTMLなどがこれにあたります。
私たちが普段実装している目に見えるアプリケーションはこの層であることが多いでしょう。
プロトコルとしてはHTTPが多いです。
3層：トランスポート層
4層で作成されたデータを通信用に変換する。
アプリケーション層のデータはトランスポート層でカプセル化され、セグメント（またはデータグラム）として送られる。
この通信層ではUDPまたはTCPといったプロトコルを利用することとなる。
この3層と4層の間でHTTPS通信による暗号化をされることもあります。
2層：インターネット層
3層で作成されたセグメントをIP(インターネットプロトコル)を用いてデータを作成する。
こうして作成されたデータをIPパケットという。
またこのパケットに付与される住所をIPv4、またはIPv6でルーティングすることになる。
こうして作成されたIPパケットをIPSecというプロトコルでさらに暗号化されることもある。
1層：ネットワークインターフェース層
これまでで作成されてきたデータを実際に送信する層。
イーサネットやPPPといったプロトコルでさらに通信を保守化します。
LANなどによる通信層などもこの層になります。
AWSとの通信の流れについて
EC2との通信にはパブリックDNSというものを通じてEC2に乗っているサーバーにアクセスできます。
このDNSによってクライアントとサーバーがつながるようになるということです。
ではどのようなロジックでつながっているのでしょうか？
先程の流れにはDNSなんてものは出てこなかったがどう通信しているのか？
それを整理していきましょう。
通信の流れ
まずはクライアントからの通信をします。
<パブリックDNS>.<ルーティング>のように通信するとき、それはどうなっているのか。
このDNSというものはIPアドレスにたどり着くまでに通る道です。
IPアドレスというものは変化する可能性があるが、それでも入り口を変えないための仕組みということです。
このパブリックDNSをDNSサーバーというものを通じてIPアドレスに変換します。
このIPアドレスを知ることでアクセス先がわかって通信が可能になります。
ではどのようなロジックで通信ができるようになっているのかも整理しましょう。
このIPアドレスに変換されるにあたり、内部ではDNSがIPアドレスになります。
つまり内部的には.<ルーティング>になるわけです。
これで通信状態がわかるので通信ができるわけですね。
ではIPアドレスがわかったところでTCP/IP通信に置き換えます。
クライアント(リクエスト送信)
4層：アプリケーション層
リクエストデータをまとめます。
リクエストに必要なデータなどについてもこちらでまとめます。
これで本通信までの準備が整います。
3層：トランスポート層
まず、取得したIPアドレス宛にTCPハンドシェイクで接続を確立。次にTLSハンドシェイクで通信路を暗号化します。
その後アプリケーション層で作成したデータをその通信方法に合わせてデータを作成します。
これにあたっての通信確認を先程のIPアドレスで行います。
2層：インターネット層
3層で作成されたデータをIPを通じてIPパケットを作成します。
そしてIPパケットには通信先IPアドレスが乗ります。
これで送信先がわかっている送信データができます。
1層：ネットワークインターフェース層
これらを本通信で送信します。
イーサネットやLANなどによるデータの送信がこの段階で行われます。
このような徐々にデータを梱包していくのをカプセル化といいます。
サーバー(リクエスト送信)
1層：ネットワークインターフェース層
物理的な層から本データの受け取りを行います。
様々な過程で梱包されたデータをこの段階で受け取ることになります。
2層：インターネット層
IPパケットによって保護された通信をここで読み取ります。
この段階でIPヘッダが取り外され、中に含まれるTCPセグメントが上の層に渡されることとなります。
3層：トランスポート層
ここで送信データをTCPやUDPで受け取りさらにバラバラに届いたセグメントを正しい順序に並べ直して、元のデータに再構築します。
この通信のデータ分解をすることで送信されたリクエストデータそのものとなります。
4層：アプリケーション層
送信された通信データを処理できるようになります。
この段階でLaravelなどでAPIを送信したりできるようになります。
今回の例ではクライアントからのデータ受け取りを希望している前提なのでLaravelなどからAPIが返るものを想定するものとします。
このようなデータを紐解いていくのをデカプセル化といいます。
このようにしてリクエストの送信が行われます。
ではリクエストのレスポンス受け取りも行いましょう。
サーバー(データ送信)
とはいえリクエスト送信と大差があるわけではないのでざっくりと。
4層：アプリケーション層
実際のデータを作成するLaravelなどでデータを返します。(DBからのデータなど)
こういったレスポンスも先程のリクエストと同じように下層でデータ作成を行っていきます。
3層：トランスポート層
レスポンス内容をTCPやUDPでデータ作成していきます。
ここで再度送信元とのやり取りを行います。
2層：インターネット層
さらにIPを使って送信元を送信先として住所指定を行います。
こうしてデータ送信を準備をします。
1層：ネットワークインターフェース層
ここで本通信をします。
元々の送信元に戻っていきます。
クライアント(データ送信)
こちらも大差はないのでざっくりと。
1層：ネットワークインターフェース層
ここでレスポンスを受け取ります。
ここで受け取ったデータをデカプセル化していきます。
2層：インターネット層
ここでIPを使って住所の梱包を解きます。
この本データを上層に回していきます。
3層：トランスポート層
ここでもTCPやUDPによるデータの梱包を解きます。
こうしたデータをリクエスト元に戻します。
4層：アプリケーション層
ここでリクエストした内容のレスポンスが届くことになります。
一周で届くように見えた通信はこのようにTCP/IP通信を経てリクエストとレスポンスの通信が行われているのです。
終わりに
難しいように思えたTCP/IP通信も状況を整理してみるとわかりやすくなりました。
このようにデータの流れを抑えるのもとても大事だと改めて感じました。
この調子でOSI参照モデルも理解していきたいです。