請問UPD跟TCP差別在哪?【求助】 - PCZONE 討論區

返回   PCZONE 討論區 > ▲ ADSL_CABLE_FTTH 寬 頻 上 網 討 論 > -- 網 路 技 術 版


PCZONE 討論區



通知

-- 網 路 技 術 版 較深入的網路方面技術問題,請來此這版討論

會員
請問UPD跟TCP差別在哪?【求助】
我找不過不資料也查過不少的書
就是不了解UDP、TCP、ICMP、IGMP的意思
是有不少書有講到TCP/IP這個東西,不過還是看不懂
因為總是沒有簡單點的解釋方法
也不知它什麼層來層去的有何意思
現在我們公司用了ZoneAlarm Pro的防火牆
裡面有
內送、外送IGMP
內送、外送ICMP
內送、外送UDP
內送、外送TCP
我真的不太了解這些跟什麼有關
內送應該是別人傳進來,而外送是我們傳出去是嗎?
而其它的UPD、TCP我就不太懂了
請問有沒有比較簡單的解釋方法,可以讓我了解他們的意思
就像UPD跟TCP差別在哪一樣?

回覆
會員

我記的UDP好像是不需對方回應的連線,就像跟DNS的連線,速度較快,
TCP是需要等待對方回應,連線較穩定,但速度較慢,
一般的連線都是用TCP,
大致上好像是這樣吧,
我也不是很確定,
如果有錯請大家更正吧.
回覆
會員

可否說一下您看到的解釋, 解釋中哪幾句看不懂

不然另外找解釋給您, 擔心您還是看不懂
回覆
會員

引用:
最初由 shauronglu 發表
可否說一下您看到的解釋, 解釋中哪幾句看不懂

不然另外找解釋給您, 擔心您還是看不懂
就像二樓那位仁兄所解釋的那種方式,簡單明了大概意思
還有IGMP、ICMP有點不太了解
主要是因為公司用了ZoneAlarm Pro的防火牆
我要負責管理,但不太了解設定的意思
裡面有
內送、外送IGMP
內送、外送ICMP
內送、外送UDP
內送、外送TCP
不曉得說跟什麼有關,怕亂設定會有不良影響
回覆
WebSphereMania

  想要深入了解 TCP/UDP/ICMP/IGMP 可以去看 RFC 768/793/791/1112。

  http://www.rfc-editor.org
回覆
會員

如果不想看RFC,去書店買一本TCP/IP lllustrated Vol.1 國際中文版 學貫出版...
回覆
進階會員

簡單白話的來說;UDP是非連接導向,就像是郵差寄平信給你,不用等你確認與回覆即可
而TCP則是連接導向,就像是郵差寄掛號給你,必需等你確認才開始給你
回覆
あなたの家に行く

OSI 模型第四層 (傳輸層) 的 TCP/IP 協定分為兩個協定 - TCP 和 UDP。

TCP 提供終端使用者應用程式間的虛擬電路。它的特性包括:

連接導向式
可靠
將外送訊息分段
在目的地工作站重組訊息
重送未收到的資料
將收到的區段重組成訊息。

UDP 在主機間不可靠地傳輸資料。以下是 UDP 的特性:

非連接式
不可靠
傳送訊息 (稱為使用者資料元)
不提供訊息傳輸的軟體檢查 (不可靠)
不重組傳入的訊息
不使用確認
不提供資料流控制

傳輸控制協定 (TCP) 是連接導向的第四層 (傳輸層) 協定,提供可靠的全雙工資料傳輸。TCP 是 TCP/IP 協定堆疊的一部份。
下面列出 TCP 區段中的欄位定義:

來源埠 -- 傳呼埠編號
目的地埠 -- 被傳呼埠的編號
順序號碼 -- 用以確保所收到的資料正確地排序編號
確認號碼 -- 期待的下一個 TCP 位元組資料
HLEN -- 表頭中 32 位元字的數目
保留 -- 設為 0
編碼位元 -- 控制函數 (例如設定與終結一個會談程序)
視窗 -- 送件者願意接受的位元組數目
檢查加總 -- 計算表頭和資料欄位所得的檢查加總
緊急指標 -- 指向緊急資料的結尾
選項 1 選項 -- TCP 區段大小的上限
資料 -- 上層協定的資料

使用者資料元協定 (UDP) 是 TCP/IP 協定堆疊中的非連接式傳輸協定。UDP 是一種沒有確認或保證傳送來交換資料元的簡單傳輸協定。錯誤的處理與重新傳輸都必須由其他協定來解決。
UDP 不使用視窗作業或確認,因此可靠性由應用層協定負責。UDP 適用於區段順序可任意重組的應用。

使用 UDP 的協定包括:

TFTP
SNMP
DHCP
DNS (領域名稱系統)

TCP 和 UDP 都使用埠 (或 socket) 號碼,將資訊傳遞給較上面各層。埠號可以記錄同時在網路上進行的不同交談。應用程式軟體開發者已同意使用,眾所週知在 RFC1700 中定義的埠號。任何要傳送到 FTP 應用程式的交談都使用標準的埠號 21。 至於不使用熟知埠號的應用交談,就指定給特定範圍內隨機選取的埠號。上述埠號在 TCP 區段中用來作為來源與目的地位址。
有些埠號雖在 TCP 與 UDP 中加以保留,但可能沒有撰寫應用程式來支援。埠號指定範圍如下:

