はじめに
「L3で動作するNLB(Network Load Balancer)でパスベースルーティングをしたい！」
私がこう言ったとき先輩は頭を抱えていました。
NWに関する一定の知識があれば上記が不可能であるとわかると思いますが、
AWSの知識しかない私は可能であると信じていました。
上記のような誤りを起こさないために、
本記事はTCP/IPのレイヤ3に関して知識の整理を行うことを目的とした備忘録になります。
TCP/IPプロトコルの全容を図で確認
ひとまず学習対象であるTCP/IPプロトコルの全容を確認する。
TCP/IPは以下図の構成となっていることだけ再認識する
| 層 | 名称 | 規格(プロトコル) | 利用例 |
|---|---|---|---|
| 4層 | アプリケーション層 | HTTP,HTTPS,SMTP,POP3,IMAP4,DHCP,DNSなど | Webサイト閲覧、メールファイル転送など |
| 3層 | トランスポート層 | TCP,UDP,NetWare/IPなど | TCP/UDP(データを適切なアプリケーションへ振り分け) |
| 2層 | インターネット層 | IP,ARP,RARP,ICMP | ルーティング,エンドツーエンド通信,Ping |
| 1層 | ネットワークインターフェイス/リンク層 | Ethernet | LAN |
※参照：TCP/IPプロトコル通信のネットワークアーキテクチャを図解で解説
トランスポート層(3層)とは
一言でいうと
トランスポート層の主な役割は「アプリケーションの識別・転送制御」である。
要するにデータを適切なアプリケーションに振り分けることを目的とした階層となる。
役割について
インターネット層(2層)は色々なネットワークを超えて通信相手に、
パケットを届けることが仕事であり、
通信相手にパケットを届ける以上のことをしてくれない。
そのため、受信したサーバ側はどのアプリケーションにパケットを渡してよいのかわからない事象が発生する。
この問題を解消するのが、トランスポート層となります。
トランスポート層では「ポート番号」という数字を利用して、
パケットを渡すアプリケーションの識別を可能とする。
また、アプリ要件に合わせてパケットの送受信量を制御したり消失したパケットの再送を行える。
※参照：TCP/IPプロトコル通信のネットワークアーキテクチャを図解で解説
トランスポート層で利用されるプロトコル
・UDP(User Datagram Protocol)：即時性を求めるときに使用
・TCP(Transmission Control Protocol)：信頼性を求めるときに使用
UDPについて
UDPは音声通話や名前解決(DHCP)や時刻同期など、
即時性(リアルタイム性)を求めるアプリケーションで使用する。
UDPのヘッダー情報(パケットフォーマット)について
UDPがヘッダーとしてアプリケーション層から受信したデータに付与する内容は以下である。
参照：UDPヘッダのフォーマットとサイズの基本
■送信元ポート
コネクションを作るときにOSが決めたランダムに割り当てた値が
「送信元ポート」として設定される。
応答を受け付ける役目もあるため、返信不要の場合は0となる
■宛先ポート
アプリケーションごとに定義されている値を「宛先ポート」にセットしてサーバに送信する。
宛先ポートを見て適切なアプリケーションにデータを送信する。
■UDPデータ長
UDPヘッダーとUDPペイロード(アプリデータ)を合わせた全体のサイズ。
データグラム長とも呼ばれる
※データグラム：トランスポート層における通信の単位
■チェックサム
受け取ったUDPデータグラムの破損確認のための整合性チェック
TCPについて
TCPはメールやファイル転送、Webブラウザなどデータを送り届けることについて、
信頼性を求めたい場合に使用する。
TCP構成について
TCPはアプリケーションデータを送信する前に「TCPコネクション」という論理的な通信経路を作成し、
通信先との通信接続を確立する。
この通信接続の確立を「3ウェイハンドシェイク」と呼ぶ。
※実際の論理通信経路は二重に冗長構成がとられている
参照：https://www.infraexpert.com/study/tcpip9.html
TCPのヘッダー情報(パケットフォーマット)について
TCPがヘッダーとしてアプリケーション層から受信したデータに付与する内容は以下である。
※参考：https://shinmeisha.co.jp/newsroom/2020/06/05/tcpヘッダのフォーマットとサイズの基本/
■送信元ポート
コネクションを作るときにOSが決めたランダムに割り当てた値が
「送信元ポート」として設定される。
応答を受け付ける役目もあるため、返信不要の場合は0となる
■宛先ポート
アプリケーションごとに定義されている値を「宛先ポート」にセットしてサーバに送信する。
宛先ポートを見て適切なアプリケーションにデータを送信する。
■シーケンス番号
データが順番通り届いているか確認するための番号
■確認応答番号
シーケンス番号に受信したデータバイト数を足して確認応答（ACK）番号として応答する。
※シーケンス番号と確認番号が常に連動することで信頼性を担保する
■データオフセット
TCPヘッダの長さを表す4ビットフィールド
■予約
将来的な使用のための予約範囲。常に0。
■フラグ
コネクションのステータス
6つのフラグ情報「URG,ACK,PSH,RST,SYN,FIN」それぞれが1ビットで、
0にしたり1にしたりすることでコネクションの状況を連携している
■ウィンドウサイズ
応答確認を待たずにまとめて送ることのできるデータ量を示す
■チェックサム
TCPヘッダとデータ部分が正しいかチェックするために使用される
■ポインタ
URGフラグが有効になっている場合に、緊急データの位置を示す。
ポート番号について
ポート番号とアプリケーションは一意に紐づいていて、
ポート番号さえ見ればどのアプリケーションにデータを渡せばよいかわかる。
ポート番号が無いとIPパケットを受領した端末はどのアプリで処理すればよいのかわからなくなる。
ポート番号の種類
アプリケーション層で動作するアプリケーションを識別する数字であり、
0~65535番まで存在し「System Port(Well-knownPorts)」「User Ports」「Dynamic and/or Private Ports」の
３種類が存在している。それぞれの役割は以下の通りである。
| ポート番号の範囲 | 名称 | 用途 |
|---|---|---|
| 0~1023 | System Port(Well-knownPorts) | 一般的なアプリケーションで使用 |
| 1024~49151 | User Ports | メーカーの独自のアプリケーションで使用 |
| 49152~65535 | Dynamic and/or Private Ports | クライアント側でランダムに割り当てて使用 |
System Port(Well-knownPorts)
ポート番号「0~1023」一般的には「ウェルノウンポート」と言われている。
以下が代表的なSystemPortsである。
| ポート番号 | UDP | TCP |
|---|---|---|
| 20 | - | FTP(データ) |
| 21 | - | FTP(制御) |
| 22 | - | SSH |
| 23 | - | Telnet |
| 53 | DNS(名前解決) | DNS(名前解決、ゾーン転送) |
| 69 | TFTP | - |
| 80 | - | HTTP |
| 110 | - | POP3 |
| 123 | NTP | - |
| 443 | HTTPS(QUIC) | HTTPS |
| 587 | - | サブミッションポート |
User Ports
ポート番号「1024~49151」メーカーが独自に開発したアプリケーションを一意に紐づけている。
以下が代表的なUserPortsである
| ポート番号 | UDP | TCP |
|---|---|---|
| 1433 | - | Microsoft SQL Server |
| 1521 | - | Oracle SQL Net Lisner |
| 1985 | Cisco HSRP | - |
| 3306 | - | MySQL Database System |
| 3389 | - | Remote Desktop |
| 5432 | - | PostgreSQL |
Dynamic and/or Private Ports
ポート番号「49152~65535」はクライアントアプリケーションがコネクションを作るとき、
送信元ポート番号としてランダムに割り当てる。
※ランダムに割り当てるポート番号の範囲はOSごとに異なっていている
なお、僧院元ポート番号はクライアント端末の中で一意であれば良い
思いついた疑問点
クライアント側がデータを送るとき、UDPとTCPはタイミングで指定すればいいの？
A：アプリケーション層にて使用するプロトコル次第で決定される(例外あり)
上記プロトコルはアプリケーション内で柔軟に使い分けができるわけではなく、
両プロトコルの使い分けは、アプリケーション層で使用するプロトコルに依存することになる。
例えば、アプリケーション層で使用するHTTPプロトコルは通常TCPで使用し、
UDPで使用することができない。
例えば、80番ポートへ向けてリクエストを受けた場合、
80番ポートが使用されるプロトコルはTCPしかないため、利用プロトコルはTCPとなる。
※例外的にどちらもサポートしているプロトコル/アプリが存在する。
その際はオプション等で使用するプロトコルを選択
「L3で動作するNLB(Network Load Balancer)でパスベースルーティングをしたい！」への回答
そもそもパスベースはアプリケーション層(HTTPプロトコル)の機能につき、
L3で動作するNLBではパスベースルーティングが不可能である。
NLBが行えるルーティング条件からわかる通り、IPベースのルーティングしか基本的にサポートしていない。
従って受信時は下図のようにL3より下層の付与されるヘッダ情報(ポート/プロトコル)を使用して受信し、
送信時のルーティングは「送信元IP、送信元ポート、宛先IP、宛先ポート、プロトコル」の５つの条件を利用して振り分け先を決めます。
最後に
AWSなどのクラウドに触り続けると、
インフラの基礎的なことが理解できないまま構築が進んでしまいます。
本記事は個人の備忘録となりますが、誰かの何かの役に立てば幸いです。
参考文献
この記事は以下の情報を参考にして執筆しました。