TIỂU LUẬN MÔN HỌC: BÁO HIỆU ĐIỀU KHIỂN VÀ KẾT NỐI NHÓM 13 1 ĐỀ TÀI: ĐIỀU KHIỂN TẮC NGHẼN CHO GIAO THỨC TCP HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG KHOA VIỄN THÔNG I TIỂU LUẬN MÔN HỌC: BÁO HIỆU ĐIỀU KHIỂN VÀ KẾT NỐI NHÓM 13 1 ĐỀ TÀI: ĐIỀU KHIỂN TẮC NGHẼN CHO GIAO THỨC TCP
TỔNG QUAN VỀ GIAO THỨC TCP
Lịch sử phát triển của TCP
Mạng Internet là một mạng máy tính toàn cầu, bắt nguồn từ thập kỷ 60 qua thí nghiệm của Bộ Quốc phòng Mỹ với ARPAnet Ban đầu, ARPAnet được thiết kế cho các nghiên cứu quốc phòng, nhằm tạo ra một mạng có khả năng chịu đựng sự cố, cho phép các máy tính liên lạc với nhau ngay cả khi một số nút bị tấn công.
Khả năng kết nối các hệ thống máy tính khác nhau đã thu hút sự chú ý của nhiều người, và đây cũng là phương pháp thực tế duy nhất để liên kết các máy tính từ các hãng khác nhau Điều này dẫn đến việc các nhà phát triển phần mềm ở Mỹ, Anh và Châu Âu tích cực nghiên cứu và phát triển các giải pháp kết nối hiệu quả.
Châu Âu đã phát triển phần mềm dựa trên giao thức TCP/IP, giúp truyền thông hiệu quả trên Internet cho mọi loại máy tính Sự phát triển này thu hút sự quan tâm từ các trường đại học, trung tâm nghiên cứu lớn và cơ quan chính phủ, những tổ chức mong muốn có sự linh hoạt trong việc mua sắm máy tính mà không bị ràng buộc vào một nhà sản xuất cụ thể nào.
Vào năm 1983, sự phát triển của các hệ thống mạng cục bộ LAN đã diễn ra song song với sự xuất hiện của máy để bàn (Desktop Workstations) Hầu hết các máy này sử dụng Berkeley UNIX, trong đó phần mềm kết nối TCP/IP được tích hợp như một phần của hệ điều hành Điều này cho thấy rằng các mạng cục bộ có khả năng kết nối với nhau một cách dễ dàng.
Trong quá trình phát triển mạng Internet, NSFNET, được tài trợ bởi Hội khoa học Quốc gia Mỹ, đã đóng vai trò quan trọng Cuối những năm 80, NSF thiết lập 5 trung tâm siêu máy tính, trước đó chỉ có những máy tính nhanh nhất phục vụ cho việc phát triển vũ khí và một số công ty lớn Với các trung tâm này, NSF đã mở ra cơ hội cho mọi người trong lĩnh vực khoa học có thể truy cập và sử dụng công nghệ tiên tiến.
NFS đã lên kế hoạch sử dụng ARPAnet để kết nối 5 trung tâm máy tính, nhưng kế hoạch này đã bị cản trở bởi sự quan liêu trong bộ máy hành chính Do đó, NFS quyết định xây dựng một mạng riêng, dựa trên giao thức TCP/IP với tốc độ truyền 56 Kbps Các trường đại học được kết nối thành các mạng vùng, và những mạng này được liên kết với các trung tâm siêu máy tính.
Ngày nay, Internet đã phát triển nhanh chóng trong lĩnh vực khoa học và giáo dục tại Mỹ, sau đó lan rộng ra toàn cầu Nó đóng vai trò quan trọng trong việc trao đổi thông tin, đặc biệt trong các lĩnh vực nghiên cứu và giáo dục, và gần đây còn hỗ trợ mạnh mẽ cho thương mại.
Internet sử dụng kỹ thuật chuyển mạch gói kết hợp với giao thức TCP/IP Hiện nay, nhiều mạng với kiến trúc đa dạng có khả năng kết nối vào Internet thông qua các cầu nối đa giao thức.
Giao thức TCP
Giao thức TCP (Transmission Control Protocol - "Giao thức điều khiển truyền vận") là một trong những giao thức quan trọng của bộ giao thức TCP/IP, cho phép các ứng dụng trên máy chủ kết nối và trao đổi dữ liệu một cách đáng tin cậy và theo thứ tự TCP còn giúp phân biệt dữ liệu của nhiều ứng dụng khác nhau trên cùng một máy chủ Để đơn giản hóa thiết kế và cài đặt mạng, hầu hết các mạng máy tính hiện nay được xây dựng theo mô hình phân tầng, trong đó mỗi tầng dựa trên tầng trước đó Mô hình tham chiếu 7 lớp của IOS (tổ chức tiêu chuẩn hóa quốc tế) là tiêu chuẩn để so sánh với các giao thức khác, do đó, trước khi nghiên cứu giao thức TCP/IP, cần tìm hiểu về mô hình 7 lớp OSI.
Trong mô hình OSI, mỗi tầng có nhiệm vụ cung cấp dịch vụ cho tầng cao hơn và mô tả cách cài đặt các dịch vụ này một cách chi tiết Các tầng được trừu tượng hóa, với mỗi tầng chỉ nhận thức được việc liên lạc với tầng tương ứng trên hệ thống khác Thực tế, mỗi tầng chỉ giao tiếp với các tầng liền kề trên và dưới của nó trong cùng một hệ thống.
Trong mô hình mạng không tầng, chỉ có tầng thấp nhất có khả năng chuyển thông tin trực tiếp với tầng tương ứng trong mạng máy tính khác Để gửi thông tin, dữ liệu trên máy cần được truyền qua tất cả các tầng thấp hơn trước khi được chuyển qua card mạng đến máy nhận Sau đó, thông tin sẽ tiếp tục được truyền lên qua các tầng cho đến khi đến tầng đã gửi thông tin.
Mô hình này bao gồm 7 tầng Tên gọi và chức năng các tầng được trình bày trong Hình 1.1
Hình 1.1: Mô hình 7 lớp OSI
Chức năng của các tầng như sau:
1 Tầng vật lý (Physical): Liên quan đến nhiệm vụ truyền dòng bits không có cấu trúc qua đường truyền vật lý, truy nhập đường truyền vật lý nhờ các phương tiện cơ, điện, hàm, vật lý.
2 Tầng liên kết dữ liệu (Data link): Cung cấp phương tiện để truyền thông tin qua liên kết vật lý đảm bảo tin cậy, gửi các khối dữ liệu với các cơ chế đồng bộ hoá, kiểm soát lỗi và kiểm soát luồng dữ liệu cần thiết.
3 Tầng mạng (Network): Thực hiện việc chọn đường và chuyển tiếp thông tin với công nghệ chuyển mạch thích hợp, thực hiện kiểm soát luồng dữ liệu và cắt hợp dữ liệu nếu cần
4 Tầng giao vận (Transport): Thực hiện việc truyền dữ liệu giữa hai đầu mút (end - to - end), thực hiện cả việc kiểm soát lỗi và kiểm soát luồng dữ liệu giữa hai đầu mút Cũng có thể thực hiện việc ghép kênh, cắt / hợp dữ liệu nếu cần.
5 Tầng phiên (Session): Cung cấp phương tiện quản lý truyền thông giữa các ứng dụng, thiết lập, duy trì, đồng bộ hoá và huỷ bỏ các phiên truyền thông giữa các ứng dụng
6 Tầng trình diễn (Presentation): Chuyển đổi cú pháp dữ liệu để đáp ứng yêu cầu truyền dữ liệu của các tầng ứng dụng qua mô hình OSI
7 Tầng ứng dụng (Application): Cung cấp các phương tiện để người sử dụng có thể truy cập được vào môi trường OSI, đồng thời cung cấp cácdịch vụ thông tin phân tán
1.2.3 Mô hình giao thức TCP
Mạng Internet sử dụng giao thức TCP/IP, được minh họa tổng quát trong hình 1.2, cho thấy các dịch vụ mà nó cung cấp cùng với các chuẩn được sử dụng So sánh với kiến trúc hệ thống mở OSI giúp chúng ta có cái nhìn tổng quát về họ giao thức này.
Hình 1.2: Giao thức TCP/IP khi so sánh với mô hình OSI
SMTP- Simple Mail Transfer Protocol
SNMP - Simple Network Manage Protocol
ICMP- Internet Control Message Protocol
FDDI - Fiber Distributed Data Interface
TCP (Giao thức kiểm soát truyền tải) là một phần quan trọng trong tầng giao vận của TCP/IP, có chức năng đảm bảo sự liên lạc thông suốt và tính chính xác của dữ liệu giữa hai đầu kết nối thông qua các gói tin IP.
UDP (User Datagram Protocol) là giao thức nằm ở tầng giao vận của TCP/IP Khác với TCP, UDP không đảm bảo tính toàn vẹn của dữ liệu và không có cơ chế sửa lỗi Tuy nhiên, UDP mang lại tốc độ truyền dữ liệu nhanh hơn so với TCP.
IP: (Internet Protocol) Là giao thức ở tầng thứ 3 của TCP/IP, nó có trách nhiệm vận chuyển các Datagrams qua mạng Internet
ICMP (Giao thức Thông điệp Điều khiển Internet) là một thủ tục quan trọng trong mạng TCP/IP, giúp truyền tải thông tin điều khiển Giao thức này xử lý các thông báo trạng thái cho IP, bao gồm thông tin về lỗi và các thay đổi trong phần cứng của mạng, từ đó ảnh hưởng đến việc định tuyến thông tin trong mạng.
RIP: (Routing Information Protocol) Giao thức định tuyến thông tin đây là một trong những giao thức để xác định phương pháp định tuyến tốt nhất cho truyền tin
ARP (Giao thức phân giải địa chỉ) là một giao thức thuộc tầng liên kết dữ liệu, có nhiệm vụ xác định địa chỉ vật lý tương ứng với một địa chỉ IP cụ thể Để thực hiện chức năng này, ARP sử dụng phương pháp Broadcasting trên mạng, cho phép máy trạm có địa chỉ IP trùng khớp với địa chỉ đang được truy vấn gửi phản hồi với thông tin về địa chỉ vật lý của nó.
DSN: (Domain name System) Xác định các địa chỉ theo số từ các tên của máy tính kết nối trên mạng
FTP, or File Transfer Protocol, is a fundamental Internet service that facilitates the transfer of files from one computer to another.
Cấu trúc phân đoạn TCP
Phân đoạn TCP bao gồm tiêu đề và trường dữ liệu, trong đó trường dữ liệu chứa thông tin ứng dụng Kích thước tối đa của trường dữ liệu được giới hạn bởi MSS Khi gửi tệp lớn, như hình ảnh trên trang web, TCP thường chia tệp thành nhiều phần có kích thước MSS Tuy nhiên, các ứng dụng tương tác thường truyền dữ liệu nhỏ hơn MSS; chẳng hạn như trong các ứng dụng đăng nhập từ xa như Telnet và SSH, trường dữ liệu trong phân đoạn TCP thường nhỏ hơn kích thước MSS.
NHÓM 13 14 chỉ có một byte Vì tiêu đề TCP thường 20 byte ( nhiều hơn 12 byte so với tiêu đề UDP), các phân đoạn được gửi bởi Telnet và ssh có thể chỉ có độ dài 21 byte
Hình 1.4 cho thấy cấu trúc phân đoạn của TCP Tiêu đề phân đoạn TCP có chứa các trường sau:
Trường số thứ tự 32 bit và số xác nhận 32 bit là hai thành phần quan trọng mà người gửi và người nhận TCP sử dụng để đảm bảo dịch vụ chuyển nhượng dữ liệu đáng tin cậy.
Trường 16 bit được sử dụng điều khiển luồng Nó được sử dụng để chỉ số byte mà người nhận sẵn sàng chấp nhận
Trường độ dài tiêu đề trong TCP là 4 bit, cho biết độ dài của tiêu đề TCP dưới dạng từ 32 bit Tiêu đề TCP có thể thay đổi độ dài nhờ vào trường tùy chọn TCP, mặc dù thường thì trường này trống, vì độ dài tiêu đề TCP điển hình là 20 byte.
Trường tùy chọn có độ dài thay đổi được sử dụng khi người gửi và người nhận thương lượng kích thước phân đoạn tối đa (MSS) hoặc tỷ lệ cửa sổ trong mạng tốc độ cao Ngoài ra, một tùy chọn đóng dấu thời gian cũng được xác định.
Trường cờ TCP chứa 6 bit, trong đó bit ACK xác nhận tính hợp lệ của dữ liệu nhận được, cho biết rằng một phân đoạn đã được nhận thành công Các bit RST, SYN và FIN có vai trò thiết lập và kết thúc kết nối, trong khi bit CWR và ECE thông báo về tình trạng tắc nghẽn Bit PSH cho phép máy thu chuyển dữ liệu ngay lập tức lên lớp trên, và bit URG chỉ ra rằng có dữ liệu khẩn cấp trong phân đoạn, với vị trí của dữ liệu khẩn cấp được xác định bởi trường con trỏ dữ liệu khẩn cấp 16 bit Mặc dù trong thực tế, các trường PSH, URG và con trỏ dữ liệu khẩn cấp ít được sử dụng, nhưng chúng vẫn được đề cập để hoàn thiện kiến thức về TCP.
Hình 1.4: Cấu trúc phân đoạn TCP
Sequence Numbers and Acknowledgment Numbers:
Hai trường quan trọng trong tiêu đề phân đoạn TCP là trường số thứ tự và trường số xác nhận, đóng vai trò thiết yếu trong việc cung cấp dịch vụ truyền dữ liệu đáng tin cậy Trước khi tìm hiểu cách thức hoạt động của các trường này trong việc đảm bảo truyền dữ liệu an toàn, chúng ta cần làm rõ nội dung mà TCP lưu trữ trong các trường này.
TCP xem dữ liệu như một luồng byte không có cấu trúc nhưng có thứ tự, với số thứ tự phản ánh vị trí của các byte trong luồng Mỗi phân đoạn được đánh số dựa trên số thứ tự của byte đầu tiên trong phân đoạn đó Ví dụ, khi một quá trình trên Máy chủ A gửi dữ liệu tới Máy chủ B qua kết nối TCP, TCP trên Máy chủ A sẽ đánh số từng byte trong luồng dữ liệu Nếu luồng dữ liệu là một tệp 500.000 byte và MSS là 1.000 byte, byte đầu tiên sẽ được đánh số 0.
NHÓM 13 16 dựng 500 phân đoạn ra khỏi luồng dữ liệu Phân đoạn đầu tiên được chỉ định số thứ tự 0, phân đoạn thứ hai được gán số thứ tự 1.000, phân đoạn thứ ba được đã gán số thứ tự 2.000, v.v Mỗi số thứ tự được chèn vào trường số thứ tự trong tiêu đề của phân đoạn TCP thích hợp
Số xác nhận trong giao thức TCP là một khía cạnh quan trọng, cho phép Máy chủ A nhận dữ liệu từ Máy chủ B trong khi cũng gửi dữ liệu trở lại Mỗi phân đoạn từ Máy chủ B đều có số thứ tự tương ứng, và số xác nhận mà Máy chủ A gửi trong phân đoạn của mình phản ánh byte tiếp theo mà nó đang mong đợi từ B Ví dụ, nếu Máy chủ A đã nhận tất cả các byte từ 0 đến 535 và đang chờ byte 536, nó sẽ đặt số 536 vào trường số xác nhận trong phân đoạn gửi đến Máy chủ B.
Telnet: A Case Study for Sequence and Acknowledgment Numbers
Telnet, theo định nghĩa trong RFC 854, là một giao thức tầng ứng dụng phổ biến cho điều khiển từ xa và đăng nhập, hoạt động trên TCP và cho phép giao tiếp giữa các máy chủ Là một ứng dụng tương tác, Telnet minh họa rõ ràng trình tự TCP và số xác nhận Tuy nhiên, nhiều người dùng hiện nay ưu tiên sử dụng giao thức SSH hơn Telnet, do dữ liệu truyền qua Telnet, bao gồm cả mật khẩu, không được mã hóa, dẫn đến nguy cơ bị tấn công nghe trộm.
Khi Máy chủ A khởi tạo phiên Telnet với Máy chủ B, Máy chủ A trở thành máy khách và Máy chủ B là máy chủ Mọi ký tự mà người dùng nhập trên máy khách sẽ được gửi đến máy chủ từ xa, và máy chủ sẽ phản hồi bằng cách gửi lại một bản sao của từng ký tự, bản sao này sẽ hiển thị trên màn hình Telnet của người dùng.
“Phản hồi lại” này được sử dụng để đảm bảo rằng các ký tự được người dùng Telnet nhìn
NHÓM 13 17 thấy đã được nhận và xử lý tại trang web từ xa Mỗi nhân vật như vậy truyền qua mạng hai lần giữa thời gian người dùng nhấn phím và thời gian ký tự được hiển thị trên màn hình của người dùng
Hình 1.5: Số thứ tự và xác nhận cho một Telnet đơn giản ứng dụng qua TCP
Khi người dùng nhập chữ cái 'C' và lấy một ly cà phê, chúng ta cần kiểm tra các phân đoạn TCP giữa máy khách và máy chủ Giả sử số thứ tự bắt đầu cho máy khách là 42 và cho máy chủ là 79 Số thứ tự của một đoạn TCP là số thứ tự của byte đầu tiên trong trường dữ liệu, vì vậy phân đoạn đầu tiên từ máy khách sẽ có số thứ tự 42, trong khi phân đoạn đầu tiên từ máy chủ sẽ có số thứ tự 79 Sau khi kết nối TCP được thiết lập, máy khách đang chờ byte 79, trong khi máy chủ đang chờ byte 42.
Trong Hình 1.5, ba phân đoạn được gửi từ máy khách đến máy chủ Phân đoạn đầu tiên chứa biểu diễn ASCII 1 byte của chữ 'C' trong trường dữ liệu, và có số thứ tự 42.
ĐIỀU KHIỂN TẮC NGHẼN CHO GIAO THỨC TCP
Kiểm soát tắc nghẽn TCP cổ điển
Phương pháp TCP yêu cầu người gửi giới hạn tốc độ gửi lưu lượng truy cập vào kết nối như một biện pháp chống tắc nghẽn mạng Khi người gửi nhận thấy ít tắc nghẽn, họ sẽ tăng tốc độ gửi, nhưng nếu phát hiện tắc nghẽn, họ sẽ giảm tốc độ Tuy nhiên, điều này đặt ra ba câu hỏi quan trọng: Thứ nhất, làm thế nào để người gửi giới hạn tốc độ gửi? Thứ hai, làm thế nào để nhận diện tắc nghẽn trên đường dẫn? Thứ ba, người gửi nên áp dụng thuật toán nào để điều chỉnh tốc độ gửi một cách hiệu quả?
Kết nối TCP bao gồm bộ đệm nhận, bộ đệm gửi và các biến như LastByteRead và rwnd Cơ chế kiểm soát tắc nghẽn TCP theo dõi một biến bổ sung tại người gửi, đó là cửa sổ tắc nghẽn (cwnd), nhằm hạn chế tốc độ gửi lưu lượng truy cập vào mạng.
Cụ thể, lượng dữ liệu chưa được xác nhận tại một người gửi không được vượt quá mức tối thiểu của cwnd và rwnd, đó là:
Để tập trung vào kiểm soát tắc nghẽn, ta giả định bộ đệm nhận TCP đủ lớn để không bị ràng buộc bởi cửa sổ nhận, do đó số lượng dữ liệu chưa được xác nhận ở người gửi chỉ phụ thuộc vào cwnd Giả định rằng người gửi luôn có dữ liệu để gửi, tức là tất cả các phân đoạn trong cửa sổ tắc nghẽn đều được gửi Trong một kết nối với tổn thất và độ trễ truyền gói không đáng kể, vào đầu mỗi RTT, ràng buộc cho phép người gửi gửi cwnd byte dữ liệu vào kết nối.
Trong giao thức TCP, vào cuối thời gian RTT, người gửi nhận được thông báo xác nhận cho dữ liệu đã gửi Tốc độ gửi dữ liệu của người gửi được tính bằng công thức cwnd / RTT (byte/giây) Bằng cách điều chỉnh giá trị của cwnd, người gửi có khả năng điều chỉnh tốc độ truyền tải dữ liệu trong kết nối của mình.
Trong quá trình truyền dữ liệu, người gửi
Câu hỏi quan trọng trong việc điều chỉnh giá trị cwnd để kiểm soát tốc độ gửi của người gửi TCP là làm thế nào để xác định tốc độ gửi hợp lý Nếu gửi quá nhanh, mạng có thể bị nghẽn, trong khi nếu quá thận trọng và gửi quá chậm, băng thông sẽ không được sử dụng hiệu quả Do đó, người gửi TCP cần tìm ra cách tối ưu để gửi dữ liệu với tốc độ cao mà không gây ra tình trạng nghẽn mạng.
NHÓM 13 21 tất cả băng thông có sẵn? Người gửi TCP có được phối hợp một cách rõ ràng không hay có một phương pháp phân tán nào, trong đó người gửi TCP có thể đặt tốc độ gửi của họ chỉ dựa trên thông tin cục bộ? TCP trả lời những câu hỏi này bằng cách sử dụng các nguyên tắc dưới đây:
Khi một phân đoạn bị mất, điều này dẫn đến tắc nghẽn và làm giảm tốc độ của người gửi TCP Một sự kiện hết thời gian chờ hoặc việc nhận được bốn xác nhận cho một phân đoạn cụ thể, bao gồm một ACK gốc và ba ACK trùng lặp, được coi là dấu hiệu cho thấy phân đoạn đã bị mất Khi sự kiện này xảy ra, người gửi TCP sẽ kích hoạt gửi lại phân đoạn bị mất và cần giảm kích thước cửa sổ tắc nghẽn.
Một phân đoạn được xác nhận cho thấy mạng đang phân phối các phân đoạn từ người gửi đến người nhận, dẫn đến việc tỷ lệ của người gửi có thể tăng khi nhận được ACK cho một phân đoạn chưa được xác nhận Sự xuất hiện của các xác nhận được xem là dấu hiệu cho thấy quá trình truyền tải diễn ra suôn sẻ và mạng không bị tắc nghẽn Do đó, kích thước cửa sổ tắc nghẽn có thể được điều chỉnh tăng lên.
TCP thăm dò băng thông bằng cách sử dụng các ACK để xác định đường dẫn không bị tắc nghẽn và các sự kiện mất mát để nhận biết tình trạng tắc nghẽn Chiến lược của TCP là tăng tốc độ truyền khi nhận được ACK và giảm tốc độ khi xảy ra mất mát Người gửi TCP sẽ tăng tốc độ truyền để thăm dò mức độ tắc nghẽn, sau đó lùi lại và tiếp tục thăm dò để đánh giá xem mức độ tắc nghẽn có thay đổi hay không Trong quá trình này, mạng không cung cấp tín hiệu rõ ràng về tình trạng tắc nghẽn; thay vào đó, ACK và sự kiện mất mát hoạt động như những tín hiệu ngầm định, và mỗi người gửi TCP chỉ dựa vào thông tin cục bộ không đồng bộ từ các người gửi khác.
Bài viết này cung cấp cái nhìn tổng quan về kiểm soát tắc nghẽn TCP, với trọng tâm là thuật toán kiểm soát tắc nghẽn TCP nổi tiếng được mô tả lần đầu tiên trong [Jacobson 1988] và tiêu chuẩn hóa trong [RFC 5681] Thuật toán này bao gồm ba thành phần chính: khởi động chậm, tránh tắc nghẽn và khôi phục nhanh Khởi động chậm và tránh tắc nghẽn là các thành phần bắt buộc của TCP, với cách thức tăng kích thước của cwnd khác nhau dựa trên các ACK đã nhận Khởi động chậm thực tế tăng kích thước cwnd nhanh hơn so với tránh tắc nghẽn, mặc dù tên gọi có thể gây hiểu lầm Khôi phục nhanh, mặc dù được khuyến nghị, nhưng không phải là yêu cầu bắt buộc đối với người gửi TCP.
Slow Start (Khởi động chậm)
Khi bắt đầu kết nối TCP, giá trị cwnd thường được khởi tạo với giá trị nhỏ là 1 MSS, từ đó tốc độ gửi ban đầu được tính bằng MSS/RTT Ví dụ, với MSS là 500 byte và RTT là 200 msec, tốc độ gửi ban đầu sẽ là 20 kbps Để nhanh chóng xác định băng thông khả dụng, cwnd sẽ tăng dần từ 1 MSS lên 1 MSS mỗi khi một phân đoạn truyền được xác nhận lần đầu tiên Quá trình này cho phép TCP tăng gấp đôi tốc độ gửi mỗi RTT, dẫn đến việc tốc độ gửi bắt đầu chậm nhưng tăng nhanh chóng trong giai đoạn khởi động chậm.
Hình 2.1: TCP khởi động chậm
Nhưng câu hỏi được đặt ra ở đây là sự tăng trưởng theo cấp số nhân này khi nào sẽ kết thúc?
- Đầu tiên, nếu xảy ra hiện tượng tắc nghẽn, người gửi TCP đặt giá trị cwnd thành
Khi MSS (Maximum Segment Size) được thiết lập, quá trình khởi động chậm sẽ được khởi động lại Giá trị của biến trạng thái thứ hai, ssthresh (ngưỡng khởi động chậm), sẽ được đặt thành cwnd/2, tức là một nửa giá trị của cửa sổ tắc nghẽn khi phát hiện tình trạng tắc nghẽn.
Quá trình khởi động chậm trong giao thức TCP có thể kết thúc khi giá trị cwnd đạt bằng ssthresh, với ssthresh được xác định là một nửa giá trị cwnd cuối cùng khi phát hiện tắc nghẽn Khi cwnd bằng ssthresh, quá trình khởi động chậm sẽ kết thúc.
TCP chuyển sang chế độ tránh tắc nghẽn Như chúng ta sẽ thấy, TCP tăng cwnd một cách cẩn thận hơn khi ở chế độ tránh tắc nghẽn
Quá trình khởi động chậm trong TCP sẽ kết thúc khi phát hiện ba gói ACK trùng lặp, dẫn đến việc TCP thực hiện truyền lại nhanh và chuyển sang trạng thái khôi phục nhanh.
Hoạt động của TCP khi khởi động chậm được tóm tắt trong mô tả FSM về kiểm soát tắc nghẽn TCP trong Hình 2.2
Congestion Avoidance (Tránh tắc nghẽn)
Thông báo tắc nghẽn rõ ràng do mạng hỗ trợ và Kiểm soát tắc nghẽn dựa trên độ trễ
Kể từ khi tiêu chuẩn hóa về khởi động chậm và kiểm soát tắc nghẽn vào cuối những năm 1980, TCP đã sử dụng phương pháp kiểm soát tắc nghẽn đầu cuối, trong đó người gửi không nhận được tín hiệu tắc nghẽn rõ ràng từ lớp mạng mà chỉ phát hiện qua mất gói Gần đây, các mở rộng cho IP và TCP đã được đề xuất và triển khai, cho phép mạng thông báo tắc nghẽn một cách rõ ràng đến người gửi và người nhận TCP Ngoài ra, một số biến thể của giao thức kiểm soát tắc nghẽn TCP cũng đã được phát triển để suy ra tình trạng tắc nghẽn thông qua việc đo độ trễ của gói tin.
Chúng ta sẽ xem xét cả kiểm soát tắc nghẽn do mạng hỗ trợ và dựa trên độ trễ trong phần này
Thông báo tắc nghẽn rõ ràng ECN
Thông báo tắc nghẽn là một phương pháp kiểm soát tắc nghẽn trên Internet, liên quan đến cả TCP và IP Trong lớp mạng, hai bit trong trường loại dịch vụ của tiêu đề IP được sử dụng cho ECN, với bốn giá trị khả dụng Bộ định tuyến sử dụng các bit ECN để báo hiệu rằng nó đang gặp phải tình trạng tắc nghẽn.
Hình 2.6: Thông báo tắc nghẽn rõ ràng: được hỗ trợ bởi mạng điều khiển tắc nghẽn
Dấu hiệu tắc nghẽn được chuyển đến máy chủ đích qua sơ đồ IP, như thể hiện trong Hình 2.6 [RFC 3168] Mặc dù tài liệu này không định nghĩa rõ thời điểm nào bộ định tuyến bị tắc nghẽn, nhưng quyết định này là tùy thuộc vào cấu hình của nhà cung cấp bộ định tuyến và sự lựa chọn của nhà khai thác mạng Bit chỉ báo tắc nghẽn có thể được thiết lập để thông báo về sự khởi đầu của tình trạng tắc nghẽn trong quá trình gửi dữ liệu trước khi xảy ra mất mát thực sự.
ECN là một thông báo từ máy chủ gửi đến các bộ định tuyến, cho biết rằng cả người gửi và người nhận đều hỗ trợ ECN Điều này cho phép họ thực hiện các biện pháp cần thiết để ứng phó với tình trạng tắc nghẽn mạng được chỉ định bởi ECN.
Khi TCP trong máy chủ nhận thông báo tắc nghẽn ECN qua sơ đồ dữ liệu, nó sẽ thông báo cho TCP trong máy chủ gửi bằng cách cài đặt bit ECE trong phân đoạn TCP ACK Khi nhận được ACK có tắc nghẽn, TCP người gửi sẽ giảm một nửa cửa sổ tắc nghẽn và sử dụng truyền lại nhanh cho phân đoạn bị mất, đồng thời đặt bit CWR trong tiêu đề của lần truyền tiếp theo gửi đến TCP nhận.
Ngoài TCP, các giao thức lớp truyền tải như DCCP, DCTCP và DCQCN cũng có thể sử dụng ECN được báo hiệu bởi lớp mạng DCCP cung cấp kiểm soát tắc nghẽn chi phí thấp và không đáng tin cậy, tương tự như UDP với ECN DCTCP và DCQCN được thiết kế cho mạng trung tâm dữ liệu và cũng áp dụng ECN Gần đây, các phép đo Internet cho thấy sự gia tăng triển khai khả năng ECN trong các máy chủ và bộ định tuyến dọc theo đường dẫn đến các máy chủ này.
Kiểm soát tắc nghẽn dựa trên độ trễ
Bộ định tuyến bị tắc nghẽn có thể gửi tín hiệu thông báo tắc nghẽn để cảnh báo người gửi về tình trạng tắc nghẽn trước khi xảy ra mất gói tin Điều này giúp người gửi điều chỉnh tốc độ gửi dữ liệu, giảm thiểu nguy cơ mất gói tin có giá trị Một phương pháp khác để tránh tắc nghẽn là sử dụng cách tiếp cận dựa trên độ trễ, cho phép phát hiện sớm tình trạng tắc nghẽn trước khi xảy ra mất gói tin.
Trong TCP Vegas, người gửi ước lượng thời gian RTT (Round Trip Time) cho tất cả các gói đã được thừa nhận RTTmin được xác định là giá trị tối thiểu của các phép đo RTT tại người gửi, xảy ra trong điều kiện đường dẫn không bị tắc nghẽn và các gói gặp phải độ trễ xếp hàng.
NHÓM 13 35 hàng tối thiểu Nếu kích thước cửa sổ tắc nghẽn của TCP Vegas là cwnd, thì tốc độ thông lượng chưa được kiểm tra sẽ là cwnd /RTTmin Trực giác đằng sau TCP Vegas là nếu thông lượng thực tế do người gửi đo gần với giá trị này, tốc độ gửi TCP có thể được tăng lên vì (theo định nghĩa và theo phép đo) đường dẫn chưa bị tắc nghẽn Tuy nhiên, nếu thông lượng thực tế do người gửi đo nhỏ hơn đáng kể so với tốc độ thông lượng không bị tắc nghẽn, đường dẫn sẽ bị tắc nghẽn và người gửi Vegas TCP sẽ giảm tốc độ gửi
TCP Vegas hoạt động theo nguyên tắc giữ cho đường ống truyền tải luôn đầy, nhưng không quá tải, nhằm tối ưu hóa hiệu suất mạng Điều này đặc biệt quan trọng khi các liên kết, đặc biệt là những nút cổ chai, có thể hạn chế băng thông của kết nối Bằng cách duy trì trạng thái bận rộn cho các liên kết, TCP Vegas đảm bảo rằng công việc truyền tải dữ liệu diễn ra hiệu quả và hữu ích.
"Cụm từ 'nhưng không đầy hơn' ám chỉ việc không có gì để đạt được, ngoại trừ việc làm tăng độ trễ Điều này xảy ra khi các hàng đợi lớn tích tụ trong khi đường ống vẫn được giữ ở mức đầy."
Giao thức kiểm soát tắc nghẽn BBR, được phát triển dựa trên ý tưởng của TCP Vegas, cho phép cạnh tranh hiệu quả với các người gửi TCP không phải BBR Kể từ năm 2016, Google đã triển khai BBR cho toàn bộ lưu lượng TCP trên mạng B4 của mình, thay thế giao thức CUBIC, và hiện đang áp dụng trên các máy chủ web của YouTube Ngoài BBR, còn có các giao thức kiểm soát tắc nghẽn TCP khác như TIMELY dành cho mạng trung tâm dữ liệu, Compound TCP (CTCP) và FAST cho các mạng đường dài và tốc độ cao.
Ngang hàng
Trong một kết nối TCP, mỗi kết nối có đường dẫn end-to-end riêng biệt, nhưng tất cả đều phải đi qua một nút cổ chai với tốc độ truyền R bps Qua nút cổ chai, mặc dù có sự tắc nghẽn, nhưng các liên kết khác trên đường dẫn đều không bị ảnh hưởng và có dung lượng truyền dồi dào Giả sử mỗi kết nối đang truyền một tệp lớn mà không có lưu lượng UDP nào đi qua nút cổ chai, thì một cơ chế kiểm soát tắc nghẽn được coi là hiệu quả nếu tốc độ truyền được duy trì ổn định.
NHÓM 13 36 truyền trung bình của mỗi kết nối là xấp xỉ R/K; nghĩa là mỗi kết nối nhận được một phần băng thông liên kết bằng nhau
Thuật toán AIMD (Additive Increase Multiplicative Decrease) của TCP mang lại nhiều lợi ích, đặc biệt trong các tình huống mà các kết nối TCP khác nhau khởi đầu vào những thời điểm khác nhau Điều này dẫn đến việc kích thước cửa sổ truyền tải có thể khác nhau tại cùng một thời điểm, giúp tối ưu hóa hiệu suất mạng và giảm thiểu tình trạng tắc nghẽn.
Trong trường hợp đơn giản của hai kết nối TCP chia sẻ một liên kết duy nhất với tốc độ truyền R, giả sử rằng cả hai kết nối có cùng kích thước MSS và RTT, điều này dẫn đến việc chúng có cùng thông lượng nếu kích thước cửa sổ tắc nghẽn tương đương Hơn nữa, giả định rằng có một lượng lớn dữ liệu cần gửi và không có kết nối TCP hoặc UDP datagram nào khác sử dụng liên kết này Cuối cùng, chúng ta sẽ bỏ qua giai đoạn slow-start của TCP và cho rằng các kết nối TCP luôn hoạt động ở chế độ CA (AIMD).
Biểu đồ thông lượng trong Hình 2.7 minh họa hai kết nối TCP chia sẻ băng thông liên kết Nếu băng thông được chia sẻ đều giữa hai kết nối, thông lượng sẽ nằm dọc theo mũi tên 45 độ xuất phát từ điểm gốc, với tổng thông lượng lý tưởng là R Mỗi kết nối sẽ nhận được một phần dung lượng liên kết bằng nhau, tuy nhiên, điều này không phải lúc nào cũng đạt được Do đó, mục tiêu là đạt được thông lượng gần giao điểm giữa đường chia sẻ băng thông bằng nhau và đường sử dụng băng thông đầy đủ trong biểu đồ.
Hình 2.7: Hai kết nối TCP chia sẻ một liên kết tắc nghẽn duy nhất
Trong một kịch bản lý tưởng, hai kết nối TCP 1 và 2 nhận được thông lượng từ điểm A, với băng thông chung nhỏ hơn R Khi không có mất mát gói, cả hai kết nối tăng cửa sổ của chúng lên 1 MSS mỗi RTT nhờ thuật toán tránh tắc nghẽn Thông lượng chung sẽ tăng dọc theo đường 45 độ cho đến khi băng thông vượt quá R, dẫn đến mất gói Khi mất gói xảy ra tại điểm B, cả hai kết nối giảm cửa sổ của chúng theo hệ số hai, dẫn đến thông lượng tại điểm C Tại đây, với băng thông nhỏ hơn R, hai kết nối tiếp tục tăng thông lượng dọc theo đường 45 độ từ C Khi mất gói xảy ra lần nữa tại điểm D, chúng lại giảm kích thước cửa sổ theo hệ số hai Quá trình này cho thấy rằng băng thông giữa hai kết nối cuối cùng sẽ dao động dọc theo đường chia sẻ băng thông bằng nhau, bất kể vị trí ban đầu của chúng trong không gian hai chiều, từ đó lý giải tại sao TCP dẫn đến chia sẻ băng thông công bằng giữa các kết nối.
Hình 2.8: Thông lượng được thực hiện bới các kết nối 1 và 2
Trong một tình huống lý tưởng, chỉ có các kết nối TCP đi qua liên kết nút cổ chai với cùng giá trị RTT và một kết nối TCP duy nhất cho mỗi cặp máy chủ-đích Tuy nhiên, trong thực tế, các điều kiện này thường không được đáp ứng, dẫn đến việc các ứng dụng máy khách-máy chủ nhận được băng thông không đồng đều Đặc biệt, khi nhiều kết nối chia sẻ một nút cổ chai, những phiên có RTT nhỏ hơn có khả năng tận dụng băng thông nhanh hơn khi nó trở nên miễn phí, từ đó đạt được thông lượng cao hơn so với các kết nối có RTT lớn hơn.
Chúng ta đã tìm hiểu về cách kiểm soát tắc nghẽn TCP điều chỉnh tốc độ truyền của ứng dụng thông qua cơ chế cửa sổ tắc nghẽn Nhiều ứng dụng đa phương tiện như điện thoại Internet và hội nghị truyền hình thường không sử dụng TCP vì họ không muốn tốc độ truyền bị hạn chế, ngay cả trong điều kiện mạng không ổn định.
NHÓM 13 39 rất tắc nghẽn Thay vào đó, các ứng dụng này thích chạy qua UDP, không có tính năng kiểm soát tắc nghẽn tích hợp Khi chạy qua UDP, các ứng dụng có thể bơm âm thanh và video của chúng vào mạng với tốc độ không đổi và đôi khi bị mất các gói, thay vì giảm tốc độ của chúng xuống mức "hợp lý" tại thời điểm tắc nghẽn và không mất bất kỳ gói nào Theo quan điểm của TCP, các ứng dụng đa phương tiện chạy trên UDP không công bằng - chúng không hợp tác với các kết nối khác cũng như điều chỉnh tốc độ truyền một cách thích hợp Bởi vì kiểm soát tắc nghẽn TCP sẽ làm giảm tốc độ truyền của nó khi đối mặt với tình trạng tắc nghẽn ngày càng tăng (mất mát), trong khi các nguồn UDP thì không cần, các nguồn UDP có thể lấn át lưu lượng TCP Một số cơ chế kiểm soát tắc nghẽn đã được đề xuất cho Internet để ngăn lưu lượng UDP đưa thông lượng của Internet bị đình trệ
Kết nối TCP Ngang bằng và Song song
Mặc dù có thể điều chỉnh lưu lượng truy cập UDP để hoạt động tương đương, vấn đề công bằng vẫn chưa được giải quyết hoàn toàn Điều này xảy ra do các ứng dụng dựa trên TCP có thể tận dụng nhiều kết nối song song Chẳng hạn, trình duyệt web thường sử dụng nhiều kết nối TCP song song để tải nhiều đối tượng trên một trang web, và số lượng kết nối này có thể được cấu hình Khi một ứng dụng sử dụng nhiều kết nối song song, nó sẽ chiếm dụng một phần lớn băng thông trong một liên kết bị tắc nghẽn Ví dụ, trong một liên kết có tốc độ R hỗ trợ chín ứng dụng máy khách-máy chủ, mỗi ứng dụng sẽ nhận được tốc độ truyền gần như R/10 Tuy nhiên, nếu một ứng dụng mới xuất hiện và cũng sử dụng một kết nối TCP, tình hình băng thông sẽ bị ảnh hưởng.
Khi có 11 kết nối TCP song song, ứng dụng mới sẽ nhận được phân bổ không công bằng, vượt quá R/2 Do lưu lượng truy cập Web rất phổ biến trên Internet, việc có nhiều kết nối song song không phải là điều hiếm gặp.
