TCP and UDP
提供許多一般Application Protocol Standards(應用標準)
使用埠號概念來標識發送方和接收方的應用層,well-know port:0-1023
將封包交給正確的行程處理用通訊埠口port(定義在http://www.iana.org/)
支援的應用如下
tcp支援:ftp,telnet,http,smtp,dns,…等
udp支援:tftp,bootp,nfs,rpc,xdr,dns,dhcp,snmp,..等
tcp與udp支援的服務比較
| 服務: | tcp | udp |
| reassembly(將下層封包重組成資料)和fragmentation(將上層資料拆成封包) | * | * |
| 將片段資料從一裝置傳送至另一裝置 | * | * |
| connection(連線導向),建立點對點之連線 | * | |
| 由滑動視窗所提供的flow control(流量控制) | * | |
| 由序號與確認提供之reliable(可靠性) | * | |
| 封包收送有順序 | * |
………………………………………….
TCP(transmission control protocol,傳輸控制協定)
ps:tcp是複雜的,而且會增加不小的網路負擔
TCP特色
Reliable Stream Transport Service
資料流切割並sequencing number(順序編號)傳送,與接收方acknowledgement保證資料完整性
利用forward reference acknowledgment(向前參照確認)的方式提供資料片段之順序
須將資料片段重新排列成完整的訊息
須將網路中毀損,遺失,重複或傳送順序不對的資料復原
流程控制和錯誤處理,用Sliding Window(滑動視窗)控制通訊連線上的資料流量
End-to-End Acknowledgements
確認模式以端到端進行,無需理會封包交換過程所參與的其它設備
為使用者在應用程式間提供的是virtual circuit
全雙工end-to-end(端對端)通訊協定
TCP版本
TCP Tahoe:具備TCP的基本架構
TCP Reno：目前最常見的版本，具Slow Start、AIMD等機制，但因為Congestion Window會Oscillation(波動)且Overreact(過度反應) to Packet Loss，而導致其Jitter較大，並且在估計頻寬上也較沒效率
TCP Vegas：TCP Reno改進版，適當傳輸量上較有效率，其Oscillation也較小
TCP Westwood：由UCLA主導，發展中的Protocol，具有估計最適傳輸量的功能，對Packet Loss較不敏感，適用Wireless環境下
……..
TCP資料結構
可參考RFC-793﹑RFC-1122﹑RFC-813﹑RFC-879﹑RFC-896
封包最大為65535byte
封包由以下兩部份組成
header：基本長度為20byte ,若含option欄位則不定,但一定是4byte的倍數
data:儲存資料的區段,資料長度取決於MSS(maximum segment size,最大區段大小)
ps:
MSS是根據layer2的frame可接受的MTU(maximum transmission unit,最大傳輸單元)所決定
header內含以下:
1-32bit:
Source Port 16bit& Destination Port 16bit
33-64bit:
Sequence Number(序號) 32bit:用於確保扺達資料為正確順序的編號,共有2^32(4billion/40億)組合
65-96bit:
Acknowledge Number(確認編號) 32bit:內含發送序號+資料長度,TCP確認會指出接收端下一個期望收到的序號
97-128bit:
HLEN(表頭長度)4bit:以字組32bit(4byte)為單位,若options欄位為空則長度是20bytes(0x14),double word長度表 5
Reserved(保留)6bit:保留區間,第5個bit可能為cwr,第6個bit可能為ecn-echo,這兩個是用做qos的功能
Contral Flag(控制旗標) 6bit:用來控制會談的建立與終結,子欄位如下:
URG(Urgent data)緊急資料需優先處理,用於中斷訊息
ACK(Acknowledge field significant)為1表此封包Acknowledge Number有效,為0表示可勿略ack
PSH(Push function)接收端須馬上將收到資料給程式處理,不可讓緩衝區滿了才給程式
RST(Reset)連線馬上結束
SYN(Synchronize sequence number)要求建立連線
FIN(No more data fro sender)傳送結束
Window(視窗) 16bit:接收端回應非0表可繼續傳送,0表示接收端暫停收資料(但可傳緊急資料,1byte區段)
129-160bit:
Checksum(總合檢查)16bit:填入送出資料的校驗值,使用crc,會檢查header和data
Urgent Pointer(緊急指標)16bit:指示出緊急資料所在位置,只有當contral flag的URG有設定時此欄位才有效
161-192bit:
Option(選項) 0-32bit倍數:選擇性,長度一定是4byte的倍數,若不是則會自動補0直到符合4byte的倍數
增加表頭沒有的其他功能,同步動作的程式用來指定資料封包大小
window scale視窗規模RFC1323:允許傳送端及接收端彼此協商出視窗的規模係數,window可達30byte
NAK,RFC1106:允許接收端要求某個特定區端,可減少資料重傳數量
refer
windows scale,http://m.oschina.net/blog/297925
TCP運作機制
https://systw.net/note/af/sblog/more.php?id=322
…………………………………………………………………………………………………………………….
UDP(user datagram protocol,使用者資料元協定)
訊息為主,最省力傳送
header比較小
可任意傳送(1to1,1to多,多to1,多to多),支援單播,群播,廣播
即時性較tcp好
封包收送順序不固定
udp封包
可參考RFC-768
大小為6-8byte
欄位如下:
Source Port 16bit & Destination Port 16bit
Message Length(長度)16bit:封包長度，最小為8bit
Checksum(總合檢查) 16bit選擇性欄位,用來檢查封包及資料的校驗值,其值與UDP Pseudo Header(虛擬表頭)一起計算
data(資料):較上層協定之資料