소개

우리 회사 기대어 기술 기존 데스크톱 애플리케이션을 웹으로 포팅하기 위한 솔루션을 제공합니다. 우리의 C++ 컴파일러 응원 WebAssembly와 JavaScript의 조합을 생성합니다. 간단한 브라우저 상호 작용, 고성능.

그 적용 사례로서 우리는 멀티플레이어 게임을 웹으로 포팅하기로 결정하고 이를 선택했습니다. Teeworlds. Teeworlds는 작지만 활동적인 플레이어 커뮤니티(저 포함!)가 있는 멀티플레이어 XNUMXD 복고풍 게임입니다. 다운로드된 리소스와 CPU 및 GPU 요구 사항 측면에서 모두 작으므로 이상적인 후보입니다.

Teeworlds 브라우저에서 실행

우리는 이 프로젝트를 사용하여 실험하기로 결정했습니다. 네트워크 코드를 웹으로 포팅하기 위한 일반적인 솔루션. 이는 일반적으로 다음과 같은 방법으로 수행됩니다.

• XMLHttp요청/가져오기, 네트워크 부분이 HTTP 요청으로만 구성된 경우, 또는
• WebSocket을.

두 솔루션 모두 서버 측에서 서버 구성 요소를 호스팅해야 하며 둘 다 전송 프로토콜로 사용할 수 없습니다. UDP. 이는 프로토콜 패킷의 전달 및 순서를 보장하므로 화상 회의 소프트웨어 및 게임과 같은 실시간 애플리케이션에 중요합니다. TCP 낮은 레이턴시를 방해하는 요소가 될 수 있습니다.

세 번째 방법이 있습니다. 브라우저에서 네트워크를 사용하는 것입니다. WebRTC가.

RTC데이터 채널 이는 신뢰할 수 있는 전송과 신뢰할 수 없는 전송을 모두 지원하며(후자의 경우 가능할 때마다 UDP를 전송 프로토콜로 사용하려고 시도함) 원격 서버와 브라우저 간에 모두 사용할 수 있습니다. 이는 서버 구성 요소를 포함하여 전체 애플리케이션을 브라우저로 포팅할 수 있음을 의미합니다!

그러나 여기에는 추가적인 어려움이 따릅니다. 두 WebRTC 피어가 통신할 수 있으려면 비교적 복잡한 핸드셰이크를 수행하여 연결해야 하며, 이를 위해서는 여러 타사 엔터티(신호 서버 및 하나 이상의 서버)가 필요합니다. 충격/회전).

이상적으로는 내부적으로 WebRTC를 사용하지만 연결을 설정할 필요가 없는 UDP 소켓 인터페이스에 최대한 가까운 네트워크 API를 만들고 싶습니다.

이를 통해 애플리케이션 코드에 복잡한 세부 정보를 노출하지 않고도 WebRTC를 활용할 수 있습니다(우리 프로젝트에서는 이를 가능한 한 적게 변경하고 싶었습니다).

최소 WebRTC

WebRTC는 오디오, 비디오 및 임의 데이터의 PXNUMXP 전송을 제공하는 브라우저에서 사용할 수 있는 API 세트입니다.

피어 간의 연결은 ICE라는 메커니즘을 통해 STUN 및/또는 TURN 서버를 사용하여 (한쪽 또는 양쪽에 NAT가 있더라도) 설정됩니다. 피어는 SDP 프로토콜의 제안 및 응답을 통해 ICE 정보 및 채널 매개변수를 교환합니다.

우와! 한 번에 몇 개의 약어가 있습니까? 이 용어의 의미를 간략하게 설명하겠습니다.

• NAT용 세션 순회 유틸리티 (충격) — NAT를 우회하고 호스트와 직접 데이터를 교환하기 위한 쌍(IP, 포트)을 얻기 위한 프로토콜입니다. 그가 작업을 완료하면 동료는 서로 독립적으로 데이터를 교환할 수 있습니다.
• NAT 주변의 릴레이를 사용한 순회 (회전) NAT 통과에도 사용되지만 두 피어 모두에게 표시되는 프록시를 통해 데이터를 전달하여 이를 구현합니다. STUN보다 대기 시간이 추가되고 구현 비용이 더 높지만(전체 통신 세션에 걸쳐 적용되기 때문에) 때로는 이것이 유일한 옵션이기도 합니다.
• 인터랙티브 커넥티비티 구축 (ICE) 피어를 직접 연결하여 얻은 정보와 다수의 STUN 및 TURN 서버에서 수신한 정보를 기반으로 두 피어를 연결하는 가장 좋은 방법을 선택하는 데 사용됩니다.
• 세션 설명 프로토콜 (SDP) ICE 후보, 멀티미디어 코덱(오디오/비디오 채널의 경우) 등과 같은 연결 채널 매개변수를 설명하기 위한 형식입니다. 피어 중 하나는 SDP Offer를 보내고 두 번째는 SDP Answer로 응답합니다. ... 그 후 채널이 생성됩니다.

