Bài giảng Internet và các giao thức

BỘ THÔNG TIN VÀ TRUYỀN THÔNG

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

BÀI GIẢNG

INTERNET VÀ CÁC GIAO THỨC

(TEL 1409)

KHOA VIỄN THÔNG 1

Biên soạn: TS. Nguyễn Chiến Trinh (chủ biên)

PGS. TS. Nguyễn Tiến Ban

ThS. Nguyễn Thị Thu Hằng

Hà nội - 2014

Mục lục

MỤC LỤC

MỤC LỤC 2

DANH MỤC HÌNH VẼ 6

DANH MỤC BẢNG 9

LỜI NÓI ĐẦU 10

CHƯƠNG 1. CÁC NGUYÊN LÝ LỚP ỨNG DỤNG MẠNG INTERNET 11

Giới thiệu 11 1.1

Kiến trúc lớp ứng dụng mạng Internet 12 1.2

Kiến trúc khách/chủ 12 1.2.1

Kiến trúc ngang hàng 13 1.2.2

Quá trình truyền thông trên mạng 14 1.3

Tiến trình khách và chủ 14 1.3.1

Giao diện giữa tiến trình và mạng 15 1.3.2

Dịch vụ truyền tải cho ứng dụng 16 1.4

Truyền dữ liệu tin cậy 16 1.4.1

Thông lượng 17 1.4.2

Yêu cầu về thời gian 18 1.4.3

Khả năng đảm báo an toàn dữ liệu 18 1.4.4

Các dịch vụ truyền tải cung cấp trên mạng Internet 18 1.5

Các dịch vụ TCP 19 1.5.1

Các dịch vụ UDP 20 1.5.2

Các dịch vụ không do giao thức lớp giao vận của Internet cung cấp 20 1.5.3

Các tiến trình đánh địa chỉ 21 1.5.4

Các giao thức lớp ứng dụng 21 1.6

Một số ứng dụng mạng 22 1.7

CHƯƠNG 2. 24 WEB VÀ GIAO THỨ C HTTP

Mục lục

2.1 Tổng quan về HTTP 24

2.2 Kết nối HTTP 26

2.2.1 Kết nối không liên tục 26

2.2.2 Kết nối liên tục 28

2.3 28 Khuôn dạng bản tin HTTP

2.3.1 Bản tin yêu cầu 28

2.3.2 Bản tin đáp ứng 30

2.4 Tương tác user-server 33

2.5 Web caching 35

2.6 Bản tin GET có điều kiện 38

CHƯƠNG 3. TRUYỀN TỆP VÀ THƯ ĐIỆN TỬ 41

3.1 41 Giao thức truyền tệp FTP

3.1.1 Dịch vụ do giao thức FTP cung cấp 41

3.1.2 Các lệnh và phản hồi 42

3.2 Giao thức truyền thư điện tử trên Internet 43

3.2.1 43 Thư điện tử trên Internet

3.2.2 Giao thức truyền thư điện tử đơn giản SMTP 45

3.2.3 So sánh với HTTP 47

3.2.4 48 Khuôn dạng bản tin thư điện tử

3.2.5 Các giao thức truy cập thư điện tử 48

CHƯƠNG 4. DỊCH VỤ TÊN MIỀN DNS 54

4.1 Tổng quan DNS 54

4.1.1 54 Giới thiệu DNS

4.1.2 Dịch vụ do DNS cung cấp 54

4.2 Hoạt động của DNS 56

4.2.1 Phân bố cơ sở dữ liệu DNS 57

Mục lục

4.2.2 DNS cache 61

4.3 Bản ghi và bản tin DNS 62

4.3.1 Bản ghi DNS 62

4.3.2 Bản tin DNS 63

4.3.3 Chèn bản ghi DNS vào cơ sở dữ liệu DNS 64

4.4 Điểm yếu an toàn DNS 65

CHƯƠNG 5. CÁC ỨNG DỤNG NGANG HÀNG (P2P) 67

5.1 Cấu trúc mạng ngang hàng 67

5.2 Phân bố tệp P2P 68

5.2.1 Kiến trúc P2P 69

5.2.2 Bit Torent 72

5.3 Bảng hàm băm DHT 74

5.3.1 DHT vòng 76

5.3.2 Peer churn 78

5.4 Ứng dụng: thoại Internet sử dụng P2P 79

CHƯƠNG 6. 82 KẾT NỐI MẠNG ĐA PHƯƠNG TIỆN

6.1 Ứng dụng kết nối mạng đa phương tiện 82

6.1.1 Các ví dụ ứng dụng đa phương tiện 82

6.1.2 85 Yêu cầu chất lượng cho ứng dụng đa phương tiện trên Internet

6.1.3 Giải pháp hỗ trợ đa phương tiện trên Internet 86

6.1.4 Chuẩn nén audio và video 88

6.2 Dịch vụ audio, video lưu trữ 89

6.2.1 90 Truy cập audio và video thông qua Web server

6.2.2 91 Gửi dữ liệu đa phương tiện từ server trự c tuyến đến ứng dụng

6.2.3 Giao thức RTSP 93

6.3 Giải pháp đảm bảo chất lượng dịch vụ đa phương tiện trên Internet 97

Mục lục

6.3.1 Hạn chế của dịch vụ best-effort 97

6.3.2 Loại bỏ jitter tại bên nhận cho audio 99

6.3.3 Khôi phục mất gói 102

6.3.4 Phân bố đa phương tiện trên mạng Internet: Mạng phân tán nội dung 105

6.3.5 Định cỡ mạng best-effort để cung cấp chất lượng dịch vụ 109

6.4 110 Giao thức tương tác thờ i gian thự c

6.4.1 Giao thức RTP 110

6.4.2 Giao thức RTCP 114

CHƯƠNG 7. 118 XU HƯỚ NG PHÁT TRIỂN Ứ NG DỤNG VÀ DI ̣CH VỤ TRÊN NỀN INTERNET

7.1 Xu hướng hội tụ và mạng NGN 118

7.1.1 Xu hướng phát triển mạng toàn IP 118

7.1.2 119 Xu hướng hội tụ mạng và di ̣ch vụ

7.1.3 121 Kiến trúc tổng thể mạng NGN

7.1.4 Các thành phần mạng NGN và công nghệ 125

7.2 Ứng dụng và dịch vụ mạng NGN 128

7.2.1 Mô hình lớp ứng dụng mạng NGN 128

7.2.2 Kiến trúc di ̣ch vụ mạng NGN 129

7.2.3 Các dịch vụ trên nền NGN 138

7.3 140 Một số xu hướng phát triển ứng dụng và di ̣ch vụ trên nền Internet

7.3.1 Xu hướng phát triển mạng và dịch vụ Internet 140

7.3.2 141 Sự phát triển của công nghệ Web

7.3.3 Điện toán đám mây 151

TÀI LIỆU THAM KHẢO 158

Danh mục hình vẽ

DANH MỤC HÌNH VẼ

Hình 1.1: Truyền thông giữa các hệ thống đầu cuối ở lớp ứng dụng ................................................... 11

Hình 1.2: Kiến trúc khách/chủ (a) và ngang hàng (b) ............................................................................ 13

Hình 1.3: Tiến trình ứng dụng, socket và giao thức lớp giao vận ......................................................... 16

Hình 2.1: Hoạt động yêu cầu-đáp ứng của HTTP .................................................................................. 25

Hình 2.2: Tính toán thời gian cần thiết để yêu cầu và nhận tệp HTML................................................. 28

Hình 2.3: Khuôn dạng chung của một bản tin yêu cầu HTTP .............................................................. 30

Hình 2.4: Khuôn dạng chung của một bản tin đáp ứng HTTP ............................................................. 32

Hình 2.5: Giữ trạng thái người sử dụng với cookie ............................................................................ 34

Hình 2.6: Máy khách yêu cầu đối tượng qua máy chủ đệm Web ...................................................... 35

Hình 2.7: Nghẽn cổ chai giữa mạng của Học viện và Internet ............................................................ 37

Hình 2.8: Thêm máy chủ đệm vào mạng của Học viện ....................................................................... 38

Hình 3.1: FTP chuyển tệp giữa các hệ thống tệp cục bộ và ở xa ........................................................... 41

Hình 3.2: Kết nối điều khiển và kết nối dữ liệu ................................................................................... 42

Hình 3.3: Tổng quan về hệ thống thư điện tử Internet ...................................................................... 44

Hình 3.4: Quá trình hai người gửi thư cho nhau ................................................................................. 46

Hình 3.5: Các giao thức thư điện tử và những thực thể truyền thông của chúng ............................. 50

Hình 4.1: Cấu trúc phân cấp của máy chủ DNS .................................................................................... 57

Hình 4.2: Các máy chủ DNS gốc năm 2009 (tên, tổ chức, vị trí) ........................................................... 58

Hình 4.3: Tương tác giữa các máy chủ DNS khác nhau ........................................................................ 60

Hình 4.4: Truy vấn đệ quy trong DNS ................................................................................................... 61

Hình 4.5: Khuôn dạng bản tin DNS ....................................................................................................... 63

Hình 5.1: Minh họa phân bố tệp ........................................................................................................... 69

Hình 5.2: Thời gian phân bố đối với kiến trúc P2P và client-server ...................................................... 72

Hình 5.3: Phân bố tệp với BitTorrent .................................................................................................... 73

Danh mục hình vẽ

Hình 5.4: (a) DHT vòng, thiết bị ngang hàng 3 muốn xác định ai chịu trách nhiệm đối với khóa 11. (b) DHT vòng với các đường nối tắt ............................................................................................................ 77

Hình 6.1: Máy chủ Web gửi audio/video trực tiếp tới bộ phát phương tiện ....................................... 91

Hình 6.2: Trực tuyến từ máy chủ trực tuyến đến bộ phát phương tiện ............................................ 92

Hình 6.3: Bộ đệm khách hàng được lấp đầy và xử lý .......................................................................... 93

Hình 6.4: Tương tác giữa máy khách và máy chủ sử dụng RTSP ........................................................ 95

Hình 6.5: Mất gói đối với các trễ phát lại cố định khác nhau ........................................................... 101

Hình 6.6: Gắn kèm thông tin dư thừa chất lượng thấp .................................................................... 104

Hình 6.7: Gửi audio đan xen .............................................................................................................. 105

Hình 6.8: CDN đẩy nội dung đối tượng gắn nhãn của nhà cung cấp đến các máy chủ CDN của nó 107

Hình 6.9: CDN sử dụng DNS để hướng các yêu cầu đến máy chủ CDN gần ..................................... 108

Hình 6.10: Các trường tiêu đề RTP .................................................................................................... 111

Hình 6.11: RTP là một phần của ứng dụng và nằm trên socket UDP. ............................................... 114

Hình 6.12: RTP có thể được xem như tầng con trong tầng truyền tải ............................................. 114

Hình 6.13: Cả bên gửi và bên nhận đều gửi các bản tin RTCP .......................................................... 115

Hình 7.1: Kiến trúc chức năng của mạng NGN .................................................................................... 122

Hình 7.2: Mạng lõi và các mạng truy nhập NGN ................................................................................. 125

Hình 7.3: NGN và các miền mạng ........................................................................................................ 126

Hình 7.4: NGN và các miền dịch vụ ..................................................................................................... 127

Hình 7.5: Chức năng hỗ trợ ứng dụng, dịch vụ ................................................................................... 129

Hình 7.6: Kiến trúc Parlay trong mạng NGN ........................................................................................ 130

Hình 7.7: Cấu trúc logic OMA .............................................................................................................. 131

Hình 7.8 Mô hình hoạt động của yêu cầu chính sách ......................................................................... 132

Hình 7.9: Các giao diện môi trường dịch vụ mở -OSE ......................................................................... 133

Hình 7.10: Tương tác dựa trên WEB ................................................................................................... 134

Hình 7.11: Mô hình kiến trúc GW Parlay ............................................................................................. 135

Danh mục hình vẽ

Hình 7.12: Mô hình kiến trúc Parlay X ................................................................................................. 136

Hình 7.13: Parlay trong cấu trúc OSE .................................................................................................. 137

Hình 7.14: Parlay X trong cấu trúc OSE ............................................................................................... 138

Hình 7.15 Kiến trúc Web 1.0 điển hình ............................................................................................... 142

Hình 7.16: Kiến trúc Web 2.0 điển hình .............................................................................................. 143

Hình 7.17 Các mô hình ứng dụng Web cổ điển và AJAX ..................................................................... 147

Hình 7.18: Sự phát triển Web trong lĩnh vực tham gia trực tuyến và tương tác người sử dụng ....... 148

Hình 7.19: Xu hướng phát triển công nghệ Web ................................................................................ 151

Hình 7.20: Ảo hóa ................................................................................................................................ 154

Hình 7.21: Mô hình triển khai Điện toán đám mây ............................................................................. 156

Danh mục bảng

DANH MỤC BẢNG

Bảng 1.1: Yêu cầu của một số ứng dụng mạng ..................................................................................... 18

Bảng 1.2: Các ứng dụng Internet điển hình, giao thức lớp ứng dụng và giao vận ................................ 21

Bảng 6.1: Ba giải pháp hỗ trợ ứng dụng đa phương tiện ................................................................... 87

Bảng 6.2: Một số loại tải trọng audio được RTP hỗ trợ .................................................................... 112

Bảng 6.3: Một số loại tải trọng video được RTP hỗ trợ .................................................................... 112

Bảng 7.1: So sánh Web 1.0 và Web 2.0 ............................................................................................... 143

Lời nói đầu

LỜI NÓI ĐẦU

Các ứng dụng mạng đa dạng là lý do tồn tại của Internet. Từ khi Internet ra đời, đã có rất nhiều giao thức được thiết kế để hỗ trợ sự phát triển và kiến tạo ra các ứng dụng mạng. Những ứng dụng đầu tiên dựa trên nền ký tự như e-mail thuần, truy nhập máy tính từ xa, truyền tệp và chát ký tự đã trở thành thông dụng từ thập kỷ 1970. Từ giữa thập kỷ 1990 những ứng dụng điển hình là WWW (World Wide Web), tìm kiếm và thương mại điện tử. Tiếp đến là những ứng dụng như nhắn tin tức thời với danh sách lưu sẵn và chia sẻ tệp P2P. Và gần đây, những ứng dụng audio và video như điện thoại Internet, chia sẻ tệp video, radio Internet và IPTV đang ngày càng phát triển và phổ biến. Ngoài ra, sự mở rộng của truy nhập băng rộng và không dây ở mọi lúc mọi nơi có thể là tiền đề dẫn đến một giai đoạn mới cho các ứng dụng thú vị trong tương lai.

Tài liệu được biên soạn phục vụ cho môn học về mạng Internet và các giao thức. Nội dung tài liệu gồm 7 chương và chia thành 3 phần. Phần thứ nhất trình bày những khái niệm cơ bản liên quan đến sự triển khai của ứng dụng mạng. Những vấn đề chính được đề cập bao gồm kiến trúc khách/chủ (client/server) và ngang hàng P2P (peer-to-peer), khái niệm tiến trình (process), giao diện lớp truyền tải và sự phát triển của các ứng dụng mạng trên nền TCP/UDP. Trong phần này của tài liệu cũng xem xét chi tiết một số ứng dụng điển hình như Web, e-mail, DNS, phân phối tệp P2P và điện thoại Internet P2P.

Phần thứ hai của tài liệu trình bày về các ứng dụng đa phương tiện. Những vấn đề chính được đề cập bao gồm: phân loại ứng dụng đa phương tiện; các ứng dụng audio/video lưu trữ, audio/video trực tuyến và audio/video tương tác thời gian thực; các yêu cầu của ứng dụng đa phương tiện đối với mạng và phương thức phát luồng audio/video; các giao thức hỗ trợ cho truyền thông đa phương tiện và các kỹ thuật nâng cao hiệu năng của ứng dụng đa phương tiện trên Internet hiện nay.

Trong phần thứ ba của tài liệu sẽ trình bày về xu hướng phát triển của các ứng dụng và dịch vụ trên nền Internet. Những nội dung chính được giới thiệu là xu hướng hội tụ mạng và dịch vụ viễn thông, khái niệm NGN, các ứng dụng và dịch vụ của NGN, một số xu hướng phát triển của ứng dụng và dịch vụ trên nền Internet như công nghệ Web hay điện toán đám mây.

Tài liệu được biên soạn trong thời gian tương đối ngắn nên không tránh khỏi còn những thiếu sót. Nhóm tác giả rất mong nhận được nhiều ý kiến đóng góp từ phía độc giả và các đồng nghiệp.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

CÁC NGUYÊN LÝ LỚP ỨNG DỤNG MẠNG INTERNET

Equation Section (Next)

Giới thiệu

Giả sử chúng ta có ý tưởng cho một ứng dụng mạng mới. Ứng dụng này có thể là một dịch vụ rất tốt cho mọi người hoặc đơn giản chỉ là để phát triển. Cho dù động cơ phát triển ứng dụng là gì thì chúng ta hãy cùng tìm hiểu xem cách thực hiện ý tưởng vào môi trường thực của ứng dụng mạng như thế nào.

Hình Error! No text of specified style in document..1: Truyền thông giữa các hệ thống đầu cuối ở lớp ứng dụng

Phần chính của quá trình phát triển ứng dụng mạng là viết chương trình chạy trên các hệ thống đầu cuối khác nhau để thực hiện truyền thông qua mạng. Ví dụ, trong ứng dụng web có hai chương trình phần mềm riêng biệt truyền thông với nhau: phần mềm trình duyệt chạy trên thiết bị đầu cuối của người sử dụng (máy tính bàn, máy tính xách tay, PDA, điện thoại di động, …) và phần mềm máy chủ chạy trên máy chủ web. Hoặc ví dụ khác, trong hệ thống chia sẻ tệp ngang hàng (P2P file sharing) có một chương trình chạy ở cả hai trạm đều tham gia vào cộng đồng chia sẻ tệp. Trong trường hợp này, các chương trình trong các trạm khác nhau có thể gần giống hoặc giống hệt nhau.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Vì vậy, khi phát triển một ứng dụng mới thì cần phải xây dựng phần mềm chạy trên nhiều hệ thống cuối. Phần mềm này có thể viết dựa trên C, Java hoặc Python. Điều quan trọng là chúng ta không cần phải viết phần mềm chạy trên các thiết bị mạng lõi như bộ định tuyến hay bộ chuyển mạch. Ngay cả khi muốn viết phần mềm ứng dụng cho các thiết bị mạng lõi cũng không cần phải làm như vậy. Như đã biết, các thiết bị mạng lõi không thực hiện chức năng lớp ứng dụng mà thực hiện chức năng ở các lớp thấp hơn, chủ yếu là ở lớp mạng và các lớp dưới. Thiết kế cơ bản này đẩy phần mềm ứng dụng vào trong hệ thống cuối (Hình Error! No text of specified style in document..1), tạo điều kiện cho sự phát triển và triển khai nhanh chóng của rất nhiều ứng dụng mạng.

Kiến trúc lớp ứng dụng mạng Internet

Trước khi đi vào việc mã hóa phần mềm, cần phải có kế hoạch về kiến trúc cho ứng dụng. Lưu ý là kiến trúc ứng dụng khác hoàn toàn với kiến trúc mạng (như kiến trúc phân lớp của Internet). Từ quan điểm của người phát triển ứng dụng, kiến trúc mạng là cố định và cung cấp một tập các dịch vụ cho các ứng dụng. Mặt khác, kiến trúc ứng dụng được các nhà phát triển ứng dụng thiết kế và chỉ rõ cách cấu trúc ứng dụng đó trên nhiều hệ thống cuối khác nhau. Khi xây dựng kiến trúc ứng dụng, một nhà phát triển ứng dụng có thể lựa chọn một trong hai mô hình nổi bật được dùng trong các ứng dụng mạng hiện tại: kiến trúc khách/chủ (client/server) hoặc kiến trúc ngang hàng (P2P - peer-to-peer).

Kiến trúc khách/chủ

Trong kiến trúc khách/chủ luôn có một máy trạm hoạt động gọi là máy chủ (server). Nó phục vụ các yêu cầu từ nhiều máy trạm khác (client). Các máy khách có thể hoạt động liên tục hoặc không. Ví dụ về ứng dụng web: luôn có máy chủ web hoạt động để phục vụ yêu cầu từ các trình duyệt chạy trên trạm khách. Khi máy chủ web nhận một yêu cầu về đối tượng từ trạm khách thì nó đáp ứng thông qua việc gửi đối tượng đó tới trạm khách.

Để ý là với kiến trúc khách/chủ, các máy khách không truyền thông trực tiếp với nhau, ví dụ trong ứng dụng web thì hai trình duyệt không truyền thông trực tiếp với nhau. Một đặc điểm nữa của kiến trúc này là máy chủ có địa chỉ cụ thể và cố định (địa chỉ IP). Chính vì đặc điểm này và việc máy chủ luôn hoạt động nên một máy khách luôn có thể kết nối với máy chủ bằng việc gửi gói tin tới địa chỉ của máy chủ. Một vài ứng dụng nổi tiếng với kiến trúc khách/chủ là web, FTP, Telnet và e-mail. Hình Error! No text of specified style in document..2(a) là minh họa kiến trúc khách/chủ.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

1. (b)

Hình Error! No text of specified style in document..2: Kiến trúc khách/chủ (a) và ngang hàng (b)

Thường trong ứng dụng khách/chủ, một trạm chủ đơn lẻ không có khả năng đáp ứng kịp những yêu cầu từ các máy khách của nó. Ví dụ, một điểm kết nối xã hội phổ biến có thể nhanh chóng bị sập nếu nó chỉ có một máy chủ xử lý tất cả các yêu cầu. Vì lý do này, một nhóm trạm lớn – đôi khi được gọi là trung tâm dữ liệu – được dùng để tạo ra một máy chủ ảo mạnh trong kiến trúc khách/chủ. Các dịch vụ ứng dụng dựa trên kiến trúc khách/chủ thường là cần nhiều cơ sở hạ tầng vì chúng yêu cầu nhà cung cấp dịch vụ phải mua, cài đặt và bảo dưỡng cụm máy chủ. Hơn nữa, các nhà cung cấp dịch vụ phải trả phí cho việc kết nối liên mạng định kỳ và băng thông cho việc gửi và nhận dữ liệu tới và từ Internet. Các dịch vụ phổ biến như công cụ tìm kiếm (ví dụ như Google), thương mại Internet (như Amazon và e-Bay), thư điện tử trên Web (như Yahoo Mail), kết nối mạng xã hội (như MySpace và Facebook) và chia sẻ video (như YouTube) là những dịch vụ cần nhiều cơ sở hạ tầng và tốn chi phí để cung cấp.

Kiến trúc ngang hàng

Trong kiến trúc ngang hàng (P2P: peer-to-peer) có rất ít (hoặc không có) máy chủ hạ tầng luôn hoạt động. Thay vào đó, ứng dụng khai thác truyền thông trực tiếp giữa cặp trạm kết nối liên tục, gọi là các thiết bị ngang hàng (peer). Các thiết bị ngang hàng này không phải của nhà cung cấp dịch vụ mà là các máy tính bàn, máy tính xách tay do người sử dụng điều khiển và hầu hết thiết bị ngang hàng nằm trong nhà, trong trường học hay trong các công sở. Vì truyền thông giữa các thiết bị ngang hàng không cần qua máy chủ dành riêng nên kiến trúc này được gọi là ngang hàng.

Rất nhiều ứng dụng thông dụng và ứng dụng cần lưu lượng lớn ngày nay dựa trên kiến trúc ngang hàng như phân bổ tệp (như BitTorrent), chia sẻ tệp (như eMule và LimeWire), điện thoại Internet (như Skype) và IPTV (như PPLive). Kiến trúc ngang hàng được minh họa trong Hình Error! No text of specified style in document..2(b). Để ý rằng một số ứng dụng có kiến trúc lai ghép, kết hợp cả các phần tử khách/chủ và ngang hàng. Ví dụ, với nhiều ứng dụng gửi tin nhắn tức thời, các máy chủ được dùng để truy vết các địa chỉ IP của người sử dụng, nhưng các bản tin người sử dụng-người sử dụng

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

thì gửi trực tiếp giữa các máy trạm của người sử dụng (mà không cần chuyển tiếp qua các máy chủ trung gian).

Một trong những đặc điểm hấp dẫn nhất của kiến trúc P2P là khả năng tự mở rộng (self-scalability). Ví dụ, trong ứng dụng chia sẻ tệp P2P, mặc dù mỗi thiết bị ngang hàng tạo ra tải trọng bằng việc yêu cầu lấy tệp, mỗi thiết bị ngang hàng cũng tăng thêm dung lượng dịch vụ cho hệ thống bằng cách phân phối tệp tới các thiết bị ngang hàng khác. Kiến trúc P2P cũng hiệu quả về chi phí vì thông thường chúng không cần hạ tầng máy chủ và băng thông máy chủ. Để giảm chi phí, các nhà cung cấp dịch vụ (MSN, Yahoo…) ngày càng quan tâm đến việc sử dụng kiến trúc P2P cho các ứng dụng của họ.

Tuy nhiên, các ứng dụng P2P trong tương lai gặp phải ba thách thức chính:

Tính thân thiện của các nhà cung cấp dịch vụ Internet (ISP). Hầu hết các ISP (gồm cả ISP cáp và DSL) đã ước định sử dụng băng thông bất đối xứng, nghĩa là băng thông chiều xuống lớn hơn băng thông chiều lên. Song các ứng dụng phân bổ tệp và video trực tuyến P2P thì lại chuyển lưu lượng lên từ các máy chủ đến các ISP dân thường, do đó sẽ đẩy áp lực đáng kể lên các ISP. Các ứng dụng P2P tương lai cần phải được thiết kế để thân thiện với các ISP.

An toàn. Vì có đặc tính mở và phân bổ rộng khắp nên các ứng dụng P2P sẽ có thách thức về vấn đề an toàn.

Khích lệ. Thành công của các ứng dụng P2P còn phụ thuộc vào việc thuyết phục được người sử dụng tình nguyện chia sẻ nguồn lực như băng thông, bộ nhớ và khả năng tính toán cho các ứng dụng, đây cũng là thách thức trong thiết kế cần được lưu ý.

Quá trình truyền thông trên mạng

Trước khi xây dựng ứng dụng, cần phải có hiểu biết cơ bản về cách thức để chương trình chạy trên các hệ thống cuối truyền thông với nhau. Trong thuật ngữ của hệ thống vận hành, đó không thực sự là các chương trình mà là các tiến trình truyền thông với nhau. Có thể coi tiến trình là một chương trình chạy trong một hệ thống cuối. Khi các tiến trình chạy trên cùng một hệ thống cuối thì chúng truyền thông với nhau theo kiểu truyền thông liên tiến trình, sử dụng những quy tắc do hệ điều hành của hệ thống đầu cuối đó điều khiển. Song ở đây, chúng ta không tập trung vào các tiến trình truyền thông trên cùng một trạm mà quan tâm đến những tiến trình chạy trên các trạm khác nhau (có thể các trạm này còn chạy các hệ điều hành khác nhau).

Các tiến trình trên hai hệ thống đầu cuối khác nhau truyền thông với nhau bằng cách gửi các bản tin xuyên qua mạng máy tính. Tiến trình gửi tạo ra và gửi bản tin vào mạng, tiến trình nhận sẽ nhận những bản tin này và có thể đáp lại bằng việc gửi bản tin ngược lại. Hình Error! No text of specified style in document..1 minh hoạ các các tiến trình truyền thông với nhau sử dụng lớp ứng dụng trong mô hình giao thức 5 lớp.

Tiến trình khách và chủ

Mỗi ứng dụng mạng có một cặp tiến trình gửi bản tin cho nhau qua mạng. Ví dụ, trong ứng dụng Web tiến trình trình duyệt khách trao đổi bản tin với tiến trình máy chủ Web. Trong hệ thống chia sẻ

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

tệp P2P, một tệp được chuyển từ một tiến trình ở một thiết bị ngang hàng này sang một tiến trình ở thiết bị ngang hàng khác. Với mỗi cặp tiến trình truyền thông, chúng ta gán tên cho hai tiến trình này là khách và chủ. Với ứng dụng Web, trình duyệt là tiến trình khách, còn máy chủ Web là tiến trình chủ. Với ứng dụng chia sẻ tệp P2P thì thiết bị ngang hàng tải tệp dữ liệu xuống được gọi là khách còn thiết bị ngang hàng tải dữ liệu lên được gọi là chủ.

Có thể thấy là trong một vài ứng dụng, ví dụ như chia sẻ tệp P2P, một tiến trình có thể vừa là khách vừa là chủ. Thực tế là một tiến trình trong hệ thống chia sẻ tệp P2P có thể tải tệp lên và xuống. Tuy nhiên, trong ngữ cảnh của một phiên truyền thông cho trước giữa một cặp tiến trình thì chúng ta vẫn gán tên cho một tiến trình là khách và tiến trình còn lại là chủ. Ta có định nghĩa tiến trình khách và chủ như sau:

Trong ngữ cảnh phiên truyền thông giữa một cặp tiến trình, tiến trình kích hoạt truyền thông (nghĩa là khởi đầu liên hệ với tiến trình khác tại đầu phiên) được gọi là khách. Còn tiến trình chờ được liên lạc để bắt đầu phiên là chủ.

Trong ứng dụng Web, tiến trình trình duyệt kích hoạt liên hệ với tiến trình máy chủ Web, vì vậy tiến trình trình duyệt là khách và tiến trình máy chủ Web là chủ. Trong ứng dụng chia sẻ tệp P2P thì khi thiết bị ngang hàng A hỏi thiết bị ngang hàng B gửi một tệp cụ thể thì thiết bị ngang hàng A là khách và thiết bị ngang hàng B là chủ trong ngữ cảnh của phiên truyền thông cụ thể này. Đôi khi chúng ta có thể sử dụng thuật ngữ “phía khách” và “phía chủ” của một ứng dụng.

Giao diện giữa tiến trình và mạng

Như đã thấy ở trên, hầu hết các ứng dụng chứa các cặp tiến trình truyền thông trong đó hai tiến trình trong một cặp gửi bản tin cho nhau. Bất kỳ bản tin nào được gửi từ tiến trình này sang tiến trình khác đều phải đi qua mạng hạ tầng. Một tiến trình gửi bản tin vào mạng và nhận bản tin từ mạng qua một giao diện phần mềm gọi là socket. Hãy xem xét khái niệm tiến trình và socket. Một tiến trình giống như một cái nhà và socket giống như cánh cửa. Khi một tiến trình muốn gửi bản tin đến một tiến trình trên trạm khác thì nó gửi bản tin qua cánh cửa (socket) của nó. Tiến trình gửi này giả định rằng có cơ sở hạ tầng truyền tải ở bên kia của cánh cửa sẽ truyền bản tin tới cửa của tiến trình bên nhận. Một khi bản tin đã tới trạm đích thì các bản tin sẽ chuyển qua cửa tiến trình nhận (socket) và tiến trình nhận sẽ nhận các bản tin này.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Hình Error! No text of specified style in document..3: Tiến trình ứng dụng, socket và giao thức lớp giao vận

Hình Error! No text of specified style in document..3 minh hoạ việc truyền thông socket giữa hai tiến trình truyền thông qua Internet (trong đó giả định là giao thức giao vận mà tiến trình sử dụng là TCP.) Trong hình này, socket là giao diện giữa lớp ứng dụng và lớp giao vận trong một trạm. Nó cũng được coi là API (giao diện lập trình ứng dụng) giữa ứng dụng và mạng, vì socket là giao diện lập trình mà ứng dụng mạng xây dựng cùng. Các nhà phát triển ứng dụng đã điều khiển lớp giao vận của socket. Nhà phát triển ứng dụng chỉ phải thực hiện điều khiển trên lớp giao vận: (1) lựa chọn giao thức lớp giao vận và (2) là khả năng ấn định một vài tham số lớp giao vận mới như bộ đệm tối đa và kích thước đoạn tối đa. Một khi nhà phát triển ứng dụng chọn một giao thức lớp giao vận thì ứng dụng được xây dựng sẽ sử dụng dịch vụ cung cấp bởi giao thức giao vận đó.

Dịch vụ truyền tải cho ứng dụng

Ta đã biết là socket là giao diện giữa tiến trình ứng dụng và giao thức lớp giao vận. Ứng dụng ở bên gửi đẩy các bản tin qua socket. Ở phía bên kia của socket giao thức lớp giao vận có trách nhiệm đẩy các bản tin tới “cánh cửa” của socket bên nhận.

Rất nhiều mạng, bao gồm cả Internet, cung cấp nhiều giao thức lớp giao vận. Khi triển khai một ứng dụng, ta phải chọn một trong những giao thức lớp giao vận đó. Vậy lựa chọn như thế nào? Thông thường ta sẽ nghiên cứu những dịch vụ do các giao thức lớp giao vận sẵn có cung cấp và chọn giao thức có dịch vụ phù hợp nhất với yêu cầu cho ứng dụng của mình. Tình huống này giống như việc chọn hoặc là vận chuyển bằng tàu hoả hoặc là máy bay để đi lại giữa hai thành phố. Mỗi phương thức vận chuyển sẽ cho các dịch vụ với những đặc tính khác nhau (ví dụ, tàu hoả sẽ có nhiều điểm dừng đỗ trong khi máy bay thì lại rút ngắn thời gian đi lại hơn).

Vậy những dịch vụ nào giao thức lớp giao vận có thể cung cấp cho ứng dụng của nó? Chúng ta có thể phân loại các dịch vụ theo 4 tiêu chí là tính tin cậy, thông lượng, yêu cầu về thời gian và khả năng đảm bảo an toàn cho dữ liệu.

Truyền dữ liệu tin cậy

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Ta biết là các gói tin có thể bị mất trong mạng máy tính. Ví dụ, một gói có thể làm tràn bộ đệm trong bộ định tuyến hoặc có thể bị loại bỏ ở trạm hay bộ định tuyến sau khi có một vài bit bị hỏng. Đối với nhiều ứng dụng, như thư điện tử, truyền tệp, truy nhập từ xa, truyền dữ liệu Web và các ứng dụng tài chính, việc mất dữ liệu có thể mang lại hậu quả rất khôn lường. Vì vậy để hỗ trợ những dịch vụ này cần phải làm gì đó để đảm bảo dữ liệu gửi ở một đầu ứng dụng được truyền chính xác và đầy đủ đến đầu kia của ứng dụng.

Nếu một giao thức cung cấp dịch vụ truyền tải dữ liệu an toàn như vậy thì nó được gọi là truyền dữ liệu tin cậy. Một dịch vụ quan trọng mà giao thức lớp giao vận có thể cung cấp cho ứng dụng là truyền dữ liệu tin cậy từ tiến trình đến tiến trình. Khi một giao thức lớp giao vận cung cấp dịch vụ này thì tiến trình bên gửi có thể chỉ chuyển dữ liệu của nó đến socket và tin tưởng hoàn toàn là dữ liệu sẽ đến tiến trình bên nhận mà không hề bị lỗi.

Khi một giao thức lớp giao vận không cung cấp việc truyền dữ liệu tin cậy thì dữ liệu gửi từ tiến trình gửi có thể không tới được tiến trình nhận. Điều này có thể chấp nhận với những ứng dụng chịu được lỗi. Hầu hết các ứng dụng đa phương tiện như audio/video thời gian thực hoặc audio/video lưu trữ có thể chịu được một tỷ lệ lỗi nhất định. Trong những ứng dụng đa phương tiện này, dữ liệu bị mất có thể dẫn tới trục trặc nhỏ trên màn hiển thị audio/video – đây không phải là suy giảm quan trọng lắm.

Thông lượng

Trong ngữ cảnh phiên truyền thông giữa hai tiến trình qua đường truyền trên mạng thông lượng khả dụng là tốc độ mà tiến trình gửi có thể gửi bít đến tiến trình nhận. Vì những phiên khác cũng chia sẻ băng thông trên đường truyền đó và những phiên khác này sẽ đến và đi nên thông lượng khả dụng có thể thay đổi theo thời gian. Những quan sát này dẫn đến một dịch vụ mà giao thức lớp giao vận có thể cung cấp đó là thông lượng khả dụng đảm bảo ở một tốc độ cụ thể nào đó.

Với những dịch vụ như vậy, ứng dụng có thể yêu cầu băng thông đảm bảo r bit/s và giao thức lớp giao vận có thể đảm bảo là thông lượng khả dụng ít nhất phải đạt r bit/s. Dịch vụ đảm bảo thông lượng như vậy có thể xuất hiện ở rất nhiều ứng dụng. Ví dụ, nếu một ứng dụng thoại Internet mã hoá thoại ở tốc độ 32kb/s thì nó cần gửi dữ liệu vào mạng và dữ liệu được truyền tới ứng dụng bên gửi ở tốc độ này. Nếu giao thức giao vận không thể cung cấp được thông lượng này thì ứng dụng sẽ cần phải mã hoá ở tốc độ thấp hơn (và nhận đủ thông lượng để duy trình được tốc độ thấp hơn này). Nếu không thì phải bỏ ứng dụng vì nếu thông lượng không đủ thì lưu lượng thoại không thể truyền đi được.

Ứng dụng có yêu cầu về thông lượng được gọi là ứng dụng nhạy cảm băng thông. Rất nhiều ứng dụng đa phương tiện ngày nay nhạy cảm về băng thông, mặc dù một vài ứng dụng thời gian thực có thể sử dụng các kỹ thuật mã hoá thích nghi để mã hóa ở tốc độ phù hợp với thông lượng khả dụng hiện có.

Trong khi các ứng dụng nhạy cảm băng thông có yêu cầu thông lượng cụ thể thì những ứng dụng “co dãn” (elastic) có thể tận dụng khả năng tối đa của thông lượng có sẵn (khả dụng). Thư điện tử, truyền

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

tệp, Web là những ứng dụng có tính chất co dãn. Dĩ nhiên là thông lượng càng lớn thì việc truyền ứng dụng càng tốt.

Yêu cầu về thời gian

Một giao thức lớp giao vận cũng có thể đảm bảo việc định thời. Cùng với sự đảm bảo về thông lượng, đảm bảo về định thời cũng có thể xuất hiện với nhiều kiểu và dạng khác nhau. Ví dụ, sự đảm bảo có thể là mỗi bít mà bên gửi chuyển cho socket phải tới socket bên nhận trong khoảng thời gian nhỏ hơn 100ms. Những dịch vụ như vậy có thể hấp dẫn với các ứng dụng tương tác thời gian thực như điện thoại Internet, môi trường ảo, hội nghị từ xa, trò chơi đa bên. Chúng yêu cầu những giới hạn định thời rất chặt chẽ về chuyển phát dữ liệu. Ví dụ, trễ lớn trong điện thoại Internet sẽ dẫn tới việc ngưng hội thoại bất thường. Ở trò chơi đa bên hay môi trường tương tác ảo trễ lớn giữa việc thực hiện một hành động và đáp ứng từ môi trường (ví dụ từ một đối thủ cùng chơi khác ở đầu kia của kết nối) sẽ làm cho cảm nhận ứng dụng kém tính thực tế. Đối với những ứng dụng không cần thời gian thực thì trễ ít vẫn luôn tốt hơn trễ nhiều, song không có một giới hạn chặt nào áp đặt lên trễ toàn trình.

Khả năng đảm báo an toàn dữ liệu

Sau cùng, một giao thức lớp giao vận có thể cung cấp ứng dụng với một hoặc nhiều dịch vụ an toàn. Ví dụ, trong trạm gửi, một giao thức lớp giao vận có thể mã hoá toàn bộ dữ liệu truyền trong tiến trình gửi, và ở trạm nhận, giao thức lớp giao vận có thể giải mã dữ liệu trước khi chuyển dữ liệu đến tiến tình nhận. Dịch vụ như vậy cung cấp tính bí mật giữa hai tiến trình, ngay cả khi dữ liệu có thể bị quan sát trong tiến trình gửi và nhận. Một giao thức lớp giao vận cũng có thể cung cấp dịch vụ an toàn khác ngoài tính bí mật, bao gồm tính toàn vẹn dữ liệu và xác thực đầu cuối.

Các dịch vụ truyền tải cung cấp trên mạng Internet

Ở trên đã giới thiệu tổng quan về các dịch vụ truyền tải mà mạng máy tính có thể cung cấp. Sau đây ta xem xét cụ thể hơn các loại ứng dụng trên Internet. Nói chung là mạng TCP/IP có hai giao thức giao vận là TCP và UDP. Khi người phát triển ứng dụng tạo ra một ứng dụng mới cho Internet, một trong những việc đầu tiên cần làm là quyết định sử dụng TCP hay UDP. Mỗi giao thức này đưa ra một tập dịch vụ khác nhau cho việc triển khai ứng dụng.

Bảng Error! No text of specified style in document..1 cho thấy những yêu cầu dịch vụ đối với một vài ứng dụng điển hình.

Bảng Error! No text of specified style in document..1: Yêu cầu của một số ứng dụng mạng

Ứng dụng Tổn thất dữ liệu Băng thông Độ nhạy về thời gian

Truyền tệp Không tổn thất Thay đổi Không

E-mail (thư điện tử) Không tổn thất Thay đổi Không

Web Không tổn thất Thay đổi (vài kb/s) Không

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Chịu được tổn thất

Audio: vài kb/s – 1 Mb/s Video: 10kb/s – 5Mb/s Điện thoại Internet/ hội nghị Video Audio/video lưu trữ Chịu được tổn thất Có: n×100 ms Có: n×s

Trò chơi tương tác Chịu được tổn thất Vài kb/s-10kb/s Có: n×100ms

Nhắn tin thức thời Không tổn thất Thay đổi Có và không

Các dịch vụ TCP

Giao thức TCP cung cấp dịch vụ hướng kết nối và dịch vụ truyền dữ liệu tin cậy. Khi một ứng dụng kích hoạt TCP làm giao thức truyền tải, ứng dụng nhận cả hai dịch vụ trên từ TCP.

Dịch vụ hướng kết nối

Trong TCP tiến trình khách và chủ trao đổi thông tin điều khiển lớp giao vận với nhau trước khi bản tin lớp ứng dụng bắt đầu được gửi. Thủ tục bắt tay này thông báo cho máy khách và máy chủ để cho phép chúng chuẩn bị gửi gói tin. Sau giai đoạn bắt tay thì có một kết nối TCP được tạo ra giữa socket của hai tiến trình. Kết nối này là song công vì hai tiến trình có thể gửi bản tin đồng thời cho nhau qua kết nối vừa thiết lập. Khi ứng dụng kết thúc việc gửi bản tin, nó phải xoá bỏ kết nối này. Dịch vụ này được gọi là dịch vụ hướng kết nối, tuy nhiên hai tiến trình được kết nối theo một cách rất lỏng.

Dịch vụ truyền dữ liệu tin cậy

Các tiến trình truyền thông có thể dựa vào TCP để chuyển toàn bộ dữ liệu mà không sợ bị lỗi hay sai thứ tự. Khi một bên của ứng dụng chuyển dòng dữ liệu tới một socket, TCP đảm bảo chuyển dòng dữ liệu này tới socket bên nhận mà không làm mất hay lặp dữ liệu.

TCP cũng có cơ chế điều khiển tắc nghẽn, đây là dịch vụ phục vụ chung cho Internet chứ không phải chỉ vì lợi ích trực tiếp của các tiến trình truyền thông. Trong cơ chế này, TCP điều chỉnh tiến trình gửi (khách hoặc chủ) khi mạng bị tắc nghẽn giữa bên gửi và bên nhận. TCP cũng hạn chế cho mỗi kết nối TCP một băng thông chia sẻ công bằng. Việc điều chỉnh tốc độ này có thể gây ảnh hưởng tới các ứng dụng audio và video thời gian thực có yêu cầu băng thông tối thiểu phải đáp ứng. Ngoài ra, các ứng dụng thời gian thực có thể chịu được tổn thất và không cần phải là dịch vụ truyền tải tin cậy hoàn toàn. Chính vì những lý do này mà các nhà phát triển ứng dụng thời gian thực thường cho các ứng dụng này chạy trên nền UDP hơn là TCP.

Đảm bảo an toàn dữ liệu

Cả TCP và UDP đều không sử dụng mã khoá: dữ liệu gửi tới socket giống hệt như dữ liệu truyền trên mạng tới tiến trình đích. Vì vậy, nếu tiến trình bên gửi gửi mật khẩu dưới dạng tường minh (không mật mã hoá) vào socket của nó thì mật khẩu này sẽ đi dọc trên các liên kết giữa bên gửi và bên nhận, và nó có thể bị phát hiện trên bất kỳ kết nối nào. Vì tính riêng tư và an toàn trở nên quan trọng với nhiều ứng dụng nên cộng đồng Internet đã phát triển TCP với SSL (Secure Sockets Layer – lớp socket an toàn). TCP nâng cao với SSL không chỉ thực hiện đầy đủ chức năng TCP truyền thống mà còn cung cấp thêm các dịch vụ an toàn tiến trình-tiến trình bao gồm mật mã hoá, toàn vẹn dữ liệu và xác thực điểm cuối. 19

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Ở đây, SSL không phải là giao thức lớp giao vận, cùng mức với TCP và UDP mà là sự nâng cao của TCP được thực thi ở lớp ứng dụng. Cụ thể là nếu một ứng dụng muốn sử dụng dịch vụ với SSL thì nó cần bao gồm mã SSL (các lớp và thư viện bậc cao) ở cả phía khách và chủ của ứng dụng. Cũng giống như TCP truyền thống, SSL có API socket riêng. Khi ứng dụng sử dụng SSL, tiến trình gửi sẽ gửi dữ liệu tường minh tới socket SSL. SSL trong trạm gửi sẽ mật mã hoá dữ liệu và chuyển dữ liệu đã mã hoá này tới socket TCP. Dữ liệu đã mật mã hoá này sẽ đi qua Internet tới socket TCP của tiến trình nhận. Socket bên nhận sẽ chuyển dữ liệu đã mật mã hoá này tới SSL để giải mã dữ liệu. Cuối cùng, SSL chuyển dữ liệu tường minh qua socket SSL của mình tới tiến trình nhận.

Các dịch vụ UDP

UDP là giao thức giao vận rất đơn giản được dùng để cung cấp những dịch vụ tối thiểu. Là giao thức phi kết nối, UDP không có bước bắt tay trước khi hai tiến trình bắt đầu truyền thông với nhau. UDP cung cấp dịch vụ vận chuyển dữ liệu không tin cậy nghĩa là khi một tiến trình gửi bản tin vào một socket UDP thì UDP không đảm bảo là bản tin đó sẽ tới được tiến trình nhận. Hơn nữa, các bản tin có thể tới tiến trình nhận không theo đúng thứ tự.

UDP cũng không có cơ chế điều khiển tắc nghẽn, vì vậy UDP phía gửi có thể đẩy dữ liệu xuống lớp mạng với bất kỳ tốc độ nào (tuy nhiên, lưu ý là thông lượng đầu cuối-đầu cuối thực sự có thể ít hơn tốc độ này do giới hạn của băng thông trên các liên kết hoặc do nghẽn mạng). Vì các ứng dụng thời gian thực có thể chịu được tổn thất song lại yêu cầu phải đảm bảo một tốc độ tối thiểu nên các nhà phát triển ứng dụng thời gian thực nhiều khi chọn UDP làm giao thức lớp giao vận, để tránh cơ chế điều khiển nghẽn của TCP và sức nặng của tiêu đề gói tin. Mặt khác, vì có rất nhiều tường lửa được cấu hình để chặn lưu lượng UDP, nên các nhà thiết kế lại phải tăng lựa chọn chạy các ứng dụng thời gian thực và đa phương tiện trên TCP.

Các dịch vụ không do giao thức lớp giao vận của Internet cung cấp

Chúng ta đã sắp xếp các dịch vụ lớp giao vận theo bốn tiêu chí: truyền dữ liệu tin cậy, thông lượng, yêu cầu thời gian và tính an toàn. Những dịch vụ nào do TCP và UDP cung cấp? Ở trên đã chỉ ra là TCP cung cấp các dịch vụ truyền dữ liệu đầu cuối-đầu cuối tin cậy và TCP dễ dàng nâng cao tính an toàn cho lớp ứng dụng bằng cách sử dụng SSL. Song qua tìm hiểu ngắn gọn về UDP và TCP, ta thấy rõ là chúng đã thiếu sự đảm bảo về thông lượng hoặc định thời. Đây chính là những yêu cầu mà các giao thức giao vận Internet truyền thống không cung cấp được.

Vậy có phải là những dịch vụ nhạy cảm về mặt thời gian như điện thoại Internet không thể chạy được trên Internet ngày nay không? Câu trả lời là Internet đã cung cấp các dịch vụ nhạy cảm thời gian thực trong nhiều năm. Những ứng dụng này thường hoạt động tốt vì chúng đã được thiết kế để đối phó ở mức độ tốt nhất với sự thiếu hụt đảm bảo này. Chương 6 sẽ cho ta thấy rõ hơn về một số thiết kế này. Tuy nhiên, những thiết kế thông minh cũng có giới hạn khi ngưỡng trễ bị vượt quá như trong trường hợp dùng Internet công cộng. Tóm lại, Internet ngày nay có thể cung cấp những dịch vụ ứng dụng thời gian thực song nó không thể lúc nào cũng đáp ứng đủ các yêu cầu về thời gian và băng thông.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Bảng Error! No text of specified style in document..2 chỉ ra các giao thức lớp giao vận dùng trong một số ứng dụng Internet điển hình. Chúng ta thấy là thư điện tử, truy nhập đầu cuối từ xa, web và dịch vụ truyền tệp đều sử dụng TCP. Những ứng dụng này chọn TCP chủ yếu bởi vì TCP cung cấp dịch vụ truyền dữ liệu tin cậy, đảm bảo là tất cả dữ liệu sẽ tới được đích. Chúng ta cũng thấy là dịch vụ điện thoại Internet thường chạy trên UDP. Mỗi bên chạy ứng dụng thoại Internet cần phải gửi dữ liệu qua mạng với một tốc độ tối thiểu nào đó (xem trong Bảng Error! No text of specified style in document..1 về audio thời gian thực), đặc điểm này giống UDP hơn là TCP. Đồng thời, những ứng dụng thoại Internet có thể chịu được tổn thất vì vậy chúng không cần tới dịch vụ truyền dữ liệu tin cậy của TCP.

Bảng Error! No text of specified style in document..2: Các ứng dụng Internet điển hình, giao thức lớp ứng dụng và giao vận

Ứng dụng Giao thức lớp ứng dụng Giao thức lớp giao vận

E-mail (thư điện tử) SMTP [RFC 5321] TCP

Truy nhập đầu cuối từ xa Telnet [RFC 854] TCP

Web HTTP [RFC 2616] TCP

Truyền tệp FTP [RFC 959] TCP

Trực tuyến đa phương tiện HTTP (ví dụ YouTube), RTP TCP hoặc UDP

Điện thoại Internet SIP, RTP hoặc riêng (ví dụ Skype) Thường là UDP

Các tiến trình đánh địa chỉ

Chúng ta đã thảo luận về các dịch vụ lớp giao vận giữa hai tiến trình truyền thông. Song làm thế nào để một tiến trình chỉ ra được tiến trình mà nó cần truyền thông với thông qua những dịch vụ này? Làm thế nào một tiến trình chạy trên một trạm ở Masachusetts của Mỹ chỉ ra được là nó muốn truyền thông với một tiến trình cụ thể chạy trên trạm ở Hà Nội, Việt Nam? Để xác định được tiến trình nhận, cần chỉ ra hai thông tin quan trọng: (1) tên hoặc địa chỉ của trạm và (2) là định danh đặc tả tiến trình nhận trong trạm đích.

Trong mạng Internet, trạm được xác định bằng địa chỉ IP. Chúng ta biết là một địa chỉ IPv4 dài 32 bít sẽ xác định duy nhất một trạm trong liên mạng, song trên thực tế việc triển khai rộng khắp NATs (Network Address Translators) có nghĩa là chỉ 32 bít địa chỉ IP là không đủ để đánh địa chỉ duy nhất cho một trạm.

Ngoài việc biết địa chỉ IP của trạm mà bản tin sẽ hướng tới, trạm gửi cũng phải nhận dạng tiến trình nhận chạy trên trạm đích. Thông tin này cần thiết vì nhìn chung một trạm có thể chạy rất nhiều ứng dụng. Số cổng đích (port number) sẽ phục vụ cho mục đích này. Các ứng dụng thông dụng đã được gán một số cổng cụ thể. Ví dụ, ứng dụng máy chủ Web được gán số cổng là 80. Một tiến trình máy chủ thư điện tử (sử dụng giao thức SMTP) được gán cổng là 25. Trang web http://www.iana.org chứa

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

danh sách các cổng hay được biết đến cho các giao thức chuẩn của Interrnet. Khi một nhà phát triển kiến tạo ứng dụng mạng mới thì ứng dụng đó phải được gán một số cổng mới.

Các giao thức lớp ứng dụng

Chúng ta đã biết là các tiến trình mạng truyền thông với nhau bằng cách gửi các bản tin vào các socket. Song cấu trúc các bản tin này như thế nào, ý nghĩa của các trường thông tin trong bản tin là gì, khi nào thì tiến trình gửi bản tin? Những câu hỏi này đưa chúng ta vào lĩnh vực của giao thức lớp ứng dụng. Một giao thức lớp ứng dụng định nghĩa các thủ tục của ứng dụng, chạy trên các hệ thống cuối khác nhau, qui định cách thức chuyển các bản tin cho nhau như thế nào. Cụ thể là một giao thức lớp ứng dụng định nghĩa các vấn đề sau:

Loại bản tin trao đổi, ví dụ bản tin yêu cầu và bản tin phản hồi; 1.

Cú pháp của các loại bản tin khác nhau, như các trường trong bản tin và cách mô tả các trường này;

Ngữ nghĩa của các trường, tức là ý nghĩa của trường thông tin; 3.

Quy tắc xác định một tiến trình gửi và phản hồi bản tin khi nào và như thế nào. 4.

Một vài giao thức lớp ứng dụng được đặc tả trong các RFC và vì thế nó mang tính công khai. Ví dụ, giao thức lớp ứng dụng của web là HTTP (Hyper-Text Transfer Protocol - giao thức truyền siêu văn bản) [RFC 2616]. Nếu một nhà phát triển trình duyệt tuân theo các quy tắc của RFC HTTP thì trình duyệt này sẽ có khả năng nhận các trang web từ bất kỳ máy chủ web nào cũng tuân theo quy tắc của RFC HTTP. Rất nhiều giao thức lớp ứng dụng khác là độc quyền và không công khai. Ví dụ, rất nhiều hệ thống chia sẻ tệp P2P sử dụng giao thức lớp ứng dụng độc quyền.

Điều quan trọng là cần phân biệt được ứng dụng mạng với giao thức lớp ứng dụng. Giao thức lớp ứng dụng chỉ là một phần của ứng dụng mạng. Ví dụ, Web là một ứng dụng khách-chủ cho phép người sử dụng lấy dữ liệu từ máy chủ Web theo yêu cầu. Ứng dụng Web gồm rất nhiều phần tử, bao gồm các khuôn dạng tài liệu chuẩn (HTML), các trình duyệt Web (ví dụ Firefox và Microsoft Internet Explorer), các máy chủ Web (ví dụ máy chủ Apache và Microsoft) và một giao thức lớp ứng dụng. Giao thức lớp ứng dụng của Web là HTTP, nó định nghĩa khuôn dạng và trình tự của các bản tin chuyển giữa phần mềm trình duyệt và máy chủ Web. Vì thế HTTP chỉ là một phần (mặc dù là phần quan trọng) của ứng dụng Web.

Một ví dụ khác là ứng dụng thư điện tử Internet cũng có rất nhiều thành phần, bao gồm các máy chủ thư điện tử chứa các hòm thư của người sử dụng, những chương trình đọc thư cho phép người sử dụng đọc và tạo ra các bản tin, một chuẩn định nghĩa cấu trúc của bản tin thư điện tử và các giao thức lớp ứng dụng định nghĩa cách các bản tin chuyển giữa các máy chủ, cách bản tin chuyển giữa máy chủ và chương trình đọc thư, và cách các nội dung của các phần cấu thành bản tin thư (ví dụ như tiêu đề của thư) được biên dịch như thế nào. Giao thức lớp ứng dụng chủ yếu cho thư điện tử là SMTP [RFC 5321]. Tuy nhiên, giao thức này cũng chỉ là một phần (dù là phần quan trọng) của ứng dụng thư điện tử.

Chương 1. Các nguyên lý lớp ứng dụng mạng Internet

Một số ứng dụng mạng

Các ứng dụng Internet độc quyền và công cộng được phát triển hàng ngày. Thay vì tìm hiểu toàn bộ các ứng dụng Internet thì chúng ta chỉ tập trung vào một số ứng dụng quan trọng và phổ biến. Trong các chương tiếp theo sẽ giới thiệu về 5 ứng dụng quan trọng là Web, truyền tệp, thư điện tử, dịch vụ thư mục và ứng dụng P2P.

Trước hết ta thảo luận về Web không phải chỉ vì nó là ứng dụng phổ biến rộng khắp mà còn vì giao thức lớp ứng dụng của nó là giao thức đơn giản và dễ hiểu. Sau đó ta tiếp tục tìm hiểu về FTP vì nó cho thấy một sự tương phản với HTTP. Tiếp đến là thư điện tử, đây là ứng dụng mang tính điển hình của Internet. Ứng dụng thư điện tử phức tạp hơn Web ở chỗ nó sử dụng không chỉ một mà là nhiều giao thức lớp ứng dụng.

Sau thư điện tử là DNS, cung cấp dịch vụ thư mục cho Internet. Phần lớn người sử dụng không tương tác với thư mục DNS trực tiếp, thay vào đó người sử dụng gọi đến DNS gián tiếp thông qua những ứng dụng khác (bao gồm Web, truyền tệp và thư điện tử). DNS minh hoạ cách một phần chức năng của mạng lõi (biên dịch tên mạng sang địa chỉ mạng) có thể triển khai ở lớp ứng dụng trong Internet. Cuối cùng chúng ta sẽ thảo luận về một số ứng dụng P2P bao gồm phân bổ tệp, cơ sở dữ liệu phân tán và điện thoại IP.

Chương 2. Web và giao thứ c HTTP

WEB VÀ GIAO THỨ C HTTP

Equation Section (Next) Cho tới đầu những năm 1990, Internet chủ yếu được các nhà nghiên cứu và sinh viên các trường đại học dùng để truy nhập vào các trạm ở xa, truyền tệp từ trạm nội bộ tới trạm từ xa và ngược lại, để nhận và gửi tin tức, thư điện tử. Mặc dù những ứng dụng đó là cực kỳ hữu dụng cho tới ngày nay, song ngoài cộng đồng nghiên cứu và học thuật thì Internet vẫn còn xa lạ với mọi người. Sau đó từ những năm 1990 một ứng dụng chủ đạo mới xuất hiện đó là WWW. Web là ứng dụng Internet đầu tiên có được sự quan tâm của toàn công chúng. Nó đã thay đổi nhanh chóng (và sẽ còn tiếp tục làm thay đổi) cách con người tương tác bên trong và bên ngoài môi trường làm việc của họ. Web đã thúc đẩy Internet từ vị trí là một trong nhiều mạng truyền dữ liệu thành mạng dữ liệu duy nhất.

Có lẽ hầu hết người sử dụng đều thấy Web vận hành theo yêu cầu. Người sử dụng nhận được những gì họ muốn và khi họ muốn. Điều này không giống với truyền thanh và truyền hình quảng bá, chúng buộc người sử dụng phải nhận nội dung mà nhà cung cấp mang lại. Ngoài việc sẵn sàng cung cấp theo yêu cầu, Web còn có rất nhiều đặc tính tuyệt vời mà mọi người thích thú và mong chờ. Việc tạo thông tin trên Web khá dễ dàng đối với bất cứ ai – tất cả mọi người đều có thể trở thành người phát hành thông tin với chi phí cực thấp. Các siêu liên kết và công cụ tìm kiếm giúp chúng ta duyệt vô cùng nhiều các trang Web. Những hình ảnh đồ hoạ tạo cảm giác thực cho chúng ta. Các khuôn dạng, chương trình Java (Java applets) và các thiết bị khác cho phép chúng ta tương tác với các trang Web. Và hơn nữa, Web cung cấp giao diện trình đơn (menu) tới rất nhiều kho dữ liệu audio và video lưu trữ trên Internet, từ đó có thể truy nhập đa phương tiện theo yêu cầu.

Tổng quan về HTTP

Giao thức truyền siêu văn bản (HTTP) - giao thức lớp ứng dụng của Web - là trái tim của ứng dụng Web. Nó được định nghĩa trong RFC 1945 và RFC 2616. HTTP được thực hiện trong hai chương trình: chương trình máy khách và chương trình máy chủ. Chương trình máy khách và chương trình máy chủ thực hiện trên các hệ thống đầu cuối khác nhau, giao tiếp với nhau bằng cách trao đổi các bản tin HTTP. HTTP định nghĩa cấu trúc của các bản tin và phương thức máy khách và máy chủ trao đổi các bản tin. Trước khi trình bày chi tiết về HTTP chúng ta xem xét một số thuật ngữ Web.

Một trang Web (Web page) - còn được gọi là tài liệu - cấu thành từ các đối tượng (object). Một đối tượng đơn giản chỉ là một tệp (file) - như tệp HTML, hình ảnh JPEG, ứng dụng Java trên trang Web hoặc một đoạn video - có khả năng đánh địa chỉ bằng một URL. Hầu hết các trang Web được cấu thành từ tệp HTML cơ sở và một số đối tượng tham chiếu. Ví dụ, nếu trang Web chứa các câu lệnh HTML và 5 hình ảnh JPEG thì trang Web đó có 6 đối tượng: tệp HTML cơ sở và 5 hình ảnh. Tệp HTML cơ sở tham chiếu các đối tượng khác trong trang với các URL của đối tượng đó. Mỗi URL có hai thành phần: tên trạm của máy chủ chứa đối tượng và tên đường dẫn tới đối tượng. Ví dụ một URL như sau:

http://www.someschool.edu/someDepartment/picture.gif

URL trên có www.someschool.edu là tên máy trạm và /someDepartment/ picture.gif là tên đường dẫn. Vì các trình duyệt Web (như Internet Explorer và Firefox) triển khai bên phía máy khách (client) của HTTP trong ngữ cảnh của Web, nên chúng ta sẽ dùng từ trình duyệt (browser) và

Chương 2. Web và giao thứ c HTTP

máy khách (client) thay thế cho nhau. Các máy chủ Web được triển khai bên phía máy chủ (server) của HTTP chứa các đối tượng Web, mỗi đối tượng được đánh một địa chỉ URL.

HTTP xác định các máy khách Web yêu cầu trang Web từ máy chủ Web và các máy chủ truyền các trang Web này tới máy khách như thế nào. Chúng ta thảo luận tương tác giữa máy khách và máy chủ chi tiết sau, song ý tưởng chung về chúng được minh hoạ trong hình 2.1. Khi người sử dụng yêu cầu một trang Web (ví dụ khi người đó nhấp chuột vào một siêu liên kết - hyperlink), trình duyệt sẽ gửi các bản tin yêu cầu HTTP về các đối tượng trong trang tới máy chủ. Máy chủ nhận được yêu cầu này và đáp ứng bằng bản tin đáp ứng HTTP chứa các đối tượng đó.

Hình Error! No text of specified style in document..4: Hoạt động yêu cầu-đáp ứng của HTTP

HTTP sử dụng TCP làm giao thức lớp giao vận nền (thay vì chạy trên UDP). Đầu tiên máy khách HTTP sẽ khởi tạo kết nối TCP với máy chủ. Một khi kết nối được thiết lập thì các tiến trình trình duyệt và máy chủ sẽ truy nhập TCP thông qua giao diện socket của nó. Như đã mô tả ở chương trước, giao diện socket phía máy khách là cánh cửa giữa tiến trình máy khách và kết nối TCP, ở bên máy chủ là cánh cửa giữa tiến trình máy chủ và kết nối TCP. Máy khách gửi các bản tin yêu cầu HTTP vào giao diện socket và nhận bản tin đáp ứng HTTP cũng từ giao diện socket của nó. Tương tự như vậy, máy chủ HTTP nhận bản tin yêu cầu từ socket và gửi bản tin đáp ứng vào giao diện socket của nó. Một khi máy khách gửi bản tin vào giao diện socket của nó thì bản tin đó đã ra khỏi sự kiểm soát của máy khách và đi vào phạm vi kiểm soát của TCP. Như trong chương trước đã đưa ra, TCP cung cấp dịch vụ truyền dữ liệu tin cậy cho HTTP. Điều này có nghĩa là mỗi bản tin yêu cầu HTTP do tiến trình máy khách gửi sẽ được chuyển nguyên vẹn tới bên máy chủ và tương tự, mỗi bản tin đáp ứng HTTP do tiến trình máy chủ gửi sẽ được chuyển nguyên vẹn tới máy khách. Ta thấy một trong những ưu điểm lớn của kiến trúc phân lớp ở đây, đó là HTTP không phải quan tâm đến dữ liệu tổn thất, hay chi tiết việc TCP khôi phục hay tái sắp xếp dữ liệu trong mạng như thế nào. Công việc đó là của TCP và của các giao thức lớp dưới trong chồng giao thức đảm nhiệm.

Điều quan trọng cần lưu ý là máy chủ gửi các tệp được yêu cầu tới máy khách mà không lưu trữ thông tin về trạng thái của máy khách. Nếu một máy khách nào đó yêu cầu cùng một đối tượng hai lần trong vài giây, thì máy chủ sẽ không phản hồi là nó vừa gửi đối tượng đó cho máy khách, mà lại tiếp tục gửi lại đối tượng đó vì nó hoàn toàn quên những việc đã làm trước đó. Vì máy chủ HTTP không duy trì thông tin về máy khách nên nó được gọi là giao thức phi trạng thái (stateless protocol).

Chương 2. Web và giao thứ c HTTP

Chúng ta cũng nhận thấy là Web sử dụng kiến trúc ứng dụng khách-chủ (xem ở chương 1). Một máy chủ Web thì luôn hoạt động, có địa chỉ IP cố định và nó phục vụ các yêu cầu từ hàng triệu trình duyệt khác nhau.

Kết nối HTTP

Trong nhiều ứng dụng Internet, truyền thông máy khách và máy chủ có thể kéo dài trong một khoảng thời gian, với việc máy khách tạo ra một loạt yêu cầu và máy chủ đáp ứng từng yêu cầu đó. Phụ thuộc vào ứng dụng và cách sử dụng ứng dụng, một loạt các yêu cầu có thể được thực hiện đi thực hiện lại, theo chu kỳ hoặc không liên tục. Khi tương tác máy khách-máy chủ được thực hiện trên TCP thì nhà phát triển ứng dụng cần phải ra quyết định quan trọng – mỗi cặp yêu cầu/đáp ứng gửi trên một kết nối TCP riêng hay là tất cả yêu cầu và phản hồi tương ứng sẽ được gửi trên cùng một kết nối TCP? Nếu gửi trên từng kết nối riêng thì ứng dụng được gọi là sử dụng kết nối không liên tục (non-persistent connection) còn trong trường hợp dùng chung kết nối thì được gọi là kết nối liên tục (persistent connection). Để hiểu sâu hơn về vấn đề này, hãy lấy ví dụ về ưu và nhược điểm của kết nối liên tục trong ngữ cảnh ứng dụng cụ thể HTTP, có thể dùng cả kết nối không liên tục và liên tục. Mặc dù trong chế độ mặc định HTTP sử dụng kết nối liên tục, song máy khách và máy chủ HTTP có thể được cấu hình để kết nối không liên tục.

Kết nối không liên tục

Hãy xem xét các bước truyền một trang Web từ máy chủ tới máy khách trong trường hợp kết nối không liên tục. Giả sử trang Web gồm một tệp HTML cơ sở và 10 hình ảnh JPEG, tổng cộng là 11 đối tượng trên cùng máy chủ. URL cho tệp HTML cơ sở là

http://www.someschool.edu/someDepartment/home.index

Các hoạt động sẽ xảy ra như sau:

1. Tiến trình máy khách HTTP khởi tạo kết nối TCP tới máy chủ

http://www.someschool.edu trên cổng 80, số cổng mặc định của HTTP. Kết hợp cùng với kết nối TCP này sẽ có một socket phía máy khách và một socket phía máy chủ.

2. Máy khách HTTP gửi một bản tin yêu cầu HTTP tới máy chủ qua socket của nó. Bản tin yêu

cầu có tên đường dẫn /someDepartment/home.index.

3. Tiến trình máy chủ HTTP nhận bản tin yêu cầu qua socket của nó, lấy đối tượng

/someDepartment/home.index từ bộ nhớ (RAM hoặc ổ đĩa cứng), đóng gói đối tượng vào một bản tin đáp ứng HTTP và gửi bản tin đáp ứng này tới máy khách qua socket của nó.

4. Tiến trình máy chủ HTTP báo cho TCP đóng kết nối TCP (song TCP không kết thúc kết nối cho

tới khi nó chắc chắn là máy khách đã nhận nguyên vẹn bản tin đáp ứng này).

5. Máy khách HTTP nhận bản tin đáp ứng. Kết nối TCP kết thúc. Bản tin chỉ dẫn đối tượng đóng gói là tệp HTML. Máy khách lấy tệp từ bản tin đáp ứng, kiểm tra tệp HTML, và tìm tham chiếu đến 10 đối tượng JPEG.

Chương 2. Web và giao thứ c HTTP

6. Bốn bước đầu tiên được lặp lại cho mỗi đối tượng JPEG tham chiếu.

Khi trình duyệt nhận trang Web, nó hiển thị trang Web cho người sử dụng. Hai trình duyệt khác nhau có thể diễn tả (hiển thị cho người sử dụng) một trang Web theo các cách khác nhau. HTTP không thể làm gì với thể hiện trang Web của máy khách. Các đặc tả HTTP (RFC 1945 và RFC 2616) chỉ định nghĩa giao thức truyền thông giữa chương trình HTTP máy khách và chương trình HTTP máy chủ.

Các bước ở trên minh hoạ việc sử dụng kết nối không liên tục, trong đó mỗi kết nối TCP sẽ bị đóng sau khi máy chủ gửi đối tượng – kết nối này không liên tục cho những đối tượng khác. Lưu ý là mỗi kết nối TCP truyền tải chính xác một bản tin yêu cầu và một bản tin đáp ứng. Vì vậy, trong ví dụ này, khi người sử dụng yêu cầu trang Web thì có 11 kết nối TCP được tạo ra.

Trong những bước mô tả ở trên, ta không rõ về việc liệu máy khách nhận 10 ảnh JPEG qua 10 kết nối TCP nối tiếp, hay một vài ảnh JPEG nhận được qua các kết nối TCP song song. Thực sự là người sử dụng có thể cấu hình các trình duyệt mới để điều khiển mức độ song song này. Trong chế độ mặc định, hầu hết các trình duyệt sẽ mở từ 5 đến 10 kết nối TCP song song, và mỗi kết nối này xử lý một giao dịch yêu cầu – đáp ứng. Nếu người sử dụng muốn thì số lượng kết nối song song tối đa có thể thiết lập bằng một, trong trường hợp đó 10 kết nối sẽ được thiết lập nối tiếp. Việc sử dụng các kết nối song song sẽ giúp rút ngắn thời gian đáp ứng.

Bây giờ, chúng ta thử tính toán để ước lượng khoảng thời gian từ thời điểm máy khách yêu cầu tệp HTML cơ sở cho tới khi nó nhận được toàn bộ tệp yêu cầu. Chúng ta định nghĩa RTT (round trip time) là thời gian cho một gói tin nhỏ đi từ máy khách tới máy chủ và trở về máy khách. RTT gồm có trễ truyền lan gói tin, trễ hàng đợi ở các bộ định tuyến, chuyển mạch trung gian và trễ xử lý gói tin (xem lại hoạt động của TCP). Ta sẽ xem xét bắt đầu từ lúc người sử dụng nhấp chuột vào một siêu kết nối (một địa chỉ trang Web). Như diễn tả trên hình 2.2, việc nhấp chuột sẽ làm trình duyệt khởi tạo một kết nối TCP giữa trình duyệt và máy chủ Web; nó bao gồm tiến trình bắt tay ba bước – máy khách gửi một đoạn TCP nhỏ tới máy chủ, máy chủ nhận biết và đáp ứng bằng một đoạn TCP nhỏ, và cuối cùng thì máy khách nhận biết trở lại với máy chủ. Hai bước đầu trong tiến trình bắt tay ba bước chiếm một RTT. Sau khi hoàn thành hai bước của tiến trình bắt tay ba bước, máy khách sẽ gửi bản tin yêu cầu HTTP kết hợp với bước thứ ba của tiến trình bắt tay (nhận biết) vào kết nối TCP. Một khi bản tin yêu cầu tới được máy chủ thì máy chủ sẽ gửi tệp HTML vào kết nối TCP. Lần yêu cầu/đáp ứng HTTP này sẽ chiếm một RTT. Vì vậy, sơ bộ tổng thời gian đáp ứng là hai RTT cộng với thời gian truyền dẫn ở máy chủ chứa tệp HTML.

Chương 2. Web và giao thứ c HTTP

Hình Error! No text of specified style in document..5: Tính toán thời gian cần thiết để yêu cầu và nhận tệp HTML

Kết nối liên tục

Các kết nối không liên tục có một số thiếu sót. Đầu tiên, là phải thiết lập và duy trì kết nối mới cho mỗi đối tượng được yêu cầu. Đối với mỗi một trong những kết nối này, phải cấp phát bộ đệm TCP và phải duy trì các biến TCP trên cả máy khách và máy chủ. Điều này có thể áp đặt tải trọng lên máy chủ Web, do nó có thể phải phục vụ yêu cầu cho hàng trăm máy khách khác nhau đồng thời. Thứ hai, như chúng ta đã thấy mỗi đối tượng sẽ chịu một thời gian trễ chuyển phát khoảng 2 RTT: một RTT để thiết lập kết nối TCP và một RTT để yêu cầu và nhận đối tượng.

Với kết nối liên tục, máy chủ phải để kết nối TCP mở sau khi gửi đáp ứng. Những yêu cầu và đáp ứng liên tiếp giữa cùng một máy khách với máy chủ có thể gửi trên cùng một kết nối. Cụ thể, toàn bộ một trang Web (như ví dụ là tệp HTML cơ sở và 10 hình ảnh) có thể gửi trên duy nhất một kết nối TCP liên tục. Hơn nữa, nhiều trang Web trong cùng một máy chủ có thể được gửi từ máy chủ này tới cùng một máy khách chỉ qua một kết nối TCP liên tục. Các yêu cầu về đối tượng này có thể được thực hiện liên tiếp mà không phải chờ phản hồi giải quyết yêu cầu chính thức (tạo đường ống - pipelining). Thông thường, máy chủ HTTP đóng một kết nối khi nó không được sử dụng trong một khoảng thời gian nhất định (thời gian quá hạn có khả năng thiết lập). Khi máy chủ nhận các yêu cầu liên tiếp, nó cũng gửi các đối tượng liên tiếp. Phương thức mặc định của HTTP là sử dụng kết nối liên tục với đường ống.

Khuôn dạng bản tin HTTP

Đặc tả HTTP trong RFC 2616 gồm các định nghĩa về khuôn dạng của các bản tin HTTP. Có hai loại bản tin HTTP là bản tin yêu cầu (request) và bản tin đáp ứng (response).

Bản tin yêu cầu

Chương 2. Web và giao thứ c HTTP

Bản tin yêu cầu HTTP

GET /somedir/page.html HTTP/1.1

Host: www.someSchool.edu

Connection: close

User-agent: Mozilla/4.0

Accept-language: fr

Chúng ta có thể tìm hiểu được rất nhiều thông qua xem xét chi tiết bản tin yêu cầu đơn giản này. Đầu tiên, ta thấy là bản tin được viết bằng ký tự ASCII thông thường, như vậy các máy tính bình thường có thể đọc được nó. Thứ hai, chúng ta thấy là bản tin gồm 5 dòng, sau mỗi dòng là ký tự xuống dòng và chuyển dòng. Sau dòng cuối cùng cũng vậy. Mặc dù bản tin cụ thể này có 5 dòng, song một bản tin yêu cầu có thể có nhiều dòng hơn hoặc có khi chỉ có một dòng. Dòng đầu tiên của bản tin yêu cầu HTTP được gọi là dòng yêu cầu, các dòng tiếp theo là các dòng tiêu đề. Dòng yêu cầu có 3 trường: trường phương thức, trường URL, và trường phiên bản HTTP. Trường phương thức có thể lấy một số giá trị khác nhau, bao gồm GET, POST, HEAD, PUT, và DELETE. Các bản tin HTTP chủ yếu sử dụng phương thức GET. Phương thức GET được sử dụng khi trình duyệt yêu cầu một đối tượng, với đối tượng yêu cầu được xác định trong trường URL. Trong ví dụ này trình duyệt yêu cầu đối tượng /somedir/page.html. Phiên bản được chỉ ra rất rõ ràng, trong ví dụ này phiên bản thực hiện trình duyệt là HTTP/1.1.

Hãy nhìn vào dòng tiêu đề trong ví dụ này. Dòng tiêu đề Host: www.someSchool.edu đặc tả trạm chủ chứa đối tượng. Bạn có thể cho rằng dòng tiêu đề này là không cần thiết vì ở đây đã có kết nối TCP tại trạm chủ. Tuy nhiên, thông tin cung cấp từ dòng tiêu đề trạm chủ (host) được bộ lưu đệm Web (Web proxy catch) yêu cầu (sẽ đưa ra kỹ hơn trong phần 2.5). Bằng việc bao hàm dòng tiêu đề Connection: close, trình duyệt báo cho máy chủ là nó không muốn bận tâm tới các kết nối liên tục, nó muốn máy chủ đóng kết nối sau khi gửi đối tượng yêu cầu. Dòng tiêu đề User-agent: dòng tiêu đề đặc tả đại lý (agent) người sử dụng, nghĩa là loại trình duyệt thực hiện yêu cầu tới máy chủ. Ở đây đại lý người sử dụng là Mozilla/4.0, trình duyệt của Netscape. Dòng tiêu đề này hữu ích vì máy chủ có thể gửi phiên bản khác của cùng đối tượng tới các loại nhân tố người sử dụng khác nhau (các phiên bản cùng đánh một địa chỉ URL). Cuối cùng là tiêu đề Accept-language: tiêu đề này chỉ rằng người sử dụng mong muốn nhận phiên bản tiếng Pháp của đối tượng nếu như đối tượng như vậy có trên máy chủ, nếu không có máy chủ sẽ gửi phiên bản mặc định. Tiêu đề Accept- language: chỉ là một trong nhiều tiêu đề thỏa thuận nội dung có sẵn trong HTTP.

Tiếp tục ví dụ trên, chúng ta sẽ xem xét khuôn dạng chung của bản tin yêu cầu trong hình 2.3. Ví dụ ở trên tuân thủ khá chặt chẽ theo khuôn dạng này. Tuy nhiên, chúng ta có thể để ý rằng sau các dòng tiêu đề (và kí tự xuống dòng bổ sung và kí tự chuyển dòng) là một “khối thực thể”. Khối thực thể này rỗng với phương thức GET, nhưng nó được sử dụng với phương thức POST. Một máy khách HTTP thường dùng phương thức POST khi người sử dụng điền vào khuôn mẫu (form), ví dụ khi người sử dụng cung cấp từ khoá tìm kiếm cho công cụ tìm kiếm. Với bản tin POST, người sử dụng vẫn yêu cầu trang Web từ máy chủ, nhưng một số nội dung cụ thể của trang Web lại phụ thuộc vào thông tin

Chương 2. Web và giao thứ c HTTP

người sử dụng đưa vào các trường của khuôn mẫu. Nếu giá trị trường phương thức là POST thì khối thực thể chứa toàn bộ thông tin mà người sử dụng đã đưa vào trường khuôn mẫu.

Hình Error! No text of specified style in document..6: Khuôn dạng chung của một bản tin yêu cầu HTTP

Cần chú ý là một yêu cầu được tạo ra với khuôn mẫu có thể không cần sử dụng phương thức POST. Thay vào đó, các khuôn mẫu HTML thường sử dụng phương thức GET và bao hàm dữ liệu đầu vào (trong trường các khuôn mẫu) trên dòng URL được yêu cầu. Ví dụ, nếu khuôn mẫu sử dụng phương thức GET có hai trường, và thông tin đầu vào hai trường là monkeys và bananas thì URL sẽ có cấu trúc

www.somesite.com/animalsearch?monkeys&bananas.

Khi lướt Web hàng ngày chúng ta có thể để ý đến kiểu URL mở rộng này.

Phương thức HEAD tương tự với phương thức GET. Khi một máy chủ nhận được yêu cầu với phương thức HEAD, nó đáp ứng bằng bản tin HTTP nhưng bỏ qua đối tượng yêu cầu. Các nhà phát triển ứng dụng thường sử dụng phương thức HEAD để gỡ rối (debugging). Phương thức PUT thường được sử dụng kết hợp với các công cụ phát hành Web. Nó cho phép người sử dụng tải lên một đối tượng tới một đường cụ thể (thư mục) trên một máy chủ Web cụ thể. Phương thức PUT cũng được các ứng dụng sử dụng khi cần tải các đối tượng lên các máy chủ Web. Phương thức DELETE cho phép người sử dụng hoặc ứng dụng xoá một đối tượng trên máy chủ Web.

Bản tin đáp ứng

Dưới đây là bản tin đáp ứng HTTP điển hình. Đây có thể là bản tin đáp ứng của bản tin yêu cầu trong ví dụ vừa đưa ra ở trên.

Chương 2. Web và giao thứ c HTTP

HTTP/1.1 200 OK

Connection: close

Date: Sat, 07 Jul 2007 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Sun, 6 May 2007 09:23:24 GMT

Content-Length: 6821

Content-Type: text/html

(data data data data data …)

Chúng ta hãy xem xét kỹ bản tin đáp ứng này. Nó có ba phần: dòng trạng thái ban đầu, sáu dòng tiêu đề và sau cùng là khối thực thể. Khối thực thể là thân của bản tin – nó chứa chính đối tượng được yêu cầu (phần data data data data data …). Dòng trạng thái có 3 trường: trường phiên bản giao thức, mã trạng thái, và bản tin trạng thái tương ứng. Trong ví dụ này dòng trạng thái cho thấy máy chủ sử dụng HTTP/1.1 và mọi thứ là ổn - OK (nghĩa là máy chủ đã tìm thấy, và đang gửi đối tượng yêu cầu).

Bây giờ hãy xem các dòng tiêu đề. Máy chủ sử dụng dòng tiêu đề Connection: close để báo máy khách là nó sẽ đóng kết nối TCP sau khi gửi bản tin. Dòng tiêu đề Date: chỉ thời gian và ngày mà đáp ứng HTTP được máy chủ tạo ra và gửi đi. Lưu ý là đây không phải thời gian tạo ra đối tượng hoặc thay đổi đối tượng lần sau cùng; nó là thời gian khi máy chủ lấy được đối tượng từ hệ thống tệp của nó, chèn đối tượng vào bản tin đáp ứng và gửi bản tin đáp ứng. Dòng tiêu đề Server: chỉ ra là bản tin đã được tạo ra bằng máy chủ Web Apache, nó tương tự như dòng tiêu đề User-agent: trong bản tin yêu cầu HTTP. Dòng tiêu đề Last-Modified: chỉ thời gian và ngày mà đối tượng được tạo ra hay thay đổi sau cùng. Dòng tiêu đề Last-Modified: rất quan trọng để cache (lưu đệm) đối tượng cả ở máy khách cục bộ lẫn ở máy chủ đệm của mạng (còn được gọi là máy chủ proxy). Dòng tiêu đề Content-Length: chỉ số byte của đối tượng được gửi. Dòng tiêu đề Content-Type: chỉ rằng đối tượng ở trong khối thực thể là văn bản HTML. (Kiểu đối tượng thường được chỉ ra chính thức bằng tiêu đề Content-Type: và không ở phần mở rộng tệp).

Bây giờ chúng ta sẽ xem xét khuôn dạng chung của bản tin đáp ứng trong hình 2.4. Khuôn dạng chung này của bản tin đáp ứng phù hợp với bản tin yêu cầu của ví dụ trước. Chúng ta tìm hiểu thêm về các mã trạng thái và mệnh đề của nó. Mã trạng thái và mệnh đề tương ứng chỉ ra kết quả của yêu cầu. Một vài mã trạng thái thông dụng và mệnh đề tương ứng gồm:

200 OK: Yêu cầu thành công và thông tin được trả về trong bản tin đáp ứng. 1.

301 Moved Permanently: Đối tượng được yêu cầu đã chuyển đi vĩnh viễn; URL mới được xác định trong tiêu đề Location: của bản tin đáp ứng. Phần mềm máy khách sẽ tự động lấy URL mới.

Chương 2. Web và giao thứ c HTTP

400 Bad Request: Đây là mã lỗi chung chỉ ra là máy chủ không hiểu yêu cầu. 3.

404 Not Found: Tài liệu yêu cầu không tồn tại ở máy chủ này. 4.

505 HTTP Version Not Supported: Phiên bản giao thức HTTP yêu cầu không được máy chủ hỗ trợ.

Hình Error! No text of specified style in document..7: Khuôn dạng chung của một bản tin đáp ứng HTTP

Bạn có muốn nhìn thấy một bản tin đáp ứng HTTP thực sự không? Đây là hành động nên làm và dễ dàng thực hiện đấy. Đầu tiên là hãy sử dụng Telnet vào máy chủ Web bạn ưa thích. Sau đó gõ một dòng bản tin yêu cầu để tìm đối tượng chứa trong máy chủ đó. Ví dụ, nếu bạn truy nhập vào dấu nhắc dòng lệnh, gõ:

telnet cis.poly.edu 80

GET /~ross/ HTTP/1.1

Host: cis.poly.edu

(Nhấn Enter 2 lần sau khi gõ dòng cuối).

Các lệnh này sẽ mở kết nối TCP tới cổng 80 của trạm chủ cis.poly.edu và sau đó gửi bản tin yêu cầu HTTP. Bạn thấy là bản tin đáp ứng bao gồm tệp HTML cơ sở trang Web của giáo sư Ross. Nếu chỉ muốn thấy các dòng bản tin HTTP và không nhận đối tượng thì thay GET bằng HEAD. Cuối cùng, thay /~ross/ bằng /~banana/ và xem bản tin đáp ứng bạn nhận được là gì.

Trong phần này chúng ta thảo luận về một số dòng tiêu đề có thể sử dụng trong bản tin HTTP yêu cầu và đáp ứng. Đặc tả HTTP định nghĩa rất nhiều những dòng tiêu đề mà các trình duyệt, máy chủ Web và các máy chủ đệm mạng có thể chèn vào. Chúng ta chỉ xem xét một số lượng nhỏ trong tổng số các dòng tiêu đề.

Làm thế nào để một trình duyệt quyết định những dòng tiêu đề nào sẽ có trong bản tin yêu cầu? Làm thế nào một máy chủ Web quyết định những dòng tiêu đề nào sẽ có trong bản tin đáp ứng? Một

Chương 2. Web và giao thứ c HTTP

trình duyệt sẽ tạo ra các dòng tiêu đề như một chức năng của loại trình duyệt và phiên bản (ví dụ: trình duyệt HTTP/1.0 sẽ không thể tạo ra dòng tiêu đề phiên bản 1.1), cấu hình của trình duyệt người sử dụng (ví dụ: ngôn ngữ ưa thích) và liệu trình duyệt hiện tại có lưu đệm phiên bản của đối tượng (có thể đã cũ) không. Các máy chủ Web hành động tương tự: Có nhiều sản phẩm khác nhau, phiên bản khác nhau, và cấu hình khác nhau, tất cả những điều này sẽ tác động tới việc những tiêu đề nào sẽ được bao hàm trong bản tin đáp ứng.

Tương tác user-server

Máy chủ HTTP không lưu trạng thái. Điều này làm đơn giản hóa thiết kế và cho phép các kỹ sư phát triển các máy chủ Web hiệu năng cao có thể xử lý đồng thời hàng nghìn kết nối TCP. Tuy nhiên, thường chúng ta mong muốn trang Web nhận dạng được người sử dụng, hoặc bởi vì máy chủ muốn giới hạn truy nhập của người sử dụng, hoặc bởi vì nó muốn dùng nội dung như một hàm nhận dạng người sử dụng. Với những mục đích này, HTTP sử dụng cookie. Các cookie được định nghĩa trong RFC 2965, nó cho phép các điểm truy nhập bám vết người sử dụng. Hầu hết các trang Web thương mại ngày nay đều sử dụng cookie.

Trên hình 2.5 công nghệ cookie có bốn thành phần: (1) dòng tiêu đề cookie trong bản tin đáp ứng HTTP; (2) dòng tiêu đề cookie trong bản tin yêu cầu HTTP; (3) tệp cookie giữ trên hệ thống đầu cuối của người sử dụng và được trình duyệt người sử dụng quản lý; (4) cơ sở dữ liệu đầu cuối (back-end) tại trang Web. Xem hình 2.5 để thấy hoạt động của cookie. Giả sử Susan, người luôn truy cập Web bằng Internet Explorer từ máy tính ở nhà, kết nối lần đầu tới Amazon.com. Giả sử là trước đây cô ấy đã từng vào trang eBay. Khi yêu cầu tới máy chủ Web Amazon thì máy chủ tạo ra một số nhận dạng duy nhất và tạo ra một mục ở cơ sở dữ liệu đầu cuối sắp xếp theo số nhận dạng. Sau đó máy chủ Web Amazon sẽ đáp ứng tới trình duyệt của Susan, bao gồm tiêu đề Set-cookie: của đáp ứng HTTP, trong đó chứa số nhận dạng. Ví dụ: dòng tiêu đề có thể là:

Set-cookie: 1678 Khi trình duyệt của Susan nhận được bản tin đáp ứng HTTP này, nó nhìn vào tiêu đề Set-cookie:. Trình duyệt sẽ thêm một dòng tới tệp cookie đặc biệt mà nó quản lý. Dòng này gồm tên máy chủ và số nhận dạng trong tiêu đề Set-cookie:. Chú ý là tệp cookie đã có sẵn một mục cho eBay, vì Susan đã vào trang đó trước đây. Khi Susan tiếp tục duyệt trang Amazon, mỗi lần cô ấy yêu cầu một trang Web thì trình duyệt sẽ tham khảo tệp cookie của cô ấy, trích lấy số nhận dạng cho trang này và đưa dòng tiêu đề cookie có chứa số nhận dạng vào yêu cầu HTTP. Đặc biệt, mỗi yêu cầu HTTP của cô ấy tới máy chủ Amazon sẽ có dòng tiêu đề:

Cookie: 1678 Theo cách này, máy chủ Amazon có thể bám vết hành động của Susan ở trang Amazon. Mặc dù trang Web Amazon không cần biết tên của Susan, song nó biết chính xác các trang mà người sử dụng 1678 đã ghé thăm và theo thứ tự nào, vào thời điểm nào. Amazon dùng cookie để cung cấp dịch vụ giỏ bán hàng (shopping cart) – Amazon có thể duy trì một danh sách những món hàng mà Susan quan tâm, và vì thế cô ấy có thể trả tiền mua chúng ở cuối phiên.

Chương 2. Web và giao thứ c HTTP

Hình Error! No text of specified style in document..8: Giữ trạng thái người sử dụng với cookie

Nếu Susan trở lại trang Amazon thì một tuần sau trình duyệt của cô sẽ tiếp tục đưa dòng tiêu đề Cookie: 1678 ở các bản tin yêu cầu. Amazon cũng khuyến nghị các sản phẩm với Susan dựa trên các trang Web mà cô ta đã ghé thăm ở Amazon trước đây. Nếu Susan cũng tự mình đăng ký với Amazon – cung cấp đầy đủ tên, địa chỉ email, địa chỉ bưu chính và thông tin thẻ tín dụng thì Amazon có thể có những thông tin này trong cơ sở dữ liệu của mình, và vì thế nó chứa cả tên của Susan với số nhận dạng của cô ấy (và tất cả các trang mà cô ấy đã vào trước đây). Đấy là cách mà Amazon và các trang thương mại điện tử khác cung cấp dịch vụ “one-click shopping” (mua bán chỉ qua một cú nhấp chuột) – khi Susan chọn mua bán một vật trong khi ghé thăm, cô không phải gõ lại tên, số thẻ tín dụng hay địa chỉ của mình. Từ đây ta thấy là cookie dùng để nhận dạng người sử dụng. Khi người sử dụng lần đầu vào một trang thì người sử dụng có thể cung cấp nhận dạng người sử dụng (có thể là tên). Trong những phiên sau đó, trình duyệt sẽ chuyển tiêu đề cookie tới máy chủ, do đó nhận dạng người sử dụng với máy chủ. Do vậy Cookie có thể được dùng để tạo lớp phiên người sử dụng trên đầu của HTTP phi trạng thái. Ví dụ, khi người sử dụng truy cập (log) vào một ứng dụng thư điện tử trên Web (ví dụ Hotmail), trình duyệt sẽ gửi thông tin cookie tới máy chủ, cho phép máy chủ nhận dạng người sử dụng trong suốt phiên của người sử dụng với ứng dụng đó.

Chương 2. Web và giao thứ c HTTP

Mặc dù cookie thường làm đơn giản kỹ năng mua sắm trên Internet cho người sử dụng, song chúng gây tranh cãi bởi vì chúng có thể xâm phạm tính riêng tư. Như chúng ta vừa thấy, sử dụng kết hợp các cookie và thông tin tài khoản do người sử dụng cung cấp thì một trang Web có thể biết được rất nhiều về thói quen người sử dụng và có thể bán thông tin này cho bên thứ ba.

Web caching

Một máy chủ đệm Web (Web Cache) còn được gọi là máy chủ proxy, là một phần tử mạng thoả mãn các yêu cầu HTTP khi đại diện cho máy chủ Web gốc. Máy chủ đệm Web có kho lưu trữ riêng và giữ các bản sao của các đối tượng được yêu cầu gần đây trong kho lưu trữ này. Trong hình 2.6, trình duyệt người sử dụng có thể được cấu hình sao cho tất cả yêu cầu HTTP của người sử dụng đầu tiên sẽ được hướng tới máy chủ đệm Web. Ví dụ, giả sử trình duyệt yêu cầu đối tượng http://www.someschool.edu/campus.gif. Sau đây là trình tự những hoạt động sẽ xảy ra:

Trình duyệt thiết lập kết nối TCP tới máy chủ đệm Web và gửi yêu cầu HTTP về đối tượng tới máy chủ đệm Web.

Máy chủ đệm Web kiểm tra xem liệu có bản sao của đối tượng trong kho lưu trữ của mình không. Nếu có, máy chủ đệm Web sẽ gửi trả đối tượng trong bản tin đáp ứng HTTP tới trình duyệt máy khách.

Nếu máy chủ đệm Web không có đối tượng này, nó sẽ mở một kết nối TCP tới máy chủ gốc (origin server), nghĩa là tới www.someschool.edu. Sau đó máy chủ đệm Web sẽ gửi một yêu cầu HTTP về đối tượng vào kết nối TCP từ bộ đệm tới máy chủ. Sau khi nhận được yêu cầu này, máy chủ gốc sẽ gửi đối tượng trong đáp ứng HTTP tới máy chủ đệm Web.

Khi máy chủ đệm Web nhận đối tượng này, nó lưu bản sao trong bộ lưu trữ nội bộ của mình và gửi một bản sao trong bản tin đáp ứng HTTP tới trình duyệt khách (trên kết nối TCP sẵn có giữa trình duyệt khách và máy chủ đệm Web).

Hình Error! No text of specified style in document..9: Máy khách yêu cầu đối tượng qua máy chủ đệm Web

Chương 2. Web và giao thứ c HTTP

Chú ý là máy chủ đệm vừa là khách vừa là chủ ở cùng thời điểm. Khi nó nhận yêu cầu từ trình duyệt và gửi lại đáp ứng thì nó là máy chủ. Khi nó gửi yêu cầu và nhận đáp ứng từ máy chủ gốc thì nó là máy khách.

Thông thường, máy chủ đệm Web được ISP mua và cài đặt. Ví dụ, một trường đại học có thể cài đặt máy chủ đệm trên mạng cục bộ của mình và cấu hình toàn bộ trình duyệt trong trường kết nối tới máy chủ đệm đó. Hoặc một nhà cung cấp dịch vụ Internet dân dụng lớn (như VNPT) có thể cài đặt một hoặc nhiều máy chủ đệm trong mạng và cấu hình trước những trình duyệt trỏ tới các máy chủ đệm này.

Đệm Web đã được triển khai trong Internet bởi hai lý do. Thứ nhất, máy chủ đệm Web có thể làm giảm đáng kể thời gian đáp ứng yêu cầu từ máy khách, đặc biệt là khi băng thông nghẽn cổ chai giữa máy khách và máy chủ gốc nhỏ hơn băng thông nghẽn cổ chai giữa máy khách và bộ đệm. Nếu có kết nối tốc độ cao giữa máy khách và máy chủ đệm, như thường xảy ra, và nếu máy chủ đệm có đối tượng được yêu cầu, thì nó có khả năng nhanh chóng chuyển đối tượng đó tới máy khách. Thứ hai, các máy chủ đệm Web có thể giảm đáng kể lưu lượng trên đường kết nối mạng của một tổ chức tới Internet (xem trong ví dụ sau). Bằng việc giảm bớt lưu lượng, tổ chức (hoặc một công ty hay một trường đại học) không cần phải tăng băng thông quá nhanh, như thế sẽ làm giảm chi phí mua thêm băng thông kết nối. Hơn nữa, các máy chủ đệm Web có thể làm giảm đáng kể lưu lượng Web trên tổng thể mạng Internet, do vậy nó sẽ cải thiện hiệu năng cho tất cả các ứng dụng.

Để hiểu sâu hơn về lợi ích của các máy chủ đệm, hãy xem ví dụ trong hình 2.7. Trong hình có hai mạng: mạng của học viện và mạng Internet công cộng. Mạng trong học viện là mạng LAN tốc độ cao. Một bộ định tuyến (router) trong mạng của học viện và một bộ định tuyến Internet được kết nối thông qua đường 15 Mbit/s. Các máy chủ gốc kết nối vào Internet nhưng được đặt trên các vị trí khắp toàn cầu. Giả sử kích thước đối tượng trung bình là 1 Mbit và tốc độ yêu cầu trung bình từ các trình duyệt trong học viện tới các máy chủ gốc là 15 yêu cầu/giây. Giả sử các bản tin yêu cầu HTTP có kích thước rất nhỏ và sẽ không tạo lưu lượng đáng kể nào trong mạng hay trong các liên kết truy nhập (từ bộ định tuyến của học viện tới bộ định tuyến của Internet). Cũng giả sử là khoảng thời gian từ khi bộ định tuyến phía Internet của kết nối truy nhập (trong hình 2.7) chuyển tiếp một yêu cầu HTTP (trong một gói tin IP) cho tới khi nó nhận được đáp ứng (thường gửi trên nhiều gói tin IP) trung bình là 2 giây. Khoảng thời gian này thường được coi là “trễ Internet”.

Chương 2. Web và giao thứ c HTTP

Hình Error! No text of specified style in document..10: Nghẽn cổ chai giữa mạng của Học viện và Internet

Như vậy, tổng thời gian đáp ứng - khoảng thời gian từ khi trình duyệt yêu cầu đối tượng cho tới lúc trình duyệt nhận được đối tượng đó - là tổng thời gian trễ trong LAN, thời gian trễ truy nhập (trễ giữa 2 bộ định tuyến) và trễ Internet. Hãy tính toán sơ bộ để ước lượng tổng trễ này. Tải trọng lưu lượng trên LAN là:

(15 yêu cầu/giây)×(1Mbit/yêu cầu)/(100Mbit/s)= 0,15

trong đó tải trọng lưu lượng trên liên kết truy nhập (từ bộ định tuyến Internet đến bộ định tuyến của học viện) là:

(15 yêu cầu/giây)×(1Mbit/yêu cầu)/(15Mbit/s)= 1

Tải trọng lưu lượng 0,15 trên mạng LAN thường dẫn đến nhiều nhất là mười giây trễ, vì thế ta có thể bỏ qua trễ của mạng LAN. Tuy nhiên với điều kiện mạng như trong hình 2.7 thì tải trọng lưu lượng là 1 (trong trường hợp liên kết truy nhập), như vậy trễ trên liên kết trở nên rất lớn và có thể tăng không giới hạn. Vì vậy, thời gian đáp ứng trung bình để thoả mãn các yêu cầu sẽ lên tới hàng phút và điều đó là không thể chấp nhận với người sử dụng trong mạng học viện. Rõ ràng là phải có biện pháp để xử lý tình huống này.

Một giải pháp khả thi là tăng tốc độ truy nhập từ 15Mbit/s đến 100Mbit/s. Điều này sẽ làm giảm tải trọng lưu lượng trên đường truy nhập xuống còn 0,15 và làm trễ giữa hai bộ định tuyến giảm đáng kể. Trong trường hợp này, tổng thời gian đáp ứng xấp xỉ 2 giây, tức là bằng trễ Internet. Song giải pháp này đồng nghĩa với việc học viện phải nâng cấp đường truy nhập từ 15Mbit/s lên 100Mbit/s, chi phí cho việc này khá tốn kém.

Chương 2. Web và giao thứ c HTTP

Bây giờ hãy cân nhắc giải pháp thay thế việc nâng cấp đường truy nhập bằng cách cài đặt thêm một máy chủ đệm Web trong mạng của học viện. Giải pháp này được minh hoạ trong hình 2.8. Tỷ lệ đáp ứng yêu cầu do máy chủ đệm giải quyết được trong thực tế thường từ 0,2 đến 0,7. Để minh hoạ cụ thể, giả sử tỉ lệ này là 0,4. Vì các máy khách và máy chủ đệm được kết nối trong cùng mạng LAN tốc độ cao nên 40% yêu cầu có thể đáp ứng ngay lập tức, nghĩa là trong vòng 10 giây thông qua máy chủ đệm Web. Tuy vậy, 60% yêu cầu còn lại vẫn cần máy chủ gốc đáp ứng. Nhưng với chỉ 60% đối tượng yêu cầu phải chuyển qua liên kết truy nhập, tải trọng lưu lượng trên đường truy nhập giảm từ 1,0 xuống còn 0,6. Thông thường, tải trọng lưu lượng nhỏ hơn 0,8 nghĩa là độ trễ tương ứng nhỏ, khoảng 10 miligiây trên liên kết 15Mbit/s. Trễ này là không đáng kể so với trễ 2 giây trên Internet. Như vậy, trễ trung bình là: 0,4×(0,01giây)+0,6×(2,01 giây)=1,21 giây. Giải pháp thứ hai này cho thời gian đáp ứng thấp đáng kể so với giải pháp thứ nhất và nó không yêu cầu học viện phải nâng cấp kết nối tới Internet. Dĩ nhiên là giải pháp này yêu cầu học viện phải mua và cài đặt máy chủ đệm Web song chi phí đó thấp, rất nhiều máy chủ đệm sử dụng các phần mềm tên miền công cộng chạy trên các máy tính cá nhân có chi phí không đắt.

Hình Error! No text of specified style in document..11: Thêm máy chủ đệm vào mạng của Học viện

Bản tin GET có điều kiện

Mặc dù việc đệm Web giảm được thời gian đáp ứng cho người sử dụng nhưng nó lại đặt ra một khó khăn mới, đó là bản sao của các đối tượng nằm trong các máy chủ đệm có thể bị cũ. Nói cách khác, đối tượng ở các máy chủ Web đã thay đổi so với thời điểm mà máy chủ đệm sao chép nó và chuyển tới máy khách. Rất may là HTTP có cơ chế cho phép máy chủ đệm tra cứu việc đối tượng đã được cập nhật hay chưa. Cơ chế này được gọi là cơ chế GET có điều kiện (conditional GET). Một bản tin yêu cầu HTTP được gọi là bản tin conditional GET nếu (1) bản tin yêu cầu sử dụng phương thức GET và (2) bản tin yêu cầu bao gồm một dòng tiêu đề If-Modified-Since:.

Chương 2. Web và giao thứ c HTTP

Ví dụ sau minh hoạ hoạt động của cơ chế này. Đầu tiên, máy chủ đệm proxy đại diện cho trình duyệt yêu cầu, gửi bản tin yêu cầu tới máy chủ Web:

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com

Thứ hai, máy chủ Web gửi một bản tin đáp ứng cùng với đối tượng yêu cầu đến máy chủ đệm:

HTTP/1.1 200 OK

Date: Sat, 7 Jul 2007 15:39:29

Server: Apache/1.3.0 (Unix)

Last-Modified: Wed, 4 Jul 2007 09:23:24

Content-Type: image/gif

(data data data data data …)

Máy chủ đệm chuyển tiếp đối tượng tới trình duyệt yêu cầu nhưng cũng lưu đối tượng lại. Điều quan trọng là máy chủ đệm cũng lưu trữ ngày thay đổi cuối cùng của đối tượng. Thứ ba, một tuần sau, một trình duyệt khác yêu cầu đối tượng đó qua máy chủ đệm, và đối tượng vẫn còn ở trong bộ đệm. Vì đối tượng này có thể đã bị thay đổi ở máy chủ Web trong tuần trước đó, nên máy chủ đệm thực hiện kiểm tra cập nhật bằng cách tạo ra một bản tin conditional GET. Cụ thể là máy chủ đệm sẽ gửi:

GET /fruit/kiwi.gif HTTP/1.1

Host: www.exotiquecuisine.com

If-Modified-Since: Wed, 4 Jul 2007 09:23:24

Chú ý là giá trị của dòng tiêu đề If-Modified-Since: giống hệt như giá trị của dòng tiêu đề Last-Modified: do máy chủ gửi một tuần trước đó. Bản tin conditional GET này báo cho máy chủ gửi đối tượng chỉ khi đối tượng đó đã thay đổi từ thời điểm chỉ ra trong bản tin. Giả sử đối tượng không thay đổi từ 9 giờ 23 phút 24 giây ngày 4 tháng 7 năm 2007 thì máy chủ sẽ gửi tới máy chủ đệm bản tin đáp ứng:

HTTP/1.1 304 Not Modified

Date: Sat, 14 Jul 2007 15:39:29

Server: Apache/1.3.0 (Unix)

Chương 2. Web và giao thứ c HTTP

(empty entity body)

Chúng ta thấy là trong bản tin đáp ứng với conditional GET, máy chủ Web vẫn gửi bản tin đáp ứng nhưng không kèm theo đối tượng yêu cầu trong bản tin đáp ứng. Việc đính kèm đối tượng yêu cầu chỉ làm phí băng thông và làm tăng thời gian đáp ứng yêu cầu của người sử dụng, đặc biệt là khi đối tượng có kích thước lớn. Chú ý là bản tin đáp ứng cuối cùng này có dòng trạng thái là 304 Not Modified, điều đó có nghĩa là máy chủ đệm có thể chuyển tiếp bản sao được lưu đệm (của máy chủ đệm proxy) của đối tượng tới trình duyệt yêu cầu.

Chương 2 đã giới thiệu giao thức ứng dụng Internet đầu tiên với khuôn dạng của bản tin HTTP, những hoạt động giữa máy khách và máy chủ Web thông qua gửi và nhận các bản tin. Chương này cũng đã giới thiệu cở sở hạ tầng ứng dụng Web như các máy chủ đệm (cache), cookie và cơ sở dữ liệu phía người sử dụng.

Chương 3. Truyền tệp và thư điện tử

TRUYỀN TỆP VÀ THƯ ĐIỆN TỬ

Equation Section (Next) Chương 3 đi sâu vào hai ứng dụng quan trọng và phổ biến của Internet là truyền tệp (File Transfer Protocol-FTP) và thư điện tử (email).

Giao thứ c truyền tệp FTP

Dịch vụ do giao thức FTP cung cấp

Trong một phiên của giao thức truyền tệp (FTP) điển hình, người sử dụng ngồi trước màn hình trạm chủ (trạm cục bộ) và muốn truyền tệp tới một trạm chủ ở xa hoặc nhận tệp từ một trạm chủ ở xa. Để truy nhập vào tài khoản ở xa thì người sử dụng phải cung cấp nhận dạng cá nhân và mật khẩu. Sau khi cung cấp thông tin uỷ quyền này, người sử dụng có thể truyền tệp từ hệ thống tệp cục bộ tới hệ thống tệp ở xa và ngược lại. Hình 3.1 minh hoạ việc người sử dụng tương tác với FTP thông qua đại lý người sử dụng FTP. Đầu tiên người sử dụng cung cấp tên trạm chủ (hostname) của trạm ở xa, buộc tiến trình máy khách FTP trên trạm chủ cục bộ thiết lập một kết nối TCP với tiến trình máy chủ FTP ở đầu xa. Sau đó người sử dụng cung cấp nhận dạng cá nhân và mật khẩu, thông tin này được gửi qua kết nối TCP như một phần của lệnh FTP. Một khi máy chủ đã cho phép người sử dụng thì người sử dụng sẽ sao chép một hoặc nhiều tệp lưu trữ trong hệ thống tệp cục bộ vào hệ thống tệp ở xa (hoặc ngược lại).

Hình Error! No text of specified style in document..12: FTP chuyển tệp giữa các hệ thống tệp cục bộ và ở xa

HTTP và FTP đều là các giao thức truyền tệp và có rất nhiều đặc tính chung, ví dụ: cả hai giao thức đều chạy trên TCP. Tuy nhiên, hai giao thức lớp ứng dụng này có một số khác biệt quan trọng. Điểm khác biệt lớn nhất là FTP sử dụng hai kết nối TCP song song để truyền tệp, một kết nối điều khiển và một kết nối dữ liệu. Kết nối điều khiển được sử dụng để gửi thông tin điều khiển giữa hai trạm chủ như nhận dạng người sử dụng, mật khẩu, lệnh thay đổi thư mục từ xa, lệnh đưa vào (put) hay lấy (get) tệp. Kết nối dữ liệu được sử dụng để gửi tệp. Vì FTP sử dụng kết nối điều khiển riêng nên nó được gọi là gửi thông tin điều khiển ngoài băng (out-of-band). Trong chương 6 chúng ta sẽ xem xét giao thức RTSP được sử dụng để truyền dòng phương tiện liên tục như video và audio cũng gửi thông tin điều khiển ngoài băng. HTTP gửi các dòng tiêu đề yêu cầu và đáp ứng vào cùng một kết nối TCP, kết nối này cũng dùng để chuyển tệp. Vì lý do này, HTTP được gọi là gửi thông tin điều khiển trong

Chương 3. Truyền tệp và thư điện tử

băng (in-band). Phần tiếp theo chúng ta sẽ xem xét SMTP, giao thức chủ yếu cho thư điện tử; đây cũng là một giao thức gửi thông tin điều khiển trong băng. Hình 3.2 minh hoạ các kết nối dữ liệu và điều khiển FTP.

Hình Error! No text of specified style in document..13: Kết nối điều khiển và kết nối dữ liệu

Khi người sử dụng bắt đầu phiên FTP với máy chủ ở xa, bên máy khách FTP (người sử dụng) sẽ khởi tạo kết nối TCP với bên máy chủ (trạm chủ ở xa) trên cổng 21 của máy chủ. Bên máy khách FTP gửi nhận dạng người sử dụng và mật khẩu trên kết nối điều khiển này. Bên máy khách cũng gửi lệnh để thay đổi thư mục từ xa trên kết nối điều khiển. Khi máy chủ nhận được lệnh truyền tệp trên kết nối điều khiển (hoặc tới hoặc từ trạm chủ ở xa) thì máy chủ sẽ khởi tạo một kết nối dữ liệu TCP tới máy khách. FTP sẽ gửi chính xác một tệp qua kết nối dữ liệu và đóng kết nối dữ liệu này. Nếu trong cùng một phiên người sử dụng muốn truyền một tệp khác thì FTP lại mở một kết nối dữ liệu khác. Vì vậy, với FTP kết nối điều khiển duy trì mở suốt phiên của người sử dụng, song cứ mỗi lần truyền một tệp trong phiên thì lại tạo ra một kết nối dữ liệu mới (nghĩa là kết nối dữ liệu là không liên tục).

Trong suốt một phiên, máy chủ FTP cần phải duy trì trạng thái về người sử dụng. Đặc biệt, máy chủ phải liên kết kết nối điều khiển với tài khoản người sử dụng cụ thể và máy chủ phải duy trì theo dõi thư mục hiện thời của người sử dụng khi người sử dụng truy nhập vào cây thư mục từ xa. Duy trì theo dõi thông tin trạng thái này cho từng phiên đang diễn ra của người sử dụng sẽ làm hạn chế đáng kể tổng số phiên mà FTP có thể duy trì đồng thời. Mặt khác, HTTP là phi trạng thái, nó không duy trì theo dõi bất kỳ trạng thái người sử dụng nào.

Các lệnh và phản hồi

Hãy xem xét một số lệnh và phản hồi thông dụng của FTP. Các lệnh từ máy khách tới máy chủ và các phản hồi từ máy chủ về máy khách được gửi trên kết nối điều khiển dưới khuôn dạng mã ASCII 7 bít. Vì vậy, cũng giống như lệnh HTTP, mọi người có thể dễ dàng đọc được lệnh FTP. Để phân định các lệnh liên tiếp cần phải xuống dòng và trở về đầu dòng sau mỗi lệnh. Mỗi lệnh gồm bốn ký tự ASCII viết hoa, một số lệnh có các đối số (argument) tuỳ chọn. Một vài lệnh thông dụng được đưa ra như sau:

USER username: Dùng để gửi nhận dạng của người sử dụng tới máy chủ. 1.

PASS password: Dùng để gửi mật khẩu của người sử dụng tới máy chủ. 2.

LIST: Dùng để yêu cầu máy chủ gửi lại danh sách tất cả các tệp trong thư mục ở xa hiện thời. Danh mục tệp này được gửi trên kết nối dữ liệu (kết nối mới và không liên tục) chứ không phải kết nối điều khiển TCP.

Chương 3. Truyền tệp và thư điện tử

RETR filename: Dùng để lấy một tệp từ thư mục hiện thời của trạm chủ ở xa. Lệnh này buộc trạm chủ ở xa khởi tạo một kết nối dữ liệu và gửi tệp được yêu cầu qua kết nối dữ liệu này.

5. STOR filename: Dùng để đưa một tệp vào thư mục hiện thời của trạm chủ ở xa.

Thường có một tương quan một-một giữa lệnh người sử dụng đưa ra và lệnh FTP gửi trên kết nối điều khiển. Tiếp theo mỗi lệnh sẽ có một phản hồi gửi từ máy chủ tới máy khách. Những phản hồi này là một số có 3 chữ số, theo sau là một bản tin tuỳ chọn. Cấu trúc này tương tự như mã trạng thái và mệnh đề trong dòng trạng thái của bản tin đáp ứng HTTP. Sau đây là một vài phản hồi điển hình, cùng với nó có thể là các thông điệp:

331 Username OK, password required (tên máy chủ OK, yêu cầu mật khẩu) 1.

125 Data connection already open; transfer starting (kết nối dữ liệu đã mở; bắt đầu truyền) 2.

425 Can’t open data connection (không thể mở kết nối dữ liệu) 3.

452 Error writing file (lỗi ghi tệp) 4.

Nếu chúng ta quan tâm chi tiết về các lệnh và phản hồi FTP khác, có thể đọc trong RFC 959.

Giao thức truyền thư điện tử trên Internet

Thư điện tử trên Internet

Thư điện tử xuất hiện từ khi Internet ra đời. Nó là ứng dụng phổ biến nhất thủa sơ khai của Internet và ngày càng phát triển mạnh mẽ. Cho tới nay, nó vẫn còn là một trong những ứng dụng Internet quan trọng và được sử dụng nhiều nhất.

Cũng như thư tín thông thường (bưu chính), thư điện tử là phương tiện truyền thông không đồng bộ - con người gửi và đọc thư vào thời điểm thuận tiện mà không phụ thuộc vào lịch biểu của người khác. Khác với thư bưu chính, thư điện tử được gửi nhanh hơn, phân phát dễ dàng hơn và có chi phí rẻ. Thư điện tử hiện đại có nhiều đặc tính mạnh mẽ. Sử dụng danh mục thư, thư điện tử và spam (thư rác) có thể gửi tới hàng nghìn người nhận cùng thời điểm. Các thư điện tử hiện đại thường bao gồm các gắn kèm, siêu liên kết, văn bản dạng HTML và ảnh.

Trong phần này chúng ta sẽ tìm hiểu về các giao thức lớp ứng dụng là trái tim của thư điện tử Internet. Nhưng trước khi đi sâu vào các giao thức này, hãy nhìn nhận một cách tổng thể hệ thống thư điện tử Internet và các thành phần chủ chốt của nó.

Chương 3. Truyền tệp và thư điện tử

Hình Error! No text of specified style in document..14: Tổng quan về hệ thống thư điện tử Internet

Hình 3.3 cho thấy bức tranh tổng thể của hệ thống thư điện tử Internet. Chúng ta thấy ở đây có 3 thành phần chính: đại lý người sử dụng (user agent), các máy chủ thư, và giao thức truyền thư đơn giản SMTP (Simple Mail Transfer Protocol). Chúng ta cùng mô tả mỗi thành phần này ở ngữ cảnh người gửi thư – Alice, gửi thư tới người nhận là Bob. Các đại lý người sử dụng cho phép người sử dụng đọc, trả lời, chuyển tiếp, lưu và soạn thảo thư. (Các đại lý người sử dụng cho thư điện tử có khi được gọi là bộ đọc thư –mail reader). Khi Alice viết xong thư, đại lý người sử dụng của cô ấy gửi bản tin tới máy chủ thư của cô ta, và bản tin được đặt ở hàng đợi bản tin đầu ra của máy chủ thư. Khi Bob muốn đọc thư, đại lý người sử dụng của anh ấy lấy thư từ hòm thư của anh ta trên máy chủ thư của anh ấy. Vào cuối những năm 1990, đại lý người sử dụng có giao diện đồ họa người sử dụng (GUI) trở nên phổ biến, nó cho phép người sử dụng xem và soạn bản tin đa phương tiện. Ngày nay, Microsoft’s Outlook, Apple Mail và Mozilla Thunderbird là những đại lý người sử dụng GUI thông dụng nhất cho thư điện tử. Ngoài ra cũng có rất nhiều các giao diện người sử dụng thư điện tử dạng văn bản trong miền công cộng, cũng như các giao diện dựa trên Web.

Các máy chủ thư tạo thành cơ sở hạ tầng lõi của thư điện tử. Mỗi người nhận (như Bob) có một hòm thư đặt ở một trong những máy chủ thư. Hòm thư của Bob quản lý và duy trì thư đã gửi cho anh ấy. Một thư thông thường sẽ bắt đầu hành trình của mình từ đại lý người sử dụng của người gửi, đi tới máy chủ thư người gửi, và tới máy chủ thư người nhận, tại đó nó được ký gửi trong hòm thư người nhận. Khi Bob muốn truy cập vào thư trong hòm thư của mình, máy chủ thư chứa hòm thư của anh ta sẽ xác thực Bob (với tên và mật khẩu). Máy chủ thư của Alice cũng phải giải quyết lỗi xảy ra trên máy chủ thư của Bob. Nếu máy chủ thư của Alice không thể chuyển thư tới máy chủ thư của Bob thì

Chương 3. Truyền tệp và thư điện tử

máy chủ của Alice sẽ giữ thư trong hàng đợi thư và sau đó cố gắng gửi thư đi. Nỗ lực gửi lại sẽ được thực hiện sau mỗi khoảng 30 phút, nếu không thành công trong vài ngày thì máy chủ sẽ xoá bỏ thư và thông báo bằng thư điện tử tới người gửi (Alice).

SMTP là giao thức lớp ứng dụng chủ yếu của thư điện tử Internet. Nó sử dụng dịch vụ truyền dữ liệu tin cậy của TCP để gửi thư từ máy chủ thư người gửi đến máy chủ thư người nhận. Như hầu hết các giao thức ứng dụng khác, SMTP có hai phía: phía khách – thực hiện trên máy chủ thư người gửi, và phía chủ - thực hiện trên máy chủ thư người nhận. Cả hai bên khách và chủ chạy SMTP trên mỗi máy chủ thư. Khi một máy chủ thư gửi thư tới các máy chủ thư khác thì nó hoạt động như máy khách SMTP. Khi một máy chủ thư nhận thư từ máy chủ thư khác thì nó hoạt động như máy chủ SMTP.

Giao thức truyền thư điện tử đơn giản SMTP

SMTP là trái tim của thư điện tử Internet (được định nghĩa trong RFC 5321). Như chúng ta đã biết, SMTP chuyển bản tin từ máy chủ thư bên gửi tới máy chủ thư bên nhận. SMTP ra đời trước HTTP (RFC đầu tiên của SMTP có từ năm 1982 và giao thức SMTP đã xuất hiện khá lâu trước đó). Mặc dù SMTP có rất nhiều đặc tính quan trọng, bằng chứng là nó đã tồn tại rộng khắp trên Internet, tuy nhiên nó là công nghệ mang tính kế thừa với nhiều đặc tính xưa cũ. Ví dụ, nó giới hạn toàn bộ bản tin (không chỉ các tiêu đề) phải là chữ và ký tự trong bảng mã ASCII 7 bít. Giới hạn này thích hợp trong những năm đầu thập kỷ 1980 khi dung lượng truyền dẫn còn khan hiếm và không ai gửi thư kèm tệp, hình ảnh, audio hay video có kích thước lớn. Nhưng ngày nay, trong kỷ nguyên đa phương tiện hạn chế của ASCII 7 bit dẫn đến một số điều không phù hợp: nó yêu cầu dữ liệu đa phương tiện số phải được mã hoá thành ASCII trước khi gửi qua SMTP, và nó yêu cầu bản tin ASCII tương ứng được giải mã trở lại nhị phân sau khi truyền tải trên SMTP. Chúng ta nhớ lại là HTTP không yêu cầu dữ liệu đa phương tiện phải được mã hoá trước khi truyền đi.

Để minh hoạ hoạt động cơ bản của SMTP, hãy xem xét một trường hợp sau (hình 3.4). Giả sử Alice muốn gửi tới Bob một bản tin mã ASCII đơn giản.

Alice gọi đại lý người sử dụng của cô ấy để gửi thư điện tử, gõ vào địa chỉ đích là hòm thư của Bob (ví dụ bob@someschool.edu), viết bản tin và lệnh cho đại lý người sử dụng gửi bản tin này.

Đại lý người sử dụng của Alice gửi bản tin tới máy chủ thư của cô ta và bản tin sẽ được đặt trong hàng đợi bản tin.

Phía máy khách của SMTP (chạy trên máy chủ thư của Alice) thấy bản tin trong hàng đợi bản tin. Nó mở một kết nối TCP tới một máy chủ thư SMTP (chạy trên máy chủ thư của Bob).

Sau quá trình bắt tay SMTP ban đầu, máy khách SMTP gửi bản tin của Alice vào kết nối TCP. 4.

Tại máy chủ thư của Bob, phía máy chủ SMTP nhận bản tin. Máy chủ thư của Bob sẽ đặt bản tin này vào hòm thư của Bob.

Bob gọi đại lý người sử dụng của anh ấy để đọc bản tin khi thuận tiện. 6.

Chương 3. Truyền tệp và thư điện tử

Hình Error! No text of specified style in document..15: Quá trình hai người gửi thư cho nhau

Một điều quan trọng cần lưu ý là SMTP thường không sử dụng các máy chủ thư trung gian để gửi bản tin, ngay cả khi hai máy chủ thư ở hai đầu trái đất. Nếu máy chủ thư của Alice ở Việt Nam và máy chủ thư của Bob ở St. Louis thì kết nối TCP là kết nối trực tiếp giữa máy chủ Việt Nam và St. Louis. Đặc biệt, nếu máy chủ của Bob mà hỏng thì bản tin sẽ ở lại trong máy chủ thư của Alice và chờ để cố gắng gửi tiếp – bản tin sẽ không lưu ở bất cứ máy chủ thư trung gian nào.

Bây giờ chúng ta sẽ đi vào chi tiết phương thức SMTP truyền bản tin từ máy chủ thư gửi đến máy chủ thư nhận. Chúng ta sẽ thấy giao thức SMTP có rất nhiều điểm tương đồng với các giao thức được dùng trong tương tác mặt đối mặt của con người. Thứ nhất, máy khách SMTP (chạy trên trạm chủ thư gửi) thiết lập kết nối TCP tới cổng 25 ở máy chủ SMTP (chạy trên trạm chủ thư nhận). Nếu như máy chủ thư hỏng thì máy khách sẽ lại cố gửi lại sau đó. Một khi kết nối được thiết lập, máy chủ và máy khách thực hiện một vài bước bắt tay lớp ứng dụng – giống như con người thường giới thiệu nhau trước khi truyền thông tin cho nhau, các máy khách và máy chủ SMTP giới thiệu nhau trước khi truyền thông tin. Trong pha bắt tay SMTP này, máy khách SMTP chỉ ra địa chỉ email của người gửi (người tạo ra bản tin) và địa chỉ email của người nhận. Một khi máy khách và máy chủ SMTP đã giới thiệu nhau xong thì máy khách sẽ gửi bản tin. SMTP có thể dựa vào dịch vụ truyền dữ liệu tin cậy của TCP để lấy bản tin từ máy chủ mà không bị lỗi. Sau đó máy khách sẽ lặp lại tiến trình này trên cùng kết nối TCP đó nếu nó có những bản tin khác gửi tới máy chủ, nếu không thì nó sẽ lệnh cho TCP đóng kết nối này.

Hãy xem xét ví dụ của các bản tin trao đổi giữa máy khách SMTP (C) và máy chủ thư SMTP (S). Tên của máy khách là crepes.fr và tên máy chủ là hambuger.edu. Các dòng văn bản ASCII bắt đầu với C: chính là các dòng máy khách gửi vào socket TCP và dòng văn bản ASCII bắt đầu với S: chính là các dòng máy chủ gửi vào socket TCP. Đoạn đối thoại sau bắt đầu ngay khi kết nối TCP được thiết lập.

S: 220 hamburger.edu

C: HELO crepes.fr

S: 250 Hello crepes.fr, pleased to meet you

C: MAIL FROM:

S: 250 alice@crepes.fr … Sender ok

Chương 3. Truyền tệp và thư điện tử

C: RCPT TO:

S: 250 bob@hamburger.edu … Recipient ok

C: DATA

S: 354 Enter mail, end with “.” on a line by itself

C: Do you like ketchup?

C: How about pickles?

C: .

S: 250 Message accepted for delivery

C: QUIT

S: 221 hambuger.edu closing connection

Trong ví dụ trên máy khách gửi một bản tin (“Do you like ketchup? How about pickles?”) từ máy chủ thư crepes.fr tới máy chủ thư hamburger.edu. Là một phần của đoạn hội thoại, máy khách đưa ra 5 lệnh: HELO (từ viết tắt của HELLO), MAIL FROM, RCPT TO, DATA và QUIT. Máy khách cũng gửi dòng chứa dấu chấm câu đơn lẻ, chỉ thị kết thúc một bản tin tới máy chủ. (Trong thuật ngữ ASCII, mỗi bản tin kết thúc bằng CRLF.CRLF, trong đó CR và LF là xuống dòng và về đầu dòng – nghĩa là dòng có một dấu chấm). Máy chủ đưa ra trả lời từng lệnh, mỗi lệnh có một mã trả lời và một vài dòng giải thích bằng tiếng Anh (tuỳ chọn). Chúng ta để ý ở đây là SMTP sử dụng kết nối liên tục: Nếu máy chủ thư bên gửi có vài bản tin gửi tới cùng máy chủ thư bên nhận thì nó có thể gửi toàn bộ bản tin trên cùng kết nối TCP đó. Với mỗi bản tin, máy khách bắt đầu tiến trình với một MAIL FROM: crepes.fr, chỉ định kết thúc bản tin với một dấu chấm câu độc lập, và đưa ra QUIT chỉ sau khi toàn bộ bản tin đã được gửi.

Bạn có thể sử dụng Telnet để thực hiện một đoạn giao tiếp trực tiếp với máy chủ SMTP, để làm điều này thực hiện:

telnet serverName 25

trong đó serverName là tên của máy chủ thư nội bộ. Khi làm điều này, bạn đang thiết lập một kết nối TCP giữa trạm chủ cục bộ và máy chủ thư. Sau khi gõ dòng lệnh này, bạn sẽ ngay lập tức nhận được bản tin “220” trả lời từ máy chủ. Sau đó đưa ra các lệnh SMTP HELO, MAIL FROM, RCPT TO, DATA, CRLF.CRLF và QUIT vào những thời điểm tương ứng.

So sánh với HTTP

Hãy so sánh sơ bộ SMTP và HTTP. Cả hai giao thức đều được dùng để truyền tệp từ một trạm chủ tới một trạm chủ khác: HTTP truyền tệp (còn được gọi là đối tượng) từ máy chủ Web tới máy khách Web (thường là trình duyệt); SMTP truyền tệp (bản tin thư điện tử) từ một máy chủ thư tới một máy chủ thư khác. Khi truyền tệp, cả HTTP và SMTP liên tục đều sử dụng các kết nối liên tục. Vì vậy hai giao

Chương 3. Truyền tệp và thư điện tử

thức này có nhiều điểm chung. Tuy nhiên, cũng có những khác biệt quan trọng. Thứ nhất là HTTP chủ yếu là giao thức kéo (pull) – người nào đó tải thông tin lên máy chủ Web và người sử dụng dùng HTTP để kéo thông tin đó từ máy chủ khi thuận tiện. Cụ thể, kết nối TCP được khởi tạo bằng máy chủ muốn nhận tệp. Mặt khác, SMTP bản chất là giao thức đẩy (push), máy chủ thư gửi đẩy tệp tới máy chủ thư nhận. Cụ thể, kết nối TCP được khởi tạo bằng máy chủ muốn gửi tệp.

Khác biệt thứ hai là SMTP yêu cầu mỗi bản tin, gồm toàn bộ thân bản tin, phải có khuôn dạng ASCII 7 bít. Nếu bản tin này chứa các ký tự không phải ASCII 7 bít (ví dụ: tiếng Việt có dấu) hoặc chứa dữ liệu nhị phân (như tệp ảnh) thì bản tin phải được mã hoá thành ASCII 7 bít. Dữ liệu HTTP không áp đặt hạn chế này.

Điểm khác biệt quan trọng thứ ba liên quan đến việc xử lý một tài liệu chứa cả văn bản và ảnh (hoặc với một loại phương tiện nào khác) như thế nào. Như đã biết, HTTP đóng gói đối tượng trong mỗi bản tin đáp ứng HTTP của nó. Thư điện tử Internet đưa toàn bộ đối tượng của thư vào trong một bản tin.

Khuôn dạng bản tin thư điện tử

Khi Alice viết bức thư tay gửi Bob, cô ấy có thể bao hàm toàn bộ các thể loại thông tin tiêu đề bên ngoài ở đầu thư, như địa chỉ của Bob, địa chỉ trả về của cô ấy và ngày tháng. Tương tự, khi bản tin thư điện tử được gửi từ người này tới người khác thì tiêu đề chứa thông tin sẽ đi trước phần nội dung tin. Những thông tin bên ngoài này được chứa trong các dòng tiêu đề, chúng được định nghĩa trong RFC 5322. Các dòng tiêu đề và thân của bản tin được tách biệt bằng một dòng trống (tức là bằng CRLF). RFC 5322 đặc tả khuôn dạng chính xác của các dòng tiêu đề thư cũng như những biên dịch ngữ nghĩa. Cùng với HTTP, mỗi dòng tiêu đề chứa văn bản đọc được, bao gồm một từ khoá, tiếp theo sau là một giá trị và dấu hai chấm. Một vài từ khoá là bắt buộc, còn lại là tuỳ chọn. Mỗi tiêu đề phải có dòng tiêu đề From: và dòng tiêu đề To:, tiêu đề có thể có dòng tiêu đề Subject: cũng như các dòng tiêu đề tuỳ chọn khác. Cần lưu ý là những dòng tiêu đề này khác với lệnh SMTP mà chúng ta nghiên cứu ở phần 3.2.1 (mặc dù chúng chứa một vài từ giống nhau như “from” và “to”). Lệnh trong phần trước là một phần của giao thức bắt tay SMTP, còn dòng tiêu đề xem xét ở đây là một phần trong bản tin thư.

Một tiêu đề tin điển hình giống như thế này:

From: alice@crepes.fr

To: bob@hamburger.edu

Subject: Searching for the meaning of life.

Sau tiêu đề bản tin là một dòng trống, sau đó là thân bản tin (dạng ASCII). Bạn có thể dùng Telnet để gửi bản tin từ máy chủ thư chứa một vài dòng tiêu đề, bao gồm dòng tiêu đề Subject:. Để làm điều đó, dùng lệnh telnet serverName 25 như mô tả ở phần 3.2.1.

Các giao thức truy cập thư điện tử

Chương 3. Truyền tệp và thư điện tử

Một khi SMTP chuyển xong thư từ máy chủ thư của Alice đến máy chủ thư của Bob thì thư được đặt trong hòm thư của Bob. Chúng ta ngầm định là Bob đọc thư bằng cách đăng nhập vào máy chủ thư và thực hiện việc đọc thư trên máy chủ đó. Cho tới tận đầu thập kỷ 1990 đấy là cách thức tiêu chuẩn để thực hiện điều này. Ngày nay, việc truy nhập thư sử dụng kiến trúc khách-chủ: người sử dụng thường đọc thư điện tử bằng máy khách thực hiện ở hệ thống cuối phía người sử dụng, ví dụ như là máy tính ở công ty, máy tính xách tay hay là PDA. Bằng cách thực hiện vai trò máy khách thư trên máy tính nội bộ, người sử dụng có được rất nhiều đặc tính, bao gồm khả năng xem các bản tin đa phương tiện và các tệp đính kèm.

Giả sử Bob (người nhận) chạy chương trình đại lý người sử dụng trên máy tính nội bộ của mình, theo lẽ tự nhiên có thể xem xét đặt máy chủ thư tại máy tính của anh ấy. Với giải pháp này, máy chủ thư của Alice sẽ đối thoại trực tiếp với máy tính của Bob. Tuy nhiên giải pháp này cũng có các khó khăn. Chúng ta nhớ lại là một máy chủ thư quản lý các hòm thư và hoạt động ở cả hai phía khách và chủ của SMTP. Nếu máy chủ thư của Bob nằm trên máy tính nội bộ của anh ấy thì máy tính đó sẽ phải luôn ở trạng thái hoạt động và phải kết nối vào Internet để nhận được những thư mới tới vào bất kỳ thời điểm nào. Điều này là không thực tế với nhiều người sử dụng Internet. Thay vào đó, một người sử dụng thường chạy chương trình đại lý người sử dụng trên máy tính nội bộ song lại truy nhập vào hòm thư của mình lưu trên một máy chủ thư chia sẻ luôn luôn hoạt động. Máy chủ thư này được rất nhiều người sử dụng khác chia sẻ và thường được một ISP của người sử dụng duy trì (ví dụ: ISP là một trường đại học hoặc một công ty).

Bây giờ hãy xét đường đi của thư điện tử khi gửi từ Alice đến Bob. Chúng ta mới học được là ở một điểm nào đó trên đường đi, thư cần phải được gửi vào máy chủ thư của Bob. Điều này có thể thực hiện dễ dàng bằng cách đại lý người sử dụng của Alice gửi thư trực tiếp tới máy chủ thư của Bob. Và thực sự điều này có thể thực hiện được với SMTP, nó được thiết kế để đẩy thư điện tử từ trạm chủ này tới trạm chủ khác. Tuy nhiên, thông thường đại lý người sử dụng của người gửi không đàm thoại trực tiếp với máy chủ thư của người nhận. Thay vào đó, như đưa ra trong hình 3.5, đại lý người sử dụng của Alice sử dụng SMTP để đẩy thư vào máy chủ thư của cô ấy, sau đó máy chủ thư của Alice sử dụng SMTP (như một máy khách SMTP) chuyển tiếp thư này vào máy chủ thư của Bob. Tại sao lại là thủ tục hai bước này? Chủ yếu bởi vì nếu không có sự chuyển tiếp qua máy chủ thư của Alice thì đại lý người sử dụng của Alice không có bất cứ cách nào truy cập đến máy chủ thư đích đang mất liên hệ. Bằng cách đầu tiên gửi e-mail của Alice vào chính máy chủ thư của cô ấy, máy chủ thư của Alice có thể lặp lại việc gửi bản tin tới máy chủ thư của Bob (sau mỗi khoảng 30 phút) cho tới khi máy chủ thư của Bob hoạt động trở lại. (Và nếu máy chủ thư của Alice bị hỏng thì cô ấy có thể phàn nàn với nhà quản trị hệ thống của cô ấy). RFC SMTP định nghĩa cách dùng các lệnh SMTP để chuyển tiếp thư qua nhiều máy chủ SMTP.

Tuy nhiên vẫn còn vấn đề chưa ổn ở đây. Làm thế nào để người nhận như Bob với đại lý người sử dụng trên máy tính cá nhân của anh ấy sẽ nhận được thư này trong khi thư lại nằm trong máy chủ thư thuộc ISP của Bob? Chú ý là đại lý người sử dụng của Bob không thể dùng SMTP để lấy thư vì lấy thư là hoạt động kéo (pull), trong khi SMTP là giao thức đẩy (push). Vấn đề này được giải quyết bằng cách đưa ra các giao thức truy nhập thư đặc biệt để truyền thư từ máy chủ thư của Bob đến máy tính cá nhân của anh ấy. Hiện nay có khá nhiều giao thức truy nhập thư thông dụng, bao gồm POP3 (Post Office Protocol Version 3), IMAP (Internet Mail Access Protocol) và HTTP.

Chương 3. Truyền tệp và thư điện tử

Hình 3.5 đưa ra tổng kết về các giao thức sử dụng cho thư Internet: SMTP được dùng để truyền thư từ máy chủ thư người gửi đến máy chủ thư người nhận; SMTP cũng được dùng để truyền thư từ đại lý người sử dụng bên gửi tới máy chủ thư người gửi. Một giao thức truy nhập thư, ví dụ POP3, được dùng để truyền thư từ máy chủ thư người nhận tới đại lý người sử dụng của người nhận.

Hình Error! No text of specified style in document..16: Các giao thức thư điện tử và những thực thể truyền thông của chúng

POP3

POP3 là giao thức truy nhập thư rất đơn giản. Nó được định nghĩa trong RFC 1939, nó khá ngắn gọn và dễ đọc. Vì giao thức này rất đơn giản nên chức năng của nó khá là hạn chế. POP3 bắt đầu khi đại lý người sử dụng (máy khách) mở một kết nối TCP tới máy chủ thư (máy chủ) trên cổng 110. Với kết nối vừa thiết lập này, POP3 tiến triển qua ba pha: uỷ quyền, giao dịch và cập nhật. Trong pha đầu tiên - pha uỷ quyền - đại lý người sử dụng gửi tên và mật khẩu (rõ ràng) để xác thực người sử dụng. Trong pha thứ hai - pha giao dịch - đại lý người sử dụng lấy các bản tin, cũng trong pha này đại lý người sử dụng có thể đánh dấu các bản tin để xoá, bỏ đánh dấu xoá và lấy thống kê thư. Pha thứ ba - pha cập nhật – diễn ra sau khi máy khách đã thực hiện lệnh quit, kết thúc phiên POP3; ở thời điểm này máy chủ thư xoá các bản tin đã bị đánh dấu để xoá.

Trong một phiên giao dịch POP3, đại lý người sử dụng đưa ra các lệnh và máy chủ đáp ứng từng lệnh bằng bản tin trả lời. Có hai khả năng đáp ứng: +OK (đôi khi còn kèm theo dữ liệu từ máy chủ tới máy khách), do máy chủ sử dụng để chỉ ra là lệnh trước đó là tốt và –ERR do máy chủ sử dụng để chỉ ra là lệnh trước đó bị lỗi.

Pha uỷ quyền có hai lệnh cơ bản: user và pass . Để minh hoạ hai lệnh này, hãy thử Telnet trực tiếp vào máy chủ POP3, sử dụng cổng 110 và đưa ra các lệnh này. Giả sử mailServer là tên của máy chủ thư của bạn. Bạn sẽ thấy như sau:

telnet mailServer 110

+OK POP3 server ready

user bob

+OK

pass hungry

+OK user successfully logged on

Chương 3. Truyền tệp và thư điện tử

Bây giờ hãy nhìn vào pha giao dịch. Một đại lý người sử dụng POP3 có thể được người sử dụng cấu hình để “tải về và xoá” hoặc “tải về và lưu giữ”. Trình tự lệnh do đại lý người sử dụng POP3 đưa ra phụ thuộc vào việc đại lý người sử dụng cấu hình theo phương thức hoạt động nào. Trong phương thức tải về-và-xoá, đại lý người sử dụng sẽ đưa ra các lệnh list, retr và dele. Ví dụ, giả sử người sử dụng có hai bản tin trong hòm thư của mình. Trong đoạn hội thoại sau, C: (máy khách) là đại lý người sử dụng và S: (máy chủ) là máy chủ thư. Giao dịch sẽ như sau:

C: list

S: 1 498

S: 2 912

S: .

C: retr 1

S: (blah blah ...

S: .................

S: ..........blah)

S: .

C: dele 1

C: retr 2

S: (blah blah ...

S: .................

S: ..........blah)

S: .

C: dele 2

C:quit

S:+OK POP3 server signing off

Đầu tiên, đại lý người sử dụng sẽ yêu cầu máy chủ thư liệt kê kích thước của mỗi bản tin lưu trữ. Sau đó đại lý người sử dụng sẽ lấy và xoá từng bản tin khỏi máy chủ. Chú ý là sau pha uỷ quyền, đại lý người sử dụng chỉ dùng bốn lệnh: list, retr, dele và quit. Cú pháp của các lệnh này được định nghĩa trong RFC 1939. Sau khi xử lý lệnh quit, máy chủ POP3 đi vào pha cập nhật và xoá bỏ các bản tin 1 và 2 khỏi hòm thư.

Chương 3. Truyền tệp và thư điện tử

Có một khó khăn với phương thức tải về-và-xoá đó là người nhận (Bob) có thể nay đây mai đó và muốn truy cập bản tin từ nhiều máy tính khác nhau như máy để bàn ở cơ quan, máy tính ở nhà hoặc máy tính xách tay của anh ấy. Phương thức tải về-và-xoá này sẽ phân chia những bản tin thư của Bob trên 3 máy này, cụ thể là nếu đầu tiên Bob đọc một bản tin trên máy tính cơ quan thì buổi tối khi về nhà anh ấy sẽ không thể đọc lại bản tin này từ máy xách tay của mình. Trong phương thức tải về-và- giữ, đại lý người sử dụng vẫn giữ bản tin trên máy chủ thư sau khi tải chúng về. Trong trường hợp này, Bob có thể đọc lại bản tin từ các máy tính khác nhau, anh ấy có thể truy nhập một bản tin từ cơ quan và truy nhập chính bản tin đó ở nhà sau đó một tuần.

Trong phiên POP3 giữa đại lý người sử dụng và máy chủ thư, máy chủ POP3 sẽ duy trì một vài thông tin trạng thái; cụ thể là nó theo dõi bản tin người sử dụng nào đã được đánh dấu xoá. Tuy nhiên, máy chủ POP3 không mang thông tin trạng thái xuyên qua các phiên POP3. Thiếu thông tin trạng thái này qua các phiên làm đơn giản hoá việc thực hiện máy chủ POP3.

IMAP

Với truy nhập POP3, một khi Bob đã tải các bản tin về máy tính nội bộ, anh ấy có thể tạo các thư mục thư và chuyển các bản tin tải về vào các thư mục đó. Sau đó Bob có thể xoá bản tin, di chuyển bản tin vào các thư mục và tìm kiếm các bản tin (qua tên người gửi hoặc chủ đề thư). Nhưng mô hình này (các thư mục và bản tin trong máy nội bộ) sẽ đặt ra một khó khăn cho người sử dụng hay di chuyển, khi họ mong muốn duy trì phân cấp thư mục trên máy chủ ở xa và có thể truy nhập từ bất kỳ máy tính nào. Điều này là không thể với POP3 – giao thức POP3 không cung cấp công cụ nào cho người sử dụng để tạo thư mục từ xa và sắp xếp bản tin vào các thư mục.

Để giải quyết khó khăn này và những vấn đề khác nữa, giao thức IMAP (RFC 3501) đã được tạo lập. Cũng giống POP3, IMAP là giao thức truy nhập thư. Nó có nhiều đặc tính hơn so với POP3 và tất nhiên là nó cũng phức tạp hơn nhiều. (Và vì thế việc thực thi ở phía máy khách và máy chủ cũng phức tạp hơn nhiều).

Một máy chủ IMAP sẽ liên kết mỗi bản tin với một thư mục, khi bản tin lần đầu đến máy chủ, nó được gắn với thư mục INBOX của người nhận. Sau đó người nhận có thể chuyển bản tin này vào một thư mục mới do người sử dụng tạo ra, đọc bản tin, xoá bản tin… Giao thức IMAP cung cấp các lệnh để cho người sử dụng tạo thư mục và chuyển bản tin từ thư mục này tới thư mục khác. IMAP cũng cung cấp các lệnh cho phép người sử dụng tìm kiếm thư trong thư mục từ xa theo những tiêu chí riêng. Chú ý là khác với POP3, máy chủ IMAP duy trì thông tin trạng thái người sử dụng xuyên suốt các phiên IMAP – ví dụ, tên của các thư mục và những bản tin nào được liên kết với những thư mục nào.

Một đặc tính quan trọng khác của IMAP là nó có những lệnh cho phép đại lý người sử dụng lấy các thành phần của bản tin. Ví dụ, đại lý người sử dụng có thể chỉ rút ra tiêu đề bản tin của bản tin hay chỉ một phần của bản tin MIME nhiều phần dữ liệu. Đặc tính này rất hữu dụng khi chỉ có kết nối băng thông thấp (ví dụ: kết nối modem tốc độ thấp) giữa đại lý người sử dụng và máy chủ thư của nó. Với kết nối băng thông thấp, người sử dụng có thể không muốn tải về toàn bộ bản tin trong hòm thư, đặc biệt là tránh những thư kích thước lớn có thể chứa đoạn audio và video.

Chương 3. Truyền tệp và thư điện tử

Thư điện tử dựa trên Web (Web-Based E-mail)

Tháng 12 năm 1995, chỉ vài năm sau khi Web được phát minh, Sabeer Bhatia và Jack Smith đã tới thăm nhà tư bản kinh doanh Internet Draper Fisher Jurvetson và đề xuất phát triển một hệ thống thư điện tử trên Web miễn phí. Ý tưởng này cấp tài khoản thư điện tử miễn phí cho bất kỳ người nào mong muốn, và tạo ra các tài khoản truy cập được từ Web. Để trao đổi lấy 15% công ty, Draper Fisher Jurvetson đã tài trợ cho Bhatia và Smit để gây dựng nên công ty Hotmail. Với nhân lực gồm 3 nhân viên chính thức và 14 nhân viên cộng tác, họ đã phát triển được và ra mắt dịch vụ vào tháng 7 năm 1996. Trong vòng một tháng sau khi bắt đầu, họ đã có 100.000 thuê bao (khách hàng). Vào tháng 12 năm 1997, chỉ sau không đến 18 tháng ra mắt dịch vụ, Hotmail đã có trên 12 triệu thuê bao và được Microsoft mua lại với giá 400 triệu đô la Mỹ (theo báo cáo). Thành công của Hotmail được cho là do lợi thế đi tiên phong và tiếp thị quảng bá của thư điện tử.

Thư điện tử trên Web tiếp tục phát triển mạnh, trở nên thông minh và mạnh mẽ hơn qua từng năm. Một trong những dịch vụ phổ biến nhất ngày nay là gmail của Google, nó cung cấp bộ nhớ miễn phí hàng gigabyte, lọc thư rác nâng cao và phát hiện virus, tính năng mật mã hoá thư điện tử (SSL), lấy thư từ dịch vụ thư điện tử bên thứ ba, và giao diện hướng tìm kiếm.

Ngày càng có nhiều người sử dụng đang gửi và truy nhập thư điện tử qua trình duyệt Web. Hotmail giới thiệu truy nhập thư điện tử qua Web vào giữa thập kỷ 1990, hiện nay thư điện tử dựa trên Web cũng được Yahoo, Google cũng như nhiều tập đoàn và trường đại học lớn sử dụng. Với dịch vụ này, đại lý người sử dụng là một trình duyệt Web bình thường và người sử dụng truyền thông với hòm thư từ xa của họ thông qua HTTP. Khi người nhận (Bob) muốn truy nhập thư trong hòm thư của mình, thì thư điện tử được gửi từ máy chủ thư của Bob tới trình duyệt của Bob sử dụng giao thức HTTP chứ không phải là POP3 hay IMAP. Khi người gửi (Alice) muốn gửi thư điện tử, thư điện tử của cô ấy sẽ được gửi từ trình duyệt của cô ta tới máy chủ thư của cô ấy trên HTTP chứ không phải SMTP. Tuy nhiên, máy chủ thư của Alice vẫn gửi bản tin tới và nhận bản tin từ những máy chủ thư khác qua SMTP.

Chương 4. Dịch vụ tên miền DNS

DỊCH VỤ TÊN MIỀN DNS

Tổng quan DNS

Chương 4 giới thiệu về dịch vụ tên miền DNS trên lớp ứng dụng của mạng Internet. Nhiệm vụ của dịch vụ này là chuyển đổi giữa tên miền và địa chỉ IP. Người sử dụng ứng dụng này dùng tên chứ không dùng địa chỉ IP.

Giới thiệu DNS

Con người có thể được nhận dạng bằng nhiều cách thức khác nhau. Ví dụ, chúng ta có thể được nhận dạng bằng tên trong giấy khai sinh, chúng ta cũng có thể được nhận dạng thông qua số chứng minh thư, hoặc số bằng lái xe. Mặc dù mỗi định danh trên đều có thể sử dụng để nhận dạng con người, song trong một ngữ cảnh cụ thể, một định danh này có thể phù hợp hơn các định danh khác. Ví dụ, máy tính ở IRS (đại lý thu thập phí của Mỹ) ưa sử dụng các số an ninh xã hội có độ dài cố định hơn là tên trong giấy khai sinh. Mặt khác, những người bình thường thích tên trong giấy khai sinh (dễ nhớ) hơn là số an ninh xã hội hoặc chứng minh thư. (Bạn có thể tưởng tượng thế này, bạn sẽ nói: “Xin chào, tên tôi là 132-67-9875. Hãy làm quen với chồng tôi, 178-87-1146”).

Có thể nhận dạng con người bằng nhiều cách khác nhau, các máy tính trên Internet cũng vậy. Một định danh cho máy trạm là tên trạm chủ (hostname). Tên trạm chủ, ví dụ cnn.com, www.yahoo.com, gaia.cs.umass.edu, cis.poly.edu, là những tên dễ nhớ và do đó phù hợp với mọi người. Tuy nhiên, tên trạm chủ cung cấp rất ít (nếu có) thông tin về vị trí của nó trong Internet. (Một tên trạm chủ như www.eurecom.fr có kết thúc bằng mã quốc gia .fr cho ta thấy là trạm chủ này có thể ở Pháp, song không có thêm thông tin gì khác). Thêm nữa, vì tên trạm chủ có thể bao gồm các ký tự chữ và số có độ dài thay đổi nên sẽ khó xử lý trên các bộ định tuyến (router). Vì những lý do này, các trạm chủ cũng được nhận dạng bằng địa chỉ IP.

Một địa chỉ IP (phiên bản 4) có độ dài 4 byte và có cấu trúc phân cấp cứng. Ví dụ, địa chỉ IP là 121.7.106.83, mỗi byte tách biệt nhau bằng một dấu chấm và có giá trị số thập phân từ 0 đến 255. Địa chỉ IP là phân cấp vì nếu chúng ta quét địa chỉ từ trái qua phải, chúng ta nhận được nhiều thông tin hơn về vị trí trạm được đặt ở đâu trong Interrnet (nghĩa là, nó đang ở trong mạng nào, trong mạng của các mạng). Tương tự, khi chúng ta quét một địa chỉ bưu chính từ trên xuống dưới, chúng ta có nhiều thông tin cụ thể hơn về địa chỉ của thư.

Dịch vụ do DNS cung cấp

Chúng ta thấy là có hai cách để nhận dạng một trạm chủ, bằng tên trạm chủ hoặc bằng địa chỉ IP. Con người thích định danh theo tên trạm chủ vì nó dễ nhớ, trong khi các bộ định tuyến thì lại ưa sử dụng địa chỉ IP có cấu trúc phân cấp và độ dài cố định. Để hài hoà những ý muốn này, chúng ta cần một dịch vụ thư mục để phiên dịch tên trạm chủ sang địa chỉ IP. Đây là nhiệm vụ chính của hệ thống tên miền (DNS) của Internet. DNS là (1) cơ sở dữ liệu phân tán thực hiện trên cấu trúc phân cấp các máy chủ DNS và (2) là một giao thức lớp ứng dụng cho phép các trạm chủ truy vấn cơ sở dữ liệu phân tán.

Chương 4. Dịch vụ tên miền DNS

Các máy chủ DNS thường là các máy UNIX chạy phần mềm BIND (Berkeley Internet Name Domain). Giao thức DNS chạy trên UDP và sử dụng cổng 53.

DNS thường được các giao thức ứng dụng khác sử dụng - bao gồm HTTP, SMTP và FTP - để phiên dịch tên trạm chủ do người sử dụng đưa ra thành địa chỉ IP. Ví dụ, hãy xem điều gì xảy ra khi khi một trình duyệt (máy khách HTTP) chạy trên máy tính của người sử dụng nào đó, yêu cầu trang www.someschool.edu/index.html. Để máy trạm của người sử dụng có thể gửi một bản tin yêu cầu HTTP tới máy chủ Web www.someschool.edu thì máy trạm của người sử dụng trước tiên phải có được địa chỉ IP của www.someschool.edu. Điều này được thực hiện như sau:

1. Máy tính của người sử dụng đó hoạt động như bên máy khách của ứng dụng DNS.

2. Trình duyệt lấy tên trạm chủ www.someschool.edu từ URL và chuyển tên trạm chủ tới

bên máy khách của ứng dụng DNS.

3. Máy khách DNS gửi một truy vấn chứa tên trạm chủ tới máy chủ DNS.

4. Máy khách DNS nhận được bản tin trả lời chứa địa chỉ IP cho tên trạm chủ.

5. Một khi trình duyệt nhận được địa chỉ IP từ DNS, nó sẽ bắt đầu một kết nối TCP tới tiến trình

máy chủ HTTP thông qua cổng 80 của máy chủ có địa chỉ IP đó.

Từ ví dụ này ta thấy DNS gây thêm một phần trễ - đôi khi khá lớn – vào các ứng dụng Internet phải sử dụng đến nó. Rất may là địa chỉ IP yêu cầu thường được lưu đệm ở một máy chủ DNS gần đó, giúp giảm lưu lượng mạng DNS cũng như giảm trễ DNS trung bình.

DNS còn cung cấp một số dịch vụ quan trọng khác ngoài việc phiên dịch tên trạm chủ thành địa chỉ IP như:

Host aliasing (Bí danh trạm chủ). Một trạm chủ có tên trạm phức tạp có thể có một hay nhiều bí danh. Ví dụ, tên trạm như relay1.west-coast.enterprise.com có thể có hai bí danh là enterprise.com và www.enterprise.com. Trong trường hợp này, tên trạm chủ relay1.west-coast.enterprise.com được gọi là tên trạm chính tắc (canonical hostname). Tên trạm bí danh, nếu có, thường dễ nhớ hơn là tên trạm chính tắc. DNS có thể được một ứng dụng gọi tới để lấy tên trạm chính tắc cho một tên trạm bí danh được cung cấp, cũng như địa chỉ IP của trạm chủ đó.

Mail server aliasing (Bí danh máy chủ thư). Rõ ràng là chúng ta cũng mong muốn địa chỉ thư điện tử cần phải dễ nhớ. Ví dụ, nếu Bob có một tài khoản Hotmail, địa chỉ email của Bob có thể đơn giản là bob@hotmail.com. Tuy nhiên, tên trạm máy chủ thư Hotmail có thể phức tạp hơn và khó nhớ hơn cái tên hotmail.com (ví dụ tên chính tắc có thể là relay1.west- coast.hotmail.com). DNS có thể được một ứng dụng thư gọi tới để lấy tên chính tắc cho một tên trạm bí danh được cung cấp, cũng như địa chỉ IP của trạm chủ đó. Thực tế là, bản ghi MX (xem ở phần sau) cho phép một máy chủ thư và máy chủ web của một công ty có cùng tên trạm (bí danh). Ví dụ, một máy chủ Web và máy chủ thư của công ty có thể có cùng tên gọi là enterprise.com.

Chương 4. Dịch vụ tên miền DNS

Phân bố tải. DNS cũng được sử dụng để thực hiện phân bố tải giữa các máy chủ nhân rộng (replicated), như các máy chủ nhân rộng Web. Các trang Web bận rộn, như cnn.com thường được nhân rộng trên nhiều máy chủ, với mỗi máy chủ chạy trên một hệ thống đầu cuối khác nhau và có địa chỉ IP khác nhau. Đối với các máy chủ Web nhân rộng, một tập địa chỉ IP sẽ được gắn với một tên chính tắc (canonical). Cơ sở dữ liệu DNS chứa tập địa chỉ IP này. Khi máy khách thực hiện truy vấn DNS đối với tên ánh xạ tới tập địa chỉ, máy chủ sẽ đáp ứng toàn bộ tập địa chỉ IP này, nhưng xoay vòng thứ tự những địa chỉ này với mỗi lần trả lời. Vì một máy khách thường gửi bản tin yêu cầu HTTP của nó đến địa chỉ IP đứng đầu tập danh sách nên việc xoay vòng DNS sẽ phân tải lưu lượng giữa các máy chủ nhân rộng. Việc xoay vòng DNS cũng được sử dụng cho ứng dụng e-mail sao cho nhiều máy chủ thư có thể có cùng bí danh. Gần đây, các công ty phân phối nội dung như Akamai dã sử dụng DNS theo cách phức tạp hơn để cung cấp phân bố nội dung Web.

Giống như HTTP, FTP và SMTP, giao thức DNS là một giao thức lớp ứng dụng vì (1) nó chạy giữa các hệ thống đầu cuối truyền thông sử dụng mô hình client-server và (2) nó dựa trên giao thức lớp giao vận end-to-end để truyền các bản tin DNS giữa các hệ thống truyền thông đầu cuối. Tuy nhiên, ở một ý nghĩa khác, vai trò của DNS khác với ứng dụng web, truyền file và thư điện tử. Khác với những ứng dụng này, DNS không phải là ứng dụng mà người sử dụng tương tác trực tiếp. Thay vào đó, DNS cung cấp chức năng Internet cốt lõi, đó là phiên dịch tên trạm chủ thành địa chỉ IP cho các ứng dụng người sử dụng và các phần mềm khác trên Internet. Ta đã biết là kiến trúc Internet phức tạp, tập trung chủ yếu ở biên mạng. DNS thực hiện tiến trình phiên dịch tên thành địa chỉ sử dụng máy khách và máy chủ đặt tại biên của mạng, là một ví dụ của tính phức tạp này.

DNS được đặc tả trong RFC 1034, RFC 1035 và được cập nhật trong một vài RFC bổ sung. Đó là một hệ thống phức tạp, chúng ta chỉ đề cập những khía cạnh chủ yếu trong hoạt động của nó ở đây.

Hoạt động của DNS

Hãy xem xét hoạt động của DNS ở mức tổng quan và thảo luận về dịch vụ phiên dịch tên-địa chỉ IP.

Giả sử một ứng dụng nào đó (như trình duyệt web) chạy trên trạm chủ người sử dụng cần phiên dịch từ tên trạm chủ thành địa chỉ IP. Ứng dụng này sẽ kích hoạt phía máy khách của DNS, đặc tả tên trạm chủ cần phải phiên dịch. (Trên nhiều máy tính chạy trên UNIX, gethostbyname() là hàm gọi ứng dụng này để thực hiện việc phiên dịch này). Sau đó, DNS ở trạm chủ người sử dụng sẽ tiếp tục qúa trình, gửi bản tin truy vấn vào trong mạng. Tất cả bản tin truy vấn và phản hồi được gửi trên dữ liệu đồ UDP tới cổng 53. Sau một khoảng thời gian trễ từ mili giây đến hàng giây, DNS trong trạm chủ người sử dụng sẽ nhận được bản tin phản hồi DNS cung cấp ánh xạ yêu cầu. Ánh xạ này sau đó được chuyển đến ứng dụng đưa ra. Vì vậy, từ khía cạnh của ứng dụng đưa ra trong trạm chủ người sử dụng, DNS là hộp đen cung cấp dịch vụ phiên dịch đơn giản và dễ dàng. Song thực tế thì hộp đen này thực hiện dịch vụ khá phức tạp, bao gồm một lượng lớn máy chủ DNS phân bố khắp nơi trên thế giới, cũng như một giao thức lớp ứng dụng đặc tả các máy chủ DNS và các trạm chủ truy vấn truyền thông với nhau như thế nào.

Một thiết kế đơn giản cho DNS có thể có một máy chủ DNS chứa tất cả ánh xạ. Trong thiết kế tập trung này, các máy khách gửi truy vấn trực tiếp tới một máy chủ DNS duy nhất và máy chủ DNS sẽ

Chương 4. Dịch vụ tên miền DNS

đáp ứng trực tiếp tới các máy khách truy vấn. Mặc dù tính đơn giản của thiết kế này rất hấp dẫn nhưng nó lại không phù hợp với Internet ngày nay, với số lượng trạm rất lớn và vẫn gia tăng từng ngày. Các khó khăn mà thiết kế tập trung gặp phải là:

1. Một điểm lỗi. Nếu máy chủ DNS trục trặc thì toàn bộ mạng Internet bị trục trặc.

Lưu lượng. Một máy chủ DNS đơn sẽ phải xử lý toàn bộ truy vấn DNS (cho toàn bộ yêu cầu HTTP và email gửi từ hàng trăm triệu máy tính).

Cơ sở dữ liệu tập trung ở xa. Một máy chủ DNS không thể “gần” với tất cả máy khách đang truy vấn. Nếu chúng ta đặt máy chủ DNS đơn này ở Thành phố New York thì tất cả truy vấn từ Việt nam sẽ phải đi tới phía bên kia của trái đất, có lẽ trên cả những kết nối chậm và tắc nghẽn. Điều này làm tăng đáng kể độ trễ.

Bảo trì. Một máy chủ DNS đơn sẽ phải lưu giữ các bản ghi cho tất cả các trạm trên Internet. Không những cơ sở dữ liệu tập trung này sẽ phải có kích thước rất lớn mà nó còn phải thường xuyên cập nhật cho từng trạm mới xuất hiện.

Tóm lại, cơ sở dữ liệu tập trung trong một máy chủ DNS là không phù hợp quy mô. Dẫn đến là DNS được thiết kế phân tán. Thực tế, DNS là một ví dụ tuyệt vời cho việc thực hiện cơ sở dữ liệu phân tán trên Internet.

Phân bố cơ sở dữ liệu DNS

Để giải quyết vấn đề quy mô (scale), DNS sử dụng nhiều máy chủ, tổ chức theo kiểu phân cấp và phân tán trên khắp địa cầu. Không có máy chủ nào chứa toàn bộ ánh xạ cho các máy tính trên Internet. Thay vào đó, các ánh xạ sẽ được phân bố giữa các máy chủ DNS. Trong mức tiệm cận ban đầu, có ba lớp máy chủ DNS: máy chủ DNS gốc (root), máy chủ DNS miền mức cao (top-level domain - TLD) và máy chủ DNS thẩm quyền. Chúng được tổ chức phân cấp như hình 4.1. Để hiểu các lớp máy chủ tương tác như thế nào, giả sử một máy khách DNS muốn xác định địa chỉ IP cho tên miền www.amazon.com.

Hình Error! No text of specified style in document..17: Cấu trúc phân cấp của máy chủ DNS

Với tiệm cận ban đầu, những sự kiện sau sẽ xảy ra. Đầu tiên máy khách sẽ kết nối với một máy chủ gốc, máy chủ gốc này sẽ trả về những địa chỉ của các máy chủ TLD cho tên miền mức cao 57

Chương 4. Dịch vụ tên miền DNS

nhất là com. Sau đó máy khách kết nối tới một trong những máy chủ TLD, máy chủ TLD này sẽ trả về địa chỉ IP của máy chủ thẩm quyền cho amazon.com. Cuối cùng, máy khách kết nối tới các máy chủ thẩm quyền cho amazon.com, máy chủ thẩm quyền này trả về địa chỉ IP cho tên trạm chủ www.amazon.com. Chúng ta sẽ xem xét chi tiết tiến trình DNS này sau. Trước tiên ta sẽ nhìn vào ba lớp của máy chủ DNS:

Các máy chủ DNS gốc. Trong mạng Internet có 13 máy chủ DNS gốc (dán nhãn từ A đến M), hầu hết đặt ở Bắc Mỹ. Hình 4.2 là bản đồ máy chủ DNS gốc tháng 10 năm 2009. Mặc dù chúng ta coi từng máy chủ trong 13 máy chủ DNS này là một máy chủ đơn, song mỗi máy chủ thực nhất là một nhóm máy chủ nhân rộng với mục đích là tăng độ an toàn và tin cậy.

Hình Error! No text of specified style in document..18: Các máy chủ DNS gốc năm 2009 (tên, tổ chức, vị trí)

Các máy chủ tên miền mức cao (TLD). Những máy chủ này chịu trách nhiệm về các miền mức cao như com, org, net, edu và gov và tất cả các miền mức cao của quốc gia như us, uk, fr, ca, cn, jp và vn. Công ty Network Solutions (các giải pháp mạng) duy trì các máy chủ TLD cho tên miền mức cao com và công ty Educause duy trì các máy chủ TLD tên miền mức cao edu.

Các máy chủ DNS thẩm quyền. Bất cứ tổ chức nào có các máy truy nhập công cộng (như máy chủ web và máy chủ thư điện tử) trên Internet phải cung cấp các bản ghi DNS có khả năng truy cập ra công chúng, với ánh xạ tên của các trạm chủ này sang địa chỉ IP. Máy chủ DNS thẩm quyền của tổ chức sẽ chứa những bản ghi DNS này. Tổ chức có thể lựa chọn triển khai máy chủ DNS thẩm quyển riêng để giữ các bản ghi này; hoặc tổ chức đó có thể phải trả tiền để lưu trữ các bản ghi trong máy chủ DNS thẩm quyền của một nhà cung cấp dịch vụ nào đó. Hầu hết các trường đại học và những công ty lớn đều triển khai và duy trì máy chủ DNS thẩm quyền sơ cấp và thứ cấp (dự phòng) của riêng mình.

Chương 4. Dịch vụ tên miền DNS

Các máy chủ gốc, TLD và thẩm quyền đều thuộc về cấu trúc phân cấp máy chủ DNS như trong hình 4.1. Còn có một loại máy chủ DNS quan trọng khác nữa được gọi là máy chủ DNS cục bộ. Một máy chủ DNS cục bộ không bắt buộc thuộc phân cấp máy chủ tuy nhiên nó là trung tâm của kiến trúc DNS. Mỗi ISP – như ISP của trường đại học, viện nghiên cứu, công ty hay là một ISP khu vực dân cư – đều có một máy chủ DNS cục bộ (còn gọi là máy chủ tên mặc định). Khi một trạm chủ kết nối tới một ISP, ISP cung cấp các địa chỉ IP của một hoặc nhiều máy chủ DNS cục bộ cho trạm chủ đó (thường là qua DHCP). Bạn có thể dễ dàng xác định địa chỉ IP của máy chủ DNS cục bộ của mình bằng cách truy nhập cửa sổ trạng thái mạng trong Window hay UNIX. Một máy chủ DNS cục bộ của một trạm thường “gần” với trạm đó. Đối với ISP của một tổ chức, máy chủ DNS cục bộ có thể nằm trên cùng mạng LAN với máy trạm; đối với ISP của khu dân cư thì nó thường chỉ tách biệt với máy chủ DNS cục bộ qua một hoặc vài bộ định tuyến. Khi một trạm chủ truy vấn DNS, truy vấn sẽ được gửi tới máy chủ DNS cục bộ - hoạt động như một proxy - chuyển tiếp truy vấn đó vào cây phân cấp máy chủ DNS.

Lấy một ví dụ đơn giản. Giả sử trạm chủ cis.poly.edu muốn có địa chỉ IP của gaia.cs.umass.edu. Cũng giả sử là máy chủ DNS cục bộ của trường bách khoa này gọi là dns.poly.edu và một máy chủ DNS thẩm quyền cho gaia.cs.umass.edu là dns.umass.edu. Trên hình 4.3, đầu tiên trạm chủ cis.poly.edu gửi bản tin truy vấn DNS tới máy chủ DNS cục bộ của nó là dns.poly.edu. Bản tin truy vấn này chứa tên cần phiên dịch là gaia.cs.umass.edu. Máy chủ DNS cục bộ chuyển tiếp bản tin truy vấn tới máy chủ DNS gốc. Máy chủ DNS gốc đánh dấu hậu tố tên miền edu và trả về cho máy chủ DNS cục bộ một danh sách địa chỉ IP của các máy chủ TLD chịu trách nhiệm về tên miền edu. Sau đó máy chủ DNS cục bộ gửi lại bản tin truy vấn tới một trong các máy chủ TLD. Máy chủ TLD sẽ đánh dấu hậu tố umass.edu và đáp ứng với địa chỉ của máy chủ DNS thẩm quyền cho trường đại học Massachusetts, có tên là dns.umass.edu. Cuối cùng, máy chủ DNS cục bộ gửi lại truy vấn trực tiếp tới dns.umass.edu, và máy chủ này đáp ứng lại cùng với địa chỉ IP của gaia.cs.umass.edu. Chú ý là trong ví dụ này, để lấy được ánh xạ cho một tên trạm chủ thì cần truyền tới tám bản tin DNS: bốn bản tin truy vấn và bốn bản tin trả lời. Sau này ta sẽ thấy việc đệm DNS sẽ làm giảm lưu lượng truy vấn này.

Chương 4. Dịch vụ tên miền DNS

Hình Error! No text of specified style in document..19: Tương tác giữa các máy chủ DNS khác nhau

Ví dụ trên đã giả sử là máy chủ TLD biết tên máy chủ DNS thẩm quyền cho tên trạm chủ. Nhìn chung thì điều này không phải là luôn luôn đúng. Thay vào đó, máy chủ TLD có thể chỉ biết một máy chủ DNS trung gian biết máy chủ DNS thẩm quyền cho tên trạm chủ. Ví dụ, giả sử là trường đại học Massachusetts có máy chủ DNS của trường có tên là dns.umass.edu. Cũng giả sử là mỗi khoa trong trường có máy chủ DNS riêng và mỗi máy chủ DNS của khoa có thẩm quyền cho toàn bộ các trạm chủ trong khoa. Trong trường hợp này, khi máy chủ DNS trung gian dns.umass.edu nhận một truy vấn tới một trạm có tên trạm kết thúc bằng cs.umass.edu, nó trả về dns.poly.edu địa chỉ IP của dns.cs.umass.edu là máy chủ thẩm quyền cho tất cả các trạm có tên trạm kết thúc là cs.umass.edu. Khi đó, máy chủ DNS cục bộ dns.poly.edu sẽ gửi một truy vấn tới máy chủ DNS thẩm quyền, máy chủ này trả ánh xạ mong muốn tới máy chủ DNS cục bộ, đến lượt máy chủ này trả ánh xạ tới trạm chủ yêu cầu. Trong trường hợp này tổng cộng có tới 10 bản tin DNS được gửi đi.

Hình 4.3 cho thấy ví dụ sử dụng cả hai loại truy vấn là đệ quy và lặp. Truy vấn gửi từ cis.poly.edu tới dns.poly.edu là truy vấn đệ quy, vì truy vấn yêu cầu dns.poly.edu lấy ánh xạ thay mặt nó. Nhưng ba truy vấn tiếp theo là lặp vì tất cả phản hồi được trả trực tiếp về dns.poly.edu. Trên lý thuyết, bất kỳ truy vấn DNS nào đều có thể là lặp hoặc đệ quy. Ví dụ, hình 4.4 cho thấy chuỗi truy vấn DNS mà tất cả các truy vấn là đệ quy. Trên thực tế, các truy vấn thường tuân theo mô hình trong hình 4.3: Truy vấn từ trạm chủ yêu cầu tới máy chủ DNS cục bộ là đệ quy và các truy vấn khác là lặp.

Chương 4. Dịch vụ tên miền DNS

Hình Error! No text of specified style in document..20: Truy vấn đệ quy trong DNS

DNS cache

Lưu đệm DNS là một đặc tính quan trọng của hệ thống DNS. Thực tế là DNS sử dụng lưu đệm DNS để cải thiện hiệu năng trễ và giảm số lượng bản tin DNS xuất hiện trên Internet. Ý tưởng của đệm DNS rất đơn giản. Trong một chuỗi truy vấn, khi một máy chủ DNS nhận tin trả lời DNS (ví dụ, chứa ánh xạ từ tên trạm chủ sang địa chỉ IP), nó có thể lưu đệm ánh xạ này ở bộ nhớ nội bộ. Ví dụ, ở hình 4.3, mỗi khi máy chủ DNS cục bộ dns.poly.edu nhận một phản hồi từ một máy chủ DNS nào đó, nó có thể lưu đệm bất kỳ thông tin nào trong phản hồi đó. Nếu một cặp địa chỉ IP/tên trạm chủ được lưu đệm trong một máy chủ DNS và có một yêu cầu nữa tới máy chủ DNS này để lấy chính tên trạm chủ đó thì máy chủ DNS có thể cung cấp địa chỉ IP yêu cầu, ngay cả khi nó không có thẩm quyền về tên trạm chủ đó. Vì các trạm và ánh xạ giữa tên trạm chủ và địa chỉ IP không phải luôn cố định, máy chủ DNS sẽ hủy thông tin đệm sau một khoảng thời gian (thường đặt là 2 ngày).

Lấy ví dụ, giả sử là trạm apricot.poly.edu truy vấn dns.poly.edu về địa chỉ IP của tên trạm chủ cnn.com. Thêm nữa, giả sử là một vài giờ sau, một trạm khác của Đại học Bách khoa, như kiwi.poly.fr cũng truy vấn dns.poly.edu với cùng tên trạm chủ. Vì có lưu đệm nên máy chủ DNS cục bộ sẽ có thể trả lời tức thì về địa chỉ IP của cnn.com cho trạm yêu cầu thứ hai này mà không phải truy vấn bất kỳ một máy chủ DNS nào khác. Máy chủ DNS cục bộ cũng có thể lưu đệm địa chỉ IP của các máy chủ TLD, do đó cho phép máy chủ cục bộ bỏ qua các máy chủ DNS gốc trong chuỗi truy vấn (điều này thường xảy ra).

Chương 4. Dịch vụ tên miền DNS

Bản ghi và bản tin DNS

Bản ghi DNS

Các máy chủ DNS cùng triển khai cơ sở dữ liệu phân tán lưu giữ các bản ghi nguồn (RRs), bao gồm các RRs cung cấp ánh xạ tên trạm chủ-tới-địa chỉ IP. Mỗi bản tin trả lời DNS mang một hoặc nhiều bản ghi nguồn. Phần này cung cấp một cái nhìn bao quát về các bản ghi nguồn và bản tin DNS, chi tiết có thể xem trong các RFC DNS (RFC 1034 và RFC 1035).

Một bản ghi nguồn có bốn trường sau:

(Name, Value, Type, TTL)

TTL là thời gian sống của bản ghi nguồn; nó xác định khi nào nguồn phải được bỏ ra khỏi lưu đệm. Trong ví dụ về bản ghi dưới đây, chúng ta bỏ qua trường TTL. Nghĩa của trường Name và Value phụ thuộc vào Type:

Nếu Type=A thì Name (tên) là tên trạm và Value (giá trị) là địa chỉ IP của tên trạm đó. Vì vậy, bản ghi Type A cung cấp ánh xạ tên trạm chủ-tới-địa chỉ IP chuẩn. Ví dụ (relay1.bar.foo.com, 145.37.93.126, A) là bản ghi Type A.

Nếu Type=NS thì Name là tên miền (như foo.com) và Value là tên trạm của máy chủ DNS thẩm quyền, máy chủ này biết cách lấy địa chỉ IP của các trạm chủ trong miền đó. Bản ghi này được dùng để định tuyến các truy vấn DNS trong một chuỗi truy vấn. Ví dụ (foo.com, dns.foo.com, NS) là bản ghi Type NS.

Nếu Type=CNAME thì Value là tên trạm chính tắc cho tên trạm bí danh Name. Bản ghi này có thể cung cấp cho các trạm truy vấn tên chính tắc cho tên trạm. Ví dụ (foo.com, relay1.bar.foo.com, CNAME) là một bản ghi CNAME.

Nếu Type=MX thì Value là tên chính tắc của máy chủ thư có tên trạm bí danh Name. Ví dụ (foo.com, mail.bar.foo.com, MX) là bản ghi MX. Các bản ghi MX cho phép các tên trạm của máy chủ thư có bí danh đơn giản. Chú ý là bằng cách sử dụng bản ghi MX, một công ty có thể có cùng bí danh cho máy chủ thư và một máy chủ khác (như máy chủ Web của nó). Để nhận được tên chính tắc cho máy chủ thư, một máy khách DNS cần truy vấn bản ghi MX; để nhận tên chính tắc cho máy chủ khác, máy khách DNS sẽ phải truy vấn bản ghi CNAME.

Nếu một máy chủ DNS có thẩm quyền cho một tên trạm cụ thể, thì máy chủ DNS này sẽ chứa bản ghi Type A cho tên trạm đó. (Ngay cả khi nếu máy chủ DNS không thẩm quyền, nó vẫn có thể chứa bản ghi Type A trong bộ đệm của nó). Nếu một máy chủ không có thẩm quyền về tên trạm, nó sẽ chứa một bản ghi loại NS cho tên miền chứa tên trạm, nó cũng sẽ có bản ghi Type A cung cấp địa chỉ IP của máy chủ DNS trong trường Value của bản ghi NS. Ví dụ, giả sử là một máy chủ TLD edu không có thẩm quyền cho trạm gaia.cs.umass.edu, ví dụ (umass.edu, dns.umass.edu, NS). Máy chủ TLD edu cũng sẽ chứa bản ghi Type A, ánh xạ máy chủ DNS dns.umass.edu với địa chỉ IP, ví dụ (dns.umass.edu, 128.119.40.111, A).

Chương 4. Dịch vụ tên miền DNS

Bản tin DNS

Lúc trước chúng ta đã đề cập đến các bản tin truy vấn và trả lời DNS. Chúng chỉ là hai loại bản tin của DNS. Hơn nữa, cả bản tin truy vấn và trả lời đều có khuôn dạng chung (hình 4.5). Ngữ nghĩa của các trường trong bản tin DNS như sau:

12 byte đầu tiên là phần tiêu đề (header), bao gồm một số trường. Trường đầu tiên là một số dài 16 bit nhận dạng truy vấn. Định dạng này được sao chép vào bản tin trả lời truy vấn, cho phép máy khách đối chiếu bản tin trả lời nhận được với truy vấn đã gửi đi. Có một số cờ trong trường cờ. Cờ truy vấn/trả lời 1 bit cho biết bản tin là truy vấn (0) hay là trả lời (1). Cờ thẩm quyền 1 bít được thiết lập trong bản tin trả lời khi máy chủ DNS là máy chủ thẩm quyền đối với tên được truy vấn. Một cờ yêu cầu đệ quy 1 bít được thiết lập khi một máy khách (trạm chủ hay máy chủ DNS) mong muốn máy chủ DNS thực hiện đệ quy khi nó không có bản ghi. Trường khả đệ quy 1 bit được thiết lập trong bản tin trả lời nếu máy chủ DNS hỗ trợ đệ quy. Trong tiêu đề này còn có bốn trường số nữa. Những trường này chỉ ra số lần xuất hiện của bốn loại dữ liệu tiếp theo tiêu đề.

Phần câu hỏi (question) chứa thông tin về truy vấn đang được thực hiện. Phần này gồm (1) trường tên chứa tên đang được truy vấn, (2) trường loại chỉ ra loại câu hỏi về tên, ví dụ: một địa chỉ trạm gắn với tên (Type A) hay máy chủ thư đối với tên (Type MX).

Hình Error! No text of specified style in document..21: Khuôn dạng bản tin DNS

Trong một bản tin trả lời từ máy chủ DNS, phần trả lời (answer) chứa bản ghi nguồn cho tên được truy vấn ban đầu. Nhớ là trong mỗi bản ghi nguồn có trường Type (ví dụ: A, NS, CNAME, MX), Value và TTL. Một bản tin trả lời có thể trả về nhiều RRs vì một tên trạm có thể có nhiều địa chỉ IP (ví dụ, với các máy chủ nhân rộng).

4. Phần thẩm quyền (authority) chứa các bản ghi của các máy chủ thẩm quyền khác.

Chương 4. Dịch vụ tên miền DNS

Phần bổ trợ (additional) chứa những bản ghi hỗ trợ khác. Ví dụ, trường trả lời trong bản tin trả lời một truy vấn MX chứa bản ghi nguồn cung cấp tên trạm chính tắc của máy chủ thư. Trường bổ trợ này chứa bản ghi Type A cung cấp địa chỉ IP cho tên trạm chính tắc của máy chủ thư này.

Bạn muốn gửi bản tin yêu cầu DNS trực tiếp từ trạm bạn đang làm việc tới một máy chủ DNS như thế nào? Điều này có thể dễ dàng thực hiện với chương trình nslookup, chương trình này thường có sẵn trên các hệ điều hành Windows và UNIX. Ví dụ, từ một trạm chủ Window, mở Command Promt (nhắc lệnh) và kích hoạt chương trình nslookup bằng cách gõ “nslookup”. Sau khi kích hoạt nslookup, bạn có thể gửi một truy vấn DNS tới bất kỳ máy chủ DNS nào (máy chủ gốc, TLD hoặc thẩm quyền). Sau khi nhận bản tin trả lời từ máy chủ DNS, nslookup sẽ hiển thị bản ghi trong bản tin trả lời (dưới dạng đọc được). Có một giải pháp khác chạy nslookup từ trạm của bạn, là bạn có thể vào một trong nhiều trang Web cho phép bạn triển khai nslookup từ xa. (Chỉ cần gõ nslookup vào một công cụ tìm kiếm và bạn có thể tới được những trang đó).

Chèn bản ghi DNS vào cơ sở dữ liệu DNS

Ở trên chúng ta đã tập trung vào việc làm thế nào để lấy bản ghi từ cơ sở dữ liệu DNS. Bạn có thể tự hỏi là làm thế nào để đưa bản ghi vào cơ sở dữ liệu trong lần đầu tiên. Hãy nhìn vào cách thực hiện điều này từ ví dụ cụ thể. Giả sử bạn vừa tạo lập một công ty mới gọi là Network Utopia. Chắc chắn điều đầu tiên mà bạn muốn làm là đăng ký tên miền networkutopia.com với công ty đăng ký. Một công ty đăng ký là một cơ quan thương mại có nhiệm vụ xác minh tính duy nhất của tên miền, đưa tên miền vào cơ sở dữ liệu DNS và thu phí của bạn cho dịch vụ này. Trước năm 1999, một công ty đăng ký duy nhất là Network Solutions chiếm độc quyền về việc đăng ký tên miền cho tên miền com, net và org. Song ngày nay có nhiều công ty đăng ký cạnh tranh khách hàng, và Công ty ICANN (Internet Corporation for Assigned Names and Numbers - http://www.icann.org/) cũng đã được công nhận là những công ty đăng ký. Danh sách các công ty đăng ký được công nhận có ở trang http://www.internic.net.

Khi bạn đăng ký tên miền networkutopia.com với một công ty đăng ký, bạn cũng cần phải cung cấp cho công ty này tên và địa chỉ IP của máy chủ DNS thẩm quyền sơ cấp và thứ cấp. Giả sử tên và địa chỉ IP đó là dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1 và 212.212.212.2. Với mỗi máy chủ DNS thẩm quyền này, công ty đăng ký sẽ đảm bảo là bản ghi Type NS và Type A được nhập vào máy chủ com TLD. Đặc biệt là với máy chủ thẩm quyền sơ cấp cho networkutopia.com, công ty đăng ký phải chèn hai bản ghi nguồn sau vào hệ thống DNS:

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

Bạn cũng phải đảm bảo là bản tin nguồn Type A cho máy chủ Web của bạn www.networkutopia.com và bản ghi nguồn Type MX cho máy chủ thư của bạn mail.networkutopia.com được nhập vào máy chủ DNS thẩm quyền của bạn. (Mãi cho tới gần đây, nội dung của mỗi máy chủ DNS mới được cấu hình tĩnh, ví dụ từ tệp cấu hình do nhà quản lý hệ

Chương 4. Dịch vụ tên miền DNS

thống tạo ra. Gần đây, tuỳ chọn OPTION mới được bổ sung vào giao thức DNS để cho phép bổ sung hoặc xoá dữ liệu linh động từ cơ sở dữ liệu thông qua các bản tin DNS. RFC2136 và RFC3007 đặc tả việc cập nhật động DNS).

Một khi tất cả các bước trên đã hoàn tất, mọi người mới có thể vào trang Web của bạn và gửi email tới nhân viên công ty bạn. Bây giờ chúng sẽ xác minh tuyên bố này là đúng. Việc xác minh này cũng giúp củng cố điều chúng ta đã học được về DNS. Giả sử là Alice ở Australia muốn xem trang Web www.networkutopia.com. Đầu tiên trạm chủ của cô ấy sẽ gửi truy vấn DNS tới máy chủ DNS cục bộ. Máy chủ DNS cục bộ sẽ kết nối tới máy chủ com TLD. (Máy chủ DNS cục bộ cũng sẽ phải kết nối tới máy chủ DNS gốc nếu địa chỉ của máy chủ com TLD không được đệm). Máy chủ TLD này chứa các bản ghi nguồn Type NS và Type A đưa ra trên, bởi vì công ty đăng ký đã có bản ghi nguồn này chèn vào tất cả máy chủ com TLD. Máy chủ com TLD gửi trả lời tới máy chủ DNS cục bộ của Alice, trong bản tin trả lời có chứa hai bản ghi nguồn. Sau đó máy chủ DNS cục bộ gửi một truy vấn DNS tới 212.212.212.1, yêu cầu bản ghi Type A tương ứng với www.netorkutopia.com. Bản ghi này cung cấp địa chỉ IP của máy chủ Web yêu cầu, là 212.212.71.4, máy chủ DNS cục bộ chuyển ngược bản ghi này về máy trạm của Alice. Bây giờ trình duyệt của Alice có thể khởi tạo kết nối TCP tới trạm 212.212.71.4 và gửi yêu cầu HTTP trên kết nối này.

Điểm yếu an toàn DNS

Chúng ta đã thấy là DNS là thành phần quan trọng trong cơ sở hạ tầng Internet với nhiều dịch vụ quan trọng, như Web và email sẽ không thể thực hiện được nếu thiếu nó. Vì vậy, chúng ta thường hỏi DNS có thể bị tấn công như thế nào? Nếu DNS bị tấn công và không cung cấp dịch vụ, thì hầu hết các ứng dụng Internet cũng bị loại bỏ cùng với nó.

Kiểu tấn công đầu tiên đó là tấn công tràn ngập băng thông DDoS (từ chối dịch vụ) chống lại các máy chủ DNS. Ví dụ, một kẻ tấn công có thể cố gửi vào từng máy chủ gốc DNS một lượng lớn gói tin làm tràn lụt máy chủ, rất nhiều hoặc hầu hết các truy vấn DNS hợp pháp không bao giờ được trả lời. Cuộc tấn công DDoS quy mô lớn như vậy chống lại các máy chủ gốc DNS thực sự xảy ra vào ngày 21 tháng 10 năm 2002. Trong vụ tấn công này, những kẻ tấn công tận dụng mạng ma (bonet) gửi những lượng bản tin ICMP khổng lồ vào toàn bộ 13 máy chủ gốc DNS. Thật may là vụ tấn công quy mô lớn này chỉ gây thiệt hại nhỏ, gần như không ảnh hưởng tới trải nghiệm người dùng Internet. Những kẻ tấn công đã thành công trong việc phát lượng gói tin rất lớn vào các máy chủ gốc. Song rất nhiều máy chủ gốc được bảo vệ bởi các bộ lọc gói, được cấu hình luôn chặn toàn bộ các bản tin ICMP ping trực tiếp vào các máy chủ gốc. Vì vậy, những máy chủ được bảo vệ này vẫn còn rỗi và hoạt động bình thường. Hơn nữa, hầu hết máy chủ DNS cục bộ đệm địa chỉ IP của các máy chủ TLD nên nó vẫn xử lý truy vấn mà không cần phải chuyển qua máy chủ gốc DNS.

Một khả năng tấn công DDoS khác hiệu quả hơn chống lại DNS là gửi lượng truy vấn DNS rất

lớn tới các máy chủ TLD, ví dụ tới tất cả các máy chủ TLD xử lý tên miền .com. Sẽ rất khó lọc những truy vấn DNS trực tiếp tới máy chủ DNS, và các máy chủ TLD thường không dễ dàng chuyển qua như máy chủ gốc. Song mức độ nghiêm trọng của những kiểu tấn công này thường được giảm nhẹ phần nào do việc đệm ở các máy chủ DNS cục bộ.

Chương 4. Dịch vụ tên miền DNS

DNS cũng có thể bị tấn công theo nhiều cách khác. Trong kiểu tấn công người trung gian

(man-in-the-middle), kẻ tấn công chặn truy vấn từ các trạm và trả về bản tin trả lời giả. Trong kiểu tấn công đầu độc, kẻ tấn công gửi trả lời giả (không có thật) tới máy chủ DNS, lừa máy chủ nhập bản ghi giả vào bộ lưu đệm của nó. Cho dù là kiểu tấn công nào thì cũng là để chuyển hướng người sử dụng trang Web không đề phòng tới trang Web của kẻ tấn công. Tuy nhiên, những kiểu tấn công này khó thực hiện vì chúng đòi hỏi đánh chặn các gói tin hoặc điều chỉnh máy chủ.

Một kiểu tấn công quan trọng khác là không tấn công vào dịch vụ DNS mà lại khai thác cơ sở

hạ tầng DNS để khởi động tấn công DDoS chống lại trạm chủ mục tiêu (ví dụ như máy chủ thư của trường bạn). Trong kiểu tấn công này, kẻ tấn công gửi truy vấn DNS tới rất nhiều máy chủ DNS thẩm quyền, mỗi truy vấn có địa chỉ nguồn giả của máy trạm mục tiêu. Các máy chủ DNS sẽ gửi trả lời trực tiếp tới trạm mục tiêu đó. Nếu những truy vấn này được gia công bằng cách nào đó sao cho đáp ứng có kích thước lớn hơn nhiều (lượng byte) so với bản tin truy vấn (gọi là khuyếch đại), thì kẻ tấn công có thể tràn ngập mục tiêu mà không phải tự tạo ra nhiều lưu lượng. Những kiểu tấn công phản hồi khai thác DNS kiểu này ít thành công cho tới nay.

Tóm lại, DNS đã tự chứng minh sức mạnh đáng kinh ngạc chống lại những cuộc tấn công. Ngày nay, chưa có kiểu tấn công nào cản trở thành công dịch vụ DNS. Có nhiều kẻ tấn công phản hồi thành công, tuy nhiên những cuộc tấn công này có thể (và đang) được giải quyết bằng cấu hình tương ứng của các máy chủ DNS.

Chương 5. Các ứng dụng ngang hàng (P2P)

CÁC ỨNG DỤNG NGANG HÀNG (P2P)

Equation Section (Next) Các ứng dụng được mô tả trong các chương trên - bao gồm Web, thư điện tử, và DNS - tất cả đều sử dụng kiến trúc client-server dựa vào các máy chủ hạ tầng luôn luôn sẵn sàng. Mô hình client-server có rất nhiều ưu điểm như: mọi xử lý tập trung tại máy chủ do đó tránh được các tính toán nặng nề cho máy khách, hoặc do tất cả dữ liệu tập trung tại một vị trí nên dễ dàng quản lý hệ thống và đảm bảo an toàn. Tuy nhiên khi Internet phát triển với tốc độ chóng mặt như ngày nay thì mô hình client-server cũng có một số vấn đề cần xem xét: số lượng máy khách tăng thì nhu cầu về tải, băng thông tăng lên và máy chủ có thể không có khả năng để cung cấp dịch vụ và mở rộng. Mô hình P2P được xem như một giải pháp khắc phục nhược điểm này của mô hình client- server.

Một mạng ngang hàng không có khái niệm máy chủ và máy khách, tất cả các máy tham gia đều bình đẳng và được gọi là nút, đóng vai trò của cả máy chủ và máy khách đối với các máy khác trong mạng. Trong kiến trúc P2P, chỉ dựa vào rất ít (hoặc không dựa vào) các máy chủ hạ tầng luôn luôn sẵn sàng. Thay vào đó, các cặp máy chủ kết nối không liên tục, gọi là các thiết bị ngang hàng (peer), truyền thông trực tiếp với nhau. Các thiết bị ngang hàng không thuộc sở hữu của các nhà cung cấp dịch vụ, mà đơn giản là các máy tính được người sử dụng kiểm soát. Mạng ngang hàng về bản chất là các hệ thống phân tán, không có sự phân cấp hay điều khiển tập trung nào. Các thiết bị ngang hàng tự tổ chức ra các mạng logic, xếp chồng lên trên mạng Internet, kết hợp các tính năng khác nhau như: khả năng định tuyến trên diện rộng, tìm kiếm dữ liệu hiệu quả, lựa chọn các nút gần, tin cậy và bảo mật, khả năng mở rộng và chịu lỗi.

Trong chương này chúng ta sẽ xem xét các ứng dụng khác nhau đặc biệt thích hợp với thiết kế P2P. Ứng dụng đầu tiên là phân bố tệp, trong đó ứng dụng phân bố tệp từ một nguồn đơn tới một số lượng lớn các thiết bị ngang hàng. Phân bố tệp là một ứng dụng điển hình để bắt đầu tìm hiểu kiến trúc P2P, do nó trình bày rất rõ ràng khả năng tự mở rộng qui mô của kiến trúc P2P. Trong chương này chúng ta cũng mô tả một ví dụ điển hình của ứng dụng phân bố tệp là hệ thống thông dụng BitTorrent. Ứng dụng thứ hai của P2P chúng ta sẽ xem xét là cơ sở dữ liệu được phân tán trên cộng đồng các thiết bị ngang hàng. Đối với ứng dụng này, chúng ta sẽ tìm hiểu khái niệm Bảng hàm băm DHT (Distributed Hash Table). Cuối cùng, chúng ta xem xét ứng dụng thứ ba là một ứng dụng thoại Internet P2P, ví dụ như Skype, đã có những thành công rất lớn trong ứng dụng thực tế.

Cấu trúc mạng ngang hàng

Cấu trúc mạng ngang hàng bao gồm tất cả các nút mạng đại diện cho các thiết bị ngang hàng và các liên kết giữa các nút mạng này. Một liên kết tồn tại giữa hai nút mạng khi một nút mạng biết vị trí của nút mạng kia. Dựa vào cấu trúc liên kết giữa các nút mạng có thể phân loại mạng ngang hàng thành hai loại: mạng không cấu trúc và mạng có cấu trúc.

Mạng ngang hàng không cấu trúc là một mạng trong đó các nút chỉ liên kết với các nút lân cận khi gửi bản tin tới các nút khác trong mạng ngang hàng, tức là các liên kết được thiết ;ập ngẫu nhiên, không theo qui luật nào. Mạng như vậy dễ dàng được xây dựng vì một thiết bị ngang hàng mới muốn

Chương 5. Các ứng dụng ngang hàng (P2P)

tham gia mạng có thể lấy các liên kết có sẵn của một thiết bị khác đang ở trong mạng và sau đó dần dần tự bản thân sẽ thêm các liên kết mới của riêng mình. Khi một thiết bị ngang hàng muốn tìm dữ liệu trong mạng ngang hàng không cấu trúc, yêu cầu tìm kiếm sẽ được truyền trên toàn bộ mạng để tìm càng nhiều thiết bị chia sẻ càng tốt. Kỹ thuật tìm kiếm chủ yếu là sử dụng tràn lụt (flooding) và các giải thuật tìm kiếm ưu tiên theo chiều rộng (breadth-first), hoặc ưu tiên theo chiều sâu (depth- first) cho đến khi nội dung được tìm thấy. Ngoài ra còn có một số kỹ thuật phức tạp khác như bước nhảy ngẫu nhiên (random walk) và chỉ số định tuyến (routing indices).

Hệ thống không cấu trúc thể hiện rõ nhược điểm: không có gì đảm bảo tìm kiếm sẽ thành công. Đối với việc tìm kiếm dữ liệu chia sẻ trên nhiều thiết bị tỉ lệ thành công là khá cao, nhưng ngược lại nếu dữ liệu chia sẻ trên một vài thiết bị thì tỉ lệ tìm được là khá nhỏ. Tính chất này là hiển nhiên vì trong mạng P2P không cấu trúc không có bất kì mối tương quan nào giữa một thiết bị và dữ liệu mà nó quản lý trong mạng, do đó yêu cầu tìm kiếm được chuyển một cách ngẫu nhiên đến một số thiết bị trong mạng. Số lượng thiết bị trong mạng càng lớn thì khả năng tìm thấy thông tin càng nhỏ. Một nhược điểm khác nữa của hệ thống không cấu trúc là do không có định hướng, một yêu cầu tìm kiếm thường được chuyển cho một số lượng lớn thiết bị ngang hàng làm tiêu tốn một lượng lớn băng thông, dẫn đến hiệu quả tìm kiếm chung của mạng là thấp. Một nhược điểm nữa là khả năng mở rộng mạng thường bị hạn chế bởi các kỹ thuật sử dụng xây dựng mạng, ví dụ kỹ thuật tràn lụt thường dẫn đến tăng lưu lượng khi mở rộng mạng. Các hệ thống không cấu trúc thường chỉ phù hợp trong các trường hợp các thiết bị ngang hàng ra vào mạng thường xuyên, tùy ý.

Mạng ngang hàng có cấu trúc là một mạng P2P trong đó các nút mạng duy trì thông tin định tuyến để tìm ra tất cả các nút trong mạng. Mạng P2P có cấu trúc giới hạn được số lượng bản tin cần thiết để tìm kiếm bất cứ đối tượng nào trong mạng. Điều này rất quan trọng khi tìm kiếm các đối tượng ít phổ biến hay ít xuất hiện.

Trong hệ thống có cấu trúc cung cấp sự liên kết (mapping) giữa nội dung (ví dụ ID của tệp) và vị trí (ví dụ địa chỉ nút). Liên kết này thường dựa trên một cấu trúc dữ liệu bảng hàm băm phân tán DHT. Do đó, đa số mạng có cấu trúc hỗ trợ tính năng DHT, định tuyến dựa trên từ khóa (key). Mỗi nút mạng có một DHT, được sử dụng cho các thuật toán chuyển tiếp.

Bảng định tuyến của các nút được tạo ra khi nút tham gia vào mạng P2P nhờ sử dụng một thủ tục khởi tạo đặc biệt. Các nút thường trao đổi thông tin trong bảng định tuyến như một phần của quá trình duy trì mạng ngang hàng. Các tệp trong mạng được ràng buộc với các khóa - ví dụ được tạo ra bằng cách băm các tên tệp và mỗi nút trong hệ thống có trách nhiệm lưu giữ một dải các khóa nào đó. Trong mạng có cấu trúc, tôpô mạng được kiểm soát chặt chẽ, khả năng mở rộng mạng được nâng cao rõ rệt. Tuy nhiên việc quản lý tôpô mạng thường gặp khó khăn khi tỉ lệ gia nhập/ rời mạng của các nút cao. Mô hình có cấu trúc thường đem lại hiệu quả tìm kiếm cao, phù hợp với mạng có qui mô lớn.

Phân bố tệp P2P

Chúng ta bắt đầu khám phá P2P bằng cách xem xét một ứng dụng rất tự nhiên, là phân bố tệp rất lớn từ một trạm chủ đơn tới một số các trạm chủ (gọi là các thiết bị ngang hàng). Tệp này có thể là phiên bản mới của hệ điều hành Linux, tệp âm nhạc MP3, hay tệp video MPEG. Trong kiến trúc phân bố tệp

Chương 5. Các ứng dụng ngang hàng (P2P)

client-server, máy chủ phải gửi bản sao của tệp tới từng thiết bị ngang hàng, áp đặt một tải trọng khổng lồ lên máy chủ và tiêu tốn lượng băng thông máy chủ rất lớn. Trong phân bố tệp ngang hàng, mỗi thiết bị ngang hàng có thể phân bố lại bất cứ lượng tệp nào mà nó nhận được tới bất cứ thiết bị ngang hàng khác, do đó hỗ trợ máy chủ trong quá trình phân bố. Giao thức phân bố tệp P2P thông dụng nhất là BitTorent. Giao thức này ban đầu được Bram Cohen phát triển, và hiện nay nhiều máy khách BitTorent độc lập khác nhau đã thích ứng với giao thức BitTorent, cũng tương tự như các máy khách của trình duyệt Web thích ứng với giao thức HTTP. Chúng ta sẽ xem xét khả năng tự mở rộng qui mô của kiến trúc P2P trong ngữ cảnh phân bố tệp. Phần này cũng sẽ mô tả BitTorrent chi tiết hơn, và nhấn mạnh các đặc tính và đặc điểm quan trọng của nó.

Kiến trúc P2P

Để so sánh kiến trúc máy khách- máy chủ và kiến trúc ngang hàng và minh họa khả năng tự mở rộng qui mô của P2P, chúng ta xem xét mô hình định lượng đơn giản nhằm phân bố tệp tới một tập cố định các thiết bị ngang hàng cho cả hai kiến trúc. Trên hình 5.1 máy chủ và các thiết bị ngang hàng được kết nối tới Internet thông qua các liên kết truy nhập. Biểu diễn tốc độ tải lên của liên kết truy nhập máy chủ là 𝑢𝑠, tốc độ tải lên của liên kết truy nhập thiết bị ngang hàng thứ i là 𝑢𝑖, và tốc độ tải xuống của liên kết truy nhập thiết bị ngang hàng thứ i là 𝑑𝑖. Chúng ta cũng ký hiệu kích cỡ của tệp được phân bố (tính bằng bit) là F và số lượng thiết bị ngang hàng muốn nhận được bản sao của tệp là N. Thời gian phân bố là thời gian thực hiện lấy được bản sao của tệp đối với tất cả N thiết bị ngang hàng. Trong phân tích thời gian phân bố dưới đây, đối với cả hai kiến trúc client-server và P2P, chúng ta sẽ đơn giản hóa (tuy nhiên vẫn chính xác) bằng giả thiết rằng lõi Internet có dư thừa băng thông, sao cho tất cả nghẽn cổ chai chỉ xảy ra tại phần truy nhập mạng. Chúng ta cũng giả sử rằng máy chủ và máy khách không tham gia vào bất cứ ứng dụng khác nào, để cho tất cả băng thông truy nhập đường lên và đường xuống của họ có thể hoàn toàn dành riêng cho việc phân bố tệp.

Hình Error! No text of specified style in document..22: Minh họa phân bố tệp

Chương 5. Các ứng dụng ngang hàng (P2P)

Đầu tiên chúng ta xác định thời gian phân bố cho kiến trúc client-server, được biểu diễn bằng 𝐷𝑐𝑠. Trong kiến trúc client-server, không có thiết bị ngang hàng nào hỗ trợ phân bố tệp. Chúng ta có các quan sát sau:

Máy chủ phải truyền một bản sao của tệp tới tất cả N thiết bị ngang hàng. Do đó, máy chủ phải truyền NF bits. Do tốc độ tải lên của máy chủ là 𝑢𝑠, thời gian phân bố tệp phải ít nhất là NF/𝑢𝑠.

Ký hiệu 𝑑𝑚𝑖𝑛 là tốc độ tải xuống thấp nhất của thiết bị ngang hàng, tức là 𝑑𝑚𝑖𝑛 = min⁡(𝑑1, 𝑑2, … , 𝑑𝑁). Thiết bị ngang hàng với tốc độ tải xuống thấp nhất không thể nhận được tất cả F bit của tệp trong khoảng thời gian nhỏ hơn 𝐹/𝑑𝑚𝑖𝑛 giây. Vì vậy thời gian phân bố tối thiểu là 𝐹/𝑑𝑚𝑖𝑛 giây.

Kết hợp hai quan sát trên, chúng ta có

, 𝐷𝑐𝑠 ≥ max 𝑁𝐹 𝑢𝑠 𝐹 𝑑𝑚𝑖𝑛

Đây chính là giới hạn dưới của thời gian phân bố tối thiểu đối với kiến trúc client-server. Máy chủ có thể lập lịch truyền dẫn của nó để đạt được giới hạn này. Do đó có thể lấy giới hạn này như là thời gian phân bố tệp thực tế, tức là

𝑁𝐹 𝑢 𝑠

𝐹 𝑑𝑚𝑖𝑛

, (5.1) 𝐷𝑐𝑠 = max

Chúng ta thấy từ phương trình (5.1) nếu N đủ lớn, thời gian phân bố tệp client-server được xác định bằng NF/𝑢𝑠. Do đó, thời gian phân bố tăng tuyến tính với số lượng thiết bị ngang hàng N. Ví dụ, nếu số lượng thiết bị ngang hàng từ tuần này sang tuần sau tăng một nghìn lần, từ một nghìn lên một triệu, thì thời gian yêu cầu để phân bố tệp cho tất cả các thiết bị ngang hàng tăng 1000 lần.

Bây giờ chúng ta sẽ thực hiện phân tích tương tự cho kiến trúc P2P, mà mỗi thiết bị ngang hàng có thể hỗ trợ máy chủ trong quá trình phân bố tệp. Cụ thể, khi thiết bị ngang hàng nhận một số dữ liệu tệp nào đó, nó có thể sử dụng dung lượng tải lên của bản thân nó để phân bố lại dữ liệu cho các thiết bị ngang hàng khác. Tính toán thời gian phân bố cho kiến trúc P2P phức tạp hơn so với kiến trúc client-server, do thời gian phân bố phụ thuộc vào từng thiết bị ngang hàng phân bố một phần tệp cho các thiết bị ngang hàng khác như thế nào. Tuy nhiên, có thể nhận được một biểu diễn đơn giản cho thời gian phân bố tối thiểu như sau đây. Trước hết chúng ta thực hiện các quan sát sau:

Tại thời điểm bắt đầu phân bố, chỉ có máy chủ có tệp. Để lấy tệp này cho cộng đồng thiết bị ngang hàng, máy chủ phải gửi từng bit của tệp ít nhất một lần ra liên kết truy nhập. Do đó, thời gian phân bố tệp phải ít nhất là F/𝑢𝑠. (Khác với mô hình client-server, mỗi bit được máy chủ gửi một lần có thể không được máy chủ gửi lại nữa, do các thiết bị ngang hàng có thể phân bố lại các bit giữa chúng với nhau).

Như với kiến trúc client-server, thiết bị ngang hàng với tốc độ tải xuống thấp nhất không thể nhận được tất cả F bít của tệp trong khoảng thời gian nhỏ hơn 𝐹/𝑑𝑚𝑖𝑛 giây. Vì vậy thời gian phân bố tối thiểu là 𝐹/𝑑𝑚𝑖𝑛 giây.

Chương 5. Các ứng dụng ngang hàng (P2P)

Cuối cùng, nhận thấy rằng tổng số dung lượng tải lên của hệ thống tổng thể bằng tốc độ tải lên của máy chủ cộng với các tốc độ tải lên của từng thiết bị ngang hàng riêng rẽ, có nghĩa là, 𝑢𝑡𝑜𝑡𝑎𝑙 = 𝑢𝑠 + 𝑢1 + 𝑢2 + ⋯ + 𝑢𝑁. Hệ thống phải phân phát (tải lên) F bit tới từng thiết bị trong N thiết bị ngang hàng, vì vậy nó phân phát tổng cộng NF bit. Việc này không thể thực hiện tại tốc độ cao hơn 𝑢𝑡𝑜𝑡𝑎𝑙 . Do đó, thời gian phân bố tối thiểu cũng ít nhất là 𝑁𝐹/(𝑢𝑠 + 𝑢1 + 𝑢2 + ⋯ + 𝑢𝑁).

Kết hợp các quan sát trên, chúng ta nhận được thời gian phân bố tối thiểu đối với P2P, được ký hiệu là 𝐷𝑃2𝑃.

𝐹 𝑢 𝑠

𝐹 𝑑𝑚𝑖𝑛

𝑢 𝑖

𝑁𝐹 𝑁 𝑢 𝑠+ 𝑖=1

, , (5.2) 𝐷𝑃2𝑃 ≥ max

Phương trình (5.2) đưa ra giới hạn dưới của thời gian phân bố tối thiểu đối với kiến trúc P2P. Nếu chúng ta hình dung mỗi thiết bị ngang hàng có thể phân bố lại các bit ngay khi nó nhận được, thì sẽ tồn tại mô hình phân bố thực sự đạt đến giá trị giới hạn dưới này. Trên thực tế, thường là khúc dữ liệu của tệp được phân bố lại chứ không phải từng bit, phương trình (5.2) là một ước lượng tốt đối với thời gian phân bố tối thiểu thực tế. Do đó, lấy giới hạn dưới của phương trình (5.2) cho thời gian phân bố tối thiểu như sau

𝐹 𝑢 𝑠

𝐹 𝑑𝑚𝑖𝑛

𝑢 𝑖

𝑁𝐹 𝑁 𝑢 𝑠+ 𝑖=1

, , (5.3) 𝐷𝑃2𝑃 = max

Hình 5.2 so sánh thời gian phân bố tối thiểu cho kiến trúc client-server và P2P với giả thiết rằng tất cả các thiết bị ngang hàng có cùng tốc độ tải lên 𝑢. Trong hình 5.2 chúng ta có F/u=1 giờ, 𝑢𝑠 = 10𝑢, và 𝑑𝑚𝑖𝑛 ≥ 𝑢𝑠. Do đó, thiết bị ngang hàng có thể truyền toàn bộ tệp trong 1 giờ, tốc độ truyền dẫn của máy chủ gấp 10 lần tốc độ tải lên của thiết bị ngang hàng và (để đơn giản) tốc độ tải xuống của thiết bị ngang hàng được thiết lập đủ lớn để không bị ảnh hưởng. Chúng ta thấy từ Hình 5.2 đối với kiến trúc client-server, thời gian phân bố tăng tuyến tính và không giới hạn khi số lượng thiết bị ngang hàng tăng lên. Tuy nhiên, đối với kiến trúc P2P, thời gian phân bố tối thiểu không chỉ bao giờ cũng nhỏ hơn thời gian phân bố đối với kiến trúc client-server; mà nó cũng nhỏ hơn 1 giờ cho bất cứ số lượng thiết bị ngang hàng N nào. Do đó, ứng dụng với kiến trúc P2P có thể tự mở rộng. Khả năng mở rộng qui mô này là hệ quả trực tiếp của các thiết bị ngang hàng trở thành thiết bị phân bố cũng như tiêu thụ thông tin (bit).

Chương 5. Các ứng dụng ngang hàng (P2P)

Hình Error! No text of specified style in document..23: Thời gian phân bố đối với kiến trúc P2P và client-server

Bit Torent

BitTorent là giao thức P2P thông dụng để phân bố tệp. Theo ngôn ngữ chuyên môn BitTorent, tập hợp tất cả các thiết bị ngang hàng tham gia phân bố một tệp cụ thể được gọi là torrent (dòng chảy). Các thiết bị trong torrent tải xuống các khúc dữ liệu kích cỡ bằng nhau của tệp từ một thiết bị khác, với kích thước khúc dữ liệu điển hình là 256 Kbyte. Khi thiết bị ngang hàng tham gia vào torrent lần đầu, nó không có khúc dữ liệu nào. Theo thời gian nó dần dần thu thập nhiều hơn và nhiều hơn các khúc dữ liệu. Trong khi tải xuống các khúc dữ liệu, nó cũng tải lên các khúc dữ liệu đến các thiết bị ngang hàng khác. Một khi thiết bị ngang hàng đã nhận được toàn bộ tệp, nó có thể (tự bản thân) rời bỏ torrent, hoặc vẫn ở lại trong torrent và tiếp tục tải lên các khúc dữ liệu tới các thiết bị ngang hàng khác. Hơn nữa, bất kì thiết bị ngang hàng nào có thể rời bỏ torrent tại bất kì thời điểm nào với một tập khúc dữ liệu, và sau đó lại gia nhập torrent.

Bây giờ chúng ta sẽ xem xét kĩ hơn các hoạt động của BitTorrent. Do BitTorrent là một giao thức và hệ thống phức tạp, chúng ta sẽ chỉ mô tả các cơ cấu quan trọng nhất của nó, và chỉ xem xét chi tiết một số cơ cấu; điều này sẽ cho phép chúng ta nắm bắt được vấn đề một cách tổng thể. Mỗi torrent có một nút hạ tầng gọi là bộ theo dõi (tracker). Khi thiết bị ngang hàng gia nhập torrent, nó tự đăng kí với bộ theo dõi và định kì thông báo với bộ theo dõi nó vẫn còn trong torrent. Bằng cách này, bộ theo dõi duy trì giám sát các thiết bị ngang hàng đang tham gia vào torrent. Một torrent cho trước có thể có ít hơn 10 hay nhiều hơn 1000 thiết bị ngang hàng tại bất cứ thời điểm nào.

Trong hình 5.3, khi thiết bị ngang hàng mới Alice gia nhập torrent, bộ theo dõi lựa chọn ngẫu nhiên một tập nhỏ các thiết bị ngang hàng (giả thiết cụ thể là 50) từ tập các thiết bị ngang hàng đang tham gia, và gửi địa chỉ IP của 50 thiết bị ngang hàng này cho Alice. Có danh sách các thiết bị ngang hàng

Chương 5. Các ứng dụng ngang hàng (P2P)

này, Alice thử thiết lập đồng thời các kết nối TCP với tất cả thiết bị ngang hàng trong danh sách. Gọi tất cả các thiết bị ngang hàng thiết lập kết nối TCP thành công với Alice là “thiết bị ngang hàng lân cận” (neighboring peers). (Trong hình 5.3 Alice chỉ có 3 thiết bị ngang hàng lân cận. Thông thường, số lượng thiết bị ngang hàng lân cận phải có nhiều hơn). Theo thời gian, một số thiết bị ngang hàng này có thể rời bỏ và các thiết bị ngang hàng khác (ngoài 50 thiết bị ban đầu) có thể thử thiết lập kết nối TCP với Alice. Như vậy thiết bị ngang hàng lân cận sẽ thay đổi theo thời gian.

Hình Error! No text of specified style in document..24: Phân bố tệp với BitTorrent

Tại bất cứ thời gian cho trước nào, mỗi thiết bị ngang hàng sẽ có một tập nhỏ các khúc dữ liệu của tệp, và các thiết bị ngang hàng khác nhau sẽ có các tập nhỏ khác nhau. Định kì theo thời gian, Alice sẽ hỏi các thiết bị lân cận (thông qua kết nối TCP) danh sách các khúc dữ liệu mà họ có. Nếu Alice có L lân cận khác nhau, nó sẽ nhận được L danh sách các khúc dữ liệu. Với nhận biết này, Alice sẽ đưa ra yêu cầu (thông qua kết nối TCP) đối với các khúc dữ liệu hiện thời nó chưa có.

Tại bất cứ thời điểm cho trước nào, mỗi thiết bị ngang hàng sẽ có một tập nhỏ các khúc dữ liệu và sẽ biết khúc dữ liệu nào lân cận (neighbor) của nó đang có. Với thông tin này, Alice sẽ có phải đưa ra hai quyết định quan trọng. Thứ nhất, khúc dữ liệu nào nó phải yêu cầu đầu tiên từ các lân cận của nó? Và thứ hai, nó phải gửi yêu cầu về khúc dữ liệu đến lân cận nào? Để quyết định yêu cầu khúc dữ liệu nào, Alice sử dụng kỹ thuật được gọi là đầu tiên là hiếm nhất (rarest first). Ý tưởng của nó là xác định khúc dữ liệu, trong số các khúc dữ liệu nó chưa có, đang có ít nhất từ các lân cận của nó (nghĩa là, các khúc dữ liệu có ít bản sao nhất trong các lận cận) và sau đó yêu cầu các khúc dữ liệu hiếm nhất trước tiên. Bằng cách này, các khúc dữ liệu hiếm nhất được phân bố lại nhanh hơn, dẫn đến (tương đối) cân bằng số lượng các bản sao của từng khúc dữ liệu trong torrent.

Để xác định Alice đáp ứng yêu cầu nào, BitTorrent sử dụng giải thuật giao dịch khôn khéo. Ý tưởng cơ bản là Alice đưa ta mức ưu tiên cho các lân cận hiện tại đang cung cấp dữ liệu cho nó với tốc độ cao

Chương 5. Các ứng dụng ngang hàng (P2P)

nhất. Cụ thể, đối với các lân cận của cô ta, Alice liên tục đo tốc độ nó nhận dữ liệu (bit) và xác định bốn thiết bị ngang hàng cung cấp bit với tốc độ cao nhất. Sau đó nó đáp lại bằng cách gửi các khúc dữ liệu tới bốn thiết bị ngang hàng này. Mỗi 10 giây, nó tính toán lại tốc độ và có thể thay đổi tập bốn thiết bị ngang hàng. Trong ngôn ngữ BitTorrent, bốn thiết bị ngang hàng này được gọi là mở (unchoked). Một điểm quan trọng nữa là cứ mỗi 30 giây, nó cũng chọn ngẫu nhiên một lân cận bổ sung và gửi khúc dữ liệu. Giả sử thiết bị ngang hàng được chọn ngẫu nhiên là Bob. Trong ngôn ngữ BitTorrent, Bob được gọi là được mở khả quan (optimistically unchoked). Vì rằng Alice gửi dữ liệu cho Bob, cô ấy có thể trở thành một trong bốn người tải lên đứng đầu của Bob, trong trường hợp này Bob có thể bắt đầu gửi dữ liệu cho Alice. Nếu tốc độ dữ liệu Bob gửi cho Alice đủ cao, đến lượt Bob sau đó có thể trở thành một trong bốn người tải lên đứng đầu của Alice. Nói một cách khác, cứ mỗi 30 giây, Alice sẽ chọn ngẫu nhiên một đối tác giao dịch mới và khởi tạo giao dịch với đối tác này. Nếu hai thiết bị khách hàng cùng thỏa mãn với giao dịch, chúng sẽ đưa nhau lên danh sách bốn người đứng đầu và tiếp tục giao dịch với nhau cho đến khi một bên tìm thấy đối tác khác tốt hơn. Ở đây hiệu quả nhận được là các thiết bị ngang hàng có khả năng tải lên với tốc độ phù hợp tiến đến tìm nhau. Việc lựa chọn lân cận ngẫu nhiên cũng cho phép các thiết bị ngang hàng mới nhận được khúc dữ liệu, do đó nó cũng có khả năng giao dịch. Tất cả các thiết bị ngang hàng khác ngoài năm thiết bị ngang hàng này (bốn thiết bị ngang hàng đứng đầu và một thiết bị thử nghiệm) đều “đóng” (choked), có nghĩa là chúng không nhận bất cứ khúc dữ liệu nào từ Alice. Ngoài ra, BitTorrent còn có một số cơ cấu khác, bao gồm các mảnh (khúc nhỏ), đường ống, lựa chọn ngẫu nhiên đầu tiên, chế độ kết thúc trò chơi, và chống rút ống (anti-snubbing).

Cơ cấu thúc đẩy giao dịch được mô tả trên thường đưa đến “ăn miếng trả miếng”. Các tài liệu chỉ ra rằng có thể tránh được mô hình thúc đẩy này. Tuy nhiên, hệ sinh thái BitTorrent đang rất thành công, với hàng triệu thiết bị ngang hàng hoạt động chia sẻ tệp đồng thời trên hàng trăm hay hàng nghìn torrent. Nếu BitTorrent được thiết kế không cần “ăn miếng trả miếng” (hay biến thể của nó), nhưng các điểm khác hoàn toàn giống như vậy, BitTorrent thậm chí có thể không tồn tại như hiện nay, do phần lớn người sử dụng có thể đã là người ăn theo.

Bảng hàm băm DHT

Thành phần quan trọng của rất nhiều ứng dụng P2P và các ứng dụng phân tán khác là chỉ số (tức là cơ sở dữ liệu đơn giản), hỗ trợ các hoạt động tìm kiếm và cập nhật. Khi các chỉ số này được phân tán, các thiết bị ngang hàng có thể tạo lập lưu đệm nội dung và định tuyến thông minh các truy vấn giữa chúng với nhau. Do đánh chỉ số và tìm kiếm thông tin là thành phần quan trọng trong các hệ thống như vậy, chúng ta sẽ tìm hiểu một kỹ thuật đánh chỉ số và tìm kiếm thông dụng, gọi là Bảng hàm băm phân tán DHT.

Xem xét quá trình xây dựng cơ sở dữ liệu phân tán đơn giản trên số lượng lớn (có thể lên đến hàng triệu) thiết bị ngang hàng hỗ trợ đánh chỉ số và truy vấn. Thông tin được lưu giữ trong cơ sở dữ liệu của chúng ta sẽ bao gồm các cặp (khóa, giá trị). Ví dụ, khóa có thể là số chứng minh thư và các giá trị có thể tương ứng với tên người; trong trường hợp này, cặp khóa-giá trị điển hình là (156-45-7081, Nguyen). Hay khóa có thể là tên nội dung (như tên bộ phim, album, phần mềm), và giá trị có thể là địa chỉ IP tại đó nội dung được lưu trữ; trong trường hợp này ví dụ cặp khóa-giá trị là (God father, 203.17.123.38). Thiết bị ngang hàng truy vấn cơ sở dữ liệu của chúng ta bằng cách cung cấp khóa:

Chương 5. Các ứng dụng ngang hàng (P2P)

nếu có cặp (khóa, giá trị) trong cơ sở dữ liệu phù hợp với khóa, cơ sở dữ liệu trả lại cặp phù hợp cho thiết bị ngang hàng truy vấn.

Như vậy, ví dụ, nếu cơ sở dữ liệu lưu trữ số chứng minh thư và tên người tương ứng, thiết bị ngang hàng có thể truy vấn số chứng minh thư cụ thể, và cơ sở dữ liệu trả lại tên của người có số chứng minh thư này. Các thiết bị ngang hàng cũng có khả năng chèn cặp (khóa, giá trị) vào cơ sở dữ liệu. Một bảng băm (hash table) là một cấu trúc dữ liệu ánh xạ giữa khóa và giá trị, tức là tương ứng với một khóa bảng băm sẽ trả về một giá trị. Để thực hiện việc ánh xạ bảng băm sử dụng hàm băm (hash function) tính toán vị trí lưu giá trị dựa trên khóa. Hàm băm phải đảm bảo: tránh xung đột và dễ dàng thực hiện. Tránh xung đột nghĩa là ánh xạ giữa không gian khóa và không gian địa chỉ phải đều và ngẫu nhiên đến mức có thể, ngoài ra thuật toán băm phải đơn giản, hiệu quả.

Xây dựng một cơ sở dữ liệu như vậy là đơn giản đối với kiến trúc client-server, mà tất cả cặp (khóa, giá trị) được lưu trữ trong một máy chủ trung tâm. Phương án tập trung cũng đã được thực thi trong hệ thống P2P trước kia như Napster. Nhưng vấn đề trở nên thách thức hơn và thú vị hơn nhiều trong hệ thống phân tán bao gồm từ hàng triệu thiết bị ngang hàng kết nối với nhau không có ủy quyền trung tâm. Trong hệ thống P2P, chúng ta muốn phân tán cặp (khóa, giá trị) thông qua tất cả các thiết bị ngang hàng. Sao cho mỗi thiết bị ngang hàng chỉ giữ một tập nhỏ của tổng số các cặp (khóa, giá trị). Một phương án đơn giản xây dựng cơ sở dữ liệu P2P như vậy là (1) rải ngẫu nhiên các cặp (khóa, giá trị) đến các thiết bị ngang hàng và (2) từng thiết bị ngang hàng bảo quản danh sách địa chỉ IP của tất cả các thiết bị ngang hàng tham gia. Bằng cách này, thiết bị ngang hàng truy vấn có thể gửi truy vấn tới tất cả các thiết bị ngang hàng khác, và thiết bị ngang hàng chứa cặp (khóa, giá trị) phù hợp với khóa có thể đáp ứng với cặp phù hợp của chúng. Tất nhiên do tính qui mô mạng, phương pháp này hoàn toàn không thể thực hiện được vì nó có thể yêu cầu mỗi thiết bị ngang hàng phải theo dõi tất cả các thiết bị ngang hàng khác (có thể hàng triệu) và tồi tệ hơn nữa, mỗi truy vấn được gửi đến tất cả các thiết bị ngang hàng.

Chúng ta sẽ mô tả một phương án thực tế khác để thiết kế cơ sở dữ liệu P2P. Đầu tiên gán một định danh cho mỗi thiết bị ngang hàng, mỗi định danh là một số nguyên trong dải 0, 2𝑛 − 1 với một số n cố định. Để ý rằng mỗi định danh như thế có thể được biểu diễn bằng n-bit. Yêu cầu mỗi khóa là một số nguyên trong dải này. Chúng ta có thể quan sát rằng các khóa điển hình mô tả ở trên (số chứng minh thư và tên nội dung) không phải là các số nguyên. Để tạo các số nguyên cho các khóa này, chúng ta sẽ sử dụng hàm băm ánh xạ từng khóa (như số chứng minh thư) tới số nguyên trong dải 0, 2𝑛 − 1 . Hàm băm là hàm nhiều-đến-một (many-to-one) mà hai đầu vào khác nhau có thể có cùng một đầu ra (cùng một số nguyên), nhưng khả năng có cùng một đầu ra là vô cùng nhỏ. Hàm băm được giả thiết là sẵn sàng công khai cho tất cả các thiết bị ngang hàng trong hệ thống. Từ giờ trở về sau, khi chúng ta đề cập đến “khóa”, chúng ta đề cập đến băm của khóa nguyên bản. Như vậy, ví dụ, nếu khóa nguyên bản là “God father”, khóa sẽ là số nguyên bằng băm của “God father”. Cũng vậy, do chúng ta sử dụng băm của khóa, thay cho bản thân khóa, chúng ta từ giờ sẽ đề cập đến cơ sở dữ liệu phân tán như là bảng hàm băm phân tán DHT.

Bây giờ chúng ta sẽ xem xét vấn đề lưu trữ cặp (khóa, giá trị) trong DHT. Vấn đề trọng tâm ở đây là xác định qui luật gán khóa cho thiết bị ngang hàng. Giả định mỗi thiết bị ngang hàng có một định danh số nguyên và mỗi khóa cũng là một số nguyên trên cùng một dải, giải pháp tự nhiên là gán mỗi

Chương 5. Các ứng dụng ngang hàng (P2P)

cặp (khóa, giá trị) tới thiết bị ngang hàng có định danh gần khóa nhất. Để thực thi phương án này, chúng ta sẽ cần định nghĩa “gần nhất” có nghĩa là gì, ở đây có thể có rất nhiều quy ước. Để thuận tiện, định nghĩa thiết bị ngang hàng gần nhất như thiết bị ngay sau của khóa. Để hiểu sâu hơn, chúng ta cùng lấy một ví dụ. Giả sử 𝑛 = 4 sao cho tất cả thiết bị ngang hàng và định danh khóa trong dải 0,15 . Tiếp tục giả sử có tám thiết bị ngang hàng trong hệ thống có định danh 1, 3, 4, 8, 10, 12, và 15. Cuối cùng, giả sử chúng ta muốn lưu trữ cặp khóa-giá trị (11, Nguyen) vào trong một từ tám thiết bị ngang hàng. Nhưng trong thiết bị ngang hàng nào? Sử dụng quy ước “gần nhất”, do thiết bị ngang hàng 12 là thiết bị ngay sau đối với khóa 11, do đó chúng ta lưu trữ cặp (11, Nguyen) trong thiết bị ngang hàng 12. Để hoàn thiện định nghĩa của chúng ta về “gần nhất”, nếu khóa bằng chính xác một định danh thiết bị ngang hàng, chúng ta sẽ lưu trữ cặp (khóa, giá trị) trong thiết bị ngang hàng trùng lặp đó; và nếu khóa lớn hơn tất cả định danh thiết bị ngang hàng, chúng ta sử dụng quy ước modulo- 2𝑛 , lưu trữ cặp (khóa, giá trị) trong thiết bị ngang hàng với định danh nhỏ nhất.

Giả sử thiết bị ngang hàng, Alice, muốn chèn một cặp (khóa, giá trị) vào DHT. Về mặt quan niệm, điều này là đơn giản: đầu tiên xác định thiết bị ngang hàng mà định danh của nó gần khóa nhất, sau đó gửi bản tin tới thiết bị ngang hàng đó, chỉ dẫn nó lưu trữ cặp (khóa, giá trị). Nhưng Alice xác định thiết bị ngang hàng gần khóa nhất như thế nào? Nếu Alice duy trì theo dõi của tất cả các thiết bị ngang hàng trong hệ thống (ID của thiết bị ngang hàng và địa chỉ IP tương ứng), nó có thể xác định tại chỗ thiết bị ngang hàng gần nhất. Nhưng giải pháp như vậy yêu cầu mỗi thiết bị ngang hàng phải duy trì theo dõi tất cả các thiết bị ngang hàng khác trong DHT – điều này hoàn toàn không thực tế đối với hệ thống qui mô lớn với hàng triệu thiết bị ngang hàng.

DHT vòng

Để giả quyết vấn đề quy mô, chúng ta sẽ xem xét tổ chức các thiết bị ngang hàng thành một vòng. Trong sắp xếp dạng vòng, mỗi thiết bị ngang hàng chỉ duy trì theo dõi thiết bị ngay sau nó (modulo 2𝑛 ). Ví dụ một vòng như vậy được đưa ra trong Hình 5.4 (a). Trong ví dụ này, n bằng 4 và cũng có tám thiết bị ngang hàng như ví dụ trước. Mỗi thiết bị ngang hàng chỉ nhận biết thiết bị ngay sau của nó; ví dụ, thiết bị ngang hàng 5 biết địa chỉ IP và định danh của thiết bị ngang hàng 8 nhưng không cần thiết phải biết về các thiết bị ngang hàng khác có thể có trong DHT. Việc bố trí vòng các thiết bị ngang hàng như vậy là trường hợp đặc biệt của mạng che phủ (overlay network). Trong mạng che phủ, các thiết bị ngang hàng tạo thành mạng logic trừu tượng lưu trú bên trên mạng máy tính “nền” bao gồm từ các liên kết vật lý, bộ định tuyến, và máy chủ. Các liên kết trong mạng che phủ không phải là các liên kết vật lý, mà chỉ đơn giản là các liên kết ảo giữa các cặp thiết bị ngang hàng. Trong mạng che phủ Hình 5.4 (a) có 8 thiết bị ngang hàng và 8 liên kết che phủ; trong mạng che phủ Hình 5.4 (b) có 8 thiết bị ngang hàng và 16 liên kết che phủ. Một liên kết che phủ đơn thường sử dụng nhiều liên kết vật lý và các bộ định tuyến trong mạng nền.

Chương 5. Các ứng dụng ngang hàng (P2P)

Hình Error! No text of specified style in document..25: (a) DHT vòng, thiết bị ngang hàng 3 muốn xác định ai chịu trách nhiệm đối với khóa 11. (b) DHT vòng với các đường nối tắt

Sử dụng che phủ vòng Hình 5.4 (a), giả sử rằng thiết bị ngang hàng 3 muốn xác định thiết bị ngang hàng nào trong DHT chịu trách nhiệm đối với khóa 11 (hoặc để chèn hoặc để truy vấn cặp khóa-giá trị). Sử dụng che phủ vòng, thiết bị ngang hàng gốc (thiết bị ngang hàng 3) tạo ra bản tin “Ai chịu trách nhiệm đối với khóa 11?” và gửi bản tin này tới thiết bị ngay sau của nó là thiết bị ngang hàng 4. Bất cứ khi nào một thiết bị ngang hàng nhận được bản tin như vậy, do nó biết định danh của thiết bị ngay sau của nó, nên nó có thể xác định nó có trách nhiệm (có nghĩa là nó là gần nhất) đối với khóa đang được hỏi hay không. Nếu thiết bị ngang hàng không chịu trách nhiệm đối với khóa, nó chỉ đơn giản gửi bản tin đến thiết bị ngay sau của nó. Ví dụ, khi thiết bị ngang hàng 4 nhận được bản tin hỏi về khóa 11, nó xác định rằng nó không chịu trách nhiệm đối với khóa (vì rằng thiết bị ngay sau của nó gần với khóa hơn), như vậy nó chỉ chuyển bản tin tiếp đến thiết bị ngay sau của nó, gọi là thiết bị ngang hàng 5. Quá trình này tiếp tục cho đến khi bản tin đến thiết bị ngang hàng 12, xác định nó gần khóa 11 nhất. Tại điểm này, thiết bị ngang hàng 12 có thể gửi bản tin trở lại thiết bị ngang hàng gốc số 3, chỉ thị rằng nó chịu trách nhiệm đối với khóa 11.

DHT vòng cung cấp giải pháp rất thông minh nhằm giảm số lượng thông tin che phủ mỗi thiết bị ngang hàng phải quản lý. Đặc biệt, mỗi thiết bị ngang hàng chỉ nhận thức hai thiết bị ngang hàng, thiết bị ngay sau của nó và thiết bị ngay trước nó. (Ngầm định thiết bị ngang hàng biết được thiết bị ngay trước của nó, do thiết bị ngay trước này gửi bản tin). Nhưng giải pháp nay đưa ra vấn đề mới. Mặc dù mỗi thiết bị ngang hàng chỉ nhận biết 2 thiết bị ngang hàng lân cận, để tìm nút chịu trách nhiệm đối với khóa (trong trường hợp xấu nhất) tất cả N nút trong DHT sẽ phải chuyển tiếp bản tin xung quanh vòng, do đó có trung bình N/2 bản tin được gửi đi.

Do vậy, trong thiết kế DHT, có điểm cân bằng giữa số lượng lân cận mỗi thiết bị ngang hàng phải theo dõi và số lượng bản tin DHT cần phải gửi để giải quyết một truy vấn. Một mặt, nếu mỗi thiết bị ngang hàng theo dõi tất cả các thiết bị ngang hàng khác (che phủ dạng lưới), thì chỉ có một bản tin được gửi đi cho mỗi truy vấn, nhưng mỗi thiết bị ngang hàng phải theo dõi N thiết bị ngang hàng. Mặt khác, với DHT vòng, mỗi thiết bị ngang hàng chỉ nhận biết hai thiết bị ngang hàng, nhưng trung bình N/2 bản tin được gửi đi cho mỗi truy vấn. May mắn là chúng ta có thể hoàn thiện thiết kế DHT sao cho số

Chương 5. Các ứng dụng ngang hàng (P2P)

lượng lân cận của một thiết bị ngang hàng cũng như số lượng của bản tin cho mỗi truy vấn trong phạm vi chấp nhận được. Một trong những hoàn thiện như vậy là sử dụng che phủ vòng như nền tảng, nhưng bổ sung các “đường tắt” sao cho mỗi thiết bị ngang hàng không chỉ theo dõi thiết bị ngay sau của nó, mà cả một số lượng nhỏ các thiết bị ngang hàng được nối tắt rải rác trên vòng tròn.

Ví dụ một DHT vòng như vậy với một số đường nối tắt được đưa ra trên Hình 5.4 (b). Các đường tắt được sử dụng để tiến hành định tuyến các bản tin truy vấn. Đặc biệt, khi thiết bị ngang hàng nhận bản tin truy vấn khóa, nó chuyển tiếp bản tin tới lân cận (lân cận ngay sau hay một trong những lân cận nối tắt) gần khóa nhất. Vì vậy, trong Hình 5.4 (b) khi thiết bị ngang hàng 4 nhận bản tin hỏi về khóa 11, nó xác định rằng thiết bị ngang hàng gần khóa nhất (trong các lân cận) là lân cận nối tắt 10 và sau đó chuyển tiếp bản tin thẳng đến thiết bị ngang hàng 10. Rõ ràng là các đường nối tắt có thể giảm đáng kể số lượng bản tin sử dụng để xử lý truy vấn.

Vấn đề tiếp theo là “Bao nhiêu lân cận nối tắt mỗi thiết bị ngang hàng cần phải có, và thiết bị ngang hàng nào phải là lân cận nối tắt?”. Vấn đề này đã nhận được sự quan tâm của cộng đồng nghiên cứu. Một điều quan trọng cần lưu ý là các nghiên cứu đã chứng minh được rằng DHT có thể được thiết kế sao cho cả số lượng lân cận của mỗi thiết bị ngang hàng lẫn số lượng bản tin mỗi truy vấn là Ο(𝑙𝑜𝑔𝑁), trong đó N là số lượng thiết bị ngang hàng. Các thiết kế này cố gắng thỏa hiệp giữa giải pháp cực trị sử dụng topo dạng lưới và topo che phủ vòng.

Peer churn

Trong hệ thống P2P, thiết bị ngang hàng có thể vào và ra không báo trước. Do đó, khi thiết kế DHT, chúng ta phải quan tâm đến duy trì che phủ DHT bằng sự có mặt của peer churn. Để đạt được bức tranh toàn cảnh thấu hiểu điều này có thể được thiết lập như thế nào chúng ta sẽ lại xem xét DHT vòng trong Hình 5.4 (a). Để xử lý peer churn, chúng ta sẽ yêu cầu mỗi thiết bị ngang hàng theo dõi (tức là biết địa chỉ IP) của thiết bị ngay sau thứ nhất và thứ hai của nó; ví dụ, thiết bị ngang hàng 4 bây giờ theo dõi cả thiết bị ngang hàng 5 và 8.

Chúng ta cũng sẽ yêu cầu mỗi thiết bị ngang hàng định kì kiểm tra hai thiết bị ngay sau của nó còn sống (ví dụ, bằng cách định kì gửi các bản tin ping đến chúng và yêu cầu chúng phản hồi). Tiếp tục xem xét DHT được duy trì như thế nào khi một thiết bị ngang hàng đột ngột rời bỏ. Ví dụ, giả sử thiết bị ngang hàng 5 trong Hình 5.4 (a) đột ngột rời bỏ. Trong trường hợp này, hai thiết bị ngang hàng đằng trước thiết bị ngang hàng bỏ đi (4 và 3) biết được 5 đã bỏ đi, do nó không còn phản hồi bản tin ping. Các thiết bị ngang hàng 4 và 3 vì vậy cần cập nhật thông tin trạng thái thiết bị ngay sau của chúng. Bây giờ chúng ta sẽ xem xét thiết bị ngang hàng 4 cập nhật trạng thái của nó như thế nào:

Thiết bị ngang hàng 4 thay thế thiết bị ngay sau thứ nhất của nó (thiết bị ngang hàng 5) bằng thiết bị ngay sau thứ hai (thiết bị ngang hàng 8).

Thiết bị ngang hàng 4 sau đó yêu cầu thiết bị ngay sau thứ nhất mới (thiết bị ngang hàng 8) về định danh và địa chỉ IP của thiết bị ngay sau của nó (thiết bị ngang hàng 10). Thiết bị ngang hàng 4 sau đó lấy thiết bị ngang hàng 10 làm thiết bị ngay sau thứ hai.

Chương 5. Các ứng dụng ngang hàng (P2P)

Chúng ta đã đưa ra ngắn gọn cần làm gì khi một thiết bị ngang hàng rời đi, bây giờ chúng ta sẽ xem xét điều gì xảy ra khi một thiết bị ngang hàng muốn gia nhập vào DHT. Giả sử thiết bị ngang hàng với định danh 13 muốn gia nhập DHT, và tại thời điểm gia nhập, nó chỉ biết về sự tồn tại của thiết bị ngang hàng 1 trong DHT. Thiết bị ngang hàng đầu tiên sẽ gửi cho thiết bị ngang hàng 13 một bản tin, như “Thiết bị ngay trước và thiết bị ngay sau của thiết bị ngang hàng 13 là ai?” Bản tin này được chuyển tiếp qua DHT cho đến khi nó tới được thiết bị ngang hàng 12, người thực sự biết rằng nó sẽ là thiết bị ngay trước của thiết bị ngang hàng 13 và thiết bị ngay sau của nó, thiết bị ngang hàng 15, sẽ trở thành thiết bị ngay sau của thiết bị ngang hàng 13. Thiết bị ngang hàng 13 bây giờ có thể gia nhập DHT bằng cách lấy thiết bị ngang hàng 15 là thiết bị ngay sau và thông báo thiết bị ngang hàng 12 là nó phải đổi thiết bị ngay sau thành 13.

DHT đã được sử dụng vô cùng rộng rãi trong thực tế. Ví du, BitTorrent sử dụng Kademlia DHT để tạo lập bộ theo dõi phân tán. Trong BitTorrent, khóa là định danh torrent và giá trị là địa chỉ IP của tất cả các thiết bị ngang hàng hiện đang tham gia trong torrent. Theo cách này, bằng truy vấn DHT với định danh torrent, thiết bị ngang hàng BitTorrent mới tham gia có thể xác định thiết bị ngang hàng chịu trách nhiệm đối với định danh (có nghĩa là theo dõi các thiết bị ngang hàng trong torrent). Sau khi đã tìm được thiết bị ngang hàng này, thiết bị ngang hàng mới tham gia có thể truy vấn nó về danh sách các thiết bị ngang hàng khác trong torrent. DHT cũng được sử dụng rộng rãi trong hệ thống chia sẻ tệp eMule để xác định vị trí nội dung trong các thiết bị ngang hàng.

Các mạng P2P DHT có khả năng cung cấp một kiến trúc định tuyến hiệu quả, tự tổ chức, qui mô lớn, kết hợp với khả năng chịu lỗi, cân bằng tải và xác định vị trí rõ ràng. Tuy nhiên định tuyến trên DHT cũng có một số vấn đề cần quan tâm. Do các nút mạng gia nhập và rời mạng vào các thời điểm bất kì, không dự báo trước được, dẫn đến mạng không ổn định (churn). Điều này ảnh hưởng rất lớn đến hiệu năng định tuyến: do mạng thay đổi liên tục, chi phí duy trì ổn định cho các bảng định tuyến tại các nút sẽ tăng; hơn nữa do định tuyến dựa trên DHT vì vậy thiếu hỗ trợ cho việc truy tìm từ khóa và các truy vấn phức tạp. Tuy nhiên với việc phát triển một nền tảng thống nhất cho các DHT khác nhau sẽ làm cho mạng có cấu trúc ngày càng hấp dẫn hơn. Một nền tảng như vậy sẽ cung cấp một API dựa trên định tuyến trên cơ sở khóa (key based routing), kết hợp với mô hình dịch vụ DHT cơ bản để triển khai các ứng dụng DHT thuận tiện và dễ dàng.

Ứng dụng: thoại Internet sử dụng P2P

Thoại Internet Skype là một ứng dụng P2P thông dụng, thường hàng chục triệu người sử dụng kết nối tại bất cứ thời điểm nào. Ngoài việc cung cấp dịch vụ thoại Internet PC-to-PC Skype còn đưa ra dịch vụ thoại PC-to-phone, dịch vụ thoại phone-to-PC và dịch vụ hội nghị video PC-to-PC.

Skype sử dụng kỹ thuật P2P bằng nhiều cách sáng tạo, minh họa một cách độc đáo P2P có thể sử dụng trong các ứng dụng khác ngoài phân bố nội dung và chia sẻ tệp như thế nào. Cũng như nhắn tin, thoại Internet PC-to-PC vốn dĩ từ bản chất bên trong đã là P2P, vì trong tâm điểm của ứng dụng, cặp người sử dụng (thiết bị ngang hàng) truyền thông thời gian thực với nhau. Nhưng Skype cũng sử dụng các kỹ thuật P2P cho hai chức năng quan trọng khác: xác định vị trí người sử dụng và hỗ trợ chuyển đổi địa chỉ mạng NAT.

Chương 5. Các ứng dụng ngang hàng (P2P)

Không chỉ các giao thức Skype là quyền sở hữu riêng, mà tất cả các gói tin được truyền đi (các gói tin thoại và điều khiển) đều được mã hóa. Tuy nhiên, chúng ta vẫn có thể tìm hiểu Skype làm việc tổng thể như thế nào. Giống như FastTrack, các nút mạng Skype được tổ chức thành mạng che phủ phân cấp, mỗi thiết bị ngang hàng được phân loại thành siêu thiết bị ngang hàng hay thiết bị ngang hàng gốc. Skype bao gồm chỉ số ánh xạ tên người sử dụng Skype tới địa chỉ IP hiện thời (và số của cổng). Chỉ số này được phân bố trên các siêu thiết bị ngang hàng. Khi Alice muốn gọi cho Bob, máy khách Skype của Alice tìm kiếm chỉ số phân bố để xác định địa chỉ IP hiện thời của Bob. Bởi vì giao thức Skype là thuộc quyền sở hữu riêng, hiện nay vẫn chưa rõ ánh xạ chỉ số được tổ chức trên các siêu thiết bị ngang hàng như thế nào, mặc dù có một số dạng tổ chức DHT có thể là giải pháp tiềm năng.

Các kỹ thuật P2P cũng được sử dụng trong chuyển tiếp Skype, nó rất hữu dụng để thiết lập cuộc gọi giữa các trạm chủ trong mạng nhà. Nhiều cấu hình mạng nhà cung cấp truy nhập vào Internet thông qua bộ định tuyến (thường là bộ định tuyến không dây). Các bộ định tuyến này thực tế còn hơn cả bộ định tuyến, và thường bao hàm cả bộ chuyển đổi địa chỉ mạng NAT (Network Address Translator). NAT ngăn chặn trạm chủ bên ngoài mạng nhà khởi tạo kết nối với trạm chủ bên trong mạng nhà. Nếu cả hai chủ gọi Skype đều có NAT, thì sẽ xuất hiện vấn đề - không ai có thể chấp nhận cuộc gọi được khởi tạo bởi người khác, làm cho cuộc gọi có vẻ như không thể thực hiện. Có thể khéo léo sử dụng các siêu thiết bị ngang hàng và các bộ chuyển tiếp để giải quyết vấn đề này. Giả sử khi Alice báo vào mạng, cô ấy được gán vào một siêu thiết bị ngang hàng không có NAT. Alice có thể khởi tạo phiên đến siêu thiết bị ngang hàng của cô ấy do NAT của Alice chỉ không cho phép các phiên khởi tạo từ ngoài mạng nhà của Alice. Điều này cho phép Alice và siêu thiết bị ngang hàng của cô ta trao đổi các bản tin điều khiển trên phiên này.

Điều tương tự cũng xảy ra với Bob khi anh ta báo vào mạng. Bây giờ, khi Alice muốn gọi cho Bob, cô ấy thông báo cho siêu thiết bị ngang hàng của cô ấy, và đến lượt siêu thiết bị ngang hàng của Alice thông báo cho siêu thiết bị ngang hàng của Bob, sau đó siêu thiết bị ngang hàng này thông báo cho Bob cuộc gọi đến của Alice. Nếu Bob chấp nhận cuộc gọi, hai siêu thiết bị ngang hàng lựa chọn siêu thiết bị ngang hàng không có NAT thứ ba – nút chuyển tiếp – công việc của nó sẽ là chuyển dữ liệu giữa Alice và Bob. Các siêu thiết bị ngang hàng của Alice và Bob sau đó chỉ dẫn cho Alice và Bob khởi tạo phiên với bộ chuyển tiếp. Sau đó Alice gửi dữ liệu thoại đến bộ chuyển tiếp trên kết nối Alice- đến-bộ chuyển tiếp (nó đã được Alice khởi tạo), và bộ chuyển tiếp truyền các các gói tin này trên kết nối bộ chuyển tiếp-đến-Bob (nó đã được Bob khởi tạo); các gói tin từ Bob đến Alice lưu thông trên cùng hai kết nối này theo chiều ngược lại. Như vậy, Bob và Alice có kết nối toàn trình theo yêu cầu thậm chí không bên nào có thể chấp nhận phiên bắt nguồn từ bên ngoài mạng LAN của nó. Việc sử dụng bộ chuyển tiếp minh họa thiết kế ngày càng thông minh của hệ thống P2P, ở đó các thiết bị ngang hàng thực hiện các dịch vụ hệ thống lõi cho các bên khác (dịch vụ chỉ số và chuyển tiếp là hai ví dụ) trong khi đồng thời chúng cũng sử dụng dịch vụ người sử dụng cuối cho bản thân (như tải tệp, thoại IP) được cung cấp bởi hệ thống P2P.

Skype là một ứng dụng Internet thành công rộng rãi, với hàng chục triệu người sử dụng. Việc áp dụng nhanh và rộng rãi của Skype, cũng như chia sẻ tệp P2P, Web, nhắn tin là minh chứng cho sự thông minh của thiết kế kiến trúc tổng thể Internet. Bản thân thiết kế Internet này không thể nhìn thấy trước sự đa dạng và ngày càng mở rộng của các ứng dụng Internet được phát triển. Các dịch vụ mạng cung cấp cho các ứng dụng Internet – truyền tải gói dữ liệu vô hướng (UDP), chuyển tải gói dữ liệu tin 80

Chương 5. Các ứng dụng ngang hàng (P2P)

cậy có hướng (TCP), giao diện socket, đánh địa chỉ, và đặt tên (DNS), và các dịch vụ khác – đã chứng minh là có thể cho phép hàng nghìn ứng dụng được phát triển. Do các ứng dụng này đã được xếp lớp trên cùng của bốn lớp tồn tại bên dưới của chồng giao thức Internet, chúng chỉ liên quan đến phát triển client-server mới như một phần mềm peer-to-peer để sử dụng tại hệ thống đầu cuối. Đến lượt điều này lại cho phép các ứng dụng này triển khai và áp dụng nhanh chóng.

Chương 6. Kết nối mạng đa phương tiện

KẾT NỐI MẠNG ĐA PHƯƠNG TIỆN

Equation Section (Next)

Trong chương này chúng ta sẽ tìm hiểu triển khai các ứng dụng audio và video trên nền

Internet. Hàng nghìn trang Web, bao gồm CNN, AOL, Yahoo, Google … đang sẵn sàng cho phát các nội dung audio và video trực tuyến. Youtube và các trang chia sẻ video cho phép người sử dụng xem theo yêu cầu các video clip do người sử dụng khác tải lên. Hàng triệu người sử dụng thường xuyên sử dụng Skype cho các nhu cầu hội nghị thoại và video. Và các kênh truyền hình truyền thống bây giờ đang được truyền trên Internet, cho phép người sử dụng Internet xem kênh TV trên khắp thế giới. Điều này làm bùng nổ tốc độ phát triển của các ứng dụng Internet đa phương tiện. Nó cũng là thành quả của sự phát triển truy nhập băng rộng tại nhà và truy nhập không dây tốc độ cao (như WiFi). Tốc độ truy nhập băng rộng vẫn tiếp tục tăng ngày càng cao, do đó ngày càng thúc đẩy triển khai các ứng dụng đa phương tiện đang tồn tại và các ứng dụng đa phương tiện mới.

Các yêu cầu của ứng dụng đa phương tiện khác nhiều so với các ứng dụng co dãn (elastic)

như thư điện tử, trình duyệt Web, đăng nhập từ xa, tải tệp và chia sẻ tệp (chương 1-5). Cụ thể, không giống như các ứng dụng co dãn, các ứng dụng đa phương tiện rất nhạy cảm với trễ đầu cuối và dung sai trễ nhưng có thể chịu được mất gói dữ liệu thỉnh thoảng xảy ra.

Chúng ta bắt đầu chương này với việc phân loại ứng dụng đa phương tiện trong phần 6.1. Chúng ta sẽ thấy rằng ứng dụng đa phương tiện có thể được chia ra thành trực tuyến audio/video lưu trữ, trực tuyến audio/video trực tiếp và audio/video tương tác thời gian thực. Chúng ta sẽ tiếp tục thấy rằng từng lớp ứng dụng này có các tập yêu cầu khác nhau đối với mạng. Phần 6.2 sẽ tìm hiểu phát luồng audio/video một cách chi tiết. Phần 6.3 sẽ tìm hiểu các kỹ thuật mức ứng dụng có thể nâng cao hiệu năng của ứng dụng đa phương tiện trên mạng Internet dịch vụ best-effort hiện nay, và phần 6.4 sẽ bao gồm một số các giao thức đa phương tiện đang sử dụng hiện nay.

Ứng dụng kết nối mạng đa phương tiện

Trong chương 1 khi thảo luận về các yêu cầu ứng dụng, chúng ta đã xác định một loạt các điểm để phân loại các yêu cầu. Hai trong số các điểm này – các xem xét về thời gian và khả năng chịu mất gói – là đặc biệt quan trọng cho các ứng dụng đa phương tiện được kết nối mạng. Các xem xét thời gian là quan trọng bởi vì rất nhiều ứng dụng đa phương tiện nhạy cảm cao với trễ. Chúng ta có thể thấy rằng trong nhiều ứng dụng đa phương tiện, các gói tin gây ra trễ bên gửi–đến–bên nhận cao hàng trăm miligiây, về cơ bản không sử dụng được tại bên nhận. Mặt khác, các ứng dụng đa phương tiện phần lớn là có thể chịu được mất gói tin – đôi khi mất gói chỉ thi thoảng gây ra nhiễu trong quá trình phát lại audio/video, và các mất gói này thường có thể được che dấu một phần hay toàn bộ. Tính chất nhạy cảm trễ nhưng chịu được mất gói rõ ràng là khác biệt với các ứng dụng co dãn như Web, thư điện tử, FTP, và Telnet. Đối với các ứng dụng co dãn, trễ dài gây khó chịu nhưng không nghiêm trọng, tính đầy đủ và tính toàn vẹn của dữ liệu truyền tải mới là tối quan trọng.

Các ví dụ ứng dụng đa phương tiện

Chương 6. Kết nối mạng đa phương tiện

Internet có thể hỗ trợ nhiều ứng dụng đa dạng khác nhau đang tồn tại. Trong phần này, chúng ta xem xét ba lớp ứng dụng đa phương tiện chủ yếu: trực tuyến audio/video lưu trữ, trực tuyến audio/video trực tiếp, và audio/video tương tác thời gian thực.

Trong chương này chúng ta không bao hàm các ứng dụng tải về rồi chạy, như tải xuống toàn bộ MP3 thông qua ứng dụng chia sẻ P2P rồi phát lại MP3. Thực chất, các ứng dụng tải xuống rồi chạy đều là co dãn, ứng dụng truyền tệp không cần các yêu cầu trễ cụ thể nào.

Trực tuyến audio và video lưu trữ

Trong lớp ứng dụng này, các khách hàng yêu cầu theo nhu cầu (on demand) tệp audio hay

video nén đang lưu trữ trong các máy chủ. Hiện nay có hàng nghìn địa điểm cung cấp trực tuyến audio và video, bao gồm CNN, YouTube, Microsoft video,… Lớp dịch vụ này có ba đặc tính phân biệt chủ yếu:

Phương tiện được lưu trữ. Nội dung đa phương tiện, được ghi lại từ trước, lưu trữ tại máy chủ. Vì rằng phương tiện được ghi lại từ trước, người sử dụng có thể tạm dừng, tua lại, tua lên, hay đánh chỉ số trên nội dung đa phương tiện. Thời gian từ khi người sử dụng thực hiện yêu cầu cho đến khi hành động biểu hiện tại máy khách vào khoảng một đến mười giây là chấp nhận được.

Trực tuyến. Trong ứng dụng trực tuyến audio/video lưu trữ, khách hàng thường bắt đầu phát audio/video vài giây sau khi nhận được tệp từ máy chủ. Điều đó có nghĩa là khách hàng sẽ phát audio/video từ một vị trí của tệp trong khi đang nhận các phần sau của tệp từ máy chủ. Kỹ thuật này, được biết như phát trực tuyến, tránh phải tải xuống toàn bộ tệp (và có thể gánh chịu trễ dài) trước khi bắt đầu phát. Có rất nhiều máy khách đa phương tiện trực tuyến, bao gồm RealPlayer của RealNetworks, Apple’s QuickTime, và Microsoft’s Window Media.

Phát liên tục. Một khi bắt đầu phát nội dung đa phương tiện, nó phải được tiến hành tương ứng với thời gian nguyên gốc của bản ghi. Do đó, dữ liệu phải được nhận từ máy chủ kịp thời để phát ra cho máy khách; nếu không người sử dụng sẽ trải nghiệm thấy trễ đệm bị phá hỏng. Mặc dù các ứng dụng phương tiện được lưu trữ có yêu cầu phát liên tục, các ràng buộc trễ toàn trình tuy thế ít nghiêm ngặt hơn so với các ứng dụng truyền trực tiếp, tương tác như hội nghị thoại và video (phần sau).

Trực tuyến audio và video trực tiếp

Lớp ứng dụng này tương tự như phát thanh và truyền hình quảng bá truyền thống, ngoại trừ truyền dẫn được thực hiện trên Internet. Các ứng dụng này cho phép người sử dụng nhận phát thanh và truyền hình xuất phát từ bất cứ nơi nào trên thế giới. (Ví dụ, một người có thể nghe một chương trình phát thanh yêu thích khi đi công tác hay ở bất cứ đâu). Các ứng dụng này thường dẫn đến phát thanh Internet và IPTV (xem bên dưới). Ngày nay có hàng nghìn trạm phát thanh quảng bá trên Internet và rất nhiều mạng triển khai IPTV.

Do audio/video truyền trực tiếp và phát trực tuyến không được lưu trữ, khách hàng không thể tua lên nội dung của phương tiện. Tuy nhiên, với bộ lưu trữ cục bộ dữ liệu nhận được, các hoạt

Chương 6. Kết nối mạng đa phương tiện

động tương tác khác như tạm dừng và tua lại có thể thực hiện được. Ứng dụng truyền trực tiếp, quảng bá thường có nhiều máy khách cùng nhận một chương trình audio/video. Phân bố audio/video truyền trực tiếp tới nhiều bên nhận có thể được thiết lập hiệu quả sử dụng kỹ thuật IP- multicast. Tuy nhiên, phân bố audio/video trực tiếp hiện nay thường được thiết lập thông qua multicast lớp ứng dụng (sử dụng P2P hay CDN) hay thông qua nhiều luồng unicast máy chủ-đến-máy khách riêng rẽ. Cũng giống như trực tuyến đa phương tiện lưu trữ, trực tuyến đa phương tiện trực tiếp yêu cầu phát liên tục, mặc dù các ràng buộc về thời gian ít nghiêm ngặt hơn so với ứng dụng tương tác thời gian thực. Trễ tới mười giây từ khi người sử dụng yêu cầu phát truyền trực tiếp cho đến khi bắt đầu phát phương tiện là có thể chấp nhận được.

IPTV

Nội dung truyền hình được phân bố theo cách truyền thống qua sóng ngắn, cáp đồng trục

HFC, và các kênh vệ tinh địa tĩnh. Nhưng hiện nay trên Internet, IPTV đang được quan tâm phát triển mạnh, tức là phân bố nội dung truyền hình trên Internet.

Một trong những thách thức của IPTV là yêu cầu băng thông rất lớn, đặc biệt tại nguồn máy

chủ. Ví dụ, xem xét phân bố một sự kiện thể thao, như một trận đấu World Cup, từ một máy chủ đơn thông qua Internet đến 100 triệu người sử dụng đồng thời. Nếu tốc độ video là 1 Mbps, thì băng thông máy chủ yêu cầu có thể lên tới 100 tetabit/sec. Do đó, phân bố truyền thống client-server hoàn toàn không thể thực hiện được. Nếu triển khai IP multicast trên Internet, thì sẽ dễ dàng thực thi IPTV hơn rất nhiều. Một phương án khác là phân bố video trên mạng che phủ multicast, như mạng phân bố nội dung (CDN) trong phần 6.3.

Một phương án nữa là sử dụng phân bố P2P, trong đó mỗi thiết bị ngang hàng nhận kênh

truyền hình cũng hỗ trợ quá trình phân bố lại các kênh tới các thiết bị ngang hàng khác. Có lẽ lợi thế lớn nhất của giải pháp này là chi phí phân bố thấp: nếu mỗi thiết bị ngang hàng riêng rẽ cung cấp băng thông chiều lên đủ lớn, băng thông của máy chủ có thể chỉ cần nhỏ (có thể chỉ vài lần của tốc độ video). Với chi phí thấp như vậy, bất cứ ai có Web-cam đều có thể phân bố chương trình truyền trực tiếp tới hàng triệu người sử dụng với chi phí không đáng kể.

Cho đến nay đã có một số hệ thống IPTV P2P tương tự như BitTorrent, được triển khai thành công. Ví dụ, PPLive và ppstream, đã thông báo có hàng chục nghìn người sử dụng cùng xem các kênh đồng thời, với tốc độ từ 300 kbps đến 1 Mbps. Trong các hệ thống tương tự như BitTorrent này các thiết bị ngang hàng tạo thành một mạng che phủ động, và trao đổi các khúc video với lân cận che phủ. Một vần đề rất thú vị được đặt ra: công nghệ nào sẽ được sử dụng cho IPTV - CDN hay P2P, hay lai ghép của cả hai? Và liệu khi nào chúng ta có thể xem World Cup trực tiếp từ Internet?

Audio và Video tương tác thời gian thực

Lớp ứng dụng này cho phép mọi người sử dụng audio/video để truyền thông với nhau trên thời gian thực. Audio tương tác thời gian thực trên Internet thường được xem như thoại Internet, do từ quan điểm của người sử dụng, nó tương tự như dịch vụ thoại chuyển mạch truyền thống. Thoại Internet có thể cung cấp dịch vụ chuyển mạch PBX, thoại nội bộ và đường dài với chi phí rất thấp. Nó cũng tạo điều kiện để triển khai các dịch vụ mới mà mạng chuyển mạch truyền thống không dễ dàng hỗ trợ

Chương 6. Kết nối mạng đa phương tiện

như tìm kiếm hiện diện, truyền thông nhóm, lọc chủ gọi, tích hợp thoại Web ... Hiện nay đã sẵn có rất nhiều các sản phẩm thoại Internet. Ví dụ, người sử dụng Skype có thể thực hiện cuộc gọi thoại PC-to- phone và PC-to-PC. Cùng với video tương tác thời gian thực, cũng còn gọi là hội nghị video, cá nhân có thể truyền thông nghe và nhìn. Hiện nay đang sẵn có rất nhiều sản phẩm video tương tác thời gian thực cho Internet bao gồm Microsoft’s Netmeeting, Skype video, và các sản phẩm Polycom. Lưu ý rằng trong ứng dụng audio/video tương tác thời gian thực người sử dụng có thể nói hay quay đầu bất cứ thời điểm nào. Đối với cuộc hội thoại tương tác giữa nhiều người, trễ từ khi người sử dụng nói hay di chuyển cho đến khi hành động biểu hiện tại trạm chủ nhận phải nhỏ hơn vài trăm miligiây. Đối với thoại, trễ nhỏ hơn 150 ms người nghe không cảm nhận được, trễ vào khoảng từ 150 ms đến 400 ms có thể chấp nhận được, và trễ vượt quá 400 ms có thể dẫn đến phá hỏng hội thoại, hoặc hoàn toàn không thể hiểu được.

Yêu cầu chất lượng cho ứng dụng đa phương tiện trên Internet

Các giao thức IP áp dụng trên mạng Internet hiện nay cung cấp các dịch vụ best-effort cho tất

cả các gói tin nó mang. Nói một cách khác, Internet thực hiện nỗ lực tối đa để chuyển gói tin từ bên gửi đến bên nhận nhanh nhất có thể, nhưng nó không hề đưa ra bất cứ hứa hẹn nào về trễ toàn trình cho từng gói tin riêng rẽ. Dịch vụ cũng không hề đưa ra bất cứ hứa hẹn nào về dung sai của trễ gói tin trong luồng gói tin. Vì rằng TCP và UDP chạy bên trên IP, dẫn đến không giao thức truyền tải nào thực thi đảm bảo trễ cho các ứng dụng liên quan. Do thiếu nỗ lực cụ thể để phân phối gói tin theo thời gian, đây là một thách thức rất lớn để phát triển các ứng dụng kết nối đa phương tiện cho Internet. Tuy vậy, đa phương tiện trên Internet đã đạt được thành công cho đến nay. Ví dụ, trực tuyến audio/video lưu trữ đạt được trễ tương tác người sử dụng trong khoảng 5 đến 10 giây đã khá thông thường trên Internet. Nhưng trong khoảng lưu lượng đạt đỉnh, hiệu năng có thể không được thỏa mãn, đặc biệt khi các liên kết tham gia bị tắc nghẽn.

Thoại Internet và video tương tác thời gian thực cũng có các sử dụng rộng rãi, ví dụ, thường

xuyên có hơn bẩy triệu người sử dụng Skype online tại bất cứ thời điểm nào. Thoại và video tương tác thời gian thực áp đặt khắt khe các ràng buộc về trễ và jitter của gói tin. Jitter gói tin là sự thay đổi của trễ các gói tin trong cùng một luồng gói tin. Thoại và video thời gian thực có thể làm việc tốt khi băng thông dồi dào, và do đó trễ và jitter nhỏ. Nhưng chất lượng có thể suy giảm tới mức không chấp nhận được khi luồng gói tin thoại và video thời gian thực gặp phải liên kết tắc nghẽn.

Thiết kế các ứng dụng đa phương tiện có thể đơn giản hơn nếu có phân loại dịch vụ Internet thành loại một và loại hai, trong đó các gói tin loại một được giới hạn bởi số lượng và có mức dịch vụ ưu tiên nhận được trong các hàng đợi bộ định tuyến. Dịch vụ loại một như vậy có thể được thỏa mãn cho các ứng dụng nhạy cảm trễ. Nhưng cho đến hiện nay, phần lớn Internet thực hiện giải pháp lập lịch trong hàng đợi bộ định tuyến. Tất cả các gói tin nhận dịch vụ như nhau; không có gói tin nào, kể cả các gói tin audio và video nhạy cảm trễ, nhận được mức ưu tiên đặc biệt trong hàng đợi bộ định tuyến. Không để ý bạn đã trả bao nhiêu tiền hay bạn quan trọng như thế nào, bạn vẫn phải gia nhập cuối hàng và đợi đến lượt! Các kiến trúc cung cấp phân chia lớp dịch vụ (như các cơ cấu lập lịch và chính sách, Diffserv) có thể giải quyết các hạn chế này. Ngoài ra, để đảm bảo chất lượng dịch vụ (QoS), các thủ tục như dự trữ tài nguyên, chấp nhận cuộc gọi, thiết lập cuộc gọi cũng được áp dụng.

Chương 6. Kết nối mạng đa phương tiện

Trong điều kiện của dịch vụ best-effort, chúng ta vẫn có thể thực hiện một loạt các quyết định thiết kế và áp dụng một số thủ thuật để nâng cao chất lượng trải nghiệm người sử dụng của các ứng dụng kết nối mạng đa phương tiện. Ví dụ, chúng ta có thể gửi audio và video trên UDP, và do đó loại bỏ thông lượng thấp của TCP khi TCP bước vào giai đoạn khởi đầu chậm (slow-start). Chúng ta có thể làm chậm phát lại tại bộ thu 100 ms hay hơn nhằm giảm tác động của jitter do mạng gây ra. Chúng ta có thể gán nhãn thời gian cho gói tin tại bên gửi sao cho bên nhận nhận biết được khi nào gói tin phải được phát ra. Đối với audio/video lưu trữ, chúng ta có thể tìm nạp trước dữ liệu trong quá trình phát lại khi có sẵn lưu trữ phía máy khách và băng thông dư thừa. Chúng ta cũng có thể gửi thông tin dự phòng nhằm giảm thiểu tác động của mất gói do mạng gây ra. Chúng ta sẽ xem xét các kỹ thuật này trong các phần sau.

Giải pháp hỗ trợ đa phương tiện trên Internet

Hiện nay vẫn đang tiếp tục công cuộc phát triển Internet để lưu lượng đa phương tiện tương

thích được với các ràng buộc khắt khe. Một mặt, các thay đổi nền tảng phải được thực hiện để các ứng dụng có thể dự trữ băng thông đầu cuối và nhận được đảm bảo hiệu năng toàn trình. Đảm bảo cứng nghĩa là các ứng dụng sẽ nhận được chất lượng dịch vụ QoS yêu cầu của nó chắc chắn. Đảm bảo mềm nghĩa là ứng dụng sẽ nhận được chất lượng dịch vụ QoS yêu cầu của nó với xác suất cao. Các nhà nghiên cứu tin tưởng rằng nếu người sử dụng muốn thực hiện, ví dụ thoại Internet từ trạm chủ A sang trạm chủ B, thì ứng dụng thoại Internet của người sử dụng phải có khả năng dự trữ băng thông tường minh trên từng liên kết trên suốt đường định tuyến giữa hai máy chủ. Nhưng cho phép ứng dụng thực hiện dự trữ tài nguyên và yêu cầu mạng thực hiện dự trữ này yêu cầu một số thay đổi lớn. Trước hết chúng ta cần giao thức thay mặt ứng dụng dự trữ băng thông liên kết trên tuyến từ thiết bị gửi đến thiết bị nhận. Thứ hai, chúng ta phải thay đổi chính sách lập lịch trong hàng đợi bộ định tuyến sao cho băng thông dự trữ có thể thực hiện được. Với chính sách lập lịch mới này, không phải tất cả gói tin được xử lý như nhau; ngược lại, gói tin nào được dự trữ (và phải trả chi phí) nhiều hơn sẽ nhận được nhiều hơn. Thứ ba, nhằm thực hiện dự trữ, các ứng dụng phải đưa ra cho mạng mô tả về lưu lượng dự định truyền qua mạng. Mạng phải giám sát lưu lượng từng ứng dụng nhằm đảm bảo rằng nó tuân thủ đúng như mô tả. Cuối cùng, mạng phải có phương tiện xác định liệu nó sẵn có đủ băng thông để hỗ trợ bất cứ yêu cầu dự trữ mới nào. Các cơ cấu này khi kết hợp lại sẽ yêu cầu phần mềm mới và phức tạp tại máy chủ và các bộ định tuyến cũng như các loại dịch vụ mới. Chi tiết về các cơ cấu nhằm đảm bảo QoS này bao gồm dự trữ tài nguyên, chấp nhận cuộc gọi, thiết lập cuộc gọi, cơ chế đảm bảo chất lượng dịch vụ trên mạng Internet như Intserv và RSVP.

Mặt khác, các nhà nghiên cứu cũng đồng ý rằng không cần thiết phải thực hiện bất cứ thay

đổi nền tảng nào đối với dịch vụ best-effort và các giao thức Internet. Thay vào đó, có thể ủng hộ giải pháp dễ dàng hơn:

Do nhu cầu tăng, các ISP sẽ thay đổi qui mô mạng để đáp ứng các nhu cầu. Cụ thể, ISP sẽ cung cấp băng thông và dung lượng chuyển mạch đủ để thỏa mãn hiệu năng trễ và mất gói trong phạm vi mạng của họ. Do vậy các ISP cung cấp dịch vụ tốt hơn cho khách hàng của họ (người sử dụng và khách hàng ISP), dẫn đến lợi nhuận cao hơn thông qua nhiều khách hàng hơn và phí dịch vụ cao hơn. Để đảm bảo rằng các ứng dụng đa phương tiện nhận được dịch vụ cân xứng, thậm chí cả trong trường hợp quá tải, ISP có thể cung cấp dự phòng băng thông

Chương 6. Kết nối mạng đa phương tiện

và dung lượng chuyển mạch. Với dự báo lưu lượng và cung cấp băng thông chính xác, đảm bảo QoS mềm có thể thực hiện được.

Mạng phân bố nội dung (CDN) nhân rộng nội dung và đưa các nội dung sao chép này đến các biên của Internet. Giả sử phần lớn các mảnh của lưu lượng phân luồng qua Internet là nội dung lưu trữ (trang Web, MP3, video), CDN có thể giảm bớt đáng kể tải lưu lượng trên ISP và giao diện ngang hàng giữa các ISP. Hơn thế nữa, CDN cung cấp dịch vụ phân biệt tới nhà cung cấp nội dung: nhà cung cấp nội dung trả tiền cho dịch vụ CDN để có thể phân phối nội dung nhanh hơn và hiệu quả hơn. Chúng ta sẽ tìm hiểu CDN trong mục 6.3.

Liên quan đến lưu lượng phát trực tuyến trực tiếp (như sự kiện thể thao) được gửi tới hàng triệu người sử dụng đồng thời, mạng che phủ multicast có thể được áp dụng. Mạng che phủ multicast bao gồm từ các trạm chủ người sử dụng và có thể cả các máy chủ dành riêng rải rác khắp Internet. Các trạm chủ, máy chủ này và các liên kết logic giữa chúng tập hợp tạo thành mạng che phủ, nó phát lưu lượng đa hướng từ nguồn tới hàng triệu người sử dụng. Không giống như IP multicast, trong đó chức năng phát đa hướng được xử lý bởi bộ định tuyến trên lớp IP, mạng che phủ phát đa hướng tại lớp ứng dụng. Ví dụ, trạm chủ nguồn có thể gửi luồng đến ba máy chủ che phủ; mỗi máy chủ che phủ có thể chuyển tiếp luồng đến các máy chủ che phủ khác; tiếp tục quá trình, tạo thành một cây phân tán bên trên của mạng IP nền. Bằng cách phát đa hướng lưu lượng trực tiếp thông thường thông qua mạng che phủ, tải lưu lượng tổng thể trên Internet có thể giảm xuống so với trường hợp phân bố đơn hướng.

Giữa hai xu hướng dự trữ và dễ dàng hơn như trên tồn tại xu hướng thứ ba – dịch vụ phân

biệt. Xu hướng này mong muốn thực hiện một ít thay đổi tại lớp mạng và giao vận, đưa ra sơ đồ đánh giá và kiểm soát đơn giản tại biên của mạng (tức là tại giao diện giữa người sử dụng và ISP người sử dụng). Ý tưởng là đề xuất một số lượng các lớp lưu lượng (có thể chỉ hai lớp), gán mỗi gói tin vào một lớp, cho các gói tin các mức dịch vụ khác nhau tương ứng với lớp của chúng trong hàng đợi bộ định tuyến, và tính chi phí cho người sử dụng tương ứng với lớp gói tin được truyền đi vào mạng.

Trên đây là ba giải pháp xử lý lưu lượng đa phương tiện – thực hiện tốt nhất cho dịch vụ

best-effort, QoS phân biệt và đảm bảo QoS – và được tổng kết trong bảng 6.1.

Bảng Error! No text of specified style in document..3: Ba giải pháp hỗ trợ ứng dụng đa

phương tiện

Giải pháp

Đơn vị phân

Đảm bảo

Triển khai Mức độ phức

Cơ chế

bổ

tạp

Thực hiện tốt

Không có

Không, hoặc

Khắp nơi

Tối thiểu

Hỗ trợ lớp ứng

nhất cho dịch

mềm

dụng, CDN,

vụ best-effort.

cung cấp dự

phòng.

QoS phân biệt Lớp các luồng Không, hoặc

Một số

Trung bình

Kiểm soát, lập

mềm

lịch

QoS đảm bảo Luồng riêng rẽ Mềm hoặc

Ít

Cao

Kiểm soát, lập

cứng, một khi

lịch, chấp nhận

luồng được

cuộc gọi và

chấp nhận

báo hiệu

Chương 6. Kết nối mạng đa phương tiện

Chuẩn nén audio và video

Trước khi audio và video có thể truyền đi trên mạng, nó phải được số hóa và nén. Sự cần

thiết của số hóa là rõ ràng: mạng máy tính truyền dẫn bit, do đó tất cả thông tin truyền đi phải biểu diễn dưới dạng một chuỗi bit. Nén cũng quan trọng vì audio và video không nén tiêu tốn lượng bộ nhớ lưu trữ và băng thông khổng lồ - loại bỏ dư thừa nội tại bằng nén tín hiệu audio và video đã số hóa có thể giảm lượng dữ liệu cần lưu trữ và truyền dẫn nhiều lần. Ví dụ, một hình ảnh bao gồm 1024 điểm ảnh, mỗi điểm ảnh mã hóa thành 24 bit (8 bit cho mỗi mầu đỏ, xanh da trời, xanh lá cây), yêu cầu 3 Mbyte lưu trữ nếu không nén. Nó có thể mất 7 phút để truyền hình ảnh này trên liên kết 64 kbps. Nếu hình ảnh được nén tại chế độ tỉ lệ 10:1, các yêu cầu lưu trữ sẽ giảm xuống còn 300 Kbyte và thời gian truyền dẫn cũng giảm đi 10 lần.

Nội dung chuyên đề nén audio và video rất lớn. Nó đã được nghiên cứu hơn 50 năm, và có

hàng trăm kỹ thuật thông dụng cũng như tiêu chuẩn cho nén cả audio lẫn video. Chúng ta chỉ đưa ra ở đây giới thiệu ngắn gọn và ở mức tổng quát vấn đề này.

Nén audio trên Internet

Tín hiệu audio tương tự biến đổi liên tục (có thể xuất phát từ tiếng nói hoặc âm nhạc) thường

biến đổi sang tín hiệu số như sau:

Tín hiệu audio tương tự trước hết được lấy mẫu với tốc độ cố định 8,000 mẫu trên giây. Giá trị mỗi mẫu là một số thực nào đó.

Mỗi mẫu được làm tròn bằng một giá trị số hữu hạn. Quá trình này được gọi là lượng tử hóa. Số lượng giá trị hữu hạn – gọi là giá trị lượng tử hóa – thường là số mũ bậc 2, ví dụ 256 giá trị lượng tử hóa.

Mỗi giá trị lượng tử hóa được biểu diễn bằng một số cố định các bit. Ví dụ, nếu có 256 giá trị lượng tử hóa thì mỗi giá trị - tức là mỗi mẫu – được biểu diễn bằng 1 byte. Mỗi mẫu được biến đổi thành dạng bit. Biểu diễn bit của tất cả các mẫu liên tiếp nhau tạo thành biểu diễn của tín hiệu.

Ví dụ, nếu tín hiệu audio tương tự được lấy mẫu tại 8,000 mẫu một giây và mỗi mẫu được

lượng tử hóa và biểu diễn bằng 8 bit, kết quả là tín hiệu số sẽ có tốc độ 64,000 bit trên giây. Tín hiệu số này có thể sau đó được biến đổi ngược lại – tức là giải mã – thành tín hiệu tương tự để phát lại.

Chương 6. Kết nối mạng đa phương tiện

Tuy nhiên, tín hiệu tương tự được giải mã thường khác với tín hiệu tương tự gốc. Bằng cách tăng tốc độ lấy mẫu, và số lượng giá trị lượng tử hóa, tín hiệu giải mã có thể tiệm cận tín hiệu tương tự gốc. Do đó, có điểm cân bằ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ữ cũng như băng thông của tín hiệu số.

Kỹ thuật mã hóa cơ bản mô tả ở trên được gọi là điều biến mã xung (PCM). Mã hóa giọng nói

thường sử dụng PCM, với tốc độ lấy mẫu 8,000 mẫu một giây và 8 bit một mẫu, và tốc độ 64 kbps. Đĩa audio CD thường sử dụng PCM với tốc độ lấy mẫu 44,100 mẫu một giây, và 16 bit một mẫu; tốc độ 705,6 kbps đối với mono và 1,411 Mbps đối với stereo.

Tốc độ 1,411 Mbps đối với âm nhạc stereo vượt quá phần lớn các tốc độ truy nhập, và thậm chí 64 kbps đối với tiếng nói cũng vượt quá tốc độ người sử dụng dial-up. Với các lý do này, tiếng nói và âm nhạc mã hóa PCM hiếm khi sử dụng trên Internet. Thay vào đó, kỹ thuật nén được sử dụng để giảm tốc độ bit của luồng. Các kỹ thuật nén thông dụng cho tiếng nói bao gồm GSM (13 kbps), G.729 (8 kbps), G.723.3 (có cả 6.4 và 5.3 kbps), và một số lớn các kỹ thuật có quyền sở hữu riêng. Kỹ thuật nén thông dụng cho âm nhạc stereo gần đạt chất lượng CD là MPEG 3 player 1, được biết nhiều hơn với tên MP3. Bộ mã hóa MP3 thường nén đến tốc độ 96 kbps, 128 kbps, và 160 kbps, và làm giảm chất lượng âm thanh rất ít. Khi tệp MP3 được chia ra thành các mảnh, và mỗi mảnh vẫn có khả năng phát. Khuôn dạng tệp không đầu này cho phép các tệp âm nhạc MP3 được truyền qua Internet (giả thiết rằng tốc độ phát lại và tốc độ kết nối Internet là tương thích). Chuẩn nén MP3 phức tạp, sử dụng mặt nạ tâm lí học, giảm dư thừa, và bộ đệm chứa bit.

Nén video trên Internet

Video là chuỗi các hình ảnh, thường được hiển thị với tốc độ không đổi – ví dụ, 24 hay 30

hình ảnh một giây. Hình ảnh không nén, mã hóa số bao gồm một mảng các điểm ảnh, với mỗi điểm ảnh được mã hóa thành một số các bit để biểu diễn độ sáng và mầu. Có hai dạng dư thừa trong video, cả hai đều có thể khai thác để nén. Dư thừa không gian là dư thừa bên trong hình ảnh đã cho. Ví dụ, hình ảnh cấu thành từ phần lớn không gian trắng có thể nén một cách hiệu quả. Dư thừa thời gian phản ánh sự lặp lại từ một hình ảnh với các hình ảnh tiếp theo. Ví dụ, nếu một hình ảnh và hình ảnh tiếp theo hoàn toàn giống hệt nhau, thì không có lí do gì để mã hóa lại hình ảnh tiếp theo; sẽ hiệu quả hơn nếu đơn giản chỉ ra trong quá trình mã hóa rằng hình ảnh tiếp theo hoàn toàn giống hệt.

Các tiêu chuẩn nén MPEG nằm trong số các kỹ thuật nén thông dụng nhất. Chúng bao gồm MPEG 1 cho nén video chất lượng CD-ROM (1.5 Mbps), MPEG 2 cho nén 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 phần lớn được rút ra từ tiêu chuẩn JPEG đối với nén hình ảnh bằng cách khai thác dư thừa thời gian qua các hình ảnh bổ sung vào dư thừa không gian đã được khai thác bằng JPEG. Tiêu chuẩn nén video H.261 cũng rất thông dụng trên Internet. Ngoài ra, có rất nhiều mô hình thuộc quyền sở hữu riêng, bao gồm mã hóa của Apple’s QuickTime và Real Network.

Dịch vụ audio, video lưu trữ

Chương 6. Kết nối mạng đa phương tiện

Trong các năm gần đây, trực tuyến audio/video đã trở thành ứng dụng thông dụng và tiêu tốn đáng kể băng thông mạng. Trong quá trình trực tuyến audio/video, máy khách yêu cầu các tệp audio/video nén nằm trong các máy chủ. Như chúng ta đã thảo luận ở trên, các máy chủ này có thể là máy chủ Web gốc hay có thể là máy chủ trực tuyến đặc thù dành riêng cho ứng dụng trực tuyến audio/video. Dựa trên yêu cầu máy khách, máy chủ gửi tệp audio/video tới máy khách bằng cách gửi tệp đến socket. Mặc dù cả TCP và UDP đều có thể sử dụng, ngày nay phần lớn các lưu lượng audio/video trực tuyến được truyền tải bằng TCP. (Tường lửa thường được cấu hình để chặn lưu lượng UDP. Hơn nữa, sử dụng TCP với chuyển tải tin cậy toàn bộ tệp được truyền tới khách hàng mà không bị mất gói, cho phép tệp được phát lại từ lưu đệm nội bộ trong tương lai). Một khi tệp audio/video yêu cầu bắt đầu đến, khách hàng bắt đầu thể hiện tệp (thông thường) trong vòng vài giây. Một số hệ thống cũng cung cấp tương tác người sử dụng, ví dụ, tạm dừng/tiếp tục, và nhảy về thời gian trong tệp audio/video. Giao thức trực tuyến thời gian thực (RSTP), đưa ra trong phần sau, là giao thức miền công cộng để cung cấp tương tác người sử dụng.

Người sử dụng thường yêu cầu trực tuyến audio/video qua máy khách Web (tức là trình duyệt Web), nhưng sau đó hiển thị và điều khiển phát audio/video sử dụng bộ phát phương tiện (media player), như Windows Media Player hay Flash player. Bộ phát phương tiện thực hiện một loạt chức năng, bao gồm:

Giải nén. Audio/video thường luôn bị nén để tiết kiệm dung lượng lưu trữ đĩa và băng thông. Bộ đọc phương tiện phải giải nén audio/video trong quá trình phát.

Loại bỏ jitter. Jitter gói tin là tính biến thiên của trễ nguồn-tới-đích của gói tin trong cùng một luồng gói tin. Do audio và video phải được phát ra cùng một thời gian như khi nó được ghi lại, bộ thu sẽ lưu các gói tin nhận được một khoảng thời gian ngắn để loại bỏ jitter. Chúng ta sẽ xem xét cụ thể trong phần 6.3.

Truy cập audio và video thông qua Web server

Audio/video lưu trữ có thể nằm trong máy chủ Web chuyển phát audio/video đến máy khách trên HTTP, hoặc có thể nằm trong máy chủ trực tuyến audio/video dành riêng sử dụng HTTP hay giao thức khác. Trong phần này, chúng ta xem xét chuyển phát từ máy chủ Web, trong phần sau chúng ta xem xét chuyển phát từ máy chủ trực tuyến. Chuyển phát đa phương tiện thông qua HTTP trở thành thông dụng vì tường lửa thường cho phép lưu lượng HTTP đi qua trong khi các giao thức có quyền sở hữu khác bị tường lửa chặn lại.

Xem xét trường hợp đầu tiên là trực tuyến audio. Khi tệp audio nằm trong máy chủ Web, tệp

audio là đối tượng gốc trong hệ thống máy chủ, cũng giống như tệp JPEG. Khi người sử dụng muốn nghe tệp audio, trạm chủ người sử dụng thiết lập kết nối TCP với máy chủ Web và gửi yêu cầu HTTP cho đối tượng. Khi nhận được yêu cầu, máy chủ Web đóng gói tệp audio trong bản tin đáp ứng HTTP và gửi bản tin trở lại trên kết nối TCP. Trong trường hợp video sẽ hơi phức tạp hơn nếu phần audio và video của video được lưu trữ trong hai tệp. Cũng có khả năng audio và video đan xen trong cùng một tệp, do đó chỉ có một đối tượng cần được gửi đến khách hàng. Để cho đơn giản, trong trường hợp của video giả thiết rằng audio và video chứa trong cùng một tệp.

Chương 6. Kết nối mạng đa phương tiện

Trong rất nhiều triển khai của audio/video trực tuyến trên HTTP, tính năng phía máy khách

được chia thành hai phần. Công việc của trình duyệt là yêu cầu siêu tệp (metafile) cung cấp thông tin (ví dụ, URL và loại mã hóa, sao cho có thể xác định bộ phát phương tiện phù hợp) về tệp đa phương tiện được trực tuyến trên HTTP. Siêu tệp này sau đó được truyền đi từ bộ trình duyệt đến bộ phát phương tiện, công việc của nó là liên lạc với máy chủ HTTP, máy chủ này sẽ gửi tệp đa phương tiện tới bộ phát phương tiện trên HTTP. Các bước này được minh họa trong Hình 6.1:

Người sử dụng bấm vào đường dẫn tệp audio/video. Đường dẫn không trỏ trực tiếp đến tệp audio/video, thay vào đó tới siêu tệp. Siêu tệp chứa URL của tệp audio/video thực tế. Bản tin đáp ứng HTTP đóng gói siêu tệp bao gồm dòng tiêu đề loại nội dung chỉ thị ứng dụng audio/video cụ thể.

Bộ trình duyệt khảo sát dòng tiêu đề loại nội dung của bản tin đáp ứng, khởi động bộ phát phương tiện, và truyền toàn bộ thân của bản tin đáp ứng (tức là siêu tệp) tới bộ phát phương tiện.

Bộ phát phương tiện thiết lập kết nối TCP trực tiếp với máy chủ HTTP. Bộ phát phương tiện gửi bản tin yêu cầu tệp audio/video vào kết nối TCP. Tệp audio/video được gửi trong bản tin đáp ứng HTTP tới bộ phát phương tiện. Bộ phát phương tiện phát trực tuyến tệp audio/video.

Hình Error! No text of specified style in document..26: Máy chủ Web gửi audio/video trực tiếp tới bộ phát phương tiện

Tính quan trọng của bước trung gian yêu cầu siêu tệp là rõ ràng. Khi bộ trình duyệt xem loại

nội dung của tệp, nó có thể khởi động bộ phát phương tiện phù hợp, và vì vậy chúng ta có bộ phát phương tiện liên lạc trực tiếp với máy chủ.

Chúng ta vừa tìm hiểu siêu tệp có thể cho phép bộ phát phương tiện truyền thông trực tiếp với máy chủ Web lưu trữ tệp audio/video như thế nào. Nhiều công ty bán sản phẩm trực tuyến audio/video không khuyến nghị kiến trúc mô tả trên. Thay vào đó họ khuyến nghị trực tuyến audio/video lưu trữ từ các máy chủ trực tuyến dành riêng, được tối ưu để phát trực tuyến.

Chương 6. Kết nối mạng đa phương tiện

Gửi dữ liệu đa phương tiện từ server trự c tuyến đến ứng dụng

Máy chủ trực tuyến có thể là máy chủ trực tuyến thuộc quyền sở hữu riêng, như các máy chủ

để thương mại của RealNetwork và Microsoft, hoặc có thể máy chủ trực tuyến miền công cộng. Với máy chủ trực tuyến, audio/video có thể được truyền trên HTTP/TCP; hoặc có thể được truyền trên UDP sử dụng các giao thức lớp ứng dụng được thiết kế tốt hơn HTTP để phát trực tuyến audio/video.

Kiến trúc này yêu cầu hai máy chủ, như đưa ra trong Hình 6.2. Một máy chủ là máy chủ Web, phục vụ trang Web (bao gồm cả các siêu tệp). Máy chủ thứ hai là máy chủ trực tuyến, phục vụ các tệp audio/video. Hai máy chủ có thể chạy trên cùng một hệ thống đầu cuối hay trên hai hệ thống đầu cuối riêng biệt. Các bước thực hiện đối với kiến trúc này tương tự như các bước mô tả trong phần trên. Tuy nhiên, bây giờ bộ phát phương tiện yêu cầu tệp từ máy chủ phương tiện thay vì từ máy chủ Web, và bộ phát phương tiện và máy chủ trực tuyến có thể tương tác sử dụng các giao thức của bản thân chúng. Các giao thức này có thể cho phép người sử dụng tương tác đa dạng với luồng audio/video.

Hình Error! No text of specified style in document..27: Trực tuyến từ máy chủ trực tuyến đến bộ phát phương tiện

Trong kiến trúc Hình 6.2 có nhiều tùy chọn cho chuyển phát audio/video từ máy chủ trực

tuyến đến bộ phát phương tiện. Một phần các tùy chọn này được đưa ra dưới đây:

Audio/video được truyền trên UDP với tốc độ không đổi bằng tốc độ xử lý tại bên nhận (là tốc độ giải mã của audio/video). Ví dụ, nếu audio được nén sử dụng GSM với tốc độ 13 kbps, thì máy chủ tạo nhịp tệp audio nén tại 13 kbps. Ngay sau khi máy khách nhận được audio/video nén từ mạng, nó giải nén audio/video và phát lại.

Cũng giống như tùy chọn đầu tiên, nhưng bộ phát phương tiện phát chậm lại 2 đến 5 giây nhằm loại bỏ trễ do mạng gây ra. Máy khách thực hiện nhiệm vụ này bằng cách đưa phương tiện nén nhận được từ mạng vào bộ đệm khách hàng, như trên Hình 6.3. Một khi máy khách tìm nạp trước phương tiện vài giây, nó bắt đầu xử lý đầu ra bộ đệm. Đối với tùy chọn này và

Chương 6. Kết nối mạng đa phương tiện

tùy chọn trước, tốc độ lấp đầy 𝑥(𝑡) bằng tốc độ xử lý đầu ra d, trừ khi có mất gói, lúc này 𝑥(𝑡) nhỏ hơn một chút so với d.

Phương tiện được truyền trên TCP. Máy chủ đẩy tệp phương tiện vào socket TCP nhanh nhất có thể; máy khách (tức là bộ phát phương tiện) đọc từ socket TCP nhanh nhất có thể và đưa video nén vào bộ đệm của bộ phát phương tiện. Sau 2 đến 5 giây ban đầu, bộ phát phương tiện đọc từ bộ đệm của nó với tốc độ d và chuyển tiếp phương tiện nén đi giải nén và phát lại. Vì rằng TCP truyền lại các gói bị mất, nó có tiềm năng cung cấp chất lượng âm thanh tốt hơn UDP. Mặt khác, tốc độ lấp đầy 𝑥(𝑡) biến động theo thời gian do điều khiển tắc nghẽn và điều khiển luồng cửa sổ. Thực tế, sau khi gói bị mất, điều khiển tắc nghẽn TCP có thể giảm tốc độ tức thời nhỏ hơn d trong khoảng thời gian dài. Điều này có thể làm rỗng bộ đệm máy khách (quá trình này được biết đến như starvation) và gây ra tạm dừng không mong muốn ở đầu ra của luồng audio/video tại máy khách. Khi thông lượng TCP trung bình xấp xỉ hai lần tốc độ phương tiện, trực tuyến trên TCP cho kết quả hiện tượng rỗng bộ đệm là tối thiểu và trễ khởi tạo thấp.

Hình Error! No text of specified style in document..28: Bộ đệm khách hàng được lấp đầy và xử lý

Đối với tùy chọn thứ ba, trạng thái của 𝑥(𝑡) phụ thuộc rất nhiều vào kích cỡ của bộ đệm máy khách (lưu ý không nhầm lẫn với bộ đệm của bộ nhận TCP). Nếu bộ đệm này đủ lớn để giữ tất cả tệp phương tiện (có thể trong đĩa lưu trữ), thì TCP sẽ sử dụng tất cả băng thông tức thời sẵn có cho kết nối, do đó 𝑥(𝑡) có thể trở nên lớn hơn d rất nhiều. Nếu 𝑥(𝑡) trở nên lớn hơn d rất nhiều trong khoảng thời gian dài, thì phần lớn phương tiện được tìm nạp trước cho máy khách, và rỗng bộ đệm máy khách khó xảy ra. Mặt khác, nếu bộ đệm máy khách nhỏ, thì 𝑥(𝑡) sẽ thay đổi xung quanh tốc độ xử lý d. Rủi ro rỗng bộ đệm đối với máy khách sẽ lớn hơn nhiều trong trường hợp này.

Giao thứ c RTSP

Rất nhiều người sử dụng đa phương tiện Internet (đặc biệt với những người thường sử dụng

TV) sẽ muốn điều khiển phát lại phương tiện liên tục bằng cách tạm dừng phát lại, tìm lại vị trí phát lại về phía trước hay phía sau từ điểm hiện thời, tua trước có hiển thị, tua lại có hiển thị … Tính năng này tương tự như những gì người sử dụng có với đầu phát DVD video hay đầu phát CD khi nghe nhạc CD. Để cho phép người sử dụng điều khiển phát lại, bộ phát phương tiện và máy chủ cần một giao

Chương 6. Kết nối mạng đa phương tiện

thức để trao đổi các thông tin phát lại. Giao thức phát trực tuyến thời gian thực (RSTP) là một giao thức như vậy (RFC 2326).

Trước khi xem xét chi tiết RTSP, chúng ta chỉ ra các chức năng RTSP sẽ không thực hiện:

RTSP không định nghĩa phương thức nén của audio và video. 1.

RTSP không xác định audio và video được đóng gói vào các gói để truyền trên mạng như thế nào; đóng gói cho phương tiện phát trực tuyến có thể được cung cấp bằng RTP hay một giao thức riêng. Ví dụ, các máy chủ và bộ phát audio/video RealNetwork sử dụng RTSP để gửi các thông tin điều khiển đến nhau, nhưng bản thân dòng phương tiện có thể được đóng gói trong các gói tin RTP hay trong một khuôn dạng dữ liệu riêng nào đó.

RTSP không hạn chế phương tiện được phát trực tuyến được truyền tải như thế nào; nó có thể được truyền tải trên UDP hay TCP.

RTSP không hạn chế bộ phát phương tiện đệm audio/video như thế nào. Audio/video có thể được phát ngay sau khi nó bắt đầu đến máy khách, nó có thể được phát sau vài giây trễ, hay nó có thể được tải về toàn bộ trước khi phát.

Nếu RTSP không thực hiện các việc trên, nó sẽ làm việc gì? RTSP cho phép bộ phát phương

tiện điều khiển truyền dẫn dòng phương tiện. Như đưa ra ở trên, các hoạt động điều khiển bao gồm tạm dừng/tiếp tục, tua trước nhanh, tua lại. RTSP là giao thức ngoài dải. Cụ thể, các bản tin RTSP được gửi ngoài dải, trong khi dòng phương tiện với cấu trúc không được định nghĩa trong RTSP được xem như là “trong dải”. Các bản tin RTSP sử dụng số cổng khác (cổng số 544) so với dòng phương tiện. Đặc tả RTSP (RFC 2326) cho phép các bản tin được gửi đi trên TCP hoặc UDP.

Chúng ta nhớ lại trong chương 3 giao thức truyền tệp FTP cũng sử dụng khái niệm ngoài dải.

Cụ thể, FTP sử dụng hai cặp socket máy chủ/máy khách, mỗi cặp có số cổng riêng: một cặp socket máy chủ/máy khách hỗ trợ kết nối TCP truyền thông tin điều khiển; cặp socket máy chủ/máy khách còn lại hỗ trợ kết nối TCP thực sự truyền tệp. Kênh RTSP có nhiều điểm giống kênh điều khiển của FTP.

Bây giờ chúng ta sẽ xem xét một ví dụ RTSP đơn giản, được minh họa trên hình 6.4. Trình duyệt trước tiên yêu cầu tệp mô tả trình diễn từ máy chủ Web. Tệp mô tả trình diễn có thể có các tham chiếu đến một loạt tệp phương tiện liên tục cũng như lệnh để đồng bộ hóa các tệp phương tiện liên tục. Mỗi tham chiếu tới tệp phương tiện liên tục bắt đầu bằng phương thức URL, rtsp://. Dưới đây chúng ta sẽ đưa ra một tệp trình diễn điển hình. Trong trình diễn này dòng audio và video được phát song song và đồng bộ lip sync (như một phần của cùng một nhóm). Đối với dòng audio, bộ phát phương tiện có thể chọn (chuyển) giữa hai bản ghi audio, bản ghi trung thực thấp (lofi) và bản ghi trung thực cao (hifi). Khuôn dạng tệp này được sử dụng trong nhiều sản phẩm phát trực tuyến để định nghĩa trình diễn đa phương tiện đồng bộ.

Chương 6. Kết nối mạng đa phương tiện

Hình Error! No text of specified style in document..29: Tương tác giữa máy khách và máy chủ sử dụng RTSP

Twister

e=”PCMU/8000/1”

src=”rtsp://audio.example.com/twister/audio.en/lofi”>

e=”DVI4/16000/2” pt=”90 DVI4/8000/1”

src=”rtsp://audio.example.com/twister/audio.en/hifi”>

src=”rtsp://video.example.com/twister/video”>

Chương 6. Kết nối mạng đa phương tiện

Máy chủ đóng gói tệp mô tả trình diễn trong bản tin đáp ứng HTTP và gửi bản tin tới trình

duyệt. Khi trình duyệt nhận được bản tin đáp ứng HTTP, trình duyệt gọi bộ phát phương tiện (tức là ứng dụng hỗ trợ) dựa trên trường loại nội dung của bản tin. Tệp mô tả trình diễn bao gồm các tham chiếu đến dòng phương tiện, sử dụng phương thức URL rtsp:// như trong ví dụ trên. Trong hình 6.4, sau đó bộ phát và máy chủ gửi cho nhau một loạt bản tin RTSP. Bộ phát gửi yêu cầu RTSP PLAY cho audio lo-fi, và máy chủ đáp ứng bằng bản tin RTSP OK. Tại thời điểm này, máy chủ trực tuyến bơm audio lo-fi vào kênh trong dải của nó. Sau đó, bộ phát phương tiện gửi yêu cầu RTSP PAUSE, và máy chủ đáp ứng bằng bản tin RTSP OK. Khi người sử dụng kết thúc, bộ phát phương tiện gửi yêu cầu RTSP TEARDOWN, và máy chủ khẳng định bằng bản tin RTSP OK.

Chúng ta sẽ xem xét các bản tin RTSP thực tế. Dưới đây là một ví dụ đơn giản của một phiên RTSP giữa máy khách (C:) và máy chủ (S:):

C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0

Cseq: 1

Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 OK

Cseq: 1

Sesion: 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Range: npt=0-

Cseq: 2

Sesion: 4231

S: RTSP/1.0 200 OK

Cseq: 2

Sesion: 4231

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Range: npt=37

Cseq: 3

Sesion: 4231

S: RTSP/1.0 200 OK

Cseq: 3

Sesion: 4231

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Cseq: 4

Sesion: 4231

S: RTSP/1.0 200 OK

Chương 6. Kết nối mạng đa phương tiện

Cseq: 4

Sesion: 4231

Cần lưu ý các điểm tương tự giữa HTTP và RTSP. Tất cả các bản tin yêu cầu và đáp ứng đều

trên dạng văn bản ASCII, máy khách sử dụng các phương thức chuẩn hóa (SETUP, PLAY, PAUSE,…) và máy chủ đáp ứng bằng các mã trả lời. Tuy nhiên có một điều khác nhau quan trọng là máy chủ RTSP duy trì theo dõi trạng thái của máy khách cho từng phiên RTSP đang diễn ra. Ví dụ, máy chủ duy trì theo dõi liệu máy khách đang trong trạng thái khởi tạo, trạng thái đang phát, hay trạng thái tạm dừng. Số của phiên và thứ tự là một phần của mỗi bản tin yêu cầu và đáp ứng giúp máy chủ theo dõi trạng thái của phiên. Số của phiên là cố định trong suốt toàn bộ phiên; máy khách tăng số thứ tự mỗi lần nó gửi một bản tin mới: máy chủ phản hồi lại số của phiên và số thứ tự hiện thời.

Như đã đưa ra trong ví dụ, máy khách khởi tạo phiên bằng yêu cầu SETUP, cung cấp URL của

tệp được phát trực tuyến và phiên bản RTSP. Bản tin bao gồm số của cổng máy khách mà phương tiện phải gửi tới. Bản tin thiết lập cũng chỉ ra rằng phương tiện phải được gửi trên UDP sử dụng giao thức gói hóa RTP (phần 6.4). Chú ý rằng trong ví dụ này, bộ phát lựa chọn không phát lại toàn bộ trình diễn, mà thay vào đó chỉ phát một phần lofi của trình diễn.

RTSP thực tế có khả năng thực hiện nhiều hơn những gì mô tả trong phần giới thiệu trên. Cụ thể, RTSP có các chức năng cho phép máy khách phát trực tuyến đến máy chủ (ví dụ, để ghi lại). RTSP được RealNetworks – một trong những công ty hàng đầu về phát trực tuyến audio/video - chấp nhận.

Giải pháp đảm bảo chất lượng dịch vụ đa phương tiện trên Internet

Giao thức lớp mạng Internet là IP cung cấp dịch vụ best-effort. Điều đó có nghĩa là dịch vụ nỗ

lực tối đa để chuyển từng gói dữ liệu từ nguồn đến đích càng nhanh càng tốt. Tuy nhiên, nó hoàn toàn không đưa ra hứa hẹn nào về mức độ của trễ toàn trình cho từng gói tin, hay về mức độ jitter và mất gói trong luồng gói tin. Việc thiếu đảm bảo về trễ và jitter gói tin đưa đến các thách thức quan trọng trong thiết kế ứng dụng đa phương tiện thời gian thực như thoại Internet và hội nghị video thời gian thực, chúng nhạy cảm sâu sắc với trễ, jitter và mất gói tin.

Trong phần này, chúng ta sẽ tìm hiểu một số các phương pháp có thể cải thiện hiệu năng của ứng dụng đa phương tiện trên mạng best-effort. Trọng tâm của chúng ta sẽ là các kỹ thuật trên lớp ứng dụng, tức là các giải pháp không đòi hỏi bất cứ thay đổi nào trên mạng lõi hay thậm chí trên lớp truyền tải (giao vận) tại các trạm chủ đầu cuối. Chúng ta trước hết mô tả ảnh hưởng của mất gói, trễ, và jitter lên ứng dụng đa phương tiện. Sau đó chúng ta sẽ bao hàm các kỹ thuật phục hồi từ những suy giảm này. Chúng ta cũng sẽ mô tả mạng phân bố nội dung và việc cung cấp dư thừa tài nguyên có thể được sử dụng để tránh các suy giảm như thế nào.

Hạn chế của dịch vụ best-effort

Chúng ta đã đề cập đến ở trên dịch vụ best-effort có thể dẫn đến mất gói, trễ toàn trình quá

mức, và jitter. Chúng ta sẽ xem xét các vấn đề này kĩ hơn. Cụ thể chúng ta sẽ thảo luận các cơ chế này trong ngữ cảnh ứng dụng thoại Internet. Tình huống này cũng giống như đối với ứng dụng hội nghị video thời gian thực. 97

Chương 6. Kết nối mạng đa phương tiện

Người nói chuyện trong ví dụ thoại Internet tạo ra tín hiệu audio bao gồm các tiếng nói và

khoảng lặng xen kẽ. Để tiết kiệm băng thông, ứng dụng thoại Internet chỉ tạo gói tin trong khoảng có tiếng nói. Trong khoảng có tiếng nói bên gửi tạo ra các byte tốc độ 8,000 byte một giây, và cứ 20 ms bên gửi lại tập hợp byte vào một khúc dữ liệu. Do đó, số byte trong một khúc dữ liệu là 160 byte. Một tiêu đề đặc biệt được đính kèm mỗi khúc dữ liệu, nội dung của nó sẽ xem xét bên dưới. Khúc dữ liệu và tiêu đề của nó được đóng gói trong đoạn UDP, thông qua cuộc gọi tới giao diện socket. Do đó, trong khoảng có tiếng nói, đoạn UDP được gửi 20 ms một lần.

Nếu mỗi gói tin đến được bên nhận và có trễ toàn trình không đổi và nhỏ, thì các gói tin đến bên nhận định kì 20 ms trong khoảng có tiếng nói. Trong điều kiện lý tưởng này, bên nhận có thể đơn giản phát lại từng khúc dữ liệu ngay lập tức sau khi nhận được. Nhưng đáng tiếc một số gói tin có thể bị mất và phần lớn gói tin không có cùng trễ toàn trình, thậm chí cả khi trong mạng Internet ít tắc nghẽn. Vì lí do này, bên nhận phải quan tâm xác định (1) khi nào phát lại khúc dữ liệu (2) làm gì với khúc dữ liệu bị mất.

Mất gói

Xem xét một đoạn UDP được tạo bởi ứng dụng thoại Internet. Đoạn UDP được đóng gói

trong gói dữ liệu IP. Khi gói dữ liệu truyền qua mạng, nó đi qua các bộ đệm (tức là hàng đợi) trong bộ định tuyến để truy nhập vào liên kết ra bên ngoài. Có khả năng là một hay nhiều bộ đệm trên đường định tuyến từ bên gửi đến bên nhận bị đầy và không thể chấp nhận gói dữ liệu IP. Trong trường hợp này gói dữ liệu IP bị loại bỏ, không bao giờ đến được ứng dụng bên nhận.

Mất gói có thể được loại bỏ bằng cách gửi các gói tin trên TCP thay cho trên UDP. Chúng ta cần nhớ lại là TCP truyền lại các gói tin không đến được đích. Tuy nhiên, cơ chế truyền lại các gói tin thường được xem như không được chấp nhận cho ứng dụng tương tác thời gian thực như thoại Internet, vì rằng chúng làm tăng trễ toàn trình. Hơn thế nữa, do điều khiển tắc nghẽn TCP, tốc độ truyền dẫn tại bên gửi có thể giảm theo mất gói tới tốc độ thấp hơn tốc độ xử lý đầu ra tại bên nhận. Với các lý do này, phần lớn các ứng dụng Internet đang hiện có chạy trên UDP và không bận tâm truyền lại gói bị mất. UDP cũng được sử dụng bởi Skype trừ phi người sử dụng ở đằng sau NAT hay tường lửa ngăn chặn các đoạn UDP (trong trường hợp này thì TCP được sử dụng).

Nhưng làm mất gói không phải là thảm họa như nhiều người nghĩ. Thực vậy, tốc độ mất gói trong khoảng 1 đến 20 phần trăm có thể chấp nhận được, phụ thuộc vào tiếng nói được mã hóa và truyền như thế nào, và mất gói được che dấu tại bên nhận như thế nào. Ví dụ, sửa lỗi tiến (FEC) có thể trợ giúp che dấu mất gói. Chúng ta sẽ thấy bên dưới rằng với FEC, thông tin dư thừa được truyền cùng với thông tin gốc sao cho một số dữ liệu gốc bị mất có thể được phục hồi từ thông tin dư thừa. Tuy vậy, nếu một hay nhiều liên kết giữa bên gửi và bên nhận bị tắc nghẽn nghiêm trọng, mất gói vượt quá 10 đến 20 phần trăm (mặc dù tốc độ này hiếm khi xảy ra trong mạng cung cấp), thì thực tế không có biện pháp nào có thể thực hiện để đạt được mức chất lượng âm thanh có thể chấp nhận. Rõ ràng, dịch vụ best-effort có các giới hạn của nó.

Trễ toàn trình

Chương 6. Kết nối mạng đa phương tiện

Trễ toàn trình là tích lũy của trễ truyền dẫn, xử lý, và hàng đợi trong bộ định tuyến; trễ truyền lan trên các liên kết; và trễ xử lý của hệ thống cuối. Đối với các ứng dụng audio tương tác cao, như thoại Internet, trễ toàn trình nhỏ hơn 150 ms người nghe không cảm nhận được; trễ giữa 150 ms và 400 ms có thể chấp nhận được nhưng không lý tưởng; và trễ vượt quá 400 ms có thể cản trở nghiêm trọng tính tương tác trong hội thoại tiếng nói. Bên nhận của ứng dụng thoại Internet sẽ thường không quan tâm đến bất cứ gói tin nào trễ hơn ngưỡng cho trước, ví dụ, hơn 400 ms. Do đó, các gói tin bị trễ quá ngưỡng sẽ bị mất hiệu quả.

Jitter

Thành phần quan trọng của trễ toàn trình là trễ hàng đợi trong các bộ định tuyến. Do các trễ

biến thiên này trong mạng, thời gian từ khi gói tin được tạo ra tại nguồn đến khi nó nhận được tại bên nhận có thể biến động đối với các gói tin. Hiện tượng này gọi là jitter.

Ví dụ, xem xét hai gói tin liên tiếp trong cùng một khoảng tiếng nói trong ứng dụng thoại

Internet. Bên gửi gửi gói tin thứ hai sau khi gửi gói tin thứ nhất 20 ms. Nhưng tại bên nhận, khoảng cách giữa các gói tin này có thể trở nên lớn hơn 20 ms. Để hiểu điều này, giả sử gói tin thứ nhất đến hàng đợi gần như rỗng tại bộ định tuyến, nhưng trước khi gói tin thứ hai đến hàng đợi một lượng lớn gói tin từ các nguồn khác đến cùng hàng đợi này. Vì rằng gói thứ nhất có trễ hàng đợi nhỏ và gói tin thứ hai có trễ hàng đợi lớn tại bộ định tuyến này, gói tin thứ nhất và thứ hai trở nên cách nhau hơn 20 ms. Khoảng cách giữa các gói tin liên tiếp cũng có thể trở nên nhỏ hơn 20 ms. Để hiểu điều này, chúng ta lại xem xét hai gói tin liên tiếp nhau trong cùng một khoảng tiếng nói. Giả sử gói tin đầu tiên nhập vào cuối của hàng đợi đang có số lượng lớn các gói tin, và gói tin thứ hai đến hàng đợi trước khi các gói tin từ các nguồn khác đến hàng đợi. Trong trường hợp này, hai gói tin đứng liền nhau trong hàng đợi. Nếu thời gian cần để truyền gói tin trên liên kết ra ngoài của bộ định tuyến nhỏ hơn 20 ms thì gói tin thứ nhất và thứ hai cách nhau một khoảng nhỏ hơn 20 ms.

Tình huống tương tự như lái một chiếc xe trên đường. Giả sử bạn A và bạn B mỗi người lái một chiếc xe từ Hà nội đi Hải phòng. Bạn A và bạn B có cùng một kiểu lái, và cùng tốc độ 50 km/h. Cuối cùng, giả sử bạn B bắt đầu lên đường một giờ trước bạn A. Vậy thì phụ thuộc vào lưu lượng, bạn A có thể đến Hải phòng sau hoặc chưa đến 1 giờ muộn hơn so với bạn B.

Nếu bên nhận bỏ qua sự xuất hiện của jitter và phát lại các khúc ngay lập tức khi nhận được,

thì có thể dễ dàng dẫn đến chất lượng âm thanh trở nên khó hiểu tại bên nhận. May thay, jitter thường có thể được loại bỏ bằng cách sử dụng số thứ tự, nhãn thời gian, và trễ phát lại, được thảo luận sau đây.

Loại bỏ jitter tại bên nhận cho audio

Đối với ứng dụng audio như thoại Internet hay audio theo yêu cầu (audio on demand) bên

nhận phải cố gắng cung cấp phát đồng bộ các khúc âm thanh trong sự xuất hiện của jitter mạng ngẫu nhiên; ứng dụng video cũng thường có các yêu cầu tương tự. Điều này thường được thực hiện bằng kết hợp ba cơ cấu sau:

Chương 6. Kết nối mạng đa phương tiện

Bắt đầu mỗi khúc bằng một số thứ tự. Bên gửi tăng số thứ tự lên một đơn vị mỗi khi có một gói tin được tạo ra.

Bắt đầu mỗi khúc bằng một nhãn thời gian. Bên gửi gán nhãn cho mỗi khúc với thời gian khúc được tạo ra.

Làm trễ phát lại các khúc tại bên nhận. Trễ phát lại của các khúc audio nhận được phải đủ dài sao cho phần lớn các gói tin nhận được trước thời gian phát đã được lập lịch của chúng. Trễ phát này có thể là cố định trong suốt phiên audio hay thay đổi thích nghi trong vòng đời phiên audio. Các gói tin không đến được trước thời gian phát lại đã được lập lịch của chúng được xem như bị mất và không tính đến; như lưu ý ở trên, bên nhận có thể sử dụng một vài dạng nội suy tiếng nói để bù mất gói này.

Bây giờ chúng ta sẽ thảo luận ba cơ chế này, khi kết hợp lại có thể giảm nhẹ hay loại trừ ảnh

hưởng của jitter. Chúng ta xem xét hai chiến lược phát lại: trễ phát cố định và trễ phát thích nghi.

Trễ phát cố định

Với chiến lược trễ cố định này, bên nhận cố gắng phát lại từng khúc chính xác q ms sau khi khúc được tạo ra. Do đó nếu khúc được gán nhãn thời gian tại thời điểm t, bên nhận phát khúc này tại thời điểm t+q, giả thiết là khúc đến bên nhận đúng thời hạn. Các gói tin đến sau thời gian phát đã được lập lịch của chúng bị loại bỏ và coi như bị mất.

Lựa chọn cho q là gì? Thoại Internet có thể hỗ trợ trễ đến 400 ms, mặc dù đạt được trải

nghiệm tương tác thỏa mãn hơn với giá trị q nhỏ hơn. Mặt khác, nếu q được thiết lập nhỏ hơn 400 ms nhiều thì rất nhiều gói tin có thể không đến kịp thời hạn phát lại đã được lập lịch do jitter gói tin mạng gây ra. Nói một cách đơn giản, nếu thường xảy ra phương sai trễ toàn trình lớn, thích hợp hơn nếu sử dụng giá trị q lớn; mặt khác, nếu trễ nhỏ và phương sai trễ cũng nhỏ, thích hợp hơn nếu sử dụng giá trị q nhỏ, có lẽ nhỏ hơn 150 ms.

Điểm cân bằng giữa trễ phát lại và mất gói được minh họa trong hình 6.5. Trên hình này đưa

ra thời gian gói tin được tạo ra và phát lại trong một khoảng có tiếng nói. Xem xét hai trễ ban đầu phân biệt. Đồ thị thang tận cùng bên trái diễn tả bên gửi tạo ra các gói tin định kì mỗi khoảng thời gian – ví dụ, 20 ms. Gói tin đầu tiên trong khoảng có tiếng nói được nhận tại thời điểm r. Trên hình vẽ, thời gian đến của các gói tin liên tục không cách đều nhau do jitter của mạng.

Đối với lịch biểu phát đầu tiên, trễ phát lại cố định ban đầu được thiết lập bằng p-r. Với lịch biểu này, gói tin thứ tư không kịp đến đúng thời hạn đã được lập lịch, và coi như bị mất. Đối với lịch biểu phát thứ hai, trễ phát lại cố định ban đầu được thiết lập bằng p’-r. Đối với lịch biểu này, tất cả gói tin đều đến trước thời hạn phát đã được lập lịch, và do đó không có mất gói.

100

Chương 6. Kết nối mạng đa phương tiện

Hình Error! No text of specified style in document..30: Mất gói đối với các trễ phát lại cố định khác nhau

Trễ phát thích nghi

Ví dụ trên biểu diễn điểm cân bằng trễ-mất gói xảy ra khi thiết kế chiến lược với trễ phát lại

cố định. Bằng cách lấy trễ phát lại ban đầu lớn, phần lớn gói tin sẽ đến kịp thời hạn và mất gói là không đáng kể; tuy nhiên, đối với các dịch vụ tương tác như thoại Internet, trễ dài có thể trở thành phiền phức nếu nó không được chấp nhận. Lý tưởng nhất là chúng ta có thể mong muốn trễ phát lại nhỏ nhất với điều kiện mất gói nhỏ hơn vài phần trăm.

Phương pháp tự nhiên giải quyết vấn đề cân bằng này là ước lượng trễ mạng và phương sai, và điều chỉnh trễ phát lại tương ứng tại điểm đầu của khoảng có tiếng nói. Điều chỉnh thích nghi trễ phát lại này tại điểm đầu của khoảng có tiếng nói sẽ làm cho khoảng lặng người gửi được nén lại và kéo dài ra; tuy nhiên, nén và kéo dãn khoảng lặng số lượng nhỏ thì không đáng chú ý trong tiếng nói.

Chúng ta sẽ mô tả thuật toán chung bên nhận có thể sử dụng để điều chỉnh thích nghi trễ

phát lại của nó. Giả sử:

𝑡𝑖 = nhãn thời gian của gói tin thứ i = thời gian gói tin được tạo ra tại bên gửi;

𝑟𝑖 = thời gian gói tin thứ i nhận được tại bên nhận;

𝑝𝑖 = thời gian gói tin thứ i được phát lại tại bên nhận.

Trễ mạng toàn trình của gói tin thứ i là 𝑟𝑖 − 𝑡𝑖. Do jitter trễ mạng này sẽ thay đổi giữa các gói

tin. Giả sử ký hiệu 𝑑𝑖 là ước lượng của trễ mạng trung bình đến khi nhận được gói tin thứ i. Ước lượng này được cấu trúc lại từ các nhãn thời gian như sau:

𝑑𝑖 = 1 − 𝑢 𝑑𝑖−1 + 𝑢(𝑟𝑖 − 𝑡𝑖)

Trong đó u là hằng số cố định (ví dụ u=0.01). Do đó, 𝑑𝑖 là trung bình mịn nhất của trễ mạng quan sát 𝑟1 − 𝑡1, …, 𝑟𝑖 − 𝑡𝑖. Ước lượng chọn trọng số lớn hơn cho các trễ mạng quan sát được hiện thời so với 101

Chương 6. Kết nối mạng đa phương tiện

trễ mạng quan sát được trong quá khứ. Dạng ước lượng này không phải hoàn toàn mới mẻ, ý tưởng tương tự đã được sử dụng nhiều để ước lượng RTT, lưu lượng … Ký hiệu 𝜈𝑖 là ước lượng của vi sai trung bình trễ từ trễ trung bình ước lượng được. Ước lượng này cũng được cấu trúc lại từ nhãn thời gian như sau:

𝜈𝑖 = 1 − 𝑢 𝜈𝑖−1 + 𝑢|𝑟𝑖 − 𝑡𝑖 − 𝑑𝑖|

Ước lượng 𝑑𝑖 và 𝜈𝑖 được tính toán cho từng gói tin nhận được, mặc dù chúng được sử dụng chỉ để xác định điểm phát lại cho gói tin ban đầu trong khoảng có tiếng nói.

Một khi đã tính toán các ước lượng này, bên nhận áp dụng thuật toán sau để phát lại gói tin.

Nếu gói tin i là gói tin đầu tiên của khoảng có tiếng nói, thời gian phát lại của nó 𝑝𝑖 được tính như sau:

𝑝𝑖 = 𝑡𝑖 + 𝑑𝑖 + 𝐾𝜈𝑖

Trong đó K là hằng số dương (ví dụ K=4). Mục tiêu của 𝐾𝜈𝑖 là thiết lập thời gian phát lại đủ xa trong tương lai để sao cho chỉ một phần nhỏ của các gói tin đến trong khoảng có tiếng nói sẽ bị mất do đến muộn. Điểm phát lại cho bất kì gói tin tiếp theo nào trong khoảng có tiếng nói được tính như khoảng trống từ thời điểm gói tin đầu tiên trong khoảng có tiếng nói được phát lại. Cụ thể, giả sử

𝑞𝑖 = 𝑝𝑖 − 𝑡𝑖

Là độ dài thời gian từ khi gói tin đầu tiên trong khoảng có tiếng nói được tạo ra đến khi nó được phát lại. Nếu gói tin j cũng thuộc khoảng có tiếng nói này thì nó được phát lại tại thời điểm

𝑝𝑗 = 𝑡𝑗 + 𝑞𝑖

Thuật toán mô tả trên có vẻ rất hoàn hảo nếu giả thiết rằng bên nhận có thể biết gói tin nào là gói tin đầu tiên trong khoảng có tiếng nói. Nếu không có mất gói, bên nhận có thể xác định gói tin i có phải là gói tin đầu tiên của khoảng có tiếng nói hay không bằng cách so sánh nhãn thời gian của gói tin thứ i với nhãn thời gian của gói tin thứ (i-1). Thực vậy, nếu 𝑡𝑖 − 𝑡𝑖−1 > 20𝑚𝑠 thì bên nhận biết rằng gói tin thứ i bắt đầu một khoảng có tiếng nói mới. Nhưng giờ giả thiết thỉnh thoảng có mất gói. Trong trường hợp này, hai gói tin liên tiếp nhau nhận tại đích có thể có nhãn thời gian lệch nhau hơn 20 ms khi thuộc cùng một khoảng có tiếng nói. Do vậy ở đây số thứ tự đặc biệt hữu dụng. Bên nhận có thể sử dụng số thứ tự để xác định sự khác biệt lớn hơn 20 ms trong nhãn thời gian là do khoảng có tiếng nói mới hay do mất gói.

Khôi phục mất gói

Chúng ta đã thảo luận tương đối chi tiết ứng dụng thoại Internet có thể đối phó với jitter gói

tin như thế nào. Bây giờ chúng ta sẽ mô tả một số phương án nỗ lực giữ chất lượng audio ở mức chấp nhận được khi xuất hiện mất gói. Các phương án này gọi là phương án phục hồi mất gói. Ở đây chúng ta định nghĩa mất gói trên nghĩa rộng: gói tin bị mất hoặc là nếu nó không bao giờ đến được bên nhận hoặc nó đến sau thời hạn phát lại đã được lập lịch. Ví dụ thoại Internet sẽ lại được sử dụng làm ngữ cảnh để mô tả phương án hồi phục mất gói.

102

Chương 6. Kết nối mạng đa phương tiện

Như đã đưa ra trong phần trên, gửi lại các gói tin bị mất nói chung không thích hợp trong

ứng dụng thời tương tác gian thực như thoại Internet. Thực vậy, truyền lại gói tin đã lỡ thời hạn phát lại hoàn toàn không đạt mục đích gì cả. Và truyền lại gói tin tràn bộ đệm trong hàng đợi bộ định tuyến bình thường không thể thực hiện đủ nhanh. Với các nguyên nhân trên, ứng dụng thoại Internet thường sử dụng một số loại phương án dự báo mất gói. Hai loại phương án dự báo mất gói là sửa lỗi tiến (FEC) và đan xen.

Sửa lỗi tiến (FEC)

Ý tưởng cơ bản của FEC là thêm thông tin dư thừa vào dòng gói tin gốc. Đổi lại là các chi phí

do tăng tốc độ truyền audio của dòng lưu lượng, thông tin dư thừa có thể được sử dụng để tái tạo lại phiên bản gần đúng hay chính xác của gói tin bị mất. Chúng ta sẽ sơ lược hai cơ chế FEC đơn giản. Cơ chế thứ nhất gửi khúc mã hóa dư thừa sau mỗi n khúc dữ liệu. Khúc dư thừa đạt được bằng toán tử loại trừ OR n khúc dữ liệu gốc. Trong phương pháp này nếu một gói trong nhóm n+1 gói bị mất thì bên nhận có thể hoàn toàn tái tạo lại gói tin bị mất. Nhưng nếu hai hay nhiều hơn các gói tin trong nhóm bị mất, bên nhận không thể tái tạo lại gói tin bị mất. Bằng cách duy trì n+1 (là kích cỡ nhóm) nhỏ phần lớn các gói tin bị mất có thể được phục hồi khi mất gói không quá mức ngưỡng. Tuy nhiên, kích cỡ nhóm càng nhỏ, tỉ lệ tăng của tốc độ truyền dòng audio càng lớn. Đặc biệt, tốc độ truyền tăng theo hệ số 1/n; ví dụ nếu n=3 thì tốc độ truyền dẫn tăng 33%. Hơn thế nữa, mô hình đơn giản này tăng trễ phát lại, do bên nhận phải đợi nhận toàn bộ nhóm gói tin trước khi bắt đầu phát lại. Chi tiết hơn về FEC đối với truyền tải đa phương tiện có thể xem trong RFC 2733.

Cơ chế FEC thứ hai là gửi dòng audio phân giải thấp như thông tin dư thừa. Ví dụ, bên gửi có thể tạo một dòng audio danh định và một dòng audio phân giải thấp, tốc độ thấp tương ứng. (Dòng danh định có thể là mã hóa PCM 64 kbps, và dòng chất lượng thấp có thể là mã hóa GSM 13 kbps.) Dòng tốc độ thấp được đưa ra như dòng dư thừa. Trên hình 6.6 bên gửi tạo gói tin thứ n bằng cách lấy khúc thứ n từ dòng danh định và gắn thêm vào nó khúc thứ (n-1) từ dòng dư thừa. Bằng phương pháp này, bất cứ khi nào có các gói rời rạc bị mất, bên nhận có thể che dấu mất gói bằng cách phát lại khúc mã hóa tốc độ thấp đến trong gói tin tiếp theo. Tất nhiên, khúc tốc độ thấp sẽ cho chất lượng thấp hơn so với khúc danh định. Tuy nhiên, dòng bao gồm phần lớn các khúc chất lượng cao, một vài khúc chất lượng thấp, và không có khúc nào bị mất, về tổng thể sẽ cho chất lượng audio tốt. Lưu ý rằng trong thiết kế này, bên gửi chỉ phải nhận hai gói tin trước khi bắt đầu phát lại, do đó trễ phát tăng thêm rất nhỏ. Hơn nữa, nếu mã hóa tốc độ thấp nhỏ hơn nhiều so với mã hóa danh định, thì mức tăng tốc độ truyền sẽ nhỏ.

103

Chương 6. Kết nối mạng đa phương tiện

Hình Error! No text of specified style in document..31: Gắn kèm thông tin dư thừa chất lượng thấp

Nhằm đối phó với mất các gói liên tiếp chúng ta có thể sử dụng một phương án đơn giản.

Thay cho việc chỉ gắn thêm khúc tốc độ thấp thứ (n-1) vào khúc danh định thứ n, bên gửi có thể gắn thêm khúc tốc độ thấp thứ (n-1) và (n-2), hoặc gắn thêm khúc tốc độ thấp thứ (n-1) và (n-3), và cứ tiếp tục như vậy. Bằng cách gắn thêm nhiều khúc tốc độ thấp vào mỗi khúc danh định, chất lượng audio tại bên gửi trở nên chấp nhận được đối với nhiều môi trường best-effort khắc nghiệt khác nhau. Mặt khác, các khúc bổ sung tăng băng thông truyền dẫn và trễ phát.

Đan xen

Trong một phương án khác để dự phòng truyền dẫn, ứng dụng thoại Internet có thể gửi audio đan xen. Như đưa ra trên hình 6.7, bên gửi sắp xếp lại các đơn vị dữ liệu audio trước khi truyền đi, sao cho các đơn vị liền nhau ban đầu được tách ra một khoảng cách trong dòng thông tin truyền dẫn. Đan xen có thể giảm thiểu ảnh hưởng của mất gói. Ví dụ, nếu các đơn vị có độ dài 5ms và khúc có độ dài 20 ms (tức là 4 đơn vị trên 1 khúc), thì khúc đầu tiên có thể chứa đơn vị 1,5,9 và 13; khúc thứ hai có thể chứa đơn vị 2,6,10, và 14; … Hình 6.7 chỉ ra rằng mất một gói đơn từ dòng đan xen dẫn đến nhiều gián đoạn nhỏ trên dòng tái tạo lại, ngược lại với một gián đoạn lớn có thể xảy ra trên dòng không đan xen.

104

Chương 6. Kết nối mạng đa phương tiện

Hình Error! No text of specified style in document..32: Gửi audio đan xen

Đan xen có thể tăng đáng kể chất lượng cảm nhận của dòng audio. Nó cũng có chi phí thấp.

Một nhược điểm rõ ràng của đan xen là nó tăng trễ. Điều này hạn chế sử dụng nó trong ứng dụng tương tác như thoại Internet, mặc dù nó có thể thực hiện rất tốt cho phát trực tuyến audio lưu trữ. Ưu điểm lớn nhất của đan xen là nó không làm tăng các yêu cầu băng thông của dòng thông tin.

Sửa dòng audio bị hỏng dựa trên bên nhận

Mô hình phục hồi này dựa trên bên nhận cố gắng tạo ra thay thế tương tự như gói tin gốc cho gói tin bị mất. Điều này là có khả năng do tín hiệu audio, và đặc biệt là giọng nói, phần lớn thể hiện tính chất tự tương tự ngắn hạn. Như vậy, các kỹ thuật này hoạt động đối với các tỉ lệ mất gói tương đối thấp (nhỏ hơn 15%) và gói tin nhỏ (4-40 ms). Khi độ dài bị mất gần đến độ dài một đơn âm (5-100 ms) các kỹ thuật này mất tác dụng, do toàn bộ âm vị có thể bị mất và không nghe thấy.

Có lẽ dạng đơn giản nhất của phục hồi dựa trên bên nhận là lặp lại gói tin. Lặp lại gói tin thay thế cho các gói tin bị mất bằng bản sao của các gói tin đã đến ngay trước gói bị mất. Dạng phục hồi này có độ phức tạp tính toán thấp và thực hiện tương đối tốt. Một dạng khác của phục hồi dựa trên bên nhận là phép nội suy sử dụng audio trước và sau gói bị mất để nội suy gói tin thích hợp nhằm bù đắp phần bị mất. Phép nội suy phần nào thực hiện tốt hơn so với lặp lại gói tin nhưng độ tính toán phức tạp hơn đáng kể.

Phân bố đa phương tiện trên mạng Internet: Mạng phân tán nội dung

Với tốc độ phát trực tuyến video trong dải từ hàng trăm kbps đối với video phân giải thấp đến hàng chục Mbps đối với video DVD, nhiệm vụ của phát trực tuyến video lưu trữ theo yêu cầu đến số lượng lớn người sử dụng phân tán về địa lý là một thử thách khó khăn. Giải pháp đơn giản nhất có thể là lưu trữ video trong một máy chủ đơn và đơn giản phát trực tuyến video từ máy chủ video (cụm máy chủ) tới máy khách đối với từng yêu cầu của máy khách như trình bày trong phần

105

Chương 6. Kết nối mạng đa phương tiện

6.2. Nhưng có hai vấn đề hiển nhiên trong giải pháp này. Thứ nhất, vì rằng máy khách có thể rất xa máy chủ, gói tin máy chủ-tới-máy khách có thể phải đi qua nhiều ISP, tăng đáng kể khả năng trễ và mất gói. Thứ hai, nếu một bộ video là rất phổ biến, có nhiều khả năng là bộ video này sẽ được gửi nhiều lần qua cùng một ISP (và trên cùng một số các liên kết truyền thông), do đó tiêu tốn một lượng băng thông đáng kể. Trong chương 2, chúng ta đã biết lưu đệm có thể giảm nhẹ vấn đề này như thế nào. Mặc dù chúng ta thảo luận lưu đệm trên phạm vi của nội dung Web truyền thống, rõ ràng là lưu đệm cũng thích hợp cho nội dung đa phương tiện như audio và video lưu trữ. Trong phần này chúng ta sẽ xem xét mạng phân tán nội dung (content distribution network – CDN) cung cấp một giải pháp khác để phân bố các nội dung đa phương tiện lưu trữ (cũng như phân bố nội dung Web truyền thống).

CDN dựa trên triết lý nếu máy khách không thể vào được nội dung (do đường best-effort từ

đường máy chủ-đến-máy khách không hỗ trợ phát trực tuyến video), thì nội dung phải được đem đến cho máy khách. CDN vì vậy sử dụng mô hình khác với lưu đệm Web. Đối với CDN, khách hàng trả tiền không phải là ISP, mà nhà cung cấp nội dung. Nhà cung cấp nội dung video phân tán (như CNN) trả tiền cho công ty CDN (như Akamai) để đưa video của họ đến người sử dụng yêu cầu với trễ nhỏ nhất có thể.

Công ty CDN thường cung cấp dịch vụ phân tán nội dung của họ như sau:

Công ty CDN thiết lập hàng trăm máy chủ trên khắp Internet. Công ty CDN thường đặt các máy chủ tại các trung tâm dữ liệu, thường là trong ISP cấp thấp hơn, gần mạng truy nhập ISP và máy khách.

CDN tái tạo nội dung của khách hàng của nó trong các máy chủ CDN. Bất cứ khi nào khách hàng cập nhật nội dung, CDN phân bố lại nội dung mới tới các máy chủ CDN.

Công ty CDN cung cấp cơ chế sao cho khi máy khách yêu cầu nội dung, nội dung sẽ được một máy chủ CDN cung cấp mà máy chủ này có thể phân phối tốt nhất đến máy khách cụ thể. Máy chủ này có thể là máy chủ CDN gần máy khách nhất (có lẽ cùng một ISP như máy khách) hoặc có thể là máy chủ CDN có các đường không tắc nghẽn nối với máy khách.

Hình 6.8 đưa ra tương tác giữa nhà cung cấp nội dung và công ty CDN. Công ty CDN trước

tiên xác định đối tượng nào (ví dụ như video) họ muốn CDN phân bố. (Nhà cung cấp nội dung phân bố các đối tượng còn lại không cần sự can thiệp của CDN). Nhà cung cấp nội dung gắn nhãn và sau đó đẩy nội dung này đến nút CDN, đến lượt nút này sao chép lại và đẩy nội dung đến các máy chủ CDN được chọn lựa. Công ty CDN có thể sở hữu mạng riêng để đẩy nội dung từ nút CDN đến các máy chủ CDN. Bất cứ khi nào nhà cung cấp nội dung thay đổi đối tượng phân bố CDN, nó lại đẩy phiên bản mới tới nút CDN, nút này lại lập tức sao chép và phân bố đối tượng đến các máy chủ CDN. Cần lưu ý là mỗi máy chủ CDN thường chứa các đối tượng từ nhiều nhà cung cấp nội dung.

106

Chương 6. Kết nối mạng đa phương tiện

Hình Error! No text of specified style in document..33: CDN đẩy nội dung đối tượng gắn nhãn của nhà cung cấp đến các máy chủ CDN của nó

Bây giờ chúng ta xem xét một vấn đề thú vị nữa. Khi trình duyệt trong trạm chủ người sử

dụng được lệnh tìm kiếm một đối tượng cụ thể (được nhận dạng bằng URL), trình duyệt xác định liệu nó phải tìm kiếm đối tượng từ máy chủ gốc hay từ một trong những máy chủ CDN như thế nào? Thông thường, CDN sử dụng chuyển hướng DNS để hướng dẫn trình duyệt tìm đến máy chủ chính xác.

Ví dụ, giả sử tên trạm chủ của nhà cung cấp nội dung là www.foo.com. Giả sử tên của công

ty CDN là cdn.com. Tiếp theo giả sử nhà cung cấp nội dung chỉ muốn các tệp video mpeg là được CDN phân bố; tất cả các đối tượng khác, bao gồm các trang HTML cơ sở, được nhà cung cấp nội dung phân bố trực tiếp. Để thực hiện điều này, nhà cung cấp nội dung thay đổi tất cả các đối tượng HTML trên máy chủ gốc sao cho URL của tệp video được gán tiền tố http://www.cdn.com. Do đó, nếu tệp HTML tại nhà cung cấp nội dung ban đầu có tham chiếu

http://www.foo.com/sports/highlights.mpg,

nhà cung cấp nội dung có thể gán nhãn đối tượng này bằng cách thay thế tham chiếu trong tệp HTML bằng

http://www.cdn.com/www.foo.com/sports/highlights.mpg.

Khi trình duyệt yêu cầu trang Web chứa video highlights.mpg các hoạt động sau sẽ xảy

ra:

Trình duyệt gửi yêu cầu đối tượng HTML cơ sở tới máy chủ gốc, www.foo.com, máy chủ này gửi đối tượng HTML được yêu cầu đến trình duyệt. Trình duyệt phân tích cú pháp tệp

107

Chương 6. Kết nối mạng đa phương tiện

HTML và tìm tham chiếu đến http://www.cdn.com/www.foo.com/sports/highlights.mpg.

Trình duyệt sau đó thực hiện dò tìm DNS về www.cdn.com, là tên trạm chủ của URL tham chiếu. DNS được cấu hình sao cho tất cả các truy vấn về www.cdn.com đến máy chủ gốc DNS đều được gửi đến máy chủ DNS thẩm quyền của www.cdn.com. Khi máy chủ DNS thẩm quyền nhận được truy vấn, nó tách lấy địa chỉ IP của trình duyệt yêu cầu. Sử dụng ánh xạ mạng nội bộ đã xây dựng cho toàn bộ mạng Internet, máy chủ DNS của CDN trả lại địa chỉ IP của máy chủ CDN có khả năng tốt nhất cho trình duyệt yêu cầu (thường là máy chủ CDN gần với trình duyệt nhất).

DNS trong máy khách yêu cầu nhận trả lời DNS với địa chỉ IP. Sau đó trình duyệt gửi yêu cầu HTTP của nó đến máy chủ CDN có địa chỉ IP đó. Trình duyệt nhận được tệp video highlights.mpg từ máy chủ CDN này. Đối với các yêu cầu tiếp theo từ www.cdn.com máy khách tiếp tục sử dụng cùng một máy chủ CDN này do địa chỉ IP của www.cdn.com đang có trong DNS lưu đệm (trong máy khách hay trong máy chủ tên miền DNS cục bộ).

Tóm lại, như minh họa trong hình 6.9, đầu tiên trạm chủ yêu cầu liên hệ đến máy chủ Web

gốc để lấy đối tượng HTML cơ sở, sau đó đến máy chủ DNS thẩm quyền để lấy địa chỉ IP của máy chủ CDN tốt nhất, và cuối cùng đến máy chủ CDN này để lấy tệp video. Lưu ý rằng không cần phải thực hiện bất cứ thay đổi nào với HTTP, DNS hay trình duyệt để triển khai mô hình phân bố này.

Hình Error! No text of specified style in document..34: CDN sử dụng DNS để hướng các yêu cầu đến máy chủ CDN gần

Vấn đề còn lại cần diễn giải là 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 nà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 này, CDN ước lượng máy chủ CDN nào cung cấp dịch vụ best-

108

Chương 6. Kết nối mạng đa phương tiện

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 nà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 là “đầu tư tài chính để giải quyết vấn đề” và do đó đơn giản là tránh tranh chấp về tài nguyên. Trong trường hợp của đa phương tiện kết nối mạng, điều này có nghĩa là 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 đó chí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ể hài lòng, và điều đó có thể đạt được mà không cần thay đổi kiến trúc best-effort của Internet. Vấn đề là dung lượng bao nhiêu là “đủ” để đạ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ế nà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ế nào, và dung lượng nà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 và thường được gọi là định cỡ mạng. Cả hai vấn đề cung cấp băng thông và đị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 là 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, và do đó cung cấp đủ băng thông để đáp ứng các yêu cầu hiệu năng ứng dụng:

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 là 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 là 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.

Các yêu cầu hiệu năng được định nghĩa rõ ràng. Ví 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é nào đấy.

Các mô hình dự báo hiệu năng toà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á thành cao mà vẫn đáp ứng tất cả yêu cầu người sử dụng. Ở đây, các nhà nghiên cứu sẽ phải phát triển các mô hình hàng đợi có thể định lượng

109

Chương 6. Kết nối mạng đa phương tiện

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 tá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 là độ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 và ITU đã nhiều năm (và 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 đề và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, và MP3 cho âm thanh và MPEG và 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. Ngà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 là 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 và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 là đượ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ã

110

Chương 6. Kết nối mạng đa phương tiện

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ế dà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ế nà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 chí nó không đảm bảo chuyển gói tin tới đ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) và 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 và 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 và 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

111

Chương 6. Kết nối mạng đa phương tiện

Trường loại tải trọng trong gói tin RTP có độ dà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 tí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 độ

PCM µ

64 kbps

8 kHz

1016

4.8 kbps

8 kHz

GSM

13 kbps

8 kHz

LPC

2.4 kbps

8 kHz

G.722

48-64 kbps

16 kHz

MPEG Audio

90 kHz

G.728

16 kbps

8 kHz

Đố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

JPEG hình ảnh động

H.261

Video MPEG 1

Video MPEG 2

Các trường quan trọng khác là:

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, và bên nhận có thể sử dụng để phát hiện mất gói và 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.

112

Chương 6. Kết nối mạng đa phương tiện

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.

Định danh nguồn đồng bộ hóa (SSRC). Trường SSRC có độ dà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 là 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 và 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 đích

và số của cổng đí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 nào, như tràn bộ đệm tại bộ định tuyến). Cánh cửa này được định rõ bằng địa chỉ IP đích và số của cổng đích. Thực tế, bất cứ dữ liệu đồ IP nào chứa địa chỉ IP đích và số của cổng đích nà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ị nà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ể nà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 vào khung để tạo ra gói tin RTP, và sau đó chuyển khung RTP vào UDP socket. Để là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ự và 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.

113

Chương 6. Kết nối mạng đa phương tiện

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) là 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 và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 đích và địa chỉ IP đích. Chúng ta cần biết là 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).

114

Chương 6. Kết nối mạng đa phương tiện

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 và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 và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 đí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 nà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:

SSRC của dòng RTP mà báo cáo quá trình nhận của nó được tạo lập. 1.

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.

115

Chương 6. Kết nối mạng đa phương tiện

Jitter giữa các khoảng đến, là ướ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:

SSRC của dòng RTP. 1.

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. 2.

Số gói tin được truyền đi trên dòng. 3.

Số byte được gửi đi trên dòng. 4.

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 là 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 này được đóng gói và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 và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ô này, RTCP điều chỉnh tốc độ các bên tham gia gửi gói tin RTCP và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. Ví 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

116

Chương 6. Kết nối mạng đa phương tiện

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 tí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à

𝑇 = (kích cỡ gói tin RTCP trung bình) số lượng bên gửi 25.0,5. 𝑏ă𝑛𝑔 𝑡ℎô𝑛𝑔 𝑝ℎ𝑖ê𝑛

Và chu kì truyền gói tin RTCP đối với bên nhận là

𝑇 = (kích cỡ gói tin RTCP trung bình) số lượng bên nhận 75.0,5. 𝑏ă𝑛𝑔 𝑡ℎô𝑛𝑔 𝑝ℎ𝑖ê𝑛

117

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

XU HƯỚ NG PHÁT TRIỂN Ứ NG DỤNG VÀ DI ̣CH VỤ TRÊN NỀN INTERNET

Equation Section (Next)

Xu hướng hội tụ và mạng NGN

Xu hướng phát triển mạng toàn IP

Công nghệ IP được xây dựng trên nền tảng giao thức IP. Giao thức này được xây dựng với mục đí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 thà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 đí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 chí định tuyến nà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ụ là 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 tính “nỗ lực tối đa” (best – effort). Sau đây là 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

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. 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 là một lợi thế rất lớn của công nghệ này. 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. Công nghệ IP cho phép khả năng tí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 vụ gia tăng trên nền tảng của các ứng dụng cơ bản được cung cấp bởi mạng IP.

Nhược điểm

Do tính thông dụng của giao thức IP (phần lớn máy tính cá nhân đều được cài đặt các phần mềm trao đổi dữ liệu bằng giao thức IP) nên yếu tố bảo mật dữ liệu là một vấn đề cần phải quan tâm xem xét. Cơ cấu điều khiển truyền tải lưu lượng trong mạng IP còn chưa có độ tinh tế cao. Do đó, vấn đề đảm bảo chất lượng dịch vụ (QoS) cũng là một vấn đề mà các nhà nghiên cứu công nghệ IP đang nỗ lực tập trung giải quyết.

Với hiệu suất truyền tải lưu lượng cao, công nghệ IP được coi là một trong những công nghệ lựa chọn để triển khai trong cả mạng lõi và mạng truy nhập. Xét về mô hình phân lớp mạng, giao thức IP phù hợp cho chức năng định tuyến tại các vị trí là ranh giới tiếp giáp mạng (giao tiếp giữa mạng lõi và biên, giữa các nhà cung cấp mạng với nhau hay giao tiếp với mạng đường trục). Phiên bản giao thức

118

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

IP phổ biến từ trước đến nay là IPv4. Một phiên bản IP mới đang trong lộ trình triển khai rộng rãi là IPv6. IPv6 được phát triển nhằm khắc phục những nhược điểm của IPv4 như là hạn chế về không gian địa chỉ, khả năng cung cấp chức năng truyền tải lưu lượng của các ứng dụng đòi hỏi QoS cũng như khả năng bảo mật của việc truyền gói tin trên mạng, … IPv6 đã được các tổ chức và nhà cung cấp giải pháp viễn thông trên thế giới lựa chọn là công nghệ ứng dụng cho mạng hội tụ thế hệ mới. Điều này thể hiện rõ nét xu hướng phát triển của viễn thông ngày nay là tiến tới một mạng toàn IP (all IP).

Xu hướng hội tụ mạng và di ̣ch vụ

Các tiền đề cho sự hội tụ mạng và dịch vụ viễn thông

Xu hướng hội tụ mạng và dịch vụ viễn thông ngày nay được dựa trên một số tiền đề như sau.

1. Phát triển IP phiên bản 6

Như đã phân tích ở phần trên, sự ra đời của IPv6 bắt nguồn từ những vấn đề nảy sinh trong mạng IP khi mà Internet đã phát triển với tốc độ vượt bậc. IPv6 được đưa ra như một giải pháp hiệu quả cho phép giải quyết những vấn đề đặt ra của mạng Internet. Cho đến nay hầu hết các hãng cung cấp sản phẩm và giải pháp mạng đều đã chấp nhận hỗ trợ cho công nghệ IPv6. Ở cấp độ quốc gia, hệ thống mạng đường trục sử dụng công nghệ IPv6 đã được triển khai tại nhiều nước trên thế giới. Ở Việt nam, Bộ thông tin và truyền thông cũng đã công bố lộ trình phát triển lên IPv6 từ nay đến năm 2020.

2. Sự tích hợp các dịch vụ viễn thông trên mạng IP/Internet

Hiện nay, xu thế sử dụng các dịch vụ viễn thông tích hợp trên mạng Internet đã trở thành phổ biến. Các dịch vụ viễn thông mới trên mạng IP nói chung và Internet nói riêng đã cho phép giảm đáng kể chi phí của người sử dụng cho việc đàm thoại và truyền dữ liệu đa phương tiện.

3. Sự gia tăng lưu lượng dành cho dịch vụ viễn thông

Việc chuyển dần lưu lượng viễn thông truyền thống qua mạng Internet (hay mạng IP) là bước quan trọng để tiến tới một cơ sở hạ tầng thông tin thống nhất trong tương lai. Hiện nay việc phát triển công nghệ thoại IP và các dịch vụ liên quan đang thu hút được sự chú ý của các nhà cung cấp kết nối và dịch vụ mạng do khả năng cung cấp dữ liệu đa phương tiện trên mạng chuyển mạch gói với chi phí thấp.

4. Sự tích hợp mạng IP/Internet và mạng di động

Sự tích hợp của mạng di động và Internet cùng với sự đa dạng của các loại hình đa dịch vụ đã tạo ra một xu hướng mới trong phát triển hạ tầng mạng viễn thông, đó là sử dụng IP trên toàn bộ mạng truy nhập cũng như mạng xương sống. Theo số liệu thống kê của các nhóm nghiên cứu, số người truy cập Internet từ máy di động đang ngày một tăng lên và có xu hướng tiến tới đây sẽ là phương thức truy cập Internet chủ đạo.

5. Sự phát triển của các giải pháp nâng cao chất lượng dịch vụ

Do giao thức IP rất đơn giản nên nó không có khả năng cung cấp các cơ chế đảm bảo chất lượng dịch vụ. Như chúng ta đã biết, giao thức IP chỉ cung cấp được cái gọi là dịch vụ “best effort”, mà thực chất là dịch vụ truyền gói tin nhưng không quan tâm đến khi nào gói tin sẽ đến đích cũng như có bao nhiêu gói tin có thể đến đích. Bởi vậy, trong mạng Internet thế hệ mới, việc đảm bảo các tham số

119

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

chất lượng dịch vụ là một trong những yếu tố được đưa lên hàng đầu. Dưới đây là ba tham số chất lượng dịch vụ chính cần phải được đảm bảo trong mạng Internet thế hệ mới:

- Giảm thiểu độ trễ trong quá trình truyền gói tin;

- Giảm thiểu sự biến thiên về độ trễ của các gói tin;

- Có khả năng cung cấp thông lượng truyền dữ liệu ổn định.

Để đảm bảo được các tham số chất lượng dịch vụ trên, trong quá trình phát triển mạng Internet thế hệ mới người ta thường áp dụng một trong ba giải pháp: cung cấp thêm tài nguyên mạng, lưu giữ tài nguyên và phân quyền ưu tiên cho các dịch vụ khác biệt.

Cung cấp thêm tài nguyên mạng

Giải pháp đầu tiên mà chúng ta có thể nghĩ tới để giải quyết vấn đề tắc nghẽn trên đường truyền mạng là cung cấp thêm tài nguyên nhằm mục đích tăng khả năng thông qua của mạng trong trường hợp xảy ra tắc nghẽn. Tuy nhiên, rõ ràng là giải pháp này không có tính kinh tế, ít nhất là đối với cấu trúc mạng như hiện nay, bởi vì chúng ta hiếm khi có thể dự đoán trước được thời điểm sẽ xảy ra tắc nghẽn mạng và cũng không thể tìm đủ tài nguyên mạng để thoả mãn tất cả các nhu cầu trên mạng.

Kiến trúc dịch vụ tích hợp Integrated Service Architecture (IntServ)

Kiến trúc dịch vụ tích hợp được định nghĩa bởi IETF nhằm mục đích đưa Internet trở thành một cơ sở hạ tầng cho các dịch vụ tích hợp tính năng cao hỗ trợ truyền thông tiếng nói, hình ảnh, dữ liệu thời gian thực cũng như các dữ liệu truyền thống.

Mô hình phân quyền ưu tiên - Cơ chế cung cấp dịch vụ khác biệt

Cơ chế cung cấp dịch vụ khác biệt được định nghĩa bởi IETF để cung cấp các lớp dịch vụ phân biệt trên đường truyền Internet, hỗ trợ nhiều loại ứng dụng và đáp ứng nhu cầu của các doanh nghiệp. Cơ chế này hoạt động dựa trên việc cung cấp chất lượng dịch vụ cho từng yếu tố sẽ tạo nên các dịch vụ khác nhau hơn là cho bản thân các dịch vụ.

Các yêu cầu hội tụ mạng và dịch vụ viễn thông

6. Yêu cầu về cấu trúc mạng

Một cấu trúc mạng chỉ được coi là tối ưu nếu nó không những được lên kế hoạch để đáp ứng cho các yêu cầu hiện tại mà còn phải có khả năng nâng cấp dễ dàng để đáp ứng được những yêu cầu có thể có trong tương lai. Một cấu trúc như vậy cũng cần cung cấp khả năng linh hoạt, khả năng mở rộng cho các phát triển sau này. Tuy nhiên để xây dựng được một cấu trúc mạng như vậy không phải là dễ dàng. Tốc độ phát triển vũ bão của các yêu cầu ứng dụng, công nghệ mạng cũng như thương mại là một thế mạnh của Internet, nhưng đồng thời cũng là một trở ngại không nhỏ mà chúng ta phải vượt qua.

7. Yêu cầu về khả năng cung cấp dịch vụ

120

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Chúng ta có thể hình dung được mối quan hệ giữa cách mà những ứng dụng được xây dựng dựa trên các công nghệ của mạng Internet hiện nay hoạt động với bản thân các ứng dụng đó. Như đã trình bày ở trên, mạng Internet hiện nay được thiết kế nhằm đảm bảo độ tin cậy trong truyền thông giữa các tài nguyên được chia sẻ trên mạng với các loại ứng dụng truyền thống như dịch vụ truyền file, dịch vụ thư điện tử hay dịch vụ đăng nhập từ xa. Cấu trúc thiết kế này cũng đáp ứng được các yêu cầu tương tác giữa các đầu cuối từ các địa điểm khác nhau trên mạng.

8. Khả năng thích ứng

Rõ ràng đây là một trong những yêu cầu cơ bản nhất đối với mạng Internet thế hệ mới. Mạng Internet thế hệ mới sẽ phải thích ứng được với nhịp tăng trưởng theo cấp số mũ về số người sử dụng, loại hình dịch vụ và ứng dụng trên Internet. Nó cũng sẽ phải tiếp tục duy trì và phát triển cuộc cách mạng công nghệ về truyền thông số hiện nay.

Kiến trúc tổng thể mạng NGN

Nguyên tắc chung xây dựng mạng

Nhìn chung, kiến trúc mạng NGN phải đáp ứng các nguyên tắc cơ bản sau:

Cung cấp các dịch vụ dữ liệu và thoại trên một hạ tầng viễn thông duy nhất; Hỗ trợ các công nghệ truy nhập khác nhau; Điều khiển phân tán; Điều khiển mở; Dịch vụ độc lập với cơ sở hạ tầng mạng; Có cơ chế bảo mật và bảo vệ mạng tiên tiến; Tăng khả năng cạnh tranh, đáp ứng yêu cầu của người sử dụng; Xây dựng cấu trúc mạng hội tụ cố định-di động FMC.

1. 2. 3. 4. 5. 6. 7. 8. Với kiến trúc mạng dựa trên những nguyên tắc như trên, mạng NGN sẽ mang lại những khả năng vượt ra ngoài phạm vi của mạng hiện tại. Đặc biệt, mạng sẽ hỗ trợ cho công nghệ truy nhập đa dạng và khả năng di động cao, tức là mạng cần hỗ trợ cho đa dạng các cấu hình mạng. Một số cấu hình mẫu sẽ được giới thiệu tương ứng với cấu trúc chức năng mô tả trong phần này.

Kiến trúc chức năng mạng NGN

Kiến trúc NGN giới thiệu ở đây hỗ trợ cho các dịch vụ bao gồm: dịch vụ đa phương tiện, dịch vụ hội thảo truyền hình, dịch vụ video, ... Mạng NGN cũng cung cấp sự hỗ trợ cho việc thay thế PSTN/ISDN (mô phỏng hoặc giả lập PSTN/ISDN). Ngoài ra, nó cung cấp dung lượng và tài nguyên để đáp ứng các ứng dụng nhóm thứ 3 cho các dịch vụ gia tăng.

Hình Error! No text of specified style in document..39 mô tả tổng quan về kiến trúc chức năng của mạng NGN, trong đó các chức năng mạng được phân chia thành các chức năng tầng dịch vụ và các chức năng tầng truyền tải tương ứng với Y.2011.

121

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..39: Kiến trúc chức năng của mạng NGN

Sự phân phối các dịch vụ/ứng dụng tới người sử dụng được cung cấp bởi các chức năng hỗ trợ ứng dụng/dịch vụ và các chức năng điều khiển dịch vụ. Mạng NGN hỗ trợ một điểm tham chiếu đến ”những ứng dụng nhóm 3”. Nhóm chức năng này được gọi là Application-Network Interface (ANI), cung cấp khả năng thiết lập và cung cấp các dịch vụ nổi bật tới những người sử dụng NGN.

Tầng vận chuyển cung cấp dịch vụ kết nối IP tới những người sử dụng NGN dưới sự điều khiển của các chức năng điều khiển truyền tải, bao gồm Network Attachment Control Functions (NACF) và Resource and Admission Control Functions (RACF).

Chức năng tầng truyền tải

Chức năng tầng truyền tải bao gồm các chức năng truyền tải và các chức năng điều khiển truyền tải.

9. Chức năng truyền tải

Chức năng truyền tải cung cấp khả năng kết nối cho tất cả các thành phần và khả năng phân chia vật lý với mạng NGN. Những chức năng này cung cấp sự hỗ trợ cho việc truyền thông tin của người sử dụng cũng như thông tin điều khiển và quản lý. Chức năng truyền tải bao gồm: chức năng mạng truy nhập, chức năng truyền tải biên, chức năng truyền tải lõi và chức năng Gateway.

Chức năng mạng truy nhập phục vụ các sử dụng đầu cuối truy nhập tới mạng như là lựa chọn và tập hợp lưu lượng đến từ những thuê bao truy nhập này để chuyển tới mạng lõi. Những chức năng này cũng thực hiện cơ chế điều khiển QoS trực tiếp tới lưu lượng người dùng, bao gồm quản lý bộ đệm, hàng đợi và kế hoạch, lọc gói, phân lớp lưu lượng, đánh dấu, kiểm soát và định dạng.

122

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Chức năng biên được sử dụng cho xử lý truyền thông và lưu lượng khi tập hợp lưu lượng đến từ các mạng truy nhập khác nhau và được kết hợp vào mạng truyền tải lõi. Chúng bao gồm các chức năng liên quan đến hỗ trợ cho QoS và điều khiển lưu lượng.

Chức năng truyền tải lõi chịu trách nhiệm đảm bảo truyền tải thông tin qua mạng lõi. Chúng cung cấp khả năng để đảm bảo sự khác biệt của chất lượng truyền dẫn trong mạng lõi. Các chức năng này cung cấp những cơ chế QoS trực tiếp tới lưu lượng người sử dụng.

Chức năng Gateway cung cấp khả năng để liên kết hoạt động với các mạng khác, bao gồm cả các mạng đã tồn tại như PSTN/ISDN, Internet công cộng, v.v. Các chức năng Gateway có thể được điều khiển trực tiếp từ chức năng điều khiển dịch vụ hoặc thông qua chức năng điều khiển truyền tải.

Chức năng điều khiển truyền thông cung cấp khả năng xử lý tài nguyên truyền thông cho các dịch vụ được cung cấp, như phát tín hiệu tone và mã hóa truyền dẫn. Những chức năng này là cụ thể cho việc nắm bắt tài nguyên trong tầng truyền tải.

10. Chức năng điều khiển truyền tải

Các chức năng điều khiển truyền tải bao gồm chức năng điều khiển sự xác nhận và tài nguyên, và chức năng điều khiển sự gắn kết mạng.

Chức năng điều khiển sự xác nhận và tài nguyên (RACF) cung cấp khả năng điều khiển QoS, NAPT và/hoặc các chức năng điều khiển FW trên mạng truy nhập và truyền tải lõi. Chức năng xác nhận bao gồm kiểm tra thông tin người dùng dựa trên sự cho phép, SLAs, các điều khoản chính sách hoạt động cụ thể, dịch vụ ưu tiên và tài nguyên cho phép trong mạng truyền tải lõi và truy nhập.

Trong cấu trúc mạng NGN, hoạt động RACF như là trọng tài đối với việc thương lượng và phân chia tài nguyên giữa các chức năng điều khiển dịch vụ và các chức năng truyền tải. RACF tương tác với các chức năng điều khiển dịch vụ và các chức năng truyền tải cho các ứng dụng dựa trên phiên và không theo phiên yêu cầu điều khiển tài nguyên truyền tải NGN, bao gồm điều khiển QoS, điều khiển NAPT/FW và NAT. Chúng cũng tương tác với các chức năng truyền tải với mục đích để điều khiển một hoặc nhiều chức năng trong tầng truyền tải: lọc gói, phân lớp lưu lượng, đánh dấu, kiểm soát, đặt trước và phân chia băng tần, chuyển đổi cổng và địa chỉ mạng, Firewall, ...

Chức năng điều khiển sự gắn kết mạng (NACF) cung cấp sự đăng ký ở tầng truy nhập và sự khởi tạo chức năng sử dụng đầu cuối cho dịch vụ truy nhập NGN. Các chức năng này cung cấp sự xác định/xác nhận mức mạng, quản lý không gian địa chỉ IP của mạng truy nhập, và xác nhận phiên truy nhập. Chúng cũng thông báo điểm đăng ký dịch vụ/ứng dụng NGN hỗ trợ các chức năng tới sử dụng đầu cuối. NACF cung cấp các chức năng sau:

Cung cấp địa chỉ IP động và các tham số cấu hình thiết bị người dùng khác; Xác nhận ở tầng IP; Xác nhận mạng truy nhập dựa trên mô tả sơ lược của người dùng; Cấu hình mạng truy nhập dựa trên mô tả sơ lược của người dùng; Quản lý vị trí tại tầng IP.

1. 2. 3. 4. 5. Chức năng tầng dịch vụ

123

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

6. Chức năng điều khiển dịch vụ

Các chức năng điều khiển dịch vụ bao gồm cả điều khiển phiên và không phiên, đăng ký và xác nhận và các chức năng xác nhận ở tầng dịch vụ. Chúng cũng có thể bao gồm các chức năng cho điều khiển tài nguyên truyền thông, ví dụ tài nguyên đặc biệt và các gateway ở mức tín hiệu dịch vụ.

7. Chức năng hỗ trợ ứng dụng/dịch vụ

Các chức năng hỗ trợ ứng dụng/dịch vụ như gateway, đăng ký, xác nhận và các chức năng xác nhận ở mức ứng dụng. Những chức năng này cho phép ”các ứng dụng nhóm 3” và các nhóm chức năng ”sử dụng đầu cuối”. Chức năng hỗ trợ ứng dụng/dịch vụ liên kết với các chức năng điều khiển dịch vụ để cung cấp tới sử dụng đầu cuối và các ứng dụng nhóm thứ 3 như dịch vụ gia tăng yêu cầu.

Thông qua UNI, chức năng hỗ trợ ứng dụng/dịch vụ cung cấp một điểm tham chiếu tới chức năng sử dụng đầu cuối. Các ứng dụng nhóm thứ 3 tương tác với các chức năng hỗ trợ ứng dụng/dịch vụ được quản lý thông qua điểm tham chiếu ANI.

8. Chức năng mô tả người sử dụng dịch vụ

Các chức năng này mô tả sự kết hợp thông tin người sử dụng và dữ liệu điều khiển khác tới chức năng mô tả người sử dụng trong tầng dịch vụ theo dạng cơ sở dữ liệu. Cơ sở dữ liệu này có thể được cài đặt như một tập cơ sở dữ liệu kết hợp với sự tập trung vào một số chức năng của NGN.

Chức năng của đầu cuối

Không có sự qui định nào về các giao diện người dùng cuối, và các mạng người dùng cuối khác nhau có thể được kết nối tới mạng truy nhập NGN. Nhiều loại thiết bị người dùng cuối khác nhau được hỗ trợ trong NGN, từ các máy điện thoại một dây cũ tới các thiết bị truy nhập tích hợp. Thiết bị người dùng cuối có thể là một máy di động hoặc cố định.

Chức năng quản lý mạng

Hỗ trợ quản lý là nền tảng cho hoạt động của NGN. Các chức năng này cung cấp khả năng quản lý NGN để cung cấp các dịch vụ với chất lượng, bảo mật, và độ tin cậy mong muốn. Các chức năng quản lí được ấn định theo cách phân phối cho mỗi thực thể chức năng (FE), và chúng tương tác với các chức năng quản lý phần tử mạng (NE), quản lý mạng, và quản lý dịch vụ.

Chức năng quản lý bao gồm các vùng sau:

a) Quản lý lỗi

b) Quản lý cấu hình

c) Quản lý tính toán

d) Quản lý hiệu suất

e) Quản lý bảo mật

124

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Chức năng quản lý tính toán cũng bao gồm chức năng tính cước và thanh toán (CBF). Những chức năng này tương tác với mỗi chức năng khác trong mạng NGN để tập hợp thông tin tính toán, cung cấp cho nhà cung cấp dịch vụ NGN với số liệu sử dụng tài nguyên phù hợp, cho phép nhà cung cấp dịch vụ làm hoá đơn phù hợp cho những người sử dụng hệ thống.

Các thành phần mạng NGN và công nghệ

Mạng lõi và mạng truy nhập

Cùng với kiến trúc và các dịch vụ mới, NGN mang đến một mức độ phức tạp cao hơn các mạng cố định hiện có. NGN tăng khả năng hỗ trợ cho các công nghệ truy nhập và hỗ trợ một dải rộng các cấu hình mạng. Hình Error! No text of specified style in document..40 biểu diễn một mạng lõi NGN với một tập các mạng truy nhập tiêu biểu.

Hình Error! No text of specified style in document..40: Mạng lõi và các mạng truy nhập NGN

Trên hình vẽ, mạng lõi là bộ phận của NGN trong đó nó cung cấp các dịch vụ viễn thông và/hoặc các dịch vụ đa phương tiện của NGN tới người sử dụng. Mạng lõi phân biệt với mạng truy nhập là nó cung cấp các chức năng chung được chia sẻ cho một hoặc nhiều mạng truy nhập. Mạng lõi NGN có thể được phân biệt với các mạng lõi NGN khác dựa trên nhu cầu hoặc quyền sở hữu kinh doanh. Các mạng truy nhập được phân biệt với mạng lõi là chúng không cung cấp trực tiếp các dịch vụ end-user (khác với truyền tải). Các mạng truy nhập có thể được phân biệt với mỗi mạng khác dựa trên các khía cạnh như công nghệ, quyền sở hữu, hay nhu cầu quản trị.

Cần thiết phải phân biệt giữa các mạng truy nhập và lõi NGN. NGN hỗ trợ việc chuyển mạng tới một mạng cấu hình khác, mạng nhà được tìm ra từ một mạng khách.

Khái niệm mạng nhà không nhất thiết phải được kết nối tới vùng địa lý của nhà hoặc nơi làm việc của người sử dụng. Hơn nữa, dựa trên nguyên lý là một nhà khai thác giữ một mô tả cho dịch vụ đang được cung cấp cho người sử dụng. Nhà khai thác này chịu trách nhiệm về việc cho phép truy nhập của người sử dụng tới dịch vụ và tính tiền người sử dụng với truy nhập này. Cho phép toàn bộ dịch vụ

125

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

được cung cấp bởi mạng khách, ví dụ, trong khi vẫn có một nhà khai thác mạng nhà riêng nhận thực dịch vụ thông qua sự sắp xếp kinh doanh phù hợp với nhà khai thác khách. Thông thường trong NGN, nhà khai thác nhà sẽ cung cấp điều khiển dịch vụ cho người sử dụng trong khi nhà khai thác khách sẽ chỉ cung cấp các khả năng truy nhập liên quan, như là hỗ trợ nhận thực, hỗ trợ trao quyền, các dịch vụ bảo toàn số liệu, và hỗ trợ QoS.

Quan hệ giữa NGN và các miền quản trị

Mạng NGN có thể được phân tích một cách logic thành các mạng con khác nhau, như biểu diễn trong Hình 7.3. Tầm quan trọng về sự phân tích logic thay vì sự phân tích vật lý được dựa trên thực tế rằng, trong tương lai, thiết bị vật lý có thể có các chức năng của cả mạng truy nhập và mạng lõi. Một sự phân tích vật lý đơn thuần sẽ gặp nhiều khó khăn khi các chức năng được kết hợp vào trong một phần tử mạng.

Hình Error! No text of specified style in document..41: NGN và các miền mạng

Các thành phần chính của một mạng NGN là:

1. 2. 3.

Mạng end-user: Một mạng end-user có thể là một mạng nhà hoặc một mạng doanh nghiệp. Nó được kết nối tới mạng của nhà cung cấp dịch vụ thông qua một giao diện người dùng - mạng UNI (User-to-Network Interface). UNI cũng là điểm ranh giới giữa nhà cung cấp dịch vụ và người dùng. Một mạng end-user có thể thu được dịch vụ nội dung của chúng từ: Mạng lõi, Trường hợp khác của mạng end-user cung cấp các dịch vụ công cộng, hoặc Trường hợp khác của mạng end-user cung cấp các dịch vụ công cộng, có thể với một kế hoạch đánh địa chỉ riêng. Mạng truy nhập: Một mạng truy nhập tập hợp lưu lượng end-user từ mạng end-user tới mạng lõi. Nhà cung cấp dịch vụ mạng truy nhập chịu trách nhiệm về mạng truy nhập. Mạng 126

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

truy nhập có thể được phân chia thành các miền khác nhau, với giao diện nội miền được đặt tên là I-NNI (Internal Network-to-Network Interface) và giao diện liên miền được đặt tên là E- NNI (External Network-to-Network Interface). Mạng truy nhập liên quan tới tầng truyền tải. Mạng lõi: Mạng lõi liên quan tới cả tầng truyền tải và tầng dịch vụ. Nhà cung cấp dịch vụ mạng lõi chịu trách nhiệm về mạng lõi. Giao diện giữa mạng lõi và mạng truy nhập và mạng truy nhập và mạng lõi có thể là I-NNI (trong trường hợp sự phân chia là một miền) hoặc là một E-NNI.

Khái niệm miền NGN được chỉ ra để phác thảo các ranh giới quản trị. Thông tin topo chi tiết có thể hoặc không thể được chia sẻ qua E-NNI, nhưng có thể được chia sẻ nếu có giá trị cho các liên kết I- NNI. Như được miêu tả trong sơ đồ ở trên, mạng truy nhập và mạng lõi có thể hoặc không thể thuộc vào cùng một miền NGN.

Quan hệ giữa NGN và các miền dịch vụ

NGN cung cấp khả năng truy cập tới một dải rộng các dịch vụ. Các dịch vụ riêng được cung cấp bởi bất kỳ nhà cung cấp dịch vụ nào được quyết định bởi các nhu cầu kinh doanh và nhu cầu của khách hàng. Hình Error! No text of specified style in document..42 biểu diễn ví dụ của một cấu hình NGN để minh hoạ nhiều miền với các dịch vụ có thể được truy nhập.

Hình Error! No text of specified style in document..42: NGN và các miền dịch vụ

Trong ví dụ này, nhà khai thác A hỗ trợ một công nghệ mạng truy nhập đơn, nhà khai thác này cung cấp khả năng truy nhập tới ba miền dịch vụ thông qua mạng lõi của nhà khai thác.

Một miền dịch vụ sẽ được cung cấp bởi các dịch vụ IMS. Ba dịch vụ có thể được hoàn thành với miền của nhà khai thác A hoặc có thể hỗ trợ các dịch vụ end-to-end cho các nhà khai thác khác. Trong ví dụ này, nhà khai thác A hỗ trợ các dịch vụ IMS end-to-end cùng với IMS của nhà khai thác B. Chúng được kết nối thông qua một mạng chuyển tiếp đáng tin cậy. Tất nhiên, các cấu hình mạng chuyển tiếp khác được cho phép, và có thể không cần mạng chuyển tiếp trong trường hợp nhà khai thác A được kết nối trực tiếp tới mạng điểm cuối khác. Trong một vài trường hợp các firewall hoặc các phần tử gateway có thể được sử dụng để bảo vệ nhà khai thác từ mạng chuyển tiếp. Chú ý rằng mạng nằm bên cạnh của mạng chuyển tiếp có thể là kiểu mạng ngoài như là PSTN.

Miền dịch vụ thứ hai trong ví dụ này là các dịch vụ không SIP của nhà khai thác A. Miền này sẽ cung cấp các dịch vụ như là video luồng. Các thực thể dịch vụ này có thể tham gia trực tiếp vào mạng lõi

127

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

của nhà khai thác A và có thể được cung cấp bởi nhóm thứ ba thông qua các sắp xếp bảo mật đáng tin cậy.

Miền dịch vụ thứ ba được chỉ ra ở đây là khả năng truy nhập Các dịch vụ dựa trên Internet. Các dịch vụ này không phải là bộ phận của miền của nhà khai thác A, và chúng được cung cấp bởi sự sắp xếp kinh doanh với nhà khai thác A. Các dịch vụ này được truy nhập nhờ nhà khai thác A cung cấp một kết nối truyền tải tới Internet. Như là một kết nối bởi nhà khai thác A chỉ cho phép thông qua các kỹ thuật firewall.

Như đã được đề cập từ trước, ví dụ này chỉ biểu diễn một tập hợp nhỏ các cấu hình có thể có được hỗ trợ bởi các nhà khai thác NGN. Nó minh hoạ ba miền cơ bản của khả năng truy nhập dịch vụ được cung cấp bởi NGN.

Ứng dụng và dịch vụ mạng NGN

Mô hình lớp ứng dụng mạng NGN

Mô hình chức năng lớp ứng dụng gồm các thực thể sau đây:

1: Thực thể phục vụ ứng dụng FE (AS-FE) – Gồm những chức năng chung của máy chủ ứng dụng sau:

1. 2. 3. Máy chủ ứng dụng SIP Máy chủ ứng dụng Cấu trúc dịch vụ mở (OSA) Bộ khả dụng môi trường dịch vụ OMA (OSE)

2: Máy chủ ứng dụng mạng thông minh FE (IN-AS- FE) – gồm các chương trình dịch vụ logic để cung cấp các dịch vụ giá trị gia tăng trên nền mạng thông minh

3: Gateway ứng dụng FE (APL-GW-FE) – hỗ trợ như các thực thể nằm giữa khối ứng dụng thứ 3 và phần tử chức năng phục vụ điều khiển phiên/cuộc gọi của tầng điều khiển dịch vụ (S-CSC-FE). Sự có mặt của phần tử S-CSC-FE cũng có vai trò như một Access Server, APL-GW-FE đưa ra một giao diện mở bảo mật cho khối ứng dụng thứ 3 và khối các dịch vụ giá trị gia tăng.

4: Quản lý kết hợp dịch vụ ứng dụng FE (APL-SCM-FE) – quản lý sự kết hợp giữa các dịch vụ đa ứng dụng (hoặc các máy chủ).

5: Thực thể chức năng chuyển mạch dịch vụ (SS-FE) – Hỗ trợ việc truy nhập và liên kết tới các điểm điều khiển dịch vụ mạng thông minh truyền thống IN SCP. Đối với IN SCP này, bộ phận điều khiển phiên được kết nối thông qua SS-FE hỗ trợ cho INAP làm việc được với SCP truyền thống.

Các chức năng hỗ trợ ứng dụng, dịch vụ có thể tác động và chi phối phiên SIP với vai trò như là các dịch vụ thông qua giao diện của nó với phần tử phục vụ điều khiển cuộc gọi phiên của tầng điều khiển dịch vụ S-CSC-FE. Nó cũng có thể là các chức năng hỗ trợ dịch vụ, ứng dụng để tạo ra các yêu cầu SIP và các cuộc thoại của khách hàng. Các yêu cầu này được được chuyển đến S-CSC-FE, và các S- CSC-FE sẽ thiết lập các thủ tục đầu tiên cho các yêu cầu này. Tồn tại cả thực thể đáng tin cậy trong mạng của khách hàng lẫn thực thể không đáng tin cậy trong lớp thứ 3 (yêu cầu một lớp cho việc chứng thực), các chức năng hỗ trợ ứng dụng, dịch vụ liên kết với các thực thể khác trong mạng.

128

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..43: Chức năng hỗ trợ ứng dụng, dịch vụ

Các chức năng hỗ trợ ứng dụng, dịch vụ được mô tả trên Hình Error! No text of specified style in document..43 và hoạt động như sau:

3. Thực hiện các dịch vụ logic dựa vào các thông tin dịch vụ của thuê bao và/hoặc dung lượng của thiết bị đầu cuối (thông tin của thiết bị). Hoạt động với các máy chủ ứng dụng, như là máy chủ trình diễn, máy chủ hệ thống thông tin địa lý (GIS), hoặc AS, để cung cấp các dịch vụ hội tụ cho các khách hàng. Nó đóng vai trò của 4 mô hình kết nối phiên với S-CSC-FE:

1. Như một đại lý khách hàng phía cuối 2. Như một đại lý khách hàng phía đầu 3. Như một SIP proxy 4. Như một bộ phận điều khiển cuộc gọi bên thứ 3 (Đại lý khách hàng back-to-back)

Nó kết hợp trực tiếp với thực thể chức năng điều khiển cổng truy nhập của tầng truyền tải hoặc thông qua S-CSC-FE để trao đổi với các khách hàng PSTN hoặc ISDN.

Các ví dụ về chức năng hỗ trợ ứng dụng, dịch vụ gồm có các máy chủ ứng dụng thoại, máy chủ, các máy chủ các loại tin nhắn khác nhau, máy chủ hội nghị, máy chủ về các ứng dụng trong nhà, v.v...

Kiến trúc di ̣ch vụ mạng NGN

Mô hình OMA và Parlay X

Rất nhiều nhà cung cấp dịch vụ ứng dụng hiện đang cung cấp hàng loạt các dịch vụ ứng dụng cho khách hàng trong miền IT. Do đó, mạng NGN nên có giao diện với miền IT.

129

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Parlay X là một trong những công nghệ giải quyết được vấn đề, nó hoạt động như một Gateway giữa miền IT và NGN (Hình 7.6).

Hình Error! No text of specified style in document..44: Kiến trúc Parlay trong mạng NGN

Ban đầu Parlay API và dịch vụ Web Parlay X 3 được định nghĩa bởi tổ chức Parlay. Nó được sử dụng để thiết lập giao diện cho cơ cấu tổ chức ứng dụng và công nghệ Gateway trên các chức năng mạng viễn thông phía dưới. Ngày nay, các tổ chức tiêu chuẩn 3GPP và ETSI đã chuẩn hóa nội dung Parlay và phát triển nó trở thành một phần của OSA. Và để đem lại hiệu quả cao nhất ta sử dụng và phát triển cả hai.

Liên minh dịch vụ di động mở OMA

OMA (Open Mobile Alliance) ra đời cùng với thời điểm 3GPP đã hoàn thành UMTS 5. OMA đã đem lại khả năng liên kết tế bào (3GPP và 3GPP2) với công nghệ IT, OMA thông qua sự tham gia của các công ty để có sự đồng ý chung. OMA là kiến trúc cho phép sử dụng các chuẩn hiện đang tồn tại dù nó từ IT hay viễn thông và sau đó sẽ xây dựng giải pháp phối hợp hoạt động end-to-end. Giải pháp gồm 3 pha :

Đồng ý thiết lập một dạng kĩ thuật mở cho phép ứng dụng trong dịch vụ và giải pháp. Các đặc điểm kĩ thuật phải được kiếm tra thao tác giữa các thành phần. Việc ban hành OMA phải được tán thành với các báo cáo kiểm tra end-to-end .

1. 2. 3. Môi trường dịch vụ OMA

Kiến trúc dịch vụ OMA bao gồm một tập các thành phần (Hình Error! No text of specified style in document..45):

Các ứng dụng (Applications): các ứng dụng nằm trong cơ cấu tổ chức trong nhà hay trong ứng dụng nhóm ba.

130

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Chức năng thực thi chính sách (Policy Enforcer): chức năng này áp dụng các chính sách khi thực hiện tương tác giữa các ứng dụng và chức năng và giữa các chức năng tại nơi nào phù hợp và trong một vài trường hợp chính sách có thể là rỗng Chức năng (Enabler): chức năng OMA bao gồm các chức năng bên trong có thể tương tác với các chức năng khác trong miền Cấu trúc và tài nguyên mạng phía dưới. Môi trường chấp hành (Execution Enviroment): điều này phù hợp với các bộ phận như là quản lý chu kì sống, cân bằng tải, OA&M…

Hình Error! No text of specified style in document..45: Cấu trúc logic OMA

Tác động giữa các ứng dụng và chức năng được thực hiện thông qua chức năng thực thi chính sách.

Nếu được yêu cầu, chức năng thực thi chính sách cung cấp cơ chế quản lý tập trung logic và phù hợp nhằm đơn giản hóa việc điều khiển truy nhập tới các tài nguyên của các nhà cung cấp dịch vụ. Chức năng thực thi chính sách cung cấp cơ chế cho các nhà cung cấp dịch vụ các chính sách bảo mật, điều khiển truy nhập, tách biệt, hay tính cước hoặc bất cứ yêu cầu nào (Hình Error! No text of specified style in document..46).

Việc thi hành chính sách được thực hiện bằng cách cung cấp các chính sách như nhận thực và cấp phép. Yêu cầu chính sách sử dụng để đánh giá và làm cho có hiệu lực các chính sách do nhà cung cấp dịch vụ định nghĩa và/hoặc các khả năng mục tiêu. Các yêu cầu chính sách có thể được sử dụng để thảo ra các quyền cho các chức năng cao hơn. Yêu cầu chính sách có thể viện dẫn bởi bất cứ phần tử được ủy quyền nào (như việc xác định bởi các chính sách truy nhập tới quản lý chính sách) của OSE để đánh giá và thực thi các chính sách.

131

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..46 Mô hình hoạt động của yêu cầu chính sách

Yêu cầu chính sách có thể áp dụng cùng một thủ tục cứng nhắc nào đấy cho các chức năng và các ứng dụng mà cư trú trong cùng một môi trường hay trên ứng dụng nhóm thứ ba. Điều này đạt được bằng cách sử dụng chức năng thực thi chính sách xử lý tất cả các yêu cầu chính sách được yêu cầu đến hay bắt nguồn các ứng dụng và tuân theo các chính sách phù hợp. Việc thực thi các chính sách được áp dụng một cách lôgic cho tất cả các yêu cầu, tuy nhiên có những nơi không cần thiết áp dụng yêu cầu chính sách. Quá trình thực thi yêu cầu khi chúng xuất phát từ các ứng dụng hay các chức năng hoặc bên ngoài nhà cung cấp dịch vụ. Nhà cung cấp dịch vụ cung cấp tài nguyên có thể thiết lập các chính sách. Các chính sách này được kết hợp với các chính sách khác từ sự ưu tiên hay các điều luật thiết lập bởi người sử dụng cuối hay từ các điều kiện được đồng ý bởi nhóm thứ ba tới việc sử dụng tài nguyên. Các nhà cung cấp dịch vụ có thể chấp nhận để thiết lập thêm các chính sách trên lợi ích của nhóm thứ ba.

Các giao diện OSE (OMA service Enviroment- môi trường dịch vụ OMA)

Trong Hình Error! No text of specified style in document..47 là các giao diện được định nghĩa bởi OSE. Mỗi giao diện sẽ được miêu tả phía dưới.

IO là giao diện thiết lập chức năng tới ứng dụng và phần tử yêu cầu chính sách. IO có thể sử dụng bằng cách liên kết hai chức năng với nhau. IO + P là tập các giao diện mà sử dụng cho các ứng dụng nhóm ba. Sự khác biệt ở đây là tham số P được thêm vào bởi nhà cung cấp dịch vụ cho một tương tác giữa chức năng và ứng dụng. Trong trường hợp không chính sách nào được áp dụng thì P rỗng. I1 là giao diện mà một bộ chức năng sử dụng cho để liên kết với môi trường thực thi cho các chức năng ví dụ như quản lý tải/chu kì sống mà được định nghĩa bởi OMA hay nhóm khác. I2 là giao diện được sử dụng để liên kết với tài nguyên mạng phía dưới như các giao thức Internet hay hệ thống IN hay các giao diện SIP.

132

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..47: Các giao diện môi trường dịch vụ mở -OSE

Tương tác dựa trên WEB

Hình Error! No text of specified style in document..48 chỉ ra các bước xác định giao diện phát triển ứng dụng kết hợp với chức năng mục tiêu. Bước 1a/1b miêu tả hai bước lựa chọn khi phát triển ứng dụng. Bước 1c là quá trình tìm ra lựa chọn sẽ được thực hiện. Sau khi thiết lập một mối liên hệ, nhóm thứ ba có thể nhận biết tài nguyên được cung cấp bởi nhà cung cấp dịch vụ. Điều này có thể đạt được thông qua việc sử dụng của các chức năng tìm kiếm. Các giao diện của tài nguyên được liên kết xuyên suốt với các tổng đài khác giữa nhà cung cấp dịch vụ và nhóm thứ ba và kết hợp chặt chẽ bởi các nhà phát triển ứng dụng trong quá trình phát triển ứng dụng.

133

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..48: Tương tác dựa trên WEB

Các ứng dụng đã được tạo ra và phát triển trong môi trường thực thi ứng dụng, hiện tại ràng buộc với các giao diện phát triển ứng dụng chức năng này. Yêu cầu chính sách thực hiện các thay đổi nhằm điều khiển truy nhập nhóm thứ ba tới các chức năng. Yêu cầu chính sách tại mức logic điều khiển bất cứ sự thay đổi nào. Tuy nhiên, có một số trường hợp khi chính sách được áp dụng có thể là chính sách “không”. Nếu có thi hành yêu cầu chính sách sau đó yêu cầu phải được đi qua mà không được thực hiện. Khi việc thi hành yêu cầu chính sách không được thực hiện bất cứ yêu cầu nào, các nhà cung cấp dịch vụ có thể chọn không phát triển việc thi hành của yêu cầu chính sách.

Ban hành, tìm kiếm và thừa nhận

Ứng dụng thực tế của kiến trúc này áp dụng tại nơi các nhà cung cấp dich vụ thiết lập một dịch vụ Web độc lập. Chức năng tìm kiếm thực tế có thể chỉ là cơ sở dữ liệu của dịch vụ được thiết lập trên Web. Các ứng dụng nên được chấp nhận với các chức năng ra lệnh qua yêu cầu chính sách. Yêu cầu chính sách có thể áp dụng các chính sách khác nhau thông qua mức dịch vụ phù hợp. Vì thế, khi cần, các ứng dụng nên được phép truy nhập đến bộ chức năng.

Công nghệ Parlay

Một trong những khả năng vượt trội của Parlay là sự độc lập của mạng. Việc cung cấp dịch vụ luôn luôn chú trọng đến phát triển một dịch vụ xung quanh công nghệ mạng liên quan. Điều này có nghĩa là tốn kém trong việc cung cấp mạng chồng lấp, với thời gian tồn tại hạn chế, thường khoảng hai đến ba năm. Nhưng với Parlay có thể cung cấp vô số khả năng ứng dụng cho khách hàng mà không cần quan tâm đến việc họ sử dụng mạng IP, di động hay cố định. Parlay có thể đạt được điều này thông qua công nghệ Gateway duy nhất.

134

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..49: Mô hình kiến trúc GW Parlay

Các gateway thường được quan niệm giống như một số phần mềm firewall nằm giữa các mạng tin cậy và không tin cậy. Gateway Parlay đôi khi giống như truy nhập dịch vụ mở Open Service Access (OSA), không chỉ cung cấp chức năng này mà còn cung cấp khả năng cho phép các nhà cung cấp ứng dụng yêu cầu mạng thực hiện định tuyến, tìm và liên kết đến thuê bao.

Như chỉ ra trên Hình Error! No text of specified style in document..49, Gateway Parlay bao gồm hai phần chính :

Cơ cấu tổ chức Dịch vụ

1. 2. Cơ cấu tổ chức cung cấp khả năng cho phép các nhà vận hành mạng chuyển giao với các nhà cung cấp ứng dụng. Nó cung cấp các điểm khởi tạo liên kết ứng dụng khách tới điểm khai thác dịch vụ mà được yêu cầu bởi mạng, có thể sử dụng bởi ứng dụng. Nó coi tất cả yêu cầu bảo mật là bắt buộc và xác định bất cứ SLA nào.

Phần dịch vụ bao gồm số lượng lớn các giao diện tách biệt mà được thiết kế cho phép các nhà cung cấp ứng dụng truy cập tới các chức năng trong mạng ví dụ như quản lý di động, điều khiển cuộc gọi, hiện diện và tính sẵn sàng.

Các mặt phẳng cung cấp liên kết giữa các phần tử không được thể hiện tất cả ở hình trên, tuy nhiên các giao diện được xác định giữa:

Các ứng dụng và cơ cấu tổ chức Ứng dụng và chức năng dịch vụ Chức năng dịch vụ và các khuyến nghị phù hợp với các thành phần mạng phiá dưới Cơ cấu tổ chức và các chức năng dịch vụ

1. 2. 3. 4. Một trong những điểm mạnh của Parlay là được thừa nhận và tán thành như là chuẩn rộng rãi, được phát triển giữa 3GPP, 3GPP2 và ETSI và được tham khảo bởi ITU-T (và ATIS trong tài liệu NGN FW).

Parlay X

135

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Mặc dù Parlay API được thiết lập để cải tiến việc cung cấp dịch vụ tới thuê bao cuối, để API có ảnh hưởng tốt nhất trên thị trường, công nghệ này cần phù hợp với các nhà phát triển IT. Một số nhà phát triển IT không có khả năng điều khiển cuộc gọi và định tuyến cuộc gọi, vì thế cần có một cơ chế đơn giản hóa các miêu tả giao diện và cho phép các nhà phát triển dịch vụ WEB và IP trở thành một phần của giải pháp. Kết quả là ra đời Parlay X.

Các dịch vụ Web Parlay X được trừu tượng và đơn giản hóa từ Parlay API và được thể hiện trên Hình Error! No text of specified style in document..50. Các dịch vụ Web Parlay X có thể áp dụng bới các chức năng trên một Gateway Parlay với các khuyến nghị phù hợp giữa Parlay X và Parlay được cung cấp, hay Server Parlay với có thể sử dụng các dịch vụ Web qua liên kết trực tiếp tới tài nguyên mạng. Ứng dụng Parlay X có thể được viết bằng bất cứ ngôn ngữ nào giống như nó có thể thực hiện các yêu cầu Web phù hợp. Có rất nhiều công cụ khác nhau, cho các ngôn ngữ khác nhau, để khởi tạo, triển khai, và tương tác với các dịch vụ Web.

Hình Error! No text of specified style in document..50: Mô hình kiến trúc Parlay X

Parlay trong cấu trúc OSE

Việc kết hợp giữa các giao diện được định nghĩa bới OMA và Parlay/OSA nên được đơn giản hóa. OMA, mặc dù được định nghĩa giao diện trong OSE, không xác định các phương pháp độc lập truy nhập với các giao diện. Điều này được đưa xuống cho các nhóm chức năng độc lập trong phạm vi OMA.

Kết hợp giữa các phần tử

Các chức năng OMA, được xác định để phục vụ nhiều loại ứng dụng, kết hợp rất tốt với các chức năng dịch vụ. Nói cách khác, các chức năng dịch vụ từ mô hình OMA cho phép liên kết giữa các ứng dụng hay yêu cầu chính sách và mạng phía dưới.

136

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Cơ cấu tổ chức Parlay thực hiện một số các chức năng như là đàm phán SLA và các chức năng khác như OAM và quản lý chu kì sống, các chức năng mà thực hiện bởi môi trường chấp hành của OSE. Thêm vào đó, các thuộc tính dịch vụ của các chức năng dịch vụ Parlay và chức năng quản lý chính sách Parlay có thể sử dụng kết hợp với cơ cấu tổ chức Parlay cung cấp thêm chức năng yêu cầu chính sách OSE.

Để làm rõ mô hình, chúng ta đặt một số phần tử Parlay trong Cấu trúc OSE như trên Hình Error! No text of specified style in document..51.

Một chức năng OMA bao gồm các chức năng bên trong tương tác với các chức năng khác trong một miền kiến trúc. Ví dụ chức năng có thể là Gateway Parlay hay các chức năng dịch vụ hoặc các chức năng khác: điều khiển cuộc gọi …Về cơ bản chức năng giao tiếp với yêu cầu chính sách và các chức năng khác như nhận thức/cấp phép…khi cần thiết. Chúng cũng giao tiếp với tài nguyên mạng phía dưới.

Hình Error! No text of specified style in document..51: Parlay trong cấu trúc OSE

Parlay X trong cấu trúc OSE

Kiến trúc trên Hình Error! No text of specified style in document..52 mô tả vị trí của Parlay X trên nền kiến trúc OSE. Có ba ứng dụng thực tế của Parlay X được thể hiện trên hình này. Với mỗi ứng dụng, thông qua liên kết dịch vụ Web tương ứng, truy cập dịch vụ Web Parlay X thông qua chức năng thực thi chính sách.

137

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..52: Parlay X trong cấu trúc OSE

Như vậy, Parlay X là công nghệ quan trọng như một Gateway giữa môi trường IP và ứng dụng SIP của NGN. Việc phát triển và ứng dụng công nghệ Parlay X là cần thiết để đảm bảo thực hiện thông suốt các dịch vụ Web và các dịch vụ SIP NGN.

Sau đây là các khuyến nghị phát triển Parlay X.

1. Đối tượng

Xây dựng một ứng dụng cho sự cộng tác các dịch vụ Web và ứng dụng SIP NGN và đánh giá tính tin cậy và ổn định của giao diện, sự phức tạp của việc phát triển và hiệu quả của các dịch vụ.

2. Mục đích Việc phát triển các dịch vụ ứng dụng Web sử dụng giao diện Parlay X và phân tích các tín hiệu giữa GW Parlay X và sự đánh giá server WEB trong hiệu quả dịch vụ.

Ngôn ngữ lập trình Java/Javaserlet, Java 2 Platform, J2EE5, J2SE5 Eclipse Dịch vụ Web XML Giao thức truy cập đối tượng đơn giản –SOAP WSDL Các kiến thức viễn thông cơ bản (TCP/IP, SIP...)

3. Yêu cầu 1. 2. 3. 4. 5. 6. 7. Các dịch vụ trên nền NGN

Sau đây là một số loại hình dịch vụ điển hình trên nền NGN:

Truyền hình qua Internet

138

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hiện nay kiểu dữ liệu dạng video đang dần trở thành một kiểu dữ liệu phổ biến- giống như dữ liệu văn bản và nhiều dự án đã được xây dựng với mục đích khắc phục trở ngại về độ trễ của dữ liệu video trong các ứng dụng trên Internet.

Thương mại điện tử

Mặc dù thương mại điện tử đã trở nên quen thuộc trên mạng Internet, chúng ta vẫn chưa đánh giá hết được tiềm năng mà loại hình ứng dụng này có thể mang lại. Không có một loại ứng dụng nào khác trên Internet lại có thể liên kết được một số lượng khách hàng, dịch vụ, và thông tin lớn như thương mại điện tử. Các ứng dụng thương mại điện tử cũng có thể tận dụng cơ chế phân quyền dịch vụ khác biệt của mạng Internet thế hệ mới bởi một trong những điểm mạnh của thương mại trên Internet là khả năng cung cấp các sản phẩm và dịch vụ theo yêu cầu riêng của từng khách hàng.

Ứng dụng trong y học

Nhiều công nghệ Internet mới hiện nay đang được phát triển hướng tới việc nâng cao sức khoẻ của con người thông qua việc hỗ trợ nghiên cứu các lĩnh vực y tế mới (ví dụ phân tích chuỗi ADN và sử dụng cơ sở dữ liệu gene phân tán), chẩn đoán từ xa với sự trợ giúp của máy tính, xây dựng các phương pháp điều trị mới, phát triển các dược phẩm, nâng cao quy trình chăm sóc, khám và chữa trị cho bệnh nhân và đào tạo kiến thức y học từ xa.

Chính phủ điện tử

Hiện nay, hầu hết các hoạt động của các cơ quan tổ chức trong chính phủ đều có liên quan tới các thông tin trên Internet. Một số chính phủ trên thế giới đã thực hiện xây dựng các ứng dụng trên Internet để nâng cao khả năng hoạt động và quản lý của mình thông qua các kết nối trực tiếp tới các địa phương trực thuộc.

Nghiên cứu và giảng dạy từ xa

Ngày nay, môi trường giảng dạy kỹ thuật số trên mạng Internet thế hệ mới sẽ cung cấp thêm các tiện ích phụ trợ nhằm nâng cao chất lượng giảng dạy cũng như tăng tính hấp dẫn thông qua các ví dụ trực quan. Thông qua môi trường giảng dạy này, bất kỳ người nào có nhu cầu trau dồi thêm kiến thức đều có thể tham gia học tập bất kể các trở ngại về khoảng cách, về thời gian cũng như về lứa tuổi. Trên Internet thế hệ mới, chúng ta có thể sử dụng các phòng thí nghiệm ảo trong đó người học có thể tự mình thực hiện các bài tập và thử nghiệm để minh hoạ cho kiến thức đã thu nhận được.

Thư viện kỹ thuật số

Thư viện kỹ thuật số đang được thiết kế để có thể lưu giữ một khối lượng khổng lồ dữ liệu, bao gồm không chỉ sách điện tử, phim ảnh, âm thanh mà còn cả các đối tượng số nhằm mô phỏng lại các động thái của thế giới thực.

Ứng dụng định vị, địa chất, địa lý và khí tượng thuỷ văn

139

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hiện nay nhiều dự án nghiên cứu về định vị toạ độ toàn cầu, nghiên cứu thành phần địa chất, dựa báo khí tượng thuỷ văn có thể được thực hiện từ nhiều điểm phân tán trên toàn cầu thông qua hệ thống mạng Internet thế hệ mới.

1. 1.

2. 3. 4.

5. 6. 7. 8. 9.

Yêu cầu chung Có thể truy nhập tới bất kỳ kiểu thông tin nào, ví dụ như các ứng dụng đa phương tiện thời gian thực Có khả năng tương tác thông tin giữa hai điểm bất kỳ trên hệ thống mạng toàn cầu Có khả năng đảm bảo toàn vẹn dữ liệu và thông tin Có khả năng biến đổi thông tin thành các tri thức có thể nhận biết, ví dụ các công cụ phân tích chuyên dụng Có khả năng truy nhập và xử lý khối lượng thông tin lớn Có khả năng truy nhập tới các thiết bị chuyên dụng Trợ giúp các khả năng cảm nhận của con người Cho phép nhiều ứng dụng khác nhau có thể sử dụng cùng một tập hợp các dịch vụ mạng Không chỉ gắn với một vài ứng dụng cụ thể mà phải cho phép nhiều ứng dụng khác nhau có thể sử dụng cùng một tập hợp dịch vụ. Cung cấp khả năng giám sát và quản lý các tài nguyên mạng một cách tối ưu.

10. Một số xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Xu hướng phát triển mạng và dịch vụ Internet

Phân loại nhà khai thác dịch vụ

Có thể phân loại các nhà khai thác mạng Internet thế hệ mới thành 5 loại như sau:

- Nhà cung cấp mạng trục

- Nhà cung cấp dịch vụ Internet

- Nhà cung cấp đa dịch vụ tích hợp

- Nhà cung cấp dịch vụ truy nhập nội hạt

- Nhà cung cấp dịch vụ thông tin di động

Các phương án phát triển mạng

Dù các nhà cung cấp dịch vụ Internet muốn triển khai những dịch vụ mới của mạng Internet thế hệ sau, họ vẫn phải quan tâm đến việc tận dụng cơ sở hạ tầng mạng cũ.

Khó khăn lớn nhất của các nhà khai thác mạng Internet truyền thống là làm sao lựa chọn giải pháp và thực hiện chúng trong khi vẫn duy trì các hoạt động cũ. Hiện nay đang có 3 phương án đang được các nhà khai thác và cung cấp dịch vụ Internet quan tâm trong giai đoạn chuyển đổi lên Internet thế hệ mới.

1. Lạc quan: tối đa hoá lợi nhuận trên hạ tầng viễn thông sẵn có 140

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

2. 3.

Hiện đại hoá: tối đa hoá lợi nhuận và đưa thêm các dịch vụ mới. Tiên phong: hoạt động với mục tiêu trở thành những công ty hàng đầu trong thị trường số liệu/IP tương lai. Sự phát triển của công nghệ Web

Mỗi công nghệ đều có các đặc điểm và tính năng riêng biệt xác định. Tương tự, công nghệ Web có các tính năng như dữ liệu, các dịch vụ, mess-up, các giao diện lập trình ứng dụng API, các platform xã hội,… Các tính năng này liên tục được phát triển qua các giai đoạn khác nhau. Sự phát triển công nghệ Web đã trải qua một số thế hệ từ Web 1.0 được xem là Web nhận thức, đến Web 2.0 được xem là Web truyền thông, và Web thế hệ kế tiếp (Web 3.0) được xem là Web hợp tác.

Cùng với sự phát triển về mặt công nghệ, thiết kế Web cũng thay đổi theo thời gian. Thiết kế Web ban đầu là hệ thống chỉ đọc siêu văn bản đơn giản, hệ thống này cho phép người sử dụng đọc thông tin. Người sử dụng chỉ là người quan sát thông tin được biểu diễn trên trang Web. Dần dần, các hình ảnh và các bảng biểu được bổ sung với sự phát triển của ngôn ngữ đánh dấu siêu văn bản HTML và các trình duyệt Web, cho phép việc thiết kế trở nên tốt hơn. Sự phát triển của các công cụ soạn thảo hình ảnh, các công cụ ủy quyền Web và các công cụ quản lý nội dung cho phép người thiết kế bắt đầu tạo ra các thiết kế Website hấp dẫn.

Trong giai đoạn phát triển kế tiếp, thiết kế Web thay đổi cùng với sự thay đổi về sự tiện dụng và sự tập trung hướng tới người sử dụng hơn là nội dung của Website. Quan hệ xã hội và tương tác người sử dụng được ứng dụng trong việc thiết kế Web. Người sử dụng không chỉ là người quan sát mà còn có thể điều khiển Web với sự phản hồi, chia sẻ thông tin, đánh gía và cá nhân hóa. Dần dần chúng ta có sự hỗn hợp chức năng, khuôn dạng, nội dung và tương tác, được gọi là Web đọc/viết. Tiếp tục sự phát triển, ngữ nghĩa được bổ sung vào thông tin được trình bày trên Web để các biểu diễn ảo cho con người có thể đọc và biên dịch thông tin được biểu diễn. Kiểu Web mà trong đó tác nhân người sử dụng mô phỏng theo phản ứng của con người, có thể đọc và hiểu thông tin sử dụng trí tuệ nhân tạo được gọi là Web ngữ nghĩa.

Web 1.0

Thế hệ đầu tiên của Web được gọi là “Web 1.0” hoặc đơn giản là “Web”. Web 1.0 còn có các tên gọi khác là “Read Web”, “Old Web” hoặc “Static Web”. Web 1.0 đề cập tới các tính năng chính của WWW trong suốt quãng thời gian 10 năm tồn tại (1994-2004). Web 1.0 chủ yếu là môi trường xuất bản thông tin một chiều. Mục tiêu chính của Web 1.0 là xuất bản thông tin để có thể truy nhập một cách dễ dàng bởi người dùng sử dụng trình duyệt Web tiêu chuẩn qua mạng Internet. Do đó, Web 1.0 được sử dụng cho các ứng dụng thương mại và các giao dịch trực tuyến, làm tiền đề cho sự ra đời của thương mại điện tử. Các nền tảng của Web được thiết lập trong giai đoạn này. Sự phát triển và những tiến bộ chủ yếu là các giao thức như HTTP, các ngôn ngữ đánh dấu như HTML và XML, các ngôn ngữ Web-centric như Java và JavaScript, các trình duyệt Web, các platform và các công cụ phát triển Web, sự tạo ra các hoạt động học thuật Website, việc sử dụng Web cho các mục đích thương mại lần đầu tiên, sự xuất hiện của các mô hình kinh doanh Web mới, và sự phát triển của các Web portal.

141

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Web 1.0 là Web trung tâm thông tin (information-centric), trong đó các Website là nơi tập trung thông tin. Người sử dụng truy nhập Internet và tìm kiếm thông tin được tập trung, được bổ sung dữ liệu bởi Webmaster chịu trách nhiệm cập nhật nội dung. Không ai có quyền thay đổi nội dung. Kinh nghiệm của người sử dụng bị hạn chế trong việc tìm kiếm danh mục và đọc nội dung. Những hạn chế của Web 1.0 bị ảnh hưởng bởi giai đoạn phát triển ban đầu của cả công nghệ phần mềm và phần cứng. Ví dụ, việc tạo ra các trang Web yêu cầu sự thành thạo về lập trình vì các trang Web này chỉ có thể được tạo ra sử dụng ngôn ngữ HTML. Về mặt phần cứng, băng thông bị hạn chế, và năng lực xử lý của các máy tính khá thấp.

Hình Error! No text of specified style in document..53 Kiến trúc Web 1.0 điển hình

Các đặc tính của Web 1.0 có thể được tổng kết như sau:

3. 4.

Trong Web 1.0, Webmaster là người chịu trách nhiệm quản lý nội dung và duy trì cập nhật cho người sử dụng. Hầu hết các siêu liên kết tới các nội dung được thực hiện nhân công bởi Webmaster; Web 1.0 không hỗ trợ xuất bản thông tin rộng rãi. Nội dung trên Website được xuất bản bởi Webmaster và do đó không thúc đẩy trí tuệ tập thể của người sử dụng; Web 1.0 sử dụng ngôn ngữ đánh dấu siêu văn bản cơ bản để xuất bản nội dung trên Internet; Web 1.0 không hỗ trợ nội dung có thể đọc bởi máy. Chỉ người đọc Web có thể hiểu được nội dung; Web 1.0 cung cấp thông tin liên lạc (email, số điện thoại, fax, hoặc địa chỉ) cho mục đích truyền thông. Người sử dụng vẫn phải sử dụng các công cụ không trực tuyến khác để truyền thông với thông tin liên lạc này; Trong Web 1.0, các trang Web được thiết kế để phản ứng theo bản năng dựa trên điều kiện được lập trình. Kết quả hoặc đáp ứng cụ thể được tạo ra khi điều kiện được lập trình được thỏa mãn. Mô hình Web 1.0 không hiểu yêu cầu từ xa và không thể chuẩn bị đáp ứng đối với yêu cầu tiềm năng.

Như vậy, ở thế hệ Web 1.0 thì người viết xuất bản nội dung dưới dạng các trang Web trên mạng Internet và người đọc đọc các trang Web này trực tuyến và không có sự truyền thông trực tiếp giữa người viết và người đọc.

Web 2.0

142

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Thuật ngữ Web 2.0 được chính thức định nghĩa vào năm 2004 bởi Dale Dougherty, phó chủ tịch của O’Reilly Media, trong hội nghị tổ chức bởi O’Reilly và MediaLive International. Tim O’Reilly định nghĩa Web 2.0 như sau:

“Web 2.0 là sự phát triển kinh doanh trong nền công nghiệp máy tính do sự dịch chuyển tới Internet như là nền tảng, và sự cố gắng hiểu các quy tắc để có thể thành công trên nền tảng mới đó. Quy tắc chủ yếu là: Xây dựng các ứng dụng khai thác các hiệu quả mạng tốt hơn thì nhiều người hơn sẽ sử dụng các ứng dụng này” [2].

Web 2.0 còn được gọi là “Wisdom Web”, “People-centric Web”, “Participate Web”, hoặc “Read- Write Web”. Trong Web 2.0, ý tưởng về người tiêu thụ (người sử dụng) và người cung cấp (Webmaster) không còn nữa. Web 2.0 hướng tới truyền thông và tương tác giữa những người sử dụng. Trong Web 2.0, người sử dụng truyền thông qua các blog, wikis, và các trang mạng xã hội. Mọi thứ trên Web được gắn thẻ (tag), giúp cho việc điều hướng nhanh và dễ dàng hơn. Web 2.0 kết hợp mọi thứ trong một trang Web đơn bằng cách gắn thẻ và sử dụng AJAX với sự hữu dụng hơn qua nhiều không gian trắng và bài trí tốt hơn. Khả năng của giao diện lập trình ứng dụng API làm cho người lập trình có thể mash up các feed dữ liệu và các cơ sở dữ liệu để tham chiếu chéo thông tin từ nhiều nguồn trong một trang. Ngược với Web 1.0, Web 2.0 có trí tuệ tập thể của hàng triệu người sử dụng.

Hình Error! No text of specified style in document..54: Kiến trúc Web 2.0 điển hình

Web 2.0 không chỉ là phiên bản kế tiếp của Web 1.0; mà sự thiết kế Web linh hoạt, việc tái sử dụng sáng tạo, sự tạo ra và thay đổi nội dung một cách hợp tác cũng được thực hiện qua Web 2.0. Một trong những tính năng nổi trội của Web 2.0 là hỗ trợ sự hợp tác và giúp tập hợp trí tuệ tập thể hơn Web 1.0. Bảng 1.1 so sánh các tính năng giữa Web 1.0 và Web 2.0.

Bảng Error! No text of specified style in document..6: So sánh Web 1.0 và Web 2.0

Web 2.0 Web 1.0

Đọc/viết Chỉ đọc

Cộng đồng Các công ty

143

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Client-Server Peer to Peer

HTML, Portals XML, RSS

Taxonomy Tags

Sở hữu Chia sẻ

IPOs Bán hàng thương mại

Netscape Google

Các định dạng Web Các ứng dụng Web

Ảnh cắt màn hình APIs

Quay số Băng rộng

Chi phí phần cứng Chi phí băng thông

Thuyết trình Hội thoại

Các dịch vụ được bán qua Web Các dịch vụ Web

Các portal thông tin Các platform

Các đặc tính của Web 2.0 có thể tổng kết như sau:

1. Web 2.0 là phiên bản thứ hai của Web cung cấp ứng dụng Internet giàu có RIA với kinh

nghiệm giống như của máy tính để bàn, chẳng hạn chức năng “Kéo và thả” trên trang Web bằng trình duyệt;

2. Kiến trúc hướng dịch vụ SOA là phần cơ bản trong Web 2.0. Các từ thông dụng xung quanh SOA là các Feed, RSS, các dịch vụ Web và mash up, các phần tử này định nghĩa phương thức mà ứng dụng Web 2.0 thực hiện chức năng để các ứng dụng khác có thể thúc đẩy và tích hợp các chức năng này, cung cấp tập giàu có hơn các ứng dụng;

3. Web 2.0 là Web xã hội. Ứng dụng Web 2.0 hướng tới tương tác nhiều hơn với người sử dụng đầu cuối. Các người sử dụng đầu cuối không chỉ là những người sử dụng ứng dụng mà còn là các thành phần tham gia bằng cách gắn thẻ nội dung, trong đó người này đóng góp cho wiki hoặc podcast cho blog. Do tính chất xã hội của ứng dụng, người sử dụng đầu cuối là thành phần thời gian của dữ liệu đối với ứng dụng, cung cấp các phản hồi và cho phép ứng dụng thúc đẩy người dùng sử dụng nó;

4. Trong thuật ngữ và chiến lược Web 2.0 thì “Web là môi trường mở”. Nội dung khả dụng

được di chuyển và được thay đổi bởi người sử dụng bất kỳ. Nội dung Website không được điều khiển bởi người viết ra Website nhưng bởi người dùng sử dụng Website;

5. Trong Web 2.0, dữ liệu là động lực. Người sử dụng sẽ sử dụng nhiều thời gian hơn trực tuyến và bắt đầu tập hợp nội dung trong thời gian thụ động của mình. Web 2.0 yêu cầu một số 144

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

công nghệ cơ bản được sử dụng trong việc phát triển các trang Web. Một trong những công nghệ quan trọng là AJAX, công nghệ này hỗ trợ sự phát triển kinh nghiệm của người sử dụng tiềm năng.

6. Các công nghệ và dịch vụ chính của Web 2.0 bao gồm các blog, tổ chức cung cấp đơn giản thực sự RSS, wiki, mashup, tag, folksonomy và các đám mây gắn thẻ, được mô tả ngắn gọn như sau:

1. Blog: Thuật ngữ weblog (hoặc blog) được đề nghị bởi Jorn Barger vào năm 1997. Blog bao

gồm các trang Web, được gọi là các bổ sung dữ liệu (các post), được xuất bản theo thời gian, mà kiểu gần đây nhất là ở dạng tạp chí. Các khách viếng thăm các blog có thể bổ sung lời bình luận dưới một blog entry. Hầu hết các blog là ở dạng văn bản, tuy nhiên cũng có các thể loại khác như photoblog hay photolog, videoblog hay vlog, và podcast. Việc bổ sung dữ liệu các blog có thể được gắn thẻ bằng các từ khóa để phân loại các chủ đề của các bổ sung dữ liệu. Chẳng hạn, khi bổ sung dữ liệu trở nên cũ, nó có thể được tập hợp thành một hệ thống menu dựa trên chủ đề, tiêu chuẩn. Sự liên kết là khía cạnh quan trọng khác của blog. Sự liên kết phụ thuộc vào tính chất hội thoại của blogsphere và cảm nhận tức thì, giúp thu hồi và tham chiếu thông tin trên các blog khác nhau;

2. RSS (tổ chức cung cấp đơn giản thực sự): RSS là họ các khuôn dạng Web feed, được sử dụng để tổ chức cung cấp nội dung từ các blog hoặc các trang Web. RSS là một tệp XML, tóm tắt các biểu tượng thông tin và liên kết tới các nguồn thông tin. Sử dụng RSS, người sử dụng được thông báo về việc cập nhật blog hoặc trang Web mà họ quan tâm. Atom là đặc tả tổ chức cung cấp khác, hướng tới giải quyết vấn đề của các phiên bản RSS không tương thích;

3. Wiki: Một Wiki là một trang Web (hoặc tập các trang Web) có thể dễ dàng được soạn thảo bởi người bất kỳ được phép truy nhập. Không giống các blog, các phiên bản trước đây của Wiki có thể được kiểm tra bởi chức năng lịch sử và có thể được lưu giữ bởi chức năng rollback. Các tính năng của Wiki bao gồm: ngôn ngữ đánh dấu Wiki, điều hướng và cấu trúc site đơn giản, template đơn giản, hỗ trợ nhiều người sử dụng, tính năng tìm kiếm được cài đặt sẵn và workflow đơn giản. Wiki phổ biến nhất có lẽ là Wikipedia, một bộ bách khoa trực tuyến, trong đó người sử dụng không chỉ đọc các bài báo mà còn có thể tạo các đóng góp mới hoặc soạn thảo và chỉnh sửa các đóng góp của những người sử dụng khác.

4. Một loại hình khác của các ứng dụng Web 2.0 rất phổ biến là các dịch vụ mạng xã hội như

MySpace, Facebook, Twitter,… trong đó người sử dụng có thể tạo ra profile của chính mình, upload các hình ảnh, xây dựng các nhóm hoặc hình thành các mạng kết bạn;

Gắn thẻ xã hội (social tagging) đề cập đến việc tạo ra một cách hợp tác và quản lý các thẻ (tag) để chú giải và phân loại nội dung web như các bài báo trong các web log, hình ảnh, video, hoặc các bookmark. Các thẻ này có thể được chọn tùy ý bởi người sử dụng. Ý tưởng cơ bản của khái niệm này là phân loại thông tin đối với người sử dụng, nhưng cũng có thể làm cho nó khả dụng đối với những người sử dụng khác để tìm kiếm các chủ đề và tìm kiếm dữ liệu phù hợp dựa trên các tag. Tập hợp nội dung được gắn thẻ được gọi là folksonomy, từ kết

145

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

hợp của folk và taxonomy. Quá trình gắn thẻ tập hợp và quản lý các bookmark trên Web được gọi là social bookmarking. Một trong những dịch vụ Web đánh dấu xã hội phổ biến là Delicious;

Một số ứng dụng phần mềm xã hội khác tồn tại, chủ yếu tập trung vào một hoặc một số ít dịch vụ. Ví dụ như việc chia sẻ video trên các Website như Youtube hoặc các cộng đồng chia sẻ hình ảnh như Flickr hoặc Picasa;

Mashup: Web mashup là trang Web hoặc Website kết hợp thông tin và các dịch vụ từ nhiều nguồn trên Web để tạo ra ứng dụng mới. Các Mashup nói chung được tạo ra sử dụng các giao diện lập trình ứng dụng API. Thông thường, sự tích hợp dễ dàng qua các giao diện lập trình ứng dụng API nên khả dụng thỏa mãn các dịch vụ hoàn toàn mới có thể được phát triển dễ dàng, cung cấp các tính năng không được hỗ trợ bởi các nguồn cơ sở ban đầu. Ví dụ, việc kết nối các bài báo Wikipedia với vị trí của chúng, chẳng hạn như dữ liệu bản đồ nhận được từ Google Maps, được cung cấp bởi Placeopedia. Các Mashup có thể được nhóm thành bảy thể loại: bản đồ, tìm kiếm, di động, bản tin, thể thao, shopping, và phim ảnh. Hơn 40 phần trăm các mashup là các mashup bản đồ. Có thể dễ dàng và nhanh chóng tạo ra các mashup hơn là thực hiện mã hóa các ứng dụng từ đầu theo cách truyền thống; khả năng này một trong những tính năng có giá trị nhất của Web 2.0;

Một số công cụ phát triển khả dụng để tạo ra các blog, wiki, và các mạng xã hội. Các công cụ này, chẳng hạn như các công cụ mashup, các wiki engine, phần mềm blog, làm cho sự lựa chọn Web 2.0 dễ dàng hơn, nhanh hơn và rẻ hơn. Những người phát triển sử dụng ba phương pháp cơ bản để tạo ra các ứng dụng Web 2.0 là: Javascript không đồng bộ và XML (AJAX), Flex, và Google Web Toolkit.

AJAX (Javascript không đồng bộ và XML) là phương pháp phát triển Web được sử dụng để phát triển hầu hết các Website tương tác bằng cách gọi ra lượng nhỏ dữ liệu từ Web Server và hiển thị nó lên ứng dụng Web mà không cần tải lại toàn bộ trang Web. Quá trình này được gọi là tải theo yêu cầu. AJAX bao gồm một số kỹ thuật quan trọng sau: HTML (ngôn ngữ đánh dấu siêu văn bản) hoặc XHTML (ngôn ngữ đánh dấu siêu văn bản mở rộng) đối với việc biểu diễn nội dung Web dựa trên tiêu chuẩn; CSS (các trang kiểu xếp tầng) đối với việc định dạng các trang Web; Hiển thị động và tương tác sử dụng DOM (mô hình đối tượng tài liệu); Trao đổi và thao tác dữ liệu sử dụng XML (ngôn ngữ đánh dấu mở rộng); XMLHttpRequest đối với việc trao đổi dữ liệu không đồng bộ với Web Server; JavaScript đối với việc biểu diễn nội dung động và là giao diện giữa các phần tử đơn lẻ. 7. 8. 9. 10. 11.

146

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

a) Mô hình ứng dụng Web cổ điển b) Mô hình ứng dụng Web AJAX

Hình Error! No text of specified style in document..55 Các mô hình ứng dụng Web cổ điển và AJAX

Hình Error! No text of specified style in document..55a) mô tả mô hình ứng dụng Web cổ điển. Tương tác được thực hiện bởi người sử dụng (ví dụ đệ trình một khuôn dạng), dẫn đến một yêu cầu HTTP được gửi tới Web Server, Web Server thực hiện một số xử lý, lưu giữ hoặc đọc dữ liệu và gửi trang HTML được xây dựng mới ngược trở lại phía client. Mô hình này được thiết kế đối với World Wide Web chỉ gồm các tài liệu siêu văn bản, nhưng không bao gồm các ứng dụng phức tạp, trong đó lượng lớn dữ liệu cần thiết được truyền tải. Một kinh nghiệm người sử dụng giàu có, cần thiết trong thời điểm của Web 2.0, không thể được thực hiện sử dụng mô hình này. Một cách tối ưu, người sử dụng thậm chí không chú ý khi dữ liệu cần được tải lại từ Web Server.

Với sự giới thiệu của phương tiện trung gian, AJAX engine, như được mô tả trên Hình Error! No text of specified style in document..55b), vấn đề trên có thể được điều khiển. Thay vì yêu cầu HTTP, tương tác người sử dụng ở phía client, dẫn đến JavaScript call được truyền tải tới AJAX engine. Nếu không cần thiết kết nối tới Web Server, AJAX engine trả lời bởi chính bản thân nó. Nếu một số dữ liệu cần được tải từ Server, một yêu cầu dữ liệu không đồng bộ tới Server (thông qua XML) được thực hiện. Sử dụng mô hình này, tương tác của người sử dụng với ứng dụng Web không bị dừng.

Như được mô tả ở trên, ưu điểm chính của việc sử dụng công nghệ AJAX là chỉ có dữ liệu cần được cập nhật phải được tải từ Server, tức là chỉ có một phần của trang Web được tải lại. Điều này có thể giảm thời gian tải Website đáng kể. Do đó, giao diện người sử dụng có thể đáp ứng nhanh hơn tới các yêu cầu của người sử dụng, giúp đạt được kinh nghiệm người sử dụng giàu có. Ngoài ra, việc sử dụng băng thông có thể giảm do các tầng (style sheet), chẳng hạn, phải được tải chỉ bởi client.

Tuy nhiên, AJAX cũng có một số nhược điểm. Trước tiên, một số người sử dụng vẫn sử dụng các trình duyệt không hỗ trợ AJAX hoặc người sử dụng có JavaScript bị cấm thỏa mãn Website được xây dựng

147

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

sử dụng các công nghệ AJAX không thể được hiển thị phù hợp. Thứ hai, nút “Back” của trình duyệt không làm việc như mong đợi đối với các trang Web dựa trên AJAX. Thay vì đi tới trạng thái cuối cùng của Website được hiển thị, nó dẫn người sử dụng tới trang cuối cùng. Để giải quyết vấn đề này, tuy nhiên, một số phương thức giải quyết tồn tại. Nhược điểm cuối cùng là việc sử dụng AJAX có thể giới thiệu một số vấn đề bảo mật mới và làm cho Website có thể bị nguy hiểm với các tấn công.

Flex: Adobe Flex là kit phát triển phần mềm (SDK) để tạo và phân phát các ứng dụng Internet giàu có (RIA) dựa trên Web. Flex dựa trên Flash và hỗ trợ các mẫu thiết kế phổ biến bằng cách cung cấp ngôn ngữ lập trình; Google Web Toolkit (GWT): là khuôn dạng phát triển Java nguồn mở, tạo ra các ứng dụng AJAX dễ dàng. GWT cho phép nhà phát triển Web thực hiện debug các ứng dụng AJAX trong ngôn ngữ Java sử dụng các công cụ phát triển Java trong lựa chọn của mình. GWT cung cấp một trình biên dịch và trình duyệt Web đặc biệt, giúp những nhà phát triển Web thực hiện debug các ứng dụng GWT.

Như vậy, công nghệ Web đã rất phát triển kể từ khi Wikipedia được thiết lập vào năm 2001. Các ứng dụng ngày nay đã trở nên mạnh hơn và cho phép người sử dụng hoàn thành nhiều nhiệm vụ hơn một cách dễ dàng hơn trước rất nhiều. Có thể nói giai đoạn 2005-2007 là thời điểm chuyển dịch đáng kể của các ứng dụng Web. Giai đoạn này đánh dấu những sự phát triển sau đây:

3. Sự thay đổi lớn trong các mô hình tương tác người sử dụng như là kết quả của việc lựa chọn công nghệ Web 2.0 và các mẫu kinh nghiệm người sử dụng (UX Pattern); Các phần mềm blog/xuất bản trở nên mạnh hơn. Việc soạn thảo WSIWYG/rich trở nên phổ biến trong giai đoạn này; Sự phát triển của các phần mềm mạng xã hội và các ứng dụng Web với thành phần xã hội (ví dụ như MySpace, Facebook, Flickr, Twitter,…)

Hình Error! No text of specified style in document..56 mô tả một số sự phát triển trong lĩnh vực tham gia trực tuyến và tương tác người sử dụng.

148

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..56: Sự phát triển Web trong lĩnh vực tham gia trực tuyến và tương tác người sử dụng

Công nghệ Web 2.0 dẫn đến sự phát triển rộng rãi của các ứng dụng Web, các sự kiện quan trọng có thể kể đến là:

Vào ngày 5 tháng 4 năm 2006, W3C đã xuất bản bản draft đầu tiên về đối tượng JavaScript, điều này cho phép áp dụng sức mạnh thực sự của công nghệ AJAX; Gmail, một trong những triển khai trên quy mô lớn đầu tiên, với việc sử dụng chủ yếu AJAX, đã được khai trương vào giữa năm 2004. Vào tháng 2 năm 2007, Gmail được mở cho mọi người sử dụng; Facebook mở dịch vụ tới công chúng vào tháng 9 năm 2006; Twitter khai trương vào năm 2006; Moveable Type khai trương bộ soạn thảo WYSIWYW vào tháng 6 năm 2007. 3. 4. 5. Một số sự kiện phát triển khác có thể kể đến là:

Yahoo Answer khai trương vào ngày 5 tháng 7 năm 2005; Answers.com khai trương vào tháng 1 năm 2005; Wikia được thiết lập vào cuối năm 2004, được đổi tên vào ngày 27 tháng 3 năm 2006.

1. 2. 3. Như vậy, Web 2.0 là phiên bản cải tiến của World Wide Web với vai trò thay đổi và mô hình kinh doanh phát triển trong đó người sử dụng có thể truyền thông với nhau, thay vì chỉ truyền thông với người xuất bản nội dung như trong Web 1.0. Mặc dù Web 2.0 đã rất phát triển kể từ khi ra đời vào năm 2004, Web 2.0 vẫn còn tồn tại nhiều hạn chế, có thể tổng kết như sau:

Các hạn chế của ngôn ngữ HTML: Mặc dù lượng lớn nội dung Web động đã phát triển, phần lớn World Wide Web vẫn gồm các tài liệu HTML tĩnh. Một số vấn đề gặp phải khi làm việc với ngôn ngữ HTML là các liên kết dễ bị bẻ gãy, tập các thẻ (tag) cố định, khuôn dạng hạn chế và các kết quả tìm kiếm không thực sự hiệu quả. Ở thời điểm hiện tại, hầu hết các engine tìm kiếm thực hiện việc tìm kiếm chỉ sử dụng thông tin được hiển thị trên trang Web. Cú pháp,

149

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

sự phù hợp, và/hoặc ngữ nghĩa của sự kiện tìm kiếm không được đưa vào xem xét. Điều này cơ bản dẫn đến rất nhiều kết quả không phù hợp và người sử dụng phải bỏ nhiều công sức để xem xét các kết quả. Vấn đề khác mà người sử dụng gặp phải là các bộ biên dịch ngôn ngữ không cung cấp các kết quả chính xác. Chúng hướng tới đưa ra việc biên dịch từ theo từ (word to word) thay vì biên dịch theo nội dung và ngữ cảnh. Điều này là do hệ quả thực tế rằng bộ biên dịch không thể hiểu những gì mà người sử dụng thực sự muốn biên dịch. Vấn đề này bắt nguồn cơ bản ở thực tế rằng ngôn ngữ HTML không hỗ trợ việc định nghĩa các tag, việc định nghĩa này cho phép nhà thiết kế định nghĩa thể loại hoặc ngữ cảnh của một Website.

Các ứng dụng được phát triển tập trung vào sự tiện nghi cho con người. Các công nghệ đằng sau các ứng dụng ở các dạng mà con người hướng tới, dẫn tới sự khó hiểu dữ liệu (data confusing) đối với người sử dụng máy, do đó làm cho việc cơ giới hóa các nhiệm vụ trở nên phức tạp.

Hầu hết các dịch vụ Web 2.0 được thiết lập ở các dạng quy tắc “free economy” và “free community”. Việc truy nhập tới hầu hết thông tin là miễn phí và phần mềm là mở, dẫn tới các dịch vụ phải đương đầu với các thách thức về lợi nhuận.

Thiếu các Web server thông minh để tránh hiện tượng tắc nghẽn nút cổ chai (bottle-neck) khi dịch vụ bên thứ ba xây dựng các khối truy nhập bởi các mash-up client trực tiếp.

Thiếu các phương pháp và mô hình hóa để hỗ trợ việc thiết kế RIA UI, không hỗ trợ sự tương thích ngữ nghĩa từ UI của Web 1.0 tới UI của Web 2.0.

Thiếu tổ chức thẩm quyền trung tâm thực hiện việc tổ chức và tiêu chuẩn hóa phương thức mà Web được quản lý.

10.

Các thách thức về an ninh và bảo mật do sự phơi bày thông tin cá nhân/tổ chức trên Web 2.0.

Cung cấp các khả năng truy vấn tồi: thiếu sự biểu diễn dữ liệu tổng quát. 11.

12.

Quá tải thông tin: Quá tải thông tin phân tán với chất lượng không đáng tin cậy được xem là vấn đề nghiêm trọng.

Chu kỳ lặp lại không đổi của việc thay đổi và nâng cấp các dịch vụ. 13.

14.

Các vấn đề nguyên tắc trong việc xây dựng và sử dụng Web 2.0: Các công nghệ và các dịch vụ mới của Web 2.0 bắt đầu cho thấy sự hạn chế theo thuật ngữ sự riêng tư và bản quyền.

15.

Vấn đề liên kết nối: Sự liên kết nối và kiến thức chia sẻ giữa các nền tảng (platform) qua các ranh giới giữa cộng đồng vẫn còn bị hạn chế.

16. Sự không hiệu quả của các hệ thống chia sẻ thông tin trong các ứng dụng Web.

150

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

17.

Sự tin cậy của các Website và các nội dung bên trong chúng: Vì Web là môi trường mở, nên độ tin cậy của các Website và thông tin mà nó lưu giữ vẫn là vấn đề cần trả lời.

18.

Truy nhập toàn cầu: Một thách thức mà Web 2.0 phải đương đầu là đảm bảo rằng tất cả các nhà phát triển Web và các nhà thiết kế Web tuân theo một nguyên tắc truy nhập trong việc cung cấp sự mô tả, tối ưu hóa việc truy nhập tới tất cả người sử dụng Web, đặc biệt là những người khuyết tật.

Khi Web 2.0 được so sánh với thế hệ Web kế tiếp, Web 3.0 cung cấp một hạ tầng chung cho việc trao đổi, tích hợp và tái sử dụng sáng tạo dữ liệu có cấu trúc, sẽ khắc phục được những hạn chế nêu trên của Web 2.0.

Web thế hệ kế tiếp

Ý tưởng chính của công nghệ Web 3.0 thế hệ kế tiếp là tạo ra nội dung Web bằng cách không sử dụng ngôn ngữ tự nhiên mà ở dạng tập lệnh (script) có thể hiểu được và phán đoán được bởi các agent phần mềm để cho phép chúng tìm kiếm, chia sẻ hoặc tích hợp thông tin dễ dàng hơn và hiệu quả hơn, hướng tới các ứng dụng thông minh. Mục đích chủ yếu của công nghệ Web 3.0 là hỗ trợ người sử dụng đóng góp thông tin theo các phương thức mà máy tính có thể hiểu được, xử lý và trao đổi. Những sự phát triển của công nghệ Web cho phép ứng dụng Web thực hiện các nhiệm vụ như so sánh thông tin từ những nguồn khác nhau và hỗ trợ người sử dụng tìm kiếm thông tin phù hợp theo yêu cầu một cách hiệu quả.

Hình Error! No text of specified style in document..57: Xu hướng phát triển công nghệ Web

Tính chất linh hoạt cung cấp bởi công nghệ trong những năm gần đây đã làm tăng sự quan tâm tới thế hệ mới của công nghệ Web, được chỉ thị bởi số lượng tăng nhanh của markup ngữ nghĩa khả dụng trên Web, số lượng các tổ chức bắt đầu tiến hành nghiên cứu và phát triển các hoạt động liên quan và số lượng các ứng dụng Web 3.0 tồn tại. Tất cả những điều này cho thấy Web 3.0 dường như đang ở giai đoạn đầu tiên của sự phát triển. Sự khả dụng của markup ngữ nghĩa sẽ mở ra những khả năng về mặt lý thuyết để phát triển các chức năng và các ứng dụng dựa trên Web thông minh. Các

151

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

ứng dụng của Web 3.0 sẽ hỗ trợ việc tích hợp và biểu diễn dữ liệu thông minh, tìm kiếm ngữ nghĩa, chú giải tự động, trả lời câu hỏi và duyệt Web ngữ nghĩa. Web 3.0 sẽ gồm những tính năng bổ sung như micro format, tìm kiếm ngôn ngữ tự nhiên, khai phá dữ liệu, học máy, các agent khuyến nghị và các công nghệ trí tuệ nhân tạo, nhấn mạnh tầm quan trọng của việc máy hiểu thông tin.

Từ quan điểm công nghệ, Web 3.0 là sự kết hợp của công nghệ Web và biểu diễn tri thức (KR), là cấu trúc con của trí tuệ nhân tạo. Sự kết hợp này cơ bản quan tâm tới việc xây dựng và duy trì các mô hình cho phép suy diễn về bản thân và những thông tin liên quan. Đồng thời, phạm vi đối với việc phát triển ứng dụng cũng mở rộng nhanh chóng, ví dụ W3C đã bắt đầu phát triển Ubiquitous Web. Nhiều công ty cũng bước đầu hướng tới công nghệ Web 3.0 như công ty Mondeca, một hãng lớn ở Châu Âu về tích hợp thông tin; Ontoprise, một công ty của Đức về các công cụ liên quan đến ontology. Các hãng lớn như Oracle, Microsoft và IBM cũng đã tập trung nghiên cứu phát triển công nghệ Web 3.0.

Điện toán đám mây

Khái niệm điện toán đám mây (Cloud Computing)

Định nghĩa

Thuật ngữ “cloud” được sử dụng như một phép ẩn dụ cho mạng Internet, dựa trên cách vẽ đám

mây thể hiện cho một mạng lưới nào đó. Còn thuật ngữ “computing” là các hoạt động hướng mục tiêu từ việc sử dụng công nghệ thông tin, bao gồm các hệ thống phần cứng và phần mềm được sử dụng cho một phạm vi mục đích rộng như: xử lý, cấu trúc, và quản lý nhiều dạng thông tin khác nhau.

Theo Viện Tiêu Chuẩn và Công Nghệ Mỹ (NIST), “điện toán đám mây” là một mô hình cho phép truy cập mạng theo nhu cầu, thuận tiện, sẵn có tới một luồng dùng chung các tài nguyên máy tính có thể cấu hình được (như mạng lưới, máy chủ, kho lưu trữ, ứng dụng, dịch vụ) mà có thể nhanh chóng cung cấp và giải phóng với nỗ lực quản lý hay tương tác nhà cung cấp dịch vụ tối thiểu.

Theo Wikipedia, “điện toán đám mây” là điện toán dựa trên mạng Internet, theo đó các tài nguyên, phần mềm và thông tin chia sẻ được cung cấp cho các máy tính và các thiết bị khác theo yêu cầu, giống như mạng lưới điện.

So sánh với mô hình truyền thống

Trong các trung tâm dữ liệu truyền thống, người quản trị hệ thống tiếp nhận yêu cầu cho tài

nguyên máy tính từ các kỹ sư phần mềm. Người quản trị thường xem xét yêu cầu hàng tuần để xác định xem những tài nguyên nào sẵn có và dự án nào cần ưu tiên cao nhất. Những dự án có độ ưu tiên cao thường được giải quyết sớm. Trong nhiều trường hợp, các trung tâm dữ liệu truyền thống có thể thực thi đầy đủ các yêu cầu trong một vài tuần từ thời điểm quyết định phân bổ tài nguyên được phê duyệt. Nếu tài nguyên máy tính cần được mua thì quy trình có thể mất cả tháng. Đối với các dự án có mức độ ưu tiên thấp thì thời gian chờ đợi giải quyết còn lâu hơn, phụ thuộc vào kinh phí và tính sẵn sàng của tài nguyên. Thậm chí trong một vài trường hợp, những dự án loại này có thể bị huỷ.

152

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Đối với điện toán đám mây, người phát triển có thể truy cập vào Website nơi họ có thể gửi yêu cầu về tài nguyên máy tính – máy chủ, phần mềm, kho lưu trữ, vân vân. Người dùng ngay lập tức biết được là tài nguyên có sẵn hay không. Nếu sẵn có thì yêu cầu có thể được chấp nhận ngay bởi người quản trị. Vì quy trình là tự động nên yêu cầu có thể được giải quyết trong một vài giờ. Nếu dự án kết thúc thì người dùng sẽ không còn sử dụng tài nguyên máy tính, và chúng sẽ được phân bổ cho những dự án khác.

Như vậy khác với mô hình truyền thống, điện toán đám mây là mô hình cung cấp và tiêu dùng mới lấy cảm hứng từ các dịch vụ internet của người dùng. Nhìn chung hầu hết các công ty tham gia vào điện toán đám mây đã thoả thuận về một số đặc điểm chung nhất định, hoặc các yếu cần thiết tiêu chuẩn hoá việc tính toán dựa trên mạng internet để được xem như là một đám mây. Các yếu tố làm điện toán đám mây khác với các mô hình truyền thống:

1. Tự dịch vụ theo nhu cầu (On-demand self-service) Một người dùng có thể đơn phương cung cấp các khả năng tính toán như thời gian sử dụng máy

chủ và kho lưu trữ mạng, khi cần mà không cần yêu cầu tác động nhiều từ nhà cung cấp dịch vụ.

2. Truy cập mạng khắp nơi (Ubiquitous network access)

Khả năng này là sẵn có qua mạng và được truy cập qua các cơ chế tiêu chuẩn thúc đẩy việc sử dụng bởi các nền tảng hoặc dày hoặc mỏng không đồng nhất khác nhau (ví dụ, điện thoại di động, laptop, và PDA).

3. Tổng hợp tài nguyên độc lập vị trí (Location independent resource pooling)

Tài nguyên máy tính của nhà cung cấp được tổng hợp để phục vụ người dùng sử dụng mô hình đa người dùng (multi-tenant), với các tài nguyên ảo và vật lý khác nhau được bàn giao và thu hồi tự động theo nhu cầu của người sử dụng.

4. Khả năng đàn hồi nhanh (Rapid elasticity)

Khả năng này có thể được cung ứng nhanh để mở rộng và giải phóng nhanh để thu hẹp. Với người tiêu dùng, các khả năng sẵn có cho thuê thường xuất hiện vô hạn và có thể được thanh toán tại bất kỳ thời điểm nào.

5. Chi trả theo việc sử dụng (Pay per use)

Khả năng này được thanh toán bằng cách sử dụng mô hình lập hoá đơn theo quảng cáo, phí dịch

vụ, hay việc đo đạc để thúc đẩy việc tối ưu hoá việc sử dụng tài nguyên. Ví dụ, đo đạc kho lưu trữ, băng thông, và tài nguyên máy tính đã sử dụng và thanh toán cho những tài khoản người dùng đã kích hoạt theo từng tháng.

Sự ảo hoá và ảnh hưởng của nó đối với điện toán đám mây

Điện toán đám mây đã nhảy một bước tiến vượt bậc về công nghệ vì sự phổ biến và sự kế thừa thành quả của sự ảo hoá, cụ thể là sự ảo hoá máy chủ. Vậy ảo hoá là gì? Phần mềm ảo hoá được sử dụng để thực thi nhiều Máy Ảo (Virtual Machines) trên một máy chủ vật lý đơn lẻ để cung cấp các

153

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

chức năng giống nhau như nhiều máy chủ vật lý. Phần mềm này được gọi là Hypervisor, phần mềm ảo hoá thực thi sự trừu tượng của phần cứng đối với các máy ảo riêng biệt.

Sự ảo hoá thì không mới vì nó đã được phát minh và phổ biến bởi IBM trong những năm 1960 cho việc chạy nhiều phần mềm trên những máy tính lớn (mainframe) của họ. Nó trở nên phổ biến trong thập niên vừa qua tại những trung tâm dữ liệu vì những mối quan tâm về cách thức sử dụng máy chủ sao cho hiệu quả. Các trung tâm dữ liệu và hệ thống web gồm nhiều máy chủ vật lý. Theo Wikipedia, việc đo lường nghiên cứu trên các hệ thống máy chủ này cho thấy việc sử dụng tài nguyên máy chủ riêng biệt thường rất thấp, khoảng 10%-20% vì các nguyên nhân khác nhau, gồm tải lưu lượng và tính tự nhiên của ứng dụng. Như vậy dẫn đến lãng phí 80%-90% tài nguyên. Chuỗi các máy chủ liên tiếp này với việc sử dụng thấp đã là sự lãng phí tài chính lớn cho cả chi phí đầu tư (Capex) và chi phí vận hành (Opex) – Thêm máy, điện năng tiêu thụ nhiều hơn, các hệ thống làm mát nhiều và mặt bằng rộng hơn. Đấy là chưa kể đến việc khi các tài nguyên máy tính này không còn được dùng nữa, vì một số lý do như số lượng người dùng hệ thống suy giảm, kinh tế khó khăn, thì sự lãng phí còn lớn hơn.

Một Hypervisor được cài đặt trên một máy chủ hoặc chạy trực tiếp trên phần cứng, hoặc chạy

trên một hệ điều hành. Hypervisor hỗ trợ chạy nhiều máy ảo và lập lịch trình các máy ảo cùng với việc cung cấp cho chúng khả năng truy cập thống nhất và nhất quán tới CPU, bộ nhớ (memory), và thiết bị Vào/Ra (I/O) trên máy chủ vật lý. Một máy ảo thường chạy một hệ điều hành và các ứng dụng, ứng dụng thì không cần biết là nó đang chạy trên môi trường ảo hay thật.

Hình Error! No text of specified style in document..58: Ảo hóa

Di cư máy ảo

Nhờ có sự ảo hoá mà việc chuyển đổi máy ảo từ môi trường máy chủ này sang môi trường máy chủ khác (di cư) cũng thuận lợi hơn. Đây là một thuận lợi lớn cho cho thời gian hoạt động liên tục của ứng dụng tại trung tâm dữ liệu. Vậy chuyển đổi máy ảo là gì? Hãy xem xét trường hợp một máy chủ với một Hypervisor và một vài máy ảo, mỗi máy chạy một hệ điều hành và vài ứng dụng. Nếu bạn cần tắt máy chủ để bảo trì (ví dụ, thêm ổ cứng lưu trữ, thêm bộ nhớ), bạn cũng phải tắt các thành phần phần mềm và khởi động lại chúng sau khi bảo trì – như vậy sẽ ảnh hưởng đáng kể đến tính sẵn sàng của ứng dụng. Di cư máy ảo cho phép bạn chuyển toàn bộ máy ảo từ máy chủ này sang máy chủ khác

154

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

và tiếp tục hoạt động của máy ảo trên máy chủ thứ hai. Thuận lợi này là duy nhất với môi trường ảo vì bạn có thể tắt máy chủ vật lý cho việc bảo trì mà không ảnh hưởng nhiều đối với việc thực thi ứng dụng.

Những lợi ích của điện toán đám mây

Trên thực tế, việc sử dụng Điện toán đám mây sẽ mang lại những lợi ích sau:

8. 9. 10. 11.

12. 13. 14.

Khả năng sử dụng các dịch vụ CNTT (hạ tầng, nền tảng, phần mềm, dịch vụ thương mại) tự động, tức thời theo nhu cầu. Khả năng chuyển/trừu tượng sự phức tạp dịch vụ ngoài mặt bằng để cung cấp khả năng sẵn có, khả năng phục hồi, và việc vá lỗ hổng an ninh hiệu quả hơn. Khả năng nhanh chóng điều chỉnh yêu cầu thương mại và tác nhân thị trường theo nhu cầu. Cải tiến quản lý rủi ro qua việc cải tiến khả năng phục hồi kinh doanh. Mô hình tính giá hiệu quả hơn, loại bỏ chi phí dư thừa. Dịch vụ linh hoạt cho người dùng, cho phép tự dịch vụ nhanh chóng theo những thoả thuận dịch vụ (SLA). Cải thiện thời gian cho thị trường và tăng tốc các dự án. Chi phí thấp hơn, cả vốn và chi phí hoạt động. Giải phóng nhân lực có kỹ năng để tập trung vào công việc mức cao hơn và các dự án đổi mới. Nâng cao hiệu quả năng lượng và giảm thời gian nhàn rỗi. 15. Mô hình cung cấp và triển khai điện toán đám mây

Với các công ty, yếu tố hấp dẫn nhất của điện toán đám mây là các tuỳ chọn nguồn lực và các lựa chọn triển khai linh hoạt. Các mô hình triển khai và cung cấp có thể cùng tồn tại và có thể tích hợp với hệ thống CNTT truyền thống và với các đám mây khác.

Mô hình cung cấp đám mây

Đám mây tư nhân 1.

Là hệ thống CNTT được sở hữu và quản lý trong mạng nội bộ của một doanh nghiệp phía sau tường lửa. Truy cập vào đám mây tư nhân được giới hạn đối với người dùng. Đám mây tư nhân điều khiển sự hiệu quả, sự chuẩn hoá và các thực hành tốt nhất trong khi vẫn duy trì sự tuỳ biến và kiểm soát cùng với tổ chức. Trong môi trường đám mây tư nhân, tất cả tài nguyên, nguồn lực là thuộc nội bộ doanh nghiệp. Việc quản lý đám mây cũng thuộc nội bộ doanh nghiệp.

2. Đám mây công cộng

Là hệ thống CNTT được cung cấp trên mạng Internet, được sở hữu và quản lý bởi nhà cung cấp dịch vụ. Người dùng cần đăng ký để được cấp quyền truy cập vào đám mây công cộng. Đám mây công cộng cung cấp một tập hợp các quy trình thương mại, ứng dụng, dịch vụ hạ tầng được chuẩn hoá theo mức giá linh hoạt dựa trên việc sử dụng.

Mô hình đa người thuê là đặc điểm chính của dịch vụ đám mây công cộng.

3. Đám mây lai

Là sự kết hợp những đặc điểm của cả đám mây công cộng và đám mây tư nhân, mà ở đó các phương thức cung cấp dịch vụ trong và ngoài được kết hợp. Ví dụ trong trường hợp đám mây tư

155

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

nhân ngoài mặt bằng doanh nghiệp, tài nguyên thì được dành riêng, nhưng nó lại không phải là tài sản của doanh nghiệp đó. Doanh nghiệp quản lý danh mục dịch vụ và các quy tắc, còn nhà cung cấp dịch vụ đám mây vận hành và quản lý hạ tầng đám mây và luồng tài nguyên.

Mô hình triển khai điện toán đám mây

Các lớp khác nhau của hệ thống CNTT như một dịch vụ được thông qua mô hình triển khai điện

toán đám mây. Có 4 mô hình CNTT như một dịch vụ chính:

4. Hạ tầng như một dịch vụ (IaaS)

Là mô hình cung cấp dịch vụ mà khách hàng sử dụng việc xử lý, kho lưu trữ, mạng lưới, và các tài nguyên máy tính khác. IaaS có khả năng cung cấp nhanh và đàn hồi, cùng với việc kiểm soát tài nguyên. Trong mô hình này khách hàng có thể triển khai, thực thi phần mềm và các dịch vụ mà không cần quản lý hay điều khiển các tài nguyên cơ sở (máy chủ, mạng, kho lưu trữ). Dịch vụ IBM Research Compute Cloud (RC2), Amazon EC2 là những ví dụ điển hình về loại hình dịch vụ này.

5. Nền tảng như một dịch vụ (PaaS)

Là mô hình cung cấp dịch vụ mà khách hàng có thể sử dụng ngôn ngữ lập trình, công cụ, nền tảng để phát triển và triển khai ứng dụng trên nền tảng dùng chung với khả năng kiểm soát môi trường và ứng dụng đã triển khai. IBM Workload Deployer, Google App Engine, Windows Azure, Force.com từ Salesforce là những ví dụ về PaaS

6. Phần mềm như một dịch vụ (SaaS)

Là mô hình phổ biến mà khách hàng sử dụng các ứng dụng chuyên môn từ các thiết bị khác khác nhau qua một trình duyệt Web trên nền tảng dùng chung mà không cần quản lý hay kiểm soát tài nguyên cơ sở. Ví dụ, Gmail, Google Docs, IBM LotusLive.

7. Quy trình nghiệp vụ như một dịch vụ (BPaaS)

Là một mô hình mới nổi mà khách hàng có thể sử dụng các kết quả kinh doanh bằng cách truy cập các dịch vụ nghiệp vụ qua giao hiện trung tâm Web trên nền tảng dùng chung. Ví dụ nghiệp vụ quản lý phúc lợi nhân viên, dịch vụ du lịch, dịch vụ đấu thầu, vân vân.

156

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

Hình Error! No text of specified style in document..59: Mô hình triển khai Điện toán đám mây

Các mối quan tâm chính trong môi trường điện toán đám mây

Công nghệ điện toán đám mây vẫn đang phát triển, do đó các công ty, các viện tiêu chuẩn vẫn

đang cố gắng giải quyết những mối quan tâm nổi cộm sau nhằm phát triển ngày một tốt hơn môi trường điện toán đám mây:

8. An ninh

Vẫn là một mối quan tâm chính cho các nhà quản lý CNTT khi họ xem xét việc sử dụng các dịch vụ của nhà cung cấp dịch vụ. An ninh vật lý bằng sự cô lập (ví dụ dùng tường lửa) là yêu cầu chủ yếu cho đám mây tư nhân, nhưng không phải tất cả người dùng đám mây cần mức đầu tư an ninh này. Với những người dùng đó, nhà cung cấp đám mây phải đảm bảo sự cô lập dữ liệu và an toàn ứng dụng qua các dịch vụ dùng chung. Ngoài ra, xác thực, chứng thực người dùng và mã hoá dữ liệu trên đường truyền từ người dùng tới ứng dụng của nhà cung cấp dịch vụ là những yếu tố cần được xem xét.

9. Mạng lưới

Phần cứng mạng phải hỗ trợ nhiều loại mạng khác nhau trong môi trường đám mây để mạng lưới của nhà cung cấp dịch vụ tương thích với mạng lưới của người dùng, hay doanh nghiệp.

10. Liên minh đám mây với đám mây

Với một doanh nghiệp có thể sử dụng nhiều nhà cung cấp dịch vụ khác nhau, do đó việc tương thích giữa các nhà cung cấp dịch vụ cũng là mối quan tâm lớn, vì trong trường hợp doanh nghiệp muốn chuyển đổi hệ thống từ nhà cung cấp dịch vụ này sang nhà cung cấp dịch vụ khác thì việc tương thích về ứng dụng, mạng lưới, an ninh, cũng phải được đảm bảo.

11. Quy định pháp lý về dữ liệu

Đối với những doanh nghiệp thuê dịch vụ đám mây thì dữ liệu của họ nằm ngoài sự quản lý của doanh nghiệp đó. Mà dữ liệu là yếu tố sống còn của một doanh nghiệp, vì vậy mối quan tâm về các quy tắc, luật sở hữu trí tuệ, an toàn dữ liệu trên môi trường đám mây cũng rất được quan

157

Chương 7. Xu hướng phát triển ứ ng dụng và di ̣ch vụ trên nền Internet

tâm. Trong phạm vi rộng hơn liên quan đến luật pháp của từng nước, thì dữ liệu được lưu trữ trên các đám mây công cộng cũng cần được xem xét.

158

Tài liệu tham khảo

TÀI LIỆU THAM KHẢO

[1]

James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach Featuring the Internet. Addison Westley, 2010.

[2]

Sareh Aghaei, Mohammad Ali Nematbakhsh and Hadi Khosravi Farsani, “Evolution of The World Wide Web: From Web 1.0 to Web 4.0”, International Journal of Web & Semantic Technology (IJWesT), Vol.3, No.1, January 2012.

[3] Larry L. Peterson and Bruce S. Davie. Computer Networks: A Systems Approach. 3ed, Morgan

Kaufmann Publishers, USA, 2003.

[4] Neill Wilkinson. Next Generation Network Services: Technologies and Strategies. Quortex

Consultants Ltd., UK. 2002, John Wiley& Sons, Ltd.

[5] T. Aattalainen. Introduction to Telecommunications Network Engineering. Artech House, 1999.

159