Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.
Trang này được dịch bởi Cloud Translation API.
Switch to English

Bắt đầu với các kết nối ngang hàng

Kết nối ngang hàng là một phần của thông số kỹ thuật WebRTC liên quan đến việc kết nối hai ứng dụng trên các máy tính khác nhau để giao tiếp bằng giao thức ngang hàng. Giao tiếp giữa các đồng nghiệp có thể là video, âm thanh hoặc dữ liệu nhị phân tùy ý (đối với các máy khách hỗ trợ API RTCDataChannel ). Để khám phá cách hai máy ngang hàng có thể kết nối, cả hai máy khách cần cung cấp cấu hình Máy chủ ICE. Đây là STUN hoặc TURN-server và vai trò của họ là cung cấp các ứng cử viên ICE cho mỗi khách hàng sau đó được chuyển đến máy ngang hàng từ xa. Việc chuyển các ứng cử viên ICE này thường được gọi là báo hiệu.

Báo hiệu

Đặc tả WebRTC bao gồm các API để giao tiếp với Máy chủ ICE (Thiết lập kết nối Internet), nhưng thành phần báo hiệu không phải là một phần của nó. Báo hiệu là cần thiết để hai đồng nghiệp chia sẻ cách họ nên kết nối. Thông thường, điều này được giải quyết thông qua API Web dựa trên HTTP thông thường (nghĩa là dịch vụ REST hoặc cơ chế RPC khác) nơi các ứng dụng web có thể chuyển tiếp thông tin cần thiết trước khi kết nối ngang hàng được bắt đầu.

Đoạn mã sau cho thấy cách dịch vụ báo hiệu giả tưởng này có thể được sử dụng để gửi và nhận tin nhắn không đồng bộ. Điều này sẽ được sử dụng trong các ví dụ còn lại trong hướng dẫn này khi cần thiết.

 // Set up an asynchronous communication channel that will be
// used during the peer connection setup
const signalingChannel = new SignalingChannel(remoteClientId);
signalingChannel.addEventListener('message', message => {
    // New message from remote client received
});

// Send an asynchronous message to the remote client
signalingChannel.send('Hello!');
 

Báo hiệu có thể được thực hiện theo nhiều cách khác nhau và đặc tả WebRTC không thích bất kỳ giải pháp cụ thể nào.

Bắt đầu kết nối ngang hàng

Mỗi kết nối ngang hàng được xử lý bởi một đối tượng RTCPeerConnection . Hàm tạo cho lớp này lấy một đối tượng RTCConfiguration làm tham số. Đối tượng này xác định cách thiết lập kết nối ngang hàng và nên chứa thông tin về các máy chủ ICE sẽ sử dụng.

Khi RTCPeerConnection được tạo, chúng tôi cần tạo một ưu đãi hoặc câu trả lời SDP, tùy thuộc vào việc chúng tôi là người gọi ngang hàng hay nhận ngang hàng. Khi đề nghị hoặc câu trả lời SDP được tạo, nó phải được gửi đến máy ngang hàng từ xa thông qua một kênh khác. Truyền các đối tượng SDP cho các đồng nghiệp từ xa được gọi là báo hiệu và không được quy định trong đặc tả WebRTC.

Để bắt đầu thiết lập kết nối ngang hàng từ phía gọi, chúng tôi tạo một đối tượng RTCPeerConnection và sau đó gọi createOffer() để tạo một đối tượng RTCSessionDescription . Mô tả phiên này được đặt làm mô tả cục bộ bằng cách sử dụng setLocalDescription() mô tả setLocalDescription() và sau đó được gửi qua kênh báo hiệu của chúng tôi đến phía nhận. Chúng tôi cũng thiết lập một trình lắng nghe cho kênh báo hiệu của chúng tôi khi nhận được câu trả lời cho mô tả phiên được cung cấp từ phía bên nhận.

 async function makeCall() {
    const configuration = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]}
    const peerConnection = new RTCPeerConnection(configuration);
    signalingChannel.addEventListener('message', async message => {
        if (message.answer) {
            const remoteDesc = new RTCSessionDescription(message.answer);
            await peerConnection.setRemoteDescription(remoteDesc);
        }
    });
    const offer = await peerConnection.createOffer();
    await peerConnection.setLocalDescription(offer);
    signalingChannel.send({'offer': offer});
}
 

Về phía bên nhận, chúng tôi chờ đợi một đề nghị đến trước khi chúng tôi tạo phiên bản RTCPeerConnection . Khi đã xong, chúng tôi đặt ưu đãi nhận được bằng cách sử dụng setRemoteDescription() . Tiếp theo, chúng tôi gọi createAnswer() để tạo câu trả lời cho lời đề nghị đã nhận. Câu trả lời này được đặt làm mô tả cục bộ bằng cách sử dụng setLocalDescription() mô tả setLocalDescription() và sau đó được gửi đến phía gọi qua máy chủ báo hiệu của chúng tôi.

 const peerConnection = new RTCPeerConnection(configuration);
