Nghiên cứu truyền tin bằng giao thức RTP và ứng dụng thực tiễn

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





Nguyễn Công Minh





NGHIÊN CỨU TRUYỀN TIN
BẰNG GIAO THỨC RTP
VÀ ỨNG DỤNG THỰC TIỄN











LUẬN VĂN THẠC SĨ

Hà Nội - 2007

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





Nguyễn Công Minh





NGHIÊN CỨU TRUYỀN TIN
BẰNG GIAO THỨC RTP
VÀ ỨNG DỤNG THỰC TIỄN

LUẬN VĂN THẠC SĨ














Hà Nội - 2007


i

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ




Nguyễn Công Minh






NGHIÊN CỨU TRUYỀN TIN
BẰNG GIAO THỨC RTP
VÀ ỨNG DỤNG THỰC TIỄN




Ngành : Công nghệ Điện tử - Viễn thông
Chuyên ngành: Kỹ thuật vô tuyến điện tử và thông tin liên lạc
Mã số: 2.07.00


LUẬN VĂN THẠC SĨ


NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS-TS TRẦN QUANG VINH

Hà Nội - 2007



iii
MỤC LỤC

Trang phụ bìa…………………………………………………………
i
Lời cam đoan…….……………………………… …………………
ii
Mục lục …… …………………………………… …………………
iii
Danh mục các bảng …… ………………………… ………………
vi
Danh mục các hình vẽ………………………… …………………
vii
Mở đầu ……………………………………… ……… ……………
1
Chương 1: Giao thức RTP …………………….…………… …….
3

1. Giới thiệu.…………………………………………….…………
3
2. Giao thức
RTP……………………………………….……………
4
2.1. Giao thức RTP………………………………….………….…
4
2.2. Cấu trúc gói tin RTP………………………….…… ………
5
2.3. Vấn đề đồng bộ của
RTP…………………….………… …
6
2.4. Hoạt động của RTP………………………….………………
7
3. Profile và các dạng của payload……………………….………
9
3.1. Profile cho hội nghị âm thanh và hình ảnh……… ……
9
3.2. Sự hoạt động H.261 trên
RTP……………………… ……
10
3.3. Dạng payload cho con trỏ thời gian
thực………… ……
11
4. Các khái niệm liên quan khác…………….…………….………
11
4.1. Nén Header…………………………………………….… …
11
4.2 Quản lý thông tin các gói RTP……………………….……
12

5. Kết luận……………………………………………………………
12
Chương 2: Truyền thông tin qua Internet……………………….
14


iv
1. Tổng quan về hệ thống Web…………………………………….
14
1.1. Giới
thiệu……………………………………………………
14
1.2. Mô hình hệ thống Web nói chung………………………….
14
1.3. Nguyên tắc hoạt động……………………………………….
15
2. Ngôn ngữ
ASP………………………………………………
15
2.1. Ngôn ngữ HTML (Hyper Text Markup
Language)…….
15
2.2.Ngôn ngữ
ASP…………………………………………………
16
2.2.1. Cơ bản về
ASP……………………………………………
16
2.2.2. Mô hình hoạt động của ASP……………………………
17

2.2.3. Tạo một trang ASP………………………………………
18
2.3. Lập trình với
ASP…………………………………………….
19
2.3.1. Thêm các Script………………………………………….
19
2.3.2. Khai báo biến trong
ASP………………………………
19
2.3.3. Biến phiên và biến ứng
dụng……………………………
20
2.3.4. Khai báo thủ tục, hàm và cách gọi……………………
20
2.3.4.1. Đối với VBScript…………………………………….
20
2.3.4.2. Đối với JScript………………………………………
21
2.3.5. Tạo liên kết giữa các file………………………………
21
2.3.6. Các đối tượng Component……………………………
21
2.3.6.1. Khái niệm về Component…………………………
21
2.3.6.2. Sử dụng các
Component…………………………….
22

v
2.3.6.3. Phương thức và thuộc tính của đối
tượng………
22
2.3.6.4. Giải phóng đối
tượng………………………………
22
2.3.7. Các đối tượng của
ASP………………………………….
22
Chương 3: Điều khiển cổng
LPT…………………………………
24
1. Giới thiệu………………………………………………………….
24
2. Điều khiển cổng LPT…… ………………………….………….
24
3. Kiểm tra ………………….……………………………………….
32
Chương 4: Thực nghiệm: Điều khiển các thiết bị cho ngôi
nhà thông minh của thế kỷ XXI …………………………………

33
1. Giới thiệu………………………………………………………….
33
2. Mô hình……………………………………………………………
33
3. Giải pháp thực
hiện………………………………………………
34

4. Các bước tiến hành………………………………………………
37
4.1. Cài đặt IIS…………………………………………………….
37
4.2. Lập trình điều khiển…………………………………………
40
5. Cấu hình WebServer……………………………………………
48
6. Cấu hình quan sát………………………………………………
53
Chương 5: Định hướng tiếp theo
………………………………….
63
1. Giới thiệu………………………………………………………….
63
2. Điều khiển thiết bị qua SMS…………………………………….
63
2.1. Định hướng thực
hiện………………………………………
63
2.2. Giải pháp phần
mềm…………………………………………
66


vi
3. Mở rộng…………………………………………………………
69
Kết luận………………………………………………………………
70

