Tải bản đầy đủ (.docx) (33 trang)

Các nguyên lý và giải pháp thiết kế hệ phân tán với mô thức web

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.71 MB, 33 trang )

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN
*****************

TIỂU LUẬN MÔN HỌC
HỆ PHÂN TÁN

Đề tài: Các nguyên lý và giải pháp thiết kế
Hệ phân tán với mô thức Web

Giáo viên hướng dẫn: GS. TS. Nguyễn Thúc Hải
Lớp: Truyền thông và mạng máy tính

Hà Nội – 10/2010

1


LỜI NÓI ĐẦU

Hiện nay, trên thế giới nói chung và Việt Nam nói riêng, mạng World Wide Web (hay thường được
gọi là Internet) đang phát triển với tốc độ chóng mặt, đóng một vai trò rất quan trọng trong đời sống,
là nơi chia sẻ thông tin, cung cấp dịch vụ, giao dịch, thương mại điện tử và là một kho lưu trữ thông
tin khổng lồ. Trong quá trình đó, hệ phân tán cũng phát triển hết sức nhanh chóng cùng bắt nhịp với
mạng Internet, một số ví dụ điển hình như mô hình các dịch vụ Web, các ứng dụng Web, các mạng
sensor, v..v...
Trong quá trình nghiên cứu về lý thuyết hệ phân tán, em nhận thấy vai trò quan trọng của việc tìm
hiểu các hệ phân tán trên nền web. Từ đó, em có thể áp dụng những lý thuyết này vào các ứng dụng
thực tế. Trong tiểu luận này, em không chỉ nghiên cứu lý thuyết chung về hệ phân tán trên nền web
được trình bày trong cuốn “Distributed Systems - Principle and Paradigm” của giáo sư Tanenbaum,
mà còn áp dụng vào một trong những hướng đề tài tốt nghiệp nhằm có một cái nhìn hệ thống hơn về


lý thuyết đó. Việc này được thể hiện trong phần trình bày về Web Service Broker.
Tuy vẫn còn đang dừng lại chưa thực hiện triển khai được toàn bộ hệ quản trị này, em mong rằng
tiểu luận sẽ giúp em có cái nhìn đúng đắn cho hướng đi sắp tới. Em xin gửi lời cám ơn chân thành
tới GS. TS. Nguyễn Thúc Hải đã truyền đạt cho chúng em kiến thức cơ bản cần có để thực hiện tiểu
luận này.

2


1

TÌM HIỂU VỀ HỆ PHÂN TÁN DỰA TRÊN NỀN TẢNG WEB

1.1 Kiến trúc chung
1.1.1 Mô hình truyền thống
Lúc khởi đầu hệ phân tán với mô thức web không khác nhiều so với những hệ phân tán khác. Tuy
nhiên trong quá trình phát triển, tài liệu được chia sẻ trên web từ tài liệu tĩnh, bị động chuyển thành
những tài liệu động, có tính tương tác cao. Thêm nữa, hệ thống web hiện nay đã không còn chỉ phục
vụ việc chia sẻ tài liệu, thông tin, hệ thống web còn phát triển theo hướng cung cấp những dịch vụ
khác.

1.1.1.1 Mô hình chung
Hệ phân tán dựa trên mô thức web được tổ chức theo mô hình client-server. Trong đó có các thành
phần là:

• Client với phần mềm trình duyệt (Browser)
• Web Server
• Cơ sở dữ liệu chứa tài liệu được yêu cầu, thường nằm cùng Web Server
Dưới đây là mô hình tổ chức của hệ truyền thống.


Hình 1.1: Mô hình tổ chức của hệ phân tán trên nền web truyền thống
(Figure 12-1 Distributed Systems: Principles and Paradigms)
Ở đây ta trình bày một số khái niệm cần thiết:

• Một tài liệu được xác định thông qua các thông tin về nơi nó được lưu trữ bao gồm định
danh của server, tên tài liệu, vị trí của nó trong hệ thống file.

3


• Thông tin về tài liệu được thể hiện dưới dạng URL. URL không chỉ chứa thông tin vị trí tài



liệu mà còn chứa thông tin về giao thức tầng ứng dụng sử dụng để truyền tài liệu trên mạng.
Phần mềm trình duyệt là phần mềm Client sử dụng để tương tác với Web Server.
Tương tác giữa Client và Web Server dựa vào một giao thức chuẩn là HTTP (HyperText
Transfer Protocol).

Cơ chế hoạt động của hệ thống như sau:

• Client thực hiện yêu cầu một tài liệu nào đó trong cơ sở dữ liệu thông qua trình duyệt (mà cụ




thể hơn là thông qua URL), nó gửi một bản tin HTTP yêu cầu tới Web Server.
Ở phía Server tồn tại một tiến trình có khả năng truy cập vào cơ sở dữ liệu
Tiến trình này thực hiện truy cập và lấy tài liệu từ cơ sở dữ liệu.
Server sau khi xử lý sẽ trả lại Client thông tin, có thể đó là thông tin báo lỗi không tìm được

tài liệu, cũng có thể là nội dung tài liệu, v..v..

1.1.1.2 Một số ngôn ngữ web
Tài liệu - thông tin được chia sẻ trên mạng có thể được phân chia tương đối làm hai phần:

• Một phần có thể sử dụng như một template cho phần còn lại, mô tả những đặc điểm như vị


trí, cách bố trí, nền, font, v..v... cho phần dữ liệu còn lại. Các ngôn ngữ dữ liệu web được sử
dụng cho phần này.
Phần còn lại là thông tin thực tế được lưu trữ mà người dùng yêu cầu.

