Báo cáo thực hành môn mạng máy tính

ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO MÔN
MẠNG MÁY TÍNH
Đề tài:
MULTIMEDIA NETWORKING
NHÓM : 6
LỚP : 12TLT.CNTT
GVHD : ThS. NGUYỄN VÕ QUANG ĐÔNG
Đà Nẵng, 2014
Báo Cáo Môn Mạng Máy Tính
THÀNH VIÊN TRONG NHÓM
1/ Nguyễn Hà Anh
2/ Lê Long Bảo
3/ Phan Hữu Phát
4/ Nguyễn Mạnh Huy
5/ Phan Tuấn Vũ
6/ Đoàn Văn Dũng
7/ Trương Thế Anh
8/ Đàm Thanh Hậu
9/ Huỳnh Quốc Nha
10/ Đỗ Thị Phượng
11/ Trần Viết Cường
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 2
Báo Cáo Môn Mạng Máy Tính
MỤC LỤC
THÀNH VIÊN TRONG NHÓM 2
1/ Nguyễn Hà Anh 2
2/ Lê Long Bảo 2

3/ Phan Hữu Phát 2
4/ Nguyễn Mạnh Huy 2
MỤC LỤC 3
DANH MỤC HÌNH ẢNH 5
6.1.CÁC ỨNG DỤNG MẠNG ĐA PHƯƠNG TIỆN 6
6.1.1.Các ví dụ của ứng dụng đa phương tiện 6
6.1.2.Những trở ngại cho đa phương tiện trên Internet 8
6.1.3.Internet nên phát triển như thế nào để hỗ trợ đa phương tiện tốt hơn 9
6.1.4.Âm thanh và video nén 10
6.2.LƯU TRỮ ÂM THANH VÀ VIDEO TRỰC TUYẾN 14
6.2.1.Truy cập âm thanh và video từ máy chủ web 16
6.2.2.Gửi đa phương tiện từ luồng server đến ứng dụng hỗ trợ 18
6.2.3.Giao thức truyền dòng dữ liệu thời gian thực 21
6.3.LÀM TỐT NHẤT DỊCH VỤ BEST EFFORT – MỘT VÍ DỤ VỀ ĐIỆN
THOẠI INTERNET 26
6.3.1.Những hạn chế của một dịch vụ Best-Effort 27
6.3.2.Loại bỏ biến động nhận được cho âm thanh 29
6.3.3.Phục hồi gói tin bị mất 33
6.3.4.Luồng lưu trữ âm thanh và video 37
6.4.GIAO THỨC RTP 39
6.4.1.Cơ bản về RTP 39
6.4.2.Trường tiêu đề trong gói tin RTP 42
6.4.3.RTP giao thức điều khiển (RTCP) 44
6.4.4.H.323 47
6.5.BEYOND BEST EFFORT 54
6.6.BỘ ĐỊNH THỜI VÀ CƠ CHẾ KIỂM SOÁT LƯU LƯỢNG MẠNG 61
6.6.1.Các cơ chế bộ định thời 62
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 3
Báo Cáo Môn Mạng Máy Tính
6.6.2.Cơ chế điều khiển lưu lượng mạng 67

6.7.DỊCH VỤ TÍCH HỢP 72
6.7.1.Bảo đảm chất lượng của dịch vụ 74
6.7.2.Kiểm soát băng thông mạng 75
6.8.RSVP 76
6.8.1.Bản chất của RSVP 76
6.8.2.Một vài ví dụ đơn giản 79
6.8.3.Tin nhắn đường dẫn 81
6.8.4.Các kiểu đặt chỗ 82
6.8.5.Vận chuyển các tin nhắn đặt chỗ: 85
6.9.DỊCH VỤ CHÊNH LỆCH 87
6.9.1.Công nghệ phân lập dịch vụ ( giao thức Diffserv, dịch vụ phân biệt or
phân loại dịch vụ ): một kịch bản đơn giản 88
6.9.2.Phân loại lưu lượng và điều chỉnh 90
6.9.3.Per-Hops Behavior ( tác động chặn) 93
TÓM TẮT 97
BÀI TẬP VỀ NHÀ VÀ CÂU HỎI THẢO LUẬN CHƯƠNG 6 100
CÂU HỎI ÔN TẬP 100
BÀI TOÁN 101
CÂU HỎI THẢO LUẬN 105
BẢNG PHÂN CÔNG CÔNG VIỆC NHÓM 6 106
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 4
Báo Cáo Môn Mạng Máy Tính
DANH MỤC HÌNH ẢNH
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 5
Báo Cáo Môn Mạng Máy Tính
6.1. CÁC ỨNG DỤNG MẠNG ĐA PHƯƠNG TIỆN
6.1.1. Các ví dụ của ứng dụng đa phương tiện
Internet chứa một lượng lớn các ứng dụng đa phương tiện thú vị. Chúng ta xác
định ba lớp của các ứng dụng đa phương tiện
- Luồng âm thanh và video đã lưu trữ

Trong lớp này của các ứng dụng , client yêu cầu theo yêu cầu âm thanh nén hoặc file
video, được lưu trữ trên các máy chủ . Đối với âm thanh, các tập tin này có thể chứa
một bài giảng giáo sư , những bản nhạc rock, giao hưởng, tài liệu lưu trữ của chương
trình phát thanh nổi tiếng , cũng như ghi âm lưu trữ lịch sử
Đối với video, những tập tin này có thể chứa video của bài giảng giáo sư, phim với
đầy đủ độ dài, chương trình truyền hình được ghi âm , tài liệu, lưu trữ video của sự
kiện lịch sử ,ghi hình sự kiện thể thao, phim hoạt hình và âm nhạc video clip. Bất cứ
lúc nào một client cũng có thể yêu cầu một tập tin audio hay video từ một máy chủ .
Trong hầu hết các ứng dụng âm thanh / video lưu trữ được lưu trữ tồn tại, sau một vài
giây bị trễ, client bắt đầu để phát lại các tập tin âm thanh trong khi nó vẫn tiếp tục
nhận được các tập tin từ máy chủ. Các tính năng phát lại âm thanh hoặc video trong
khi tập tin đang được nhận được gọi là streaming.
Nhiều sản phẩm hiện có cũng cung cấp cho người sử dụng tương tác, ví dụ như : tạm
dừng / tiếp tục và nhảy thời gian đến trước và sau của các tập tin âm thanh.Trì hoãn từ
khi người dùng tạo một yêu cầu (ví dụ, yêu cầu để nghe một tập tin âm thanh hoặc bỏ
qua hai phút về phía trước) cho đến khi hành động thể hiện ở các máy chủ sử dụng (ví
dụ, người sử dụng bắt đầu nghe tập tin âm thanh) nên về trình tự từ 1 đến 10 giây cho
đáp ứng chấp nhận được. Yêu cầu đối với gói sự chậm trễ và sự bồn chồn không phải
là nghiêm ngặt như đối với các ứng dụng thời gian thực như điện thoại Internet
và hội nghị truyền hình thời gian thực (xem bên dưới). Có rất nhiều sản phẩm trực
tuyến để lưu trữ audio / video, bao gồm cả RealPlayerfrom RealNetworksand
NetShowfrom Microsoft.
- Một đến nhiều luồng âm thanh và video thời gian thực :
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 6
Báo Cáo Môn Mạng Máy Tính
Lớp này của các ứng dụng tương tự như phát sóng bình thường của đài phát thanh và
truyền hình, ngoại trừ việc truyền tải diễn ra trên Internet.Các ứng dụng này cho phép
người dùng nhận được tín hiệu của một đài phát thanh và truyền hình phát ra từ bất kỳ
nơi trên thế giới. (Ví dụ, một trong những tác giả của cuốn sách này thường lắng nghe
yêu thích của mình Đài phát thanh Philadelphia từ nhà của ông ở Pháp.) Microsoft

