SCTP가 많이 사용되거나 알려지지 않은 이유

최근 Richards Stevens의 "UNIX Network Programming, Vol. 1" 책을 확인했는데 TCP와 UDP 외에 SCTP 라는 세 번째 전송 계층 표준이 있음을 발견했습니다 .

요약 : SCTP는 UDP와 같은 메시지 구동 방식이지만 TCP와 같은 안정성을 갖춘 전송 수준 프로토콜입니다. 다음은 IBM DeveloperWorks 의 간략한 소개입니다 .

솔직히 전에는 SCTP에 대해 들어 본 적이 없습니다. 나는 네트워킹 책에서 읽거나 내가 수강했던 수업에서 그것에 대해 듣는 것을 기억할 수 없습니다. SCTP를 언급하는 다른 스택 오버플로 질문 을 읽으면 지식이 부족하다는 것을 혼자가 아닙니다.

SCTP가 왜 그렇게 알려지지 않았습니까? 왜 그렇게 많이 사용되지 않습니까?

실제로 SCTP는 주로 통신 분야에서 사용됩니다. 일반적으로 통신 스위치는 SS7 ( 신호 시스템 번호 7 )을 사용하여 통신 네트워크의 여러 엔티티를 상호 연결합니다. 예를 들어, 통신 사업자의 가입자 데이터베이스 (HLR)에는 스위치 (MSC)가 있고 가입자도 연결되어 있습니다 (MSC).

통신 지역은 더 빠른 속도와 더 접근하기 쉬운 환경으로 이동하고 있습니다. 이러한 변경 중 하나는 SS7 프로토콜을보다 우아하고 빠르고 유연한 IP 기반 프로토콜로 대체하는 것입니다.

통신 지역은 매우 보수적입니다. SS7 네트워크는 수십 년 동안 여기에서 사용되었습니다. 매우 안정적이고 폐쇄 된 네트워크입니다. 이는 일반 사용자가 액세스 할 수 없음을 의미합니다.

반대로 IP 네트워크는 개방적이고 신뢰할 수 없으며, SS7이 처리하는 최소한의 부하를 처리하지 않으면 통신 업체가 해당 네트워크로 변환하지 않습니다. 이것이 SCTP가 개발 된 이유입니다. 시도 :

• 수십 년 동안 축적 된 SS7 네트워크의 모든 장점을 모방했습니다.
• 속도, 보안 및 이중화에서 TCP보다 더 나은 연결 지향 프로토콜을 생성

최신 Linux 릴리스는 이미 SCTP를 지원합니다.

현재 여러 응용 프로그램에 SCTP를 배포하고 있으며 다양한 홈 라우터에서 SCTP를 지원할 때 심각한 문제가 발생했습니다. 그들은 단순히 SCTP를 올바르게 처리하지 않습니다. 나는 이것이 주로 성능 문제라고 생각합니다 (SCTP 프로토콜 사양에는 헤더뿐만 아니라 전체 패킷을 다시 계산 해야하는 체크섬이 필요합니다).

다른 많은 유망한 프로토콜과 마찬가지로 SCTP는 D-link와 Netgear가 깨진 NAT 상자를 고칠 때까지 슬프게도 물에서 죽었습니다.

SCTP를 최대한 활용하려면 응용 프로그램 내에서 더 많은 디자인이 필요합니다. TCP보다 더 많은 옵션이 있으며, 소켓과 유사한 API가 나중에 제공되었으며 더 젊습니다. 그러나 TCP를 이해하는 데 시간이 걸리고 TCP의 단점을 알고있는 대부분의 사람들은 TCP와 UDP에 대한 ~ 30 년의 지식을 바탕으로 잘 설계된 프로토콜이라고 생각합니다.

약간의 생각이 필요한 측면 중 하나는 개울입니다. 스트림은 (TCP 연결과 같은) 스트림 내에서 주문 보장을 제공하지만 (일반적으로 끌 수 있다고 생각합니다) SCTP 연결마다 여러 개의 스트림이있을 수 있습니다. 응용 프로그램의 데이터를 여러 스트림으로 전송할 수있는 경우 하나의 잘못된 패킷으로 인해 수신자가 굶주는 헤드 라인 차단을 피할 수 있습니다. 서로 다른 영향을 미치지 않으면 서 동일한 연결을 통해 효과적으로 다른 대화를 할 수 있습니다.

또 다른 유용한 추가 기능은 멀티 호밍 (multi-homing) 지원입니다. 한 연결은 양쪽 끝에있는 여러 인터페이스에 걸쳐있을 수 있으며 장애에 대처할 수 있습니다. TCP에서 그러나 응용 프로그램 계층에서이를 에뮬레이션 할 수 있습니다.

비 일시적 연결에 TCP를 사용하는 모든 응용 프로그램이 처음으로 구현하는 적절한 링크 하트 비트는 무료입니다.

SCTP에 대한 나의 개인적인 요약은 실질적인 응용 프로그램 지원으로 다른 방법으로는 (TCP 또는 UDP에서) 할 수없는 일을하지 않는다는 것입니다. 그것이 제공하는 것은 그 코드를 (나쁘게) 직접 구현할 필요가 없다는 것입니다.

참고로, SCTP는 Diameter에 대해 지원되는 것으로 의무화됩니다 (cf RADIUS next gen). RFC 3588 참조

   직경 클라이언트는 TCP 또는 SCTP를 지원해야하며 에이전트와
   서버는 반드시 두 가지를 모두 지원해야합니다. 이 사양의 향후 버전은
   클라이언트가 SCTP를 지원하도록 요구합니다.

