UDP از حروف اول کلمات User Datagram Protocol گرفته شده و یک پروتکل غیر اتصال گرا (Connectionless) است که مثل TCP در بالاترین لایه اجرا می شود. برخلاف TCP در پروتکل UDP امکان بروز خطا وجود دارد.

یک ارتباط غیراتصال گرا بین دو هاست برقرار می کنه و هر بسته از داده کاربر و کمترین میزان سرایند تشکیل شده که به آن UDP دیتاگرام گفته می شود.

UDP غیراتصال گرا است .یعنی یک دیتاگرام در هر لحظه ای میتونه ارسال بشه ، بدون نیاز به هر گونه اعلام قبلی، مذاکره و یا هیچ آماده سازی از قبل.فقط داده رو ارسال می کنه و امیدواره که گیرنده داده ها رو دریافت کنه.

یک ارتباط غیرقابل اعتماد ایجاد می کنه . یعنی هیچ تضمینی برای اطمینان از تحویل داده ها در مقصد وجود ندارد. نه تنها هیچ اطمینانی از رسیدن داده ها به مقصد وجود نداره بلکه حتی به صحت و درستی داده هائی که به مقصد رسیده هم نمیشه اطمینان داشت. ممکنه بسته ای رو  دو بار دریافت کنیم!! برنامه ما که بر اساس این پروتکل کار میکنه باید آمادگی مواجه شدن با تمام این موقعیت ها رو داشته باشه: از دست دادن دیتاگرام ، دیتاگرام تکراری و یا دریافت دیتاگرام با ترتیب غلط.

مهمترین محاسن UDP اینه که محدوده داده ها در ائن مشخص شده ، در ارسال های broadcast میشه از این پروتکل استفاده کرد و همچنین سریعه.

و مهمترین معایب غیرقابل اعتماد بودن آن و در نتیجه پیچیده بودن برنامه نویسی در سطح لایه application است.

 

ين پروتکل برای کاهش overflow طراحی شده و در خيلی از موارد وابسته به TCP هستش .

نکته مهم اينه که وقتی با يه پورت خاص روی يک کامپيوتر ديگه ارتباط برقرار می‌ کنيم ، اين ارتباط می‌تونه از نوع TCP يا UDP باشه . بنابراين وقتی می‌ خوايم يه کامپيوتر خاصی رو از نظر پورت‌ ها بررسی کنيم ، هر دو بايد بررسی بشه .

 

 

و اما قالب بسته UDP :

 


 

همین طور که در شکل می بینید :

·               Source Port : یک فیلد اختیاری برای شماره پورت فرستنده. اگر شماره پورت مشخص نشه در این فیلد 0 قرار میگیره.

·               Destination Port : شماره پورت مقصد

·               Length : طول دیتاگرام، شامل Header و داده اصلی

·               Checksum: کد کشف خطا. این فیلد در Header بسته UDP اختیاریست.

 

 آدرس دهی

TCP و UDP از یک مدل آدرس دهی استفاده می کنند : یک آدرس IP و شماره پورت مورد نظر.

آدرس IP برای هدایت بسته به هاست منظور در شبکه ی مشخص شده و شماره پورت برای هدایت به پروسه منتظر. معمولا یک پورت برای یک برنامه اختصاص داره.

 

محاسن TCP

·         سیستم عامل همه کار رو برای شماانجام میده. دیگه باگهای ابتدائی که هر کس در اولین کارش با اون ها روبرو میشه رو مرتکب نمیشید. برای اینکه تمام این ها برای ما توسط سیستم  عامل انجام و رفع شده.

·         کارهائی که سیستم عامل برای دریافت و ارسال بسته های TCP انجام میده نیازی به سوئیچ لز مود کرنل به مود کاربر نداره. چون اغلب کارها مثل اسمبل کردن مجدد بسته های رسیده، پاسخ مبنی بر دریافت بسته ها (ACK) ، گزارش خطاها،و... توسط کرنل انجام می شود.

·         TCP سه چیز رو برای شما گارانتی میکنه : داده های ما به مقصدبرسه ، داده ها با ترتیب صحیحی برسه ، داده ها بدون تکرار در مقصد دریافت شود.

·         مسیریاب ها در مواجهه با بسته هایTCP رفتارهای خاص متناسبب رو انجام میدن . مثلا در صورت لزوم می تونند تقاضای ارسال مجدد بسته کنند.

 محاسن UDP

·         محدود و ملزم به رعایت از مدل ارتباطی connection oriented نیستیم.

·         کنترل خطاها، پاسخ به فرستنده (ACK) و... به برنامه بستگی داره و ما به عنوان برنامه نویس ویژگیهائی را که نیاز داریم پیاده سازی و استفاده می کنیم.

·         انتقال های broadcast و multicast در UDP امکان پذیره.

 معایبTCP

·         اگر سیستم عامل باگ داشته باشه، ما نمیتونیم از دست این باگ راحت بشیم.ممکنه برای چیزی که ما می خواهیم موثر نباشه و کارا نباشه ولی ما مجبوریم که از همون استفاده کنیم.

·         TCP ویژگیهای فوق العاده ای رو برای شما فراهم می کنه که شاید خیلی از اونها رو نیاز نداشته باشید. در نتیجه برای کار شما، پهنای باند و یا زمان رو هدر میده و بیخود صرف می کنه.