Tài liệu tham khảo…………………………………………………
71
Phụ lục 1……………………………………………………………….
73
Phụ lục 2……………………………………………………………….
83







vii
DANH MỤC CÁC BẢNG


Cấu trúc gói tin RTP ………………………………………………
5
Giá trị bit các chân của cổng LTP………………………………
31

viii
DANH MỤC HÌNH VẼ


Cấu trúc gói tin RTP……………………………………………….
5
Truyền trực tiếp một buổi hòa nhạc………………………………
7
Mô hình hệ thống Web……………………………………………
14
Mô hình hoạt động của ASP……………………………………….
18
Cấu tạo cổng LPT…………………………………………………
24
Sơ đồ mạch thử cổng LPT………………………………………….
32
Mô hình điều khiển thiết bị………………………………………
33
Sơ đồ lắp ráp Rơle trong mạch……………………………………
34
Cấu trúc UNL2003, UNL2803……………………………………
35
Sơ đồ nguyên lý điều khiển thiết
bị………………………………
36
Sơ đồ nguyên lý chi tiết điều khiển thiết bị………………………
36

Kiến trúc hệ thống quan sát……………………………………….
55
Sơ đồ kết nối Mobile và PC………………………………………
64







1
MỞ ĐẦU

Ngày nay, cùng với sự phát triển của xã hội thì ngành công nghệ
thông tin đang đạt được những tiến bộ đáng kể. Các hãng sản xuất phần
cứng cũng như phần mềm luôn luôn cố gắng tạo ra những sản phẩm tốt
nhất và tối ưu nhất với mức giá hấp dẫn nhất có thể, đưa ra thị trường
nhằm phục vụ cho lợi ích của người tiêu dùng cũng như làm tăng thị
phần của mình trong môi trường cạnh tranh khốc liệt.
Cùng với sự phát triển của ngành công nghệ thông tin trên thế giới,
công nghệ thông tin Việt Nam với phương châm đi tắt đón đầu cũng đã
có những bước phát triển vượt bậc. Những năm trước đây, người sử
dụng mạng Internet ở nước ta chỉ có thể truy cập bằng các Modem quay
số (Dial-up) với tốc độ khá chậm và cước phí còn khá cao so với thu
nhập bình thường của người lao động. Vài ba năm trở lại đây, người sử
dụng mạng Internet đã được tiếp cận nhiều hơn bởi sự phát triển rộng rãi
của công nghệ DSL (Digital Subsriber Line - đường dây thuê bao số).
Với công nghệ này thì Internet đã trở nên phổ biến trong cộng đồng và
Internet dần trở thành một nhu cầu tất yếu của xã hội hiện đại. Đời sống

xã hội ngày càng được cải thiện, môi trường sống và làm việc tốt hơn
cùng với thu nhập của người lao động cũng khá hơn trước nên yêu cầu
về các tiện ích trong cuộc sống cũng tăng lên đáng kể. Giờ đây, người sử
dụng không chỉ dừng lại ở những ứng dụng thông thường mà Internet
mang đến, những loại hình giải trí như nghe nhạc, xem phim chưa đủ
làm thỏa mãn nhu cầu mà họ cần có những ứng dụng cao hơn, hiện đại
hơn như giám sát và điều khiển những thiết bị từ xa, bởi nó vừa có tính
an toàn cao và đồng thời cũng mang rất nhiều tiện ích trong một xã hội
công nghiệp đang phát triển.
Xuất phát từ những nhu cầu cơ bản đó trong xã hội hiện đại nên tác
giả đã nghiên cứu để ứng dụng sự phát triển của công nghệ thông tin vào
sử dụng trong đời sống thường ngày, nhằm thiết kế một ngôi nhà thông
minh, đáp ứng những yêu cầu thiết yếu của con người trong việc quan
sát ngôi nhà thân yêu của mình và điều khiển các thiết bị điện trong nhà
mỗi khi đi vắng, tạo tâm lý yên tâm hơn mỗi khi chúng ta không có mặt
ở nhà để tập trung nâng cao năng suất lao động trong công việc đạt được
những kết quả cao hơn.


2
Về cơ bản, nội dung của đề tài này được chia thành hai phần chính:
Lý thuyết và Thực nghiệm.
Phần Lý thuyết trình bày các vấn đề cơ bản về truyền tin trên mạng
Internet sử dụng giao thức thời gian thực RTP (Real-Time Transport
Protocol), xây dựng ý tưởng quan sát và điều khiển từ xa đối với ngôi
nhà thông minh và các thiết bị được lắp đặt trong nó.
Phần Thực nghiệm trình bày về các bước tiến hành để dự án có thể
khả thi, các yêu cầu về thiết bị, phần cứng, phần mềm, lập trình ứng
dụng nhằm giải quyết những vấn đề đã được đề cập đến trong phần Lý
thuyết, thiết kế và thi công lắp ráp hoàn chỉnh các mạch điện thực hiện

