TCP so với UDP trên luồng video

Tôi vừa trở về nhà sau kỳ thi lập trình mạng và một trong những câu hỏi họ hỏi chúng tôi là "Nếu bạn định phát video, bạn sẽ sử dụng TCP hay UDP? Hãy giải thích cho cả video được lưu trữ và video trực tiếp" . Đối với câu hỏi này, họ chỉ mong đợi một câu trả lời ngắn gọn của TCP cho video được lưu trữ và UDP cho video trực tiếp, nhưng tôi đã nghĩ về điều này trên đường về nhà và có nhất thiết phải sử dụng UDP để phát video trực tiếp không? Ý tôi là, nếu bạn có băng thông cho nó và nói rằng bạn đang phát trực tuyến một trận bóng đá hoặc buổi hòa nhạc cho vấn đề đó, bạn có thực sự cần sử dụng UDP không?

Giả sử rằng trong khi bạn đang phát trực tuyến buổi hòa nhạc này hoặc bất cứ điều gì bằng TCP, bạn bắt đầu mất các gói (điều gì đó tồi tệ đã xảy ra trong một số mạng giữa bạn và người gửi) và trong cả phút bạn không nhận được bất kỳ gói nào. Luồng video sẽ tạm dừng và sau khi hết một phút, các gói bắt đầu hoạt động trở lại (IP đã tìm thấy một tuyến đường mới cho bạn). Điều gì sẽ xảy ra sau đó là TCP sẽ truyền lại số phút bạn bị mất và tiếp tục gửi cho bạn luồng trực tiếp. Theo giả định, băng thông cao hơn tốc độ bit trên luồng và ping không quá cao, vì vậy trong một khoảng thời gian ngắn, một phút bạn bị mất sẽ hoạt động như một bộ đệm cho luồng cho bạn, theo cách đó , nếu mất gói tin lại xảy ra, bạn sẽ không nhận thấy.

Bây giờ, tôi có thể nghĩ đến một số thiết bị mà đây không phải là một ý tưởng hay, chẳng hạn như hội nghị truyền hình, nơi bạn cần phải luôn ở cuối luồng, vì sự chậm trễ trong cuộc trò chuyện video thật kinh khủng, nhưng trong một trận đấu bóng đá hoặc một buổi hòa nhạc, điều gì quan trọng nếu bạn chậm một phút so với luồng? Ngoài ra, bạn được đảm bảo rằng bạn nhận được tất cả dữ liệu và tốt hơn là bạn nên lưu để xem sau khi dữ liệu đến mà không có bất kỳ lỗi nào.

Vì vậy, điều này đưa tôi đến câu hỏi của tôi. Có bất kỳ hạn chế nào mà tôi không biết khi sử dụng TCP để phát trực tiếp không? Hay nó thực sự nên là, nếu bạn có băng thông cho nó, bạn nên sử dụng TCP vì nó "đẹp" hơn đối với mạng (điều khiển luồng)?

Hạn chế của việc sử dụng TCP cho video trực tiếp:

1. Thông thường, các thiết bị phát video trực tiếp không được thiết kế với tính năng phát trực tuyến TCP. Nếu bạn sử dụng TCP, HĐH phải đệm các phân đoạn chưa được xác nhận cho mọi máy khách. Điều này là không mong muốn, đặc biệt trong trường hợp các sự kiện trực tiếp; có lẽ danh sách khách hàng đồng thời của bạn dài do tính chất kỳ dị của sự kiện. Diễn viên video được ghi trước thường không gặp nhiều vấn đề với điều này vì người xem làm trì trệ hoạt động phát lại của họ; do đó TCP thích hợp hơn để phát lại video theo yêu cầu.
2. IP multicast làm giảm đáng kể yêu cầu về băng thông video đối với lượng lớn khán giả; TCP ngăn cản việc sử dụng IP multicast, nhưng UDP rất phù hợp với IP multicast.
3. Video trực tiếp thường là một luồng băng thông không đổi được ghi lại từ máy ảnh; các luồng video được ghi trước đi ra khỏi đĩa. Động lực dự phòng mất mát của TCP khiến việc phân phát video trực tiếp khó khăn hơn khi các luồng nguồn có băng thông không đổi (như sẽ xảy ra đối với sự kiện trực tiếp). Nếu bạn đệm vào đĩa từ máy ảnh, hãy đảm bảo bạn có đủ bộ đệm cho các sự kiện mạng không thể đoán trước và tốc độ gửi / gửi ngược TCP thay đổi. UDP cung cấp cho bạn nhiều quyền kiểm soát hơn đối với ứng dụng này vì UDP không quan tâm đến việc giảm lớp truyền tải mạng.

