Giao tiếp qua video là cách giao tiếp chính giữa giáo viên và học sinh trên nền tảng Vimbox. Chúng tôi đã từ bỏ Skype từ lâu, thử một số giải pháp của bên thứ ba và cuối cùng đã giải quyết bằng sự kết hợp WebRTC - Janus-gateway. Trong một thời gian, chúng tôi hài lòng với mọi thứ, nhưng vẫn có một số khía cạnh tiêu cực tiếp tục xuất hiện. Kết quả là một hướng video riêng đã được tạo ra.
Tôi đã yêu cầu Kirill Rogovoy, người đứng đầu bộ phận chỉ đạo mới, nói về sự phát triển của truyền thông video tại Skyeng, những vấn đề được phát hiện, các giải pháp và điểm tựa mà cuối cùng chúng tôi đã sử dụng. Chúng tôi hy vọng bài viết sẽ hữu ích cho các công ty cũng tự tạo video thông qua ứng dụng web.
Một chút lịch sử
Vào mùa hè năm 2017, người đứng đầu bộ phận phát triển Skyeng, Sergey Safonov, đã phát biểu tại Backend Conf với câu chuyện về cách chúng tôi “từ bỏ Skype và triển khai WebRTC”. Các bạn quan tâm có thể xem bản ghi âm bài phát biểu tại (~45 phút), và ở đây tôi sẽ phác thảo ngắn gọn bản chất của nó.
Đối với Trường Skyeng, giao tiếp qua video luôn là phương thức giao tiếp được ưu tiên giữa giáo viên và học sinh. Lúc đầu, Skype đã được sử dụng, nhưng về cơ bản nó không đạt yêu cầu vì một số lý do, chủ yếu là do thiếu nhật ký và không thể tích hợp trực tiếp vào ứng dụng web. Vì vậy, chúng tôi đã thực hiện tất cả các loại thí nghiệm.
Trên thực tế, yêu cầu của chúng tôi đối với giao tiếp video xấp xỉ như sau:
- sự ổn định;
— giá thấp cho mỗi bài học;
- ghi lại bài học;
— theo dõi xem ai nói bao nhiêu (điều quan trọng đối với chúng tôi là học sinh nói nhiều hơn giáo viên trong giờ học);
- chia tỷ lệ tuyến tính;
- khả năng sử dụng cả UDP và TCP.
Lần đầu tiên thử nghiệm là triển khai Tokbox vào năm 2013. Mọi thứ đều tốt, nhưng hóa ra nó rất đắt - 113 rúp mỗi bài học - và ăn hết lợi nhuận.
Sau đó vào năm 2015, Voximplant được tích hợp. Đây là chức năng mà chúng tôi cần để theo dõi xem ai đã nói bao nhiêu, đồng thời giải pháp này rẻ hơn nhiều: nếu chỉ ghi âm thì sẽ tốn 20 rúp mỗi bài học. Tuy nhiên, nó chỉ hoạt động qua UDP và không thể chuyển sang TCP. Tuy nhiên, khoảng 40% sinh viên đã sử dụng nó.
Một năm sau, chúng tôi bắt đầu có những khách hàng doanh nghiệp với những yêu cầu cụ thể của riêng họ. Ví dụ: mọi thứ sẽ hoạt động thông qua trình duyệt, công ty chỉ mở http và https; tức là không có Skype hoặc UDP. Khách hàng doanh nghiệp = tiền nên họ quay lại Tokbox nhưng vấn đề về giá vẫn không biến mất.
Giải pháp - WebRTC và Janus
Quyết định sử dụng . Nó chịu trách nhiệm thiết lập kết nối, mã hóa và giải mã các luồng, đồng bộ hóa các bản nhạc và kiểm soát chất lượng cũng như xử lý các trục trặc của mạng. Về phần mình, chúng tôi phải đảm bảo đọc các luồng từ máy ảnh và micrô, vẽ video, quản lý kết nối, thiết lập kết nối WebRTC và truyền các luồng tới nó, cũng như truyền các tin nhắn báo hiệu giữa các máy khách để thiết lập kết nối (bản thân WebRTC chỉ mô tả định dạng dữ liệu chứ không phải cơ chế chuyển giao của nó). Nếu máy khách sử dụng NAT, WebRTC sẽ kết nối máy chủ STUN; nếu điều này không hiệu quả, hãy TURN máy chủ.
Kết nối p2p thông thường là không đủ đối với chúng tôi vì chúng tôi muốn ghi lại các bài học để phân tích thêm trong trường hợp có khiếu nại. Vì vậy, chúng tôi gửi luồng WebRTC thông qua rơle . Kết quả là các máy khách không biết địa chỉ của nhau mà chỉ nhìn thấy địa chỉ máy chủ Janus; nó cũng thực hiện các chức năng của một máy chủ tín hiệu. Janus có nhiều tính năng mà chúng ta cần: tự động chuyển sang TCP nếu máy khách bị chặn UDP; có thể ghi cả luồng UDP và TCP; có thể mở rộng; Thậm chí còn có một plugin tích hợp để kiểm tra tiếng vang. Nếu cần, máy chủ STUN và TURN từ Twilio sẽ tự động được kết nối.
Vào mùa hè năm 2017, chúng tôi có hai máy chủ Janus đang chạy, cùng với một máy chủ bổ sung để xử lý các tệp âm thanh và video thô đã ghi để không chiếm bộ xử lý của các máy chủ chính. Khi kết nối, các máy chủ Janus được chọn theo nguyên tắc chẵn-lẻ (số kết nối). Vào thời điểm đó, điều này là đủ, theo cảm nhận của chúng tôi, nó mang lại tỷ lệ an toàn xấp xỉ gấp bốn lần, tỷ lệ thực hiện là khoảng 80. Đồng thời, giá giảm xuống ~ 2 rúp mỗi bài học, cộng với sự phát triển và hỗ trợ.
Quay lại chủ đề truyền thông video
Chúng tôi liên tục theo dõi phản hồi từ học sinh và giáo viên để xác định và khắc phục kịp thời các vấn đề. Vào mùa hè năm 2018, chất lượng cuộc gọi đã vững chắc ở vị trí đầu tiên trong số các lời phàn nàn. Một mặt, điều này có nghĩa là chúng tôi đã khắc phục thành công những khuyết điểm khác. Mặt khác, cần phải làm một việc gì đó khẩn trương: nếu bài học bị gián đoạn, chúng ta có nguy cơ mất đi giá trị của nó, đôi khi kèm theo chi phí mua gói tiếp theo, và nếu bài học nhập môn bị gián đoạn, chúng ta có nguy cơ mất đi một khách hàng tiềm năng. toàn bộ.
Vào thời điểm đó, giao tiếp video của chúng tôi vẫn ở chế độ MVP. Nói một cách đơn giản, họ đã khởi chạy nó, nó hoạt động, họ mở rộng quy mô một lần, họ hiểu cách thực hiện - à, thật tuyệt. Nếu nó hoạt động, đừng sửa nó. Không ai cố tình giải quyết vấn đề chất lượng truyền thông. Đến tháng XNUMX, rõ ràng là điều này không thể tiếp tục và chúng tôi đã đưa ra một hướng đi riêng để tìm hiểu xem WebRTC và Janus đã gặp vấn đề gì.
Đầu vào, hướng đi này nhận được: giải pháp MVP, không có số liệu, không có mục tiêu, không có quy trình cải tiến, trong khi 7% giáo viên phàn nàn về chất lượng giao tiếp (cũng không có dữ liệu về học sinh).
Một hướng đi mới đang được thực hiện
Lệnh trông giống như thế này:
- Người đứng đầu bộ phận, đồng thời là nhà phát triển chính.
- QA giúp kiểm tra các thay đổi, tìm kiếm những cách mới để tạo điều kiện giao tiếp không ổn định và báo cáo các vấn đề từ tuyến đầu.
- Nhà phân tích liên tục tìm kiếm các mối tương quan khác nhau trong dữ liệu kỹ thuật, cải thiện việc phân tích phản hồi của người dùng và kiểm tra kết quả thử nghiệm.
- Người quản lý sản phẩm giúp định hướng và phân bổ nguồn lực tổng thể cho các thử nghiệm.
- Nhà phát triển thứ hai thường giúp lập trình và các công việc liên quan.
Để bắt đầu, chúng tôi thiết lập một số liệu tương đối đáng tin cậy để theo dõi những thay đổi trong đánh giá chất lượng truyền thông (trung bình theo ngày, tuần, tháng). Vào thời điểm đó, đây là điểm của giáo viên, điểm sau này của học sinh được thêm vào. Sau đó, họ bắt đầu xây dựng các giả thuyết về những gì đang xảy ra sai sót, sửa chữa nó và xem xét những thay đổi trong động lực. Chúng tôi đã tìm kiếm kết quả dễ dàng: ví dụ: chúng tôi đã thay thế codec vp8 bằng vp9, hiệu suất được cải thiện. Chúng tôi đã cố gắng thử cài đặt Janus và tiến hành các thử nghiệm khác - trong hầu hết các trường hợp, chúng không dẫn đến điều gì.
Ở giai đoạn thứ hai, một giả thuyết xuất hiện: WebRTC là một giải pháp ngang hàng và chúng tôi sử dụng một máy chủ ở giữa. Có lẽ vấn đề nằm ở đây? Chúng tôi bắt đầu tìm hiểu và tìm thấy sự cải thiện đáng kể nhất cho đến nay.
Vào thời điểm đó, một máy chủ từ nhóm đã được chọn bằng một thuật toán khá ngu ngốc: mỗi máy chủ có “trọng số” riêng, tùy thuộc vào kênh và sức mạnh, và chúng tôi đã cố gắng gửi người dùng đến máy chủ có “trọng lượng” lớn nhất, mà không chú ý đến vị trí địa lý của người dùng. Do đó, một giáo viên từ St. Petersburg có thể liên lạc với một học sinh từ Siberia qua Moscow chứ không phải qua máy chủ Janus của chúng tôi ở St. Petersburg.
Thuật toán đã được làm lại: bây giờ, khi người dùng mở nền tảng của chúng tôi, chúng tôi sẽ thu thập ping từ người đó đến tất cả các máy chủ sử dụng Ajax. Khi thiết lập kết nối, chúng tôi chọn một cặp ping (máy chủ giáo viên và máy chủ học sinh) với số lượng nhỏ nhất. Ít ping hơn có nghĩa là khoảng cách mạng tới máy chủ ít hơn; khoảng cách ngắn hơn có nghĩa là xác suất mất gói thấp hơn; Mất gói là yếu tố tiêu cực lớn nhất trong giao tiếp video. Tỷ lệ tiêu cực đã giảm một nửa trong ba tháng (công bằng mà nói, các thí nghiệm khác đã được thực hiện vào thời điểm này, nhưng thí nghiệm này gần như chắc chắn có tác động lớn nhất).
Gần đây, chúng tôi đã phát hiện ra một điều không rõ ràng nhưng có vẻ quan trọng khác: thay vì một máy chủ Janus mạnh mẽ trên một kênh dày, tốt hơn là nên có hai máy chủ đơn giản hơn với băng thông mỏng hơn. Điều này trở nên rõ ràng sau khi chúng tôi mua những chiếc máy mạnh mẽ với hy vọng có thể nhồi nhét nhiều phòng (phiên giao tiếp) vào đó cùng một lúc. Máy chủ có giới hạn băng thông mà chúng tôi có thể dịch chính xác thành số lượng phòng - chúng tôi biết có thể mở bao nhiêu phòng, chẳng hạn như ở tốc độ 300 Mbit/s. Ngay khi có quá nhiều phòng mở trên máy chủ, chúng tôi sẽ ngừng chọn máy chủ đó cho các hoạt động mới cho đến khi tải giảm. Ý tưởng là, sau khi mua một chiếc máy mạnh mẽ, chúng tôi sẽ tải kênh đến nó ở mức tối đa, để cuối cùng nó sẽ bị giới hạn bởi bộ xử lý và bộ nhớ chứ không phải bởi băng thông. Nhưng hóa ra là sau một số phòng mở nhất định (420), mặc dù tải trên bộ xử lý, bộ nhớ và ổ đĩa vẫn còn rất xa so với giới hạn, nhưng sự tiêu cực bắt đầu ập đến với bộ phận hỗ trợ kỹ thuật. Rõ ràng có điều gì đó đang trở nên tồi tệ hơn bên trong Janus, có lẽ ở đó cũng có một số hạn chế. Chúng tôi bắt đầu thử nghiệm, hạ giới hạn băng thông từ 300 xuống 200 Mbit/s và các vấn đề đã biến mất. Bây giờ chúng tôi đã mua ba máy chủ mới cùng một lúc với giới hạn và đặc điểm thấp, chúng tôi nghĩ rằng điều này sẽ dẫn đến sự cải thiện ổn định về chất lượng liên lạc. Tất nhiên, chúng tôi không cố gắng tìm hiểu chuyện gì đang xảy ra ở đó; đôi nạng của chúng tôi là tất cả. Để bào chữa cho chúng ta, hãy nói rằng tại thời điểm đó cần phải giải quyết vấn đề cấp bách càng nhanh càng tốt chứ không phải làm một cách đẹp đẽ; hơn nữa, Janus đối với chúng tôi là một hộp đen viết bằng C, mày mò nó rất tốn kém.
Vâng, trong quá trình này chúng tôi:
- đã cập nhật tất cả các phần phụ thuộc có thể được cập nhật, cả trên máy chủ và máy khách (đây cũng là những thử nghiệm, chúng tôi đã theo dõi kết quả);
- đã sửa tất cả các lỗi đã xác định liên quan đến các trường hợp cụ thể, chẳng hạn như khi kết nối bị ngắt và không được khôi phục tự động;
- Chúng tôi đã tổ chức rất nhiều cuộc họp với các công ty làm việc trong lĩnh vực truyền thông video và quen thuộc với các vấn đề của chúng tôi: phát trực tuyến trò chơi, tổ chức hội thảo trên web; chúng tôi đã thử mọi thứ có vẻ hữu ích cho chúng tôi;
- Đã tiến hành đánh giá kỹ thuật về chất lượng phần cứng và giao tiếp của giáo viên, những người nhận được nhiều khiếu nại nhất.
Các thử nghiệm và những thay đổi tiếp theo đã giúp giảm sự không hài lòng trong giao tiếp giữa giáo viên từ 7,1% vào tháng 2018 năm 2,5 xuống còn 2019% vào tháng XNUMX năm XNUMX.
những gì tiếp theo
Ổn định nền tảng Vimbox của chúng tôi là một trong những dự án chính của công ty trong năm 2019. Chúng tôi rất hy vọng rằng chúng tôi sẽ có thể duy trì động lực và không còn thấy giao tiếp qua video nằm trong số những lời phàn nàn hàng đầu nữa. Chúng tôi hiểu rằng một phần đáng kể trong số những khiếu nại này có liên quan đến độ trễ của máy tính và Internet của người dùng, nhưng chúng tôi phải xác định phần này và giải quyết phần còn lại. Mọi thứ khác đều là vấn đề kỹ thuật, có vẻ như chúng ta có thể giải quyết được nó.
Khó khăn chính là chúng tôi không biết thực sự có thể cải thiện chất lượng ở mức độ nào. Tìm ra mức trần này là nhiệm vụ chính. Vì vậy, hai thí nghiệm đã được lên kế hoạch:
- so sánh video qua Janus với p2p thông thường trong điều kiện chiến đấu. Thí nghiệm này đã được thực hiện, không tìm thấy sự khác biệt có ý nghĩa thống kê giữa giải pháp của chúng tôi và p2p;
- Hãy cung cấp dịch vụ (đắt tiền) từ các công ty kiếm tiền độc quyền từ các giải pháp truyền thông video và so sánh mức độ tiêu cực từ chúng với dịch vụ hiện có.
Hai thử nghiệm này sẽ cho phép chúng tôi xác định mục tiêu có thể đạt được và tập trung vào nó.
Ngoài ra, có một số nhiệm vụ có thể được giải quyết thường xuyên:
- Chúng tôi tạo ra thước đo kỹ thuật về chất lượng truyền thông thay vì đánh giá chủ quan;
- Chúng tôi tạo nhật ký phiên chi tiết hơn để phân tích chính xác hơn các lỗi xảy ra, hiểu chính xác chúng xảy ra khi nào và ở đâu cũng như những sự kiện dường như không liên quan đã diễn ra tại thời điểm đó;
- Chúng tôi chuẩn bị bài kiểm tra chất lượng kết nối tự động trước bài học, đồng thời cho khách hàng cơ hội kiểm tra kết nối theo cách thủ công nhằm giảm mức độ tiêu cực do phần cứng và kênh của họ gây ra;
- chúng tôi sẽ phát triển và tiến hành nhiều thử nghiệm tải truyền thông video hơn trong điều kiện kém, mất gói thay đổi, v.v.;
- chúng tôi thay đổi hành vi của máy chủ trong trường hợp có sự cố để tăng khả năng chịu lỗi;
- Chúng tôi sẽ cảnh báo người dùng nếu có điều gì đó không ổn với kết nối của anh ấy, giống như Skype đã làm, để anh ấy hiểu rằng vấn đề nằm ở phía anh ấy.
Kể từ tháng XNUMX, hướng truyền thông video đã trở thành một dự án riêng biệt hoàn toàn trong Skyeng, xử lý sản phẩm của chính họ chứ không chỉ là một phần của Vimbox. Điều này có nghĩa là chúng tôi đang bắt đầu tìm kiếm những người trên . Vâng, như mọi khi .
Và tất nhiên, chúng tôi tiếp tục tích cực liên lạc với mọi người và các công ty làm việc về truyền thông video. Nếu bạn muốn trao đổi kinh nghiệm với chúng tôi, chúng tôi sẽ rất vui! Bình luận, liên hệ - chúng tôi sẽ trả lời tất cả mọi người.
Nguồn: www.habr.com