[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]


Capitolo 113.   Definizione dei protocolli e dei servizi

Prima ancora di analizzare sommariamente il funzionamento dei protocolli IP, è opportuno portare momentaneamente l'attenzione a due file di configurazione che di solito sono già stati predisposti correttamente dalle varie distribuzioni GNU/Linux: si tratta di /etc/protocols e /etc/services. Normalmente non ci si accorge nemmeno della loro presenza, ma la loro mancanza, o l'indicazione errata di alcune voci pregiudica seriamente il funzionamento elementare delle reti IP.

113.1   Protocolli di trasporto e di rete

I protocolli di comunicazione possono inserirsi a diversi livelli nella stratificazione del modello di rete presentato nel capitolo 111. Quelli riferiti ai livelli di trasporto e di rete sono classificati nel file /etc/protocols che alcuni programmi hanno la necessità di consultare. Di solito non c'è la necessità di modificare questo file che però deve essere presente quando si utilizzano programmi che accedono alla rete. Segue un estratto abbreviato di questo file:


ip          0   IP              # internet protocol, pseudo protocol number
icmp        1   ICMP            # internet control message protocol
...
tcp         6   TCP             # transmission control protocol
...
udp         17  UDP             # user datagram protocol
...
ipv6        41  IPv6            # IPv6
...
ipv6-icmp   58  IPv6-ICMP       # ICMP for IPv6
...

113.2   Servizi

I protocolli TCP e UDP inseriscono il concetto di porta di comunicazione. Per la precisione, ogni pacchetto TCP o UDP, contiene una porta mittente e una porta di destinazione. Naturalmente, al livello IP vengono anche aggiunte le indicazioni dell'indirizzo IP del mittente e del destinatario.

Perché un pacchetto possa essere ricevuto da un destinatario, occorre che questo sia in ascolto proprio della porta prevista, altrimenti il pacchetto in questione non raggiunge il suo obiettivo. In generale, un'applicazione che deve svolgere un servizio attraverso la rete, starà in ascolto sempre della stessa porta, in modo tale che chi vuole accedervi sappia come farlo. Dall'altra parte, un'applicazione che vuole accedere a un servizio, aprirà per conto proprio una porta locale qualsiasi, purché non utilizzata, iniziando poi a inviare dei pacchetti TCP o UDP (in base alle caratteristiche del protocollo al livello superiore) presso l'indirizzo e la porta del servizio. Si intende che l'applicazione che svolge il servizio saprà a quale porta rispondere perché questa informazione è parte dei pacchetti TCP e UDP.

Figura 113.1. Viaggio di un pacchetto UDP o TCP: «n» è la porta di origine; «m» è la porta di destinazione.

.----------.                                                   .----------.
|          |   Pacchetto UDP o TCP da «A:n» diretto a «B:m»    |          |
|  Nodo A  | - - - - - - - - - - - - - - - - - - - - - - - - > |  Nodo B  |
|          |                                                   |          |
`----------'                                                   `----------'

Figura 113.2. Andata e ritorno per le connessioni che prevedono l'uso delle porte: «n» è la porta usata nel nodo «A»; «m» è la porta usata nel nodo «B».

