ウリジン二リン酸

関: uridine diphosphate

WordNet

the 21st letter of the Roman alphabet (同)u

PrepTutorEJDIC

uraniumの化学記号
上流の,上流階級にふさわしい / (映画が)児童観覧用の

Wikipedia preview

出典(authority):フリー百科事典『ウィキペディア（Wikipedia）』「2013/12/20 21:26:25」(JST)

wiki ja

[Wiki ja表示]

「UDP」はこの項目へ転送されています。ヌクレオチドの一種のUDPについては「ウリジン二リン酸」をご覧ください。

User Datagram Protocol（ユーザデータグラムプロトコル、UDP（ユーディーピー））は、主にインターネットで使用されるインターネット・プロトコル・スイートの中核プロトコルの一つ。アプリケーションから Internet Protocol (IP) ネットワーク上の他のホストへ「データグラム」と呼ばれるメッセージを送るのに使われ、事前に転送チャネルやデータ経路といった特別な設定をする必要がない。デイヴィッド・P・リード（英語版）が1980年に設計し、RFC 768 で定義した（STD番号: 6）。非常にシンプルに設計されており公式仕様のRFC 768はわずか3ページである。

主にIPプロトコル上に実装されておりOSI参照モデルのトランスポート層にあたる。明確なハンドシェイクを省いたコネクションレスであり、送達確認などを行わない言わば無手順方式のデータ転送で、信頼性・順序性・データ完全性を保証しない。通信中のパケット紛失や重複、データ誤り等の検出やその為の対応が必要な場合はアプリケーションで行う。それによってトランスポート層でのそのような処理のオーバーヘッドを削減している。リアルタイム・システムでは遅れているパケットを待つよりもそういうパケットはないものとして処理する方が好ましいため、適時性を重視するアプリケーションでよく使われている^[1]。トランスポート層での誤り訂正機能が必要なら、その用途に設計された Transmission Control Protocol (TCP) または Stream Control Transmission Protocol (SCTP) を使えばよい。

UDPは内部状態を持たない「ステートレス」であり、多数のクライアントからの簡単な問い合わせに応えるサーバなどの用途に有効である。TCPとは異なり、ブロードキャスト（ローカル・ネットワーク上の全ホストへの送信）とマルチキャスト（購読者全員への送信）をサポートしている^[2]。

UDPを使っている主なネットワーク・アプリケーションとしては、途中でデータが抜け落ちても問題が少ない音声や画像のストリーム形式での配信（VoIP、MPEG-TS、Realストリーミング、QuickTimeストリーミング、IP放送など）、小さなデータをリアルタイムで大量に転送するオンラインゲームなどがある。

その他、SNMP、TFTP、DNS、DHCPなどの各種上位プロトコルがある。

IPヘッダにおけるプロトコル番号は17である。

ポート[編集]

UDPアプリケーションはデータグラム・ソケットを使ってホスト間の通信を行う。アプリケーションでソケットとデータ転送のエンドポイントを結びつけるのだが、そのエンドポイントはIPアドレスとサービスポートの組み合わせで表される。ポートとはポート番号で識別されるソフトウェア構造であり、ポート番号は16ビット整数値で0から65,535まである。ポート番号0は予約されているが、送信側プロセスが応答を期待していない場合は使うことも許されている。

Internet Assigned Numbers Authority (IANA) はポート番号を3つの範囲に分割した^[2]。0から1023まではウェルノウンポートであり、よく知られている一般的サービスが使用する。Unix系オペレーティングシステムでは、そのうちの一部の使用にはスーパーユーザーの権限を必要とする。1024から49,151まではレジスタードポートであり、IANAが登録したサービスが使用する。49,152から65,535まではダイナミックポートであり、公式には特定サービスに割り当てられておらず、任意の用途で使用可能である。エフェメラルポートとしても使用でき、ソフトウェアがランダムに選んで使うことができる^[2]。一般に、クライアントが何らかのサーバと通信する際に一時的ポートとして使用する。

パケット構造[編集]

UDPは最小メッセージ指向のトランスポート層プロトコルで、仕様は IETF RFC 768 にある。

上位層プロトコルへのメッセージ配送を全く保証せず、送信済みのUDPメッセージについて何の状態も保持しない。このため、UDPを Unreliable Datagram Protocol（信頼できないデータグラム・プロトコル）と呼ぶこともある^[3]。

