SCTP 通訊協定簡介

Aaron Liao (aaron@netdpi.net)

SCTP不僅在設計層面能夠改善傳統 TCP 連線安全的弱點，SCTP 之多重串流特性能夠改善 HoL Blocking 問題，並且路徑多宿之特性更是能夠增強資料傳輸之可靠度。

IETF組織於2000年十月制定了SCTP（Stream Control Transmission Protocol）通訊協定，SCTP透過四向交握（four-way handshake）的方式（圖1）建立一個初始連線（association），並經由Cookie機制作為端點之間的認證，如此的設計可避免傳統TCP三向交握（圖2）過程中易遭受服務阻斷攻擊之弱點。在連線中斷方面，TCP採用四向交握方式結束連線（圖2），當TCP連線之一方已經關閉了並且無法繼續傳送新的資料，而另一方仍保持開啟狀態並可以繼續傳送資料，即所謂之半關閉狀態（half-closed state）；而SCTP是以三向交握的方式結束連線（圖1），不提供半關閉狀態，接收端在接收由傳送端送出SHUTDOWN訊息的chunk之後，會回傳一個SHOUTDOWN-ACK封包進行回覆，等待結束連線的傳送端確認完成後便結束連線，同時傳送SHUTDOWN-COMPLETE的訊息至接收端。在一個SCTP封包中能夠包含不同的資料區塊（data chunk）與控制區塊（control chunk），而SCTP通訊協定以heartbeat封包對路徑進行偵測與回復。

圖1、SCTP association之建立與終止流程

圖2、TCP session之建立與終止流程

1 多重串流 (Multi-streaming)

SCTP 通訊協定之多重串流特性有別於傳統的 TCP 通訊協定單一串流（single-stream），當端點建立連線時，可預先相互協調將要使用的串流數量，並且能夠將不同類型的資料分別以不同的串流傳輸，當其中一個串流正在等待重新傳送的訊息時，其他串流仍然能夠繼續傳送，在每個串流中的 data chunk 都會有各自運作的的串流序號（SSN, stream sequence number），因此在某一個串流的封包重送動作並不會使其他串流因等待重送的封包而造成延遲。如應用於網頁伺服器時，不需為了同時傳輸多個檔案而建立多個連線，網頁與圖片能夠透過不同的串流傳輸，不需等待網頁傳輸完畢，圖片就能透過其他串流同時傳輸。多重串流之功能可以改善原本因單一串流時，必須等待遺失封包之重送而產生的 HoL Blocking 延遲，圖3是一個 SCTP 多重串流的示意圖，SCTP 兩端點透過一條 SCTP 連線（association）進行通訊，在接收與傳送的部份，可使用多個串流進行資料的傳送與接收。

圖3、SCTP多重串流示意圖

在 Meixner [8] 與Grinnem [6] 等學者的研究中，他們已經探討了 SCTP 通訊協定之多重串流功能對於 HoL Blocking 延遲之改善，Meixner 等人以 FreeBSD 作業系統進行實驗分析 TCP 與 SCTP 通訊協定之效能，觀察 SCTP 通訊協定的幾項特性。首先作者比較了串流數目與發生封包遺失時所產生的延遲時間之關係，經過觀察多重串流之實驗結果得知，透過多重串流傳輸與單一串流傳輸資料時，當發生了封包遺失的情況時，使用多重串流傳輸所產生的延遲時間會比僅使用單一串流傳輸要來的少，因此可以瞭解到配置較多的串流數目確實能夠有效改善因 HoL Blocking 所產生的延遲時間。而在 Natarajan [12] 等學者的研究中，他們將 SCTP 多重串流的功能應用於傳統之檔案傳輸協定（FTP, file transfer protocol）中，經由實驗的結果得知，使用多重串流也能夠提昇傳輸效能。

2 路徑多宿 (Multi-homing)

