Esta não é uma pergunta ideal para o Superusuário. Falha no servidor teria sido um alvo melhor para essa questão. Dito isto ...
Não há respostas concretas para suas perguntas - com muitas opções diferentes disponíveis para realizar cada ponto. Vou responder principalmente com o que eu recomendaria.
- Does TLS happen where I showed it?
Um dispositivo dedicado, como um balanceador de carga, é onde eu descarregaria o TLS, sim. Normalmente você tem hardware dedicado aqui que é especialmente projetado para acelerar o TLS sem usar ciclos mais lentos de uso geral da CPU. A centralização de seus certificados TLS em tal dispositivo também auxilia no gerenciamento de certificados - ou no caso de problemas de segurança como Heartbleed ou POODLE, fornece um único ponto em que qualquer alteração de segurança necessária precisa ser feita - em vez de vários servidores da Web.
- O ideal seria ter dois ou mais balanceadores de carga, configurados como ativo / ativo ou ativo / passivo em uma configuração altamente disponível para failover e redundância.
- No caso do Heartbleed, pelo menos alguns dos balanceadores de carga significativos no mercado não estavam vulneráveis - devido ao uso de uma pilha nativa SSL / TLS em vez de OpenSSL.
Se a segurança fosse primordial para você, você poderia considerar o encapsulamento do tráfego entre seu balanceador de carga e seus servidores da Web em uma nova conexão TLS. Como alternativa, não termine o TLS e somente encaminhe a conexão TCP para um ou mais de seus servidores da web. No entanto, fazer praticamente desfaz qualquer uma das vantagens que mencionei acima. Além disso, espero que suponha que tanto o (s) seu (s) balanceador (es) de carga e o (s) servidor (es) da Web (e suas comunicações) estejam contidos em um data center seguro em que as comunicações criptografadas não sejam necessárias. (Se esses dispositivos não forem seguros, todas as apostas serão desativadas de qualquer maneira).
Veja também: link
- Where does URL re-writes and re-direction happen?
Como você mencionou, um CDN seria outra possibilidade para isso - que de outra forma ignorarei aqui.
Você pode fazer isso em um balanceador de carga ou no servidor da web. Eu tenho a tendência de fazer a maior parte disso dentro do servidor web - especialmente quando uso o Apache HTTPD - já que você simplesmente não consegue superar as capacidades e a flexibilidade oferecidas por mod_rewrite . Ser capaz de manter essas regras em um arquivo de texto independente de dispositivo que pode ser controlado por fonte no SVN, etc., também é um bônus adicional - especialmente porque as regras tendem a ser alteradas com freqüência (dada a sua natureza).
Eu sempre manteria quaisquer reescritas e redirecionamentos internos ao site / domínio que você está hospedando no servidor da web. Em casos limitados em que URLs em um site hospedado precisam redirecionar para outro lugar - e onde o desempenho é uma preocupação crítica - eu verificaria esse trabalho no balanceador de carga.
- Should/can I let static content be handled at the load-balancing layer (which may be on a separate server) or should it be handled at the Web server layer?
Com raras exceções, o conteúdo é veiculado por um servidor da Web, não por um balanceador de carga. O que você pode / deve fazer aqui é configurar seu servidor web para servir tal conteúdo estático diretamente - e não tê-lo enviado para PHP / Python / Tomcat / etc., para uma veiculação provavelmente mais lenta. Quando possível, use e configure um CDN para ter tudo isso descarregado na rede de borda e nem mesmo atingir seu balanceador de carga.
Um aspecto que pode ser um pouco complicado aqui é autenticação, autorização e registro. A qualquer momento em que você descarregar esse conteúdo "estático", suas camadas inferiores podem nunca estar cientes de que esse conteúdo está sendo veiculado - não é possível protegê-lo nem rastrear seu acesso. Uma possibilidade aqui (se isso é uma preocupação) é usar um modelo de "autenticação centralizada" - onde uma camada superior pode ter o conteúdo armazenado em cache, mas ainda enviará a solicitação de volta para a camada / origem inferior com um "If-Modified-". Desde "cabeçalho. A origem é então capaz de inspecionar o ID da sessão / cookies / etc - e tem a oportunidade de responder com algo como "HTTP 403 Proibido" ou "HTTP 304 Não Modificado" (retorno do cache).