스트림 제어 전송 프로토콜
Stream Control Transmission Protocol| 인터넷 프로토콜 스위트 |
|---|
| 응용 프로그램레이어 |
| 트랜스포트 레이어 |
| 인터넷 레이어 |
| 링크 레이어 |
SCTP(Stream Control Transmission Protocol)는 인터넷 프로토콜 스위트의 전송 계층에 있는 컴퓨터 네트워킹 통신 프로토콜입니다.원래 통신에서의 Signaling System 7(SS7) 메시지 전송을 목적으로 한 이 프로토콜은 UDP(사용자 데이터그램 프로토콜)의 메시지 지향 기능을 제공함과 동시에 Transmission Control Protocol(TCP)과 같은 폭주 제어가 있는 메시지의 신뢰할 수 있는 순차 전송을 보장합니다.UDP 및 TCP와 달리 이 프로토콜은 복원력과 신뢰성을 높이기 위해 다중 호밍 및 다중 경로를 지원합니다.
SCTP는 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)에 의해 표준화되어 있습니다. RFC9260.SCTP 레퍼런스 실장은 FreeB의 일부로 출시되었습니다.SD 버전 7은 이후 다른 플랫폼으로 널리 이식되고 있습니다.
정식 감독
IETF Signaling Transport(SIGTRAN; 시그널링 트랜스포트) 작업 그룹은 2000년 [2]10월에 프로토콜(번호[1] 132)을 정의했으며, IETF Transport Area(TSVWG; 전송 영역) 작업 그룹이 이를 유지합니다.RFC 9260은 프로토콜을 정의하고 있습니다.RFC 3286에서는 개요에 대해 설명합니다.
메시지 기반 멀티 스트리밍
SCTP 애플리케이션은, 메시지(바이트 그룹)내의 송신용 데이터를 SCTP 트랜스포트 레이어에 송신합니다.SCTP는 메시지와 제어 정보를 각각 청크헤더로 식별되는 개별 청크(데이터 청크 및 제어 청크)에 배치합니다.프로토콜은 메시지를 여러 데이터 청크로 분할할 수 있지만 각 데이터 청크에는 하나의 사용자 메시지의 데이터만 포함됩니다.SCTP는 청크를 SCTP 패킷에 번들합니다.SCTP 패킷은 Internet Protocol 에 송신됩니다.패킷 헤더, SCTP 제어 청크(필요한 경우), 다음으로 SCTP 데이터 청크(사용 가능한 경우)로 구성됩니다.
SCTP는 메시지 지향으로 특징지을 수 있습니다.즉, TCP와 같이 바이트의 연속 스트림을 전송하는 것이 아니라 일련의 메시지(각각 바이트의 그룹)를 전송합니다.UDP와 마찬가지로 SCTP에서는 송신자가 1회의 조작으로 메시지를 송신하고, 그 정확한 메시지가 1회의 조작으로 수신 애플리케이션프로세스에 전달됩니다.반면 TCP는 스트림 지향 프로토콜로 바이트의 스트림을 안정적이고 순서대로 전송합니다.다만, TCP 에서는, 송신원애플리케이션이 송신하는 바이트 그룹을 건네주는TCP 트랜스포트상에서 호출한 회수를 수신자가 알 수 없습니다.송신측에서는, TCP 는 네트워크를 개입시켜 송신 대기하고 있는 바이트의 큐에 바이트를 추가하는 것만으로, 개별의 발신 메시지의 큐를 유지할 필요가 없어집니다.
멀티스트리밍이란 예를 들어 웹 페이지이미지를 웹 페이지텍스트와 동시에 전송하는 등 여러 개의 독립된 청크스트림을 병렬로 전송하는 SCTP의 기능을 말합니다.기본적으로는 여러 연결을 단일 SCTP 어소시에이션으로 번들하여 바이트가 아닌 메시지(또는 청크)로 동작합니다.
TCP는 각 세그먼트에 바이트 시퀀스 번호를 포함시킴으로써 스트림 내의 바이트 순서를 유지합니다.한편 SCTP는 스트림으로 전송되는 각 메시지에 시퀀스 번호 또는 메시지 ID를[note 1] 할당합니다.이를 통해 서로 다른 스트림에서 메시지를 독립적으로 정렬할 수 있습니다.단, SCTP에서는 메시지 순서는 옵션입니다.수신측 애플리케이션은, 송신 순서가 아닌 수신 순서로 메시지를 처리하도록 선택할 수 있습니다.
특징들
SCTP의 특징은 다음과 같습니다.
- 정렬된 데이터 스트림과 정렬되지 않은 데이터 스트림의 신뢰성 높은 전송
- 접속의 한쪽 또는 양쪽 엔드포인트가 복수의 IP 주소로 구성될 수 있는 멀티호밍 지원으로 용장 네트워크 패스 간의 투과적인 페일오버가 가능합니다.
- 독립 스트림 내에서 청크를 전달하면 TCP 바이트 스트림 전달과 달리 불필요한 헤드 오브 라인 차단이 제거됩니다.
- 명시적 부분 신뢰성
- 기본 데이터 전송 경로를 선택하고 전송 경로의 연결을 테스트하는 경로 선택 및 모니터링
- 검증 및 확인 응답 메커니즘은 플래딩 공격으로부터 보호하고 중복되거나 누락된 데이터 청크를 통지합니다.
- 이더넷 점보 프레임에 적합한 향상된 오류 감지 기능
SCTP 설계자는 원래 IP에서 SS7 시그널링 네트워크의 신뢰성 속성 중 일부를 복제하는 것을 목표로 인터넷 프로토콜을 통한 텔레포니(즉, 시그널링 시스템7) 전송을 목적으로 했습니다.이 IETF 작업은 SIGTRAN으로 알려져 있습니다.그동안 Diameter[3] 프로토콜과 ReserPool(RSERPool)[4] 등의 다른 용도가 제안되었습니다.
모티베이션과 채용
TCP는 인터넷을 통해 데이터를 안정적으로 전송할 수 있는 주요 수단을 제공해 왔습니다.그러나 TCP는 여러 응용 프로그램에 제한을 가했습니다.RFC 4960부터:
- TCP 는, 신뢰성이 높은 데이터 전송과 엄격한 송신 순서 전달을 모두 제공합니다.시퀀스 유지보수가 필요 없는 신뢰성 높은 전송이 필요한 어플리케이션도 있고 데이터의 부분적인 순서를 만족하는 어플리케이션도 있습니다.어느 경우든 TCP의 선두 오브 라인 블로킹속성에 의해 불필요한 지연이 발생합니다.
- 개별 레코드 또는 메시지를 교환하는 어플리케이션의 경우 TCP의 스트림 지향성을 위해 개별 레코드를 기술하기 위해 명시적 마커 또는 기타 인코딩을 추가해야 합니다.
- 하나의 큰 패킷으로 충분할 정도의 작은 IP 패킷의 송신을 피하기 위해서, TCP 실장은, 애플리케이션(Nagle 알고리즘)에 의해서 큐잉 되는 데이터가 많아질 때까지, 데이터의 송신을 지연하는 일이 있습니다.이러한 작은 지연이 바람직하지 않은 경우, 애플리케이션은 (TCP 패킷헤더에 PSH 플래그를 설정함으로써) 푸시 패실리티를 사용하여 케이스 바이 케이스(case-by-case)로 지연되지 않은 전송을 명시적으로 요구해야 합니다.한편, SCTP 를 사용하면, 지연 없는 전송을 어소시에이션의 디폴트로서 설정할 수 있기 때문에, 불필요한 지연은 배제됩니다만, 전송 [5]오버헤드는 증가합니다.
- TCP 소켓의 범위가 한정되어[vague] 있기 때문에 멀티홈 호스트를 사용한 고가용성 데이터 전송 기능을 제공하는 작업이 복잡해집니다.
- TCP 는, SYN 공격등의 서비스 거부 공격에 비교적 취약합니다.
인식 부족, 구현 부족(특히 Microsoft Windows), 애플리케이션 지원 부족 및 네트워크 [6]지원 부족으로 인해 채택이 늦어지고 있습니다.
멀티호밍
SCTP는 신뢰성을 높이기 위해 다중 경로를 제공합니다.
각 SCTP 엔드 포인트는 하트비트를 사용하여 리모트엔드 포인트의 프라이머리 주소와 용장 주소의 도달 가능성을 체크해야 합니다.각 SCTP 엔드 포인트는 리모트엔드 포인트로부터 수신한 하트비트를 확인할 필요가 있습니다.
SCTP가 리모트주소로 메시지를 송신하는 경우, 송신원인터페이스는 호스트의 라우팅 테이블에 의해서만 결정됩니다(SCTP에 의해서가 아닙니다).
비대칭 멀티호밍에서는 2개의 엔드포인트 중 하나가 멀티호밍을 지원하지 않습니다.
로컬 멀티호밍 및 리모트싱글호밍에서는 리모트프라이머리 주소에 도달할 수 없는 경우 대체 패스가 가능하더라도 SCTP 어소시에이션은 실패합니다.
패킷 구조
SCTP 패킷은, 다음의 2개의 기본적인 섹션으로 구성됩니다.
- 첫 번째 12바이트를 차지하고 파란색으로 강조 표시된 공통 헤더.
- 패킷의 나머지 부분을 차지하는 데이터 청크.첫 번째 청크는 녹색으로 강조 표시되고 마지막 N개 청크(청크 N)는 빨간색으로 강조 표시됩니다.
| 비트 | 0–7 | 8–15 | 16–23 | 24–31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| +0 | 송신원포트 | 수신처 포트 | ||||||||||||||||||||||||||||||
| 32 | 검증 태그 | |||||||||||||||||||||||||||||||
| 64 | 체크섬 | |||||||||||||||||||||||||||||||
| 96 | 청크 1 타입 | 청크 1 플래그 | 청크 1 길이 | |||||||||||||||||||||||||||||
| 128 | 청크 1 데이터 | |||||||||||||||||||||||||||||||
| … | … | |||||||||||||||||||||||||||||||
| … | 청크 N 타입 | 청크 N 플래그 | 청크 N 길이 | |||||||||||||||||||||||||||||
| … | 청크 N 데이터 | |||||||||||||||||||||||||||||||
각 청크는 RFC 9260에서 정의된15개의 청크타입과 추가 RFC에서 [note 2]정의된5개 이상의 청크타입 식별자로 시작합니다.8개의 플래그 비트, 2바이트 길이의 필드 및 데이터가 청크의 나머지 부분을 구성합니다.청크가 4바이트의 배수를 형성하지 않는 경우(즉, 길이가 4의 배수가 아님), 청크 길이에 포함되지 않는 0으로 채워집니다.2바이트 길이 필드는 각 청크를 65,535바이트 길이(type, flags 및 length 필드 포함)로 제한합니다.
보안.
암호화는 원래 SCTP 설계에는 포함되지 않았지만 SCTP는 SYN 플래딩 공격으로부터 보호하기 위한 4-way 핸드쉐이크(TCP 3-way 핸드쉐이크보다), 어소시에이션 검증과 신뢰성을 위한 큰 「쿠키」등의 시큐러티를 향상시키는 기능을 탑재하고 있습니다.
신뢰성은 또한 SCTP 보안 설계의 핵심이었습니다.멀티호밍을 사용하면 일부 루트와 인터페이스가 다운되어 있는 경우에도 어소시에이션은 오픈 상태를 유지할 수 있습니다.이는 SCTP를 사용하여 IP 네트워크를 통해 SS7을 전송하기 때문에 SIGTRAN에 특히 중요합니다.또한 네트워크의 이상 현상이 지속되는 경우에도 통신 서비스를 유지하기 위해 링크 장애 시 강력한 복원력을 필요로 합니다.
경우에 따라서는 SCTP가 핑거프린트 후보가 될 수 있습니다.일부 운영체제시스템에서는 SCTP 지원이 네이블로 출하되고 있으며 TCP나 UDP로 잘 알려져 있지 않기 때문에 방화벽 및 침입검출 설정에서 간과되는 경우가 있기 때문에 프로빙트래픽이 허가되는 경우가 많습니다.
실장
SCTP 레퍼런스 실장은 FreeBSD, Mac OS X, Microsoft Windows 및 [7]Linux에서 실행됩니다.
다음의 operating system은, SCTP 를 실장하고 있습니다.
- AIX 버전 5 이상
- 8[8].0 이후[9] NetBSD
- Cisco IOS 12 이후
- 버전 1.4 이후 DragonFly BSD는 지원 대상에서 제외됩니다.
- FreeBSD 버전7 이상에는 레퍼런스 SCTP 구현이[11] 포함되어 있습니다.
- HP-UX, 11i v2 이상[12]
- 일루미네이션
- Linux 커널 2.4 이상
- QNX Neutrino Realtime OS [13](6.3.0 ~6.3.2), 6.4.0 이후[14] 폐지
- Compaq SCTP 애드온 패키지 포함 Tru64
- Sun Solaris 10 이후[15]
- VxWorks 버전 6.2.x ~ 6.4.x 및 6.7 이상
서드파티제 드라이버:
- Microsoft Windows:
- SctpDrv 커널 드라이버는 BSD SCTP 스택에서 Windows로의 포트(2012년 [16]이후 폐기)입니다.
- MacOS:
- Mac OS[17] X용 SCTP 네트워크 커널 확장
사용자 공간 라이브러리:
- 휴대용 SCTP 사용자 랜드[18] 스택
- SCTP 라이브러리[19]
- Oracle Java SE 7
- Erlang/OTP
다음 응용 프로그램은 SCTP를 구현합니다.
UDP를 통한 터널링
운영 체제에서 네이티브 SCTP가 지원되지 않는 경우 SCTP over [21]UDP 터널링 및 TCP API 콜을 SCTP 콜에 매핑하여 기존 응용 프로그램이 변경 없이 SCTP를 [22]변경하지 않고 사용할 수 있도록 할 수 있습니다.
RFC
- RFC 9260 스트림 제어 전송 프로토콜
- RFC 8540 스트림 제어 전송 프로토콜:RFC 4960의 에러타 및 문제(RFC 9260에 의해 폐지)
- RFC 7829 SCTP-PF: 스트림 제어 전송 프로토콜의 빠른 페일오버 알고리즘
- RFC 7765 TCP and Stream Control Transmission Protocol(SCTP) RTO 재시작
- RFC 7496 부분적으로 신뢰할 수 있는 스트림 제어 전송 프로토콜 확장을 위한 추가 정책
- RFC 7053 스트림 제어 전송 프로토콜용 SACK-IMMEDIY 확장(RFC 9260에 의해 폐지)
- RFC 6951 엔드호스트 간 통신을 위한 Stream Control Transmission Protocol(SCTP) 패킷의 UDP 캡슐화
- RFC 6525 Stream Control Transmission Protocol(SCTP) 스트림 재구성
- RFC 6458 Stream Control Transmission Protocol(SCTP)용 소켓 API 확장
- RFC 6096 Stream Control Transmission Protocol(SCTP) 청크 플래그 등록(RFC 9260에 의해 폐지됨)
- RFC 5062 Stream Control Transmission Protocol(SCTP)에 대한 보안 공격 및 현재 대책
- RFC 5061 Stream Control Transmission Protocol(SCTP) 다이내믹주소 재설정
- RFC 5043 Stream Control Transmission Protocol(SCTP) 직접 데이터 배치(DDP) 적응
- RFC 4960 스트림 제어 전송 프로토콜(RFC 9260에 의해 폐지됨)
- RFC 4895 Stream Control Transmission Protocol(SCTP) 인증 청크
- RFC 4820 Stream Control Transmission Protocol(SCTP)의 패딩 청크 및 파라미터
- RFC 4460 스트림 제어 전송 프로토콜(SCTP) 사양 오류 및 문제(RFC 9260에 의해 폐지됨)
- RFC 3873: 스트림 제어 전송 프로토콜(SCTP) 관리 정보 기반(MIB)
- RFC 3758 스트림 제어 전송 프로토콜(SCTP) 부분 신뢰성 확장
- RFC 3554 IPsec에서의 Stream Control Transmission Protocol(SCTP) 사용에 대하여
- RFC 3436 스트림 제어 전송 프로토콜을 통한 트랜스포트 계층 보안
- RFC 3309 Stream Control Transmission Protocol(SCTP) 체크섬 변경(RFC 4960에 의해 폐지)
- RFC 3286 스트림 제어 전송 프로토콜 소개
- RFC 3257 스트림 제어 전송 프로토콜 적용 가능성 선언
- RFC 2960 스트림 제어 전송 프로토콜(RFC 3309에 의해 업데이트되고 RFC 4960에 의해 폐지됨)
「 」를 참조해 주세요.
- Transport Layer » Transport Layer Protocol
- Session Initiation Protocol(SIP) – SCTP, TCP 또는 UDP를 통해 여러 스트림을 시작할 수 있습니다.
- 멀티패스 TCP – TCP 접속에서 여러 경로를 사용하여 리소스 사용률을 극대화하고 용장성을 높일 수 있습니다.
- Happy Eyeballs – 원래 [23]접속용으로 IPv4 또는 IPv6를 효율적으로 선택할 수 있도록 설계되어 있습니다.TCP나 SCTP[24] 등 다양한 전송 프로토콜에서 선택할 수도 있습니다.
메모들
레퍼런스
- ^ "Protocol Numbers". iana.org. IANA. Retrieved 2014-09-09.
- ^ Stream Control Transmission Protocol. IETF. October 2000. doi:10.17487/RFC2960. RFC 2960.
- ^ "Transport". Diameter Base Protocol. IETF. sec. 2.1. doi:10.17487/RFC3588. RFC 3588. Retrieved 2012-05-18.
- ^ "Example Scenario Using RSerPool Session Services". An Overview of Reliable Server Pooling Protocols. IETF. p. 10. sec. 4.2. doi:10.17487/RFC5351. RFC 5351.
- ^ RFC 9260, 섹션 1.5.5
- ^ Hogg, Scott. "What About Stream Control Transmission Protocol (SCTP)?". Network World. Retrieved 2017-10-04.
- ^ "Reference Implementation for SCTP - RFC4960". Retrieved 2013-10-14.
This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).
- ^ "sys/netinet/sctp.h". BSD Cross Reference. NetBSD. 2017-06-27. Retrieved 2019-01-21.
- ^ "man4/sctp.4". BSD Cross Reference. NetBSD. 2018-07-31. Retrieved 2019-01-21.
- ^ "DragonFly Removes SCTP". Lists.dragonflybsd.org. Retrieved 2016-04-28.
- ^ "About FreeBSD's Technological Advances". The FreeBSD Project. 2008-03-09. Retrieved 2008-09-13.
SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.
- ^ "Stream Control Transmission Protocol (SCTP)". Hewlett-Packard Development Company. Archived from the original on 2013-01-03.
- ^ "TCP/IP Networking". QNX Developer Support. QNX Software Systems. Retrieved 2008-09-13."What's New in this Reference". QNX Library Reference. QNX Software Systems. Retrieved 2012-12-18.
- ^ "QNX Software Development Platform 6.4.0".
- ^ "Solaris 10 Operating System Networking — Extreme Network Performance". Sun Microsystems. Retrieved 2008-09-13.
- ^ "SctpDrv: an SCTP driver for Microsoft Windows". Archived from the original on 2017-08-08. Retrieved 2022-01-04.
- ^ "SCTP Network Kernel Extension for Mac OS X". 23 September 2021.
- ^ "sctplab/usrsctp". Github. Retrieved 21 September 2021.
{{cite web}}: CS1 maint :url-status (링크) - ^ "SCTP Download Page". 2006-05-29. Retrieved 2011-02-04.
- ^ "Windows SCTP library installer". Retrieved 2011-02-04.
- ^ Tuexen, Michael; Stewart, Randall R. (May 2013). UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. IETF. doi:10.17487/RFC6951. RFC 6951.
- ^ Bickhart, Ryan; Paul D. Amer; Randall R. Stewart (2007). "Transparent TCP-to-SCTP Translation Shim Layer" (PDF). Retrieved 2008-09-13.
- ^ D. Wing; A. Yourtchenko (April 2012). "Happy Eyeballs: Success with Dual-Stack Hosts". tools.ietf.org. IETF.
- ^ Khademi, Naeem; Brunstrom, Anna; Hurtig, Per; Grinnemo, Karl-Johan (July 21, 2016). "Happy Eyeballs for Transport Selection". tools.ietf.org. IETF. Retrieved 2017-01-09.