SCTP通訊協定路徑多宿之特性允許端點與端點間的連線可透過多個網路裝置達到路徑備援的能力，當具備多路徑時，SCTP會選擇某一路徑做為資料傳輸的主要路徑（primary path），而其它的路徑則作為備援路徑（backup path），備援路徑的用途是當主要路徑發生故障或斷線時，SCTP會利用heartbeat週期性偵測各線路是否存活，因此當主要路徑發生中斷時，SCTP之端點可自動由多個備援路徑中選取其中一路做為主要路徑之替代，進而達到快速恢復（failover）的能力。

以圖4為例，host A與host B設備均具備了兩張網路介面卡，每張介面卡都能夠經由網路服務供應商（ISP）之路由器或閘道器(gateway)連結至網際網路，因此host A或host B都能夠透過各自擁有的任何一張網路介面卡傳送資料。該圖例呈現host A使用A1網路介面作為主要路徑與host B進行網路語音電話之通話，而對於host A而言，A2網路介面僅是備援路徑。當主要路徑（primary path）發生問題時，SCTP則會自動從主要路徑切換至備援路徑（backup path），避免host A與host B的通話因單一線路之故障而被迫通話中斷，增加了連線通訊的可靠度。

圖4、SCTP路徑多宿示意圖

3 SACK 機制

SCTP通訊協定預設採用選擇回覆（SACK, selective acknowledgement）之回報機制，SACK之功能主要協助接收端以確認封包資料之接收或通知傳送端之封包資料傳輸產生的區段（gaps）, 接收端將尚未接收到的TSN值記錄於SACK chunk並回送至傳送端，以通知傳送端進行新資料之傳輸或已傳送資料之重傳的動作，圖5為SCTP通訊協定之SACK chunk。

圖5、SCTP SACK Chunk格式

下列是SACK chunk中各參數的定義：

(a) Chunk Flags: 8 bits

當傳送時，全部的bits都設定為零，接收時，忽略這個欄位。

(b) Cumulative TSN ACK: 32 bits (unsigned integer)

此參數是最後一個收到的依序data chunk的TSN值。

(c) Advertised receiver window credit: 32 bits (unsigned integer)

告知傳送端更新接收端的緩衝區空間（單位：bytes）。

(d) Number of Gap ACK block: 16 bits (unsigned integer)

說明此SACK中有幾個Gap ACK blocks。

(e) Number of Duplicate TSNs: 16 bits

收到的重複TSN數目。

(f) Gap ACK block start: 16 bits (unsigned integer)

說明此Gap ACK block開始的TSN offset。

(g) Gap ACK block end: 16 bits (unsigned integer)

說明此Gap ACK block結束的TSN offset。

圖6、SACK範例

圖6是一個SCTP通訊協定的SACK chunk範例，根據SACK chunk的欄位格式，可以得知最後所收到的data chunk TSN序號值為29，而number of block=2是代表區塊（block）之數目為2，如圖中之著色區塊數目。在區塊一的offset範圍是3 ~ 4，如圖中之著色區塊TSN = 32 ~ 33，TSN start offset為3 （29 + 3 = 32）即代表 TSN = 32 為該區塊的起始位置，而TSN end offset是4（29 + 4 = 33）即代表 TSN = 33 為該區塊之結束位置。同理，位於SACK chunk第五列之區塊二，TSN start offset與TSN end offset均相同為6，代表該區塊之範圍起始與結束位置均於TSN=35（29 + 6 = 35）。透過這樣的方式，傳送端可以從SACK回覆訊息中計算出需要重送的data chunk之TSN序號值。

4 Path MTU Discovery

