sctp-v1b.xml

檔案傳輸協定(FTP)為目前相當普遍與廣泛使用之網&#63799 應用。然而在傳統檔案傳輸協定之設計下

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" 
href="C:\IBM developerWorks\article-author-package\developerworks\xsl\dw-document-html-4.0.xsl" ?>
<dw-document xsi:noNamespaceSchemaLocation="C:\\IBM developerworks\article-author-package\developerworks\schema\dw-document-4.0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<!-- C:\IBM developerWorks\article-author-package\developerworks\schema\dw-document-4.0.xsd  -->

<dw-article local-site="worldwide" ratings-form="auto" related-contents="auto" toc="auto" skill-level="1">
<id cma-id="" domino-uid="" content-id="" original="yes" />

<keywords content="networking, internet, protocol availability, reliability, SCTP, IP" />
<meta-last-updated day="06" month="04" year="2005" initials="maa" />

<content-area-primary name="linux" />
<title>Stream Control Transmission Protocol</title>
<subtitle>An alternate transport layer protocol</subtitle>

<target-content-file filename="msdemo.zip" file-type="zip" size="3 KB" file-description="Multi-streaming SCTP Demo Source" target-content-type="Code sample" link-method-ftp="yes" url-ftp="ftp://blah/msdemo.zip" link-method-http="yes" url-http="http://blah/msdemo.zip" link-method-dd="yes" url-download-director="http://where-to-go???/msdemo.zip" show-license="yes" registration-required="no" />

<author jobtitle="Senior Principal Software Engineer" company="Emulex" email-cc="[e-mail]" email="[e-mail]">
	<bio>M. Tim Jones is an embedded software engineer and the author of <i>GNU/Linux Application
		Programming, AI Application Programming,</i> and <i>BSD Sockets Programming from a
		Multilanguage Perspective.</i> His engineering background ranges from the development of
		kernels for geosynchronous spacecraft to embedded systems architecure and networking
		protocols development. Tim is a senior principal engineer at Emulex Corp.
	</bio>
	<img src="mtimjones.jpg" width="64" height="80" alt="Author photo" />
	<name>M. Tim Jones</name>
</author>

<date-published day="13" month="04" year="2005" />
<!--<date-updated day="20" month="03" year="2005" />-->


<abstract>The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol that offers services similar to both the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). Like TCP, SCTP provides reliable, ordered delivery of data between two endpoints, but it also preserves message boundaries of data, like UDP. It uses the standard BSD Sockets calls along with a few extensions that simplify sockets programming. But SCTP also offers several advantages over TCP and UDP, such as multi-homing and multi-streaming. This article introduces some of the important features of SCTP in the Linux 2.6 kernel (lksctp) along with server and client source code that demonstrates SCTP's multi-streaming feature.</abstract>

<!--<column-info col-name="series name" col-icon="column_icon.gif" />-->

<docbody>
	<p>SCTP is a reliable general-purpose transport layer protocol for use on IP networks (see Figure 1).
		While the protocol was originally designed for telephony signaling (under the RFC 2960), SCTP also
		solved some of the limitations of TCP while borrowing beneficial features of UDP. It provides features
		for high availability, increased reliability, and improved security for socket initiation.</p>

		<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 1. Layered architecture of the IP stack</heading>
			<img src="images\figure1.gif" width="350" height="183" alt="Layered architecture of the IP stack"/>
		</figure>

	<heading refname="" type="major" toc="yes" alttoc="">The IP stack</heading>
		<p>Let's begin with a quick overview of the IP stack. The Internet protocol suite is split into several
			layers, with each layer providing specific functionality (see Figure 1). Starting from the bottom,
			the <i>link layer</i> provides the physical interface to the communication medium (such as an
			Ethernet device). The <i>network layer</i> manages the movement of packets in a network,
			specifically getting packets to their destination (called <i>routing</i>). The <i>transport layer</i>
			regulates the flow of packets between two hosts for the application layer. It also presents the
			application endpoint for communication, known as a <i>port.</i> Finally, the <i>application layer</i>
			provides meaning to the data transported through the socket. This data could consist of e-mail
			messages using the Simple Mail Transport Protocol (SMTP) or Web pages rendered through the
			Hypertext Transport Protocol (HTTP).</p>

<sidebar>All application layer protocols utilize the sockets layer as their interface to the transport layer
	protocol. The Sockets API was developed at UC Berkeley within the BSD UNIX<reg>庐</reg> operating
	system.