cho mục đích chính của đề tài.
Trong quá trình thực hiện đề tài này, tác giả đã nhận được sự giúp đỡ
rất nhiều của các thầy cô giáo trường Đại học Công nghệ - Đại học
Quốc gia Hà nội, nhất là sự hướng dẫn nhiệt tình của thầy giáo PGS TS
Trần Quang Vinh, nhân đây tác giả xin chân thành cảm ơn sự giúp đỡ
của các thầy cô giáo và đặc biệt cảm ơn PGS TS Trần Quang Vinh đã
giúp cho tác giả có điều kiện, kiến thức để thực hiện thành công đề tài.
Mặc dù tác giả đã rất cố gắng, nhưng do điều kiện và trình độ còn có
nhiều hạn chế nên không thể tránh được những thiếu sót trong đề tài, rất
mong sự đóng góp ý kiến của các thầy giáo, cô giáo và các bạn đồng
nghiệp cũng như các độc giả để đề tài này có thể phát triển tốt hơn, nhằm
phục vụ các nhu cầu cơ bản của đời sống cộng đồng.
Hà nội, tháng 11 năm 2007
Tác giả



Nguyễn Công Minh


3
Chương 1: GIAO THỨC RTP
1. Giới thiệu:
Hai thập niên trước, sự phát triển của Internet mới chỉ đơn thuần là cố
gắng truyền tải các bản tin và các file dữ liệu. Giao thức truyền chủ yếu
được sử dụng là TCP (Transmission Control Protocol), cung cấp một
dịch vụ đáng tin cậy cho việc truyền dữ liệu không cấu trúc [13]. Từ đó,
đã có rất nhiều nghiên cứu về thuật toán điều khiển tắc nghẽn của giao
thức này, bởi vì công việc làm giảm tắc nghẽn một cách có hiệu quả là
nhu cầu cần thiết của Internet khi mà số lượng các Host trong mạng liên

tục tăng lên một cách nhanh chóng.
Những năm gần đây đã xuất hiện xu hướng sử dụng giao thức IP
(Internet Protocol) để truyền đi các loại dữ liệu khác nhau. Ngoài việc
cung cấp các dịch vụ truyền thống như thư điện tử và các ứng dụng
duyệt Web, các nhà cung cấp còn có tham vọng đưa đến cho chúng ta
những dịch vụ mới hơn, đó là có thể xem những chương trình truyền
hình yêu thích trên nền Internet bằng cách sử dụng các thiết bị IP, hoặc
có thể thưởng thức các buổi hòa nhạc với thời gian thực (real-time) được
truyền trên mạng IP từ bất kỳ nơi nào trên thế giới.
Tuy nhiên, việc truyền các dữ liệu âm thanh hay hình ảnh
(Audio/Video) lại không thể thực hiện được bằng giao thức TCP, bởi nó
yêu cầu tất cả các bit dữ liệu cần phải sắp xếp theo đúng thứ tự. Có một
lựa chọn khác để truyền các luồng dữ liệu theo thời gian thực trên
Internet, đó là sử dụng trên giao thức UDP (User Datagram Protocol)
[14], nhưng giao thức này lại không hỗ trợ cho việc nhận các thông tin
phản hồi từ phía thu, không kiểm tra được luồng dữ liệu có đến đích hay
không và cũng không có sự hổ trợ một số tính năng cần thiết cho truyền
các dữ liệu theo thời gian thực.
AVT (Audio/Video Transport – truyền dẫn các tín hiệu âm thanh và
hình ảnh) là một nhóm của tổ chức IETF (Internet Engineering Task
Force) đã xác định các giao thức cần thiết cho việc truyền các dữ liệu âm
thanh và hình ảnh, trong đó phải kể đến giao thức RTP (Real-time
Transport Protocol) dùng để truyền tải các dữ liệu thời gian thực trên
Internet. Ngoài giao thức RTP, nhóm này còn xác định một số profile
dùng cho RTP và dạng payload cho các loại dữ liệu thời gian thực khác
nhau, mà chủ yếu là dạng âm thanh và hình ảnh [7].


4
2. Giao thức RTP

2.1. Giao thức RTP
RTP (Real-time Transport Protocol - giao thức truyền tải thời gian
thực) được coi là một chuẩn của RFC được IETF giới thiệu vào năm
1996. Mục đích của giao thức là cung cấp dịch vụ truyền dữ liệu theo
thời gian thực như các luồng âm thanh và hình ảnh [15]. RTP được sử
dụng ở lớp trên của các giao thức truyền tải khác, mà điển hình là lớp
UDP trên Internet. Theo như nguyên lý thiết kế của giao thức thì RTP là
giao thức end-to end, mặc dù trên đường truyền dẫn có thể gồm có một
số Host trung gian.
RTP gồm hai giao thức liên quan là: RTP dùng cho truyền dữ liệu
thời gian thực và cho điều khiển, giám sát nguồn dữ liệu được truyền đi,
hay còn gọi là RTCP (RTP Control Protocol - giao thức điều khiển
truyền dữ liệu thời gian thực). Đối với RTP thì dạng của các Header là
cố định nhưng dạng của payload lại phụ thuộc vào dữ liệu được mã hóa.
Bên cạnh các luồng dữ liệu âm thanh và hình ảnh thì RTP cũng được
dùng để truyền các dạng dữ liệu thời gian thực bất kỳ. Và như vậy, các
đặc tính truyền phụ thuộc rất nhiều vào dạng của payload [7].
Cũng giống như RTP, RTCP là giao thức truyền Datagram ở lớp trên
cùng. Đặc điểm quan trọng nhất của RTCP là nơi gửi sẽ nhận được các
phản hồi (feedback) về chất lượng truyền dẫn.
Các header của giao thức RTP cũng khá đơn giản, thường thì chúng
chỉ thị cho dạng của payload và các dạng của chúng được định nghĩa đầy
đủ trong Profile Specification. Ngoài các thông tin về dạng payload, các
header còn chứa thông tin nhận dạng về nguồn đồng bộ (Synchronization
Source) và có thể gồm cả danh sách phân bố kèm theo của chúng
(Contributing Source). Tuy nhiên, các header này có thể mở rộng theo
yêu cầu của dạng payload.
Giao thức RTP sử dụng khái niệm nguồn đồng bộ (SSRC -
Synchronization Source) trong các header của gói tin để nhận diện ra các
gói dữ liệu đã được Share ở cùng thời điểm và được đánh số một cách

