Traducido al: español Mostrar texto original Opciones ▼

¡Bienvenido Invitado! | Iniciar sesión | Registro

Blog Hojas de trucos Captura Arsenal Caja de instrumento Estante para libros Contáctame

Banderas TCP: PSH y URG

Por estiramiento | Miércoles 2 de marzo de 2011 a las 3:58 am UTC

El encabezado TCP contiene varios campos booleanos de un bit conocidos como indicadores utilizados para influir
en el flujo de datos a través de una conexión TCP. Al ignorar los indicadores CWR y ECE agregados para la
notificación de congestión por RFC 3168 , hay seis indicadores de control TCP. Cuatro de estos, que se enumeran
a continuación, se utilizan para controlar el establecimiento, mantenimiento y desmontaje de una conexión TCP, y
deben ser familiares para cualquiera que haya realizado un análisis de paquetes incluso rudimentario.

SYN - Inicia una conexión

ACK - Reconoce los datos recibidos
FIN - Cierra una conexión
RST - Anula una conexión en respuesta a un error

Las otras dos banderas, PSH (push) y URG (urgente), no son tan conocidas. Son el foco del artículo de hoy.

La bandera de PSH
Para comprender la función del indicador PSH, primero debemos entender cómo TCP almacena los datos. TCP
opera en la capa cuatro del modelo OSI; presenta a las capas superiores un simple zócalo que puede leerse y
escribirse, ocultando las complejidades de las comunicaciones basadas en paquetes. Para permitir que las
aplicaciones lean y escriban en este socket en cualquier momento, los buffers se implementan en ambos lados de
una conexión TCP en ambas direcciones.

El diagrama a continuación muestra cómo los datos son almacenados por el remitente antes de enviarlos y por el
receptor al momento de la recepción.

Los buffers permiten una transferencia de datos más eficiente al enviar más de un tamaño de segmento máximo
(MSS) de datos (por ejemplo, transferir un archivo grande). Sin embargo, los búferes grandes hacen más daño que
beneficio cuando se trata de aplicaciones en tiempo real que requieren que los datos se transmitan lo más rápido
posible. Considere lo que pasaría con una sesión de Telnet, por ejemplo, si TCP esperara hasta que hubiera
suficientes datos para llenar un paquete antes de que se enviara uno: tendría que escribir más de mil caracteres
antes de que el primer paquete llegara al dispositivo remoto. . No es muy útil.

Aquí es donde entra el indicador PSH. La aplicación puede escribir en el socket que TCP hace disponible a nivel
de sesión con la opción de "expulsar" los datos inmediatamente, en lugar de esperar a que ingresen datos
adicionales al búfer. Cuando esto sucede, el indicador PSH en el paquete TCP saliente se establece en 1
(activado). Al recibir un paquete con el conjunto de indicadores PSH, el otro lado de la conexión sabe que debe
reenviar el segmento inmediatamente a la aplicación. Para resumir, la capacidad de inserción de TCP logra dos
cosas:

La aplicación de envío informa a TCP que los datos deben enviarse inmediatamente.
El indicador PSH en el encabezado TCP informa al host receptor que los datos deben enviarse a la
aplicación receptora inmediatamente.

Podemos ver un ejemplo del indicador PSH que se está utilizando en esta captura de paquetes de una solicitud
HTTP GET. En el paquete # 4, vemos que la solicitud HTTP inicial tiene su indicador PSH establecido, lo que indica
que el cliente no tiene más datos para agregar y la solicitud debe enviarse a la aplicación (en este caso, un
demonio web) de inmediato. También vemos que el servidor ha establecido el indicador PSH en el paquete # 36,
que contiene los últimos bytes del archivo solicitado. Nuevamente, el indicador PSH se usa para informar al
receptor que el remitente no tiene más datos para transmitir (por ahora).

Como se mencionó, el indicador PSH también se usa para facilitar la comunicación en tiempo real a través de TCP.
Esta captura de paquetes de una breve sesión de Telnet muestra que todos los paquetes que contienen datos de
Telnet tienen el indicador PSH establecido para evitar que TCP presione en el búfer.

