libp2p의 웹트랜스포트(WebTransport)

libp2p가 브라우저 연결을 달성하는 방법에 대한 일련의 게시물 중 첫 번째 항목이다.

목차

• 개요
• 웹트랜스포트란
• 웹소켓(WebSocket): 기존 솔루션과 그 과제
• 웹트랜스포트를 만나보십시오
  • 심층 분석: 웹트랜스포트 작동 방식
  • 제한 사항
• 웹트랜스포트의 현재 상태와 지원 현황
  • 사양 상태
  • IETF 사양
  • libp2p 사양
  • 브라우저에서 웹트랜스포트 상태
  • libp2p 구현에서 웹트랜스포트 상태
  • libp2p의 남은 작업
• 현재 사용 가능성
  • 이를 통해 볼 수 있는 어플리케이션 및 사용 사례
• 리소스 및 이바지하는 방법

개요

원활한 브라우저 연결은 libp2p 프로젝트의 중요한 목표이다. 수년 동안 libp2p는 그 비전을 실현하기 위해 많은 발전을 이루었다. 오늘 우리는 그 목표에 훨씬 더 가까워지는 중요한 이정표를 발표하게 된 것을 자랑스럽게 생각한다.

libp2p는 이제 새로운 최첨단 웹트랜스포트 프로토콜을 지원한다.

이 문서에서 다룰 내용은:

• 웹트랜스포트 소개
• 앱에서의 의미와 사용 방법
• 기존 솔루션을 통한 장점 설명
• 작동 방식에 대한 심층 분석
• 웹트랜스포트의 현재 상태 설명(사양 및 구현)

웹트랜스포트란?

높은 수준에서 현재 IETF(인터넷 엔지니어링 대책 위원회)와 W3C(WWW 컨소시엄)이 개발중인 웹트랜스포트는 트랜스포트 프로토콜 및 웹 API이다.

웹트랜스포트는 다음과 같은 목표를 달성하기 위해 개발 중이다.

• 브라우저와 서버 사이의 소통 지연율을 낮춘다(효과적으로 데이터를 이전하고 브라우저와 서버 간의 이동시간 감소).
• 다양한 프로토콜과 사용 사례를 지원하는 API 준비(예: 신용 가능한/불가능한 및 순서가 지정된/지정되지 않은 데이터 이전, 클라이언트-서버 및 P2P 아키텍처, 오디오/비디오 미디어 및 일반 데이터 이전)
• 현재 솔루션과 같은 보안 속성(예: 전송 계층 보안을 통한 웹소켓)

이러한 목표를 염두에 두고 웹트랜스포트는 브라우저 게임, 라이브 스트리밍, 멀티미디어 어플리케이션 등을 포함한 다양한 사용 사례를 해결하려고 한다. 이러한 어플리케이션은 데이터 송수신이 가능한 한 빨라야 하므로 대기 시간이 짧아야 한다. 또한, 화상 회의 및 스트리밍 어플리케이션은 전송된 데이터를 신뢰할 수 없고 순서가 맞지 않게 처리할 가능성이 있다. 사용 사례에 더 효율적이기 때문에 선호된다.

웹트랜스포트는 이러한 목표를 충족하고 웹에서 데이터를 빠르게 전송할 수 있다.

웹소켓: 기존 솔루션과 그 과제

더 깊이 들어가기 전에 libp2p에서 브라우저 연결 기록을 살펴보려고 한다. 다음과 같은 질문들이 있다: 웹트랜스포트가 등장하기 이전에 libp2p 브라우저 노드가 서버 노드에 어떻게 연결되었으며 브라우저를 libp2p 에코시스템에 연결할 때 어떤 문제가 있었을까?

브라우저는 TCP 연결(HTTP 1.1용 및 HTTP/2) 및 QUIC 연결(HTTP/3용)에 항상 접속한다. 하지만 TCP 또는 QUIC 연결에 접속해 HTTP 이외의 용도로 사용할 방법은 없다.

