Tóm tắt nội dung—Trong bài báo này, tôi đã tìm hiểu hoạt động của giao thức TCP NewReno tại lớp truyền vận đồng thời là phân tích hiệu năng (thông lượng) của một hệ thống tự đề xuất . Dựa trên những nghiên cứu về mô hình hoạt động có sẵn của giao thức TCP, tôi sẽ đi sâu vào những điểm mà giao thức TCP NewReno tập trung cải tiến. Dựa trên phương thức hoạt động của TCP Reno tôi sẽ chỉ ra giao thức TCP NewReno đã cải thiện so với các phiên bản trước đó là quá trình Phục hồi nhanh, cũng là vấn đề chính được nói đến ở đây. Để phân tích hiệu năng (thông lượng) một hệ thống tự đề xuất, tôi sử dụng một hệ thống có sẵn, về mặt lý thuyết là đã phân tích. Trong đó, chuỗi Markov và phân tích lý thuyết có thể được áp dụng. Tôi phân tích lấy ra thông số để chỉ ra mức độ hiệu quả và tính đúng đắn của phân tích lý thuyết. Hơn nữa, có thể xác định rõ yếu tố nào đóng vai trò cho hiệu suất của TCP New Reno. Kết luận này là cực kỳ quan trọng đối với nghiên cứu cải thiện hiệu suất TCP sau này.
Tìm hiểu hoạt động giao thức TCP-NewReno lớp truyền vận Tien-Anh Vu CTCLC-HTTT&TT-K62 Hanoi University of Science and Technology Hanoi, Vietnam anh.vt172955@sis.hust.edu.vn Tóm tắt nội dung—Trong báo này, tơi tìm hiểu hoạt động giao thức TCP NewReno lớp truyền vận đồng thời phân tích hiệu (thơng lượng) hệ thống tự đề xuất Dựa nghiên cứu mô hình hoạt động có sẵn giao thức TCP, tơi sâu vào điểm mà giao thức TCP NewReno tập trung cải tiến Dựa phương thức hoạt động TCP Reno giao thức TCP NewReno cải thiện so với phiên trước q trình Phục hồi nhanh, vấn đề nói đến Để phân tích hiệu (thơng lượng) hệ thống tự đề xuất, tơi sử dụng hệ thống có sẵn, mặt lý thuyết phân tích Trong đó, chuỗi Markov phân tích lý thuyết áp dụng Tơi phân tích lấy thơng số để mức độ hiệu tính đắn phân tích lý thuyết Hơn nữa, xác định rõ yếu tố đóng vai trị cho hiệu suất TCP New Reno Kết luận quan trọng nghiên cứu cải thiện hiệu suất TCP sau Từ khóa: Transport Layer, TCP, TCP Performance, TCP NewReno, TCP Reno I GIỚI THIỆU CHUNG Các thuật tốn TCP cổ điển tiêu chuẩn đóng góp to lớn vào hoạt động TCP, nhiệm vụ chúng giải vấn đề sụp đổ tắc nghẽn Internet Tuy nhiên, số lĩnh vực cần cải thiện đáng kể Với phổ biến TCP, ngày có nhiều nỗ lực nhằm đảm bảo TCP hoạt động tốt nhiều điều kiện Bây số tìm thấy nhiều triển khai TCP ngày Một vấn đề với khơi phục nhanh nhiều gói bị rơi cửa sổ liệu, gói khôi phục (tức phân phối thành công ACKed), ACK tốt nhận người gửi gây lạm phát cửa sổ tạm thời q trình khơi phục nhanh xóa trước tất gói bị truyền lại ACK kích hoạt hành vi gọi ACK phần TCP Reno phản ứng với ACK phần cách giảm cửa sổ tắc nghẽn tăng cao mà không hoạt động hẹn truyền lại kích hoạt Để giải thích cho điều này, nhớ lại TCP (không phải SACK) phụ thuộc vào tín hiệu ba ACK (hoặc lặp lại) trùng lặp để kích hoạt quy trình truyền lại nhanh Nếu khơng có đủ gói mạng, khơng thể kích hoạt quy trình gói, cuối dẫn đến hết hạn đếm thời gian truyền lại yêu cầu thủ tục khởi động chậm, điều ảnh hưởng nghiêm trọng đến hiệu suất thông lượng TCP Để giải vấn đề với Reno, sửa đổi có tên NewReno [RFC 3782] phát triển Quy trình điều chỉnh khả khơi phục nhanh cách theo dõi số thứ tự cao từ cửa số liệu truyền cuối Chỉ nhận ACK có số ACK điểm khơi phục lạm phát việc phục hồi nhanh loại bỏ Điều cho phép TCP tiếp tục gửi phân đoạn cho ACK mà nhận khơi phục giảm xuất thời gian chờ truyền lại, đặc biệt nhiều gói bị bỏ cửa sổ liệu NewReno không gặp phải vấn đề khơi phục nhanh ban đầu thực phức tạp đáng kể so với SACK Tuy nhiên, với SACKs, TCP hoạt động tốt NewReno nhiều gói bị cửa sổ liệu, thực điều đòi hỏi cần ý đến thủ tục kiểm soát tắc nghẽn Ý tưởng hình thành mơ hình TCP/IP bắt nguồn từ Bộ giao thức liên mạng cơng trình DARPA vào năm 1970 trải qua vô số năm nghiên cứu phát triển kỹ sư Robert E Kahn Vinton Cerf hỗ trợ khơng nhóm nghiên cứu Đầu năm 1978, giao thức TCP/IP ổn định hóa với giao thức tiêu chuẩn dùng Internet mơ hình TCP/IP Version Vào năm 1975, thử nghiệm thông nối mơ hình TCP/IP diễn thành cơng Cũng đây, thử nghiệm thông nối mơ hình TCP/IP diễn nhiều đạt kết tốt Cũng điều này, hội thảo Internet Architecture Broad mở ra, với Hình Mơ hình OSI mơ hình TCP/IP tham dự 250 đại biểu công ty thương mại, từ giao thức mơ hình TCP/IP phổ biến rộng rãi khắp giới Năm 2001, RFC 3168 mô tả chế báo hiệu chống nghẽn mạng có tên Thơng báo nghẽn mạng (Explicit Congestion Notification) Vào thời điểm đầu kỷ 21, khoảng 95% gói tin Internet TCP Các ứng dụng tiêu biểu sử dụng TCP HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (e-mail) FTP (truyền file) Các thuật toán liên quan đến TCP ngày phát triển ứng dụng rộng rãi.Nội dung nghiên cứu báo cáo gồm phần: phần thứ nói hoạt động giao thức TCP-NewReno lớp truyền vận, phần thứ phân tích hiệu suất TCP NewReno qua dặm cuối mạng di động: Suy hao đệm kênh II MÔ HÌNH HỆ THỐNG CỦA TCP TẠI LỚP TRUYỀN VẬN Trước tìm hiểu hoạt động TCP NewReno ta tìm hiểu cấu trúc lớp truyền vận Bộ giao thức TCP/IP(được sử dụng Internet) trước có mơ hình OSI Các tầng giao thức TCP/IP khơng giống hệt tầng mơ hình OSI Bộ giao thức TCP/IP có tầng liên kết liệu, mạng, giao vận, ứng dụng (Hình 1) Tầng giao vận nằm tầng ứng dụng tầng mạng tầng trung tâm kiến trúc phân tầng với nhiệm vụ cung cấp dịch vụ truyền thông tiến trình ứng dụng chạy máy tính khác nhau,trong giao thức tầng giao vận Internet có hai giao thức quan trọng: Transmission Control Protocol (TCP) User Datagram Protocol (UDP) Trong báo nghiên cứu giao thức TCP A Quản lý kết nối TCP Thiết lập kết nối Khi tiến trình muốn tiến hành truyền thơng với tiến trình khác qua mạng sử dụng giao thức TCP phải thông báo cho tầng giao vận để khởi tạo liên kết TCP trình tiến trình khởi tạo liên kết gọi tiến trình khách, tiến trình cịn lại tiếp nhận liên kết TCP gọi tiến trình chủ Bắt tay ba bước: Quá trình thiết lập liên kết TCP hai tiến trình thực ba bước thường gọi trình bắt tay bước (three-way handshake) Hình Cấu trúc TCP Segment Bước Tiến trình khách gửi TCP segment không chứa liệu tới tiến trình chủ, đó, bit SYN = Tiến trình khách chọn giá trị ngẫu nhiên cho trường Sequence (để tránh công loại SYN) Segment loại thường gọi SYN Segment Bước Khi tiến trình chủ nhận SYN segment, bố trí nhớ cho TCP buffer biến trạng thái cho liên kết TCP Tiến trình chủ sau gửi segment trả lời cho tiến trình khách, segment này: bit SYN = 1; số báo nhận (ACK number) = Sequence SYN segment (nhận từ tiến trình khách) + 1; số thứ tự Sequence lựa chọn ngẫu nhiên Segment trả lời thường gọi SYNACK Bước Khi nhận SYNACK Segment, tiến trình khách thiết lập nhớ đệm đến trạng thái cho liên kết TCP, sau gửi lại cho tiến trình chủ Segment, trường số báo nhận ACK = số thứ tự Sequence server + 1, SYN = 0, trường số thứ tự Sequence tăng thêm đơn vị Sau bước này, liên kết TCP hai tiến trình thiết lập Truyền liệu ● ● ● ● ● ● Một số đặc điểm TCP để phân biệt với UDP; Truyền liệu khơng lỗi (do có chế sửa lỗi/truyền lại); Truyền gói liệu theo thứ tự; Truyền lại gói liệu đường truyền; Loại bỏ gói liệu trùng lặp Cơ chế hạn chế tắc nghẽn đường truyền Kết thúc kết nối Để kết thúc kết nối hai bên sử dụng trình bắt tay bước chiều kết nối kết thúc độc lập với Khi bên muốn kết thúc, gửi gói tin FIN bên gửi lại tin báo nhận ACK Vì vậy, trình kết thúc tiêu biểu có cặp gói tin trao đổi Một kết nối tồn dạng "nửa mở": bên kết thúc gửi liệu nên nhận thông tin, bên tiếp tục gửi B Cấu trúc TCP Segment Ý nghĩa trường TCP Segment (Hình 2): ● ● ● ● Source port (16 bit): số cổng tiến trình gửi; Destination port ( 16 bit ): số cổng tiến trình nhận; Sequence number (32 bit): số thứ tự Giá trị ý nghĩa số thứ tự phụ thuộc giá trị bit SYN; Các trường flag ( trường, trường bit ): Bit ACK dùng để xác nhận tính xác giá trị trường Acknowledgement 2 ● ● ● ● Bit RST, SYN, FIN dùng để thiết lập hủy bỏ kết nối Bit PSH định máy nhận phải chuyển liệu lên tầng Bit URG định có vùng liệu đánh dấu “urgent” (dữ liệu khẩn) Nếu URG=1, trường Urgent pointer ( 16 bit ) chứa vị trí byte cuối liệu khẩn; TCP phải thông báo tồn liệu khẩn cho máy nhận, đồng thời chuyển cho máy nhận trỏ tới cuối vùng liệu khẩn Trong thực tế, hai trường PSH URG không sử dụng Checksum ( 16 bit ): sử dụng để kiểm tra lỗi • Window size ( 16 bit ): kích thước cửa sổ dùng kiểm soát luồng Reserved ( bit ): ( Header length) - kích thước TCP header Kích thước TCP header thay đổi tồn môi trường Options Tuy nhiên, trường Options thường để trống, đó, kích thước TCP header thường 20 bytes Acknowledgement number ( 32 bit ): số báo nhận Trường số thứ tự số báo nhận sử dụng để đảm bảo dịch vụ truyền liệu đáng tin cậy Options ( độ dài thay đổi ): sử dụng máy tham gia truyền thơng thỏa thuận kích thước tối đa segment (Maximum segment size: MSS ) hệ số tỉ lệ cửa sổ trượt C Số thứ tự số biên nhận Số biên nhận phức tạp số thứ tự Vì TCP kênh truyền song cơng, nên A nhận liệu từ B, gửi liệu tới B Mỗi segment đến từ máy B có số thứ tự cho dòng liệu từ B sang A Số biên nhận mà máy A đặt segment số thứ tự byte mà máy A chờ máy B gửi tới Để hiểu rõ xét ví dụ sau: Giả sử máy A nhận tất byte từ byte số đến byte số 535 máy B gửi đến giả sử máy A gửi segment tới máy B Trong trường hợp này, máy A đợi byte thứ 536 toàn byte dịng liệu từ máy B Khi máy A đặt giá trị 536 vào trường số biên nhận segment mà gửi tới máy B D Truyền liệu tin cậy TCP tạo đường truyền liệu tin cậy dịch vụ không tin cậy IP Dịch vụ truyền liệu tin cậy TCP đảm bảo dịng liệu tới tiến trình nhận khơng có lỗi, liên tục khơng trùng lặp liệu, thứ tự Có nghĩa dịng byte nhận giống hệt dòng byte gửi Mục nghiên cứu cách thức cung cấp dịch vụ truyền liệu tin cậy TCP người ta thấy dịch vụ truyền liệu tin cậy TCP sử dụng nhiều nguyên lý Để đơn giản, coi kết nối TCP máy A B chuyển liệu từ máy A tới máy B Tại phía gửi (máy A), thực thể TCP lấy liệu tầng ứng dụng đóng gói segment chuyển xuống tầng mạng Do đó, nhận liệu từ tầng ứng dụng, đóng gói liệu segment gửi segment kiện quan trọng mà thực thể TCP bên gửi phải xử lý Ngay sau chuyển segment cho TP,TCP khởi động timer cho segment Thời gian đợi hết (timeout) gây ngắt máy A TCP phản ứng với kiện timeout kiện thứ hai mà bên gửi TCP phải xử lý cách truyền lại gây ngắt thời gian Hai số trường quan trọng TCP segment trường số thứ tự trường số biên nhận Trước nói đến trường cần sử dụng để cung cấp đường truyền liệu tin cậy nào, cần nói đến trường nhận giá trị gì? TCP xem liệu dịng byte khơng có cấu trúc, có thứ tự TCP đánh số thứ tự cho byte dòng liệu Mỗi segment có số thứ tự số thứ tự byte segment Sự kiện thứ ba mà bên gửi TCP phải xử lý nhận segment bên nhận(ACK) từ bên gửi (chính xác segment chứa giá trị trị trường biên nhận ACK hợp lệ) Ở thực thể TCP phía gửi phải định ACK lần nhận (tức bên nhận cho segment gửi chưa biên nhận), ACK trùng lập biên nhận lại gói tic ghi nhận Trong trường hợp thứ nhất, bên gửi biết tất byte có số thứ tự không vượt giá trị bên nhận vừa nhận được gửi thành cơng Khi bên gửi cập nhật biến trạng thái TCP kiểm sốt số thứ tự byte cuối mà cho nhận xác theo thứ tự phía bên nhận Xét ví dụ sau: Giả sử có tiến trình máy A muốn gửi dịng liệu tới tiến trình máy B thơng qua kết nối TCP Thực thể TCP máy A đánh số thứ tự cho byte dòng liệu Giả sử dòng liệu chứa file có kích thước 500 000 byte, giá trị MMS 1000 byte, byte dòng liệu đánh số thứ tự 0.TCP tạo ra 500 segment từ dịng liệu này.Trong hình 3, segment có số thứ tự 0, segment thứ có số thứ tự 1000, segment thứ ba có số thứ tự 2000, Mỗi số thứ chèn vào trường số thứ tự tiêu đề TCP segment tương ứng Để hiểu rõ phản ứng bên gửi nhận ACK trùng lặp, trước tiên phải xét bên nhận gửi ACK trùng lặp Khi nhận ACK có số thứ tự lớn số thứ tự mong đợi bên nhận phát có đoạn trống dịng liệu - nghĩa thiếu segment Vì TCP khơng sử dụng biên nhận phủ định (NAK) nên bên nhận khơng thể gửi biên nhận phủ định thay vào bên nhận lại byte thứ tự cuối mà nhận tạo ACK trùng lặp Nếu bên gửi TCP nhận ACK trùng lặp cho segment cho segment sau segment bên nhận lần bị Trong trường hợp này, TCP thực chế truyền lại Hình Biểu diễn số thứ tự nhanh (fast retransmit), gửi lại segment bị cho trước timer segment hết hạn (kết thúc) trường window tất segment gửi tới A Ban đầu máy B thiết lập RcvWin = RcvBuffer E Kiểm soát lưu lượng Máy A có hai biến LastByteSent LastByteAcked Độ lệch biến này, LastByteSent LastByteAcked số lượng liệu chưa biên nhận mà A gửi qua kết nối Bằng cách khống chế số lượng liệu chưa biên nhận nhỏ giá trị RcvWin A đảm bảo không làm tràn đệm B A: LastByteSent – LastByteAcked ≤ RcvWindow III Hình Biến Receive đệm NGUYÊN LÝ HOẠT ĐỘNG CỦA Q TRÌNH KIỂM SỐT TẮC NGHẼN TRONG TCP A Tổng quan kiểm soát tắc nghẽn TCP Thiết bị đầu/cuối phía kết nối TCP có đệm liệu(buffer) Khi nhận dòng byte liên tục, TCP đặt dòng byte vào đệm nhận (receiver buffer) TCP cung cấp cung cấp dịch vụ kiểm soát lưu lượng (flow control) để tránh tượng bên gửi làm tràn đệm bên nhận Kiểm sốt lưu lượng q trình làm tương thích (matching) tốc độ (tương thích tốc độ gửi tốc độ nhận) Bên gửi TCP bị giới hạn tắc nghẽn mạng IP, chế kiểm soát tắc nghẽn TCP Mặc dù kiểm soát lưu lượng giống kiểm soát tắc nghẽn (hạn chế tốc độ gửi bên gửi), nhiên chúng thực với nhiều mục đích khác Để cung cấp chế kiểm soát lưu lượng, TCP bên gửi sử dụng biến receive window Đây giá trị mà bên nhận báo cho bên gửi biết độ lớn vùng đệm cịn rỗi Trong kết nối hai hướng, phía kết nối có giá trị receive window riêng Giá trị receive window thay đổi thời gian kết nối Giả sử máy A gửi file lớn tới máy B qua kết nối TCP Máy B khởi tạo đệm cho kết nối với độ lớn RcvBuffer Tiến trình ứng dụng B đọc liệu từ đệm Ta định nghĩa số biến sau: ● ● LastByteread = số thứ tự byte cuối dòng liệu mà tiến trình ứng dụng máy B đọc từ buffer LastByterRcvd = số thứ tự byte cuối dòng liệu đến từ mạng để receiver buffer máy B Vì TCP khơng cho phép tràn đệm nên LastbyteRcvd – LastByteread ≤ RcvBuffer RcvWin giá trị Receive Window, độ lớn vùng đệm rỗi: Hình Cửa sổ kiểm sốt tắc nghẽn Kết nối TCP kiểm sốt tốc độ truyền cách giới hạn số lượng sản phẩm gửi chưa bên nhận, giả sử w số lượng cho phép xe chưa cần biết nhận thường coi kích thước cửa sổ TCP (TCP Window) Điều lý tưởng kết nối TCP cho phép truyền với tốc độ tối đa (càng nhiều segment chưa biên nhận tốt) chừng chưa xảy tượng segment bị tắc nghẽn Nói chung, kết nối TCP bắt đầu với giá trị w tương đối nhỏ sau "thăm dị" kênh truyền cịn rỗi khơng cách tăng dần giá trị w, tăng w xảy liệu (sự kiện hết thời gian đợi - Timeout hay nhận biên nhận trùng lặp) TCP giảm w tới giá trị an toàn sau lại bắt đầu "thăm dị" kênh truyền rỗi cách tăng dần giá trị w Mỗi kết nối TCP có đệm gửi, đệm nhận số biến (LastByteread, RcvWin, ) Cơ chế kiểm soát tắc nghẽn TCP bổ sung thêm hai biến congrest window (CongWin) (cửa sổ tắc nghẽn) threshold (ngưỡng) Cửa sổ tắc nghẽn biểu thị số lượng liệu tối đa mà người gửi gửi qua kết nối Như vậy,khối lượng liệu gửi không vượt CongWin RcvWin, tức là: LastByteSent - LastByteAcked ≤ minCongWin,RcvWin RcvWin = RcvBuffer – [LastByteRcvd – Last Byteread] Bởi độ lớn vùng đệm rỗi thay đổi theo thời gian nên giá trị RcvWin biến đổi Biến RcvWin minh họa (Hình 4) Kết nối sử dụng biến RcvWin để cung cấp kiểm soát lưu lượng nào? Máy B báo cho máy A độ lớn vùng rỗi đệm cách đặt giá trị RcvWin thời vào Ngưỡng ký hiệu ảnh hưởng tới trình tăng CongWin trình bày Hãy xem giá trị CongWin tăng suốt kết nối TCP nào? Để tập trung vào chế kiểm soát tắc nghẽn (khác kiểm soát lưu lượng), giả thiết đệm nhận đủ lớn để bỏ qua hạn chế cửa sổ nhận Trong trường hợp này, số lượng liệu gửi chưa cần biên nhận bị giới hạn CongWin, giả thiết phía gửi cần gửi nhiều liệu Sau thiết lập kết nối TCP hai hệ thống đầu/cuối, tiến trình ứng dụng bên gửi chuyển liệu tới đệm gửi TCP TCP chia liệu thành khối với kích thước MMS, đặt khối liệu TCP segment, chuyển segment xuống tầng mạng để gửi Cửa sổ tắc nghẽn TCP điều tiết số lượng segment gửi Ban đầu, CongWin nhận giá trị MMS, TCP gửi segment biên nhận Nếu segment biên nhận trước timeout, phía gửi tăng CongWin lên MMS gửi hai segment Nếu segment biên nhận thời gian đợi chúng, CongWin lại tăng thêm MMS cho segment biên nhận Khi CongWin MMS phía gửi gửi bốn segment Thủ tục thực liên tục CongWin vượt ngưỡng (threshold) hay không nhận biên nhận thời gian chờ biên nhận Trong giai đoạn này, CongWin tăng theo hàm số mũ Ban đầu nhận giá trị MMS, sau tăng lên MMS, MMS, MMS, Đây giai đoạn khởi đầu chậm (slow start) giá trị cửa sổ khởi đầu với giá trị nhỏ(1 MMS) Tuy giá trị cửa sổ tăng nhanh Giai đoạn slow start kết thúc CongWin vượt ngưỡng Khi giá trị CongWin tăng tuyến tính khơng cịn tăng theo hàm số mũ Tức CongWin = w, sau nhận biên nhận cho w segment, giá trị CongWin tăng lên 1, CongWin = w + Đây giai đoạn tránh tắc nghẽn (congestion avoidance) Giai đoạn tránh tắc nghẽn tiếp tục nhận biên nhận thời gian đợi Tuy nhiên, giá trị cửa sổ tốc độ gửi liệu tăng Đến lúc xảy cố gói liệu router Điều dẫn đến kiện timeout phía gửi Lúc giá trị ngưỡng nhận giá trị nửa CongWin, CongWin đặt MMS Bên gửi tiếp tục tăng giá trị CongWin theo hàm số mũ vượt ngưỡng B TCP Reno Tóm tắt TCP Cho đến có tính sau: ● ● ● ● Khởi động chậm không giới hạn từ đầu; Tránh tắc nghẽn với AIMD đạt số trạng thái ổn định; Ngưỡng bắt đầu chậm sau lần đánh mất; Mỗi ngưỡng chậm bắt đầu chuyển đổi tự nhiên để tránh tắc nghẽn Vấn đề mà TCP thường gặp phải, hai đoạn khởi động chậm tránh tắc nghẽn, gói bị mất, người gửi phát điều sau Đến lúc đó, muộn để tránh bị mát thêm Truyền lại nhanh Xác nhận trùng lặp sở cho chế truyền lại nhanh chóng Chiến lược gửi lại liệu [N] nhận ba ACK lặp lại cho Data[N-1]; có nghĩa là, bốn ACK[N-1] tất Đây tính quan trọng TCP Tahoe TCP Reno Phục hồi nhanh Phục hồi nhanh kỹ thuật thường cho phép người gửi tránh thoát đường ống di chuyển từ cwnd đến cwnd/2 không gian RTT (Round-trip time: thời gian khứ hồi) TCP Reno TCP Tahoe với việc bổ sung Fast Recovery Ý tưởng sử dụng trùng lặp đến để tăng tốc độ truyền lại Giả định lần lặp lại đến số gói liệu theo sau gói bị gửi thành cơng; khơng quan trọng Khi phát gói bị thông qua Truyền lại nhanh, đặt cwnd = cwnd/ 2; bước tìm số lần lặp lại phải đợi trước tiếp tục truyền liệu Ban đầu, giả định có gói liệu bị mất, phần sau, thấy nhiều mát xử lý thơng qua sửa đổi nhỏ chiến lược Khơi phục nhanh Trong q trình khơi phục, khơng thể sử dụng cwnd trực tiếp, cửa sổ trượt di chuyển gói tin bị truyền lại Thay vào đó, sử dụng khái niệm Kích thước chuyến bay ước tính, EFS (Estimated Flight Size) , dự đốn tốt người gửi số lượng gói tin chưa tốn Trong trường hợp bình thường, EFS giống cwnd Quan sát phục hồi nhanh quan trọng EFS nên giảm cho lần lặp lại Đầu tiên ta phác thảo trường hợp chung, sau xem xét ví dụ cụ thể Giả sử cwnd = N, giả sử gói bị (số gói coi tương đối) Cho đến gói truyền lại, người gửi gửi qua gói N (Dữ liệu [N] gửi sau ACK[0] đến tay người gửi) Bên nhận gửi N-1 ACK[0] lặp lại đại diện cho gói từ đến N Hình Sơ đồ minh họa Fast Recovery cho cwnd = 10 Data[10] bị Tại điểm lần lặp thứ ba, phát Data[1], người gửi tính tốn sau: EFS lúc cwnd = N Ba lần trùng lặp đến, đại diện cho ba gói sau khơng cịn hoạt động nữa, EFS N-3 Tại thời điểm này, người gửi nhận gói tin bị mất, điều làm cho EFS N-4 thời gian ngắn, gói tin sau truyền lại lập tức, điều đưa EFS trở lại N - Người gửi dự kiến thời điểm nhận thêm N-4 lần lặp lại, ACK để truyền lại gói tin bị ACK cuối dành cho toàn cửa sổ ban đầu Mục tiêu cho cwnd N/2 (để đơn giản, giả sử N số chẵn) Vì vậy, chờ N/2 - lần lặp đến, lúc EFS N - - (N/2 - 3) = N/2 Sau thời điểm này, người gửi tiếp tục gửi gói tin mới; gửi gói tin cho N/2 - gói trùng lặp đến sau (nhớ lại cho N-1 gói tin trùng lặp tất cả) Những lần truyền Data[N+1] qua Data[N + (N/2 - 1)] Sau lần cuối lần lặp lại đến ACK tương ứng với việc truyền lại gói tin bị mất; ACK[N], ghi nhận tất cửa sổ ban đầu Tại thời điểm này, N/2 - gói chưa xác nhận Data[N - 1] thông qua Data[N + (N/2 - 1)] Người gửi gửi Data[N + N/2] tiếp tục cửa sổ trượt với cwnd = N/2: người gửi nhận ACK[N] có xác cửa sổ chưa toán đầy đủ cho giá trị N/2 cwnd Đây sơ đồ minh họa Fast Recovery cho cwnd = 10 Data[10] bị mất.(Hình 6) Trong trình trượt cửa sổ mà không bị mất, người gửi gửi gói cwnd RTT Nếu thời gian chờ “thơ” xảy ra, thơng thường khơng phát sau RTT hồn chỉnh liên kết khơng hoạt động; có thêm nhiều RTT không sử dụng giai đoạn khởi động chậm Cần kiểm tra trình tự Phục hồi nhanh hiển thị hình minh họa từ góc độ băng thơng chưa sử dụng Biểu đồ hiển thị ba thời gian khứ hồi, nhìn thấy từ phía người gửi Trong RTT đầu tiên, mười gói Data[9] - Data[18] gửi RTT thứ hai bắt đầu việc gửi Data[19] tiếp tục thông qua việc gửi Data[22], với truyền lại Data[10] RTT thứ ba bắt đầu việc gửi Data[23] bao gồm thông qua Data[27] Về hiệu khôi phục, RTT gửi gói tin 9, (chúng tơi đếm Data[10] hai lần); điều gần với lý tưởng giảm cwnd xuống Lý sử dụng cwnd trực tiếp công thức Fast Recovery Data[10] bị xác nhận, cửa sổ bị đóng băng Data[10] - Data[19] Mô tả ban đầu RFC 2001 Phục hồi nhanh mô tả truyền lại lạm phát cwnd giảm phát Lạm phát bắt đầu thời điểm người gửi tiếp tục truyền gói tin mới, thời điểm đó, cwnd tăng lên cho lần lặp lại; sơ đồ trên, cwnd kết thúc mức 15 Khi ACK[20] kích hoạt gói bị cuối đến, giai đoạn khôi phục kết thúc cwnd giảm xuống C TCP NewReno Data[9] tạo ACK[9] ban đầu, gói Data[11] đến Data[19], gói tạo ACK[9] lặp lại Chúng ta biểu thị ACK[9] lặp lại tạo Data[N] cách lặp lại ACK[9]/N; chúng biểu thị dọc theo phía bên phải Trừ SACK TCP (bên dưới) sử dụng, người gửi cách để xác định N phân biệt trùng lặp Khi trùng lặp ACK[9]/13 (lần lặp thứ ba) đến tay người gửi, người gửi sử dụng Phục hồi nhanh để suy Data[10] bị truyền lại Tại thời điểm EFS = 7: người gửi gửi ban đầu gồm 10 gói liệu, cộng với Data[19], nhận ACK ba tệp trùng lặp, tổng cộng 10 + -1 -3 = Người gửi suy Data[10] bị (EFS - = 1) sau truyền lại (EFS + = 1) Sáu lần ACK[9] lặp lại đường EFS giảm dần cho lần xuất trùng lặp tiếp theo; sau nhận thêm hai lần lặp lại ACK[9], EFS Lần lặp ACK[9] (lặp lại ACK[9]/16) giảm EFS xuống cho phép tơi truyền Data[20] (điều nhanh chóng hỗ trợ EFS lưu đến 5) Chúng ta có (Hình 7) Hình Sơ đồ minh họa Fast Recovery cho cwnd = 12 Data[1] Data[4] bị Hình Sơ đồ liệu gửi sau lần trung lập TCP NewReno, tinh chỉnh khiêm tốn cho Fast Recovery giúp cải thiện đáng kể việc xử lý trường hợp hai nhiều gói bị cửa sổ Nó coi phần TCP Reno đương đại Nếu hai gói liệu bị gói truyền lại, người nhận ghi nhận liệu trước gói thứ hai sau tiếp tục gửi gói liệu gói liệu bị thứ hai truyền lại Các ACK liệu trước gói thứ hai gọi ACK phần, việc truyền lại gói liệu bị không dẫn đến ACK tất liệu tồn đọng Cơ chế NewReno sử dụng ACK phần làm chứng để truyền lại gói bị sau để trì tốc độ q trình Khơi phục nhanh Trong sơ đồ bên (Hình 8), gói bị cửa sổ 0-11 có kích thước 12 Ban đầu người gửi nhận ACK[0] lặp lại; 11 ACK (đường đứt nét từ phải sang trái) ACK[0] 10 ACK[0] phát lại Khi gói truyền lại thành cơng nhận ACK[0] thứ ba, phản hồi người nhận ACK[3] (đường đứt nét đậm) Đây ACK phần (ACK đầy đủ ACK[12]) Khi nhận ACK phần q trình Khơi phục nhanh, TCP NewReno giả định gói liệu sau bị truyền lại lập tức; người gửi không đợi ba lần lặp lại gói liệu sau khơng bị mất, khơng có trường hợp ACK phần tạo ra, việc xếp lại gói xảy Phản hồi người gửi TCP NewReno đây, thực tế, coi ACK phần ACK[0], ngoại trừ việc người gửi truyền lại gói liệu - mà dựa việc nhận ACK phần - suy bị NewReno tiếp tục tăng tốc độ Phục hồi nhanh ACK đến, cho dù chúng ban đầu hay phần ACK sau ACK lặp lại Khi ACK[3] người nhận đến tay người gửi, NewReno thông báo Data[4] bị gửi lại; dòng liệu nặng thứ hai Không cần phải đến nơi ACK[3] lặp lại; đề cập trên, người gửi suy từ ACK[3] Data[4] bị Người gửi phản hồi thể ACK[0] khác đến gửi Data[17] Sự xuất ACK[3] báo hiệu EFS giảm 2: suy luận Data[4] bị mất, ACK[0] khác đến; hai lần truyền theo phản hồi (của Data[4] Data[17]) đưa EFS trở lại vị trí ban đầu Tại thời điểm Data[16] gửi, kích thước chuyến bay thực tế (khơng ước tính) 5, khơng phải 6, có trùng lặp ACK[0] Data[4] Tuy nhiên, NewReno gửi lại Data[4] sau gửi Data[17], kích thước thực tế trở lại đầu), phản hồi tương ứng với ACK[17] tiếp tục với Data[23] Như với ví dụ khơi phục nhanh trước đó, xem xét số lượng gói gửi RTT; biểu đồ (Hình 9) hiển thị bốn RTT nhìn thấy từ phía người gửi Hình Số lượng gói gửi RTT Một lần nữa, sau mát phát hiện, chuyển sang cwnd với gói bị bỏ sót (trong RTT thứ hai) Tuy nhiên, NewReno gửi gói truyền lại cho RTT Lưu ý TCP Newreno, giống TCP Tahoe Reno, đổi từ phía người gửi; người nhận khơng phải làm điều đặc biệt IV MƠ PHỎNG VÀ PHÂN TÍCH HIỆU NĂNG Tơi sử dụng phần mềm mơ NS2 hệ điều hành Ubuntu để mô hệ thống tự đề xuất sử dụng giao thức TCP NewReno phân tích hiệu A Kịch mô hệ thống Hệ thống tự đề xuất bao gồm nút nguồn tạo nguồn lưu lượng tcp1 gửi gói tin đến nút đích n3 dựa giao thức truyền TCP-NewReno Hàng đợi gắn với liên kết sử dụng chế DropTail Tôi thay đổi độ trễ truyền dẫn với giá trị 10ms, 25ms 50ms để thấy khác chúng Bảng Kịch mô Thời điểm (s) Mục đích 0.5 Luồng bắt đầu truyền liệu 50 Luồng kết thúc truyền liệu 50.5 Đóng file trace data, vẽ đồ thị cwnd Có thêm bốn lần lặp lại ACK[3] đến NewReno tiếp tục gửi liệu nhận liệu này; Data[18] đến Data[21] Phản hồi người nhận truyền lại Data[4] gửi ACK[16]; tích lũy tất liệu nhận thời điểm Tại thời điểm ACK quay trở lại người gửi, vừa gửi Data[21] để phản hồi lại lần lặp thứ tư ACK[3]; phản hồi với ACK[16] gửi gói liệu tiếp theo, Data[22] Người gửi trở lại cửa sổ trượt bình thường, với cwnd Tương tự, Data[17] sau Data[4] truyền lại lấy ACK[17] (đây Data[N] lấy cách xác phù hợp với ACK[N] kể từ tổn thất bắt Hình 10 Mơ hình mạng hệ thống B Kết mơ Nhận xét: Dựa (Hình 11) (Hình 12) (Hình 13), ta thấy giảm độ trễ truyền dẫn lặp lại số lượng gói mà cửa sổ trì diễn nhanh C Phân tích hiệu (thơng lượng) Hình 11 Congestion Window ứng với TCP-NewReno với độ trễ truyền dẫn 10ms Hình 14 Thơng lượng ứng với TCP-NewReno, TCP-Cubic với độ trễ truyền dẫn 10ms Hình 12 Congestion Window ứng với TCP-NewReno với độ trễ truyền dẫn 25ms Hình 13 Congestion Window ứng với TCP-NewReno với độ trễ truyền dẫn 50ms Hình 15 Thơng lượng ứng với TCP-NewReno, TCP-Cubic với độ trễ truyền dẫn 25ms Hình 16 Thơng lượng ứng với TCP-NewReno, TCP-Cubic với độ trễ truyền dẫn 50ms Nhận xét: Dựa (Hình 14) (Hình 15) (Hình 16), ta thấy rõ ràng TCP-NewReno đạt thông lương cao nhiều so với TCP- Cubic Bên cạnh ta tăng độ trễ truyền dẫn khiến thông lượng giảm D Đánh giá mô Các mơ cần tinh chỉnh để thấy rõ khác TCP, cần thêm luồng khác để có nhìn rõ nét V LỜI CẢM ƠN Đây lần đầu tơi viết báo nên cịn nhiều sai sót q trình trình bày Tơi xin cảm ơn PGS.TS Nguyễn Thành Chuyên giúp đỡ q trình hồn thành báo Tơi xin chân thành cảm ơn! KẾT LUẬN Trong báo này, tìm hiểu phương thức hoạt động giao thức TCP NewReno lớp truyền vận phân tích hiệu (thông lượng) hệ thống tự đề xuất Trong báo này, bắt đầu nghiên cứu từ mơ hình TCP lớp truyền vận, trình bày quản lý kết nối TCP, cấu trúc TCP Segment, trường quan trọng, truyền liệu tin cậy phương thức kiểm soát lưu lượng Từ sâu vào nguyên lý hoạt động trình kiểm sốt tắc nghẽn TCP, cụ thể TCP Reno cải tiến TCP NewReno Tơi mơ mơ hình cho TCP NewReno Từ hình ảnh, biểu đồ, kết nhận đưa nhận xét mô hình Từ thêm nhiều hiểu biết thông lượng hệ thống sử dụng giao thức TCP NewReno TÀI LIỆU THAM KHẢO [1] [2] [3] [4] [5] [6] [7] A Kumar, “Comparative performance analysis of versions of tcp in a local network with a lossy link”, IEEE/ACM Transactions on Networking, vol 6, no 4, pp 485-498, 1998 J Liu, Z Han, and W Li, “Performance analysis of tcp new reno over satellite dvb-rcs2 random access links”, IEEE Transactions on Wireless Communications, vol 19, no 1, pp 345-446, 2020 Dr Saleem Ullah, “Modeling TCP NewReno Slow Start and Congestion-Avoidance using Simulation Approach”, published in January 2011 Youtube channel, Mạng truyền thông IT Gnuplot.info, “Linetype, colors, and styles” Isi.edu, “TCP Agents” Wikipedia, “TCP Congestion Control”