IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

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

NIVELL DE TRANSPORT 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.
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

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ó:

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

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

Exemples: A mode d'exemple no és el mateix que al intentar accedir com a client per el

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.

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.

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

Vegeu també conntrack.

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-headers.jpg


  • 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

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
Sockets.png
Sockets1.png
Sockets3.png
Sockets4.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

Serveis sense 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


====Serveis sense connexió==== (pag 219 passar) 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


Datagrames
  • S'envien directament paquets de l'emissor al receptor sense establir prèviament una connexió.
User Datagram Protocol (UDP)
  • No és una connexió fiable, ja que els paquets poden arribar en qualsevol ordre, duplicats, es poden perdre...
  • Protocols:
•DNS, DHCP, VoIP, Videoconferència, jocs en xarxa.
Ports

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

[email protected]:~$ cat /etc/services | more
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, officially ports have two entries
# even if the protocol doesn't support UDP operations.
#
# Updated from http://www.iana.org/assignments/port-numbers and other
# sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services .
# New ports will be added on request if they have been officially assigned
# by IANA and used in the real-world or are needed by a debian package.
# If you need a huge list of used numbers please install the nmap package.

tcpmux          1/tcp                           # TCP port service multiplexer
echo            7/tcp
echo            7/udp
discard         9/tcp           sink null
discard         9/udp           sink null
systat          11/tcp          users
daytime         13/tcp

Sockets

(enchufes) Posar captura pàg 223

  • Sockets

Dispositius virtuals de comunicacions bidireccionals.

  • Hi han tantes famílies de sockets com protocols
    • Unix Domain Sockets
    • Internet Sockets (TCP, UDP i RAW)
Unix domain socket

srwxrwxrwx/var/run/mysqld/mysqld.sock 07:42 /var/run/mysqld/mysqld.sock Quan comença en s --> socket

Sockets d'Internet

IMPORTANT -si es TCP o UDP -Adreça i port van en parells

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

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

UDPCAST

Instal·lació
$ sudo apt-get install udpcast

Els fitxers instal·lats són:

$ dpkg -L udpcast
/.
/usr
/usr/bin
/usr/bin/udp-sender
/usr/bin/udp-receiver
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/udp-sender.1.gz
/usr/share/man/man1/udp-receiver.1.gz
/usr/share/doc
/usr/share/doc/udpcast
/usr/share/doc/udpcast/copyright
/usr/share/doc/udpcast/changelog.Debian.gz
Tunning

Tuning hints:

  • Chose the proper duplex mode: if your network has a Hub, use --half-duplex, if it has a switch, use --full-duplex. If the network is mixed (central switch, hubs around), use --half-duplex
  • If you have a switch:
  • enable "IGMP snooping".
  • If hubs are connected to your switch, disable flow control on the ports to which the hubs are connected. Disable flow control is also necessary (on all ports where udp-senders site) if IGMP snooping is not available or not working correctly.
  • Disable Broadcast Storm Control (or else the switch might consider the udpcast session as a broadcast storm, and slow it down...)
  • If too many retransmissions happen in full-duplex mode, consider lowering the slice size using the --slice-size option (default is 112).

Undulatus Asperatus Clouds Nothing is impossible

Considering these, change parameters as follows:

  • If you observe long stretches of lost packets, increase interleave
  • If you observe that transfer is slowed down by CPU saturation, decrease redundancy and stripesize proportionnally.
  • If you observe big variations in packet loss rate, increase redundancy and stripesize proportionnally.
  • If you just observe high loss, but not necessarily clustered in any special way, increase redundancy or decrease stripesize
  • Be aware that network equipment or the receiver may be dropping packets because of a bandwidth which is too high. Try limiting it using max-bitrate
  • The receiver may also be dropping packets because it cannot write the data to disk fast enough. Use hdparm to optimize disk access on the receiver. Try playing with the settings in /proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max, i.e. setting them to a higher value.


udp-sender

