Catch-All ist nun auch nicht die Welt. Ich kaufe es nicht ab, dass wirklich von ALLEN TV-Sendern jemand Sendungen interessieren. Ich weiß, bei Catch-All geht es darum 'Es könnte mich später interessiert haben', allerdings mit 200 Channeln können 50 TV-Sender programmiert werden, ich denke mehr TV-Sender kann man gar nicht überblicken - entsprechend, selbst wenn es weitere TV-Sender geben sollte ist noch Luft vorhanden.
Es ist, wie mit einer 10 Gbit/s Internetleitung auskommen zu müssen, aber ein 100 TB Traffic Limit als Privatkunde zu haben. Manche Klauseln sollen tatsächlich nur missbrauch vorbeugen. Zwar könnte durch eine 10 Gbit/s Internetleitung das Datenvolumen binnen eines Tages aufbrauchen, aber im Gegensatz zu den Drosselkom-Klauseln wird dieses Limit selbst einen heutigen Vielnutzer im Monat nicht überschreiten.
Warum ich von 10 Gbit/s rede? Weil in der Schweitz inzwischen 10 Gbit/s Anschlüsse Privatkunden angeboten werden - und das zu äußerst günstigen Preisen.
Zurück zum Thema: Bei SaveTV scheint sich ganz offensichtlich einiges zu tun, in der Entwicklung NEUER Anwendungen und NEUER Features. Allerdings kümmert sich SaveTV kaum um die Wartung bestehender Funktionalitäten.
Ich hatte sogar Kontakt mit dem Support bezüglich des Problems, doch es hat sich entgegen der Versprechungen offenbar nichts getan: Und zwar wird in 2 Tagen, am 27. April (
https://www.chromestatus.com/features/schedule) Chrome 66 veröffentlicht, womit Symantec TLS-Zertifikaten aufgrund von Missbrauch/Mängel in der Zertifikatinfrastruktur das vertrauen entzogen wird. Das bedeutet
ab Dienstag sieht die SaveTV Startseite nur noch so aus:
- 2018-04-15_14h05_34.png (269.96 KiB) 7004 mal betrachtet
Um noch weiter vorweg zu greifen.
Ende des Jahres, mit der Veröffentlichung der jetzigen Chrome Developer Version, wird SaveTV nur noch so aussehen:
- 2018-04-15_14h10_58.png (23.17 KiB) 7004 mal betrachtet
Um noch weiter zu gehen, so gibt es auch noch weitere Technische Nachsichtigkeiten. So erhalten Kabel-Kunden zum Beispiel keine IPv4 Adressen (DNS A-Record), sondern in erster Linie nur eine IPv6-Adresse. Aufgrund von Adressmangel werden bereits jetzt Kompatibilitätslayer für IPv4 eingesetzt wie NAT444 und DNS64/NAT64, was dazu führt, das die erreichbare Geschwindigkeit von IPv4 hinter IPv6 zurückbleibt. So habe ich zum Beispiel nun nur noch Zugang über ein NAT444 auf die IPv4-Welt. Dies führt zu Diskrepanzen und lustigen Fehlermeldungen, wie zum Beispiel das Amazon Video langsamer als Netflix sei. (logisch: Amazon Video wird auf modernen Internetanschlüssen ohne DSLite über einen IPv4-Kompatibilitätlayer angesprochen; Netflix unterstützt IPv6 - und IPv6 arbeitet nativ, was immer am schnellsten geht).
--------------------------------
Es gibt aber auch weitere Nachlässigkeiten an der Serverinfrastruktur:
YouTube wickelt seinen Traffic zu einem größeren Teil über
QUIC/UDP statt
HTTP/TLS/TCP ab - insbesondere jetzt wo TLS 1.3 so gut wie fertig ist, ist das auch zunehmend für alle die mit Video und Musikstreaming zu tun haben, zu empfehlen. QUIC ist seit 2013 im Einsatz und verspricht unterbrechungsfreie und stabile Streams und einen sehr schnellen Verbindungsaufbau, da es bei Änderung am Netzwerk oder Änderungen der IP-Adresse davon unbeirrt weiterarbeiten kann. Beim HTTP/TLS/TCP-Stack gibt es (alleine die Auflistung der Protokolle ist länger) einen größeren Overhead, es ist langsamer, veraltet und es kommt zum Verbindungsverlust, sollten sich etwas am Netzwerk ändern.
Hintergrund:
Der Stack HTTP/TLS/TCP öffnet für jede Verbindung einen Socket, welcher einzigartig sein muss, bestehend aus IP-Adresse (Hausnummer) des Clients und Servers, sowie der Port-Nummer (Tür/Wohnungsnr-Nummer) des Client und Servers. Das bedeutet, bei mehreren Verbindungen zu einem Server, öffnet der Client bei sich verschiedene Ports, damit sich einer der Zahlen ändert, wodurch ein einzigartiger Sockets entsteht. Ports stehen allerdings lediglich 65.536 zur Verfügung (da die Port-Nummer mit 16-Bit angegeben wird). Bei gegenwärtigen Kompatibilitätslösungen zur Hinauszögerungen des IPv4-Adressmangels "NAT Network Address Translation", teilen sich mehrere Computer eine öffentliche IP-Adresse, durch Übersetzung der Adressen durch das NAT auf freie Port-Nummern - die das NAT in seiner NATT (Network Adresse Translation Table) einträgt. Doch eine IP-Adresse kann maximal 65.536 Sockets öffnen. DIe NAT-Hauspost kann andersherum gesagt maximal 65.536 Türen intern anschreiben.
Bei der heutigen Größe einiger internationaler Konzerne dürfte bereits diese Zahl zur Adressierung jedes Mitarbeiters zu klein sein - es skaliert einfach nicht mehr.
QUIC verabschiedet sich von diesem Socket-Modell in der Hinsicht, als das eine 64-Bit Lange Connection-ID genutzt wird, um eine Verbindung zu identifizieren - unabhängig von Abhängigkeiten zur IP-Adresse. Damit können 18.446 Billiarden Verbindungen pro Gerät verwaltet werden, wodurch die inzwischen (mehr als offensichtlich) zu geringen Kapazitätsbedingten weiter nach oben skalieren.
Bereits jetzt wird QUIC durch Google und einige Content Delivery Networks (CDNs) unterstützt und wickelt einen messbaren Anteil des Internet-Traffics ab, erfährt aber noch keinen wirklichen Durchbruch, da die 0-8-15 Server Apache und NGINX das Protokoll nicht von Haus aus unterstützen. Momentan ist QUIC-Support in NGINX
https://trac.nginx.org/nginx/ticket/1057 wohl ein ähnliches Sorgenkind, wie lange Zeit eine Passwort-Verschlüsselung in FileZilla (
https://trac.filezilla-project.org/ticket/2277) welche immerhin 1 Dutzend Jahre benötigt hat, um vom Support-Ticket zum implementierten Feature heranzureifen. QUIC wird bislang auch erst seit 5 Jahren eingesetzt. (Der Webserver Apache hat noch ganz andere Probleme), weswegen unter anderem neue Projekte wie CaddyServer das Feld übernehmen und insbesondere antworten auf die gegenwärtigen Anforderung (wie bspw. sämtlichen Internet-Traffic mit TLS zu verschlüsseln) finden.
Während zumindest HTTP/2.0 inzwischen so gut wie Flächendeckend eingesetzt wird, bleibt allerdings die Technik der SaveTV Stream und Downloadserver, ebenso wie des CDNs zur Auslieferung der Bilder & Thumbnails selbst noch mit HTTP/1.1 auf der Strecke liegen. Die Streamserver unterstützen auch keine TLS Verschlüsselung, was zu Problemen führt, wenn in Webbrowsern die "Upgrade-Insecure-Requests"-Flag gesetzt wird, welche erzwingt, das HTTPS Webseiten auch nur HTTPS-Assets laden, womit die Streaming-Server nicht mehr abgerufen werden. Dabei ist es gemäß Googles jahrelang verfolgter Ziele nicht unrealistisch zu behaupten, das dieses Flag über kurz oder lang im Google Chrome Webbrowser Standardmäß aktiviert werden wird. Auch von adaptiven Videostreams mit Techniken wie HLS oder DASH ist SaveTV gegenwärtig entfernt und bleibt somit auf dem Stand der Technik von vor Jahren hängen.
Einzig und allein, die Benutzer-Interfaces, angefangen von der Webseite bis zu den Apps, sind aufgrund von stetiger Weiter/Neuentwicklung - nicht zuletzt auch aufgrund der Umstellung von SOAP-APIs zu REST-API's die bereits vor Jahren durchgeführt wurde - auf der Welle der Zeit und Reiten sogar dem ein oder anderen Global Player voraus. Allerdings wenn es um Agilität ging, waren kleine Unternehmen häufig besser dran.
Entsprechend finde ich es schön und gut, die ganzen Apps weiterzuentwickeln. Es ist vermutlich genau die Schokoladenseite, die die meisten Nutzer wahrnehmen werden. Doch wie es sich nun mit den Zertifikat-Fehlern in Google Chrome Stable (in 2 Tagen) sowie bereits jetzt in Chrome Beta, Chrome Canary und Chrome Dev zeigen wird (von denen die Screenshots stammen), zeigt es sich über kurz oder lang gnadenlos, wenn man etwas im Hintergrund auf der Strecke liegen lässt. Entsprechend würde ich es begrüßen, wenn SaveTV sich demnächst auf den Netzwerk-Bereich konzentrieren würde.
In Mailinglisten wird diskutiert, das endgültig 2024 (also in 6 Jahren) IPv4 nicht mehr eingesetzt wird. Die DSGVO (Datenschutzgrundverordnung) der EU war auch bereits lange Zeit bekannt - und dennoch weiß ich selbst von einem großen deutschen Softwarehaus, dass diese hals über Kopf in den letzten Monaten völlig überrascht alles in Bewegung gesetzt haben.
PS: Mich würde zuletzt interessieren, wie SaveTV zum Video-Codec AV1 steht, welche vermutlich zum nächsten großen Video-Codec im Internet wird und ob man diesen ggf. für 2021/2022 plant einzuführen, wenn auch Hardware-Acceleration bereit steht. YouTube und Netflix werden vermutlich schon früher gemeinsam mit Chrome und FireFox vorpreschen, die Webbrowser unterstützen den Codec bereits jetzt in ihrer Developer-Version.