Bài giảng Mạng máy tính - Bùi Trọng Tùng

đi ngắn nhất  Đường đi ngắn nhất(qua ít AS nhất) là mục tiêu rất quan trọng trong định tuyến liên vùng (vì sao?) nhưng không phải là ưu tiên hàng đầu.  BGP ưu tiên chọn đường theo chính sách trước 2 3 1 Nút 2 có thể chọn “2, 3, 1” thay vì “2, 1” 143 142 143 71 BGP khác DV (2) Định tuyến theo vector đường đi  Ý tưởng chính: quảng bá toàn bộ các chặng trên đường đi  Distance vector: chọn đường dựa trên chi phí của đường đi tới các đích  có thể xuất hiện đường đi quẩn do vấn đề đếm tới vô cùng (count-to-infinity)  Path vector: chọn đường dựa trên các chặng của đường đi tới đích  dễ dàng phát hiện các đường đi quẩn (loop) 3 2 1 “d: path (2,1)” “d: path (1)” “d: path (3,2,1)” d 144 BGP khác DV (3) Kết hợp đường đi  BGP có khả năng kết hợp các đường đi tới các mạng con không đầy đủ VNPT a.0.0.0/8 HUST a.b.0.0/16 VNU a.c.0.0/16 đường đi tới a.*.*.* foo.com a.d.0.0/16 145 144 145 72 BGP khác DV (4) Quảng bá có chọn lựa  Một AS có thể chọn để không quảng bá đường đi tới một đích nào đó  Nói một các khác, một AS có đường đi tới AS đích nhưng không đảm bảo sẽ vận chuyển mọi lưu lượng mạng tới đó Ví dụ: AS2 không muốn vận chuyển thông tin từ AS1 tới AS3 146 AS1 AS3 AS2 Quảng bá có chọn lựa  Lựa chọn: Đường đi nào được dùng để chuyển dữ liệu tới AS đích?  Kiểm soát thông tin ra khỏi AS  Quảng bá: Quảng bá cho AS khác đường đi nào?  Kiểm soát thông tin vào AS Đường đi tới đích X Lựa chọn Khách hàng Đối thủ cạnh tranh A B C Quảng bá 147 146 147 73 Quảng bá có chọn lựa: Một số chính sách điển hình  Thay đổi mục tiêu khi định tuyến:  Tối thiểu hóa chi phí, tối đa hóa lợi nhuận  Tối đa hóa hiệu năng (đường đi qua ít AS nhất)  Tối thiểu hóa lưu lượng qua AS (định tuyến kiểu “hot potato”)  ...  BGP có cơ chế gán thuộc tính cho các tuyến đường để thực hiện các mục tiêu trên 148 4.4.2. Hoạt động của BGP 149 148 149 74 eBGP, iBGP và IGP  BGP cài đặt trên các router biên của AS(kết nối tới các AS khác): 2 phiên hoạt động  External BGP (eBGP): thực hiện trao đổi thông điệp với các router biên trên AS khác để tìm đường đi tới đích nằm ngoài AS của nó  Internal BGP (iBGP): trao đổi thông điệp với các router biên và router nội vùng cùng AS để quảng bá đường đi tới đích nằm ngoài AS của nó  IGP : Interior Gateway Protocol = Intra-domain Routing Protocol  Cài đặt trên router nội vùng  Tìm đường đi tới đích nằm trong vùng AS  Dữ liệu tới đích ngoài AS sẽ được chuyển tới router biên 150 eBGP và iBGP – Ví dụ  Quảng bá thông tin đường đi 1. 3a gửi tới 1c bằng eBGP 2. 1c gửi thông tin nội bộ tới (1b, 1d, ) trong AS1 bằng iBGP  1b: Router biên cài BGP  1a,1d: Router nội vùng cài IGP 3. 2a nhận thông tin từ 1b bằng eBGP 3b 1d 3a 1c 2a AS3 AS1 AS2 1a 2c 2b 1b 3c eBGP session iBGP session 151 150 151 75 Các thông điệp BGP cơ bản  OPEN:  Thiết lập phiên trao đổi thông tin đường đi  Sử dụng TCP, cổng 179  NOTIFICATION: thông báo các sự kiện bất thường  UPDATE:  Thông báo về đường đi mới  Thông báo về đường đi không còn khả dụng  KEEPALIVE: thông báo duy trì kết nối TCP  Kết nối của TCP cung cấp cho BGP là nửa duy trì (semi- persistent) 152 Phiên trao đổi thông tin của BGP OPEN: Thiết lập kết nối TCP cổng 179 Trao đổi thông tin đường đi đang có Trao đổi thông điệp UPDATE, NOTIFICATION AS1 AS2 Duy trì kết nối BGP session 153 152 153 76 Còn rất nhiều vấn đề về tầng mạng  Giao thức IPv6  Mobile IP  Định tuyến trên mạng cáp quang  Định tuyến trên mạng không dây  Broadcast và Multicast  An toàn bảo mật thông tin tầng mạng  An toàn bảo mật cho các giao thức định tuyến... 154 Tài liệu tham khảo  Keio University  “Computer Networking: A Top Down Approach”, J.Kurose  “Computer Network”, Berkeley University 155 154 155 1Chương 5. Tầng giao vận 1 1. Tổng quan về tầng giao vận Nhắc lại kiến trúc phân tầng Hướng liên kết vs. Không liên kết UDP & TCP 2 1 2 2Nhắc lại về kiến trúc phân tầng Application (HTTP, Mail, ) Network (IP, ICMP) Datalink (Ethernet, ADSL) Physical (bits) Hỗ trợ các ứng dụng trên mạng Điều khiển truyền dữ liệu giữa các tiến trình của tầng ứng dụng Chọn đường và chuyển tiếp gói tin giữa các máy, các mạng Hỗ trợ việc truyền thông cho các thành phần kế tiếp trên cùng 1 mạng Truyền và nhận dòng bit trên đường truyền vật lý Transport (UDP, TCP) 3 Tổng quan về tầng giao vận (1)  Cung cấp phương tiện truyền giữa các ứng dụng cuối  Bên gửi:  Nhận dữ liệu từ ứng dụng  Đặt dữ liệu vào các gói tin và chuyển cho tầng mạng  Nếu dữ liệu quá lớn, nó sẽ được chia làm nhiều phần và đặt vào nhiều đoạn tin khác nhau  Bên nhận:  Nhận các đoạn tin từ tầng mạng  Tập hợp dữ liệu và chuyển lên cho ứng dụng application transport network data link physical application transport network data link physical 4 3 4 3Tổng quan về tầng giao vận (2)  Được cài đặt trên các hệ thống cuối  Không cài đặt trên các routers, switches  Hai dạng dịch vụ giao vận  Tin cậy, hướng liên kết, e.g TCP  Không tin cậy, không liên kết, e.g. UDP  Đơn vị truyền: datagram (UDP), segment (TCP) application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical 5 Tại sao lại cần 2 loại dịch vụ?  Các yêu cầu đến từ tầng ứng dụng là đa dạng  Các ứng dụng cần dịch vụ với 100% độ tin cậy như mail, web  Sử dụng dịch vụ của TCP  Các ứng dụng cần chuyển dữ liệu nhanh, có khả năng chịu lỗi, e.g. VoIP, Video Streaming  Sử dụng dịch vụ của UDP 6 5 6 4Ứng dụng và dịch vụ giao vận Ứng dụng e-mail remote terminal access Web file transfer streaming multimedia Internet telephony Giao thức ứng dụng SMTP Telnet HTTP FTP giao thức riêng (e.g. RealNetworks) giao thức riêng (e.g., Vonage,Dialpad) Giao thức giao vận TCP TCP TCP TCP TCP or UDP thường là UDP 7 Dồn kênh/phân kênh - Mux/Demux process socket Sử dụng thông tin trên tiêu đề gói tin để gửi dữ liệu tới đúng socket Nhận: Phân kênhNhận dữ liệu từ các tiến trình tầng ứng dụng khác nhau (qua socket), đóng gói theo giao thức tầng giao vận và gửi trên liên kết mạng Gửi: Dồn kênh transport application physical link network P2P1 transport application physical link network P4 transport application physical link network P3 8 7 8 5Mux/Demux hoạt động ntn?  Số hiệu cổng dịch vụ/ứng dụng (Port Number): Một số 16 bit là định danh của tiến trình ứng dụng  Nút mạng nhận gói tin với các địa chỉ:  Địa chỉ IP nguồn  Địa chỉ IP đích  Số hiệu cổng nguồn  Số hiệu cổng đích  Địa chỉ IP và số hiệu cổng được sử dụng để xác định socket nhận dữ liệu source port # dest port # 32 bits segment of application data (payload) other header fields source IP address destination IP address (other header fields) N etw o rk Tran sp o rt A p p licatio n 9 Socket là gì?  Socket là đối tượng dịch vụ mà tầng giao vận cung cấp cho tiến trình ứng dụng.  Tiến trình ứng dụng sử dụng dịch vụ tầng giao vận qua socket 10 9 10 62.UDP (User Datagram Protocol) Tổng quan Khuôn dạng gói tin 11 Đặc điểm chung  Giao thức hướng không kết nối (connectionless)  Không sử dụng báo nhận:  Phía nguồn gửi dữ liệu nhanh nhất, nhiều nhất có thể  Truyền tin “best-effort”: chỉ gửi 1 lần, không phát lại  Vì sao cần UDP?  Không cần thiết lập liên kết (giảm độ trễ)  Đơn giản: Không cần lưu lại trạng thái liên kết ở bên gửi và bên nhận  Phần đầu đoạn tin nhỏ  UDP có những chức năng cơ bản gì?  Dồn kênh/phân kênh  Phát hiện lỗi bit bằng checksum 12 11 12 7Khuôn dạng bức tin (datagram) source port # dest port # 32 bits Application data (message) Khuôn dạng đơn vị dữ liệu của UDP length checksum Độ dài toàn bộ bức tin tính theo byte  UDP sử dụng đơn vị dữ liệu gọi là – datagram (bức tin) 13 Các vấn đề của UDP  Không có kiểm soát tắc nghẽn  Làm Internet bị quá tải  Không bảo đảm được độ tin cậy  Các ứng dụng phải cài đặt cơ chế tự kiểm soát độ tin cậy  Việc phát triển ứng dụng sẽ phức tạp hơn 14 13 14 83. TCP (Transmission Control Protocol) 15 3.1.Khái niệm về truyền thông tin cậy 16 15 16 9Kênh có lỗi bit, không bị mất tin  Truyền thông tin cậy: đảm bảo dữ liệu được truyền đi thành công  Phát hiện lỗi?  Checksum  Làm thế nào để báo cho bên gửi?  ACK (acknowledgements): gói tin được nhận thành công  NAK (negative acknowledgements): gói tin bị lỗi  Phản ứng của bên gửi?  Truyền lại nếu là NAK 17 Hoạt động Time Time Sender Receiver send pkt pkt is corrupted send NAK rcv ACK send next packet rcv NAK resend pkt pkt is OK send ACK stop-and-wait 18 17 18 10 Lỗi ACK/NAK  Cần truyền lại  Xử lý việc lặp gói tin ntn?  Thêm Seq.# Time Time Sender Receiver send pkt0 pkt1 is error send NAK rcv ACK send pkt1 rcv NAK! resend pkt1 pkt0 is OK send ACK rcv pkt1 OK, 19 Giải pháp không dùng NAK Time Time Sender Receiver send pkt0 pkt1 is OK send ACK1 rcv ACK0 send pkt1 rcv ACK1 send pkt2 pkt0 is OK send ACK0 pkt2 is corrupted send ACK1rcv ACK1 resend pkt2 Gói tin nhận được lỗi  gửi lại ACK trước đó Nhận được ACK với Seq# không đổi  gửi lại gói tin 20 19 20 11 Kênh có lỗi bit và mất gói tin  Dữ liệu và ACK có thể bị mất  Nếu không nhận được ACK?  Truyền lại như thế nào?  Timeout!  Thời gian chờ là bao lâu?  Ít nhất là 1 RTT (Round Trip Time)  Mỗi gói tin gửi đi cần 1 timer  Nếu gói tin vẫn đến đích và ACK bị mất?  Dùng số hiệu gói tin 21 Minh họa sender receiver rcv pkt1 rcv pkt2 send ack0 send ack1 send ack2 rcv ack0 send pkt2 send pkt1 rcv ack1 send pkt0 rcv pkt0 pkt0 pkt2 pkt1 ack1 ack0 ack2 (a) Không có mất gói tin sender receiver rcv pkt1 rcv pkt2 send ack0 send ack1 send ack2 rcv ack0 send pkt2 send pkt1 rcv ack1 send pkt0 rcv pkt0 pkt0 pkt2 ack1 ack0 ack2 (b) mất gói tin gửi đi pkt1 X loss pkt1 timeout resend pkt1 22 21 22 12 Minh họa rcv pkt1 send ack1 (detect duplicate) pkt1 sender receiver rcv pkt1 rcv pkt2 send ack0 send ack1 send ack2 rcv ack0 send pkt2 send pkt1 rcv ack1 send pkt0 rcv pkt0 pkt0 pkt2 ack1 ack0 ack2 (c) mất ACK báo nhận ack1 X loss pkt1 timeout resend pkt1 rcv pkt1 send ack1 (detect duplicate) pkt1 sender receiver rcv pkt1 send ack0 rcv ack0 send pkt1 send pkt0 rcv pkt0 pkt0 ack0 (d) timeout sớm/ACK tới trễ pkt1 timeout resend pkt1 ack1 send ack1 send pkt2 rcv ack1 pkt2 ack1 ack2 send pkt2 rcv ack1 pkt2 rcv pkt2 send ack2ack2 rcv pkt2 send ack2 (detect duplicate) Hiểu nhầm đây là ack cho gói tin pkt1 gửi lại trước đó Hiểu nhầm đây là ack báo lỗi pkt2 23 Hiệu năng của stop-and-wait bit đầu tiên được gửi đi t = 0 sender time RTT bit cuối cùng được gửi đi t = L / R Nhận được ACK, gửi gói tiếp theo t = RTT + L / R time L: Kích thước gói tin R: Băng thông RTT: Round trip time = / + / receiver bit đầu tiên tới đích bit cuối cùng tới đích 24 23 24 13 Ví dụ  L = 1000 byte  R = 8 Mbps  RTT = 50ms  H = ?  L/R = 1000 x 8 / 8 x 106 = 1 ms  H = 1/(50 + 1) ~ 2% 25 Pipeline  Gửi liên tục một lượng hữu hạn các gói tin mà không cần chờ ACK  Số thứ tự các gói tin phải tăng dần  Dữ liệu gửi đi chờ sẵn ở bộ đệm gửi  Dữ liệu tới đích chờ ở bộ đệm nhận 26 25 26 14 Hiệu năng của pipeline sender receiver RTT bit cuối cùng được gửi đi L / R Nhận được ACK, gửi gói tiếp theo RTT + L / R time time L: Kích thước gói tin R: Băng thông RTT: Round trip time n: Số gói tin gửi liên tục = ∗ / + / bit đầu tiên được gửi đi 0 các gói tin tới đích 27 Ví dụ  L = 1000 byte  R = 8 Mbps  RTT = 50ms  n = 20  H = ?  L/R = 1000 x 8 / 8 x 106 = 1 ms  H = 20 x 1/(50 + 1) ~ 40%  Liệu có thể tăng n để H > 100% 28 27 28 15 Go-back-N Bên gửi • Chỉ gửi gói tin trong cửa sổ. Chỉ dùng 1 bộ đếm (timer) cho gói tin đầu tiên trong cửa sổ • Nếu nhận được ACKi, dịch cửa sổ sang vị trí (i+1). Đặt lại timer • Nếu timeout cho gói tin pkti gửi lại tất cả gói tin trong cửa sổ Bên nhận • Gửi ACKi cho gói tin pkti đã nhận được theo thứ tự • Gói tin đến không theo thứ tự: hủy gói tin và gửi lại ACK của gói tin gần nhất còn đúng thứ tự đã gửi, đã nhận ACK đã gửi, chưa nhận ACK đang gửi chưa gửi #Seq Cửa sổ gửi kích thước Swnd 29 Go-back-N send pkt0 send pkt1 send pkt2 send pkt3 (wait) sender receiver receive pkt0, send ack0 receive pkt1, send ack1 receive pkt3, discard, (re)send ack1rcv ack0, send pkt4 rcv ack1, send pkt5 pkt 2 timeout send pkt2 send pkt3 send pkt4 send pkt5 Xloss receive pkt4, discard, (re)send ack1 receive pkt5, discard, (re)send ack1 rcv pkt2, deliver, send ack2 rcv pkt3, deliver, send ack3 rcv pkt4, deliver, send ack4 rcv pkt5, deliver, send ack5 ignore duplicate ACK 0 1 2 3 4 5 6 7 8 sender window (N=4) 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 30 29 30 16 Selective Repeat  Gửi: chỉ gửi gói tin trong cửa sổ gửi  Nhận: chỉ nhận gói tin trong cửa sổ nhận  Sử dụng bộ đệm để lưu tạm thời các gói tin tới chưa đúng thứ tự đã gửi, đã nhận ACK đã gửi, chưa nhận ACK đang gửi chưa gửi #Seq Cửa sổ gửi kích thước Swnd #Seq Cửa sổ nhận kích thước Rwnd đã nhận đúng thứ tự chưa nhận đã nhận, chưa đúng thứ tự 31 Selective Repeat Bên gửi  Chỉ gửi gói tin trong cửa sổ gửi  Dùng 1 timer cho mỗi gói tin trong cửa sổ  Nếu timeout cho gói tin pkti chỉ gửi lại pkti  Nhận được ACKi:  Đánh dấu pkti đã có ACK  Nếu i là giá trị nhỏ nhất trong các gói tin chưa nhận ACK, dịch cửa sổ sang vị trí gói tin tiếp theo chưa nhận ACK Bên nhận  Chỉ nhận gói tin trong cửa sổ nhận  Nhận pkti:  Gửi lại ACKi  Không đúng thứ tự: đưa vào bộ đệm  Đúng thứ tự: chuyển cho tầng ứng dụng cùng với các gói tin trong bộ đệm đã trở thành đúng thứ tự sau khi nhận pkti 32 31 32 17 Selective Repeat Điều gì xảy ra nếu kích thước cửa số lớn hơn ½ giá trị Seq# lớn nhất? send pkt0 send pkt1 send pkt2 send pkt3 (wait) sender receiver receive pkt0, send ack0 receive pkt1, send ack1 receive pkt3, buffer, send ack3rcv ack0, send pkt4 rcv ack1, send pkt5 pkt 2 timeout send pkt2 Xloss receive pkt4, buffer, send ack4 receive pkt5, buffer, send ack5 rcv pkt2; deliver pkt2, pkt3, pkt4, pkt5; send ack2 record ack3 arrived 0 1 2 3 4 5 6 7 8 sender window (N=4) 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 record ack4 arrived record ack5 arrived Điều gì xảy ra nếu ack2 tới bên gửi 33 Kích thước cửa sổ quá lớn 34 receiversender 0 1 2 3 0 1 2 0 1 2 3 0 1 2 0 1 2 3 0 1 2 pkt0 pkt1 pkt2 0 1 2 3 0 1 2 pkt0 0 1 2 3 0 1 2 0 1 2 3 0 1 2 0 1 2 3 0 1 2 X will accept packet with seq number 0 0 1 2 3 0 1 2 pkt3 (a) pkt0 là gói tin mới 0 1 2 3 0 1 2 0 1 2 3 0 1 2 0 1 2 3 0 1 2 pkt0 pkt1 pkt2 0 1 2 3 0 1 2 pkt0 timeout retransmit pkt0 0 1 2 3 0 1 2 0 1 2 3 0 1 2 0 1 2 3 0 1 2X X X will accept packet with seq number 0 (b) pkt0 là gói tin bị lặp receiversender  Giả sử Seq# = {0, 1 , 2 ,3}  Kích thước cửa sổ: 3  Phía nhận không phân biệt được 2 trường hợp  Trong trường hợp b, gói tin pkt0 gửi lại được bên nhận coi như gói tin mới, đưa vào bộ đệm chờ xử lý 33 34 18 3.2. Hoạt động của TCP Cấu trúc đoạn tin TCP Quản lý liên kết Kiểm soát luồng Kiểm soát tắc nghẽn 35 Tổng quan về TCP  Giao thức hướng liên kết  Bắt tay ba bước  Giao thức truyền dữ liệu theo dòng byte (byte stream), tin cậy  Sử dụng vùng đệm  Truyền theo kiểu pipeline  Tăng hiệu quả  Kiểm soát luồng  Bên gửi không làm quá tải bên nhận  Kiểm soát tắc nghẽn  Việc truyền dữ liệu không nên làm tắc nghẽn mạng 36 35 36 19 Khuôn dạng đoạn tin - TCP segment source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pointerchecksum FSRPAU head len not used Options (variable length) URG: Dữ liệu khẩn ACK: ACK # PSH: Chuyển dữ liệu ngay RST, SYN, FIN: Ký hiệu cho các gói tin đặc biệt -Số lượng bytes có thế nhận - Điều khiển luồng - Dùng để truyền dữ liệu tin cậy - Tính theo bytes 37 Thông số của liên kết TCP  Mỗi một liên kết TCP giữa hai tiến trình được xác định bởi bộ 4 thông số (4-tuple):  Địa chỉ IP nguồn  Địa chỉ IP đích  Số hiệu cổng nguồn  Số hiệu cổng đích Tầng mạng Tầng giao vận 38 37 38 20 TCP cung cấp dịch vụ tin cậy ntn?  Kiểm soát lỗi dữ liệu: checksum  Kiểm soát mất gói tin: phát lại khi có time-out  Kiểm soát dữ liệu đã được nhận chưa:  Seq. #  Ack  Chu trình làm việc của TCP:  Thiết lập liên kết  Bắt tay ba bước  Truyền/nhận dữ liệu: có thể thực hiện đồng thời(duplex) trên liên kết  Đóng liên kết Cơ chế báo nhận 39 Thiết lập liên kết TCP : Giao thức bắt tay 3 bước  Bước 1: A gửi SYN cho B  chỉ ra giá trị khởi tạo seq # của A  không có dữ liệu  Bước 2: B nhận SYN, trả lời bằng SYN/ACK  B khởi tạo vùng đệm  chỉ ra giá trị khởi tạo seq. # của B  Bước 3: A nhận SYNACK, trả lời ACK, có thể kèm theo dữ liệu A B Tại sao không dùng giao thức bắt tay 2 bước 40 esta- blished esta- blished 39 40 21 Nếu chỉ dùng 2 bước 41 A Time out Đóng kết nối Bỏ qua Kết nối thiết lập 1 nửa Cơ chế báo nhận trong TCP sequence numbers: Thứ tự byte đầu tiên trên payload của gói tin (segment) acknowledgements: Thứ tự của byte muốn nhận source port # dest port # sequence number acknowledgement number checksum rwnd urg pointer Gói tin báo nhận A đã gửi đã nhận ACK đã gửi chưa nhận ACK đang gửi chưa gửi Kích thước cửa sổ N Chuỗi Seq# ở phía gửi source port # dest port # sequence number acknowledgement number checksum rwnd urg pointer Gói tin gửi đi ở phía gửi 42 41 42 22 Cơ chế báo nhận trong TCP Seq. #:  Số hiệu của byte đầu tiên của đoạn tin trong dòng dữ liệu ACK:  Số hiệu byte đầu tiên mong muốn nhận từ đối tác Host A Host B User types ‘computer’ host ACKs receipt Gửi ACK báo nhận time 43 User types ‘network’ Cơ chế báo nhận trong TCP 44 Host A Host B User types ‘computer’ host ACKs receipt User types ‘network’ 43 44 23 Đóng liên kết 45 FIN_WAIT_2 CLOSE_WAIT FIN, seq=y ACK, ACKnum=y+1 ACK, ACKnum=x+1 đợi nhận FIN từ server có thể tiếp tục gửi dữ liệu ngừng gửi dữ liệu LAST_ACK CLOSED TIMED_WAIT đợi trong 2 x thời gian gửi MSS CLOSED FIN_WAIT_1 FIN, seq=xkhông gửi tiếp nhưng vẫn nhận dữ liệu close(socket) A state B state ESTABESTAB A B Chu trình sống của TCP (đơn giản hóa) SYN_SENT FIN_WAIT_1 FIN_WAIT_2 ESTABLISHED Receive ACK Send nothing Receive SYN/ACK Send ACK CLOSED TIME_WAIT CLOSED LISTENLAST_ACK SYN_RCVDCLOSE_WAIT ESTABLISHED Receive SYN Send SYN/ACK Receive ACK Send nothing Receive FIN Send ACK Send FIN Receive ACK Send nothing Server application Creates a listen socket Send SYN Send FIN Wait Receive FIN Send ACK Client application Initiates close connection 46 45 46 24 Pipeline trong TCP Go-back-N hay Selective Repeat?  Bên gửi:  Nếu nhận được ACK# = i thì coi tất cả gói tin trước đó đã tới đích (ngay cả khi chưa nhận được các ACK# < i). Dịch cửa sổ sang vị trí i  Nếu có timeout của gói tin Seq# = i chỉ gửi lại gói tin đó  Bên nhận:  Đưa vào bộ đệm các gói tin không đúng thứ tự và gửi ACK  thuật toán lai 47 TCP: Hoạt động của bên gửi Nhận dữ liệu từ tầng ứng dụng  Đóng gói dữ liệu vào gói tin TCP với giá trị Seq# tương ứng  Tính toán và thiết lập giá trị TimeOutInterval cho bộ đếm thời gian (timer)  Gửi gói tin TCP xuống tầng mạng và khởi động bộ đếm cho gói đầu tiên trong cửa sổ timeout:  Gửi lại gói tin bị timeout  Khởi động lại bộ đếm Nhận ACK# = i  Nếu là ACK cho gói tin nằm bên trái cửa sổ  bỏ qua  Ngược lại, trượt cửa sổ sang vị trí i  Khởi động timer cho gói tin kế tiếp đang chờ ACK 48 47 48 25 Tính toán timeout(Đọc thêm)  Dựa trên giá trị RTT (> 1 RTT)  Nhưng RTT thay đổi theo từng lượt gửi  Timeout quá dài: hiệu năng giảm  Timeout quá ngắn: không đủ thời gian để ACK báo về  Ước lượng RTT EstimatedRTTi = *EstimatedRTTi-1 + (1-)*SampleRTTi-1  EstimatedRTT: RTT ước lượng  SampleRTT: RTT đo được  0 <  < 1: Jacobson đề nghị  = 0.875 49 Tính toán timeout  Độ lệch: DevRTTi = (1-)*DevRTTi-1 + *|SampleRTTi-1 - EstimatedRTTi-1|  Jacobson đề nghị  = 0.25  Timeout: TimeOutIntervali = EstimatedRTTi + 4*DevRTTi 50 49 50 26 Ước lượng RTT – Ví dụ Packet# Estimated RTT(ms) DevRTT (ms) TimeoutInt erval(ms) SampleR TT(ms) 1 40 20 120 80 2 45 25 145 15 3 4 5 ? 51 Phát lại như thế nào? 52 mất ACK Host BHost A Seq=92, 8 bytes of data ACK=100 Seq=92, 8 bytes of data Xtim e o u t ACK=100 timeout quá ngắn Host BHost A Seq=92, 8 bytes of data ACK=100 Seq=92, 8 bytes of data ti m e o u t ACK=120 Seq=100, 20 bytes of data ACK=120 ti m e o u t ti m e o u t 51 52 27 Phát lại như thế nào? (tiếp) 53 X Host BHost A Seq=92, 8 bytes of data ACK=100 Seq=120, 15 bytes of data ti m e o u t Seq=100, 20 bytes of data ACK=120 ACK tích lũy Hoạt động của bên nhận  Nhận 1 gói tin với Seq# = i đúng thứ tự, bộ đệm trống  Nhận 1 gói tin với Seq# = i đúng thứ tự, trong khi còn ACK cho gói trước đó chưa gửi 54 Seq# = i, size = N Đợi 500ms, nếu không có gói tin kế tiếp ACK# = i + N Seq# = j, size = * ACK# = i + N Seq# = i, size = N ACK tích lũy (cumulative ACK) Bên nhận Bên nhận 53 54 28 Hoạt động của bên nhận  Nhận gói tin đúng thứ tự Seq = i, trong bộ đệm có gói tin không đúng thứ tự liền kề  Nhận gói tin không đúng thức tự: thực hiện cơ chế hồi phục nhanh 55 Seq# = i, size = N ACK# = i + N + M Bên nhận Seq# = i + N size = MACK tích lũy (cumulative ACK) Hồi phục nhanh  Thời gian timeout khá dài có thể làm giảm hiệu năng  Cơ chế hồi phục nhanh:  Bên nhận: Khi nhận gói tin không đúng thứ tự, gửi liên tiếp 2 gói tin lặp lại ACK# của gói tin còn đúng thứ tự trước đó  Bên gửi: Nhận được 3 ACK# liên tiếp giống nhau, gửi lại ngay gói tin mà không chờ time-out X Host BHost A Seq=92, 8 bytes of data ACK=100 ti m e o u t ACK=100 ACK=100 Seq=100, 20 bytes of data Seq=100, 20 bytes of data 56 55 56 29 3.3. Kiểm soát luồng 57 Kiểm soát luồng (1) A B A B Chậm Quá tải 58 57 58 30 Kiểm soát luồng (2)  Điều khiển lượng dữ liệu được gửi đi  Bảo đảm rằng hiệu quả là tốt  Không làm quá tải các bên  Các bên sẽ có cửa sổ kiểm soát  Rwnd: Cửa sổ nhận  Cwnd: Cửa sổ kiểm soát tắc nghẽn  Lượng dữ liệu gửi đi phải nhỏ hơn min(Rwnd, Cwnd) 59 Kiểm soát luồng trong TCP  Kích thước vùng đệm trống = Rwnd = RcvBuffer-[LastByteRcvd - LastByteRead] 60 Receive Window: Kích thước dữ liệu tối đa mà phía nhận có thể xử lý 59 60 31 Trao đổi thông tin về Rwnd A B  Bên nhận sẽ báo cho bên gửi biết Rwnd trong các đoạn tin  Bên gửi đặt kích thước cửa sổ gửi theo Rwnd 61 Tính công bằng trong TCP  Nếu có K kết nối TCP chia sẻ đường truyền có băng thông R thì mỗi kết nối có tốc độ truyền trung bình là R/K 62 TCP connection 1 bottleneck router capacity R TCP connection 2 61 62 32 3.4. Điều khiển tắc nghẽn trong TCP 63 Tổng quan về tắc nghẽn  Khi nào tắc nghẽn xảy ra ?  Quá nhiều cặp gửi-nhận trên mạng  Truyền quá nhiều làm cho mạng quá tải  Hậu quả của việc nghẽn mạng  Mất gói tin  Thông lượng giảm, độ trễ tăng  Tình trạng của mạng sẽ trở nên tồi tệ hơn. Congestion occur 64 63 64 33 Nguyên lý kiểm soát tắc nghẽn  Slow-start  Tăng tốc độ theo hàm số mũ  Tiếp tục tăng đến một ngưỡng nào đó  Tránh tắc nghẽn  Tăng dẫn tốc độ theo hàm tuyến tính cho đến khi phát hiện tắc nghẽn  Phát hiện tắc nghẽn  Gói tin bị mất 2 4 6 8 10 12 14 16 18 20 Slow-start ssthresh =16 cwnd (MSS = Maximum Segment Size) 65 Xảy ra tắc nghẽn  Khi có timeout của bên gửi  TCP đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của cwnd  TCP đặt cwnd về 1 MSS  TCP chuyển về slow start  Hồi phục nhanh:  Nút nhận: nhận được 1 gói tin không đúng thứ tự thì gửi liên tiếp 3 ACK giống nhau.  Nút gửi: nhận được 3 ACK giống nhau  TCP đặt ngưỡng ssthresh xuống còn một nửa giá trị hiện tại của cwnd  TCP đặt cwnd về giá trị hiện tại của ngưỡng mới  TCP chuyển trạng thái “congestion avoidance”(tránh tắc nghẽn) 66 65 66 34 Kiểm soát tắc nghẽn – minh họa 2 4 6 8 10 12 14 16 18 20 22 Timeout 3 ACKs SS SS AI AI AI Threshold=16 Threshold=10 Threshold=6 Threshold is set to half of cwnd (20) And slow start starts Threshold is set to half of cwnd (12) And additive increase starts cwnd Step 67 Ví dụ  Giả sử phía gửi đang có Cwnd = 14000 byte, ngưỡng ssthresh = 16800 byte, 1MSS = 1400 byte Phía gửi có thể gửi một lượng dữ liệu tối đa là bao nhiêu nếu: 1. Nhận được một gói tin ACK báo thành công có Rwnd = 8600 byte: Cwnd < ssthresh: đang ở trạng thái Slow Start Nhận được ACK: Cwnd = min (2*Cwnd, ssthresh) = 16800 Lượng dữ liệu gửi tối đa = min (Rwnd, Cwnd) = 8600 byte 68 67 68 35 Ví dụ  Giả sử phía gửi đang có Cwnd = 14000 byte, ngưỡng ssthresh = 16800 byte, 1MSS = 1400 byte  Phía gửi có thể gửi một lượng dữ liệu tối đa là bao nhiêu nếu: (2) Nhận được một gói tin ACK báo thành công có Rwnd = 28000 byte Cwnd < ssthresh: đang ở trạng thái Slow Start Nhận được ACK: Cwnd = min (2*Cwnd, ssthresh) = 16800 Lượng dữ liệu gửi tối đa = min (Rwnd, Cwnd) = 16800 byte 69 Ví dụ  Giả sử phía gửi đang có Cwnd = 14000 byte, ngưỡng ssthresh = 16800 byte, 1MSS = 1400 byte  Phía gửi có thể gửi một lượng dữ liệu tối đa là bao nhiêu nếu: (3) Nhận được một 3 gói tin ACK giống nhau có Rwnd = 28000 byte: ssthresh = Cwnd/2 = 14000 / 2 = 7000 Cwnd = ssthresh = 7000  chuyển sang tránh tắc nghẽn Lượng dữ liệu tối đa có thể gửi: min(Rwnd, Cwnd) = min (28000, 7000) = 7000 byte 70 69 70 36 Ví dụ  Giả sử phía gửi đang có Cwnd = 14000 byte, ngưỡng ssthresh = 16800 byte, 1MSS = 1400 byte  Phía gửi có thể gửi một lượng dữ liệu tối đa là bao nhiêu nếu: (4) Xảy ra time-out Ssthresh = Cwnd /2 = 7000 Cwnd = 1 MSS = 1400 byte  bắt đầu ở Slow Start Lượng dữ liệu gửi đi tối đa: 1400 byte. 71 Tổng kết  Có hai dạng giao thức giao vận  UDP và TCP  Best effort vs. reliable transport protocol  Các cơ chế bảo đảm độ tin cậy  Báo nhận  Truyền lại  Kiểm soát luồng và kiểm soát tắc nghẽn 72 71 72 37 Tài liệu tham khảo  Keio University  “Computer Networking: A Top Down Approach”, J.Kurose  “Computer Network”, Berkeley University 73 73 1Chương 6. Tầng ứng dụng 1 1. Tổng quan về tầng ứng dụng 2 1 2 2Nhắc lại về kiến trúc phân tầng Application (HTTP, Mail, ) Transport (UDP, TCP ) Network (IP, ICMP) Datalink (Ethernet, ADSL) Physical (bits)  Cung cấp các dịch vụ trên mạng.  Trong mô hình TCP/IP không có 2 tầng trình diễn và tầng phiên, nhưng các giao thức tầng ứng dụng phải cung cấp các chức năng của 2 tầng này (biểu diễn dữ liệu, điều khiển phiên) 3 Ứng dụng mạng  Hoạt động trên các hệ thống đầu cuối (end system)  Cài đặt giao thức ứng dụng để cung cấp dịch vụ  Gồm có 2 tiến trình giao tiếp với nhau qua môi trường mạng:  Client: cung cấp giao diện NSD, gửi thông điệp yêu cầu dịch vụ  Server: cung cấp dịch vụ, trả thông điệp đáp ứng  Ví dụ: Web  Web browser (trình duyệt Web): Chrome, Firefox  Web server: Apache, Tomcat application transport network data link physical application transport network data link physical application transport network data link physical 4 3 4 3Giao tiếp giữa các tiến trình ứng dụng  Socket: điểm truy cập dịch vụ của tầng giao vận  Các tiến trình ứng dụng sử dụng socket gọi dịch vụ của tầng giao vận để trao đổi thông điệp  Định danh cho tiến trình bởi: Địa chỉ IP, Số hiệu cổng  Ví dụ: tiến trình web server trên máy chủ của SoICT có định danh 202.191.56.65:80 Network controlled by OS controlled by app developer transport application physical link network process transport application physical link network process socket 5 Giao tiếp giữa các tiến trình  Tiến trình client: gửi yêu cầu  Tiến trình server: trả lời  Mô hình điển hình: 1 server – nhiều client  Client cần biết địa chỉ của server: địa chỉ IP, số hiệu cổng 6 request response handle request wait wait wait for result handles response client server 5 6 4Các mô hình ứng dụng  Khách-chủ (Client/Server)  Ngang hàng (P2P: Peer-to-peer)  Mô hình lai 7 Mô hình khách chủ  Khách  Gửi yêu cầu truy cập dịch vụ đến máy chủ  Về nguyên tắc, không liên lạc trực tiếp với các máy khách khác  Chủ  Thường xuyên online để chờ y/c đến từ máy trạm  Có thể có máy chủ dự phòng để nâng cao hiệu năng, phòng sự cố  e.g. Web, Mail, client client client client Server 8 7 8 5Mô hình ngang hàng thuần túy  Không có máy chủ trung tâm  Các máy có vai trò ngang nhau  Hai máy bất kỳ có thể liên lạc trực tiếp với nhau  Không cần vào mạng thường xuyên  E.g. Gnutella PeerPeer Peer Peer Peer Peer 9 Mô hình lai  Một máy chủ trung tâm để quản lý NSD, thông tin tìm kiếm  Các máy khách sẽ giao tiếp trực tiếp với nhau sau khi đăng nhập  E.g. Skype  Máy chủ Skype quản lý các phiên đăng nhập, mật khẩu  Sau khi kết nối, các máy sẽ gọi VoIP trực tiếp cho nhau Server Client Client Client Client-Server Comm. P2P Comm. 10 9 10 62. Tên miền và dịch vụ DNS 11 Giới thiệu chung  Tên miền: định danh trên tầng ứng dụng cho các nút mạng  Trên Internet được quản lý tập trung  Quốc tế: ICANN  Việt Nam: VNNIC  DNS(Domain Name System): hệ thống tên miền  Không gian thông tin tên miền  Gồm các máy chủ quản lý thông tin tên miền và cung cấp dịch vụ DNS  Vấn đề phân giải tên miền sang địa chỉ IP  Người sử dụng dùng tên miền để truy cập dịch vụ  Máy tính và các thiết bị mạng không sử dụng tên miền mà dùng địa chỉ IP khi trao đổi dữ liệu  Làm thế nào để chuyển đổi tên miền sang địa chỉ IP? 12 11 12 7Chuyển đổi địa chỉ và ví dụ NSD Tôi muốn vào địa chỉ www.soict.hust.edu.vn Máy chủ tên miền Mời truy cập vào 202.191.56.65 Máy chủ web 202.191.56.65 Cần có chuyển đổi địa chỉ • Máy tính dùng địa chỉ IP • NSD dùng tên miền Bạn cũng có thể nhập địa chỉ trực tiếp 13 Quy tắc đặt tên miền  Tên miền đầy đủ(FQDN): Kết thúc bằng dấu ‘.’ (tên miền gốc). VD: hust.edu.vn.  Tên miền rút gọn: không thể hiện tên miền gốc. VD: hust.edu.vn  Quy tắc đặt tên miền:  Độ dài tối đa : 255 ký tự  Độ dài tối đa của label : 63 ký tự  Label phải bắt đầu bằng số hoặc chữ, chỉ chứa số, chữ, “-“, “.”  Phân cấp tên miền : gốc, cấp 1, cấp 2 14 13 14 8Phân cấp tên miền 15 . .vn .com .net root Tên miền cấp 1 .edu .com.fpt .google .mail .drive Tên miền cấp 2 Tên miền cấp 3 Hệ thống DNS  Không gian tên miền  Kiến trúc : hình cây  Root  Zone  Mỗi nút là một tập hợp các bản ghi mô tả tên miền tương ứng với nút đó.  SOA  NS  A  PTR  CNAME 16 15 16 9Hệ thống máy chủ DNS  Máy chủ tên miền gốc (Root server)  Trả lời truy vấn cho các máy chủ cục bộ  Quản lý các zone và phân quyền quản lý cho máy chủ cấp dưới  Có 13 hệ thống máy chủ gốc trên mạng Internet ( servers.org) 17 Hệ thống máy chủ DNS (tiếp)  Máy chủ tên miền cấp 1 (Top Level Domain)  Quản lý tên miền cấp 1  Máy chủ được ủy quyền (Authoritative DNS servers)  Quản lý tên miền cấp dưới  Máy chủ của các tổ chức: của ISP  Không nằm trong phân cấp của DNS  Máy chủ cục bộ: dành cho mạng nội bộ của cơ quan tổ chức  Không nằm trong phân cấp của DNS 18 17 18 10 Phân giải tên miền  Tự phân giải  File HOST : C:\WINDOWS\system32\drivers\etc\  Cache  Dịch vụ phân giải tên miền DNS: client/server  UDP, Port 53  Phân giải đệ quy (Recursive Query)  Phân giải tương tác (Interactive Query) 19 Thông điệp DNS  DNS Query và DNS Reply  Chung khuôn dạng  QUESTION: tên miền cần truy vấn  Số lượng: #Question  ANSWER: thông tin tên miền tìm kiếm được  Số lượng: #Answer RRs  AUTHORITY: địa chỉ server trả lời truy vấn  ADDITIONAL: thông tin phân giải tên miền cho các địa chỉ khác SRC = 53 DST = 53 checksum length Identification Flags #Question #Answer RRs #Authority RRs #Additional RRs QUESTION ANSWER AUTHORITY ADDITIONAL 20 19 20 11 Ví dụ: dig linux.com 21 ; DiG 9.9.2-P1 linux.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;linux.com. IN A ;; ANSWER SECTION: linux.com. 1786 IN A 140.211.167.51 linux.com. 1786 IN A 140.211.167.50 ;; AUTHORITY SECTION: linux.com. 86386 IN NS ns1.linux-foundation.org. linux.com. 86386 IN NS ns2.linux-foundation.org. ;; ADDITIONAL SECTION: ns1.linux-foundation.org. 261 IN A 140.211.169.10 ns2.linux-foundation.org. 262 IN A 140.211.169.11 TTL: thời gian(s) lưu giữ trả lời trong cache Ví dụ: dig linux.com 22 ; DiG 9.9.2-P1 linux.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;linux.com. IN A ;; ANSWER SECTION: linux.com. 1786 IN A 140.211.167.51 linux.com. 1786 IN A 140.211.167.50 ;; AUTHORITY SECTION: linux.com. 86386 IN NS ns1.linux-foundation.org. linux.com. 86386 IN NS ns2.linux-foundation.org. ;; ADDITIONAL SECTION: ns1.linux-foundation.org. 261 IN A 140.211.169.10 ns2.linux-foundation.org. 262 IN A 140.211.169.11 Tên các máy chủ DNS server trả lời truy vấn. Nếu phần ANSWER rỗng, DNS Resolver gửi truy vấn tới các máy chủ này 21 22 12 Ví dụ: dig linux.com 23 ; DiG 9.9.2-P1 linux.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21655 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: ;linux.com. IN A ;; ANSWER SECTION: linux.com. 1786 IN A 140.211.167.51 linux.com. 1786 IN A 140.211.167.50 ;; AUTHORITY SECTION: linux.com. 86386 IN NS ns1.linux-foundation.org. linux.com. 86386 IN NS ns2.linux-foundation.org. ;; ADDITIONAL SECTION: ns1.linux-foundation.org. 261 IN A 140.211.169.10 ns2.linux-foundation.org. 262 IN A 140.211.169.11 Địa chỉ IP của các máy chủ trả lời truy vấn. Thông tin này được lưu vào cache Giờ nghỉ giải lao(Đến 14h15) 24 23 24 13 Phân giải tương tác  Cơ chế mặc định trên các máy chủ DNS root server TLD server Authoritative DNS server soict.hust.edu.vn soict.hust.edu.vn dns.vn dns.hust.edu.vn Hỏi dns.hust.edu.vn202.191.56.65 Tải đặt lên máy chủ tên miền gốc rất lớn. Thực tế máy chủ DNS cục bộ thường đã biết các máy chủ TLD (cơ chế cache). Default Server (DNS Resolver) 25 Phân giải đệ quy  Tùy chọn mở rộng Root server TLD server Authoritative DNS server soict.hust.edu.vn soict.hust.edu.vn dns.vn dns.hust.edu.vn 202.191.56.65 202.191.56.65 soict.hust.edu.vn 202.191.56.65 Tải đặt lên các máy chủ cấp trên rất lớn. Thực tế máy chủ tên miền gốc và máy chủ cấp 1 không thực hiện phân giải đệ quy Default server 26 25 26 14 3. HTTP và WWW 27 HTTP và Web  Internet trước thập kỷ 1990s:  Hầu như chỉ sử dụng hạn chế trong cơ quan chính phủ, phòng nghiên cứu...  Các dịch vụ email, FTP không phù hợp cho chia sẻ thông tin đại chúng  Không có cơ chế hiệu quả để liên kết các tài nguyên thông tin nằm rải rác trên Internet  Năm 1990, Tim Berners-Lee giới thiệu World Wide Web:  Trao đổi thông tin dưới dạng siêu văn bản (hypertext) sử dụng ngôn ngữ HTML (Hypertext Markup Language)  Các đối tượng không cần đóng gói “tất cả trong một” như trên các văn bản trước đó  Siêu văn bản chỉ chứa chứa liên kết (hypertext) tới các đối tượng khác (định vị bằng URL). 28 27 28 15 Uniform Resource Locator  Định vị một tài nguyên bất kỳ trên mạng và cách thức để truy cập tài nguyên đó protocol://hostname[:port]/directory-path/resource  protocol: Giao thức (http, ftp, https, smtp, rtsp)  hostname: tên miền, địa chỉ IP  port: cổng ứng dụng (có thể không cần)  directory path: đường dẫn tới tài nguyên  resource: định danh của tài nguyên 29 HTTP và Web  WWW: World Wide Web  trao đổi dữ liệu siêu văn bản HTML (HyperText Markup Language) trên mạng  HTTP: HyperText Transfer Protocol  Mô hình Client/Server  Client yêu cầu truy nhập tới các trang web (chứa các đối tượng web) và hiển thị chúng trên trình duyệt  Server: Nhận yêu cầu và trả lời cho client PC running Firefox browser server running Apache Web server iphone running Safari browser 30 29 30 16 HTTP hoạt động ntn?  Server mở một TCP socket chờ yêu cầu kết nối tại cổng 80 (default)  Client khởi tạo một liên kết TCP tới server  Server chấp nhận yêu cầu, tạo liên kết  Trao đổi thông điệp HTTP (giao thức ứng dụng)  HTTP Request  HTTP Response  Đóng liên kết TCP 31 Khuôn dạng HTTP request  Mã ASCII (dễ dàng đọc được dưới dạng văn bản) request line (GET, POST, HEAD commands) header lines carriage return, line feed at start of line indicates end of header lines GET /~tungbt/index.htm HTTP/1.1\r\n Host: soict.hust.edu.vn\r\n User-Agent: Mozilla/5.0 Accept: text/html,application/xhtml+xml\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n Keep-Alive: 115\r\n Connection: keep-alive\r\n \r\n 32 31 32 17 Các phương thức trong thông điệp yêu cầu HTTP/1.0  GET  POST  HEAD  yêu cầu máy chủ loại một số đối tượng ra khỏi thông điệp trả lời HTTP/1.1  GET, POST, HEAD  PUT  tải file lên máy chủ, đường dẫn chỉ ra trong URL, file để trong body  DELETE  Xóa file chỉ ra bới đường dẫn Lưu ý: Có 2 cách để gửi tham số đến server: POST hoặc GET 33 Khuôn dạng HTTP response status line (protocol status code status phrase) header lines data, e.g., requested HTML file HTTP/1.1 200 OK\r\n Date: Thu, 31 Jul 2014 00:00:14 GMT\r\n Server: Apache/2.2.15 (CentOS)\r\n Last-Modified: Wed, 30 Jul 2014 23:59:50 GMT\r\n ETag: "17dc6-a5c-bf716880"\r\n Accept-Ranges: bytes\r\n Content-Length: 2652\r\n Connection: close\r\n Content-Type: text/html; charset=UTF-8\r\n \r\n data data data data data ... 34 33 34 18 Mã trạng thái trả lời 200 OK  request succeeded, requested object later in this message 301 Moved Permanently  requested object moved, new location specified later in this message (Location:) 400 Bad Request  request message not understood by server 404 Not Found  requested document not found on this server 505 HTTP Version Not Supported Trong dòng đầu tiên của thông điệp trả lời, ví dụ 35 Kiến trúc chung của các dịch vụ web 36 subdomain.mysite.com/folder/page?id=5 Database Queries HTML Page, JS file, CSS file, image, etc. run code 35 36 19 Hiển thị (rendering) nội dung trang web  Mô hình xử lý cơ bản tại trình duyệt: mỗi cửa sổ hoặc 1 frame:  Nhận thông điệp HTTP Response  Hiển thị:  Xử lý mã HTML, CSS, Javascripts  Gửi thông điệp HTTP Request yêu cầu các đối tượng khác(nếu có)  Bắt và xử lý sự kiện  Các sự kiện có thể xảy ra:  Sự kiện của người dùng: OnClick, OnMouseOver  Sự kiện khi hiển thị: OnLoad, OnBeforeUnload  Theo thời gian: setTimeout(), clearTimeout() 37 38 Web Browser nct.soict.hust.edu.vn GET /mmt/lab05 .html GET en.jpg GET vi.jpg lingosolutions HTTP GET 37 38 20 Các liên kết HTTP HTTP không duy trì  Chỉ một đối tượng web được gửi qua liên kết TCP  Sử dụng mặc định trong HTTP/1.0  HTTP 1.0: RFC 1945 HTTP có duy trì  Nhiều đối tượng có thể được gửi qua một liên kết TCP.  Sử dụng mặc định trong HTTP/1.1  HTTP 1.1: RFC 2068 39 Hoạt động của HTTP/1.0 Time Time Web client Web server Init TCP connection Send HTTP response: index.html Close TCP connection OK, send HTTP request Accept TCP connection Parse index.html: has 10 reference to 10 images Repeat above steps 10 times! Send images 1 Close TCP connection Accept TCP connection 11xRTT 40 39 40 21 Hoạt động của HTTP/1.1 Time Time Web client Web server Init TCP connection Send HTTP response: index.html OK, send HTTP request Accept TCP connection request images 2 Parse index.html: has 10 reference to 10 images request images 1 Send images 1 Send images 2 request images 10 Stop-and- wait! Pipeline 41 HTTP/1.1 với pipeline Time Time Web client Web server Init TCP connection Send HTTP response: index.html OK, send HTTP request Accept TCP connection Parse index.html: has 10 reference to 10 images request images 1 -10 Send images 1-10 42 41 42 22 HTTP là giao thức stateless  Một phiên hoạt động của HTTP:  Trình duyệt kết nối với Web server  Trình duyệt gửi thông điệp yêu cầu HTTP Request  Web server đáp ứng với một thông điệp HTTP Response  lặp lại  Trình duyệt ngắt kết nối  Các thông điệp HTTP Request được xử lý độc lập  Web server không ghi nhớ trạng thái của phiên HTTP  Nếu dịch vụ Web cần xác thực người dùng thì người dùng sẽ phải đăng nhập lại cho mỗi thông điệp HTTP Request gửi đi  43 HTTP là stateless  Quản lý phiên truy cập: Nếu HTTP Request chỉ được xử lý bởi phần mềm Web Server 44 Web Browser Web Server HTTP POST /login (Body: uid + pass) Login success  state: authenticatedHTTP Response (Body: Hello User) Forget  state: not authenticated HTTP POST /other HTTP Response (Body: You need login) Lặp đi lặp lại 43 44 23 HTTP Cookie  Cookie: dữ liệu do ứng dụng Web tạo ra, chứa thông tin trạng thái của phiên làm việc  Server có thể lưu lại cookie(một phần hoặc toàn bộ)  Sau khi xử lý yêu cầu, Web server trả lại thông điệp HTTP Response với coookie đính kèm  Set-Cookie: key = value; options;  Trình duyệt lưu cookie  Trình duyệt gửi HTTP Request tiếp theo với cookie được đính kèm 45 Trình duyệt Web server HTTP Request HTTP Response CookieCookieCookie HTTP Request Cookie HTTP Cookie - Ví dụ 46 HTTP Response 45 46 24 HTTP Cookie - Ví dụ  HTTP Request 47 Web caching  Các trang web có thể được lưu trên máy trạm cục bộ  Sử dụng local cache để  Duyệt web offline  Duyệt các trang web hiệu quả hơn 48 47 48 25 Web caching  “Cache”: Bộ nhớ đệm  Khái niệm bộ nhớ cache trong máy tính  L1 cache, L2 cache  “cache miss”, “cache hit”  Xem xét trường hợp sau:  Một tổ chức có một đường nối tới Internet  Tất cả lưu lượng truy cập web đều đi qua liên kết này  Nhiều NSD web có thể cùng truy nhập tới cùng một nội dung  Giải pháp cải tiến? www.xyz.com/index.htm 49 Sử dụng bộ đệm - web proxy  NSD đặt tham số kết nối truy cập web của trình duyệt qua một máy chủ proxy  trình duyệt gửi yêu cấu đến proxy  Miss: Proxy gửi yêu cầu tới máy chủ web, trả lời trình duyệt và lưu đệm đối tượng web  Hit: Proxy trả đối tượng web cho trình duyệt client Proxy server client Web server 50 49 50 26 Web proxy  Proxy: Vừa là client, vừa là server  Sử dụng bởi các ISP nhỏ, các tổ chức như trường học, công ty  Ảnh hưởng của proxy  Làm giảm lưu lượng web trên đường ra Internet  Có thể làm giảm thời gian đáp ứng  Thử phân tích vài trường hợp  cache hit  cache miss  proxy bị quá tải  Trang web thay đổi/trang web động? 51 Phương thức GET có điều kiện  Mục đích: Máy chủ sẽ không gửi đối tượng web nếu proxy còn lưu giữ thông tin cập nhật  Proxy: chỉ ra thời gian cũ của đối tượng If-modified-since:  server: Xác nhận lại có thay đổi hay không: HTTP/1.0 304 Not Modified proxy server HTTP request msg If-modified-since: HTTP response HTTP/1.0 304 Not Modified object not modified HTTP request msg If-modified-since: HTTP response HTTP/1.0 200 OK object modified 52 51 52 27 HTTPS  Hạn chế của HTTP:  Không có cơ chế để người dùng kiểm tra tính tin cậy của Web server  lỗ hổng để kẻ tấn công giả mạo dịch vụ hoặc chèn mã độc vào trang web HTML  Không có cơ chế mã hóa giữ mật  lỗ hổng để kẻ tấn công nghe lén đánh cắp thông tin nhạy cảm  Secure HTTP: sử dụng liên kết SSL/TLS thay cho TCP để truyền các thông điệp HTTP  Xác thực:  Người dùng truy cập vào đúng Website mong muốn  Dữ liệu trong quá trình truyền không bị thay đổi  Bảo mật: dữ liệu được giữ bí mật trong quá trình truyền  Số hiệu cổng ứng dụng: 443 53 HTTP trên trình duyệt Web 54 Truy cập dịch vụ Web với HTTP Khi click vào liên kết... 53 54 28 HTTPS trên trình duyệt Web 55 Truy cập Web với HTTPS - Toàn bộ nội dung website (bao gồm hình ảnh, CSS, Flash, scripts...) đã được trình duyệt thẩm tra tính toàn vẹn và nguồn gốc tin cậy. - Mọi thông tin trao đổi giữa trình duyệt và Vietcombank được giữ bí mật. HTTPS  Tuy nhiên, HTTPS có thể gây hiểu nhầm cho người dùng rằng trang web là an toàn:  Người dùng bất cẩn vì chỉ chú ý biểu tượng  HTTPS không chống lại được các dạng tấn công khai thác điểm yếu của Website 56 55 56 29 4. Email 57 Thư điện tử  MUA (Mail User Agent)  Lấy thư từ máy chủ, gửi thư đến máy chủ  e.g. Outlook, Thunderbird  MTA (Mail Transfer Agent): :  Chứa hộp thư đến của NSD (mail box)  Hàng đợi để gửi thư đi  e.g. Sendmail, MS Exchange user agent mail server mail server user agent  Giao thức:  Chuyển thư: SMTP-Simple Mail Transfer Protocol  nhận thư  POP – Post Office Protocol  IMAP – Internet Mail Access Protocol SMTP POP IMAP Mail box Message queue IMAP POP SMTPSMTP 58 57 58 30 Giao thức SMTP  RFC 2821  TCP, port 25: Chuyển thư từ client đến server và giữa các server với nhau  Tương tác yêu cầu/trả lời  Yêu cầu: Lệnh với mã ASCII  Trả lời: mã trạng thái và dữ liệu 59 Các giao thức nhận thư  POP: Post Office Protocol [RFC 1939]  Đăng nhập và lấy hết thư về  IMAP: Internet Mail Access Protocol [RFC 1730]  Phức tạp hơn POP  Cho phép lưu trữ và xử lý thư trên máy chủ user agent sender’s mail server user agent SMTP SMTP access protocol receiver’s mail server 60 59 60 31 Web Mail  Sử dụng Web browser như một MUA  MUA và MTA giao tiếp thông qua HTTP  Mails được lưu trữ trên máy chủ  E.g.  Gmail,  Hotmail,  Yahoo! Mail, etc.  Ngày nay, rất nhiều các MTA cho phép truy cập thông qua giao diện web   61 Khuôn dạng thông điệp thư điện tử SMTP: Giao thức để truyền thư RFC 822: Định nghĩa khuôn dạng  Phần đầu  To:  From:  Subject:  Phần thân  mã hóa dưới dạng mã ASCII header body blank line 62 61 62 32 Để chuyển dữ liệu đa phương tiện: multimedia extensions  MIME: multimedia mail extension, RFC 2045, 2056  Thêm một dòng trong phần đầu chỉ rõ khuôn dạng dữ liệu gửi đi From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data multimedia data type, subtype, parameter declaration method used to encode data MIME version encoded data 63 5. Ứng dụng truyền tệp 64 63 64 33 FTP: File Transfer Protocol  Mô hình Client-server  Trao đổi file giữa các máy  RFC 959  Sử dụng TCP, cổng 20, 21 TCP data connection, port 20 FTP server user interface FTP client local file system remote file system user TCP control connection, port 21  Điều khiển Out-of-band :  Lệnh của FTP : cổng 21  Dữ liệu: cổng 20  NSD phải đăng nhập trước khi truyền file  Một số server cho phép NSD với tên là anonymous 65 Lệnh và mã trả lời Một số ví dụ  USER username  PASS password  LIST : trả về danh sách file  RETR filename Lấy file  STOR filename Đặt file lên máy chủ Ví dụ về mã trả lời  331 Username OK, password required  125 data connection already open; transfer starting  425 Can’t open data connection  452 Error writing file 66 65 66 34 Ví dụ về ftp client C:\Documents and Settings\hongson>ftp ftp> ? Commands may be abbreviated. Commands are: ! delete literal prompt send ? debug ls put status append dir mdelete pwd trace ascii disconnect mdir quit type bell get mget quote user binary glob mkdir recv verbose bye hash mls remotehelp cd help mput rename close lcd open rmdir Command line GUI FTP clients: IE, Firefox, GFTP, . 67 Tóm tắt  Mô hình ứng dụng  Client-server vs. P2P  Một số ứng dụng và giao thức  HTTP  Mail  FTP  Về nhà, hãy tìm hiểu thêm  P2P   Giao diện lập trình Socket 68 67 68 35 Tài liệu tham khảo  Keio University  “Computer Networking: A Top Down Approach”, J.Kurose  “Computer Network”, Berkeley University 69 69