255 以下編號 - 供公共應用程式使用。
255 至 1023 - 指定供公司的商業應用程式使用
1023 以上的號碼 - 尚未規定
終端系統使用埠號來選擇適當的應用程式,發送訊息的來源埠號是由來源主機以動態方式指定;通常是大於 1023 的號碼。

連接導向式的傳輸分為三個階段。在連線建立階段,會決定一條來源與目的地之間的路徑。此時資源通常會加以保留,以確保服務等級一致。在資料傳送階段,資料會透過已建立的路徑循序傳輸 - 依照送出時的順序一一到達目的地。不再需要連線時,連線終結階段即切斷來源與目的地的連線。
TCP 主機之間會使用三向式交握法,建立連接導向式的會談。三向式交握法/開放連接順序會在資料抵達終端之前,先將兩終端連線同步化。這種在連接順序時的介紹性順序編號交換非常重要。它可確保由於傳輸問題導致遺失的任何資料,都可以在稍後復原。

首先,由某一台主機啟動一個連線,送出要求連線的封包,並指定起始序號為 "X",同時在表頭中設定一個傳送位元。然後,彼方主機接收到封包,記錄下序號 x,而以 x + 1 的確認來回覆,其中包含它自己的啟始序號 y。確認號碼 x + 1 代表主機已收到已包含 x 的所有位元組,接下來等著要收 x + 1。

肯定確認與重新傳輸 (Positive Acknowledgement and Retransmission, PAR) 是許多通訊協定用來確保可信度時,經常使用的一種技術。有了 PAR,發送端送出一個封包後,會開始計時,待對方確認後,才會再送出下一個封包。若尚未收到確認,而計時器已逾時,則發送端會再傳輸一次該封包,並重新計時。

視窗大小決定在收到目的地確認之前,一次可以傳送的資料量。代表視窗大小的數字越大 (位元組),主機可以傳輸的資料量就越多。當主機傳輸視窗大小數目的位元組資料後,就必須等收到確認以後,才可以再傳下面的訊息。例如,若視窗的大小為 1,則傳完每個 (1) 區段後,都必須經過確認,才可以再傳下一個區段。

TCP 採用預期確認,這表示「確認數等於下一個預期的位元組」。滑動窗的「滑動」部分是指「在 TCP 交談中,可以動態決定窗的大小。」這會造成主機浪費頻寬。

視窗作業是一種資料流控制技巧,它要求發送端設備在傳送一定量的資料以後,必須接收對方確認。例如,若視窗大小為 3,就表示發送端設備可以連續送出三個封包給接收端。然後就必須等待對方確認。如果目的地接收到三個位元組,就會傳送確認到來源設備,來源設備就可以再傳送另外三個位元組。若由於某種原因,接收端沒有收到三個位元組 (例如,可能是因緩衝區溢位),就不送出確認訊息。因為來源沒有收到確認,它就會知道必須重新傳送位元組,並且要降低傳送速率。

TCP 以向前參照確認來提供區段排序作業。每個資料元在傳輸前都會先加以編號,到目的地工作站時,TCP 會將這些區段重新組成完整的訊息。若資料中少了某個順序號碼,就會重傳該區段。區段傳出後,若在一段特定時間內沒有收到確認,也會要求重傳。

ICMP
網際網路控制訊息協定 (Internet Control Message Protocol)。網路層的網際網路協定,負責錯誤報告及提供 IP 封包處理的相關資訊。相關文件見 RFC 792。

IGMP
網際網路群組管理協定 (Internet Group Management Protocol)。IP 主機用以通知相鄰多點廣播路由器所屬的多點廣播群組成員。

multicast router (多點廣播路由器)
用在附著的區域網路上傳送 IGMP 查詢訊息的路由器。多點廣播群組的主機成員會藉由送出 IGMP 來回應此一查詢,以報告它們所隸屬的群組。多點廣播路由器負責從多點廣播群組推送多點廣播資料到群組內的所有成員。



文章有些亂~~~還是你想要英文版的?

回覆
會員
一般: 請問UPD跟TCP差別在哪?【求助】
引用:
最初由 ivyserver 發表
請問有沒有比較簡單的解釋方法,可以讓我了解他們的意思
就像UPD跟TCP差別在哪一樣?
TCP 傳送過程 像 打電話
1 播電話
2 對方 喂
3 聽到 喂, ........
傳送資料過程較可靠

UDP 傳送過程 像 寄信
只把信丟到郵桶
傳送資料過程不可靠
回覆
會員

well, 其實zonealarm真的很不好用呢!!!
怎麼會是公司用的唷?
之前測試過, 我覺得很吵.. 就關掉過了...

回覆







 XML   RSS 2.0   RSS 
本站使用 vBulletin 合法版權程式
站務信箱 : [email protected]

本論壇所有文章僅代表留言者個人意見,並不代表本站之立場,討論區以「即時留言」方式運作,故無法完全監察所有即時留言,若您發現文章可能有異議,請 email :[email protected] 處理。