Streaming: why TCP not UDP

 If you are a skilled developer and have eaten a lot with development related to internet services you might be aware of the TCP vs UDP specifics and know more than very well that for such services like video streaming it's more natively to use UDP not TCP https://www.wowza.com/blog/udp-vs-tcp but why, say, YouTube and Netflix use TCP?

Because each problem should be started to be viewed from the business perspective and not technical. Let's review pros which UDP has against TCP for streaming:

1. Much higher speed
2. Will not be broken if something is lost in the middle
3. Can be broadcasted - e.g. 1 source can be received by many destinations

And cons:

1. Doesn't give guarantee that all packets will be received
2. The sequence of the packets can be disordered

TCP:

1. Is much slower but gives the 100% guarantee of the data integrity - the sequence of the packets will be correct and nothing will be lost.
2. Due to requirement for integrity the channel can be broken and require reestablishing. In the case of enough wide internet connection this can be easily compensated with caching.
2. Other benefits like ability to work via secure channels, etc...

Also we should take into respect the following factors:

1. Price delta for the internet connection with the increased speed is very low nowadays. e.g. Fizz asks $44 for 200 megabits and $45 for 400.
2. To receive quality video Full HD video we need around 10 megabits, for 4K - 40.
3. Most popular video services are "on demand" which means user picks e.g. a movie he want to see now, not a general TV channel with online translation which makes UDP broadcasting ability useless here.
4. To use UDP service providers must have their own software (like "Zoom" client) or aim hardware (e.g. TV set). HTTP2 standard ("just in Web Browser") covers TCP only.
5. From business perspective most services would like to cover as many clients as possible and most people prefer to have an ability to just open the web page to access its favorite video service instead of installing an additional software.
6. And of course all providers would like to save the money - once they have a solution via TCP to cover WEB approach, it's cheaper to re-use it e.g. in their software for TV. Development for UDP will be more expensive - you need to take a control of packets sequence by yourself and decide what to do with lost packets, how much to wait for them to decide that this part of the picture should be left broken, develop the workaround for the broken parts of the image (i.e. insert a "glitch"), etc. To maintain TCP you need only caching for probable slowdown in the channel or even break to just restore the channel.
7. Do people want to have even rarely broken picture while watching their lovely movie? If they can easily pay $1 extra for the double speed? Which can be used to transfer 8 4K simultaneous quality video via the TCP channel?
6+7. Even if providers decide to cover UDP as well they will need to increase their prices. So even if they have a brilliant solution not to affect the quality so much (I doubt) and propose to customers "we deliver you better picture within your 30 MBt channel so you can save not paying for 100 MBt channel"... Who would take this offer??

So dear DonQuixotes, with a big respect to your knowledge and technical background where you are definitely right :) TCP usually still wins there where you expect UDP should win. Just because of business :)