Почему сервер не может получить клиентский MAC-адрес, как клиентский IP?
Из того, что я знаю, все MAC-адреса, что прошедший пакет находится в пакете. Это вызвано тем, что тот каждый пакет, который входит в определенный путь, должен также быть возвращен в подобном пути. Так, если маршрутизатор сервера знает о MAC-адресе клиента (все они), почему страница сервера (как aspx) не может иметь этой информации?
Дайте объяснение. (не просто скажите мне, что я неправ).
Если я понимаю это правильно, клиент отправляет пакет, который содержит, это - MAC-адрес. когда к пакету проходят прокси (как маршрутизатор клиента), адрес прокси добавляется к пакету также. и так далее.
Вот отрывок из Википедии о слое строки данных TCP/IP:
http://en.wikipedia.org/wiki/TCP/IP_model#Data_Link_Layer
Канальный уровень используется для перемещения пакетов между интернет-интерфейсами Слоя двух различных хостов на той же ссылке. Процессами передачи и получения пакетов на данной ссылке можно управлять оба в драйвере устройства программного обеспечения для сетевой платы, а также на встроенном микропрограммном обеспечении или специализированных чипсетах. Они выполнят функции канала передачи данных, такие как добавление заголовка пакета для подготовки его к передаче, затем на самом деле передадут кадр по физической среде. Модель TCP/IP включает спецификации перевода методов обращения сети, привыкших в Протоколе Интернета к обращению канала передачи данных, таких как Управление доступом к среде (MAC), однако все другие аспекты ниже того уровня, как неявно предполагается, существуют на Канальном уровне, но явно не определяются.
7 ответов
Простое отличие: IP-адреса являются сквозными адресами (конечно, в IP-пакете), тогда как MAC-адреса используются только шаг за шагом. Кроме того, базовый протокол MAC может изменяться на каждом переходе без ведома клиента, поэтому клиент может даже не понимать все адреса на пути своего IP-пакета.
Фактически, MAC-адрес, хранящийся в пакете , изменяется на каждом шаге пути пакета.
MAC - это сокращение от Media Access Control, где носитель относится к локальной среде связи. В то время как IP-адреса источника и назначения остаются неизменными на протяжении всего пути (и используются для принятия решений о маршрутизации на большие расстояния), MAC-адреса источника и назначения просто указывают следующий переход.
Из-за этого MAC-адрес, хранящийся в пакетах, полученных вашим сервером, должен быть MAC-адресом вашей точки присутствия-маршрутизатора или оборудования вашего провайдера.
Возможно, вы захотите взглянуть на модель уровня OSI и инкапсуляцию .
У вас перепутаны отношения между IP-стеком и физическим стеком. MAC-адрес находится в части, которая оборачивает информацию IP, а не наоборот. Поэтому, когда я отправляю что-то с моего компьютера, скажем, на ваш, физический сегмент моей локальной сети (в данном случае Ethernet) оборачивает IP-информацию и включает мой MAC-адрес. Затем маршрутизатор извлекает IP-информацию и передает ее дальше и выше (в данном случае снова по Ethernet) моему DSL-модему, используя при этом свой собственный MAC. DSL-модем разворачивает IP-информацию и отправляет ее по телефонной линии, используя любой протокол, который он использует (не знаю и не забочусь об этом), в ... ну, вы поняли идею. Каждый переход по физическому каналу связи заворачивает и разворачивает IP-информацию, используя любую дополнительную информацию, приложенную физическим уровнем для локальной передачи.
Не существует "маршрутизатора сервера". Пакеты могут достигать сервера от многих маршрутизаторов.
Не существует "маршрутизатора клиента". Пакеты могут отправляться от клиента на множество маршрутизаторов.
Единственными устройствами, которые могут видеть MAC-адрес, являются устройства в той же локальной сети - возможно, только те, которые находятся в том же сегменте кабеля.
BTW, сервер также не может получить IP-адрес клиента, если клиент находится на другой стороне прокси-сервера.
Вы не можете - если только клиент не является локальным для вашего сервера. Если это так, вы можете попробовать выполнить arp-ping и получить mac-адрес клиента таким образом.
Вы думаете о прямом соединении между LAN сервера и LAN клиента, а Интернет работает не так. Между двумя локальными сетями может быть любое количество переходов - и, кстати, нет никаких ограничений, чтобы любая из них использовала что-либо вроде MAC, поэтому «MAC-адреса» не помещаются в IP-пакеты. «MAC» имеет смысл только в пределах LAN (фактически только один, нижние уровни которого действительно используют что-то вроде MAC ;-), и обнаруживаются / объявляются с помощью протоколов ARP и RARP (которые не маршрутизируются ;-).
Это IP-адрес источника и назначения, которые остаются. Идея межсетевого взаимодействия основана на передаче данных по принципу hop-to-hop. Промежуточные маршрутизаторы/хосты понимают только MAC-адреса. Насколько я знаю, таблицы маршрутизации должны понимать машинный адрес.
Если бы MAC-адреса могли оставаться на протяжении всего пути пакета, это означало бы, что не было бы необходимости в изобретении адресов Интернет-протокола. И весь Интернет использовал бы только MAC-адреса :-)
Вы можете достичь желаемого, только если сервер и клиент находятся в одной локальной сети (оба хоста соединены некоторым L1-носителем).
Учитывая это, ваше приложение похоже на Web-сервер, что говорит мне о том, что он не обязательно должен находиться в той же сети.
И все же, если вам нужен MAC-адрес хоста-источника на хосте-получателе; подумайте, не послать ли его в качестве полезной нагрузки?
Добавление:
Сети не обязательно должны быть одного типа по всему миру (например, Ethernet, Frame relay и т.д.). Сетевой уровень предоставляет нам гибкость маршрутизации без различия между нижележащими уровнями (Data Link Layer) или, я бы сказал, нижележащими технологиями L1. Короче говоря, IP обеспечит нам межсетевое взаимодействие, а Data Link Layer (на котором появляются MAC-адреса) позаботится о связи на микроуровне (т.е. в локальной сети). Это справедливая причина, по которой Mac- и IP-адреса сосуществуют! :-)
.