Trong một ví dụ đơn giản, tải liệu được lấy về có dạng sau:

<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<body>

Hello, World!


</body>
</html>
Với dữ liệu này, phần thông tin thực tế người dùng cần có là dòng chữ “Hello, World!” phần còn lại
đóng vai trò giúp trình duyệt thể hiện thông tin đó cho người dùng.
Một số ngôn ngữ web thường được sử dụng như: HTML, XML. Các ngôn ngữ này không chỉ cung
cấp thông tin về việc thể hiện dữ liệu cho người dùng, mà còn cung cấp thông tin về các dữ liệu
khác giúp biết được loại file, loại định dạng, v..v... của thành phần tạo nên dữ liệu. Các ngôn ngữ
này có khả năng đó thông qua việc sử dụng cơ chế MIME để phân biệt nội dung dữ liệu. Bảng dưới
đây cho ta thấy các kiểu và kiểu con được định nghĩa bởi MIME.

4



Bảng 1.1: Các kiểu dữ liệu và kiểu dữ liệu con được định nghĩa với MIME
(Figure 12-2 Distributed Systems: Principles and Paradigms)

1.1.1.3 Mô hình truyền thống với kiến trúc đa tầng
Ngôn ngữ Web như HTML, XML cùng phối hợp với các ngôn ngữ script thực sự đã cho chúng ta
thấy được một phương tiện mạng mẽ để thể hiện dữ liệu Web. Tuy nhiên, chúng ta chưa đi sâu vào
cơ chế hoạt động của nó hiện tại. Cho tới hiện tại, Web không còn dừng lại ở kiến trúc hai tầng đơn
giản client-server, mà qua thời gian nó đã được phát triển với kiến trúc đa tầng, với nhiều thành phần
nhằm hỗ trợ tốt hơn những kiểu dữ liệu khác nhau mà ở phần trước chúng ta đã đề cập qua bảng 1.1
phần trên.
Một trong những cải tiến so với kiến trúc cơ bản là việc sử dụng các CGI (Common Gateway
Interface) nhằm cung cấp sự tương tác cho người dùng. Thông qua các Interface này, Web server có
thể chạy những chương trình với dữ liệu đầu vào được người dùng cung cấp.
Cơ chế của quá trình này được thể hiện ở hình 1.2 dưới đây.

Hình 1.2: Chương trình CGI tại phía Server

5


(Figure 12-3 Distributed Systems: Principles and Paradigms)
Qua hình 1.2 ta có thể thấy cơ chế hoạt động sử dụng CGI như sau:

• Người dùng nhập vào một form chứa các tham số cần thiết. Thông tin về chương trình cũng




như thông số của nó được Client gửi tới Server.

Khi Server nhận được bản tin yêu cầu từ phía Client, nó chạy chương trình được đề cập
trong bản tin cùng với các thông số đi kèm.
Sau đó, chương trình tương tác với cở sở dữ liệu, xử lý và tạo ra văn bản HTML. Văn bản
này được trả lại cho Server.
Server thực hiện trả lại văn bản cho phía Client.

Qua đó, ta có thể thấy được Server hoàn toàn ủy quyền việc xử lý yêu cầu cho phía chương trình
CGI. Đây chính là một kiến trúc 2 tầng tại phía Server.
Ngày nay, Server không chỉ dừng lại ở kiến trúc 2 tầng. Một ví dụ cho kiến trúc này có thể lấy từ
việc một người dùng vào một trang Web bán hàng:

• Các ứng dụng Java Servlet quản lý thông tin về những mòn hàng người dùng mua, thực hiện





các gợi ý, lưu trữ các món hàng ưa thích, v..v..
Khi người dùng thực hiện việc tìm kiếm theo một từ khóa nào đó, phía Web Server sẽ phải
chuyển yêu cầu tới chương trình.
Chương trình thực hiện gửi truy vấn tới cơ sở dữ liệu. Phía cơ sở dữ liệu trả lại kết quả truy
vấn.
Chương trình thực hiện tạo ra một trang web danh sách các tìm kiếm và trả lại Web Server.
Web Server trả lại thông tin cho người dùng.

Như trên có thể thấy, một kiến trúc 3 tầng đã hình thành, trong đó bao gồm Web Server, Application
Server (Server chạy ứng dụng), và Cơ sở dữ liệu.
Kiến trúc 3 tầng hình thành đã đặt ra một vấn đề: giảm hiệu năng của hệ thống. Việc phân chia rõ
ràng 3 tầng là điều cần thiết, các Server ứng dụng và Cơ sở dữ liệu phải chịu tải rất lớn. Vấn đề này
sẽ được bàn đến tại phần 1.6 trong tiểu luận này.


1.1.2 Mô hình dịch vụ web
Hệ phân tán với mô thức web đã phát triển tới mức cung cấp dịch vụ cho các ứng dụng từ xa. Các
phần mềm như trình duyệt tại phía Client đã không còn chỉ là một giao diện hiển thị nội dung cho
người sử dụng.

1.1.2.1 Mô hình chung
Dịch vụ Web cũng giống như các dịch vụ thông thường như dịch vụ định danh, cung cấp địa chỉ,
mail, v..v.... Chúng được cung cấp qua Internet và tuân theo một số chuẩn nhất định. Hình dưới đây
cho ta thấy mô hình cơ chế hoạt động của dịch vụ Web.

6


Hình 1.3: Mô hình dịch vụ Web
(Figure 12-4 Distributed Systems: Principles and Paradigms)
Cơ chế chung của mô hình là việc ứng dụng ở phía Client có thể gọi các dịch vụ từ ứng dụng phía
Server. Quá trình này được thực hiện dựa trên sự chuẩn hóa. Về mặt nào đó, cơ chế này cũng gần
giống với cơ chế gọi thủ tục từ xa (RPC)
Ở đây ta trình bày một số khái niệm cần thiết để hiểu rõ hình 1.3:

