Mi aplicación interactúa con muchos otros servicios basados en HTTPS. Como los usamos con una frecuencia considerable, me preocupa el impacto en el rendimiento del uso de HTTPS.
¿Hay algún mecanismo (límite de tiempo o algún otro permanente) que pueda usar para evitar el apretón de manos HTTPS y otros posibles cuellos de botella?
Por supuesto, no quiero usar HTTP :)
En SSL hay conexiones , y hay sesiones .
Una conexión comienza con un apretón de manos, y termina cuando cualquiera de las partes lo declara enviando un mensaje de alerta close_notify . Los navegadores y servidores web típicos mantendrán las conexiones abiertas durante algún tiempo, cerrándolas después de uno o dos minutos de inactividad; una o varias solicitudes y respuestas HTTP se envían a través de esa conexión. En contextos HTTPS normales, hay una asignación uno a uno entre las conexiones SSL y las conexiones TCP subyacentes: para cada conexión TCP (al puerto 443), habrá una única conexión SSL, y cuando la conexión SSL finalice, La conexión TCP subyacente está cerrada.
Una sesión se relaciona con la criptografía asimétrica que se produce en un "apretón de manos completo". El proceso handshake , que se produce al comienzo de una conexión, trata sobre el establecimiento de los algoritmos y claves criptográficos que se utilizarán para proteger los datos de esa conexión. Hay dos tipos de apretones de manos:
El apretón de manos completo es lo que hacen un cliente y un servidor cuando no se conocen (no han hablado anteriormente, o eso fue hace mucho tiempo). En el apretón de manos completo, los certificados se envían y se produce una criptografía asimétrica (RSA, Diffie-Hellman ...).
El apretón de manos abreviado es lo que un cliente y un servidor se recuerdan entre sí; con más precisión, recuerdan los algoritmos y las claves que establecieron en un apretón de manos anterior y aceptan reutilizarlos (técnicamente, reutilizan el "secreto maestro" y derivan de las nuevas claves de cifrado para esta conexión).
Una conexión con un apretón de manos completo, y el conjunto de conexiones con un apretón de manos abreviado que reutilizan ese apretón de manos completo, constituyen juntas la sesión .
El apretón de manos abreviado es más eficiente que el apretón de manos completo, porque implica menos viajes de ida y vuelta a la red, mensajes de apretón de manos más pequeños y ninguna criptografía asimétrica.
Para el rendimiento , en general, desea lo siguiente:
Mantenga las conexiones abiertas tanto como sea posible. Una "conexión abierta" utiliza unos pocos recursos de memoria (ambas partes deben recordar las claves) y los recursos del sistema (para la conexión TCP subyacente, que se mantiene abierta). Sin embargo, no hay tráfico de red involucrado en mantener una conexión viva, excepto posiblemente el opcional TCP keepalive ".
Cuando las conexiones no se pueden mantener abiertas (por ejemplo, para liberar recursos del sistema), es mejor si el cliente y el servidor recuerdan sesiones para que puedan hacer apretones de manos abreviados si se vuelven a conectar. Los servidores web tienen varias políticas predeterminadas y configurables. Por ejemplo, Apache (con mod_ssl ) utiliza un caché que se define tanto para tamaño y para duración ; el servidor "olvida" una sesión cuando su caché está lleno y necesita algo de espacio adicional, o cuando se ha alcanzado el tiempo de espera, la condición que ocurra primero.
Si tiene control sobre la configuración de los servidores, es posible que desee aumentar el "tiempo de espera de inactividad" para la terminación de la conexión, y también para aumentar el tamaño y la duración del caché de la sesión. Si no tiene control sobre los servidores, entonces su pregunta es un tanto irrelevante: haga lo que haga, tendrá que ser compatible con lo que ofrecen los servidores. De alguna manera, puede forzar a un servidor no a olvidar una sesión abriendo regularmente una nueva conexión con un protocolo de enlace abreviado, pero eso no es necesariamente una buena idea (por lo general, cuando un servidor olvida las sesiones, es para un más o menos buena razón).
De todos modos, deberás tomar medidas . Esta es una pregunta sobre el rendimiento; El razonamiento abstracto no puede dar respuestas definitivas. La regla general habitual es que los problemas de rendimiento no existen hasta que se hayan medido debidamente en la vida real, o al menos en un sistema prototipo razonablemente representativo.
En cualquier caso, es difícil obtener las mismas funcionalidades de seguridad de SSL con un costo menor. Reemplazar SSL por "algo personalizado" es poco probable que proporcione una gran mejora en cuanto al rendimiento sin sacrificar la seguridad de alguna manera.
Para obtener una guía de SSL, consulte esta respuesta . Tener algún conocimiento de los aspectos internos de SSL realmente ayuda mucho a pensar en cualquier diseño que implique SSL.
Esto debería ser un comentario, ya que no hay suficiente información en su pregunta para diagnosticar el problema / proponer una respuesta definitiva, pero es un poco largo ...
Es bastante difícil decir a tu pregunta cómo se ve tu aplicación. ¿Se refiere al código que se ejecuta en su servidor y que hace llamadas HTTPS a otros servicios o se realizan las llamadas desde el navegador? ¿Las llamadas a un número predecible y pequeño de servidores?
Si el cliente para las llamadas HTTPS es su código de aplicación, obtendrá grandes beneficios de la explotación de keepalive (si es compatible con el servidor HTTPS). Dependiendo de cómo funcione su aplicación, esto puede significar administrar un grupo de conexiones (lo que puede ser complicado), sin embargo, algunos servidores proxy inversos lo admitirán.
Tal vez solo necesite utilizar la información de almacenamiento en caché ya proporcionada por el servicio HTTPS; sería útil enrutar las solicitudes a través de un proxy de almacenamiento en caché local.
De forma alternativa, si controla los servicios remotos, utilizar una VPN en lugar de TLS eliminaría la sobrecarga de intercambio (la mayoría de las veces).
Si la convergencia está en el cliente, entonces se convierte en una pregunta muy diferente. Si las múltiples solicitudes se dirigen en su mayoría a sus servidores, la solución podría ser habilitar el almacenamiento en caché de la sesión ssl (distribuida). Ciertamente, debe habilitar keepalive (sé que Ralph Engeschall dijo que no debería hacer esto con mod_ssl y MSIE, pero eso fue un muy hace mucho tiempo, ya que MSIE7 la mayoría de los problemas están solucionados).
Lea otras preguntas en las etiquetas tls