Protocolo de control de transmisiónDe Wikipedia, la enciclopedia libre

Para otras aplicaciones, vea TCP (desambiguación)  .

Protocolo de control de transmisión

Estándar

internacional

RFC 675

RFC 793

RFC 1122

RFC 2581

RFC 5681

Desarrollado por Internet Engineering Task Force

Introducido 12 1974

Industria LAN , WAN , Internet

Hardware

compatible

Los teléfonos móviles ,ordenadores

personales ,ordenadores portátiles

El Protocolo de Control de Transmisión ( TCP ) es uno de los principales protocolos de la suite de

protocolo de Internet (IP), y es tan común que todo el conjunto es a menudo llamado TCP / IP . TCP

proporciona fiabilidad , ordenada, sin errores verificado la entrega de una corriente de octetosentre

los programas que se ejecutan en computadoras conectadas a una red de área

local , intranet o Internet . Es reside en la capa de transporte .

Exploradores Web utilizan TCP cuando se conectan a los servidores de la World Wide Web , y se

utiliza para entregar correo electrónico y la transferencia de archivos de un lugar a otro.

Las aplicaciones que no requieren la fiabilidad de una conexión TCP pueden utilizar en su lugar

la conexión Protocolo de datagramas de usuario(UDP), que hace hincapié en la operación de baja

sobrecarga y la reducción de la latencia en lugar de la comprobación de errores y la validación de

entrega.

Suite de protocolo de Internet

Capa de aplicación

DHCP

 

DHCPv6

 

DNS

 

FTP

 

HTTP

 

IMAP

IRC

 

LDAP

 

MGCP

 

NNTP

 

BGP

 

NTP

 

POP

RPC

 

RTP

 

RTSP

 

RIP

 

SIP

 

SMTP

 

SNMP

SOCKS

 

SSH

 

Telnet

 

TLS / SSL

 

XMPP

Más información ...

La capa de transporte

TCP

 

UDP

 

DCCP

 

SCTP

 

RSVP de

Más información ...

Capa de Internet

IP  

IPv4

 

IPv6

 

 

ICMP

 

ICMPv6

 

ECN

 

IGMP

IPsec

 

Más información ...

Capa de enlace

ARP / InARP

 

NDP

 

OSPF

 

Túneles  

L2TP

 

PPP

 

Control de acceso al medio  

Ethernet

DSL

 

ISDN

 

FDDI

 

 

Más información ...

V

 

T

 

E

Contenido

  [ ocultar ] 

1 Origen histórico

2 Función de la red

3 Estructura de un segmento TCP

4 Protocolo de Operación

o 4.1 Establecimiento de la conexión

o 4.2 de terminación Conexión

o 4.3 La utilización de recursos

o 4.4 Transferencia de datos

4.4.1 Transmisión fiable

4.4.2 Detección de errores

4.4.3 Control de flujo

4.4.4 Control de congestión

o 4.5 Tamaño máximo de segmento

o 4,6 reconocimientos selectivos

o 4.7 Ventana de escala

o 4.8 marcas de tiempo TCP

o 4.9 datos fuera de banda

o 4.10 Forzar la entrega de datos

5 Vulnerabilidades

o 5.1 Denegación de servicio

o 5.2 Conexión secuestro

o 5,3 TCP veto

6 puertos TCP

7 Desarrollo

8 TCP sobre redes inalámbricas

9 implementaciones de hardware

10 Depuración

11 Alternativas

12 Checksum cómputo

o 12.1 TCP checksum para IPv4

o 12.2 TCP checksum para IPv6

o 12.3 Checksum descargar

13 Véase también

14 Referencias

15 Lectura adicional

16 Enlaces externos

o 16.1 RFC

o 16.2 Otros

Origen histórico [ editar ]

En mayo de 1974, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) publicó un artículo

titulado " Protocolo para Packet Intercomunicación Network. " [ 1 ] Los autores del artículo, Vint

Cerf y Bob Kahn , describe un protocolo de conexión en red para compartir recursos

con conmutación de paquetes entre los nodos. Un componente central de control de este modelo

fue elPrograma de control de transmisión que incorpora dos enlaces orientados a la conexión y de

datagramas entre hosts servicios. El Programa de Control de Transmisión monolítica más tarde se

dividió en una arquitectura modular que consiste en el Protocolo de control de transmisión en

la capa orientada a la conexión y el Protocolo de Internet en la capa de interconexión (datagrama).El

modelo fue conocido informalmente como TCP / IP , aunque formalmente se llama a partir de ahora

el conjunto de protocolos de Internet .

Función de la red [ edit ]

El protocolo corresponde a la capa de transporte de TCP suite / IP. TCP proporciona un servicio de

comunicación en un nivel intermedio entre un programa de aplicación y el Protocolo de Internet

(IP). Es decir, cuando un programa de aplicación desea enviar una gran cantidad de datos a través

de Internet a través de IP, en lugar de dividir los datos en pedazos IP de tamaño y la emisión de una

serie de peticiones IP, el software puede emitir una única solicitud para TCP y dejar TCP manejar

los detalles de propiedad intelectual.

IP funciona mediante el intercambio de elementos de información llamados paquetes . Un paquete

es una secuencia de octetos (bytes) y consta de una cabecera seguida de un cuerpo . El

encabezado describe la fuente del paquete, el destino y la información de control. El cuerpo contiene

el IP de datos está transmitiendo.

Debido a la congestión de la red, balanceo de carga de tráfico, o cualquier otro comportamiento

impredecible de la red, los paquetes IP pueden perderse , duplicarse, o entregadas fuera de

orden. TCP detecta estos problemas, peticiones de retransmisión de datos perdidos, reorganiza los

datos fuera de orden, e incluso ayuda a minimizar la congestión de la red para reducir la aparición

de los otros problemas. Una vez que el receptor TCP ha vuelto a montar la secuencia de octetos

transmitidos originalmente, los pasa a la aplicación receptora. Por lo tanto, TCP abstrae la

comunicación de la aplicación de los datos de redes subyacentes.

TCP es utilizado ampliamente por muchas de las aplicaciones más populares de Internet, incluyendo

el ancho (WWW) World Web , E-mail , Protocolo de transferencia de archivos , Shell Secure, peer-

to-peer para compartir archivos , y algunos medios de streaming de aplicaciones.

TCP está optimizado para la entrega correcta y no la entrega a tiempo, y por lo tanto, TCP veces

incurre en demoras relativamente largas (del orden de segundos) a la espera de mensajes fuera de

orden o retransmisiones de mensajes perdidos. No es particularmente adecuado para aplicaciones

en tiempo real tales como voz sobre IP . Para este tipo de aplicaciones, protocolos como elProtocolo

de transporte en tiempo real (RTP) que se ejecuta sobre el protocolo de datagramas de

usuario (UDP) se recomiendan en su lugar. [ 2 ]

TCP es un servicio de entrega de flujo confiable que garantice que todos los bytes recibidos serán

idénticos a bytes enviados y en el orden correcto. Dado que la transferencia de paquetes a través de

muchas redes no es fiable, una técnica conocida como acuse de recibo positivo con retransmisión

se utiliza para garantizar la fiabilidad de transferencias de paquetes. Esta técnica fundamental

requiere que el receptor responde con un mensaje de acuse de recibo, ya que recibe los datos. El

emisor mantiene un registro de cada paquete que envía. El remitente también mantiene un

temporizador desde que se envió el paquete, y retransmite un paquete si el temporizador expira

antes de que el mensaje ha sido reconocido. Se necesita el contador de tiempo en caso de que un

paquete se pierde o se daña. [ 2 ]

Mientras IP encarga de la entrega real de los datos, TCP realiza un seguimiento de las unidades