La bandera de URG
El indicador URG se usa para informar a una estación receptora que ciertos datos dentro de un segmento son
urgentes y deben tener prioridad. Si se establece el indicador URG, la estación receptora evalúa el puntero
urgente, un campo de 16 bits en el encabezado TCP. Este puntero indica la cantidad de datos en el segmento,
contando desde el primer byte, es urgente.

El indicador URG no es empleado mucho por los protocolos modernos, pero podemos ver un ejemplo de ello en la
captura de paquetes de Telnet que se mencionó anteriormente. El carácter 0xFF enviado en el paquete # 86
precede al comando Telnet 0xF2 (242) en el paquete # 70 que denota una marca de datos. Según RFC 854 , este
comando debe enviarse con el conjunto de indicadores TCP URG. El puntero urgente en el paquete n. ° 68 indica
que el primer byte del segmento (que en este caso es el segmento completo) debe considerarse como datos
urgentes.

Es cierto que probablemente este no sea el ejemplo más ilustrativo de la bandera de URG, pero fue
sorprendentemente difícil encontrar otros usos en las capturas del mundo real.

Para obtener más información sobre las funciones PSH y URG de TCP, consulte la Guía en línea de TCP / IP .

Sobre el Autor
Jeremy Stretch es un ingeniero de redes que vive en el área de Raleigh-Durham,
Carolina del Norte. Es conocido por su blog y hojas de trucos aquí en Packet Life.
Puede contactarlo por correo electrónico o seguirlo en Twitter .

Publicado en Packet Analysis

Comentarios

CAMBIO Excelente redacción. Sinceramente, no tenía idea de para qué eran URG y
2 marzo 2011 a las 16:51 UTC PSH antes de leer esto.
Sin embargo, tengo una pregunta. ¿Algunas bibliotecas de redes activan
automáticamente el indicador PSH? Recuerdo que en una clase tuvimos
que escribir aplicaciones que hablaban entre sí a través de una conexión
TCP. Cuando un lado envió "FOO" sobre el zócalo, el otro lado obtendría
inmediatamente "FOO", aunque 1) nunca configuré ningún tipo de
indicador PSH y 2) el búfer de transmisión no se llenó.

Sonic (invitado) bien escrito

2 de marzo de 2011 a las 8:06 am UTC ¿Qué tal chuleta en TCP?
En mi humilde opinión, no estoy solo quien lo apreciaría, ¿verdad?
¡Estás haciendo un gran trabajo con este sitio Jeremy!

gracias

stuh84 Siempre me había preguntado qué hacía la bandera de PSH, lo veo mucho
2 de marzo de 2011 a las 8:48 am UTC en las transacciones (chip y pin, sin contacto, etc.) y solo pensé que era el
mensaje que contenía datos. Esto tiene mucho más sentido ahora.

Brannen Good post Stretch - como siempre, bien escrito y documentado, e

2 de marzo de 2011 a las 12:14 pm UTC informativo.

juancarlospaco (invitado) Eso es interesante. ʘ_ʘ paquetes exóticos ...

3 de marzo de 2011 a las 1:51 am UTC

Steve B (invitado) Wow - la guía TCP / IP es un gran recurso. Directo a mi carpeta de

4 de marzo de 2011 a las 5:19 am UTC marcadores útiles de enlaces de red!

Gracias

paulkil Nice Stretch,

4 de marzo de 2011 a las 2:27 pm UTC este es un muy buen seguimiento del último artículo de TCP que escribiste
el año pasado.

Gracias,

Pablo

CJ (invitado) Gracias por el post Stretch. Este blog se ha convertido en uno de mis
4 de marzo de 2011 a las 3:24 pm UTC lugares goto. Usted publica información muy relevante y útil. ¡Seguid así!

Ste (invitado) Buen artículo, y buen sitio también.

