›
›

Bài giàng Nhập môn mạng máy tính - Chương 3: Tầng giao vận

pdf 99 trang hapham 2510
Download
Bạn đang xem 20 trang mẫu của tài liệu "Bài giàng Nhập môn mạng máy tính - Chương 3: Tầng giao vận", để 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:

  • pdfbai_giang_nhap_mon_mang_may_tinh_chuong_2_tang_giao_van.pdf

Nội dung text: Bài giàng Nhập môn mạng máy tính - Chương 3: Tầng giao vận

  1. Chương 3 TẦNG GIAO VẬN Transport Layer Nhập mơn mạng máy tính
  2. Chương 3: Mục tiêu:  hiểu các nguyên tắc  nghiên cứu về các giao đằng sau các dịch thức trên Internet: vụ :  UDP: vận chuyển khơng  multiplexing/demult kết nối (connectionless) iplexing  TCP: vận chuyển hướng  truyền dữ liệu tin kết nối (connection- cậy oriented)  điều khiển lưu lượng  điều khiển tắc nghẽn TCP  điều khiển tắc nghẽn 2
  3. Chương 3: Nội dung trình bày  3.1 Các dịch vụ  3.5 Vận chuyển hướng kết  3.2 Multiplexing và nối: TCP demultiplexing  cấu trúc phân đoạn  ề ữ ệ ậ  3.3 Vận chuyển khơng truy n d li u tin c y kết nối: UDP  điều khiển lưu lượng  quản lý kết nối 3.4 Các nguyên lý của ủ ề việc truyền dữ liệu tin 3.6 Các nguyên lý c a đi u ể ắ ẽ cậy khi n t c ngh n  3.7 Điều khiển tắc nghẽn TCP 3
  4. 3.1 Các dịch vụ 4 4
  5. Các dịch vụ và giao thức Transport  cung cấp truyền thơng logic application transport chạy trên các host khác nhau network data link network  các giao thức transport chạy physical data link network physical trên các hệ thống đầu cuối data link physical  ử ắ ệ network phía g i: c t các thơng đi p data link ứ ụ ạ physical network ng d ng thành các đo n, data link physical chuyển cho lớp network network  phía nhận: tái kết hợp các data link đoạn thành các thơng điệp, physical chuyển cho lớp application application transport network  Tầng giao vận của Internet cĩ 2 data link giao thức giao vận: TCP và UDP physical 5
  6. với lớp network  lớp network: truyền Tình huống tự nhiên tương tự: thơng logic giữa các 12 đứa trẻ gửi thư đến 12 đứa host trẻ khác  ế ứ  Lớp transport: truyền các ti n trình = các đ a trẻ thơng logic giữa các tiến trình  các thơng điệp = thư trong bao thư  Thêm, phát triển dịch vụ mới từ dịch vụ tầng mạng  các host = các gia đình  giao thức transport = An và Bình  giao thức lớp network = dịch vụ bưu điện 6
  7. Các giao thức trên Internet  ậ ề ứ application tin c y, truy n theo th transport ự network t (TCP) data link network physical data link  điều khiển tắc nghẽn network physical data link  điều khiển lưu lượng physical network  data link thiết lập kết nối physical network data link physical  khơng tin cậy, truyền network khơng theo thứ tự: UDP data link physical  mở rộng của giao thức IP application  transport khơng cĩ các dịch vụ: network data link  bảo đảm trễ physical  bảo đảm bandwidth 7
  8. 3.2 Multiplexing và demultiplexing 8 8
  9. Multiplexing/demultiplexing Demultiplexing tại host nhận: Multiplexing tại host gửi: ặ ữ ệ ừ ề vận chuyển các đoạn đã nhận thu nh t d li u t nhi u ữ ệ ớ được đến đúng socket socket, đĩng gĩi d li u v i header (sẽ dùng sau đĩ cho demultiplexing) = socket = tiến trình application P3 P1P1 application P2 P4 application transport transport transport network network network link link link physical physical physical host 1 host 2 host 3 9
  10. Demultiplexing làm việc như thế nào  host nhận các IP datagrams  mỗi datagram cĩ địa chỉ IP 32 bits nguồn và IP đích port # nguồn port # đích  mỗi datagram mang 1 đoạn của tầng giao vận  mỗi đoạn cĩ số port nguồn và các header fields khác đích  host dùng địa chỉ IP & số port để điều hướng đoạn đến socket dữ liệu ứng dụng thích hợp (thơng điệp) dạng thức đoạn TCP/UDP 10
  11. Ví dụ Multiplexing/demultiplexing 11
  12. 3.3 Vận chuyển khơng kết nối: UDP 12
  13. UDP: User Datagram Protocol [RFC 768]  giao thức Internet transport “đơn giản hĩa” Cĩ UDP để làm gì?  dịch vụ “best effort”, các  khơng thiết lập kết nối (giúp đoạn UDP cĩ thể: cĩ thể thêm delay)  mất mát  đơn giản: khơng trạng thái kết  vận chuyển khơng thứ tự nối tại nơi gửi, nơi nhận đến ứng dụng  header của đoạn nhỏ  connectionless (khơng kết  khơng điều khiển tắc nghẽn: nối): UDP cĩ thể gửi nhanh nhất  khơng bắt tay giữa bên theo mong muốn ậ ử nh n và bên g i UDP  mỗi đoạn UDP được quản lý độc lập 13
  14. UDP: (tt)  thường dùng cho các ứng dụng streaming multimedia 32 bits  chịu mất mát Độ dài source port # dest port #  cảm nhận tốc độ đoạn UDP length checksum bao gồm cả  ngồi ra, UDP dùng header  DNS  SNMP  truyền tin cậy trên UDP: dữ liệu thêm khả năng này tại lớp ứng dụng application (thơng điệp)  sửa lỗi dạng thức đoạn UDP 14
  15. UDP checksum Mục tiêu: kiểm tra các “lỗi” (các bit cờ đã bật lên) trong các đoạn đã truyền bên gửi: bên nhận:  đối xử các nội dung đoạn  tính tốn checksum của đoạn đã như một chuỗi các số nguyên nhận 16-bit  kiểm tra giá trị trên cĩ bằng với  checksum: bổ sung(tổng bù giá trị trong trường checksum: 1) của các nội dung đoạn  NO – cĩ lỗi xảy ra  đặt giá trị checksum vào  YES – khơng cĩ lỗi. trường UDP checksum  Nhưng cĩ thể cịn lỗi khác nữa? Xem tiếp phần sau . 15
  16. Ví dụ Checksum  Lưu ý  Khi cộng các số, một bit nhớ ở phía cao nhất cĩ thể sẽ phải thêm vào kết quả  Ví dụ: cộng hai số nguyên 16-bit 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 bit dư 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 tổng 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 16
  17. 3.4 Các nguyên lý của việc truyền dữ liệu tin cậy 17
  18. Các nguyên lý truyền dữ liệu tin cậy  quan trọng trong các lớp application, transport, link  là danh sách 10 vấn đề quan trọng nhất của mạng  các đặc thù của kênh truyền khơng tin cậy sẽ xác định sự phức tạp của giao thức truyền dữ liệu data transfer protocol (rdt) 18
  19. Các nguyên lý truyền dữ liệu tin cậy  quan trọng trong các lớp application, transport, link  là danh sách 10 vấn đề quan trọng nhất của mạng  các đặc thù của kênh truyền khơng tin cậy sẽ xác định sự phức tạp của giao thức truyền dữ liệu data transfer protocol (rdt) 19
  20. Truyền dữ liệu tin cậy rdt_send(): được gọi bởi lớp app. deliver_data(): được gọi Chuyển dữ liệu cần truyền đến lớp cao bởi rdt để truyền dữ liệu đến hơn bên nhận lớp cao hơn bên bên gửi nhận udt_send(): được gọi bởi rdt, rdt_rcv(): được gọi khi gĩi đến để truyền các gĩi trên kênh kênh bên nhận khơng tin cậy đến nơi nhận 20
  21. Truyền dữ liệu tin cậy  chỉ xem xét truyền dữ liệu theo 1 hướng duy nhất  nhưng điều khiển lưu lượng thơng tin sẽ theo cả 2 chiều!  dùng máy trạng thái hữu hạn (finite state machines-FSM) để xác định bên gửi, bên nhận sự kiện gây ra trạng thái truyền các hành động xảy ra khi truyền trạng thái: khi ở “trạng thái” này thì trạng thái trthái trthái sự kiện kế tiếp duy nhất được 1 2 xác định bởi sự kiện kế các hành động tiếp 21
  22. Rdt1.0: truyền dữ liệu tin cậy trên 1 kênh truyền tin cậy  kênh truyền tin cậy hồn tồn  khơng cĩ các lỗi  khơng mất mát các gĩi  các FSM phân biệt cho bên gửi, bên nhận:  bên gửi gửi dữ liệu vào kênh tin cậy  bên nhận nhận dữ liệu từ kênh tin cậy rdt_send(data) rdt_rcv(packet) chờ gọi từ chờ gọi từ extract (packet,data) lớp trên packet = make_pkt(data) lớp dưới deliver_data(data) udt_send(packet) bên gửi bên nhận 22
  23. Rdt2.0: kênh truyền cĩ lỗi  Kênh truyền bên dưới cĩ lỗi bit  checksum để kiểm tra các lỗi  Hỏi: làm sao khơi phục các lỗi?  các acknowledgements (ACK): bên nhận rõ ràng thơng báo cho bên gửi rằng quá trình nhận gĩi tốt  các negative acknowledgements (NAK): bên nhận rõ ràng thơng báo cho bên gửi rằng quá trình nhận gĩi cĩ lỗi  bên gửi gửi lại gĩi nào được xác nhận là NAK  các cơ chế mới trong rdt2.0 (sau rdt1.0):  kiểm tra lỗi  nhận phản hồi: các thơng điệp điều khiển (ACK,NAK) bên nhận bên gửi 23
  24. rdt2.0: đặc tả FSM rdt_send(data) snkpkt = make_pkt(data, checksum) bên nhận udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) chờ gọi từ chờ ACK rdt_rcv(rcvpkt) && lớp trên hoặc NAK udt_send(sndpkt) corrupt(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) L chờ gọi từ lớp dưới bên gửi rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 24
  25. rdt2.0: hoạt động khi khơng lỗi rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) chờ gọi từ chờ ACK rdt_rcv(rcvpkt) && lớp trên hoặc NAK udt_send(sndpkt) corrupt(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) chờ gọi từ L lớp dưới rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 25
  26. rdt2.0: hoạt động khi cĩ lỗi rdt_send(data) snkpkt = make_pkt(data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) chờ gọi từ chờ ACK rdt_rcv(rcvpkt) && lớp dưới hoặc NAK udt_send(sndpkt) corrupt(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) L chờ gọi từ lớp dưới rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) 26
  27. rdt2.0 cĩ lỗ hổng nghiêm trọng! Điều gì xảy ra nếu Quản lý trùng lặp: ACK/NAK bị hỏng?  Bên gửi truyền lại gĩi hiện tại  bên gửi khơng biết điều gì đã nếu ACK/NAK bị hỏng xảy ra tại bên nhận!  bên gửi thêm số thứ tự vào  khơng thể đơn phương truyền mỗi gĩi lại: khả năng trùng lặp  bên nhận hủy (khơng nhận) gĩi trùng lặp dừng và chờ bên gửi gửi 1 gĩi, sau đĩ dừng lại chờ phản hồi từ bên nhận 27
  28. rdt2.1: bên gửi quản lý các ACK/NAK bị hỏng rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || chờ ACK chờ gọi 0 từ isNAK(rcvpkt) ) hoặc NAK 0 lớp trên udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) && isACK(rcvpkt) L L chờ ACK chờ gọi 1 từ hoặc NAK lớp trên rdt_rcv(rcvpkt) && 1 ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_send(data) udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) Bên gửi 28
  29. rdt2.1: bên gửi quản lý các ACK/NAK bị hỏng rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) udt_send(sndpkt) chờ chờ rdt_rcv(rcvpkt) && 0 từ 1 từ rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && dưới dưới not corrupt(rcvpkt) && has_seq1(rcvpkt) has_seq0(rcvpkt) sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) Bên nhận udt_send(sndpkt) 29
  30. rdt2.1: thảo luận bên gửi: bên nhận:  số thứ tự # thêm vào  phải kiểm tra cĩ nhận gĩi trùng gĩi khơng  chỉ cần hai số thứ tự  trạng thái chỉ rõ cĩ hay (0,1) là đủ. Tại sao? khơng mong chờ số thứ tự 0 hoặc 1  phải kiểm tra nếu việc  chú ý: bên nhận khơng nhận ACK/NAK bị hỏng biết ACK/NAK vừa rồi  số trạng thái tăng lên 2 của nĩ cĩ được bên gửi lần nhận tốt hay khơng  trạng thái phải “nhớ” gĩi “hiện tại” cĩ số thứ tự là 0 hay 1 30
  31. rdt2.2: một giao thức khơng cần NAK  chức năng giống như rdt2.1, chỉ dùng các ACK  thay cho NAK, bên nhận gửi ACK cho gĩi vừa rồi đã nhận tốt  bên nhận phải rõ ràng chèn số thứ tự của gĩi vừa ACK  trùng ACK tại bên gửi hậu quả giống như hành động của NAK: truyền lại gĩi vừa rồi 31
  32. rdt2.2: gửi, nhận các mảnh rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || Chờ cho Chờ cho isACK(rcvpkt,1) ) gọi 0 từ ACK trên 0 udt_send(sndpkt) gửi phân mảnh FSM rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && && isACK(rcvpkt,0) (corrupt(rcvpkt) || L has_seq1(rcvpkt)) Chờ nhận phân mảnh cho gọi udt_send(sndpkt) 0 từ FSM dưới rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK1, chksum) udt_send(sndpkt) 32
  33. rdt3.0: các kênh với lỗi và mất mát Giả định mới: kênh truyền Cách tiếp cận: bên gửi chờ cũng cĩ thể làm mất các ACK trong khoảng thời gĩi (dữ liệu hoặc các gian “chấp nhận được” ACK)  truyền lại nếu khơng nhận ACK  checksum, số thứ tự, các trong khoảng thời gian này ACK, các việc truyền lại sẽ  nếu gĩi (hoặc ACK) chỉ trễ hỗ trợ nhưng khơng đủ (khơng mất):  truyền lại sẽ gây trùng, nhưng dùng số thứ tự sẽ giải quyết được  bên nhận phải xác định số thứ tự của gĩi vừa gửi ACK  cần bộ định thì đếm lùi 33
  34. rdt3.0 gửi rdt_send(data) rdt_rcv(rcvpkt) && sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) || udt_send(sndpkt) isACK(rcvpkt,1) ) rdt_rcv(rcvpkt) start_timer L L Chờ Chờ cho timeout gọi 0 cho udt_send(sndpkt) từ trên ACK 0 start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt,1) && notcorrupt(rcvpkt) stop_timer && isACK(rcvpkt,0) stop_timer Chờ Chờ cho timeout cho gọi 1 udt_send(sndpkt) ACK 1 từ trên start_timer rdt_rcv(rcvpkt) rdt_send(data) L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum) isACK(rcvpkt,0) ) udt_send(sndpkt) start_timer L 34
  35. hành động của rdt3.0 35
  36. hành động của rdt3.0 36
  37. Hiệu suất của rdt3.0  rdt3.0 làm việc được, nhưng hiệu suất thấp  ví dụ: liên kết 1 Gbps, trễ lan truyền giữa hai đầu cuối là 15 ms, gĩi 1KB: L (độ dài gĩi tính bằng bits) 8x103b/pkt T ề = = = 8 microsec truy n R (tốc độ truyền, bps) 109 b/sec  U sender: độ khả dụng – Hiệu suất sử dụng đường truyền L / R .008 U = = = 0.00027 sender RTT + L / R 30.008 microsec onds  gĩi 1KB mỗi 30 msec -> 33kB/s trên đường truyền 1 Gbps  giao thức network hạn chế việc dùng các tài nguyên vật lý! 37
  38. rdt3.0: hoạt động dừng-và-chờ gửi nhận gĩi đầu tiên đã truyền, t = 0 gĩi cuối cùng đã truyền, t = L / R gĩi đầu tiên đã đến RTT gĩi cuối cùng đã đến, gửi ACK ACK đến, gửi gĩi kế tiếp, t = RTT + L / R L / R .008 U = = = 0.00027 sender RTT + L / R 30.008 microsec onds 38
  39. Các giao thức Pipelined Pipelining: bên gửi cho phép gửi nhiều gĩi đồng thời, khơng cần chờ báo nhận được  nhĩm các số thứ tự phải tăng dần  phải cĩ bộ nhớ đệm tại nơi gửi và/hoặc nơi nhận  hai dạng phổ biến của các giao thức pipelined: go-Back-N, Selective Repeat 39
  40. Pipelining: độ khả dụng tăng sender receiver gĩi đầu tiên đã truyền, t = 0 gĩi cuối cùng đã truyền, t = L / R gĩi đầu tiên đã đến RTT gĩi cuối cùng đã đến, gửi ACK bit cuối của gĩi thứ 2 đến, gửi ACK bit cuối của gĩi thứ 3 đến, gửi ACK ACK đến, gửi gĩi kế tiếp, t = RTT + L / R Độ khả dụng tăng lên gấp 3 lần! 3 * L / R .024 U = = = 0.0008 sender RTT + L / R 30.008 microsecon ds 40
  41. Go-Back-N Bên gửi:  k-bit số thứ tự trong header của gĩi  “cửa sổ” tăng lên đến N, cho phép gửi các gĩi liên tục khơng cần ACK ACK(n): ACKs tất cả các gĩi đến, chứa số thứ tự n – “ACK tích lũy”  cĩ thể nhận các ACK trùng lặp (xem bên nhận) định thì cho mỗi gĩi trên đường truyền timeout(n): gửi lại gĩi n và tất cả các gĩi cĩ số thứ tự cao hơn trong cửa sổ 41
  42. GBN: bên gửi mở rộng FSM rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } L else refuse_data(data) base=1 nextseqnum=1 timeout start_timer chờ udt_send(sndpkt[base]) rdt_rcv(rcvpkt) udt_send(sndpkt[base+1]) && corrupt(rcvpkt) udt_send(sndpkt[nextseqnum-1]) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer 42
  43. GBN: bên nhận mở rộng FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) L && hasseqnum(rcvpkt,expectedseqnum) expectedseqnum=1 chờ extract(rcvpkt,data) sndpkt = deliver_data(data) make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ ACK-duy nhất: luơn luơn gửi ACK cho gĩi đã nhận đúng, với số thứ tự xếp hạng cao nhất  cĩ thể sinh ra các ACK trùng nhau  chỉ cần nhớ expectedseqnum  gĩi khơng theo thứ tự:  hủy -> khơng nhận vào bộ đệm!  gửi lại ACK của gĩi đúng thứ tự lớn nhất 43
  44. GBN hoạt động 44
  45. Lặp cĩ lựa chọn  bên nhận thơng báo đã nhận đúng tất cả từng gĩi một  đệm (buffer) các gĩi nếu cần thiết  bên gửi chỉ gửi lại các gĩi nào khơng nhận được ACK  bên gửi định thì đối với mỗi gĩi khơng gửi ACK  cửa sổ bên gửi  N số thứ tự liên tục  hạn chế số thứ tự các gĩi khơng gửi ACK 45
  46. Lặp cĩ lựa chọn: các cửa sổ gửi, nhận 46
  47. Lặp cĩ lựa chọn Gửi Nhận Gửi dữ liệu từ lớp trên: gĩi n trong [rcvbase, rcvbase+N-1]  nếu số thứ tự kế tiếp sẵn sàng gửi ACK(n) trong cửa sổ, gửi gĩi khơng thứ tự: lưu vào bộ đệm timeout(n): (buffer)  gửi lại gĩi n, tái khởi tạo bộ định Đúng thứ tự: chuyển tất cả dữ thì liệu đã nhận đúng thứ tự lên tầng bên trên ACK(n) trong [sendbase,sendbase+N]: gĩi n trong [rcvbase-N,rcvbase-1]  đánh dấu gĩi n là đã nhận ACK(n)  Nếu n là STT bé nhất chưa biên nhận, dịch chuyển cửa sổ lên ngược lại: STT gĩi tin bé nhất chưa biên lờ đi nhận kế tiếp 47
  48. Hoạt động của lặp cĩ lựa chọn 48
  49. Lặp cĩ lựa chọn: tình hợp khĩ giải quyết Ví dụ:  Số thứ tự: 0, 1, 2, 3  Kích thước cửa sổ = 3  bên nhận khơng thấy sự khác nhau trong 2 tình huống  chuyển khơng chính xác dữ liệu trùng lặp như dữ liệu mới trong (a) Hỏi: quan hệ giữa dãy số thứ tự và kích thước cửa sổ? 49
  50. 3.5 Vận chuyển hướng kết nối: TCP 50 50
  51. TCP: Tổng quan RFCs: 793, 1122, 1323, 2018, 2581  point-to-point:  dữ liệu full duplex:  một bên gửi, một bên nhận  luồng dữ liệu đi 2 chiều  tin cậy, dịng byte cĩ thứ trong cùng một kết nối tự:  MSS: maximum segment size – kích thước đoạn tối  khơng “ranh giới thơng đa điệp”  hướng kết nối:  Đường ống - pipelining:  bắt tay (trao đổi các thơng  TCP điều khiển lưu lượng và điệp điều khiển) trạng thái tắc nghẽn, thiết lập kích bên gửi, bên nhận trước thước cửa sổ khi trao đổi dữ liệu  các bộ đệm gửi & nhận  điều khiển lưu lượng: application application writes data reads data  bên gửi sẽ khơng lấn át bên socket socket door door nhận TCP TCP send buffer receive buffer segment 51
  52. TCP: cấu trúc đoạn URG: urgent data 32 bits (generally not used) source port # dest port # counting ACK: ACK # by bytes sequence number valid of data (not segments!) Header length acknowledgement number head not (by 32-bit word) rcvr window size len used UA P R S F # bytes checksum ptr urgent data PSH: push data to rcvr willing app immediately to accept (generally not used) Options (variable length) RST, SYN, FIN: connection estab application (setup, teardown commands) data (variable length) Internet checksum (as in UDP) 52
  53. Các số thứ tự TCP và ACK Các số thứ tự: Host A Host B  dịng byte “đánh số” byte đầu tiên trong User ậ ữ ệ ủ ạ nh p d li u c a đo n ‘C’ các ACK: host ACKs báo nhận  số thứ tự của byte kế ‘C’, phản hồi tiếp được chờ đợi từ ngược lại ‘C’ phía bên kia  ACK tích lũy host ACKs Hỏi: làm thế nào bên nhận nhận phản hồi ‘C’ quản lý các đoạn khơng thứ tự  Trả lời: TCP khơng đề time cập, tùy thuộc người tình huống telnet đơn giản hiện thực 53
  54. TCP Round Trip Time vàTimeout Hỏi: Làm thế nào để thiết Hỏi: Làm thế nào để thiết lập lập giá trị TCP RTT? timeout?  SampleRTT: thời gian được đo từ  dài hơn RTT khi truyền đoạn đến khi báo nhận ACK  khác với RTT  ờ ệ ề ạ  quá ngắn: timeout sớm l đi vi c truy n l i  SampleRTT sẽ thay đổi mạnh nên  truyền lại khơng cần ầ ướ ượ ượ ơ thiết c n c l ng RTT “m t h n”  ộ ố ị  quá dài: phản ứng chậm đối tính trung bình m t s giá tr ượ ầ ỉ với việc mất mát gĩi đo đ c g n đĩ, khơng ch SampleRTT hiện tại 54
  55. TCP Round Trip Time và Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT giá trị đặc trưng: = 0.125 55
  56. Ví dụ đánh giá RTT: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 300 250 RTT (milliseconds) 200 x 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT 56
  57. TCP Round Trip Time và Timeout Thiết lập timeout  EstimtedRTT cộng “hệ số dự trữ an tồn”  sự biến thiên lớn trong EstimatedRTT -> hệ số dự trữ an tồn lớn hơn  ước lượng đầu tiên về sự biến thiên của SampleRTT từ EstimatedRTT : DevRTT = ()*DevRTT + *|SampleRTT-EstimatedRTT| (tiêu biểu  = 0.25) Sau đĩ thiết lập timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT 57
  58. TCP: truyền dữ liệu tin cậy  TCP tạo dịch vụ rdt trên  Truyền lại được kích dịch vụ khơng tin cậy IP hoạt bởi:  các sự kiện timeout  các ack trùng lặp ử ụ ơ ế S d ng các c ch  lúc đầu khảo sát các bên  các đoạn Pipelined gửi TCP đơn giản:  các ACK tích lũy  lờ đi các ack trùng lặp  TCP dùng bộ định thời  lờ đi điều khiển lưu lượng, để truyền lại% điều khiển tắc nghẽn 58
  59. Các sự kiện TCP tại bên gửi 59
  60. NextSeqNum = InitialSeqNum SendBase = InitialSeqNum TCP loop (forever) { switch(event) bên gửi event: data received from application above create TCP segment with sequence number NextSeqNum (đơn giản) if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number start timer event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y cancel the timer for sendbase if (there are currently not-yet-acknowledged segments) start timer } } /* end of loop forever */ 60
  61. TCP: các tình huống truyền lại Host A Host B Host A Host B timeout X loss timeout Seq=92 Sendbase = 100 SendBase = 120 SendBase timeout Seq=92 = 100 SendBase = 120 timeout sớm time time tình huống mất ACK 61
  62. TCP: các tình huống truyền lại (tt) Host A Host B timeout X loss SendBase = 120 time tình huống ACK tích lũy 62
  63. TCP tại bên nhận [RFC 1122, RFC 2581] Sự kiện tại bên nhận TCP bên nhận hành động Đoạn đến với đúng số thứ tự ACK trễ. Chờ đến 500ms mong muốn. cho đoạn kế tiếp. Nếu khơng cĩ đoạn kế tiếp, gửi ACK Đoạn đến với đúng số thứ tự Gửi ngay một ACK tích lũy mong muốn. Một đoạn khác đang chờ ACK Các đoạn đến khơng thứ tự Gửi ngay ACK trùng lặp, chỉ thị số thứ tự lớn hơn số thứ tự đoạn mong muốn. đoạn của byte kế tiếp đang mong chờ Cĩ khoảng trống Đoạn đến điền vào vị trí khoảng Gửi ngay ACK tích lũy, là gĩi tin cĩ số trống lớn nhất chưa được nhận 63
  64. Gĩi tin đến Ack tích lũy 64
  65. Truyền lại nhanh  Chu kỳ Time-out thường  Nếu bên gửi nhận 3 ACK tương đối dài: của cùng một dữ liệu, nĩ  độ trễ dài trước khi gửi lại cho là đoạn sau dữ liệu đã gĩi đã mất ACK bị mất:  Xác nhận các đoạn đã  Truyền lại nhanh: gửi lại mất bằng các ACK trùng đoạn trước khi bộ định thì lặp. hết hạn  bên gửi thường gửi nhiều đoạn song song  Nếu đoạn bị mất, sẽ xảy ra tình trạng giống như nhiều ACK trùng nhau 65
  66. Giải thuật truyền lại nhanh: sự kiện: ACK đã nhận, với trường là y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } một ACK trùng lặp cho Truyền lại nhanh đoạn đã được ACK 66
  67. TCP điều khiển lưu lượng điều khiển lưu lượng bên gửi sẽ khơng làm  bên nhận của kết nối TCP tràn bộ đệm vì truyền cĩ một bộ đệm nhận: quá nhiều và quá nhanh  dịch vụ so trùng tốc độ: so trùng tốc độ gửi với tốc độ nhận của ứng dụng tiến trình ứng dụng cĩ thể chậm tại lúc đọc bộ đệm 67
  68. TCP điều khiển lưu lượng 68
  69. TCP quản lý kết nối Chú ý: Bên gửi và bên nhận TCP phương pháp bắt tay 3 bước: thiết lập “kết nối” trước khi ướ ử ạ trao đổi dữ liệu B c 1: client host g i đo nTCP SYN đến server  khởi tạo các biến TCP:  xác định số thứ tự khởi đầu  các số thứ tự đoạn  khơng phải dữ liệu  thơng tin các bộ đệm, điều khiển lưu lượng (như Bước 2: server host nhận SYN, trả RcvWindow) lời với đoạn SYNACK  client: Khởi tạo, yêu cầu kết  server cấp phát các bộ đệm ố n i  xác định số thứ tự khởi đầu Socket clientSocket = new Socket("hostname","port Bước 3: client nhận SYNACK, trả lời với đoạn ACK (cĩ thể chứa dữ number"); liệu)  server: chấp nhận kết nối khi client cĩ yêu cầu Socket connectionSocket = welcomeSocket.accept(); 69
  70. TCP quản lý kết nối (tt) Đĩng một kết nối: client server đĩng client đĩng socket: clientSocket.close(); Bước 1: client gửi đoạn điều đĩng khiển TCP FIN đến server Bước 2: server nhận FIN, trả ờ lời với ACK. Đĩng kết nối, gửi FIN. i gian ch gian i ờ th đã đĩng 70
  71. TCP quản lý kết nối (tt) Bước 3: client nhận FIN, trả client server ờ ớ l i v i ACK. đang đĩng  Trong khoảng “thời gian chờ” – sẽ phản hồi với ACK để nhận các FIN đang đĩng Bước 4: server, nhận ACK thì Kết nối đã đĩng thực sự ờ đĩng. đã đĩng Chú ý: với một sửa đổi nhỏ, cĩ i gian ch gian i thể quản lý nhiều FIN đồng ờ thời. th đã đĩng 71
  72. TCP quản lý kết nối (tt) chu kỳ sống của TCP server chu kỳ sống của TCP client 72
  73. 3.6 Các nguyên lý của điều khiển tắc nghẽn 73
  74. Các nguyên lý điều khiển tắc nghẽn Tắc nghẽn:  “quá nhiều nguồn gửi quá nhanh và quá nhiều dữ liệu đến mạng”  khác với điều khiển lưu lượng!  các biểu hiện:  các gĩi bị mất (tràn bộ đệm tại các router)  các độ trễ quá dài (xếp hàng trong bộ đệm của router)  là 1 trong 10 vấn đề nan giải nhất! 74
  75. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 1 Host A lout Host C l : original data  2 gửi, 2 nhận in  1 router, các bộ Host B unlimited shared output đệm khơng giới hạn link buffers  khơng cĩ truyền lại Host D Hình A  các độ trễ lớn hơn khi tắc nghẽn  năng suất cĩ thể đạt tối đa 75 Hình B Hình C
  76. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 2  1 router, các bộ đệm cĩ giới hạn  bên gửi truyền lại các gĩi đã mất Host A l lin : dữ liệu gốc out l'in : dữ liệu gốc, cùng với dữ liệu truyền lại Host B chia sẻ vơ hạn các bộ đệm ouput 76
  77. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 2 l = l  Trường hợp lý tưởng in out  ề ạ ấ l > l truy n l i khi m t gĩi tin: in out  truyền lại vì trễ (khơng mất) làm cho l > l in out C/2 C/2 C/2 C/3 out out out C/4 l l l C/2 C/2 C/2 lin lin lin a. b. c. “các chi phí” của tắc nghẽn: nhiều việc (truyền lại) các truyền lại khơng cần thiết: liên kết nhiều bản sao của gĩi 77
  78. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 3  4 người gửi Hỏi: điều gì xảy ra nếu lin và l’in  các đường qua nhiều hop tăng lên?  timeout/truyền lại Host A lout lin : dữ liệu gốc l'in : dữ liệu gốc, cùng với dữ liệu truyền lại chia sẻ vơ hạn các bộ đệm ouput Host B 78
  79. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 3 H l o o st u A t H o st B 79
  80. Các cách tiếp cận đối với điều khiển tắc nghẽn 2 cách: điều khiển tắc nghẽn đầu – điều khiển tắc nghẽn cĩ sự cuối hỗ trợ của mạng:  khơng cĩ phản hồi rõ ràng từ  các router cung cấp phản hồi về mạng các hệ thống đầu cuối  tắc nghẽn được suy ra từ việc  1 bit duy nhất chỉ thị tắc quan sát các hệ thống đầu nghẽn cuối cĩ mất mát, trễ  tốc độ sẽ gửi được xác định  tiếp cận được quản lý bởi TCP rõ ràng 80
  81. Ví dụ: điều khiển tắc nghẽn ATM ABR ABR: available bit rate: RM (resource management):  “dịch vụ mềm dẻo”  gửi bởi bên gửi, rải rác với các ơ  nếu đường truyền “tốt”: dữ liệu  bên gửi sẽ dùng tăng tốc  các bit trong ơ thiết lập bởi các switch  nếu đường gửi tắc nghẽn:  bit NI : khơng tăng tốc độ  bên gửi điều tiết với tốc ắ ẽ ẹ độ tối thiểu (t c ngh n nh )  bit CI : tắc nghẽn rõ rệt  Các ơ RM được trả về bên gửi từ bên nhận với nguyên vẹn các bit 81
  82. Ví dụ: điều khiển tắc nghẽn ATM ABR  trường 2-byte ER (explicit rate) trong tế bào RM  switch đã tắc nghẽn cĩ thể gán giá trị ER thấp hơn  tốc độ gửi do đĩ cĩ thể được hỗ trợ tối đa trên đường  EFCI bit trong các ơ dữ liệu: được cài giá trị 1 trong switch đã tắc nghẽn  nếu tế bào dữ liệu đứng trước tế bào RM cĩ cài EFCI, bên nhận ẽ ế ả ạ ử s cài bit CI trong t bào RM và tr l i cho bên g i 82
  83. 3.7 Điều khiển tắc nghẽn TCP 83
  84. Cơ chế điều khiển tắc nghẽn  Các chiến lược (thuật tốn) điều khiển tắc nghẽn trong TCP: Slow Start (SS): bắt đầu chậm Tính thời gian khứ hồi một cách thơng minh + Rút lui theo hàm mũ Congestion Avoidance (CA): Trách tắc nghẽn Fast Retransmit (FRTX): Phát lại nhanh Fast Recovery (FRCV): Khơi phục nhanh  Các thuật tốn trên là độc lập, nhưng thường được kết hợp 84
  85. TCP Congestion Control (điều khiển tắc nghẽn)  end-end control (no network assistance)  Tốc độ truyền bị giới hạn bởi kích thước cửa sổ tắc nghẽn Congwin, được tính là số segment Congwin w segments, each with MSS bytes sent in one RTT: w * MSS throughput = Bytes/sec RTT 85
  86. TCP congestion control:  Sử dụng kỹ thuật thăm dị  Cĩ 2 giai đoạn (“phases”) “probing” kênh truyền  Khởi động chận (slow start)  Khi khơng cĩ tắc nghẽn, thì  Tránh tắc nghẽn (congestion truyền với tốc độ nhanh nhất avoidance) cĩ thể  Tăng Congwin cho đến khi mất gĩi tin (congestion)  Khi mất gĩi tin: giảm Congwin, sau đĩ lại thăm dị để tăng trở lại 86
  87. TCP khởi động chậm -Thuật tốn Slow Start  Thực thể phát sử dụng thêm biến:  Congwin(congestion window) - kích thước cửa sổ phát  threshold - giới hạn trên của cwnd, nếu vượt qua tắc nghẽn Slowstart algorithm initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold)  Lưu ý  Congwin: tăng theo hàm mũ  Loss: khi timeout hoặc 3 ACK trùng lặp 87
  88. Tránh tắc nghẽn - Thuật tốn CA:  Congwin := Congwin + 1 với mỗi ack.  Khi phát hiện dấu hiệu tắc nghẽn:  threshold := Congwin/2, Congwin:= 1  RTO = RTO * 2 (Exponential backoff)  SS  Nhận xét: 1. Trong giai đoạn CA, cwnd tăng tuyến tính:  Đảm bảo tận dụng băng thơng cĩ thể sử dụng được  Vẫn thăm dị tiếp khả năng sử dụng băng thơng nhiều hơn 2. Congwin bị giảm theo cấp số nhân (Multiplicative Decreased) 88
  89. Minh hoạ thuật tốn SS và CA: 89
  90. Fast Retransmit (FRTX)  Sau khi nhận được Dupack (>=3), TCP thực hiện phát lại nhanh, khơng chờ bị Timeout, sau đĩ chuyển ngay về SS.  Đây là một cách “dự đốn thơng minh” rằng, gĩi tin đã bị mất. 90
  91. Fast Recovery (FRCV): Cải tiến FRTX: thực hiện FRTX xong về CA chứ khơng về SS:  ssthresh := Congwin /2, nhưng khơng nhỏ hơn 2 (gĩi tin)  Congwin := Congwin + 3. Bên gửi “đốn”: 3 dupack ứng với 3 gĩi tin đã được nhận đúng.  Với mỗi dupack nhận được thêm, tăng Congwin := Congwin + 1 91
  92. TCP Reno và TCP Tahoe: 14 12 10 8 6 (segments) 4 threshold 2 congestion windowcongestion size 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Transmission round Series1TCP Series2TCP Tahoe Reno 92
  93. Chú ý:  Trong các thuật tốn trên, khơng bao giờ tăng cửa sổ phát quá giá trị mà bên nhận loan báo – rcnd (Receiver Adverticed Window). Nĩi cách khác, cửa sổ phát =Congwin, rcnd} 93
  94. TCP: tính cơng bằng Mục tiêu: nếu K phiên làm việc TCP chia sẻ kết nối cổ chai của băng thơng là R, mỗi phiên cĩ tốc độ trung bình là R/K TCP kết nối 1 router cổ chai TCP khả năng R kết nối 2 94
  95. TCP: tính cơng bằng (tt) Tính cơng bằng & UDP  nhiều ứng dụng thường khơng dùng TCP  khơng muốn tốc độ bị điều tiết do điều khiển tắc nghẽn  Thay bằng dùng UDP:  truyền audio/video với tốc độ ổn định, chịu được mất mát  Làm thế nào để xây dựng một ứng dụng truyền file (tin cậy) mà khơng phải chia sẻ đường truyền??? 95
  96. Ví dụ Thực nghiệm 1 • Mục tiêu thực nghiệm • Topo mạng mơ phỏng 96
  97. Kết quả thực nghiệm 1 97
  98. Thực nghiệm 2 98
  99. Hết Chương 3 99