이로 인해 브라우저 응용 프로그램을 libp2p와 통합할 때 문제가 발생했다. libp2p는 양방향 비동기 스트림 추상화 위에 구축되는 반면 HTTP는 상태 비저장 단방향 동기식 요청-응답 프로토콜이다. HTTP에서 클라이언트는 서버에 요청을 보내고 응답을 기다린다. 상태는 저장되지 않으며 HTTP API는 즉각적인 요청만 신경을 쓴다. libp2p에서 상호 작용은 이벤트 기반이며 비동기식이다. 통신은 응답을 기다리지 않고 양방향으로 발생한다. 전송 중에 이벤트의 컨텍스트를 유지하기 위해 상태가 유지된다.

따라서 가장 오랫동안 브라우저에서 실행 중인 libp2p 클라이언트를 네트워크의 나머지 부분에 연결하는 유일한 방법은 다소 오래된 웹소켓 프로토콜을 사용하는 것이었다.

웹소켓은 먼저 서버에 HTTP 연결(가장 일반적으로 HTTP 1.1)을 설정한 다음 단일 HTTP 요청을 수행하여 연결을 양방향 바이트 스트림으로 '업그레이드'하는 방식으로 작동한다. libp2p에서는 이를 통해 웹소켓 연결을 원시 TCP 연결로 취급할 수 있다.
해당 연결에서 libp2p 핸드셰이크(컴퓨터가 다른 컴퓨터 또는 디바이스에 연결하는 과정)를 실행하고 다음 중 하나(yamux 또는 mplex)를 스트림 멀티플렉서(다중 통신용 장치)로 적용한다. 추가된 단계는 HOL 블로킹(네트워킹에서 성능 제한 현상의 일종)이라는 문제에 취약하므로 필요하다. 프로토콜은 기본적으로 다중화를 지원하지 않으므로 메시지가 서로 독립적인 경우에도 하나의 메시지가 전송된 다른 메시지를 차단할 수 있다.

여기에는 여러 단점이 있다.

• 느린 연결 시간
  • 웹소켓 연결 설정과 관련된 단계로 인해 libp2p 연결이 최종적으로 설정될 때까지 6번의 네트워크 왕복이 필요하다.
• 비효율
  • 데이터를 이중 암호화하고 있다. 처음에 외부(HTTPS) 연결에서 암호화한 후에 libp2p 보안 프로토콜에 의해 다시 암호화된다.
• 대기 시간 증가
  • 웹소켓에는 기본 스트림 다중화가 없으며 자체 멀티플렉서를 추가한 후에도 각 내부 스트림은 여전히 HOL 블로킹 문제를 겪을 수 있다.

결과적으로 웹소켓이 빠르고 우수할 것이라고 예상할 수 없었다. 웹소켓이 브라우저에 유일한 연결 옵션이라는 점을 고려할 때 성능 페널티를 받을 수밖에 없었다.

실제로 웹소켓이 libp2p에서 널리 배포되는 것을 방해하는 또 다른 장애물이 있다. 브라우저가 웹사이트에 연결할 때 실제로 모든 사례에서 HTTPS를 통해 접속한다. HTTPS는(HTTP가 아닌) HTTPS를 통한 웹소켓의 멋진 이름인 시큐어 웹소켓(Secure WebSocket)의 사용을 강제한다. 이는 서버에 유효한 TLS 인증서 즉, 인증 기관에서 서명한 Let's Encrypt와 같은 인증서가 필요하다는 것을 의미한다.

그러나 대부분의 libp2p 노드에는 이러한 인증서가 없다. libp2p 노드가 분산형 p2p 네트워크를 구성함에 기인한다. 이 네트워크에서는 참여자가 집의 랩탑 혹은 브라우저에서 노드를 실행하고 마음대로 네트워크에 참가하거나 떠날 수 있다. 대부분의 노드는 도메인 이름도 없으므로 여러 인증 기관의 인증서가 필요하다. TLS 인증서를 얻기 어렵지는 않지만, 분산형 방식의 자동 수행은 쉬운 일이 아니다.

P2P 설정에서 사용하기 어렵고 성능 저하 탓에 웹소켓은 항상 libp2p 스택에서 비주류 전송 프로토콜이었다.