Un exemple de udp-sender (cas extret d'una execució de DRBL):

[email protected]:~$ cat /home/rafelmelich/Baixades/ubuntu-12.10-desktop-i386.iso | udp-sender --full-duplex --min-clients 2 --max-wait 200 --interface eth0 --nokbd --mcast-all-addr  224.0.0.1 --portbase 2232 --ttl 1
Udp-sender 20100130
Using mcast address 232.168.204.226
UDP sender for (stdin) at 192.168.204.226 on eth0 
Broadcasting control to 224.0.0.1
New connection from 192.168.204.100  (#0) 00000009
Starting transfer: 00000009
bytes=134 730 960  re-xmits=0000000 (  0.0%) slice=0112 -   00
Disconnecting #0 (192.168.204.100)
bytes=137 013 968  re-xmits=0000000 (  0.0%) slice=0112 -   0
Transfer complete.


NOTA: Si el paquet multicast ha de passar per encaminadors, aleshores cal augmentar el TTL

La màquina que executa udp-sender envia un paquet multicast a l'adreça 224.0.0.1 (totes les màquines multicast):

$ sudo tcpdump -i eth0 -n ip multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:22:05.203830 IP 192.168.204.115.2233 > 224.0.0.1.2232: UDP, length 28
13:32:47.335759 IP 192.168.204.100.2232 > 224.0.0.1.2233: UDP, length 12
13:32:47.335838 IP 192.168.204.100.2232 > 224.0.0.1.2233: UDP, length 12
13:32:47.351201 IP 192.168.204.100 > 232.168.0.8: igmp v1 report 232.168.0.8
13:32:50.791182 IP 192.168.204.100 > 232.168.0.8: igmp v1 report 232.168.0.8
13:32:51.381170 IP 192.168.204.100 > 232.168.0.8: igmp v1 report 232.168.0.8


Recursos

Exemple amb broadcast
# cat /home/partimag/2009-04-29-19-img-FestaUbuntuAula5/sda1 | udp-sender --full-duplex --min-clients 5 --max-wait 300 --interface eth0 --nokbd 
Udp-sender 2008-12-13
Using mcast address 232.168.0.8
UDP sender for (stdin) at 192.168.0.8 on eth0 
Broadcasting control to 192.168.0.255

La màquina que executa udp-sender envia un paquet de broadcast a la xarxa:

# tcpdump -i eth0 host 192.168.0.255
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:16:43.150553 IP 192.168.0.8.9001 > 192.168.0.255.9000: UDP, length 
[email protected]:~$ udp-receiver --file=/tmp/test
Udp-receiver 20100130
UDP receiver for /tmp/test at 192.168.204.226 on eth0
received message, cap=00000009
Connected as #0 to 192.168.204.215
Listening to multicast on 232.168.204.215
Press any key to start receiving data!
Sending go signal
bytes=729 067 520  ( 37.03 Mbps))
Transfer complete.
udp-receiver

Un exemple de udp-sender (cas extret d'una execució de DRBL):

$ udp-receiver $udp_receiver_extra_opt_default --nokbd --mcast-all-addr $MULTICAST_ALL_ADDR --portbase $port $TIME_TO_LIVE_OPT

És a dir

$ udp-receiver --nokbd --mcast-all-addr 224.0.0.1 --portbase 2232 --ttl 1

Recursos

Adreça multicast

Udpcast utilitza per defecte una adreça multicast que es genera a partir de la IP de l'emissor. Es treu el primer octet de la IP de l'emisor i la resta de la IP s'afegeix a 232.

Per exemple si l'emissor té la IP:

192.168.0.8

L'adreça de multicast per defecte de udpcast serà:

232.168.0.8

Ho podeu comprovar a l'executar udp-sender:

$ cat /home/partimag/2009-04-29-19-img-FestaUbuntuAula5/sda1 | udp-sender --full-duplex --min-clients 5 --max-wait 300 --interface eth0 --nokbd 
--mcast-all-addr 224.0.0.1 --portbase 2232
Udp-sender 2008-12-13
Using mcast address 232.168.0.8
UDP sender for (stdin) at 192.168.0.8 on eth0
...
Exemple

Vegem un exemple de com enviar un fitxer amb udpcast.

La màquina emissora del fitxer ha d'enviar el fitxer amb la comanda udp-sender. Per exemple, suposem que volem enviar una imatge ISO d'Ubuntu, a múltiples màquines al mateix temps. Amb multicast podem estalviar molt ample de banda i temps:

$ udp-sender --file=/home/sergi/downloads/ubuntu-8.04.1-desktop-i386.iso 
Udp-sender 2008-12-13
Using full duplex mode
Using mcast address 232.168.1.33
UDP sender for /home/sergi/downloads/ubuntu-8.04.1-desktop-i386.iso at 192.168.1.33 on eth0 
Broadcasting control to 192.168.1.255

(No cal ser superusuari per utilitzar udpcast).

Hem executat aquest exemple a una xarxa privada de classe C 192.168.1.0/24. Com podeu veure amb ipcalc:

$ ipcalc 192.168.1.0/24
Address:   192.168.1.0          11000000.10101000.00000001. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.1.0/24       11000000.10101000.00000001. 00000000
HostMin:   192.168.1.1          11000000.10101000.00000001. 00000001
HostMax:   192.168.1.254        11000000.10101000.00000001. 11111110
Broadcast: 192.168.1.255        11000000.10101000.00000001. 11111111
Hosts/Net: 254                   Class C, Private Internet

L'adreça de broadcast és 192.168.1.255. Com podeu veure s'envia un paquet a tota la xarxa. Aquest paquet és de tipus UDP i indicat a tots els possibles clients (receptors) que s'ha iniciat els servei multicast.

Si en un client executem:

$ sudo tcpdump -n -i eth0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

09:15:17.352831 IP 192.168.1.33.9001 > 192.168.1.255.9000: UDP, length 28

Veurem com l'emissor (que té la IP 192.168.1.33) ha enviat el paquet HELLO a tota xarxa. Udpcast, per defecte, utilitza els ports 9000 i 9001.

Els clients que vulguin rebre aquest fitxer, han d'executar:

$ udp-receiver --file=/tmp/test
Udp-receiver 2004-05-31
UDP receiver for /tmp/test at 192.168.1.38 on eth0
received message, cap=00000009
Connected as #0 to 192.168.1.33
Listening to multicast on 232.168.1.33
Press any key to start receiving data!

Com podeu veure amb ipcalc, l'adreça 232.168.1.33 és de multicast

$ ipcalc 232.168.1.33
Address:   232.168.1.33         11101000.10101000.00000001. 00100001
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   232.168.1.0/24       11101000.10101000.00000001. 00000000
HostMin:   232.168.1.1          11101000.10101000.00000001. 00000001
HostMax:   232.168.1.254        11101000.10101000.00000001. 11111110
Broadcast: 232.168.1.255        11101000.10101000.00000001. 11111111
Hosts/Net: 254                   Class D, Multicast

El receptor enviarà un paquet a tota la xarxa per indicar que està preparat:

$ sudo tcpdump -n -i eth0 
09:19:18.839434 IP 192.168.1.38.9000 > 192.168.1.255.9001: UDP, length 12
09:19:18.839906 IP 192.168.1.38.9000 > 192.168.1.255.9001: UDP, length 12
09:19:18.840489 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 32
09:19:18.845993 IP 192.168.1.38 > 224.0.0.22: igmp v3 report, 1 group record(s)
09:19:28.161997 IP 192.168.1.38 > 224.0.0.22: igmp v3 report, 1 group record(s)

Abans de premer qualsevol tecla, s'inicien la resta de clients. Un cop tingueu tots els clients en espera, un d'ells inicia la transmissió i tots comencen a rebre paquets UDP:

09:21:50.753165 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 1472
09:21:50.753171 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 1472
09:21:50.753177 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 1472
09:21:50.753183 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 1472
09:21:50.753190 IP 192.168.1.33.9001 > 192.168.1.38.9000: UDP, length 1472

Recursos:

Fitxers de log

Es pot consultar el fitxer /var/log/messages o el fitxer /var/log/syslog:

$  tail -f /var/log/messages
May  4 09:09:30 SistemaFitxers udpcast[27925]: New connection from 192.168.0.7  (#0) 
May  4 09:09:32 SistemaFitxers udpcast[27925]: max wait[300] passed: starting
May  4 09:09:32 SistemaFitxers udpcast[27925]: Starting transfer: file[] pipe[] port[2232] if[eth0] participants[1]
May  4 09:10:50 SistemaFitxers udpcast[27925]: Transfer complete.
May  4 09:10:50 SistemaFitxers udpcast[27925]: Disconnecting #0 (192.168.0.7)


Aquest exemple correspon a les següents execucions de udp-sender i udp-receiver:

$ cat /home/partimag/2009-04-29-19-img-FestaUbuntuAula5/sda1 | udp-sender --full-duplex --min-clients 5 --max-wait 300 --interface eth0 --nokbd 
--mcast-all-addr 224.0.0.1 --portbase 2232 --ttl 1

i

$ sudo udp-receiver --file=/tmp/test --mcast-all-addr 224.0.0.1 --portbase 2232
Udp-receiver 2004-05-31
UDP receiver for /tmp/test at 192.168.0.7 on eth0
received message, cap=00000009
Connected as #0 to 192.168.0.8
Listening to multicast on 232.168.0.8
Press any key to start receiving data!
bytes=    481 472 992  ( 89.71 Mbps)    481 308 672
bytes=    851 687 443  ( 86.67 Mbps)    851 687 443
Resolució de problemes

MULTICAST

Grups Multicast

Les adreces IP estan dividides en classes:

Bit -->  0                           31            Address Range:
          +-+----------------------------+
          |0|       Class A Address      |       0.0.0.0 - 127.255.255.255
          +-+----------------------------+
          +-+-+--------------------------+
          |1 0|     Class B Address      |     128.0.0.0 - 191.255.255.255
          +-+-+--------------------------+
          +-+-+-+------------------------+
          |1 1 0|   Class C Address      |     192.0.0.0 - 223.255.255.255
          +-+-+-+------------------------+
          +-+-+-+-+----------------------+
          |1 1 1 0|  MULTICAST Address   |     224.0.0.0 - 239.255.255.255
          +-+-+-+-+----------------------+
          +-+-+-+-+-+--------------------+
          |1 1 1 1 0|     Reserved       |     240.0.0.0 - 247.255.255.255
          +-+-+-+-+-+--------------------+

Les IPs de clase D són les IP Multicast i s'identifiquen de la resta perquè són aquelles IP que comencen per 1110. La eina Ipcalc us permet obtenir informació sobre una IP:


[email protected]:~$ sudo tcpdump -i eth0 ip multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:03:36.819887 IP xavi-client1.local > all-systems.mcast.net: ICMP echo request, id 30499, seq 32, length 64
17:03:36.879972 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 197, length 64
17:03:37.192757 IP a204pcprofe.aula204.iesebre.com.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 100.255.255.239.in-addr.arpa. (46)
17:03:37.296782 IP SGBD-Virtual1.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
17:03:37.369619 IP a204PC12.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3914, seq 76, length 64
17:03:37.596406 IP a204pcprofe.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3801, seq 209, length 64
17:03:37.792208 IP xavi-client1.local > all-systems.mcast.net: ICMP echo request, id 30499, seq 33, length 64
17:03:37.880980 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 198, length 64
17:03:37.952976 IP 192.168.140.116 > 239.255.255.100: igmp v1 report 239.255.255.100 [len 72]
17:03:38.300480 IP SGBD-Virtual1.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
17:03:38.370245 IP a204PC12.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3914, seq 77, length 64
17:03:38.597800 IP a204pcprofe.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3801, seq 210, length 64
17:03:38.781312 IP 192.168.140.115 > 239.255.255.100: igmp v1 report 239.255.255.100 [len 72]
17:03:38.804714 IP xavi-client1.local > all-systems.mcast.net: ICMP echo request, id 30499, seq 34, length 64
17:03:38.883889 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 199, length 64
17:03:39.190079 IP a204pcprofe.aula204.iesebre.com.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 121.140.168.192.in-addr.arpa. (46)
17:03:39.371827 IP a204PC12.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3914, seq 78, length 64
17:03:39.563503 IP DGM-ASUS.local > all-systems.mcast.net: ICMP echo request, id 5398, seq 1, length 64
17:03:39.598385 IP a204pcprofe.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3801, seq 211, length 64
17:03:39.793952 IP xavi-client1.local > all-systems.mcast.net: ICMP echo request, id 30499, seq 35, length 64
17:03:39.885627 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 200, length 64
17:03:40.191286 IP a204pcprofe.aula204.iesebre.com.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 121.140.168.192.in-addr.arpa. (46)
17:03:40.300439 IP SGBD-Virtual1.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42)
17:03:40.371942 IP a204PC12.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3914, seq 79, length 64
17:03:40.598883 IP a204pcprofe.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3801, seq 212, length 64
17:03:40.887292 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 201, length 64
17:03:41.233363 IP portatil.local > 239.255.255.250: igmp v2 report 239.255.255.250
17:03:41.372951 IP a204PC12.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3914, seq 80, length 64
17:03:41.599930 IP a204pcprofe.aula204.iesebre.com > all-systems.mcast.net: ICMP echo request, id 3801, seq 213, length 64
17:03:41.890070 IP SGBD-Virtual1.local > all-systems.mcast.net: ICMP echo request, id 7506, seq 202, length 64
17:03:42.191174 IP a204pcprofe.aula204.iesebre.com.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 121.140.168.192.in-addr.arpa. (46)
^C17:03:42.208628 IP a204PC07.aula204.iesebre.com.17500 > 255.255.255.255.17500: UDP, length 123

32 packets captured
139 packets received by filter
80 packets dropped by kernel


[email protected]:~$ sudo netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      all-systems.mcast.net
eth0            1      224.0.0.251
eth0            2      all-systems.mcast.net
lo              1      ip6-allnodes
eth0            1      ff02::fb
eth0            1      ff02::1:ffdb:7f10
eth0            1      ip6-allnodes


[email protected]:~$ sudo netstat -n
[sudo] password for rafelmelich: 
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 192.168.204.226:36249   173.194.41.226:80       ESTABLISHED
tcp        0      0 192.168.204.226:48821   173.194.41.2:80         ESTABLISHED
tcp        1      0 192.168.204.226:37512   91.189.88.33:80         CLOSE_WAIT 
tcp        1      0 192.168.204.226:37514   91.189.88.33:80         CLOSE_WAIT 
tcp        1      0 192.168.204.226:37515   91.189.88.33:80         CLOSE_WAIT 
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  15     [ ]         DGRAM                    6295     /dev/log
unix  2      [ ]         DGRAM                    21306    
unix  3      [ ]         STREAM     CONNECTED     21118    /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     CONNECTED     21117    
unix  2      [ ]         DGRAM                    21116    
unix  3      [ ]         STREAM     CONNECTED     20122    /home/rafelmelich/.pulse/d44f13d6439bf9284433b7940000002c-runtime/native
unix  3      [ ]         STREAM     CONNECTED     20121

Que cal mirar si no funciona?

Si es treballa amb un concentrador (HUB) cal indicar la opció:

--half-duplex

Si és un commutador (switch) aleshores cal utilitzar:

--full-duplex

Si la xarxa és mixta, aleshores cal utilitzar --half-duplex

Al commutador cal:

  • Que permeti "IGMP snooping"
  • Desactivar Broadcast Storm Control (sinó udpcast serà ralentitzat pel commutador )
  • Si hi han massa retransmission baixeu el valor de --slice-size option (per defecte 112).
Com descomprimir un fitxer en recepció?

Utilitzant una pipe o indicant el paràmetre:

$ udp-receiver --pipe "gzip -dc"

O

$ udp-receiver -p "gzip -dc" 

es pot utilitzar gzip o altres sistemes de compressió com lzop.

Enviar una imatge de disc

Es pot enviar tot un disc dur amb:

$ udp-sender –file /dev/sda -pipe "lzop"

O una partició amb:

$ udp-sender –file /dev/sda1 -pipe "lzop"

És millor que la partició no estigui en ús (estigui desmuntada).

Vegeu també

Udpcast és utilitzat per DRBL i clonezilla.

Enllaços externs

netstat

  • Netstat (network statistics) és una comanda que ens mostra les connexions de xarxa, les taules de rutes i altres estadístiques de la xarxa.

Taula de rutes

  • Per consultar la taula de rutes equivalet a realitzar un traceroute
[email protected]:~$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.204.1   0.0.0.0         UG        0 0          0 eth2
192.168.204.0   *               255.255.255.0   U         0 0          0 eth2

o també

[email protected]:~$ sudo netstat -rn  -->(en valors numèrics)
[sudo] password for rafel: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.204.1   0.0.0.0         UG        0 0          0 eth2
192.168.204.0   0.0.0.0         255.255.255.0   U         0 0          0 eth2

Taula d'interfícies de xarxa

  • com un ifconfig
[email protected]:~$ netstat -ie
Kernel Interface table
eth2      Link encap:Ethernet  HWaddr 00:30:05:eb:3b:44  
          inet addr:192.168.204.118  Bcast:192.168.204.255  Mask:255.255.255.0
          inet6 addr: fe80::230:5ff:feeb:3b44/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:228751 errors:0 dropped:0 overruns:0 frame:0
          TX packets:161542 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:178685881 (178.6 MB)  TX bytes:13580521 (13.5 MB)
          Interrupt:23 Base address:0x8000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:10634 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10634 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1032701 (1.0 MB)  TX bytes:1032701 (1.0 MB)

Estadístiques



[email protected]:~$ sudo netstat -i
Kernel Interface table
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth2       1500 0    221661      0      0 0        157681      0      0      0 BMRU
lo        16436 0     10225      0      0 0         10225      0      0      0 LRU
[email protected]:~$ sudo netstat -s
Ip:
    224563 total packets received
    25 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    223374 incoming packets delivered
    164847 requests sent out
    2 dropped because of missing route
Icmp:
    3007 ICMP messages received
    42 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 122
        timeout in transit: 71
        echo requests: 86
        echo replies: 2728
    3485 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 119
        echo request: 3322
        echo replies: 44
IcmpMsg:
        InType0: 2728
        InType3: 122
        InType8: 86
        InType11: 71
        OutType0: 44
        OutType3: 119
        OutType8: 3322
Tcp:
    1465 active connections openings
    5 passive connection openings
    17 failed connection attempts
    25 connection resets received
    3 connections established
    202393 segments received
    66990 segments send out
    92 segments retransmited
    0 bad segments received.
    4665 resets sent
Udp:
    13560 packets received
    119 packets to unknown port received.
    0 packet receive errors
    5161 packets sent
UdpLite:
TcpExt:
    16 resets received for embryonic SYN_RECV sockets
    659 TCP sockets finished time wait in fast timer
    644 delayed acks sent
    Quick ack mode was activated 94 times
    6 packets directly queued to recvmsg prequeue.
    60544 bytes directly in process context from backlog
    5 bytes directly received in process context from prequeue
    108960 packet headers predicted
    42 packets header predicted and directly queued to user
    2582 acknowledgments not containing data payload received
    919 predicted acknowledgments
    52 congestion windows recovered without slow start after partial ack
    65 other TCP timeouts
    90 DSACKs sent for old packets
    21 DSACKs received
    39 connections reset due to unexpected data
    11 connections reset due to early user close
    4 connections aborted due to timeout
    TCPDSACKIgnoredNoUndo: 1
    TCPSackShiftFallback: 21
    TCPDeferAcceptDrop: 5
IpExt:
    InMcastPkts: 3869
    OutMcastPkts: 101
    InBcastPkts: 10386
    OutBcastPkts: 1234
    InOctets: 173591993
    OutOctets: 11365026
    InMcastOctets: 237997
    OutMcastOctets: 8232
    InBcastOctets: 1997923
    OutBcastOctets: 207360

[email protected]:~$ sudo watch netstat -n 1

Every 2,0s: netstat -n 1                                                                                                                  Mon Feb  4 21:36:03 2013

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp       38      0 192.168.204.118:50142   199.47.216.177:443      CLOSE_WAIT
tcp        0      0 192.168.204.118:49324   108.160.160.164:80      ESTABLISHED
tcp        0      0 192.168.204.118:39586   173.194.44.39:80        ESTABLISHED
tcp        1      0 192.168.204.118:37726   91.189.89.144:80        CLOSE_WAIT
tcp       38      0 192.168.204.118:40242   108.160.161.177:443     CLOSE_WAIT
tcp       38      0 192.168.204.118:37679   107.20.249.77:443       CLOSE_WAIT
tcp       38      0 192.168.204.118:40915   108.160.160.177:443     CLOSE_WAIT
tcp       38      0 192.168.204.118:50214   108.160.160.178:443     CLOSE_WAIT
tcp        0      0 192.168.204.118:54036   173.194.44.40:80        ESTABLISHED
udp        0      0 127.0.0.1:55099         127.0.0.1:55099         ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  15     [ ]         DGRAM                    7947     /dev/log
unix  2      [ ]         DGRAM                    10099    @  ^ ^
unix  2      [ ]         DGRAM                    3439489
unix  2      [ ]         DGRAM                    3439486
unix  3      [ ]         STREAM     CONNECTED     3429257  /var/run/cups/cups.sock
unix  3      [ ]         STREAM     CONNECTED     3432614
unix  3      [ ]         STREAM     CONNECTED     3257510  @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     3256769
unix  3      [ ]         STREAM     CONNECTED     3256767  @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     3256766
unix  3      [ ]         STREAM     CONNECTED     3257509  @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     3257508
unix  3      [ ]         STREAM     CONNECTED     3257480  @/tmp/dbus-HF6GXyEtLE
unix  3      [ ]         STREAM     CONNECTED     3256708

[email protected]:~$ netstat | more


[email protected]:~$ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 a204PC18.aula204.:48873 108.161.189.111:http    TIME_WAIT  
tcp       38      0 a204PC18.aula204.:50142 v-d-1a.sjc.dropbo:https CLOSE_WAIT 
tcp        0      0 a204PC18.aula204.:48878 108.161.189.111:http    TIME_WAIT  
^C
[email protected]:~$ netstat -n | more
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 192.168.204.118:48873   108.161.189.111:80      TIME_WAIT  
tcp       38      0 192.168.204.118:50142   199.47.216.177:443      CLOSE_WAIT 
tcp        0      0 192.168.204.118:48878   108.161.189.111:80      TIME_WAIT  
tcp        0      0 192.168.204.118:49324   108.160.160.164:80      ESTABLISHED
tcp        1      0 192.168.204.118:37726   91.189.89.144:80        CLOSE_WAIT 
tcp        0      0 192.168.204.118:53937   173.194.44.46:80        TIME_WAIT  
tcp       38      0 192.168.204.118:40242   108.160.161.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:37679   107.20.249.77:443       CLOSE_WAIT 
tcp       38      0 192.168.204.118:40915   108.160.160.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:50214   108.160.160.178:443     CLOSE_WAIT 
tcp        0      0 192.168.204.118:39649   173.194.44.39:80        ESTABLISHED
udp        0      0 127.0.0.1:55099         127.0.0.1:55099         ESTABLISHED
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node   Path
unix  14     [ ]         DGRAM                    7947     /dev/log  -->()
unix  2      [ ]         DGRAM                    10099    @���
unix  3      [ ]         STREAM     CONNECTED     3429257  /var/run/cups/cups.sock
unix  3      [ ]         STREAM     CONNECTED     3432614  
unix  3      [ ]         STREAM     CONNECTED     3257510  @/tmp/.X11-unix/X0  --->x0 conmutació de usuaris
unix  3      [ ]         STREAM     CONNECTED     3256769  
unix  3      [ ]         STREAM     CONNECTED     3256767  @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     3256766  
unix  3      [ ]         STREAM     CONNECTED     3257509  @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     CONNECTED     3257508  
unix  3      [ ]         STREAM     CONNECTED     3257480  @/tmp/dbus-HF6GXyEtLE
unix  3      [ ]         STREAM     CONNECTED     3256708  
unix  3      [ ]         STREAM     CONNECTED     3257449  @/tmp/dbus-HF6GXyEtLE

[email protected]:~$ netstat -nt | more
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp       38      0 192.168.204.118:50142   199.47.216.177:443      CLOSE_WAIT 
tcp        0      0 192.168.204.118:49324   108.160.160.164:80      ESTABLISHED
tcp        1      0 192.168.204.118:37726   91.189.89.144:80        CLOSE_WAIT 
tcp       38      0 192.168.204.118:40242   108.160.161.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:37679   107.20.249.77:443       CLOSE_WAIT 
tcp       38      0 192.168.204.118:40915   108.160.160.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:50214   108.160.160.178:443     CLOSE_WAIT 

[email protected]:~$ netstat -t | more


[email protected]:~$ netstat -nt | more
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp       38      0 192.168.204.118:50142   199.47.216.177:443      CLOSE_WAIT 
tcp        0      0 192.168.204.118:49324   108.160.160.164:80      ESTABLISHED
tcp        1      0 192.168.204.118:37726   91.189.89.144:80        CLOSE_WAIT 
tcp       38      0 192.168.204.118:40242   108.160.161.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:37679   107.20.249.77:443       CLOSE_WAIT 
tcp       38      0 192.168.204.118:40915   108.160.160.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:50214   108.160.160.178:443     CLOSE_WAIT 
[email protected]:~$ netstat -ntul | more
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:17500           0.0.0.0:*               LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 ::1:631                 :::*                    LISTEN     
tcp6       0      0 :::3128                 :::*                    LISTEN     
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp        0      0 0.0.0.0:17500           0.0.0.0:*                          
udp        0      0 0.0.0.0:57973           0.0.0.0:*                          
udp        0      0 0.0.0.0:54902           0.0.0.0:*                          
udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp6       0      0 :::50606                :::*                               
udp6       0      0 :::58508                :::*                               
udp6       0      0 :::5353                 :::*                               
[email protected]:~$ 

[email protected]:~$ netstat -nt | more
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 192.168.204.118:35669   185.13.76.40:80         TIME_WAIT    -> Pag web (fixar-nos am el port d'origen , es aleatori per tant filtrar per port d'origen es absurt), obri qualsevol port per sobre de 1024 , en el port de destinació cada servei te el seu port establert, quan obrim un a pagina web s'obre la pagina web se descarrega i tamca la conexió.i no estan relacionades entre elles.
tcp       38      0 192.168.204.118:50142   199.47.216.177:443      CLOSE_WAIT 
tcp        0      0 192.168.204.118:53958   173.194.44.46:80        ESTABLISHED
tcp        0      0 192.168.204.118:48911   108.161.189.111:80      TIME_WAIT  
tcp        0      0 192.168.204.118:49324   108.160.160.164:80      ESTABLISHED
tcp        0      0 192.168.204.118:39672   173.194.44.39:80        ESTABLISHED
tcp        0      0 192.168.204.118:35681   185.13.76.40:80         TIME_WAIT  
tcp        1      0 192.168.204.118:37726   91.189.89.144:80        CLOSE_WAIT 
tcp        0      0 192.168.204.118:39673   173.194.44.39:80        TIME_WAIT  
tcp        0      0 192.168.204.118:48900   108.161.189.111:80      TIME_WAIT  
tcp       38      0 192.168.204.118:40242   108.160.161.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:37679   107.20.249.77:443       CLOSE_WAIT 
tcp       38      0 192.168.204.118:40915   108.160.160.177:443     CLOSE_WAIT 
tcp       38      0 192.168.204.118:50214   108.160.160.178:443     CLOSE_WAIT 
tcp        0      0 192.168.204.118:35667   185.13.76.40:80         TIME_WAIT  
tcp        0      0 192.168.204.118:35668   185.13.76.40:80         TIME_WAIT  
tcp        0      0 192.168.204.118:48905   108.161.189.111:80      TIME_WAIT  
tcp        0      0 192.168.204.118:48898   108.161.189.111:80      TIME_WAIT


COMANDA SUPER ÚTIL
[email protected]:~$ sudo netstat -A inet -lnp (lisent numèric n: numèric p:process identifiers(PID)) al saber el PID pots tancar l'aplicació si vols
[sudo] password for rafel: 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1143/mysqld     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      778/sshd        
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      883/cupsd       
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      1673/inetd      
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      1171/postgres   
tcp        0      0 0.0.0.0:17500           0.0.0.0:*               LISTEN      2006/dropbox    
udp        0      0 0.0.0.0:68              0.0.0.0:*                           2495/dhclient   
udp        0      0 0.0.0.0:17500           0.0.0.0:*                           2006/dropbox    
udp        0      0 0.0.0.0:57973           0.0.0.0:*                           887/avahi-daemon: r
udp        0      0 0.0.0.0:54902           0.0.0.0:*                           1117/squid3     
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           887/avahi-daemon: r


  • Columna tipo: si es un datagrama o stream(flux) -->datagrama UDP (per carta) --> Stream TCP (tuberia del gràfic mateix ordre)
  • Protocol IP funcionari (best effort)

Network Address Translation (NAT)

  • En principi es va crear en mode "parxe"'.
  • És un estàndard creat de la Internet Engineering Task Force (IETF). Creat per lluitar contra la falta d'IPs.

TIPUS

  • Principalment és port dividir en 2 classe principals (SNAT,DNAT) i una secundaria. (PNAT)
SNAT (Source NAT)
  • Compartir una connexió a Internet. Permet compartir una adreça vàlida d'Internet entre diverses adreces de xarxa privades.
[email protected]:~$ wget http://checkip.dyndns.org/
--2013-02-04 22:52:37--  http://checkip.dyndns.org/
Resolent checkip.dyndns.org (checkip.dyndns.org)... 216.146.39.70, 91.198.22.70, 216.146.38.70
S'està connectant a checkip.dyndns.org (checkip.dyndns.org)|216.146.39.70|:80... conectat.
HTTP: Petició enviada, esperant resposta... 200 OK
Longitud: 105 [text/html]
S'està desant a: «index.html»

100%[========================================================================================================================>] 105         --.-K/s   en 0s       

2013-02-04 22:52:37 (13,1 MB/s) - s'ha desat «index.html» [105/105]
=====DNAT (Destination NAT)===== 
  • Permet accedir als serveis d'una màquina local.

Consulteu l'article Network Address Translation (NAT).

Vegeu també

Enllaços externs