SCTP协议详解：互联网标准传输协议

SCTP

需积分: 9 139 浏览量更新于2024-07-22 收藏 401KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"Stream Control Transmission Protocol (SCTP) 是一种网络传输协议，设计用于在IP网络上承载公共交换电话网络（PSTN）的信令消息，但其应用范围更广泛。它提供可靠的数据传输服务，包括确认无错、无重复数据传输，根据路径最大传输单元（MTU）大小进行数据分片，以及在多个流中有序交付用户消息等特性。" 正文: Stream Control Transmission Protocol (SCTP) 是一种面向连接的无连接包网络（如IP网络）上的可靠传输协议，由IETF（互联网工程任务组）在RFC4960中定义。此协议旨在取代早期的TCP/IP通信协议，以更好地适应现代网络的需求，尤其是在VoIP和电信领域。SCTP的主要目标是为用户提供类似于TCP的可靠性，同时提供比TCP更灵活和更安全的服务。 SCTP的关键特性之一是多宿主支持，这意味着一个SCTP端点可以有多个IP地址，从而提高了网络的可用性和容错性。当一个接口或网络出现问题时，SCTP可以自动切换到其他可用的路径，确保数据传输的连续性。 SCTP还引入了“关联”(Association)的概念，这是两个SCTP端点之间的逻辑连接，可支持多个独立的双向数据流。每个数据流都有自己的序列号，确保了数据的有序传递。这种多流特性使得SCTP特别适合需要并发处理多个逻辑通道的应用，例如多媒体通信和信令传输。协议的另一个显著特点是其创新的确认机制——部分确认（Partial Acknowledgments）。与TCP的累积确认不同，SCTP允许部分确认，从而减少了延迟，特别是在高带宽低延迟的环境中。此外，SCTP的确认机制也支持快速重传和快速恢复策略，提高了传输效率和性能。 SCTP的数据传输保证了无重复和无错误，通过使用确认和序列号来确保数据的完整性和一致性。它还具备防止中间人攻击的安全特性，如使用校验和保护数据免受篡改，并且支持认证头（AH）和封装安全负载（ESP）选项，可以集成到IPsec框架中，增强数据的安全性。尽管SCTP最初设计用于承载PSTN信令，但其通用性使其在其他领域也得到了广泛应用，如互联网电话（VoIP）、金融交易和分布式系统中的高可靠性通信。与TCP相比，SCTP提供了更强的故障恢复能力，以及更灵活的流量控制和拥塞控制策略。总结来说，SCTP是一种先进的网络传输协议，它结合了TCP的可靠性与UDP的灵活性，同时还提供了额外的多流、多宿主和安全性功能。对于需要高效、安全、灵活传输的应用，SCTP是一个值得考虑的选择。

资源详情

资源推荐

RFC 4960

Stream Control Transmission Protocol September 2007

3.1. SCTP Common Header Field Descriptions

SCTP Common Header Format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port Number | Destination Port Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Verification Tag |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port Number: 16 bits (unsigned integer)

This is the SCTP sender’s port number. It can be used by the

receiver in combination with the source IP address, the SCTP

destination port, and possibly the destination IP address to

identify the association to which this packet belongs. The port

number 0 MUST NOT be used.

Destination Port Number: 16 bits (unsigned integer)

This is the SCTP port number to which this packet is destined.

The receiving host will use this port number to de-multiplex the

SCTP packet to the correct receiving endpoint/application. The

port number 0 MUST NOT be used.

Verification Tag: 32 bits (unsigned integer)

The receiver of this packet uses the Verification Tag to validate

the sender of this SCTP packet. On transmit, the value of this

Verification Tag MUST be set to the value of the Initiate Tag

received from the peer endpoint during the association

initialization, with the following exceptions:

- A packet containing an INIT chunk MUST have a zero Verification

Tag.

- A packet containing a SHUTDOWN COMPLETE chunk with the T bit