cung cấp một đài phát thanh Internet hướng dẫn.
Thông thường, có nhiều người sử dụng đồng thời nhận được chương trình âm thanh/
video thời gian thực giống nhau. Lớp này của các ứng dụng là không tương tác, một
client không thể kiểm soát được lịch trình truyền tải của máy chủ. Như với streaming
của lưu trữ đa phương tiện, yêu cầu cho sự chậm trễ gói và sợ bồn chồn không phải là
nghiêm ngặt như đối với điện thoại Internet và hội nghị truyền hình thời gian thực.
Sự chậm trễ lên đến hàng chục giây từ khi người dùng nhấp chuột vào một liên kết cho
đến khi phát lại âm thanh / video bắt đầu có thể được bỏ qua.Việc phân phối âm thanh
/ video theo thời gian thực đến nhiều người nhận là một cách hiệu quả khi thực hiện
với multicast, tuy nhiên, như các văn bản này, hầu hết các hệ một-nhiều âm thanh /
video truyền trên Internet được thực hiện với dòng unicast riêng biệt cho mỗi người
nhận.
- Tương tác âm thanh và video thời gian thực:
Lớp này của các ứng dụng cho phép người sử dụng âm thanh / video để giao
tiếp với nhau trong thời gian thực. Thời gian thực âm thanh tương tác thường được gọi
là điện thoại Internet, từ đó, từ quan điểm của người sử dụng, nó tương tự như dịch vụ
điện thoại chuyển mạch kênh truyền thống. Điện thoại Internet có khả năng cung cấp
tổng đài, địa phương và dịch vụ điện thoại đường dài với chi phí rất thấp
Nó cũng có thể tạo thuận lợi cho việc hội nhập máy tính điện thoại (được gọi là
CTI), nhóm thông tin liên lạc thời gian thực, dịch vụ thư mục, nhận dạng người gọi,
người gọi lọc, vv .Có nhiều sản phẩm điện thoại Internet hiện đã có.Với video tương
tác thời gian thực, còn được gọi là hội nghị truyền hình, các cá nhân giao tiếp trực
quan giống như nói miện. Trong một cuộc họp nhóm, người dùng có thể mở một cửa
sổ cho mỗi người tham gia người sử dụng muốn nhìn thấy. Ngoài ra còn có nhiều các
sản phẩm video tương tác thời gian thực, hiện có sẵn cho Internet, bao gồm
Netmeeting của Microsoft.
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 7
Báo Cáo Môn Mạng Máy Tính
Lưu ý rằng trong ứng dụng tương tác âm thanh / video thời gian thực, một
người sử dụng có thể nói chuyện hay di chuyển bất cứ lúc nào. Sự chậm trễ từ khi

người dùng nói hoặc di chuyển cho đến khi hành động được thể hiện tại các máy chủ
tiếp nhận nên được ít hơn một vài trăm mili giây. Đối với giọng nói, sự chậm trễ nhỏ
hơn 150 mili giây không được nhận thấy bởi người nghe, sự chậm trễ giữa 150 và 400
mili giây có thể chấp nhận được, và sự chậm trễ quá 400 mili giây cho kết quả không
tốt nếu đàm thoại hoàn toàn không đáng tin cậy.
6.1.2. Những trở ngại cho đa phương tiện trên Internet
IP , giao thức tầng mạng Internet, cung cấp dịch vụ băng thông tốt nhất cho tất
cả các gói dữ liệu nó mang . Nói cách khác, Internet cố gắng tốt nhất để di chuyển mỗi
gói tin từ người gửi đến người nhận một cách càng nhanh càng tốt. Tuy nhiên , dịch vụ
tốt nhất dù cố gắng không thực hiện bất kỳ lời hứa nào về sự chậm trễ end-to -end cho
các gói cá nhân. Dịch vụ cũng không thực hiện bất kỳ lời hứa về sự biến đổi của
pakcet trì hoãn trong một dòng gói tin.
Như chúng ta đã học ở Chương 3, bởi vì TCP và UDP chạy qua IP , không phải
của các giao thức này có thể thực hiện bất kỳ sự chậm trễ đảm bảo cho các ứng dụng
gọi . Do thiếu của bất kỳ đặc biệt nỗ lực để cung cấp các gói tin một cách kịp thời , nó
là vấn đề extermely thách thức để phát triển thành công các ứng dụng mạng đa phương
tiện cho mạng Internet. Đến nay, đa phương tiện trên Internet đã đạt được thành công
đáng kể nhưng hạn chế. Ví dụ, cửa hàng trực tuyến audio / video với sự chậm trễ
người dùng tương tác năm đến mười giây bây giờ là phổ biến trên mạng Internet.
Nhưng trong thời gian cao điểm , hiệu suất có thể không đạt yêu cầu , đặc biệt là khi
liên kết can thiệp là các liên kết bị tắc nghẽn (ví dụ như tắc nghẽn liên kết xuyên đại
dương ). Điện thoại internet và video thời gian thực tương tác đã, cho đến nay, được ít
thành công hơn trực tuyến audio / video lưu trữ. Thật vậy, tương tác giọng nói và
video thời gian thực áp đặt những hạn chế cứng nhắc về sự chậm trễ gói và jitter gói.
Gói jitteris sự thay đổi của sự chậm trễ gói trong luồng gói tin đó. Thời gian thực thoại
và video có thể làm việc tốt ở vùng có băng thông là phong phú, và do đó sự chậm trễ
và jitter được tối thiểu. Nhưng chất lượng có thể xấu đi đến mức không thể chấp nhận
ngay khi giọng nói hoặc gói phim chơi thời gian thực truy cập một liên kết tắc nghẽn.
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 8
Báo Cáo Môn Mạng Máy Tính

