 miércoles, enero 17, 2018

PARA PROGRAMADORES
Todo relacionado a la programacion e informática

 PROGRAMACION  REDES  ELECTRONICA  SEGURIDAD INFORMATICA  INTELIGENCIA ARTIFICIAL VIDEOJUEGOS

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Programacion

Los Beneficios De Las API REST Con HTTP / 2

 enero 12, 2018  dynamic  Comment(0)

SOCIAL

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Para Programado…
Me gusta esta página

Sé el primero de tus amigos en indicar

que te gusta esto.

Compártelo

 Facebook  Twitter  Google+

HTTP / 1.x frente a HTTP / 2

Primero, veamos algunas de las diferencias de alto nivel:

HTTP / 2 es binario, en lugar de textual

Los protocolos binarios son más eficientes de analizar, más compactos “sobre la marcha” y, lo que
es más importante, son mucho menos propensos a errores en comparación con los protocolos de
texto como HTTP / 1.x, porque a menudo tienen una serie de posibilidades para “ayudar”. “con cosas
como manejo de espacio en blanco, mayúsculas, finales de línea, líneas en blanco, etc.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Por ejemplo, HTTP / 1.1 define cuatro formas diferentes de analizar un mensaje; en HTTP / 2, solo hay
una ruta de código.

HTTP / 2 está completamente multiplexado, en lugar de ordenado y bloqueado

HTTP / 1.x tiene un problema llamado “bloqueo de cabecera de línea”, donde efectivamente solo una
solicitud puede estar pendiente en una conexión a la vez.

HTTP / 1.1 intentó solucionar esto con pipelining, pero no resolvió completamente el problema (una
respuesta grande o lenta puede bloquear a otros detrás de ella). Además, se ha descubierto que la
canalización es muy difícil de implementar, porque muchos intermediarios y servidores no la
procesan correctamente.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Esto obliga a los clientes a usar una cantidad de heurísticas (a menudo adivinar) para determinar
qué solicitudes se deben establecer en qué conexión con el origen y cuándo; dado que es común
que una página cargue 10 veces (o más) la cantidad de conexiones disponibles, esto puede afectar
gravemente el rendimiento, lo que a menudo resulta en una “cascada” de solicitudes bloqueadas.

La multiplexación soluciona estos problemas al permitir que múltiples mensajes de solicitud y

respuesta estén en vuelo al mismo tiempo; incluso es posible mezclar partes de un mensaje con
otro en el cable.

Esto, a su vez, permite que un cliente use solo una conexión por origen para cargar una página.

HTTP / 2 puede usar una conexión para el paralelismo

Con HTTP / 1, los navegadores abren entre cuatro y ocho conexiones por origen. Dado que muchos
sitios usan orígenes múltiples, esto podría significar que una única carga de página abre más de
treinta conexiones.

Una aplicación que abre tantas conexiones simultáneamente rompe muchas de las suposiciones
sobre las que se construyó TCP; dado que cada conexión iniciará una avalancha de datos en la
respuesta, existe un riesgo real de que los buffers en la red intermedia se desborden, causando un
evento de congestión y retransmite.

Además, el uso de tantas conexiones monopoliza injustamente los recursos de red, “robándolos” de
otras aplicaciones de mejor comportamiento (por ejemplo, VoIP).

HTTP / 2 usa la compresión de encabezado para reducir gastos generales

Si supone que una página tiene alrededor de 80 activos (que es conservadora en la Web de hoy), y

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 cada solicitud tiene 1400 bytes de encabezados (una vez más, no es raro, gracias a las cookies,
Referer, etc.), se necesita al menos 7-8 viajes de ida y vuelta para sacar los encabezados “en el
cable”. Eso no cuenta el tiempo de respuesta, eso es solo para sacarlos del cliente.

Esto se debe al mecanismo de inicio lento de TCP, que estimula los paquetes en las nuevas
conexiones en función de la cantidad de paquetes reconocidos, lo que limita efectivamente el
número de paquetes que se pueden enviar en los primeros viajes de ida y vuelta.

En comparación, incluso una compresión leve en los encabezados permite que esas solicitudes
lleguen al cable en un viaje de ida y vuelta, tal vez incluso un paquete.