UDPは（ポート番号による）アプリケーション多重化と、（チェックサムによる）ヘッダおよびペイロードの完全性検証を提供する^[4]。高信頼転送が必要なら、上位アプリケーションが実装しなければならない。

オフセット（ビット）	0 – 15	16 – 31
0	送信元ポート番号	宛先ポート番号
32	データ長	チェックサム
64+	データ

UDPヘッダには4つのフィールドがあり、それぞれ2バイト（16ビット）である^[1]。そのうち2つ（ピンク色の部分）はIPv4ではオプションである。IPv6では送信元ポート番号だけがオプションである（後述）。

送信元ポート番号: 送信元のポート番号で、相手からの応答が不要の場合はゼロ。それ以外の値の場合、必要なら相手からの応答を受け付けるポート番号を示す。送信元がクライアントの場合、エフェメラルポート番号ということが多い。送信元がサーバの場合、ウェルノウンポート番号ということが多い^[2]。
宛先ポート番号: 宛先のポート番号であり、必須である。送信元ポート番号と同様、宛先がクライアントならエフェメラルポート、サーバならウェルノウンポートということが多い^[2]。
データ長: ヘッダとデータを含むデータグラム全体のバイト数を指定する。ヘッダが8バイトなので、それが最小値となる。理論上の上限は65,535バイト（ヘッダ8バイト + データ65,527バイト）である。下位層がIPv4の場合、実際の上限は65.507バイト（IPヘッダ20バイトとUDPヘッダ8バイトを差し引いた値）となる^[2]。; IPv6のジャンボグラム機能では、65.535バイトを越えるサイズのUDPパケットを扱える^[5]。この場合、IPv6のオプションヘッダでサイズを指定し、最大4,294,967,295バイト（2³² - 1）を指定できるので、ヘッダ部の8バイトを差し引くと最大4,294,967,287バイトのデータを扱える。
チェックサム: ヘッダとデータの誤り検出に使用。送信元がチェックサムを生成しない場合、このフィールドの値はゼロとする^[6]。IPv6ではオプションではないので、ゼロにはできない^[7]。

チェックサムの計算[編集]

チェックサムの計算法は RFC 768 で以下のように定義されている。

IPヘッダからの情報で作られる擬似ヘッダとUDPヘッダとデータを長さが2オクテットの倍数になるように（必要なら）値がゼロのオクテットでパディングし、各2オクテットの1の補数の総和の1の補数の下位16ビットをチェックサムとする^[6]。

つまり、全16ビットワードを1の補数演算で足しあわせる。その合計を1の補数化すればUDPのチェックサム・フィールドの値になる。

チェックサム計算の結果がゼロになる場合（16ビット全部が0）、チェックサムを省略する場合と区別するため、その1の補数（全ビットが1）を設定する。

IPv4とIPv6ではチェックサム計算に使うデータに差異がある。

IPv4 擬似ヘッダ[編集]

IPv4上のUDPでは、実際のIPv4ヘッダからの情報から作った擬似ヘッダをチェックサム計算に使用する。擬似ヘッダは実際のIPv4ヘッダそのものではない。以下にチェックサム計算にのみ使用する擬似ヘッダを示す。

bits	0 – 7	8 – 15	16 – 23
0	送信元IPアドレス
32	あて先IPアドレス
64	ゼロ	プロトコル番号	UDP長
96	送信元ポート番号		宛先ポート番号
128	データ長		チェックサム
160+	データ

送信元IPアドレスとあて先IPアドレスはIPv4ヘッダにある値である。プロトコル番号はUDPを表すので17 (0x11) である。UDP長フィールドはUDPのヘッダとデータの全長である。

UDPチェックサム計算はIPv4ではオプションである。チェックサムを使わない場合はゼロを設定する。

IPv6 擬似ヘッダ[編集]

IPv6上のUDPでは、チェックサムは必須である。チェックサム計算法の違いは RFC 2460 で次のように文書化されている。

トランスポート層かそれより上位のプロトコルで、IPヘッダ内のアドレスをチェックサム計算に使う場合、IPv6では128ビットのIPv6のアドレスを使用する^[7]。

チェックサム計算では、実際のIPv6ヘッダを真似た次のような擬似ヘッダを用いる。

