que serve mp3s para dispositivos móveis está inundando o nginx com solicitações parciais

Question

Estou servindo mp3s com um servidor nginx minimalista. O que eu vejo em meus arquivos de log é que há muitas solicitações, em especial da AppleCoreMedia e às vezes dos useragents do Android, que inundam o servidor com solicitações curtas. Às vezes, eles continuam solicitando o download do mesmo conteúdo parcial por um tempo muito longo; às vezes mais de uma hora. Por exemplo:

"GET /somefile.mp3 HTTP/1.1" 206 33041 "AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 like Mac OS X; en_us)"
"GET /somefile.mp3 HTTP/1.1" 206 33041 "AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 like Mac OS X; en_us)"
"GET /somefile.mp3 HTTP/1.1" 206 33041 "AppleCoreMedia/1.0.0.9B206 (iPhone; U; CPU OS 5_1_1 like Mac OS X; en_us)"
[...]

Eu também recebo muito, mas não tanto assim:

"-" 400 0 "-" 
"-" 400 0 "-"

Os endereços IP são sempre de clientes que começam a baixar logo após a solicitação, geralmente eles têm aproximadamente o mesmo UserAgent do primeiro exemplo. texto enfatizado Eu habilitei os limites de limitação e conexão do servidor em nginx para limitar a quantidade enorme de entradas de log de IPs equivalentes pelo menos um pouco.

Houve um problema de desempenho quando vi o mesmo comportamento no servidor anterior que usava o Apache. Eu instalei o nginx em um servidor melhor e movi o site. Quando o Apache não conseguia lidar com mais conexões do número crescente de clientes de forma eficaz, esse servidor era digitado. Não houve problema de largura de banda com clientes já conectados e não sei se os clientes já conectados estavam usando mais de uma conexão por vez.

Por favor, me diga:

• Os clientes que parecem ficar presos em um download de um Bad Thing ™

Eu ouvi pessoas dizerem que seu uso de banda larga móvel foi muito maior do que eles poderiam explicar. Eu estou pensando que esse tipo de comportamento do cliente pode explicar isso. E nos custa mais largura de banda também.

• Quais alternativas atualizadas existem por aí que podem manipular a exibição desse tipo de dados melhor do que o HTTP simples?
• Insights gerais úteis para alguém que acabou de entrar nesse campo desde o final dos anos 90. : -)

Answer 1

Segunda questão primeiro:

"-" 400 0 "-"

Isso geralmente significa que o cliente abriu uma conexão Keep-Alive , mas depois desconectou depois de receber uma resposta à sua solicitação anterior. Como o servidor da Web esperava algo, ele registra uma solicitação incorreta (HTTP 400). Estes são principalmente inofensivos.

Agora, qual é o problema dos iPhones baixarem conteúdo parcial? São apenas os arquivos de log grandes ? Você pode desativar o registro para solicitações específicas usando diretivas nginx. Se estiver causando um problema de desempenho, ou se os clientes não puderem acessar os recursos, talvez você deva começar a se preocupar. Mas você não mencionou explicitamente nenhum destes.

(Tudo isso dito, isso é um comportamento estranho de um iPhone; ele desperdiça os recursos de rede e a vida útil da bateria, coisas que os dispositivos móveis têm em falta.)

    

Answer 2

O iOS fará solicitações de alcance para conteúdo de vídeo / áudio, incluindo se reproduzido por meio das tags <video> e <audio> HTML5, e elas serão canceladas quando tiverem o suficiente para o usuário ouvir por algum tempo. Isso é uma coisa boa - só vai buscá-los quando necessário, então se alguém não ouvir / assistir a coisa toda, você não desperdiça a largura de banda enviando o arquivo inteiro.