이러한 연결을 생성하려면 피어는 STUN 및 TURN 서버로부터 받은 정보를 수집하고 이를 서로 교환해야 합니다.

문제는 아직 직접 통신할 수 있는 기능이 없기 때문에 이 데이터를 교환하려면 신호 서버라는 대역 외 메커니즘이 존재해야 한다는 것입니다.

신호 서버는 유일한 작업이 핸드셰이크 단계에서 피어 간에 데이터를 전달하는 것이므로 매우 간단할 수 있습니다(아래 다이어그램 참조).

단순화된 WebRTC 핸드셰이크 시퀀스 다이어그램

Teeworlds 네트워크 모델 개요

Teeworlds 네트워크 아키텍처는 매우 간단합니다.

• 클라이언트와 서버 구성 요소는 서로 다른 두 가지 프로그램입니다.
• 클라이언트는 한 번에 하나의 게임만 호스팅하는 여러 서버 중 하나에 연결하여 게임에 들어갑니다.
• 게임 내 모든 데이터 전송은 서버를 통해 이루어집니다.
• 게임 클라이언트에 표시되는 모든 공용 서버 목록을 수집하기 위해 특수 마스터 서버가 사용됩니다.

데이터 교환을 위해 WebRTC를 사용함으로써 게임의 서버 구성 요소를 클라이언트가 있는 브라우저로 전송할 수 있습니다. 이는 우리에게 좋은 기회를 제공합니다...

서버를 없애세요

서버 로직이 없다는 점은 좋은 장점이 있습니다. Github 페이지나 Cloudflare 뒤의 자체 하드웨어에 정적 콘텐츠로 전체 애플리케이션을 배포할 수 있으므로 무료로 빠른 다운로드와 높은 가동 시간을 보장할 수 있습니다. 사실, 우리는 그것들을 잊어버릴 수 있으며 운이 좋고 게임이 인기를 얻게 된다면 인프라를 현대화할 필요가 없을 것입니다.

그러나 시스템이 작동하려면 여전히 외부 아키텍처를 사용해야 합니다.

• 하나 이상의 STUN 서버: 선택할 수 있는 몇 가지 무료 옵션이 있습니다.
• 최소 하나의 TURN 서버: 여기에는 무료 옵션이 없으므로 자체적으로 설정하거나 서비스 비용을 지불할 수 있습니다. 다행스럽게도 대부분의 경우 STUN 서버를 통해 연결을 설정할 수 있지만(및 진정한 p2p 제공) 대체 옵션으로 TURN이 필요합니다.
• 시그널링 서버: 다른 두 가지 측면과 달리 시그널링은 표준화되지 않습니다. 시그널링 서버가 실제로 담당하는 일은 애플리케이션에 따라 다릅니다. 우리의 경우 연결을 설정하기 전에 소량의 데이터를 교환해야 합니다.
• Teeworlds 마스터 서버: 다른 서버에서 자신의 존재를 알리고 클라이언트가 공용 서버를 찾는 데 사용됩니다. 필수는 아니지만(클라이언트는 항상 수동으로 알고 있는 서버에 연결할 수 있음) 플레이어가 임의의 사람들과 게임에 참여할 수 있도록 하면 좋을 것입니다.

우리는 Google의 무료 STUN 서버를 사용하기로 결정하고 하나의 TURN 서버를 직접 배포했습니다.

우리가 사용한 마지막 두 점에 대해 중포 기지:

• Teeworlds 마스터 서버는 각 활성 서버의 정보(이름, IP, 지도, 모드 등)를 포함하는 개체 목록으로 매우 간단하게 구현됩니다. 서버는 자체 개체를 게시하고 업데이트하며 클라이언트는 전체 목록을 가져와 플레이어에 표시합니다. 또한 플레이어가 서버를 클릭하기만 하면 바로 게임으로 이동할 수 있도록 홈 페이지에 목록을 HTML로 표시합니다.
• 신호는 다음 섹션에서 설명하는 소켓 구현과 밀접하게 관련되어 있습니다.

게임 내부 및 홈페이지의 서버 목록

소켓 구현

우리는 필요한 변경 횟수를 최소화하기 위해 Posix UDP 소켓에 최대한 가까운 API를 만들고 싶습니다.

또한 우리는 네트워크를 통한 가장 간단한 데이터 교환에 필요한 최소한의 요구 사항을 구현하려고 합니다.

예를 들어 실제 라우팅이 필요하지 않습니다. 모든 피어는 특정 Firebase 데이터베이스 인스턴스와 연결된 동일한 "가상 LAN"에 있습니다.

따라서 고유한 IP 주소가 필요하지 않습니다. 고유한 Firebase 키 값(도메인 이름과 유사)은 피어를 고유하게 식별하는 데 충분하며, 각 피어는 변환해야 하는 각 키에 로컬로 "가짜" IP 주소를 할당합니다. 이는 결코 쉽지 않은 작업인 글로벌 IP 주소 할당의 필요성을 완전히 제거합니다.

구현해야 하는 최소 API는 다음과 같습니다.

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

