›
›

Mạng máy tính - Chương 3: Lớp transport

pdf 111 trang vanle 2880
Download
Bạn đang xem 20 trang mẫu của tài liệu "Mạng máy tính - Chương 3: Lớp transport", để 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:

  • pdfmang_may_tinh_chuong_3_lop_transport.pdf

Nội dung text: Mạng máy tính - Chương 3: Lớp transport

  1. Chương 3 Lớp Transport Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. Slide này được biên dịch sang tiếng Việt theo sự cho phép của các tác giả All material copyright 1996-2006 J.F Kurose and K.W. Ross, All Rights Reserved Lớp Transport 1
  2. Chương 3: Lớp Transport 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 vụ thức lớp Transport trên lớp transport: Internet:  multiplexing/demultipl  UDP: vận chuyển không kết exing nối (connectionless)  truyền dữ liệu tin cậy  TCP: vận chuyển hướng kết  điều khiển luồng nối (connection-oriented)  điều khiển tắc nghẽn  điều khiển tắc nghẽnTCP Lớp Transport 2
  3. Chương 3: Nội dung trình bày ˆ 3.1 Các dịch vụ lớp ˆ 3.5 Vận chuyển hướng kết Transport nối: TCP ˆ 3.2 Multiplexing và  cấu trúc phân đoạn demultiplexing  truyền dữ liệu tin cậy  ề ể ồ ˆ 3.3 Vận chuyển không đi u khi n lu ng kết nối: UDP  quản lý kết nối ˆ 3.6 Các nguyên lý của ˆ 3.4 Các nguyên lý của ề ể ắ ẽ việc truyền dữ liệu tin đi u khi n t c ngh n cậy ˆ 3.7 Điều khiển tắc nghẽn TCP Transport Layer 3-3
  4. 3.1 Các dịch vụ lớp Transport Lớp Transport 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 physical data link ˆ các giao thức transport chạy lo ginetwork physical datac link trên các hệ thống đầu cuối a physicall e n network  ử ắ d phía g i: c t các thông data link -e n physical network điệp ứng dụng thành các d t data link r ạ ể ớ a physical đo n, chuy n cho l p n s p network o network rdata link tphysical  phía nhận: tái kết hợp các đoạn thành các thông điệp, application transport chuyển cho lớp application network data link ˆ có nhiều hơn 1 giao thức physical transport dành cho các ứng dụng  Internet: TCP và UDP Lớp Transport 5
  6. Lớp Transport 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 host đứa trẻ khác ˆ lớp transport: truyền ˆ các tiến trình = các đứa thông logic giữa các trẻ tiến trình ˆ các thông điệp = thư  dựa vào và làm nổi bật trong bao thư các dịch vụ lớp network ˆ các host = các gia đình ˆ giao thức transport = Ann và Bill ˆ giao thức lớp network = dịch vụ bưu điện Lớp Transport 6
  7. Các giao thức lớp transport trên Internet ˆ tin cậy, truyền theo thứ application transport ự network t (TCP) data link network physical data link lo  điều khiển tắc nghẽn ginetwork physical datac link a physicall  điều khiển luồng e n network d data link  -e thiết lập kết nối n physical network d t data link r ˆ a physical không tin cậy, truyền n s p network o không theo thứ tự: UDP rdata link tphysical  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 Lớp Transport 7
  8. 3.2 Multiplexing và demultiplexing Lớp Transport 8
  9. Multiplexing/demultiplexing Demultiplexing tại host nhận: Multiplexing tại host gửi: thu nhặt dữ liệu từ nhiều vận chuyển các đoạn đã nhận socket, đóng gói dữ liệu với được đến đúng socket 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 3 host 1 host 2 Lớp Transport 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ồnport # đích  mỗi datagram mang 1 đoạn của lớp transport  mỗi đoạn có số port nguồn các header fields khác và đí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 Lớp Transport 10
  11. Demultiplexing không kết nối ˆ Khi host nhận đoạn UDP: ˆ Tạo các sockets với các số port:  kiểm tra port đích trong đoạn DatagramSocket mySocket1 = new DatagramSocket(12534);  điều hướng đoạn UDP đến ợ ớ ố DatagramSocket mySocket2 = new socket nào phù h p v i s DatagramSocket(12535); port đó ˆ UDP socket được xác định ˆ IP datagrams với địa chỉ bởi bộ 2: IP nguồn và/hoặc số port khác nhau có thể được (địa chỉ IP, số port đích) điều hướng đến cùng socket Lớp Transport 11
  12. Demultiplexing không kết nối (tt) DatagramSocket serverSocket = new DatagramSocket(6428); P1 P2 P3 P1 SP: 6428 SP: 6428 DP: 9157 DP: 5775 SP: 9157 SP: 5775 client DP: 6428 server DP: 6428 Client IP: A IP: C IP:B SP cung cấp “địa chỉ trở về” Lớp Transport 12
  13. Demultiplexing hướng kết nối ˆ TCP socket được xác ˆ Host server có thể hỗ định bởi bộ 4: trợ nhiều TCP socket  địa chỉ IP nguồn đồng thời:  số port nguồn  mỗi socket được xác định  địa chỉ IP đích bởi bộ 4 của nó  số port đích ˆ Web server có các ˆ host nhận dùng cả 4 giá socket khác nhau cho mỗi trị trên để điều hướng kết nối từ client đoạn đến socket thích  kết nối HTTP không bền hợp vững sẽ có socket khác nhau cho mỗi yêu cầu Lớp Transport 13
  14. Demultiplexing hướng kết nối (tt) P1 P4 P5 P6 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 client DP: 80 server DP: 80 Client IP: A S-IP: A IP: C S-IP: B IP:B D-IP:C D-IP:C Lớp Transport 14
  15. Demultiplexing hướng kết nối: Threaded Web Server P1 P4 P2 P1P3 SP: 5775 DP: 80 S-IP: B D-IP:C SP: 9157 SP: 9157 client DP: 80 server DP: 80 Client IP: A S-IP: A IP: C S-IP: B IP:B D-IP:C D-IP:C Lớp Transport 15
  16. 3.3 Vận chuyển không kết nối: UDP Lớp Transport 16
  17. 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  vận chuyển không thứ tự kế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 Lớp Transport 17
  18. 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ả ˆ ngoà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 Lớp Transport 18
  19. 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 toán checksum của đoạn như một chuỗi các số đã nhận nguyên 16-bit ˆ kiểm tra giá trị trên có bằng ˆ checksum: bổ sung(tổng với giá trị trong trường bù 1) của các nội dung checksum: đ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 . Lớp Transport 19
  20. 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 Lớp Transport 20
  21. 3.4 Các nguyên lý của việc truyền dữ liệu tin cậy Lớp Transport 21
  22. 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) Lớp Transport 22
  23. 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) Lớp Transport 23
  24. 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) Lớp Transport 24
  25. 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 bởi rdt để truyền dữ liệu đến cao 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_rcv(): được gọi khi gói đến rdt, để truyền các gói trên kênh bên nhận kênh không tin cậy đến nơi nhận Lớp Transport 25
  26. Truyền dữ liệu tin cậy Sẽ: ˆ chỉ xem xét truyền dữ liệu theo 1 hướng duy nhất  nhưng điều khiển luồ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 trthái trthái sự kiện thái kế tiếp duy nhất 1 2 được xác định bởi sự các hành động kiện kế tiếp Lớp Transport 26
  27. Rdt1.0: truyền dữ liệu tin cậy trên 1 kênh truyền tin cậy ˆ kênh ưu tiên tin cậy hoàn toà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 ưu tiên  bên nhận nhận dữ liệu từ kênh ưu tiên chờ gọi rdt_send(data) chờ gọi rdt_rcv(packet) từ lớp từ lớp extract (packet,data) trên packet = make_pkt(data) dưới deliver_data(data) udt_send(packet) bên gửi bên nhận Lớp Transport 27
  28. Rdt2.0: kênh với các lỗi ˆ kênh ưu tiên có thể bật lên một số bit trong gói  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 Lớp Transport 28
  29. 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 udt_send(sndpkt) corrupt(rcvpkt) NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) 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) Lớp Transport 29
  30. 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 dưới hoặc udt_send(sndpkt) corrupt(rcvpkt) NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) chờ gọi từ Λ lớp dưới rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Lớp Transport 30
  31. 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 udt_send(sndpkt) corrupt(rcvpkt) NAK udt_send(NAK) rdt_rcv(rcvpkt) && isACK(rcvpkt) chờ gọi từ Λ lớp dưới rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) Lớp Transport 31
  32. 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êngử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 mỗi gói truyền lại: khả năng trùng ˆ bên nhận hủy (không nhận) lặp 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 Lớp Transport 32
  33. 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 isNAK(rcvpkt) ) từ lớp trên hoặc NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Λ Λ chờ ACK chờ gọi 1 hoặc NAK từ 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) Lớp Transport 33
  34. 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) udt_send(sndpkt) Lớp Transport 34
  35. 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 Lớp Transport 35
  36. 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 Lớp Transport 36
  37. 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) || Λ 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) Lớp Transport 37
  38. rdt3.0: các kênh với lỗi và mất mát Giả định mới: kênh ưu tiên Cách tiếp cận: bên gửi chờ cũng có thể làm mất ACK trong khoảng thời các gói (dữ liệu hoặc gian “chấp nhận được” cá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 ˆ nếu gói (hoặc ACK) chỉ trễ sẽ 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 Lớp Transport 38
  39. 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 Λ Λ 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) Λ rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum) isACK(rcvpkt,0) ) udt_send(sndpkt) start_timer Λ Lớp Transport 39
  40. hành động của rdt3.0 Lớp Transport 40
  41. hành động của rdt3.0 Lớp Transport 41
  42. Hiệu suất của rdt3.0 ˆ rdt3.0 làm việc được, nhưng đánh giá hiệu suất hơi rắc rối ˆ 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) 8kb/pkt T ề = = = 8 microsec truy n R (tốc độ truyền, bps) 10 9 b/sec  U sender: độ khả dụng – L / R .008 U = = = 0.00027 sender RTT + L / R 30.008  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ý! Lớp Transport 42
  43. 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 Lớp Transport 43
  44. 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, Lặp có lựa chọn Lớp Transport 44
  45. 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 Lớp Transport 45
  46. 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ổ Lớp Transport 46
  47. 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++ } Λ 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 Lớp Transport 47
  48. GBN: bên nhận mở rộng FSM default udt_send(sndpkt) rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) Λ && 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 với số thứ tự xếp hạng cao nhất Lớp Transport 48
  49. GBN hoạt động Lớp Transport 49
  50. 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 Lớp Transport 50
  51. Lặp có lựa chọn: các cửa sổ gửi, nhận Lớp Transport 51
  52. Lặp có lựa chọn Gửi Nhận 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 trong cửa sổ, gửi gói ˆ gửi ACK(n) timeout(n): ˆ không thứ tự: đệm (buffer) ˆ có thứ tự: truyền (cũng ˆ gửi lại gói n, tái khởi tạo bộ truyền các gói đã đệm, có định thì thứ tự), dịch chuyển cửa sổ ACK(n) trong đến gói chưa nhận kế tiếp [sendbase,sendbase+N]: gói n trong [rcvbase-N,rcvbase- ˆ ấ ậ đánh d u gói n là đã nh n 1] ˆ nếu gói không ACK có n nhỏ ˆ ACK(n) nhất, dịch chuyển cửa sổ base đến số thứ tự không ngược lại: ACK kế tiếp ˆ lờ đi Lớp Transport 52
  53. Hoạt động của lặp có lựa chọn Lớp Transport 53
  54. Lặp có lựa chọn: tình trạng 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ổ? Lớp Transport 54
  55. 3.5 Vận chuyển hướng kết nối: TCP Lớp Transport 55
  56. 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 trong cùng một kết nối ˆ tin cậy, dòng byte có  MSS: maximum segment thứ tự: 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: ˆ kênh liên lạc:  bắt tay (trao đổi các  TCP điều khiển luồng và thông điệp điều khiển) tắc nghẽn, thiết lập kích trạng thái bên gửi, bên thước cửa sổ nhận trước khi trao đổi dữ liệu ˆ ộ ệ ử ậ các b đ m g i & nh n ˆ điều khiển luồng: application application writes data reads data  bên gửi sẽ không lấn át socket socket door door bên nhận TCP TCP send buffer receive buffer segment Lớp Transport 56
  57. TCP: cấu trúc đoạn 32 bits URG: dữ liệu khẩn cấp port # nguồn port # đích đếm bởi số byte (thường không dùng) của dữ liệu số thứ tự ACK: ACK # hợp lệ số ACK head not ử ổ ậ PSH: push data now len usedUAPRSF c a s nh n số byte bên (thường không dùng) checksum con trỏ URG nhận sẵn ấ RST, SYN, FIN: Tùy chọn (độ dài thay đổi) sàng ch p thiết lập kết nối nhận (các lệnh thiết lập, chia nhỏ) dữ liệu ứng dụng Internet (độ dài thay đổi) checksum (giống UDP) Lớp Transport 57
  58. Các số thứ tự TCP và ACK Các số thứ tự: Host A Host B  dòng byte “đánh User số” byte đầu tiên Seq= 42, AC nhập K=79 ữ ệ ủ , data trong d li u c a ‘C’ = ‘C’ đoạn host ACKs báo nhận các ACK: ‘C’ ata = ‘C’, phản hồi 43, d CK= ượ ạ  số thứ tự của byte 79, A ng c l i ‘C’ Seq= kế tiếp được chờ đợi từ phía bên kia host ACKs  ACK tích lũy nhận phản hồi S eq=43 ‘C’ , ACK Hỏi: làm thế nào bên nhận =80 quản lý các đoạn không thứ tự time  Trả lời: TCP không tình huống telnet đơn giản đề cập, tùy thuộc ườ ệ ự ng i hi n th c Lớp Transport 58
  59. TCP Round Trip Time vàTimeout Hỏi: Làm thế nào để Hỏi : Làm thế nào để thiết lập thiết 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, muốn ước  truyền lại không cần ượ ượ ơ thiết l ng RTT “m t h n”  ộ ố ị ˆ quá dài: phản ứng chậm tính trung bình m t s giá tr ượ ầ ỉ đối với việc mất mát gói đo đ c g n đó, không ch SampleRTT hiện tại Lớp Transport 59
  60. TCP Round Trip Time và Timeout EstimatedRTT = ( α)*EstimatedRTT + α*SampleRTT ˆ giá trị đặc trưng: α = 0.125 Lớp Transport 60
  61. Ví dụ đánh giá RTT: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 300 250 RTT (milliseconds)RTT 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT Lớp Transport 61
  62. TCP Round Trip Time và Timeout Thiết lập timeout ˆ EstimtedRTT cộng “hệ số dự trữ an toàn”  sự biến thiên lớn trong EstimatedRTT -> hệ số dự trữ an toà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 Lớp Transport 62
  63. TCP: truyền dữ liệu tin cậy ˆ TCP tạo dịch vụ rdt ˆ Truyền lại được kích trên dịch vụ không tin hoạt bởi: cậy IP  các sự kiện timeout ˆ các đoạn Pipelined  các ack trùng lặp ˆ các ACK tích lũy ˆ lúc đầu khảo sát các bên gửi TCP đơn giản: ˆ TCP dùng bộ định thì truyền lại đơn  lờ đi các ack trùng lặp  lờ đi điều khiển luồng, điều khiển tắc nghẽn Lớp Transport 63
  64. TCP các sự kiện: dữ liệu đã nhận từứng timeout: dụng: ˆ gửi lại đoạn nào gây ra ˆ tạo đoạn với số thứ tự timeout của nó ˆ khởi động lại bộ định ˆ số thứ tự là số theo thì byte dữ liệu đầu tiên Ack đã nhận: ˆ khởi động bộ định thì  cập nhật cái gì sẽ được nếu chưa chạy ACK ˆ khoảng thời gian hết  khởi động bộ định thì nếu có các đoạn còn chờ hạn: TimeOutInterval Lớp Transport 64
  65. NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { TCP switch(event) ử event: data received from application above bên g i create TCP segment with sequence number NextSeqNum (đơn giản) if (timer currently not running) start timer pass segment to IP Chú thích: NextSeqNum = NextSeqNum + length(data) • SendBase-1: byte event: timer timeout vừa được ACK retransmit not-yet-acknowledged segment with tích lũy smallest sequence number Ví dụ: start timer • SendBase-1 = 71; y= 73, vì thế bên nhận event: ACK received, with ACK field value of y muốn 73+ ; if (y > SendBase) { y > SendBase, vì thế SendBase = y dữ liệu mới được if (there are currently not-yet-acknowledged segments) start timer chấp nhận } } /* end of loop forever */ Lớp Transport 65
  66. ền lại ống truy Host B Host A TCP: các tình hu Seq=92, 8 bytes data Host B Seq=100, 20 bytes data Host A 0 10 20 Seq=92, 8 bytes data = 1 K = C K A AC 00 =1 K timeout Seq=92 AC Seq=92, 8 bytes data X 0 timeout Sendbase 2 loss =1 = 100 CK Seq=92, 8 bytes data SendBase A = 120 00 timeout Seq=92 =1 ớm CK A SendBase timeout s = 120 66 time Lớp Transport SendBase = 100 ất ACK ống m time tình hu
  67. ền lại (tt) ống truy TCP: các tình Hosthu B Host A Seq=92, 8 bytes data 0 10 K= AC Seq=100, 20 bytes data X timeout loss 0 12 K= AC SendBase = 120 67 ũy Lớp Transport time ống ACK tích l tình hu
  68. TCP sinh ra ACK [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. Tất cả dữ liệu đến cho đoạn kế tiếp. Nếu không có đoạn đã được ACK 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, chấp nhận mong muốn. Một đoạn khác đang cho cả các đoạn theo thứ tự 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 Gửi ngay ACK, với điều kiện là đoạn lấp đầy từng phần hoặc toàn bộ bắt đầu ngay điểm có khoảng trống khoảng trống Lớp Transport 68
  69. Truyền lại nhanh ˆ Chu kỳ Time-out ˆ Nếu bên gửi nhận 3 ACK thường tương đối dài: của cùng một dữ liệu, nó  độ trễ dài trước khi gửi cho là đoạn sau dữ liệu lại 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 đoạn trước khi bộ định thì trùng 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 Lớp Transport 69
  70. 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 Lớp Transport 70
  71. TCP điều khiển luồng điều khiển luồng bên gửi sẽ không làm ˆ bên nhận của kết nối tràn bộ đệm vì truyền TCP có một bộ đệm quá nhiều và quá nhanh nhận: ˆ 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 Lớp Transport 71
  72. TCP điều khiển luồng: cách làm? ˆ Bên nhận thông báo khoảng dự trữ nhờ giá trị RcvWindow trong các đoạn ˆ Bên gửi hạn chế dữ liệu (Giả sử bên nhận TCP loại bỏ không được ACK vào các đoạn không có thứ tự) RcvWindow ˆ dự phòng trong bộ đệm  bảo đảm bộ đệm nhận = RcvWindow không tràn = RcvBuffer-[LastByteRcvd - LastByteRead] Lớp Transport 72
  73. TCP quản lý kết nối Chú ý: Bên gửi và bên nhận 3 phương pháp bắt tay: TCP 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 ˆ khởi tạo các biến TCP: SYN đến server  ị ố ứ ự ở ầ  các số thứ tự đoạn xác đ nh s th t kh i đ u  ả ữ ệ  thông tin các bộ đệm, không ph i d li u điều khiển luồng (như Bước 2: server host nhận SYN, RcvWindow) trả lời với đoạn SYNACK ˆ ườ ở ướ ế client: ng i kh i x ng k t  server cấp phát các bộ nối đệm Socket clientSocket = new Socket("hostname","port  xác định số thứ tự khởi đầu number"); Bước 3: client nhận SYNACK, trả lời với đoạn ACK (có thể chứa ˆ server: được tiếp xúc bởi dữ liệu) client Socket connectionSocket = welcomeSocket.accept(); Lớp Transport 73
  74. TCP quản lý kết nối (tt) Đóng một kết nối: client server đóng client đóng socket: FIN clientSocket.close(); CK Bước 1: client gửi đoạn điều A đóng khiển TCP FIN đến server FIN Bước 2: server nhận FIN, trả ờ A lời với ACK. Đóng kết nối, CK gửi FIN. i gian ch thờ đã đóng Lớp Transport 74
  75. 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 FIN  Trong khoảng “thời gian chờ”–sẽ phản hồi với ACK để nhận các FIN CK A đang đóng IN Bước 4: server, nhận ACK. F Kết nối đã đóng. ờ ACK Chú ý: với một sửa đổi nhỏ, đã đóng có thể quản lý nhiều FIN i gian ch đồng thời. thờ đã đóng Lớp Transport 75
  76. 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 Lớp Transport 76
  77. 3.6 Các nguyên lý của điều khiển tắc nghẽn Lớp Transport 77
  78. 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 luồ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! Lớp Transport 78
  79. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 1 Host A λ λ : original data out ˆ 2 gửi, 2 nhận in ˆ 1 router, các bộ Host B unlimited shared đệm không giới hạn output link buffers ˆ không có truyền lại ˆ các độ trễ lớn hơn khi tắc nghẽn ˆ năng suất có thể đạt tối đa Lớp Transport 79
  80. 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 λ λin : dữ liệu gốc out λ'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 Lớp Transport 80
  81. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 2 ˆ luôn luôn: λ = λ in out ˆ truyền lại “hoàn toàn” chỉ khi mất mát: λ > λ in out ˆ truyền lại vì trễ (không mất) làm cho λ lớn hơn với cùng in λ out R/2 R/2 R/2 R/3 out out out R/4 λ λ λ R/2 R/2 R/2 λin λin λin 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 Lớp Transport 81
  82. 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 λ và λ in in ˆ các đường qua nhiều hop tăng lên? ˆ timeout/truyền lại Host A λout λin : dữ liệu gốc λ'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 Lớp Transport 82
  83. Các nguyên nhân/chi phí của tắc nghẽn: tình huống 3 H λ o s o u t A t H o s t B “chi phí” khác của tắc nghẽn: ˆ khi các gói bị bỏ, bất kỳ “khả năng truyền upstream dùng cho gói đósẽ bị lãng phí!” Lớp Transport 83
  84. 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 end- điều khiển tắc nghẽn có sự end: hỗ trợ của mạng: ˆ không có phản hồi rõ ràng ˆ các router cung cấp phản từ mạng hồi về các hệ thống đầu cuối ˆ tắc nghẽn được suy ra từ  1 bit duy nhất chỉ thị tắc việc quan sát các hệ thống nghẽn (SNA, DECbit, đầu cuối có mất mát, trễ TCP/IP ECN, ATM) ˆ tiếp cận được quản lý bởi  tốc độ sẽ gửi được xác TCP định rõ ràng Lớp Transport 84
  85. Ví dụ: điều khiển tắc nghẽn ATM ABR ABR: tốc độ bit sẵn RM (resource management): sàng: ˆ gửi bởi bên gửi, rải rác với các ô ˆ “dịch vụ mềm dẻo” dữ liệu ˆ nếu đường gửi “chưa hết”: ˆ các bit trong ô thiết lập bởi các switch  bên gửi sẽ dùng băng thông sẵn sàng  bit NI : không tăng tốc độ ắ ẽ ẹ ˆ nếu đường gửi tắc nghẽn: (t c ngh n nh )  bit CI : tắc nghẽn rõ rệt  bên gửi điều tiết với tốc độ tối thiểu ˆ Các ô RM được trả về bên gửi từ bên nhận với nguyên vẹn các bit Lớp Transport 85
  86. Ví dụ: điều khiển tắc nghẽn ATM ABR ˆ trường 2-byte ER trong ô RM  switch đã tắc nghẽn có thể có giá trị ER thấp hơn trong ô  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 ô dữ liệu đứng trước ô RM có cài EFCI, bên gửi sẽ cài bit CI trong ô RM trả về Lớp Transport 86
  87. 3.7 Điều khiển tắc nghẽn TCP Lớp Transport 87
  88. TCP điều khiển tắc nghẽn: additive tăng lên, multiplicative giảm xuống ˆ Cách tiếp cận: tăng tốc độ truyền (kích thước cửa sổ), tìm khả năng băng thông có thể, cho đến khi có mất mát xảy ra  additive tăng lên: tăng CongWin bởi 1 MSS mỗi RTT cho đến khi có mất mát xảy ra  multiplicative giảm xuống: bỏ CongWin trong nửa giai đoạn sau khicongestion mất mát window 24 Kbytes Tìm kiếm ổ a s băng thông n ẽ 16 Kbytes c cử ướ c ngh ắ t 8 Kbytes time kích th time Lớp Transport 88
  89. TCP điều khiển tắc nghẽn: chi tiết ˆ bên gửi hạn chế việc truyền: Làm thế nào bên gửi nhận LastByteSent-LastByteAcked biết tắc nghẽn? ≤ CongWin ˆ mất mát xảy ra = ặ ˆ Công thức, timeout ho c 3 ack trùng lặp CongWin tốc độ = Bytes/s ˆ bên gửi giảm tốc độ RTT (CongWin) sau khi mất ˆ CongWin thay đổi, chức năng là mát xảy ra nhận biết tắc nghẽn trên mạng 3 cơ chế:  AIMD  khởi động chậm  thận trọng sau khi có các sự kiện timeout Lớp Transport 89
  90. TCP khởi động chậm ˆ Khi kết nối bắt đầu, ˆ Khi kết nối bắt đầu, tăng CongWin = 1 MSS tốc lên rất nhanh cho  Ví dụ: MSS = 500 bytes & đến khi sự cố mất mát RTT = 200 ms xảy ra đầu tiên  tốc độ khởi tạo = 20 kbps ˆ băng thông sẵn sàng có thể >> MSS/RTT  mong muốn nhanh chóng tăng tốc lên tốc độ có thể đáp ứng Lớp Transport 90
  91. TCP khởi động chậm (tt) ˆ Khi kết nối bắt đầu, Host A Host B tăng tốc lên rất nhanh cho đến khi sự cố mất 1 đoạn mát xảy ra đầu tiên: RTT  nhân đôi CongWin mỗi 2 đoạn RTT  hoàn thành nhờ tăng CongWin ứng với mỗi 4 đoạn ACK đã nhận ˆ Tổng kết: tốc độ khởi đầu là chậm nhưng sau đó tăng tốc rất nhanh thời gian Lớp Transport 91
  92. Tinh chế Hỏi: Khi nào việc tăng tốc trở thành tuyến tính? Trả lời: Khi CongWin đạt đến 1/2 giá trị của nó trước khi timeout. Hiện thực: ˆ Ngưỡng thay đổi ˆ Tại thời điểm có sự cố mất mát, ngưỡng được cài giá trị bằng ½ của CongWin ngay trước đó Lớp Transport 92
  93. Tinh chế: nhận biết mất mát ˆ Sau 3 ACK trùng lặp:  CongWin sẽ giảm 1/2 Nguyên lý:  kích thước cửa sổ tăng tuyến tính ‰3 ACK trùng nhau chỉ ra ˆ nhưng sau sự cố timeout: khả năng truyền của mạng ‰ timeout chỉ thị “nhiều  CongWin thay giá trị cảnh báo” về tình huống bằng 1 MSS; tắc nghẽn  kích thước cửa sổ tăng cấp lũy thừa  khi đến một ngưỡng thì tăng tuyến tính Lớp Transport 93
  94. Tổng kết: TCP điều khiển tắc nghẽn ˆ Khi CongWin dưới Threshold, bên gửi đang trong giai đoạn khởi động chậm, kích thước cửa sổ tăng nhanh theo cấp lũy thừa. ˆ Khi CongWin trên Threshold, bên gửi đang trong giai đoạn tránh tắc nghẽn, kích thước cửa sổ tăng nhanh theo cấp tuyến tính. ˆ Khi có 3 ACK trùng lặp xảy ra, Threshold = CongWin/2 và CongWin = Threshold. ˆ Khi timeout xảy ra, Threshold = CongWin/2 và CongWin = 1 MSS. Lớp Transport 94
  95. TCP điều khiển tắc nghẽn bên gửi Trạng thái Sự kiệnTCP bên gửi hành động Diễn giải Slow Start ACK báo CongWin = CongWin + MSS, Hậu quả làm tăng gấp đôi (SS)-Khởi nhận cho dữ If (CongWin > Threshold) CongWin mỗi RTT động chậm liệu chưa cài đặt trạng thái “Tránh tắc ACK trước nghẽn” đó Congestion ACK báo CongWin = CongWin+MSS * Additive tăng lên, làm tăng Avoidance nhận cho dữ (MSS/CongWin) CongWin lên 1 MSS mỗi (CA) –Tránh liệu chưa RTT tắc nghẽn ACK trước đó SS hoặc CA Sự cố mất Threshold = CongWin/2, Khôi phục nhanh, hiện thực mát xảy ra CongWin = Threshold, giảm xuống multiplicative. khi thấy có 3 cài đặt trạng thái “Tránh tắc CongWin sẽ không giảm ACK trùng nghẽn” xuống dưới 1 MSS. lặp SS hoặc CA Timeout Threshold = CongWin/2, Vào chế độ “Khởi động CongWin = 1 MSS, chậm” cài đặt trạng thái “Khởi động chậm” SS hoặc CA ACK trùng Đếm ACK tăng lên cho đoạn CongWin và Threshold lặp vừa được ACK không thay đổi Lớp Transport 95
  96. TCP throughput ˆ Throughout trung bình của TCP biểu diễn qua kích thước của sổ và RTT?  Bỏ qua trạng thái “Khởi động chậm” ˆ Cho W là kích thước cửa sổ khi có mất mát xảy ra. ˆ Khi kích thước cửa sổ = W, lưu lượng = W/RTT ˆ Chỉ ngay sau khi mất mát, cửa sổ giảm xuống = W/2, lưu lượng = W/2RTT. ˆ throughout trung bình: 0.75 W/RTT Lớp Transport 96
  97. TCP tương lai ˆ Ví dụ: các đoạn dài 1500 byte, RTT 100ms, lưu lượng 10 Gbps ˆ Kích thước cửa sổ yêu cầu W = 83,333 đoạn trên đường truyền ˆ Lưu lượng trong các trường hợp mất mát: 1 . 22⋅ MSS RTT L ˆ ➜ L = 2·10-10 ˆ Phiên bản mới của TCP dành cho nhu cầu tốc độ cao! Lớp Transport 97
  98. 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 Lớp Transport 98
  99. Tại sao phải TCP công bằng? 2 phiên làm việc cạnh tranh nhau: ˆ Additive tăng, lưu lượng tăng ˆ multiplicative giảm lưu lượng tương xứng R chia sẻ băng thông bằng nhau t u p h g u o r mất mát: giảm cửa sổ bằng 1/2 h t tránh tắc nghẽn: additive tăng lên 2 ấ ả ử ổ ằ m t mát: gi m c a s b ng 1/2 n ắ ẽ o tránh t c ngh n: additive tăng lên i t c e n n o C Connection 1 throughput R Lớp Transport 99
  100. TCP: tính công bằng (tt) Tính công bằng & UDP Tính công bằng & các kết nối TCP song song ˆ nhiều ứng dụng thường không dùng TCP ˆ không có gì ngăn cản việc  không muốn tốc độ bị ứng dụng mở các kết nối điều tiết do điều khiển song song giữa 2 host. tắc nghẽn ˆ Trình duyệt Web làm giống ˆ Thay bằng dùng UDP: như thế  truyền audio/video với ˆ Ví dụ: tốc độ R hỗ trợ 9 tốc độổn định, chịu ế ố được mất mát k t n i ;  ứng dụng mới yêu cầu 1 TCP, ˆ Nghiên cứu: giao thức có tốc độ R/10 thân thiện với TCP  ứng dụng mới yêu cầu 11 TCP, có tốc độ R/2 ! Lớp Transport 100
  101. Mô hình trễ Notation, các giả định: ỏ ấ ể ậ H i: M t bao lâu đ nh n 1 ˆ Giả sử một kết nối giữa đối tượng từ Web server client và server có tốc độ R sau khi gửi yêu cầu? ˆ S: MSS (bits) Bỏ qua tắc nghẽn, trễ bịảnh ˆ O: kích thước đối tượng hưởng bởi: (bits) ˆ thiết lập kết nối TCP ˆ không truyền lại (không mất mát, không hỏng) ˆ trễ truyền dữ liệu ˆ khởi động chậm Kích thước cửa sổ: ˆ Giả định 1: cửa sổ tắc nghẽn cố định, có W đoạn ˆ Sau đócửa sổ thay đổi, mô hình khởi động chậm Lớp Transport 101
  102. Cửa sổ tắc nghẽn cố định (1) Trường hợp đầu tiên: WS/R > RTT + S/R: cho đoạn đầu tiên trong cửa sổ trả về trước khi cửa sổ dữ liệu gửi ACK trễ = 2RTT + O/R Lớp Transport 102
  103. Cửa sổ tắc nghẽn cố định (2) Trường hợp thứ hai: ˆ WS/R < RTT + S/R: sent chờ cho ACK sau khi gửi dữ liệu trễ = 2RTT + O/R + (K-1)[S/R + RTT - WS/R] Lớp Transport 103
  104. TCP Mô hình trễ: Khởi động chậm (1) Bây giờ giả sử kích thước cửa sổ tăng lên tùy theo quá trình khởi động chậm Độ trễ của một đối tượng sẽ là: O ⎡ S ⎤ P S Latency=2RTT +P + RTT ( +− 2 − 1 ) R ⎣⎢ R⎦⎥ R trong đsà l óPố lần TCP rảnh ở tại server: PQKmin= { ,− 1 } - trong àsđ l óQố lần server rảnh nếu đối tượng đã khởi tạo kích thước - và K là số lượng cửa sổ bao trùm đối tượng Lớp Transport 104
  105. TCP Mô hình trễ: Khởi động chậm (2) initiate TCP Các thành phần trễ: connection • 2 RTT dành cho thiết lập kết nối và yêu cầu request object • O/R để truyền đối first window tượng = S/R RTT •thời gian server rảnh second window bởi vì khởi động chậm = 2S/R third window Server rảnh: = 4S/R P = min{K-1,Q} lần fourth window Ví dụ: = 8S/R • O/S = 15 đoạn •K = 4 cửa sổ •Q = 2 complete • P = min{K-1,Q} = 2 object transmission delivered time at Server rảnh P=2 lần time at server client Lớp Transport 105
  106. TCP Mô hình trễ(3) S time+RTTserver = from starts when to send segment R untilreceives acknowledg server ement initiate TCP connection k −1 S time2 = tothe kthtransmit window request R object first window = S/R + RTT ⎡ S k −1 S ⎤ second window 2 idle⎢ +RTT − time⎥ = after thek th window = 2S/R ⎣ R R ⎦ third window = 4S/R O P delay= +2RTT + idleTime fourth window ∑ p = 8S/R R p=1 O P S S = +2RTT +∑ [ RTT +2k −1 − ] R k =1 R R complete object transmission delivered O S P S = +2RTT + [ P RTT + ] ( − 2 1 − ) time at time at server R R R client Lớp Transport 106
  107. TCP Mô hình trễ (4) K = số lượng cửa sổ bao trùm đối tượng Làm thế nào tính được K ? 0 1 k −1 Kmin= { k :+ 2 S + 2L S +SO 2 ≥ } 0 1 k −1 min= {k :+ 2 + 2L +OS 2 ≥ / } O min= {k :k− 2 ≥ 1 } S O min= {k :≥ k log + ( 1 )} 2 S ⎡ O ⎤ =log⎢ 2 ( + ⎥ 1 ) ⎢ S ⎥ cách tính toán Q tương tự (xem HW). Lớp Transport 107
  108. HTTP Mô hình ˆ Giả sử trang Web chứa:  1 trang HTML (kích thước O bits)  M hình ảnh (mỗi cái kích thướcO bits) ˆ HTTP không bền vững:  M+1 TCP kết nối  Thời gian đáp ứng = (M+1)O/R + (M+1)2RTT + tổng số thời gian rảnh ˆ HTTP bền vững:  2 RTT để yêu cầu và nhận file HTML  1 RTT để yêu cầu và nhận M hình ảnh  Thời gian đáp ứng = (M+1)O/R + 3RTT + tổng số thời gian rảnh ˆ HTTP không bền vững với X kết nối song song  Giả sử M/X là số nguyên.  1 TCP kết nối cho file  M/X thiết lập các kết nối song song cho các hình ảnh  Thời gian đáp ứng = (M+1)O/R + (M/X + 1)2RTT + tổng số thời gian rảnh Lớp Transport 108
  109. HTTP thời gian đáp ứng (giây) RTT = 100 msec, O = 5 Kbytes, M=10 và X=5 20 18 16 14 non-persistent 12 10 persistent 8 6 4 parallel non- persistent 2 0 28 100 1 10 Kbps Kbps Mbps Mbps Với băng thông thấp, thời gian kết nối & đáp ứng trội hơn thời gian truyền Các kết nối bền vững chỉ cho sự cải thiện không đáng kể trên các kết nối song song Lớp Transport 109
  110. HTTP thời gian đáp ứng (giây) RTT =1 sec, O = 5 Kbytes, M=10 and X=5 70 60 50 non-persistent 40 30 persistent 20 parallel non- 10 persistent 0 28 100 1 10 Kbps Kbps Mbps Mbps Với RTT lớn hơn, thời gian đáp ứng trội hơn thời gian trễ chờ thiết lập kết nối TCP & khởi động chậm. Các kết nối bền vững bây giờ cho thấy cải thiện rõ rệt: đặc biệt với các mạng băng thông cao Lớp Transport 110
  111. Chương 3: Tổng kết ˆ các nguyên lý của các dịch vụ lớp transport  multiplexing, demultiplexing  truyền dữ liệu tin cậy  điều khiển luồng Tiếp theo:  điều khiển tắc nghẽn ˆ nghiên cứu xong các ˆ khởi tạo và hiện thực trong vấn đề “ngoài biên” Internet (các lớp application,  UDP transport)  TCP ˆ chuẩn bị vào phần “lõi” của mạng Lớp Transport 111