SCTP는 다음과 같은 이유로 잘 알려져 있지 않으며 많이 사용 / 배포되지 않았습니다.

• 널리 보급 됨 : TCP / IP 스택에 광범위하게 통합되지 않음 (2013 년 : 최신 Mac OSX 및 Windows에서 여전히 기본적으로 누락 됨)
• 라이브러리 : 사용하기 쉬운 언어로 된 고수준 바인딩이 거의 없음 (면책 조항 : pysctp 관리자 , Python에 대한 SCTP 쉬운 스택 지원)
• NAT : NAT를 아주 잘 / 전혀 교차하지 않습니다 (1 % 미만의 인터넷 홈 및 엔터프라이즈 라우터는 SCTP에서 NAT를 수행함).
• 인기도 : 일반 공개 앱을 사용하지 않음
• 프로그래밍 패러다임 : 조금 바뀌 었습니다. 아직 소켓이지만 많은 호스트를 많은 호스트 (멀티 호밍)에 연결할 수 있으며 데이터 그램이 주문되고 신뢰할 수 있습니다.
• 복잡성 : SCTP 스택은 구현하기가 복잡합니다 (위로 인해)
• 경쟁 : 멀티 패스 TCP가 다가오고 멀티 호밍 요구 / 기능을 해결해야하므로 사람들은 가능하면 SCTP 구현을 자제하고 MTCP를 기다립니다
• 틈새 : SCTP 채우기 요구 사항은 매우 독특하고 (정확한 데이터 그램, 멀티 스트림) 많은 응용 프로그램에서 필요하지 않습니다.
• 보안 : SCTP는 보안 제어를 회피합니다 (일부 방화벽, 대부분의 IDSe, 모든 DLP는 CentOS / Redhat / Fedora ...를 제외하고 netstat에 나타나지 않음).
• 감사 기능 : 전 세계 3 개 회사가 SCTP 보안 감사를 정기적으로 수행합니다 (면책 조항 : 그 중 하나에서 근무 함).
• 학습 곡선 : SCTP와 함께 사용할 툴체인이 많지 않음 ( netcat과 잘 결합되거나 socat을 사용 하는 우수한 withsctp 확인 )
• 후드 아래 : 주로 통신에 사용되며 SMS를 보내거나 모바일에서 인터넷 서핑을 시작하거나 전화를 걸 때마다 SCTP (GSM / UMTS가있는 SIGTRAN / SS7, LTE / IMS가있는 직경)를 통해 메시지가 전송되는 경우가 종종 발생합니다. / RCS, LTE를 사용하는 S1AP / X2AP)) 실제로 실제로 많이 사용하지만 알지 못합니다. ;-)

p1. IPv4에 직접 매핑 된 SCTP는 NAT 게이트웨이를 지원해야합니다. NAT 게이트웨이는 어디에도 널리 배포되지 않았으며 일반적인 NAT 게이트웨이는 공용 주소 당 하나의 개인 호스트 만 한 번에 SCTP를 사용하도록 허용합니다.

p2. UDP / IPv4를 통해 매핑 된 SCTP는 퍼블릭 주소 당 더 많은 개인 호스트를 허용하지만 IPv4 / NAT 게이트웨이의 UDP 매핑은 NAT가 추적 할 수있는 명시적인 상태가없는 비 연결 전송이기 때문에 IPv4 / NAT 게이트웨이의 UDP 매핑은 유지하기가 까다로울 수 있습니다. .

p3. IPv6에 직접 매핑 된 SCTP는 다음을 필요로합니다. 음 ... IPv6. IPv6을 배포하려고 했습니까? 그렇다면 IPv6 방화벽을 구입하려고 했습니까? SCTP를 지원합니까? 로드 밸런서는 어떻습니까? SSL 가속기?

p4. 마지막으로, 많은 인터넷이 TCP 포트 80 및 포트 443을 통해 적합하게 제한되어 있으므로 어떤 풍미의 SCTP도 손실되는 경향이 있습니다. 따라서 IETF 의 MPTCP 워킹 그룹 과 같은 노력이 있습니다.

SCTP는 WebRTC 데이터 채널에서 UDP 위에 TCP와 같은 안정적인 레이어를 생성하는 데 사용되므로 UDP를 통해 SCTP를 통해 SCTP를 사용하기 때문에 곧 SCTP를 사용할 것입니다. https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # section-6

SCTP Wikipedia 페이지 읽기 주된 이유는 SCTP가 현재 주류 OS ( Windows , OS X , Linux ) 에서 지원하지 않는 아주 어린 프로토콜 (2000 년에 제안 된 프로토콜)이기 때문입니다 .

"매우 젊음"이 당신에게 부적절 해 보인다면, IPV6 에 대해 생각해보십시오 . "2008 년 12 월, 표준 트랙 프로토콜로 10 주년을 맞았지만 IPv6은 전 세계적으로 일반적인 배치 측면에서 초기 단계였습니다."

SCTP는 Diameter가 AAA에 사용되는 4G LTE 네트워크에서 광범위하게 사용됩니다.

잘 알려지지 않았지만 사용되지는 않습니다. 최근 에 IETF 에서 HTTP 용 전송 계층 프로토콜로 SCTP 사용 에 관한 초안이 발표되었습니다 .

상용 라우터가 손상되었거나 SCTP 지원이 부족하다는 모든 의견과 관련하여 문제는 NAT를 사용하는 SCTP가 여전히 IETF의 초안 형식이라는 것입니다. 따라서 구현할 RFC 사양은 없습니다.

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctp는 너무 늦게 태어 났으며 많은 경우 TCP로 충분합니다.

또한 대부분의 사용법은 통신 분야에서 사용됩니다.