Việc thiết kế các ứng dụng đa phương tiện chắc chắn sẽ đơn giản hơn nếu
chúng là một số loại các dịch vụ Internet lớp một và lớp2, theo đó các gói tin của lớp
đầu tiên được giới hạn về số lượng và luôn luôn được ưu tiên trong hàng đợi định
tuyến. Đối với dịch vụ lớp một như vậy có thể được thỏa đáng cho sự chậm trễ nhạy
cảm các ứng dụng. Nhưng cho đến nay, Internet đã hầu như thực hiện một cách tiếp
cận giống nhau với gói lập lịch trong hàng đợi định tuyến: tất cả các gói nhận được
dịch vụ như nhau, không có gói tin, bao gồm cả gói dữ liệu âm thanh và video nhạy
cảm với trễ, nhận được bất kỳ ưu tiên trong hàng đợi định tuyết. Không cần biết là bạn
có bao nhiêu tiền hoặc bạn quan trọng như thế nào, bạn phải tham gia phần cuối của
dòng và đợi đến lượt của bạn!
Vì vậy, cho thời gian được, chúng tôi phải sống với các dịch vụ nỗ lực tốt nhất.
Không có vấn đề như thế nào quan trọng hoặc làm thế nào giàu chúng tôi, các gói tin
của chúng tôi phải đợi đến lượt của họ trong hàng đợi router. Nhưng với hạn chế này,
chúng ta có thể làm cho một số quyết định thiết kế và sử dụng một vài thủ thuật để cải
thiện với người sử dụng cảm nhận chất lượng của một đa phương tiện ứng dụng kết
nối mạng. Ví dụ, chúng ta có thể gửi âm thanh và video trên UDP, và do đó phá vỡ
thông thấp TCP khi TCP đi vào giai đoạn chậm bắt đầu của nó. Chúng ta có thể trì
hoãn phát lại tại nhận 100 msecs hoặc nhiều hơn để giảm bớt những ảnh hưởng của
jitter mạng gây ra. chúng ta có thể gói dấu thời gian ở người gửi để nhận biết khi các
gói dữ liệu cần được phát lại. Cho lưu trữ âm thanh / video chúng ta có thể Prefetch dữ
liệu trong quá trình phát lại khi lưu trữ và băng thông khách hàng thêm là có sẵn.
Chúng tôi thậm chí có thể gửi thông tin dự phòng để giảm thiểu ảnh hưởng của mạng
gây ra mất gói tin. Chúng tôi sẽ điều tra rất nhiều các kỹ thuật trong chương này.
6.1.3. Internet nên phát triển như thế nào để hỗ trợ đa phương tiện tốt hơn
Ngày nay có một cuộc tranh luận khác thường và đôi khi dữ dội về cách
Internet nên phát triển như thế nào để đáp ứng tốt hơn lưu lượng truy cập đa phương
tiện với thời gian hạn chế cứng nhắc của nó. Ở một bên quan điểm, một số nhà nghiên
cứu cho rằng nó không cần thiết để thực hiện bất kỳ thay đổi cơ bản đến dịch vụ của
nỗ lực tốt nhất và các giao thức Internet cơ bản
Thay vào đó, theo những phần tử cực đoan, nó chỉ là cần thiết để thêm băng

thông nhiều hơn cho các liên kết (cùng với bộ nhớ đệm cho mạng thông tin được lưu
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 9
Báo Cáo Môn Mạng Máy Tính
trữ và hỗ trợ multicast cho một-nhiều thời gian thực trực tuyến). Đối thủ để quan điểm
này cho rằng băng thông bổ sung có thể tốn kém, và ngay sau khi nó được đưa ra nó sẽ
được ăn tăng băng thông ứng dụng đói mới (ví dụ, video độ nét cao theo yêu cầu)
Ở quan điểm khác, một số nhà nghiên cứu cho rằng những thay đổi cơ bản phải
được thực hiện với Internet để các ứng dụng có thể dự trữ băng thông đầu cuối một
cách rõ ràng. Các nhà nghiên cứu cảm nhận , ví dụ,rằng nếu người dùng muốn thực
hiện cuộc gọi điện thoại Internet từ máy chủ A đến máy chủ của B , sau đó điện thoại
Internet của người sử dụng ứng dụng sẽ có thể dự trữ một cách rõ ràng băng thông
trong mỗi liên kết dọc theo tuyến đường từ máy chủ A để lưu trữ B. Nhưng cho phép
các ứng dụng để thực hiện đặt chỗ và yêu cầu mạng để tôn vinh đặt đòi hỏi một số
thay đổi lớn . Đầu tiên chúng ta cần một giao thức , thay mặt các ứng dụng, dự trữ
băng thông từ người gửi đến người nhận của họ. Thứ hai, chúng ta cần phải sửa đổi
chính sách kế hoạch trong hàng đợi router để đặt băng thông có thể được tôn trọng.
Với những chính sách lập lịch trình mới , tất cả các gói tin không còn được đối xử bình
đẳng , thay vào đó , những dự trữ đó (và trả tiền ) hơn nhận được nhiều hơn . Thứ ba ,
trong đặt để tôn vinh đặt , các ứng dụng cần để cung cấp cho mạng mô tả về giao
thông họ có ý định gửi vào mạng. Sau đó các mạng phải cảnh sát giao thông của mỗi
ứng dụng để làm chắc chắn rằng nó tuân thủ để mô tả. Cuối cùng , mạng phải có một
phương tiện xác định xem nó có đủ băng thông có sẵn để hỗ trợ bất kỳ yêu cầu đặt
phòng mới . Các cơ chế này , khi kết hợp , yêu cầu phần mềm mới và phức tạp trong
các máy chủ và thiết bị định tuyến cũng như các loại dịch vụ mới .
6.1.4. Âm thanh và video nén
Trước khi âm thanh và video có thể được truyền qua mạng máy tính, nó phải
được số hóa và nén. Nhu cầu số hóa là rõ ràng: mạng máy tính truyền bit, do đó tất cả
các thông tin được truyền đi phải được biểu diễn như là một chuỗi các bit. Nén rất
quan trọng vì không nén âm thanh và video sẽ tiêu thụ một lượng lớn dung lượng lưu
trữ và băng thông; loại bỏ các cố hữu dư thừa trong số hóa tín hiệu âm thanh và video

