Diferencia entre revisiones de «Capa de transport»

De Jose Castillo Aliaga
Ir a la navegación Ir a la búsqueda
 
(No se muestran 20 ediciones intermedias del mismo usuario)
Línea 1: Línea 1:
La '''capa de transport''' es troba entre la [[capa d'aplicació]] i la [[capa de xarxa]] del model [[TCP/IP]]. Dins del model de referència [[OSI]], la capa de transport es trobaria entre la capa de sessió i la capa de xarxa.
La '''capa de transport''' es troba entre la [[capa d'aplicació]] i la [[Capa de xarxa]] del model [[TCP/IP]]. Dins del model de referència [[OSI]], la capa de transport es trobaria entre la capa de sessió i la capa de xarxa.
<br clear="all"/>
<br clear="all"/>


Línea 5: Línea 5:
La capa de transport és la part del [[protocol de comunicació|protocol]] TCP/IP encarregada de garantir la transmissió de les dades.  
La capa de transport és la part del [[protocol de comunicació|protocol]] TCP/IP encarregada de garantir la transmissió de les dades.  


La [[capa de xarxa]] transfereix datagrames entre dos [[ordinador]]s per la [[Xarxa informàtica|xarxa]] utilitzant com a identificadors les adreces [[Adreça IP|IP]]. La capa de transport és l'encarregada d'afegir la noció de [[port (informàtica)|port]]. Amés, la capa de xarxa s'encarrega de enviar el paquet per distints enrutadors, topologíes i tecnologíes de transmisió. La capa de xarxa pot fallar en algun paquet o poden arrivar desordenats. De la recuperació dels paquets i la ordenació s'encarrega la capa de transport.
La [[Capa de xarxa]] transfereix datagrames entre dos [[ordinador]]s per la [[Xarxa informàtica|xarxa]] utilitzant com a identificadors les adreces [[Adreça IP|IP]]. La capa de transport és l'encarregada d'afegir la noció de [[port (informàtica)|port]]. Amés, la capa de xarxa s'encarrega de enviar el paquet per distints enrutadors, topologíes i tecnologíes de transmisió. La capa de xarxa pot fallar en algun paquet o poden arrivar desordenats. De la recuperació dels paquets i la ordenació s'encarrega la capa de transport.
Dins d'una mateixa computadora hi pot haver més d'una [[aplicació (Informàtica)|aplicació]] que estigui accedint simultàniament a la xarxa (podem tenir l'[[Emule]] funcionant, i el [[Windows Messenger|Messenger]], i la pàgina del [[correu electrònic]], i...). Per aquest motiu, quan s'envia un [[datagrama]] no en tenim prou amb l'adreça IP de la màquina de destí, necessitem també indicar a quina aplicació estem enviant la informació. Cada aplicació que estigui esperant un missatge utilitzarà un port diferent; estarà a l'espera d'un [[missatge]] en un port concret (escoltant un port). S'utilitzarà també un port concret per a l'enviament de missatges.  


Els ports tenen una [[memòria intermitja]] (buffer, en [[anglès]]) situada entre els programes d'aplicació i la xarxa, de tal manera que les aplicacions transmeten la informació als ports, aquí es van emmagatzemant fins que pugui enviar-se per la xarxa. Un cop transmès arribarà al port destí on s'anirà guardant fins que l'aplicació estigui preparada per a rebre-la.  
Dins d'una mateixa computadora hi pot haver més d'una [[aplicació (Informàtica)|aplicació]] que estigui accedint simultàniament a la xarxa. Per aquest motiu, quan s'envia un [[datagrama]] no en tenim prou amb l'adreça IP de la màquina de destí, necessitem també indicar a quina aplicació estem enviant la informació. Cada aplicació que estigui esperant un missatge utilitzarà un port diferent; estarà a l'espera d'un [[missatge]] en un port concret (escoltant un port). S'utilitzarà també un port concret per a l'enviament de missatges.
 
Els ports tenen una memòria intermitja (buffer, en anglès) situada entre els programes d'aplicació i la xarxa, de tal manera que les aplicacions transmeten la informació als ports, aquí es van emmagatzemant fins que pugui enviar-se per la xarxa. Un cop transmès arribarà al port destí on s'anirà guardant fins que l'aplicació estigui preparada per a rebre-la.  


A més, la capa de transport proporciona un mecanisme per intercanviar les dades entre sistemes finals. El servei de transport orientat a connexió assegura que les dades s'entreguin lliures d'errors, en ordre i sense pèrdues ni duplicacions. És més, la capa de transport pot estar involucrada en la optimitzacció de l'ús dels serveis de xarxa. Es a dir; pot proporcionar la qualitat del servei que s'hagi solicitat. Per exemple, l'entitat de sessió pot solicitar una tasa d'error determinada, un retard màxim, una prioritat i un nivell de seguretat donat.  
A més, la capa de transport proporciona un mecanisme per intercanviar les dades entre sistemes finals. El servei de transport orientat a connexió assegura que les dades s'entreguin lliures d'errors, en ordre i sense pèrdues ni duplicacions. És més, la capa de transport pot estar involucrada en la optimitzacció de l'ús dels serveis de xarxa. Es a dir; pot proporcionar la qualitat del servei que s'hagi solicitat. Per exemple, l'entitat de sessió pot solicitar una tasa d'error determinada, un retard màxim, una prioritat i un nivell de seguretat donat.  
Línea 42: Línea 43:
Té funcions similars al nivell d'enllaç (salt a salt) però entre dues màquines que no estan connectades directament (extrem a extrem)
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ó
:*'''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í
:*'''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
*'''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
Línea 55: Línea 56:
:*'''Primitives de transport''': Poques aplicacions han de tractar les xarxes a un nivell inferior que el de transport i aquest nivell ja està implementat en els sistemes operatius. Però moltes han de utlitzar el les primitives per a fer ús del nivell de transport. Per aixó, aquestes han de ser fàcils d'utilitzar. Aquestes primitves són LISTEN, CONNECT, SEND, RECEIVE, DISCONNECT.
:*'''Primitives de transport''': Poques aplicacions han de tractar les xarxes a un nivell inferior que el de transport i aquest nivell ja està implementat en els sistemes operatius. Però moltes han de utlitzar el les primitives per a fer ús del nivell de transport. Per aixó, aquestes han de ser fàcils d'utilitzar. Aquestes primitves són LISTEN, CONNECT, SEND, RECEIVE, DISCONNECT.


==Serveis OSI==
==Protocol TCP==


'''Servei orientat a connexió'''
===Connexions TCP===
:*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ó'''
El protocol TCP és orientat a connexió. El següent diagrama mostra el protocol d'establiment d'una 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'''
[[Archivo:300px-Tcp-handshake.png]]
:*'''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ó ===
i aquest altre diagrama mostra el procés de terminació d'una connexió:


'''Propietats'''
[[Archivo:300px-Fin de conexión TCP.svg.png]]
:*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ó.
 
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]].
[[Archivo:Acktcp.gif]]
 
==Protocol TCP==


===Connexions TCP===
#El host A que necessita inicialitzar una connexió envia un paquet SYN (Sincronitzar) amb un número de seqüència inicial proposat per al host de destinació B.
#Quan el host B rep el missatge SYN, retorna un paquet amb els SYN i ACK en la capçalera TCP (SYN-ACK).
#Quan el host A rep el SYN-ACK, envia ACK (reconeixement).
#Host B rep ACK i en aquesta etapa s'estableix la connexió.


El protocol TCP és orientat a connexió. El següent diagrama mostra el protocol d'establiment d'una connexió:
*En cas de que el host B no tinga el port disponible, no fà el segon pas, sino que envia un missatge de RST per rebujar la connexió.


[[Archivo:300px-Tcp-handshake.png]]
Terminació de la connexió.


i aquest altre diagrama mostra el procés de terminació d'una connexió:
Quan la transmissió de dades es completa i el host vol acabar la connexió, s'inicia el procés de terminació. A diferència d'establiment de connexió TCP, que utilitza tres vies, la terminació utilitza quatre vies. La connexió s'acaba quan ambdues parts hagin acabat el procediment d'apagada mitjançant l'enviament d'un FIN i rebre un ACK.


[[Archivo:300px-Fin de conexión TCP.svg.png]]
#El host A, que necessita per acabar la connexió, envia un missatge especial amb el FIN (acabat), que indica que ha acabat d'enviar les dades.
#El host B, que rep el segment FIN, no finalitza la connexió sinó que entra en un estat de "tancament passiu" (CLOSE_WAIT) i envia el ACK per al FIN de tornada al host A. Ara el host B entra en estat LAST_ACK. En aquest punt el host B no acceptarà dades del host A, però pot continuar transmetre dades al host A. Si el host B no té dades per transmetre al host A, també acabarà la connexió mitjançant l'enviament d'segment FIN.
#Quan el host A rep l'ACK passat des del host B, entra en un estat (TIME_WAIT) i envia un ACK de tornada al host B.
#Host B rep l'ACK des del host A i tanca la connexió.


:*http://wiki.mikrotik.com/wiki/Manual:Connection_oriented_communication_%28TCP/IP%29
:*http://wiki.mikrotik.com/wiki/Manual:Connection_oriented_communication_%28TCP/IP%29
Línea 152: Línea 104:
Cal tenir en compte que les configuracions per defecte de la finestra TCP poden ser molt poc adequades per a casos específics.
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:
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
=== Límits de velocitat de TCP. ===
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 ====
In [[computer networking]], '''RWIN''' ([[TCP Receive Window]]) is the amount of [[Data (computing)|data]] that a [[computer]] can accept without acknowledging the sender. If the sender has not received acknowledgement for the first [[packet (information technology)|packet]] it sent, it will stop and wait and if this wait exceeds a certain limit, it may even [[Retransmission (data networks)|retransmit]]. This is how TCP achieves reliable [[data transmission]].
Even if there is no packet loss in the network, [[Tcp receive window|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===
===Estats TCP===
Línea 213: Línea 128:
[[Archivo:OSIEstats1.png|center]]
[[Archivo:OSIEstats1.png|center]]


Vegeu també [[conntrack]].
[[Archivo:800px-TCP state diagram.png|center]]
 
[[Archivo:800px-TCP state diagram.png]]


*'''ESTABLISHED''': Connexió establerta.
*'''ESTABLISHED''': Connexió establerta.
Línea 235: Línea 148:
===Capçalera TCP===
===Capçalera TCP===


[[Archivo:Tcp-headers.jpg]]
{| class="wikitable" style="text-align:center"
|+TCP Header
|-
! style="border-bottom:none; border-right:none;"| ''Offsets''
! style="border-left:none;"| [[Octet (computing)|Octet]]
! colspan="8" | 0
! colspan="8" | 1
! colspan="8" | 2
! colspan="8" | 3
|-
! style="border-top: none" | Octet
! <tt>[[Bit]]</tt>!!<tt>0</tt>!!<tt>1</tt>!!<tt>2</tt>!!<tt>3</tt>!!<tt>4</tt>!!<tt>5</tt>!!<tt>6</tt>!!<tt>7</tt>!!<tt>8</tt>!!<tt>9</tt>!!<tt>10</tt>!!<tt>11</tt>!!<tt>12</tt>!!<tt>13</tt>!!<tt>14</tt>!!<tt>15</tt>!!<tt>16</tt>!!<tt>17</tt>!!<tt>18</tt>!!<tt>19</tt>!!<tt>20</tt>!!<tt>21</tt>!!<tt>22</tt>!!<tt>23</tt>!!<tt>24</tt>!!<tt>25</tt>!!<tt>26</tt>!!<tt>27</tt>!!<tt>28</tt>!!<tt>29</tt>!!<tt>30</tt>!!<tt>31</tt>
|-
! 0
!<tt> 0</tt>
| colspan="16"| Source port || colspan="16"| Destination port
|-
! 4
!<tt>32</tt>
| colspan="32"| Sequence number
|-
! 8
!<tt>64</tt>
| colspan="32"| Acknowledgment number (if <tt>ACK</tt> set)
|-
! 12
! <tt>96</tt>
| colspan="4"| Data offset || colspan="3"| Reserved<br><tt>'''0 0 0'''</tt> || cellpadding="1"|<tt>N<br>S</tt>|||<tt>C<br>W<br>R</tt>|||<tt>E<br>C<br>E</tt>|||<tt>U<br>R<br>G</tt>|||<tt>A<br>C<br>K</tt>|||<tt>P<br>S<br>H</tt>|||<tt>R<br>S<br>T</tt>|||<tt>S<br>Y<br>N</tt>|||<tt>F<br>I<br>N</tt>|| colspan="16"| Window Size
|-
! 16
!<tt>128</tt>
|colspan="16"| Checksum || colspan="16" | Urgent pointer (if <tt>URG</tt> set)
|-
! 20<br />...
!<tt>160<br />...</tt>
| colspan="32" style="background:#ffcc88;"| Options (if Data Offset &gt; 5, padded at the end with "0" bytes if necessary)<br />...
|}
 


*'''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.
*'''Source port - bit 0 - 15'''. Port d'origen.
*'''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.
*'''Destination port - bit 16 - 31'''. Port de destí.  
*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.
*'''Sequence Number - bit 32 - 63.''' El número de seqüencia són 32 bits dedicats a saber l'ordre dels paquets enviats. S'estableix en l'ACK al principi de la connexió.  
*'''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.
*'''Acknowledgment Number - bit 64 - 95'''. Número de confirmació de recepció.  
*'''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.
*'''Data Offset - bit 96 - 99'''. Indica la longitud del encapçalament TCP en quantitat de paraules de 32 bits.  
*'''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.
*'''Reserved - bit 100 - 103'''. Bits reservats que no s'utilitzen.  
*'''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.
*''' 3 bits per al ECN'''. El ECN és una amplicació del TCP per a controlar millor la congestió.
*'''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'''. Se estableix en 1 si està actiu l'apuntador urgent.
*'''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'''. Si el bit ACK està a 1, farà cas del número de confirmació de recepció.
*'''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
*'''PSH -bit 108''' Indica que el paquet s'ha d'enviar inmediatament i no esperar a completar un paquet més gran.
*'''RST - bit 109''' Per a resetejar la connexió.
*'''SYN -bit 110''' per a establir la connexió.
*'''FIN - bit 111''' Per a lliberar una connexió.  
*El control de flux de TCP s'efectua amb una finestra corredera de mida variable. El camp '''Window size''' Indica la mida que el receptor espera rebre.
*'''Checksum 16 bits a partir del 128 ''' Suma de verificació de que la capçalera està bé.
*Les opcions serveixen per a coses que el encapçalament no pot indicar i els hosts poden necessitar. Per exemple, la càrrega útil.
*Les opcions s'han d'omplir de 0 fins a arrivar a un múltiplo de 32 bits.
* Al final estàn les dades.


===Ports===
===Ports===
Wikipedia: [http://en.wikipedia.org/wiki/TCP_and_UDP_port Ports]


:*Un port és una connexió virtual que pot ser utilitzada per les aplicacions per intercanviar dades.
:*Un port és una connexió virtual que pot ser utilitzada per les aplicacions per intercanviar dades.
Línea 256: Línea 215:
:*Cada port esta associat a un servei per la IANA
:*Cada port esta associat a un servei per la IANA
:*Els ports per defecte dels serveis es poden canviar
:*Els ports per defecte dels serveis es poden canviar
:*Els ports s'identifiquen amb una paraula de 16 bits i poden ser 65535
:*El port 0 no es deu utilitzar. Està reservat per als programadors per a que signifique qualsevol port i el sistema operatiu puga escollirlo del rang de ports efímers.
:*Els ports efímers són utilitzats per a les connexions puntuals de eixida de programes clients. Quant termina la connexió, el port es tanca. [http://en.wikipedia.org/wiki/Ephemeral_port]
:* Existeix un rang de ports efímers que, en Linux es pot consultar o modificar:
$ cat /proc/sys/net/ipv4/ip_local_port_range
:* Fins al port 1024 són port reservats per als serveis conneguts de xarxa i sols poden ser oberts per root.


Una llista possible dels ports més habituals
Una llista possible dels ports més habituals
Línea 275: Línea 240:
:*'''[[995]]''': [[POP3]] segur
:*'''[[995]]''': [[POP3]] segur


Consulteu també [[/etc/services]].
 


====Sockets====
====Sockets====
Línea 294: Línea 259:
'''Components'''
'''Components'''
:*Tipus: Datagrama o Stream. Camí absolut del fitxer
:*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''':
'''Sockets TCP/IP''':
Línea 306: Línea 268:
:*Adreça IP remota
:*Adreça IP remota
:*Número de port remot
:*Número de port remot
[[Archivo:Sockets.png|center]]
[[Archivo:Sockets1.png|center]]
[[Archivo:Sockets3.png|center]]
[[Archivo:Sockets4.png|center]]
===Exemple de connexió TCP amb Telnet===
Consulteu [[Telnet#Telnet_com_a_eina_per_a_obrir_connexions_TCP]].


== Protocol UDP ==
== Protocol UDP ==
Línea 339: Línea 292:
== Network Address Translation (NAT) ==
== Network Address Translation (NAT) ==


Consulteu l'article [[Network Address Translation (NAT)]].
[[NAT]]


== Vegeu també ==
== Vegeu també ==
Línea 347: Línea 300:


== Enllaços externs ==
== Enllaços externs ==
*http://iptables-tutorial.frozentux.net/chunkyhtml/index.html


Gran part d'aquesta entrada està feta amb materials de [http://acacha.org/mediawiki/index.php/Nivell_de_transport_TCP/IP]
Gran part d'aquesta entrada està feta amb materials de [http://acacha.org/mediawiki/index.php/Nivell_de_transport_TCP/IP]

Revisión actual - 16:07 15 feb 2013

La capa de transport es troba entre la capa d'aplicació i la Capa de xarxa del model TCP/IP. Dins del model de referència OSI, la capa de transport es trobaria entre la capa de sessió i la capa de xarxa.

Funcions de la Capa de Transport

La capa de transport és la part del protocol TCP/IP encarregada de garantir la transmissió de les dades.

La Capa de xarxa transfereix datagrames entre dos ordinadors per la xarxa utilitzant com a identificadors les adreces IP. La capa de transport és l'encarregada d'afegir la noció de port. Amés, la capa de xarxa s'encarrega de enviar el paquet per distints enrutadors, topologíes i tecnologíes de transmisió. La capa de xarxa pot fallar en algun paquet o poden arrivar desordenats. De la recuperació dels paquets i la ordenació s'encarrega la capa de transport.

Dins d'una mateixa computadora hi pot haver més d'una aplicació que estigui accedint simultàniament a la xarxa. Per aquest motiu, quan s'envia un datagrama no en tenim prou amb l'adreça IP de la màquina de destí, necessitem també indicar a quina aplicació estem enviant la informació. Cada aplicació que estigui esperant un missatge utilitzarà un port diferent; estarà a l'espera d'un missatge en un port concret (escoltant un port). S'utilitzarà també un port concret per a l'enviament de missatges.

Els ports tenen una memòria intermitja (buffer, en anglès) situada entre els programes d'aplicació i la xarxa, de tal manera que les aplicacions transmeten la informació als ports, aquí es van emmagatzemant fins que pugui enviar-se per la xarxa. Un cop transmès arribarà al port destí on s'anirà guardant fins que l'aplicació estigui preparada per a rebre-la.

A més, la capa de transport proporciona un mecanisme per intercanviar les dades entre sistemes finals. El servei de transport orientat a connexió assegura que les dades s'entreguin lliures d'errors, en ordre i sense pèrdues ni duplicacions. És més, la capa de transport pot estar involucrada en la optimitzacció de l'ús dels serveis de xarxa. Es a dir; pot proporcionar la qualitat del servei que s'hagi solicitat. Per exemple, l'entitat de sessió pot solicitar una tasa d'error determinada, un retard màxim, una prioritat i un nivell de seguretat donat.

Existeixen dos protocols principals dins d'aquesta capa:

  • TCP (Transfer Control Protocol). Ofereix una transferència fiable i orientada a connexió.
  • UDP (User Datagram Protocol). Ofereix una transferència no fiable i no orientada a connexió.

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.

NIvelltransport.png

É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
  • Primitives de transport: Poques aplicacions han de tractar les xarxes a un nivell inferior que el de transport i aquest nivell ja està implementat en els sistemes operatius. Però moltes han de utlitzar el les primitives per a fer ús del nivell de transport. Per aixó, aquestes han de ser fàcils d'utilitzar. Aquestes primitves són LISTEN, CONNECT, SEND, RECEIVE, DISCONNECT.

Protocol TCP

Connexions TCP

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

300px-Tcp-handshake.png

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

300px-Fin de conexión TCP.svg.png

Acktcp.gif

  1. El host A que necessita inicialitzar una connexió envia un paquet SYN (Sincronitzar) amb un número de seqüència inicial proposat per al host de destinació B.
  2. Quan el host B rep el missatge SYN, retorna un paquet amb els SYN i ACK en la capçalera TCP (SYN-ACK).
  3. Quan el host A rep el SYN-ACK, envia ACK (reconeixement).
  4. Host B rep ACK i en aquesta etapa s'estableix la connexió.
  • En cas de que el host B no tinga el port disponible, no fà el segon pas, sino que envia un missatge de RST per rebujar la connexió.

Terminació de la connexió.

Quan la transmissió de dades es completa i el host vol acabar la connexió, s'inicia el procés de terminació. A diferència d'establiment de connexió TCP, que utilitza tres vies, la terminació utilitza quatre vies. La connexió s'acaba quan ambdues parts hagin acabat el procediment d'apagada mitjançant l'enviament d'un FIN i rebre un ACK.

  1. El host A, que necessita per acabar la connexió, envia un missatge especial amb el FIN (acabat), que indica que ha acabat d'enviar les dades.
  2. El host B, que rep el segment FIN, no finalitza la connexió sinó que entra en un estat de "tancament passiu" (CLOSE_WAIT) i envia el ACK per al FIN de tornada al host A. Ara el host B entra en estat LAST_ACK. En aquest punt el host B no acceptarà dades del host A, però pot continuar transmetre dades al host A. Si el host B no té dades per transmetre al host A, també acabarà la connexió mitjançant l'enviament d'segment FIN.
  3. Quan el host A rep l'ACK passat des del host B, entra en un estat (TIME_WAIT) i envia un ACK de tornada al host B.
  4. Host B rep l'ACK des del host A i tanca la connexió.

Segments transmission (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.

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, aicò 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.

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.


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:

OSIEstats.png

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

OSIEstats1.png
800px-TCP state diagram.png
  • 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:

TimeOutsTCPConnections.jpg

Capçalera TCP

TCP Header
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source port Destination port
4 32 Sequence number
8 64 Acknowledgment number (if ACK set)
12 96 Data offset Reserved
0 0 0		 N
S		 C
W
R		 E
C
E		 U
R
G		 A
C
K		 P
S
H		 R
S
T		 S
Y
N		 F
I
N		 Window Size
16 128 Checksum Urgent pointer (if URG set)
20
... 		160
... 		Options (if Data Offset > 5, padded at the end with "0" bytes if necessary)
...


  • Source port - bit 0 - 15. Port d'origen.
  • Destination port - bit 16 - 31. Port de destí.
  • Sequence Number - bit 32 - 63. El número de seqüencia són 32 bits dedicats a saber l'ordre dels paquets enviats. S'estableix en l'ACK al principi de la connexió.
  • Acknowledgment Number - bit 64 - 95. Número de confirmació de recepció.
  • Data Offset - bit 96 - 99. Indica la longitud del encapçalament TCP en quantitat de paraules de 32 bits.
  • Reserved - bit 100 - 103. Bits reservats que no s'utilitzen.
  • 3 bits per al ECN. El ECN és una amplicació del TCP per a controlar millor la congestió.
  • URG - bit 106. Se estableix en 1 si està actiu l'apuntador urgent.
  • ACK - bit 107. Si el bit ACK està a 1, farà cas del número de confirmació de recepció.
  • PSH -bit 108 Indica que el paquet s'ha d'enviar inmediatament i no esperar a completar un paquet més gran.
  • RST - bit 109 Per a resetejar la connexió.
  • SYN -bit 110 per a establir la connexió.
  • FIN - bit 111 Per a lliberar una connexió.
  • El control de flux de TCP s'efectua amb una finestra corredera de mida variable. El camp Window size Indica la mida que el receptor espera rebre.
  • Checksum 16 bits a partir del 128 Suma de verificació de que la capçalera està bé.
  • Les opcions serveixen per a coses que el encapçalament no pot indicar i els hosts poden necessitar. Per exemple, la càrrega útil.
  • Les opcions s'han d'omplir de 0 fins a arrivar a un múltiplo de 32 bits.
  • Al final estàn les dades.

Ports

Wikipedia: 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
  • Els ports s'identifiquen amb una paraula de 16 bits i poden ser 65535
  • El port 0 no es deu utilitzar. Està reservat per als programadors per a que signifique qualsevol port i el sistema operatiu puga escollirlo del rang de ports efímers.
  • Els ports efímers són utilitzats per a les connexions puntuals de eixida de programes clients. Quant termina la connexió, el port es tanca. [1]
  • Existeix un rang de ports efímers que, en Linux es pot consultar o modificar:
$ cat /proc/sys/net/ipv4/ip_local_port_range
  • Fins al port 1024 són port reservats per als serveis conneguts de xarxa i sols poden ser oberts per root.

Una llista possible dels ports més habituals


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

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

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

Segment UDP

SegmentUDP.png

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)
TCPvsUDP.png

Network Address Translation (NAT)

NAT

Vegeu també

Enllaços externs

Gran part d'aquesta entrada està feta amb materials de [2]

Obtenido de «https://castilloinformatica.es/wiki/index.php?title=Capa_de_transport&oldid=955»