SCTP
SCTP(Stream Control Transmission Protocol,流控制傳輸協(xié)議,RFC 2960、RFC 3286、RFC 3309)是一個 IP 協(xié)議之上的、可靠的、面向控制信令的、傳輸層協(xié)議。SCTP 可以在 “盡力而為(無連接、不可靠)” 的 IP 網(wǎng)絡(luò)之上為電信級信令傳輸提供高效、可靠的信令傳輸服務,例如 5GC 中的 N2 接口就使用了 SCTP 協(xié)議。 SCTP 的誕生是為了彌補 TCP/UDP 在電信網(wǎng)絡(luò)控制信令傳輸場景中的不足,它們都難以完全滿足在電信網(wǎng)絡(luò)中信令承載的要求。包括:
UDP 是一種無連接的不可靠傳輸協(xié)議,自然無法滿足信令對傳輸質(zhì)量的要求。
TCP 雖然是一種基于連接的可靠傳輸協(xié)議,但同時也具有隊頭阻塞、實時性差、支持多歸屬困難、易受 DDOS(拒絕服務)攻擊的缺陷。
為了解決 TCP/UDP 協(xié)議在傳輸實時信令時所面臨的不可靠傳輸和時延等問題,SCTP 協(xié)議設(shè)計了以下的核心特性,包括:
適當?shù)膿砣刂疲?/p>
防止泛濫和偽裝攻擊;
更優(yōu)的實時性能;
多屬主(Multi-homing)特性支持;
多流(Multi-streaming)特性支持;
等等。
SCTP 與 TCP 的區(qū)別
和 TCP 類似,SCTP 是面向連接、端到端、全雙工、帶有流量和擁塞控制的可靠傳輸協(xié)議。數(shù)據(jù)可靠傳輸都是通過確認機制來實現(xiàn)的,與 TCP 的區(qū)別是:
TCP 是以字節(jié)為單位傳輸?shù)模琒CTP 是以數(shù)據(jù)塊為單位傳輸?shù)摹?/p>
TCP 通常是單路徑傳輸,SCTP 可以多路徑傳輸。
TCP 的兩端都只能用一個 IP 來建立連接,連接建立之后就只能用這一對 IP 來相互收發(fā)消息。如果這一對 IP 之間的路徑出了問題,那這條 TCP 連接就不可用了;而 SCTP 的兩端都可以綁定到多個 IP 上,只要有其中一對 IP 能通,這條 SCTP 連接就還可以用。這就是 SCTP 的多宿主機制。
TCP 是單流的有序傳輸,SCTP 可以多流獨立有序/無序傳輸。這就是 SCTP 的多流機制。
TCP 連接的建立過程需要三步握手,SCTP 連接的建立過程需要四步握手。
SCTP 有 Heartbeat(心跳)機制來管理路徑的可用性。
SCTP 與 QUIC 的區(qū)別
SCTP 在 WebRTC 上已有基于 UDP 的實現(xiàn),但 SCTP/UDP 與 QUIC/UDP 相比還不夠好:
沒有解決數(shù)據(jù)流的隊頭阻塞問題。
連接建立時需要決定數(shù)據(jù)流的數(shù)量。
沒有穩(wěn)固的 TLS 安全性支持。
建立連接時候需要 4 次握手,而 QUIC 一次都不用(0-RTT)。
QUIC 是類 TCP 的字節(jié)流,而 SCTP 是信息流(message-based)。
QUIC 連接支持 IP 地址遷移,SCTP 不行。
SCTP 的基本概念
主機(Host)和端點(Endpoint)
主機(Host)就是具有一個或多個 IP 地址的計算機,是一個物理概念;
端點(Endpoint)就是一個 SCTP Endpoint,是一個邏輯概念,作為 SCTP 協(xié)議收/發(fā)的兩端。
SCTP Endpoint 有一個 L4 傳輸層端口號(Port)和若干個 L3 網(wǎng)絡(luò)層 IP 地址組成(通常是 2 個 IP 地址),但一個 SCTP Endpoint 所含有的若干個 IP 地址必須使用同一個相同的 Port。
多宿主(Multi-homing)
SCTP Endpoint(具有多個 IP 地址)是 SCTP 多宿主特性的基礎(chǔ),一個 SCTP Endpoint 可能有多個冗余的 IP 網(wǎng)絡(luò)連接。當不同 Hosts 之間的 SCTP Endpoint 建立了一個偶聯(lián)之后,如果它的某個 IP 網(wǎng)絡(luò)連接發(fā)生故障了,SCTP 就可以通過切換到另一個 IP 地址來避免業(yè)務中斷。是一種類似于主備的高可用思想。 如下圖所示,我們可以配置 “雙宿主” 模式。
通路(Path)和首選通路(Primary Path)
多宿主特性提高了網(wǎng)絡(luò)的容錯能力,這也引出了另一對概念:通路(Path)和首選通路(Primary Path)。 如果 Receiver 是多宿主的,那么對于 Sender 來說每一個 Receiver 的 IP 地址就代表著一條通往對端的 Path,這樣 Sender 可以選擇任一條 Path 來發(fā)送數(shù)據(jù)。
SCTP 規(guī)定任何時間都有一條路徑作為 Primary Path 來發(fā)送數(shù)據(jù),其他路徑作為 Backup Path。如果 Primary Path 因接口故障或者網(wǎng)絡(luò)擁塞等原因而失效,SCTP 可以自動切換到另外一條 Path 來發(fā)送,避免單點失效,從而提高整個關(guān)聯(lián)的容錯能力。
偶聯(lián)(Association)
SCTP 使用 “偶聯(lián)” 一詞替代 TCP 的 “連接” 是為了避免內(nèi)涵的混淆:一個連接只涉及兩個 IP 地址間的通信。 SCTP 協(xié)議規(guī)定在任何時刻,2 個 SCTP Endpoint 之間能且僅能建立一個偶聯(lián),它可能因為 SCTP 的多宿主特性而涉及若干個 IP 地址。
SCTP 支持多種網(wǎng)絡(luò)協(xié)議,當 SCTP 在 IP 網(wǎng)絡(luò)上運行時,Local IP 地址、Local SCTP Port 號、Remote IP 地址、Remote SCTP Port 號等 4 個參數(shù),可以唯一標識一個 SCTP 偶聯(lián)。 SCTP 的偶聯(lián)需要通過 4 次握手建立。相對于 TCP 的 3 次握手建立連接,SCTP 的偶聯(lián)能夠抵御 DoS 攻擊,從而提高了安全性。數(shù)據(jù)只有在建立偶聯(lián)之后與關(guān)閉偶聯(lián)之前才可發(fā)送。SCTP 偶聯(lián)通過 3 次握手關(guān)閉,不支持類似 TCP 的半關(guān)閉連接。也就是在任何一方關(guān)閉偶聯(lián)后,對方即不再發(fā)送數(shù)據(jù)。
傳輸控制塊(TCB)
TCB(Transmission Control Block,傳輸控制塊)是 SCTP 內(nèi)部的數(shù)據(jù)結(jié)構(gòu),是一個 SCTP Endpoint 為其他 Endpoint 之間已經(jīng)建立的每 個偶聯(lián)生成的。TCB 包括 Endpoint 的所有狀態(tài)、操作信息,便于維護和管理相應的偶聯(lián)。
多流(Multi-streaming)
一個 SCTP 偶聯(lián)中的 Stream(流)用來表示需要按順序遞交到高層協(xié)議的用戶消息序列,在同一個 Stream 中的 Msg 需要按照其順序進行遞交。嚴格地說,Stream 就是一個 SCTP 偶聯(lián)中,從一個 Endpoint 到另一個 Endpoint 的單向邏輯通道。一個偶聯(lián)是由多個單向的 Stream 組成的。
Multi-streaming 是 SCTP 協(xié)議的另一個關(guān)鍵特性,主要解決了 TCP 隊頭擁塞的問題。在一個 SCTP 偶聯(lián)中,各個 Stream 之間相對獨立,使用 Stream ID 進行標識。在同一 Stream 內(nèi)發(fā)送的消息有序,而不同 Stream 之間的消息無序,因此不同 Stream 之間的消息傳輸是相對獨立的,每個 Stream 可以單獨發(fā)送數(shù)據(jù)而不受其他流的影響。
一個 SCTP 偶聯(lián)中可用的 Stream 的數(shù)量是在建立 SCTP 偶聯(lián)時由雙方端點協(xié)商決定的,但一個 Stream 只能屬于一個 SCTP 偶聯(lián)。SCTP 報文會在不同的 Stream 內(nèi)發(fā)送,這也是 “流控制傳輸協(xié)議“ 名稱的由來。 ?
每個 Stream 上某個 Msg 的丟失不會阻塞同一關(guān)聯(lián)其他 Stream 上消息的投遞。這種做法正好與 TCP 相反,就 TCP 而言,在單一字節(jié)流中任何位置的字節(jié)丟失都將在阻塞該連接上其后所有數(shù)據(jù)的遞送,直到該丟失被修復為止。SCTP 在某一個 Stream 內(nèi)由于數(shù)據(jù)傳輸失敗而引起的阻塞不會影響其他 Stream 的消息遞交,多流特性可以幫助解決 TCP 中的隊頭阻塞(HOL)問題。
這一點與 HTTP/2 協(xié)議非常類型。因為 TCP 傳輸是按字節(jié)嚴格有序的,先行傳送的字節(jié)如果丟失或損壞,即使后續(xù)的字節(jié)正確地被接收到也不能向上層遞交,必須在接收端緩沖起來,直到先行字節(jié)由于重傳而全部正確接收到后才可以提交,并且釋放緩沖區(qū)。
傳輸順序號(TSN)和流順序號(SSN)
TSN(Transmission Sequence Number):SCTP 使用 TSN 機制實現(xiàn)數(shù)據(jù)的確認傳輸。一個偶聯(lián)的發(fā)送端為發(fā)送的每個數(shù)據(jù)塊順序分配一個基于初始 TSN 的 32 位順序號,以便接收端進行確認。TSN 是基于偶聯(lián)進行維護的。
SSN(Stream Sequence Number):SCTP 為一個偶聯(lián)的發(fā)送端中的一個流中發(fā)送的每個數(shù)據(jù)塊順序分配一個 16 位 SSN,以便保證流 內(nèi)的順序傳遞。在偶聯(lián)建立時,所有流中的 SSN 都是從 0 開始。當 SSN 到達 65535 后,則接下來的 SSN 為 0。
TSN 和 SSN 的分配是相互獨立的。此外,SCTP 還定義了無序消息。如果消息帶有無序標志,則不論它在哪個流中(在具體實現(xiàn)中,數(shù)據(jù)塊中的 Steam ID 不被解析),只要被正確接收,都提交給 ULP,從而實現(xiàn)和流無關(guān)的無序遞交,具有更好的靈活性。
SCTP 的報文格式
一個 SCTP 報文包含了一個 Common Header(公共報頭)和若干個 Chunk(數(shù)據(jù)塊),每 個數(shù)據(jù)塊中既可以包含控制信息,也可以包含用戶數(shù)據(jù)。
INIT 數(shù)據(jù)塊的報文中必須為 0。
含 SHUTDOWN-COMPLETE 數(shù)據(jù)塊且設(shè)置了 T 比特的報文中,驗證標簽必須要從包含 SHUTDOWN-ACK 數(shù)據(jù)塊的報文中復制。
含 ABORT 數(shù)據(jù)塊的報文中,驗證標簽必須要從觸發(fā)這個 ABORT 發(fā)送的報文中復制。
0:凈荷數(shù)據(jù)(DATA)
1:啟動(INIT)
2:啟動證實(INIT ACK)
3:選擇證實(SACK)
4:Heartbeat 請求(HEARTBEAT)
5:Heartbeat 證實(HEARTBEAT ACK)
6:中止(ABORT)
7:關(guān)閉(SHUTDOWN)
8:關(guān)閉證實(SHUTDOWN ACK)
9:操作差錯(ERROR)
10:狀態(tài) Cookie(COOKIE ECHO)
11:Cookie 證實(COOKIE ACK)
12:為明確擁塞通知響應(ECNE)預留
13:為降低擁塞窗口(CWR)預留
14:關(guān)閉完成(SHUTDOWN COMPLETE)
15-62:IETF 預留
63:IETF 定義的數(shù)據(jù)塊擴展
64-126:IETF 預留
127:IETF 定義的數(shù)據(jù)塊擴展
128-190:IETF 預留
191:IETF 定義的數(shù)據(jù)塊擴展
192-254:IETF 預留
255:IETF 定義的數(shù)據(jù)塊擴展
Source Port Number(源端口號):接收方可以使用源端口號、源 IP 地址、目的端口號和目的 IP 地址標識該 SCTP 報文所屬的偶聯(lián)。
Destination Port Number(目的端口號):接收方可以使用目的端口號將 SCTP 報文復用到正確的端點或應用中。
Verification Tag(驗證標簽):偶聯(lián)建立時,本端端點為這個偶聯(lián)生成一個隨機標識。偶聯(lián)建立過程中,雙方會交換這個 Tag,到了數(shù)據(jù)傳遞時,發(fā)送端必須在 Common Header 中帶上對端的這個 Tag,以備校驗。
Checksum:SCTP 通過對用戶數(shù)據(jù)使用 ADLER-32 算法,計算出一個 32 位的校驗碼,帶在數(shù)據(jù)報文中,在接收端進行同樣的運算,通過檢查校驗碼是否相等來驗證用戶數(shù)據(jù)是否遭到破壞。
Chunk Type:定義塊值(Chunk Value)中消息所屬的類型。包括:INIT、INIT ACK、 SACK、ABORT、ERROR、SHUTDOWN、COOKIE ACK 等 13 種數(shù)據(jù)塊類型。該參數(shù)的取值范圍為 0~254,255 留作今后的擴展。數(shù)據(jù)塊類型字段的編碼分配如下:
另外,Chunk type 的高兩位 bit 指示了接收端不認識對應的 Chunk type 的處理原則:
00:停止處理數(shù)據(jù)報并丟棄,不再處理報中的其他 Chunk。
01:與 00 相同處理外,還要在 ERROR 或 INIT ACK 中上報,原因為不認識的參數(shù)類型。
10:忽略該 Chunk,繼續(xù)處理數(shù)據(jù)報中的其他 Chunk。
11:同 10 相同處理外,還要在 ERROR 中上報,原因為不認識的 Chunk 類型。
SCTP 的數(shù)據(jù)傳輸方式
從 SCTP 的報文格式可以看出 SCTP 是通過傳輸 Chunk 來傳輸數(shù)據(jù)的。對比 TCP 傳輸?shù)臄?shù)據(jù)方式:TCP 接收端確認的是收到的字節(jié)數(shù)(TCP 基于數(shù)據(jù)流進行數(shù)據(jù)傳輸),SCTP 接收端確認的是接收到的數(shù)據(jù)塊(SCTP 基于數(shù)據(jù)塊進行數(shù)據(jù)傳輸)。
SCTP 的數(shù)據(jù)塊(Data Chunk)通常會攜帶應用的一個數(shù)據(jù)報文,或者說是應用要發(fā)送的一個消息(Message)。 在實際的應用中,TCP 發(fā)送方的可以將應用程序需要發(fā)送的多個消息打包到一個 TCP 數(shù)據(jù)報文中發(fā)出。比如,應用程序連續(xù)調(diào)用兩次 send() 向?qū)Χ税l(fā)送兩條消息,TCP 協(xié)議可能把這兩條消息都打包放在同一個 TCP 數(shù)據(jù)報文中。接收端在收到這個 TCP 報文時,回給對端的 ACK 只是表明自己接收到了多少個字節(jié),TCP 協(xié)議本身并不會把收到的數(shù)據(jù)重新拆散分成兩條應用層消息并通知應用程序去接收。
事實上,應用程序可能只需要調(diào)用一次 receive(),就會把兩條消息都收上來了,然后應用需要根據(jù)應用程序自己定義的格式去拆成兩條消息。 與 TCP 不同,SCTP 是將應用程序每次調(diào)用 sendmsg() 發(fā)送的數(shù)據(jù)當作一個整體,放到一個 Data Chunk,接收端也是以 Data Chunk 為單位接收數(shù)據(jù),并重新組包,通知應用程序接收。
通常,應用程序每次調(diào)用 recvmesg() 都會收到一條完整的消息。在 SCTP 的發(fā)送端,多條短的應用層消息可以被 SCTP 協(xié)議打包放在同一個 SCTP 報文中,此時在 SCTP 包中可以看到多個 Data Chunk。另一方面,一條太長(比如,超過了路徑 MTU)的應用層消息也可能被 SCTP 協(xié)議拆分成多個片段,分別放在多個 Data Chunk 并通過不同的 SCTP 報文發(fā)送給對端。這兩種情況下,SCTP 的接收端都能重新組包,并通知應用程序去接收。
數(shù)據(jù)庫(Data Chunk)格式
?
這里重點關(guān)注 Chunk Type=0 的數(shù)據(jù)塊:
Reserved:預留,應當設(shè)置為全 0,在接收方忽略。
U(比特):非順序比特。如果該比特設(shè)置為 1,則指示這是一個非順序的數(shù)據(jù)塊,不需要給該數(shù)據(jù)塊分配流順序號碼,所有接收方必須忽略流順序號碼。在重新組裝完成后(如果需要),非順序的數(shù)據(jù)塊不需要嘗試任何重新排序的過程,可以由接收方直接遞交到高層;如果一個非順序的用戶消息被分段,則消息的每個分段中的 U 比特必須被設(shè)置為 1。
B(比特):分段開始比特。如果該比特被設(shè)置,則表示這是用戶消息的第一個分段。
E(比特):分段結(jié)束比特。如果該比特被設(shè)置,則指示這是用戶消息的最后一個分段。一個未分段的用戶消息應當把所有的 B 和 E 比特設(shè)置為 1。如果 B 和 E 比特都設(shè)置為 0,則表明這是一個分段的用戶消息的一個中間分段。當用戶消息被分段到多個數(shù)據(jù)塊中,接收方需要使用 TSN 對消息進行重組,這意味著給分段的用戶消息的每個分段都必須要使用連續(xù)的 TSN。
B、E 比特的取值含義如下:
0 表示高層未對該協(xié)議凈荷規(guī)定應用標識符。
M2UA 協(xié)議凈荷使用編碼 2。
M3UA 協(xié)議凈荷使用編碼 3。
SUA 協(xié)議凈荷使用編碼 4。
M2PA 協(xié)議凈荷使用的編碼待定。
B=1、E=0:用戶消息的第 1 個分片。
B=0、E=0:用戶消息的中間分片。
B=0、E=1:用戶消息的最后一個分片。
B=1、E=1:未分片的消息。
Length:表示數(shù)據(jù)塊從類型字段開始到用戶數(shù)據(jù)字段結(jié)束之間的字節(jié)數(shù),但不包含任何填充字節(jié),如果數(shù)據(jù)塊的用戶數(shù)據(jù)字段為 0,則長度字段設(shè)為 16。
TSN:TSN 的值達到 4294967295 后將回轉(zhuǎn)到 0。
Stream Identifier S:表示用戶數(shù)據(jù)屬于的流。
Stream Sequence Number n:表示所在流中的用戶數(shù)據(jù)的順序號碼。有效值為 0~65535。當一個用戶消息被 SCTP 分段后,則必須在消息的每個分段中都帶有相同的流順序號碼。
Payload Protocol Identifier:表示一個應用(或上層協(xié)議)特定的協(xié)議標識符。這個值由高層協(xié)議傳遞到 SCTP,并發(fā)送到對端。這個標識符不由 SCTP 使用,但卻可以由特定的網(wǎng)絡(luò)實體或?qū)Φ鹊膽脕碜R別在數(shù)據(jù)塊中攜帶的信息類型。甚至在每個分段的數(shù)據(jù)塊中也應包含該字段(以確保對網(wǎng)絡(luò)中間的代理可用)。
User Data:用來攜帶用戶數(shù)據(jù)凈荷。該字段必須被填充為 4 字節(jié)的整數(shù),發(fā)送方填充的字節(jié)數(shù)應不超過 3 個字節(jié),接收方忽略所有的填充字節(jié)。
?
在實際開發(fā)時,需要注意在同一 SCTP 報文中對多個 DATA CHUNK 的處理。例如:如果為每個長度很短的用戶數(shù)據(jù)都帶上一個很大 SCTP Header,其傳遞效率比如會很低。因此,SCTP 協(xié)議至此將幾個用戶數(shù)據(jù)(容量足夠的前提下)捆綁到一個 SCTP 報文里面?zhèn)鬏敚蕴岣邘挼睦寐省_@就是所謂的用戶消息捆綁。
SCTP 用戶能夠可選地使用捆綁功能,決定是否將多個用戶數(shù)據(jù)報捆綁在一個 SCTP 分組中。但為提高效率,在擁塞/重發(fā)時,捆綁功能可能仍被執(zhí)行,即使用戶已經(jīng)禁止捆綁了。這是開發(fā)時需要注意的地方,稍不留神就可能漏掉了用戶數(shù)據(jù)。
SCTP 基本信令流程
偶聯(lián)的建立和發(fā)送流程
?
上圖為 SCTP EndpointA 啟動建立偶聯(lián),并向 EndpointB 發(fā)送一個用戶消息,隨后 EndpointB 向 EndpointA 發(fā)送 兩個用戶消息的信令流程(假定這些消息沒有捆綁和分段)。
啟動標簽(nitiate Tag):對端驗證標簽,如設(shè)為 Tag_A。Tag_A 是從 1 到 4294967295 中的一個隨機數(shù)。
輸出流數(shù)量(OS):本端點期望的最大出局流的數(shù)量。
輸入流數(shù)量(MIS):本端點允許入局流的最大數(shù)量。
目的地 IP 地址:設(shè)置成 INIT 數(shù)據(jù)塊的起源 IP 地址。
啟動標簽(Initiate Tag):設(shè)置成 Tag_B。
狀態(tài) COOKIE(STATE COOKIE):根據(jù)偶聯(lián)的基本信息生成一個 TCB,不過這個 TCB 是一個臨時 TCB。這個 TCB 生成以后,將其中的必要信息(包含一個 COOKIE 生成的時間戳、COOKIE 的生命期)和一個本端的密鑰通過 RFC2401 描述的算法計算成一個32 位 的摘要 MAC(這種計算是不可逆的)。必要信息和 MAC 組合成 STATE COOKIE 參數(shù)。
本端點傳送地址。
最大入局流的數(shù)量。
最大出局流的數(shù)量。
TSN:DATA 數(shù)據(jù)塊的初始 TSN。流標識符(Stream Identifier):用戶數(shù)據(jù)屬于的流,假設(shè)流標識符為 0。流順序碼(Stream Sequence Number):所在流中的用戶數(shù)據(jù)的順序號碼。該字段從 0 到 65535。用戶數(shù)據(jù)(User Data):攜帶用戶數(shù)據(jù)凈荷。
累積證實 TSN 標簽(Cumulative TSN Ack):EndpointA 的初始 TSN。間隔塊(Gap Ack Block):此值為 0。EndpointA 收到 SACK 數(shù)據(jù)塊后,停止 T3-RTX 定時器。
TSN:EndpointB 發(fā)出 DATA 數(shù)據(jù)塊的初始 TSN。
流標識符(Stream Identifier):用戶數(shù)據(jù)屬于的流,假設(shè)流標識符為 0。
流順序碼(Stream Sequence Number):所在流中的用戶數(shù)據(jù)的順序號碼。假設(shè)流 順序碼為 0。
用戶數(shù)據(jù)(User Data):攜帶用戶數(shù)據(jù)凈荷。
TSN:EndpointB 發(fā)出 DATA 數(shù)據(jù)塊的初始 TSN+1。
流標識符(Stream Identifier):用戶數(shù)據(jù)屬于的流,假設(shè)流標識符為 0。
流順序碼(Stream Sequence Number):所在流中的用戶數(shù)據(jù)的順序號碼。此時流順序碼為 1。
用戶數(shù)據(jù)(User Data):攜帶用戶數(shù)據(jù)凈荷。
累積證實 TSN 標簽(Cumulative TSN Ack):EndpointB 的初始 TSN。
間隔塊(Gap Ack Block)此值為 0。
EndpointA 創(chuàng)建一個數(shù)據(jù)結(jié)構(gòu) TCB(傳輸控制塊)來描述即將發(fā)起的這個偶聯(lián)(包含偶聯(lián)的基本信息),然后向 EndpointB 發(fā)送 INIT 數(shù)據(jù)塊。INIT 數(shù)據(jù)塊中主要包括如下參數(shù):
EndpointB 收到 INIT 消息后,立即用 INIT ACK 數(shù)據(jù)塊響應。INIT ACK 數(shù)據(jù)塊中必須帶有如下參數(shù):
EndpointA 收到 INIT ACK 后,首先停止 INIT,離開 COOKIE-WAIT 狀態(tài), 然后發(fā)送 COOKIE ECHO 數(shù)據(jù)塊,將收到 INIT ACK 數(shù)據(jù)塊中的 STATE COOKIE 參數(shù)原封帶回。最后 EndpointA 啟動 COOKIE 定時器并進入 COOKIE-ECHOED 狀態(tài)。
EndpointB 收到 COOKIE ECHO 數(shù)據(jù)塊后,進行 COOKIE 驗證。將 STATE COOKIE 中的 TCB 部分和本端密鑰根據(jù) RFC2401 的 MAC 算法進行計算,得出的 MAC 和 STATE COOKIE 中攜帶的 MAC 進行比較。如果不同則丟棄這個消息;如果相同,則取出 TCB 部分的時間 戳,和當前時間比較,看時間是否已經(jīng)超過 了COOKIE 的生命期。如果是,同樣丟棄;否則根據(jù) TCB 中的信息建立一個和 EndpointA 的偶聯(lián)。EndpointB 將狀態(tài)遷入 ESTABLISHED,并發(fā)出 COOKIE ACK 數(shù)據(jù)塊。EndpointB 向 SCTP 用戶發(fā)送 SCOMMUNCIATION UP 通知。
EndpointA 向 EndpointB 發(fā)送一個 DATA 數(shù)據(jù)塊,啟動 T3-RTS 定時器。DATA 數(shù)據(jù)塊中必須帶 有如下參數(shù):
EndpointB 收到 DATA 數(shù)據(jù)塊后,返回 SACK 數(shù)據(jù)塊。SACK 數(shù)據(jù)塊中必須帶有如下參數(shù):
EndpointB 向 EndpointA 發(fā)送第一個 DATA 數(shù)據(jù)塊。DATA 數(shù)據(jù)塊中必須帶有如下參數(shù):
EndpointB 向 EndpointA 發(fā)送第二個 DATA 數(shù)據(jù)塊。DATA 數(shù)據(jù)塊中必須帶有如下參數(shù):
EndpointA 收到 DATA 數(shù)據(jù)塊后,返回 SACK 數(shù)據(jù)塊。SACK 數(shù)據(jù)塊中必須帶有如下參數(shù):
偶聯(lián)關(guān)閉流程
當一個 Endpoint 退出服務時,需要停止它的偶聯(lián)。偶聯(lián)的停止使用兩種流程:
偶聯(lián)的中止流程(非正常關(guān)閉):可以在任何未完成期間進行,偶聯(lián)的兩端都舍棄數(shù)據(jù)并且不提交到對端。此種方法不考慮數(shù)據(jù)的安全。偶聯(lián)的中止步驟比較簡單:發(fā)起端點向?qū)Χ硕它c發(fā)送 ABORT 數(shù)據(jù)塊,發(fā)送的 SCTP 分組中必須填上對端端點的驗證標簽,而且不在 ABORT 數(shù)據(jù)塊中捆綁任何 DATA 數(shù)據(jù);接收端點收到 ABORT 數(shù)據(jù)塊后,進行驗證標簽的檢查。如果驗證標簽與本端驗證標簽相同,接收端點從記錄上清除該偶聯(lián),并向 SCTP 用戶報告偶聯(lián)的停止。
偶聯(lián)的正常關(guān)閉流程:任何一個端點執(zhí)行正常關(guān)閉程序時,偶聯(lián)的兩端將停止接受從其 SCTP 用戶層發(fā)來的新數(shù)據(jù),并且在發(fā)送或接收到 SHUTDOWN 數(shù)據(jù)塊時,把分組中的數(shù)據(jù)遞交給 SCTP 用戶。偶聯(lián)的關(guān)閉可以保證所有兩端的未發(fā)送、發(fā)送未證實數(shù)據(jù)得到發(fā)送和證實后再終止偶聯(lián)。
?
偶聯(lián)的正常關(guān)閉步驟如下:
偶聯(lián)關(guān)閉發(fā)起 EndpointA 的 SCTP 用戶層向 SCTP 發(fā)送請求 SHUTDOWN 原因。SCTP 偶聯(lián)從 ESTABLISHED 狀態(tài)遷入 SHUTDOWN-PENDING 狀態(tài)。在這個狀態(tài),SCTP 不接受 SCTP 用戶在這個偶聯(lián)上的任何數(shù)據(jù)發(fā)送請求。同時等待 EndpointA 所有發(fā)送未證實的數(shù)據(jù)得到 EndpointB 的證實。當所有 EndpointA 發(fā)送未證實數(shù)據(jù)得到證實,則向 EndpointB 發(fā)送 SHUTDOWN 數(shù)據(jù)塊。EndpointA 啟動 T2-shutdown 定時器進入 SHUTDOWN-SENT 狀態(tài)。啟動 T2-shutdown 定時器的目的是等待 EndpointB 發(fā)回的 SHUTDOWN-ACK 數(shù)據(jù)塊,如果定時器超時,則 EndpointA 必須重新發(fā)送 SHUTDOWN 數(shù)據(jù)塊。
EndpointB 收到 SHUTDOWN 消息后,進入 SHOUTDOWN-RECEIVED 狀態(tài),不再接收從 SCTP 用戶發(fā)來的的新數(shù)據(jù),并且檢查數(shù)據(jù)塊的累積 TSN ACK 字段,驗證所有未完成的 DATA 數(shù)據(jù)塊已經(jīng)被 SHUTDOWN 的發(fā)送方接收。當 EndpointB 所有未發(fā)送數(shù)據(jù)和發(fā)送未證實 數(shù)據(jù)得到發(fā)送和證實后, 發(fā)送 SHUTDOWN ACK 數(shù)據(jù)塊并啟動本端 T2-SHUTDOWN 定時器,并且進入 SHUTDOWN-ACK-SENT 狀態(tài)。如果定時器超時了,EndpointB 則重新發(fā)送 SHUTDOWN ACK 數(shù)據(jù)塊。
EndpointA 收到 SHUTDOWN ACK 消息后,停止 T2-shutdown 定時器,并且向 EndpointB 發(fā)送 SHUTDOWN COMPLETE 數(shù)據(jù)塊,并清除偶聯(lián)的所有記錄。EndpointB 收到 SHUTDOWN COMPLETE 數(shù)據(jù)塊后, 驗證是否處于 SHUTDOWN-ACK-SENT 狀態(tài)。如果不是處于該狀態(tài),則丟棄該數(shù)據(jù)塊;如果端點處于 SHUTDOWN-ACK-SENT 狀態(tài),EndpointB 則停止 T2- shutdown 定時器并清除偶聯(lián)的所有記錄,進入 CLOSED 狀態(tài)。
審核編輯:劉清
-
接收機
+關(guān)注
關(guān)注
8文章
1202瀏覽量
54067 -
ACK
+關(guān)注
關(guān)注
0文章
28瀏覽量
11313 -
SCTP協(xié)議
+關(guān)注
關(guān)注
0文章
3瀏覽量
6728 -
TCP通信
+關(guān)注
關(guān)注
0文章
146瀏覽量
4397 -
TLS
+關(guān)注
關(guān)注
0文章
45瀏覽量
4415
原文標題:網(wǎng)絡(luò)協(xié)議: SCTP 流控制傳輸協(xié)議
文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
TCP和UDP協(xié)議簡析
APB接口協(xié)議的讀寫傳輸及工作流程簡析
Linux內(nèi)核網(wǎng)絡(luò)之網(wǎng)絡(luò)層發(fā)送消息之IP分片簡析
基于SCTP 協(xié)議的偶聯(lián)管理系統(tǒng)設(shè)計
SigTran在3G組網(wǎng)中的應用
基于ATM理念的UTRAN傳輸架構(gòu)簡析
基于SCTP協(xié)議的偶聯(lián)管理系統(tǒng)設(shè)計
流控制傳輸協(xié)議(SCTP),SCTP的結(jié)構(gòu)和內(nèi)容是什么?
簡析BGA封裝技術(shù)與質(zhì)量控制
傳輸控制協(xié)議(TCP)/網(wǎng)絡(luò)層協(xié)議是什么意思
SCTP在軍事通信網(wǎng)絡(luò)中的應用研究
鼠標HID例程(中)簡析
讓“可靠”變得“更快更安全”的數(shù)據(jù)傳輸協(xié)議:SCTP

評論