TCPとUDPの違い|現役が教える「FWポリシー設計」という実務の核心

CCNAと実務

「TCPとUDPの違いを説明してください」——ネットワークの面接や研修で定番の質問ですが、現場で後輩を見ていると、これに自分の言葉で答えられる人は意外なほど少ないです。

「TCPは信頼性があって、UDPは速い」と暗記はしていても、なぜそうなのか、それが実務のどこで効いてくるのかまで説明できる人は一握りです。

この記事では、現役10年のネットワークエンジニアとして、TCPとUDPの違いを仕組みから解説します。そして後半では、多くの解説記事が触れない「ネットワークエンジニアはどこでTCP/UDPを意識するのか」——ファイアウォールのポリシー設計という実務の核心を紹介します。

TCPとUDPは何をしているのか

TCPとUDPは、どちらもOSI参照モデルの第4層(トランスポート層)で動くプロトコルです(階層の話はOSI参照モデルの記事を参照)。役割をひとことで言えば、「届いたデータを、どのアプリケーションに渡すかを仕分けること」「その受け渡しをどれだけ丁寧にやるか」です。

仕分けに使われるのがポート番号です。1台のPCでブラウザとメールを同時に使えるのは、ポート番号で「このデータはブラウザ宛、これはメール宛」と仕分けているからです。そして「どれだけ丁寧に運ぶか」の設計思想が、TCPとUDPで正反対です。

TCP:確認しながら確実に届ける

TCP(Transmission Control Protocol)は、データを確実に、順番どおりに届けることを重視した方式です。

通信を始める前に、3ウェイハンドシェイクという手順で「これから送っていいですか?」「いいですよ」「では始めます」という確認を交わします(SYN → SYN-ACK → ACK)。

データを送った後も、届いたかどうかの確認応答(ACK)を取り、届いていなければ再送します。順番が入れ替われば並べ直します。

宅配便で言えば、手渡しで受領印をもらう配達です。Webページの表示、メール、ファイル転送——「一部でも欠けたら困る」データは、すべてTCPで運ばれます。

UDP:確認せず、とにかく速く送る

UDP(User Datagram Protocol)は逆に、確認の手間を全部省いて、とにかく速く送る方式です。

ハンドシェイクなし、確認応答なし、再送なし。ポストに投函するハガキのように、送ったら送りっぱなしです。その分、TCPのような事前準備や確認のオーバーヘッドがなく、軽くて速い。

ビデオ会議や音声通話、ライブ配信を考えてみてください。0.1秒前の音声パケットが1つ欠けたとして、それを再送してもらって遅れて再生されるより、多少欠けてもリアルタイムに流れ続けるほうが大事です。

こういう「鮮度が命」の通信にUDPが使われます。DNSの名前解決も、小さな問い合わせを高速に捌きたいのでUDPが基本です。

TCPUDP
方式コネクション型(事前に接続確立)コネクションレス型(いきなり送る)
信頼性確認応答・再送・順序保証ありなし(送りっぱなし)
速度・負荷重い(その分確実)軽くて速い
主な用途Web、メール、ファイル転送、SSH音声・映像、DNS、NTP、SNMP

覚え方:「欠けたら困るか、遅れたら困るか」

初学者向けに、私なりの整理を1つ。「データが欠けたら困る通信はTCP、遅れたら困る通信はUDP」です。

ファイルは1バイト欠けても壊れます=欠けたら困る=TCP。通話は少し欠けても会話は成立しますが、5秒遅れたら会話になりません=遅れたら困る=UDP。この軸で考えると、初見のプロトコルでも「どちらを使っていそうか」の見当がつくようになります。丸暗記より、この判断軸を持つことをおすすめします。

【現場の視点】TCP/UDPを一番意識するのは、FWのポリシー設計

サイト主
サイト主

“動画はUDP、WebはTCP”は正直アプリを作る側の話です。ネットワークエンジニアがTCP/UDPを意識するのは、圧倒的にファイアウォールのポリシー設計のとき。ここが実務の核心です。

ここからが、多くの解説記事に書かれていない話です。「動画はUDP、WebはTCP」という使い分けは、正直に言えばアプリケーションを作る側の話です。では、ネットワークエンジニアは、いつTCP/UDPを意識するのか。

私の実感では、圧倒的に多いのがファイアウォールのポリシー設計のときです。

FWやACLで通信を許可するルールは、基本的に「プロトコル(TCPかUDPか)+ポート番号」のペアで書きます。「TCPの443番を許可」「UDPの123番を許可」という具合です。

ここで、通したいアプリケーションがTCPを使うのかUDPを使うのかを取り違えると、ルールは書けているのに通信が通らないという状況になります。設定は入っている、だが動かない——切り分けに時間を食う、地味に嫌なパターンです。

だから現場のエンジニアにとって、「このサービスはTCPかUDPか、ポートは何番か」という知識は、暗記クイズではなくポリシー設計の実務知識そのものです。ACLの書き方についてはACLの記事で詳しく解説しています。

【実務の勘所】DNSは「UDPだけ」ではない

サイト主
サイト主

“DNSはUDP53番”と覚えている人が多いですが、DNSはTCP53番も使います。ここを知らずにUDPだけ許可して、たまに名前解決が失敗する——地味にハマるやつです。

FWポリシーの文脈で、1つ実務の勘所を紹介します。「DNSはUDPの53番」と覚えている人は多いですが、実はDNSはTCPの53番も使います

代表的なのは、DNSサーバ間のゾーン転送や、応答サイズが大きくなるケースです。もしFWで「DNSはUDPだから」とUDP 53だけを許可していると、こうした通信が失敗します。

DNSを許可するときはTCP/UDPの両方の53番を考慮する——これは、TCP/UDPの知識がそのまま設計品質に直結する良い例です。

なお、UDPには「届かなくても送信側は気づけない」という性質があることも、頭の片隅に置いておいてください。SyslogやSNMPのような監視系の通信はUDPが多く、経路のどこかで破棄されていても、エラーは出ません。

「監視が飛んでいないことに、障害が起きてから気づく」という事態は、仕組み上起こりえます。

まとめ

  • TCPは確認しながら確実に届ける(3ウェイハンドシェイク・確認応答・再送)。UDPは確認せず速く送る
  • 覚え方は「欠けたら困るならTCP、遅れたら困るならUDP」
  • ネットワークエンジニアがTCP/UDPを一番意識するのはFWのポリシー設計。ルールは「プロトコル+ポート番号」のペアで書くため、取り違えると通信が通らない。
  • DNSはUDP 53だけでなくTCP 53も使う。FWでは両方の考慮が必要。
  • UDPは届かなくても気づけない性質がある。監視系(Syslog・SNMP)の経路設計では特に意識する。

ポート番号はNATのアドレス変換でも重要な役割を果たします。NATの記事、現場で使うコマンドはCCNAコマンドの記事もあわせてどうぞ。

コメント

タイトルとURLをコピーしました