có thể giảm đơn đặt hàng của các cường độ lượng dữ liệu mà cần phải được lưu trữ và
truyền đi. Ví dụ, một hình ảnh duy nhất bao gồm 1024 pixel x 1024 pixel với mỗi
điểm ảnh được mã hóa thành 24 bist đòi hỏi 3 MB dung lượng lưu trữ mà không cần
nén. Nó sẽ mất bảy phút để gửi hình ảnh này trên một liên kết 64 Kbps. Nếu hình ảnh
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 10
Báo Cáo Môn Mạng Máy Tính
được nén ở mức khiêm tốn 10:01 tỉ lệ nén, các yêu cầu lưu trữ giảm xuống còn 300
KB và thời gian truyền giảm xuống dưới 6 giây.
Các lĩnh vực âm thanh và nén video là rất lớn.Khu vực hoạt động có hơn 50
năm nghiên cứu, và hiện nay có hàng trăm kỹ thuật và các tiêu chuẩn phổ biến cho cả
âm thanh và nén video. Hầu hết các trường đại học cung cấp toàn bộ các khóa học về
nén âm thanh và video, và thường cung cấp một khóa học riêng về âm thanh nén và
một khóa học riêng biệt về nén video. Hơn nữa, kỹ thuật và khoa học máy tính ngành
điện thường xuyên cung cấp các khóa học độc lập về đề tài này, với mỗi bộ phận tiếp
cận chủ đề từ một góc độ khác nhau. Do đó chúng tôi chỉ cung cấp ở đây một cách
ngắn gọn và cao cấp giới thiệu về chủ đề này.
Nén âm thanh trên Internet
Một tín hiệu âm thanh analog liên tục thay đổi (có thể bắt nguồn từ lời nói hoặc
âm nhạc) là bình thường chuyển đổi thành một tín hiệu kỹ thuật số như sau:
Tín hiệu âm thanh analog là lần đầu tiên lấy mẫu tại một số lãi suất cố định, ví
dụ, 8.000 mẫu mỗi giây. Các giá trị của mỗi mẫu là một số thực tùy ý.
Mỗi mẫu là sau đó "làm tròn" với một trong một số hữu hạn các giá trị. Hoạt động này
là gọi là "lượng tử". Số các giá trị hữu hạn - gọi là giá trị lượng tử - là
thường là một sức mạnh của 2, ví dụ, 256 giá trị lượng tử. Mỗi giá trị lượng tử được
đại diện bởi một số cố định của các bit. Ví dụ, nếu có 256 lượng tử hóa các giá trị, sau
đó mỗi giá trị - và do đó mỗi mẫu - được đại diện bởi 1 byte. Môi của các mẫu được
chuyển thành đại diện bit của nó. Cơ quan đại diện bit của tất cả các mẫu được nối với
nhau để tạo thành các đại diện kỹ thuật số của tín hiệu.
Ví dụ, nếu một tín hiệu âm thanh analog được lấy mẫu tại 8.000 mẫu mỗi giây,
mỗi mẫu là lượng tử hóa và biểu diễn bởi 8 bit, sau đó các tín hiệu kỹ thuật số kết quả

sẽ có một tỷ lệ 64.000 bit mỗi thứ hai . Tín hiệu kỹ thuật số này sau đó có thể được
chuyển đổi trở lại - tức là , giải mã - một tín hiệu tương tự để phát lại.
Tuy nhiên, tín hiệu tương tự được giải mã thường là khác nhau từ các tín hiệu âm
thanh gốc . bằng cách tăng tỷ lệ lấy mẫu và số lượng các giá trị lượng tử hóa tín hiệu
giải mã có thể gần đúng (và thậm chí được chính xác bằng) các tín hiệu tương tự ban
đầu. Do đó , có một sự cân bằng rõ ràng giữa chất lượng của tín hiệu giải mã và các
yêu cầu lưu trữ và băng thông của tín hiệu kỹ thuật số. Các kỹ thuật mã hóa cơ bản mà
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 11
Báo Cáo Môn Mạng Máy Tính
chúng ta vừa mô tả được gọi là Pulse Code Modulation (PCM) . bài phát biểu
mã hóa thường sử dụng PCM, với một tỷ lệ lấy mẫu 8000 mẫu mỗi thứ hai và 8 bit cho
mỗi mẫu , đưa ra một tỷ lệ 64 kbs . Disk nhỏ gọn âm thanh ( CD ) cũng sử dụng PCM,
mà không có một tỷ lệ lấy mẫu của 44.100 mẫu mỗi thứ hai với 16 bit cho mỗi mẫu ,
điều này cho tốc độ 705,6 Kbps cho mono và 1.411 Mbps cho âm thanh stereo .Một tỷ
lệ bit của 1.411 Mbps cho âm nhạc stereo vượt quá tốc độ truy cập nhất , và thậm chí
64 kbps cho bài phát biểu vượt quá tốc độ truy cập cho một người dùng modem dial-
up. Vì những lý do , PCM mã hóa giọng nói và âm nhạc là hiếm khi được sử dụng
trong Internet. Kỹ thuật thay vì nén được sử dụng để làm giảm tốc độ bit của dòng
suối.Kỹ thuật nén phổ biến cho các bài phát biểu bao gồm GSM (13 Kbps ) , G.729
(8.5 Kbps ) và G.723 ( cả hai 6.4 và 5.3 Kbps ) , và cũng có một số lượng lớn các kỹ
thuật độc quyền, bao gồm cả những người sử dụng bởiRealNetworks . Một kỹ thuật
nén phổ biến cho gần nhạc stereo chất lượng CD là MPEG Layer 3, thường được gọi
là MP3 . MP3 nén tốc độ bit cho âm nhạc đến 128 hoặc 112 Kbps, và sản xuất rất ít sự
xuống cấp âm thanh . Một tập tin MP3 có thể được chia thành từng mảnh, và mỗi phần
vẫn là có thể chơi được . Định dạng tập tin không đầu này cho phép các file nhạc MP3
để được xem trực tiếp qua mạng Internet (giả sử các bitrate phát và tốc độ kết nối
Internet tương thích ) . MP3 tiêu chuẩn nén là phức tạp, nó sử dụng mặt nạ tâm lý học ,
dự phòng giảm và bit đệm hồ chứa.
Nén video trên Internet
Một đoạn video là một chuỗi các hình ảnh, với mỗi hình ảnh thường được hiển

thị với một tốc độ không đổi, ví dụ 24 hoặc 30 hình mỗi giây . Một nén, mã hóa hình
ảnh kỹ thuật số bao gồm một loạt các điểm ảnh, với mỗi điểm ảnh được mã hóa thành
một số bit để respresent độ sáng và màu sắc. Có hai loại dư thừa trong video, cả hai
đều có thể được khai thác để nén . Dư thừa không gian là dư thừa trong một hình ảnh
nhất định. Ví dụ, một hình ảnh bao gồm chủ yếu là không gian trắng có thể hiệu quả
nén. Dự phòng thời gian phản ánh sự tái diễn từ hình ảnh đến hình ảnh tiếp theo.Ví dụ,
một hình ảnh và hình ảnh tiếp theo là giống hệt nhau, không có lý do tái mã hóa các
hình ảnh tiếp theo , đó là hiệu quả hơn chỉ đơn giản là chỉ ra trong quá trình mã hóa
hình ảnh tiếp theo được chính xác như nhau . Các tiêu chuẩn nén MPEG là một trong
những kỹ thuật phổ biến nhất nén . Chúng bao gồm MPEG 1 cho video chất lượng đĩa
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 12
Báo Cáo Môn Mạng Máy Tính
CD-ROM ( 1,5 Mbps) , MPEG2 cho video DVD chất lượng cao (3-6 Mbps) và MPEG
4 cho nén video hướng đối tượng. Tiêu chuẩn MPEG thu hút rất nhiều từ JPEG chuẩn
nén hình ảnh. Các tiêu chuẩn nén video H.261 cũng rất phổ biến trong các Internet ,
cũng rất nhiều tiêu chuẩn độc quyền.Độc giả quan tâm đến việc học thêm về âm thanh
và video mã hóa được khuyến khích để xem [ Rao ] và [ Solari ].
Tài liệu tham khảo
[ Rao ] K.R. Rao và J.J. Hwang , kỹ thuật và tiêu chuẩn cho hình ảnh, Video và Audio
Coding ,
Prentice Hall , 1996
[ Solari ] S.J. Solari , video kỹ thuật số và âm thanh nén , McGraw Hill văn bản, năm
1997.
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 13
Báo Cáo Môn Mạng Máy Tính
6.2. LƯU TRỮ ÂM THANH VÀ VIDEO TRỰC TUYẾN
Trong những năm gần đây, audio/video trực tuyến trở nên phổ biến với nhiều
ứng dụng và là thành phần tiêu thụ chính về băng thông mạng. Chúng ta hy vọng xu
hướng này vẫn tiếp tục với một vài lý do sau. Thứ nhất, giá thành của đĩa cứng đang
giảm theo xu hướng, thậm chí còn giảm nhanh hơn giá thành của việc xử lý và băng