set MUST have the Verification Tag copied from the packet with

the SHUTDOWN ACK chunk.

- A packet containing an ABORT chunk may have the verification

tag copied from the packet that caused the ABORT to be sent.

For details see

Section 8.4 and Section 8.5.

Stewart Standards Track [Page 16]

RFC 4960

Stream Control Transmission Protocol September 2007

An INIT chunk MUST be the only chunk in the SCTP packet carrying it.

Checksum: 32 bits (unsigned integer)

This field contains the checksum of this SCTP packet. Its

calculation is discussed in

Section 6.8. SCTP uses the CRC32c

algorithm as described in

Appendix B for calculating the checksum.

3.2. Chunk Field Descriptions

The figure below illustrates the field format for the chunks to be

transmitted in the SCTP packet. Each chunk is formatted with a Chunk

Type field, a chunk-specific Flag field, a Chunk Length field, and a

Value field.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Chunk Type | Chunk Flags | Chunk Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ \

/ Chunk Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Type: 8 bits (unsigned integer)

This field identifies the type of information contained in the

Chunk Value field. It takes a value from 0 to 254. The value of

255 is reserved for future use as an extension field.

The values of Chunk Types are defined as follows:

ID Value Chunk Type

----- ----------

0 - Payload Data (DATA)

1 - Initiation (INIT)

2 - Initiation Acknowledgement (INIT ACK)

3 - Selective Acknowledgement (SACK)

4 - Heartbeat Request (HEARTBEAT)

5 - Heartbeat Acknowledgement (HEARTBEAT ACK)

6 - Abort (ABORT)

7 - Shutdown (SHUTDOWN)

8 - Shutdown Acknowledgement (SHUTDOWN ACK)

9 - Operation Error (ERROR)

10 - State Cookie (COOKIE ECHO)

11 - Cookie Acknowledgement (COOKIE ACK)

Stewart Standards Track [Page 17]

RFC 4960

Stream Control Transmission Protocol September 2007

12 - Reserved for Explicit Congestion Notification Echo

(ECNE)

13 - Reserved for Congestion Window Reduced (CWR)

14 - Shutdown Complete (SHUTDOWN COMPLETE)

15 to 62 - available

63 - reserved for IETF-defined Chunk Extensions

64 to 126 - available

127 - reserved for IETF-defined Chunk Extensions

128 to 190 - available

191 - reserved for IETF-defined Chunk Extensions

192 to 254 - available

255 - reserved for IETF-defined Chunk Extensions

Chunk Types are encoded such that the highest-order 2 bits specify

the action that must be taken if the processing endpoint does not

recognize the Chunk Type.

00 - Stop processing this SCTP packet and discard it, do not

process any further chunks within it.

01 - Stop processing this SCTP packet and discard it, do not

process any further chunks within it, and report the

unrecognized chunk in an ’Unrecognized Chunk Type’.

10 - Skip this chunk and continue processing.

11 - Skip this chunk and continue processing, but report in an

ERROR chunk using the ’Unrecognized Chunk Type’ cause of

error.

Note: The ECNE and CWR chunk types are reserved for future use of

Explicit Congestion Notification (ECN); see

Appendix A.

Chunk Flags: 8 bits

The usage of these bits depends on the Chunk type as given by the

Chunk Type field. Unless otherwise specified, they are set to 0

on transmit and are ignored on receipt.

Chunk Length: 16 bits (unsigned integer)

This value represents the size of the chunk in bytes, including

the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.

Therefore, if the Chunk Value field is zero-length, the Length

field will be set to 4. The Chunk Length field does not count any

chunk padding.

Stewart Standards Track [Page 18]

RFC 4960

Stream Control Transmission Protocol September 2007

Chunks (including Type, Length, and Value fields) are padded out

by the sender with all zero bytes to be a multiple of 4 bytes

long. This padding MUST NOT be more than 3 bytes in total. The

Chunk Length value does not include terminating padding of the

