Transmission Control Protocol

Transmission Control Protocol (TCP) o Protocolo de de comenzar a transmitir los datos a ese usuario que debe
Control de Transmisin, es uno de los protocolos fun- recibirlos.
damentales en Internet. Fue creado entre los aos 1973 y
1974 por Vint Cerf y Robert Kahn.[1]

2.2 Caractersticas del TCP

Muchos programas dentro de una red de datos compuesta

por redes de computadoras, pueden usar TCP para crear
conexiones entre s a travs de las cuales puede enviarse un ujo de datos. El protocolo garantiza que los datos
sern entregados en su destino sin errores y en el mismo
orden en que se transmitieron. Tambin proporciona un
mecanismo para distinguir distintas aplicaciones dentro
de una misma mquina, a travs del concepto de puerto.

Permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.
Permite el monitoreo del ujo de los datos y as evita
la saturacin de la red.
Permite que los datos se formen en segmentos de
longitud variada para entregarlos al protocolo IP.

TCP da soporte a muchas de las aplicaciones ms populares de Internet (navegadores, intercambio de cheros, clientes FTP, etc.) y protocolos de aplicacin HTTP,
SMTP, SSH y FTP.

Permite multiplexar los datos, es decir, que la informacin que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma lnea pueda circular
simultneamente.

Objetivos de TCP

Por ltimo, permite comenzar y nalizar la comunicacin amablemente.

Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al de acuse de recibo -ACK- del protocolo TCP) independientemente de las
capas inferiores. Esto signica que los routers (que funcionan en la capa de Internet) slo tiene que enviar los
datos en forma de datagrama, sin preocuparse con el monitoreo de datos porque esta funcin la cumple la capa de
transporte (o ms especcamente el protocolo TCP).

2.3 Formato de los segmentos TCP

En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo TCP se llaman
segmentos. El formato de los segmentos TCP se muestra en el esquema segmento TCP.

3 Funcionamiento del protocolo en

detalle

Informacin tcnica

TCP es usado en gran parte de las comunicaciones de datos. Por ejemplo, gran parte de las comunicaciones que
Las conexiones TCP se componen de tres etapas:
tienen lugar en Internet emplean TCP.

2.1

1. establecimiento de conexin,

Funciones de TCP

2. transferencia de datos, y

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicacin. Muchas veces las aplicaciones necesitan que la comunicacin
a travs de la red sea conable. Para ello se implementa
el protocolo TCP que asegura que los datos que emite el
cliente sean recibidos por el servidor sin errores y en el
mismo orden que fueron emitidos, a pesar de trabajar con
los servicios de la capa IP, la cual no es conable. Es un
protocolo orientado a la conexin, ya que el cliente y el
servidor deben de anunciarse y aceptar la conexin antes

3. n de la conexin.
Para establecer la conexin se usa el procedimiento llamado negociacin en tres pasos (3-way handshake).
Para la desconexin se usa una negociacin en cuatro
pasos (4-way handshake). Durante el establecimiento de
la conexin, se conguran algunos parmetros tales como
el nmero de secuencia con el n de asegurar la entrega
ordenada de los datos y la robustez de la comunicacin.
1

3.1

Establecimiento de la conexin (nego- errores, y asentimientos y temporizadores para detectar

prdidas y retrasos.
ciacin en tres pasos)

Server

Client
SYN

SYN

-ACK

ACK

seq=

x+
ack=

ack=

y+1

[dat

a]

q=
1 se

seq=

x+1

Negociacin en tres pasos o Three-way handshake