• UDDI là một directory chứa các mô tả dịch vụ cần thiết. Nó là một cơ sở dữ liệu giúp cho



các Client có thể truy cập tìm kiếm các dịch vụ phù hợp.
Các dịch vụ nằm trong UDDI được mô tả thông qua ngôn ngữ WSDL. Ngôn ngữ này cũng
tương tự như ngôn ngữ IDL trong RPC. Ngôn ngữ WSDL mô tả các thủ tục, các kiểu dữ liệu,
nơi chứa dịch vụ, v..v...
Client và Server trao đổi thông qua giao thức SOAP, đây là giao thức chuẩn cho các tiến

trình liên lạc với nhau. Giao thức này sẽ được đề cập đến chi tiết hơn tại phần sau của tiểu
luận.

Tựu chung lại, ta có cơ chế làm việc của mô hình dịch vụ Web như sau:

• Các dịch vụ của máy chủ được công bố ra phía UDDI. Cơ sở dữ liệu này lưu lại mô tả dịch





vụ dưới ngôn ngữ WSDL.
Khi Client cần đến dịch vụ, nó tìm kiếm dịch vụ tại UDDI. UDDI trả về kết quả cho Client.
Client biết được dịch vụ qua các mô tả trả về qua ngôn ngữ WSDL.
Client thực hiện kết nối đến máy chủ qua giao thức SOAP và gọi dịch vụ.
Từ đây, quá trình trao đổi diễn ra bình thường thông qua giao thức SOAP.

7


1.1.2.2 Thành phần và sự điều phối trong dịch vụ Web
Như trên đã trình bày, mô hình dịch vụ Web có thể được hình dung tương đối đơn giản là việc một
dịch vụ được triển khai dưới dạng ứng dụng và được triệu gọi thông qua một chuẩn nào đó.
Tuy nhiên, chính ứng dụng đôi khi lại rất phức tạp và nó có thể là một ứng dụng phân tán trong hệ
thống mạng. Ở trường hợp này, người ta sử dụng một proxy nội mạng nhằm tương tác với những
thành phần của ứng dụng phân tán này. Proxy này cũng đảm bảo cho phía Client trong suốt với sự
phân tán của ứng dụng.
Trong mô hình, chúng ta cũng có thể thấy ứng dụng được cung cấp chỉ thông qua một bước triệu gọi
(Look up a Service - Hình 1.3). Tuy nhiên, trong thực tế mô hình triệu gọi phức tạp hơn nhiều. Đơn
cử như khi người dùng thực hiện mua một cuốn sách từ trang Web thương mại điện tử. Một việc

tưởng chừng đơn giản đó bao gồm việc chọn lựa, việc thanh toán, việc lấy thông tin giao hàng. Dịch
vụ ở đây chính là một giao dịch chia làm nhiều bước có thứ tự. Hay nói cách khác, dịch vụ được
cung cấp ở đây bao gồm những dịch vụ con khác nhau.
Sự phức tạp càng tăng lên khi người ta phải kết hợp trên một trang Web các dịch vụ của những nhà
cung cấp dịch vụ khác nhau. Vẫn lấy mô hình trang Web thương mại làm ví dụ, một trang Web này
có thể bao gồm các dịch vụ khác nhau như sau:

• Lựa chọn mặt hàng từ nhà cung cấp mặt hàng
• Tiến hành thanh toán thông qua hệ thống banking của ngân hàng
• Nhập thông tin giao hàng do công ty chuyển phát nhanh cung cấp
Như vậy, mặc dù ở phía người dùng đây là các dịch vụ được cung cấp trên cùng một trang Web,
nhưng thực tế ở phía cung cấp dịch vụ lại là sự kết hợp của nhiều nhà cung cấp dịch vụ khác nhau.
Như vậy, 3 vấn đề trên (Ứng dụng phân tán; Sự phức tạp của giao dịch; Sự tham gia của nhiều nhà
cung cấp dịch vụ) đặt ra nhu cầu phải điều phối các dịch vụ này, sao cho chúng có thể được kết hợp
với nhau, và phải tạo được sự trong suốt của hệ thống với người dùng.
Việc điều phối như trên đặt ra được thực hiện bởi các giao thức điều phối. Những giao thức này sẽ
đưa ra các luật về những bước cần thực hiện đối với các dịch vụ, đồng thời buộc các dịch vụ của các
phía phải tuân thủ theo. Để đạt được điều đó, người ta định nghĩa một dịch vụ riêng dùng để cung
cấp các giao thức điều phối. Các tiến trình sẽ thực hiện đăng ký với giao thức điều phối khi tham
gia.

8


1.2 Các tiến trình trong hệ phân tán trên nền web
Tại phần này, chúng ta nghiên cứu về các tiến trình của hệ phân tán theo mô thức Web

1.2.1 Tiến trình tại phía Client
Ở đây ta xét đến hai tiến trình thường gặp ở môi trường Web phía Client, đó là tiến trình trình duyệt
Web và Web proxy.


1.2.1.1 Tiến trình trình duyệt Web
Trình duyệt Web tại phía Client giúp người dùng có thể xem nội dung trang Web, cũng như cung cấp
cho người dùng những liên kết mà người dùng có thể dễ dàng chọn.

Hình 1.4: Các thành phần logic của một trình duyệt Web
(Figure 12-5 Distributed Systems: Principles and Paradigms)
Như hình 1.4, chúng ta có thể thấy được những thành phần logic của một trình duyệt Web bao gồm
3 thành phần chính:

