Thiet Ke Giao Thuc5

  • Uploaded by: HocLieuMo
  • 0
  • 0
  • October 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Thiet Ke Giao Thuc5 as PDF for free.

More details

  • Words: 2,725
  • Pages: 5
12/6/2007

Tại sao chúng ta cần thiết kế giao thức mới?

Thiết kế giao thức



Các ứng dụng mới xuất hiện mọi nơi mọi lúc – ngày càng phụ thuộc vào truyền thông mạng 



Giảng viên: Nguyễn Hoài Sơn Bộ môn Mạng và Truyền thông máy tính Khoa Công nghệ thông tin

Network programming

Sự thay đổi trong môi trường làm việc đòi hỏi chúng ta xem xét lại thiết kế của các giao thức đã có

1

Quy trình thiết kế giao thức

Network programming

Hiểu mục đích, yêu cầu  







Network programming

4

Một số khía cạnh chung của việc thiết kế giao thức (2)

Quy mô thiết kế  Chỉ là một phần trong thiết kế ứng dụng nào đó  Nhằm tạo ra platform cho một môi trường cạnh tranh Mục đích thiết kế  Giải pháp hoàn chỉnh cho một ứng dụng  Tạo ra các gói đế sử dụng lại một cách mềm dẻo  Sử dụng các gói có sẵn để tạo ra giải pháp cụ thể nào đó Tạo ra hay Sử dụng lại  Sử dụng lại các công nghệ đã có  Hưởng lợi từ kinh nghiệm, code, etc. ít rủi ro  Nhưng: Có thực sự đáp ứng mục đích, yêu cầu, chi phí, …  Tạo ra công nghệ mới từ zero  Có thể tối ưu hóa phù hợp với quy mô, mục đích, yêu cầu sử dụng  chấp nhận rủi ro lớn hơn, nhiều thời gian để đưa ra thị trường Network programming

Must vs. nice-to-have

3

Một số khía cạnh chung của việc thiết kế giao thức (1)



Giới hạn về chức năng: Môi trường thực hiện Các giới hạn khác: giá thành, cân nặng, năng lượng tiêu thụ, memory, CPU, …

Hiểu về những thỏa hiệp có thể chấp nhận được 



Yêu cầu về chức năng: features, security,… Các yêu cầu khác: scale, time-to-market, cost, …

Hiểu về những giới hạn 



2

Các yêu cầu khi thiết kế giao thức 

Network programming

Cuộc cách mạng về thông tin làm xuất hiện các nhu cầu mới



Học từ những giải pháp liên quan 

Mượn các khái niệm và giải pháp  



 

Tránh “second system syndrome”

Bám sát các yêu cầu trong quá trình thiết kế Một số cách thức đơn giản hóa    

5

nhưng chỉ ở chỗ nào có thể áp dụng được Tránh lỗi. Xem xét các triến khai trên thực tế trước khi mượn

Tối ưu hóa cho trường hợp chung Không phức tạp hóa vấn đề – Keep it simple stupid (KISS) Tránh các tùy chọn và tham số Nhớ rằng cuối cùng chúng ta sẽ phải thực thi thiết kế

Network programming

6

1

12/6/2007

Một số khía cạnh chung của việc thiết kế giao thức (3) 





Định nghĩa rõ ràng các điểm truy cập dịch vụ (SAPs) Có xu hướng che dấu hoàn toàn các tầng dưới với các tầng trên

Phá vỡ sự trừu tượng hóa- Leaky abstraction    



Xử lý các khía cạnh độc lập nhau một cách độc lập Những gì thực sự là độc lập nhau?

Phân tầng chặt chẽ 



…giữa các yêu cầu và các hạn chế của môi trường làm việc  “Tốt, nhanh, rẻ – chỉ được hai, không thể thực hiện được cả ba.”  Ví dụ

Phân tách rạch ròi các vấn đề 



Thiết kế giao thức có tính Trade-Offs…



Phân tầng chặt chẽ không phải lúc nào cũng tốt Không nhất thiết phải che dấu bằng mọi giá Áp dụng cho thiết kế giao thức, lập trình và một số công việc khác By Joel Spolsky http://www.joelonsoftware.com/articles/LeakyAbstractions.html

  



Tối ưu hóa bằng thông tầng (Cross-layer) 

