Bài giảng Internet và các giao thức (TEL 1409)

y chủ CDN gần Vấn đề còn lại cần diễn giải là công ty CDN xác định máy chủ CDN “tốt nhất” như thế nào. Mặc dù mỗi công ty CDN có cách thức riêng để thực hiện điều này, không khó để thấy được ý tưởng chung của họ. Đối với mỗi ISP truy nhập trên Internet (bao gồm các máy khách yêu cầu tiềm năng) công ty CDN duy trì theo dõi máy chủ tốt nhất cho ISP truy nhập đó. Công ty CDN xác định máy chủ CDN tốt nhất dựa trên hiểu biết về bảng định tuyến Internet (đặc biệt là bảng định tuyến BGP), ước lượng thời gian RTT, và các dữ liệu đo lường khác nó có được từ các máy chủ khác nhau đến các mạng truy nhập khác nhau. Bằng cách này, CDN ước lượng máy chủ CDN nào cung cấp dịch vụ best- P T I T Chương 6. Kết nối mạng đa phương tiện 109 effort tốt nhất cho ISP. CDN thực hiện việc này cho nhiều ISP truy nhập và trên Internet và sử dụng thông tin này để cấu hình máy chủ DNS thẩm quyền. Định cỡ mạng best-effort để cung cấp chất lượng dịch vụ Trong phần trước, chúng ta đã xem xét các kỹ thuật mức ứng dụng như phát gói tin, FEC, đan xen gói tin tại trạm chủ, và triển khai hạ tầng CDN trên mạng có thể cải thiện chất lượng ứng dụng đa phương tiện trên mạng Internet hiện nay như thế nào. Về cơ bản, khó khăn trong việc hỗ trợ ứng dụng đa phương tiện phát sinh từ các yêu cầu hiệu năng nghiêm ngặt – trễ gói toàn trình, jitter, mất gói thấp – và thực tế là trễ gói, jitter, và mất gói xảy ra bất kể khi nào mạng bị nghẽn. Giải pháp cuối cùng để nâng cao chất lượng của ứng dụng đa phương tiện – giải pháp có thể hay được sử dụng để giải quyết bất cứ vấn đề nào ở trên khi nguồn tài nguyên bị giới hạn – đơn giản là “đầu tư tài chính để giải quyết vấn đề” và do đó đơn giản là tránh tranh chấp về tài nguyên. Trong trường hợp của đa phương tiện kết nối mạng, điều này có nghĩa là cung cấp dung lượng liên kết đủ lớn trong toàn mạng sao cho nghẽn mạng và hệ quả của nó là trễ và mất gói không bao giờ (hoặc rất hiếm khi) xảy ra. Với dung lượng liên kết đầy đủ, gói tin có thể truyền qua mạng Internet hiện nay mà không gặp trễ xếp hàng hay mất gói. Từ nhiều quan điểm đó chính là giải pháp lý tưởng - ứng dụng đa phương tiện có thể được thực hiện hoàn hảo, người sử dụng có thể hài lòng, và điều đó có thể đạt được mà không cần thay đổi kiến trúc best-effort của Internet. Vấn đề là dung lượng bao nhiêu là “đủ” để đạt được điều kiện này, và liệu chi phí của việc cung cấp “đủ” băng thông có thực tế từ quan điểm kinh doanh của ISP. Vấn đề cung cấp dung lượng bao nhiêu cho các liên kết mạng trên topo cho trước để đạt được mức độ hiệu năng đầu cuối nhất định thường được biết đến dưới tên cung cấp băng thông. Vấn đề thậm chí phức tạp hơn như thiết kế topo mạng như thế nào (đặt bộ định tuyến ở đâu, kết nối các bộ định tuyến bằng các liên kết như thế nào, và dung lượng nào được gán cho liên kết) để đạt được mức độ nhất định của hiệu năng đầu cuối là vấn đề thiết kế mạng và thường được gọi là định cỡ mạng. Cả hai vấn đề cung cấp băng thông và định cỡ mạng đều là các chủ đề phức tạp và không xem xét trong phạm vi môn học. Tuy nhiên, chúng ta lưu ý ở đây là các vấn đề sau phải được đưa ra để dự báo hiệu năng mức ứng dụng giữa hai điểm cuối mạng, và do đó cung cấp đủ băng thông để đáp ứng các yêu cầu hiệu năng ứng dụng: 1. Mô hình nhu cầu lưu lượng giữa các điểm đầu cuối mạng. Các mô hình cần được xác định tại cả mức cuộc gọi (tức là người sử dụng “đến” mạng và bắt đầu ứng dụng đầu cuối) và tại mức gói tin (tức là các gói tin được ứng dụng đang thực hiện tạo ra). Lưu ý rằng tải trọng có thể thay đổi theo thời gian. 2. Các yêu cầu hiệu năng được định nghĩa rõ ràng. Ví dụ, yêu cầu hiệu năng để hỗ trợ lưu lượng nhạy cảm trễ như ứng dụng audio/video tương tác có thể là xác suất trễ toàn trình của ứng dụng lớn hơn trễ cho phép tối đa phải nhỏ hơn một giá trị rất bé nào đấy. 3. Các mô hình dự báo hiệu năng toàn trình đối với mô hình tải cho trước, và các kỹ thuật tìm cách tối thiểu cấp phát băng thông giá thành cao mà vẫn đáp ứng tất cả yêu cầu người sử dụng. Ở đây, các nhà nghiên cứu sẽ phải phát triển các mô hình hàng đợi có thể định lượng P T I T Chương 6. Kết nối mạng đa phương tiện 110 hiệu năng đối với tải cho trước, và các kỹ thuật tối ưu để tìm cung cấp băng thông với chi phí tối thiểu mà vẫn đáp ứng yêu cầu hiệu năng. Giả sử Internet hiện nay có thể (từ quan điểm công nghệ) hỗ trợ lưu lượng đa phương tiện tại hiệu năng phù hợp nếu nó được định cỡ để làm việc đó, câu hỏi tự nhiên là tại sao mạng Internet không thực hiện điều này. Câu trả lời chủ yếu là vấn đề kinh tế và tổ chức. Từ quan điểm kinh tế người sử dụng có thể tự nguyện trả cho ISP của họ số tiền đủ để lắp đặt băng thông đầy đủ nhằm hỗ trợ ứng dụng đa phương tiện trên best-effort Internet không? Vấn đề tổ chức còn khó khăn hơn. Lưu ý rằng đường dẫn đầu cuối đến đầu cuối giữa hai điểm đa phương tiện sẽ đi qua mạng của nhiều ISP. Từ quan điểm tổ chức, các ISP này có tự nguyện hợp tác (có lẽ cùng chia sẻ lợi nhuận) để đảm bảo rằng đường dẫn đầu cuối đến đầu cuối được định cỡ đúng để hỗ trợ ứng dụng đa phương tiện không? Giao thức tương tác thời gian thực Các ứng dụng tương tác thời gian thực bao gồm thoại Internet và hội nghị video hứa hẹn là động lực của phát triển Internet trong tương lai. Vì vậy không có gì ngạc nhiên nếu các tổ chức tiêu chuẩn như IETF và ITU đã nhiều năm (và tiếp tục trong tương lai) xây dựng các tiêu chuẩn cho lớp ứng dụng này. Với các tiêu chuẩn phù hợp cho ứng dụng tương tác thời gian thực, các công ty độc lập sẽ có khả năng tạo ra các sản phẩm mới và hấp dẫn, đồng thời dễ dàng hoạt động tương hợp với nhau. Trong phần này chúng ta sẽ tìm hiểu các giao thức RTP, RTCP cho các ứng dụng tương tác. Tất cả các giao thức này có ứng dụng rộng rãi trong các sản phẩm và dịch vụ hiện nay. Giao thức RTP Trong phần trước chúng ta đã thấy rằng bên gửi ứng dụng đa phương tiện gắn các trường tiêu đề vào các khúc audio/video trước khi đưa chúng tới tầng truyền tải. Các trường tiêu đề này bao gồm số thứ tự và nhãn thời gian. Do phần lớn các ứng dụng kết nối mạng đa phương tiện có thể sử dụng đến số thứ tự và nhãn thời gian nên cần thiết phải có cấu trúc gói tin tiêu chuẩn bao gồm các trường cho dữ liệu audio/video, số thứ tự, và nhãn thời gian cũng như các trường có thể hữu ích khác. RTP – được định nghĩa trong RFC 3550 - là một giao thức như thế. RTP có thể được sử dụng để truyền tải các khuôn dạng chung như PCM, GSM, và MP3 cho âm thanh và MPEG và H263 cho hình ảnh. Nó cũng có thể được sử dụng để truyền tải các khuôn dạng độc quyền âm thanh và hình ảnh. Ngày nay RTP đang được triển khai rộng rãi trên hàng nghìn sản phẩm và mẫu nghiên cứu. Nó cũng là phần bổ sung cho các giao thức tương tác thời gian thực quan trọng khác, bao gồm SIP và H.323. Trong phần này chúng ta giới thiệu RTP và giao thức đi cùng với nó là RTCP. Khái niệm cơ bản RTP Thông thường RTP chạy trên UDP. Phía gửi đóng gói khúc đa phương tiện trong gói tin RTP, sau đó đóng gói gói tin vào đoạn UDP, và chuyển đoạn UDP xuống IP. Phía nhận trích lấy gói tin RTP từ đoạn UDP, sau đó trích lấy khúc đa phương tiện từ gói tin RTP, và chuyển khúc đến bộ phát phương tiện để giải mã và phát. Ví dụ, xem xét sử dụng RTP để truyền tải thoại. Giả sử nguồn thoại là mã PCM (tức là được lấy mẫu, lượng tử hóa, và số hóa) với tốc độ 64 kbps. Tiếp tục giả sử ứng dụng thu thập dữ liệu mã P T I T Chương 6. Kết nối mạng đa phương tiện 111 hóa trên các khúc 20 ms, tức là 160 byte trên một khúc. Phía gửi gắn trước mỗi khúc dữ liệu âm thanh tiêu đề RTP bao gồm loại mã hóa âm thanh, số thứ tự, và nhãn thời gian. Tiêu đề RTP thường có 12 byte. Khúc âm thanh cùng với tiêu đề RTP tạo thành gói tin RTP. Sau đó gói tin RTP được gửi tới giao diện socket UDP. Tại bên nhận ứng dụng nhận gói tin RTP từ giao diện socket. Ứng dụng trích lấy khúc audio từ gói tin RTP và sử dụng các trường tiêu đề của gói tin RTP để giải mã chính xác và phát lại khúc audio. Nếu ứng dụng kết hợp RTP – thay cho sử dụng thiết kế dành riêng để cung cấp loại tải trọng, số thứ tự, hay nhãn thời gian – thì ứng dụng sẽ dễ dàng kết hợp với các ứng dụng đa phương tiện kết nối mạng khác. Ví dụ, nếu hai công ty khác nhau phát triển phần mềm thoại Internet và cả hai kết hợp RTP trong sản phẩm của họ, có thể hi vọng rằng người dùng sử dụng một sản phẩm thoại Internet có thể sẽ truyền thông được với người dùng sử dụng sản phẩm thoại Internet kia. RTP thường được sử dụng kết hợp với các tiêu chuẩn thoại Internet. Cần nhấn mạnh rằng RTP không cung cấp bất cứ cơ chế nào để đảm bảo chuyển phát dữ liệu đúng thời gian hay cung cấp các đảm bảo chất lượng QoS khác; thậm chí nó không đảm bảo chuyển gói tin tới đích hay ngăn ngừa chuyển gói tin đến sai thứ tự. Thực vậy, đóng gói tin RTP chỉ được thấy tại các hệ thống cuối. Các bộ định tuyến không phân biệt giữa dữ liệu đồ IP mang gói tin RTP hay dữ liệu đồ IP không mang gói tin RTP này. RTP cho phép mỗi nguồn (ví dụ camera hay microphone) được gắn với dòng gói tin RTP độc lập của mình. Ví dụ, đối với hội nghị video giữa hai bên tham gia, bốn dòng RTP có thể được mở - hai dòng để truyền audio (mỗi dòng trên một hướng) và hai dòng để truyền video (mỗi dòng trên một hướng). Tuy nhiên, nhiều kỹ thuật mã hóa thông dụng – bao gồm MPEG 1 và MPEG 2 – kết hợp cả audio lẫn video vào cùng một dòng trong tiến trình mã hóa. Khi audio và video được kết hợp bằng bộ mã hóa, thì chỉ có một dòng RTP được tạo ra trên mỗi hướng. Gói tin RTP không giới hạn chỉ cho ứng dụng đơn hướng (unicast). Chúng cũng có thể được gửi trên các cây đa hướng (multicast) một điểm-đến-nhiều điểm hay nhiều điểm-đến-nhiều điểm. Đối với một phiên đa hướng nhiều điểm-đến-nhiều điểm tất cả các bên gửi của phiên và nguồn thường sử dụng cùng một nhóm đa hướng để gửi dòng RTP. Các dòng đa hướng RTP thuộc lẫn nhau, như dòng audio và video xuất phát từ nhiều bên gửi trong ứng dụng hội nghị video thuộc một phiên RTP. Các trường tiêu đề RTP Bốn trường chủ yếu của tiêu đề gói tin RTP là loại tải trọng, số thứ tự, nhãn thời gian và các trường định danh nguồn (hình 6.10). Hình Error! No text of specified style in document..35: Các trường tiêu đề RTP P T I T Chương 6. Kết nối mạng đa phương tiện 112 Trường loại tải trọng trong gói tin RTP có độ dài 7 bit. Đối với dòng audio, trường loại tải trọng được sử dụng để chỉ loại mã hóa audio (ví dụ PCM, điều chế delta thích nghi, mã hóa tuyến tính) được sử dụng. Nếu bên gửi quyết định thay đổi mã hóa trong phiên, bên gửi có thể thông báo bên nhận về thay đổi này thông qua trường loại tải trọng. Bên gửi có thể muốn thay đổi mã hóa để tăng chất lượng audio hay giảm tốc độ bit dòng RTP. Bảng 6.2 liệt kê một số loại tải trọng hiện đang được RTP hỗ trợ. Bảng Error! No text of specified style in document..4: Một số loại tải trọng audio được RTP hỗ trợ Số cuả loại tải trọng Khuôn dạng audio Tốc độ lấy mẫu Tốc độ 0 PCM µ 8 kHz 64 kbps 1 1016 8 kHz 4.8 kbps 3 GSM 8 kHz 13 kbps 7 LPC 8 kHz 2.4 kbps 9 G.722 16 kHz 48-64 kbps 14 MPEG Audio 90 kHz - 15 G.728 8 kHz 16 kbps Đối với dòng video loại tải trọng được sử dụng để chỉ loại mã hóa video (ví dụ JPEG hình ảnh động, MPEG 1, MPEG 2, H. 261). Cũng như audio, bên gửi có thể thay đổi mã hóa video trong phiên đang diễn ra. Bảng 6.3 liệt kê một số loại tải trọng video đang được RTP hỗ trợ. Bảng Error! No text of specified style in document..5: Một số loại tải trọng video được RTP hỗ trợ Số của loại tải trọng Khuôn dạng video 26 JPEG hình ảnh động 31 H.261 32 Video MPEG 1 33 Video MPEG 2 Các trường quan trọng khác là: 1. Trường số thứ tự. Trường số thứ tự có độ dài 16 bit. Số thứ tự tăng thêm một đơn vị mỗi lần có gói tin RTP được gửi đi, và bên nhận có thể sử dụng để phát hiện mất gói và lưu lại số thứ tự gói. Ví dụ, nếu bên nhận ứng dụng nhận được dòng gói tin RTP với khoảng trống số thứ tự giữa 86 và 89 thì bên nhận sẽ biết ngay gói tin số 87 và 88 bị mất. Sau đó bên nhận có thể cố gắng phục hồi dữ liệu mất này. P T I T Chương 6. Kết nối mạng đa phương tiện 113 2. Trường nhãn thời gian. Trường nhãn thời gian có độ dài 32 bit. Nó phản ánh thời điểm lấy mẫu của byte đầu tiên trong gói tin dữ liệu RTP. Như chúng ta đã thấy trong phần trên, bên nhận có thể sử dụng nhãn thời gian để loại bỏ jitter do mạng gây ra và cung cấp phát lại đồng bộ tại bên nhận. Nhãn thời gian được lấy từ đồng hồ lấy mẫu tại bên gửi. Ví dụ, đối với audio đồng hồ nhãn thời gian tăng thêm một với mỗi chu kì lấy mẫu (ví dụ mỗi khoảng 125 µs cho đồng hồ lấy mẫu 8 kHz): nếu ứng dụng audio tạo các khúc từ 160 mẫu được mã hóa thì nhãn thời gian tăng thêm 160 đối với mỗi gói tin RTP khi nguồn hoạt động. Đồng hồ nhãn thời gian tiếp tục tăng với tốc độ không đổi thậm chí nếu nguồn không hoạt động nữa. 3. Định danh nguồn đồng bộ hóa (SSRC). Trường SSRC có độ dài 32 bit. Nó định danh nguồn của dòng RTP. Thông thường mỗi dòng trong phiên RTP có SSRC phân biệt. SSRC không phải địa chỉ IP của bên gửi, mà là một số được nguồn gán ngẫu nhiên khi một dòng mới được bắt đầu. Xác suất hai dòng được gán cùng một SSRC là vô cùng nhỏ. Nếu điều này xảy ra, hai nguồn chọn một giá trị SSRC mới. Phát triển ứng dụng phần mềm với RTP Có hai giải pháp để phát triển ứng dụng kết nối mạng dựa trên RTP. Giải pháp đầu tiên là cho người phát triển ứng dụng kết hợp RTP thủ công – tức là thực sự viết mã thực hiện đóng gói gói tin RTP tại bên gửi và tháo gỡ RTP tại bên nhận. Giải pháp thứ hai là cho người phát triển sử dụng các thư viện RTP (đối với người lập trình C) và các lớp Java (đối với người lập trình Java) sẵn có, để thực hiện đóng gói và tháo gỡ cho ứng dụng. Do chúng ta có thể mong muốn tự viết ứng dụng kết nối đa phương tiện sử dụng RTP, chúng ta sẽ tìm hiểu thêm về hai giải pháp này trên ngữ cảnh truyền thông đơn hướng. Trong chương 2 chúng ta đã biết rằng UDP API yêu cầu tiến trình gửi thiết lập địa chỉ IP đích và số của cổng đích đối với mỗi đoạn UDP nó gửi đi trước khi đẩy gói tin vào socket UDP. Sau đó đoạn UDP sẽ được truyền qua Internet và cuối cùng đến cửa của tiến trình nhận ứng dụng (nếu đoạn không bị mất vì một lý do nào, như tràn bộ đệm tại bộ định tuyến). Cánh cửa này được định rõ bằng địa chỉ IP đích và số của cổng đích. Thực tế, bất cứ dữ liệu đồ IP nào chứa địa chỉ IP đích và số của cổng đích này sẽ được hướng đến cánh cửa UDP của tiến trình nhận. (UDP API cũng cho phép người phát triển ứng dụng thiết lập số của cổng nguồn UDP, tuy nhiên giá trị này không tác động đến tiến trình đoạn được gửi đi). Cần lưu ý rằng RTP không được ủy nhiệm một số cổng cụ thể nào. Khi người phát triển ứng dụng tạo một ứng dụng RTP, người phát triển xác định số của cổng cho cả hai phía của ứng dụng. Chúng ta có thể tự viết một chương trình ứng dụng. Chúng ta có thể viết trên máy chủ RTP để đóng gói các khung video lưu trữ vào các gói tin RTP. Chúng ta có thể thực hiện một cách thủ công: ứng dụng của chúng ta bắt lấy khung video, thêm các tiêu đề RTP vào khung để tạo ra gói tin RTP, và sau đó chuyển khung RTP vào UDP socket. Để làm điều đó, chúng ta sẽ cần tạo các trường giữ chỗ cho các tiêu đề RTP khác nhau, bao gồm trường số thứ tự và trường nhãn thời gian. Đối với mỗi gói tin RTP được tạo ra chúng ta sẽ phải thiết lập số thứ tự và nhãn thời gian tương ứng. Chúng ta sẽ viết mã tất cả các hoạt động RTP này vào bên gửi của ứng dụng. Trong hình 6.11 API vào mạng của chúng ta sẽ là API của UDP socket tiêu chuẩn. P T I T Chương 6. Kết nối mạng đa phương tiện 114 Hình Error! No text of specified style in document..36: RTP là một phần của ứng dụng và nằm trên socket UDP. Một giải pháp khác (không thực hiện trên việc thiết lập chương trình) là sử dụng lớp RTP của Java (hay thư viện RTP của C đối với người lập trình C) để thực hiện hoạt động RTP. Với giải pháp này (Hình 6.12) người phát triển ứng dụng có ấn tượng là RTP là một phần của lớp truyền tải, với API của RTP/UDP nằm giữa lớp ứng dụng và lớp truyền tải. Không cần đi sâu vào chi tiết (do chúng phụ thuộc vào lớp/thư viện) khi gửi khúc phương tiện vào API, bên gửi của ứng dụng cần cung cấp giao diện với khúc phương tiện, số của loại tải trọng, SSRC, và nhãn thời gian, cùng với số cổng đích và địa chỉ IP đích. Chúng ta cần biết là khung phương tiện Java (JMF) bao gồm toàn bộ việc thực hiện RTP. Hình Error! No text of specified style in document..37: RTP có thể được xem như tầng con trong tầng truyền tải Giao thức RTCP Tiêu chuẩn RFC 3550 cũng định nghĩa RTCP, ứng dụng đa phương tiện có thể sử dụng giao thức này kết hợp cùng RTP. Trong kịch bản truyền đa hướng (multicast) hình 6.13 mỗi bên tham gia trong phiên RTP truyền các gói tin RTCP tới tất cả các bên tham gia khác trong phiên sử dụng IP multicast. Đối với phiên RTP, thường có một địa chỉ multicast duy nhất và tất cả các gói tin RTP và RTCP thuộc phiên sử dụng địa chỉ multicast này. Gói tin RTP và RTCP được phân biệt với nhau thông qua sử dụng các số cổng phân biệt. (Số của cổng RTCP được thiết lập bằng số của cổng RTP cộng 1). P T I T Chương 6. Kết nối mạng đa phương tiện 115 Hình Error! No text of specified style in document..38: Cả bên gửi và bên nhận đều gửi các bản tin RTCP Các gói tin RTP không đóng gói khúc dữ liệu audio hay video. Thay vào đó các gói tin RTCP được gửi định kì và chứa các báo cáo của bên gửi và/hoặc bên nhận thông báo các thống kê có thể có ích cho ứng dụng. Các thống kê này bao gồm số gói tin được gửi đi, số gói tin bị mất, và jitter giữa các gói tin đến. Đặc tả RTP (RFC 3550) không chỉ dẫn ứng dụng phải phải làm gì với thông tin phản hồi này, mà nó sẽ phụ thuộc vào người phát triển ứng dụng. Ví dụ, các bên gửi có thể sử dụng thông tin phản hồi để thay đổi tốc độ truyền dẫn. Thông tin phản hồi có thể cũng được sử dụng cho các mục đích dự báo; ví dụ bên nhận có thể xác định liệu các vấn đề là trong phạm vi cục bộ, vùng hay toàn cầu. Các loại gói tin RTCP Đối với mỗi dòng RTP mà bên nhận nhận như một phần của phiên, bên nhận tạo ra báo cáo quá trình nhận. Bên nhận thu thập các báo cáo quá trình nhận của nó vào một gói tin RTCP duy nhất. Gói tin này được gửi đến cây multicast kết nối tất cả các bên tham gia của phiên. Báo cáo quá trình nhận bao gồm một số trường, các trường quan trọng nhất được liệt kê dưới đây: 1. SSRC của dòng RTP mà báo cáo quá trình nhận của nó được tạo lập. 2. Phần gói tin bị mất trong dòng RTP. Mỗi bên nhận tính số gói tin RTP bị mất chia cho số gói tin được gửi trên một phần của dòng. Nếu bên gửi nhận được các báo cáo quá trình nhận chỉ ra rằng bên nhận chỉ nhận được phần nhỏ các gói tin đã gửi đi thì nó có thể chuyển sang tốc độ mã hóa thấp hơn, nhằm làm giảm nghẽn mạng và cải thiện tốc độ nhận. 3. Số thứ tự cuối cùng nhận được trong dòng gói tin RTP. T I Chương 6. Kết nối mạng đa phương tiện 116 4. Jitter giữa các khoảng đến, là ước lượng gần đúng của phương sai thời gian đến giữa các gói tin liên tiếp trong dòng RTP. Đối với mỗi dòng RTP mà bên gửi đang truyền đi, bên gửi tạo và truyền các gói tin báo cáo RTCP của bên gửi. Các gói tin này bao gồm thông tin về dòng RTP: 1. SSRC của dòng RTP. 2. Nhãn thời gian và thời gian thực (đồng hồ) của gói tin mới nhất được tạo trong dòng RTP. 3. Số gói tin được truyền đi trên dòng. 4. Số byte được gửi đi trên dòng. Các báo cáo của bên gửi có thể được sử dụng để đồng bộ các dòng phương tiện trong cùng một phiên RTP. Ví dụ, xem xét ứng dụng hội nghị video trong đó mỗi bên gửi tạo ra hai dòng RTP độc lập, một dòng video và một dòng audio. Nhãn thời gian trong các gói tin RTP này liên kết chặt chẽ với đồng hồ lấy mẫu video và audio, và không liên kết với thời gian thực (đồng hồ thông thường). Đối với gói tin mới nhất được tạo ra trong dòng RTP liên quan, mỗi báo cáo bên gửi RTCP chứa nhãn thời gian của gói tin RTP và thời gian thực khi gói tin được tạo ra. Do đó các gói tin báo cáo bên gửi RTCP liên kết đồng hồ lấy mẫu với đồng hồ thời gian thực. Bên nhận có thể sử dụng liên kết này trong các báo cáo bên nhận RTCP để đồng bộ phát lại audio và video. Đối với mỗi dòng RTP bên gửi đang truyền đi, bên gửi cũng tạo và truyền các gói tin mô tả nguồn. Các gói tin này chứa thông tin về nguồn, như địa chỉ e-mail của bên gửi, tên của bên gửi, và ứng dụng tạo ra dòng RTP. Nó cũng bao gồm SSRC của dòng RTP liên quan. Các gói tin này cung cấp ánh xạ giữa định danh nguồn (tức là SSRC) và tên người sử dụng/trạm chủ. Các gói tin RTCP là có khả năng xếp chồng; nghĩa là các báo cáo quá trình nhận của bên nhận, các báo cáo bên gửi, và mô tả nguồn có thể ghép với nhau trong cùng một gói tin. Sau đó gói tin tổng hợp này được đóng gói vào đoạn UDP và chuyển vào cây multicast. Băng thông RTCP Chúng ta có thể để ý thấy rằng RTCP có thể có vấn đề về qui mô. Ví dụ, xem xét phiên RTP bao gồm một bên gửi và một số lượng lớn bên nhận. Nếu mỗi bên nhận định kì tạo các gói tin RTCP thì tốc độ truyền tổng thể của gói tin RTCP có thể vượt xa tốc độ gửi gói tin RTP của bên gửi. Quan sát rằng lượng lưu lượng RTP gửi vào cây multicast không thay đổi nếu số lượng bên nhận tăng, trong khi đó lượng lưu lượng RTCP tăng tuyến tính với số lượng bên nhận. Để giải quyết vấn đề qui mô này, RTCP điều chỉnh tốc độ các bên tham gia gửi gói tin RTCP vào cây multicast như một hàm số của số lượng bên tham gia trong phiên. Do mỗi bên tham gia gửi các gói tin điều khiển đến bất cứ ai nên bên tham gia có thể ước lượng tổng số bên tham gia vào phiên. RTCP cố gắng hạn chế lưu lượng không quá 5% của băng thông phiên. Ví dụ, giả sử có một bên gửi, gửi video tốc độ 2 Mbps. RTCP cố gắng hạn chế lưu lượng không quá 5% của 2 Mbps (tức là 100 kbps) như sau. Giao thức dành 75% tốc độ này hay 75 kbps cho các bên nhận, và 25% còn lại của P T I T Chương 6. Kết nối mạng đa phương tiện 117 tốc độ hay 25 kbps cho bên gửi. 75 kbps dành cho các bên nhận được chia sẻ đều cho tất cả bên nhận. Vì vậy, nếu có R bên nhận thì mỗi bên nhận gửi lưu lượng RTCP với tốc độ là 75/R kbps, và bên gửi gửi lưu lượng RTCP với tốc độ 25 kbps. Một bên tham gia (bên gửi hay bên nhận) xác định chu kì truyền gói tin RTCP bằng cách tính toán động kích cỡ gói tin RTCP trung bình (trên toàn bộ phiên) và chia kích cỡ gói tin RTCP trung bình cho tốc độ ấn định của nó. Cuối cùng, chu kì truyền gói tin RTCP đối với bên gửi là 𝑇 = số lượng bên gửi 25.0,5.𝑏ă𝑛𝑔 𝑡ℎô𝑛𝑔 𝑝ℎ𝑖ê𝑛 (kích cỡ gói tin RTCP trung bình) Và chu kì truyền gói tin RTCP đối với bên nhận là 𝑇 = số lượng bên nhận 75.0,5.𝑏ă𝑛𝑔 𝑡ℎô𝑛𝑔 𝑝ℎ𝑖ê𝑛 (kích cỡ gói tin RTCP trung bình) P T I T Chương 7. Xu hướng phat́ triển ứng dụng và dic̣h vụ trên nền Internet 118 XU HƯỚNG PHAT́ TRIÊN̉ ỨNG DỤNG VÀ DIC̣H VỤ TRÊN NỀN INTERNET Equation Section (Next) Xu hướng hội tụ và mạng NGN Xu hướng phat́ triển mạng toàn IP Công nghệ IP được xây dựng trên nền tảng giao thức IP. Giao thức này được xây dựng với mục đích truyền tải dữ liệu giữa các máy tính trong một mạng liên kết các máy tính với nhau thông qua một số cơ chế định tuyến gói tin cụ thể. Hoạt động chủ yếu của giao thức IP là thực hiện phân chia khối dữ liệu cần gửi đi thành các gói tin có khuôn dạng được chuẩn hóa và truyền chúng vào mạng. Các gói tin được định tuyến truyền trên mạng để tới được đích bằng cách áp dụng các giải thuật định tuyến xác định với một số tiêu chí định tuyến nào đó. Bản chất của công nghệ IP là cung cấp phương thức truyền tải phi kết nối (connectionless). Do vậy, phương thức truyền tải này xét ở phạm vi mạng của nhà cung cấp dịch vụ là phương thức truyền tải không mang tính tin cậy cao, ứng dụng truyền tải trên mạng IP mang tính “nỗ lực tối đa” (best – effort). Sau đây là một số đặc điểm nổi bật của công nghệ mạng trên nền IP. Ưu điểm 1. Với phương thức chuyển gói mềm dẻo, các giao thức định tuyến áp dụng trong công nghệ IP cho phép truyền tải lưu lượng với hiệu suất cao, tận dụng băng thông truyền tải, do đó tiết kiệm được dung lượng kênh truyền dẫn. 2. Phần lớn các phần mềm ứng dụng thực hiện trao đổi dữ liệu mạng trong các sản phẩm máy tính cá nhân, máy chủ, các thiết bị định tuyến đều được thiết kế để có thể chạy trên nền IP. Đây là một lợi thế rất lớn của công nghệ này. 3. Các giải thuật định tuyến ứng dụng trong công nghệ IP cho phép trao đổi dữ liệu trong môi trường liên mạng một cách mềm dẻo, linh hoạt. 4. Công nghệ IP cho phép khả năng tích hợp đa dịch vụ. Dựa trên nền tảng giao thức IP, người sử dụng có thể kiến tạo rất nhiều ứng dụng và loại hình dịch vụ khác nhau cũng như các dịch