From LAN to the Internet: Token Ring, Ethernet, and the Protocols That Won
2026-08-22 · 11 min
Every network diagnostic in this toolkit — a ping, a traceroute, a DNS lookup — quietly depends on decisions made in engineering rooms half a century ago. Before any of it was possible, engineers first had to solve a much more basic problem: how do you get more than two computers talking on the same wire without every conversation turning into noise?
That problem produced two competing philosophies for the local area network, a standards process that still governs the Internet today, and a decade-long transition from proprietary hardware to the open, layered protocol stack every device now runs. This is that story.
1969
ARPANET goes live
The first four nodes (UCLA, Stanford Research Institute, UC Santa Barbara, University of Utah) are connected, the direct ancestor of the modern Internet.
1973
Ethernet is invented
Bob Metcalfe and David Boggs at Xerox PARC design a packet-based network over shared coaxial cable, named after the 19th-century 'luminiferous ether'.
1974
TCP is described
Vint Cerf and Bob Kahn publish 'A Protocol for Packet Network Intercommunication', laying out the ideas that become TCP/IP.
1980
DIX Ethernet standard
DEC, Intel, and Xerox jointly publish the first commercial Ethernet standard: 10 Mbps over thick coaxial cable.
1981
IP and TCP formalized
RFC 791 (Internet Protocol) and RFC 793 (Transmission Control Protocol) are published, still the foundation of Internet addressing and reliable delivery today.
1983
The ARPANET flag day
On January 1, every host on ARPANET switches from the old NCP protocol to TCP/IP overnight - the moment the modern Internet's protocol stack becomes mandatory.
1985
IEEE 802.5 Token Ring
IBM's deterministic, token-passing ring topology is formally standardized at 4 Mbps, later extended to 16 Mbps.
1990
10BASE-T arrives
IEEE 802.3i brings Ethernet onto twisted-pair cabling and RJ45 connectors, enabling cheap star-topology wiring through a central hub.
1995
Fast Ethernet (100 Mbps)
IEEE 802.3u standardizes 100 Mbps Ethernet, six times faster than Token Ring's ceiling - the tipping point in enterprise LAN purchasing decisions.
1999
Gigabit Ethernet over copper
IEEE 802.3ab delivers 1000 Mbps over the same twisted-pair cabling already installed everywhere, cementing Ethernet as the unchallenged LAN standard.
Before the LAN: one cable, one conversation
Early computer networking was built around point-to-point or multidrop links between a mainframe and its terminals - reliable, but expensive to wire and impossible to scale past a handful of devices. As offices filled with independent minicomputers and, later, personal computers, the real problem shifted: how do dozens of machines share one physical cable without their signals colliding into unreadable noise?
Two very different answers emerged in the 1970s and 1980s, and for over a decade neither one was the obvious winner.
Two philosophies: token passing vs. listen-and-retry
IBM's Token Ring, standardized as IEEE 802.5, solved the collision problem by removing the possibility of collision entirely. A single small 'token' frame circulates continuously around a logical ring; a station may only transmit when it is holding the token, guaranteeing that exactly one device speaks at a time. It is deterministic and predictable under heavy load - properties IBM's mainframe-oriented enterprise customers valued highly.
Ethernet took the opposite bet. Its CSMA/CD access method (Carrier Sense Multiple Access with Collision Detection) simply lets any station transmit whenever it believes the wire is idle, and listens for a collision; if one occurs, both senders back off for a random interval and retry. It is probabilistic rather than guaranteed, but radically simpler and cheaper to implement in hardware - and under the light-to-moderate traffic loads of a typical office, it performed just as well in practice as the more elaborate token scheme.
Token Ring's logical ring (left) passes a single token station-to-station; Ethernet's shared bus or hub-based star (right) lets any station transmit and resolves collisions after the fact.
The protocols that made packets talk
A shared cable only solves how frames move between two adjacent machines. Getting a message from a computer in Los Angeles to one in Boston, across networks owned by entirely different organizations, needed a second, independent layer of addressing and routing - which is exactly what the ARPANET research program was built to solve. Vint Cerf and Bob Kahn's 1974 paper introduced the idea of splitting that job into two protocols: IP, responsible for addressing packets and getting them from network to network, and TCP, responsible for reassembling them reliably and in order at the far end.
Both were formalized as RFC 791 and RFC 793 in September 1981, and on January 1, 1983 - a date engineers still refer to as 'flag day' - every host still connected to ARPANET was cut over from the older NCP protocol to TCP/IP simultaneously, essentially overnight. It is one of the largest coordinated protocol migrations in computing history, and it is the direct reason IP addressing and TCP's three-way handshake are still exactly how this toolkit's Ping, Traceroute, and every other tool talk to the network today.
The RFC (Request for Comments) process itself, still run by the IETF, deserves credit here too: unlike Token Ring's IBM-controlled standardization, RFCs are open documents anyone can propose, argue about in public, and implement - the process's own famous motto is 'rough consensus and running code'. That openness is a large part of why TCP/IP, rather than any of several competing proprietary networking stacks of the era (including IBM's own SNA), became the protocol every vendor eventually converged on.
The layered model that came out of this era: each layer only talks to the one directly above and below it, which is why a tool like Ping (ICMP, network layer) works identically regardless of what application layer protocol - HTTP, DNS, SMTP - runs on top of it.
Why Ethernet ultimately won
Through the mid-1980s, Token Ring and Ethernet coexisted as genuinely competing enterprise choices, with Token Ring often preferred in IBM-centric shops for its predictable behavior under load. The balance tipped decisively over the following decade for reasons that had less to do with raw technical merit and more to do with economics and pace of innovation: Ethernet's move to twisted-pair cabling with 10BASE-T in 1990 made wiring dramatically cheaper and easier than Token Ring's shielded cabling and specialized connectors, and the arrival of switching (replacing shared hubs with a dedicated point-to-point link per port, eliminating collisions altogether) removed CSMA/CD's biggest theoretical weakness.
The final blow was speed. Fast Ethernet's 100 Mbps in 1995 was already six times Token Ring's 16 Mbps ceiling, and by the time Gigabit Ethernet arrived in 1999 running over the exact same cabling already installed everywhere, there was no remaining reason to choose the more expensive, proprietary alternative. IBM itself quietly shifted its own recommendations to Ethernet during the 1990s; Token Ring survives today mostly in legacy industrial control systems, not new deployments.
Итог
The specific hardware debate is settled, but the pattern it set is still the one modern networking follows: an open, community-driven standard (Ethernet's IEEE process, TCP/IP's RFCs) tends to out-innovate a closed, vendor-controlled one over a long enough timeline, because more organizations can build on it, extend it, and drive its cost down. Every device on a modern LAN, from a laptop to an IoT sensor, still speaks the same Ethernet frame format standardized in the 1980s carrying the same IP packets standardized in 1981 - which is exactly why a tool as simple as Ping still works the same way it did forty years ago.
Ваш публичный IP-адрес и сетевое местоположение определяются автоматически.
Загружается автоматически при открытии NetChecks — ввод не требуется. Используйте кнопку «Обновить» после смены сети или переподключения VPN.
Ваш браузер
Комплексное сканирование
Запускает все соответствующие проверки для одного IP или имени хоста за один проход: DNS, whois, ping, traceroute, сканирование известных портов (1-1024), заголовки HTTP и сертификат SSL.
Введите домен или IP-адрес и запустите проверку, чтобы разом проверить DNS, whois, ping, traceroute, распространённые порты, HTTP-заголовки и SSL-сертификат.
Большинство проверок выполняются параллельно - обычно завершается примерно за 30 секунд, дольше, если цель медленная или недоступна.
Этап сканирования портов выполняется только при установленном флажке согласия выше - все остальные проверки выполняются в любом случае.
Ping
Отправляет ICMP echo-запросы на хост для проверки его доступности и задержки.
Введите имя хоста или IP-адрес и нажмите Ping, чтобы отправить ICMP echo-запросы и измерить задержку туда-обратно.
Подробнее о Ping
Что это
Ping отправляет пакеты ICMP Echo Request на узел и измеряет время, за которое возвращаются пакеты ICMP Echo Reply. Это самый базовый тест сетевого подключения из существующих: он отвечает ровно на один вопрос - "доступна ли эта машина и насколько быстро?". Протокол ICMP (RFC 792) был разработан ещё в 1981 году специально для передачи управляющих и диагностических сообщений по IP-сетям, вне какого-либо прикладного трафика - Ping является его самой известной и повсеместно доступной реализацией, присутствующей практически на каждой операционной системе и сетевом устройстве с самых первых версий.
Как это работает
Каждый пакет ICMP несёт поле TTL (Time To Live), уменьшаемое на единицу при прохождении каждого маршрутизатора; если оно достигает нуля до того, как пакет достигнет цели, пакет отбрасывается, и отправителю возвращается сообщение об ошибке. Время кругового обхода (RTT), измеряемое в миллисекундах, отражает суммарную сетевую задержку на всём пути туда и обратно, а не только последний участок вблизи цели - момент, который часто понимают неверно, поскольку медленный результат ping может иметь причину в любой точке пути, не обязательно рядом с тестируемым сервером. Ping обычно отправляет несколько пакетов подряд, а не один, что позволяет отличить разовый всплеск задержки от повторяющейся проблемы и рассчитать долю потерь пакетов по выборке.
Интерпретация результатов
Стабильное, низкое значение RTT - несколько миллисекунд в локальной сети, от 10 до 50 мс для назначения внутри той же страны и заметно больше для межконтинентального соединения - свидетельствует о здоровом соединении. Даже небольшая потеря пакетов (свыше 1-2%) особенно пагубна для чувствительных к задержке приложений, таких как VoIP или интерактивные удалённые сеансы, где каждый потерянный пакет проявляется как сбой или слышимый разрыв. Сильно варьирующаяся задержка от пакета к пакету (джиттер) для тех же случаев зачастую является более серьёзной проблемой, чем высокая, но абсолютно стабильная задержка. "Превышено время ожидания запроса" означает, что в отведённое время не пришло ни одного ответа - узел действительно может быть недоступен, файрвол может незаметно блокировать ICMP, либо где-то на пути повреждён маршрут; "Узел назначения недостижим" - это другое и более информативное сообщение: промежуточный маршрутизатор явно отправил обратно сообщение о том, что не смог переслать пакет, что помогает сузить круг поиска реальной проблемы.
Частые ошибки
Наиболее распространённая ошибка интерпретации - делать вывод, что узел "недоступен", как только ping не проходит, тогда как очень многие серверы и устройства - особенно за грамотно настроенным файрволом или размещённые у крупных облачных провайдеров - намеренно блокируют входящий ICMP в качестве политики, оставаясь при этом полностью работоспособными и доступными по своим реальным сервисам (HTTP, база данных и так далее). Поэтому отсутствие ответа на ping является значимым доказательством недоступности только в сочетании с другими признаками, например, если само приложение тоже не отвечает. И наоборот, успешный ping вовсе не гарантирует, что прикладной сервис, размещённый на этой машине, работает корректно - это два совершенно независимых уровня сетевого стека.
Когда использовать
Первое, что нужно проверить перед эскалацией тикета: отвечает ли машина вообще, прежде чем копать дальше? Подтверждение подключения после изменения правила файрвола или таблицы маршрутизации, чтобы убедиться, что изменение не нарушило доступ. Установление базового измерения задержки перед внедрением VoIP или переключением на резервный канал оператора, чтобы иметь объективную точку сравнения, если позже поступят жалобы на качество связи. Лёгкая, периодическая проверка работоспособности для MSP, параллельно контролирующего несколько клиентских площадок, всегда как дополнение к более глубокому мониторингу на уровне приложений, а не как замена ему.
Traceroute
Отслеживает сетевой маршрут (переход за переходом) до хоста назначения.
Введите имя хоста или IP-адрес и запустите проверку, чтобы увидеть каждый сетевой узел между этим сервером и целью с задержкой на каждом узле.
Введите домен, выберите тип записи (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV или CAA) и выполните запрос.
Whois
Просмотр регистрационной информации домена или IP-адреса.
Введите домен или IP-адрес, чтобы узнать данные регистрации: регистратора, организацию-владельца и важные даты.
Проверка чёрных списков
Проверяет, находится ли IP-адрес или домен в публичных чёрных списках спама/злоупотреблений (DNSBL).
Введите IPv4-адрес или домен и запустите проверку сразу по 7 публичным чёрным спискам (DNSBL/RBL) - для каждого показывается статус: в списке, не в списке или ошибка проверки.
Сканирование TCP-портов
Проверка, открыты ли TCP-порты на хосте или IP: распространённые порты, свой список, или весь диапазон 1-65535.
Введите хост или IP, выберите распространённые порты, свой список или весь диапазон, затем просканируйте, какие TCP-порты отвечают.
Полное сканирование диапазона может занять до ~100 секунд. Крупные сканирования (более 100 портов, включая настраиваемые диапазоны/списки) ограничены 1 разом в минуту на посетителя.
Открытые порты (0)
Просмотр заголовков HTTP
Получает статус ответа HTTP и заголовки для URL.
Введите URL, чтобы получить код состояния HTTP-ответа и все заголовки ответа, отправленные сервером.
Проверка сертификата SSL / TLS
Проверяет TLS-сертификат хоста: издатель, сроки действия и оставшиеся дни.
Введите имя хоста, чтобы проверить его TLS-сертификат: издателя, сроки действия и количество дней до истечения.
Geo-IP запрос
Определяет географическое местоположение и сетевую информацию для IP-адреса. Оставьте пустым, чтобы узнать свой публичный IP.
Введите любой IP-адрес или оставьте поле пустым, чтобы узнать свой, — вы увидите примерное местоположение и данные о сети/провайдере.
Вычисляется полностью в вашем браузере — данные на сервер не отправляются.
Введите IP-адрес и префикс CIDR (например, 192.168.1.0/24), чтобы мгновенно вычислить диапазон сети, широковещательный адрес и количество доступных хостов.
Тест скорости
Базовый тест скорости загрузки/выгрузки относительно этого сервера (точность зависит от собственного канала сервера).
Нажмите «Старт», чтобы измерить скорость скачивания и загрузки относительно этого сервера. Точность зависит от собственного соединения этого сервера.
Словарь кодов стран
Коды стран ISO 3166-1 alpha-2 — поиск выполняется полностью в вашем браузере.
Ищите или просматривайте список кодов стран ISO 3166-1 alpha-2 — поиск выполняется полностью в вашем браузере.
Страна
Код ISO
Словарь телефонных кодов
Международные телефонные коды по странам — поиск выполняется полностью в вашем браузере.
Ищите или просматривайте международные телефонные коды по странам — поиск выполняется полностью в вашем браузере.
Страна
Код
Мировые часы
Выберите часовой пояс, чтобы увидеть текущее время — перетащите глобус, чтобы вращать его.
Выберите часовой пояс из списка или покрутите глобус, чтобы увидеть текущее время там.
Ваше время
--:--:--
—
—
Выбранное время
--:--:--
—
—UTC±00:00
Разница с вами—
—
Перетащите, чтобы вращать глобус.
Статус мобильной сети Франции
Мобильные вышки, не работающие или на обслуживании во Франции, по операторам (Orange, Free, SFR, Bouygues Telecom), по открытым данным Arcep. Снимок обновляется раз в день - не поминутный поток.
Просматривайте данные об авариях мобильных вышек и оптоволокна по французским операторам — ввод не требуется, данные обновляются автоматически из открытых данных Arcep.
Источник: Arcep, набор данных «Sites indisponibles», опубликован по Открытой лицензии / Etalab 2.0 - коммерческое использование явно разрешено, в отличие от ранее использовавшихся данных IODA/CAIDA. Значок «Норма/Наблюдение/Тревога» - собственная оценка (число сбоев сегодня относительно медианы за предыдущие дни), не официальная классификация Arcep. Ссылки на источники ниже.
Наиболее затронутые департаменты
Число объектов, сейчас не работающих или на обслуживании, по департаментам. Нажмите на оператора выше для фильтрации.
Качество оптоволоконной сети (FTTH) по операторам: доля зарегистрированных сбоев и доля неудачных подключений, по открытым данным Arcep. Ежемесячные показатели, скользящее среднее за 6 месяцев - не прямой поток, как в разделе мобильной связи.
Источник: Arcep, набор данных «Qualité des réseaux en fibre optique», опубликован по Открытой лицензии / Etalab 2.0 - коммерческое использование явно разрешено. Ссылки на источники ниже.
По операторам (материнская компания)
Средние значения за последние 6 доступных месяцев, по материнской компании оператора инфраструктуры.
NetChecks предоставляется исключительно для законной диагностики сети и образовательных целей, для систем, доменов и IP-адресов, которыми вы владеете или которые вы явно уполномочены тестировать.
Выполнение сканирования портов, DNS/whois-запросов, traceroute или других проверок в отношении сторонних систем без разрешения может нарушать законы о неправомерном использовании компьютеров в вашей юрисдикции (например, Computer Fraud and Abuse Act в США, «Loi Godfrain» во Франции или аналогичное местное законодательство). Только вы несёте ответственность за то, чтобы убедиться, что у вас есть право тестировать любую цель, указанную здесь.
Этот сайт и его результаты предоставляются «как есть», без каких-либо гарантий. Оператор этого сайта не несёт ответственности за любые прямые, косвенные или косвенные убытки, правовые последствия или неправомерное использование, возникшие в результате использования этого сайта.
Запросы ограничены по частоте для предотвращения злоупотреблений. Оператор этого экземпляра может по желанию включить журналирование активности запросов - в этом случае каждый запрос к инструменту (ваш IP-адрес, отметка времени, используемый инструмент и введённая цель/запрос) может записываться в базу данных в целях безопасности, предотвращения злоупотреблений и анализа использования. По умолчанию это отключено. Используя этот сайт, вы соглашаетесь с этими условиями; если вы не согласны, не используйте этот сайт.
Программное использование (API) этого сайта подчиняется тем же условиям, включая указанное выше требование авторизации.
Отправить отзыв
Сообщите о проблеме, оставьте комментарий или предложите новую функцию.
Этот сайт показывает рекламу и, если вы согласны, использует файлы cookie рекламных партнёров, чтобы помочь финансировать хостинг. Вы можете отказаться и продолжать пользоваться всеми инструментами без рекламы.