• Rendering Engine: Engine này chịu trách nhiệm hiển thị các văn bản HTML hay XML lên




màn hình. Nó chứa các thành phần có khả năng:
 Tạo liên kết, giao tiếp trên mạng
 Xử lý ngôn ngữ HTML, XML
 Phiên dịch các script trong văn bản
Browser Engine: Engine là trung tâm của trình duyệt, cung cấp cho người dùng cơ chế xem
văn bản, như chia nó thành các phần, lựa chọn các phần của văn bản, vào một liên kết, v..v..
User Interface: Engine cung cấp giao diện cho người dùng. Ngoài ra, do trình duyệt không
phụ thuộc nền tảng nó chạy, User Interface cùng với Browser Engine chạy trên các thư viện
đồ họa chuẩn được thể hiện trên hình (Display back end).

9


1.2.1.2 Tiến trình Web Proxy
Một tiến trình khác có thể kể đến ở phía Client và tiến trình chạy Web proxy. Một trong các chức

năng của nó được thể hiện ở hình dưới.

Hình 1.5: Trường hợp sử dụng Web proxy khi có sự bất đồng về giao thức
(Figure 12-6 Distributed Systems: Principles and Paradigms)
Web proxy tại lúc được tạo ra có mục đích nhằm cho phép trình duyệt xử lý các giao thức ở mức
ứng dụng khác với HTTP. Tuy nhiên cho tới thời điểm hiện tại, trình duyệt đã có khả năng xử lý
nhiều giao thức khác nhau và không còn cần tới chức năng này nữa. Web proxy sau này được sử
dụng cho rất nhiều mục đích khác như caching, nén, ghi log, v..v... Những tính năng này sẽ được đề
cập đến tại phần 1.6 - Cơ chế nhất quán và nhân bản.

1.2.2 Tiến trình tại máy chủ Web
Chúng ta nghiên cứu tiến trình tại phía máy chủ thông qua một trong những Web server thông dụng
tính tới thời điểm hiện tại (Chiếm 70% lượng sử dụng trên thế giới), đó là Apache.
Hai ưu điểm nổi bật của Apache có thể kể đến là:

• Chạy độc lập với nền tảng của Server: Apache thực hiện điều này bằng cách sử dụng một



nền tảng chạy của mình được tạo ra nhằm chạy trên những hệ điều hành khác nhau. Môi
trường này được gọi là APR (Apache Portable Runtime). Đây là một bộ thư viện cung cấp
các giao diện cho việc xử lý file, kết nối mạng, xử lý luồng, v..v... Khi chạy, thay vì những
lời gọi tới các thư viện của nền tảng Apache cài trên, tiến trình gọi tới các thư viện APR.
Dễ mở rộng tính năng: Apache có khả năng mở rộng thêm nhiều tính năng thông qua các
thư viện của mình, mà vẫn đảm bảo cho những phần mở rộng được phát triển là độc lập. Đơn
cử như mô hình nhân bản thích nghi (Adaptive Replicate) trong Globule, một mạng phân
phối dữ liệu tại trường đại học Vrije Amsterdam. Globule được mở rộng lên từ Apache
nhưng vẫn giữ được tính độc lập của nó so với những phần mở rộng khác được phát triển.

10



Tổ chức cơ chế hoạt động của Apache có thể được miêu tả qua hình vẽ dưới đây:

Hình 1.6: Trường hợp sử dụng Web proxy khi có sự bất đồng về giao thức
(Figure 12-7 Distributed Systems: Principles and Paradigms)
Trong sơ đồ đặt ra ở đây, chúng ta thấy một khái niệm là hook, nó chỉ một nhóm các chức năng có
chung một nhiệm vụ nào đó. Các nhóm chức năng này cũng được cung cấp thông qua các module
riêng. Các module này cũng sẽ có sự độc lập với nhau.
Một ví dụ như có hook làm nhiệm vụ chuyển đổi từ URL thành vị trí cần thiết trong hệ thống file, có
hook làm nhiệm vụ viết log, v..v...

1.2.3 Cơ chế chạy Clustering các
máy chủ
Một vấn đề khi cung cấp dịch vụ Web là việc các Web Server có thể dễ dàng bị quá tải. Chính vì vậy
phải có cơ chế chạy nhiều máy chủ. Đó là cơ chế Clustering. Cơ chế này sẽ được đề cập ở phần 1.6,
“Cơ chế nhất quán và nhân bản”. Ở đây chúng ta chỉ xem xét về mặt tiến trình thực hiện trong hệ
thống các máy chủ.

11


Hình 1.7: Hệ thống Web Server Cluster với máy Front-End
(Figure 12-8 Distributed Systems: Principles and Paradigms)
Với cơ chế Clustering, hệ thống sẽ có một máy chủ Front End để nhận các yêu cầu, chuyển các yêu
cầu tới các máy chủ Web, nhận trả lời từ máy chủ Web, và gửi về cho phía yêu cầu. Cơ chế gửi có
thể là tuần tự, cũng có thể có cơ chế theo dõi để gửi yêu cầu đến máy chủ đang chịu tải ít hơn.
Ngoài ra, với hệ thống Web server, chúng ta có thể cấu hình hệ thống Content-Aware Cluster. Hệ
thống này cũng có một Front-End làm nhiệm vụ nhận và chuyển tiếp các yêu cầu.


