CHƢƠNG 2 GIẢI PHÁP KỸ THUẬT WEBRTC
2.4. CÁC GIAO THỨC MẠNG TRUYỀN THÔNG THỜI GIAN THỰC
Đầu tiên, một điểm then chốt của truyền tải dữ liệu thời gian thực là giao thức mạng sử dụng để truyền tải nó tới ngƣời dùng khác. WebRTC sử
dụng giao thức UDP để truyền tín hiệu, dữ liệu đi. Trong WebRTC các ứng dụng chia sẻ audio và video đƣợc thiết kế với mục đích làm giảm thiểu khả năng mất mát gói tin liên tục trong một thời gian dài. Các cơng cụ mã hóa gói tin audio và video có thể thêm, hay bổ sung những phần gói tin bị thiếu, bị mất trong quá trình truyền tải, một phần dữ liệu nhỏ. Nhƣ vậy, các ứng dụng phải sử dụng logic để phục hồi các dữ liệu bị mất hay bị trì hỗn.
Hình 2.6. Ngăn xếp giao thức WebRTC
Yêu cầu tính tức thời quan trọng hơn độ tin cậy nên đó là lý do chính tại sao giao thức UDP là một giao thức truyền thông tốt để truyền các dữ liệu thời gian thực trong WebRTC. TCP cũng đƣợc sử dụng bởi tính đáng tin cậy và đúng tuần tự của nó, nếu gói tin trung gian bị mất trong quá trình truyền, dữ liệu sẽ đƣợc truyền lại với cơ chế hạn chế tắc nghẽn đƣờng truyền.
UDP là nền tảng trong giao tiếp thời gian thực trong trình duyệt nhƣng để đáp ứng tất cả các yêu cầu khắt khe của WebRTC, trình duyệt cũng cần rất nhiều giao thức giao vận và dịch vụ khác hỗ trợ nó. Hình 2.8 mơ tả ngăn xếp các giao thức và dịch vụ hỗ trợ trình duyệt trong WebRTC, trong đó:
ICE
ICE là một giao thức đƣợc tiêu chuẩn hóa bởi IETF (RFC- 5245) [2]. Giao thức ICE đƣợc dùng để thiết lập phiên media dựa trên UDP đi qua NAT một cách nhanh nhất.
Cũng giống nhƣ các hệ thống VoIP, WebRTC bị cản trở khi tạo kết nối peer-to-peer bởi tƣờng lửa và NAT. WebRTC sử dụng giao thức ICE để tạo kênh giao tiếp giữa các peer nhờ STUN và TURN server [12]. 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 đƣờng kết nối hiệu quả nhất. Đầu tiên, ICE thử kết nối trực tiếp giữa hai peer 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 server.
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.
STUN
STUN (Session Traversal Utilities for NAT) là một giao thức mạng cho phép các máy khách tìm ra địa chỉ cơng khai của mình, loại NAT mà chúng đang đứng sau và cổng phía Internet đƣợc NAT gắn liền với cổng nội bộ nào đó. Thơng tin này đƣợc sử dụng để thiết lập giao tiếp UDP giữa 2 host mà đều nằm sau NAT router. Giao thức STUN đƣợc định nghĩa trong RFC 5389 [13]. 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].
TURN
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 [7].
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.
SCTP và SRTP
Giao thức quan trọng nhất đƣợc sử dụng bởi WebRTC là RTP. WebRTC chỉ sử dụng phiên bản an toàn của RTP gọi là SRTP [2]. 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 ứ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.
SDP
Mô tả phiên WebRTC đƣợc mô tả bằng cách sử dụng SDP. 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 [7]. 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 số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, 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.
TLS
TLS (các phiên bản cũ đƣợc gọi là SSL - Secure Sockets Layer), là một lớp chèn giữ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. 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. Ngồ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].
DTLS
DTLS 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ụng peer-to-peer.
ICE, STUN và TURN server rất cần thiết để thiết lập và duy trì kết nối ngang hàng giữa các trình duyệt. Giao thức DTLS đƣợc thiết kế sử dụng trong WebRTC để ngăn chặn việc nghe trộm, giả mạo, để đảm bảo tất cả các dữ liệu đƣợc truyền giữa các peer trong kết nối peer-to-peer. Và SCTP, SRTP đƣợc sử dụng để ghép các luồng khác nhau, điều khiển tắc nghẽn và kiểm soát lƣu lƣợng. Hai giao thức này cung cấp một số tính năng dịch vụ giống với TCP và UDP cụ thể đó là một thơng điệp định hƣớng nhƣ UDP và đảm bảo tin cậy, trong chuỗi truyền tải thông tin với sự điểu khiển tắc nghẽn nhƣ TCP. Do đó, nó là bổ sung khác cho UDP cho việc truyền tin, dữ liệu audio – video [10].
WebRTC sử dụng giao thức UDP ở tầng giao vận bởi cho rằng độ trễ và tức thời là rất quan trọng. UDP không cung cấp sự tin cậy và thứ tự truyền nhận mà TCP làm, các gói dữ liệu có thể đến khơng đúng thứ tự hoặc bị mất mà khơng có bất kỳ một thơng báo nào. Tuy nhiên UDP nhanh và hiệu quả hơn rất nhiều đối với các mục tiêu có kích thƣớc nhỏ và yêu cầu khắt khe về thời gian. Vì thế những ứng dụng phổ biến sử dụng giao thức UDP nhƣ ứng dụng streaming media, Voice over IP, Trivial File Transfer Protocol (TFTP), game trực tuyến và tất nhiên giao tiếp thời gian thực nền Web – WebRTC sử dụng nó [14].
Hình 2.7. Phân phối audio video qua SRTP trên UDP