individuales de transmisión de datos, llamado segmentos , que un mensaje se divide en para el

enrutamiento eficiente a través de la red. Por ejemplo, cuando un archivo HTML se envía desde un

servidor web, la capa de software de TCP de servidor que divide la secuencia de octetos del archivo

en segmentos y las envía de forma individual a la capa de software de IP ( Capa de Internet ). La

capa de Internet encapsula cada segmento TCP en un paquete IP mediante la adición de una

cabecera que incluye (entre otros datos) en el destino IP . Cuando el programa cliente en el equipo

de destino que recibe, la capa TCP ( Transport Layer ) reensambla los segmentos individuales y

asegura que están bien ordenados y libres de errores, ya que les corrientes a una solicitud.

Estructura de un segmento TCP [ edit ]

Protocolo de Control de Transmisión acepta datos de un flujo de datos, lo divide en trozos, y añade

una cabecera TCP crear un segmento TCP. El segmento TCP es entonces encapsulado en un

protocolo de Internet (IP) de datagramas, e intercambió con sus compañeros. [ 3 ]

El término de paquetes TCP , aunque a veces se utiliza de manera informal, no está en consonancia

con la terminología actual, en el segmento hace referencia a la TCP Protocol Data Unit

(PDU) , datagramas  [ 4 ] a la PDU IP y el marco de la capa de enlace de datos PDU:

Los procesos de transmisión de datos invocando el TCP y pasando buffers de datos como

argumentos. Los paquetes TCP los datos de estos buffers en segmentos y pide al módulo internet

[por ejemplo IP] para transmitir cada segmento para el TCP de destino. [ 5 ]

Un segmento TCP consiste en un segmento de cabecera y los datos de la sección. La cabecera

TCP contiene 10 campos obligatorios, y un campo de extensión opcional ( Opciones , fondo

anaranjado en la tabla).

La sección de datos sigue al encabezado. Sus contenidos son los datos de carga transportadas para

la aplicación. La longitud de la sección de datos no está especificada en el encabezado de

segmento TCP. Se puede calcular restando la longitud combinada de la cabecera TCP y la cabecera

IP encapsulada de la longitud total del datagrama IP (especificado en la cabecera IP).

Puerto de origen (16 bits)

Identifica el puerto de envío

Puerto de destino (16 bits)

Identifica el puerto receptor

Número de secuencia (32 bits)

Tiene una doble función:

Si el SYN se fija la bandera (1), entonces este es el número de secuencia inicial. El número de

secuencia del primer byte de datos real y el número reconocido en el correspondiente ACK son

entonces este número de secuencia más 1.

Si el SYN bandera es clara (0), entonces este es el número de secuencia acumulado del primer

byte de datos de este segmento de la sesión actual.

Número de reconocimiento (32 bits)

Si el ACK indicador se establece a continuación, el valor de este campo es el siguiente número de

secuencia que el receptor está esperando. Esto confirma la recepción de todos los bytes anteriores

(si los hay). La primera ACK enviado por cada extremo reconoce inicial en sí número de secuencia

del otro extremo, pero no hay datos.

Compensación de datos (4 bits)

Epecifica el tamaño de la cabecera TCP en palabras de 32 bits. El encabezado de tamaño mínimo

es de 5 palabras, y el máximo es de 15 palabras, dando así el tamaño mínimo de 20 bytes y un

máximo de 60 bytes, lo que permite un máximo de 40 bytes de opciones en la cabecera. Este

campo toma su nombre del hecho de que también es el desplazamiento desde el inicio del

segmento TCP a los datos reales.

Reservado (3 bits)

Para uso futuro y se debe establecer en cero

Banderas (9 bits) (bits de control aka)

Contiene 9 banderas de 1 bit

NS (1 bit) - Protección ocultamiento ECN-nonce (añadido a la cabecera por RFC 3540 ).

CWR (1 bit) - Congestion Window Reduced (CWR) esté establecido por el envío de acogida para

indicar que se ha recibido un segmento TCP con el ECE set bandera y había respondido en el

mecanismo de control de congestión (añadido a la cabecera por RFC 3168 ).

ECE (1 bit) - ECN-Echo indica

Si el SYN se fija la bandera (1), que el par es TCP ECN capaz.

Si el SYN bandera es clara (0), que se recibe un paquete con marca de congestión con

experiencia en conjunto encabezado IP durante la transmisión normal (añadido a la cabecera

por RFC 3168 ).

URG (1 bit) - indica que el campo puntero urgente es significativa

ACK (1 bit) - indica que el campo de reconocimiento es significativo. Todos los paquetes después

de la inicial de SYN paquete enviado por el cliente deben tener esta bandera.

PSH (1 bit) - Función Push. Pide a insertar los datos almacenados en el búfer de la aplicación

receptora.

RST (1 bit) - Restablecer la conexión

SYN (1 bit) - Sincronizar números de secuencia. Sólo el primer paquete enviado desde cada

extremo debe tener esta bandera. Algunas otras banderas cambian de significado sobre la base de

este indicador, y algunos sólo son válidas para cuando se establece, entre otros, cuando es

evidente.

FIN (1 bit) - No hay más datos de remitente

Tamaño de la ventana (16 bits)

El tamaño de la ventana de recepción , que especifica el número de unidades de tamaño de la

ventana (por defecto, bytes) (más allá del número de orden en el campo de reconocimiento) que el

emisor de este segmento está dispuesto a recibir ( véase Control de flujo y Window Scaling )

Suma de comprobación (16 bits)

El de 16 bits checksum campo se utiliza para la comprobación de errores de la cabecera y los datos

Puntero urgente (16 bits)

Si el URG indicador se establece, a continuación, este campo de 16 bits es un desplazamiento desde

el número de secuencia que indica el último byte de datos urgente

Opciones (variable 0-320 bits, divisibles por 32)

La longitud de este campo se determina por el campo de desplazamiento de datos. Las opciones

tienen un máximo de tres campos: Opción de Póquer (1 byte), Opción-Longitud (1 byte), Opción-

Data (variable). El campo Opción-Tipo indica el tipo de opción, y es el único campo que no es

opcional. Dependiendo de qué tipo de opción que nos ocupa, se pueden establecer las siguientes

dos campos: el campo Opción y Longitud indica la longitud total de la opción y el campo Opción de

datos contiene el valor de la opción, si procede. Por ejemplo, un byte Opción Tipo de 0x01 indica

que se trata de una opción de No-Op utilizado sólo para el relleno, y no tiene una opción de longitud

u Opción-Data byte le sigue. Un byte Opción-Kind of 0 es la opción Fin Opciones de, y está a sólo

un byte. Un byte de Tipo de Opción-0x02 indica que esta es la opción tamaño máximo del

segmento, y será seguido por un byte que especifica la longitud del campo de MSS (debe ser

0x04). Tenga en cuenta que esta longitud es la longitud total del campo de opciones dado,

incluyendo la opción-Kind and bytes Opción de longitud. Así, mientras que el valor MSS se expresa

típicamente en dos bytes, la longitud del campo será de 4 bytes (2 bytes de tipo y longitud). En

resumen, un campo de opción MSS con un valor de 0x05B4 se mostrará como (0x02 0x04 0x05B4)

en la sección de opciones de TCP.

Algunas opciones sólo se pueden enviar al SYN se fija, sino que se indican a continuación

como [SYN] . Opción Tipo y longitudes estándar dados como (Opción-Kind, Opción de longitud).

0 (8 bits) - Fin de la lista de opciones

1 (8 bits) - Ninguna operación (NOP, Relleno) Esto puede ser utilizado para alinear los