chunk. However, it does include padding of any variable-length

parameter except the last parameter in the chunk. The receiver

MUST ignore the padding.

Note: A robust implementation should accept the chunk whether or

not the final padding has been included in the Chunk Length.

Chunk Value: variable length

The Chunk Value field contains the actual information to be

transferred in the chunk. The usage and format of this field is

dependent on the Chunk Type.

The total length of a chunk (including Type, Length, and Value

fields) MUST be a multiple of 4 bytes. If the length of the chunk is

not a multiple of 4 bytes, the sender MUST pad the chunk with all

zero bytes, and this padding is not included in the Chunk Length

field. The sender MUST NOT pad with more than 3 bytes. The receiver

MUST ignore the padding bytes.

SCTP-defined chunks are described in detail in

Section 3.3. The

guidelines for IETF-defined chunk extensions can be found in

Section

14.1 of this document.

3.2.1. Optional/Variable-Length Parameter Format

Chunk values of SCTP control chunks consist of a chunk-type-specific

header of required fields, followed by zero or more parameters. The

optional and variable-length parameters contained in a chunk are

defined in a Type-Length-Value format as shown below.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Parameter Type | Parameter Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\ \

/ Parameter Value /

\ \

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stewart Standards Track [Page 19]

RFC 4960

Stream Control Transmission Protocol September 2007

Chunk Parameter Type: 16 bits (unsigned integer)

The Type field is a 16-bit identifier of the type of parameter.

It takes a value of 0 to 65534.

The value of 65535 is reserved for IETF-defined extensions.

Values other than those defined in specific SCTP chunk

descriptions are reserved for use by IETF.

Chunk Parameter Length: 16 bits (unsigned integer)

The Parameter Length field contains the size of the parameter in

bytes, including the Parameter Type, Parameter Length, and

Parameter Value fields. Thus, a parameter with a zero-length

Parameter Value field would have a Length field of 4. The

Parameter Length does not include any padding bytes.

Chunk Parameter Value: variable length

The Parameter Value field contains the actual information to be

transferred in the parameter.

The total length of a parameter (including Type, Parameter Length,

and Value fields) MUST be a multiple of 4 bytes. If the length of

the parameter is not a multiple of 4 bytes, the sender pads the

parameter at the end (i.e., after the Parameter Value field) with

all zero bytes. The length of the padding is not included in the

Parameter Length field. A sender MUST NOT pad with more than 3

bytes. The receiver MUST ignore the padding bytes.

The Parameter Types are encoded such that the highest-order 2 bits

specify the action that must be taken if the processing endpoint

does not recognize the Parameter Type.

00 - Stop processing this parameter; do not process any further

parameters within this chunk.

01 - Stop processing this parameter, do not process any further

parameters within this chunk, and report the unrecognized

parameter in an ’Unrecognized Parameter’, as described in

Section 3.2.2.

10 - Skip this parameter and continue processing.

11 - Skip this parameter and continue processing but report the

unrecognized parameter in an ’Unrecognized Parameter’, as

described in

Section 3.2.2.

Stewart Standards Track [Page 20]

剩余151页未读，继续阅读

asbgsh

粉丝: 0
资源: 4

SCTP协议详解：互联网标准传输协议

streamControl

UDP Stream Relaying Control-开源

stream安装包（SteamInstall.msi.）

stream control transmission protocol

传输层常见的协议有哪些

nmap 可以通过那些网络协议进行扫描网络？

新手入门教程SCTP

计算机网络中，物理层、数据链路层、网络层、运输层、应用层每层都有哪些协议

nmap命令搜索出的sctp是什么

sctp abort wireshark

有没有能进行5GXn切换的开源基站

作用是什么libusrsctp?

usrsctp_setsockopt

sctp数据包结构体

webtc一对一通信的流程

sctp+heartbeat

linux sctp setsockopt详解

sctp和tcp的区别

SCTP not supported on this platform

socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:

最新资源