FYI, vui lòng không sử dụng từ "gói" khi mô tả mạng. Các mạng gửi "gói tin".

nhưng trong một trận đấu bóng đá, hoặc một buổi hòa nhạc, điều gì quan trọng nếu bạn chậm một phút trong luồng?

Đối với một số người hâm mộ bóng đá, khá một chút. Người ta nhận xét rằng sự chậm trễ thậm chí vài giây trong các luồng video kỹ thuật số do mã hóa (hoặc bất cứ điều gì) có thể rất khó chịu khi, trong các sự kiện nổi bật như các trận đấu cúp thế giới, bạn có thể nghe thấy tiếng reo hò và rên rỉ từ các chàng trai. bên cạnh (những người đang xem một chương trình tương tự không xác thực) trước khi bạn có thể xem các động thái trò chơi đã gây ra họ.

Tôi nghĩ rằng đối với một người quan tâm nhiều đến thể thao (và đó là nhóm khách hàng trả tiền lớn nhất cho truyền hình kỹ thuật số, ít nhất là ở Đức), chậm một phút trong một luồng video trực tiếp sẽ là hoàn toàn không thể chấp nhận được (Như trong, họ ' d chuyển sang đối thủ cạnh tranh của bạn nếu điều này không xảy ra).

Thông thường, một luồng video có khả năng chịu lỗi. Vì vậy, nếu một số gói bị mất (do một số bộ định tuyến trên đường đi bị quá tải), thì nó vẫn có thể hiển thị nội dung nhưng với chất lượng giảm.

Nếu luồng trực tiếp của bạn đang sử dụng TCP / IP, thì luồng sẽ buộc phải đợi các gói bị loại bỏ đó trước khi có thể tiếp tục xử lý dữ liệu mới hơn.

Điều đó thật tồi tệ:

• dữ liệu cũ được truyền lại (đó có thể là đối với khung đã được hiển thị và do đó vô giá trị) và
• dữ liệu mới không thể đến sau khi dữ liệu cũ được truyền lại

Nếu mục tiêu của bạn là hiển thị thông tin cập nhật nhất có thể (và đối với luồng trực tiếp, bạn thường muốn cập nhật, ngay cả khi khung hình của bạn trông tệ hơn một chút), thì TCP sẽ chống lại bạn.

Đối với một luồng đã ghi, tình hình hơi khác một chút: bạn có thể sẽ lưu vào bộ đệm nhiều hơn (có thể là vài phút!) Và muốn dữ liệu được truyền lại hơn là có một số hiện vật do các gói bị mất. Trong trường hợp này TCP là một kết hợp tốt (tất nhiên, điều này vẫn có thể được triển khai trong UDP, nhưng TCP không có nhiều nhược điểm như đối với trường hợp phát trực tiếp).

Có một số trường hợp sử dụng phù hợp với vận chuyển UDP và những trường hợp khác phù hợp với vận chuyển TCP.

Trường hợp sử dụng cũng quy định cài đặt mã hóa cho video. Khi phát sóng trận đấu bóng đá, trọng tâm là chất lượng và đối với hội nghị truyền hình, trọng tâm là độ trễ.

Khi sử dụng multicast để cung cấp video cho khách hàng của bạn thì UDP sẽ được sử dụng.

Yêu cầu cho phát đa hướng là phần cứng mạng đắt tiền giữa máy chủ phát sóng và khách hàng. Trên thực tế, điều này có nghĩa là nếu công ty của bạn sở hữu cơ sở hạ tầng mạng, bạn có thể sử dụng UDP và multicast để phát video trực tiếp. Ngay cả khi đó chất lượng dịch vụ cũng được thực hiện để đánh dấu các gói video và ưu tiên chúng để không xảy ra mất gói.

Multicast sẽ đơn giản hóa phần mềm phát sóng vì phần cứng mạng sẽ xử lý việc phân phối các gói cho khách hàng. Khách hàng đăng ký kênh đa hướng và mạng sẽ cấu hình lại để định tuyến gói đến thuê bao mới. Theo mặc định, tất cả các kênh đều có sẵn cho tất cả khách hàng và có thể được định tuyến tối ưu.

Quy trình làm việc này gây khó khăn cho quy trình ủy quyền. Phần cứng mạng không phân biệt người dùng đã đăng ký với người dùng khác. Giải pháp để ủy quyền là mã hóa nội dung video và cho phép giải mã trong phần mềm trình phát khi đăng ký hợp lệ.

Luồng công việc Unicast (TCP) cho phép máy chủ kiểm tra thông tin đăng nhập của khách hàng và chỉ cho phép các đăng ký hợp lệ. Thậm chí chỉ cho phép một số kết nối đồng thời nhất định.

Multicast không được kích hoạt qua internet.

Để phân phối video qua internet, TCP phải được sử dụng. Khi UDP được sử dụng, các nhà phát triển kết thúc việc thực hiện lại việc truyền lại gói, chẳng hạn. Bittorrent p2p giao thức trực tiếp.

"Nếu bạn sử dụng TCP, HĐH phải đệm các phân đoạn chưa được xác nhận cho mọi máy khách. Điều này là không mong muốn, đặc biệt là trong trường hợp các sự kiện trực tiếp".

Bộ đệm này phải tồn tại ở một số dạng. Điều tương tự cũng đúng với bộ đệm jitter ở phía người chơi. Nó được gọi là "bộ đệm ổ cắm" và phần mềm máy chủ có thể biết khi nào bộ đệm này đầy và loại bỏ các khung video thích hợp cho các luồng trực tiếp. Tốt hơn là sử dụng phương pháp unicast / TCP vì phần mềm máy chủ có thể thực hiện logic giảm khung thích hợp. Các gói bị thiếu ngẫu nhiên trong trường hợp UDP sẽ chỉ tạo ra trải nghiệm người dùng không tốt. như trong video này: http://tinypic.com/r/2qn89xz/9

"IP multicast làm giảm đáng kể yêu cầu băng thông video cho nhiều khán giả"

Điều này đúng với các mạng riêng, Multicast không được kích hoạt qua internet.

"Lưu ý rằng nếu TCP mất quá nhiều gói, kết nối sẽ chết; do đó, UDP cung cấp cho bạn nhiều quyền kiểm soát hơn đối với ứng dụng này vì UDP không quan tâm đến việc giảm lớp truyền tải mạng."

UDP cũng không quan tâm đến việc giảm toàn bộ khung hình hoặc nhóm khung hình, vì vậy nó không cung cấp thêm bất kỳ quyền kiểm soát nào đối với trải nghiệm người dùng.

"Thông thường một luồng video có khả năng chịu lỗi một chút"

Video được mã hóa không có khả năng chịu lỗi. Khi được truyền qua quá trình truyền tải không đáng tin cậy thì sửa lỗi chuyển tiếp được thêm vào vùng chứa video. Ví dụ điển hình là bộ chứa MPEG-TS được sử dụng trong phát sóng video vệ tinh mang một số luồng âm thanh, video, EPG, v.v. Điều này là cần thiết vì liên kết vệ tinh không phải là giao tiếp song công, có nghĩa là người nhận không thể yêu cầu truyền lại các gói bị mất.

Khi bạn có sẵn giao tiếp song công, tốt hơn hết là bạn chỉ nên truyền lại dữ liệu cho các máy khách bị mất gói sau đó bao gồm chi phí sửa lỗi chuyển tiếp trong luồng gửi đến tất cả các máy khách.

Trong mọi trường hợp, các gói bị mất là không thể chấp nhận được. Khung hình bị giảm vẫn được chấp nhận trong những trường hợp ngoại lệ khi băng thông bị cản trở.

Kết quả của các gói bị thiếu là các hiện vật như sau:

Một số bộ giải mã có thể ngắt các luồng bị thiếu gói ở những nơi quan trọng.

Tôi khuyên bạn nên xem giao thức p2p trực tiếp mới Bittorent Live .

Đối với việc phát trực tuyến, tốt hơn nên sử dụng UDP, trước tiên vì nó giảm tải trên các máy chủ, nhưng chủ yếu là vì bạn có thể gửi các gói bằng multicast, đơn giản hơn là gửi nó đến từng máy khách được kết nối.

Nó phụ thuộc. Nội dung bạn đang phát trực tuyến quan trọng như thế nào? Nếu quan trọng, hãy sử dụng TCP. Điều này có thể gây ra các vấn đề về băng thông, chất lượng video (bạn có thể phải sử dụng chất lượng thấp hơn để giải quyết độ trễ) và độ trễ. Nhưng nếu bạn cần nội dung được đảm bảo đến đó, hãy sử dụng nó.

Nếu không thì UDP sẽ ổn nếu luồng không quan trọng và sẽ được ưu tiên hơn vì UDP có xu hướng ít chi phí hơn.

Một trong những vấn đề lớn nhất khi cung cấp các sự kiện trực tiếp trên Internet là 'quy mô' và TCP không mở rộng quy mô tốt. Ví dụ: khi bạn đang chiếu một trận bóng đá trực tiếp - trái ngược với phát lại phim theo yêu cầu - số lượng người xem có thể dễ dàng gấp 1000 lần. Trong một tình huống như vậy, sử dụng TCP là một bản án tử hình đối với các CDN (mạng phân phối nội dung).

Có một số lý do chính khiến TCP không mở rộng quy mô tốt:

1. Một trong những đánh đổi lớn nhất của TCP là sự thay đổi của thông lượng có thể đạt được giữa người gửi và người nhận. Khi truyền video qua Internet, các gói video phải truyền qua nhiều bộ định tuyến trên Internet, mỗi bộ định tuyến này được kết nối với các kết nối tốc độ khác nhau. Thuật toán TCP bắt đầu với cửa sổ TCP nhỏ, sau đó phát triển cho đến khi phát hiện mất gói, việc mất gói được coi là dấu hiệu của tắc nghẽn và TCP phản ứng lại bằng cách giảm mạnh kích thước cửa sổ để tránh tắc nghẽn. Do đó làm giảm thông lượng hiệu quả ngay lập tức. Bây giờ, hãy tưởng tượng một mạng có đường truyền TCP sử dụng 6-7 bước nhảy của bộ định tuyến tới máy khách (một kịch bản rất bình thường), nếu bộ định tuyến trung gian nào bị mất gói tin nào thì TCP cho liên kết đó sẽ giảm tốc độ truyền. Trên thực tế Dòng lưu lượng giữa các bộ định tuyến tuân theo một loại hình đồng hồ cát; luôn tăng và giảm ở giữa một trong các bộ định tuyến trung gian. Hiển thị thông qua hiệu quả thấp hơn nhiều so với UDP nỗ lực tối đa.

2. Như bạn có thể đã biết TCP là một giao thức dựa trên xác nhận. Ví dụ, giả sử một người gửi cách đó 50ms (tức là độ trễ btw hai điểm). Điều này có nghĩa là thời gian để một gói được gửi đến người nhận và người nhận để gửi một xác nhận sẽ là 100ms; do đó thông lượng tối đa có thể so với truyền dựa trên UDP đã giảm một nửa.

3. TCP không hỗ trợ đa hướng hoặc tiêu chuẩn mới nổi của AMT đa hướng. Điều đó có nghĩa là các CDN không có cơ hội để giảm lưu lượng mạng bằng cách sao chép các gói - khi nhiều máy khách đang xem cùng một nội dung. Chính điều đó đã là một lý do đủ lớn để các CDN (như Akamai hoặc Level3) không sử dụng TCP cho các luồng trực tiếp.

Trong khi đọc cuộc tranh luận TCP UDP, tôi nhận thấy một lỗ hổng hợp lý. Việc mất gói TCP gây ra độ trễ một phút được chuyển đổi thành bộ đệm một phút không thể tương quan với việc UDP giảm trọn một phút trong khi gặp cùng một mất mát. Một so sánh công bằng hơn như sau.

TCP bị mất gói. Video bị dừng trong khi TCP gửi lại các gói trong một nỗ lực truyền các gói hoàn hảo về mặt toán học. Video bị trì hoãn trong một phút và bắt đầu từ nơi nó dừng lại sau khi gói bị thiếu đến đích. Tất cả chúng ta đều chờ đợi nhưng chúng ta biết rằng chúng ta sẽ không bỏ lỡ một pixel nào.

UDP bị mất gói. Trong một giây trong khi phát video, một góc của màn hình bị mờ một chút. Không ai để ý và chương trình tiếp tục mà không cần tìm các gói tin bị mất.

Bất kỳ thứ gì phát trực tiếp đều thu được nhiều lợi ích nhất từ ​​UDP. Việc mất gói gây ra độ trễ một phút đối với TCP sẽ không gây ra độ trễ một phút đối với UDP. Xem xét rằng hầu hết các hệ thống sử dụng nhiều luồng độ phân giải làm cho mọi thứ trở nên tắc nghẽn khi đói các gói, càng có ý nghĩa hơn khi sử dụng UDP.

UDP FTW khi phát trực tuyến.

Nếu băng thông cao hơn nhiều so với tốc độ bit, tôi khuyên bạn nên sử dụng TCP để phát video trực tiếp unicast.

Trường hợp 1: Các gói tin liên tiếp bị mất trong khoảng thời gian vài giây. => video trực tiếp sẽ dừng ở phía máy khách bất kể lớp truyền tải là gì (TCP hay UDP). Khi mạng phục hồi: - nếu TCP được sử dụng, trình phát video của ứng dụng khách có thể chọn khởi động lại luồng khi gói đầu tiên bị mất (dịch chuyển thời gian) HOẶC bỏ tất cả các gói trễ và khởi động lại luồng video mà không có dịch chuyển thời gian. - nếu UDP được sử dụng, không có lựa chọn nào ở phía máy khách, video khởi động lại trực tiếp mà không có bất kỳ sự thay đổi thời gian nào. => TCP bằng hoặc tốt hơn.

Trường hợp 2: một số gói bị mất ngẫu nhiên và thường xuyên trên mạng. - Nếu TCP được sử dụng, các gói này sẽ được truyền lại ngay lập tức và với một bộ đệm jitter chính xác, sẽ không ảnh hưởng đến chất lượng / độ trễ của luồng video. - Nếu sử dụng UDP, chất lượng video sẽ kém. => TCP tốt hơn nhiều

Đối với băng thông phát trực tuyến video có thể là hạn chế đối với hệ thống. Sử dụng multicast bạn có thể giảm đáng kể lượng băng thông ngược dòng được sử dụng. Với UDP, bạn có thể dễ dàng phát các gói của mình tới tất cả các thiết bị đầu cuối được kết nối. Bạn cũng có thể sử dụng một giao thức multicast đáng tin cậy, một giao thức được gọi là Pragmatic General Multicast (PGM), tôi không biết gì về nó và tôi đoán nó không được sử dụng rộng rãi.

Bên cạnh tất cả các lý do khác, UDP có thể sử dụng multicast. Hỗ trợ 1000 người dùng TCP truyền cùng một dữ liệu sẽ gây lãng phí băng thông. Tuy nhiên, có một lý do quan trọng khác cho việc sử dụng TCP.

TCP có thể dễ dàng vượt qua tường lửa và NAT hơn nhiều. Tùy thuộc vào NAT và nhà điều hành của bạn, bạn thậm chí có thể không nhận được luồng UDP do các vấn đề với việc đục lỗ UDP.

Tất cả các câu trả lời 'sử dụng UDP' đều giả định một mạng mở và cách tiếp cận 'nhồi nhét nó nhiều nhất có thể'. Phù hợp với các mạng âm thanh / video chuyên dụng trong vườn kín kiểu cũ, đây là một loại không gian.

Trong thế giới thực, đường truyền của bạn sẽ đi qua tường lửa (sẽ làm rớt mạng đa hướng và đôi khi là udp), mạng được chia sẻ với những ứng dụng quan trọng hơn ($$$) khác, vì vậy bạn muốn trừng phạt những kẻ lạm dụng bằng cách mở rộng cửa sổ.

Đây là vấn đề, nó là một vấn đề nội dung hơn là một vấn đề thời gian. Giao thức TCP yêu cầu rằng một gói tin không được phân phối phải được kiểm tra, xác minh và gửi lại. UDP không sử dụng yêu cầu này. Vì vậy, nếu bạn đã gửi một tệp chứa hàng triệu gói bằng UDP, chẳng hạn như một video, nếu một số gói bị thiếu khi gửi, chúng rất có thể sẽ bị bỏ qua.