campos de opciones en los límites de 32 bits para un mejor rendimiento.

2,4, SS (32 bits) - tamaño de segmento máximo ( véase el  tamaño máximo de

segmento ) [SYN]

3,3, S (24 bits) - Escala de ventana ( ver el ajuste de ventanas para los

detalles ) [SYN] [ 6 ]

4.2 (16 bits) - Reconocimiento Selectivo permitido. [SYN] ( Ver reconocimientos

selectivos para más detalles ) [ 7 ]

5, N, BBBB, EEEE, ... (bits variable, N es o bien 10, 18, 26, o 34) - confirmación

selectiva (SACK) [ 8 ] Estos dos primeros bytes son seguidos por una lista de 1-4

bloques ser reconocido selectivamente, especificado como 32 bits Begin / End

punteros.

8,10, TTTT, EEEE (80 bits) - Marca de tiempo y el eco de la marca de tiempo anterior

( ver marcas de tiempo TCP para más detalles ) [ 9 ]

14,3, S (24 bits) -. TCP Solicitud Checksum alternativo [SYN] [ 10 ]

15, N, ... (bits variables) - TCP alternativo de datos de suma de comprobación.

(Las opciones restantes son obsoletos, experimental, aún no normalizada o no asignado)

Relleno

El encabezado TCP relleno se utiliza para garantizar que los extremos de cabecera y los datos TCP

comienza en un límite de 32 bits. El relleno se compone de ceros. [ 11 ]

Protocolo de funcionamiento [ edit ]

Operaciones de protocolo TCP se pueden dividir en tres fases. Las conexiones deben establecerse

adecuadamente en un proceso de negociación de varios pasos ( establecimiento de conexión )

antes de entrar en la transferencia de datos de fase. Después de que se complete la transmisión de

datos, la finalización de la conexión se cierra circuitos virtuales establecidos y libera todos los

recursos asignados.

Una conexión TCP está gestionado por un sistema operativo a través de una interfaz de

programación que representa el punto final local para las comunicaciones, la toma de

Internet . Durante la vida de una conexión TCP el punto final local, se somete a una serie

de estados cambios: [ 12 ]

ESCUCHAR 

(Servidor) representa la espera de una petición de conexión de cualquier TCP remoto y el puerto.

SYN-SENT 

(Cliente) representa la espera de una petición de conexión a juego después de haber enviado una

solicitud de conexión.

SYN-RECEIVED 

(Servidor) representa la espera de una conexión de solicitud de acuse de recibo que confirma

después de tener ambos recibieron y enviaron una petición de conexión.

ESTABLECIDO 

(Tanto en el servidor y el cliente) representa una conexión abierta, los datos recibidos pueden ser

entregadas al usuario. El estado normal para la fase de transferencia de datos de la conexión.

FIN-WAIT-1 

(Servidor y cliente) representa la espera de una solicitud de finalización de conexión del TCP

remoto, o un acuse de recibo de la solicitud de finalización de conexión enviada previamente.

FIN-WAIT-2 

(Servidor y cliente) representa la espera de una solicitud de finalización de conexión del TCP

remoto.

CLOSE-WAIT 

(Servidor y cliente) representa la espera de una solicitud de finalización de conexión del usuario

local.

CIERRE 

(Servidor y cliente) representa la espera de una conexión de terminación solicitud de reconocimiento

del TCP remoto.

LAST-ACK 

(Servidor y cliente) representa a la espera de un acuse de recibo de la solicitud de finalización de

conexión enviada anteriormente al TCP remoto (que incluye un reconocimiento de su solicitud de

finalización).

TIME-WAIT 

(Servidor o cliente) representa la espera de tiempo para pasar a estar seguro de que el TCP remoto

ha recibido el acuse de recibo de su solicitud de finalización. [De acuerdo con RFC 793una conexión

puede permanecer en TIME-WAIT durante un máximo de cuatro minutos conocidos

como MSL (duración máxima del segmento).]

CERRADO 

(Servidor y cliente) no representa el estado de conexión en absoluto.

Establecimiento de la conexión [ edit ]

Para establecer una conexión, TCP utiliza una de tres vías apretón de manos . Antes de que un

cliente intenta conectar con un servidor, el servidor debe primero unirse y escuchar en un puerto a

abrir para las conexiones: esto se llama una apertura pasiva. Una vez que se establece la apertura

pasiva, un cliente puede iniciar una sesión abierta. Para establecer una conexión, de tres vías (o 3

pasos) apretón de manos se produce:

1. SYN : El abierto activo se lleva a cabo por el cliente que envía un SYN al servidor. El cliente

establece el número de secuencia del segmento a un valor al azar A.

2. SYN-ACK : En respuesta, el servidor responde con un SYN-ACK. El número de acuse de

recibo se fija a uno más que el número de secuencia recibido es decir, A 1, y el número de

secuencia que el servidor elige para el paquete es otro número aleatorio, B.

3. ACK : Por último, el cliente envía un ACK de vuelta al servidor. El número de secuencia se

establece en el valor recibido acuse de recibo es decir, A 1, y el número de acuse de recibo se

fija a uno más que el número de secuencia recibido es decir, B 1.

En este punto, el cliente y el servidor han recibido un reconocimiento de la conexión. Los pasos

1 y 2 establecen el parámetro de conexión (número de secuencia) en una dirección y se

reconoce. Los pasos 2 y 3 establecen el parámetro de conexión (número de secuencia) en la

otra dirección y se reconoce. Con esto, se establece una comunicación full-duplex.

Terminación Conexión [ edit ]

La fase de finalización de conexión utiliza una de cuatro vías apretón de manos , con cada lado de

la conexión de terminación de forma independiente. Cuando un punto final quiere detener su medio

de la conexión, transmite un paquete FIN, que reconoce el otro extremo con un ACK. Por lo tanto,

un típico desmontaje requiere un par de segmentos FIN y ACK desde cada extremo TCP. Después

de que se llegó a la conclusión tanto FIN / ACK intercambios, el lado que envía la primera aleta

antes de recibir una espera a un tiempo de espera antes de que finalmente el cierre de la conexión,

tiempo durante el cual el puerto local no está disponible para nuevas conexiones, lo que evita la

confusión debido a paquetes retardados se entregan durante las conexiones posteriores.

Una conexión puede ser "medio-abierto" , en cuyo caso uno de los lados ha terminado su extremo,

pero el otro no tiene. La parte que ha terminado ya no puede enviar los datos al respecto, pero la

otra parte puede. El lado de terminación debe continuar la lectura de los datos hasta el otro lado

termina también.

También es posible poner fin a la conexión de un apretón de manos de 3 vías, cuando el host A

envía un FIN y respuestas B de acogida con un FIN y ACK (sólo combina 2 pasos en uno) y el host

A responde con un ACK. [ 13 ] Este es quizás el método más común.

Es posible que ambos hosts para enviar las FIN simultáneamente, tanto sólo hay que ACK. Esto

podría ser considerado como un 2-way handshake ya que la secuencia / ACK FIN se hace en

paralelo en ambos sentidos.

Algunas pilas TCP huésped pueden implementar una secuencia de cierre half-duplex,

como Linux o HP-UX hacer. Si tal acogida cierra una conexión activa, pero aún no ha leído todos los

datos de entrada de la pila ya recibió del enlace, este host envía un RST en lugar de un FIN

(Sección 4.2.2.13 en RFC 1122 ). Esto permite a una aplicación TCP para asegurarse de que la

aplicación remota ha leído todos los datos de la ex enviado de honor el FIN del lado opuesto,

cuando se cierra la conexión activa. Pero la pila TCP remoto no puede distinguir entre un Abortando