웹트랜스포트를 만나보십시오

웹트랜스포트는 웹소켓을 사용할 때 발생하는 거의 모든 문제점을 해결한다.

개념적으로 웹소켓이 유선상의 새로운 프로토콜임에도 웹트랜스포트와 유사하다. 브라우저는 HTTP/2 또는 HTTP/3 연결을 웹트랜스포트 세션으로 '업그레이드' 할 수 있다.
HTTP/3는 QUIC 위에서 실행된다. HTTP/3을 통한 웹트랜스포트 세션을 사용하면 두 엔드포인트가 서로에 대해 QUIC 스트림을 열 수 있다(매우 얇게 감싸고 있음). 이를 통해 웹트랜스포트는 QUIC가 제공한 것을 활용할 수 있으며 결과는 다음과 같다.

• 빠른 핸드셰이크를 사용하여 빠르게 연결할 수 있다(단 한 번의 네트워크 왕복).
• HOL 블로킹 없는 기본 스트림 다중화
• 고급 손실 복구 및 혼잡 제어
• 대기 시간이 짧은 통신 및 순서가 지정되지 않고 신뢰할 수 없는 데이터 전달

참고사항: HTTP를 사용하는 웹트랜스포트는 QUIC를 사용할 수 없는 경우 TCP 전송 기능을 제공한다.

새로운 검증 옵션을 도입하는 것은 P2P 사용 사례에 가장 큰 변화이다. QUIC 위에 계층화되어 있는 웹트랜스포트는 항상 (TLS)암호화 연결이 필요하다. 웹트랜스포트 브라우저 API는 두 가지 고유한 모드를 허용한다.

1. TLS 인증서 체인 확인

• 브라우저가 연결하는 모든 웹사이트의 인증서를 확인할 때 하는 일이다. 이는 서버가 인증 기관이 서명한 인증서를 가져야 하는 것을 의미한다.

2. TLS 인증서 해시(hash) 확인

• 이 옵션은 서버에 자체 서명된 인증서만 있는 단기 가상 머신 배포를 위한 것이다. 핸드셰이크 중에 사용된 인증서의 해시와 일치하면 브라우저는 서버를 신뢰한다.

옵션 (1)에는 웹소켓에서 발생한 것과 정확히 같은 문제가 있다.

옵션 (2)를 사용하면 수동 구성없이 모든 libp2p 노드에서 웹트랜스포트를 사용할 수 있다.

웹트랜스포트 서버를 설정할 때 libp2p 노드는 자체 서명된 TLS 인증서를 생성하고 인증서 해시를 계산하므로 작동할 수 있다. 그 후 다음과 같은 다중주소를 네트워크에 알린다.

/ip4/1.2.3.4/udp/4001/quic/webtransport/certhash/<hash>

여기서 certhash 요소는 브라우저에 인증서 해시를 알려주고 성공적으로 웹트랜스포트 연결을 설정할 수 있도록 한다.

실제로 여러 인증서 해시를 포함한 주소를 볼 수 있다.

/ip4/1.2.3.4/udp/4001/quic/webtransport/certhash/<hash1>/certhash/<hash2>

위에서 설명한 것처럼 옵션 (2)는 단기 배포용이며 브라우저는 14일 미만의 유효한 인증서만 수락한다. 두 개의 인증서를 생성하여 이 제약 조건을 해결한다. 하나는 즉시 사용할 수 있고 다른 하나는 첫 번째 인증서가 만료할 때부터 유효하다. 14일 후 서버는 인증서를 전달하고 새 인증서 해시가 포함된 업데이트된 주소를 네트워크에 알릴 수 있다.

심층 분석: 웹트랜스포트 작동 방식

세부 사항을 살펴보려 한다. 웹트랜스포트를 이용하고 싶다면 필요없는 부분이므로 건너뛰어도 좋다.

▲ 웹 트랜스포트 작동 방식

1. 브라우저가 서버에 대한 일반 HTTP/3 연결에 접속하여 신뢰 체인이나 인증서 해시로 인증서를 확인한다.