5 de marzo de 2011 a las 4:20 pm UTC
Acerca del mecanismo de URG: hay un RFC 6093 recientemente
agregado que actualiza el estándar y desaprueba explícitamente su uso.

Stefano.

mikesm (invitado) Buen artículo, en general - buen sitio, bastante útil.

14 de marzo de 2011 a las 5:12 am UTC
Yo: me gustaría obtener una ilustración de una posible situación en la que
se puede hacer el reconocimiento una vez para un grupo de segmentos
TCP, no para cada segmento por separado. No entiendo cómo puede
suceder esto, dado que la recepción de cada segmento debe confirmarse
por acuse de recibo. Creo que Jeremy puede explicarlo.
Gracias
michael

Ste @ imMute:
. 25 de marzo de 2011 a las 7:02 pm ese comportamiento sugiere que el algoritmo de Nagle fue deshabilitado
UTC. en su socket
Por lo que sé, deshabilitarlo es en realidad la forma correcta de garantizar
la entrega inmediata, ya que cuando está habilitado (y por lo general lo es
por defecto), incluso los datos "enviados" se almacenan temporalmente
durante algún tiempo antes de ser enviados.

exgenoma (invitado) Me interesé en el software que usas para capturar paquetes de datos?
17 de abril de 2012 a las 2:06 pm UTC y por cierto bonito post !! :-)

Bala (invitado) ¡¡Buen post!!

1 de mayo de 2012 a las 4:37 pm UTC
Ejemplo de URG, creo que cuando presionamos Ctrl + C durante una
sesión de telnet, se establecerá el indicador URG !!

Ashok (invitado)
23 de mayo de 2012 a las 3:44 pm UTC
Muy informativo. :) Supongo que cuando dices "El carácter 0xFF enviado
en el paquete # 86 es anterior al comando Telnet 0xF2 (242) en el paquete
# 70 que denota una marca de datos" que realmente quisiste decir "El
carácter 0xFF enviado en el paquete # 86 es anterior a la Telnet comando
0xF2 (242) en el paquete # 88 que denota una marca de datos ", y en lugar
de" El puntero urgente en el paquete # 68 indica "te refieres" El puntero
urgente en el paquete # 86 indica ". Me confundí por un tiempo, por favor
dime si estoy equivocado.

Somya Jain (invitado) Muy buena información sobre PUSH Flag

16 de agosto de 2012 a las 5:04 am UTC

Abhaas Sood (invitado) Hola,

29 de enero de 2013 a las 9:00 am UTC
Soy bastante nuevo en el campo de las redes y después de revisar el
documento anterior. Veo que lo has explicado perfectamente. Sin embargo,
me preguntaba en el paquete que tiene un conjunto de indicadores de
inserción, si observa que también tiene un conjunto de paquetes de
confirmación. Me preguntaba es el bit de reconocimiento establecido. No
puedo comprender en qué paquete se reconoce este paquete. Apreciaría
mucho la ayuda para explicar la consulta.

Gracias y saludos,
Abhaas Sood

Un invitado muy útil

el 21 de marzo de 2013 a las 10:28 pm
UTC
John (invitado)
3 de julio de 2013 a las 3:44 pm UTC
También estoy interesado en lo que Abhaas Sood mencionó. Para nuestro
servicio DDoS administrado, vemos muchas alertas de las fuentes de
Akamai con el conjunto de bits PSH + ACK. Ahora esto es "generalmente"
el tráfico normal, sin embargo, hay un ataque conocido de PSH + ACK
DDoS.

"El ataque PUSH + ACK es similar a un ataque TCP SYN, ya que su

objetivo es agotar los recursos del sistema víctima. Los agentes atacantes
envían paquetes TCP con los bits PUSH y ACK establecidos en uno. Estos
paquetes ordenan al sistema víctima que descargar todos los datos en el
búfer TCP (independientemente de si el búfer está lleno o no) y enviar un
acuse de recibo cuando se complete "