lần lượt. Tại nơi nhận, thông tin về SSRC của các gói tin được chia ra từ
các luồng khác nhau sẽ được sử dụng để sắp xếp luồng dữ liệu đầu ra.
Dữ liệu gốc từ các nguồn vật lý khác nhau, ví dụ như từ các Camera,
phải được phân biệt bởi các SSRC, ngay cả khi chúng đã được đồng bộ.


5
Và như vậy, các luồng âm thanh và hình ảnh từ các cuộc hội thảo được
truyền một cách tách biệt với nhau cũng dùng các SSRC khác nhau, rồi
sau đó chúng được kết hợp với nhau tại nơi nhận bởi các thông tin định
thời trong các gói tin RTP [7].
2.2. Cấu trúc của gói tin RTP
Cấu trúc gói tin RTP và header cụ thể được biểu diễn như sau [29]:

IP
Header
UDP
Header
RTP
Header
RTP Payload
Timestamp
+Bits
0
32
64
96
96+(CCx32)
96+(CCx32)
+

(Xx((EHL+1)x32))
0-1 2 3 4-7 8 9-15 16-31
Ver P X CC M PT
Sequence
Number
SSRC indentifier
…SSRC indentifier…
Extension header (optional)
Data



6
Trong đó:
V (Version - phiên bản) gồm 2 bit chỉ thị phiên bản của RTP
P (Padding - đệm) gồm 1 bit chỉ thị số lượng octet không chứa dữ liệu
nằm sau payload
X (Extention - phần mở rộng) gồm 1 bit chứa header mở rộng
CC (CSRC Count - bộ đếm CSRC) gồm 4 bit chứa số lượng CSRC
trong header
M (Marker - đánh dấu) gồm 1 bit chứa thông tin về mục đích của ứng
dụng
PT (Payload Type - Dạng payload) gồm 7 bit chứa thông tin về dạng
của payload, diễn tả ứng dụng
Sequence Number - dãy số gồm 16 bit được tăng lên tương ứng với
lượng dữ liệu được gửi đi và cũng có thể được sử dụng tại nơi
nhận để phát hiện gói tin bị mất, giá trị ban đầu thường là ngẫu
nhiên
Timestamp - tem thời gian bồm 32 bit phản ánh tốc độ lấy mẫu octet
đầu tiên của gói dữ liệu RTP

SSRC gồm 32 bit nhận diện nguồn đồng bộ
CSRC chứa thông tin nhận diện về sự phân bố của nguồn dữ liệu
chứa payload của gói tin, số lượng do CC quyết định, tối đa là 15.
CSRC indentifer được chèn bởi các bộ trộn.
2.3. Vấn đề đồng bộ của RTP[29]
Để có thể đồng bộ được, bên nhận cần phải có 3 thông tin về nguồn
đồng bộ, trật tự của gói tin và thời gian lấy mẫu. Các thông tin này được
cung cấp trong header.
Nguồn đồng bộ (SSRC): Bên nhận có thể nhận dữ liệu từ nhiều
nguồn phát khác nhau, do vậy để sắp xếp lại chúng thì cần phải có thông
tin từ các nguồn đồng bộ của các gói tin đơn lẻ được cung cấp trong
SSRC
Chuỗi số (Sequence Number): khi không đủ thông tin để nhận ra
nguồn phát, chuỗi số được thêm vào. Chuỗi số này được tăng lên khi các


7
gói tin được gửi đi và có thể được sử dụng tại nơi nhận để phát hiện các
gói tin bị mất và khôi phục lại chuỗi của gói tin
Tem thời gian (Timestamp): các gói tin được truyền trên mạng có tem
thời gian, phía nhận có thể dựa vào thông tin về các tem thời gian này để
tái tạo lại dữ liệu âm thanh và hình ảnh
2.4. Hoạt động của RTP
Việc tách riêng các luồng âm thanh và hình ảnh sẽ cho phép nơi nhận
có thể loại ra một số luồng đến chậm do sự nghẽn cổ chai của các đường
truyền dẫn. Hơn nữa, đối với các loại dữ liệu âm thanh và hình ảnh khác
nhau thì việc gắn các tem thời gian (timestamp) của các xung clock cũng
khác nhau.
Một Host trung gian trên mạng kết nối RTP có thể hoạt động như một
bộ trộn (mixer), nghĩa là nó sẽ sử dụng một số phương pháp để kết hợp