2. 브라우저는 웹트랜스포트 세션 설정을 요청하는 Extended CONNECT 요청을 HTTP/3 스트림에 보낸다. 서버가 200이라는 HTTP 상태를 보내면 웹트랜스포트 세션 설정은 성공적이다.

양쪽 모두 이제 스트림(양방향 및 단방향 모두)을 개방하고 (신뢰할 수 없는)HTTP 데이터그램을 전송할 수 있다.

참고사항: 신뢰할 수 없는 데이터그램은 QUIC가 기반인 UDP 속성이다. 이러한 불안정하고 비순차적인 전달 방법은 UDP, QUIC 및 웹트랜스포트를 낮은 지연율과 속도가 가장 중요한 비디오 스트리밍 또는 브라우저 게임과 같은 어플리케이션에 완벽히 적합하게 만든다.

libp2p에서는 libp2p 사용자 ID를 확인해야 하기 때문에 아직 완전히 끝난 것이 아니다.

이를 위해서는 브라우저는 새로운 웹트랜스포트를 열고 노이즈(Noise) 핸드셰이크를 시작한다. 이는 libp2p에서 TCP 위의 연결을 확보하려 사용한 핸드셰이크와 같다. 이 핸드셰이크에서 외부 연결을 바인딩하여 중간자(MITM) 공격의 희생양이 되지 않았는지 확인할 수 있다.

따라서 libp2p에서 웹트랜스포트 연결을 설정하는 데 네트워크 왕복이 3번 이상 걸리지 않는다. 웹소켓에 필요한 6번의 왕복을 생각해보십시오.

앞으로 왕복을 2번으로 줄일 수도 있다. 원칙적으로 CONNECT 요청과 노이즈 핸드셰이크를 병렬로 실행할 수 있어야 한다. 현재 브라우저 API는 이를 허용하지 않지만, 이 기능을 활성화하기 위해 제안서를 제출했다.

제한 사항

지금까지 브라우저과 서버 사이의 연결성과 그에 대한 웹트랜스포트와 웹소켓의 역할에 대해 논의했다. 아직 사용자 간의 연결성 및 브라우저 간의 연결성 그리고 또 다른 주요 전송 방법인 웹RTC에 대해 논의하지 않았다.

웹트랜스포트가 지원하지 않는 브라우저 간의 연결에 대한 부분을 웹RTC가 해결한다. 이 요구를 충족하기 위해 libp2p 구현은 웹RTC 브라우저-서버 연결(러스트-libp2p에서 지원) 및 브라우저 간의 연결(곧 제공 예정)에 대한 지원을 추가하는 과정에 있다. 이 면에서 진전을 이루면서 더 많은 것을 공유할 계획이다.

웹트랜스포트의 현재 상태와 지원 현황

사양 상태

IETF 사양

위에서 설명한 것처럼 웹트랜스포트는 새롭고 최첨단이다.

프로토콜 자체의 IETF 사양은 계속 수정되는 초기 단계에 있다(HTTP/3 및 HTTP/2를 통한 웹트랜스포트도 마찬가지이다). 아마도 몇 달 동안 지속할 것이라 생각되므로 따라서 프로토콜의 최종 버전이 어떤 모습일지 아직 알 수 없다.

libp2p 사양

여기 libp2p가 웹트랜스포트를 사용하는 방법에 대한 산문 사양이 있다: libp2p 웹트랜스포트 사양. 주소 체계, 인증서 사용, HTTP 엔트포인트 및 보안 핸드셰이크를 더 자세히 설명한다. 다른 libp2p 언어 구현은 이 사양에 따라 웹트랜스포트 구현을 작성한다.

libp2p는 HTTP/3 변종만 지정한다는 점에 유의해야 한다.

브라우저의 웹트랜스포트 상태

현재 웹트랜스포트 지원은 프로토콜 및 웹 API가 다른 곳에서 지원되지 않는 관계로 크로미움 브라우저(크롬97에서 제공되는)로 제한된다. 자세한 내용은 사용할 수 있을까? 페이지를 참조하십시오.