Aunque es posible que un par de entidades nales comiencen una conexin entre ellas simultneamente, normalmente una de ellas abre un socket en un determinado
puerto TCP y se queda a la escucha de nuevas conexiones.
Es comn referirse a esto como apertura pasiva, y determina el lado servidor de una conexin. El lado cliente de
una conexin realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de
la negociacin en tres pasos. En el lado del servidor (este receptor tambin puede ser una PC o alguna estacin
terminal) se comprueba si el puerto est abierto, es decir,
si existe algn proceso escuchando en ese puerto, pues se
debe vericar que el dispositivo de destino tenga este servicio activo y est aceptando peticiones en el nmero de
puerto que el cliente intenta usar para la sesin. En caso
de no estarlo, se enva al cliente un paquete de respuesta
con el bit RST activado, lo que signica el rechazo del intento de conexin. En caso de que s se encuentre abierto
el puerto, el lado servidor respondera a la peticin SYN
vlida con un paquete SYN/ACK. Finalmente, el cliente
debera responderle al servidor con un ACK, completando as la negociacin en tres pasos (SYN, SYN/ACK y
ACK) y la fase de establecimiento de conexin. Es interesante notar que existe un nmero de secuencia generado por cada lado, ayudando de este modo a que no se
puedan establecer conexiones falseadas (spoong).

3.2

FUNCIONAMIENTO DEL PROTOCOLO EN DETALLE

Transferencia de datos

Durante la etapa de transferencia de datos, una serie de

mecanismos claves determinan la abilidad y robustez del
protocolo. Entre ellos estn incluidos el uso del nmero
de secuencia para ordenar los segmentos TCP recibidos
y detectar paquetes duplicados, checksums para detectar

Durante el establecimiento de conexin TCP, los nmeros iniciales de secuencia son intercambiados entre las
dos entidades TCP. Estos nmeros de secuencia son usados para identicar los datos dentro del ujo de bytes,
y poder identicar (y contar) los bytes de los datos de
la aplicacin. Siempre hay un par de nmeros de secuencia incluidos en todo segmento TCP, referidos al nmero
de secuencia y al nmero de asentimiento. Un emisor
TCP se reere a su propio nmero de secuencia cuando
habla de nmero de secuencia, mientras que con el nmero de asentimiento se reere al nmero de secuencia del
receptor. Para mantener la abilidad, un receptor asiente
los segmentos TCP indicando que ha recibido una parte del ujo continuo de bytes. Una mejora de TCP, llamada asentimiento selectivo (Selective Acknowledgement,
SACK) permite a un receptor TCP asentir los datos que
se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan.
A travs del uso de nmeros de secuencia y asentimiento,
TCP puede pasar los segmentos recibidos en el orden correcto dentro del ujo de bytes a la aplicacin receptora.
Los nmeros de secuencia son de 32 bits (sin signo), que
vuelve a cero tras el siguiente byte despus del 232 1.
Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la seleccin del nmero
inicial de secuencia (Initial Sequence Number, ISN).
Un checksum de 16 bits, consistente en el complemento
a uno de la suma en complemento a uno del contenido
de la cabecera y datos del segmento TCP, es calculado
por el emisor, e incluido en la transmisin del segmento.
Se usa la suma en complemento a uno porque el acarreo
nal de ese mtodo puede ser calculado en cualquier mltiplo de su tamao (16-bit, 32-bit, 64-bit...) y el resultado,
una vez plegado, ser el mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos.
El complemento es usado para que el receptor no tenga
que poner a cero el campo del checksum de la cabecera antes de hacer los clculos, salvando en algn lugar el
valor del checksum recibido; en vez de eso, el receptor
simplemente calcula la suma en complemento a uno con
el checksum incluido, y el resultado debe ser igual a 0. Si
es as, se asume que el segmento ha llegado intacto y sin
errores.
Hay que jarse en que el checksum de TCP tambin cubre
los 96 bit de la cabecera que contiene la direccin origen,
la direccin destino, el protocolo y el tamao TCP. Esto
proporciona proteccin contra paquetes mal dirigidos por
errores en las direcciones.
El checksum de TCP es una comprobacin bastante dbil. En niveles de enlace con una alta probabilidad de
error de bit quiz requiera una capacidad adicional de
correccin/deteccin de errores de enlace. Si TCP fuese rediseado hoy, muy probablemente tendra un cdigo
de redundancia cclica (CRC) para control de errores en

3.4

Escalado de ventana

vez del actual checksum. La debilidad del checksum est parcialmente compensada por el extendido uso de un
CRC en el nivel de enlace, bajo TCP e IP, como el usado en el PPP o en Ethernet. Sin embargo, esto no signica que el checksum de 16 bits es redundante: sorprendentemente, inspecciones sobre el trco de Internet
han mostrado que son comunes los errores de software y
hardware[cita requerida] que introducen errores en los paquetes protegidos con un CRC, y que el checksum de 16 bits
de TCP detecta la mayora de estos errores simples.