PMTU探索（Path MTU discovery）[9, 10] 能夠讓傳輸層得知路徑之MTU限制，因而可以確保傳輸層之segment 在經過IP層時不需要分割。在IPv4網路環境中，endpoint將IP表頭之Don’t fragment 欄位標示，當路由器接收到IP表頭標示 Don’t fragment時，將不能夠對該封包進行分割，因此，當該封包的長度超過路由器下一步 (next hop) 路徑之MTU時，路由器將會回傳ICMP訊息告知該封包的傳送端，多數的路由器會在ICMP訊息中存放可傳送的IP資料長度告知傳送端，當傳送端接收到路由器的ICMP訊息時，就會再次發送一個適當長度的封包，endpoint透過週期性的不斷探測，直到封包到達接收端為止，透過這樣的方式達成path MTU的探索。而在IPv6網路環境中，由於IPv6表頭並沒有don’t fragment欄位，路由器並不負責IP層的分割工作，而是由endpoint處理。

SCTP通訊協定在使用PMTU探索與TCP通訊協定之不同點在於，SCTP具備路徑多宿的特性，因此SCTP透過PMTU之探索，在每個路徑都會得到一個PMTU，SCTP 的方式是採用所有路徑之PMTU中最小的PMTU，稱之為sPMTU。以圖7所示，Endpoint Joe進行PMTU探索後將會發現路徑 Joe-A-C-Mary 之 PMTU 值為 512 bytes，而Joe-B-D-Mary之PMTU值為1024 bytes，因此，SCTP 通訊協定會選擇最小的512 bytes作為 sPMTU 之值。當應用層要傳送4096 bytes的資料時，則會先由SCTP進行分割的動作，將資料分割為512 bytes，若是SCTP傳輸之主要路徑已經分換為Joe-B-D-Mary時，由於該路徑之PMTU為1500 bytes，因此SCTP會將已經分割過的data chunk再集合為適當大小之長度，以達到最佳效能。

圖7、The Path MTU discovery

他們的實驗比較IP分割與SCTP協定分割在封包遺失率的環境中之傳輸率（throughput）；結果以SCTP協定分割傳輸的傳輸率皆比IP分割高，原因在於當傳輸層的segment在IP層被分割成數個小碎片（fragmentations）之後，只要其中的任何一個小碎片遺失，都會導致傳輸層的整個segment需要重新傳送。

5 Ordered/Unordered 傳送機制

SCTP通訊協定支援ordered與unordered傳輸機制，除了在同一個串流（stream）中有限制必須要嚴格遵守ordered傳遞的規則外，SCTP能夠透過將data chunk中的U旗標設定為1以Unordered模式傳輸資料。因此，當SCTP端點接收到U旗標為1的data chunk時，會跳過（bypass）依序機制 （Ordering mechanism），同時也立刻將資料傳送至上層，除非是分割過的片段（fragment）資料才需要先將資料重組完成後傳送至上層。當data chunk中的U旗標設定為1時，也就使用Unordered機制傳送資料時，傳送端並不會增加串流序號（SSN, stream sequence number）的計算，因此傳送時，在data chunk的串流欄位中並不會被指定串流序號，而接收端在收到U旗標設定為1之data chunk時，則不需要使用該data chunk的串流序號，而且需要將串流序號欄位的內容忽略。

在Grinnem [8] 等人的研究中，他們比較SCTP通訊協定分別以非依序（unordered）傳輸與依序（ordered）傳輸模式傳輸時，觀察平均傳輸延遲的變化，根據他們實驗所得結果，非依序傳輸會比依序傳輸減少0 % 到18 % 的平均傳輸延遲時間，因此，可以表示SCTP通訊協定之非依序傳輸功能的確有助於降低HoL Blocking產生的延遲。

6. SCTP API

目前於Linux平台SCTP API [14] 之實作有LKSCTP （Linux kernel SCTP）[16] 與SCTPLIB [17]，如圖8的LKSCTP的堆疊架構所示，LKSCTP將SCTP協定實作於作業系統之kernel space，應用層之網路程式使用socket API或ULP（upper layer protocol）以使用SCTP協定進行傳輸，lksctp運作於Linux作業系統之kernel space。

圖8、LKSCTP之堆疊架構圖