thông mạng. Việc lưu trữ với giá rẻ sẽ dẫn theo việc tăng theo cấp số nhân số lượng
lưu trữ audio video trên Internet. Thứ hai, cải thiện hạ tầng mạng Internet, như là truy
cập tốc độ cao, lưu trữ bản sao video trên mạng và chất lượng dịch vụ tốt sẽ tạo điều
kiện đóng góp cho việc lưu trữ audio và video. Thứ ba, nhu cầu về video trực tuyến
với chất lượng cao là rất lớn, ứng dụng sẽ kết hợp việc giao tiếp giữa 2 công nghệ -
truyền hình và web theo yêu cầu.
Trong việc truy cập audio/video trực tuyến, máy khách sẽ yêu cầu file
audio/video đã nén nằm ở trên server. Như chúng thảo luận trong phần này, thì máy
chủ có thể là một máy chủ web bình thường hoặc có thể là một máy chủ chuyên biệt
cho việc truy cập và xử lý audio/video trực tuyến. Tập tin trên máy chủ có thể là nhiều
loại tập tin audio/video với nội dung khác nhau, bao gồm bài giảng của các giáo sư,
các bài nhạc rock, phim ảnh, truyền hình, các đoạn ghi hình về sự kiện thể thao …v…
v…Khi máy khách gửi yêu cầu, máy chủ truy cập trực tiếp tới tập tin audio/video rồi
gửi đến client bằng cách gửi tập tin vào socket. Hai giao thức kết nối TCP và UDP
socket được dùng trong trường hợp này. Trước khi gửi tập tin audio/video lên mạng,
tập tin có thể chia thành các phân đoạn nhỏ và các phân đoạn nhỏ này sẽ được đóng
gói với phần header đặt biệt cho việc vận chuyển gói tin audio/video. Giao thức thời
gian thực (RTP), được thảo luận cho phần 6.4, là một miền công cộng chuẩn cho việc
đóng gói các phân đoạn nhỏ này. Một khi máy khách bắt đầu nhận các yêu cầu tập tin
audio/video, máy khách sẽ bắt đầu gắn các phân đoạn này lại trong một vài giây.
Người dùng tương tác cũng đòi hỏi một giao thức để tương tác giữa máy khách và máy
chủ. Giao thức thời gian thực, sẽ được thảo luận đến cuối chương này, là giao thức
công cộng chuẩn cung cấp sự tương tác cho người dùng.
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 14
Báo Cáo Môn Mạng Máy Tính
Audio/video trực tuyến được gửi yêu cầu thường xuyên bởi người dùng thông
qua trình duyệt web. Nhưng bởi vì audio/video diễn ra không được tích hợp trực tiếp
trong trình duyệt web, nên một ứng dụng trợ giúp riêng biệt là cần thiết cho việc chơi
các audio/video. Ứng dụng trợ giúp này thường được gọi là media player, thường phổ
biến trong các ứng dụng chơi nhạc trên mạng và trong ứng dụng chơi nhạc của

Microsoft là Windows Media Players. Media player cung cấp một vài chức năng, bao
gồm
- Giải nén: Audio/video thường được nén để tiết kiệm đĩa cứng và băng thông
mạng. Ứng dụng chơi nhạc media player sẽ giải nén audio/video trong suốt quá
trình chơi nhạc.
- Loại bỏ jitter: các gói tin jitter là sự thay đổi về độ trễ trong luồng gói tin đó.
Các gói tin jitter, nếu không được loại bỏ có thể dẫn đến các audio và video khó
hiểu. Chúng ta sẽ bàn ví dụ về trường hợp này trong phần 6.3, các gói tin jitter
thường bị giới hạn bởi bộ nhớ đệm audio/video trong một vài giây tại máy
khách trước khi phát nhạc.
- Lỗi không đúng: Do tắc nghẽn không thể đoán trước trên mạng Internet, một
phần nhỏ của các gói dữ liệu trong luồng dữ liệu có thể bị mất. Nếu phần này
trở nên quá lớn, người dùng nhận thức chất lượng audio/video trở nên không
thể chấp nhận. Để kết thúc việc này, nhiều hệ thống trực tuyến cố gắng phục
hồi từ những gói bị mất bằng cách xây dựng lại các gói tin bị mất thông qua
việc truyền các gói dữ liệu dư thừa, bằng cách máy khách sẽ gửi yêu cầu gửi lại
gói bị mất hoặc cả hai.
- Giao diện người dùng với nút bấm điều khiển: Đây là giao diện thực mà người
dùng tương tác với nó. Nó bao gồm nút điều khiển âm lượng, nút pause hoặc
resume, thanh trượt cho việc nhảy đến một đoạn audio/video …v…v…
Các thành phần hỗ trợ có thể được nhúng vào giao diện của ứng dụng media
trong cửa sổ của trình duyệt web. Ví dụ như phần nhúng, trình duyệt nhúng lưu không
gian màn hình của trang web hiện tại và đặt nó vào ứng dụng media để quản lý. Nhưng
khi cả hai hiện lên sẽ hiện trong cửa sổ riêng biệt hoặc trong cửa sổ của trình duyệt
(như một thành phần phụ trợ), ứng dụng media là chương trình được thực hiện riêng rẽ
với các trình duyệt.
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 15
Báo Cáo Môn Mạng Máy Tính
6.2.1. Truy cập âm thanh và video từ máy chủ web
Việc lưu trữ xử lý audio/video có thể được thực hiện bên trong Web Server, nơi