Esta sobrecarga es considerable, especialmente cuando se considera el impacto sobre los clientes
móviles, que normalmente ven la latencia de ida y vuelta de varios cientos de milisegundos, incluso
en buenas condiciones.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 HTTP / 2 permite a los servidores “presionar” las respuestas de manera proactiva en cachés de
clientes
Cuando un navegador solicita una página, el servidor envía el código HTML en la respuesta y luego
necesita esperar a que el navegador analice el HTML y emita solicitudes para todos los activos
incorporados antes de que pueda comenzar a enviar JavaScript, imágenes y CSS.

Server Push potencialmente permite que el servidor evite este viaje de ida y vuelta al “empujar” las
respuestas que cree que el cliente necesitará en su caché.

Sin embargo, presionar respuestas no es “mágico”: si se usa incorrectamente, puede dañar el

rendimiento. Por ahora, muchos todavía seguirán trabajando con Webhooks.

Tabla de Contenidos [hide]

1 ¿Cómo afecta esto a las API REST existentes creadas en HTTP / 1.1?
2 Beneficios de HTTP / 2 explicados
3 Comunicación bidireccional utilizando solicitudes de inserción
4 Multiplexación dentro de una única conexión TCP
5 Long Running Connections
6 Conexiones con estado
7 Más Encriptación
8 Resumen

¿Cómo afecta esto a las API REST existentes

creadas en HTTP / 1.1?

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 La semántica principal de HTTP se ha retenido en HTTP / 2. Esto significa que todavía tiene métodos
HTTP como GET, POST, encabezados HTTP y URI para identificar recursos.

Lo que ha cambiado en HTTP / 2 con respecto a HTTP / 1.1 es la forma en que la semántica de HTTP
(por ejemplo, “Quiero PUT resource / foo en host domain.com”) se transporta por cable. Esto significa
que las API REST creadas en HTTP / 1.1 continuarán funcionando de forma transparente como antes,
sin cambios en las aplicaciones.

El contenedor web que ejecuta las aplicaciones se ocupará de traducir el nuevo formato de cable
en la semántica HTTP habitual en nombre de las aplicaciones, y la aplicación solo ve la semántica
HTTP de nivel superior, sin importar si fue transportada a través de HTTP / 1.1 o HTTP. / 2 sobre el cable.

Debido a que el formato HTTP / 2 es más eficiente (en particular debido a multiplexación y
compresión), las API REST sobre HTTP / 2 también se beneficiarán de esto.

La otra mejora importante presente en HTTP / 2, HTTP / 2 Push, apunta a la descarga eficiente de
recursos correlacionados y, como probablemente no sea útil en la mayoría de casos de uso REST
API, tal vez solo los Servicios de almacenamiento de objetos se puedan beneficiar de esto (como
Amazon S3).

Un requisito típico de HTTP / 2 es desplegarse sobre TLS. Esto requiere que los implementadores
pasen de HTTP a HTTPS, lo que significa que deben comprar certificados SSL de una autoridad de
confianza, etc.

Beneficios de HTTP / 2 explicados

Entre las principales mejoras aportadas por HTTP / 2 se encuentran las transmisiones multiplexadas,
la compresión de encabezados, la inserción del servidor y un protocolo binario en lugar de uno

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 textual. Estos y otros cambios positivos permitieron obtener buenos resultados de carga de páginas
web, incluidos los que tienen muchos archivos adicionales adjuntos (por ejemplo, estilos, secuencias
de comandos, imágenes, fuentes, etc.).

HTTP / 2, la nueva versión del protocolo HTTP, también ofrece muchas características nuevas para la
comunicación de servidor a servidor:

Comunicación bidireccional utilizando

solicitudes de inserción
El “envío de servidor” de HTTP / 2 permite a un servidor enviar cosas proactivamente a la memoria
caché del cliente para uso futuro.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Esto ayuda a evitar un viaje de ida y vuelta entre buscar HTML y hojas de estilo vinculadas y CSS, por
ejemplo; el servidor puede comenzar a enviar estas cosas de inmediato, sin esperar a que el cliente
las solicite.

También es útil para actualizar o invalidar proactivamente la caché del cliente, algo que las
personas han pedido.

Por supuesto, en algunas situaciones, el cliente no quiere que se le agregue algo, generalmente
porque ya tiene una copia, o sabe que no la usará. En estos casos, puede decir “no” con RST_STREAM.

Multiplexación dentro de una única conexión

TCP
HTTP / 2 usa multiplexación para permitir que muchos mensajes se intercalen en una conexión al
mismo tiempo, de modo que una respuesta grande (o una que requiera un tiempo prolongado para
que el servidor lo piense) no bloquea otras.

