Durante a execução do Fiddler, observei algo estranho em uma solicitação de um arquivo XML estático ~ 5MB no meu servidor: Apesar de enviar cabeçalhos idênticos byte-by-byte (Edit: Incluindo os cabeçalhos), as respostas eram diferentes:
Resposta A:
1. 700KB de conteúdo gzip
2. Incluído o cabeçalho Content-Length
3. Cabeçalho de codificação de transferência excluído
Resposta B:
1. 1000KB de conteúdo gzip
2. Excluído o cabeçalho Content-Length
3. Incluído cabeçalho de transferência-codificação: cabeçalho em pedaços
O que posso fazer para que eu receba consistentemente o comportamento mais eficiente em largura de banda mostrado na resposta A?
Pedido bruto:
GET http://[REDACTED]/[REDACTED]/[REDACTED]/[REDACTED].xml?dt=Test1 HTTP/1.1
Host: [REDACTED]
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Resposta bruta A:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Encoding: gzip
Last-Modified: Tue, 07 May 2013 04:04:01 GMT
Accept-Ranges: bytes
ETag: "80ceefe7d74ace1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 07 May 2013 21:07:21 GMT
Content-Length: 728105
[700KB GZipped Body]
Resposta bruta B:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Content-Encoding: gzip
Last-Modified: Tue, 07 May 2013 04:04:01 GMT
Accept-Ranges: bytes
ETag: "60be30e8d74ace1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 07 May 2013 21:07:14 GMT
[1MB Gzipped Body]
Aparentemente, na primeira solicitação de um arquivo estático, o IIS não tem uma cópia compactada do arquivo em seu cache de arquivos compactados, portanto, ele usa compactação dinâmica nessa solicitação. Isso pode ser resolvido configurando o atributo serverRuntime do elemento frequentHitTHreshold como 1.
Isso é discutido em detalhes aqui . Provavelmente, essa configuração só vale a pena se estiver servindo um CDN.
A compactação de arquivos estáticos é tratada dinamicamente (se a compactação dinâmica estiver ativada), enquanto o arquivo é considerado infrequente pelo IIS. Uma vez que o arquivo é considerado freqüente , ele será compactado e armazenado em cache (se a compactação estática estiver ativada). A versão em cache continuará a ser exibida até que se torne pouco frequente novamente. Existem 2 configurações que você pode usar no IIS para configurar arquivos frequentes:
system.webServer / serverRuntime:
frequentHitThreshold : Quantas vezes o mesmo arquivo deve ser solicitado antes de ser considerado frequente e armazenado em cache? O padrão é 2. frequentHitTimePeriod : intervalo de tempo em que o mesmo arquivo deve ser solicitado {frequencyHitThreshold} vezes, para que seja armazenado em cache. O padrão é 10 segundos. Tenha em atenção que, independentemente do frequenteHitTimePeriod definido, um ficheiro frequente será sempre pouco frequente se não for solicitado após 1 minuto. Eu não tenho idéia se existe uma configuração para isso na configuração.
A definição de frequentHitThreshold para 1, por exemplo, significará que o arquivo é sempre considerado freqüente pelo IIS, mesmo a partir da primeira solicitação. Isso, por sua vez, contornará a compressão dinâmica e será tratado apenas pela compressão estática.
Observe que os níveis de compactação para compactação dinâmica (padrão 0) e estática (padrão 7) são diferentes, então retornará 2 tamanhos de arquivo diferentes.
Também e é por isso que eu entrei nesta questão em primeiro lugar: o ETag para o mesmo arquivo é diferente entre a compressão dinâmica e a estática, mesmo se você usar os mesmos níveis para ambos.
Espero que isso ajude.