RST conexión y RST pérdida de datos . Tanto porque la pila a distancia para perder todos los datos

recibidos.

Algunos protocolos de aplicación pueden violar las capas del modelo OSI , utilizando el TCP de

apertura / cierre de enlace para el protocolo de aplicación de apertura / cierre apretón de manos -

esto puede encontrar el problema RST de cierre activo. Como un ejemplo:

s = connect (a distancia);

enviar (s, datos);

cerrar (s);

Para un flujo de programa habitual como la de arriba, una pila TCP / IP como el descrito

anteriormente no garantiza que todos los datos que llegan a la otra aplicación.

El uso de recursos [ edit ]

La mayoría de las implementaciones de asignar una entrada en una tabla que asigna una sesión en

un proceso del sistema operativo que se ejecuta. Debido a los paquetes TCP no incluyen un

identificador de sesión, ambos extremos identificar la sesión con la dirección y el puerto del

cliente. Cada vez que se recibe un paquete, la aplicación TCP debe realizar una búsqueda en esta

tabla para encontrar el proceso de destino. Cada entrada en la tabla se conoce como un bloque de

control de transmisión o TCB. Contiene información acerca de los puntos finales (IP y puerto), el

estado de la conexión, corriendo datos sobre los paquetes que se intercambian y tampones para

enviar y recibir datos.

El número de sesiones en el lado del servidor está limitado sólo por la memoria y puede crecer

como nuevas conexiones llegan, pero el cliente debe asignar un puerto aleatorio antes de enviar la

primera SYN al servidor. Este puerto permanece asignada durante toda la conversación, y

efectivamente limita el número de conexiones de salida de cada una de las direcciones IP del

cliente.Si una aplicación no se cierra correctamente conexiones sin contrapartida, el cliente puede

quedarse sin recursos y se vuelven incapaces de establecer nuevas conexiones TCP, incluso desde

otras aplicaciones.

Ambos extremos deben asignar espacio para los paquetes no reconocidos y recibidos (pero no

leídos) de datos.

Transferencia de datos [ edit ]

Hay algunas características clave que marcan TCP aparte de User Datagram Protocol :

Pedido de transferencia de datos - el host de destino reorganiza según el número de

secuencia [ 2 ]

Retransmisión de paquetes perdidos - cualquier corriente acumulado no reconoció se

retransmite [ 2 ]

Libre de errores de transferencia de datos [ 14 ]

Control de flujo - limita la velocidad de un remitente transfiere datos para garantizar la entrega

segura. El receptor insinúa continuamente el remitente en la cantidad de datos se pueden recibir

(controlado por la ventana deslizante). Cuando el búfer del host receptor se llena, el siguiente

acuse de recibo contiene un 0 en el tamaño de la ventana, para detener la transferencia y permitir

que los datos en la memoria intermedia a ser procesados. [ 2 ]

Control de congestión [ 2 ]

Transmisión fiable [ edit ]

TCP utiliza un número de secuencia para identificar cada byte de datos. El número de secuencia

identifica el orden de los bytes enviados desde cada ordenador de manera que los datos pueden ser

reconstruidos en orden, independientemente de cualquier fragmentación, desorden, o la pérdida de

paquetes que pueden producirse durante la transmisión. Para cada byte de carga útil transmitida, el

número de secuencia debe ser incrementado. En los dos primeros pasos del 3-way handshake,

ambos equipos intercambian un número de secuencia inicial (ISN). Este número puede ser arbitrario

y, de hecho, debería ser impredecibles para defenderse de los ataques de predicción de secuencia

TCP .

TCP utiliza principalmente un acuse de recibo acumulativo esquema, donde el receptor envía un

acuse de recibo que significa que el receptor ha recibido todos los datos que preceden al número de

secuencia reconocido. El remitente establece el campo de número de secuencia para el número de

secuencia del primer byte de carga útil en el campo de datos del segmento, y el receptor envía un

acuse de recibo que especifica el número de secuencia del siguiente byte que esperan recibir. Por

ejemplo, si un equipo emisor envía un paquete que contiene cuatro octetos de carga útil con un

campo de número de secuencia de 100, a continuación, los números de secuencia de los cuatro

bytes de carga útil son 100, 101, 102 y 103. Cuando este paquete llega al equipo receptor, sería

devolver un número de confirmación de 104 ya que es el número de secuencia del próximo byte que

espera recibir en el próximo paquete.

Además de reconocimientos acumulados, los receptores TCP pueden enviar confirmaciones

selectivas para proporcionar más información.

Si el remitente deduce de ello que se han perdido datos en la red, que retransmite los datos.

Detección de errores [ edit ]

Los números de secuencia permiten a los receptores a descartar paquetes duplicados y paquetes

reordenados correctamente secuencia. Agradecimientos permiten a los remitentes que determinan

cuándo retransmitir paquetes perdidos.

Para asegurar un correcto checksum campo se incluye ( ver estructura de segmentos TCP para

obtener detalles sobre la suma de comprobación ). La suma de comprobación TCP es una

comprobación débil para los estándares modernos. Datos Enlace capas con alta tasa de errores de

bit pueden requerir capacidades de corrección / detección de errores de enlace adicionales.La suma

de comprobación débil está parcialmente compensado por el uso común de un CRC o mejor

comprobación de integridad en la capa 2 , por debajo de los protocolos TCP e IP, tal como se utiliza

en PPP o la Ethernet marco. Sin embargo, esto no significa que el 16-bit de suma de comprobación

TCP es redundante: notablemente, la introducción de errores en los paquetes entre lúpulo CRC-

protegido es común, pero el extremo-a-extremo 16 bits suma de comprobación TCP atrapa la

mayoría de estos errores simples. [ 15 ] Este es el principio de extremo a extremo en el trabajo.

El control de flujo [ edit ]

TCP utiliza un extremo a extremo de control de flujo del protocolo para evitar que el remitente envíe

datos demasiado rápido para que el receptor TCP para recibir y procesar de forma fiable. Tener un

mecanismo de control de flujo es esencial en un entorno donde las máquinas de diversas

velocidades de la red se comunican. Por ejemplo, si un PC envía datos a un teléfono inteligente que

procesa de forma poco a poco los datos recibidos, el teléfono inteligente debe regular el flujo de

datos a fin de no ser abrumado. [ 2 ]

TCP utiliza una ventana deslizante de protocolo de control de flujo. En cada segmento TCP, el

receptor especifica en la ventana de recepción campo de la cantidad de datos, además, recibidos

(en bytes) que está dispuesto para amortiguar para la conexión. El host emisor sólo puede enviar

hasta esa cantidad de datos antes de que se debe esperar a que un reconocimiento y actualización

de la ventana del host receptor.

Cuando un receptor anuncia un tamaño de ventana de 0, el emisor se detiene el envío de datos y se

inicia el temporizador de persistir . El temporizador de persistir se utiliza para proteger TCP desde

un punto muerto situación que podría surgir si una actualización del tamaño de la ventana posterior

del receptor se pierde, y el remitente no puede enviar más datos hasta recibir una nueva

actualización del tamaño de la ventana del receptor. Cuando expira el temporizador de persistir, el

emisor TCP intenta recuperación mediante el envío de un pequeño paquete de manera que el

receptor responde mediante el envío de otro acuse de recibo que contiene el nuevo tamaño de la

ventana.

Si el receptor está procesando los datos entrantes en pequeños incrementos, puede anunciar

repetidamente una ventana de recepción pequeña.Esto se conoce como el síndrome de ventana

tonto , ya que es ineficiente para enviar sólo unos pocos bytes de datos en un segmento TCP, dada

la relativamente gran sobrecarga de la cabecera TCP.