Además, agrega compresión de encabezado, por lo que los encabezados de solicitud y respuesta
normales no dominan el ancho de banda, incluso si lo que está solicitando es muy pequeño. Esa es
una gran ganancia para los dispositivos móviles, donde obtener grandes encabezados de solicitud
puede simplificar el tiempo de carga de una página con muchos recursos en varios viajes
redondos.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Long Running Connections
HTTP / 2 está diseñado para usar menos conexiones, por lo que los servidores y las redes disfrutarán
de menos carga. Esto es especialmente importante cuando la red se congestiona porque el uso de
HTTP / 1 de múltiples conexiones para el paralelismo se suma al problema.

Por ejemplo, si su teléfono abre seis conexiones TCP a cada servidor para descargar los recursos de
una página (recordando que la mayoría de las páginas usan múltiples servidores actualmente),
puede sobrecargar fácilmente los buffers de la red móvil, lo que hace que descarten paquetes,
retransmiten, y empeorando el problema

HTTP / 2 permite el uso de una sola conexión por host y alienta a los sitios a consolidar su contenido
en un host siempre que sea posible.

Conexiones con estado

Si su cliente HTTP / 1 envía una solicitud y luego descubre que no necesita la respuesta, necesita
cerrar la conexión si quiere ahorrar ancho de banda; no hay forma segura de recuperarlo.

HTTP / 2 agrega el marco RST_STREAM para permitir que un cliente cambie de opinión; si el
navegador navega fuera de una página, o el usuario cancela una descarga, puede evitar tener que
abrir una nueva conexión sin desperdiciar todo ese ancho de banda.

Una vez más, se trata de mejorar el rendimiento percibido y la compatibilidad con la red; al permitir
que los clientes mantengan viva la conexión en este escenario común, se evitan los viajes de ida y
vuelta y el consumo de recursos adicionales.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Pero…
Como siempre, no todo se trata de beneficios, hay algunas desventajas cuestionables:

Uso de Binary en lugar de texto

Esta también es una característica buena y no tan buena.

Una de las cosas buenas de HTTP / 1 es la capacidad de abrir telnet, escribir una solicitud (¡si el
servidor no se detiene!) Y luego mirar la respuesta. Esto no será práctico en HTTP / 2 porque es un
protocolo binario. ¿Por qué?

Considere cómo podemos almacenar short int 30000 (0x7530), tanto como texto como binario:

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Como puede ver, en lugar de usar 5 bytes, estamos usando 2 bytes. Es más de 50% de reducción de
tamaño.

Si bien los protocolos binarios tienen una sobrecarga menor para analizar, así como una huella de
red ligeramente más ligera, la verdadera razón de este gran cambio es que los protocolos binarios
son más simples y, por lo tanto, menos propensos a errores.

Esto se debe a que los protocolos textuales deben cubrir cuestiones como la delimitación de
cadenas (contadas, ¿doble línea nueva?), Cómo manejar espacios en blanco, caracteres
adicionales, etc. Esto lleva a una gran complejidad de implementación; en HTTP / 1, hay no menos de
tres formas de saber cuándo termina un mensaje, junto con un complejo conjunto de reglas para
determinar qué método está en uso.

La naturaleza textual de HTTP / 1 también ha sido la fuente de una serie de problemas de seguridad;
Debido a que diferentes implementaciones toman decisiones diferentes sobre cómo analizar un
mensaje, las partes malintencionadas pueden abrirse camino (por ejemplo, con el ataque de
división de respuesta).

Una razón más para alejarse del texto es que cualquier cosa que se parezca remotamente a HTTP / 1
se procesará como HTTP / 1, y cuando agregue funciones fundamentales como la multiplexación
(donde asociar contenido con el mensaje incorrecto puede tener resultados desastrosos), necesita
para hacer una pausa limpia

Por supuesto, todo esto es un pequeño consuelo para la persona de operaciones pobres que solo
quiere depurar el protocolo. Eso significa que necesitaremos nuevas herramientas y muchas de
ellas para abordar esta deficiencia; para empezar, Wireshark ya tiene un complemento.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Más Encriptación
HTTP / 2 no requiere el uso de TLS (la forma estándar de SSL, la capa de cifrado de la Web), pero su
mayor rendimiento facilita el uso del cifrado, ya que reduce el impacto sobre la velocidad de su sitio.
Esto significa que probablemente necesite comprar certificados SSL, renovarlos, etc. No es una
cantidad pequeña de dinero para gastar cuando trabaja con muchos microservicios que utilizan
API REST.