Xử lý các vấn đề phụ thuộc vào các tầng dưới ở tầng trên và ngược lại

Một thiết kế để thực hiện một mục tiêu nào đó sẽ tác động ngược lại vào một mục tiêu khác 

Network programming

7

Các bên truyền tin và vai trò 











8













Tên  Định danh có thể đọc được để con người dễ nhớ (e.g., DNS name, URI, URN) Định danh  Định dang có thể xử lý bới máy tính Địa chỉ  Định dang cấp giao thức (e.g., IP address) Địa điểm  Thông tin về địa điểm của bên truyền tin trong một tôpô mạng Cần quản lý (là duy nhất)  Hoặc được chọn ngẫu nhiên trong môi trường ad-hoc Các định danh này cần được chuyển đổi lẫn nhau  Address books, dữ liệu phân tán(e.g., DNS, DHTs), giao thức trao đổi, caching, cấu hình (thủ công), … Network programming

10

Độ phức tạp (2)

Độ phức tạp giao thức Số lượng của giao thức, số lượng của tùy chọn Độ phức tạp trạng thái  E.g., Số trạng thái và chuyển trạng thái, yêu cầu đồng bộ hóa  Số chuyển trạng thái (tương tác) để đạt được kết quả Độ phức tạp tính toán  Ví dụ: Mã hóa, định tuyến, tìm kiếm Vấn đề về tính tương thích  Cần làm tương thích với các phiên bản cũ  Khó khăn trong việc đưa ra chức năng mới, dễ dẫn đến sự phức tạp 



Network programming

9

Độ phức tạp 

Cần tìm kiếm sự thỏa hiệp hợp lý để thực hiện được chức năng yêu cầu với giá thành có thể chấp nhận được

Định danh bên truyền tin

Truyền tin điểm-điểm vs. nhiều điểm  Có bao nhiêu bên tham gia vào quá trình truyền tìn? Unicasting vs. group-overlays vs. multicasting  Kiểu trao đổi thông tin nào được giả thiết? Truyền tin Client-server vs. truyền tin ngang hàng  Các bên có cùng vai trò hay có vai trò khác nhau? Truyền tin cuối-cuối vs. trung gian vs. hỗ trợ của router  Những thực thể nào có thể, có hoặc phải tham gia vào quá trình truyền tin? Chúng có “thấy được” hay không? Network programming

Độ tin cậy vs. độ trễ Chức năng vs. băng thông Khả năng mở rộng vs. hiệu quả Chức năng vs. đơn giản

Network programming

11



Độ phức tạp thực thi Yêu cầu về CPU (liên quan đến độ phức tạp hoạt động và độ phức tạp tính toán)  Yêu cầu bộ nhớ (code, dữ liệu – liên quan đến độ phức tạp trạng thái)  Yêu cầu về độ lớn của đĩa  Những tài nguyên khác… 

Network programming

12

2

12/6/2007

Độ phức tạp điều khiển 

Tính kinh tế

Để chạy hệ thống Có bao nhiêu tham số phải cấu hình?  Cần bao nhiêu sự phối hợp (ví dụ. giữa các tổ chức)?  Có thể phát hiện được cấu hình sai không và cấu hình như thế nào?  Xử lý tự động vs. xử lý thủ công Theo dõi  Những tham số nào? Như thế nào? Chu kỳ bao lâu?... Xứ lý lỗi  Giảm dần vs. ngừng hoàn toàn hoạt động của hệ thống  Làm thế nào để theo dõi và phát hiện lỗi?  Làm thế nào để khôi phục lại hệ thống?  Mất khoảng bao nhiêu lâu?









Network programming







13

Một số vấn đề về thiết kế giao thức 





Network programming



Trạng thái này được lưu giữ tại đâu? (Tại một hay cả hai bên trong trường hợp giao tiếp điểm-điểm)? 

  





15







Network programming

16

Một câu đánh giá thiết kế điển : “Thiết kế này không co dãn (scale) …”

robustness (chống DoS, điểm lỗi duy nhất, etc.) Khả năng đưa ra thực tế theo từng bước

Khả năng tương thích 

Ví du: tiêu đề giao thức, mã hóa giao thức

Số lượng tương tác giao thức, packets, bits, xử lý