Congestion Control [ edit ]

El principal aspecto final del TCP es el control de congestión . TCP utiliza una serie de mecanismos

para lograr un alto rendimiento y evitar la congestión del colapso , donde el rendimiento de la red

puede caer en varios órdenes de magnitud. Estos mecanismos de control de la tasa de datos que

entran en la red, manteniendo el flujo de datos por debajo de una tasa que daría lugar a

colapso. También producen un aproximadomax-min justa distribución entre los flujos.

Reconocimientos para los datos enviados o falta de reconocimientos, son utilizados por los

remitentes para inferir las condiciones de red entre el emisor y el receptor TCP. Junto con

contadores de tiempo, los remitentes y receptores TCP pueden alterar el comportamiento del flujo

de datos.Esto se conoce más generalmente como control de la congestión y / o evitación de la

congestión de la red.

Las implementaciones modernas de TCP contienen cuatro algoritmos entrelazados: Slow-

start , evitar la congestión , retransmisión rápida yrecuperación rápida ( RFC 5681 ).

Además, los remitentes emplean un tiempo de retransmisión (RTO) que se basa en la estimación

de tiempo de ida y vuelta (o RTT) entre el emisor y el receptor, así como la varianza en este tiempo

de ida y vuelta. El comportamiento de este temporizador se especifica en el RFC 6298 . Hay

sutilezas en la estimación de RTT. Por ejemplo, los remitentes deben tener cuidado al calcular

muestras RTT de paquetes retransmitidos, por lo general utilizan el algoritmo de Karn o marcas de

tiempo TCP (ver RFC 1323 ). Estas muestras de RTT individuales se promedian en el tiempo para

crear una suavizada Round Trip Time (SRTT) utilizando Jacobson algoritmo 's. Este valor SRTT es

lo que se utiliza finalmente como la estimación del tiempo de ida y vuelta.

Mejora de TCP para manejar confiablemente pérdida, minimizar errores, administrar la congestión y

va muy rápido en entornos de alta velocidad son las áreas actuales de investigación y desarrollo de

normas. Como resultado, hay una serie de algoritmo de evitación de congestión TCP variaciones.

Tamaño máximo del segmento [ edit ]

El tamaño máximo de segmento (MSS) es la mayor cantidad de datos, en bytes, que TCP está

dispuesto a recibir en un solo segmento. Para un mejor rendimiento, el SMS debe ser lo

suficientemente pequeño como para evitar la fragmentación de IP , que puede conducir a la pérdida

de paquetes y retransmisiones excesivos. Para tratar de lograr esto, típicamente el SMS es

anunciado por cada lado usando la opción SMS cuando se establece la conexión TCP, en cuyo caso

se deriva de la unidad de transmisión máxima (MTU) de la capa de enlace de datos de las redes a

las que el remitente y el receptor están conectados directamente. Además, los remitentes TCP

pueden utilizar Path MTU Discovery para inferir la MTU mínima a lo largo de la ruta de red entre el

emisor y el receptor, y utilizar esta opción para ajustar dinámicamente el MSS para evitar la

fragmentación IP dentro de la red ..

MSS anuncio también se conoce como "MSS negociación". Estrictamente hablando, el SMS no se

"negocia" entre el iniciador y el receptor, porque eso implicaría que tanto emisor y el receptor va a

negociar y acordar un único SMS unificado que se aplica a todas las comunicaciones en ambos

sentidos de la conexión. De hecho, se permiten dos valores totalmente independientes de SMS para

las dos direcciones de flujo de datos en una conexión TCP. [ 16 ] Esta situación puede surgir, por

ejemplo, si uno de los dispositivos que participan en una conexión tiene una cantidad

extremadamente limitada de memoria reservada (tal vez incluso más pequeño que la MTU de la ruta

descubierta en total) para el procesamiento de segmentos TCP entrantes.

Reconocimientos selectivos [ edit ]

Basándose únicamente en el esquema de reconocimiento acumulada empleado por el protocolo

original TCP puede conducir a ineficiencias cuando se pierden paquetes. Por ejemplo, supongamos

que 10.000 bytes son enviados en 10 paquetes TCP diferentes, y el primer paquete se pierde

durante la transmisión. En un protocolo de reconocimiento acumulada puro, el receptor no puede

decir que ha recibido bytes 1000 a 9999 con éxito, pero no recibió el primer paquete, que contiene

bytes 0 a 999. Así, el emisor puede entonces volver a enviar los 10.000 bytes.

Para resolver este problema TCP emplea el reconocimiento selectivo (SACK) opción, se define en

el RFC 2018 , lo que permite que el receptor reconozca bloques discontinuos de paquetes que se

recibieron correctamente, además del número de secuencia del último byte contigua recibido

sucesivamente, como en la confirmación TCP básica. El reconocimiento puede especificar un

número de bloques SACK , donde cada bloque SACK es transportada por los números iniciales y

finales de la secuencia de un rango contiguo de que el receptor ha recibido correctamente.En el

ejemplo anterior, el receptor enviará saco con números de secuencia 1000 y 9999. El remitente

retransmite por lo tanto sólo el primer paquete, los bytes 0 a 999.

Una extensión de la opción SACK es la opción duplicado-SACK, se define en el RFC 2883 . Una

entrega de paquetes fuera de orden puede a menudo erróneamente indicar el TCP remitente del

paquete perdido y, a su vez, el emisor TCP retransmite el paquete sospechoso-a-ser-perdidas y

retrasar la entrega de datos para evitar la congestión de la red. El remitente TCP deshace la acción

de desaceleración, es una recuperación del ritmo original de la transmisión de datos, al recibir una

D-SACK que indica el paquete retransmitido es duplicado.

La opción SACK no es obligatoria y sólo se utiliza si ambas partes apoyan. Esto se negocia cuando

se establece la conexión. SACK utiliza la parte opcional de la cabecera TCP ( ver estructura de

segmentos TCP para más detalles ). El uso de SACK es generalizada - todas las pilas TCP

populares apoyan. Recepción selectiva también se utiliza en corriente Protocolo de Control de

Transmisión (SCTP).

Ventana de escala [ edit ]

Artículo principal: opción de escala de ventana TCP

Para un uso más eficiente de las redes de gran ancho de banda, se puede usar un mayor tamaño de

la ventana TCP. El campo de tamaño de la ventana TCP controla el flujo de datos y su valor se

limita a entre 2 y 65535 bytes.

Desde el campo de tamaño no puede ser expandido, se utiliza un factor de escala. La opción de

escala de ventana TCP , tal como se define en el RFC 1323 , es una opción que se utiliza para

aumentar el tamaño máximo de ventana de 65.535 bytes a 1 gigabyte. La ampliación a mayor

tamaño de la ventana es una parte de lo que es necesario para la optimización TCP .

La opción de escala de ventana se utiliza sólo durante el 3-way handshake TCP. El valor de escala

de ventana representa el número de bits de desplazamiento a la izquierda del campo de tamaño de

ventana de 16 bits. El valor de escala de ventana se puede ajustar entre 0 (sin cambio) a 14 para

cada dirección de forma independiente. Ambos lados deben enviar la opción en sus segmentos SYN

para permitir el escalado de ventanas en cualquier dirección.

Algunos routers y firewalls de paquetes reescribir el factor de escala de ventana durante una

transmisión. Esto hace que el envío y la recepción de las partes a asumir diferentes tamaños de

ventana TCP. El resultado es el tráfico no estable que puede ser muy lenta. El problema es visible

en algunos sitios de envío y recepción detrás de la trayectoria de los routers defectuosos. [ 17 ]

Marcas de tiempo TCP [ edit ]