3
mandar paquetes con un tamao mximo de datos de (X Y) bytes. Los siguientes paquetes recibidos seguirn restando tamao a la ventana de recepcin. Esta situacin
seguir as hasta que la aplicacin receptora recoja los
datos del bfer de recepcin.

3.4 Escalado de ventana

Para una mayor eciencia en redes de gran ancho de banLos asentimientos (ACK o Acknowledgments) de los da- da, debe ser usado un tamao de ventana mayor. El camtos enviados o la falta de ellos, son usados por los emi- po TCP de tamao de ventana controla el movimiento de
sores para interpretar las condiciones de la red entre el datos y est limitado a 16 bits, es decir, a un tamao de
emisor y receptor TCP. Unido a los temporizadores, los ventana de 65.535 bytes.
emisores y receptores TCP pueden alterar el comporta- Como el campo de ventana no puede expandirse se usa
miento del movimiento de datos. TCP usa una serie de un factor de escalado. La escala de ventana TCP (TCP
mecanismos para conseguir un alto rendimiento y evi- window scale) es una opcin usada para incrementar el
tar la congestin de la red (la idea es enviar tan rpido mximo tamao de ventana desde 65.535 bytes, a 1 Gicomo el receptor pueda recibir). Estos mecanismos in- gabyte.
cluyen el uso de ventana deslizante, que controla que el
La opcin de escala de ventana TCP es usada solo durantransmisor mande informacin dentro de los lmites del
te la negociacin en tres pasos que constituye el comienzo
bfer del receptor, y algoritmos de control de ujo, tales
de la conexin. El valor de la escala representa el nmero
como el algoritmo de evitacin de la congestin (congesde bits desplazados a la izquierda de los 16 bits que fortion avoidance), el de comienzo lento (slow-start), el de
man el campo del tamao de ventana. El valor de la escala
retransmisin rpida, el de recuperacin rpida (fast repuede ir desde 0 (sin desplazamiento) hasta 14. Hay que
covery), y otros.
recordar que un nmero binario desplazado un bit a la
izquierda es como multiplicarlo en base decimal por 2.
3.2.1 Control de ujo
TCP usa control de ujo para evitar que un emisor enve 3.5 Fin de la conexin
datos de forma ms rpida de la que el receptor puede recibirlos y procesarlos. El control de ujo es un mecanismo esencial en redes en las que se comunican computadoCliente
ras con distintas velocidades de transferencia. Por ejemTransferencia
plo, si una PC enva datos a un dispositivo mvil que prode datos
cesa los datos de forma lenta, el dispositivo mvil debe
Terminar
regular el ujo de datos.
FIN
conexin
TCP usa una ventana deslizante para el control de ujo. En cada segmento TCP, el receptor especica en el
campo receive window la cantidad de bytes que puede almacenar en el bfer para esa conexin. El emisor puede
enviar datos hasta esa cantidad. Para poder enviar ms
datos debe esperar que el receptor le enve un ACK con
un nuevo valor de ventana.

3.3

Tamao de ventana TCP

El tamao de la ventana de recepcin TCP es la cantidad de datos recibidos (en bytes) que pueden ser metidos
en el bfer de recepcin durante la conexin. La entidad
emisora puede enviar una cantidad determinada de datos
pero antes debe esperar un asentimiento con la actualizacin del tamao de ventana por parte del receptor.

Servidor
Transferencia
de datos

ACK
FIN
Conexin
terminada

ACK
Conexin
terminada

Cierre de una conexin segn el estndar.

La fase de nalizacin de la conexin utiliza una negociacin en cuatro pasos (four-way handshake), terminando la conexin desde cada lado independientemente. Sin
embargo, es posible realizar la nalizacin de la conexin
en 3 fases; enviando el segmento FIN y el ACK en uno
solo.[2] Cuando uno de los dos extremos de la conexin
Un ejemplo sera el siguiente: un receptor comienza con desea parar su mitad de conexin transmite un segmenun tamao de ventana X y recibe Y bytes, entonces su ta- to con el ag FIN en 1, que el otro interlocutor asentir
mao de ventana ser (X - Y) y el transmisor slo podr con un ACK. Por tanto, una desconexin tpica requiere

