Perché la porta 80 è stata scelta come porta HTTP predefinita e 443 come porta HTTPS predefinita?

C'è un motivo o è stato appena definito in quel modo?

networking port sockets

— Samuel Alexander
fonte

A causa del mio eroe, Jon Postel, fondatore del sistema RFC e di IANA. en.wikipedia.org/wiki/Jon_Postel faqs.org/rfcs/rfc2468.html (I Remember IANA, di Vint Cerf).

— Frank Thomas,

L'Internet Assigned Numbers Authority (IANA) è un dipartimento dell'ICANN, una società americana privata senza scopo di lucro che sovrintende all'allocazione globale dell'indirizzo IP, al Domain Name System (DNS), alle porte note e ad altri simboli e numeri relativi al protocollo Internet.

Nel marzo 1990 pubblicarono il documento RFC1060 dove elencarono le porte ben note a quel tempo. In quell'elenco non c'era un protocollo assegnato alla porta 80. Passava da 79 a 81:

79       FINGER     Finger                                
81       HOSTS2-NS  HOSTS2 Name Server

Quindi, a quel tempo la porta 80 era ufficialmente libera.

Nel 1991 Tim Berners-Lee pubblicò la prima versione di HTTP in un documento su HTTP 0.9 in cui affermava:

If the port number is not specified, 80 is always assumed for HTTP.

Quindi, nel luglio 1992, fu pubblicato RFC 1340 che oscura RFC 1060 dove appare:

   finger           79/tcp    Finger                            
   finger           79/udp    Finger                            
   www              80/tcp    World Wide Web HTTP               
   www              80/udp    World Wide Web HTTP

Tale documento rende ufficiale la porta 80 come www o http. Tuttavia non c'è nulla di 443 su quel documento.

Nell'ottobre 1994 appare RFC 1700 dove per la prima volta appare questo:

https           443/tcp    https  MCom
https           443/udp    https  MCom
#                          Kipp E.B. Hickman <kipp@mcom.com>

Sembra sia stato sollecitato da Kipp EB Hickman che all'epoca lavorava presso Mosaic, la prima società di browser con GUI che in seguito divenne Netscape.

Non è chiaro perché sia stato scelto 443, tuttavia il precedente RFC aveva un gap da 374 a 512 e in questo RFC veniva riempito lo spazio da 375 a 451 . È molto probabile che i numeri siano stati semplicemente dati in ordine di richiesta.

— jcbermu
fonte

Probabilmente non esiste un motivo diverso da "443 non è già stato assegnato", seleziono sempre le porte di servizio senza un motivo specifico per il numero.

— Johnny,

Alcuni protocolli (essendo FTP il più ovvio e l'unico esempio che mi viene in mente in questo momento) utilizzano due porte. Forse, volevano lasciare lacune per possibili future estensioni dei protocolli esistenti?

— Jörg W Mittag,

"17 QUOTE Quote of the Day" Questo è un porto importante!

— Almo,

@AL c'è un divario, probabilmente stavi guardando l'elenco dei numeri di protocollo, non l'elenco dei numeri di porta

— Mark Rotteveel,

Una cosa da considerare è che quando questi porti venivano assegnati, lo sviluppo del protocollo del livello di trasporto era rapido e furioso, con accademici di tutti gli stati che lavoravano su questo o quel progetto. Il redattore di RFC (Jon Postel) era molto esigente nei suoi standard per le versioni finali delle specifiche accettate, quindi conoscevano i progetti in corso che erano in lavorazione, ma che potevano o non potevano mai raggiungere lo status formale di RFC, e potevano quindi essere incluso nell'elenco delle porte IANA. Inoltre, è stato possibile richiedere numeri di porta specifici se non erano prenotati, quindi non sono in ordine numerico.

— Frank Thomas,

La risposta di jcbermu menziona che RFC 1340 (numeri assegnati) aveva una serie di porte inutilizzate da 374 a 512 e 443 è proprio nel mezzo.

assert https_port == (374 + 512) / 2 == 443

— adriaticc
fonte