Marcas de tiempo TCP, que se define en RFC 1323 , puede ayudar a determinar TCP en el que se

envían los paquetes pedidos. Marcas de tiempo TCP normalmente no se alinean con el reloj del

sistema y empezar en algún valor aleatorio. Muchos sistemas operativos se incrementará la marca

de tiempo para cada milésima de segundo transcurrido, sin embargo, el RFC sólo establece que las

garrapatas deben ser proporcionales.

Hay dos campos de fecha y hora:

un valor de marca de tiempo del remitente de 4 bytes (mi marca de

tiempo)

un valor de marca de tiempo de respuesta de eco de 4 bytes (la más

reciente marca de tiempo recibida de usted).

Marcas de tiempo TCP se utilizan en un algoritmo conocido como Protección contra secuencia

ajustados números o PAWS (véase el RFC 1323 para más detalles). PAWS se utiliza cuando el

tamaño de la ventana TCP supera los números posibles de números de secuencia 2 ( 32 ). En el

caso de que un paquete era potencialmente retransmitidas responde a la pregunta: "¿Es este el

número de secuencia en los primeros 4 GB o el segundo?" Y la marca de tiempo se utiliza para

romper el empate.

RFC 1323 indica incorrectamente en la sección 2.3 que la escala de la ventana debe ser limitado a

2 30 a permanecer menos de 1 GB (lo cual es correcto, pero el límite de número de secuencia es de

4 GB), pero una escala de 16 y un tamaño de ventana de 65.535 sería 65.536 menos de los

2 32 posibles números de secuencia y por lo tanto un valor aceptable aún excesivo.Debido a este

error muchos sistemas que reducen el alcance máximo a 2 14 a "seguir el RFC". [ cita requerida ]

Además, el algoritmo de detección de Eifel ( RFC 3522 ) utiliza marcas de tiempo TCP para

determinar si las retransmisiones están ocurriendo porque los paquetes se pierden o simplemente

fuera de orden.

Fuera de datos de banda [ editar ]

Uno de ellos es capaz de interrumpir o cancelar el flujo en cola en lugar de esperar a que la

corriente hasta el final. Esto se realiza mediante la especificación de los datos como urgente . Esto

le dice al programa receptor para procesar de inmediato, junto con el resto de los datos

urgentes. Cuando haya terminado, TCP informa a la aplicación y vuelve de nuevo a la cola de

corriente. Un ejemplo es cuando TCP se utiliza para una sesión remota, el usuario puede enviar una

secuencia de teclas que interrumpe o cancela el programa en el otro extremo. Estas señales son a

menudo necesarias cuando un programa en el equipo remoto no funciona correctamente. Las

señales deben ser enviados sin esperar a que el programa termine su transferencia actual. [ 2 ]

Datos TCP OOB no está diseñado para la Internet moderna. La urgente puntero sólo altera el

procesamiento en el host remoto y no acelera cualquier proceso en la propia red. Cuando se llega a

la máquina remota, hay dos interpretaciones ligeramente diferentes del protocolo, lo que significa

sólo bytes individuales de datos OOB son fiables. Esto es suponiendo que es fiable en absoluto, ya

que es uno de los elementos de protocolo utilizadas menos comúnmente y tiende a ser mal

aplicado. [ 18 ] [ 19 ]

Obligar a la entrega de datos [ edit ]

Normalmente, TCP espera 200 ms o para un paquete completo de datos a enviar (= Algoritmo de

Nagle intenta agrupar mensajes pequeños en un solo paquete). Esto crea retrasos menores, pero

potencialmente grave si se repite constantemente durante una transferencia de archivos. Por

ejemplo, un bloque de envío típico sería de 4 KB, un MSS típico es 1460, por lo que 2 paquetes

salen en una Mbit / s Ethernet 10 tomando ~ 1.2 ms cada una seguida por una tercera que lleva el

resto de 1176 después de una pausa de 197 ms como TCP es la espera de una memoria intermedia

completa.

En el caso de telnet, cada golpe de teclado del usuario se refleja de nuevo en el servidor antes de

que el usuario pueda ver en la pantalla. Este retraso podría llegar a ser muy molesto.

Ajuste del socket opción TCP_NODELAY reemplaza el valor predeterminado de 200 ms de retardo

de envío. Los programas de aplicación utilizan esta opción de socket para forzar la salida para ser

enviado después de escribir un carácter o una línea de caracteres.

El RFC define el PSH poco empuje como "un mensaje a la pila TCP receptor para enviar esta

información inmediatamente a la aplicación receptora". [ 2 ] No hay forma de indicar o controlar que

en el espacio de usuario usando sockets de Berkeley y es controlado por pila

Protocolo solamente. [ 20 ]

Vulnerabilidades [ edit ]

TCP puede ser atacado en una variedad de maneras. Los resultados de una evaluación de

seguridad completa de TCP, junto con las posibles medidas de mitigación para los problemas

identificados, fueron publicados en 2009, [ 21 ] y en la actualidad se persiguen dentro de la IETF . [ 22 ]

Denegación de servicio [ edit ]

Mediante el uso de una IP falsa dirección y el envío repetido a propósito reunidos paquetes SYN,

seguido de muchos paquetes ACK, los atacantes pueden hacer que el servidor de consumir grandes

cantidades de recursos de mantenimiento de la pista de las conexiones fraudulentas. Esto se

conoce como una inundación SYN ataque. Propuestas de solución a este problema sonlos cookies y

puzzles criptográficos, aunque los cookies vienen con su propio conjunto de

vulnerabilidades. [ 23 ] Sockstress es un ataque similar, que puede ser mitigado con la gestión de los

recursos del sistema. [ 24 ] Un ataque DoS avanzada que hace explotación del TCP Persistir Timer se

analizó en Phrack # 66. [ 25 ]

Conexión secuestro [ edit ]

Artículo principal: ataque predicción de secuencia TCP

Un atacante que es capaz de interceptar una sesión TCP y redirigir los paquetes puede secuestrar

una conexión TCP. Para ello, el atacante aprende el número de secuencia de la comunicación

continua y forja un segmento falso que se parece al siguiente segmento de la ruta. Tal una simple

secuestro puede resultar en un paquete que se está aceptado erróneamente en un extremo.Cuando

el host receptor reconoce el segmento extra para el otro lado de la conexión, se pierde la

sincronización. Secuestro podría ser combinado con ARP o ataques de enrutamiento que permiten

tomar el control del flujo de paquetes, con el fin de obtener el control permanente de la conexión

TCP secuestrado. [ 26 ]

Hacerse pasar por una dirección IP diferente, no era difícil antes de la RFC 1948 , cuando el

primer número de secuencia era fácil de adivinar. Eso permitió que un atacante enviara a ciegas una

secuencia de paquetes que el receptor podría creer que venir de una dirección IP diferente, sin la

necesidad de desplegar ataques ARP y de enrutamiento: es suficiente para asegurar que el anfitrión

legítimo de la dirección IP es suplantado por o llevarlo a ese estado usando ataques de denegación

de servicio. Esta es la razón por el número de secuencia inicial ahora es elegida al azar.

Veto TCP [ edit ]

Un atacante que puede espiar y predecir el tamaño del siguiente paquete a enviar puede hacer que

el receptor para aceptar una carga maliciosa sin interrumpir la conexión existente. El atacante

inyecta un paquete malicioso con el número de secuencia y un tamaño de carga útil del siguiente

paquete esperado. Cuando se recibe en última instancia el paquete legítimo, que se encuentra que

tiene el mismo número de secuencia y longitud como un paquete ya recibido y se deja caer en

silencio como un duplicado de paquetes normal-el paquete legítimo se "vetado" por el paquete