Hình 1.8: Cơ chế hoạt động của mô hình Content-Aware Cluster
(Figure 12-9 Distributed Systems: Principles and Paradigms)
Ý tưởng của việc triển khai Content-Aware Cluster là việc có một phần tử là Dispatcher sẽ có thể
biết nội dung gói tin và liên tục điều khiển loại gói tin đó về một server. Làm như vậy giúp Web
server có thể phục vụ nhanh hơn thông qua cơ chế caching, nên hầu hết thời gian sẽ không phải chạy
tiến trình lấy dữ liệu từ cơ sở dữ liệu. Ngoài ra, việc lựa chọn như vậy có thể giúp hệ thống phân tải
cho các Server cho hợp lý.
Cơ chế hoạt động của mô hình như sau:

• Client gửi yêu cầu tới hệ thống
• Switch Front End chuyển tiến yêu cầu đó (bản tin TCP Request) tới một trong các Web






server hay còn gọi là Distributor.
Distributor nhận được bản tin không xử lý ngay mà tương tác với Dispatcher xem máy chủ
Web nào sẽ xử lý bản tin đó.
Dispatcher quyết định máy chủ sẽ xử lý bản tin.
Bản tin TCP được gửi tới cho máy chủ Web được chọn, đây là quá trình 3. TCP Hand off.
Web server được chọn sẽ thiết lập kết nối TCP với Client.
Switch Front-End cũng được thông báo về điều này, và sau đó tất cả các kết nối được

12


Để đạt được hiệu quả phân tải tốt người ta cũng dùng rất nhiều cách khác như chia VLAN và ứng
dụng các giao thức Gateway(GLBP, VRRP, v..v...) , hoặc sử dụng cơ chế DNS. Đã đạt được mục

tiêu xem xét các tiến trình tại phía các máy chủ Clustering, chúng ta sẽ không đi quá sâu vào những
phương pháp này.

13


1.3 Cơ chế truyền thông
Đối với hệ phân tán trên mô thức Web, các giao thức được sử dụng cũng khá thông dụng. Giao thức
truyền thống HTTP được sử dụng để trao đổi các bản tin. Còn về phía dịch vụ Web thì có các giao
thức như SOAP, CORBA. Ở đây, chúng ta nghiên cứu cơ chế truyền thông của hệ phân tán mô thức
Web với hai giao thức là HTTP và SOAP.

1.3.1 Giao thức HTTP
Các giao tiếp giữa Client và Server đều dựa trên giao thức HTTP, HTTP là một giao thức clientserver khá đơn giản. Cơ chế của nó là Client gửi bản tin yêu cầu tới Server và chờ thông tin trả về từ
phía server.

1.3.1.1 Kết nối HTTP
Giao thức HTTP được xây dựng dựa trên nền tảng TCP. Sau khi nhận được yêu cầu từ phía Client,
Server sẽ thiết lập một kết nối TCP với Client. Thông qua nền tảng TCP, giao thức HTTP không còn
phải triển khai các tính năng như chống lỗi, ACK, v..v...

Hình 1.9: Cơ chế kết nối của HTTP dựa trên TCP (hai phiên bản HTTP cũ và mới)
(Figure 12-10 Distributed Systems: Principles and Paradigms)
Với phiên bản HTTP cũ, HTTP đã không tận dụng tốt giao thức TCP khi mỗi yêu cầu từ Client phải
dựng một kết nối TCP, làm cho Server phải chịu tải nặng hơn. Với các phiên bản HTTP hiện tại, một
kết nối TCP có thể phục vụ nhiều yêu cầu từ Client. Như vậy cơ chế truyền thông này sẽ giúp tiết
kiệm thời gian dựng kết nối, số lượng kết nối TCP, từ đó giảm tải cho hệ thống.

1.3.1.2 Các phương thức HTTP
HTTP được thiết kế dưới dạng một giao thức client-server hướng tới việc chuyển tài liệu theo hai

chiều. Một Client có thể yêu cầu gửi hoặc nhận một tài liệu nào đó thông qua các bản tin yêu cầu với
các kiểu khác nhau.

14


Dưới đây là các kiểu gói tin yêu cầu của HTTP:

Hình 1.10: Các loại bản tin yêu cầu của giao thức HTTP
(Figure 12-11 Distributed Systems: Principles and Paradigms)

1.3.1.3 Định dạng gói tin HTTP
Tất cả các giao tiếp giữa Client-Server đều thông qua gói tin. Định dạng gói tin HTTP bao gồm 3
phần chính như hình dưới đây:

Hình 1.11: Các loại bản tin yêu cầu của giao thức HTTP
(Figure 12-12 Distributed Systems: Principles and Paradigms)
Ba phần chính đó bao gồm:

• Dòng yêu cầu
• Header của bản tin yêu cầu
• Nội dung cụ thể của bản tin
Trong đó, dòng yêu cầu chứa thông tin về phương thức sử dụng giữa Client và Server. Đó là các
phương thức yêu cầu chuyển tài liệu mà ta đã nhắc tới ở phần trên. Các Header của bản tin cung cấp
thông tin về phiên bản HTTP sử dụng, đồng thời nó còn chứa các thông số trạng thái tài liệu. Ví dụ
như: 405 - “Method not allowed”.

15



Hình dưới đây cho ta thấy một số các header của bản tin HTTP

Hình 1.12: Một số loại bản tin yêu cầu của giao thức HTTP
(Figure 12-13 Distributed Systems: Principles and Paradigms)

16


