Tài liệu Nghiên cứu giao tiếp thời gian thực trên Web WebRTC và ứng dụng xây dựng hệ thống webchat thời gian thực

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ KHÚC NGỌC HIỆP NGHIÊN CỨU GIAO TIẾP THỜI GIAN THỰC TRÊN WEB WEBRTC VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG WEB CHAT THỜI GIAN THỰC LUẬN VĂN THẠC SỸ Hà Nội - 2014 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ KHÚC NGỌC HIỆP NGHIÊN CỨU GIAO TIẾP THỜI GIAN THỰC TRÊN WEB WEBRTC VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG WEB CHAT THỜI GIAN THỰC Ngành:Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60480103 LUẬN VĂN THẠC SỸ NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. TRƯƠNG NINH THUẬN TS. TRỊNH THANH BÌNH Hà Nội - 2014 LỜI CAM ĐOAN Tôi xin cam đoan rằng đây là công trình nghiên cứu của riêng tôi. Các số liệu và kết quả nghiên cứu trong luận văn này là trung thực vàkhông sao chép của bất kỳ ai. Các thông tin trích dẫn trong luận văn đã đƣợc chỉ rõ nguồn gốc. Hà Nội, ngày tháng Học viên Khúc Ngọc Hiệp 1 năm 2014 TÓM TẮT WebRTC là một nỗ lực để xây dựng một framework mở có khả năng giao tiếp audio và video thời gian thực, nó có thể biến các trình duyệt web thành một nền tảng cho giao tiếp giữa ngƣời với ngƣời. Giao tiếp thời gian thực trong trình duyệt web đã có trƣớc đây tuy nhiênchúng ta phải cài đặt phần mềm của bên thứ ba lên trình duyệt web. WebRTC mang lại hỗ trợ giao tiếp thời gian thực từ ngay bên trong các trình duyệt web và các nhà phát triển web có thể sử dụng một cách tự do thông qua các JavaScript API tiêu chuẩn. Điều này mang lại giao tiếp thời gian thực nhƣ là một tính năng cho web, có thể thúc đẩy sự đổi mới hơn nữa. Luận văn này nghiên cứu chuyên sâu về WebRTC, các kiến trúc và mô hình trong WebRTC, các giao thức và kỹ thuật đƣợc sử dụng trong WebRTC, các API của WebRTC và các vấn đề về bảo mật và tính riêng tƣ đƣợc giải quyết trong WebRTC. Dựa trên kết quả nghiên cứu về lý thuyết cho WebRTC và hiện trạng của hệ thống hỗ trợ khách hàng trực tuyến của các website thƣơng mại điện tử ở Việt Nam phải sử dụng các ứng dụng chat bên ngoài nhƣ Yahoo messenger và Skype, chúng tôi đã tiến hành xây dựng một ứng dụng web chat thời gian thực sử dụng WebRTC để cải tiến hệ thống hỗ trợ khách hàng này. Khách hàng sẽ không phải cài đặt thêm một ứng dụng hoặc plugin nào để có thể chat video, gửi tin nhắn và gửi file với nhân viên hỗ trợ khách hàng ngay trên trình duyệt web. Chúng tôi thấy rằng WebRTC là một công nghệ rất khả thi, và rất thích hợp cho trƣờng hợp giao tiếp một một từ trình duyệt đến trình duyệt. Mặc dù chúng tôi phát hiện ra một số thách thức chƣa đƣợc giải quyết, chúng tôi không thấy bất kỳ trở ngại không thể vƣợt qua nào sẽ ngăn cản việc chấp nhận WebRTC. WebRTC mở ra những cơ hội cho các công ty sẽ sử dụng nó trực tiếp để cung cấp một dịch vụ giao tiếp thời gian thực trên web, nó cũng tạo ra không gian cho các nhà cung cấp PaaS WebRTC trên thị trƣờng. Thêm vào đó, WebRTC cho phép kết nối với các hệ thống cũ nhƣ PSTN hay PLMN, mở ra cơ hội cho các nhà cung cấp viễn thông để khám phá tạo ra cách thức truyền thông mới cho khách hàng của họ. 2 MỤC LỤC LỜI CAM ĐOAN.................................................................................................. 1 TÓM TẮT ............................................................................................................. 2 MỤC LỤC ............................................................................................................. 3 DANH SÁCH HÌNH VẼ ...................................................................................... 5 DANH SÁCH BẢNG ........................................................................................... 5 BẢNG TỪ VIẾT TẮT .......................................................................................... 6 MỞ ĐẦU ............................................................................................................... 7 CHƢƠNG 1: GIỚI THIỆU VỀ TRUYỀN THÔNG WEB THỜI GIAN THỰC WEBRTC .............................................................................................................. 9 1.1 Ngắn gọn về lịch sử của WebRTC .....................................................................9 1.2 Kiến trúc của WebRTC ....................................................................................10 1.3 Chồng giao thức trong WebRTC .....................................................................13 1.4 Các API của WebRTC ......................................................................................19 1.5 Kênh báo hiệu trong WebRTC ........................................................................20 1.6 Bảo mật trong WebRTC ...................................................................................21 CHƢƠNG 2: GIỚI THIỆU VỀ EASYRTC FRAMEWORK ............................ 23 2.1 Giới thiệu về EasyRTC framework .................................................................23 2.2 Cài đặt và chạy máy chủ EasyRTC .................................................................24 2.3 Sử dụng EasyRTC .............................................................................................26 2.4 Một số API tiện ích khác của EasyRTC ..........................................................30 CHƢƠNG 3: SỬ DỤNG EASYRTC FRAMEWORK ĐỂ XÂY DỰNG ỨNG DỤNG WEB CHAT THỜI GIAN THỰC .......................................................... 33 3.1 Phân tích hệ thống .............................................................................................33 3.1.1 Mục tiêu tổng thể của ứng dụng web chat thời gian thực ......................33 3.1.2 Thực trạng của hệ thống tư vấn bán hàng trực tuyến ...........................33 3.1.3 Phân tích yêu cầu của ứng dụng ...............................................................39 3.2 Thiết kế ứng dụng .............................................................................................39 3.2.1 Biểu đồ trường hợp sử dụng .....................................................................39 3.2.2 Biểu đồ tuần tự ...........................................................................................43 3.2.3 Biểu đồ lớp ..................................................................................................45 3.2.4 Thiết kế giao diện .......................................................................................46 3.3 Thực hiện ứng dụng ..........................................................................................47 3 3.4 Chạy thử và đánh giá ứng dụng.......................................................................50 3.4.1 Chạy thử ứng dụng ....................................................................................51 3.4.2 Đánh giá ứng dụng .....................................................................................57 KẾT LUẬN ......................................................................................................... 58 TÀI LIỆU THAM KHẢO ................................................................................... 59 4 DANH SÁCH HÌNH VẼ Hình 1: Kiến trúc tổng thể của WebRTC [3]. ..................................................... 11 Hình 2: Kiến trúc bên trong của WebRTC [8]. ................................................... 12 Hình 3: Chồng giao thức trong WebRTC [1]...................................................... 14 Hình 4: Kênh báo hiệu trong WebRTC. ............................................................. 21 Hình 5: Góc hỗ trợ khách hàng trực tuyến trên website trananh.vn. .................. 34 Hình 6: Góc hỗ trợ khách hàng trực tuyến trên website mediamart.vn. ............ 34 Hình 7: Góc hỗ trợ khách hàng trực tuyến trên website nama.vn. ..................... 35 Hình 8: Lựa chọn hỗ trợ thông qua Skype trên website trananh.vn. .................. 36 Hình 9: Trình duyệt yêu cầu khách hàng cho phép bật ứng dụng Skype trên máy tính. ...................................................................................................................... 36 Hình 10: Màn hình đăng nhập Skype trên máy tính. .......................................... 37 Hình 11: Màn hình đăng nhập Skype trên máy tính - tiếp. ................................. 37 Hình 12: Bắt đầu chat với nhân viên hỗ trợ khách hàng. .................................... 38 Hình 13: Biểu đồ trƣờng hợp sử dụng. ............................................................... 40 Hình 14: Biểu đồ tuần tự. .................................................................................... 45 Hình 15: Biểu đồ lớp. .......................................................................................... 46 Hình 16: Thiết kế wireframe cho ứng dụng web chat......................................... 47 Hình 17: Nhân viên mở trang hỗ trợ khách hàng bên trong phần quản trị của website. ................................................................................................................ 51 Hình 18: Nhân viên hỗ trợ khách hàng đăng nhập vào phòng hỗ trợ mà họ chịu trách nhiệm. ......................................................................................................... 52 Hình 19: Khách hàng xem sản phẩm và tìm đến góc hỗ trợ khách hàng. .......... 52 Hình 20: Khách hàng lựa chọn Gọi nhân viên hỗ trợ "Kinh doanh điện thoại". 53 Hình 21: Khách hàng lựa chọn kết nối với nhân viên hỗ trợ sau khi đã đăng nhập. .................................................................................................................... 53 Hình 22: Trình duyệt yêu cầu quyền truy cập tới máy ảnh và microphone........ 54 Hình 23: Nhân viên hỗ trợ nhận đƣợc yêu cầu kết nối từ khách hàng và đồng ý kết nối. ................................................................................................................. 54 Hình 24: Nhân viên hỗ trợ và khách hàng nói chuyện, chia sẻ webcam và gửi tin nhắn với nhau. ..................................................................................................... 55 Hình 25: Gửi file khi đang nói chuyện................................................................ 55 Hình 26: Nhận file và lƣu lại trên máy tính. ....................................................... 56 Hình 27: Ứng dụng chạy trên điện thoại Android với trình duyệt Chrome cho Android................................................................................................................ 56 DANH SÁCH BẢNG Bảng 1: Bảng mô tả các trƣờng hợp sử dụng. ..................................................... 43 5 BẢNG TỪ VIẾT TẮT Từ viết tắt Giải nghĩa WebRTC Web Real-Time Communications PaaS Platform as a Service PSTN Public Switched Telephone Network PLMN Public Land Mobile Network WWW World Wide Web SIP Session Initiation Protocol VoIP Voice over Internet Protocol IETF Internet Engineering Task Force W3C World Wide Web Consortium TCP Transmission Control Protocol UDP User Datagram Protocol STUN Session Traversal Utilities for NAT TURN Traversal Using Relays around NAT SDP Session Description Protocol DTLS Datagram Transport Layer Security SCTP Stream Control Transport Protocol SRTP Secure Real-Time Transport Protocol ICE Interactive Connectivity Establishment 6 MỞ ĐẦU World Wide Web (WWW hay Web) là hệ thống đƣợc biết đến rộng rãi nhất đƣợc truy cập qua Internet. Hơn nữa, đối với đa số ngƣời sử dụng Internet, từ "Internet" là tƣơng đƣơng với Web. Đối với họ, Internet là những gì bạn truy cập đƣợc thông qua trình duyệt web. Hai yếu tố này liên kết với nhau hơn nữa tại vì sự phát triển các tính năng và dịch vụ web cung cấp có tác động đến các phần khác của hệ sinh thái Internet, ví dụ các hệ thống khác, các nhà cung cấp dịch vụ, doanh nghiệp và ngƣời sử dụng. Vì lý do đó, sự phát triển của web là một thành phần quan trọng trong sự phát triển của bản thân Internet. Ban đầu các trang web, cũng nhƣ các trình duyệt web - giao diện để truy cập web chỉ có dạng văn bản đơn giản. Sau đó, một trong những cột mốc quan trọng đầu tiên trong sự phát triển của web là sự ra đời của trình duyệt web Mosaic, trong đó có một giao diện ngƣời dùng hiển thị cả đồ họa và văn bản, nó trở thành phổ biến trong các tài liệu trên web. Sau đó, sự phát triển trong các trình duyệt web hiện đại và các công nghệ hỗ trợ đã mang các nội dung đa phƣơng tiện đƣa lên web. Video và audio, hình ảnh tĩnh và hình ảnh động cùng đƣợc sử dụng trong các trang web tƣơng tác, đã trở thành một chuẩn mực. Tuy nhiên, nội dung đa phƣơng tiện chủ yếu là chỉ là nội dung tĩnh đƣợc sản xuất trƣớc đó và phát hành, sau đó đƣợc gửi lên web để đến với mục tiêu ngƣời nhận. Web, mặt khác, ngày càng trở nên một nền tảng cho truyền thông, thúc đẩy bởi sự gia tăng của các mạng xã hội, một địa điểm nơi con ngƣời có thể thể hiện bản thân và chia sẻ với bạn bè, gia đình các mảnh khác nhau trong cuộc sống của họ. Bất cứ khi nào khi thông tin liên lạc thời gian thực là cần thiết, nếu không nhờ đến sự trợ giúp của phần mềm bổ sung khác, các trang web chỉ có thể cung cấp tin nhắn tức thời dựa trên văn bản. Giao tiếp web thời gian thực (Web Real-Time Communications - WebRTC), là một nỗ lực để loại bỏ hạn chế này của web đƣợc điều hành bởi một số nhà cung cấp trình duyệt chính (Google, Mozilla, Microsoft, Opera) và các công ty nổi tiếng khác (Cisco, Ericsson, vv). WebRTC là một framework mở có khả năng giao tiếp audio và video thời gian thực, nó biến các trình duyệt web thành một nền tảng truy cập chung để giao tiếp giữa ngƣời với ngƣời. Trong khi hội thoại và video thời gian thực không phải là mới với Internet, cho đến nay nó chỉ sử dụng đƣợc trong trình duyệt web bằng cách cài 7 đặt thêm phần mềm của bên thứ ba, chẳng hạn nhƣ Adobe Flash [15] hoặc Skype plugin. WebRTC mang lại hỗ trợ cho giao tiếp thời gian thực cho các trình duyệt web và giúp các nhà phát triển web sử dụng một cách tự do thông qua Javascript API đƣợc tiêu chuẩn hóa. Cấu trúc của luận văn: Ngoài phần tóm tắt, kết luận và phụ lục. Luận văn đƣợc chia thành ba chƣơng nhƣ sau:  Chƣơng 1: Tổng quan lý thuyết. Chƣơng này đƣợc dành để nói về kiến trúc của WebRTC và các kỹ thuật đƣợc sử dụng trong nền tảng này.  Chƣơng 2: Tìm hiểu về EasyRTC framework. Chƣơng này chúng tôi tìm hiểu về một framework đƣợc xây dựng trên nền WebRTC để hỗ trợ các nhà phát triển trong việc xây dựng các ứng dụng có sử dụng WebRTC.  Chƣơng 3: Sử dụng EasyRTC framework để xây dựng ứng dụng web chat thời gian thực. Chƣơng này chúng tôi sẽ đi vào xây dựng một hệ thống web chat thời gian thực sử dụng WebRTC để hỗ trợ cho hệ thống hỗ trợ khách hàng trực tuyến của các website thƣơng mại điện tử. 8 CHƯƠNG 1: GIỚI THIỆU VỀ TRUYỀN THÔNG WEB THỜI GIAN THỰC - WEBRTC Hãy tƣởng tƣợng một thế giới nơi mà điện thoại, TV và máy tính của chúng ta đều có thể giao tiếp trên cùng một nền tảng chung. Hãy tƣởng tƣợng rằng chúng ta có thể dễ dàng thêm vào tính năng video chat và chia sẻ dữ liệu peer-to-peer cho ứng dụng web. Đó là tầm nhìn của WebRTC. Trƣớc đây khi chƣa có công nghệ WebRTC, chúng ta vẫn có thể thực hiện các cuộc gọi video, audio và chat trên trình duyệt, tuy nhiên nó đòi hỏi phải cài đặt thêm các plugin cho trình duyệt, và thậm chí cả hai ngƣời thực hiện cuộc gọi cùng phải cài đặt một loại plugin. Và nếu ngƣời sử dụng chuyển sang một máy tính khác hoặc sử dụng một trình duyệt web khác, thì lại phải cài đặt lại plugin để có thể thực hiện cuộc gọi đƣợc. Việc sử dụng plugin thƣờng hay gặp phải các vấn đề về bảo mật và gây khó khăn cho ngƣời sử dụng. Hiện tại, WebRTC là công nghệ duy nhất cho phép truyền thông thời gian thực trong trình duyệt web mà không cần cài đặt thêm bất cứ một plugin hoặc ứng dụng nào khác. WebRTC là một nỗ lực của ngành công nghiệp để đƣa khả năng truyền thông thời gian thực vào tất cả các trình duyệt web, cho phép các nhà phát triển web dễ dàng sử dụng các tính năng này thông qua các thẻ HTML5 tiêu chuẩn và các JavaScript API. Ví dụ, thực hiện một ứng dụng web có các tính năng tƣơng tự nhƣ các tính năng Skype™ cung cấp mà không cần phải cài đặt thêm bất kỳ phần mềm hay plug-in nào của bên thứ ba [1]. 1.1 Ngắn gọn về lịch sử của WebRTC Một trong những thách thức lớn nhất cho các trang web là cho phép con ngƣời giao tiếp thông qua giọng nói và video: giao tiếp thời gian thực hay RTC - Real Time Communication. Trong lịch sử, RTC đã đƣợc thực hiện một cách rất phức tạp, đòi hỏi các giấy phép công nghệ audio và video rất tốn kém hoặc các công nghệ tự phát triển riêng. Việc tích hợp công nghệ RTC với các nội dung, dữ liệu và các dịch vụ hiện có rất khó khăn và tốn nhiều thời gian, đặc biệt là trên web. 9 Gmail video chat trở nên phổ biến trong năm 2008, và vào năm 2011 Google đã giới thiệu Hangouts, nó sử dụng dịch vụ Google Talk (cũng giống nhƣ trong Gmail). Google mua lại GIPS, một công ty đã phát triển nhiều thành phần cần thiết cho RTC, chẳng hạn nhƣ các bộ codec và các kỹ thuật triệt tiếng dội. Google mở mã nguồn các công nghệ đƣợc phát triển bởi GIPS và tham gia vào các tiêu chuẩn có liên quan tại tổ chức IETF và W3C để đảm bảo sự đồng thuậncủa ngành công nghiệp [19]. WebRTC hiện nay đã thực hiện các tiêu chuẩn mở cho thời gian thực, không cần plugin chotruyền thông video, audio và dữ liệu. Nhu cầu sử dụng WebRTC là có thật:  Nhiều dịch vụ web đã sử dụng RTC, nhƣng cần phải tải về thêm các ứng dụng hoặc plugin. Trong đó bao gồm Skype, Facebook (trong đó sử dụng Skype) và Google Hangouts (sử dụng plugin Google Talk).  Tải, cài đặt và cập nhật các plugin có thể phức tạp, dễ bị lỗi và gây phiền nhiễu.  Các plugin có thể khó khăn để triển khai, gỡ lỗi, khắc phục sự cố, kiểm thử và bảo trì và nó có thể yêu cầu giấy phép và tích hợp với các công nghệ phức tạp đắt tiền. Thƣờng thì rất khó để thuyết phục mọi ngƣời cài đặt plugin ngay từ đầu. Các nguyên tắc dẫn đƣờng của dự án WebRTC là các API của nó phảilà mã nguồn mở, miễn phí, đƣợc tiêu chuẩn hóa, đƣợc xây dựng trong các trình duyệt web và phải hiệu quả hơn so với các công nghệ hiện có. WebRTC hiện tại vẫn chƣa hoàn thiện, nó vẫn đang tiếp tục đƣợc xây dựng, cả ở cấp độ API của trình duyệt và ở cấp độ giao thức. Tuy nhiên, một số trình duyệt web đã hỗ trợ hầu hết các API của WebRTC nhƣ các trình duyệt Google Chrome, Opera và Mozilla Firefox mới nhất [8]. 1.2 Kiến trúc của WebRTC Cho phép truyền thông thời gian thực trong trình duyệt là một cam kết đầy tham vọng, và có lẽ là một trong những bổ sung quan trọng nhất cho nền tảng web từ khi đƣợc hình thành cho đến nay. Với kết quả là kiến trúc WebRTC bao gồm rất nhiều tiêu chuẩn, giao thức và API mới để cho nó hoạt động:  Tổ chức W3C chịu trách nhiệm định nghĩa các APIs mới của WebRTC cho trình duyệt [2]. 10  Tổ chức IETF chịu trách nhiệm định nghĩa các giao thức, định dạng dữ liệu, bảo mật và các khía cạnh cần thiết khác để cho phép truyền thông peer-topeer trong trình duyệt [2]. Hình 1 dƣới đây mô tả kiến trúc tổng thể của WebRTC.Khối màu nhạt hơn gọi là "chức năng truyền thông thời gian thực của trình duyệt". Chức năng nàytƣơng tác với các ứng dụng web sử dụng các API tiêu chuẩn của WebRTC và nó giao tiếp với hệ điều hành thông qua trình duyệt. Máy chủ Web Máy chủ báo hiệu HTTP hoặc WebSocket HTTP hoặc WebSocket cho báo hiệu JavaScript/HTML/CSS Các API khác Trình duyệt Web Các API RTC Giao thức trên dây (cho truyền media hoặc dữ liệu) Chức năng RTC Các dịch vụ của hệ điều hành Hình 1: Kiến trúc tổng thể của WebRTC [3]. Một khía cạnh mới của WebRTC là sự tƣơng tác xảy ra giữa trình duyệt với trình duyệt, đƣợc biết đến nhƣ một kết nối peer-to-peer, nơi mà chức năng RTC trong một trình duyệt giao tiếp sử dụng các giao thức tiêu chuẩn trên dây (không phải HTTP) với chức năng RTC trong một trình duyệt khác. Trong khi truyền thôngtrên web sử dụng 11 giao thức TCP, các giao thức tiêu chuẩn trên dây đƣợc RTC sử dụng giữa các trình duyệt có thể sử dụng giao thức truyền UDP- User Datagram Protocol. Một cái mới nữa là máy chủ báo hiệu (signaling server) cung cấp các kênh báo hiệu giữa các trình duyệt trong kết nối peer-to-peer. Hình 2 dƣới đây thể hiện kiến trúc bên trong của WebRTC. Chúng ta thấy có hai tầng riêng biệt trong WebRTC [8]: 1. Các nhà phát triển trình duyệt web (nhƣ Google Chrome hoặc Mozilla Firefox) sẽ quan tâm đến các WebRTC C ++ API cho kết nối peer-to-peervà các API cho audio, video và vào/ra mạng theo ý của họ. 2. Các nhà phát triển ứng dụng web sẽ quan tâm đến các web API. Ứng dụng Web #n Ứng dụng Web #2 Ứng dụng Web #1 ... WebRTC JavaScript API (Soạn thảo bởi W3C) WebRTC WebRTC C++ API (PeerConnection) Quản lý phiên Trình duyệt Web Voice Engine iSAC / iLBC / Opus Codec Giao vận Video Engine VP8 Codec SRTP Bộ đệm jitter NetEQ Bộ đệm Video jitter Dồn kênh Bộ khử tiếng vọng/giảm tiếng ồn Tăng cường ảnh P2P STUN + TURN +ICE Audio Capture/Render Video Capture Network I/O JavaScript API cho các nhà phát triển ứng dụng Web C++ API cho các nhà phát triển trình duyệt Web API viết chồng lên được cho các nhà phát triển trình duyệt Web Hình 2: Kiến trúc bên trong của WebRTC [8]. Ứng dụng web: là ứng dụng viết trên nền web sử dụng các JavaScript API của WebRTCcho chức năng truyền thông thời gian thực nhƣ chia sẻ video, audio chat, chia sẻ file. WebRTC JavaScript API: là các API đƣợc xây dựng bởi các nhà phát triển trình duyệt web theo tiêu chuẩn đƣợc quy định bởi tổ chức W3C. Các API này đƣợc các nhà 12 phát triển ứng dụng web sử dụng để viết ra các ứng dụng web có sử dụng chức năng truyền thông thời gian thực. WebRTC C++ API: là một lớp API bên trong của WebRTC đƣợc các nhà phát triển trình duyệt web sử dụng để dễ dàng thực hiện các WebRTC JavaScript API. Khối giao vận: đảm nhiệm việc thiết lập kết nối qua các mô hình mạng khác nhau sử dụng STUN, TURN và ICE, đồng thời thực hiện việc dồn kênh và thực hiện chức năng truyền thông thời gian thực. VideoEngine: là một framework xử lý chuỗi khung hình video, từ máy ảnh vào mạng, và từ mạng tới màn hình hiển thị.VideoEngine trong WebRTC sử dụng VP8 video codec, đây là một định dạng video mở, chất lƣợng cao và miễn phí cho nền tảng web đƣợc phát triển từ dự án WebM - http://www.webmproject.org/. VideoEngine cũng sử dụng bộ đệm jitter động cho video, nó giúp che giấu những ảnh hƣởng của hiện tƣợng jitter và mất gói tin đến chất lƣợng hình ảnh tổng thể. Ngoài ra Video Engine còn có bộ tăng cƣờng ảnh, giúp loại bỏ nhiễu cho các hình ảnh thu đƣợc từ webcam. Voice Engine: là một framework xử lý chuỗi âm thanh từ card âm thanh vào mạng. Nó sử dụng iSAC, iLBC và Opus audio codec và sử dụng bộ đệm jitter động để che giấu những tác động của hiện tƣợng jitter và việc mất gói tin, trong khi giữ độ trễ thấp nhất có thể và duy trì chất lƣợng âm thanh cao nhất. Voice Engine cũng sử dụng bộ khử tiếng vọng và bộ giảm tiếng ồn để nâng cao chất lƣợng đàm thoại. 1.3 Chồng giao thức trong WebRTC Hình 3 thể hiện các giao thức đƣợc sử dụng trong WebRTC. 13 Tầng ứng dụng ICE HTTP WebSocket SRTP SDP STUN TURN Tầng giao vận TLS DTLS TCP Tầng mạng UDP SCTP IP Hình 3: Chồng giao thức trong WebRTC [1]. a) Giao thức HTTP WebRTC sử dụng giao thức HTTP - Hyper-Text Transport Protocol giống nhƣ bất kỳ ứng dụng web nào, vì vậy không cần một kiến thức đặc biệt nào về HTTP. Phiên bản hiện tại của HTTP là 1.1. IETF đang làm việc để định nghĩa phiên bản tiếp theo của HTTP, đƣợc gọi là 2.0. Giao thức này sẽ có khả năng tăng tốc độ và hiệu quả tải web và các ứng dụng. WebRTC sẽ có thể sử dụng giao thức này và bất kỳ phiên bản khác trong tƣơng lai của HTTP. b) Giao thức WebSocket WebSocket là một giao thức cung cấp các kênh truyền thông song công hoàn toàn thông qua một kết nối TCP duy nhất [11].WebSocket làm cho giao tiếp thời gian thực hiệu quả hơn vì nó giảm thiểu độ trễ để gửi/nhận thông báo giữa hai phía của kết nối [12].WebRTC sử dụng WebSocket để trao đổi thông báo giữa các trình duyệt với nhau và giữa các trình duyệt với máy chủ web để thiết lập, duy trì và ngắt kết nối. c) RTP và SRTP Giao thức quan trọng nhất đƣợc sử dụng bởi WebRTC là RTP - Real-time Transport Protocol. WebRTC chỉ sử dụng phiên bản an toàn của RTP gọi là SRTP - Secure RTP [10]. SRTP là giao thức đƣợc sử dụng để vận chuyển và mang các gói tin audio và video media giữa các WebRTC client. Các gói tin media chứa các audio hoặc các khung hình video đƣợc số hóa đƣợc tạo ra bởi một microphone hoặc máy ảnh hoặc 14 ứng dụng, và đƣợc dựng lại bởi loa hoặc màn hình hiển thị. Một thiết lập thành công một kết nối peer, cùng với việc hoàn thành trao đổi một cặp offer/answer sẽ dẫn đến một kết nối SRTP đƣợc thiết lập giữa các trình duyệt hoặc một trình duyệt và một máy chủ, và trao đổi thông tin media. SRTP cung cấp thông tin cần thiết để vận chuyển thành công và dựng hình thông tin media: các codec (coder/decoder đƣợc sử dụng để lấy mẫu và nén audio hoặc video), nguồn của các media (nguồn đồng bộ hóa hoặc SSRC), một dấu thời gian, số thứ tự (để phát hiện mất các gói dữ liệu), và các thông tin khác cần thiết để phát lại. Đối với dữ liệu không phải là audio hoặc video, SRTP không đƣợc sử dụng. Thay vào đó, một cuộc gọi đến API RTCDataChannel sẽ dẫn đến một kênh dữ liệu đƣợc mở ra giữa các trình duyệt cho phép bất kỳ định dạng dữ liệu đƣợc trao đổi. d) SDP Mô tả phiên WebRTC đƣợc mô tả bằng cách sử dụng SDP - Session Description Protocol. Một mô tả phiên SDP (mã hóa nhƣ là một đối tƣợng RTCSessionDescription) đƣợc sử dụng để mô tả các đặc điểm media của kết nối peer [9]. Có một danh sách dài và phức tạp của thông tin cần phải đƣợc trao đổi giữa hai đầu của phiên SRTP để chúng có thể giao tiếp. Lời gọi API đến RTCPeerConnection sẽ cho kết quả là một mô tả phiên SDP, một tập định dạng dữ liệu theo cách đặc biệt, đƣợc tạo ra bởi các trình duyệt và truy cập bằng cách sử dụng JavaScript bởi các ứng dụng web. Một ứng dụng muốn có kiểm soát media chặt chẽ hơn có thể thay đổi các mô tả phiên trƣớc khi chia sẻ nó với trình duyệt khác. Khi các thay đổi đƣợc thực hiện cho một kết nối peer, điều này sẽ dẫn đến thay đổi mô tả phiên mà hai bên sẽ trao đổi. Điều này đƣợc gọi là một trao đổi offer/answer. Bất kỳ nhà phát triển nào có nhu cầu kiểm soát các phiên media chi tiết hơn cần phải hiểu về SDP. Cả SRTP và SDP là hai giao thức đƣợc chuẩn hóa bởi IETF và đƣợc sử dụng rộng rãi bởi các thiết bị và dịch vụ truyền thông trên Internet, chẳng hạn nhƣ điện thoại VoIP, cácgateways, hội nghị truyền hình và các thiết bị hợp tác khác. Kết quả là, thông tin liên lạc giữa một trong những thiết bị và một WebRTC client là có thể đƣợc. Tuy nhiên, rất ít các thiết bị VoIP hoặc video hiện nay hỗ trợ đầy đủ các khả năng và các giao thức của WebRTC. Các thiết bị này sẽ cần phải đƣợc nâng cấp để hỗ trợ các giao thức mới, hoặc một chức năng gatewayđƣợc sử dụng giữa WebRTC client và VoIP hoặc video client để làm việc chuyển đổi. 15 e) STUN STUN - Session Traversal Utilities for NAT - là một giao thức đƣợc sử dụng để giúp đi qua NAT. Trong WebRTC, một STUN client đƣợc xây dựng sẵn trong user agent của trình duyệt, và các máy chủ web sẽ chạy một máy chủ STUN. Gói tin kiểm tra STUN đƣợc gửi trƣớc khi thiết lập phiên để cho phép trình duyệt biết nếu nó đang ở đằng sau một NAT và để khám phá các địa chỉ ánh xạ và cổng của nó. Thông tin này sau đó đƣợc sử dụng để xây dựng các địa chỉ ứng cử viên trong kỹ thuật ICE "hole punching". STUN có thể đƣợc vận chuyển qua UDP, TCP, hoặc TLS [1]. f) TURN TURN - Traversal Using Relays around NAT - là một mở rộng của giao thức STUN, nó cung cấp một chuyển tiếp media cho các trƣờng hợp mà ICE "hole punching" thất bại. Trong WebRTC, các user agent trong trình duyệt sẽ bao gồm một TURN client, và một máy chủ web sẽ cung cấp một máy chủ TURN. Trình duyệt yêu cầu một địa chỉ IP công cộng và số cổng nhƣ một địa chỉ chuyển tiếp vận chuyển từ máy chủ TURN. Địa chỉ này sau đó đƣợc bao gồm nhƣ là một địa chỉ ứng cử viên trong ICE "hole punching". TURN cũng có thể đƣợc sử dụng để đi qua tƣờng lửa [1]. TURN có thể đƣợc sử dụng để thiết lập địa chỉ vận chuyển chuyển tiếp sử dụng UDP, TCP, hoặc TLS. Tuy nhiên, thông tin liên lạc giữa các máy chủ TURN và TURN client (thông qua NAT) luôn luôn là UDP. g) ICE ICE - Interactive Communication Establishment - là một giao thức đƣợc tiêu chuẩn hóa bởi IETF (RFC- 5245) [17]. Giao thức ICE đƣợc dùng để thiết lập phiên media dựa trên UDP đi qua NAT. ICE cố gắng tìm ra con đƣờng tốt nhất để kết nối giữa các peer, nó thử tất cả các khả năng có thể kết nối một cách song song và lựa chọn một con đƣờngkết nối hiệu quả nhất. ICE đầu tiên cố gắng để tạo ra một kết nối bằng cách sử dụng địa chỉ thu đƣợc từ hệ điều hành và card mạng của thiết bị; nếu thất bại (có thể do thiết bị ở đằng sau một NAT), ICE lấy địa chỉ bên ngoài của thiết bị bằng cách sử dụng một máy chủ STUN, và nếu không thành công, lƣu lƣợng mạng đƣợc chuyển qua một máy chủ chuyển tiếp TURN. ICE đƣợc chạy vào lúc bắt đầu của một phiên trƣớc khi thiết lập phiên SRTP giữa các trình duyệt. Nó cũng đƣợc sử dụng để thiết lập các kênh dữ liệu không media. 16 h) TLS TLS - Transport Layer Security (các phiên bản cũ đƣợc gọi là SSL - Secure Sockets Layer), là một lớp chèngiữa TCP và các ứng dụng cung cấp các dịch vụ bảo mật và xác thực. Bảo mật đƣợc cung cấp bằng cách mã hóa các gói tin "trên dây". Xác thực đƣợc cung cấp bằng cách sử dụng giấy chứng nhận kỹ thuật số. Duyệt web an toàn ngày nay (HTTPS) chỉ sử dụng vận chuyển TLS. WebRTC có thể tận dụng lợi thế của TLS cho báo hiệu và bảo mật giao diện ngƣời dùng. Ngoài ra còn có một phiên bản của TLS chạy trên UDP, đƣợc gọi là DTLS - Datagram TLS, và một phiên bản có thể đƣợc sử dụng để tạo ra các khóa cho SRTP đƣợc gọi là DTLS-SRTP [1]. i) TCP Giao thức TCP - Transmission Control Protocol - là một giao thức lớp vận chuyển trong chồng giao thức IP, nó cung cấp vận chuyển đáng tin cậy với kiểm soát tắc nghẽn và kiểm soát luồng. TCP đƣợc sử dụng để vận chuyển trên web (HTTP), nhƣng không phù hợp để thực hiện truyền thông thời gian thực nhƣ trong RTP, tại vìviệc truyền tải lại đƣợc sử dụng để đảm bảo độ tin cậy tạo ra sự chậm trễ quá lâu. Giống nhƣ trong UDP, TCP sử dụng một khái niệm về cổng, một số nguyên 16-bit, để tách riêng các luồng và các giao thức. TCP đƣợc cung cấp bởi hệ điều hành ở bên dƣới trình duyệt [1]. j) DTLS DTLS - Datagram TLS - là một phiên bản của TLS chạy trên UDP, nó cung cấp tính bảo mật và xác thực tƣơng tự nhƣ trong TLS. UDP đi qua NAT dễ dàng hơn và có thể phù hợp hơn cho các ứng dụngpeer-to-peer. k) UDP UDP - User Datagram Protocol - là một giao thức lớp vận chuyển trong chồng giao thức IP cung cấp dịch vụ gói tin không đáng tin cậy cho các lớp phía trên. UDP thƣờng đƣợc sử dụng để vận chuyển trao đổi gói tin nhỏ và ngắn (ví dụ các gói tin DNS) hoặc để vận chuyển media thời gian thực nhƣ là RTP. UDP đƣợc cung cấp để trao đổi thông tinrất nhanh và hiệu quả; tuy nhiên, ngƣời sử dụng UDP phải đối phó với khả năng mất gói tin. Ngoài ra, UDP không có kiểm soát tắc nghẽn, vì vậy ngƣời sử dụng phải nhạy cảm với việc mất gói tin và tắc nghẽn để tránh làm quá tải các kết nối Internet. Giống nhƣ TCP, UDP sử dụng khái niệm về cổng, một số nguyên 16-bit, để phân tách các luồng và các giao thức [1]. 17 Hầu hết các ứng dụng Internet sử dụng vận chuyển đáng tin cậynhƣ là TCP, trong đó các gói dữ liệu bị mất sẽ tự động đƣợc truyền lại. Trình duyệt web, email, và dữ liệu âm thanh và video sử dụng vận chuyển đáng tin cậy. Gói tin nhận đƣợc đƣợc xác nhận, và việc thiếu một xác nhận sau một thời gian nhất định sẽ kích hoạt việc truyền lại của các gói tin cho đến khi nó đƣợc xác nhận. Thông tin liên lạc thời gian thực không thể tận dụng lợi thế của loại hình vận chuyển đáng tin cậy này do sự chậm trễ về thời gian cho việc phát hiện mất gói tin và nhận các gói tin truyền lại. Mất gói tin khi tải một trang web có thể dẫn đến việc đợi thêm một hoặc hai giây để tải đầy đủ. Một phiên giao tiếp thời gian thực không thể tạm dừng một hoặc hai giây ở giữa một cuộc trò chuyện bằng giọng nói, hoặc tạm dừng phát lại video một giây trong khi chờ đợi truyền lại các thông tin còn thiếu. Thay vào đó, hệ thống thông tin liên lạc thời gian thực chỉ cần làm tốt nhất có thể khi thông tin bị mất. Các kỹ thuật để che đậy việc mất gói tin hoặc giảm thiểu những tác động của nó đƣợc gọi là PLC - Packet Loss Conceal. Sự mất mát gói tin trung bình qua Internet là rất thấp. Mặc dù ít khi xảy ra, việc mất gói tin lại xảy ra đột ngột, dẫn đến mất gói cao hơn trong khoảng thời gian ngắn. Khả năng xử lý những sự kiện mất mát trong thời gian ngắn có tác động lớn đến chất lƣợng cảm nhận của một hệ thống thông tin liên lạc. Các codec tiên tiến, đặc biệt là các codec âm thanh Opus, đƣợc thiết kế để cung cấp một trải nghiệm ngƣời dùng tốt ngay cả khi mất gói tin cao. Ngoài ra, thông tin phản hồi thời gian thực từ ngƣời nhận media cũng cung cấp khả năng làm giảm băng thông hay độ phân giải trong quá trình tắc nghẽn gói, cung cấp một trải nghiệm ngƣời dùng tốt hơn và chia sẻ băng thông công bằng với những ngƣời sử dụng Internet khác. UDP đƣợc cung cấp bởi hệ điều hành phía dƣới trình duyệt. l) SCTP SCTP - Stream Control Transport Protocol –là một tiêu chuẩn của IETF (RFC 4960) [16] nằm ở tầng chuyên vận, nó cung cấp vận chuyển đáng tin cậy hoặc không đáng tin cậy trên IP cùng với việc kiểm soát tắc nghẽn và nhiều dòng trong một phiên. Kiểm soát tắc nghẽn là khả năng của một giao thức để cảm nhận đƣợc khi mất gói tin Internet và sự chậm trễ, và tự động điều chỉnh tốc độ gửi của mình để giảm thiểu những tác động. Nhiều dòng trong một phiên cho phép một phiên duy nhất đƣợc phân 18