6 COMPARATIVA ENTRE UDP Y TCP

un par de segmentos FIN y ACK desde cada lado de la fue escrito para describir la Noticacin de Congestin
conexin.
Explcita (ECN), una forma de eludir la congestin con
Una conexin puede estar medio abierta en el caso de mecanismos de sealizacin. En los comienzos del siglo
el 95% de todos los paquetes que
que uno de los lados la nalice pero el otro no. El lado XXI, TCP es usado en[cita
requerida]
circulan
por
Internet.
Entre las aplicaciones
que ha dado por nalizada la conexin no puede enviar
ms
comunes
que
usan
TCP
estn
HTTP/HTTPS
(World
ms datos pero la otra parte si podr.
Wide Web), SMTP/POP3/IMAP (correo electrnico) y
FTP (transferencia de cheros). Su amplia extensin ha
sido la prueba para los desarrolladores originales de que
4 Puertos TCP
su creacin estaba excepcionalmente bien hecha.
TCP usa el concepto de nmero de puerto para identicar a las aplicaciones emisoras y receptoras. Cada lado
de la conexin TCP tiene asociado un nmero de puerto
(de 16 bits sin signo, con lo que existen 65536 puertos
posibles) asignado por la aplicacin emisora o receptora.
Los puertos son clasicados en tres categoras:
1. bien conocidos,
2. registrados, y

Recientemente, un nuevo algoritmo de control de congestin fue desarrollado y nombrado como FAST TCP
(Fast Active queue management Scalable Transmission
Control Protocol) por los cientcos de California Institute of Technology (Caltech). Es similar a TCP Vegas en
cuanto a que ambos detectan la congestin a partir de los
retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todava hay un debate abierto sobre si este es un sntoma apropiado para el control de la
congestin.[cita requerida]

3. dinmicos/privados.
Los puertos bien conocidos son asignados por la Internet
Assigned Numbers Authority (IANA), van del 0 al 1023 y
son usados normalmente por el sistema o por procesos
con privilegios.[3] Las aplicaciones que usan este tipo de
puertos son ejecutadas como servidores y se quedan a la
escucha de conexiones. Algunos ejemplos son: FTP (21),
SSH (22), Telnet (23), SMTP (25) y HTTP (80).
Los puertos registrados son normalmente empleados
por las aplicaciones de usuario de forma temporal cuando
conectan con los servidores, pero tambin pueden representar servicios que hayan sido registrados por un tercero
(rango de puertos registrados: 1024 al 49151).
Los puertos dinmicos/privados tambin pueden ser
usados por las aplicaciones de usuario, pero este caso es
menos comn. Los puertos dinmicos/privados no tienen
signicado fuera de la conexin TCP en la que fueron
usados (rango de puertos dinmicos/privados: 49152 al
65535, recordemos que el rango total de 2 elevado a la
potencia 16, cubre 65536 nmeros, del 0 al 65535).

Desarrollo de TCP

TCP es un protocolo muy desarrollado y complejo. Sin

embargo, mientras mejoras signicativas han sido propuestas y llevadas a cabo a lo largo de los aos, ha conservado las operaciones ms bsicas sin cambios desde el
RFC 793, publicado en 1981. El documento RFC 1122
(Host Requirements for Internet Hosts), especica el nmero de requisitos de una implementacin del protocolo TCP.[4] El RFC 2581 (Control de Congestin TCP)
es uno de los ms importantes documentos relativos a
TCP de los ltimos aos, describe nuevos algoritmos para evitar la congestin excesiva.[5] En 2001, el RFC 3168

6 Comparativa entre UDP y TCP

