Como fazer cache de vídeos do youtube no Squid
Do ano passado pra cá, o crescimento de vídeos explodiu no mundo. Um problema notado, porém, foi que os vídeos não eram cacheados no squid.
Foram criadas várias ferramentas para de redirecionamento, com menor ou maior grau de sucesso.
Aqui no trabalho, testamos uma alternativa, adicionando as linhas
acl googlevideo dstdomain .googlevideo.com
cache allow googlevideo
acl youtube dstdomain .youtube.com
cache allow youtube
no arquivo /etc/squid/squid.conf e o problema foi resolvido.
Importante. Essas linhas devem estar acima dessas duas:
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
A explicação é simples.
A RFC 2616, que define o HTTP 1.1, diz que não deve entrar no cache todo recurso que tiver na resposta os cabeçalhos:
Conforme testes, verificamos que os vídeos continham um cabeçalho de expiração de algumas horas, além de não conter instruções nos cabeçalhos para não guardá-los. O que fizemos foi inserir uma regra dizendo que não é pra descartar de cara o conteúdo de googlevideo.com e youtube.com. A regra foi colocada antes por questão de prioridade.
Pudemos, assim, cachear tranquilamente os vídeos, atentos a um pequeno detalhe. O recurso é definido pela URL de requisição, o cabeçalho Vary da resposta (quando existir) e a ETag. Assim, essas duas URL abaixo são entidades diferentes, pois não atendem ao primeiro quesito:
Como última dica, deixo a de aumentar o parâmetro maximum_object_size, pois o padrão é de apenas 4 MB.
O resultado no log do squid foi o seguinte (substituí os IPs por falsos):
Fonte: http://lucianopinheiro.net/
Foram criadas várias ferramentas para de redirecionamento, com menor ou maior grau de sucesso.
Aqui no trabalho, testamos uma alternativa, adicionando as linhas
acl googlevideo dstdomain .googlevideo.com
cache allow googlevideo
acl youtube dstdomain .youtube.com
cache allow youtube
no arquivo /etc/squid/squid.conf e o problema foi resolvido.
Importante. Essas linhas devem estar acima dessas duas:
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY
A explicação é simples.
A RFC 2616, que define o HTTP 1.1, diz que não deve entrar no cache todo recurso que tiver na resposta os cabeçalhos:
- Cache-Control: no-cache;
- Pragma: no-cache;
- Cache-Control: no-store;
Conforme testes, verificamos que os vídeos continham um cabeçalho de expiração de algumas horas, além de não conter instruções nos cabeçalhos para não guardá-los. O que fizemos foi inserir uma regra dizendo que não é pra descartar de cara o conteúdo de googlevideo.com e youtube.com. A regra foi colocada antes por questão de prioridade.
Pudemos, assim, cachear tranquilamente os vídeos, atentos a um pequeno detalhe. O recurso é definido pela URL de requisição, o cabeçalho Vary da resposta (quando existir) e a ETag. Assim, essas duas URL abaixo são entidades diferentes, pois não atendem ao primeiro quesito:
- http://dominio.com.br/?a=1&b=2
- http://dominio.com.br/?b=2&a=1
Como última dica, deixo a de aumentar o parâmetro maximum_object_size, pois o padrão é de apenas 4 MB.
O resultado no log do squid foi o seguinte (substituí os IPs por falsos):
# tail -n 5000 /var/log/squid/access.log|grep googlevideo 1244065234.402 1478259 10.10.5.7 TCP_MISS/200 9944050 GET http://v2.lscache6.googlevideo.com/videoplayback? - ROUNDROBIN_PARENT/200.200.200.29 video/x-flv 1244065379.699 129413 10.10.5.8 TCP_MISS/200 1042113 GET http://v22.lscache1.googlevideo.com/videoplayback? - ROUNDROBIN_PARENT/200.200.200.28 video/x-flv 1244065640.822 167 10.10.5.7 TCP_HIT/200 1042121 GET http://v22.lscache1.googlevideo.com/videoplayback? - NONE/- video/x-flv 1244065709.024 1590 10.10.5.8 TCP_HIT/200 9944059 GET http://v2.lscache6.googlevideo.com/videoplayback? - NONE/- video/x-flvUPDATE: Veja meu outro post sobre como resolver o problema da efetividade e fazer 100% de acerto nas requisições: Cache efetivo de vídeos do Youtube com Squid
Fonte: http://lucianopinheiro.net/
Nenhum comentário:
Postar um comentário