De hecho, muchas personas creen que la única forma segura de implementar el nuevo protocolo
en la Internet “abierta” es usar el cifrado; Firefox y Chrome han dicho que solo admitirán HTTP / 2 con
TLS.

Ellos tienen dos razones para esto. Una es que la implementación de una nueva versión de HTTP en
Internet es difícil, porque muchos “middleboxes”, como los servidores proxy y firewalls, suponen que
HTTP / 1 no cambiará nunca, y pueden introducir interoperabilidad e incluso problemas de seguridad
si Intenta interpretar una conexión HTTP / 2.

El otro es que la Web es un lugar cada vez más peligroso, y el uso de más cifrado es una forma de
mitigar una serie de amenazas. Al utilizar HTTP / 2 como una zanahoria para que los sitios usen TLS,
esperan que mejore la seguridad general de la web.

Resumen
El beneficio real para sus API REST existentes será que la mayoría de sus microservicios que
probablemente estén basados en REST estén trabajando en la comunicación de servidor a servidor.
En la arquitectura actual de microservicios, cuando muchos microservicios hablan entre sí de
muchas maneras pero aún usan REST, HTTP / 2 puede aumentar la velocidad de sus flujos de trabajo.

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 HTTP / 2 no define una API de JavaScript ni le ayuda a construir sus API de REST mucho más
fácilmente. Por ahora, los clientes JavaScript que se ejecutan en un navegador web pueden hacer
un uso limitado de las nuevas capacidades. Sin embargo, para la comunicación de servidor a
servidor, HTTP / 2 ofrece muchas maneras de ir más allá de las API REST existentes.

Además, la desventaja de la compatibilidad de red de HTTP / 2 es que hace que el control de la

congestión de TCP sea más notorio; ahora que los navegadores solo usan una conexión por host, la
ventana inicial y las pérdidas de paquetes son mucho más evidentes.

Así como HTTP ha pasado por un período de escrutinio, experimentación y evolución, se está
volviendo evidente que la atención de la comunidad se está volcando hacia TCP y su impacto en el
rendimiento; ya hubo una discusión temprana sobre ajustes e incluso reemplazo de TCP en el IETF.

Compártelo

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
  Facebook  Twitter  Google+

Dynamic

RELATED ARTICLES

Programacion Programacion Programacion

Los 5 mejores lenguajes Los 7 mejores IDEs para Swift libro en PDF
funcionales para usar en este 2018 avanzado
desarrollo front-end  enero 11, 2018  dynamic  noviembre 20, 2017 
 enero 11, 2018  dynamic
Compártelo dynamic

Compártelo FacebookTwitterGoogle+Tabla Compártelo

FacebookTwitterGoogle+Tabla de Contenidos1 Visual Studio FacebookTwitterGoogle+Tabla
de Contenidos1 JavaScript2 Code2 PhpStorm3 NetBeans4 de Contenidos1 Excelente Swift
Purescript3 ClojureScript4 Elm5 Eclipse5 Aptana Studio6 libro en PDF2 Acerca de Swift3

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Reason ML JavaScript
JavaScript (JS) es un lenguaje
de programación de
computadora dinámico. Se usa
más comúnmente como parte
de los navegadores web, cuyas
implementaciones permiten
que los scripts del lado del
cliente interactúen con el
usuario, controlen el
navegador, se comuniquen de
forma asíncrona y modifiquen
[…]
Angular IDE (by Webclipse)7
Komodo IDE Visual Studio Code
Visual Studio Code es un editor
de código redefinido y
optimizado para construir y
depurar aplicaciones web y en
la nube modernas. Visual Studio
Code es gratuito y está
disponible en su plataforma
favorita: […]
Un recorrido rápido4 Los
basicos Excelente Swift libro en
PDF Aprende todo sobre Swift
con este libro llamado Swift
libro en PDF, todos los
conceptos sobre este lenguaje
de programación de la familia
Apple. Acerca de Swift Swift es
un nuevo lenguaje de […]

 Cómo monitorear… Los microservicios …

Deja un comentario
Tu dirección de correo electrónico no será publicada. Los campos obligatorios están
marcados con *

Comentario

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD
 Nombre *

Correo
electrónico *

Web

Publicar comentario

2017 eggnews | Eggnews by Theme Egg. Sobre Nosotros Política Contactos Mapa del sitio

Create PDF in your applications with the Pdfcrowd HTML to PDF API PDFCROWD