</sidebar>

		<heading refname="" type="minor" toc="no" alttoc="">The transport layer protocols</heading>
			<p>The two most popular transport layer protocols are TCP and UDP. TCP is a reliable protocol that
				guarantees sequenced, ordered delivery of data and manages congestion within a network. UDP
				is a message-oriented protocol that neither guarantees ordering of delivery nor manages congestion.
				But UDP is a fast protocol that preserves the boundaries of the messages it transports.</p>
			<p>SCTP provides reliable ordered delivery of data like TCP but operates in a message-oriented fashion
				like UDP (preserving message boundaries). SCTP also provides several advanced features, such as:</p>
				<ul>
					<li>Multi-homing</li>
					<li>Multi-streaming</li>
					<li>Initiation protection</li>
					<li>Message framing</li>
					<li>Configurable unordered delivery</li>
					<li>Graceful shutdown</li>
				</ul>

	<heading refname="" type="major" toc="yes" alttoc="">Major features of SCTP</heading>
		<p>The two most important feature enhancements in SCTP over traditional transport layer protocols are
			end-host multi-homing and multi-streaming. SCTP also includes several other enhancements that are
			important in their own right, but I begin with multi-homing and multi-streaming.</p>

		<heading refname="" type="minor" toc="no" alttoc="">Multi-homing</heading>
			<p><i>Multi-homing</i> is an important feature in SCTP that provides applications with higher availability
				than those that use TCP. A <i>multi-homed host</i> is one that has more than one network interface
				(and therefore more than one IP address for which it can be addressed). In TCP, a <i>connection</i>
				refers to a channel between two endpoints (in this case, a socket between the interfaces of two hosts).
				SCTP introduces the concept of an <i>association,</i> which exists between two hosts but potentially
				to multiple interfaces at each host.</p>
			<p>Figure 2 illustrates the difference between a TCP connection and an SCTP association. At the top of
				Figure 2 is a TCP connection. Each host includes a single network interface, and a connection is created
				between a single interface on each of the client and server. Upon establishment, the connection is bound
				to each interface. At the bottom of the figure, you can see an architecture that includes two network interfaces
				per host. Two paths are provided through the independent networks, one from interface C0 to S0 and another
				from C1 to S1. In SCTP, these two paths would be collected into an association. SCTP monitors the paths
				of the association using a built-in heartbeat; upon detecting a path failure, the protocol sends traffic over the
				alternate path. It's not even necessary for the applications to know that a failover recovery occurred.</p>

				<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 2. TCP connection vs. an SCTP association</heading>
					<img src="images\figure2.gif" width="481" height="328" alt="TCP connection vs. an SCTP association"/>
				</figure>

<sidebar>Failover can also be used to maintain network application connectivity. For example, consider a laptop that
	includes a wireless 802.11 interface and an Ethernet interface. When the laptop is in its docking station, the
	higher-speed Ethernet interface would be preferred (in SCTP, called the <i>primary address</i>); but upon loss of
	this connection (removal from the docking station), connections would be failed over to the wireless interface. Upon
	return to the docking station, the Ethernet connection would be detected and communication resumed over this
	interface. This is powerful mechanism for high availability and reliability.
</sidebar>

		<heading refname="" type="minor" toc="no" alttoc="">Multi-streaming</heading>
			<p>In some ways, an SCTP association is like a TCP connection except that SCTP supports multiple streams
				within an association. All the streams within an association are independent but related to the association
				(see Figure 3). Each stream is given a stream number, which is encoded inside SCTP packets flowing through
				the association. Multi-streaming is important, because a blocked stream (for example, one awaiting
				retransmission resulting from the loss of a packet) does not affect the other streams in an association. This
				problem is commonly referred to as <i>head-of-line blocking,</i> and TCP is prone to such blocking.</p>

				<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 3. Relationship of an SCTP association to streams.</heading>
					<img src="images\figure3.gif" width="502" height="162" alt="Relationship of an SCTP association to streams."/>
				</figure>

<sidebar>The HTTP protocol shares control and data over the same socket. A Web client requests a file from a server,
	and the server sends the file back over the same connection. A multi-streamed HTTP server would provide better
	interactivity, because multiple requests could be serviced on independent streams within the association. This functionality
	would parallelize the responses and, while not potentially faster, would simultaneously load the HTML and graphics images,
	providing the perception of better responsiveness.