bits	0 – 7	16 – 23	24 – 31
0	送信元IPアドレス
32
64
96
128	あて先IPアドレス
160
192
224
256	UDP長
288	ゼロ		次のヘッダ
320	送信元ポート番号	宛先ポート番号
352	データ長	チェックサム
384+	データ

送信元IPアドレスはIPv6ヘッダにある値を使う。あて先IPアドレスは最終的なあて先であり、IPv6パケットにルーティングヘッダがなければIPv6ヘッダ内のあて先IPアドレスを使い、さもなくば送信側ではルーティングヘッダの最後の要素を、受信側ではIPv6ヘッダのあて先IPアドレスを使う。次のヘッダというフィールドはプロトコル番号を意味し、UDPなので17を指定する。UDP長フィールドはUDPのヘッダとデータを合わせた長さである。

信頼性と輻輳制御の実現[編集]

信頼性を欠いているため、UDPアプリケーションは一般に喪失・誤り・重複を覚悟しなければならない。TFTPなどのアプリケーションでは、アプリケーション層で必要に応じて基本的な信頼性機構を付与している^[2]。

多くの場合、UDPアプリケーションは信頼性機構を持たず、むしろそのオーバーヘッドを嫌っている。ストリーミング、リアルタイムのオンラインゲーム、VoIPといった用途ではUDPを使うことが多く、パケット喪失は大きな問題とはならない。高信頼性が求められる用途では、Transmission Control Protocol などのプロトコルや消失訂正符号（英語版）を代わりに使う。

より深刻なのは、TCPとは異なり、UDPアプリケーションでは輻輳を回避・制御する機構を持たないことがある点である。帯域の大きな部分を消費して輻輳を起こしやすいUDPアプリケーションは、インターネットの安定性を危険にさらす可能性があり、実際に帯域を大幅に占める事態が発生している。制御できないUDPトラフィックによって輻輳崩壊になる可能性を低減するためのネットワーク機構が提案されてきた。現状では、ルーターなどのネットワーク機器でのパケット・キューイングやパケット・ドロッピングが過度なUDPトラフィックをスローダウンさせる唯一の手段となっている。Datagram Congestion Control Protocol (DCCP) はこの問題を部分的に解決すべく設計されたプロトコルで、ストリーミングなどの高転送レートのUDPストリームに対してTCPのような輻輳制御を追加するものである。

用途[編集]

UDPを利用するインターネットの重要なアプリケーションはいくつもある。例えば Domain Name System (DNS) は、1つのクエリに素早く1つの応答パケットを返すだけなのでUDPを使用している。他にも Simple Network Management Protocol (SNMP)、Routing Information Protocol (RIP)^[1]、Dynamic Host Configuration Protocol (DHCP)、Network Time Protocol (NTP) などがある。

音声や動画のトラフィックも一般にUDPを使用している。リアルタイムの動画・音声ストリーミングのプロトコルはパケット喪失が発生しても画質・音質が若干低下するだけで済むよう設計されており、喪失パケットの再送を待って止まってしまう方が不都合である。TCPとUDPは同じネットワーク上で使われており、ストリーミングなどの用途が増えているため、UDPトラフィックの割合も増えている。そのため、POS、会計、データベースなどのTCPを使っているシステムはUDPトラフィックに圧迫されつつある。TCPでパケットを喪失すると、輻輳制御が働いて転送レートを抑えるというのも一因である。リアルタイム・アプリケーションもビジネス・アプリケーションもビジネスには重要なので、Quality of Service のソリューション開発が大切だとする者もいる^[8]。

UDPとTCPの比較[編集]

詳細は「トランスポート層」を参照

TCPはコネクション指向のプロトコルであり、エンドツーエンドの通信を設定するためのハンドシェイクを必要とする。コネクションが設定されると、そのコネクション上で双方向のデータ転送が行われる。