1.3.2 Giao thức SOAP
Trong khi HTTP là giao thức truyền thống sử dụng cho hệ phân tán trên mô thức Web, giao thức
SOAP (Simple Object Acces) được sử dụng như một chuẩn truyền thông cho các dịch vụ Web. Hầu
hết việc truyền thông với SOAP được sử dụng trên nền giao thức HTTP. Mục đích của SOAP là việc
cung cấp khả năng giao tiếp cho các nhóm cung cấp dịch vụ khác nhau, không biết về nhau.
Một gói SOAP thông thường bao gồm 2 phần, một phần là thông tin cần được chuyển đi và một
phần header chứa thông tin về các node gói tin đi qua giữa người gửi và người nhận. Các node này
là thành phần của một hệ thống dịch vụ Web nhiều tầng.
SOAP có hai kiểu tương tác. Kiểu thứ nhất, SOAP cung cấp khả năng trao đổi thông tin giữa các
nhóm cung cấp dịch vụ. Kiểu thứ hai, SOAP cung cấp khả năng triệu gọi dịch vụ giống như cơ chế
RPC.
Việc cung cấp dịch vụ Web có thể chỉ sử dụng đến SOAP, tuy nhiên ngày nay như ở phần đầu chúng
ta đã giới thiệu , SOAP sử dụng kết hợp với WSDL và UDDI để cung cấp dịch vụ Web.

Hình 1.13: Mô hình dịch vụ Web
(Figure 12-4 Distributed Systems: Principles and Paradigms)
Trong phạm vi tiểu luận chúng ta không đi quá chi tiết vào SOAP cùng WSDL và UDDI, tuy nhiên
chúng ta đã nắm được các cơ chế cơ bản của nó.

17



1.4 Cơ chế định danh
Web sử dụng một cơ chế định danh cho các tài liệu được cung cấp. Cơ chế định danh này được
thông qua URI (Uniform Resource Identifiers). URI có hai dạng:

• URL (Uniform Resource Locator): URL chịu trách nhiệm xác định một tài liệu nằm ở đâu và


truy cập nó bằng cách nào trong một hệ thống.
URN (Uniform Resource Name): URN chịu trách nhiệm như là một cơ chế định danh chung
cho toàn thế giới, không phụ thuộc vào một hệ thống riêng nào.

Sự khác nhau giữa URL và URN ngày nay trở nên hết sức nhỏ. Dưới đây chúng ta đưa ra một ví dụ
về các cấu trúc URL thường được sử dụng trong Web:

Hình 1.14: Mô hình dịch vụ Web
(Figure 12-15 Distributed Systems: Principles and Paradigms)
Như vậy ta có thể thấy URL cung cấp cho chúng ta các thông tin như: Giao thức; Tên Host; Port;
Pathname. Từ tên host sử dụng cơ chế DNS để biết được địa chỉ IP của host. Sau đó, ta có thể biết
được tài liệu nằm ở vị trí nào trên mạng (Host name), sử dụng giao thức nào để lấy tài liệu
(Scheme), giao tiếp với máy chủ thông qua port nào (Port), vào vị trí của tài liệu trong hệ thống máy
chú (Pathname).
Dưới đây là một số ví dụ về các định danh với các giao thức, các định dạng khác nhau:

Hình 1.15: Mô hình dịch vụ Web

18


(Figure 12-16 Distributed Systems: Principles and Paradigms)
Data URI là một loại URI chưa các dữ liệu được nhúng vào ngay trong nó. URI còn được sử dụng

trong một số trường hợp khác ngoài việc định danh tài liệu. Ví dụ như sử dụng cho các phiên telnet,
dựng các kết nối modem với các máy, v...v... Tuy nhiên, những cách sử dụng này không thường gặp.

19


1.5 Cơ chế đồng bộ
Vấn đề đồng bộ đối với hệ thống Web truyền thống không phải là một vấn đề đáng quan tâm vì hai
lý do sau:

• Đầu tiên, với cơ chế tổ chức client server, và giao thức sử dụng, việc đồng bộ là không cần


thiết.
Thứ hai, Web là một hệ thống mà ở đó ít khi có sự thay đổi dữ liệu của nhiều người dùng
trên cùng một thực thể, vì thế ít khi có sự xung đột.

Tuy nhiên, với hệ thống Web hiện tại, khi mà tồn tại việc cung cấp hỗ trợ cho nhiều thành phần dịch
vụ của cùng một hệ thống, người ta không thể không thực hiện đồng bộ hóa.
Quá trình đồng bộ được giải quyết thông qua một giao thức riêng, đó là WebDAV (Web Distributed
Authoring and Versioning). WebDAV cung cấp cơ chế khóa tài liệu khi có truy cập, cơ chế tạo các
phiên bản, xóa, sao, v..v....
Nhằm đồng bộ hóa, WebDAV sử dụng hai cơ chế khóa:

• Cơ chế khóa khi một Client thực hiện chỉnh sửa tài liệu, lúc này các Client khác sẽ bị khóa


chức năng chỉnh sửa (quyền write).
Cơ chế khóa cho một nhóm người sử dụng. Cơ chế này cho phép một nhóm người dùng
chỉnh sửa các phần khác nhau của tài liệu. Tuy nhiên người dùng phải tự quan tâm tới các

vấn đề về xung đột khi chỉnh sửa.

Khi Client cần chỉnh sửa tài liệu, Client phải truy cập tới Server và yêu cầu quyền lấy khóa (Key
token). Sau khi các dữ liệu được chỉnh sửa, Client gửi về Server qua bản tin HTTP Post, cùng với
chứng minh quyền sửa dữ liệu (Key token).
Ở đây có một vấn đề đặt ra là khi Client không trả lại quyền chỉnh sửa do bị sự cố. Lúc này, Server
cần có một cơ chế để lấy lại khóa. Tuy nhiên với WebDAV, cơ chế này không được định nghĩa mà
được để mở cho các mục đích triển khai khác nhau.

20