dữ liệu đến từ các nguồn khác nhau để tạo dòng dữ liệu đầu ra. Vì các
nguồn dữ liệu sử dụng các định thời và các chuỗi khác nhau, do đó các
gói dữ liệu của các luồng phải sử dụng các SSRC khác nhau để có thể
nhận diện ra dữ liệu gốc. Bộ trộn lưu trữ các SSRC của các dữ liệu gốc
dưới dạng danh sách nguồn (Contributing Source - CSRC) trong header
của gói tin RTP. Node trung gian cần có kiểu gọi khác, gọi là bộ chuyển
đổi (Translator), nó không là thay đổi SSRC nhưng nó có thể biến đổi
thông tin mã hóa hoặc lọc các gói tin dữ liệu theo yêu cầu [7].




8
Hình 1: Truyền trực tiếp một buổi hòa nhạc

Hình 1 miêu tả một ví dụ về buổi hòa nhạc được truyền trực tiếp theo
nền tảng của công nghệ IP. Các ca sĩ và nhà quay phim được nối với các
Computer Box nhỏ để có thể truyền được âm thanh và hình ảnh bằng các
gói tin RTP tới các máy trạm (Client).
Bộ trộn (mixer) tập hợp trộn các dữ liệu âm thanh, xử lý chúng rồi
chuyển tiếp tới máy trạm (Client). Bộ trộn sử dụng nguồn đồng bộ của
nó (SSRC = 20) và lưu trữ SSRC của ca sĩ vào bảng CSRC trong header
của RTP.
Trên hình cũng chỉ ra rằng luồng Video và dữ liệu Audio không được
kết hợp với nhau tại bất kỳ điểm nào mà nó được truyền tới các máy
trạm (Client) một cách độc lập và riêng rẽ bởi các SSRC. Tại phía nhận,
máy trạm (Client) không quan tâm tới sự khác nhau của các SSRC, mà
nó kết hợp các dữ liệu với nhau dựa trên các thông tin về tem thời gian
(timestamp) với giả sử rằng các xung clock của nhạc sĩ, bộ trộn và các
camere được đồng bộ tại thời điểm truyền đi.

Nơi gửi RTP sẽ gửi định kỳ các bản tin (sender report) trong các gói
tin RCTP 64 bit với tem thời gian NTP. Tem thời gian NTP sử dụng giao
thức thời gian mạng (Network Time Protocol) [16], biểu thị thời gian đã
qua với mốc tính từ thể kỷ XX. Tuy nhiên, tem thời gian RTP cũng được
dùng với cùng tần số đồng hồ và được bù ngẫu nhiên trong các gói dữ
liệu. Sở dĩ phải dùng hai loại tem thời gian khác nhau như vậy là để đồng
bộ các dữ liệu từ các nguồn khác nhau. Hơn nữa, dựa vào các thông tin
định thời, nơi phát có thể cho biết về các gói đã được truyền đi.
Nơi nhận RTP sẽ phản hồi lại thông tin về tem thời gian cho nơi phát
thông qua bản tin nhận (receiver report) RCTP để cho nơi phát biết định
thời và thống kê quá trình truyền. Hơn thế nữa, bản tin nhận còn cho biết
về số lượng các gói bịn mất, các gói đã nhận được. Trong quá trình
truyền dẫn hai chiều thì bản tin gửi đi có thể chứa thông tin về dữ liệu
được gửi đi từ các nguồn khác.
Mục đích chính của các bản tin là giám sát chất lượng truyền của dữ
liệu thời gian thực, do hiện tượng mất các gói và nghẽn mạng trên đường
truyền. Các bản tin RTP gửi đi tuỳ thuộc vào khoảng cách, tốc độ truyền


9
và cách mã hóa dữ liệu. Các gói tin này thường được xử lý bởi các bộ
chuyển đổi trung gian nếu có sự thay đổi dữ liệu. Chẳng hạn như bộ
chuyển đổi có thể thay đổi dữ liệu RTP mã hóa nếu nó làm ảnh hưởng
đến số lượng các octet mà bộ chuyển đổi truyền đi. Tuy nhiên, tại nơi
gửi cần ước lượng các octet chứa dữ liệu giống nhau trong quá trình
truyền gói.
3. Profile và các dạng của payload
Như đã đề cập từ trước, bản thân giao thức RTP không đủ khả năng
để cung cấp một ứng dụng hoàn thiện cho quá trình truyền dữ liệu theo
thời gian thực, mà nó cần thiết phải kết hợp với hoặc profile truyền dẫn,

