뭐라고요?
RTCQuicTransport는 새로운 웹 플랫폼입니다. QUIC를 사용하여 원격 피어와 임의의 데이터를 교환할 수 있는 API입니다. 사용할 수 있습니다 P2P 사용 사례를 위한 것이기 때문에 독립형 RTCIceTransport P2P 연결을 설정하는 API ICE. 데이터는 안정적이고 순서대로 전송됩니다 (아래 섹션 참고). 비주문 및 신뢰할 수 없는 게재). 일반적이기 때문에 양방향 데이터 전송으로 게임, 파일 전송, 미디어 전송, 메시징 등입니다.
왜냐하면
강력한 하위 수준 데이터 전송 API는 애플리케이션 (예: 실시간 웹에서 새로운 것을 할 수 있도록 돕는 것입니다. API를 기반으로 빌드할 수 있습니다. 동료들과 함께 할 수 있는 일의 한계를 뛰어넘는 예를 들어 맞춤 비트 전송률 할당 노브를 잠금 해제하는 것이 좋습니다. 포함 인코딩된 미디어가 추가로 지원되면 동영상 커뮤니케이션 애플리케이션을 실행할 수 있습니다. WebRTC의 NV 노력 낮은 수준의 API로 전환하는 것이며, 이를 초기에 실험하는 것은 가치가 있습니다.
QUIC를 사용해야 하는 이유
QUIC 프로토콜은 실시간 통신에 적합합니다. Kubernetes는
암호화, 혼잡 제어 기능이 내장되어 있고 외부 IP 주소 없이도
헤드라인 차단 기능이 있습니다. RTCQuicTransport
는
RTCDataChannel
API를 사용하지만 전송으로 SCTP가 아닌 QUIC를 사용합니다.
사용할 수 있습니다 RTCQuicTransport
는 독립형 API이므로
실시간 미디어가 포함된 RTCPeerConnection
API의 오버헤드
있습니다
방법
일반 API 개요
API에는 3가지 주요 추상화(RTCIceTransport
, RTCQuicTransport
)가 있습니다.
및 RTCQuicStream
RTCIceTransport
ICE는 인터넷을 통해 P2P 연결을 설정하는 프로토콜이며
오늘날 WebRTC에서 사용됩니다. 이 객체는
ICE 연결입니다. QUIC 연결을 위한 패킷 전송으로 사용되며
RTCQuicTransport
가 생성자에서 이를 가져옵니다.
RTCQuicTransport
QUIC 연결을 나타냅니다. QUIC 연결을 설정하고 QUIC 스트림 만들기 또한 QUIC 연결과 관련된 통계를 표시합니다. 있습니다.
RTCQuicStream
원격 측에서 데이터를 읽고 쓰는 데 사용됩니다. 스트림 전송
데이터를 안정적으로
저장할 수 있습니다 한 채널에서 여러 스트림을 만들 수 있습니다.
RTCQuicTransport
를 포함하고 데이터가 스트림에 쓰면
‘onquicstream’ 이벤트를 지원합니다. 스트림을 사용하면
동일한 QUIC 연결에서 서로 다른 데이터를 구별할 수 있습니다. 일반적인 예는
별도의 스트림, 즉 작은 데이터 청크를 여러 다른 스트림으로
여러 스트림 또는 개별 스트림에 있는 다른 유형의 미디어를 예로 들 수 있습니다.
RTCQuicStream
는 가볍고 QUIC 연결을 통해 다중화됩니다.
다른 RTCQuicStream
에 대한 대기 행렬 막힘을 유발하지 않습니다.
연결 설정
다음은 P2P QUIC 연결을 설정하는 예시입니다.
RTCPeerConnection
와 마찬가지로 RTCQuicTransport
API에는
연결 매개변수를 협상하기 위해
모든 리소스 및 서비스를 포함합니다 RTCIceTransport
에서 ICE 협상
매개변수 (ufrag 및 비밀번호)와 RTCIceCandidate
를 포함합니다.
고객 관점:
const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
iceParams: iceTransport.getLocalParameters(),
quicKey: quicTransport.getKey(),
});
iceTransport.onicecandidate = e => {
if (e.candidate) {
signalingChannel.send({candidate: e.candidate});
}
};
// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, candidate}) => {
if (iceParams) {
iceTransport.start(iceParams);
quicTransport.connect();
} else if (candidate) {
iceTransport.addRemoteCandidate(candidate);
}
};
서버 관점:
const iceTransport = new RTCIceTransport();
const quicTransport = new RTCQuicTransport(iceTransport);
// Signal parameters, key and candidates.
signalingChannel.send({
iceParams: iceTransport.getLocalParameters(),
});
iceTransport.onicecandidate = e => {
if (e.candidate) {
signalingChannel.send({candidate: e.candidate});
}
};
// When remote parameters are signaled, start connection.
signalingChannel.onMessage = async ({iceParams, quicKey, candidate}) => {
if (iceParams && quicKey) {
iceTransport.start(iceParams);
quicTransport.listen(quicKey);
} else if (candidate) {
iceTransport.addRemoteCandidate(candidate);
}
};
데이터 전송
데이터 전송은 RTCQuicStream API를 사용하여 쓰기:
RTCQuicStreamReadResult readInto(Uint8Array data);
void write(RTCQuicStreamWriteParameters data);
Promise<void> waitForWriteBufferedAmountBelow(unsigned long amount);
Promise<void> waitForReadable(unsigned long amount);
버퍼링
waitFor*
메서드가 반환하는 프로미스는 다음과 같은 경우 버퍼링 데이터를 허용합니다.
JavaScript를 사용 중입니다. 인코더-디코더는 출력을 수신 대기할 때
읽기 버퍼가 수신 측에서 가득 차게 됩니다. 전송 측에 쓰기가 있음
버퍼가 채워져 있어야 하므로
쓰기 측에는 waitForWriteBufferedAmountBelow
메서드도 있습니다.
버퍼가 쓸 수 있는 공간을 기다립니다. 추가 정보:
데이터 쓰기/읽기는 해당 개발자에게
문서를 참조하세요.
주문되지 않음/신뢰할 수 없는 배송
RTCQuicStream
는 안정적이고 순서대로 데이터 전송을 지원하지만
다른 방법을 통해 신뢰할 수 없거나 정렬되지 않은 게재를 달성할 수 있습니다. 대상
순서가 지정되지 않은 전송에서는 작은 데이터 청크를 별도의 스트림으로 전송할 수 있습니다.
스트림 간에 데이터가 정렬되지 않기 때문입니다. 신뢰할 수 없는 제공의 경우
완료를 true로 설정하여 작은 데이터 청크를 전송하고
제한 시간이 지나면 스트림의 reset()
입니다. 제한 시간은
데이터를 삭제하기 전에 얼마나 많은 재전송을 원하는지 결정합니다.
시기
오리진 트라이얼은 Chrome 73 버전에서 시작되며 사용할 수 있습니다. M75 버전 이하입니다 이후에는 오리진 트라이얼이 있습니다. 의견과 관심에 따라 적절하게 변경합니다. API를 제공하거나 이 API의 새로운 오리진 트라이얼을 계속 사용할 수 있습니다. API를 중단할 수 있습니다
위반 위치
iOS를 제외한 모든 플랫폼의 Chrome 브라우저
안 되는 사람이랄까?
의견
오리진 트라이얼의 주요 목표 중 하나는 도움이 될 수 있습니다 관심 있는 주제는 다음과 같습니다.
- 이 API를 사용하면 무엇을 할 수 있나요?
- 이 API가 다른 데이터 전송 API보다 어떻게 개선되나요?
(
WebSocket
또는 WebRTC의RTCDataChannel
)? 어떻게 하면 개선할 수 있을까요? - 성능
- API 에르고노믹스
오리진 트라이얼 등록
- 원본에 대한 토큰을 요청합니다.
- 페이지에 토큰을 추가합니다. 이 토큰을 제공하는 방법에는 두 가지가 있습니다.
원본의 모든 페이지:
<ph type="x-smartling-placeholder">
- </ph>
- 페이지 헤드에
origin-trial
<meta>
태그를 추가합니다. 예를 들어 다음과 같을 수 있습니다.<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
- 서버를 구성할 수 있는 경우 페이지에 토큰을 제공할 수도 있습니다.
Origin-Trial
HTTP 헤더 사용 결과 응답 헤더는 다음과 같이 표시됩니다.Origin-Trial: TOKEN_GOES_HERE
- 페이지 헤드에
웹 사양
초안 사양이 오리진 트라이얼에서 API보다 먼저 이전되었습니다. 포함:
- WhatWG 스트림과 더욱 밀접하게 관련된 단방향 스트림
- 재전송 사용 중지
- (제공 예정) 데이터그램
Google은 다음을 포함하여 전체 사양 및 그 이상을 구현하는 데 관심이 있습니다. WhatWG 스트림 지원에 문의하실 수 있으나 먼저 의견을 듣고 싶습니다.
보안
QUIC 핸드셰이크의 보안은 암호화된 P2P QUIC 연결을 설정합니다. 이 키는 기밀성과 무결성을 보장하는 안전한 대역 외 채널 키는 JavaScript에 노출됩니다.
활발한 공격
인증서 신호를 보내기 위한 무결성만 필요한 DTLS-SRTP와는 달리 사전 공유 키에 신호를 보낼 때 무결성 및 기밀유지 협약을 맺습니다 PSK가 손상된 경우 (예: 활성 공격자가 잠재적으로 중간자 공격을 QUIC 핸드셰이크에 대항합니다.
현재 상태
단계 | 상태 |
---|---|
1. 설명 만들기 | 완전함 |
**2a. RTCQuicTransport 사양 ** | **진행 중** |
**2b. RTCIceTransport 사양 ** | **진행 중** |
**3. 의견 수집 및 디자인 반복** | **진행 중** |
4. 오리진 트라이얼 | Chrome 73에서 시작됩니다. |
5. 출시 | 시작되지 않음 |
유용한 링크
- 추가 문서
- 공개 설명
- 버그 추적
- 오리진 트라이얼 토큰 요청
- 오리진 트라이얼 토큰 사용 방법
- RTCQuicTransport 문제에 대한 논의
- RTCIceTransport 문제에 대한 토론