IP,UDP,TCP,SCTP整理总结
1. 协议栈:
应用层 |
DNS, HTTP, FTP, TELNET, SSH, SIP, H.248/MGACO, DIAMETER, MGCP, M3UA,M2UA,M2PA,SUA… |
||
传输层 |
UDP |
TCP |
SCTP |
网络层 |
IP(ARP/RARP) |
||
数据链路层 |
网络设备驱动程序 |
2. IP层特点:无连接,不可靠,无序的;
· 主要负责路由,拆/并IP数据报;数据分发(根据协议和端口号向传输层协议分发);
· 不可靠:IP层收到传输层发来的数据就立即打包发送,不会在缓存中保留备份, 因为IP层不负责重传;本端IP层也不知道所发送的IP数据报是否被对端正确接收;
· IP数据报丢失主要有两种情况:一是传输途中整个数据报丢失;二是数据包被分片了,对端定时器超时后没有收到所有的分片,无法拼出发端的原始数据报,所以只能把已收到的分片也丢弃;但并不会通知发送方数据报已被丢弃;如果上层对可靠性有需求则需要由传输层来保证;
· 无序,是指IP层收到对端发送到IP数据报后就会传给传输层,并不关心对端发送到先后顺序;如果上层有对顺序的要求则需要由传输层来保证;
3. UDP特点:无连接,不可靠,无序的,基于应用层消息的;
· 因为IP层本身是无连接,不可靠,无序的,而UDP也没有做特殊处理,所以UDP仍然是无连接,不可靠,无序的;关于“基于应用层消息”是指应用层调用发送消息的接口(Sendto)发送一块数据时,UDP不对数据做任何处理,只是将其加上UDP头部,然后交给IP层;这样一来如果应用层每次发送的数据块比较大的话就很容易造成IP层分片;
· 此外UDP还具有如下特性:
1) 可以限制本地和远端IP地址;
2) 支持广播和多播;
· 下面是UDP的头部结构:
MAC header |
IP header |
UDP header |
Data ::: |
UDP header:
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
Source Port |
Destination Port |
||||||||||||||||||||||||||||||
Length |
Checksum |
||||||||||||||||||||||||||||||
Data ::: |
4. TCP特点:面向链接,可靠性,有序性;面向字节流;
· 面向链接:是指TCP客户端和服务器之间通信之前首先要建立一个虚拟的链接,这个链接由“源IP地址,源端口号ó目的IP地址,目的端口号”唯一确定;同时TCP层需要为每一个链接维护一个状态机;
· 可靠性:是指TCP为了保证数据正确的传到对端,引入了重传机制;TCP层发送的每一个数据包都有一个唯一的序号,对端收到后需要对收到的数据包进行确认;本端TCP层对发送的每一个TCP数据包都在缓存中保留一个副本,只有在收到对端的确认后才将其删除,否则在定时器超时后仍没收到确认就会重传;
· 有序性:因为TCP发送到每一个数据包都有一个唯一的序号,该序号是结合本次发送端字节数依次增长的,所以对端收到后很容易按照其发送顺序进行排序,然后依次交个应用层;
· 面向字节流:和UDP不同,应用层调用发送消息的接口发送一块数据时,TCP为了不让IP层发生分片,会对用户的数据块分片后分别加上TCP头部然后交给IP层,所以基于TCP的程序很难使IP层发生分片;这样一来用户的数据块就被分割了,到达对端TCP层也不会被合并,就直接交给应用层,所以对端应用层收到的可能是被分割后的数据块,而不是源端最初发送的整个数据块;如果应用层需要对源端发送的整个数据块进行处理则需要应用层自己负责将TCP送上来的分片合并起来。
· 此外UDP还具有如下特性:
3) TCP中引入了拥塞控制;
4) TCP中使用四个定时器;
· 下面是TCP的头部结构:
MAC header |
IP header |
TCP header |
Data ::: |
TCP header:
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
Source Port |
Destination Port |
||||||||||||||||||||||||||||||
Sequence Number |
|||||||||||||||||||||||||||||||
Acknowledgment Number |
|||||||||||||||||||||||||||||||
Data Offset |
Reserved |
ECN |
Control Bits |
Window |
|||||||||||||||||||||||||||
N |
C |
E |
U |
A |
P |
R |
S |
F |
|||||||||||||||||||||||
Checksum |
Urgent Pointer |
||||||||||||||||||||||||||||||
Options and padding ::: |
|||||||||||||||||||||||||||||||
Data ::: |
· Sequence Number:是本次发送数据中第一个字节的序号,下个TCP包中的Sequence Number是本次的Sequence Number加上本次TCP数据包Data中的字节数;
· Acknowledgment Number: 该值只有在Control Bits中的Ack位被置位才有意义,它表示对端希望收到的下一个字节的序号;
· Data Offset:表示TCP中Data部分开始的偏移量,因为TCP头的长度是不固定的;
· Control Bits:U置位表示Urgent Pointer有效,A置位表示带有Acknowledgment Number有效, P置位表示应尽快把该消息发送给应用层, R置位表示重建链接;S置位表示开始发起一个链接;F置位表示停止发送消息;
· Window:用来进行流量控制,该值表示对端希望接受到的字节数;
5. SCTP特点:面向链接,可靠性可配置,有序性可配置,基于应用层消息的,基于多地址(Multi Home Address),基于多个流(Stream),Cookie认证;
· 面向链接:和TCP一样,SCTP客户端和服务器之间通信之前首先要建立一个虚拟的链接,这个链接在SCTP中被称作偶联(Association); SCTP层需要为每一个偶联维护一个状态机;和TCP不同SCTP支持多IP地址,所以一个偶联的两端被称为EndPoint,比如:
assoc = { [10.1.61.111 : 2223], [168.10.8.221, 192.1.1.5 : 80] }
第二个EndPoint中包含两个IP地址,但是端口号必须是一个;
· EndPoint:
1) 一个SCTP的EndPoint是指一个特定主机上的一个端口;
2) 一个SCTP的EndPoint可以对应多个Association;
3) 在任何两个SCTP的EndPoint之间只能存在一个Association;
· 关于“可靠性”和“有序性”在SCTP中都是可以配置的,可配成“可靠的”,“有序的”也可配成“不可靠的”,“无序的”;
· 基于应用层消息:含义和UDP中的含义是相同的;
· 基于多地址:是指建立偶联的时候可以指定对端的多个IP地址(前提是对端确实存在这些IP),这样,如果发向其中一个IP的链路不通,可以继续发往其他IP。
· 基于多个流:是指建立偶联的时候可以指定偶联中允许多少个Stream,每个Stream有一个数字来标识,发送数据的时候可以指定在哪个流上发送;同时还可以指定在该流上的数据是有序的还是无须的;
· Cookie认证:SCTP中引入了Cookie认证机制,有效防止SYN Flood攻击,关于这一特性会在下一篇文章中详述;
· 下面是SCTP的头部结构:
MAC header |
IP header |
SCTP header |
Data ::: |
SCTP header:
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
Source port |
Destination port |
||||||||||||||||||||||||||||||
Verification tag |
|||||||||||||||||||||||||||||||
Checksum |
|||||||||||||||||||||||||||||||
Chunk [1.. n] ::: |
· Verification tag:偶联建立后两个EndPoint各自都会生成一个值作为自己的Verification tag,此后传送的SCTP数据包中,两端发送数据时都包含各自的Verification tag,这个值从偶联建立后就保持不变;
· Chunk [1.. n] ::: SCTP可以携带多个Chunk,比如用户层消息比较小的时候,为了提高传输效率,SCTP会把几个消息分别组装成Data Chunk放在一个SCTP报中发送;
· 下面是Chunk块的结构:
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
Chunk type |
Chunk flags |
Chunk length |
|||||||||||||||||||||||||||||
Chunk data ::: |
· 下面是一些常见的Chunk type:
Chunk type |
Description |
References |
0 |
DATA, Payload Data. |
RFC 2960 |
1 |
INIT, Initiation. |
RFC 2960 |
2 |
INIT ACK, Initiation Acknowledgement. |
RFC 2960 |
3 |
SACK, Selective Acknowledgement. |
RFC 2960 |
4 |
HEARTBEAT, Heartbeat Request. |
RFC 2960 |
5 |
HEARTBEAT ACK, Heartbeat Acknowledgement. |
RFC 2960 |
6 |
ABORT, Abort. |
RFC 2960 |
7 |
SHUTDOWN, Shutdown. |
RFC 2960 |
8 |
SHUTDOWN ACK, Shutdown Acknowledgement. |
RFC 2960 |
9 |
ERROR, Operation Error. |
RFC 2960 |
10 |
COOKIE ECHO, State Cookie. |
RFC 2960 |
11 |
COOKIE ACK, Cookie Acknowledgement. |
RFC 2960 |
12 |
ECNE, Reserved for Explicit Congestion Notification Echo. |
RFC 2960 |
13 |
CWR, Reserved for Congestion Window Reduced. |
RFC 2960 |
14 |
SHUTDOWN COMPLETE, Shutdown Complete. |
RFC 2960 |
15 |
AUTH, Authentication Chunk. |
RFC 4895 |
· 下面是Data Chunk的结构:
00 |
01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
Type = 0 |
Reserved |
U |
B |
E |
Length |
||||||||||||||||||||||||||
TSN |
|||||||||||||||||||||||||||||||
Stream Identifier S |
Stream Sequence Number n |
||||||||||||||||||||||||||||||
Payload Protocol Identifier |
|||||||||||||||||||||||||||||||
User Data (seq n of Stream S) |
· U,B,E: U置位表示这个消息是无序(UnOrder)的,B置位表示这是一个应用层消息的起始部分(Begin),E置位表示这是一个应用层消息的结束部分(End);因为SCTP是“面向应用层消息”的,所以如果应用层消息比较大,为了防止在IP层被分片,通常SCTP会先对比较大的消息进行分片,如果一个应用层消息在SCTP层没分片则B,E都会被置位,如果分片了,则第一个分片B置位,E不置位,中间分片B,E都不置位,最后的分片B不置位,E置位;
· TSN: 每一个Data Chunk中的该值都会依次加1,不管是分片还是完整消息;
· Stream Identifier S:Stream标识号,表示该消息是在哪个Stream中发送;
· Stream Sequence Number n:消息在指定的Stream中的序号,只有当U不置位的时候(表示该Stream中的消息是有序的)才有效,否则被置为0;如果一个消息被分成多个分片放在不同的Data Chunk中,则这些Data Chunk都有相同的Stream Sequence Number;
· Payload Protocol Identifier:表示SCTP 承载的上层协议类型,下表是目前IANA给出的值:
Value |
SCTP Payload Protocol Identifier |
Reference |
0 |
Reserved by SCTP |
[RFC4960] |
1 |
IUA |
[RFC4233] |
2 |
M2UA |
[RFC3331] |
3 |
M3UA |
[RFC4666] |
4 |
SUA |
[RFC3868] |
5 |
M2PA |
[RFC4165] |
6 |
V5UA |
[RFC3807] |
7 |
H.248 |
[H.248] |
8 |
BICC/Q.2150.3 |
[Q.1902.1][Q.2150.3] |
9 |
TALI |
[RFC3094] |
10 |
DUA |
[RFC4129] |
11 |
ASAP |
[RFC5352] |
12 |
ENRP |
[RFC5353] |
13 |
H.323 |
[H.323] |
14 |
Q.IPC/Q.2150.3 |
[Q.2631.1][Q.2150.3] |
15 |
SIMCO <draft-kiesel-midcom-simco-sctp-00.txt> |
[Kiesel] |
16 |
DDP Segment Chunk |
[RFC5043] |
17 |
DDP Stream Session Control |
[RFC5043] |
18 |
S1 Application Protocol (S1AP) |
[TS 23.401][TS 36.413][Koodli] |
19 |
RUA |
[TS 25.467][TS 25.468][Meredith] |
20 |
HNBAP |
[TS 25.467][TS 25.469][Meredith] |
21 |
ForCES-HP |
[RFC5811] 2009-08-04 |
22 |
ForCES-MP |
[RFC5811] 2009-08-04 |
23 |
ForCES-LP |
[RFC5811] 2009-08-04 |
24 |
SBc-AP |
[TS 29.168][Kymalainen] |
25 |
NBAP |
[TS 25.433][Kymalainen] |
26 |
Unassigned |
|
27 |
X2AP |
[TS 36.423][Kymalainen] |
28 |
IRCP - Inter Router Capability Protocol |
[Stewart] |
29 |
LCS-AP |
[TS 29.271][Kymalainen] |
30 |
MPICH2 |
[Tuexen][MPICH2] |