hoặc dạng của tải (payload) hoặc cả hai. Phần này sẽ giới thiệu một
profile chung nhất, khái quát nhất của RTP được dùng trong các dạng
payload âm thanh, hình ảnh khác nhau.
Hơn nữa, phần này sẽ trình bày một cách tóm tắt về phương thức
truyền các luồng hình ảnh bằng giao thức RTP với khuyến nghị H.261 và
những vấn đề khác khi truyền các luồng hình ảnh thời gian thực bằng gói
tin RTP, các dạng payload khác nhau.
3.1. Profile cho hội nghị âm thanh và hình ảnh
Nhóm AVT đã đưa ra định nghĩa về một profile đơn giản cho hội
nghị âm thanh/hình ảnh, theo như định nghĩa chỉ ra thì profile này được
cấu hình tối thiểu, không có bất kỳ header mở rộng nào và được khởi tạo
cùng với kiểu payload bằng cách ánh xạ, các xung clock của tem thời
gian (timestamp) cũng tỉ lệ với các kiểu mã hóa khác nhau của payload.
Vì các header của RTP có 7 bit dành cho việc mã hóa kiểu của chúng,
do vậy có tất cả 128 loại mã có thể được sử dụng, trừ những trường hợp
sử dụng mã cố định. Chính vì thế, có 22 loại mã cố định, chung và
thông dụng nhất cho các payload profile âm thanh/hình ảnh. Các loại mã
payload động được xác định gồm có 32 loại, còn lại các loại mã khác sẽ
được sử dụng tuỳ thuộc vào giao thức phát triển của chúng. Tuy nhiên,
giao thức điều khiển xác định các dạng payload động không được đề cập
đến trong profile, các kiểu của profile tĩnh sẽ được cân nhắc kỹ trong
cộng đồng rộng lớn sử dụng Internet [7].
Để nhận diện dạng payload, các xung clock của profile sẽ có tốc độ tỉ
lệ với từng loại payload riêng biệt. Đối với các luồng âm thanh thì xung


10
clock này sẽ có tốc độ giống như tốc độ lấy mẫu của tín hiệu âm thanh
được số hóa. Tốc độ lấy mẫu cơ bản của âm thanh là 8kHz, nhưng thông
thường thì người ta vẫn hay sử dụng hai thêm hai loại tốc độ nữa là

16kHz và 44.1kHz cho một vài loại mã âm thanh khác. Với payload của
tín hiệu hình ảnh thì tốc độ thường được sử dụng là 90kHZ, phụ thuộc
vào các chuẩn truyền hình khác nhau.
3.2. Sự hoạt động H.261 trên RTP
Khuyến nghị H.261 của ITU-T chỉ ra rằng mã dùng cho truyền dẫn
dữ liệu âm thanh/hình ảnh được sử dụng trên băng tần thấp. Mặc dù
được thiết kế cho các line có băng tần cố định, nhưng các nghiên cứu đã
chỉ ra rằng H.261 cũng có thể được sử dụng trên cả các mạng chuyển
mạch gói (packet-switched). Chính vì vậy mà AVT đã thiết kế các dạng
của payload cho phép truyền dẫn dữ liệu của H.261 trên RTP [12].
Để truyền các luồng âm thanh/hình ảnh bằng RTP thì mã hóa H.261
phải có một số sự thay đổi so với ban đầu.
Đầu tiên, về nguyên bản thì H.261 cho phép trộn lẫn các luồng âm
thanh/hình ảnh với nhau, nhưng điều đó lại không phù hợp với RTP vì
RTP đòi hỏi các luồng âm thanh/hình ảnh phải được truyền dẫn một cách
riêng biệt. Chính vì vậy, các luồng âm thanh và hình ảnh phải được tách
ra thành các gói RTP khác nhau. Một điểm khác biệt nữa của H.261 với
RTP đó là sử dụng các mã sửa lỗi giữa các khung dữ liệu (data frame).
Cho dù công việc sửa lỗi các frame của H.261 trong quá trình truyền dẫn
được tiến hành khá tốt, nhưng khi sử dụng RTP thì điều đó lại không cần
thiết, bởi việc phát hiện và sửa lỗi đã được thực hiện tốt ở các giao thức
lớp dưới.
H.261 luôn sử dụng các loại mã khác nhau nhằm mục đích giảm
lượng dữ liệu cần phải truyền đi. Tuy nhiên, điều đó cũng làm nảy sinh
vấn đề về mất gói, do đó cần phải có biện pháp để khắc phục hiện tượng
này. Một phương pháp đơn giản nhất được sử dụng để làm giảm số
lượng mã hóa trong nén dữ liệu là chỉ truyền đi những frame mà các
frame này hoàn toàn độc lập với các frame khác (hay còn gọi là Intra-
frames). Mặc dù đây chưa phải là giải pháp toàn diện nếu có sự giới hạn
về băng tần, dạng của payload H.261 được khuyến nghị nên dùng các

phương thức khác nhau. Bên phát có thể khôi phục lại các luồng dữ liệu
H.261 bằng cách gửi Intra-frame theo một chu kỳ nhất định, hoặc bên


11
nhận có thể gửi yêu cầu về Intra-frame khi phát hiện có hiện tượng mất
gói [7].