UDP: proporciona un nivel de transporte no able
de datagramas, ya que apenas aade la informacin necesaria para la comunicacin extremo a extremo al paquete que enva al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System)
y RCP (comando para copiar cheros entre computadores remotos), pero sobre todo se emplea en tareas de control y en la transmisin de audio y vdeo
a travs de una red. No introduce retardos para establecer una conexin, no mantiene estado de conexin alguno y no realiza seguimiento de estos parmetros. As, un servidor dedicado a una aplicacin
particular puede soportar ms clientes activos cuando la aplicacin corre sobre UDP en lugar de sobre
TCP.[cita requerida]
TCP: es el protocolo que proporciona un transporte able de ujo de bits entre aplicaciones. Est pensado para poder enviar grandes cantidades de
informacin de forma able, liberando al programador de la dicultad de gestionar la abilidad de la conexin (retransmisiones, prdida de paquetes, orden
en el que llegan los paquetes, duplicados de paquetes...) que gestiona el propio protocolo. Pero la complejidad de la gestin de la abilidad tiene un coste
en eciencia, ya que para llevar a cabo las gestiones
anteriores se tiene que aadir bastante informacin
a los paquetes que enviar. Debido a que los paquetes
para enviar tienen un tamao mximo, cuanta ms
informacin aada el protocolo para su gestin, menos informacin que proviene de la aplicacin podr
contener ese paquete (el segmento TCP tiene una
sobrecarga de 20 bytes en cada segmento, mientras
que UDP solo aade 8 bytes). Por eso, cuando es

5
ms importante la velocidad que la abilidad, se utiliza UDP. En cambio, TCP asegura la recepcin en
destino de la informacin para transmitir.

[5] Ver RFC 2581

[6] http://www.solarsockets.solar-opensource.com
[7] http://www.solarsockets.solar-opensource.com/index.
php/Ejemplos

Bibliotecas de sockets TCP

[8] http://www.libsdl.org/projects/SDL_net/

Se listan algunas de las bibliotecas de comunicaciones [9] http://www.alhem.net/Sockets/index_spanish.html

existentes, que utilizan los protocolos TCP y UDP para [10] http://www.gnu.org/software/commoncpp/docs/refman/
distintos sistemas operativos.
html/_sample_socket_port_8cpp-example.html
SolarSockets es una biblioteca para C++ Multiplataforma y Multithread, gratuita para proyectos
libres.[6] Fcil de usar y con varios ejemplos.[7]
SDL NET proporciona funciones y tipos de dato
multiplataforma para programar aplicaciones que
trabajen con redes.[8]
C++ Sockets Library es una biblioteca de clases en
C++ bajo licencia GPL que 'mapea' el berkeley sockets C API, y funciona tanto en algunos sistemas
Unix como en Win32.[9]
GNU Common C++ es una biblioteca de propsito
general que incluye funciones de red.[10]
HackNet es una biblioteca de comunicaciones para
crear juegos multijugador.[11]
DirectPlay simplica el acceso de las aplicaciones a
los servicios de comunicacin. Es una componente
de DirectX.

Vase tambin
Implementaciones de TCP
Lista de nmeros de puerto
SCTP
UDP
Ruido de fondo de internet

Referencias

[1] Cerf, V.; Kahn, R. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on Communications. COM-22 (5): 637648.
[2] Andrew S. Tanenbaum y David J. Wetherall, Redes
de computadoras, Quinta edicin, Pearson Educacin,
2012,Pg. 482
[3] Asignacin de puertos del IANA
[4] Ver RFC 1122

[11] http://hacknet.sourceforge.net/

10 Enlaces externos
RFC793 en texto en claro
RFC1180 Un Tutorial de TCP/IP
Administracin avanzada de redes TCP/IP. Javier Carmona Murillo, David Corts Polo, M.
Domnguez-Dorado, Alfonso Gazo-Cervero, JosLuis Gonzlez-Snchez, Francisco Javier Rodrguez
Prez. ISBN 978-84-695-2037-6. January, 2012.
Protocolo TCP
Comunicaciones y redes de computadoras

11 TEXTO E IMGENES DE ORIGEN, COLABORADORES Y LICENCIAS

11
11.1

Texto e imgenes de origen, colaboradores y licencias

Texto

Transmission Control Protocol Fuente: http://es.wikipedia.org/wiki/Transmission_Control_Protocol?oldid=82230342 Colaboradores:

Hashar, Aloriel, Rsg, Aequanimous, Tano4595, Barcex, Porao, 142857, Caos, Digigalos, Petronas, Rembiapo pohyiete (bot), Caiser, NekroByte, Orgullobot~eswiki, RobotQuistnix, Dibujon, Yrbot, FlaBot, Vitamine, YurikBot, GermanX, Equi, KnightRider, JRGL, Play284,
Scardoso, Pieraco, Maldoror, Er Komandante, Ciencia Al Poder, Cheveri, Chlewbot, Siabef, Paintman, BOTpolicia, CEM-bot, Damifb,
DEEJAY, Paco c, Roberpl, Thijs!bot, PabloCastellano, Xoacas, IrwinSantos, Isha, Martin Rizzo, Mpeinadopa, JAnDbot, Jugones55, BetBot~eswiki, Muro de Aguas, Gaius iulius caesar, TXiKiBoT, Rei-bot, NaSz, Plux, Snakefang, Cinevoro, VolkovBot, Technopat, Raystorm, Matdrodes, Trustee~eswiki, Shooke, Barri, Muro Bot, SieBot, DaBot~eswiki, Loveless, Cobalttempest, Er conde, Paconi, Idleloop,
ElYeante, Egjose, Marcecoro, HUB, Mrzeon, David.rgh, Ignacio Jorge Castaos Gonzalez, PixelBot, Botelln, Marcelo8776, Alejandrocaro35, Alecs.bot, Alexbot, Darkicebot, BodhisattvaBot, AVBOT, Edenial, LucienBOT, MastiBot, Pipandro, Diegusjaimes, DumZiBoT,
MelancholieBot, Dcostanzo, Luckas-bot, Nallimbot, Jrodri18, Princess 14, KrlosT, Billinghurst, Gacpro, Hampcky, Vivaelcelta, DirlBot,
ArthurBot, Xqbot, Jkbw, Ismael ule, Rubinbot, Ricardogpn, Botarel, BenzolBot, RedBot, LoliBot, PatruBOT, Ripchip Bot, JdmGarcia,
Foundling, EmausBot, AVIADOR, Guarddon, Usuariotuputhamadre, KLBot, Rubpe19, ChuispastonBot, Snubcube, Miguel.baillon, MerlIwBot, MetroBot, Invadibot, IRedRat, Elvisor, Agckem, Otosan-kf, Legobot, AleAnonMallo, Addbot, Tcproyect, Kevinsimon300, Philip
7, Facumontero, MrCharro, Magdiel2014 y Annimos: 186

11.2

Imgenes

Archivo:Commons-emblem-question_book_orange.svg
Fuente:
http://upload.wikimedia.org/wikipedia/commons/1/1f/
Commons-emblem-question_book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//commons.wikimedia.org/
wiki/File:Commons-emblem-issue.svg'
class='image'><img
alt='Commons-emblem-issue.svg'
src='//upload.wikimedia.org/
wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/25px-Commons-emblem-issue.svg.png'
width='25'
height='25'
srcset='//upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/38px-Commons-emblem-issue.svg.png
1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/50px-Commons-emblem-issue.svg.png 2x'
data-le-width='48' data-le-height='48' /></a> + <a href='//commons.wikimedia.org/wiki/File:Question_book.svg' class='image'><img
alt='Question book.svg' src='//upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/25px-Question_book.svg.png'
width='25' height='20' srcset='//upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/38px-Question_book.svg.
png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/50px-Question_book.svg.png 2x' data-lewidth='252' data-le-height='199' /></a> Artista original: GNOME icon artists, Jorge 2701
Archivo:Fin_de_conexin_TCP.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/3/35/Fin_de_conexi%C3%B3n_TCP.
svg Licencia: CC-BY-SA-3.0 Colaboradores: ? Artista original: ?
Archivo:Tcp-handshake.svg Fuente: http://upload.wikimedia.org/wikipedia/commons/9/98/Tcp-handshake.svg Licencia: CC-BY-SA3.0 Colaboradores:
300px-Tcp-handshake.png Artista original: 300px-Tcp-handshake.png: ???

11.3

Licencia de contenido

Creative Commons Attribution-Share Alike 3.0