Điều khiển lưu lượng trong giao thức TCP

độ dài của nó là bội của 4, đảm bảo phần header luôn kết thúc ở một mốc 32 bits. Phần thêm này toàn số 0. Data: số liệu của ứng dụng TCP 2.2.3. Thiết lập và kết thúc kết nối TCP 2.2.3.1 Thiết lập kết nối Việc thiết lập kết nối dựa trên phương thức bắt tay 3 bước như sau: Tiến trình trạm làm việc yêu cầu thiết lập một kết nối TCP bằng cách gửi một gói tin TCP với cờ SYN=1, gọi tắt là điều khiển SYN và giá trị khởi tạo số tuần tự ISN của mình. Giá trị ISN là một số 4 byte không dấu và được tăng mỗi khi có một kết nối được yêu cầu (giá trị này quay về 0 khi đạt tới 232). Trong gói điều khiển SYN này còn chứa số hiệu cổng TCP của phần mềm dịch vụ mà tiến trình trạm làm việc muốn kết nối. Mỗi thực thể kết nối TCP đều có một giá trị ISN mới. Số này được tăng theo thời gian. Vì một kết nối TCP có cùng một số hiệu cổng và cùng một địa chỉ TCP được dùng lại nhiều lần, do đó việc thay đổi ISN ngăn không cho các kết nối dùng lại các số liệu cũ, vẫn còn đựoc truyền từ một kết nối cũ và có cùng 1 địa chỉ kết nối. (bước 1) Sau khi nhận được gói điều khiển SYN ở trạng thái sẵn sàng chấp nhận kết nối, thực thể TCP của phần mềm dịch vụ gửi lại gói SYN với giá trị ISN của mình và đặt bít cờ ACK=1, để thông báo rằng thực thể dịch vụ đã nhận được giá trị ISN của tiến trình trạm.(bước 2) Tiến trình trạm phúc đáp lại gói SYN của thực thể dịch vụ bằng 1 thông báo trả lời ACK cuối cùng, khẳng định đã nhận được giá trị ISN của thực thể phần mềm dịch vụ. (bước 3) Bằng cách này, các thực thể TCP trao đổi một cách tin cậy các giá trị ISN của nhau và sẵn sàng trao đổi số liệu. Chú ý rằng: không có gói điều khiển SYN nào trong 3 bước trên chứa số liệu của thực thể ứng dụng; tất cả các số liệu điều khiển được trao đổi đều nằm trong phần tiêu đề của gói điều khiển TCP(bước 3). 2.2.3.2 Kết thúc kết nối Khi có nhu cầu kết thúc kết nối, thực thể TCP (thực thể A) gửi yêu cầu kết thúc kết nối với cờ FIN=1. Vì kết nối TCP là song công nên mặc dù nhận được yêu cầu kết thúc kết nối của A (A thông báo hết số liệu để gửi), thực thể B vẫn có thể tiếp tục truyền số liệu cho đến khi B không còn số liệu để gửi và thông báo cho A bằng yêu cầu kết thúc kết nối với cờ FIN=1 của mình. Khi thực thể TCP nhận được thông điệp FIN, sau khi đã gửi thông điệp FIN của chính mình, kết nối TCP thực sự được kết thúc. TCP hiện nay dung nạp nhiều loại mạng vật lý cơ sở khác nhau bằng việc cung cấp nhiều độ trễ khác nhau, nhiều loại băng thông cũng như tỷ lệ gói tin bị mất. Nó xử lý mỗi kết nối độc lập, cho phép nhiều kết nối từ một máy đến máy khác di chuyển theo con đường có đặc tính cơ sở khác nhau. Quan trọng hơn, TCP có thể hiệu chỉnh đối với những thay đổi của thời gian khứ hồi RTT (Round Trip Time) của một kết nối nên làm cho nó đáng tin cậy ngay cả khi hệ thống chuyển mạch gói cơ sở bị nghẽn mạch hoặc tạm thời bị hỏng. Việc truyền lại với khả năng hiệu chỉnh chính là trọng tâm của TCP và đóng góp vào sự thành công của nó. Việc truyền lại với khả năng hiệu chỉnh sử dụng cách hoạt động vừa qua để dự đoán cách hoạt động trong tương lai. Nó đòi hỏi TCP tính toán thời gian khứ hồi cho mỗi lần truyền và sử dụng các kỹ thuật thống kê để kết hợp các số liệu riêng lẻ thành một ước lượng đủ đúng của thời gian khứ hồi, hơn nữa TCP liên tục cập nhật ước lượng về thời gian khứ hồi của nó. Đặc thù phát triển của các mạng diện rộng ngày nay là phát triển trên nền tích hợp của nhiều công nghệ và phương tiện khác nhau. Một hệ thống như vậy mang đặc trưng của một hệ thống không đối xứng, sự chênh lệch giữa các kênh truyền ảnh hưởng không nhỏ đến tốc độ chung của hệ thống. Mạng diện rộng là hệ thống liên mạng với giao thức trao đổi dữ liệu cơ bản là TCP, trong đó băng thông cho mỗi kênh trao dổi dữ liệu chênh lệch nhau đáng kể. Việc nghiên cứu hiệu suất mạng gắn liền với việc điều khiển các gói xác nhận ACK đóng vai trò quan trọng trong sự phát triển các giao thức mới. Trong các hệ thống mạng, điều khiển lưu lượng và điều khiển tắc nghẽn là hai quá trình có quan hệ mật thiết với nhau. Tắc nghẽn là nguyên nhân, là lý do điều khiển lưu lượng. Sự tắc nghẽn xảy ra khi dữ liệu nhận được vượt quá khả năng xử lý của một nút mạng. Trong các hệ thống mạng diện rộng sự tắc nghẽn làm giảm hiệu suất, tăng thời gian truyền và xử lý, điều này đôi khi dẫn đến nghẽn mạch toàn bộ hệ thống. Điều đó có thể do một số nguyên nhân sau: Thiết bị mạng không đáp ứng được nhu cầu xử lý số liệu (ví dụ: bộ đệm quá nhỏ…) Tần suất dữ liệu đầu vào quá lớn so với tần suất dữ liệu đầu ra Thời gian chờ xử lý, xếp hàng…quá lớn Tần suất lỗi mạng cao Vấn đề là khi một trong các điều kiện trên xảy ra nó có thể kéo theo các điều kiện còn lại. Để giải quyết vấn đề này trong các hệ thống mạng người ta phải đưa vào các thủ tục điều khiển tắc nghẽn. 2.2. Sự kiện tắc nghẽn đầu tiên trên Internet và đề xuất của Jacobson về nguyên lý “bảo toàn gói tin” 2.2.1. Sự kiện tắc nghẽn đầu tiên trên Internet Các mạng máy tính đã trải qua một sự bùng nổ lớn trong những năm qua và trong sự phát triển đã có một số sự kiện tắc nghẽn xảy ra. Ví dụ, người ta thống kê được một việc phổ biến là các cổng (gateway) Internet làm mất tới 10% các gói tin đến vì bị tràn bộ đệm cục bộ (local buffer).Tháng mười năm 1986, trên mạng Internet xảy ra hiện tượng tắc nghẽn đầu tiên. Trong suốt thời kỳ này, thông lượng thực tế của dữ liệu từ mạng của phòng thí nghiệm LBL đến trường đại học UC ở berkeley (đó là hai nơi riêng biệt, cách nhau khoảng 360 m, giữa chúng có 2 router) bị giảm từ 32kbps xuống 40bps. Người ta đã tập trung tìm hiểu nguyên nhân dẫn đến hiện tượng này và đã tìm ra, đồng thời đề xuất các biện pháp khắc phục, đó là tuân theo nguyên lý bảo toàn số lượng gói tin trong mạng. 2.2.2. Nguyên lý bảo toàn gói tin Hình 14. Nguyên lý bảo toàn các gói tin trong điều khiển lưu lượng TCP Nguyên lý bảo toàn gói tin trong điều khiển lưu lượng TCP: ”giữ cho số gói số liệu có mặt trong mạng của một kết nối không thay đổi” Nếu nguyên lý này được tuân theo, thì sự sụp mạng do tắc nghẽn sẽ rất khó xảy ra. Sự điều khiển tắc nghẽn liên quan đến việc tìm ra những nơi vi phạm nguyên lý bảo toàn và sửa chữa chúng Thủ tục điều khiển tắc nghẽn trong giao thức TCP Một số khái niệm, thuật ngữ cơ bản mà chúng ta sử dụng như sau: Gói dữ liệu: đơn vị cơ bản trong kỹ thuật truyền số liệu bằng giao thức TCP. Gói xác nhận ACK: thông tin dùng để xác nhận một gói dữ liệu đã được truyền đến đích. W(t): số gói dữ liệu tối đa cho phép phát tại thời điểm t, hay nó là độ lớn cửa sổ phát thời điểm t. SMSS (Sender Maximum Segment Size): độ lớn tối đa của gói dữ liệu có thể gửi. Giá trị này có thể dựa trên kích thước đơn vị dữ liệu truyền tối đa của mạng. SMSS không bao gồm kích thước tiêu đề TCP và các trường lựa chọn. Rwnd (Received window): giá trị w(t) tại bên nhận. Cwnd (Congestion Window): giá trị w(t) trong trường hợp có tắc nghẽn. Time-out: thời gian chờ tối đa trước khi được coi là có lỗi. RTT (Round Trip Time): thời gian khứ hồi, là thời gian đủ để gói dữ liệu được phát đi đến đích và biên nhận được truyền trở về từ thực thể đối tác. SS (Slow Start): giai đoạn khởi động chậm trong cơ chế điều khiển lưu lượng. CA (Congestion avoidance): giai đoạn tránh tắc nghẽn trong cơ chế điều khiển lưu lượng. Ssthresh (Slow Start threshold): ngưỡng chuyển đổi từ giai đoạn khởi động chậm sang giai đoạn tránh tắc nghẽn. Đối với mỗi phiên làm việc, sự chênh lệch giữa kênh phát và kênh sử dụng cho các gói xác nhận ACK ảnh hưởng rất lớn đến hiệu suất sử dụng trên các kênh phát dữ liệu. Đơn vị cơ bản trong truyền số liệu của TCP là gói dữ liệu, với một hay nhiều gói dữ liệu sẽ tương ứng một hay nhiều gói xác nhận ACK. Như vậy băng thông sử dụng của mạng phải dựa trên các yếu tố: tốc độ, độ lớn gói dữ liệu, độ lớn gói xác nhận ACK và thời gian khứ hồi RTT. Băng thông cơ sở chưa đủ để đảm bảo mạng đó đạt tốc độ cao. Giao thức TCP điều khiển tần suất truyền bằng cách giới hạn số gói xác nhận ACK được truyền. Trong mỗi phiên làm việc, độ lớn cửa sổ phát w là số gói dữ liệu chưa có gói xác nhận ACK trả lời tương ứng. Một cách lý tưởng, khi không có sự mất mát dữ liệu do tắc nghẽn trên đường truyền thì độ lớn cửa sổ phát càng lớn càng tốt. Khi một kết nối được thiết lập, độ lớn cửa sổ truyền ban đầu là thấp, sau đó tăng dần lên nhằm tránh tắc nghẽn. Quá trình tăng liên tục cho đến khi w đạt giá trị tối đa, tức là khi gặp lỗi hay khi nhận được gói xác nhận ACK yêu cầu phát lại, hay quá thời gian chờ tối đa cho phép. Khi đó, độ lớn cửa sổ phát sẽ được giảm và quá trình truyền lại bắt đầu một chu kỳ mới. Chúng ta có thể thấy được về tính động trong cơ chế điều khiển tắc nghẽn của TCP thể hiện ở chỗ nó tự điều chỉnh tần suất khi phát dữ liệu tuỳ theo trạng thái kênh truyền, trong đó đặc biệt là băng thông và tần suất xuất hiện lỗi. Qua đó tự thiết lập các thông số phục vụ cho việc trao đổi số liệu. Điều này có thể thấy rõ trong các thuật toán điều khiển trong TCP: khởi động chậm, phục hồi nhanh và tránh tắc nghẽn. Chúng ta sẽ nghiên cứu các thuật toán điều khiển lưu lượng cơ bản, hợp thành cơ chế điều khiển lưu lượng trong giao thứcTCP đó là: khởi động chậm (slow tart), tránh tắc nghẽn (congestion avoidance), phát lại nhanh và phục hồi nhanh (fast retransmit and fast recovery). 2.3. Các cơ chế điều khiển lưu lượng trong giao thức TCP 2.3.1. Một số cơ chế điều khiển lưu lượng trong giao thức TCP Để thực hiện được điều khiển lưu lượng. TCP có một số cơ chế sau: Cơ chế cửa sổ động (cửa sổ trượt có kích thước thay đổi) Cơ chế cửa sổ động là một trong các phương pháp điều khiển số liệu trong mạng thông tin máy tính. Độ lớn cửa sổ chính bằng số gói tin được gửi liên tục mà không cần chờ thông báo trả lời về kết quả nhận các gói tin đó. Ví dụ, nếu độ lớn của cửa sổ w=3 thì sau khi gửi đi ba gói tin liên tiếp nhau, thực thể phát phải chờ trả lời về kết quả nhận 3 gói tin nói trên, trước khi gửi ba gói tin tiếp theo. Độ lớn cửa sổ quyết định hiệu suất trao đổi trong mạng. Nếu chọn độ lớn cửa sổ cao thì có thể gửi được nhiều số liệu trong cùng một đơn vị thời gian. Một khi việc truyền số liệu có lỗi, trong trường hợp này, rõ ràng số liệu phải gửi lại lớn và vì vậy hiệu quả sử dụng đường truyền thấp (tỷ lệ giữa số liệu được chuyển thực sự trên tổng số số liệu được trao đổi trên mạng). Giao thức TCP cho phép thay đổi độ lớn cửa sổ một cách động, phụ thuộc vào độ lớn bộ đệm thu của thực thể TCP nhận. Để thực hiện cơ chế cửa sổ động, TCP đảm bảo: Trả lời về số tuần tự thu tiếp theo trong trường ACK, nghĩa là khẳng định tổng số byte nhận đúng cho đến thời điểm gửi gói trả lời này. Thông báo về tổng số byte có thể nhận được, tương ứng với độ lớn bộ nhớ đệm thu. Cơ chế phát lại thích nghi Để đảm bảo kiểm tra phát lại và khắc phục lỗi trong việc trao đổi số liệu qua mạng diện rộng được kết nối từ nhiều mạng khác nhau, TCP phải có cơ chế đồng hộ kiểm tra phát (time-out) và cơ chế phát lại (retransmmision) mềm dẻo, thay đổi phụ thuộc vào thời gian trễ thực của môi trường truyền dẫn cụ thể. Thời gian khứ hồi (Round Trip Time), được xác định từ thời điểm bắt đầu phát gói tin cho đến khi nhận được trả lời về kết quả nhận của thực thể đối tác, là yếu tố quyết định giá trị của đồng hồ kiểm tra phát tout. Rõ ràng tout phải lớn hơn hoặc bằng RTT. Như hình 15. Hình 15. Xác định thời gian khứ hồi RTT Cơ chế phát lại thích nghi dựa trên việc xác định thời gian khứ hồi RTT theo thời gian. Bằng việc sử dụng các hàm xác định thời gian của hệ điều hành, hoàn toàn xác định được thời gian khứ hồi của một kết nối TCP tại các mốc thời gian nhất định. Có thể tính thời gian khứ hồi theo công thức sâu đây: RTT a¬RTT+(1-a)*new_RTT (với 0≤a<1, là hằng số khuyếch đại lọc, giá trị gợi ý là 0.9). Từ đó có thể tính thời gian kiểm tra phát tout theo công thức: Tout=β*RTT (với β được xem là khoảng biến đổi của RTT, có giá trị gợi ý là 2). Các cơ chế điều khiển tắc nghẽn số liệu: Hiện tượng tắc nghẽn số liệu được thể hiện trước hết ở việc gia tăng thời gian khứ hồi RTT của một gói tin bất kỳ nào khi chuyển qua mạng. Để hạn chế khả năng dẫn đến tắc nghẽn số liệu trong mạng, người ta điều khiển lưu lượng số liệu trao đổi trên mạng theo một số chiến lược sau đây: Khởi động chậm (Slow Start). Tránh tắc nghẽn (congestion avoidance). Phát lại nhanh (fast retransmission). Khôi phục nhanh (fast recovery). Để thuận tiện cho việc minh hoạ cơ chế hoạt động của các biện pháp này, ta chọn đơn vị cửa sổ w bằng số gói tin TCP (trong thực tế, độ lớn cửa sổ w được tính bằng đơn vị byte). Việc kiểm soát tránh tắc nghẽn trên mạng là vấn đề quan trọng, các thuật toán được phát triển bắt nguồn từ ý tưởng của việc tạo được sự vững chắc, ổn định mạng bằng cách thực hiện kết nối chuyển vận để tuân thủ theo một nguyên lý “bảo toàn gói tin”. Việc chúng ta “bảo toàn gói tin”, có nghĩa rằng thực hiện kết nối “trong cân bằng” (In Equilibrium), tức là, chạy ổn định với một cửa sổ đầy đủ của dữ liệu được chuyển vận qua. Khi đó, một cách vật lý, dòng chảy của các gói tin có thể được đưa vào mạng cho đến khi gói tin cũ đã rời đi. Có thể hình dung thấy tính ổn định của dòng chảy này như một luồng giao thông với sự ổn định lưu lượng của nó. Jacobson đã đưa ra nguyên lý bảo toàn như ở trên để khẳng định tính ổn định của mạng. Nếu nguyên lý này được tuân theo thì sự suy sụp mạng do tắc nghẽn sẽ rất khó xảy ra. Như vậy, sự điều khiển tắc nghẽn liên quan đến việc tìm ra những nơi vi phạm nguyên lý bảo toàn và sửa chữa chúng: Các nguyên nhân dẫn đến thực hiện không đúng “nguyên lý bảo toàn” này là: Kết nối không đạt tới sự cân bằng Người gửi đã đưa một gói tin mới vào mạng trước khi có một gói tin cũ ra khỏi mạng. Nguyên nhân là do hai sai lầm: Người gửi không thể đánh giá được đúng độ biến thiên của thời gian khứ hồi RTT. Chọn thời gian rút lui sau khi phát lại: nếu một gói số liệu phải được phát lại trên một lần, thì các lần phát lại này phải có cự li thời gian như thế nào? Với nguyên nhân này khi các gói tin cũ chưa đưa ra khỏi mạng mà đã đưa gói tin tiếp theo vào dẫn đến thông tin mà người đó gửi thừa ra. Mà trên mạng có rất nhiều người sử dụng. Giả sử mỗi người gây ra sự dư thừa đó thì tắc nghẽn xảy ra là điều rất khó tránh khỏi. Không đạt được sự cân bằng do có sự hạn chế các tài nguyên mạng dọc theo đường truyền: các tài nguyên mạng như băng thông (đường truyền), bộ đệm (các node trung gian). Băng thông thấp dẫn đến đường truyền tốc độ kém mà khi đó yêu cầu là truyền những lượng thông tin lớn, hoặc là thiếu bộ đệm dẫn đến các thông tin bị lưu lại trên đường truyền…Nhiều thông tin lưu lại dẫn đến tắc nghẽn chắc chắn sẽ xảy ra. Các biện pháp khắc phục đã được xây dựng như thuật toán: khởi động chậm (Slow Start), hay việc tính toán lại thời gian khứ hồi RTT,…Chúng ta sẽ xem xét ở sau đây để giải quyết những vi phạm nguyên lý bảo toàn, cái mà gây ra tắc nghẽn mạng. Với nguyên nhân thứ nhất, sử dụng thuật toán khởi động chậm (Slow Start) để tăng dần lượng dữ liệu đang được truyền thông trên mạng, nhằm đạt tới sự cân bằng. Với nguyên nhân thứ hai, phải tính lại thời gian khứ hồi một cách “thông minh”: Giải quyết sai lầm thứ nhất: tính ước lượng thời gian khứ hồi bằng một bộ lọc giải thông thấp để tránh cho đại lượng này khỏi thăng giáng quá mạnh nhằm duy trì sự cân bằng: RTT a¬RTT+(1-a)*new_RTT Giải quyết sai lầm thứ hai: rút lui theo hàm mũ. Với nguyên nhân thứ ba, chiến lược tránh tắc nghẽn sẽ được xem xét, gồm hai thành phần: Thứ nhất, mạng phải có khả năng gửi tín hiệu đến cho các thực thể ở đầu cuối của các kết nối, báo cho chúng biết là tắc nghẽn đang xảy ra hoặc sắp xảy ra. Thứ hai, các thực thể điểm cuối phải có chính sách giảm lưu lượng đưa vào mạng nếu nhận được các tín hiệu báo và tăng thêm lưu lượng đưa vào mạng nếu không nhận được tín hiệu báo này. Chính sách của thực thể điểm cuối đối với tắc nghẽn: thích ứng với đường truyền (tăng theo cấp số cộng, giảm theo cấp số nhân). Phản ứng của mạng đối với điều khiển tắc nghẽn: loại bỏ. 2.3.2. Việc áp dụng cơ chế điều khiển lưu lượng trong phiên bản TCP đầu tiên 2.3.2.1 Thuật toán khởi động chậm (Slow Start). Thuật toán này được thực hiện việc tăng dần lượng dữ liệu được vận chuyển trong mạng để đạt tới sự cân bằng. Khởi động chậm ta hiểu một cách cụ thể là bắt đầu với một giá trị cửa sổ (lượng dữ liêu được gửi đi) nhỏ, sau ta tăng dần lên theo cấp số cộng. Nhưng vì cấp số cộng ở đây là tăng theo số gói ACK biên nhận, cho nên quá trình tăng của nó cũng nhanh. Như tăng theo hàm số mũ. Thuật toán như sau: Thêm vào một biến trạng thái mới, gọi là cửa sổ tắc nghẽn, congestion window (cwnd) tới mỗi trạng thái kết nối. Khi khởi động, hay khởi động lại sau một mất mát nào đó, đặt cwnd tới bằng một gói tin. Với mỗi ACK cho dữ liệu mới, tăng cwnd bởi một, (tức là cửa sổ tắc nghẽn được tăng lên gấp đôi). Khi gửi, gửi lượng nhỏ nhất của cwnd và cửa sổ đã thông báo của người nhận. Hoạt động của thuật toán được mô tả trong hình 16 sau: Hình 16. Hoạt động của thuật toán Slow Start Thuật toán khởi động chậm định nghĩa thêm khái niệm “cửa sổ tắc nghẽn” (congestion window), gọi là cwnd, cho thực thể TCP phát. Một khi kết nối TCP được thiết lập, cwnd được gán giá trị: cwnd=1 đơn vị gói tin có độ dài được thông báo bởi thực thể TCP đối tác. Thực thể TCP bắt đầu phát với cwnd=1. Mỗi khi nhận được thông báo biên nhận trả lời ACK, giá trị cửa sổ cwnd được tăng thêm ACK (nói cách khác, thì giá trị cwnd được tăng gấp đôi), cho đến khi xuất hiện tình trạng tắc nghẽn số liệu thể hiện qua việc gia tăng của thời gian khứ hồi RTT. Đến đây, thực thể phát cần biết rằng độ lớn của cửa sổ cwnd đã quá lớn, và cần phải có điều chỉnh thích hợp. Thuật toán được thể hiện như sau: Initialize: cwnd==1 For (each segment ACKed) Cwnd++ Until(lost_event or cwnd>threshold) Hình 17. Hoạt động của Slow Start Với hình 17 trên, ta thấy cửa sổ tắc nghẽn, cwnd được tăng theo hàm số mũ (nó liên tiếp được nhân đôi), và khi việc mất mát gói tin (được xác định bởi bộ thời gian tại phía người gửi) chỉ ra rằng sự tắc nghẽn là đã xảy ra. Một chú ý quan trọng trong hoạt động này, đó là tốc độ tăng của kích thước cửa sổ w. Để đạt tới kích thước cửa sổ w, nó mất thời gian RTT.log2w, trong đó RTT là thời gian khứ hồi. Như vậy, dễ thấy rằng nếu các kết nối có RTT khác nhau, chúng sẽ nhận được sự chia sẻ băng thông theo thời gian khác nhau, và sự chia sẻ này không công bằng với nhau. Cụ thể, các kết nối có RTT nhỏ hơn, sẽ mất ít thời gian hơn để tăng dần lên lượng băng thông mà chúng chiếm dữ. Các kết nối có chặng đường đi xa hơn, có thời gian RTT lớn hơn sẽ bị sự chia sẻ không công bằng băng thông, khi băng thông tăng nhanh được chia sẻ dần cho các kết nối có chặng đường đi ngắn hơn. Vì vậy, việc nghiên cứu để thực hiện được các chính sách quản lý hàng đợi hợp lý, thực hiện sự chia sẻ công bằng băng thông giữa các kết nối đầu cuối- đầu cuối (end-to-end) có thời gian trễ khác nhau là quan trọng. Chúng giúp đảm bảo sự công bằng trong truyền thông mạng, giúp mạng hoạt động ổn định và hiệu quả hơnl trong khoá luận tốt nghiệp này, việc xây dựng lên mô hình hàng đợi có chứa các mức ưu tiên cho các kết nối, từ đó gán cho mỗi kết nối có được tỉ lệ băng thông định trước sẽ được xem xét, khi đó các kết nối sẽ không bị chiếm dụng băng thông lẫn nhau một cách không công bằng. 2.3.2.2 Thuật toán “tránh tắc nghẽn (congestion avoidance)” số liệu Đặc trưng của hiện tượng tắc nghẽn số liệu là thời gian khứ hồi RTT tăng. Những nguyên nhân dẫn đến sự gia tăng giá trị này có thể được xem đến là: hiện tượng mất gói tin tại một hệ định tuyến nào đó trong mạng (do thiếu bộ nhớ nhận chẳng hạn), dẫn đến time-out và thực thể phát phải thực hiện phát lại gói tin bị mất, hoặc thực thể phát nhận được nhiều lần các thông báo trả lời ACK cho biết tại trạm nhận, các gói tin đã đến không theo thứ tự phát (out-of-order). Biện pháp tránh tắc nghẽn số liệu chính là giảm lưu lượng số liệu vào kênh TCP được thiết lập, từ đó hạn chế được tình trạng mất gói tin. Nó thực chất là việc làm chậm lại của quá trình Slow Start khi cửa sổ tắc nghẽn đang tăng nhanh theo hàm mũ. Chiến lược tránh tắc nghẽn gồm hai thành phần: Thứ nhất: Mạng phải có khả năng gửi tín hiệu đến cho các thực thể ở đầu cuối của các kết nối (endpoint), báo cho chúng biết là tắc nghẽn đang xảy ra hoặc sắp xảy ra. Điều này có nghĩa là: khi tắc nghẽn xảy ra thì các thực thể đầu cuối có thể báo gián tiếp cho các thực thể gửi là tắc nghẽn đã xảy ra. Tức là: nó có thể huỷ bỏ gói tin đó và thực thể gửi chờ sau một thời gian time-out nó không nhận được ACK biên nhận và nó nghĩ rằng lỗi đã xảy ra. Sau đó nó truyền lại. Nhưng vì nhiều lần như thế thì các thực thể gửi hiểu được là tắc nghẽn đã xảy ra và nó tính lại thời gian phát gói tin để truyền một cách thích hợp nhất. Thứ hai: các endpoint phải có chính sách giảm lưu lượng đưa vào mạng nếu nhận được các tín hiệu báo và tăng thêm lưu lượng đưa vào mạng nếu không nhận được tín hiệu báo này. Chính sách của endpoint đối với tắc nghẽn: thích ứng với đường truyền. Khi nhận được tín hiệu báo là có tắc nghẽn xảy ra các thực thể giảm lưu lượng đi vào. Phản ứng của các nốt (node): tăng theo cấp số cộng, tắc nghẽn xảy ra thì giảm theo cấp số nhân (kích thước cửa sổ giảm một nửa). Phản ứng của mạng đối với điều khiển tắc nghẽn: loại bỏ Thuật toán tránh tắc nghẽn như sau: Với mỗi time-out, đặt cwnd tới một nửa kích thước cửa sổ hiện tại (đây được xem là sự giảm theo cấp số nhân, multiplicative decrease). Với mỗi ACK cho dữ liệu mới, tăng cwnd bởi 1/cwnd (đây được xem là sự tăng theo cấp số cộng (additive increase). Khi gửi, chỉ gửi lượng nhỏ nhất của cửa sổ đã thông báo của người nhận và cwnd. Thuật toán khởi động chậm và tránh tắc nghẽn là những kỹ thuật điều khiển lưu lượng, tránh tắc nghẽn số liệu hoạt động độc lập, song có quan hệ mật thiết với nhau và thường được cài đặt cùng nhau. Hoạt động của hai giải pháp kết hợp này như sau: Đặt giá trị ban đầu cwnd=1 đơn vị gói tin và ssthresh=65.535 byte, trong đó ssthresh là ngưỡng trên của thuật toán khởi động chậm. Thực thể TCP không bao giờ phát nhiều hơn giá trị cửa sổ tối thiểu của cwnd và độ lớn của cửa sổ thu rwnd được thực thể thu thông báo trước đó: w=min(cwnd,rwnd). Khi hiện tượng tắc nghẽn số liệu xuất hiện, đặt giá trị cửa sổ w/2 lưu giữ trong trường ssthresh và đặt cwnd=1 đơn vị gói tin. Mỗi khi nhận được thông báo ACK, giá trị cwnd được tăng lên, phụ thuộc vào thuật toán khởi động chậm hay thuật toán tránh tắc nghẽn được thực hiện: Nếu cwnd<ssthresh, thuật toán khởi động chậm được thực hiện: giá trị cwnd được tăng lên 1 đơn vị gói tin với mỗi thông báo ACK nhận được. Ngược lại, nếu cwnd=ssthresh,, thuật toán tránh tắc nghẽn được thực hiện: giá trị cwnd được tăng lên1/cwnd với mỗi thông báo ACK nhận được Chúng ta có thể xem xét việc cài đặt hoạt động kết hợp của hai thuật toán như ở dưới: Hình 18. Hoạt động kết hợp của Slow Start và Congestion Avoidance Có thể thấy độ gia tăng giá trị của cửa sổ phát trong trường hợp điều khiển tránh tắc nghẽn là tuyến tính, trong khi ở thuật toán khởi động chậm (không có tắc nghẽn) là tăng theo hàm số mũ. Điều này đảm bảo tận dụng băng thông được cấp phát, tăng hiệu suất trao đổi số liệu trên kết nối TCP khi áp dụng thuật toán khởi động chậm và vẫn phòng tránh có hiệu quả khi hiện tượng tắc nghẽn số liệu xuất hiện. 2.3.2.3 Thuật toán “phát lại nhanh”. Thông thường, thực thể TCP thực hiện phát lại một gói tin khi nhận được thông báo thu sai, hoặc được đồng hồ quảnlý phát lại kích hoạt (time-out). Thuật toán “phát lại nhanh” (fast retransmission) cho phép thực thể phát thực hiện phát lại không cần chờ đồng hồ time-out, trong trường hợp nhận được nhiều hơn ba thông báo ACK lặp lại, (duplicated ACK). Thông báo ACK lặp lại được tạo ra trong trường hợp thực thể nhận thông báo gói tin đến không đúng theo thứ tự phát (out-of-order) và nêu số thứ tự gói tin chờ nhận. Trong thực tế, thường chỉ cần từ một đến hai thông báo ACK lặp lại là đủ để gói tin “bị lạc” đến và được xử lý đúng thứ tự.nếu thực thể phát nhận được nhiều hơn ba thông báo ACK lặp lại thì điều đó đồng nghĩa với việc gói tin bị mất (packet loss) và trong trường hợp này, gói tin đó cần được phát lại nhanh. 2.3.2.4 Thuật toán “khôi phục nhanh”. Thuật toán khôi phục nhanh (fast recovery) quy định việc thực hiện thuật toán tránh tắc nghẽn ngay sau khi thực hiện phát lại nhanh. Điều này tránh cho lưu lượng số liệu trong kết nối TCP không bị thay đổi đột ngột- nếu thực hiện thuật toán khởi động chậm- và đảm bảo thông lượng số liệu được phù hợp với bối cảnh thực tế: việc phát, thu có lỗi. Thuật toán phát lại nhanh và khôi phục nhanh thường được cài đặt cùng nhau như sau: Sau khi nhận được ba thông báo ACK lặp lại liên tiếp nhau, thực thể phát thiết lập ssthresh=cwnd/2 (không nhỏ hơn hai đơn vị gói tin SMSS) và phát lại gói tin bị mất; Tăng cwnd=cwnd+3*SMSS. Điều này cho phép tăng “nhân tạo” cửa sổ phát cwnd tương ứng với ba gói tin đã rời khỏi mạng, hay nói cách khác: chúng không còn chiếm giữ tài nguyên của mạng (thực chất là: ba gói tin đã nhận trong bộ đệm của thực thể nhận, tương ứng với ba thông báo ACK lặp lại). Với mỗi thông báo ACK lặp lại, tăng cwnd=cwnd+1*SMSS, tương ứng với một gói tin được phát vào mạng (và như được lưu giữ trong bộ đệm của thực thể nhận). Thực hiện phát một gói tin, nếu thoả mãn w=min(cwnd,rwnd); Sau khi nhận được thông báo trả lời ACK không bị lặp lại nghĩa là thông báo về số gói tin nhận được đúng trong khoảng thời gian cho đến thời điểm đó. Đặt w(t)=ssthresh (bước1) và kết thúc thuật toán. Như vậy, việc phát lại nhanh (fash retransmission) được thực thi ngay sau ba biên nhận lặp được nhận, nó tránh được việc phải đợi time-out và không cần phải thực thi Slow Start mà quy định ngay việc thực thi của congestion avoidance điều này tránh cho băng thông bị giảm đột ngột, không tận dụng được đường truyền, khi này, cwnd sẽ dao động xung quanh một giá trị kích thước cửa sổ tối ưu. TCP thực thi các cơ chế điều khiển lưu lượng cũng như tắc nghẽn mạng trong khi vẫn giữ vững, duy trì hiệu suất người dùng tốt. Các sự thực thi trước đó theo mô hình go-back-n, sử dụng biên nhận xác thực tích luỹ và đòi hỏi một sự mãn hạn bộ thời gian truyền lại để gửi lại dữ liệu đã mất trong khi chuyển vận. Các sự thực thi TCP này đã thực hiện được chút ít trong việc hạn chế sự tắc nghẽn mạng của mình. 2.4. Các cơ chế thực thi TCP 2.4.1. Việc áp dụng cơ chế điều khiển lưu lượng trong phiên bản TCP đầu tiên là: Tahoe TCP Tahoe TCP thêm vao các thuật toán mới, cũng như tự tinh chế và làm cho nó thực thi tốt hơn so với TCP trước đó. Các thuật toán được thêm vào bao gồm: Slow Start, congestion avoidance, và fast retransmiss. Tahoe TCP còn tinh chế bộ ước lượng RTT được sử dụng để thiết lập các giá trị time-out chuyển vận lại. Thuật toán phát lại nhanh là sự quan tâm đặc biệt trong sự thực thi này. Với thuật toán này, sau khi nhận được một số lượng nhỏ của các biên nhận lặp cho cùng một TCP segment, người gửi sẽ kết luận rằng một gói tin đã bị thất lạc và sẽ gửi lại gói tin ấy mà không phải chờ cho đến khi bộ thời gian chuyển vận lại hết hạn, điều đó làm cho hiệu suất kết nối và sử dụng kênh truyền được nâng cao. Như vậy, nếu trên mạng xảy ra hiện tượng mất mát gói tin, người gửi sẽ gửi lại dữ liệu sau khi nhận được ba biên nhận lặp, tránh phải đợi time-out, và việc khởi đầu lại được bắt đầu với Slow Start. Hình vẽ 19 cho thấy hoạt động của Tahoe TCP: Hình 19. Hoạt động của Tahoe TCP Với kết qủa mô phỏng như hình 20 sau: Hình 20. Tahoe TCP với một gói tin bị loại bỏ Ở dưới cho trường hợp có một gói tin bị loại bỏ từ cửa sổ dữ liệu, Tahoe TCP sử dụng thuật toán Slow Start để khôi phục lại từ một gói tin bị mất mát. Như trên hình 20, các gói tin từ 0 đến 13 được gửi đi và không có lỗi xảy ra khi cửa sổ tắc nghẽn TCP được người gửi tăng theo hàm mũ từ 1 đến 15, phụ thuộc theo thuật toán Slow Start. Vào lúc cuối của cửa sổ dữ liệu lần gửi thứ tư (lúc này kích thước cửa sổ đã tăng lên đến 8), xảy ra hiện tượng mất mát gói tin do hàng đợi của bộ định tuyến bị đầy, nó là nguyên nhân làm cho gói 14 bị loại bỏ (dropped). Bởi vì bẩy gói trước đó của cửa sổ dữ liệu lần gửi thứ tư đã được phân phát thành công, khi bảy ACKs đã về tới người gửi, kích thước cửa sổ người gửi sẽ tăng lên từ 8 đến 15 và tiếp tục gửi đi 14 gói nữa, từ 15 đến 28. Sau khi nhận ACK đầu tiên của gói tin 13, người nhận gửi nhận 14 biên nhận lặp ACK cho gói tin 13 tương ứng với việc nhận thành công các gói tin từ 15 đến 28 của người nhận. Biên nhận lặp ACK thứ ba đã đạt tới ngưỡng, và thuật toán Retransmission và Slow Start được gọi đến. Thêm nữa, ngưỡng Slow Start, ssthresh, được giảm giá trị thành 7 tức ((8+7)/2). TCP người gửi thiết lập lại cửa sổ tắc nghẽn tới 1 và gửi lại gói tin 14. Người nhận đã nhận được các gói tin từ 15 đến 28, và nhận gói tin 14 đã được gửi lại. Biên nhận cho gói 28 là nguyên nhân làm cho người gửi tăng lên cửa sổ tắc nghẽn bởi 1 và tiếp tục truyền số liệu từ gói 29. Trong khi truyền , khi cửa sổ bắt đầu với gói tin 35, ngưòi gửi đạt tới ngưỡng trên của thuật toán Slow Start và bắt đầu tiến hành thuật toán tránh tắc nghẽn (congestion avoidance). Trong suốt việc truyền thông sau đó, cửa sổ người gửi được tăng lên bởi một gói tin qua mỗi khoảng thời gian khứ hồi round-trip-time. Hình 21 cho chúng ta thấy rõ hơn các quá trình hoạt động ở trên: Hình 21. Hoạt động chi tiết của Tahoe TCP với một gói tin bị loại bỏ 2.4.2. Các cải tiến của giao thức TCP 2.4.2.1 Reno, new-Reno, SACK v.v. Cho mạng truyền thông có dây Reno TCP: Reno TCP đã giữ lại những điểm nổi bật hợp thành lên Tahoe TCP nhưng đã sửa thuật toán phát lại nhanh để thêm vào thuật toán khôi phục nhanh. Thuật toán mới này ngăn chặn đường truyền thông sẽ bị rỗng sau khi phát lại nhanh (do bắt đầu Slow Start lại), vì thế tránh được việc cần thiết phải có thuật toán Slow Start để làm đầy lại đường truyền thông sau khi xảy ra sự mất mát của gói tin. Khôi phục nhanh (fast recovery) hoạt động bằng cách giả thiết rằng mỗi biên nhận lặp ACK đã nhận, sẽ đại diện cho một gói tin đã vừa ra khỏi đường truyền thông. Do đó, trong suốt thời gian khôi phục nhanh, người gửi có thể thực hiện những ước lượng thông minh về khối lượng dữ liệu còn tồn tại. Fast recovery được đưa vào bởi TCP người gửi sau khi nhận một ngưỡng khởi tạo của cácc biên nhận lặp. Giá trị ngưỡng này thường được biết đến như là tcprexmtthresh, thường được gán giá trị bằng 3. Khi giá trị ngưỡng của các biên nhận lặp được nhận, người gửi truyền lại một gói và giảm bớt cửa sổ tắc nghẽn của mình xuống một nửa. Thay vì Slow Start, như được thực hiện bởi người gửi ở Tahoe TCP, người gửi Reno TCP sử dụng các biên nhận lặp mới đến thêm vào để điểm giờ cho các gói tin sắp đi ra tiếp sau. Sau đây là sơ đồ hoạt động của Reno TCP: Hình 22. Hoạt động của Reno TCP Trong hoạt động của Reno TCP, cửa sổ có thể sử dụng được của người gửi trở thành min(awin,cwnd+ndup), ở đây awin là cửa sổ đã thông báo của người nhận, cwnd là cửa sổ tắc nghẽn của người gửi,và ndup được duy trì tại 0 cho đến khi số lượng các biên nhận lặp đạt tới tcprexmtthresh, và sau đó theo dõi số lượng của các biên nhận lặp. Do đó, trong giai đoạn fast recovery người gửi tăng thêm cửa sổ của mình bằng số lượng của các biên nhận lặp mà nó đã vừa nhận, phụ thuộc vào sự theo dõi mỗi biên nhận lặp đó và chỉ ra vài gói tin đã bị đi ra khỏi mạng và đón được tại phía người nhận.sau khi đưa vào thuật toán fast recovery và gửi lại một gói đơn lẻ, người gửi chờ cho đến khi một nửa cửa sổ của các biên nhận lặp được nhận, và rồi gửi một gói tin mới cho mỗi biên nhận lặp thêm vào mà đã được nhận. Cho đến khi nhận một biên nhận ACK cho một gói tin mới (được gọi là biên nhận phục hồi, “recovery ACK”), người gửi thoát khỏi fast recovery bằng cách đặt ndup tới 0. Hình 23. Reno TCP với một gói tin bị loại bỏ Với Reno TCP, thuật toán fast recovery của nó đưa đến sự thực thi tối ưu trong khuôn cảnh này. Cửa sổ tắc nghẽn người gửi bị giảm xuống một nửa, các biên nhận lặp mới đến đã được sử dụng để điểm giờ cho các gói tin sắp đi ra, nó tránh được Slow Start. Các hoạt động của Reno như trên là giống với Tahoe cho đến khi biên nhận thứ tư cho gói tin 13 được nhận ở người gửi. Các biên nhận tương ứng với các gói từ 15 đến 28 bao gồm 14 biên nhận lặp cho gói tin 13. Biên nhận lặp thứ ba gây ra việc truyền lại của gói tin 14, làm cho người gửi phải dùng đến fast recovery, và giảm cửa sổ tắc nghẽn của nó xuống, ngưỡng Slow Start được đặt tới bẩy. Trong giai đoạn fast recovery, việc nhận biên nhận lặp thứ tư đưa cửa sổ có thể sử dụng được đến 11, và bởi biên nhận lặp thứ 14 cửa sổ có thể sử dụng được đạt đến 21. Cửa sổ đã tăng thêm từ sáu biên nhận lặp vừa rồi cho phép ngưòi gửi gửi các gói tin từ 29 đến 34. Cho đến khi biên nhận cho gói 28, người gửi thoát khỏi fast recovery và tiếp tục thực hiện congestion avoidance với cửa sổ tắc nghẽn là bảy. Quá trình hoạt động của nó được thể hiện trên hình 24. Hình 24. Hoạt động chi tiết của Reno TCP với một gói tin bị loại bỏ New-Reno New-Reno có một sửa đổi nhỏ trong thuật toán frcv để cải thiện hiệu năng trong trường hợp một cửa sổ có trên một gói số liệu bị loại. Sự thay đổi liên quan đến hành vi của bên gửi trong quá tình thực hiện frcv, khi nhận được một biên nhận một phần (partial ACK), đó là một biên nhận mới, nhận được sau khi thực hiện phát lại nhanh, biên nhận này có số thứ tự nhỏ hơn số thứ tự của byte cuối cùng đã truyền khi thực hiện phát lại nhanh. Mỗi biên nhận từng phần biên nhận cho một số chứ không phải là tất cả các gói số liệu đã đi vào trong mạng từ khi bắt đầu giai đoạn frcv, do đó nó chỉ ra việc có nhiều gói số liệu bị mất trong một cửa sổ phát. Trong Reno TCP, biên nhận từng phần không làm cho TCP ra khỏi giai đoạn frcv, ngược lại, việc nhận được các biên nhận từng phần được coi như là một tín hiệu báo rằng gói số liệu đi sau (có thứ tự tiếp theo) gói số liệu được biên nhận đã bị mất và nó cần được truyền lại. Như vậy, khi trong một cửa sổ có nhiều gói số liệu bị mất, new-Reno có thể phát lại ngay chứ không bị hết giờ. Mỗi gói số liệu bị mất được phát lại trong khoảng thời gian khứ hồi cho đến khi tất cả các gói số liệu bị mất trong cùng cửa sổ đã được phát lại hết. New-Reno sẽ vẫn ở trong trạng thái frcv cho đến khi mọi gói số liệu được gửi đi từ khi bắt đầu thực hiện frcv được nhận hết. Hình 25. Hoạt động của New Reno TCP, trường hợp có ba gói số liệu bị loại bỏ Trường hợp trong một cửa sổ chỉ có một gói số liệu bị loại, hoạt động của new-Reno và Reno là giống nhau. Hình 25 minh hoạ sự hoạt động của new-Reno trong trường hợp có ba gói số liệu bị loại. SACK TCP Trong SACK TCP (Selective ACKnowledgement TCP) mỗi segment có chứa một trường tuỳ chọn SACK, trường này gồm một số khối SACK, mỗi khối chứa các thông tin về một khối dữ liệu đã được nhận, nhưng không đúng thứ tự, đang được bên nhận chứa trong bộ đệm. Khối SACK thứ nhất chứa thông tin về gói số liệu nhận được mới nhất, khối SACK thứ hai cũng chứa các thông tin như vậy. Việc bổ sung tuỳ chọn SACK vào giao thức TCP không làm thay đổi cơ chế điều khiển tắc nghẽn bên trong của nó, SACK TCP vẫn bảo toàn được các đặc tính của Tahoe và Reno TCP là mạnh trong trường hợp có các gói số liệu đến không đúng thứ tự, nó sử dụng cơ chế phát lại khi bị hết giờ như giải pháp cuối cùng. Hình 26 minh hoạ sự hoạt động của SACK TCP trong trường hợp có ba gói số liệu bị loại. Hình 26. Hoạt động của SACK TCP, trường hợp có ba gói số liệu bị mất SACK TCP giống Reno TCP ở chỗ: SACK TCP đi vào giai đoạn frcv khi bên gửi nhận được số biên nhận lặp bằng tcprexmtthresh; bên gửi sẽ phát lại gói số liệu và giảm cwnd xuống còn một nửa. SACK TCP khác Reno TCP ở chỗ: trong khi thực hiện frcv, SACK TCP duy trì một biến được gọi là pipe. Biến này biểu diễn ước lượng số gói số liệu đã gửi vào mạng nhưng chưa có biên nhận. Bên gửi chỉ gửi dữ liệu mới hoặc phát lại khi ước lượng nói trên nhỏ hơn cửa sổ tắc nghẽn cwnd. Biến pipe sẽ được tăng thêm một mỗi khi bên gửi phát đi một gói số liệu mới hoặc phát lại một gói số liệu cũ, nó giảm đi một khi bên gửi nhận được một gói số liệu biên nhận lặp, trong đó trường tuỳ chọn SACK cho biết rằng bên nhận đã nhận được dữ liệu mới. Trong trường hợp một cửa sổ có không quá một gói số liệu bị loại, hoạt động của SACK TCP cũng giống như Reno và new-Reno TCP. SACK TCP khác Reno TCP một cách căn bản khi nhiều gói số liệu trong một cửa sổ bị loại. Nhận xét các biện pháp thực thi TCP: Hiệu suất của Tahoe TCP không bị giảm quá mạnh khi tỉ lệ gói tin hỏng tăng. Reno TCP có hiệu suất cao hơn hẳn Tahoe TCP khi trong một cửa sổ có một gói số liệu bị loại. Số gói số liệu bị loại trong một cửa sổ càng tăng thì hiệu suất của Reno TCP càng tồi. Ngay cả trường hợp trong một cửa sổ có hai gói số liệu bị loại, hiệu suất của Reno TCP đã thấp hơn hiệu suất của Tahoe TCP nhiều. New-Reno và SACK TCP có hiệu suất cao hơn Tahoe và Reno khi số gói số liệu bị loại trong một cửa sổ lớn hơn một. Khi số gói số liệu trong một cửa sổ bị loại tăng lên trên hai, SACK TCP có hiệu suất cao hơn new-Reno TCP. Đó là vì new-Reno chỉ có thể phát lại nhiều nhất là một gói số liệu bị loại trong mỗi khoảng thời gian khứ hồi, gây ra sự trễ lớn trong việc phát lại các gói số liệu bị loại tiếp theo trong cùng cửa sổ. 2.4.2.2 Sơ qua các cải tiến giao thức TCP cho mạng không dây Indirect TCP (I-TCP) TCP gián tiếp (Indirect TCP): theo cơ chế này, kết nối TCP từ người gửi sẽ kết thúc tại đầu vào đường truyền hay gây lỗi, nơi đặt agent TCP, agent sẽ biên nhận các gói số liệu mà nó nhận được và chịu trách nhiệm gửi nó đến đích. Trên đường truyền không dây, nơi có tỉ suất lỗi bit cao và thất thường, một kết nối TCP được tinh chỉnh cho phù hợp với đặc điểm của đường truyền này sẽ được thiết lập. Ngoài kết nối TCP, tại đây, cũng có thể sử dụng một giao thức giao vận khác. Nhược điểm của I-TCP là làm mất ngữ nghĩa đầu cuối- đầu cuối của giao thức TCP, nút trung gian (trong đó có agent TCP) gửi biên nhận thay cho người nhận, do đó biên nhận có thể đến người gửi trước khi gói số liệu thực sự đến người nhận. Ngoài ra, I-TCP cũng gây khó khăn cho các trạm cơ sở, vì chúng phải chuyển cho nhau một lượng lớn thông tin trạng thái khi xảy ra việc chuyển cuộc gọi. Snoop TCP Cơ chế thực hiện agent TCP thứ hai này tôn trọng ngữ nghĩa “end-to-end”. Agent nằm giữa hai mạng không chia đôi kết nối TCP, nó chỉ giữ bản sao các gói số liệu chứ không tự sinh ra các biên nhận. Các biên nhận không phải là lặp mà bên nhận gửi lại sẽ được agent chuyển tiếp tới cho bên gửi, còn các biên nhận lặp sẽ bị chặn lại, tránh cho bên gửi chuyển sang pha phát lại nhanh. Khi nhận được biên nhận lặp thứ ba, hoặc khi agent đã đợi quá một khoảng thời gian hết giờ cục bộ, gói số liệu tương ứng sẽ được agent phát lại. Thời gian hết giờ cục bộ này phải được xác định phù hợp với đường truyền không dây chỉ có một chặng, nó đương nhiên là nhỏ hơn thời gian hết giờ mà bên người gửi (nguồn) sử dụng. Về thực chất, giải pháp Snoop-TCP cũng giống giải pháp phát lại ở tầng liên kết dữ liệu, vì vậy, chúng cũng còn có tên gọi là “phát lại ở tầng liên kết có sự nhận biết TCP” (TCP aware link layer retransmission). Cả hai giải pháp này đều đòi hỏi không có sự mất gói số liệu do tắc nghẽn trên đường truyền snoop agent và đích, nghĩa là từ trạm cơ sở đến người nhận chỉ có một chặng. Ngoài ra, giải pháp này cũng có nhược điểm tương tự giải pháp phát lại ở tầng liên kết dữ liệu, đó là nó có thể vẫn cản trở các cơ chế kiểu đầu cuối- đầu cuối, nếu thời gian đường truyền xấu kéo quá dài. Như vậy, với các biện pháp cải tiến này ta thấy sử dụng mạng hiệu suất cao hơn hẳn. Chương 3: KHẢO SÁT ĐÁNH GIÁ HIỆU SUẤT CỦA TCP BẰNG BỘ MÔ PHỎNG MẠNG NS2 3.1. Giới thiệu về bộ mô phỏng mạng NS2 (Network Simulator Version 2) Việc nghiên cứu các mạng thực sẽ trở nên trực quan, đáng tin cậy, dễ dàng và đưa đến những kết quả chính xác hơn nếu chúng ta sử dụng một hệ thống phần mềm mô phỏng mạng thích hợp, NS (Network Simulator) là một phần mềm như thế. Các hoạt động mạng thực được mô phỏng để xem xét về đặc tính, tính chất hoạt động của mạng, từ đó có thể đánh giá hay đề ra các cải tiến, tinh chỉnh giao thức để nâng cao hiệu suất truyền thông trên mạng. NS2 (Network Simulator Version 2) là hệ thống phần mềm mô phỏng máy tính được xây dựng và phát triển bởi dự án VINT của phòng thí nghiệm quốc gia Lawrence Berkeyley Laborary ở Mỹ. NS là hệ mô phỏng có cấu trúc hướng đối tượng được xây dựng bằng hai ngôn ngữ C++ và Otcl, nó được xây dựng theo cách để có thể mở rộng được dễ dàng bởi người dùng. Với NS, người dùng có thể mô phỏng các mạng LAN, WAN, … theo kiểu truyền thống có dây, không dây, hỗn hợp có dây và không dây, các mạng thông tin vệ tinh,… NS có thể mô phỏng sự thực thi của những giao thức mạng như TCP, UDP, thực hiện phương thức khai thác truyền thông như FTP, TELNET, WEB, CBR và VBR, kỹ thuật quản lý hàng đợi tại các bộ định tuyến như là Drop Tail, Red, và CBQ, các thuật toán định tuyến như Dijkstra,… Cùng với NS, NAM (Network Animator) và Xgraph là hai bộ công cụ phần mềm đi kèm được dùng để xem xét, nghiên cứu, trực quan hoá những kết quả thu được từ ns dưới dạng đồ hoạ. Chúng thể hiện các quá trình và kết quả thu được trên giao diện màn hình đồ hoạ, tiện cho người dùng có thể xem xét sự hoạt động của mạng và có thể phát hiện được một số sai sót trong việc viết kịch bản mô phỏng. Hình vẽ 27 dưới đây cho thấy sự thể hiện của màn hình NAM. Ngoài các công cụ đi kèm NS là NAM và XGRAPH nêu trên, em cũng đã sử dụng một bộ chương trình công cụ để phân tích kết quả mô phỏng trong trace file, có tên là trace graph, tác giả là Jaroslaw malek, thuộc trường Đại học Tổng hợp kỹ thuật Wroclaw, Ba Lan, đóng góp cho cộng đồng sử dụng NS. Phiên bản 2.02 có thể chạy trong môi trường Linux, Unix và cả Windows nữa. Màn hình hiển thị kết quả phân tích bằng đồ thị của trace graph được trình bày trên hình 31. Hình 27. Màn hình thể hiện của NAM (Network Animator) Có thể hình dung một cách đơn giản về hoạt động của ns qua hình vẽ 28 sau đây: Hình 28. Hoạt động của NS dưới góc nhìn của người sử dụng Như vậy, để có thể thực hiện một chương trình mô phỏng mạng, cũng như công việc lập trình, người dùng cần viết một kịch bản (script) cho chương trình mô phỏng, nó là một script trong ngôn ngữ otcl, được NS xử lý, thông qua việc liên kết tới các thư viện của mình, NS sẽ đưa ra kết quả mô phỏng, thông qua NAM hay công cụ xử lý khác, người dùng có thể đánh giá các tham số mạng mô phỏng của mình. NS cung cấp các kết quả mô phỏng dưới dạng file văn bản một cách chính xác, đầy đủ và có thể tuỳ biến mềm dẻo. Các file kết quả: Khi thực hiện việc mô phỏng, NS sẽ sinh ra các trace file ghi lại toàn bộ quá trình xảy ra các sự kiện trong thời gian mô phỏng được gọi là các trace file (các file dấu vết), có phần tên mở rộng là tr. Ngoài ra NS còn có thể tạo ra một loại trace file nữa, có tên mở rộng là NAM, dùng làm input cho chương trình hiển thị trực quan NAM. Sau đây là cấu trúc một trace file: Hình 29. Cấu trúc một trace file Theo hình trên chúng ta thấy, cấu trúc một trace file gồm các dòng, mỗi dòng ghi các thông tin về một sự kiện mạng và bao gồm 12 trường, các trường có ý nghĩa như sau: Event: có bốn giá trị được diễn tả là: r (receive), + (enqueue), - (dequeue), và d (drop), chúng lần lượt tương ứng với việc nhận packet tại nút mạng có định danh được ghi trong trường to_node, đưa packet vào hàng đợi, đưa packet ra khỏi hàng đợi, và loại bỏ packet khỏi hàng đợi. Time: thời gian xảy ra sự kiện mô phỏng, tính theo đơn vị giây. From node: xác định nút gửi gói tin. Pkt type: kiểu của packet. Pkt size: kích thước của packet tính theo byte. Flags: thiết lập các giá trị cờ. Fid: flow id, định danh dòng (hay kết nối). Src addr: địa chỉ nút nguồn. Dst addr: địa chỉ nút đích. Seq num: định danh duy nhất của packet. Như vậy, các trace file chứa đầy đủ các thông tin về từng sự kiện diễn ra trong quá trình hoạt động của mạng, trace file là cần thiết cho việc nghiên cứu mạng mô phỏng. 3.2. Thí nghiệm mô phỏng và kết quả đạt được 3.2.1. Thí nghiệm mô phỏng Chương trình mô phỏng do em xây dựng được in trong phụ lục của khoá luận tốt nghiệp này. File chương trình có tên “kltn-nthat01.tcl”, file vết của chương trình mô phỏng có tên là “kltn-nthat01.tr”, file vết dùng cho chương trình hiển thị NAM có tên là “kltn-nthat01.nam”. Mạng mô phỏng được xây dựng gồm 6 nốt tham gia vào quá trình truyền thông, với các kết nối như mô tả trên hình vẽ 30. NS tự động đánh số thứ tự các nốt theo thứ tự các nốt được tạo ra, đầu tiên là nốt 0. Để dễ nhớ, em gán tên cho các nốt, thí dụ s1, s2 ... với chữ cái s nhần chỉ các nốt có thể gửi (send) gói tin số liệu hoặc gói tin biên nhận, chữ cái r ngầm chỉ bộ định tuyến – router. Nốt 0 (trên hình ghi nhãn là s1) sẽ gửi các gói tin tới nốt 4 (s3), nốt 1 (s2) sẽ gửi các gói tin tới nốt 5 (s4), hai luồng gói tin ứng với 2 kết nối sẽ cùng đi qua chặng đường từ nốt 2 (r1) đến nốt 3 (r2). Như vậy, tô pô của mạng đã được xác định. Để thực hiện việc gửi dữ liệu giữa các nốt, chúng ta phải tạo các agent gửi dữ liệu từ các nốt gửi cũng như tạo các agent nhận dữ liệu trên nốt nhận. Ở đây, các agent TCP (TCP1, TCP2) gửi sẽ được gắn vào các nốt s1, s2. Các agent sink (sink1, sink2) nhận dữ liệu sẽ được gắn vào nốt s3, s4. Khi đó chúng ta nối các agent này tương ứng lại với nhau. Tiếp đến chúng ta tạo các nguồn truyền thông (traffic source) ftp (ftp1,ftp2) và gắn chúng tương ứng vào các agent TCP. Chúng ta có thể thấy rõ chi tiết mạng mô phỏng qua hình vẽ 30 sau: Hình 30. Chi tiết tô pô của mạng mô phỏng Em thực hiện thí nghiệm mô phỏng với việc truyền thông từ nốt s1 đến nốt s3 và từ nốt s2 đến nốt s4. Thực thể tcp1 truyền các gói tin đến thực thể nhận sink1 trên nốt s3 trong khoảng thời gian 0.1s đến 10.0s; Thực thể tcp2 truyền các gói tin đến thực thể nhận sink2 trên nốt s4 trong khoảng thời gian 3s đến 10.0s; Kích thước gói tin lấy giá trị mặc định bằng 1040 byte. Tương tự như vậy, kích thước hàng đợi tại các nốt trung gian r1, r2 và một số tham số khác được nhận giá trị mặc định của bộ mô phỏng mạng NS. 3.2.2. Phân tích trace file Sau khi chạy chương trình mô phỏng với cấu hình và các tham số được mô tả ở phần trên, em sử dụng chương trình tracegraph để phân tích kết quả mô phỏng bằng đồ thị và nhận được kết quả như trên hình vẽ 31 dưới đây. Trục hoành “simulation time” – chính là thời gian mô phỏng. Trục tung “throughput of receiving packets [no. of receiving packets / TIL]”, chính là thông lượng tại bên nhận tính theo đơn vị TIL (Time Interval Lenghth), với thí nghiệm mô phỏng này, TIL = 1s. Đường số 1 (nét mảnh màu hồng) nhận được khi chọn “throughput of receiving packets at curent node 4”, đó là đường biểu diễn thông lượng của kết nối tcp giữa nốt s1 và s3. Đường số 2 (nét đậm màu xanh da trời sẫm) nhận được khi chọn “throughput of receiving packets at curent node 5”, đó là đường biểu diễn thông lượng của kết nối tcp giữa nốt s2 và s4. Đường số 3 (nét mảnh màu xanh lơ, nằm ở trên cùng) nhận được khi chọn “throughput of receiving packets”, đó là đường biểu diễn thông lượng tổng cộng của cả 2 kết nối TCP nêu trên. Hình 31. Thông lượng của các kết nối 3.2.3. Nhận xét và kết luận Nhận xét: Về thông lượng của kết nối TCP thứ nhất, giữa nốt s1 và nốt s3: Thông lượng cực đại là 185 packets/s, đạt được trong khoảng thời gian từ 2,15s đến 3,15s, đó là lúc kết nối tcp thứ hai giữa nốt s2 và nốt s4 chưa gửi các gói tin lên đường truyền. Với kích thước 1 packet bằng 1040 byte, em đổi ra đơn vị Mbps được: 185 packets/s * 1040 bytes/packet * 8 bits/byte /220 = 1,47 Bbps. So với đường truyền giữa r1 và r2 có băng thông là 1,54Mbps, thông lượng cực đại trên bằng: 95,3%. Khi kết nối thứ 2 đi vào hoạt động (thời điểm 3,1s), thông lượng của cả 2 kết nối bắt đều tiến tới giá trị dừng (ổn định) sau khoảng 2s (thời điểm 5s). Từ thời điểm đó cả 2 đường biểu diễn thông lượng của 2 kết nối dao động quanh một giá trị trung bình, bằng khoảng 92 packets/s. Nếu tính ra Mbps tương tự như cách tính trên, sẽ nhận được giá trị bằng 50,1Mbps. Nếu đem chia cho 1,54Mbps sẽ được 47,4%. Về thông lượng của kết nối tcp thứ hai, giữa nốt s2 và nốt s4: Đường cong thông lượng tăng dần lên bắt đầu từ thời điểm 3,1s cho đến thời điểm 5,2s thì đạt giá trị khoảng 92 packets/s, là giá trị trung bình của cả 2 kết nối, tính từ thời điểm đó cho đến khi kết thức mô phỏng (10s). Kết luận: TCP có khả năng tự thích ứng với đường truyền và sử dụng hữu hiệu đường truyền. Khi đường truyền rỗi (chỉ có một kết nối tcp hoạt động), kết nối tcp sẽ nhanh chóng sử dụng gần như toàn bộ băng thông của đường truyền. Trong thí dụ của em, kết nối tcp thứ nhất chỉ cần khoảng 2,1s là đạt tới thông lượng bằng 95,3% năng khả năng vận chuyển của đường truyền. TCP có khả năng chia sẻ công bằng đường truyền với các kết nối tcp khác. Khi có nhiều kết nối cùng chia sẻ một đường truyền chung, mỗi kết nối sẽ sử dụng được một phần băng thông, sự chia sẻ là tương đối công bằng. Trong thí dụ mô phỏng của em, 2 kết nối được thiết lập qua các đường truyền có các tham số giống hệt nhau, vì vậy sự chia sẻ là 50/50, nghĩa là mỗi kết nối sử dụng 50% khả năng vận chuyển của đường truyền. Tuy nhiên nếu các kết nối có các tham số “bandwidth x delay” khác nhau, tỉ lệ chia sẻ sẽ khác nhau [8]. KẾT LUẬN Các kết quả đạt được Qua việc nghiên cứu khoá luận tốt nghiệp này, chúng ta thu được những kết quả như sau: Thấy được sự phát triển ngày càng lớn mạnh của mạng Internet và các vấn đề nảy sinh trong mạng. Thấy được hiện tượng tắc nghẽn và các cơ chế để điều khiển lưu lượng và điều khiển tắc nghẽn. Tìm hiểu về giao thức TCP và cách điều khiển lưu lượng + điều khiển tắc nghẽn của giao thức. Biết được các cải tiến của TCP: Tahoe, Reno, New-Reno, SACK v.v. cho mạng truyền thông có dây cũng như không dây như: Indirect TCP, snoop TCP và các thuật toán áp dụng điều khiển lưu lượng cũng như điều khiển tắc nghẽn trong các cải tiến này. Tìm hiểu về bộ mô phỏng mạng :NS2(Network version 2) Thực hiện mô phỏng thấy được: Sử dụng giao thức TCP hiệu suất sử dụng đường truyền gần như tối đa. Việc đảm bảo tính công bằng trong chia sẻ: Các kết nối TCP có tích bandwidth*delay bằng nhau, sẽ chia sẻ dải thông bằng nhau và ngược lại sẽ chia sẻ không công bằng.