malicioso. A diferencia de en el secuestro de conexiones, la conexión no es desincronizada y la

comunicación continúa de forma normal después de la aceptación de la carga maliciosa. Veto TCP

da el atacante menos control sobre la comunicación, pero hace que el ataque particularmente

resistente a la detección. Se evita el gran aumento en el tráfico de red de la tormenta ACK. La única

prueba para el receptor que algo anda mal es un solo paquete duplicado, de un comportamiento

normal en una red IP. El remitente del paquete vetado nunca ve ninguna evidencia de un ataque. [ 27 ]

Puertos TCP [ edit ]

Artículo principal: puerto TCP y UDP

TCP utiliza números de puerto para identificar el envío y recepción de solicitud puntos finales en un

host o sockets de Internet . Cada lado de la conexión TCP tiene un número de puerto de 16 bits sin

signo asociado (0-65535) reservada por el envío o la recepción de solicitud. Al llegar los paquetes

de datos TCP se identifican como pertenecientes a una conexión TCP específico por sus tomas de

corriente, es decir, la combinación de la dirección de origen de host, puerto de origen, dirección de

host de destino, y puerto de destino. Esto significa que un ordenador servidor puede proporcionar

varios clientes con varios servicios al mismo tiempo, siempre y cuando un cliente se encarga de la

iniciación de cualesquiera conexiones simultáneas a un puerto de destino de diferentes puertos de

origen.

Los números de puerto se clasifican en tres categorías básicas: bien conocidos, registrados y

dinámicos / privados. Los puertos bien conocidos son asignados por la Internet Assigned Numbers

Authority (IANA) y suelen ser utilizados por los procesos fundamentales del sistema-nivel

o. Aplicaciones conocidas que ejecutan como servidores y escuchar pasivamente conexiones suelen

utilizar estos puertos. Algunos ejemplos incluyen: FTP (20 y

21), SSH (22), TELNET (23), SMTP (25), SSL (443) y HTTP (80). Puertos registrados suelen ser

utilizados por las aplicaciones de usuario final como efímeras puertos de origen cuando se

comunique con los servidores, pero también pueden identificar los servicios mencionados que han

sido registrados por un tercero. Los puertos dinámicos / privados también pueden ser utilizados por

las aplicaciones de usuario final, pero son menos comunes que sí. Los puertos dinámicos / privados

no contienen ningún significado fuera de cualquier conexión TCP en particular.

Desarrollo [ editar ]

TCP es un protocolo complejo. Sin embargo, mientras que las mejoras significativas se han hecho y

se propone a través de los años, su funcionamiento más básico no ha cambiado significativamente

desde su primera especificación RFC 675 en 1974, y la especificación v4 RFC 793 , publicado en

septiembre de 1981. RFC 1122 , Requisitos de host de Internet Los anfitriones, aclaró una serie de

requisitos de implementación del protocolo TCP. RFC 2581 , TCP control de la congestión, una de

las RFCs relacionadas con el PCT más importantes de los últimos años, se describen los algoritmos

actualizados que eviten la congestión excesiva. En 2001, RFC 3168 fue escrito para

describir notificación explícita de congestión ( ECN ), un mecanismo de señalización de evitación de

la congestión.

El original algoritmo de evitación de congestión del TCP se conoce como "TCP Tahoe", pero desde

entonces se han propuesto muchos algoritmos alternativos (incluyendo Reno TCP , TCP

Vegas , RÁPIDO TCP , TCP Nueva Reno , y TCP Hybla ).

TCP Interactiva (PICT) [ 28 ] es un esfuerzo de investigación sobre extensiones TCP que permite que

las aplicaciones se suscriban a eventos TCP y registro de los componentes de controlador que

puede lanzar aplicaciones para diversos fines, incluyendo el control de la congestión de la aplicación

asistida.

Múltiples rutas TCP (MPTCP) [ 29 ] [ 30 ] es un esfuerzo en curso dentro de la IETF que tiene por objeto

permitir una conexión TCP a utilizar varias rutas para maximizar el uso de los recursos y aumentar la

redundancia. La redundancia que ofrece múltiples rutas TCP en el contexto de las redes

inalámbricas [ 31 ] permite la multiplexación estadística de los recursos, y por lo tanto aumenta el

rendimiento de TCP de forma espectacular. Múltiples rutas TCP también trae beneficios en el

rendimiento en entornos de centros de datos. [ 32 ] La implementación de referencia [ 33 ]de múltiples

rutas TCP se está desarrollando en el núcleo Linux. [ 34 ] [ 35 ]

Transacciones cookies TCP (TPORAC) es una extensión propuesta en diciembre de 2009 para

proteger los servidores de los ataques de denegación de servicio. A diferencia de las cookies SYN,

TPORAC no entra en conflicto con otras extensiones TCP como el escalado de ventanas . TPORAC

fue diseñado debido a las necesidades de DNSSEC , donde los servidores tienen que manejar un

gran número de conexiones TCP de corta duración.

tcpcrypt es una extensión propuesta en julio de 2010 para proporcionar el cifrado de nivel de

transporte directamente en sí TCP. Está diseñado para trabajar de forma transparente y no requiere

ninguna configuración. A diferencia de TLS (SSL), el propio tcpcrypt no proporciona autenticación,

pero proporciona primitivas sencillas a la aplicación para hacerlo. A partir de 2010 , la primera

tcpcrypt IETF proyecto ha sido publicado y existen implementaciones para varias plataformas

principales.

TCP abierto rápido es una extensión para acelerar la apertura de conexiones sucesivas TCP entre

dos puntos finales. Su acción consiste en saltarse el protocolo de enlace de tres vías con una

"cookie" criptográfico. Es similar a una propuesta anterior llamada T / TCP , que no fue ampliamente

adoptada por cuestiones de seguridad. [ 36 ] A partir de julio 2012 , es un borrador de Internet

IETF. [ 37 ]

TCP a través de redes inalámbricas [ edit ]

TCP ha sido optimizado para las redes de cable. Cualquier pérdida de paquetes se considera que es

el resultado de la congestión de la red y el tamaño de la ventana de congestión se reduce

drásticamente como medida de precaución. Sin embargo, los enlaces inalámbricos son conocidos

por experimentar pérdidas esporádicas y generalmente temporal, debido a la decoloración, sombras,

mano fuera, y otros efectos de radio, que no pueden ser considerados congestión. Después de la

(errónea) de back-off del tamaño de ventana de congestión, debido a la pérdida de paquetes

inalámbrica, puede haber una fase de evitar la congestión con una disminución en el tamaño de la

ventana conservadora. Esto hace que el enlace de radio que se subutilizada. Una amplia

investigación se ha hecho sobre el tema de cómo combatir estos efectos nocivos. Soluciones

recomendadas pueden ser categorizados como soluciones de extremo a extremo (que requieren

modificaciones en el cliente o servidor), [ 38 ] las soluciones de capa de enlace (tales como RLP en

redes de telefonía móvil), o soluciones basadas en proxy (que requieren algunos cambios en la red

sin modificar los nodos finales). [ 38 ] [ 39 ]

Se han propuesto un número de algoritmos de control de congestión alternativos para ayudar a

resolver el problema inalámbrica, tales como Vegas , Westwood , veno y Santa Cruz.

Implementaciones de hardware [ edit ]

Una forma de superar los requerimientos de potencia de procesamiento de TCP es para construir

implementaciones de hardware de la misma, ampliamente conocidos como motores de descarga

TCP (TOE). El principal problema de los dedos es que son difíciles de integrar en los sistemas de

computación, que requiere grandes cambios en el sistema operativo del equipo o dispositivo. Una de