mà có nhiệm vụ trung chuyển audio/video đến máy khác thông qua giao thức HTTP,
hoặc trên luồng dữ liệu audio/video của server, nơi mà có nhiệm vụ trung chuyển
audio/video không thông qua giao thức HTTP (giao thức có thể là độc quyền hoặc
trong miền công cộng). Trong phần này, chúng tôi đưa ra ví dụ về việc trung chuyển
audio/video từ Web server, trong phần tiếp theo, chúng tôi đưa ra ví dụ về việc trung
chuyển từ luồng dữ liệu server.
Liên quan đến trường hợp đầu tiên của việc truyền dữ liệu âm thanh. Khi tập
âm thanh nằm trên máy chủ web, tập tin âm thanh này là một đối tượng bình thường
giống như các tập tin trên server như là tập tin HTML và JPEG. Khi người dùng muốn
nghe tập tin âm thanh, nó sẽ kết nối bằng giao thức kết nối TCP với máy chủ Web và
gửi yêu cầu HTTP đến đối tượng, khi nhận được yêu cầu, máy chủ Web đóng gói tập
tin âm thanh trong gói thông điệp phản hồi HTTP và gửi phản hồi ngược lại thông qua
kết nối TCP. Đối với trường hợp video có thể ít phức tạp hơn, bởi vì audio và video là
môt phần của video có thể lưu trữ trong hai tập tin khác nhau, chúng có thể là hai đối
tượng khác nhau trong các tập tin trên máy chủ Web. Trong trường hợp này, hai yêu
cầu HTTP song song được gửi đến máy chủ server (với hai giao thức kết nối song
song là TCP cho HTTP/1.0), và tập tin audio và video nhận tại máy khách trong hai
luồng song song. Nó sẽ được đồng bộ tại máy khách trong hai luồng. Có thể là audio
và video sẽ trong cùng một tập tin, vì thế chỉ một đối tượng được được gửi đến máy
khách. Để cho cuộc thảo luận này đơn giản, trong trường hợp video, chúng tôi giả định
audio và video là nằm trong một file cho phần này.
Kiến trúc cho luồng dữ liệu audio/video.
- Trình duyệt tạo kết nối TCP với máy chủ Web và gửi yêu cầu tập tin
audio/video với yêu cầu HTTP
- Máy chủ Web gửi lại cho trình duyệt tập tin audio/video trong thông tin phản
hồi HTTP.
- Kiểu nội dung: dòng đầu phần header trong giao thức phản hồi HTTP chỉ đến
phần mã hóa đặc biệt của audio/video. Trình duyệt máy khách kiểm tra loại nội
dung của thông điệp phản hồi, và chạy ứng dụng media và chuyển tập tin đến
ứng dụng media.

Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 16
Báo Cáo Môn Mạng Máy Tính
- Ứng dụng media sẽ gắn kết các tập tin audio/video
Hình 6.2 - : Luồng thực hiện cho tập tin âm thanh
Mặc dù phương pháp tiếp cận rất đơn giản, nó có một hạn chế chính đó là : ứng
dụng media hay trình phát media (hoặc ứng dụng trợ giúp) phải tương tác với máy chủ
thông qua trình duyệt Web trung gian. Từ đây có thể dẫn đến nhiều vấn đề, trong
trường hợp khi trình duyệt trung gian, một đối tượng phải được tải về trước khi trình
duyệt chuyển đối tượng đến ứng dụng hỗ trợ; kết quả là độ trễ không thể chấp nhận
cho tập tin audio/video với độ dài vừa phải. Chính vì lý do này, luồng audio/video
được triển khai, server gửi tập tin audio/video trực tiếp đến tiến trình đang chạy trình
phát media. Trong trường hợp khác, một kết nối socket trực tiếp được tạo giữa tiến
trình server và tiến trình của ứng dụng media. Như hình ở 6.2.2, đây là trường hợp
hoàn tất bằng cách dùng “meta file”, là tập tin cung cấp thông tin về tập audio/video.
Hình 6.2 - : Máy chủ web gửi trực tiếp tập tin audio/video đến ứng dụng media
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 17
Báo Cáo Môn Mạng Máy Tính
Một kết nối TCP trực tiếp giữa máy chủ và ứng dụng media thu được như sau:
1. Người dùng click trên link liên kết tập tin audio/video.
2. Link liên kết không trỏ trực tiếp đến tập tin audio/video, nhưng thay vào đó
là trỏ đến tập tin meta. Tập tin meta chứa địa chỉ của tập tin audio/video
thật. Gói tin phản hồi HTTP sẽ đóng gói tập tin meta bao gồm kiểu nội
dung: dòng đầu phần header chỉ đến ứng dụng audio/video.
3. Trình duyệt máy khách đọc kiểu nội dung trong phần đầu header của gói
phản hồi, sau đó chạy ứng dụng media và chuyển phần nội dung của gói
phản hồi đến ứng dụng media.
4. Ứng dụng media thiết lập kết nối TCP trực tiếp với HTTP server. Ứng dụng
media gửi yêu cầu HTTP cho tập tin audio/video vào trong kết nối TCP.
5. Tập tin audio/video sẽ được gửi tới ứng dụng media thông qua gói phản hồi
HTTP. Sau đó ứng dụng media sẽ chạy luồng audio/video này.

Tầm quan trọng của bước trung gian là phải thu nhận các tập tin meta phải rõ
ràng. Khi trình duyệt thấy được kiểu nội dung của tập tin, nó có thể chạy ứng dụng
media, và ứng dụng media sẽ giao tiếp trực tiếp với máy chủ.
Chúng ta đã biết làm thế nào một tập tin meta có thể cho phép ứng dụng media
có thể giao tiếp trực tiếp với một máy chủ Web audio / video. Tuy nhiên, nhiều công
ty bán sản phẩm audio / video không giới thiệu kiến trúc , chúng tôi vừa mô tả. Điều
này là do các kiến trúc có ứng dụng media giao tiếp với máy chủ qua HTTP và cũng
qua kết nối TCP . HTTP thường được xem là không đủ để làm hài lòng về sự tương
tác giữa người dùng với máy chủ. Cụ thể , HTTP không dễ dàng cho phép người dùng
( thông qua máy chủ media ) gửi tạm dừng / tiếp tục, nhanh chóng, trượt về phía trước
và thời gian nhảy lệnh đến máy chủ. TCP thường được xem là không phù hợp cho âm
thanh / hình ảnh , đặc biệt là khi người dùng có kết nối Internet tốc độ chậm. Điều này
là do , khi mất gói tin , tỷ lệ người gửi với kết nối TCP gần như dừng lại, mà có thể
dẫn đến thời gian dài của các ứng dụng media dài. Tuy nhiên, âm thanh và video
thường được truyền từ máy chủ Web với kết nối TCP cho kết quả khả quan.
6.2.2. Gửi đa phương tiện từ luồng server đến ứng dụng hỗ trợ
Để nắm được các hoạt động xung quanh các giao thức HTTP hoặc TCP, và tập
tin âm thanh/video có thể lưu trữ và được gửi đi từ luồng dữ liệu server đến ứng dụng
media. Luồng dữ liệu tại server có thể là một luồng độc quyền như luồng được thiết kế
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 18
Báo Cáo Môn Mạng Máy Tính
và quảng cáo bởi RealNetworks và Microsoft, hoặc luồng với miền server công cộng.
Với luồng này, audio/video có thể được gửi thông qua giao thức UDP (chứ không phải
là TCP) dùng giao thức của lớp ứng dụng là HTTP.
Kiến trúc này đòi hỏi hai máy chủ, như trong hình 6,2-3 . Một máy chủ, máy
chủ HTTP, phục vụ các trang web (bao gồm cả các tập tin meta) . Các máy chủ thứ hai
, các máy chủ streaming , phục vụ các tập tin audio / video. Hai máy chủ có thể chạy
trên các hệ thống cuối cùng hoặc trên hai hệ thống kết thúc khác nhau. ( Nếu máy chủ
Web là rất bận rộn phục vụ các trang web , nó có thể được thuận lợi để đặt máy chủ
streaming trên máy tính riêng của mình . ) Các bước cho kiến trúc này cũng tương tự