signalingChannel.addEventListener('message', async message => {
    if (message.offer) {
        peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer));
        const answer = await peerConnection.createAnswer();
        await peerConnection.setLocalDescription(answer);
        signalingChannel.send({'answer': answer});
    }
});
 

Khi hai đồng nghiệp đã thiết lập cả mô tả phiên cục bộ và phiên từ xa, họ biết khả năng của máy ngang hàng từ xa. Điều này không có nghĩa là kết nối giữa các đồng nghiệp đã sẵn sàng. Để làm việc này, chúng tôi cần thu thập các ứng cử viên ICE ở mỗi đồng đẳng và chuyển (qua kênh báo hiệu) sang các đồng nghiệp khác.

Ứng viên ICE

Trước khi hai đồng nghiệp có thể giao tiếp bằng WebRTC, họ cần trao đổi thông tin kết nối. Vì các điều kiện mạng có thể khác nhau tùy thuộc vào một số yếu tố, nên một dịch vụ bên ngoài thường được sử dụng để khám phá các ứng cử viên có thể để kết nối với một mạng ngang hàng. Dịch vụ này được gọi là ICE và đang sử dụng máy chủ STUN hoặc TURN. STUN là viết tắt của session Traversal Utility cho NAT và thường được sử dụng gián tiếp trong hầu hết các ứng dụng WebRTC.

TURN (Traversal Sử dụng Relay NAT) là giải pháp tiên tiến hơn kết hợp các giao thức STUN và hầu hết các dịch vụ dựa trên WebRTC thương mại sử dụng máy chủ TURN để thiết lập kết nối giữa các đồng nghiệp. API WebRTC hỗ trợ trực tiếp cả STUN và TURN và được thu thập theo Thiết lập kết nối Internet có thời hạn đầy đủ hơn. Khi tạo kết nối WebRTC, chúng tôi thường cung cấp một hoặc một số máy chủ ICE trong cấu hình cho đối tượng RTCPeerConnection .

ICE nhỏ giọt

Khi một đối tượng RTCPeerConnection được tạo, khung bên dưới sử dụng các máy chủ ICE được cung cấp để tập hợp các ứng cử viên cho cơ sở kết nối (ứng viên ICE). Sự kiện icegatheringstatechange trên RTCPeerConnection báo hiệu trạng thái thu thập ICE là gì ( new , gathering hoặc complete ).

Mặc dù đồng nghiệp có thể đợi cho đến khi quá trình thu thập ICE hoàn tất, nhưng việc sử dụng kỹ thuật "đá nhỏ giọt" sẽ hiệu quả hơn và truyền từng ứng cử viên ICE đến đồng nghiệp từ xa khi được phát hiện. Điều này sẽ giảm đáng kể thời gian thiết lập cho kết nối ngang hàng và cho phép cuộc gọi video bắt đầu với độ trễ ít hơn.

Để thu thập các ứng cử viên ICE, chỉ cần thêm một người nghe cho sự kiện icecandidate . RTCPeerConnectionIceEvent phát ra trên trình nghe đó sẽ chứa thuộc tính candidate đại diện cho một ứng cử viên mới sẽ được gửi đến máy ngang hàng từ xa (Xem phần Báo hiệu).

 // Listen for local ICE candidates on the local RTCPeerConnection
peerConnection.addEventListener('icecandidate', event => {
    if (event.candidate) {
        signalingChannel.send({'new-ice-candidate': event.candidate});
    }
});

// Listen for remote ICE candidates and add them to the local RTCPeerConnection
signalingChannel.addEventListener('message', async message => {
    if (message.iceCandidate) {
        try {
            await peerConnection.addIceCandidate(message.iceCandidate);
        } catch (e) {
            console.error('Error adding received ice candidate', e);
        }
    }
});
 

Kết nối thành lập

Khi các ứng cử viên ICE đang được nhận, chúng ta nên mong đợi trạng thái cho kết nối ngang hàng của chúng ta cuối cùng sẽ thay đổi thành trạng thái được kết nối. Để phát hiện điều này, chúng tôi thêm một người nghe vào RTCPeerConnection của chúng tôi, nơi chúng tôi lắng nghe các sự kiện connectionstatechange .

 // Listen for connectionstatechange on the local RTCPeerConnection
peerConnection.addEventListener('connectionstatechange', event => {
    if (peerConnection.connectionState === 'connected') {
        // Peers connected!
    }
});
 

Tài liệu API RTCPeerConnection