SCTPLIB（圖9）在作業系統中是屬於user space的設計，利用raw socket的方式於user space運作SCTP協定，以服務應用層網路程式。SCTPLIB為了能夠達到於系統內部服務多個應用層網路程式，透過UDP協定 [20] 與SCTP daemon協同運作，SCTP daemon是負責同步排程工作以及與底層溝通的任務。以作業系統層面比較LKSCTP與SCTPLIB之SCTP API實作，由於SCTPLIB位於user space，因此在kernel space與user space間需要額外付出資料複製的成本，因此預期LKSCTP效能會較SCTPLIB佳。

圖9、SCTPLIB之堆疊架構圖

在Siddiqui等人的研究中 [13]，他們進行兩個實驗比較SCTP協定實作在kernel space與user space之效能，在第一個實驗中，他們比較了SCTP協定切換路徑所需耗費的時間延遲，經由實驗結果得到，LKSCTP所耗費之時間延遲遠小於SCTPLIB，作者認為這是因為SCTPLIB需要時間與SCTP Daemon協調，因此在傳送與處理ASCONF [15] 訊息時會增加額外的負擔；在第二個實驗中，他們分別於LKSCTP與SCTPLIB之SCTP API環境中，以檔案傳輸程式（FTP）傳輸不同資料尺寸之檔案，經由結果得知LKSCTP之運作效能均較SCTPLIB優異。

Nurul Islam [7] 等人使用SCTPLIB之SCTP API，實驗主要的目的在分析傳輸不同的data chunk大小對傳輸效能所造成的影響，因此他們設計了兩個實驗場景，分別是設定無封包遺失與5 % 封包遺失的實驗場景，實驗一是在無封包遺失的場景中進行，先後傳輸288 bytes與488 bytes的資料，兩次傳輸由於是各自獨立進行，因此不會互相競爭，透過實驗結果分析可以得到傳輸488 bytes的平均傳輸率比288 bytes高，也就是傳輸較大的data chunk可以獲得較高的傳輸效能。實驗二是在 5% 封包遺失率的場景進行，同樣是分別傳輸288 bytes與488 bytes的資料，結果與之前的實驗相似，傳輸較大的data chunk平均能夠獲得較高的傳輸率。他們認為這樣的結果是因為在SCTP中使用Appropriate Byte Counting [4]、Limited Transmit [2] 與SACK等機制。由於SCTP是計算已接收的SACK回應bytes數來增加壅塞視窗的大小，因此，即使SCTP使用SACK延遲也不會減緩壅塞視窗的成長。

7. TCP 與 SCTP 通訊協定比較

TCP通訊協定於初始連線時，透過三向交握的方式進行初始連線的建立，然而，三向交握因具有DoS攻擊之弱點，於是在SCTP通訊協定的設計，初始連線則是採用四向交握的策略，SCTP通訊協定先天上的設計可避免DoS攻擊的發生。在終止連線的處理上，TCP通訊協定是以四向交握的方式結束連線，一方之端點可先關閉連線，另一方則可繼續接收資料，這樣的情況又稱為半開放狀態（half-open state）；SCTP通訊協定則是使用三向交握的方式終止連線。在資料傳遞的方面，TCP通訊協定因必須嚴格依序傳輸而會有HOL blocking之問題存在，而SCTP通訊協定僅在同一串流中為絕對依序傳輸，當有封包遺失的情況發生時，順序在該遺失封包之後的資料可以透過其他的串流進行傳輸，而能夠避免HoL Blocking之發生。

在Chang 等人 [5] 之研究中，於Linux作業系統中將開放原始碼之FTP客戶端與伺服端應用程式由TCP通訊協定移植至SCTP通訊協定，並於Linux作業系統中以LKSCTP將FTP應用程式以透過TCP與SCTP通訊協定進行資料傳輸與比較傳輸效能。實驗之目的在於比較於不同的網路壅塞情況中，SCTP通訊協定、未採用SACK [11] 機制之TCP通訊協定（TCP without SACK）與啟動SACK機制之TCP通訊協定（TCP with SACK）分別進行資料傳輸，藉此觀察與分析封包遺失率對於平均傳輸率的影響。