信頼性: TCPではメッセージに対する確認応答があり、再送やタイムアウトを管理している。そして、何とかしてメッセージを確実に届けようとする。パケットが喪失した場合、相手側から再送を要求する。TCPでは全くデータが失われないか、あるいは複数のタイムアウトが発生してコネクションが維持できなくなるかのどちらかである。
順序性: 2つのメッセージが順番に送り出されると、受信側アプリケーションには順番どおりにメッセージが届く。セグメントがばらばらな順番で届いた場合、TCPがそれらを蓄積し、正しい順番に並べ替えてアプリケーションに渡す。
オーバーヘッド: TCPでは、ユーザーのデータを送信する前に必ず3つのパケットをやり取りしてコネクションを確立する必要がある。また、信頼性と輻輳制御のためのオーバーヘッドもある。
ストリーミング: アプリケーションから見ればデータはバイトストリームであり、個々のメッセージ（セグメント）の境界を示す印はない。

UDPはより単純なメッセージベースのコネクションレス・プロトコルである。コネクションレス・プロトコルはエンドツーエンドのコネクション確立を行わない。通信は送信側から受信側へ、特に相手の状態を確認することなく一方的に行われる。UDPがTCPに対して優れているのはリアルタイム性であり、VoIPなどの用途で重視される。

信頼性: メッセージを送ったとき、それが相手に届いたかどうかを確認できず、喪失したらそのままである。チェックサムで誤りを検出したメッセージも廃棄され、廃棄したことはどちらのアプリケーションにも通知されない。確認応答、再送、タイムアウトといった概念がない。
順序性: 2つのメッセージを相手に送ったとき、どちらが先に届くかは予測できない。
オーバーヘッド: メッセージの順序を保証せず、コネクションも保持しないなど、トランスポート層プロトコルとしてはオーバーヘッドが小さい。
データグラム: パケットは個別に送信され、受信されたときだけ完全性をチェックする。メッセージ単位の送受信であり、送信元のアプリケーションが1つのメッセージとして送ったものが、そのまま相手側アプリケーションに1つのメッセージとして届く。
輻輳: UDP自身は輻輳を防げない。広帯域アプリケーションでは輻輳が発生する可能性があり、必要ならば上位層で輻輳制御を実装しなければならない。

脚注・出典[編集]

^ ^a ^b ^c Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 9780131365483.
^ ^a ^b ^c ^d ^e ^f ^g Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
^ content@ipv6.com. “UDP Protocol Overview”. Ipv6.com. 2012年2月27日閲覧。
^ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
^ RFC 2675
^ ^a ^b Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
^ ^a ^b Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
^ “The impact of voice/video on data applications”. Networkperformancedaily.com. 2011年8月17日閲覧。

RFC[編集]

RFC 768 – User Datagram Protocol
RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification
RFC 2675 - IPv6 Jumbograms
RFC 4113 – Management Information Base for the UDP
RFC 4347 - Datagram Transport Layer Security
RFC 5405 – Unicast UDP Usage Guidelines for Application Designers

外部リンク[編集]

The Trouble with UDP Scanning (PDF)
Breakdown of UDP frame
UDP on MSDN Magazine Sockets and WCF
UDP connections

wiki en

[Wiki en表示]

UpToDate Contents

全文を閲覧するには購読必要です。 To read the full text you will need to subscribe.

1. 封入体筋炎の臨床症状および診断 clinical manifestations and diagnosis of inclusion body myositis
2. 薬と肝臓：代謝および肝障害の機序 drugs and the liver metabolism and mechanisms of injury
3. 肝細胞移植 hepatocyte transplantation
4. ガラクトース血症の臨床的特徴および診断 clinical features and diagnosis of galactosemia
5. HIVプロテアーゼ阻害剤 hiv protease inhibitors

English Journal

Role of PelF in Pel Polysaccharide Biosynthesis in Pseudomonas aeruginosa.

Ghafoor A, Jordens Z, Rehm BH.SourceInstitute of Fundamental Sciences.
Applied and environmental microbiology.Appl Environ Microbiol.2013 May;79(9):2968-78. doi: 10.1128/AEM.03666-12. Epub 2013 Feb 22.
Pseudomonas aeruginosa produces three exopolysaccharides, Psl, Pel, and alginate, that play vital roles in biofilm formation. Pel is a glucose-rich, cellulose-like exopolysaccharide. The essential Pel biosynthesis proteins are encoded by seven genes, pelA to pelG. Bioinformatics analysis suggests th
PMID 23435893

Role of endogenous psychosine accumulation in oligodendrocyte differentiation and survival: Implication for Krabbe disease.