.----------.                                                   .----------.
|          |   Pacchetti di andata da «A:n» diretti a «B:m»    |          |
|  Nodo A  | - - - - - - - - - - - - - - - - - - - - - - - - > |  Nodo B  |
|          |                                                   |          |
`----------'                                                   `----------'
      ^                                                             V
      |        Pacchetti di ritorno da «B:m» diretti a «A:n»        |
      `- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'

I servizi di rete sono offerti utilizzano protocolli al livello quinto del modello ISO-OSI, ovvero al livello di sessione, utilizzando nello strato inferiore (TCP o UDP) delle porte ben conosciute, che tendono così a confondersi con il servizio stesso. Per esempio, la porta 23 viene usata per il protocollo TELNET, pertanto tende a essere identificata con il servizio corrispondente.

Figura 113.3. Esempio di ciò che accade quando dal nodo «A» un processo instaura una connessione HTTP con il nodo «B»; in particolare, in questo caso il processo in questione utilizza localmente la porta 1 083.

Cliente HTTP                                                   Servente HTTP
.----------.                                                   .----------.
|          | Pacchetti di andata da «A:1083» diretti a «B:80»  |          |
|  Nodo A  | - - - - - - - - - - - - - - - - - - - - - - - - > |  Nodo B  |
|          |                                                   |          |
`----------'                                                   `----------'
      ^                                                             V
      |     Pacchetti di ritorno da «B:80» diretti a «A:1083»       |
      `- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'

Generalmente, nei sistemi Unix le porte che gli applicativi devono utilizzare per stare in ascolto in attesa di richieste di connessione sono elencate nel file /etc/services. Il file in questione serve anche ai programmi che accedono ai servizi (sia locali che remoti), per sapere quale porta interpellare.

Il file /etc/services viene utilizzato in particolare da Inetd, per interpretare correttamente i nomi di tali servizi indicati nel suo file di configurazione /etc/inetd.conf (135.2).

Spesso, nel file /etc/services si annotano due righe per ogni porta: una nel caso di utilizzo del protocollo TCP e l'altra nel caso di UDP. Questo può succedere anche quando il servizio corrispondente fa sempre uso sempre solo di uno dei due protocolli.

Segue un estratto molto breve del file in questione, in cui si può vedere la definizione di servizi di uso comune:


ftp-data        20/tcp
ftp             21/tcp
...
ssh             22/tcp                          # SSH Remote Login Protocol
ssh             22/udp                          # SSH Remote Login Protocol
telnet          23/tcp
smtp            25/tcp          mail
...
domain          53/tcp          nameserver      # name-domain server
domain          53/udp          nameserver
...
www             80/tcp          http            # WorldWideWeb HTTP
www             80/udp                          # HyperText Transfer Protocol
...
pop3            110/tcp         pop-3           # POP version 3
pop3            110/udp         pop-3
...
irc             194/tcp                         # Internet Relay Chat
irc             194/udp
...
x11             6000/tcp        x11-0           # X windows system
x11             6000/udp        x11-0           # X windows system
...

113.3   Messaggi ICMP

Più o meno allo stesso livello dei protocolli TCP e UDP, si affianca il protocollo ICMP, il quale non dispone più di porte, ma di messaggi, definiti attraverso un codice numerico, composto da un tipo e da un eventuale sottotipo.

Tabella 113.1. Messaggi ICMP comuni.

Tipo Codice Nome Chi lo utilizza
0 echo-reply risposta a un ping (pong)
1
2
3 destination-unreachable traffico TCP/UDP
3 0   network-unreachable
3 1   host-unreachable
3 2   protocol-unreachable
3 3   port-unreachable
3 4   fragmentation-needed
3 5   source-route-failed
3 6   network-unknown
3 7   host-unknown
3 8   
3 9   network-prohibited
3 10   host-prohibited
3 11   TOS-network-unreachable
3 12   TOS-host-unreachable
3 13   communication-prohibited
3 14   host-precedence-violation
3 15   precedence-cutoff
4 source-quench
5 redirect instradamento dei pacchetti
5 0   network-redirect
5 1   host-redirect
5 2   TOS-network-redirect
5 3   TOS-host-redirect
6
7
8 echo-request ping
9 router-advertisement
10 router-solicitation
11 time-exceeded (ttl-exceeded) traceroute
11 0   ttl-zero-during-transit
11 1   ttl-zero-during-reassembly
12 parameter-problem
12 0   ip-header-bad
12 1   required-option-missing
13 timestamp-request
14 timestamp-reply
15 information-request
16 information-reply
17 address-mask-request
18 address-mask-reply

In molti casi, i messaggi ICMP servono a fornire delle segnalazioni di errore riferite allo stato della rete.

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome definizione_dei_protocolli_e_dei_servizi.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]