由於TCP通訊協定之設計是基於單一串流傳輸，而且沒有路徑多宿的設計，因此作者實驗時將SCTP通訊協定設定限制為僅使用單一串流，並且關閉SCTP通訊協定路徑多宿之功能，限制SCTP通訊協定以單一串流及依序傳遞與TCP通訊協定進行比較。實驗測量分析的方法是使用FTP客戶端下載FTP伺服端的檔案，並以Wireshark [18] 網路協定分析程式觀察封包了解實際資料傳輸情形，並且於Linux router中隨機丟棄封包，造成封包遺失的效果。他們所測量的傳輸效能沒有包含控制連線之指令傳輸時間，而是僅有初始化資料連線至資料連線結束的這段時間。實驗的每條連線都是獨立且不會互相競爭，因此所呈現的平均傳輸率則是表達在該封包遺失率的網路環境中，該傳輸協定的效能表現。

首先作者於 0 % ~ 10 % 封包遺失率中傳輸1 KB檔案，實驗結果顯示當傳輸1 KB的小檔案時，TCP通訊協定的傳輸效率會比SCTP通訊協定要高，主要是因為SCTP通訊協定連線的建立需要四向交握，與TCP通訊協定的三向交握相較之下，SCTP通訊協定增加了COOKIE認證機制，而於MTU為1500 bytes之路徑中，傳輸1 KB的資料僅需一個封包的傳送即能夠將資料傳輸完成，因此四向交握所增加的負載（overhead）使得SCTP通訊協定在傳輸1 KB小資料時平均傳輸率會比TCP通訊協定低。

而在0 % ~ 10 % 封包遺失率環境傳輸512 KB的資料，由於總資料量足以使SCTP四向交握之負載僅佔據微量比例並不足影響整體效能時， 依據作者的實驗結果，在沒有封包遺失的情況下，SCTP通訊協定與TCP通訊協定的傳輸效能是並駕齊驅的，然而隨著封包遺失率的增加，傳輸效能比為SCTP > TCP with SACK > TCP without SACK，以SCTP的表現為最佳，因為單個SACK封包就能夠攜帶多筆回報訊息，可減少ACK封包的數目，所以TCP with SACK與SCTP通訊協定在傳輸效能比TCP without SACK協定為佳。

然而，比較SCTP與TCP with SACK，作者觀察於8 % 封包遺失率時傳輸512 KB資料量的結果，SCTP通訊協定之平均傳輸率為3566 KB/sec，而TCP with SACK僅有696 KB/sec，傳輸率的效能比甚至高達五倍之多。於是作者追蹤Linux kernel 2.6.17原始碼 [19] ，以了解Linux系統SCTP通訊協定實作之細節，經由程式碼發現在Linux kernel中，SCTP通訊協定之初始壅塞視窗是依循RFC 3390 [3] 提出的方式實作，將壅塞視窗（cwnd）之初始值設定為min (4*PMTU, max(2*PMTU, 4380 bytes))並將ssthresh設定為65535 bytes，而TCP通訊協定之壅塞視窗初始值僅使用兩個MSS（max segment size）的大小 [1] 與100 bytes之ssthresh初值（標準TCP通訊協定ssthresh則沒有限制），因此使得SCTP通訊協定在起初就能夠擁有較大的壅塞視窗，可以比TCP通訊協定傳輸較多的資料。

而在快速重送（fast retransmission）機制上，重複的ACK或SACK會觸發快速重送的發生並導致壅塞視窗的減半，觸發TCP通訊協定快速重送的條件是收到三個重複的ACK訊息，而觸發SCTP通訊協定之快速重送機制則需要四次重複之SACK訊息，這使得TCP通訊協定在封包遺失率高的環境中，壅塞視窗降低的機率會比SCTP通訊協定還大，也是導致TCP平均傳輸率降低的其中原因。TCP通訊協定之SACK封包僅能攜帶三個區塊（blocks）回報資訊，而SCTP通訊協定並沒有特別限制，因此SCTP通訊協定所能攜帶之訊息僅受限於SACK封包格式制定的欄位數。

