Tại sao RTP sử dụng UDP thay vì TCP?

Question

Tôi muốn biết tại sao UDP được sử dụng trong RTP thay vì TCP? Các công cụ VoIP chính chỉ sử dụng UDP khi tôi tấn công một số phần mềm VoIP.

Answer 1

Như DJ đã chỉ ra, TCP sắp nhận được luồng dữ liệu tin cậy và sẽ làm chậm quá trình truyền và truyền lại các gói bị hỏng, để đạt được điều đó.

UDP không quan tâm đến độ tin cậy của giao tiếp và sẽ không làm chậm hoặc truyền lại dữ liệu.

Nếu ứng dụng của bạn cần luồng dữ liệu đáng tin cậy, ví dụ: để truy xuất tệp từ máy chủ web, bạn chọn TCP.

Nếu ứng dụng của bạn không quan tâm đến các gói bị hỏng hoặc bị mất và bạn không cần phải chịu thêm phí để cung cấp độ tin cậy bổ sung, bạn có thể chọn UDP thay thế.

VOIP không được cải thiện đáng kể bằng truyền gói tin đáng tin cậy, và trong thực tế, trong một số trường hợp, mọi thứ trong TCP như truyền lại và trả về theo hàm mũ có thể làm tổn hại chất lượng VOIP. Do đó, UDP là một lựa chọn tốt hơn.

Answer 2

UDP thường được sử dụng cho các loại lưu lượng truy cập thời gian thực khác nhau mà không cần đặt hàng nghiêm ngặt để hữu ích. Điều này là do TCP thi hành một thứ tự trước khi truyền dữ liệu đến một ứng dụng (theo mặc định, bạn có thể giải quyết vấn đề này bằng cách đặt con trỏ URG, nhưng không ai có thể làm điều này) và điều đó có thể rất không mong muốn trong môi trường mà bạn muốn thay vì nhận dữ liệu thời gian thực hiện tại hơn là nhận dữ liệu cũ đáng tin cậy.

Answer 3

RTP là không nhạy cảm với mất gói, do đó, nó không đòi hỏi độ tin cậy của TCP.

UDP có ít chi phí hơn cho đầu trang để một gói có thể mang nhiều dữ liệu hơn, do đó băng thông mạng được sử dụng hiệu quả hơn.

UDP cũng cung cấp truyền dữ liệu nhanh.

Vì vậy, UDP là lựa chọn hiển nhiên trong các trường hợp như vậy.

Answer 4

UDP được sử dụng ở bất cứ nơi nào dữ liệu được gửi, mà không cần phải được chính xác nhận được trên mục tiêu, hoặc nơi không có kết nối ổn định là cần thiết.

TCP được sử dụng nếu dữ liệu cần được nhận chính xác, bit cho bit, không bị mất bit.

Để phát video và âm thanh, một số bit bị mất trên đường không ảnh hưởng đến kết quả theo cách đó, điều đó được đề cập, một số pixel không ảnh trong luồng, không ảnh hưởng đến người dùng, trên DVD tỷ lệ bit bị mất cao hơn.

Answer 5

Rất nhiều câu trả lời tốt đã được đưa ra, nhưng tôi muốn chỉ có một điều ra một cách rõ ràng:

Về cơ bản một dòng dữ liệu hoàn chỉnh là một điều tốt đẹp để có cho real-time audio/video, nhưng nó không thật sự cần thiết (như những người khác đã chỉ ra):

Thực tế quan trọng là một số dữ liệu đến quá muộn là vô giá trị. Dữ liệu bị thiếu cho khung hình nào đáng lẽ phải được hiển thị cách đây một giây?

Nếu bạn sử dụng TCP (cũng đảm bảo đúng thứ tự của tất cả dữ liệu), thì bạn sẽ không thể truy cập dữ liệu cập nhật hơn cho đến khi dữ liệu cũ được truyền chính xác.Điều này là gấp đôi xấu: bạn phải đợi cho việc truyền lại dữ liệu cũ và dữ liệu mới (hiện đang bị trì hoãn) có thể sẽ không đáng giá.

Vì vậy, RTP thực hiện một số loại truyền nỗ lực tốt nhất ở chỗ nó cố chuyển tất cả dữ liệu sẵn có kịp thời nhưng không cố gắng truyền lại dữ liệu bị mất/hỏng trong quá trình truyền (*). Nó chỉ tiếp tục với cuộc sống và hy vọng rằng dữ liệu hiện tại quan trọng hơn sẽ đạt được điều đó một cách chính xác.

(*) thực sự tôi không biết chi tiết về RTP. Có lẽ nó cố gắng truyền lại, nhưng nếu nó thực hiện thì nó sẽ không tích cực như TCP (mà sẽ không bao giờ chấp nhận bất kỳ dữ liệu bị mất nào).

