Ogni processo che fa uso del TCP/IP, deve avere un numero di porta di protocollo, per fare riferimento alla posizione di una particolare applicazione che gestisce il processo sulla singola macchina. Un’applicazione, teoricamente, può essere configurata per essere eseguita su quasi tutte le 65'536 porte (UDP e TCP) disponibili, anche se le applicazioni ed i servizi TCP/IP di uso più comune usano solitamente le prime 1'023.
Queste porte, sono dette “Well knowed ports” (porte ben note) e sono assegnate e gestite a lato server dalla IANA (Internet Assigned Numbers Authority). Per esempio, quando si stabilisce una sessione Telnet, l’applicazione client si collega alla porta 23 TCP del server Telnet. Una porta è in realtà un sottoinsieme di una socket. Le socket sono infatti semplici stringhe, formate dalla combinazione indirizzo IP + numero di porta.

UDP è un altro protocollo dello strato del trasporto a cui va la responsabilità della trasmissione dati su una rete. A differenza del TCP, però, si tratta di un protocollo che non necessita di connessione. Non viene infatti stabilita alcuna sessione e l’UDP si limita soltanto a “fare del suo meglio” perché la spedizione vada a buon fine.
Questo protocollo non cerca di verificare che l’host di destinazione abbia o meno ricevuto le informazioni che gli sono state inviate. UDP è utilizzato da quelle applicazioni che inviano piccole quantità di dati e che non hanno bisogno di una consegna sicura. Come vedremo nel corso del capitolo 5, UDP è usato dal NetBIOS per i servizi “Name service” e “Datagram”, che devono inviare piccolissime quantità di dati. Anche questo protocollo utilizza i numeri di porta per fare identificare un processo particolare ad un indirizzo IP specifico, ma le porte UDP sono diverse da quelle TCP e possono pertanto coincidere numericamente, senza causare conflitti.

Un protocollo UDP fornisce un servizio senza connessione. Non esiste una garanzia del fatto che l’host destinatario riceverà le informazioni. Le applicazioni che si servono di UDP devono fare da sé per assicurarsi che i dati siano consegnati con successo all’host ricevente. L’unica protezione che esiste in un pacchetto UDP è un valore di controllo nella sua intestazione, il quale assicura che i dati non si siano danneggiati durante il transito.
Una tipica analogia che serve a paragonare i protocolli TCP e UDP è l’ufficio postale in confronto ad un corriere espresso. L’ufficio postale funziona un po’ come il protocollo UDP.
Quando si scrive una lettera per un amico e la si imbuca, non è garantito che essa giungerà a destinazione, anche se la maggior parte delle volte lo farà. Questo meccanismo può andare bene finché si deve scrivere una qualche sciocchezza: infatti, che essa arrivi o non arrivi non ha grande importanza.
Il protocollo TCP possiamo vederlo invece come un corriere espresso, che garantisce sempre e comunque la consegna, oltretutto entro un determinato lasso di tempo.
Ovviamente, il costo del corriere è superiore rispetto a quello del postino tradizionale. In materia di protocolli, il maggior costo si rileva come maggior traffico sulla rete, in quanto, oltre all’invio del frammento, il TCP richiede che venga inviata al mittente la conferma di ricezione.

I protocolli che operano allo strato dell’applicazione sono svariati. Per la gestione delle e-mail, infatti, esistono SMTP (invio), POP3 ed IMAP4 (ricezione). Per il trasferimento di file vi è l’FTP, mentre per la visualizzazione di documenti si è affermato l’HTTP, che ha avuto la meglio su Gopher e Telnet

Per dirla con il linguaggio di Postel e Reynolds, che lo teorizzarono nel 1983 con la pubblicazione della RFC 854, il Telnet “non è altro che una connessione TCP usata per la trasmissione di dati, intervallati da particolari informazioni di controllo”. Il protocollo Telnet appoggia su tre idee fondamentali:

• il concetto di Network Virtual Terminal;
• il principio delle opzioni negoziabili;
• una visione simmetrica dei terminali e dei processi;

Quando tra due host viene stabilita una connessione Telnet, ciascuno dei due determina l’apertura e la chiusura di una rete di terminali virtuali (NVT). Una NVT, concettualmente, è una rete che fornisce degli standard per la comunicazione, una certa ampiezza di banda e gestisce la sessione come se il server avesse a che fare con un terminale tradizionale. Questo elimina la necessità che ogni host (sia esso un server o un client) debba mantenere in memoria le informazioni (indirizzo IP, MAC, ecc…) relative all’altro terminale.

Il principio della negoziazione delle opzioni, nasce dalla considerazione che alcuni server possono fornire servizi addizionali per la NVT che vanno a creare. I client potrebbero avere software Telnet molto semplici, che non permettono altro che le operazioni di base, o anche software piuttosto sofisticati. Gli utenti di questi ultimi desiderano giustamente avere il massimo dai loro programmi.
Per garantire comunque compatibilità per tutti i vari client Telnet, Postel e Reynolds hanno previsto una fase, ad inizio collegamento, di negoziazione delle opzioni. Al giorno d’oggi, queste opzioni fanno sorridere.
Il server chiede infatti al client se possiede ad esempio un display a colori, qual é lo standard di caratteri utilizzato e così via. Il client risponde semplicemente accettando o rifiutando le opzioni che gli vengono proposte dal server.

La simmetria della sintassi di negoziazione, potrebbe potenzialmente portare ad un loop infinito. Ciascun host, infatti, vede ogni comando in entrata non come un acknowledgment, ma sempre come una richiesta che deve essere soddisfatta. Per prevenire questi loop, valgono le seguenti regole, volte anche a minimizzare l'occupazione di banda sulla rete:
• gli host possono soltanto richiedere un cambiamento nello stato delle opzioni. Non possono pertanto spedire messaggi del tipo: "io sono in questo stato";
• se un host riceve la richiesta di abilitare una opzione che é già attiva, a questa richiesta non deve essere data alcuna risposta;
• quando uno dei due host invia un comando volto a cambiare un'opzione e l'uso di questa opzione avrà una qualche operazione anche sui dati già processati, allora il comando deve essere inserito nel punto esatto in cui si desidera che abbiano inizio i suoi effetti. Questo punto deve essere specificato dall’host che invia il comando;

Creato nell’aprile del 1991 all’università del Minnesota, da un gruppo di studenti guidato dal programmatore Mark McCahill, il Gopher si può definire come un altro sistema che tentò di rappresentare tutte le risorse ed i servizi che Internet metteva a disposizione in quel periodo. Il nome deriva dalla mascotte dell’università, una specie di talpa dorata, chiamata appunto “Golden Gopher”. Più tecnicamente, si trattava di un sistema client/server, dotato di una interfaccia che si presentava all’utente sotto forma di menù a scelta multipla. Ogni menù, era in realtà una categoria in cui vi erano i dati o i servizi richiesti che rimandavano ad altri server Internet. I vari server Gopher, nei quali un demone rimaneva in ascolto sulla porta TCP 70, erano connessi tra di loro a collegare una gigantesca rete.
Per trovare le informazioni di cui un utente necessitava, venne creato un motore di ricerca interno (precursore degli odierni Google, Altavista, NorthernLight, Yahoo, ecc…), chiamato Veronica. Al giorno d’oggi il Gopher è pressoché inutilizzato, sopraffatto in praticità, velocità e diffusione dall’HTTP, benché tutti i browser di ultima generazione continuino a supportarlo. All’indirizzo gopher://gopher.tc.umn.edu/ è possibile trovare interessanti risorse riguardo a questo protocollo.