Can you summarize the following document?
        
  由於UDP缺乏可靠性且屬於無連線協議,所以應用程式通常必須容許一些丟失、錯誤或重複的資料包。某些應用程式(如TFTP)可能會根據需要在應用程式層中新增基本的可靠性機制。  一些應用程式不太需要可靠性機制,甚至可能因為引入可靠性機制而降低效能,所以它們使用UDP這種缺乏可靠性的協議。流媒體,實時多人遊戲和IP語音(VoIP)是經常使用UDP的應用程式。 在這些特定應用中,丟包通常不是重大問題。如果應用程式需要高度可靠性,則可以使用諸如TCP之類的協議。  例如,在VoIP中延遲和抖動是主要問題。如果使用TCP,那麼任何資料包丟失或錯誤都將導致抖動,因為TCP在請求及重傳丟失資料時不向應用程式提供後續資料。如果使用UDP,那麼應用程式則需要提供必要的握手,例如實時確認已收到的訊息。  由於UDP缺乏擁塞控制,所以需要基於網路的機制來減少因失控和高速UDP流量負荷而導致的擁塞崩潰效應。換句話說,因為UDP傳送端無法檢測擁塞,所以像使用包佇列和丟棄技術的路由器之類的網路基礎裝置會被用於降低UDP過大流量。資料擁塞控制協議(DCCP)設計成通過在諸如流媒體型別的高速率UDP流中增加主機擁塞控制,來減小這個潛在的問題。

  許多關鍵的網際網路應用程式使用UDP,包括:  串流媒體、線上遊戲流量通常使用UDP傳輸。 實時視訊流和音訊流應用程式旨在處理偶爾丟失、錯誤的資料包,因此只會發生質量輕微下降,而避免了重傳資料包帶來的高延遲。 由於TCP和UDP都在同一網路上執行,因此一些企業發現來自這些實時應用程式的UDP流量影響了使用TCP的應用程式的效能,例如銷售、會計和資料庫系統。 當TCP檢測到資料包丟失時,它將限制其資料速率使用率。由於實時和業務應用程式對企業都很重要,因此一些人認為開發服務質量解決方案至關重要。  某些VPN應用(如OpenVPN)使用UDP並可以在應用程式級別實現可靠連線和錯誤檢查。

  UDP報頭包括4個欄位,每個欄位佔用2個位元組(即16個二進位制位)。在IPv4中,“來源連線埠”和“校驗和”是可選欄位(以粉色背景標出)。在IPv6中,只有來源連線埠是可選欄位。 各16bit的來源埠和目的埠用來標記傳送和接受的應用程序。因為UDP不需要應答,所以來源埠是可選的,如果來源埠不用,那麼置為零。在目的埠後面是長度固定的以位元組為單位的長度域,用來指定UDP資料包包括資料部分的長度,長度最小值為8byte。首部剩下地16bit是用來對首部和資料部分一起做校驗和(Checksum)的,這部分是可選的,但在實際應用中一般都使用這一功能。

  

  當UDP執行在IPv4之上時,為了能夠計算校驗和,需要在UDP資料包前新增一個“偽頭部”。偽頭部包括了IPv4頭部中的一些資訊,但它並不是傳送IP資料包時使用的IP資料包的頭部,而只是一個用來計算校驗和而已。

  當UDP執行於IPV6之上時,校驗和是必須的,其計算方法位於:  IPv6偽頭部是生成校驗和所用的資料。
使用者資料包協議(英語:User Datagram Protocol,縮寫:UDP;又稱使用者資料包協議)是一個簡單的面向資料包的通訊協議,位於OSI模型的傳輸層。該協議由David P. Reed在1980年設計且在RFC 768中被規範。典型網路上的眾多使用UDP協議的關鍵應用在一定程度上是相似的。