Tiểu Luận Môn Học Hệ Phân Tán – Distributed Web Based System

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

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

Đề tài: Distributed-Web-Based-System

Giảng viên hướng dẫn: TS. Trần Thị Minh Châu
Thực hiện: Nguyễn Ngọc Thế - Nguyễn Thị Ngọc Tú
Lớp: k17

Hà Nội – 01/2011

1


MỤC LỤC
1.1

Kiến trúc chung ............................................................................................................................ 3

1.1.1

Mô hình truyền thống ............................................................................................................ 3

1.1.2

Mô hình dịch vụ web ............................................................................................................. 6

1.2

Các tiến trình trong hệ phân tán trên nền web.............................................................................. 8

1.2.1

Tiến trình tại phía Client ........................................................................................................ 8

1.2.2

Tiến trình tại máy chủ Web ................................................................................................... 9

1.2.3

Cơ chế chạy Clustering các máy chủ ................................................................................... 10

1.3

Cơ chế truyền thông ................................................................................................................... 11

1.3.1

Giao thức HTTP .................................................................................................................. 11

1.3.2

Giao thức SOAP .................................................................................................................. 14

1.4

Cơ chế định danh ........................................................................................................................ 14

1.5

Cơ chế đồng bộ ........................................................................................................................... 15

1.6

Cơ chế nhất quán và nhân bản. ................................................................................................... 16

1.6.1. Cơ chế Proxy Caching ............................................................................................................ 17
1.6.2. Nhân bản các ứng dụng web (Chi tiết). .................................................................................. 17
1.7.

Khả năng chịu lỗi. ................................................................................................................... 17

1.8. Tính an toàn, bảo mật của hệ thống............................................................................................ 24
TÀI LIỆU THAM KHẢO ....................................................................................................................... 25

2


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.1Mô 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.
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.

3


•

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.2Mộ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.

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.

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)

4


1.1.1.3Mô 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ạnh để 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
(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.

5


•
•
•

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.1Mô 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.

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:

6


•
•
•

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óm 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.

1.1.2.2Thà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 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 gọi (Look up a
Service - Hình 1.3). Tuy nhiên, trong thực tế mô hình 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.

7


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.

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.1Tiế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).

8


1.2.1.2Tiế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).
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

9


(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ủ.

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)

10

Ý 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

Để đạ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 này.

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 client-server 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.1Kế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...

11


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.2Cá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.
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:

12


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”.
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)

13

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ó.

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.

14


