| Nivell 1: | Nivell_d'interfície_de_xarxa_TCP/IP |
| Nivell 2: | Nivell_d'internet_TCP/IP |
| Nivell 3: | Nivell_de_transport_TCP/IP |
| Nivell 4: | Nivell_d'aplicació_TCP/IP |
El nivell de transport és l'encarregat de que les dades transferides entre emissor i receptor estiguin lliures d'errors. També és l'encarregat de controlar el flux de dades.
Model de referència OSI
Pila de protocols TCP/IP
Protocols: TCP (Transport Control Protocol) i UDP (User Datagram Protocol)
Té funcions similars al nivell d'enllaç (salt a salt) però entre dues màquines que no estan connectades directament (extrem a extrem)
Servei orientat a connexió
Servei no orientat a connexió
Servei confirmat o no confirmat
Propietats
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:
Hi ha dos variants:
Propietats:
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
Protocols que utilitzen UDP:
DNS, DHCP, VoIP, Videoconferència, jocs en xarxa.
El protocol TCP és orientat a connexió. El següent diagrama mostra el protocol d'establiment d'una connexió:
i aquest altre diagrama mostra el procés de terminació d'una connexió:
Consulteu Exemple amb netcat de captura de paquets de connexió TCP
Exemples: A mode d'exemple no és el mateix que al intentar accedir com a client per el
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.
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.
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.
Els podeu consultar amb
$ netstat --inet -t -a -c | grep upc.es:www tcp 1 0 casa-linux.local:48520 raiden.upc.es:www CLOSE_WAIT tcp 0 687 casa-linux.local:48529 raiden.upc.es:www ESTABLISHED tcp 0 1 casa-linux.local:48522 raiden.upc.es:www SYN_SENT tcp 0 709 casa-linux.local:48537 raiden.upc.es:www ESTABLISHED tcp 0 1 casa-linux.local:48522 raiden.upc.es:www SYN_SENT tcp 1 1 casa-linux.local:48560 raiden.upc.es:www LAST_ACK tcp 0 0 casa-linux.local:48556 raiden.upc.es:www TIME_WAIT tcp 0 0 casa-linux.local:48556 raiden.upc.es:www TIME_WAIT ...............................................
El següent diagrama mostra els canvis d'estats segons els serveis OSI:
I al diagrama següent podeu observar quin és l'evolució de l'establiment d'una connexió i els estats relacionats:
Vegeu també conntrack.
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:
Una llista possible dels ports més habituals
Consulteu també /etc/services.
Dispositius virtuals de comunicacions bidireccionals.
Hi han tantes famílies de sockets com protocols. Els dos més importants:
Sockets Unix
Unix domain socket (UDS o IPC socket)
Components
$ 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
Consulteu Telnet#Telnet_com_a_eina_per_a_obrir_connexions_TCP.
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
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
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
(enchufes) Posar captura pàg 223
Dispositius virtuals de comunicacions bidireccionals.
srwxrwxrwx/var/run/mysqld/mysqld.sock 07:42 /var/run/mysqld/mysqld.sock Quan comença en s --> socket
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
Els dos protocols de nivell de transport més utilitzats són TCP i UDP.
$ 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
Tuning hints:
Undulatus Asperatus Clouds Nothing is impossible
Considering these, change parameters as follows:
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
# 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.
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
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 ...
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:
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
Les adreces IP estan dividides en classes:
Acacha Wiki
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
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:
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.
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).
Udpcast és utilitzat per DRBL i clonezilla.
[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
[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)
[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
[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)=====
Consulteu l'article Network Address Translation (NAT).