Nivell de transport TCP/IP (S'ha redirigit des de: Transport Control Protocol)

Compartiu

Aquesta wiki forma part dels materials d'un curs
Curs:	DissenyXarxesLinux, LinuxAdministracioAvancada, LPIC1_102
Fitxers:	Consulteu LPI_109.1
Repositori SVN:	https://svn.projectes.lafarga.cat/svn/iescopernic/ServeisInternet/moodle/Wifi
Usuari:	anonymous
Paraula de pas:	sense paraula de pas
Autors:	Sergi Tur Badenas

http://acacha.org/~sergi/UD_4._Nivell_de_xarxa_i_nivell_de_transport._Dispositius_de_xarxes_d_rea_local.pdf

Nivells TCP/IP
Nivell 1:	Nivell_d'interfície_de_xarxa_TCP/IP
Nivell 2:	Nivell_d'internet_TCP/IP
Nivell 3:	Nivell_de_transport_TCP/IP
Nivell 4:	Nivell_d'aplicació_TCP/IP

El nivell de transport és l'encarregat de que les dades transferides entre emissor i receptor estiguin lliures d'errors. També és l'encarregat de controlar el flux de dades.

Nivells OSI i TCP/IP

Model de referència OSI

Nivell 4. Nivell de transport

Pila de protocols TCP/IP

Nivell 3. Nivell de transport

Els objectius són els mateixos que el nivell d'enllaç però aquest com la comunicació és entre màquines que no estan directament connectades.

És una capa de transició que connecta les aplicacions i/o usuaris amb la xarxa o el que és el mateix, entre els nivells orientats a la xarxa i els orientats a les aplicacions.

Treballa amb unitats de dades 4-PDU també anomenades TPDU o segments.

Té funcions similars al nivell d'enllaç (salt a salt) però entre dues màquines que no estan connectades directament (extrem a extrem) i s'encarrega de preparar les dades de les aplicacions per a la xarxa i assegurar-se que arribaran correctament al nivell de transport del destinatari.

Protocols: TCP (Transport Control Protocol) i UDP (User Datagram Protocol)

Funcions del nivell de transport

Té funcions similars al nivell d'enllaç (salt a salt) però entre dues màquines que no estan connectades directament (extrem a extrem)

Establiment de connexió: és opcional (UDP no ho implementa). Només s'aplica al serveis orientats a connexió

Orientat a connexió (Connection-oriented): La capa de xarxa o d'internet (nivell 3 OSI) és una capa que no proveeix de connexió. Protocols com TCP introdueixen el concepte de connexió en la capa de transport. Normalment és més senzill programar aplicacions orientades a connexió. S'estableix un camí virtual a través de qual es durà a terme la comunicació. Les dades s'envien de forma ordenada per aquest camí

Reoordenació de paquets: Opcional. Només s'aplica al serveis no orientats a connexió. No s'estableix cap camí i els paquets poden arribar desordenats

Ordre de lliurament (Same Order Delivery): La capa de xarxa no garanteix que els paquets arribin en el mateix ordre que han sortit de l'emissor. La capa de transport permet garantir l'ordre. La forma més senzilla és enumerar els paquets i reordenar-los al receptor.

Control d'errors: Les capçaleres (headers) del nivell 4 contenen dades redundants que permeten detectar errors en la transmissió Recuperació de caigudes de xarxa, reenviament de paquets, etc.

Dades fiables (Reliable data): Els paquets es poden perdre per la xarxa per problemes de congestió, error, interferències, etc. Alguns protocols de transport com TCP poden solucionar aquests problemes mitjançant tècniques com la detecció de paquets corruptes (checksums) i la retransmissió dels errors. Cal fer notar que les transmissions 100% sense errors no són possibles que el que s'intenta és que hi hagin el mínim d'errors no detectats.
Control de fluxe (Flow Control): La memòria dels dispositius de xarxa és limitada i sense un control de flux una computadora amb una alta capacitat d'enviament d'informació pot saturar fàcilment una computadora més lenta i amb poca memòria. Actualment això no es gaire problema ja que les memòries són relativament molt més barates que l'ample de banda. Aquest control el pot fer la capa de xarxa però quan no el fa és responsabilitat de la capa de transport.
Control de la congestió (Congestion avoidance): Quan els paquets és perden es tornen a retransmetre. En el cas de no tenir un control de congestió que permeti parar d'enviar durant un temps la informació per un node congestionat el control d'errors (reenviament) pot esdevenir un problema sense fi.
Orientació a bytes (Byte orientation): En comptes de treballar a nivell de paquets, la capa de tranport permet treballar a nivell de bytes, veiem la comunicació com un stream de bytes. Això facilita la programació per que una connexió de xarxa es pot tractar igual que les comunicacions d'entrada/sortida (fitxers, dispositius, etc.).
Ports/Multiplexació de connexions: Els ports són una forma essencial de permetre múltiples serveis en una mateixa localització (Adreça IP). NOTA: Els ports són part de la capa de transport en el model TCP/IP però de la cappa de sessió al model OSI.Permet tenir més d'una connexió oberta a través d'un mateix medi físic. S'utilitzen ports i el concepte de sockets.

Qualitat de servei. QoS (Quality of Service): Garanteix la fiabilitat i la qualitat del servei. Per exemple es pot reservar un ampla de banda mínim per a una connexió concreta

Serveis OSI

Servei orientat a connexió

Abans d'intercanviar dades es necessita establir una connexió (Exemples: telèfon, accés a una pàgina web, protocol TCP)

Servei no orientat a connexió

Les dades s'envien directament sense establir cap connexió prèvia (enviar una carta, enviar un email, protocol UDP)

Servei confirmat o no confirmat

Servei confirmat: Trucada telefònica (pot ser confirmada (et despengen el telèfon) o no confirmada (no et despengen, et denegen la trucada o comunica))
Servei no confirmat: Per exemple al parlar per telèfon. És una comunicació full duplex i ni emissor ni receptor necessiten de confirmació per començar a parlar.

Serveis orientats a connexió

Propietats

Requereixen el establiment inicial de una connexió i la ruptura o alliberament final de la mateixa.
Entre la connexió i l’alliberament es produeix l’intercanvi de dades d’usuari.
Els blocs de dades es reben en el destí en el mateix ordre en que s’emeten a l’origen.
Tots els paquets segueixen la mateixa ruta, aconseguida en l’establiment de la connexió
Com que la ruta es coneguda, els paquets de dades no precisen indicar l’adreça de destinació.

Exemple: Trucada telefònica

El protocol orientat a connexió per excel·lència és TCP.

Els dispositius de cada banda de la connexió (emissor i receptor) utilitzen un protocol preliminar a l'enviament de dades per establir una connexió punta a punta. Sovint també s'anomenen serveis de xarxa fiables (reliable) per què es garanteix que les dades arribaren en l'ordre adequat.

La comunicació pot estar en diferents estats

La comunicació es duu a terme en tres fases:

Fase 1: Establiment de la connexió (handshake)
Fase 2: Transmissió de dades
Fase 3: Tancament de la connexió

Hi ha dos variants:

Seqüència de missatges. S’estableixen fronteres que defineixen i determinen cada missatge (és equivalent a la sincronització).
Seqüència de bytes. En aquests serveis no hi ha contorns entre els missatges. Cada missatge és una seqüència de caràcters, deixant al receptor la responsabilitat de la seva interpretació.

Serveis no orientats a connexió

Propietats:

Ofereixen la capacitat de comunicació sense necessitat de realitzar una connexió amb el destinatari.
L’emissor envia paquets de dades al receptor confiant en que la xarxa tindrà prou intel·ligència com per a conduir les dades per rutes adequades.
Els paquets poden seguir rutes diferents durant la comunicació.
Els blocs de dades es poden rebrà desordenats.
Cada paquet ha de portar l’adreça de destinació i, en alguns casos, el receptor ha d’enviar un acusament de rebuda per confirmar l’èxit de la comunicació.

Exemple: Correu postal

El protocol no orientat a connexió per excel·lència és UDP o User Datagram Protocol.

A les unitats de dades d'aquests tipus de paquets se'ls anomena Datagrames. Els datagrames s'envien directament paquets de l'emissor al receptor sense establir prèviament una connexió.

NOTA: Datagrama: L'origen prové de la paraula telegrama

No és una connexió fiable, ja que els paquets poden arribar en qualsevol ordre, duplicats, es poden perdre...

Tipologies

Servei de datagrama sense confirmació.

L’emissor no necessita confirmació per part del receptor de que els paquets de dades li arriben correctament (protocol IP)

Servei de datagrama amb confirmació. El receptor envia confirmacions a l’emissor. (correu electrònic)

Servei de petició i resposta: És un servei propi de gestió interactiva basat en que a cada petició li segueix una resposta. (peticions a bases de dades).

Protocols que utilitzen UDP:

DNS, DHCP, VoIP, Videoconferència, jocs en xarxa.

Protocol TCP

Connexions TCP

El protocol TCP és orientat a connexió. El següent diagrama mostra el protocol d'establiment d'una connexió:

i aquest altre diagrama mostra el procés de terminació d'una connexió:

Consulteu Exemple amb netcat de captura de paquets de connexió TCP

http://wiki.mikrotik.com/wiki/Manual:Connection_oriented_communication_%28TCP/IP%29

Segments transmission (windowing)

TODO: http://www.tcpipguide.com/free/t_TCPSlidingWindowDataTransferandAcknowledgementMech.htm
aka TCP Windowing

Un cop s'ha establert la comunicació, necessitem entendre com la transmissió de dades és gestionada i mantinguda. En xarxes TCP/IP, la transmissió entre màquines és controlada pel protocol TCP.

Que passa si els datagrames són enviats a més velocitat que la que pot processar el dispositiu? Els dispositius guarden els datagrames en unes memòries anomenades buffers. Els buffers no tenen però un espai il·limitat i si la seva capacitat és excedida aleshores el receptor començara a perdre paquets (DROP). Tots aquests paquets s'han de tornar a transmetre i aquesta és una de les raons per les quals el rendiment/velocitat de la transmissió pot disminuir.

Per solucionar aquest problema el protocol TCP utilitza un protocol de control de flux. El mecanisme de finestra (windowing) s'utilitza per controlar el flux de dades. Quan la connexió és establerta el receptor especifiquen el camp window la mida de la finestra TCP (vegeu capçalera TCP). La mida de la finestra (en bytes) representa la quantitat de dades rebudes que el receptor pot emmagatzemar al buffer. Aquesta mida s'indica al emissor en el paquet ACK. La mida de la finestra controla quin és el màxim d'informació que pot enviar el emissor abans de rebre una confirmació. El emissor envia la quantita d'informació especificada a la mida de la finestra i s'espera a rebre una confirmació abans d'enviar més dades. En les confirmacions es torna a enviar una mida de finestra actualitzada per a utilitzar-la en les següents transmissions.

IMPORTANT: La mida de la finestra tampoc es pot augmentar indefinidament. Si un sol paquets que s'envia dins d'una finestra ha de ser tornat a transmetre aleshores tota la finestra s'ha de tornar a enviar. En el cas d'un canal que perdi paquets, això pot afectar molt el rendiment

La mida de la finestra s'anirà augmentant mentrestant el receptor pugui processar els paquets. Un cop les velocitat dels dos receptors estan a la par la mida de la finestra ja no augmenta i en tot cas si el receptor es satura pot disminuir la mida de la finestra fins i tot fins a especificar una mida de zero. En aquest cas el emisor ha de parar d'enviar informació fins que la finestra torni a ser positiva.

Fitxer:Windowing.gif

TCP utilitza els algorismes Slow Start i Congestion Avoidance per tal de determinar quants paquets es poden enviar entre el emissor i el receptor o el que també s'anomena congestion window, és a dir la màxima quantitat de dades que es poden enviar abans de rebre un ACK (acknowledgment) per part del receptor. Si no es rep el ACK aleshores el emissor suposa que hi ha congestió a la xarxa i disminueix la velocitat de transmissió de paquets.

Cal tenir en compte que les configuracions per defecte de la finestra TCP poden ser molt poc adequades per a casos específics.

El control de la mida de la finestra es gestiona en diferents algorismes com Reno, Vegas, Tahoe, etc. Una llista completa:

TODO: This is a list of 14 congestion control algorithms available in TCP. I'm presenting it in alphabetical order.
BIC TCP - Binary Increase Congestion Control, this is the default congestion control algorithm in Linux as of kernel version 2.6.7
   Compound TCP (CTCP) - TCP Reno with a scalable delay-based component, developed by Microsoft and used in Windows Vista
   FAST TCP - uses queueing delay (rather than packet loss) as an indicator of congestion
   Hamilton TCP (H-TCP) - uses AIMD to control the congestion window
   HighSpeed TCP (HSTCP) - a recent (2003) implementation
   Scalable TCP - adaptation of the algorithms in TCP Reno
   TCP Hybla - aimed at overcoming the extremely long RTTs of satellite networks
   TCP Low Priority (TCP-LP) - designed to only use 'extra' bandwidth
   TCP NewReno - TCP Reno with a modified Fast Retransmit and Fast Recovery
   TCP Reno - adds Fast Recovery to TCP Tahoe's Fast Retransmit
   TCP Tahoe - uses Fast Retransmit to reduce wait time when a packet is lost
   TCP Vegas - similar to FAST TCP, uses delay rather than loss to determine congestion
   TCP Veno - slight modification to TCP Reno, optimized for heterogeneous networks, especially those involving wireless links
   TCP Westwood+ - based on end-to-end bandwidth estimates, especially effective in wireless networks

Vegeu també Throughput#TCP.

Límits de velocitat de TCP.

Vegeu també Throughput
TODO

Maximum achievable throughput for a single TCP connection is determined by different factors. One trivial limitation is the maximum bandwidth of the slowest link in the path. But there are also other, less obvious limits for TCP throughput. Bit errors can create a limitation for the connection as well as round-trip time.

Window size

En xarxes, RWIN (TCP Receive Window) és la quantitat de dades màxima que un node pot acceptar sense la recepció de un acknowledge. Si un cop arribada aquesta quantitat no s'ha rebut el acknowledge, s'atura la transmisió (stop and wait) i esperara un cert temps (timeout) i si no es rep la confirmació es demanarà una retransmissió.

Even if there is no packet loss in the network, windowing can limit throughput. Because TCP transmits data up to the window size before waiting for the acknowledgements, the full bandwidth of the network may not always get used. The limitation caused by window size can be calculated as follows:

Throughput <= RWIN/RTT

where RWIN is the TCP Receive Window and RTT is the Round-trip delay time o Round-trip time for the path.

At any given time, the window advertised by the receive side of TCP corresponds to the amount of free receive memory it has allocated for this connection. Otherwise it would take the risk to have to drop received packets by lack of space.

Unrelated to the TCP receive window, the sending side should also allocate the same amount of memory as the receive side for good performance. That is because, even after data has been sent on the network, the sending side must hold it in memory until it has been acknowledged as successfully received, just in case it would have to be retransmitted. If the receiver is far away, acknowledgments will take a long time to arrive. If the send memory is small, it can saturate and block emission. A simple computation gives the same optimal send memory size as for the receive memory size given above.

http://en.wikipedia.org/wiki/TCP_tuning

Estats TCP

Els podeu consultar amb

$ netstat --inet -t -a -c  | grep upc.es:www
tcp 1   0 casa-linux.local:48520  raiden.upc.es:www  CLOSE_WAIT 
tcp 0 687 casa-linux.local:48529  raiden.upc.es:www  ESTABLISHED
tcp 0   1 casa-linux.local:48522  raiden.upc.es:www  SYN_SENT   
tcp 0 709 casa-linux.local:48537  raiden.upc.es:www  ESTABLISHED
tcp 0   1 casa-linux.local:48522  raiden.upc.es:www  SYN_SENT   
tcp 1   1 casa-linux.local:48560  raiden.upc.es:www  LAST_ACK    
tcp 0   0 casa-linux.local:48556  raiden.upc.es:www  TIME_WAIT   
tcp 0   0 casa-linux.local:48556  raiden.upc.es:www  TIME_WAIT    
...............................................

El següent diagrama mostra els canvis d'estats segons els serveis OSI:

I al diagrama següent podeu observar quin és l'evolució de l'establiment d'una connexió i els estats relacionats:

Vegeu també conntrack.

ESTABLISHED: Connexió establerta.
SYN_SENT: El socket està intentant establir de forma activa una connexió.
SYN_RECV: S'ha rebut una petició de connexió des de la xarxa
FIN_WAIT1: El socket està tancat i la connexió s'està apagant.
FIN_WAIT2: El socket està tancat i la connexió està esperant l'apagament de la connexió remota.
TIME_WAIT: El socket està esperant la recepció de paquets de la xarxa tot i haver-se apagat la connexió.
CLOSED: El socket està apagat.
CLOSE_WAIT: La connexió remota s'ha apagat i s'està esperant que el socket es tanqui.
LAST_ACK: La connexió remota s'ha apagat i el socket està apagat però en espera d'un acknowledgement.
LISTEN: El socket està a l'espera de peticions de connexió.
CLOSING: Els dos sockets estan tancats però encara no s'han rebut totes les dades.

En les comunicacions sempre hi han errors (de programació, dispositius que es pengen, caigudes de xarxa, etc). Per evitar que els sockets es quedin penjats en una esta fins indeterminadament s'estableixen uns timeouts:

Capçalera TCP

TODO

Source port - bit 0 - 15. This is the source port of the packet. The source port was originally bound directly to a process on the sending system. Today, we use a hash between the IP addresses, and both the destination and source ports to achieve this uniqueness that we can bind to a single application or program.
Destination port - bit 16 - 31. This is the destination port of the TCP packet. Just as with the source port, this was originally bound directly to a process on the receiving system. Today, a hash is used instead, which allows us to have more open connections at the same time. When a packet is received, the destination and source ports are reversed in the reply back to the originally sending host, so that destination port is now source port, and source port is destination port.
Sequence Number - bit 32 - 63. The sequence number field is used to set a number on each TCP packet so that the TCP stream can be properly sequenced (e.g., the packets winds up in the correct order). The Sequence number is then returned in the ACK field to ackonowledge that the packet was properly received.
Acknowledgment Number - bit 64 - 95. This field is used when we acknowledge a specific packet a host has received. For example, we receive a packet with one Sequence number set, and if everything is okey with the packet, we reply with an ACK packet with the Acknowledgment number set to the same as the original Sequence number.
Data Offset - bit 96 - 99. This field indicates how long the TCP header is, and where the Data part of the packet actually starts. It is set with 4 bits, and measures the TCP header in 32 bit words. The header should always end at an even 32 bit boundary, even with different options set. This is possible thanks to the Padding field at the very end of the TCP header.
Reserved - bit 100 - 103. These bits are reserved for future usage. In RFC 793 this also included the CWR and ECE bits. According to RFC 793 bit 100-105 (i.e., this and the CWR and ECE fields) must be set to zero to be fully compliant. Later on, when we started introducing ECN, this caused a lot of troubles because a lot of Internet appliances such as firewalls and routers dropped packets with them set. This is still true as of writing this.
CWR - bit 104. This bit was added in RFC 3268 and is used by ECN. CWR stands for Congestion Window Reduced, and is used by the data sending part to inform the receiving part that the congestion window has been reduced. When the congestion window is reduced, we send less data per timeunit, to be able to cope with the total network load.
ECE - bit 105. This bit was also added with RFC 3268 and is used by ECN. ECE stands for ECN Echo. It is used by the TCP/IP stack on the receiver host to let the sending host know that it has received an CE packet. The same thing applies here, as for the CWR bit, it was originally a part of the reserved field and because of this, some networking appliances will simply drop the packet if these fields contain anything else than zeroes. This is actually still true for a lot of appliances unfortunately.
URG - bit 106. This field tells us if we should use the Urgent Pointer field or not. If set to 0, do not use Urgent Pointer, if set to 1, do use Urgent pointer.
ACK - bit 107. This bit is set to a packet to indicate that this is in reply to another packet that we received, and that contained data. An Acknowledgment packet is always sent to indicate that we have actually received a packet, and that it contained no errors. If this bit is set, the original data sender will check the Acknowledgment Number to see which packet is actually ack

Ports

Un port és una connexió virtual que pot ser utilitzada per les aplicacions per intercanviar dades.
Els ports més comuns són els dels protocols TCP i UDP
Notació: Decimal (22, 80) o Hexadecimal
El fitxer /etc/services manté una llista de ports i els seus serveis associats.
Cada port esta associat a un servei per la IANA
Els ports per defecte dels serveis es poden canviar

Una llista possible dels ports més habituals

20 i 21: Port de dades i control de FTP respectivament. TCP
22: Servidor SSH (OpenSSH). TCP
23: Servidor Telnet. TCP
25: SMTP. Enviament de correu electrònic no segur.
53: Servidor de DNS (Bind). UDP per a consultes (TCP per a transferències de zona)
80: Servidor web (Apache). TCP
110: POP3. Recepció de correu electrònic. TCP
119: Servidor de notícies (Usenet News Transfer Protocol - UNTP)
137, 138 i 139: Netbios Name Service (WINS) I Netbios servei datagrama i servei de sessió
143: IMAP. Recepció de correu electrònic. TCP
161: SNMP. Monitorització. UDP
443: Protocol HTTPS. Servidor Web Apache TCP.
465: SMTP segur
993: IMAP segur
995: POP3 segur

Consulteu també /etc/services.

Sockets

Dispositius virtuals de comunicacions bidireccionals.

Hi han tantes famílies de sockets com protocols. Els dos més importants:

Unix Domain Sockets
Internet Sockets (TCP, UDP i RAW)

Sockets Unix

Unix domain socket (UDS o IPC socket)

Són sockets virtuals, similars als sockets d'Internet que s'utilitzen en sistemes operatius POSIX per a la comunicació entre processos (IPC)
També anomenats POSIX Local IPC Sockets.

Components

Tipus: Datagrama o Stream. Camí absolut del fitxer

$ ls -la /var/run/mysqld/mysqld.sock
srwxrwxrwx 1 mysql mysql 0 2007-05-10 07:42 /var/run/mysqld/mysqld.sock

Sockets TCP/IP:

Components d'un socket d'Internet

Protocol (TCP, UDP, RAW IP)
Adreça IP local
Número de port local
Adreça IP remota
Número de port remot

Fitxer:Sockets2.png

Exemple de connexió TCP amb Telnet

Consulteu Telnet#Telnet_com_a_eina_per_a_obrir_connexions_TCP.

Protocol UDP

UDP o User Datagram Protocol és un protocol de nivell 4 OSI (Nivell 3 TCP/IP) que ofereix serveis no orientats a connexió.

Utilitzat en serveis on la velocitat és important i ens podem permetre perdre part de la informació (aplicacions en temps real com veu IP, videoconferència, jocs online...)

És un dels protocol importants d'Internet

Vegeu també:

Segment UDP

TCP vs UDP

Els dos protocols de nivell de transport més utilitzats són TCP i UDP.

TCP és més fiable però més lent. S'utilitza en comunicacions on la integritat de les dades és vital (per exemple la transferència de fitxers).
UDP és menys fiable però més ràpid (aprox. 40% ). S'utilitza en aplicacions on la velocitat és important i ens podem permetrà la pèrdua d'algunes dades (P. ex. serveis en temps real com la telefonia IP o videoconferència)

Network Address Translation (NAT)

Consulteu l'article Network Address Translation (NAT).

Vegeu també

Enllaços externs

http://iptables-tutorial.frozentux.net/chunkyhtml/index.html