SCTP通訊協定之四向交握初始連線過程可防禦傳統TCP通訊協定初始連線時的弱點，並有以上的學者研究分析證實了SCTP通訊協定之多重串流與路徑多宿的功能是可以改善傳輸效能與降低傳輸延遲的。即使限制SCTP通訊協定僅使用單一串流傳輸，在傳輸效能方面也能夠與TCP並駕齊驅，甚至於網路壅塞環境中SCTP之效能表現更為優良，因此，SCTP通訊協定也適合應用於目前普遍使用的TCP網路環境。

8. 參考文獻

[1] M. Allman, V. Paxson, and W. Stevens, “TCP Congestion Control”, RFC 2581, IETF, April 1999.

[2] M. Allman, H. Balakrishnan, and S. Floyd, “Enhancing TCP’s Loss Recovery Using Limited Transmit”, RFC 3042, IETF, January 2001.

[3] M. Allman, S. Floyd, and C. Partridge, “Increasing TCP’s Initial Window Size”, RFC 3390, October 2002.

[4] M. Allman, “TCP Congestion Control with Appropriate Byte Counting”, RFC 3465, IETF, February 2003.

[5] L.H. Chang, M.Y. Liao, and C.H. Song, “Implementation and evaluation of single-stream SCTP and TCP for FTP“, Journal of Communications of IICM Taiwan, Vol. 10, Issue 1, pp. 163-178, March 2007.

[6] K.J. Grinnem, T. Andersson and A. Brunstrom “Performance Benefits of Avoiding Head-of-Line Blocking in SCTP”, Proceedings of the IEEE ICAS/ICNS, pp. 44-51, October 2005.

[7] M. Nurul Islam, and A. Kara, “Throughput Analysis of SCTP over a Multi-homed Association”, Proceedings of the IEEE CIT, pp. 110-116, September 2006.

[8] A. Meixner, P. Yin, D. Onyango, and A. Vahdat, “Design and Evaluation of a Kernel-Level SCTP Implementation”, http://www.cs.duke.edu/~py/paper/miscPaper/sys-sctp.tech.2001.pdf.

[9] J. Mogul, and S. Deering, “Path MTU Discovery”, RFC 1063, IETF, November 1990.

[10] J. Mogul, S. Deering, and J. Mogul, “Path MTU Discovery for IP version 6”, RFC 1981, IETF, August 1996.

[11] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “TCP Selective Acknowledgement Options”, RFC 2018, IETF, October 1996.

[12] P. Natarajan, P.D. Amer, R. W. Bickhart, and S. Ladha, “Improving Multiple File Transfer using SCTP Multi-streaming”, Proceedings of the IEEE International Performance Computing and Communications Conference, 2004.

[13] F. Siddiqui and S. Zeadally, “SCTP Multihoming Support for Handoffs across Heterogeneous Networks”, Proceedings of the IEEE CNSR 2006, pp. 243-250, May 2006.

[14] R. Steward, Q. Xie, L. Yarroll, K. Poon, M. Tuexen, “Sockets API Extensions for Stream Control Transmission Protocol (SCTP)”, draft-ietf-tsvwg-sctpsocket-15, IETF, July 9, 2007.

[15] R. Steward, Q. Xie, M. Tuexen, S. Maruyama, and M. Kozuka, “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration”, draft-ietf-tsvwg-addip-sctp-22, IETF, June 19, 2007.

[16] Linux Kernel Stream Control Transmission Protocol Project, http://lksctp.sourceforge.net.

[17] SCTPLIB, Simens and Computer Networking Technology Group of the University of Essen, http://www.sctp.de/sctp-download.html.

[18] The Wireshark Network Protocol Analyzer, http://www.wireshark.org.

[19] The Linux kernel Archives, http://www.kernel.org.

[20] J. Postel, “User Datagram Protocol”, RFC 768, IETF, August 1980.