Khả năng mở rộng

Bảo mật Khả năng triển khai 

Ví dụ điển hình: Số lương nodes Tốc độ truyền dữ liệu, tốc độ lỗi, độ dài đường truyền, độ trễ Số lượng và kích thước dữ liệu

Hiệu quả  Duy trì một mức độ overhead hợp lý 

Đánh giá thiết kế giao thức (2)

Ví dụ: sự thích ứng về độ trễ playout và codec với truyền thông đa phương tiện

Khả năng mở rộng  Có thể làm việc trong các khoảng rộng của các tham số môi trường





14

Khả năng thích ứng  Khả năng thích ứng với các điều kiện môi trường khác nhau (thay đổi chất lượng dịch vụ ở mức có thể chấp nhận được) 

Nút cố định vs. nút di động  ảnh hưởng đến định tuyến, khả năng truy cập, … Truyền tin dựa vào hạ tầng mạng vs. truyền tin kiểu ad-hoc/tự động  Kiểu hạ tầng này được giả thiết? Bảo mật trong giao thức vs. bảo mật dựa vào nơi khác  Yêu cầu nào? (e.g., hạ tầng yêu cầu như PKI)

Network programming

giá trị của một mạng truyền thông tỷ lệ với bình phương của số người tham gia

Đánh giá thiết kế giao thức (1)

Hoạt động có trạng thái vs. không trạng thái  Số lượng thông tin cần duy trì khi trao đổi thông tin  Khái niệm về “liên kết” hay “kết nối” 



Truyền dữ liệu gắn với chi phí  Rate, volume, packets, QoS, … Độ phức tạp thực thi gắn liền với chi phí  Nhân công để thiết kế, thực thi và kiểm tra hệ thống  Các thiết bị cần thiết Lợi nhuận gắn liền với độ phức tạp giao thức  Định luật Metcalfe



Tương thích với các phiên bản cũ và mới



Khả năng điều khiển và quản lý

Network programming



17

Tại sao? Câu này nói về điều gì? Tại sao lại phải như vậy?

Network programming

18

3

12/6/2007

Khả năng mở rộng nói chung

Khả năng mở rộng như là một thước đo (1)

Thường dùng (không chỉ) trong truyền tin, là  Khả năng của hệ thống hoạt động với nhiều điều kiện môi trường khác nhau  ngược lại là chỉ hạn chế với một điều kiện môi trường duy nhất  Đánh giá trên một hay nhiều tham số đầu vào  Khả năng sử dụng với khoảng tham số đầu vào có thể chấp nhận được  Gần như gắn liền với mức độ( và tính công bằng) sử dụng tài nguyên  Liên quan đến học thuyết về độ phức tạp  Phân chia mức độ sử dụng tài nguyên dựa trên đầu vào Các cấp độ phức tạp: O(1), O(n), O(log n), O(nk), O(en)

Network programming

19

Khả năng mở rộng: Phía mạng 





Khả năng mở rộng: Phía mạng (2)

Độ trễ do khoảng cách phụ thuộc tốc độ truyền ánh sáng + độ trễ xử lý/xếp hàng tài mỗi nút mạng Trên một host vs. cùng mạng cục bộ vs. cách 30 hops trên mạng Internet < 1ms trên đường LAN vs. vài giây qua GPRS hay truyền thông vệ tinh 



vs. vài phút, vài giờ với trạm vũ trụ

do giao thức truy cập trung gian

Network programming





Đo bởi số hoạt động trong 1 giây vs. 1 giờ vs. 1 ngày Thời gian giữa 2 cập nhật Kích thước dữ liệu từ vài chục bytes đến10 GB

Số lượng các bên tham gia (người dùng, mạng, hệ thống)  



Bao nhiêu bên thực hiện gửi Số luợng mỗi bên tham gia 

Các hoạt động chi phí cao như chấp nhận và đóng kết nối, bảo mật, …

Multiplexing và xử lý xuất nhập dữ liệu  Xử lý đa tiến trình vs. đa luồng vs. đơn luồng  Vấn đề với hiệu quả cuộc gọi hệ thống (e.g., poll (), select ())  Xử lý nhiều sự kiện sẽ tiêu tốn thời gian Truy cập dữ liệu  Tìm kiếm dữ liệu trong ổ cứng khi truy cập file  