3.3. Dạng payload cho con trỏ thời gian thực
Giao thức RTP có thể được sử dụng để truyền các loại dữ liệu thời
gian thực khác nhau. Như ví dụ trên, dạng payload thời gian thực được
kết hợp với dữ liệu được truyền trên giao thức RTP được miêu tả một
cách ngắn gọn.Việc truyền các con trỏ thời gian thực trên Internet là cần
thiết, bởi vì khi ứng dụng trong hội nghị truyền hình để truyền âm thanh
và hình ảnh một cuộc hội thảo về đào tạo sử dụng thì lúc này con trỏ trở
nên rất cần thiết cho bài giảng của một giảng viên [11]. Con trỏ này đòi
hỏi phải có tính chính xác, thời gian di chuyển phải phù hợp với những
gì mà người giảng viên trình bày, đồng thời phải đồng bộ với tốc độ của
luồng thông tin âm thanh và hình ảnh. Sử dụng phương pháp mã hóa
thông thường RTP cho các luồng hình ảnh này là không thích hợp, bởi vì
tín hiệu hình ảnh sẽ không đạt được độ phân giải như mong muốn khi
truyền trên mạng với băng thông bị hạn chế.
Dạng của payload RTP cho con trỏ thời gian thực rất đơn giản. Nó sẽ
được thêm 3 bit dữ liệu cho ứng dụng đặc biệt này, payload sẽ sử dụng
24 bit cho con trỏ kết hợp với khoảng trắng từ hai phía và 3 bit cho biểu
tượng số của con trỏ (pointer icon number). Các tem thời gian RTP sử
dụng xung clock có tần số 90kHz, bằng với tần số của các luồng hình
ảnh được xác định trong profile cơ sở về âm thanh và hình ảnh, do vậy
việc đồng bộ con trỏ với các dữ liệu hình ảnh trở nên dễ dàng hơn [7].
4. Các khái niệm liên quan khác

