carregamento HTTPS limitado por EC2

Question

Eu tenho um aplicativo em duas instâncias do EC2 atrás de um ELB. O ELB faz a terminação HTTPS e, em seguida, fala HTTP para as instâncias.

Ao fazer o upload via HTTPS, a transferência parece ser limitada a ~ 10 Mbps por arquivo (ex. 2 arquivos serão enviados a 20 Mbps, 3 a 30 Mbps e assim por diante), enquanto se eu transferir via HTTP posso facilmente saturar 100 Mbps upload link com um único arquivo.

Eu tentei mover a terminação HTTPS para as instâncias (nginx) e meus testes deram os mesmos resultados.

Eu tentei de diferentes clientes (sistema operacional e navegador) e diferentes redes de uplink. Os resultados são sempre os mesmos.

Eu realmente não tenho ideia de por onde começar a solucionar esse problema, então qualquer orientação seria muito apreciada.

    

Answer 1

Acho que o ELB foi projetado para escalabilidade horizontal, não necessariamente para alta taxa de transferência de fluxo único. Isso é o que você observou também - muitos fluxos simultâneos estão todos funcionando bem, mas cada um deles está limitado a uma taxa de transferência máxima.

Se você quiser acelerar o upload para a AWS, consulte S3 Transfer Acceleration - que provavelmente será muito mais rápido e seus arquivos serão salvos diretamente em um bucket do S3, a partir do qual eles poderão ser processados pelo aplicativo. Você pode até mesmo receber as notificações do SNS sempre que um novo upload de arquivo for concluído para que você possa iniciar o processamento imediatamente.

Depende do seu uso, é claro, mas o upload de arquivos grandes por ELB e Nginx não parece que você está usando os melhores serviços disponíveis para o propósito. Estes seriam mais adequados para lidar com um grande número de usuários simultâneos, não um pequeno número de usuários pesados.

Espero que ajude:)

    

Answer 2

Então, foi um problema HTTP2.

Citando o representante do AWS Support:

Although ALB supports data transfer using HTTP 2.0 protocol while connecting over HTTPS, the upload a file could be slower than HTTP1.1 if the client uses a single stream in the connection to upload it.

In a general use, the HTTP2 introduces an additional layer of flow control on top of TCP flow control that is intended to allow applications to control throughput per HTTP2.0 stream, allowing the applications to ensure equal treatment to all streams on a connection or conversely to prioritize one or some streams above others.

In an ALB, the HTTP/2.0 window update for a single stream is capped to 64K. The clients have to advertise WINDOW_UPDATE frame consistently for every 64KB otherwise, if slow, it will negatively affect the throughput when only one stream is utilized for doing larger uploads on relatively high latency networks as compared to HTTP/1.1 or lower versions which lack this feature.

Generally the Clients over the internet like Chrome, Firefox, an others are designed to advertise this in a slow fashion considering that the server is having a bigger cap on the frame, experiencing latency.

Desativamos o HTTP2 e os uploads agora são muito rápidos!