QUIC를 libp2p에 통합한 경험으로 볼 때 브라우저 공급업체는 웹트랜스포트의 여러 초안 버전을 동시에 지원하지 않을 것이다. 대신 새 버전에 대한 지원을 배포하는 즉시 이전 버전에 대한 지원을 중단한다.

libp2p 구현의 웹트랜스포트 상태

웹트랜스포트는 두 가지 libp2p 구현에서 실험적 기능으로 지원된다.

• v.0.23.0 기준 고-libp2p
• js-lilbp2p-웹트랜스포트 npm 패키지를 통한 js-libp2p

게다가 당연히 이 두 가지 구현은 서로 상호 운용이 가능하다. 다음은 libp2p Day에서 알렉스 팟사이드(Alex Potsides)(프로토콜 랩스의 소프트웨어 엔지니어 및 js-libp2p 관리자)의 데모이다. 알렉스는 쿠보(go-ipfs)에서 파일을 직접 가져오기 위해 브라우저를 사용하여 웹트랜스포트 시연을 보여줬다.

추가로 가까운 시일 내에 러스트-libp2p는 웹트랜스포트에 대한 지원을 추가할 예정이다.

libp2p의 남은 작업

게시 당시 최신 go-libp2p 버전은 v0.24.0 이었으며 웹트랜스포트는 아직 기본 전송방식이 아니었다. 이를 가능하게 하는 작업이 여기에서 수행되고 있다.

언급했듯이 IETF 사양은 여전히 초기 단계에 머물러 있다. 브라우저가 최신 버전의 초안을 채택할 때 libp2p는 그에 상응하여 버전 채택을 해야 한다. 두 버전 간의 변경 범위에 따라 libp2p 구현은 브라우저와 같은 접근 방식을 취한다. 이전 초안 버전에서 웹트랜스포트 구현에 대한 지원을 중단한다.

참고사항: 그 결과 libp2p 노드와 브라우저가 새 버전으로 업그레이드되면서 일시적으로 웹트랜스포트 버전 간에 불일치가 발생하여 연결 시도에 실패할 수 있다.

마지막으로 이 기능은 IETF 초안이 더는 아니게 될 때 실험단계에서 촉진되어야 한다.

현재 사용 가능성

당연히 가능하다. 위에서 설명한 것처럼 웹트랜스포트는 이미 go-libp2p 및 js-libp2p로 구동되는 어플리케이션에서 브라우저와 서버 간에 작동한다.

이를 통해 볼 수 있는 어플리케이션 및 사용 사례

많은 사용 사례를 볼 수 있으며 빌더가 스스로 길을 개척하게 되어 기쁘다. 다음은 몇 가지의 아이디어이다.

• 분산 네트워크에서 브라우저 노드(또는 단순 클라이언트)를 '완전한' 피어(peer)로 활성화
  • 브라우저 노드는 더 넓은 분산 네트워크에서 피어에게 직접 간섭할 수 있다. 즉, HTTP/그래프QL API와 같은 중앙 집중식 인프라 또는 인터페이스에 의존하지 않고 직접 메시지를 수신 및 제출, 발신 및 수신할 수 있다.
• 블록체인에 직접 거래를 제출하기 위한 브라우저 확장 암호화폐 지갑 활성화
• DHT(분산 해시 테이블) 서버 노드에 직접 접속함으로써 DHT에서 데이터 얻기
• 브라우저에서 파일코인 직접 업로드하기
• 분산형 앱으로서 탈중앙화 P2P 비디오 스트리밍 활성화

이것은 몇 가지 가능성에 불과하며 더 많은 가능성을 열어둘 수 있다. 웹트랜스포트의 속도와 성능을 최대한 활용하십시오.

리소스 및 이바지하는 방법

웹트랜스포트에 대해 더 자세히 알고 싶다면 libp2p를 참조하십시오:

• 웹트랜스포트 문서
• 프로토콜의 연결 사이트 섹션
  • 다른 전송 구현과 함께 웹트랜스포트를 설명한다.
• 웹트랜스포트 사양

이바지하고 싶다면:

• libp2p 관리자와 연결

감사합니다.

보다 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인할 수 있습니다.