TCPとUDPの違いは何?と聞かれると実は答えに困ってしまうという方もいるのではないでしょうか。弊社の動的テストツールDT10(以下、DT10)はEthernet経由でログを出力できますが、「TCPとUDPのどちらを使用すればよいのか?」というご相談もよく受けます。

そこで今回は、そもそもTCPとUDPはどういったプロトコルでどういった特長があるのかをおさらいし、DT10ではどちらを選ぶべきかを解説します。また、その特長を活かしたオーバーヘッドの削減方法も紹介します。

オーバーヘッドって何?という方はコチラ↓もどうぞ!

オーバーヘッド って何なんだ!!!?
~ソフトの動的解析に付きまとう余計な処理時間を何とかしたい~

ソフトウェアの検証を考えるうえでゼッタイ避けては通れないオーバーヘッドについて、組込み機器をアレコレいじってきたエンジニアが、とりあえず思いの丈をまとめてみました。
続きを読む
 

TCPとUDPの違い

TCP と UDP はともにクライアントとサーバ間での通信チャネルの提供、通信管理を行う、レイヤー 4 のプロトコルです。通信チャネルというのはいわゆる “ポート” というもので、1 番から 65535 番までの番号が使用できます。同じ IP アドレスであっても TCP や UDP のポートが異なれば、提供されるサービスが異なります。

 
TCPとは

TCP (Transmission Control Protocol) は、IPの上位プロトコルのトランスポート層で動作するプロトコルです。インターネットにおいて標準的に利用されているプロトコルでネットワーク層のIPとセッション層以上のプロトコル(例:HTTP、FTP、Telnet) の橋渡しをする形で動作しています。

TCPは、高信頼性(3 way ハンドシェイクによる通信前の打診、ack による相手の受信確認や再送処理、等)や 通信効率の最適化機能(Windowによるフロー制御や輻輳制御)を提供します。そのため、UDPと比べて負荷がかかります。

 
UDPとは

UDP (User Datagram Protocol) は、TCPと同様にIPの上位プロトコルのトランスポート層で動作するプロトコルです。インターネットにて標準的に利用されているプロトコルでネットワーク層のIPとセッション層以上のプロトコル( 例:DNS、NTP、DHCP )の橋渡しをするかたちで動作しています。

UDPは、コネクションレス型のプロトコルであることから、TCPに比べると信頼性がないものの高速に転送を行うことができます。また、UDPヘッダサイズ(8byte)が少ない事から、その分アプリケーションのデータを多く送受信することができます。ただし、パケットが到達する保証がないことから、パケットロスなどの場合アプリケーション側で再送処理をして通信を成立させるかパケットロスが容認できるアプリである必要があります。

 

TCPとUDPの違いをまとめた表が以下になります。どちらかが優れているということではなく、通信特性によりTCPまたはUDPを使い分けます。

 
DT10ではどちらを使えば良い?

TCPとUDPのメリット/デメリットは以下になりますが、TCPのメリットがUDPのデメリットに、TCPのデメリットがUDPのメリットに相当するというイメージです。

どちらの方式を使うかは自由ですが、各方式のメリット/デメリットを考慮して次のように使い分けすることを想定しています。

オーバーヘッドだけを考慮すると「あれ?DT10ではTCPよりUDPを使った方が良いのではないかな?」と思うかもしれません。しかし、詳細を把握していない処理の不具合解析中にパケットロスが発生してしまい、肝心のログデータが取得できないという可能性がUDPにはあります。オーバーヘッドを抑えつつも確実にデータを取得できる方法はないのでしょうか。

 

TCPの特長を活かしたドライバのカスタマイズ

弊社で提供しているサンプルドライバでは、テストポイントを通過するたびにTCP送信APIを呼び出し、データを送信します。 ひとつのテストポイントのデータは22Byteと小さいのに、1つのパケットに区切られるため、パケットを送信する度にヘッダ情報が付加されてしまい、データ転送量が大きくなります。そのため、オーバーヘッドが大きくなるという欠点があります。

 
まとめて送ってオーバーヘッドを抑える

TCPが高信頼性であるという特長を利用し、複数のテストポイントのデータを1つのパケットでまとめて送信頻度を減らすことで、オーバーヘッドを削減し、かつ正しいデータを送信できます。カスタマイズ例を以下に示します。

ポイントとなるのは、テストポイント通過時はバッファにデータを格納するだけであること(青色部分)、TCP送信APIの呼び出しはバッファフル状態のとき実行されること(オレンジ色の部分)です。前述のサンプルドライバのようにいちいちヘッダ情報を付加せず、MSS(Maximum Segment Size = 1460Byte)毎にヘッダ情報が付加されます。これによりデータ転送量を抑えられますので、オーバーヘッドの削減が可能になります。

例えば、10個のテストポイントを通過したときのデータ転送量を比較すると以下のようになります。TCPヘッダは20~60Byteですが、ここでは60Byteで計算しています。

  • サンプルドライバのデータ転送量  =  (TCPヘッダ(60Byte) + テストポイントデータ(22Byte)) * 10 ⇒ 820Byte
  • カスタマイズドライバ のデータ転送量 =  TCPヘッダ(60Byte) + (テストポイントデータ(22Byte) * 10) ⇒ 280Byte

このように1度に送信するデータ転送量はサンプルドライバの4分の1に抑えることができます。

 

まとめ

DT10のEthernet接続において、TCPとUDPを比較すると、TCPでオーバーヘッドが大きいことを容認して信頼性を取るか、UDPで信頼性を犠牲にしてもより小さいオーバーヘッドにするかのいずれかになります。そこで、高い信頼性のTCP接続のドライバのカスタマイズによって、UDPのようなパケットロスも発生せず、複数のテストポイントデータをバッファにまとめて送信することで、TCPの最大の問題であるオーバーヘッドを削減できます。両者のいいとこ取りをしたEthernet接続使用法ではないでしょうか。

今回ご紹介したドライバを試してみたいという方やドライバの改善をご検討の方は、
ぜひ【こちら】までお問い合わせください。


組込みソフトのバグを解析する「動的テストツールDT+」


「DT+(ディーティープラス)」は、組込みソフトウェアのリアルな実行経路を見える化できるデバッグツールです。 経路情報を取得するためのテストポイントを、ソースコードに自動で挿入して、いつも通り実行するだけ。

詳細はこちら

【 無料セミナー 】
レガシーコードをいじる前に知っておいてほしい「動的テスト」の3つの使い方

レガシーコードやOSSなどの資産を使ったソフトウェア開発では、ベースコードへの理解は最重要。
しっかり理解せずに開発してしまうと、あとで不具合発生の温床になってしまうことも。
そんなときこそ、ソフトウェアの実挙動を解析する「動的テスト」の出番。
はじめましてのソースコード相手でも短時間でかなり深く理解できる仕組みをご紹介します。

お申し込みはこちら!