TCP と UDP のどちらも有効なトランスポート層のプロトコルです。 アプリケーションの要件に応じて、これらのトランスポート層のプロトコルのどちらか一方または場合によっては両方を使用できます。 アプリケーション開発者は、アプリケーションの要件に基づいて、どちらのトランスポート層プロトコル タイプが適しているのかを決める必要があります。
一部のアプリケーションでは、セグメントが正しく処理されるために、セグメントがある一定の順序で到達する必要があります。 また、すべてのデータが完全に受信されて初めてデータが有効であると見なされるアプリケーションもあります。 どちらの場合も、トランスポート層のプロトコルとして TCP が使用されます。 たとえば、データベース、Web ブラウザ、電子メール クライアントなどのアプリケーションでは、送信されたすべてのデータが元の状態で宛先に到達する必要があります。 データが少しでも失われると通信は正しく行われずに、完了エラーまたは読み取りエラーが発生します。 したがって、これらのアプリケーションは TCP を使用するように設計されています。 これらのアプリケーションでは、オーバーヘッドの増加がやむを得ないものと見なされます。
それに対し、ネットワークで伝送中に一部のデータが失われるのは許容できても、伝送の遅延は受け入れられないアプリケーションもあります。 UDP はネットワーク オーバーヘッドが少なくて済むので、このようなアプリケーションには適しています。 UDP はストリーミング オーディオ、ストリーミング ビデオ、Voice over IP（VoIP）などのアプリケーションに向いています。 確認応答を行うと配信が遅れる上、再送信も好ましくありません。
たとえば、ビデオ ストリームのセグメントが 1 ～ 2 個到達しなかった場合でも、そのストリームは瞬間的に中断するだけで済みます。 この現象は、結果として画像の歪みを生じさせることもありますが、ユーザには明確にわからないこともあるでしょう。 しかし、宛先のデバイスがデータの消失に対応し、再送信を待ってストリームを遅らせなければならないとしたら、ストリーミング ビデオ画像の品質は大幅に低下します。 この場合、受信したセグメントで可能な最上のビデオを表示し、信頼性を放棄するのが望ましいでしょう。
インターネット ラジオは、UDP を使用するアプリケーションのもう 1 つの例です。 メッセージの一部がネットワークを伝わる途中で失われても、再送信されません。 一部のパケットが失われると、聴取者には音が少し割れたように聞こえることがあります。 もし TCP が使用されていて、失われたパケットが再送信されると、再送信されたパケットを受信するために伝送が停止し、さらに音声が割れたり、飛んだりして聞こえにくくなります。