sirven - tcp flags

Diferencia entre banderas push y urgentes en TCP

Question

Estoy tratando de entender la diferencia entre un segmento TCP con la bandera PSH y con la bandera URG . Leí el RFC pero aún no pude obtenerlo, ¿uno de ellos almacena los datos antes de enviarlos al proceso y el otro no?

Answer 1

Añadiendo más información a la ya contestada.

• El bit URG , si se establece, prioriza los datos, lo que significa que, en lugar de esperar a que se transmita todo el flujo de bytes que está por delante de los datos "Urgentes", los datos urgentes se enviarán de manera urgente y no esperarán a que todo el byte Transmisión a transmitir que está por delante de ella.

• Cuando se establece el bit URG se establece el puntero urgente (en el campo Opciones del encabezado TCP : 16 bits).

• El puntero URG indica cuántos bytes de los datos son urgentes en el segmento que ha llegado. (Por ejemplo, si el tamaño de los datos es de 100 bytes y solo es urgente obtener 50 bytes, el puntero urgente tendrá un valor de 50).

• Ahora que viene a la PSH poco. El propósito del bit PSH es decirle a TCP que no espere a que se llene el búfer y enviar los datos inmediatamente. De manera similar, cuando el receptor recibe el segmento con el conjunto de indicadores PSH, debe enviar los datos inmediatamente a la capa superior sin esperar a que se llene el búfer de recepción. El ejemplo práctico de esto es la aplicación de telnet donde la aplicación envía datos en forma de unas pocas pulsaciones de teclas. El telnet se volverá inutilizable si espera a que se llene el búfer y luego transita los datos al receptor.

Answer 2

No aceptaría todo en una RFC con demasiada rigidez, parece que hay cierta ambigüedad sobre la implementación de estas banderas. URG se refiere al envío de paquetes antes de llenar los buffers, mientras que PSH controla el movimiento de datos hacia arriba de la pila en el extremo receptor.

Answer 3

Son dos mecanismos muy diferentes.

PSH y la función PUSH

Cuando envías datos, tu TCP almacena. Entonces, si envías un personaje, no lo enviará de inmediato, pero espera a ver si tienes más. Pero tal vez quiera que vaya directo al cable: aquí es donde entra en juego la función PUSH. Si PULSA datos, su TCP creará inmediatamente un segmento (o algunos segmentos) y los empujará .

Pero la historia no se detiene aquí. Cuando el TCP de igual recibe los datos, naturalmente los almacenará en búfer , no perturbará la aplicación para cada byte . Aquí es donde se PSH indicador PSH . Si un TCP receptor ve el indicador PSH, enviará los datos a la aplicación inmediatamente.

No hay API para establecer la bandera PSH . Normalmente, el kernel lo establece cuando vacía el búfer. Desde TCP / IP Ilustrado:

Este indicador se usa convencionalmente para indicar que el búfer en el lado que envía el paquete se ha vaciado junto con el envío del paquete. En otras palabras, cuando el paquete con el campo de bits PSH dejado el remitente, el remitente no tenía más datos que enviar.

Pero ten en cuenta que Stevens también dice:

Empuje (el receptor debe pasar estos datos a la aplicación lo antes posible, no implementado ni usado de manera confiable )

Datos URG y OOB

TCP es un protocolo orientado a la corriente. Entonces, si presionas 64K bytes en un lado, eventualmente obtendrás 64k bytes en el otro. Así que imagina que ingresas muchos datos y luego tienes un mensaje que dice "¿Sabes todos los datos que acabo de enviar? Sí, tira eso". La esencia del asunto es que una vez que usted presiona los datos en una conexión, tiene que esperar a que el receptor los obtenga todos antes de llegar a los nuevos datos.

Aquí es donde se URG indicador URG . Cuando envía datos urgentes, su TCP crea un segmento especial en el que establece el indicador URG y también el campo del puntero urgente. Esto hace que el TCP receptor reenvíe los datos urgentes en un canal separado a la aplicación (por ejemplo, en Unix, su proceso obtiene un SIGURG ). Esto permite que la aplicación procese los datos fuera de banda¹ .

Como nota al margen, es importante tener en cuenta que los datos urgentes rara vez se usan hoy en día y no se implementan muy bien. Es mucho más fácil usar un canal separado o un enfoque diferente por completo.

¹: RFC 6093 no está de acuerdo con este uso de "fuera de banda" y afirma:

El mecanismo urgente de TCP NO es un mecanismo para enviar datos "fuera de banda": los llamados "datos urgentes" deben entregarse "en línea" al usuario de TCP.

Pero luego sigue admitiendo:

De forma predeterminada, el último byte de "datos urgentes" se entrega "fuera de banda" a la aplicación. Es decir, no se entrega como parte del flujo de datos normal.

Una aplicación debe salir de su camino y especificar, por ejemplo, SO_OOBINLINE para obtener una semántica urgente que SO_OOBINLINE con los estándares.

Si todo esto suena complicado simplemente no use datos urgentes .