what grabbing example ruby scala playframework sinatra lift

ruby - grabbing - ¿Por qué debería uno usar un servidor http frente a un servidor web marco?



banner grabbing is an example of what (5)

Frameworks de aplicaciones web como sinatra (ruby), play (scala), lift (scala) producen un servidor web que escucha un puerto específico.

Sé que hay algunas razones como la seguridad, la agrupación en clústeres y, en algunos casos, el rendimiento, que me pueden llevar a utilizar un servidor web Apache delante de mi aplicación web.

¿Tienes alguna razón para esto a partir de tu experiencia?

Con bastante frecuencia, los marcos hacen todo lo que necesita, pero a veces, agregar una capa encima de eso puede brindarle funcionalidades aparentemente gratuitas como compresión, seguridad, administración de sesiones, balanceo de carga, etc. Sin embargo, agregar un servidor web también puede presentar problemas de seguridad. por ejemplo, es probable que la seguridad de su servidor web se vea comprometida más fácilmente que Lift por sí sola. Además, algunos de los marcos web son extremadamente escalables e incluso pueden verse obstaculizados por un servidor web mal elegido.

En resumen, si necesita una funcionalidad similar a un servidor web que no está provista por el marco, entonces un servidor web puede ser una muy buena opción, pero tenga en cuenta que es una cosa más para configurar correctamente y actualizar regularmente con parches de seguridad, etc.

Si, por ejemplo, solo necesita cifrado o compresión, entonces puede encontrar que agregar la biblioteca o el complemento correcto a su marco puede hacer eso (y solo eso)

Con un servidor http de proxy, el marco no necesita mantener una conexión http abierta para proporcionar el contenido computado y, luego, puede comenzar a atender otra solicitud. Actúa como un amortiguador.

Es una cuestión de reinventar la rueda. La mayoría de los marcos le brindarán un entorno de desarrollo, pero para la producción, por lo general es una buena práctica utilizar un proyecto comercial / de código abierto que sea capaz de resolver todos los problemas que surjan durante la producción.

Los individuos que construyen un Marco tendrán el marco en el que concentrarse, mientras que los que construyen un servidor están haciendo lo mismo (perfeccionando).

Yo podria agregar:

  • manejo de ssl
  • para algunos servidores como apache lotes de módulos (es decir, autenticación ntml / kerberos)
  • Los servidores web son mucho mejores para algunas cosas en comparación con su aplicación, como el servicio de estática.
  • Parte de cualquier aplicación web es una funcionalidad completamente estandarizada y comercializada. Los servidores web maduros como nginx o apache pueden hacer las siguientes cosas. Pueden hacer las siguientes cosas de una manera que probablemente sea más correcta, más eficiente, más estable, más segura, más familiar para los administradores de sistemas y más fácil de configurar que cualquier cosa que pueda reescribir en su servidor de aplicaciones.
    • Servir archivos estáticos como HTML, imágenes, CSS, javascript, fuentes, etc.
    • Manejar el alojamiento virtual (múltiples dominios en una sola dirección IP)
    • Reescritura de URL
    • reescritura / redireccionamiento del nombre de host
    • Terminación TLS (gracias @ emt14)
    • compresión (gracias @JacobusR)
  • Un servidor web independiente brinda la capacidad de servir una página de "mantenimiento inactivo" mientras el servidor de aplicaciones se reinicia o se bloquea
  • Los proxies inversos pueden proporcionar equilibrio de carga y tolerancia a fallos para su marco de aplicación
  • Los servidores web tienen mecanismos incorporados y probados para vincularse a puertos privilegiados (por debajo de 1024) como root y luego ejecutarse como un usuario sin privilegios. La mayoría de los marcos de aplicaciones web no lo hacen de forma predeterminada.
  • Los servidores web maduros son resistentes a la batalla y estables. Por establo, quiero decir que casi literalmente nunca se estrellan. Su aplicación web es seguramente mucho menos estable. Esto le da la capacidad de al menos mostrar una página de error bastante al usuario que dice que su aplicación está inactiva en lugar de que el navegador web solo muestre un error genérico de "no se pudo conectar".

Y en caso de que desee la respuesta semioficial de Isaac Schluetter en la charla técnica de Airbnb el 30 de enero de 2013, en unos 40 minutos aborda la cuestión de si el nodo es lo suficientemente estable y seguro para servir las conexiones directamente a Internet. Su respuesta es esencialmente "sí", está bien. Por lo tanto, puede hacerlo y probablemente estará bien desde el punto de vista de la estabilidad y la seguridad (asumiendo que está usando un clúster para manejar la terminación inesperada de un proceso del servidor de aplicaciones), pero como se detalla más arriba, la realidad de las operaciones actuales es que todavía casi todo el mundo ejecuta el nodo detrás de un servidor web separado o proxy / caché inverso.