như mô tả trong kiến trúc trước đó. Tuy nhiên , hiện nay các phương tiện truyền thông
yêu cầu các tập tin từ một máy chủ streaming chứ không phải là từ một máy chủ Web ,
và bây giờ ứng dụng media và máy chủ streaming có thể tương tác bằng cách sử dụng
giao thức riêng của họ. Các giao thức này có thể cho phép người dùng tương tác phong
phú với các dòng âm thanh / video. Hơn nữa, các tập tin audio / video có thể được gửi
đến máy nghe nhạc phương tiện truyền thông trên UDP thay vì TCP
Hình 6.2 - : Luồng từ máy chủ streaming đến ứng dụng media
Trong kiến trúc của hình 6,2-3 , có nhiều tùy chọn để cung cấp âm thanh / video
từ các máy chủ streaming đến ứng dụng media. Một phần danh sách các tùy chọn được
đưa ra dưới đây :
1. Âm thanh / video được gửi qua UDP với một tốc độ không đổi tương đương với tỷ
lệ cống ở người nhận ( đó là tốc độ mã hóa của âm thanh / video) . Ví dụ, nếu âm
thanh được nén sử dụng GSM với tốc độ 13 Kbps, sau đó xung nhịp đồng hồ máy chủ
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 19
Báo Cáo Môn Mạng Máy Tính
nén các tập tin âm thanh ở 13 Kbps. Ngay sau khi máy khách nhận được tập tin nén
audio / video từ mạng, nó giải nén âm thanh / video và chơi nó trở lại.
2 . Điều này tương tự như tùy chọn 1 , nhưng sự chậm trễ của ứng dụng media diễn ra
trong 2-5 giây để loại bỏ mạng gây ra jitter . Máy khách kết thúc nhiệm vụ này bằng
cách đặt các tập tin media nén mà nó nhận được từ mạng vào một bộ đệm của nó, như
trong hình 6,2-4 . Một khi máy khách đã " nạp trước " một vài giây của tập tin meida ,
nó bắt đầu lấy từ các vùng đệm . Đối với điều này và các tùy chọn trước đó , tỷ lệ cống
d bằng với tỷ lệ lấp đầy x (t) , ngoại trừ khi có mất gói tin .
3 . Âm thanh được gửi qua giao thức TCP và sự chậm trễ media player diễn ra trong 2-
5 giây. Máy chủ truyền dữ liệu với giao thức TCP với một tốc độ không đổi tương
đương với tỷ lệ cống thu d. Giao thức TCP truyền lại các gói tin bị mất, và do đó có
thể cải thiện chất lượng âm thanh . Nhưng tỷ lệ lấp đầy x (t) tại biến động theo thời
gian do TCP khởi đầu chậm chạp và kiểm soát dòng chảy cửa sổ, ngay cả khi không
có mất gói tin. Nếu không có gói tin bị mất , trung bình tỷ lệ lấp đầy gần bằng với tỷ lệ
cống d . Hơn nữa, sau khi kiểm soát tắc nghẽn mất gói tin TCP có thể làm giảm tỷ lệ

đến tức thời ít hơn d trong thời gian dài của thời gian. Vùng bộ nhớ đệm này của máy
khách có thể trống và lúc này sẽ tạm dừng và hiển thị ra đầu ra của luồng audio/video
tại máy khách.
4 . Điều này tương tự như phương án 3, nhưng bây giờ các phương tiện truyền thông
tại máy khách sử dụng một bộ đệm lớn - đủ lớn để giữ nhiều nếu không phải tất cả các
âm thanh / video nộp (có thể lưu trữ trong đĩa). Máy chủ đẩy các tập tin audio / video
với giao thức TCP đến máy khách và máy khách đọc dữ liệu từ Socket TCP và đặt
video âm thanh giải nén vào bộ đệm tại máy khách. Trong trường hợp này , TCP sử
dụng tất cả các băng thông có sẵn để kết nối, vì vậy ở lần x (t) có thể lớn hơn nhiều so
với d . Khi những băng thông tức thời dưới mức cống , người nhận không bị mất dữ
liệu khi bộ đệm của máy khách là không rỗng .
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 20
Báo Cáo Môn Mạng Máy Tính
Hình 6.2 - : Bộ nhớ đệm máy khách x(t) và d
6.2.3. Giao thức truyền dòng dữ liệu thời gian thực
Âm thanh, video và SMIL, v…v…, thường được gọi là phương tiện truyền
thông liên tục. ( SMIL là viết tắt của đồng bộ đa phương tiện. Ngôn ngữ, nó là một
ngôn ngữ chuẩn , ví dụ như là HTML. Như tên gọi của nó , SMIL định nghĩa như thế
nào là đối tượng phương tiện truyền thông liên tục, cũng như các đối tượng tĩnh , được
đồng bộ hóa trong một bài trình bày sáng tỏ theo thời gian. Một cuộc thảo luận sâu sắc
của SMIL là vượt quá phạm vi của cuốn sách này. ) Người dùng thường muốn kiểm
soát phát lại audio hay video liên tục bằng cách tạm dừng, phát lại hoặc nhảy đến 1
điểm muốn phát, phát lại nhanh chóng chuyển tiếp trực quan , phát tua trực quan , vv .
chức năng này tương tự như những chức năng khi xem một băng video hoặc với một
đĩa CD, máy nghe nhạc khi nghe nhạc CD . Để cho phép người dùng kiểm soát phát
lại, các ứng dụng media và máy chủ cần một giao thức để trao đổi phát lại kiểm soát
thông tin. RTSP , được định nghĩa trong [ RFC 2326 ], là một giao thức như vậy.
Nhưng trước khi đi vào các chi tiết của RTSP , chúng ta hãy chỉ ra những gì RTSP
không làm được:
- RTSP không xác định được chương trình nén âm thanh và video .

