Чому порт 80 обраний як порт HTTP за замовчуванням, а 443

Чому порт 80 обраний як порт HTTP за замовчуванням, а 443 - порт HTTPS за замовчуванням?

Чи є причина чи це просто визначено таким чином?

networking port sockets

Через мого героя, Джона Постеля, засновника системи RFC, та IANA. en.wikipedia.org/wiki/Jon_Postel faqs.org/rfcs/rfc2468.html (я пам'ятаю IANA, від Вінта Серфа).

— Френк Томас

Internet Assigned Numbers Authority (IANA) - це відділ ICANN, некомерційної приватної американської корпорації, яка здійснює нагляд за глобальним розподілом IP-адрес, системою доменних імен (DNS), відомими портами та іншими символами та номерами, пов’язаними з Інтернет-протоколом.

У березні 1990 р. Вони опублікували документ RFC1060, де перелічили відомі на той час порти . У цьому списку не було протоколу, призначеного порту 80. Він переходив від 79 до 81:

79       FINGER     Finger                                
81       HOSTS2-NS  HOSTS2 Name Server

Так, на той час порт 80 був офіційно вільним.

У 1991 році Тім Бернерс-Лі видав першу версію HTTP в документі про HTTP 0.9, де заявив:

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

Тоді в липні 1992 року був опублікований RFC 1340, який застарів RFC 1060, де з'являється:

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

Цей документ робить офіційним порт 80 як www або http. Однак у цьому документі нічого немає.

У жовтні 1994 року з'являється RFC 1700, де вперше з'являється таке:

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

Здається, він попросив Kipp EB Хікмана, який у той час працював у Mosaic - першій браузерній компанії GUI, яка згодом стає Netscape.

Незрозуміло, чому було обрано 443, проте попередній RFC мав проміжок від 374 до 512, і в цьому RFC простір від 375 до 451 було заповнене. Дуже ймовірно, що номери були просто задані в порядку запиту.

— jcbermu
джерело

Ймовірно, немає жодної причини, окрім "443 не було призначено", я постійно вибираю порти обслуговування без конкретної причини для номера.

— Джонні

У деяких протоколах (FTP є найбільш очевидним і єдиним прикладом, про який я зараз думаю) використовують два порти. Можливо, вони хотіли залишити прогалини для можливого подальшого розширення існуючих протоколів?

— Йорг W Міттаг

"17 цитата дня" Це важливий порт!

— Альмо

@AL є розрив, ви, мабуть, дивились на список номерів протоколів, а не на перелік номерів портів

— Марк Ротвевель

Одне, що слід враховувати, - це те, що, коли ці порти були призначені, розробка протоколів транспортного рівня була швидкою і лютою, вчені з усіх держав працювали над тим чи іншим проектом. Редактор RFC (Джон Постел) був дуже вимогливим у своїх стандартах щодо прийнятих остаточних версій специфікацій, тому вони мали знання про поточні проекти, які працювали, але які можуть або не можуть досягти офіційного статусу RFC, і могли б потім бути включеним до списку портів IANA Крім того, можна було запитати конкретні номери портів, якщо вони не захищені, тому вони не в порядку порядку.

— Френк Томас

Відповідь jcbermu зазначає, що RFC 1340 (присвоєні номери) мав пробіл невикористаних портів від 374 до 512, а 443 - прямо посередині.

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

— adriaticc
джерело