4.1. Nén Header
Việc nén các header của gói tin IP/UDP/RTP là một đặc điểm rất
quan trọng để tận dụng hiệu quả băng tần trên Internet. Nếu header của
RTP chưa được nén thì chiếm ít nhất 12 byte, còn header của gói tin IP
và UDP lớn hơn 28 byte. Một số payload của dữ liệu RTP gồm có 20
byte hoặc hơn thế nữa, nhưng theo chuẩn nén RFC2508 thì các header
của RTP chỉ còn chứa khoảng 2 đến 4 byte.
Các header của RTP được nén hoạt động rất hiệu quả cho gói tin
TCP/IP [. Thuật toán nén header cơ bản bỏ qua header của các field


12
giống nhau trong quá trình truyền, như địa chỉ IP và bộ nhận dạng nguồn
RTP, bởi vì các bộ nhận dạng chỉ cần truyền duy nhất một lần, sau đó có
thể bỏ qua. Như vậy dung lượng các field có thể được giảm đáng kể bởi
trong quá trình truyền các gói tin đến sau chỉ có một lượng thay đổi nhỏ.
Thuật toán nén header yêu cầu phải được lưu ở cả hai bên phát và bên
thu. Nếu có xảy ra hiện tượng mất gói tin thì header được nén sẽ mất
đồng bộ và tăng lượng dữ liệu bị lỗi.
4.2. Quản lý thông tin các gói RTP
Giao thức SNMP là giao thức quản lý mạng được sử dụng để quản lý
và giám sát toàn mạng bao gồm cả các router và các host. SNMP được
thiết kế cho việc truyền thông tin bằng cách dùng các đối tượng dữ liệu
cơ bản cho các mục đích khác nhau để tạo cấu trúc điều khiển thông tin
(Structure of Management Information). SNMP lưu trữ các đối tượng
quản lý mạng trong các MIB (Management Information Base). Các MIB
chứa thông tin về các lớp RTP , các giao thức phát RTP cũng như các
giao thức nhận RTP. Mục đích chính của RTP MIB là tập hợp thống kê
về các lớp RTP trên mạng để xác định các trường hợp lỗi, thông tin có
thể được sử dụng tại lớp 3 cho việc giám sát trên mạng [7].

5. Kết luận
Giao thức RTP đã được phát triển mạnh vào khoảng 10 năm trở lại
đây và ngày càng trở nên tin cậy. Bên cạnh giao thức RTP, IETF còn
định nghĩa một số dạng payload cho việc truyền các dữ liệu khác nhau sử
dụng giao thức RTP. Hơn nữa, để tăng tính bảo mật IETF cũng đã giới
thiệu phương pháp nén và điều khiển các luồng dữ liệu RTP. Chỉ có một
vấn đề cần quan tâm khi thực hiện truyền trên Internet, đó là việc điều
khiển và khống chế hiện tượng tắc nghẽn luồng dữ liệu. Chính vì vậy mà
việc tìm ra phương pháp điều khiển tắc nghẽn vẫn luôn là một nhiệm vụ
khó khăn và người ta vẫn không ngừng nghiên cứu để tìm ra và có thể
khống chế nó.
Từ khi giao thức RTP được công bố thì các ứng dụng của nó cho các
hội nghị truyền hình và điện thoại Internet đã được phát triển rộng rãi.
Hơn nữa, có một số lượng lớn các phân tích thống kê cho thấy nó được
ứng dụng rộng rãi trong các bộ trộn và bộ chuyển đổi, đồng thời nó còn
được ứng dụng trong một số thư viện các phần mềm hữu ích khác. Chỉ


13
có một điều cần quan tâm khi sử dụng giao thức RTP , đó là chưa thực
sự có chuẩn ứng dụng trong lập trình giao tiếp.
Giao thức RTP là một giao thức được phát minh hoạt động trên lớp
vận chuyển (Transport layer) do đó có thể coi nó là một giao thức thuộc
lớp ứng dụng. Tuy RTP thường được dùng trong các ứng dụng ở tầng
vận chuyển nhưng nó cũng có thể dùng để ghép các gói dữ liệu thời gian
thực của các ứng dụng khác nhau cho các giao thức ở lớp dưới. Chính vì
vậy mà theo như đánh giá của Henning Schlzrinne, một trong những tác
giả chính của giao thức, thì RTP thực sự là một ứng dụng kép nghĩa là nó
có thể được coi là một giao thức của lớp ứng dụng nhưng đồng thời cũng
có thể hoạt động như một hệ thống độc lập.

14
Chương 2: TRUYỀN THÔNG TIN QUA INTERNET

Với sự phát triển của Internet như hiện nay, việc trao đổi thông tin
giữa các máy tính là nhu cầu rất cần thiết. Người ta cần có sự trao đổi dữ
liệu của các máy tính ở các vị trí địa lý khác nhau, từ đó ta có thể quản lý
dữ liệu tập trung. Mô hình sử dụng có thể là giữa Server (máy chủ) với
Client (máy trạm) hoặc giữa các Client với nhau. Để các nguồn dữ liệu
có thể chia sẻ hoặc trao đổi với nhau giữa các máy tính thì ta phải xây
dựng cách cập nhật và truy xuất các nguồn dữ liệu này.
1. Tổng quan về hệ thống Web
1.1. Giới thiệu:
Hệ thống Web là một hệ thống cung cấp thông tin trên mạng Internet
thông qua các thành phần như các Server (máy chủ), Web Browser (trình
duyệt Web) và nội dung thông tin
1.2. Mô hình hệ thống Web nói chung:


15
1.3. Nguyên tắc hoạt động:
Mạng dịch vụ Web là một mạng các máy tính liên quan đến dịch vụ
Web bao gồm các máy chủ cung cấp dịch vụ, các máy tính và các thiết bị
nhằm phục vụ cho việc cung cấp dịch vụ trên nền Web.
Khi máy Client kết nối vào Internet thì người sử dụng sẽ dùng trình
duyệt Web gõ tên miền cần truy cập để gửi yêu cầu đến máy chủ. Sau đó
Web Server sẽ xem xét và thực hiện các yêu cầu từ phía Web Browser.
Nếu trang Web là tĩnh thì Web Server sẽ lấy thông tin lưu sẵn trên

máy chủ, còn nếu là trang Web động thì sẽ sử dụng các ngôn ngữ lập
trình Web như ASP, PHP, JSP, CGI,… để kết nối và khai thác dữ liệu
[1].
2. Ngôn ngữ ASP
2.1. Ngôn ngữ HTML (Hyper Text Markup Language)
Ngôn ngữ HTML hay còn gọi là ngôn ngữ đánh dấu siêu văn bản là
một ngôn ngữ thông dụng hiển thị Web . Thực chất HTML không phải là
một ngôn ngữ lập trình, sở dĩ nó được gọi là ngôn ngữ vì nó gồm các tập
hợp nhỏ các nhóm ký tự được sử dụng theo một quy tắc nhất định để
hiển thị kiểu dáng, vị trí, kích thước của văn bản hay các đối tượng nào
đó [1].
Cấu trúc của một trang HTML có dạng như sau:
<HTML>
<Head>
<Title>
Hiển thị tiêu đề trang
<Title>
<Body>
Nội dung cần hiển thị
</Body>
</Head>
</HTML>


16

2.2. Ngôn ngữ ASP
2.2.1. Cơ bản về ASP
ASP (Active Server Page) không hẳn được coi là một ngôn ngữ lập
trình, Microsoft chỉ gọi nó là ngôn ngữ kịch bản phía Server (Server-

Side Scripting), môi trường này cho phép tạo và chạy các ứng dụng Web
Server động có hiệu quả cao. Để làm việc trong môi trường này, các
đoạn mã (Code) của ASP thường sử dụng VBScript hay JavaScript.
Các đoạn Code của ASP có thể xuất hiện mọi nơi trong trang HTML,
giữa ASP và HTML có sự gắn bó chặt chẽ với nhau. Với ASP, ta có thể
chèn các Script vào trực tiếp các file HTML, khi đó thì việc tạo ra một
trang HTML và xử lý Script trở nên đồng thời làm cho hoạt động của
Website linh hoạt, uyển chuyển.
Nội dung các Script sử dụng trong các trang ASP được chứa trong tag
<%
Nội dung của Script
%>
VBScript là ngôn ngữ mặc định của ASP và là một ngôn ngữ lập
trình nhẹ, chính vì vậy nó được gọi là Script. Nó là một phiên bản nhẹ
của ngôn ngữ lập trình Visual Basic. Khi VBScript được chèn vào trong
trang văn bản HTML thì trình duyệt Internet sẽ đọc và dịch đoạn mã này
để thực hiện ngay hoặc trong các sự kiện sau này.
Còn JavaScript là ngôn ngữ được phát triển bởi Nescape thiết kế tựa
như Java của Sun. Cấu trúc của JavaScript đơn giản dễ dàng cho người
sử dụng, được chia làm hai loại: JavaScript cho phía Server và
JavaScript cho phía Client. Nói chung hai loại Script này tương đối
giống nhau, phía trên Server dùng để tương tác các ứng dụng trên Server
còn phía Client dùng để trình bày và chạy trên máy của người sử dụng.
Nội dung đoạn mã JavaScript được chưa trong tag:
<script language="javascript"
</script>
hoặc: <script language="javascript">