- RTSP không định nghĩa như thế nào âm thanh và video được đóng gói trong
các gói tin truyền qua mạng, đóng gói cho ứng dụng media có thể được cung
cấp bởi RTP hoặc một giao thức độc quyền. ( RTP được thảo luận trong phần
6.4) Ví dụ, máy chủ G2 và máy nghe nhạc sử dụng RealMedia của RTSP để gửi
thông tin điều khiển với nhau. Nhưng ứng dụng media chính nó có thể được
đóng gói gói tin RTP hoặc với một số chương trình độc quyền như
RealNetworks .
- RTSP không hạn chế làm thế nào các ứng dụng media có thể được chuyển đi ,
nó có thể được vận chuyển qua UDP hoặc TCP .
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 21
Báo Cáo Môn Mạng Máy Tính
- RTSP không hạn chế làm thế nào các ứng dụng media đưa audio/video vào bộ
đệm. Audio / video có thể được diễn ra ngay sau khi nó bắt đầu đến máy
khách , nó có thể được diễn ra sau khi một sự chậm trễ của một vài giây , hoặc
nó có thể được tải về toàn bộ trước khi diễn ra .
Vì vậy, nếu RTSP không làm bất kỳ điều gì ở trên, vậy RTSP làm gì? RTSP là
một giao thức cho phép một ứng dụng media điều khiển việc truyền tải một luồng
media. Như đã đề cập ở trên, hành động kiểm soát bao gồm pause / resume , tái định vị
và phát lại, nhanh chóng chuyển tiếp và tua lại . RTSP còn được gọi là giao thức out-
of -band. Đặc biệt, các mẩu tin RTSP đượcgửi out-of -band, trong khi các dòng
phương tiện truyền thông, có cấu trúc gói tin không được xác định bởi RTSP, được coi
là " in-band". Các tin nhắn RTSP sử dụng các cổng khác nhau hơn so với các dòng
phương tiện truyền thông . RTSP sử dụng cổng số 554. ( Nếu các thông điệp RTSP đã
sử dụng số cổng tương tự như các dòng phương tiện truyền thông, sau đó tin nhắn
RTSP sẽ được cho là " xen kẽ " với các dòng phương tiện truyền thông . ) Các đặc
điểm kỹ thuật RTSP [ RFC 2326 ] cho phép thông điệp RTSP được gửi qua TCP hoặc
UDP. Nhớ lại từ phần 2.3 rằng giao thức truyền file (FTP) cũng sử dụng khái niệm
out-of -band. Đặc biệt, FTP sử dụng hai cặp client / server của 2 giao thức, mỗi cặp
với số cổng riêng của mình: một cặp socket client / server hỗ trợ kết nối TCP vận
chuyển kiểm soát thông tin, cặp client / server với giao thức hỗ trợ kết nối TCP mà

thực sự vận chuyển các tập tin . Kết nối điều khiển TCP được gọi là out-of –band
trong khi kết nối TCP vận chuyển các tập tin là cái gọi là kênh dữ liệu . Kênh out-of
-band được sử dụng cho việc thay đổi các thư mục từ xa , xóa tập tin từ xa , đổi tên tập
tin từ xa, yêu cầu tập tin tải về, v…v…. kênh in-band vận chuyển các tập tin đó. Kênh
RTSP theo nhiều cách tương tự như kênh điều khiển FTP . Bây giờ chúng ta đi qua
một ví dụ đơn giản RTSP, được minh họa trong hình 6,2-5 . Trình duyệt web đầu tiên
yêu cầu một tập tin mô tả trình bày từ một máy chủ Web. Các tập tin mô tả trình bày
có thể có tham chiếu đến một số tập tin liên tục phương tiện truyền thông cũng như chỉ
thị cho đồng bộ các tập tin liên tục với ứng dụng media . Mỗi tham chiếu đến một tập
tin liên tục đến ứng dụng media bắt đầu với phương pháp URL , rtsp :/ / . Dưới đây
chúng tôi cung cấp một tập tin mẫu trình chiếu, đã được chuyển thể từ giấy. Trong bài
trình bày này, một âm thanh và hình ảnh video được chơi song song và lipsync ( như
là một phần của cùng một " nhóm" ). Cho dòng âm thanh , máy nghe nhạc phương tiện
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 22
Báo Cáo Môn Mạng Máy Tính
truyền thông có thể lựa chọn ( "chuyển đổi" ) trong hai bản ghi âm, ghi âm trung thực
thấp và ghi âm trung thực cao.
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">

</group>
</session>
Máy chủ Web đóng gói các tập tin mô tả trình bày trong một thông điệp trả lời
HTTP và gửi thông báo cho trình duyệt. Khi trình duyệt nhận được tin nhắn phản hồi
HTTP , trình duyệt chạy sẽ là một ứng dụng media (ví dụ, ứng dụng trợ giúp ) dựa trên
kiểu nội dung : trường của tin nhắn. Các tập tin mô tả trình bày bao gồm tài liệu tham
khảo để phương tiện truyền thông dòng, sử dụng phương pháp URL rtsp :/ / , như
trong ví dụ trên .
Như thể hiện trong hình 6,2-4 , máy nghe nhạc và máy chủ sau đó gửi cho nhau
một loạt các tin nhắn RTSP. Các ứng dụng gửi một yêu cầu SETUP RTSP, và máy
chủ sẽ gửi một phản hồi SETUP RTSP . Các ứng dụng gửi một yêu cầu RTSP PLAY, ,
và máy chủ sẽ gửi phản hồi RTSP PLAY .
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 23
Báo Cáo Môn Mạng Máy Tính
Tại thời điểm này , các máy chủ streaming đưa âm thanh vào kênh hay băng tần của
riêng mình. Sau đó, các ứng dụng media sẽ gửi một yêu cầu PAUSE RTSP, và máy
chủ đáp ứng với một phản hồi PAUSE RTSP . Khi người dùng kết thúc, các ứng dụng
media sẽ gửi một yêu cầu TEARDOWN RTSP, và máy chủ đáp ứng với một phản ứng
TEARDOWN RTSP.
Hình 6.2 - : Tương tác giữa máy khách và máy chủ dùng RSTP
Mỗi phiên RTSP có một định danh phiên, được lựa chọn bởi các máy chủ. Máy
khách khởi tạo phiên với yêu cầu SETUP, và máy chủ đáp ứng các yêu cầu cho một
định danh. Máy khách lặp đi lặp lại các định danh phiên cho mỗi yêu cầu, cho đến khi
máy khách đóng phiên với yêu cầu teardown . Sau đây là một ví dụ đơn giản của một
phiên RTSP :
C : SETUP rtsp :/ / audio.example.com / twister / âm thanh RTSP/1.0
Vận chuyển : RTP / UDP , nén ; port = 3056 ; chế độ = PLAY
S : RTSP/1.0 200 1 OK
phiên 4231
C : PLAY rtsp :/ / audio.example.com / twister / audio.en / LoFi RTSP/1.0

Phiên : 4231
Khoảng: npt = 0 -
C : PAUSE rtsp :/ / audio.example.com / twister / audio.en / LoFi RTSP/1.0
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 24
Báo Cáo Môn Mạng Máy Tính
Phiên : 4231
Khoảng: npt = 37
C : TEARDOWN rtsp :/ / audio.example.com / twister / audio.en / LoFi RTSP/1.0
Phiên : 4231
S : 200 3 OK
Tài liệu tham khảo
[Schulzrinne] H. Schulzrinne, "A Comprehensive Multimedia Control Architectuure
for the Internet," NOSSDAV'97 (Network and Operating System Support for Digital
Audio and Video), St. Louis, Missouri; May 19, 1997. Online version available.
[RealNetworks] RSTP Resource:
[RFC 2326] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol
(RTSP)", RFC 2326, April 1998
Nhóm thực hiện: Nhóm 6, Lớp 12TLT.CNTT Trang 25