·         در TCP داده ها هیچ محدوده ای مشخص نشده و ما باید خودمان محدوده داده را مشخص کنیم.

·         TCP برای انتقال های broadcast و یا multicast نمیتونه مورد استفاده قرار بگیره.

 معایب UDP

·         با وجود UDP هیچ گارانتی وجود نداره. ممکنه بسته ای تحویل مقصد داده شه ، یا دو بار داده بشه و یا اینکه به ترتیب تحویل داده نشه. و با بروز هریک از این خطاها ما متوجه نمیشویم، مگر اینکه برنامه ای که به داده ها گوش می دهد، در صورت بروز هر یک از خطا ها بخواهد کاری انجام دهد.

·         UDP برای خطاهای احتمالی هیچ گونه مکانیزمی ندارد و پیاده سازی کشف و رفع خطاها به عهده برنامه نویس است.

RFC 768                                                        J. Postel
                                                                     ISI
                                                          28 August 1980
 
 
 
                         User Datagram Protocol
                         ----------------------
 
Introduction
------------
 
This User Datagram  Protocol  (UDP)  is  defined  to  make  available  a
datagram   mode  of  packet-switched   computer   communication  in  the
environment  of  an  interconnected  set  of  computer  networks.   This
protocol  assumes  that the Internet  Protocol  (IP)  [1] is used as the
underlying protocol.
 
This protocol  provides  a procedure  for application  programs  to send
messages  to other programs  with a minimum  of protocol mechanism.  The
protocol  is transaction oriented, and delivery and duplicate protection
are not guaranteed.  Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP) [2].
 
Format
------
 
                                    
                  0      7 8     15 16    23 24    31  
                 +--------+--------+--------+--------+ 
                 |     Source      |   Destination   | 
                 |      Port       |      Port       | 
                 +--------+--------+--------+--------+ 
                 |                 |                 | 
                 |     Length      |    Checksum     | 
                 +--------+--------+--------+--------+ 
                 |                                     
                 |          data octets ...            
                 +---------------- ...                 
 
                      User Datagram Header Format
 
Fields
------
 
Source Port is an optional field, when meaningful, it indicates the port
of the sending  process,  and may be assumed  to be the port  to which a
reply should  be addressed  in the absence of any other information.  If
not used, a value of zero is inserted.
 
 
 
 
 
Postel                                                          [page 1]
 
 
                                                             28 Aug 1980
User Datagram Protocol                                           RFC 768
Fields
 
 
 
Destination  Port has a meaning  within  the  context  of  a  particular
internet destination address.
 
Length  is the length  in octets  of this user datagram  including  this
header  and the data.   (This  means  the minimum value of the length is
eight.)
 
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data,  padded  with zero octets  at the end (if  necessary)  to  make  a
multiple of two octets.
 
The pseudo  header  conceptually prefixed to the UDP header contains the
source  address,  the destination  address,  the protocol,  and the  UDP
length.   This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.
 
                  0      7 8     15 16    23 24    31 
                 +--------+--------+--------+--------+
                 |          source address           |
                 +--------+--------+--------+--------+
                 |        destination address        |
                 +--------+--------+--------+--------+
                 |  zero  |protocol|   UDP length    |
                 +--------+--------+--------+--------+
 
If the computed  checksum  is zero,  it is transmitted  as all ones (the
equivalent  in one's complement  arithmetic).   An all zero  transmitted
checksum  value means that the transmitter  generated  no checksum  (for
debugging or for higher level protocols that don't care).
 
User Interface
--------------
 
A user interface should allow
 
  the creation of new receive ports,
 
  receive  operations  on the receive  ports that return the data octets
  and an indication of source port and source address,
 
  and an operation  that allows  a datagram  to be sent,  specifying the
  data, source and destination ports and addresses to be sent.
 
 
 
 
 
 
[page 2]                                                          Postel
 
 
28 Aug 1980
RFC 768                                           User Datagram Protocol
                                                            IP Interface
 
 
 
IP Interface
-------------
 
The UDP module  must be able to determine  the  source  and  destination
internet addresses and the protocol field from the internet header.  One
possible  UDP/IP  interface  would return  the whole  internet  datagram
including all of the internet header in response to a receive operation.
Such an interface  would  also allow  the UDP to pass  a  full  internet
datagram  complete  with header  to the IP to send.  The IP would verify
certain fields for consistency and compute the internet header checksum.
 
Protocol Application
--------------------
 
The major uses of this protocol is the Internet Name Server [3], and the
Trivial File Transfer [4].
 
Protocol Number
---------------
 
This is protocol  17 (21 octal)  when used  in  the  Internet  Protocol.
Other protocol numbers are listed in [5].
 
References
----------
 
[1]     Postel,   J.,   "Internet  Protocol,"  RFC 760,  USC/Information
        Sciences Institute, January 1980.
 
[2]     Postel,    J.,   "Transmission   Control   Protocol,"   RFC 761,
        USC/Information Sciences Institute, January 1980.
 
[3]     Postel,  J.,  "Internet  Name Server,"  USC/Information Sciences
        Institute, IEN 116, August 1979.
 
[4]     Sollins,  K.,  "The TFTP Protocol,"  Massachusetts  Institute of
        Technology, IEN 133, January 1980.
 
[5]     Postel,   J.,   "Assigned   Numbers,"  USC/Information  Sciences
        Institute, RFC 762, January 1980.
 
 
 
 
 
 
 
 
 
Postel                                                          [page 3]