las empresas para desarrollar dicho dispositivo era Alacritech .

Depuración [ edit ]

Un analizador de paquetes , que intercepta el tráfico TCP en un enlace de red, puede ser útil en la

depuración de las redes, las pilas de red y aplicaciones que utilizan TCP al mostrar al usuario qué

paquetes están pasando a través de un enlace. Algunas pilas de redes soportan la opción de socket

SO_DEBUG, que puede ser activado en el socket usando setsockopt. Esa opción vuelca todos los

paquetes TCP, los estados y los eventos en ese socket, que es de gran ayuda en la

depuración. Netstat es otra utilidad que se puede utilizar para la depuración.

Alternativas [ edit ]

Para muchas aplicaciones TCP no es apropiado. Uno de los problemas (por lo menos con las

implementaciones normales) es que la aplicación no puede tener acceso a los paquetes que llegan

después de un paquete perdido hasta que se reciba la copia retransmitida del paquete perdido. Esto

causa problemas para las aplicaciones en tiempo real tales como streaming de medios , juegos

multijugador en tiempo real y de voz sobre IP (VoIP), donde por lo general es más útil para

conseguir la mayor parte de los datos en el momento oportuno de lo que es para obtener todos los

datos en orden.

Por razones tanto históricas como el rendimiento, la mayoría de las redes de área de

almacenamiento (SAN) prefieren utilizar Fibre Channel Protocol ( FCP ) en lugar de TCP / IP.

Además, para los sistemas integrados , el arranque de red y los servidores que atienden peticiones

simples de un gran número de clientes (por ejemplo, DNS servidores) la complejidad de TCP puede

ser un problema. Por último, algunos trucos tales como la transmisión de datos entre dos anfitriones

que son tanto detrás de NAT (utilizando STUN sistemas o similar) son mucho más simples y sin un

protocolo relativamente compleja como TCP en el camino.

En general, cuando TCP no es adecuado, el Protocolo de datagramas de usuario se utiliza

(UDP). Esto proporciona la aplicación de multiplexación y sumas de comprobación que TCP no,

pero no maneja corrientes o retransmisión, dando el desarrollador de aplicaciones la capacidad de

codificar de una manera adecuada para la situación, o para sustituirlos por otros métodos como

lacorrección de errores hacia adelante o interpolación .

Corriente del Protocolo de Control de Transmisión (SCTP) es otro protocolo IP que ofrece servicios

orientados a flujo confiable similares a TCP. Es nuevo y mucho más complejo de lo que TCP, y

todavía no ha visto el despliegue generalizado. Sin embargo, está especialmente diseñado para ser

utilizado en situaciones en las consideraciones de fiabilidad y casi en tiempo real, son importantes.

Protocolo de transporte Venturi (VTP) es un sistema patentado de protocolo propietario que está

diseñado para reemplazar TCP de forma transparente para superar las ineficiencias percibidas

relacionadas con el transporte de datos sin hilos.

TCP también tiene problemas en entornos de gran ancho de banda. El algoritmo de prevención de

congestión TCP funciona muy bien para entornos ad-hoc donde el remitente de los datos no se

conoce de antemano, pero si el ambiente es predecible, un protocolo basado en el tiempo, tales

como el modo de transferencia asíncrono (ATM) puede evitar retransmisiones de TCP por encima.

Protocolo de Transacción multipropósito (MTP / IP) es un software patentado patentado que está

diseñado para lograr un alto rendimiento de forma adaptativa y rendimiento de las transacciones en

una amplia variedad de condiciones de la red, en particular aquellos en TCP se percibe a ser

ineficiente.

Checksum computación [ edit ]

TCP checksum para IPv4 [ edit ]

Cuando el TCP se ejecuta sobre IPv4 , el método utilizado para calcular la suma de comprobación

se define en RFC 793 :

La comprobación sobre el terreno es el complemento a 16 bits de uno de los de una suma de los

complementos de todas las palabras de 16 bits en el encabezado y el texto. Si un segmento

contiene un número impar de octetos de cabecera y el texto que la suma de comprobación, el último

octeto se rellena por la derecha con ceros para formar una palabra de 16 bits para los propósitos de

suma de comprobación. La almohadilla no se transmite como parte del segmento. Si bien el cálculo

de la suma de comprobación, el propio campo de suma de comprobación se sustituye con ceros.

En otras palabras, después de relleno adecuado, se añaden todas las palabras de 16 bits

usando una aritmética de complemento . La suma es entonces bit a bit complementa y se inserta

como la comprobación sobre el terreno. Un pseudo-cabecera que imita la cabecera del paquete IPv4

se utiliza en el cálculo de suma de comprobación se muestra en la tabla a continuación.

La direcciones de origen y de destino son los de la cabecera IPv4. El valor de protocolo es 6 para

TCP (cf. Lista de números de protocolo IP ). El campo de longitud de TCP es la longitud de la

cabecera y los datos (medido en octetos) de TCP.

TCP checksum para IPv6 [ edit ]

Cuando el TCP se ejecuta sobre IPv6 , el método utilizado para calcular la suma de comprobación

se cambia, como por RFC 2460 :

Cualquier transporte u otro protocolo de capa superior que incluye las direcciones de la cabecera IP

en su cálculo de suma de comprobación deben ser modificados para su uso a través de IPv6, para

incluir los IPv6 de 128 bits, en lugar de las direcciones IPv4 de 32 bits.

Un pseudo-cabecera que imita la cabecera IPv6 para el cálculo de la suma de comprobación se

muestra a continuación.

Dirección de origen - el uno en la cabecera IPv6

Dirección de destino - el destino final, si el paquete IPv6 no contiene una cabecera de

enrutamiento, TCP utiliza la dirección de destino en la cabecera IPv6, de lo contrario, en el

nodo de origen, se utiliza la dirección en el último elemento de la cabecera de enrutamiento, y ,

en el nodo receptor, se utiliza la dirección de destino en la cabecera IPv6.

La longitud de TCP - la longitud de la cabecera y los datos TCP

Siguiente cabecera - el valor de protocolo de TCP

Descarga de checksum [ editar ]

Muchas implementaciones de la pila de software TCP / IP ofrecen opciones para utilizar la asistencia

de hardware para calcular automáticamente la suma de verificación en el adaptador de redantes de

la transmisión en la red o en el momento de recepción de la red para su validación. Esto puede

aliviar el sistema operativo de utilizar preciosos ciclos de CPU cálculo de la suma de

comprobación. Por lo tanto, se incrementa el rendimiento global de la red.

Esta característica puede causar analizadores de paquetes detectar el tráfico de red saliente arriba

del adaptador de red que no son conscientes o dudas sobre el uso de descarga de checksum de

reportar la suma de comprobación no válida en los paquetes salientes.

Véase también [ editar ]

Protocolo orientado a la conexión

Portal de redes de computadoras

Portal de Ciencia de la Computación

Portal Computing

T / TCP  variante de TCP

TCP y UDP

Números de puerto TCP y UDP  para una larga lista de puertos / servicios

Algoritmos de evitación de la congestión TCP

El algoritmo de Nagle

El algoritmo de Karn

Unidad de transmisión máxima

Fragmentación de IP

Tamaño máximo del segmento

Vigencia máxima del segmento

Micro-estallido (networking)

Síndrome de ventana tonta

Segmento TCP

TCP Predicción de secuencia de ataque

SYN

SYN cookies

Estimulación TCP

Tuning TCP  para redes de alto rendimiento

Path MTU discovery

Corriente del Protocolo de Control de Transmisión  (SCTP)

Protocolo de Transacción multipropósito  (MTP / IP)

Transporte tabla comparativa protocolo

Sockstress

Sincronización global TCP