Estoy un poco confundido en cuanto a por qué vacía su búfer si ambos bits
de PSH + ACK están configurados. Esto parece ser lo contrario del
propósito de la bandera PSH. ¿Alguien sabe el mecanismo detrás de esto?

Gaurav (invitado) @John, @Abbas

23 de julio de 2013 a las 7:54 am UTC
My 2c.
No creas que la bandera ACK tiene nada que ver con la bandera AFAIK de
PSH.
TCP ordena que al menos uno de los seis indicadores (SYN ACK FIN RST
PSH URG) debe configurarse. Dado que no es incorrecto enviarlos a
ambos juntos, en realidad no es inválido, pero francamente no es normal.
PSH es suficiente para indicar que los datos del búfer deben enviarse
inmediatamente a la aplicación. Así que la única forma de evitarlo es
decirle al remitente que no envíe estos 2 juntos.
Puede que esté equivocado, pero estoy abierto a que me demuestren que
estoy equivocado.

ami (invitado) La bandera de PSH no está muy claramente definida.

17 de agosto de 2013 a las 2:29 am UTC Descubrí que no es seguro usar PSH para indicar el final de los paquetes

Cuando la ventana TCP se establece en un número más pequeño (por

cualquier razón, enlaces más lentos, fragmentados, etc.), el indicador PSH
se establece aunque hay más paquetes por venir. Esto puede crear
confusión si se usa PSH para indicar que este es el final de una solicitud
(como en HTTP): el host comenzará a responder una solicitud incompleta.

Me parece que el indicador PSH se copia en varios paquetes, ya sea por la

pila tcp del remitente o en algún lugar a lo largo de la ruta.

Todavía es necesario encontrar otra forma FIABLE para identificar el final

de los paquetes.
(Para HTTP hay información de longitud de solicitud, pero esto puede ser
peligroso ya que algunos navegadores no envían la información correcta y,
por cierto, está en la capa de aplicación, no en la capa de TCP)

Javito (invitado) Muy buen post !! Útil ...

26 de octubre de 2013 a las 2:03 pm
UTC ¡Muchas gracias, amigo!

Uday (invitado) Jeremy

2 de enero de 2014 a las 6:45 pm UTC
Gracias por tomarse su tiempo en escribir este excelente blog.

Lo hiciste tan simple.

¡Muchas gracias!

Voy a pasar mucho tiempo leyendo tu blog ...

ProfProtocol (invitado) Stefano,

21 de febrero de 2014 a las 8:58 pm
UTC RFC 6093 es una norma propuesta, aún no es una norma. Así que la
bandera de URG no está en desuso todavía, AFAIK.

freeurmind111 (invitado) Gran artículo ... mantén tu pasión por la informática ... ¡que tengas un buen
13 de marzo de 2014 a las 1:49 pm UTC día! ;RE

Brooke King (invitado) Otro artículo útil entre muchos de los tuyos. Gracias por incluir el enlace a
13 de mayo de 2014 a las 6:50 pm UTC un ejemplo de captura de paquetes. Me gusta el comentario de Ashok
(invitado) el 23 de mayo de 2012 a las 3:44 pm UTC. Iba a escribir algo
parecido, pero ya lo hizo.

maxwell (invitado) ¡Buen trabajo!

31 de mayo de 2014 a las 2:30 am UTC

KC (invitado) Buen post

10 de junio de 2014 a las 5:47 am UTC

Gelashvili (invitado) Muchas gracias!

6 de agosto de 2014 a las 3:47 pm UTC

Aasim (invitado) Como siempre Jeremy, rockeras. Desearía haber podido conocer su sitio
29 de septiembre de 2014 a las 8:26 pm web antes, hubiera sido mucho mejor de lo que soy ahora en Networking.
UTC
¡Te amo hombre! Y muchas gracias por sus explicaciones.

Mayo (invitado) ¡Gracias! Muy útil.

21 de octubre de 2014 a las 4:48 pm
UTC
Upendra (invitado) ¡¡¡Muchas gracias!!!
4 de febrero de 2015 a las 5:33 pm UTC