1.6 Cơ chế nhất quán và nhân bản
Một trong các vấn đề cho hệ thống phân tán với mô thức Web là việc đảm bảo hiệu năng và tính sẵn
sàng. Với một hệ thống phục vụ nhiều người dùng, cung cấp dịch vụ, thậm chí là các dịch vụ nhạy
cảm như dịch vụ ngân hàng, v..v..., hệ thống phải đảm bảo không được chậm trễ, đồng thời phải luôn
có tính chịu lỗi qua việc dự phòng.
Đối với việc đảm bảo hiệu năng hệ thống, hệ thống cung cấp qua cơ chế caching, tức là lưu lại các
thông tin được yêu cầu nhiều, nhằm trả lại Client ngay lập tức mà không cần phải thực hiện các tiến
trình lấy dữ liệu, v..v... Đồng thời, việc chạy nhiều máy chủ giống nhau (nhân bản) với cùng một
chức năng và cơ sở dữ liệu (nhất quán) giúp cho hiệu năng phục vụ người dùng của hệ thống tăng
lên.
Việc đảm bảo tính sẵn sàng của hệ thống được thực hiện bởi các các máy chủ với cơ chế nhất quán
và nhân bản. Khi có sự cố xảy ra, các máy chủ khác vẫn có khả năng thay thế, đón nhận các yêu cầu
từ Client cho thiết bị gặp sự cố. Như vậy với việc chạy nhiều máy chủ, tính sẵn sàng của hệ thống
cũng được tăng lên.

1.6.1 Cơ chế Proxy Caching
Việc Caching thông tin được thực hiện ở phía Client của một hệ thống. Tại phía Client, các trình
duyệt có cơ chế caching thông thường, có thể lưu lại một số dữ liệu đã lấy về từ trước. Ngoài ra,

phía Client cũng có thể có một Web Proxy phục vụ việc Caching.
Web Proxy này đóng vai trò trung gian giữa Web Server và Web Client. Nó nhận các yêu cầu từ phía
Client, gửi tới Server, nhận trả lời từ Web Server, gửi về Client, đồng thời lưu lại trả lời đó. Khi một
Client khác yêu cầu cùng thông tin, Web Server sẽ kiểm tra dữ liệu đã lưu và trả lại cho Client mà
không cần phải chuyển tiếp yêu cầu tới phía Web Server.

Hình 1.16: Mô hình dịch vụ Web
(Figure 12-17 Distributed Systems: Principles and Paradigms)

21


Ngoài ra, trong thực tế người ta còn thực hiện Caching dữ liệu theo vùng, và vì thế dẫn đến một cấu
trúc Caching dữ liệu từ các vùng nhỏ như công ty đến các vùng lớn như thành phố, và lên tới các
vùng địa lý khác nhau. Việc này dẫn tới, khi Proxy không chứa các dữ liệu được yêu cầu trong
Cache, trước tiên nó không chuyển tiếp yêu cầu tới Web Server ngay, mà chuyển yêu cầu tới các
Proxy xung quanh.
Có một số giao thức được sử dụng để đảm bảo tính nhất quán của hệ thống Cache. Nhằm đảm bảo
tài liệu trả về từ Cache có tính nhất quán, các Web Proxy trước khi trả dữ liệu cho người dùng thực
hiện gửi một bản tin HTTP get, hỏi Web Server liệu tài liệu có bị thay đổi so với lúc được Cache
không. Nếu có, Web Server sẽ phải gửi lại các tài liệu đã thay đổi, nếu không Web Proxy chỉ việc
gửi trả lại dữ liệu đã Cache.

1.6.2 Nhân bản hệ thống Web
Hosting
Việc phát triển nhanh chóng của hệ phân tán mô thức Web đã phát triển hết sức nhanh chóng. Việc
đảm bảo hoạt động của hệ thống không còn chỉ nằm ở duy trì nội dung Web mà còn nằm ở việc
cung cấp dịch vụ liên tục không ngừng. Điều này đã dẫn đến khái niệm mạng cung cấp nội dung
CDN (Content Delivery Networks). Mục tiêu chính của mạng là hướng tới việc cung cấp một kiến
trúc phân phối và nhân bản nội dung Web trên Internet.

Cơ chế tổ chức của mạng CDN được thể hiện ở hình dưới đây:

Hình 1.17: Cơ chế tổ chức thông qua hệ thống feed-back
(Figure 12-18 Distributed Systems: Principles and Paradigms)
Ta có thể thấy trong hình cơ chế tổ chức với một vòng lặp feed-back. Khi tổ chức mạng CDN như
vậy, có ba điểm nổi bật được thể hiện phần nào trên tổ chức như hình vẽ:

22


• Ước lượng đưa ra Metric: Metric là các độ đo về trễ, về thông lượng, về tính thống nhất, về





tính kinh tế của hệ thống. Thông qua các thông số ước lượng này mà chúng ta có thể chỉnh
sửa mạng cho phù hợp. Ví dụ như các thông tin độ trễ cho ta biết các đặc điểm về đường
truyền, về khả năng xử lý của thiết bị trên đường truyền; các thông tin về thông lượng cho ta
biết liệu đường truyền có bị thiếu băng thông, hay liệu có cần đưa ra các giải pháp tối ưu
băng thông cho đường truyền, v..v...
Lựa chọn khi nào đưa ra điều chỉnh cho hệ thống: Theo cách thông thường nhất, người ta có
thể liên tục cập nhật Metric và điều chỉnh hệ thống cách một khoảng thời gian. Cách này
thường được gặp trong thực tế. Tuy nhiên cũng có một số thay đổi đối với hệ thống lại cần
được xử lý ngay lập tức. Ví dụ như sự tăng vọt yêu cầu một tài nguyên nào đó. Việc lựa chọn
thời điểm điều chỉnh hệ thống cũng có thể dựa vào một thuật toán theo dõi, nhằm phát hiện
những thay đổi mang tính chất cần xử lý ngay, qua đó người ta có thể lựa chọn thời điểm
thay đổi hợp lý.
Điều chỉnh sao cho hợp lý: Việc điều chỉnh một hệ thống Web Hosting sao cho hợp lý bao
gồm ba hướng:

 Thay đổi vị trí đặt các bản sao
 Thay đổi các luật về tính nhất quán
 Thay đổi về cách thức và thời điểm chuyển tiếp gói tin yêu cầu từ Client