Won JS, Kim J, Paintlia MK, Singh I, Singh AK.SourceDepartment of Pathology and Laboratory Medicine, Medical University of South Carolina, Charleston, SC, United States.
Brain research.Brain Res.2013 May 1;1508:44-52. doi: 10.1016/j.brainres.2013.02.024. Epub 2013 Feb 21.
Krabbe disease is a lethal, demyelinating condition caused by genetic deficiency of galactocerebrosidase (GALC) and resultant accumulation of its cytotoxic substrate, psychosine (galactosylsphingosine), primarily in oligodendrocytes (OLs). Psychosine is generated by galactosylation of sphingosine by
PMID 23438514

Genistein protection against acetaminophen-induced liver injury via its potential impact on the activation of UDP-glucuronosyltransferase and antioxidant enzymes.

Fan YJ, Rong Y, Li PF, Dong WL, Zhang DY, Zhang L, Cui MJ.SourceSchool of Biotechnology and Food Engineering, Hefei University of Technology, Hefei 230009, China. Electronic address: swf89105@hfut.edu.cn.
Food and chemical toxicology : an international journal published for the British Industrial Biological Research Association.Food Chem Toxicol.2013 May;55:172-81. doi: 10.1016/j.fct.2013.01.003. Epub 2013 Jan 16.
The purpose of this study was to investigate genistein's influence on the relationship between the activation of uridine diphosphate glucuronosyltransferase (UGTs) and the protection against acetaminophen-induced liver toxicity. Animal experimental results revealed that genistein (50, 100 or 200mg/B
PMID 23333575

Japanese Journal

ACPの分散動的データ構造インタフェース

安島雄一郎 ,野瀬貴史 ,佐賀一繁 ,志田直之 ,住元真司
情報処理学会研究報告. [ハイパフォーマンスコンピューティング] 2014-HPC-146(18), 1-6, 2014-09-25
… ースの仕様を示す.また初期評価として,Tofu インターコネクト版および UDP 版の ACP 基本層上でグローバルメモリアロケータ関数の実行時間を評価する.acp_malloc および acp_free 関数の平均実行時間は割当先 local の場合,Tofu 版で 9 及び 19μ 秒,UDP 版で 16 および 26μ 秒,割当先 remote の場合,Tofu 版で 34 及び 68μ 秒,UDP 版で 2.0 および 7.9 ミリ秒となった.分散動的データ構造インタフェース …
NAID 110009827569

Identification of a protein glycosylation operon from Campylobacter jejuni JCM 2013 and its heterologous expression in Escherichia coli(MICROBIAL PHYSIOLOGY AND BIOTECHNOLOGY)

Srichaisupakit Akkaraphol,Ohashi Takao,Fujiyama Kazuhito
Journal of bioscience and bioengineering 118(3), 256-262, 2014-09
… Transcriptional analysis showed that UDP-diNAcBac synthases and diNAcBac transferase are transcribed but might not function in the constructed system. …
NAID 110009857354

S3-5 Structure/function studies on properties of UDP-sugar producing pyrophosphorylases(Overseas Invited Presentation)

Kleczkowski Leszek A.,Decker Daniel,Meng Meng,Geisler Matt,Wilczynska Malgorzata
応用糖質科学 : 日本応用糖質科学会誌 4(3), B62, 2014-08-20
NAID 110009843670

Related Pictures

★リンクテーブル★

リンク元	「ウリジン二リン酸グルコース」「グリコーゲンシンターゼ」「UDP-グルクロノシルトランスフェラーゼ」「ウリジン二リン酸」
拡張検索	「UDPglucose-hexose-1-phosphate uridylyltransferase」
関連記事	「U」

「ウリジン二リン酸グルコース」

TCP/IP群
アプリケーション層
	BGP / DHCP / DNS / FTP / HTTP / IMAP / IRC / LDAP / MGCP / NNTP / NTP / POP / RIP / RPC / RTP / SIP / SMTP / SNMP / SSH / Telnet / TFTP / TLS/SSL / XMPP カテゴリ
トランスポート層
	TCP / UDP / DCCP / SCTP / RSVP / ECN カテゴリ
ネットワーク層
	IP (IPv4, IPv6) / ICMP / ICMPv6 / IGMP / IPsec カテゴリ
リンク層
	ARP/InARP / NDP / OSPF / トンネリング (L2TP) / PPP / MAC (イーサネット, IEEE 802.11, DSL, ISDN, FDDI) カテゴリ