Bài giảng Internet và các giao thức - Nguyễn Chiến Trinh

160 trang ngocly 3420

Download

Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Internet và các giao thức - Nguyễn Chiến Trinh", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

bai_giang_internet_va_cac_giao_thuc_nguyen_chien_trinh.pdf

Nội dung text: Bài giảng Internet và các giao thức - Nguyễn Chiến Trinh

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 P T I T
Hà nội - 2014 P T I T 1
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 1.1 Giới thiệu 11 1.2 Kiến trúc lớp ứng dụng mạng Internet 12 1.2.1 Kiến trúc khách/chủ 12 1.2.2 Kiến trúc ngang hàng 13 1.3 Quá trình truyền thông trên mạng 14 1.3.1 Tiến trình khách và chủ 14 1.3.2 Giao diện giữa tiến trình và mạng 15 1.4 Dịch vụ truyền tải cho ứng dụng 16 1.4.1 Truyền dữ liệu tin cậy 16 1.4.2 Thông lượng 17 1.4.3 Yêu cầu về thời gian 18 1.4.4 Khả năng đảm báo an toàn dữ liệu 18 1.5 Các dịch vụ Ptruyền tải cung Tcấp trên m ạngI Internet T 18 1.5.1 Các dịch vụ TCP 19 1.5.2 Các dịch vụ UDP 20 1.5.3 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.4 Các tiến trình đánh địa chỉ 21 1.6 Các giao thức lớp ứng dụng 21 1.7 Một số ứng dụng mạng 22 CHƯƠNG 2. WEB VÀ GIAO THỨ C HTTP 24 2
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 Khuôn dạng ban̉ tin HTTP 28 2.3.1 Bản tin yêu cầu 28 2.3.2 Bản tin đáp ứng 30 2.4 Tương tać 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 Giao thức truyền tệp FTP 41 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 Thư điện tử trên Internet 43 3.2.2 Giao thức truyền thư điện tử đơn gian̉ SMTP 45 3.2.3 So sań h với HTTP 47 3.2.4 Khuôn daP̣ng ban̉ tin thư đTiện tử 48I 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 Giới thiệu DNS 54 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 3
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 ban̉ 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. KÊT́ NỐI MẠNG ĐA PHƯƠNG TIÊṆ 82 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 Yêu cầu cPhât́ lượng c ho ưT́ng dụng đ a phIươn g tiêṬn trên Internet 85 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 Truy cập audio và video thông qua Web server 90 6.2.2 Gửi dữ liệu đa phương tiện từ server trực tuyến đến ứng dụng 91 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 4
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 Giao thức tương tać thời gian thực 110 6.4.1 Giao thức RTP 110 6.4.2 Giao thức RTCP 114 CHƯƠNG 7. XU HƯỚNG PHAT́ TRIÊN̉ Ứ NG DỤNG VÀ DIC̣ H VỤ TRÊN NỀN INTERNET 118 7.1 Xu hướng hội tụ và mạng NGN 118 7.1.1 Xu hướng phat́ triển mạng toàn IP 118 7.1.2 Xu hướng hội tụ mạng và dic̣ h vu ̣ 119 7.1.3 Kiến trúc tổng thể mạng NGN 121 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ô hiǹ h lớp ứng dụng mạng NGN 128 7.2.2 Kiến trúc dic̣ h vụ mạng NGN 129 7.2.3 Các dịch vụ trên nền NGN 138 7.3 Một số xu hPướng phat́ triểnT ứng dụng và dIic̣ h v ụ trTên nền Internet 140 7.3.1 Xu hướng phat́ triển mạng và dịch vụ Internet 140 7.3.2 Sự phát triển của công nghệ Web 141 7.3.3 Điện toań đaḿ mây 151 TÀI LIỆU THAM KHẢO 158 5
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 gPốc năm 2009 (tên,T tổ chứ c, vị Itrí) T 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 6
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ịPch vụ T I T 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 7
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 P T I T 8
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 P T I T 9
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 trongP thời gian tương T đối ngắn nênI không tránhT 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. 10
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. P T I T 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. 11
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ụPng nổi tiếng vớiT kiến trúc khách/chI ủ là Tweb, 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ủ. 12
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:P peer-to -peerT) có rất ít (hoIặc không T 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 13
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: 1. 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. 2. 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. 3. 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ềPu khiển. Song ởT đây, chúng ta Ikhông tậTp 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ẻ 14
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́chP thì các bản tinT sẽ chuy ển quaI c ửa tiTến trình nhận (socket) và tiến trình nhận sẽ nhận các bản tin này. 15
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 trongP những giao thứTc lớp giao vậnI đó. Vậy Tlự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 16
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ó cPần gửi dữ li ệu vàoT mạng và dữI liệu đượTc 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 17
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 triPển khai ứng dụTng. I T 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 18
Chương 1. Các nguyên lý lớp ứng dụng mạng Internet Điện thoại Internet/ Có: n×100 ms Chịu được tổn thất hội nghị Video Audio: vài kb/s – 1 Mb/s Audio/video lưu trữ Chịu được tổn thất Video: 10kb/s – 5Mb/s 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ể chPịu được tổ n thấTt và không cầnI phả i là dTị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 sPử dụng SSL. SongT qua tìm hiểIu ngắ n gọTn 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. 20
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ôngP tin quan trọng:T (1) tên hoặcI địa chỉ cTủ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 chứa 21
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: 1. Loại bản tin trao đổi, ví dụ bản tin yêu cầu và bản tin phản hồi; 2. 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; 3. Ngữ nghĩa của các trường, tức là ý nghĩa của trường thông tin; 4. 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. 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íP dụ máy ch ủ ApacheT và Microsoft)I vàT 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ử. 22
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. P T I T 23
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 chiP tiết về HTTP chúngT ta xem xétI m ột sốT 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: 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à 24
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ểmP soát của TCP. NhưT trong chươngI trư ớcT đã đư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). 25
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à 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ủ 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 mPột bản tin yêuT cầu HTTP tới máyI chủ quaT 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. 26
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áyP chủ sẽ gử i tệpT HTML vào kếtI nối TCP. TLầ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. 27
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 WebP trong cùng mTột máy ch ủ cóI thể đượTc 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 ban̉ 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 28
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ụPng là Mozilla/4.0 T, trình duyIệt của TNetscape. 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 29
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ươngP thức HEAD đểT gỡ rối (debugging). I PhươngT 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. 30
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 đPối tượng ở trongT khối thự c thIể là văn Tbả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: 1. 200 OK: Yêu cầu thành công và thông tin được trả về trong bản tin đáp ứng. 2. 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. 31
Chương 2. Web và giao thức HTTP 3. 400 Bad Request: Đây là mã ỗl i chung chỉ ra là máy chủ không hiểu yêu cầu. 4. 404 Not Found: Tài liệu yêu cầu không tồn tại ở máy chủ này. 5. 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òngP cuối). T I T 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 32
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 tać 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 Pđây. Khi Susan tiTếp tục duy ệt trangI Amazon,T 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. 33
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̀yP trong cơ sở dữT liệu của mình,I và vì thTế 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 đó. 34
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 Sau đây là trình tự những hoạt động sẽ xảy ra: 1. 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. 2. 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. 3. 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. 4. 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áchP và máy ch ủ đTệm Web). I T 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 35
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 gianP này thườ ng đưTợc coi là “trễI Internet”. T 36
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êuP cầu)/(15Mb it/s)=T 1 I T 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. 37
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. P T I 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:. 38
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 đPề If-Modified T-Since: I giống hệTt 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) 39
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. P T I T 40
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 specifiedP style in document.T.12 : FTPI chuy ển tTệ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̀ udioa 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 41
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 Pkhách được gửiT trên kết n ối điIều khi ểnT 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: 1. USER username: Dùng để gửi nhận dạng của người sử dụng tới máy chủ. 2. PASS password: Dùng để gửi mật khẩu của người sử dụng tới máy chủ. 3. 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. 42
Chương 3. Truyền tệp và thư điện tử 4. 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: 1. 331 Username OK, password required (tên máy chủ OK, yêu cầu mật khẩu) 2. 125 Data connection already open; transfer starting (kết nối dữ liệu đã mở; bắt đầu truyền) 3. 425 Can’t open data connection (không thể mở kết nối dữ liệu) 4. 452 Error writing file (lỗi ghi tệp) 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ó nhiPều đặc tính mạTnh mẽ. Sử dụngI danh mTụ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ó. 43
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 P1990, đại lý ngưTời sử dụng có Igiao diệnT đồ 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ì 44
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 gian̉ 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. 1. 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. P T I T 2. Đạ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. 3. 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). 4. 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. 5. 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. 6. Bob gọi đại lý người sử dụng của anh ấy để đọc bản tin khi thuận tiện. 45
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ảnP tin trao đ ổi giữTa máy khách SMTPI (C) Tvà 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 46
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: telnetP serverName T 25 I T 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 sań h 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 47
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 ban̉ 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ư. P T I T 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ử 48