GIỚI THIỆU
Tổng quan về công nghệ WebRTC
Ý tưởng phát triển WebRTC được nhóm kỹ sư Google Hangouts khởi xướng từ năm 2009, nhằm thay thế công nghệ Flash thường được sử dụng để truyền tải video và hình ảnh trên web Nhóm này đã quyết định phát triển một chuẩn riêng thay vì tiếp tục sử dụng Flash Đến năm 2010, Google đã mua lại hai công ty On2 và Global IP Solutions (GIPS) để tiếp cận công nghệ truyền dữ liệu thời gian thực, cung cấp các bộ codec và kỹ thuật loại bỏ tiếng vang, làm nền tảng cho WebRTC.
Vào tháng 5/2011, Google đã giới thiệu dự án mã nguồn mở WebRTC nhằm cải thiện giao tiếp thời gian thực giữa các trình duyệt Cùng thời điểm đó, Hiệp hội W3C và Tổ chức IETF cũng phát triển các giao thức cho kết nối thời gian thực, hợp tác để hoàn thiện và tích hợp vào WebRTC.
Ngày 27/10/2011, Hiệp hội W3C ra mắt bản “nháp” đầu tiên của WebRTC Tháng 11/2011, Chrome 23 ra mắt, trở thành trình duyệt đầu tiên có tích hợp WebRTC ngay từ bên trong
Công nghệ WebRTC vẫn đang tiếp tục được phát triển và liên tục cập nhật.
WebRTC là gì?
WebRTC là viết tắt của cụm từ Web Real-Time Communication.
Theo Arin Sime, CEO của AgilityFeat.com tại Charlottesville, Virginia, đã định nghĩa WebRTC một cách ngắn gọn và súc tích.
“WebRTC là một tiêu chuẩn HTML5 cho mã hóa peer-to-peer (P2P) trao đổi video, âm thanh và dữ liệu, trực tiếp giữa hai máy tính”
Các tính năng nổi bật nhất của WebRTC đó là được tích hợp trực tiếp vào trình duyệt, và chúng ta dùng HTML5 và Javascript để sử dụng nó.
WebRTC không chỉ là một sản phẩm hay API đơn lẻ, mà là một tập hợp các hàm đa dạng cho lập trình viên Các hàm này phục vụ nhiều mục đích, từ việc yêu cầu quyền truy cập vào webcam và microphone, đến việc thiết lập kết nối giữa hai người dùng Ngoài ra, WebRTC còn hỗ trợ chia sẻ màn hình và thực hiện cuộc gọi video, chức năng quan trọng nhất của nó.
WebRTC là một bộ API cho phép thực hiện các tác vụ theo thời gian thực, không chỉ giới hạn trong việc gọi video giữa hai trình duyệt Nó hỗ trợ nhiều tính năng giao tiếp giữa hai hoặc nhiều người dùng Công nghệ này được hỗ trợ chính thức bởi các hãng lớn như Google, Mozilla và Opera.
Phương pháp của WebRTC
Trước khi WebRTC ra đời, việc phát triển ứng dụng web đa phương tiện thường dựa vào Flash, Java Applet và các plugin của bên thứ ba, điều này gây khó khăn trong triển khai và bảo trì Sự phức tạp này đã thúc đẩy nhu cầu tìm kiếm giải pháp đơn giản và hiệu quả hơn cho các ứng dụng đa phương tiện, đặc biệt khi người dùng hiện nay có thể truy cập Internet mọi lúc mọi nơi WebRTC đã được phát triển để khắc phục những vấn đề này, với khả năng tích hợp các Voice Engine và Video Engine hàng đầu, đồng thời được triển khai trên hàng triệu thiết bị mỗi năm.
Những lợi ích của WebRTC:
- Giảm giá thành: chi phí triển khai và hỗ trợ IT thấp vì không cần cài đặt phần mềm client đặc biệt nào phía client
WebRTC loại bỏ nhu cầu sử dụng các plugin bên thứ ba như Flash hay Java Applets để xây dựng ứng dụng web tương tác đa phương tiện Người dùng không còn phải tải xuống và cài đặt các plugin cho nội dung đa phương tiện, cũng như không cần lo lắng về sự tương thích với các hệ điều hành và nền tảng khác nhau.
- Truyền thông P2P: trong đa phần các trường hợp, truyền thông được thiết lập trực tiếp giữa trình duyệt, không cần có những điểm trung gian.
- Dễ sử dụng: có thể dễ dàng tích hợp tính năng WebRTC trong dịch vụ web/trang web bằng cách sử dụng JavaScript APIs, những framework đã có sẵn
- Một giải pháp cho mọi nền tảng: không cần phát triển những phiên bản dịch vụ web cho những nền tảng khác nhau (Windows, Android, IOS…)
WebRTC là một dự án mã nguồn mở do Google phát triển, được hỗ trợ bởi các công ty quốc tế như Mozilla, Google và Opera Nhờ vào sự cộng tác của cộng đồng toàn cầu, người dùng có thể phát hiện và khắc phục lỗi một cách nhanh chóng và hoàn toàn miễn phí.
- Built-in security: WebRTC quy định mọi dữ liệu truyền P2P đều được bảo mật và mã hóa.
Cấu trúc đặt điểm của WebRTC
1.4.1 Các hàm API của WebRTC
WebRTC có ba loại hàm API thường được dùng:
- getUserMedia: truy cập vào camera và microphone của người dùng
- RTCpeerConnection: gửi và nhận dữ liệu hình ảnh, giọng nói
- RTCdataChannel: gửi và nhận dữ liệu không phải là hình ảnh, giọng nói giữa ứng dụng/trình duyệt.
1.4.2 Tính an toàn, bảo mật của công nghệ WebRTC
Công nghệ WebRTC sử dụng giao thức bảo mật DTLS và SRTP để đảm bảo an toàn cho các ứng dụng truyền thông DTLS (Data Transport Layer Security) ngăn chặn nghe trộm, giả mạo và tin nhắn giả mạo, đồng thời xử lý hiệu quả khi mất gói tin mà không gây chậm trễ Giao thức SRTP (Secure Real-time Transport Protocol) đảm bảo tính bảo mật, toàn vẹn và xác thực cho các thông điệp trong môi trường truyền thông như âm thanh và hình ảnh, đồng thời tối ưu hóa việc sử dụng tài nguyên thông qua cơ chế quản lý khóa ngoài.
- Mã hóa là bắt buộc đối với tất cả các thành phần WebRTC, bao gồm các cơ chế báo hiệu (signaling)
WebRTC không cần plugin, vì các thành phần của nó hoạt động trong sandbox của trình duyệt Điều này có nghĩa là người dùng không phải cài đặt thêm gì, và các thành phần sẽ tự động được cập nhật cùng với trình duyệt.
TỔNG QUAN VỀ WEBRTC
Kiến trúc WebRTC
2.1.1 Giao tiếp peer to peer Để có thể giao tiếp lẫn nhau thông qua trình duyệt web, mỗi trình duyệt của user phải thực hiện những bước sau đây:
- Đồng ý để bắt đầu giao tiếp
- Biết cách xác định vị trí của đối tượng
- Vượt qua an ninh và tưởng lửa bảo vệ
- Chuyển giao tất cả các giao tiếp đa phương tiện theo real-time
Một trong những thách thức lớn nhất trong giao tiếp P2P trên trình duyệt là xác định vị trí và thiết lập kết nối socket mạng với một trình duyệt khác để truyền tải dữ liệu hai chiều Bài viết này sẽ phân tích những khó khăn trong việc thiết lập kết nối này.
Khi webapp cần dữ liệu hoặc tài nguyên, nó sẽ lấy từ các server Tuy nhiên, để tạo ứng dụng video chat kết nối trực tiếp giữa các trình duyệt, chúng ta gặp khó khăn vì không biết địa chỉ của trình duyệt khác, do đó không thể thiết lập kết nối P2P mà không có các yếu tố cần thiết.
Máy tính thường không sở hữu địa chỉ IP công cộng tĩnh, vì chúng cần phải được bảo vệ bởi tường lửa và thiết bị NAT (Network Access Translation - Bộ phiên dịch truy cập mạng).
Thiết bị NAT chuyển đổi địa chỉ IP cá nhân bên trong tường lửa thành địa chỉ IP công khai, giúp bảo mật và khắc phục sự hạn chế của IPv4 về số lượng địa chỉ IP công khai có sẵn Do đó, các ứng dụng web không nên giả định rằng thiết bị hiện tại luôn có một địa chỉ IP công khai tĩnh.
Khi bạn kết nối vào mạng WiFi công cộng, máy tính của bạn sẽ nhận được một địa chỉ IP nội bộ, ví dụ như 172.0.23.4, nhưng địa chỉ IP mà thế giới bên ngoài thấy lại khác, chẳng hạn như 164.53.27.98 Điều này có nghĩa là các yêu cầu từ thiết bị của bạn sẽ được gửi từ địa chỉ 164.53.27.98, trong khi thiết bị NAT sẽ đảm bảo rằng các phản hồi sẽ được chuyển đúng về địa chỉ 172.0.23.4 của bạn, nhờ vào các bảng ánh xạ (mapping table) quan trọng.
IP thì cổng (port) cũng là điều kiện cần thiết cho các giao tiếp mạng.
Để thiết bị NAT hoạt động hiệu quả, trình duyệt cần xác định địa chỉ IP của máy tính mà bạn muốn giao tiếp Điều này được thực hiện thông qua các server STUN (Session Traversal Utilities for NAT) và TURN (Traversal Using Relays around NAT) Khi công nghệ WebRTC được triển khai, một yêu cầu sẽ được gửi đến server STUN để hỏi địa chỉ IP công cộng của bạn Server này sẽ phản hồi với địa chỉ IP mà nó nhận được từ máy tính của bạn, giúp xác định kết nối mạng một cách chính xác.
Nếu tiến trình diễn ra suôn sẻ, bạn sẽ nhận được địa chỉ IP công cộng và số cổng của mình, cho phép bạn hướng dẫn các peer ngang hàng khác cách kết nối trực tiếp với bạn Các peer này cũng có thể áp dụng STUN và server TURN để thông báo cho bạn địa chỉ liên lạc phù hợp.
2.1.3 Tín hiệu, phiên, giao thức
Quá trình khám phá thông tin mạng chỉ là một phần trong chủ đề Signaling, đặc biệt quan trọng trong WebRTC, nơi signaling dựa trên chuẩn JSEP (Giao thức thiết lập phiên của Javascript) Signaling bao gồm khám phá mạng, NAT Traversal, tạo và quản lý phiên, bảo mật giao tiếp, siêu dữ liệu và phối hợp khả năng của media, cũng như xử lý lỗi Để kết nối hoạt động, peer cần thu thập thông tin về local media và các địa chỉ mạng khả thi cho ứng dụng Tuy nhiên, cơ chế signaling để truyền tải thông tin này không được định nghĩa trong API của WebRTC.
Signaling không được quy định trong chuẩn WebRTC và không được triển khai qua API của nó, cho phép linh hoạt trong việc sử dụng các công nghệ và giao thức khác nhau Các nhà phát triển WebRTC cần xử lý signaling và quản lý server cho quá trình này.
Ứng dụng WebRTC trên trình duyệt của bạn có khả năng xác định địa chỉ IP công khai thông qua STUN Sau đó, bước tiếp theo là tiến hành đàm phán và thiết lập phiên kết nối với peer.
Phần đàm phán và thiết lập phiên bắt đầu khi sử dụng một giao thức signaling được xác định trong các giao tiếp đa phương tiện Giao thức này không chỉ quản lý quy trình khởi tạo phiên mà còn điều hành các quy định liên quan đến việc quản lý và hủy bỏ phiên.
Một trong những giao thức khởi tạo phiên quan trọng là Session Initiation Protocol (SIP) Tuy nhiên, do tính linh hoạt của WebRTC signaling, SIP không phải là giao thức signaling duy nhất có thể sử dụng Giao thức signaling được chọn cần tương thích với giao thức ở tầng ứng dụng gọi là Session Description Protocol (SDP), được áp dụng trong WebRTC Tất cả các metadata đa phương tiện cụ thể được truyền tải thông qua giao thức SDP này.
Bất kỳ peer nào (ví dụ: app tận dụng WebRTC) thử giao tiếp với 1 peer khác đều sinh ra 1 tập các ứng viên giao thức Interactive Connectivity Establishment (ICE
Những ứng viên thiết lập kết nối tương tác thể hiện một bộ kết hợp gồm địa chỉ IP, port và giao thức vận chuyển Cần lưu ý rằng một máy tính có thể sở hữu nhiều giao diện mạng, bao gồm cả không dây và có dây, do đó có thể được gán nhiều địa chỉ khác nhau.
IP cho mỗi giao diện.
Hình 2.1 Mô hình sự trao đổi trong việc kết nối
Mỗi peer đầu tiên cần thiết lập địa chỉ IP công khai để tạo ra kênh dữ liệu signaling, nhằm xác định các peer và hỗ trợ quá trình đàm phán peer-to-peer cũng như thiết lập phiên.
Thế giới bên ngoài hoàn toàn không biết hoặc không thể truy xuất đến những
"kênh" này và nó cũng yêu cầu 1 định danh duy nhất nếu muốn truy cập.
WebRTC có tính linh động cao và tiến trình signaling không được quy định cụ thể trong các tiêu chuẩn, dẫn đến sự khác biệt trong ý tưởng và cách thực hiện "kênh" tùy thuộc vào công nghệ sử dụng Một số giao thức có thể giao tiếp mà không cần cơ chế "kênh".
Chúng ta sẽ giả sử rằng "kênh" được dùng trong việc triển khai cho các mục đích được nhắc tới ở bài viết này.
Ứng dụng WebRTC trong Live Boadlive
2.2.1 WebRTC trong thế giới thực
Trong thế giới thực thì WebRTC cần có server, tuy nhiên thực tế lại đơn giản hơn:
- Các user tự khám phá ra đối tác của họ và trao đổi các chi tiết chẳng hạn như tên.
- Các ứng dụng WebRTC phía client (các peer) trao đổi thông tin mạng.
- Các peer trao đổi dữ liệu về media chẳng hạn như định dạng hình ảnh và độ phân giải.
- Các ứng dụng WebRTC phía client di chuyển xuyên qua các cổng NAT và tường lửa.
- Nói cách khác, WebRTC cần phải có 4 tính năng ở phía server:
- User khám phá ra và giao tiếp.
- Di chuyển NAT/tường lửa
- Các server chuyển tiếp trong trường hợp giao tiếp peer-to-peer thất bại.
Giao thức STUN và bản mở rộng TURN của nó là các công cụ quan trọng trong việc kích hoạt RTCPeerConnection thông qua ICE, giúp xử lý các vấn đề liên quan đến di chuyển NAT và những thay đổi mạng không xác định.
Như đã nhắc đến trước đó, ICE là 1 giao thức để kết nối các peer, chẳng hạn như
Hai ứng dụng video chat client sử dụng ICE để thiết lập kết nối trực tiếp giữa các peer với độ trễ thấp nhất thông qua UDP Trong quá trình này, server STUN đóng vai trò quan trọng trong việc kích hoạt một peer nằm sau NAT để xác định địa chỉ công cộng.
Hình 2.3 Hoạt động WebRTC trong thế giới thực
2.2.2 Tìm ứng viên kết nối
Khi UDP không thành công, ICE sẽ chuyển sang thử TCP, bắt đầu với HTTP và sau đó là HTTPS Nếu kết nối trực tiếp không khả thi do NAT và tường lửa doanh nghiệp, ICE sẽ sử dụng một server TURN làm điểm chuyển tiếp Cụ thể, ICE sẽ ưu tiên sử dụng STUN với UDP để kết nối trực tiếp các peer, và nếu không thành công, sẽ chuyển sang phương án sử dụng server TURN Quá trình "tìm kiếm ứng viên" đề cập đến việc tìm kiếm các giao diện mạng và port.
Hình 2.4 Sơ đồ cách thức tìm ứng viên kết nối
Có rất nhiều cách mà 1 ứng dụng hoặc plugin giao tiếp real-time có thể bị ảnh hưởng về bảo mật Ví dụ:
- Dữ liệu hoặc media không được mã hóa có thể bị chặn trên đường đi giữa các trình duyệt hay giữa trình duyệt và server
- Một ứng dụng có thể ghi chép và phân phối âm thanh, hình ảnh mà user hoàn toàn không biết
- Malware hoặc virus máy tính có thể được cài đặt cùng với 1 ứng dụng hoặc plugin vớ vẩn.
- WebRTC có nhiều tính năng để tránh các vấn đề trên:
- WebRTC triển khai sử dụng các giao thức bảo mật chẳng hạn như DTLS và SRTP
- Mã hóa là điều cần thiết đối với tất cả các component của WebRTC, bao gồm cả cơ chế signaling.
WebRTC không phải là một plugin; các thành phần của nó hoạt động trong môi trường an toàn của trình duyệt mà không cần chạy trên một luồng riêng Điều này có nghĩa là người dùng không cần cài đặt từng thành phần riêng lẻ, và chúng sẽ tự động được cập nhật cùng với các bản cập nhật của trình duyệt.
Việc truy xuất camera và microphone cần phải được cấp quyền một cách rõ ràng Khi camera hoặc microphone đang hoạt động, trạng thái này phải được hiển thị rõ ràng trên giao diện người dùng.
WebRTC là 1 công nghệ cực kỳ thú vị & mạnh mẽ dành cho các sản phẩm cần làm việc với mô hình truyền tải real-time giữa các trình duyệt.
SessionStack cho phép người dùng tích hợp thư viện JavaScript vào ứng dụng web của họ Nhiệm vụ chính của thư viện này là thu thập dữ liệu như sự kiện người dùng, thay đổi trên DOM, thông tin mạng, lỗi và thông báo gỡ lỗi, sau đó gửi những dữ liệu này về máy chủ.
Người dùng có thể truy cập webapp và theo dõi phiên làm việc của họ theo thời gian thực SessionStack sử dụng dữ liệu thu thập được để tái tạo mọi hoạt động trên trình duyệt, kết hợp hình ảnh và một bộ giả lập console Điều này tương tự như desktop từ xa nhưng không yêu cầu người dùng tải về chương trình nào Hơn nữa, người dùng có thể xem các thông tin kỹ thuật chi tiết từ phiên làm việc.
TRIỂN KHAI XÂY DỰNG ỨNG DỤNG
Nội dung thực hiện
- Viết code một ứng dụng web có giao diện cơ bản với chức năng gọi video bằng ngôn ngữ HTML.
- Tích hợp API vào chương trình.
- Download thư viện có sẵn, cài vào chương trình.
- Viết một server signal có sự hỗ trợ của công cụ SocketIO.
- Đưa ứng dụng lên heroku.
- Upload giao diện ứng dụng lên trang localhost và tạo một đường dẫn như sau: http://localhost:3000/
3.1.2 Ngôn ngữ thực hiện và các thư viện thực hiện
- Chương trình sử dụng các ngôn ngữ Javascript, HTML viết trên nền tảng NodeJS.
- Sử dụng một số thư viện và công cụ có sẵn của NodeJS như: Jquery, PeerJS, SocketIO.
3.1.3 Các bước thực hiện cuộc gọi
Các bước thực hiện chương trình được mô tả theo sơ đồ sau:
Hình 3.1 Sơ đồ tổng quan thứ tự các nội dung thực hiện chương trình
Server chỉ đóng vai trò như một server đơn lẻ, có chức năng chuyển tiếp tin nhắn giữa hai thiết bị kết nối Khi hai thiết bị đã kết nối, chúng giao tiếp theo hình thức peer to peer, cho phép dữ liệu được truyền trực tiếp giữa chúng mà không cần thông qua server.
Mô tả chức năng của chương trình:
- Hiển thị user đang hoạt động
- Gọi video khi chọn vào User đang hoạt động
- Tắt kết nối sau cuộc gọi
- Tắt trạng thái hoạt động.
Các hàm sử dụng
Các hàm sử dụng chính:
- OnStream(): có chức năng mở webcam và micro của thiết bị.
- const congfig = { audio: false, video: true };
- return navigator.mediaDevices.getUserMedia(congfig);
- PlayStream(): truyền luồng (Stream) âm thanh và hình ảnh. function playStream(idVideoTag, stream) { const video = document.getElementById(idVideoTag); video.srcObject = stream; video.play();
- Các hàm jquery bắt sự kiện click vào các button trên giao diện.
$('#ulUser').on('click','li', function()
Khi người dùng đăng ký thành công, giao diện chương trình sẽ hiển thị và tài khoản sẽ được cấp phát một giá trị peerID từ peer-server Lệnh socket.emit('NGUOI_DUNG_DANG_KI', { ten: userName, peerId: id }); sẽ được thực hiện để gửi thông tin này.
Nếu bạn gặp thông báo "Đăng kí thất bại", điều này có thể do tài khoản đã tồn tại với tên đăng kí tương tự Hãy chọn một tên người dùng khác để hoàn tất quá trình đăng kí.
- Hiển thị danh sách Online: Sau khi đăng kí sẽ thấy các tài khoản khác đang hoạt động. socket.on('DANH_SACH_ONLINE', arrUserInfo => {
Khi có người dùng mới, hệ thống sẽ tự động hiển thị người dùng đó trong danh sách hoạt động Sự kiện này được xử lý qua socket với mã lệnh: socket.on('CO_NGUOI_DUNG_MOI', user => { const { ten, peerId } = user; });.
$('#ulUser').append(`
Khi tài khoản bị ngắt kết nối, giá trị PeerID sẽ bị xóa và không còn hiển thị trong danh sách trực tuyến.
- Sự kiện cuộc gọi đi: khi click vào tài khoản đang hoạt động, thực hiện theo mục 2.c (Các bước thực hiện cuộc gọi).
Phân tích sự kiện chính
Tên user case Tên Broadcaster
Sự kiện kích hoạt Đăng nhập tài khoản
1 Người dùng nhập tên tài khoản
1 Đăng kí thất bại, tài khoản tồn tại
Bảng 3.1 Sự kiện tạo Broadcaster
Tên user case Tên User viewer
Sự kiện kích hoạt Đăng nhập tài khoản
1 Người dùng nhập tên tài khoản
1 Đăng kí thất bại, tài khoản tồn tại
Bảng 3.2 Sự kiện tạo User viewer 3.3.3 Sự kiện Live
Sự kiện kích hoạt Người dùng tạo phòng live
1 Người dùng tạo phòng live
3 Đăng kí thất bại, phòng live tồn tại
Bảng 3.3 Sự kiện Live 3.3.4 Sự kiện tham gia Live
Tên user case Tham gia live
Sự kiện kích hoạt Người dùng nhập tên phòng để tham gia buổi live Luồng sự kiện chính:
1 Người dùng tham gia buổi live
3 Đăng nhập thất bại, phòng live không tồn tại
Bảng 3.4 Sự kiện tham gia Live
3.3.5 Sự kiện kết thúc live
Tên user case Tham gia live
Sự kiện kích hoạt Người dùng nhập tên phòng để tham gia buổi live Luồng sự kiện chính:
1 Người dùng tham gia buổi live
3 Đăng nhập thất bại, phòng live không tồn tại
Bảng 3.5 Sự kiện tham gia Live 3.3.6 Sự kiện thoát Live
Tên user case Thoát Live
Sự kiện kích hoạt Người dùng rời khỏi buổi live
1.Người dùng rời khỏi buổi live
2.Tắt kết nối giữa các thiết bị
3.Trở về trạng thái ban đầu
1 Tắt trạng thái hoạt động của thiết bị trên hệ thống
Bảng 3.6 Sự kiện thoát khỏi live.
DEMO
Giao diện tạo phòng live
Hình 4.2 Giao diện chương trình khi tạo phòng live
Giao diện Viewer nhập phòng live
Hình 4.4 Giao diện Viewer nhập phòng live
Giao diện Viewer tham gia live
Hình 4.5 Giao diện Viewer tham gia Live
TỔNG KẾT
Thực tế, WebRTC hiện tại đang rất phổ biến, được các trang web lớn sử dụng, có thể ứng dụng vào các mô hình web cá nhân, doanh nghiệp
Nhờ nỗ lực của các thành viên trong nhóm, chúng em đã hiểu rõ hơn về kiến thức và khả năng áp dụng vào các bài toán thực tế Tuy nhiên, vẫn còn nhiều hạn chế và thiếu sót cần khắc phục.
Những việc chúng em đã làm được:
- Chúng em đã tạo ra được 1 website Broadcast live tương đối hoàn chỉnh
- Có thể nhiều người xem 1 lúc
- Nhiều người cũng có thể live trong cùng 1 thời điểm
- Tốc độ kết nối nhanh
- Hình ảnh tương đối sắc nét
Những việc chúng em chưa làm được:
- Giao diện website chưa hoàn chỉnh
Chúng tôi nhận thấy rằng hệ thống hiện tại vẫn còn một số tính năng hạn chế Trong tương lai, chúng tôi cam kết sẽ nỗ lực cải thiện những điểm còn thiếu sót và bổ sung nhiều tính năng mới để nâng cao trải nghiệm người dùng.
- Cải thiện giao diện website
- Cải thiện chất lượng hình ảnh
- Cải thiện những thiết xót của hệ thống
- Tìm tòi, phát triển hệ thống ngày một tốt hơn
- Cố gắng đưa hệ thống phổ biến đến với mọi người
Chúng em mong nhận được những đóng góp ý kiến, nhận xét của Thầy Cô và các bạn.Nhóm chúng em xin chân thành cảm ơn !
DANH MỤC TÀI LIỆU THAM KHẢO
