✔ Wireshark: Protokolle bei Facebooknutzung untersuchen
- Themenstarter bb-champ
- Beginndatum
sheel
I love Asm
HTTP. Sowohl für Seitengerüst (klar) als auch Video.
Die Gründe für diese Entscheidung bei der Entwicklung sind mir unbekannt, aber man kann es leicht prüfen.
Beim Aufruf eines YT-Videos wird neben HTML, CSS etc. ein "videoplayback" mit einigen Parametern
irgendwo aus einem CDN geladen. Nutzdaten dabei sind die reinen Videodaten.
Wenn man sich das direkt aufruft bzw. in eine Datei herunterladet und es an VLC füttert...
[
Ganz so einfach ist es nicht. Zu bechten, falls man es probiert will.
a) Der Link hat ein "Ablaufdatum" in den Parametern, zB. 5 Minuten haltbar
b) Außerdem ist üblicherweise ein Videobereich angegeben. Man bekommt mit einem Aufruf nicht die ganze Datei
c) Dabei ist ein krypt. Urlhash, um die beliebige manuelle Parameteränderung zu verhindern.
Der Flashplayer etc. kann sich das ausrechnen, manuell ists etwas schwer
(vor allem auch abhängig von anderen geladenen Sachen außer dieser textuellen Adresse beim Seitenöffnen)
d) Und zuletzt hat YT auch noch eigene Datenformate.
Eventuell bekommt man eine Standarddatei, eventuell leicht andere Header,
und eventuell etwas seltsames, mit dem auch VLC nicht mehr klarkommt. Zusätzlich kann der Ton getrennt sein usw.
e) Verschiedene Qualitäten, Sprachen, Untertitel etc.etc. machen das Chaos perfekt)
]
Die Gründe für diese Entscheidung bei der Entwicklung sind mir unbekannt, aber man kann es leicht prüfen.
Beim Aufruf eines YT-Videos wird neben HTML, CSS etc. ein "videoplayback" mit einigen Parametern
irgendwo aus einem CDN geladen. Nutzdaten dabei sind die reinen Videodaten.
Wenn man sich das direkt aufruft bzw. in eine Datei herunterladet und es an VLC füttert...
[
Ganz so einfach ist es nicht. Zu bechten, falls man es probiert will.
a) Der Link hat ein "Ablaufdatum" in den Parametern, zB. 5 Minuten haltbar
b) Außerdem ist üblicherweise ein Videobereich angegeben. Man bekommt mit einem Aufruf nicht die ganze Datei
c) Dabei ist ein krypt. Urlhash, um die beliebige manuelle Parameteränderung zu verhindern.
Der Flashplayer etc. kann sich das ausrechnen, manuell ists etwas schwer
(vor allem auch abhängig von anderen geladenen Sachen außer dieser textuellen Adresse beim Seitenöffnen)
d) Und zuletzt hat YT auch noch eigene Datenformate.
Eventuell bekommt man eine Standarddatei, eventuell leicht andere Header,
und eventuell etwas seltsames, mit dem auch VLC nicht mehr klarkommt. Zusätzlich kann der Ton getrennt sein usw.
e) Verschiedene Qualitäten, Sprachen, Untertitel etc.etc. machen das Chaos perfekt)
]
Hallo,
Youtube verwendet RTMP welches HTTP(s)/TCP auf Port 1935 läuft.
RTMP ist ein Netzwerkprotokol welches von Adobe für das Videostreaming von Flash entwickelt wurde.
Für die mobile Version von Youtube m.youtube.de wird auch RTSP verwendet soviel ich weiß.
Einige der Informationen zu Youtube findet man auch direkt bei Google: https://support.google.com/youtube/answer/2853702?hl=en&topic=2853713&ctx=topic
Grüße
Youtube verwendet RTMP welches HTTP(s)/TCP auf Port 1935 läuft.
RTMP ist ein Netzwerkprotokol welches von Adobe für das Videostreaming von Flash entwickelt wurde.
Für die mobile Version von Youtube m.youtube.de wird auch RTSP verwendet soviel ich weiß.
Einige der Informationen zu Youtube findet man auch direkt bei Google: https://support.google.com/youtube/answer/2853702?hl=en&topic=2853713&ctx=topic
Grüße
sheel
I love Asm
@JFS: Dein Link behandelt Livestreams (davon das Encoding), keine abgepeicherten Videos.
Man kann es wirklich nachmachen. Sowohl den Download (der RTMP-losen Datei aus HTTP raus)
als auch die WS-Kontrolle, das da kein RTMP etc. dabei ist.
edit: Der gleiche Inhalt im Kontext (mit Navi etc.): https://support.google.com/youtube/answer/2853702?hl=en&ref_topic=2853713
Man kann es wirklich nachmachen. Sowohl den Download (der RTMP-losen Datei aus HTTP raus)
als auch die WS-Kontrolle, das da kein RTMP etc. dabei ist.
edit: Der gleiche Inhalt im Kontext (mit Navi etc.): https://support.google.com/youtube/answer/2853702?hl=en&ref_topic=2853713
Zuletzt bearbeitet:
Hallo bb-champ
Ich glaub hier liegt eine Konfusion vor. TCP ist nicht in der gleichen Schicht wie HTTP und RMPT. TCP ist transport layer, HTTP/RMTP sind application layer. HTTP und RMTP sind in TCP enthalten. Bis und mit Transport Layer kann dir Wireshark alle Details anzeigen, da dies standardisiert ist, auf Applikationsstufe gibt es zu viele Protokolle, nicht alle davon sind in Wireshark komplett implementiert und du musst die Daten der Applikationsschicht da selber interpretieren.
Wenn ich es richtig verstanden habe geht es hier um eine Seminararbeit? Ich denke in diesem Kontext sind die Worte 'wahrscheinlich' und 'vermutlich' nicht brauchbar.
Viele Grüsse
Cromon
Ich glaub hier liegt eine Konfusion vor. TCP ist nicht in der gleichen Schicht wie HTTP und RMPT. TCP ist transport layer, HTTP/RMTP sind application layer. HTTP und RMTP sind in TCP enthalten. Bis und mit Transport Layer kann dir Wireshark alle Details anzeigen, da dies standardisiert ist, auf Applikationsstufe gibt es zu viele Protokolle, nicht alle davon sind in Wireshark komplett implementiert und du musst die Daten der Applikationsschicht da selber interpretieren.
Wenn ich es richtig verstanden habe geht es hier um eine Seminararbeit? Ich denke in diesem Kontext sind die Worte 'wahrscheinlich' und 'vermutlich' nicht brauchbar.
Viele Grüsse
Cromon