Answer 6

Bên cạnh đó tất cả các câu trả lời tốt và chính xác khác this article cho hiểu rõ về sự khác biệt giữa TCP và UDP.

Answer 7

Những người khác là chính xác, tuy nhiên không thực sự cho bạn biết lý do REAL tại sao. Sau một loại gợi ý về nó, nhưng đây là một câu trả lời hoàn chỉnh hơn.

Âm thanh và video là thời gian thực. Nếu bạn đang nghe radio, hoặc xem TV, và tín hiệu bị gián đoạn, nó sẽ không dừng lại ở nơi bạn rời đi .. bạn chỉ đang "quan sát" tín hiệu khi nó phát ra, và nếu bạn không thể quan sát tại bất kỳ thời điểm nào, bạn sẽ mất nó.

Lý do rất đơn giản. Sự chậm trễ. VOIP cố gắng hết sức để giảm thiểu lượng thời gian trì hoãn từ khi ai đó nói vào một đầu và bạn kết thúc nó và phản hồi của bạn trở lại. Nếu không, khi xảy ra lỗi, lượng thời gian trễ giữa khi người đó nói và khi tín hiệu được nhận sẽ liên tục phát triển cho đến khi nó trở nên vô dụng.

Hãy nhớ rằng, mỗi độ trễ từ quá trình truyền lại phải được phát lại và làm cho dữ liệu bị trễ hơn, sau đó một lỗi khác gây ra sự chậm trễ lớn hơn nữa. Giải pháp khả thi duy nhất là chỉ cần thả bất kỳ dữ liệu nào không thể hiển thị trong thời gian thực.

Độ trễ 1 giây từ quá trình truyền lại có nghĩa là bây giờ sẽ là 1 giây kể từ khi tôi nói điều gì đó cho đến khi bạn nghe thấy. Một sự chậm trễ thứ hai thứ hai bây giờ có nghĩa là nó 2 giây từ thời gian tôi nói điều gì đó cho đến khi bạn nghe thấy nó. Số liệu này được tích lũy bởi vì dữ liệu được phát lại với cùng tốc độ mà tại đó nó được phát lại, và như vậy ...

RTP có thể được định hướng kết nối, nhưng sau đó nó sẽ phải thả (hoặc bỏ qua) dữ liệu để theo kịp lỗi truyền lại anyways, vậy tại sao bận tâm với các chi phí phụ?

Answer 8

chỉ là một chú thích: Mỗi gói được gửi trong luồng RTP được cấp cao hơn số một của gói tiền nhiệm.Điều này cho phép điểm đến thr xác định xem có gói nào bị thiếu hay không. Nếu một gói tin đang hoạt động, hành động tốt nhất cho đích cần thực hiện là ước lượng khoảng trống mất tích bằng phép nội suy. Retranmission không phải là một tùy chọn proctical vì gói truyền lại sẽ quá muộn để có ích.

Answer 9

Tôi muốn thêm một cách nhanh chóng vào những gì Matt H nói để trả lời câu trả lời của Stobor. Matt H đã đề cập rằng RTP trên các gói UDP có thể được kiểm tra để nếu chúng bị hỏng, chúng sẽ bị gửi lại. Đây thực sự là một tính năng tùy chọn trên hầu hết các tổng đài. Trong Asterisk, ví dụ, bạn có thể bật/tắt tổng kiểm tra trên RTP của bạn trên lưu lượng UDP trong tệp cấu hình rtp.conf với dòng sau:

rtpchecksums=yes ; or no if you prefer 

Chúc mừng!

Answer 10

Các gói RTP kỹ thuật có thể được xen kẽ qua kết nối TCP. Có rất nhiều câu trả lời tuyệt vời được đưa ra ở đây.Hai điểm phụ bổ sung:

RFC 4588 mô tả cách người dùng có thể sử dụng truyền lại với dữ liệu RTP. Hầu hết các máy khách nhận luồng RTP đều sử dụng bộ đệm để tính toán jitter trong mạng thường dài 1-5 giây và điều đó có nghĩa là có sẵn thời gian để truyền lại để nhận dữ liệu mong muốn.

Lưu lượng truy cập RTP có thể được xen kẽ qua kết nối TCP. Trong thực tế khi điều này được thực hiện, sự khác biệt giữa RTP xen kẽ (tức là trên TCP) và RTP được gửi qua UDP là cách hai hoạt động này thực hiện trên một mạng bị mất không đủ băng thông cho người dùng. Dòng TCP xen kẽ sẽ bị giật khi người chơi liên tục chờ trong trạng thái đệm cho các gói tin đến. Tùy thuộc vào người chơi nó có thể nhảy lên phía trước để bắt kịp. Với kết nối RTP, bạn sẽ nhận được hiện vật (bôi/rách) trong video.