了解tcp/ip協議的人都知道tcp協議是可靠傳輸的，而udp協議是不可靠傳輸。「可靠傳輸」大家基本上可以達成共識，就是協議確保資料正確到達目標機器；但是「不可靠傳輸」可能就存在爭議了，到底是不保證資料到達？還是不保證資料正確？又或者是兩者都不保證？關於這個問題，我想」不保證資料到達「這點是無容置疑的，至於是否保證資料正確，通過對udp協議的cheksum研究，可以幫助我們得到答案。
udp檢驗和覆蓋udp首部和udp資料，而ip首部的檢驗和只覆蓋ip的首部—並不覆蓋ip資料報中的任何資料。udp和tcp在首部中都有覆蓋它們首部和資料的檢驗和。udp的檢驗和是可選的，而tcp的檢驗和是必需的。儘管udp檢驗和的基本計算方法與ip首部檢驗和計算方法相類似（16 bit字的二進位制反碼和），但是它們之間存在不同的地方。
首先，udp資料報的長度可以為奇數位元組，但是檢驗和演算法是把若干個16 bit字相加。解決方法是必要時在最後增加填充位元組0，這只是為了檢驗和的計算（也就是說，可能增加的填充位元組不被傳送）。
其次，udp資料報和tcp段都包含乙個12位元組長的偽首部，它是為了計算檢驗和而設定的。偽首部包含ip首部一些字段。其目的是讓udp兩次檢查資料是否已經正確到達目的地（例如， ip沒有接受位址不是本主機的資料報，以及ip沒有把應傳給另一高層的資料報傳給udp）。注意，udp資料報的長度在檢驗和計算過程中出現兩次。如果檢驗和的計算結果為0，則存入的值為全1（6 5 5 3 5），這在二進位制反碼計算中是等效的。如果傳送的檢驗和為0，說明傳送端沒有計算檢驗和。
1. 32位源ip位址
2. 32位目的ip位址
3. 0 8位協議(17) 16位udp長度
4. 16位目的埠號
5. 16位udp檢驗和
6. udp首部
7. udp偽首部
8. 16位源埠號
9. 16位udp長度
10.資料
11.填充位元組(0)
如果傳送端沒有計算檢驗和而接收端檢測到檢驗和有差錯，那麼udp資料報就要被悄悄地丟棄，不產生任何差錯報文（當ip層檢測到ip首部檢驗和有差錯時也這樣做）。udp檢驗和是乙個端到端的檢驗和，它由傳送端計算，然後由接收端驗證。其目的是為了發現udp首部和資料在傳送端到接收端之間發生的任何改動。儘管udp檢驗和是可選的，但是它們應該總是在用。在80年代，一些計算機產商在預設條件下關閉udp檢驗和的功能，以提高使用udp協議的nfs（network file system）的速度。在單個區域網中這可能是可以接受的，但是在資料報通過路由器時，通過對鏈路層資料幀進行迴圈冗餘檢驗（如乙太網或令牌環資料幀）可以檢測到大多數的差錯，導致傳輸失敗。不管相信與否，路由器中也存在軟體和硬體差錯，以致於修改資料報中的資料。如果關閉端到端的udp檢驗和功能，那麼這些差錯在udp資料報中就不能被檢測出來。另外，一些資料鏈路層協議（如slip）沒有任何形式的資料鏈路檢驗和。host requirements rfc宣告，udp檢驗和選項在預設條件下是開啟的。它還宣告，如果傳送端已經計算了檢驗和，那麼接收端必須檢驗接收到的檢驗和（如接收到檢驗和不為0）。但是，許多系統沒有遵守這一點，只是在出口檢驗和選項被開啟時才驗證接收到的檢驗和。
分組傳輸與報文傳輸時間計算
如圖所示網路。a在t 0時刻開始向c傳送乙個2mbits的檔案 b在t 0.1 e秒 e為無限趨近於0的小正實數 向d傳送乙個1mbits的檔案。忽略傳播延遲和結點處理延遲。請回答下列問題 1 如果圖中網路採用儲存 方式的報文交換，則a將2mbits的檔案交付給c需要多長時間？b將1mbits的檔案...
BizTalk 2010 EDI 報文傳輸
edi報文可以通過任何協議傳送給我們的 合作夥伴，例如 smtp file ftp http以及其他的許多協議，在這裡就不一一枚舉了。但是，edi標準僅支援van和as2。van可以確保報文是有效的 將報文路由到合適的收件人以及會有交易的記錄，而as2是一種技術，可以讓 合作夥伴允許使用s mime...
J1939 多包報文傳輸
以j1939 rc retarder configration 報文為例，19個位元組，需要分3條報文傳送。1 將要傳送多包報文之前先會廣播一條id為0x18ecff 形式的一條報文tpcm 以目前理解最後 為源位址，rc報文的話為0f 資料場會提示接下來將會傳送多少條報文，包含什麼資訊 rc 2 ...