</sidebar>

			<p>Multi-streaming is an important feature of SCTP, especially when you consider some of the control and
				data issues in protocol design. In TCP, control and data typically share the same connection, which can be
				problematic because control packets can be delayed behind data packets. If control and data were split into
				independent streams, control data could be dealt with in a more timely manner resulting in better
				utilization of available resources.</p>

		<heading refname="" type="minor" toc="no" alttoc="">Initiation protection</heading>
			<p>Initiating a new connection in TCP and SCTP occurs with a packet handshake. In TCP, it's a called <i>three-way
				handshake.</i> The client sends a <code type="inline">SYN</code> packet (short for <i>Synchronize</i>), for
				which the server responds with a <code type="inline">SYN-ACK</code> packet (<i>Synchronize-Acknowledge</i>).
				Finally, the client confirms receipt with an <code type="inline">ACK</code> packet (see Figure 4). The problem
				that can occur with TCP is when a rogue client forges an IP packet with a bogus source address, then floods a
				server with TCP <code type="inline">SYN</code> packets. The server allocates resources for the connections
				upon reciept of the <code type="inline">SYN</code>, and under a flood of <code type="inline">SYN</code> packets,
				eventually runs out and is unable to service new requests. This problem is commonly called a <i>Denial of Service</i>
				(DoS) attack.</p>
				
			<p>SCTP protects against this type of attack through a four-way handshake and the introduction of a 
			    cookie.  In SCTP, a client initiates a connection with an <code type="inline">INIT</code> packet. 
			    The server responds with an <code type="inline">INIT-ACK</code>, which includes the cookie (a 
			    unique context identifying this proposed connection). The client then responds with a 
			    <code type="inline">COOKIE-ECHO</code>, which contains the cookie sent by the server. At this 
			    point, the server allocates the resource for the connection, and acknowledges this by sending a 
			    <code type="inline">COOKIE-ACK</code> to the client.</p>
			    
				<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 4. The packet exchanges for the TCP and STCP handshake</heading>
					<img src="images\figure4.gif" width="541" height="258" alt="The packet exchanges for the TCP and SCTP handshake"/>
				</figure>

			<p>To solve the problem of delayed data movement with the four-way handshake, SCTP permits data to be included in
				the <code type="inline">COOKIE-ECHO</code> and <code type="inline">COOKIE-ACK</code> packets.</p>

		<heading refname="" type="minor" toc="no" alttoc="">Message framing</heading>
			<p>With message framing, the boundaries in which messages are communicated through a socket are preserved,
				which means that if a client sends 100 bytes to a server followed by 50 bytes, the server will read 100 bytes
				and 50 bytes, respectively, for two reads. UDP also operates in this way, which makes it advantageous for
				message-oriented protocols. In contrast, TCP operates in a byte-stream fashion. Without framing, a peer may
				receive more or less than was sent (splitting up a write, or aggregating multiple writes into a single read). This
				behavior requires that message-oriented protocols operating over TCP provide data-buffer and message framing
				within their application layer (a potentially complex task).</p>
			<p>SCTP provides for message framing in data transfer. When a peer performs a write on a socket, it is guaranteed
				that this same-sized chunk of data will be read at the peer endpoint (see Figure 5). For stream-oriented data, such
				as audio or video data, lack of framing is acceptable</p>

				<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 5. Message framing in UDP/SCTP vs. a byte stream-oriented protocol</heading>
					<img src="images\figure5.gif" width="430" height="193" alt="Message framing in UDP/SCTP vs. a byte stream -oriented protocol"/>
				</figure>

		<heading refname="" type="minor" toc="no" alttoc="">Configurable unordered delivery</heading>
			<p>Messages in SCTP are transferred reliably but not necessarily in the desired order. TCP guarantees that data
				is delivered in order (which is a good thing, considering TCP is a stream protocol). UDP guarantees no ordering.
				You can also configure streams within SCTP to accept unordered messages, if desired.</p>
			<p>This feature can be useful in message-oriented protocols, where requests are independent and ordering is
				not important. Further, you can configure unordered delivery on a stream-by-stream basis within an association.</p>

		<heading refname="" type="minor" toc="no" alttoc="">Graceful shutdown</heading>
			<p>TCP and SCTP are connection-based protocols, whereas UDP is a connection-less protocol. Both TCP and
				SCTP require connection setup and teardown between peers. What you'll find different for socket shutdown
				in SCTP is the removal of TCP's <i>half-close</i>.</p>
			<p>In Figure 6, you see the shutdown sequences for TCP and SCTP. In TCP, it's possible for a peer to close its
				end of a socket (resulting in a <code type="inline">FIN</code> packet being sent) but then continue to receive
				data. The <code type="inline">FIN</code> indicates that no more data is to be sent by this endpoint, but until the
				peer closes its end of the socket, it may continue to transmit data. Applications rarely use this half-closed state,
				and therefore the SCTP designers opted to remove it and replace it with a cleaner termination sequence. When
				a peer closes its socket (resulting in the issuance of a <code type="inline">SHUTDOWN</code> primitive), both
				endpoints are required to close, and no further data movement is permitted in either direction.</p>

				<figure><heading refname="" type="figure" toc="no" name="" alttoc="">Figure 6. TCP and SCTP connection termination sequences</heading>
					<img src="images\figure6.gif" width="532" height="258" alt="TCP and SCTP connection termination sequences"/>
				</figure>

	<heading refname="" type="major" toc="yes" alttoc="">Multi-streaming demonstration</heading>