CHƢƠNG 2 GIAO THỨC TRAO ĐỔI SỐ LIỆU
2.2 Giao thức TCP (Transmission Control Protocol)
2.2.1 Giới thiệu TCP
TCP là giao thức trao đổi số liệu có kết nối, đảm bảo tin cậy và chính xác giữu hai thực thể cuối trong mạng. TCP đảm bảo:
- Quản lý đúng số tuần tự tính theo byte của dòng dữ liệu.
- Tối ƣu hố khả năng sử dụng dải thơng của mạng bằng cách giám sát và điều khiển lƣu lƣợng số liệu từ thực thể gửi đến thực thể nhận.
TCP đảm bảo trao đổi số liệu tin cậy và chính xác giữa các thực thể đầu cuối trong mạng nhờ các yếu tố sau:
Đối thoại khi thu phát: Bên nhận phải thông báo cho bên gửi mỗi khi nhận đƣợc một gói số liệu sau một khoảng thời gian nhất định. Nếu khơng, gói số liệu đƣợc coi là nhận sai hoặc bị mất và đƣợc phát lại. Kiểm tra số liệu thu, phát: TCP đƣợc cài đặt các thuật toán kiểm tra số
liệu khi phát và khi thu (nhờ trƣờng checksum). Khi có sai sót trong trƣờng này, bên thu sẽ thông báo cho bên nhận để phát lại.
Kiểm tra số tuần tự: Gói tin TCP khi xuống tầng dƣới có thể sẽ bị chia cắt cho phù hợp, vì vậy bên nhận phải biết hợp các gói tin này theo đúng tuần tự phát.
Điều khiển lƣu lƣợng: TCP có các thuật tốn điều khiển phát căn cứ trên vùng đệm thu, phát cũng nhƣ tình trạng đƣờng truyền, nhờ vậy tránh đƣợc tắc nghẽn trên đƣờng truyền cũng nhƣ tối ƣu hoá băng thơng đƣờng truyền.
2.2.2 Cấu trúc gói số liệu TCP
Cấu trúc gói tin TCP gồm phần tiêu đề TCP “giả” (Pseudo header TCP) và gói số liệu TCP “thực”. Phần tiêu đề giả cần thiết cho việc xây dựng gói tin IP, bao gồm các thơng tin về địa chỉ IP nguồn, địa chỉ IP đích, số liệu thuộc giao thức TCP và độ dài của gói số liệu TCP thực.
Hình 2.1 Gói số liệu IP với phần tiêu đề giả Cấu trúc dữ liệu gói tin TCP phần “thực” nhƣ sau: Cấu trúc dữ liệu gói tin TCP phần “thực” nhƣ sau:
Ý nghĩa của các trƣờng trong gói tin TCP:
- Source/Destination port number: Số hiệu cổng TCP, cùng với địa chỉ IP nguồn và địa chỉ IP đích trong gói số liệu IP.
- Sequence number: số tuần tự phát, định danh byte đầu tiên của data so với byte đầu của dòng dữ liệu của thực thể gửi. Giá trị ban đầu là ISN+1 (Initial Sequence Number)
- Acknowledgement: Vị trí tƣơng đối của byte cuối cùng đã nhận đúng bởi thực thể gửi gói ACK cộng thêm 1. Giá trị của trƣờng này đúng khi bít cờ ACK=1
- Data Offset: Khoảng cách tƣơng đối của trƣờng dữ liệu với phần tiêu đề của TCP tính theo từ 32 bít.
- Resered = 0 : để dùng trong tƣơng lai.
- Flags: có 6 bít cờ trong phần tiêu đề của TCP. Giá trị cụ thể nhƣ sau: a. URG =1: có sử dụng trƣờng Urgent pointer.
b. ACK =1: trƣờng Ack đúng.
c. PSH =1: thực thể nhận đƣợc yêu cầu chuyển ngay segment này d. RST =1: Tái tạo kết nối; từ chối kết nối v.v.
e. SYN =1: đồng bộ trƣờng số thứ tự, dùng để thiết lập kết nối TCP f. FIN =1: thông báo thực thể gửi đã kết thúc việc gửi số liệu
- Window size: Độ lớn cửa sổ nhận, quy định tổng số byte dữ liệu mà thực thể thu có thể nhận đƣợc, tính từ byte đƣợc biên nhận (ack).
- Checksum: checksum của cả TCP segment + Pseudo header. Trƣớc khi tính, trƣờng này = 0. (Tổng các word 16 bit kiểu bù 1, kết quả thu đƣợc lại tính bù 1 - XOR).
- Urgent pointer: Vị trí tƣơng đối của byte trong trƣờng dữ liệu TCP cần đƣợc xử lý đầu tiên.
- Options: Các tuỳ chọn. Hiện nay tuỳ chọn duy nhất đƣợc dùng là MSS (Maximum Segment Size). Giá trị default = 536 byte payload + 20 byte header = 556 byte.
- 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 2.2.3.1 Thiết lập kết nối
Thiết lập kết nối TCP đƣợc thực hiện trên cơ sở bắt tay 3 bƣớc (Three- way Handshacke) nhƣ sau:
TCP_A TCP_B Syn. Seq=x Syn. Seq=y Ack(x+1) Ack(y+1) Hình 2.3 Thiết lập kết nối
Bƣớc 1: Bên A yêu cầu kết nối, gửi CONNECTION REQUEST với cờ SYN=1, giá trị khởi tạo số tuần tự Seq = x (ISN), số hiệu cổng TCP của phần mềm dịch vụ mà tiến trình làm việc muốn kết nối.
Bƣớc 2: Bên B nhận đƣợc, gửi lại ACK với các giá trị ACK (x+1), SYN=1, Seq = y (ISN).
Bƣớc 3: A biên nhận ACK của B, khẳng định đã nhận đƣợc giá trị ISN của B với ACK (y+1), Seq = x và sẵn sàng cho kết nối.
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ể 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, 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. Thực thể TCP nhận đƣợc thơng điệp FIN sau khi gửi FIN của mình thì kết nối TCP thực sự đƣợc kết thúc.
TCP_A TCP_B Fin Seq=x Ack(x+1) Fin Seq=y) Ack(x+1) Ack(y+1) Hình 2.4 Kết thúc kết nối 2.3 Giao thức UDP (User Datagram Protocol)
Giao thức UDP (User Datagram Protocol) là giao thức ở mức vận chuyển, không hƣớng kết nối. Vì vậy, UDP là giao thức vận chuyển khơng tin cậy: UDP khơng có cơ chế kiểm tra số tuần tự phát, số tuần tự thu và kiểm tra lỗi. Ƣu điểm của UDP là thực hiện đơn giản.
UDP đƣợc sử dụng cho các ứng dụng mà trong đó:
- Việc phân phát tin nhanh chóng là quan trọng hơn việc phân phối tin chính xác: Email, dịch vụ tên miền DNS…
- Muốn tự cung cấp các chức năng flow control và error control
Thống kê thực tế cho thấy: 99% các gói tin UDP đƣợc vận chuyển đến đích khơng bị lỗi.
Gói tin UDP có cấu trúc nhƣ sau:
Gói tin UDP có cấu trúc tƣơng tự cấu trúc gói tin TCP:
- Phần đầu “tiêu đề giả”(Pseudo header) giúp thƣc thể IP xây dựng IP packet. - Trƣờng Lenght trong “tiêu đề giả” là độ dài tồn bộ gói số liệu UDP, kể cả phần “tiêu đề giả”.
- Số hiệu cổng nguồn và số hiệu cổng đích (UDP Src /Dest port) cho biết địa chỉ nguồn và địa chỉ đích của các thực thể ứng dụng sử dụng giao thức UDP. - Trƣờng Length trong UDP segment: độ dài UDP segment, độ dài tối thiểu bằng 8.
- Trƣờng Checksum đƣợc tính cho tồn bộ gói số liệu UDP.
Gói số liệu UDP đƣợc tự động loại bỏ một khi bị lỗi; chỉ những gói số liệu UDP khơng bị lỗi mới đƣợc chuyển cho các thực thể ứng dụng.
2.4 Giao thức truyền tải thời gian thực RTP (Realtime Transfer Protocol) Để đáp ứng các ứng dụng cần truyền tải dữ liệu thời gian thực, RTP Để đáp ứng các ứng dụng cần truyền tải dữ liệu thời gian thực, RTP (Realtime Transfer Protocol) đã đƣợc xây dựng và chuẩn hoá bằng RFC 1889. Giao thức RTP chạy trên UDP đƣợc sử dụng để truyền dữ liệu đa phƣơng tiện. Dữ liệu đa phƣơng tiện đƣợc gắn kèm RTP header, đƣợc đóng gói vào gói tin RTP. Mỗi gói tin RTP lại đƣợc đóng gói vào trong gói UDP rồi đƣợc truyền đi. RTP cung cấp dịch vụ vận chuyển cho các ứng dụng đa phƣơng tiện (multimedia). Tuy nhiên, RTP khơng cung cấp sự đảm bảo gói tin đƣợc phân phối đúng thời gian cũng nhƣ đảm bảo chất lƣợng dịch vụ khác. Việc đóng gói gói tin RTP đƣợc thực hiện tại các hệ thống cuối (end-system). RTP có thể xem nhƣ là lớp con của tầng giao vận.
Các trƣờng trong RTP header nhƣ sau:
Hình 2.7 Các trƣờng trong gói tin RTP
Trƣờng PT (payload type): Dài 7 bit, xác định kiểu mã hoá và nén audio/video đƣợc dùng trong phiên RTP (RTPsession); do đó RTP hỗ trợ 128 kiểu dữ liệu. Với luồng audio, trƣờng payload type dùng để xác định kiểu mã hóa audio (PCM chẳng hạn) đƣợc sử dụng. Nếu phía gửi quyết định thay đổi kiểu mã hóa trong một session, phía gửi có thể thơng báo cho phía nhận sự thay đổi qua trƣờng này. Việc thay đổi kiểu mã hóa thƣờng nhằm để tăng chất lƣợng audio hoặc giảm tốc độ bit của RTP stream.
Trƣờng sequence number: Trƣờng này có độ dài 16 bít. Số tuần tự tăng lên 1 sau khi mỗi gói RTP đƣợc gửi đi, nó có thể đƣợc phía nhận dùng để phát hiện sự mất gói tin và khơi phục lại gói tin bị mất. Ví dụ: nếu phía nhận nhận đƣợc các gói RTP có khoảng trống giữa số 86 và 89 thì sẽ biết đƣợc rằng gói thứ 87, 88 bị mất và nó cố gắng khơi phục lại dữ liệu mất Trƣờng timestamp: Trƣờng này dài 32 bít. Nó xác định thời điểm lấy mẫu
của byte đầu tiên trong gói dữ liệu RTP. Phía nhận dùng timestamp để loại bỏ thăng giáng độ trễ. Timestamp đƣợc lấy từ đồng hồ lấy mẫu ở phía gửi. Ví dụ: timestamp tăng lên 1 sau mỗi chu kì lấy mẫu.
Trƣờng synchronization source identifier (SSRC): Trƣờng này dài 32 bit. Nó xác định số định danh của luồng RTP. Mỗi luồng trong một phiên RTP có một số SSRC phân biệt. SSRC khơng phải là địa chỉ IP của phía
gửi mà là một số mà phía nguồn gán ngẫu nhiên khi một luồng mới bắt đầu.
2.5 Hạn chế của TCP, UDP và RTP
Trong những năm gần đây, sự phát triển nhƣ vũ bão của các công nghệ mạng, các kỹ thuật nén, dụng lƣợng thiết bị lƣu trữ đã làm bùng nổ các ứng dụng mới trên Internet, nhƣ là truyền dòng số liệu video(streaming video), điện thoại trên mạng IP (IP telephony), hội thảo từ xa (teleconferencing), trò chơi tƣơng tác (interactive game), thế gới ảo (virtual world), học từ xa,… Những ứng dụng truyền thông đa phƣơng tiện là các ứng dụng trên môi trƣờng truyền thông liên tục, yêu cầu về băng thông, độ trễ, lỗi…khác với các ứng dụng truyền thống nhƣ e-mail, Web, telnet, … Các ứng dụng truyền thông đa phƣơng tiện chủ yếu chứa dữ liệu audio và video là động, yêu cầu về băng thông cao, vô cùng nhạy với độ trễ và phụ thuộc vào ứng dụng mạng đa phƣơng tiện cụ thể. Mặt khác, các ứng dụng này cho phép một mức độ mất mát gói tin nhất định. Sự mất mát này chỉ gây ra sự thực thi không đều trong audio hoặc video mà ngƣời dùng khơng nhận ra đƣợc và thƣờng có thể đƣợc che dấu một phần hoặc hoàn toàn tuỳ theo từng chuẩn mã hoá khác nhau. Điều này hoàn toàn ngƣợc lại với các ứng dụng truyền thống, dữ liệu là tĩnh (text, image, v.v.) có thể bỏ qua độ trễ nhƣng không chấp nhận sự mất mát.
Để thấy đƣợc hạn chế của các giao thức trên trong các ứng dụng mới, chúng ta sẽ xét qua một ứng dụng cụ thể là hệ thống điện thoại hữu tuyến và khả năng sử dụng các giao thức trên trong truyền tải tín hiệu điện thoại của hệ thống điện thoại trên mạng IP.
Hệ thống điện thoại hữu tuyến đƣợc sử dụng từ hàng thế kỷ nay. Đặc điểm của hệ thống này là sự chiếm dụng đƣờng truyền khi hai đầu cuối sử dụng để đàm thoại, yêu cầu chặt chẽ về độ trễ và độ tin cậy. Khi hệ thống mạng dựa trên nền IP phát triển rộng khắp (Internet), nẩy sinh nhu cầu truyền tải các tín hiệu điện thoại dựa trên mạng IP. Nhu cầu này xuất phát từ một thực tế là khi thực hiện những cuộc gọi điện thoại đƣờng dài, phải thiết lập một kênh truyền giữa hai đầu cuối sử dụng để đàm thoại. Việc thiết lập
đƣờng truyền nhƣ vậy là rất tốn kém và lãng phí. Lãng phí ở điểm trong khi đàm thoại, không phải lúc nào hai đầu cuối liên tục sử dụng để thoại mà có những khoảng lặng, khi đó đƣờng truyền khơng đƣợc sử dụng gì mà ngƣời dùng vẫn phải trả tiền. Với việc dùng mạng Internet để truyền tải tín hiệu điện thoại, giá thành cuộc gọi sẽ rất rẻ, cuộc gọi đƣờng dài trở thành cuộc gọi nội hạt do không phải thiết lập kênh truyền riêng giữa hai đầu cuối. Tuy nhiên, các giao thức đã đƣợc phát triển và sử dụng là TCP và UDP có q nhiều hạn chế, khơng thể khắc phục đƣợc, làm chất lƣợng cuộc gọi không tốt, dẫn tới nhu cầu phát triển giao thức mới.
2.5.1 Hạn chế của TCP
TCP (Chuẩn hoá bởi IETF RFC 793) đã đƣợc phát triển trên 20 năm cho các ứng dụng đòi hỏi độ tin cậy trong truyền tải dữ liệu, độ trễ của dữ liệu vừa phải với thứ tự đƣợc đảm bảo chặt chẽ. Ứng dụng truyền tín hiệu điện thoại cũng đòi hỏi độ tin cậy nhƣng khơng nhất thiết phải đảm bảo tính tuần tự của toàn bộ khối lƣợng dữ liệu truyền tải mà thƣờng chỉ yêu cầu đảm bảo tính tuần tự trong từng phần của dữ liệu. Sự đảm bảo tuần tự dữ liệu tồn bộ của TCP có thể làm tăng độ trễ của dữ liệu khi truyền tải.
Trong cơ chế truyền tải dữ liệu của TCP, độ trễ lớn có thể xảy ra khi có lỗi thuộc loại HOLB (Head Of Line Blocking), đó là khi truyển tải một dịng các gói dữ liệu từ điểm tới điểm, vì một lý do nào đó, nếu gói tin đầu hay một gói tin nào đó bị hỏng hay mất, thì sẽ phải truyền lại tồn bộ các gói tin kế sau nó, dù các gói tin này có thể vẫn nguyên vẹn, dẫn đến độ trễ lớn của dữ liệu. Có thể thấy điều đó trong hình sau:
Lỗi HOLB làm tăng đáng kể độ trễ của gói tin. Với một tổng đài điện thoại có thể thực hiện đồng thời hàng nghìn cuộc gọi thì độ trễ đó có thể là rất lớn do hiệu ứng “domino” và dẫn tới làm tê liệt hệ thống.
TCP là giao thức hƣớng byte, khơng bảo tồn ranh giới thơng điệp do vậy không phù hợp với việc truyền tải tín hiệu điện thoại dựa trên các thơng điệp. Ứng dụng do vậy phải có ghi nhớ ranh giới và cần các phƣơng tiện để đảm bảo thông điệp đƣợc truyền tải trong thời gian chấp nhận đƣợc.
TCP khơng hỗ trợ đa địa chỉ (multihome), do vậy khó đảm bảo tính sẵn sàng là một yêu cầu bắt buộc của hệ thống điện thoại. Khơng có các kết nối dự phòng, tổng đài điện thoại có thể bị tê liệt khi đƣờng kết nối bị hỏng. Ngồi ra, giới hạn của cơ chế truyền thơng TCP (TCP socket) không đáp ứng đƣợc các yêu cầu truyền dữ liệu với độ sẵn sàng cao
Đối với các ứng dụng điện thoại, nhất là các dịch vụ điện thoại thƣơng mại, yêu cầu về an ninh và phịng chống các tấn cơng có chủ ý làm tê liệt hệ thông là ƣu tiên hàng đầu. Nhƣng TCP rất dễ bị tấn công dạng từ chối dịch vụ - DoS nhƣ “SYN flooding”…
2.5.2 Hạn chế của UDP
UDP cũng có nhiều hạn chế khi xem xét sử dụng truyền tải tín hiệu điện thoại. UDP là giao thức truyền tải dữ liệu không tin cậy, cũng nhƣ không tuần tự. Bên gửi dữ liệu không thể biết dữ liệu đƣợc truyền có đến đích hay khơng, cũng nhƣ bên nhận có thể nhận lặp lại dữ liệu.
Thứ hai, UDP khơng có cơ chế kiểm sốt, phát hiện và tránh tắc nghẽn. Do vậy, UDP vẫn phát dữ liệu ngay cả khi mạng đã bị nghẽn, làm trầm trọng mức độ nghẽn và ảnh hƣởng đến các ứng dụng khác sử dụng chung đƣờng truyền. Khi mạng bị tắc nghẽn, các gói tin sẽ tự động bị vứt bỏ, vì vậy, tính tin cậy của UDP càng khơng đảm bảo.
Vì các lý do trên, UDP khơng thể đáp ứng đƣợc các yêu cầu và không phù hợp cho các ứng dụng tín hiệu điện thoại. Tuy nhiên, UDP có ƣu điểm là gọn nhẹ, đơn giản, hƣớng thơng điệp nên để có thể đáp ứng nhu cầu tối ƣu hoá độ trễ và truyền tin cậy dữ liệu, UDP sẽ phải xây dựng thêm cơ chế:
- Phát hiện và phát lại gói tin bị mất.
- Loại bỏ các thông điệp trùng lặp hay bị hỏng. - Phát hiện và có cơ chế chống tắc nghẽn.