tcp español
-
Upload
walter-edu -
Category
Documents
-
view
50 -
download
0
Transcript of tcp español
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