Hi all,
I'm experiencing some anomalies while streaming videos off YouTube on Unifi. For certain 'political' videos -- I've observed that the HTTP connection for the videoplayback stream to YT's local CDNs are being disrupted as follows :
1. Client video player makes a connection to the YT CDN
2. HTTP GET request is sent
There's a few different behaviors after this .. :
3a. HTTP 200 OK is received however it arrives 90 seconds later (should be instant) :
![user posted image]()
3b. HTTP 200 OK is received instantly, first 1-4KB of video stream traffic is sent (allowing the YT player to show the first frame of the video with a timestamp of 0:00).. then no traffic is received for 90 seconds once again :
![user posted image]()
There's a duplicate TCP ACK when the stream returns, did my ACK at packet #271 ever reach the CDN in the first place??
Further testing :
1. Using an unencrypted SOCKS proxy on a remote server + non standard TCP port results in the same behavior with packet loss between the client and SOCKS proxy server
2. Using an encrypted SSH tunnel to the same remote server results in absolutely no issues with viewing the videos
Sample videos :
http://www.youtube.com/watch?v=hHTz22bTBRw
http://www.youtube.com/watch?v=uVWxB4AWOxc
UPDATE :
I performed a simultaneous packet capture on both my client + remote server while encapsulating the HTTP connection via plaintext SOCKS. All the video payload packets were dropped en route back to my SOCKS client :
![user posted image]()
Dafuq?
I'm experiencing some anomalies while streaming videos off YouTube on Unifi. For certain 'political' videos -- I've observed that the HTTP connection for the videoplayback stream to YT's local CDNs are being disrupted as follows :
1. Client video player makes a connection to the YT CDN
2. HTTP GET request is sent
There's a few different behaviors after this .. :
3a. HTTP 200 OK is received however it arrives 90 seconds later (should be instant) :

3b. HTTP 200 OK is received instantly, first 1-4KB of video stream traffic is sent (allowing the YT player to show the first frame of the video with a timestamp of 0:00).. then no traffic is received for 90 seconds once again :

There's a duplicate TCP ACK when the stream returns, did my ACK at packet #271 ever reach the CDN in the first place??
Further testing :
1. Using an unencrypted SOCKS proxy on a remote server + non standard TCP port results in the same behavior with packet loss between the client and SOCKS proxy server
2. Using an encrypted SSH tunnel to the same remote server results in absolutely no issues with viewing the videos
Sample videos :
http://www.youtube.com/watch?v=hHTz22bTBRw
http://www.youtube.com/watch?v=uVWxB4AWOxc
UPDATE :
I performed a simultaneous packet capture on both my client + remote server while encapsulating the HTTP connection via plaintext SOCKS. All the video payload packets were dropped en route back to my SOCKS client :

Dafuq?