답변:
TLDR : TCP 위에서 여러 채널을 멀티플렉싱 할 때 눈에 띄는 주요 단점 은 채널 간 헤드 라인 차단으로 인해 대기 시간 이 늘어난 것 입니다.
결론 : 대기 시간에 신경 쓰지 않는다면 괜찮을 것입니다.
반면에 단일 TCP 연결을 사용하면 "다른 흐름 및 수명이 긴 연결과의 경쟁이 줄어들어 가용 네트워크 용량의 활용도가 향상됩니다" .
동일한 TCP 스트림 위에서 여러 채널을 멀티플렉싱 할 경우 채널에 헤드 라인 차단 이 발생할 수 있습니다 .
전송 프로토콜이 주문 또는 부분 순서 서비스를 제공 할 때 HOL (Head-of-Line Blocking)이 발생할 수 있습니다. 세그먼트가 손실되면 후속 메시지가 수신자 큐에서 재전송이 성공하기를 기다려야하므로 지연됩니다.
TCP 위에서 여러 스트림을 멀티플렉싱 하면 채널간에 HOL이 발생합니다 .
채널 A가 TCP 전송 버퍼를 채운 경우, 채널 B의 새 데이터를 원격 응용 프로그램 계층으로 효과적으로 전송할 수 있으려면이 모든 데이터가 수신되기 전에 기다려야합니다.
참조 "TCP 위에 멀티플렉싱" TCP의 상단과에 채널을 다중화에 대한 자세한 내용은 hackernews에 대한 토론 .
이것의 전형적인 예는 SSH입니다. SSH는 여러 채널을 (참조 다중화 수 ControlMaster, ControlPath및 ControlPersistOpenSSH의에서). 이를 사용하면 새 SSH 세션 (초기 대기 시간)을 초기화하는 비용은 줄어 들지만 한 채널을 많이 전송하면 일반적으로 다른 채널의 대기 시간 / 상호 작용이 증가합니다 (여러 TCP 스트림을 사용하는 경우에는 발생하지 않음) : 대화식을 사용하는 경우 같은 채널을 통해 많은 양의 파일 전송을 심사하기 시작하면 세션이 훨씬 덜 대화식으로 시작됩니다.
HTTP / 2는 HOL 차단을 수정하기 위해 TCP를 통한 요청 / 응답의 다중화를 사용합니다. 이 기능은 HTTP / 2에 대한 많은 기사와 논문에서 광고됩니다. HTTP / 2 RFC의 주장 :
HTTP / 1.1은 요청 파이프 라이닝을 추가했지만, 이것은 부분적으로 요청 동시성만을 다루고 여전히 헤드 라인 차단으로 고통 받고 있습니다.
[...]
결과 프로토콜은 HTTP / 1.x와 비교하여 더 적은 TCP 연결을 사용할 수 있기 때문에 네트워크에 더 친숙합니다. 이는 다른 흐름 및 오래 지속되는 연결과의 경쟁이 줄어들어 가용 네트워크 용량의 활용도가 향상됩니다.
그러나 논의되지 않은 것은 HOL 차단이 완전히 해결되지 않는다는 것입니다. HTTP / 2 TCP 여전히 이상 영속한다 )에서 TCP 레벨 HOL 차단 .
이 LWN 기사에서 QUIC에 대해 설명합니다 .
HTTP / 2는 단일 연결에 내장 된 여러 "스트림"을 사용하여이 문제를 해결하도록 설계되었습니다 . [...] 새로운 문제를 만듭니다 : 단일 패킷의 손실로 모든 스트림의 전송이 한 번에 중단되어 새로운 대기 시간 문제가 발생합니다. HOL (head-of-line-blocking) 문제의이 변형은 TCP 자체에 내장되어 있으며 HTTP 수준에서 더 많은 조정으로 수정할 수 없습니다.
이것이 SCTP (멀티 스트리밍)의 특징 중 하나이며 동일한 SCTP 연관에서 여러 개의 독립적 인 스트림을 가질 수 있으며 각 스트림은 다른 스트림을 차단하지 않습니다.
SSH 에서 교차 채널 HOL 차단을 피하기 위해 SCTP를 사용하는 효과에 대해서는 SCTP 를 통한 SSH — 다중 채널 프로토콜을 SCTP에 적용하여 다중 채널 프로토콜 최적화를 참조하십시오 .
SCTP는 헤드 라인 차단이라는 알려진 효과를 완화하기 위해 단일 스트림 내의 메시지 순서 만 유지합니다. 메시지가 유실되면, 순서를 유지하기 위해 유실 된 메시지가 재전송 될 때까지 후속 메시지가 지연되어야합니다. 동일한 스트림의 메시지 만 지연되어야하므로 손실 후 영향을받는 메시지의 수가 줄어 듭니다.
[...]
SSH의 채널을 SCTP의 스트림에 매핑함으로써 다중 스트리밍의 이점 을 헤드 라인 차단 의 완화 인 SSH에 사용할 수 있습니다 .
SCTP는 OS 가용성, 미들 박스 상호 작용 등으로 인해 배포하기가 쉽지 않습니다. userspace에서 UDP 를 통해 구현할 수 있습니다.
또 다른 예는 HTTP / 2가 HTTP 를 멀티플렉싱하는 데 사용되는 실험적인 QUIC 프로토콜입니다 ( HTTP / 2는 HOL 차단을 겪기 때문에 TCP 위에 여러 스트림을 멀티플렉싱 하기 때문입니다 ).
QUIC는 TCP와 비교하여 대기 시간 을 줄이는 새로운 전송입니다 . 표면적으로 QUIC는 UDP에 구현 된 TCP + TLS + HTTP / 2와 매우 유사합니다.
[...]
헤드 라인 차단없는 멀티플렉싱
Google의 QUIC 프로토콜 : TCP에서 UDP로 웹을 이동하면 TCP 위에 채널을 멀티플렉싱 할 때 QUIC 및 HOL 차단에 대한 좋은 개요가 나타납니다.
최근 발표에 따르면 QUIC를 통한 HTTP 는 대기 시간은 향상되지만 HOL 차단 개선은 "더 작은 이점"이라고합니다.
0-RTT, 대기 시간 개선의 50 % 이상
[…]
타임 아웃 기반 재전송 횟수 감소 테일 레이턴시 개선 […]
기타 작은 혜택, 예 : 헤드 오브 블로킹
QUIC는“UDP에서 구현 된 TCP + TLS + HTTP / 2와 매우 유사하다”고 설명되어 있지만 실제로 는 HTTP / 2와 독립적으로 사용할 수 있으며 사용자의 요구에 적합 할 수있는 범용 전송 입니다.
참고 : HTTP / QUIC si는 HTTP / 3 으로 표준화됩니다 .
ZeroMQ Guide 를 읽어야한다고 말하고 싶습니다 . 이유와 단점이있는 패턴은 필수 독서입니다.
그러나 그렇지 않으면 응용 프로그램 데이터 전송에서 네트워크 채널 연결을 끊는 데 아무런 문제가 없습니다. 전송 된 데이터 패킷의 멀티플렉싱 및 디 먹싱 (및 연속 흐름으로 데이터를 스트리밍하지 않고 여기에서 패킷 기반 아키텍처를 권장 함) 및 각 끝에 버퍼링을 수행해야합니다.
그렇지 않으면 영향이 거의 없으며 데이터를 버퍼링하기 위해 더 많은 메모리가 필요하지만 약간만 필요하며 패킷을 잠그고 구문 분석하기 위해 더 많은 코드를 처리 할 때 CPU가 조금 더 필요하지만 별다른 의미는 없습니다. 처리량이 많고 성능이 필요한 전문가를 작성하지 않는 한 중요합니다.
예,이 원칙을 정확하게 사용하여 클라이언트-서버 데이터베이스 시스템을 구축했습니다.
하나의 TCP 연결로 멀티플렉싱 된 채널은 각각 데이터 패킷을 전송 한 다음 다른 쪽 끝에서 해당 수신자에게 분할됩니다.
데이터를 전송할 준비가 된 채널 중에서 전송할 패킷을 라운드 로빈 선택하여 TCP 연결 발신자가 하나의 끔찍한 채널에 의한 연결 호깅을 수행합니다.
한 채널이 1GB 패킷을 전송하기로 결정하고 다른 모든 사람을 잠그는 경우를 처리하기 위해, 발신자는 패킷을 청크로 분할하고 다른 채널을 돌리기 전에 한 청크 만 전송하도록 선택할 수 있습니다. 수신단에서 수신자가 패킷을보기 전에 청크를 패킷으로 재 조립한다.