1.6.3 Nhân bản các ứng dụng Web
Trong tiểu luận cho tới thời điểm này, ta mới chỉ nói đến cơ chế sử dụng Caching và Nhân bản cho
các nội dung Web tĩnh. Tuy nhiên ngày nay các trang Web với nội dung động ngày càng nhiều và
các dịch vụ cũng được triệu gọi nhiều. Vậy, ta phải xem xét cơ chế nhân bản và nhất quán đối với hệ
thống Web động.

Hình 1.18: Caching và nhân bản với các ứng dụng Web
(Figure 12-21 Distributed Systems: Principles and Paradigms)

23


Nhìn vào sơ đồ trên ta có thể thấy được có hai cơ chế nhân bản cho các cơ sở dữ liệu giữa phía Edge
Server và phía Origin Server, đó là nhân bản toàn bộ hay nhân bản một phần.
Nếu như cường độ thay đổi dữ liệu lớn thì việc nhân bản toàn bộ có thể ảnh hưởng đến hệ thống mà
lại không có được hiệu quả cần thiết. Nếu nhân bản bộ phận thì điều khó khăn đặt ra là việc lựa chọn
dữ liệu nào được ưu tiên nhân bản.
Ngoài ra, việc nhân bản còn có khó khăn khi gặp các truy vấn phức tạp. Chính vì thế việc tạo ra bộ
các mẫu truy vấn (query template) sẽ giúp cho việc caching hiệu quả hơn.
Ở phía Edge Server ta còn có thể nhận thấy các Content-aware Cache, nghĩa là việc Caching phục
vụ cho một số ứng dụng hay dữ liệu cụ thể. Các yêu cầu còn lại khi cần có thể được chuyển tới phía
Origin Server.

1.7 Khả năng chịu lỗi
Khả năng chịu lỗi của hệ phân tán dựa trên mô thức Web cũng chủ yếu dựa vào các cơ chế Caching
và Nhân bản. Với giao thức HTTP thì không có cơ chế trợ giúp chống lỗi hay phục hồi. Tuy nhiên

việc hoạt động trên nền TCP cũng cho việc truyền thông khả năng chống lỗi phục hồi nhất định. Với
các Web Server, người ta có thể thực hiện dự phòng qua cơ chế nhân bản, đồng thời cung cấp địa chỉ
Web Server qua DNS sẽ giúp thực hiện việc phân tải về hệ thống.
Đối với các dịch vụ Web thì việc chống lỗi trở nên cần thiết. Với các dịch vụ nhạy cảm, ví dụ như
dịch vụ chuyển tiền, khả năng chịu lỗi đóng vai trò quan trọng. Nó không chỉ liên quan tới đường
truyền mà còn liên quan tới kiến trúc đa lớp giữa Client và Server.
Tuy nhiên, ngoài việc dự phòng các thành phần của hệ thống, một giao thức có khả năng chịu lỗi
cũng là một điều đáng quan tâm. Những vấn đề sau cần được quan tâm với một giao thức cung cấp
khả năng chịu lỗi của một hệ phân tán Web:

• Giao thức chống lỗi có thể được nhìn như một ứng dụng Web. Nó phải được ẩn đối với



người dùng. Giao thức chống lỗi bản thân là tiến trình thu thập và xử lý thông tin của các
tiến trình khác. Sau khi có lỗi nó sẽ phải thực hiện các xử lý phù hợp cho tiến trình gặp lỗi.
Giao thức chống lỗi cũng phải đảm bảo nhất quán khi trả lời các thành phần được nhân bản,
để đảm bảo tính nhất quán giữa các thành phần đó.
Giao thức chống lỗi phải coi dịch vụ được cung cấp như một thực thể, nghĩa là chỉ khi thành
phần thu thập thông tin nhận được đủ tất cả các thông báo từ các thành phần nhân bản, nó
mới được đưa ra xử lý phù hợp.

24


1.8 Tính an toàn, bảo mật của hệ thống
Với đặc tính mở của hệ thống Internet, việc xây dựng một kiến trúc bảo mật giữa Client và Server là
điều quan trọng. Hầu hết các giải pháp với hệ thống Web là việc xây dựng một tuyến bảo mật giữa
Client và Server, hay nói cách khác là bảo mật các thông tin truyền qua mạng thông qua mã hóa.
Thông thường trong thực tế người ta sử dụng giao thức mã hóa như TLS hay SSL để bảo mật. Hình

dưới cho ta thấy vị trí của giao thức TLS trên mô hình OSI:

Hình 1.19: Vị trí của TLS trong mô hình OSI
(Figure 12-22 Distributed Systems: Principles and Paradigms)
Chúng ta có thể xem xét việc xây dựng một tuyến bảo mật qua việc thiết lập một phiên truyền dữ
liệu của TLS qua hình vẽ sau:

Hình 1.20: TLS xác thực
(Figure 12-23 Distributed Systems: Principles and Paradigms)
Nhưu vậy, ta thấy việc thiết lập một kết nối bảo mật bao gồm 2 giai đoạn:

25


×