#5 Todo el mundo está negociando los alquileres. El dueño es libre de aceptarlo o no, pero con 4 neuronas que tenga conectadas, entenderá que si quiebra el negocio tardará larguísimo en volver a tener inquilino y de seguro le tocará bajar el precio de todas formas.
Te leí en #18 pues tío: deja que el mercado se encargue de ellos. Si tienen ahorros para toda la vida, bien por ellos, pero dudo que sea la situación general.
Si son pequeños, les va doler. Si son grandes, actúan en pro de la rentabilidad también
#3 no siempre es así, está el keep-alive para que el servidor se quede a la espera sin cerrar la conexión y se reutilice en las siguientes peticiones, también está HTTP/2 Server push que no se si le podría afectar, pero aún así yo también veo veo mucho mas factible ataques a servicios que usan conexiones más persistentes en el tiempo tal y como comentas.
#6 Tu petición
1- Es HTTP/1.1
2- No tiene cabeceras
Si haces nc o telnet y pegas tal cual esto (acabo de probar)
GET / HTTP/1.1
Host: www.google.com
Connection: Keep-Alive
(enter 2 veces)
te da el resultado y la conexión queda abierta, y pides después sobre la misma conexión TCP lo que te de la gana. Los navegadores hacen esto (algunos), escanean el HTML y ya reaprovechan esa conexión para pedir recursos al mismo dominio, eso no quita que dependiendo del tipo de recurso (o alguna otra consideración, la carga del navegador, max connexiones abiertas etc) puedan lanzarla en paralelo y pasar del keepalive como decia en #25.
De todas formas con HTTP/2 y 3 esto es es otra historia, y cada vez está más implementado.
#24 Totalmente de acuerdo en lo de aprender. Sin embargo, lo que comentas en #21, no estoy de acuerdo. No te hace falta una sesion persistente para fastidiar una peticion HTTP. Si empiezo a hacer un TCP RST en el momento en el que te veo lanzar tu primer SYN al servidor, vas a tenerlo muy complicado para poder ver cualquier pagina web. Y esto sin contar algunas conexiones HTTP mas largas, ya sea para cargar imagenes, descargar ficheros o incluso scripts y html largos que utilizan mas de un paquete. Y a todo esto no me he metido con HTTPS, donde establecer el canal TLS va a requerir multiples paquetes en ambos sentidos tipo "Client Hello" y demas.
Tampoco entiendo por que dices que al final de la peticion HTTP hay un RST. Esto no es el comportamiento por defecto, ahi deberiamos ver normalmente un FIN/ACK/FIN/ACK. Cierto que en algunas redes puedes acabar con algun dispositivo que termina lanzando un RST para "cerrar" una comunicacion, pero vamos, yo lo considero una falta de educacion.
#5#17#20 Ya no es solo el keepalive, depende de más cosas, se han ido implementando varias técnicas, casi todas para eliminar el HoL blocking, el keepalive es una.. pero hay más.
Por una parte está el domain sharding, una técnica que escanea el HTML inicial en busca de dominios para ver qué recursos están en el mismo dominio, por otra parte está un ajuste del navegador relacionado con el máximo número de conexiones que puede realizar en paralelo al mismo servidor (o proxy), es decir, que el keepalive posibilita el uso de la misma conexión para acceder a todos los recursos en el caso óptimo, pero es posible que el navegador decida que va a lanzar 4 peticiones en paralelo (como si no existiera el ajuste keepalive) porque accede antes a los recursos, probablemente esto también depende del tipo de medio y de si puede hacer una carga parcial o no, o si se necesita hacer una precarga o no.
Eso sí, una vez agotadas las conexiones en paralelo si se podrá usar las conexiones persistentes para reutilizar esas conexiones, pero en el caso del ejemplo del ejercicio de 3 imágenes no aplica, porque la mayoría de los navegadores tienen por defecto alrededor de 6 conexiones simultaneas por defecto.
En resumen, ahora mismo, que yo sepa (por pruebas que hago de vez en cuando) solo firefox hace caso realmente al keepalive si está disponible, pero la misma prueba en Chrome y Edge pasan del ajuste totalmente y lanzan peticiones en paralelo
En el caso de HTTP/2 y HTTP/3 las conexiones persistentes ya son obligatorias, ya que solo se realiza una conexión a cada servidor y todas las peticiones son multiplexadas en modo binario sobre esa conexión.
De todos modos pensaba estar seguro!... lo bueno de comentar y que te corrijan es que se aprende. ¿No crees? Hoy aprendí una cosa nueva!
Al mensaje que replicaba no daba detalle técnico alguno, información que poder comprobar ni leer. Entiende que sin esto, uno se reafirme en lo que cree que es cierto.
#5 Si alguien te corrige, mas vale que estes muy seguro de lo que dices, porque en este caso me parece que estas insistiendo en el error. Todo depende de si el cliente y el servidor estan de acuerdo y establecen una peticion persistente (lo que venia siendo Connection-type: keep-alive y que se sigue poniendo "por si acaso"). Esto no estaba en el RFC de HTTP 1.0 (pero se implemento por muchos servidores y clientes como extension) pero si que forma parte de HTTP 1.1 y de hecho se considera la opcion por defecto del protocolo.
Incluyo una pequeña imagen donde se ve el trafico de wireshark, claramente un unico stream tcp con su inicio y dos peticiones http dentro. Tras eso, puede verse como se mantiene la comunicacion durante aproximadamente dos minutos mas y tras esto, la comunicacion termina Si tienes especial interes, avisame y te lo paso en formato pcap.
#6 Como tu mismo dices, en sucesivas peticiones HTTP, no necesariamente TCP que en muchos casos es persistente. Estas confundiendo peticiones HTTP y TCP.
#5 Sí, hay muchas peticiones pero si el servidor y el cliente quieren, se abre un canal TCP y se mantiene abierto para evitar tener que hacer una nueva conexión para cada petición.
Ese keep-alive le dice al navegador que no cierre la conexión después del pedido. Si el navegador lo soporta, mantendrá el socket abierto y enviará más peticiones por ahí. Así se ahorra tráfico.
#12 1 petición HTTP ninguna, 1 única conexión TCP, todas las que tengan la cabecera Content: keep-alive. Mismamente, Meneame tiene activada dicha cabecera y todas las peticiones HTTP se rutan a través de una única conexión TCP.
Como Meneame usa https es dificil capturar el tráfico, aunque si lo capturas con Wireshark ves una única conexión TCP sobre la que se multiplexan varias peticiones y respuestas HTTP al mismo sitio.
Sin embargo, si capturas tráfico de una web HTTP se ve como sobre la misma conexión TCP se multiplexan varias peticiones HTTP. Por ejemplo, si capturas el tráfico de dbfmkchsnlrxtvwz.neverssl.com/online verás que hace 2 peticiones HTTP /online y /favicon.ico sobre la misma conexión TCP. Puedes descargar la captura de tráfico en we.tl/t-R7f6VLXu3w y comprobarlo con Wireshark. Obviamente, el resto de peticiones que hace (A platform.twitter.com y syndication.twitter.com) son dos conexiones TCP diferentes, pero las 2 peticiones que hace a platform.twitter.com también son multiplexadas en una única conexión TCP (Que no adjunto por ser SSL y no poder distinguirse el tráfico). Es decir, para visitar dicho sitio web, se hacen 5 peticiones HTTP ruteadas a través de 3 sockets TCP.
Si lo miras en el inspector ves que son 5 peticiones HTTP pero en ningún momento el inspector (al menos en mi versión de Firefox) habla de conexiones TCP. Sin embargo, si capturas tráfico con Wireshark, ves como son solo 3 sockets, es decir, que el socket TCP persiste y es utilizado para seguir mandando subsecuentes peticiones HTTP, que es lo que decía #4.
#32 Pero si no viene del estado, el arrendador se acoge a su contrato y a lo que encuentre en el mercado + sus riesgos + esfuerzo. mientras que para el arrendatario un cambio de locla puede suponer un desembolso igual al posible beneficio de muchos años y quizá no puede acometerlo y menos despues de meses de perdidas(es la gran diferencia entre un negocio pequeño/familiar a uno grande o muy grande donde si el beneficio es a largo plazo positivo se pueden permitir cambios grandes o inversiones).
#10 No conocía DASH, le echaré un vistazo, gracias por el enlace. En #9 me intento explicar mejor. Todo venía porque en las imágenes de la web de #0 ponen código HTML ....
En HTTP 1.0 las conexiones no son persistentes salvo que se indique lo contrario con la cabecera keep-alive. En HTTP/1.1 y HTTP/2, las conexiones son persistentes por defecto salvo que se indique lo contrario. Más información en en.wikipedia.org/wiki/HTTP_persistent_connection
Por otro lado, al menos en mi versión de Firefox, lo único que te muestra el developer tools son las conexiones HTTP pero no el manejo TCP subyacente. Todas esas peticiones se enrutan por un único canal TCP cuando la cabecera de keep-alive está activa.
Desconozco las estadísticas de uso de la cabecera keep-alive, pero la mayoría de los sitios que conozco la tienen activa. La mejor manera de comprobarlo sería con Wireshark o similar, si capturas tráfico, vez que todas las consultas a un sitio se hacen vía un único canal TCP, conteniendo la consulta HTTP a varios recursos (html, css, js...)
#8No son persistentes, en cuanto la descarga acabe el servidor cierra la conexión, sigue siendo HTTP.
Si la descarga dura 1 hora, y te hacen un ataque de estos, tiene impacto. Y si se lo hacen a todos los usuarios de una web de descargas, básicamente en un DoS en toda regla.
Por otro lado los servicios de streaming de video suelen usar UDP, no TCP.
#5 Todo depende de los que cobran. El casero debería apechugar con su parte y reducir la cuota al menos a la mitad. Los Ayuntamientos están haciendo muchos su parte y están anulando el pago de las tasas de terraza. Si el casero quiere que el negocio de su arrendado se vaya a tomar por saco por no poder hacer frente a los gastos y por tanto, cerrar el negocio, el casero se va a terminar quedando sin cliente y por tanto sin ingresos. Es cuestión de que los arrendadores sepan ver las cosas con lógica.
Aunque supongo que, si hablamos de http(s) se podría usar este ataque contra servicios de descarga web, o contra servicios de streaming de vídeo, por ejemplo, que asumo que usan conexiones persistentes. Eso por mencionar servicios de alta demanda y uso común, aunque por supuesto en un entorno empresarial, y si hablamos en términos generales, hay cosas más críticas, como conexiones a BBDD, y no digamos iSCSI si usas BfS en los servidores. En general funciona contra cualquier conexión persistente que no se haga sobre IPsec, con más o menos impacto.
#3 No exactamente, normalmente se usan conexiones persistentes para hacer varias peticiones al mismo servidor. Ten en cuenta que una página web moderna igual tiene 10 scripts, tres o cuatro hojas de estilos y 20 imágenes. Tener que establecer una conexión TCP para pedir cada uno de los recursos es más lento que mantener la conexión abierta y reusarla para pedir varias cosas seguidas.
#289 portera 