•

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
(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.

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.

15

•

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.

1.6 Cơ chế nhất quán và nhân bản.
Càng ngày các ứng dụng về web lại càng được quan tâm tới những vấn để về hiệu năng và tính
chính xác. Đặc biệt là với các hệ thống phục vụ nhiều người dùng, cung cấp những dịch vụ nhạy cảm

như ngân hàng, giao dịch tiền bạc, cũng như các bảng hệ thống chứng khoán trực tuyến. Những hệ
thống này phải đảm bảo không được chậm trễ, và đồng thời cũng luôn luôn có tính chịu lỗi cao.
Với việc đảm bảo hiệu năng hệ thống thì giải pháp chính là qua cơ chế caching dữ liệu (lưu thông
tin dữ liệu yêu cầu của client) nhằm đáp ứng lại ngay được làm giảm thời gian truyền thông tin cũng
như là giảm xử lý phía server. Và cũng đồng thời với việc tạo ra nhiều ứng dụng giống nhau trên nhiều
server khác nhau. Sẽ góp phần đáp ứng nhanh nhu cầu cầu của người dùng.
Hệ thống có cơ chế nhất quán. Đảm bảo là không khiến thông tin trả về khách hàng bị sai lệch
hoặc nhầm lẫn. Khi có nhiều máy chủ cùng chạy song song giúp đảm bảo tính an toàn. Khi bất kỳ
server nào bị gián đoạn cũng không làm ảnh hưởng quá nhiều tới hệ thống.

16


1.6.1. Cơ chế Proxy Caching
Caching client-side thường xuất hiện ở 2 vị trí. Thứ nhất, là ở bộ đệm của các trình duyệt. Mỗi
khi lấy dữ liệu của website nó thường lưu lại trong bộ đệm của nó. Khi có yêu cầu lấy lại dữ liệu thì nó
sẽ kiểm tra trong bộ nhớ đệm trước. Nếu có thì nó sẽ được sử dụng. Bộ đệm của trình duyệt có thể do
người dùng cấu hình được.
Thứ hai, bộ đệm có thể được lưu ơ web proxy. Web proxy làm cầu nối giữa Client và Server vì
vậy nó có thể lưu dữ liệu của lần request trước để sử dụng cho các lần sau.

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

Cơ chế để đảm bảo tính nhất quán của dữ liệu: mỗi lần gửi request tới web Proxy thì web proxy
lại gửi một xác thực tới server xem dữ liệu có bị thay đổi hay không. Nếu dữ liệu là không bị thay đổi
thì nó sẽ lập tức gửi cho client. Còn không thì Web Server sẽ gửi dữ liệu lại cho Web Proxy . Web
Proxy sẽ gửi dữ liệu mới cho phía client và lưu lại dữ liệu mới. Cơ chế này chủ yếu phù hợp với web
tĩnh .

1.6.2. Nhân bản các ứng dụng web.
Trong phần này chúng tôi sẽ giới thiệu với các bạn 2 mô hình “Nhân Bản Một Ứng Dụng Web
Động “ và chúng ta đi vào phân tích một ứng dụng thực tế để thấy rõ những ưu điểm, nhược điểm,
đánh giá khó khăn khi áp dụng một mô hình phân tán.
Mô hình thứ nhất : Mô hình theo sách giáo khoa

17


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

Mô hình thứ hai: Của các tác giả
Swaminathan Sivasubramaniam, Guillaume Pierre, Maarten van Steen.

(a) edge computing

(b) content-aware caching,

(c) content-blind caching (d) data replication.
18


Giải thích thành phần của mô hình:
1. Edge server: Server ngoài biên. Có thể chứa bản sao lưu của toàn bộ ứng dụng web
hay chứa một phần ứng dụng.
2. Origin server: Server trung tâm. Nơi chứa ứng dụng web chính. Phục vụ cho các tác
vụ từ các server biên.
3. Content – aware Caching
Thay vì giữ những bản sao đầy đủ của các hệ thống cơ sở dữ liệu CAC lưu lại kết quả

truy vấn cơ sở dữ liệu như là mã ứng dụng của chúng.
Kiểm tra ngăn chặn truy vấn: Các ứng dụng chạy ở các server biên
(edge-server) kiểm tra các cơ sở dữ liệu tại địa phương nếu có đủ dữ liệu để trả lời các
truy vấn tại địa phương thì tự sẽ trả lời luôn.
Chúng có thể kết hợp dữ liệu của giữa server chính (origin-server) và server biên để
trả về cho phía client.
CAC lưu trữ kết quả các câu truy vấn.
Ví dụ: Query 1: select * from items where price < 50
Query 2: select * from items where price < 20
Query template: “Select * from items where price <”
Kiểm tra ngăn chặn truy vấn này là rất đắt tiền bởi vì nó phải kiểm tra các truy vấn mới
với tất cả các truy vấn trước đó được lưu trữ.
Để giảm chi phí CAC này sử dụng các mẫu truy vấn, với một tham số truy
vấn SQL có giá trị tham số được phân tích trong thời gian chạy
Trong hệ thống CAC luôn luôn cập nhật các truy vấn được thực hiện tại các cơ sở dữ
liệu trung tâm.
4. Content-blind Caching
Ở đây , các máy chủ biên hạn chế tới mức tối đa việc thao tác với cơ sở dữ liệu. Vì
vậy nó lưu trữ các kết quả của các truy vấn cơ sở dữ liệu độc lập.
Kết quả tìm kiếm sẽ được lưu trữ ở đây không cần phải sât nhập với thông tin phía
server trung tâm. Khi có một yêu cầu của client tới nó có chứa dữ liệu trả về luôn do
đó chi phí rất thấp, thời gian thực thi được đảm bảo.
CBC có một số ưu điểm so với CAC như:
Phải gánh chịu rất ít tính toán tải trọng.
Caching kết quả truy vấn là toàn bộ thay vì hồ sơ dữ liệu do đó có thể trả về kết quả
ngay lập tức.
19


Cuối cùng , khi thêm một nguyên tố mới vào bộ nhớ cache không yêu cầu phải sửa

đổi câu truy vấn.
5. Data replication
Giải pháp cho các máy server ngoài biên là đặt dữ liệu ở mỗi máy chủ khác nhau. Tạo
thành các cơ sở dữ liệu sao chép có thể giúp duy trì các bản sao giống hệt nhau ở
nhiều địa điểm.
Cũng có một số vấn đề nảy sinh ở đây là khi có một cập nhật cơ sở dữ liệu thì cần chi
phí để cập nhật các server con.
Dựa vào 2 mô hình trên trong thực tế thường áp dụng mô hình sau cho những ứng dụng cần
đáp ứng số lượng người truy cập lớn.
Web
Browser

Web
Browser

APPL.Code

APPL.Code

APPL.Code

(Edge-server)

(Edge-server)

(Edge-server)

Web
Browser

Request

Respons

Caching
APP(CBC)

Caching
APP(CBC)

Database

Database
Replication

Caching
APP(CBC)

Replication
Databse Master

Mô hình và các phương pháp cài đặt
20


Giải thích:
a. Quá trình cài đặt các : Edge Server (áp dụng phương pháp Share tải trong mạng, chủ yếu
là cấu hình hệ thống phần cứng) Thông tin thêm mời các bạn có thể tìm hiểu.
b. Cache dữ liệu ở tại ứng dụng. Có thể lưu vào trong Ram Server,lưu vào file, Bộ Nhớ
đệm của ứng dụng (VD: application pool của IIS, … ) ..Dữ liệu của của Cache có thể

được cập nhật khi nó không tìm thấy dữ liệu. Và cũng có thể được định kỳ cập nhật.
c. Những database sao lặp database chính.Chúng được đồng bộ hóa database chính. Mục
đích cho các ứng dụng view dữ liệu từ các database này. Mỗi database sao lặp có thể
được chỉ đinh view một phần dữ liệu mà tầng Edge Server cần .
Áp dụng cho mô hình hệ quản trị SQL:
+ Sử dụng cơ chế đồng bộ hóa Dependency của SQL để đồng bộ các database
+ Các database đặt tại các server trong 1 Work Group(Nhằm có thể nhìn thấy nhau, và
đáp ứng được Dependency)
d. Database Server chính chỉ làm nhiệm vụ cập nhật dữ liểu của ứng dụng web. Và đồng bộ
với các Database Server sao lặp khác trong hệ thống.
Chương trình demo.
Do điều kiện thời gian có hạn và kinh nghiệm cải đặt một hệ thống lớn còn hạn chế nên
chúng em demo một chương trình đơn giản sau :
Ứng dụng mô hình phân tán vào website: Http://infomap.vn.

21


Mô hình gồm:
1. Cài đặt 1 Edge-server
2. Cài đặt 1 Caching (CBC)
3. Cài đặt 1 Databse Master
Bảng phân tích đánh giá hiệu năng khi áp dụng mô hình :
Tiêu chuẩn

Mô hình cũ

Mô hình phân tán.

Cài đặt

Dễ

Khó

Lượng người dùng có thể
đáp ứng

< 10.000 Page/1 ngày
<500 Page/1H
< 20 Page /1s

>50.000 Page/1 ngày
>4000 Page /1h
> 100Page/1s

Thời gian / Trang Chi tiết

5s

1.5s
22


Thao tác với server

Hoàn toàn

Rất ít.

Chip sử dụng SQL

80 -> 100%(máy chủ dẽ bị
tổn thương)

5-> 15% (máy chủ ít phải
hoạt động)

300 MB

700MB

Nhanh hơn

Chậm hơn.

Bộ nhớ của ứng dụng
(w3wp.exe)
Tính cập nhật dữ liệu

Demo ứng dụng qua internet. Truy cập vào qua máy tính đã cài đăt qua logmein Mô tả kiến trúc
database, và chạy thử quá trính Caching dữ liệu. Phân tích các rủi ro gặp phải của nó trên ứng dụng
thực.

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.

23


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ư 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:
•
•

Giai đoạn 1: Client thông báo tới Server các thuật toán mã hóa và các chuẩn nén mà Client có thể hỗ trợ.
Server lựa chọn thuật toán và chuẩn nén cho kết nối đó và gửi trả lại thông tin cho phía Client.
Giai đoạn 2: Giai đoạn 2 là giai đoạn xác thực giữa Client và Server. Server xác thực (chứng minh mình
là Server) thông qua một chứng thư. Nếu như Server yêu cầu Client phải xác thực thì Client sẽ phải xác
thực với Server.

Sau quá trình xác thực, Server và Client sẽ thực hiện thỏa thuận về một số tham số dành cho việc mã hóa
(Session key). Hai bên sẽ sử dụng các tham số này cùng với hệ thống khóa công khai và khóa riêng để mã hóa
và giải mã dữ liệu.

24


TÀI LIỆU THAM KHẢO

[1] Andrew S.Tanenbaum, Maarten Van Steen, Distributed Systems - Principles and Paradigms, 2nd
edition, Pearson Education, 2007
[2] Slide Web Distributer of Swaminathan Sivasubramaniam, Guillaume Pierre, Maarten van Steen.
[3] ASP.NET + MVC + SQL 2005

25