API는 간단하고 Posix Sockets API와 유사하지만 몇 가지 중요한 차이점이 있습니다. 콜백 로깅, 로컬 IP 할당 및 지연 연결.

콜백 등록

원본 프로그램이 비차단 I/O를 사용하더라도 웹 브라우저에서 실행하려면 코드를 리팩터링해야 합니다.

그 이유는 브라우저의 이벤트 루프가 프로그램(JavaScript 또는 WebAssembly)에서 숨겨져 있기 때문입니다.

기본 환경에서는 다음과 같은 코드를 작성할 수 있습니다.

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

이벤트 루프가 숨겨져 있으면 다음과 같이 바꿔야 합니다.

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

로컬 IP 할당

"네트워크"의 노드 ID는 IP 주소가 아니라 Firebase 키입니다(다음과 같은 문자열입니다: -LmEC50PYZLCiCP-vqde ).

이는 IP를 할당하고 고유성을 확인(클라이언트 연결이 끊어진 후 처리)하는 메커니즘이 필요하지 않기 때문에 편리하지만, 숫자 값으로 피어를 식별해야 하는 경우가 많습니다.

이것이 바로 기능이 사용되는 목적입니다. resolve и reverseResolve: 애플리케이션은 어떻게든 (사용자 입력 또는 마스터 서버를 통해) 키의 문자열 값을 수신하고 내부 사용을 위해 이를 IP 주소로 변환할 수 있습니다. API의 나머지 부분도 단순화를 위해 문자열 대신 이 값을 받습니다.

이는 DNS 조회와 유사하지만 클라이언트에서 로컬로 수행됩니다.

즉, IP 주소는 서로 다른 클라이언트 간에 공유될 수 없으며, 일종의 전역 식별자가 필요한 경우 다른 방식으로 생성해야 합니다.

게으른 연결

UDP에는 연결이 필요하지 않지만 앞서 살펴본 것처럼 WebRTC는 두 피어 간에 데이터 전송을 시작하기 전에 오랜 연결 프로세스가 필요합니다.

동일한 수준의 추상화를 제공하려면 (sendto/recvfrom 사전 연결이 없는 임의의 피어와 함께) API 내에서 "지연"(지연) 연결을 수행해야 합니다.

이는 UDP를 사용할 때 “서버”와 “클라이언트” 간의 일반적인 통신 중에 발생하는 일이며, 우리 라이브러리가 수행해야 하는 작업은 다음과 같습니다.

• 서버 호출 bind()지정된 포트에서 패킷을 수신하고 싶다고 운영 체제에 알리는 것입니다.

대신 서버 키 아래의 Firebase에 개방형 포트를 게시하고 해당 하위 트리에서 이벤트를 수신합니다.

• 서버 호출 recvfrom(), 이 포트의 모든 호스트에서 들어오는 패킷을 수락합니다.

우리의 경우에는 이 포트로 전송된 패킷의 수신 대기열을 확인해야 합니다.

각 포트에는 자체 대기열이 있으며, 새 패킷이 도착할 때 어떤 대기열로 전달할지 알 수 있도록 WebRTC 데이터그램의 시작 부분에 소스 및 대상 포트를 추가합니다.

호출은 비차단이므로 패킷이 없으면 간단히 -1을 반환하고 설정합니다. errno=EWOULDBLOCK.

• 클라이언트는 외부 수단을 통해 서버의 IP와 포트를 수신하고 호출합니다. sendto(). 이는 내부 호출도 수행합니다. bind(), 따라서 후속 recvfrom() 명시적으로 바인드를 실행하지 않고 응답을 받습니다.

우리의 경우 클라이언트는 외부에서 문자열 키를 수신하고 함수를 사용합니다. resolve() IP 주소를 얻으려면.

이 시점에서 두 피어가 아직 서로 연결되지 않은 경우 WebRTC 핸드셰이크를 시작합니다. 동일한 피어의 다른 포트에 대한 연결은 동일한 WebRTC DataChannel을 사용합니다.

간접적으로 수행하기도 합니다. bind()다음에 서버가 다시 연결될 수 있도록 sendto() 어떤 이유로든 문을 닫은 경우.

클라이언트가 Firebase의 서버 포트 정보 아래에 SDP 제안을 작성할 때 서버는 클라이언트 연결에 대한 알림을 받고, 서버는 거기에 대한 응답으로 응답합니다.

아래 다이어그램은 소켓 구성표에 대한 메시지 흐름의 예와 클라이언트에서 서버로의 첫 번째 메시지 전송을 보여줍니다.

클라이언트와 서버 간의 연결 단계에 대한 전체 다이어그램

결론

여기까지 읽었다면 아마도 이론이 실제로 작동하는 모습을 보는 데 관심이 있을 것입니다. 게임은 다음에서 플레이할 수 있습니다. teeworlds.leaningtech.com, 시도 해봐!

동료간의 친선경기

네트워크 라이브러리 코드는 다음에서 무료로 사용할 수 있습니다. 깃허브. 다음 채널에서 대화에 참여하세요. Gitter!

출처 : habr.com