Josh (invitado) Fantástica explicación! Muy claro y conciso con ejemplos impresionantes.
12 de marzo de 2015 a las 10:34 am ¡Apreciado enormemente!
UTC

Kushal singh (invitado) Buen post. Descrito bien.

12 de marzo de 2015 a las 1:25 pm UTC

Syed (invitado) Doble me gusta !!!

21 de marzo de 2015 a las 9:44 am UTC

Faisal Ibnu Arifin (invitado) Hola,

8 de septiembre de 2015 a la 1:01 pm
UTC Soy bastante nuevo en el campo de las redes y después de revisar el
documento anterior. Veo que lo has explicado perfectamente. Sin embargo,
tengo una pregunta sobre los segmentos TCP.

Host A es un servidor de telnet (¡nunca, nunca use telnet!) Y Host B es un

cliente de telnet. El número de secuencia A-> B TCP es actualmente 231, y
el número B-> A es 748. El usuario escribe el comando "ls" (para enumerar
los contenidos del directorio actual) y presiona Enter. Enumere los
segmentos TCP que se envían en cada dirección como resultado (suponga
que no se pierden), incluidos los números de SEQ y ACK y los datos de
carga útil, suponiendo que el comando ls produce el siguiente resultado:
archivo1 archivo2 archivo3 (seguido de una nueva línea)

Gracias y saludos, Faisal Ibnu Arifin

Un invitado esta página es muy útil para mí

el 9 de noviembre de 2015 a las 3:44 pm
UTC
Rob O (invitado)
6 de enero de 2016 a las 3:48 pm UTC
Hola jeremy
Soy un gran lector de tu blog y me gusta mucho. Espero que sigas leyendo
las reacciones a las publicaciones anteriores, pero tengo una pregunta
sobre la captura que publicaste aquí. Podemos ver que el receptor está
enviando un ACK después de cada segmento. Por qué esta haciendo eso?
¿Normalmente esperaría que hiciera ACK acumulativo? Además, el
tamaño de la ventana no es tan pequeño, ¿por lo que se podrían enviar
más segmentos antes de que el cliente necesite ACTIGIRLO?

Gracias por responder de antemano,

Aclamaciones

Robar

LMD6204 (invitado) Gran explicación con ejemplos! ¡Ojalá fueras mi maestro! ¡Todo lo que
28 de enero de 2016 a las 4:46 pm UTC aprendí en Cisco fue autodidacta ya que mi maestra acaba de leer el
capítulo! Luché por aprender por mi cuenta.

Attila (invitado) Gracias por estas explicaciones informativas. Realmente aprecio estos
18 de marzo de 2016 a las 12:26 pm pequeños 'recordatorios' sobre cosas que escuché hace algún tiempo pero
UTC que poco a poco se fueron desvaneciendo;

RAKESH (invitado) ¡Excelente! Ayuda mucho a entender la importancia de las banderas.

18 de abril de 2016 a las 8:22 pm UTC

soleado (invitado) ¡¡¡buen trabajo!!!

4 de julio de 2016 a las 5:57 am UTC

umarmuqthiyar (invitado) Awe some, Realmente aprendí un gran conocimiento de este artículo ...
22 de julio de 2016 a las 7:10 am UTC Muchas gracias ...

Rajesh Singh (invitado) Buena explicación para la bandera TCP ... Gracias por el buen trabajo
16 de agosto de 2016 a las 6:08 am UTC hecho!

Alois Odhiambo (invitado) ¡Buen post!

6 de octubre de 2016 a las 10:47 am
UTC

Los comentarios se han cerrado para este artículo debido a su antigüedad.

Casa | Blog | Hojas de trucos | Captura | Arsenal | Caja de instrumento | Estante para libros | Contáctame | Acerca de

Mas cosas chulas

networking-forum.com | r / Redes | Internetworkpro | firewall.cx | Ingeniería de redes @ StackExchange