Ổ cứng là “nhanh” nếu không truy cập dồn Ví dụ: video-on-demand streaming

Băng thông bus của hệ thống Tương tác với các tiến trình khác trên cùng một máy tính 

Ví dụ: vấn đề C10K: xử lý 10,000(s) máy khách với một máy chủ Network programming

22

Vấn đề C10K:  Sự tương tác thường xuyên 



Kích cỡ dữ liệu 



Network programming

Khả năng mở rộng: thực thi

Tốc độ cập nhật hay gửi yêu cầu 

Mức độ mất mát  Độ mất mát 0 trên đường truyền cục bộ vs. Mất mát < 10% trên đường truyền Internet  Mất mát không dự đoán được trên đường truyền không dây  Mất mát riêng rẽ (tuân theo một phân bố nào đó) vs. mất mát bùng nổ Tốc độ đường truyền  Vài trăm bit/s qua đường truyền không dây, tiết kiệm điện vs. Tbit/s trên đường cáp quang

21

Khả năng mở rộng: Phía ứng dụng





Độ trễ không đổi trên mạng cục bộ vs. độ trễ chênh lệch vài giây với truyền tin vệ tinh 



20

Độ dài đường truyền (Số lượng hop, độ trễ, biến thiên độ trễ) 



Network programming



23

Network programming

24

4

12/6/2007

Khả năng mở rộng: thực thi(2) 

Cân bằng tải 



Sử dụng chuỗi máy chủ để cân bằng tải  





 Vấn đề: cần phải đồng bộ dữ liệu giữa các máy chủ Khả năng mở rộng với các platform  Thiết bị chạy bằng pin  Hệ thống nhúng nhỏ (TCP stack 4 KB)  TV/car yêu cầu giá thành thấp  Phone/PDA  Desktop hay laptop PC cấu hình mạnh  Máy tính đa CPU tốc độ cao







26

Khả năng thích ứng

Phân tán, ủy thác



Dynamic Delegation Discovery System (DDDS): Ánh xạ chuỗi ký tự vào dữ liệu Network programming

Tìm kiếm từ dưới lên: khai thác tính cục bộ của các yêu cầu Đạt hiệu quả nhờ caching Network programming





Có thể ánh xạ tới bất cứ thông tin gì

Khả năng mở rộng được thực hiện như thế nào? 

25

Để có thể quản lý và hoạt động phân tán Giao phó trách nhiệm một cách dễ dàng

Mục đích chung: không chỉ dùng với địa chi IP 



Một máy chính và một hay nhiều hơn một máy phụ

Cấu trúc phân tầng của tên miền 

Ví dụ: DNS (2) 

Mô hình phân tán: sự hợp tác giữa các máy chủ Máy chủ dự trữ: tránh “single point of failure” 

Và giảm độ trễ truyền thông

Network programming

Tính chất then chốt 

Cân bằng tải sử dụng DNS, proxies Có thể xử lý phân tán để tăng khả năng truy cập 



Ví dụ: DNS



27

Tính chất của mạng có thể thay đổi nhiều và nhanh  Phục thuộc vào hoạt động của các bên tham gia  Phụ thuộc vào tải do các máy khác  Phụ thuộc vào sự thay đổi định tuyến mạng (e.g., để đáp ứng với sự hỏng hóc) Tính chất của ứng dụng có thể thay đổi nhiều  Kích thước dữ liệu  Số lượng các bên tham gia Sự thay đổi thường không thể dự đoán trước được

Network programming

28

Bài tập 2 

 



Tự thiết kế một giao thức mạng và trình bày thiết kế theo các mục sau:  Mục đích, yêu cầu của giao thức  Chi tiết về giao thức thiết kế  Ưu/nhược điểm của giao thức thiết kế với các giao thức khác Thời hạn nộp bài: Thứ 2 ngày 15 tháng 10 năm 2007 Địa chỉ nộp bài: [email protected] and [email protected] Tiêu đề mail: [Network programming K49-MMT][2] Your name

Network programming

29

5

Related Documents


More Documents from ""

Ltdt6
October 2019 9
Dstt05
October 2019 7
Otmat08
October 2019 10
Otmat04
October 2019 11
Sthc04
October 2019 10
Pluatdc5
October 2019 7