UDPを利用するインターネットの重要なアプリケーションはいくつもある。例えば Domain Name System (DNS) は、1つのクエリに素早く1つの応答パケットを返すだけなのでUDPを使用している。他にも Simple Network Management Protocol (SNMP)、Routing Information Protocol (RIP)、Dynamic Host Configuration Protocol (DHCP)、Network Time Protocol (NTP) などがある。音声や動画のトラフィックも一般にUDPを使用している。リアルタイムの動画・音声ストリーミングのプロトコルはパケット喪失が発生しても画質・音質が若干低下するだけで済むよう設計されており、喪失パケットの再送を待って止まってしまう方が不都合である。TCPとUDPは同じネットワーク上で使われており、ストリーミングなどの用途が増えているため、UDPトラフィックの割合も増えている。そのため、POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる。
UDPアプリケーションはパケットの喪失、誤りが起こることを想定しなければならない。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している。多くの場合、UDPアプリケーションは信頼性機構を持たず、むしろそのオーバーヘッドを嫌っている。ストリーミング、リアルタイムのオンラインゲーム、VoIPといった用途ではUDPを使うことが多く、パケット喪失は大きな問題とはならない。高信頼性が求められる用途では、Transmission Control Protocol などのプロトコルや消失訂正符号を代わりに使う。より深刻なのは、TCPとは異なり、UDPアプリケーションでは輻輳を回避・制御する機構を持たないことがある点である。帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。
検査合計の計算法は RFC 768 で以下のように定義されている。IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットを検査合計とする。つまり、全16ビットワードを1の補数演算で足しあわせる。その合計を1の補数化すればUDPの検査合計・フィールドの値になる。検査合計計算の結果がゼロになる場合（16ビット全部が0）、検査合計を省略する場合と区別するため、その1の補数（全ビットが1）を設定する。IPv4とIPv6では検査合計計算に使うデータに差異がある。
UDPアプリケーションはデータグラム・ソケットを使ってホスト間の通信を行う。アプリケーションでソケットとデータ転送のエンドポイントを結びつけるのだが、そのエンドポイントはIPアドレスとサービスポートの組み合わせで表される。ポートとはポート番号で識別されるソフトウェア構造であり、ポート番号は16ビット整数値で0から65,535まである。ポート番号0は予約されているが、送信側プロセスが応答を期待していない場合は使うことも許されている。Internet Assigned Numbers Authority (IANA) はポート番号を3つの範囲に分割した。0から1023まではウェルノウンポートであり、よく知られている一般的サービスが使用する。Unix系オペレーティングシステムでは、そのうちの一部の使用にはスーパーユーザーの権限を必要とする。1024から49,151まではレジスタードポートであり、IANAが登録したサービスが使用する。49,152から65,535まではダイナミックポートであり、公式には特定サービスに割り当てられておらず、任意の用途で使用可能である。エフェメラルポートとしても使用でき、ソフトウェアがランダムに選んで使うことができる。一般に、クライアントが何らかのサーバと通信する際に一時的ポートとして使用する。
1912年（明治45年）7月17日、海軍兵学校を卒業（40期）。翌年12月、海軍少尉任官し「金剛」乗組となる。1918年（大正7年）12月から1年間、海軍水雷学校高等科で学んだ。1919年（大正8年）12月、「扶桑」分隊長となり、「龍田」分隊長、「浦風」水雷長兼水雷学校教官、「汐風」水雷長などを経て、1923年（大正12年）3月、海軍大学校選科学生となった。1925年（大正14年）4月、「阿蘇」分隊長となり、同年12月、海軍少佐に昇進し「迅鯨」水雷長に就任。1926年（大正15年）12月1日、「五十鈴」水雷長となり、「古鷹」水雷長、「灘風」駆逐艦長、兼「夕風」駆逐艦長、「榛名」水雷長などを経て、1937年（昭和12年）12月、海軍中佐に進級し「鳴戸」副長に就任。1933年（昭和8年）11月、「多摩」副長となり、「木曾」副長、「対馬」艦長、第4駆逐隊司令、「嵯峨」艦長などを歴任し、1938年（昭和13年）11月、海軍大佐に進級。同年12月、「北上」艦長に就任し、鎮海要港部軍需部長を経て、1941年（昭和16年）4月、鎮海軍需部長となり太平洋戦争を迎えた。1943年（昭和18年）3月、横須賀鎮守府付となり、第9特別根拠地隊付、第11潜水艦基地隊司令、兼第9警備隊司令、横須賀鎮守府付を歴任し、同年11月、海軍少将に進級。同月、軍令部出仕となり、翌月、待命・予備役編入となった。