引言
起因是某个同事接到了领导安排下来的一个需求，要在一个Web应用（Java+Tomcat）中，记录用户登录时的IP地址和MAC地址，用于安全审计，于是咨询我如何实现。
第一反应是，这个需求本身是不成立的，根据以往的了解，MAC地址应该是过不了路由器的才对。
以往做开发，都是用engineer的思维：先动手做，遇到问题再解决问题。但这个需求，应当用scientist的思维去思考：首先确定能不能做，然后才是怎么做。
翻查了一些资料，想来证实"为什么WEB服务器，可以获取到客户端的IP地址，但获取不到MAC地址"，看着看着才发现，这是个挺大的命题，够写一篇BLOG了。
PS：由于个人对这块内容了解的不够彻底，本文很可能会有谬误，请读者先不要太当真，另外希望平台组的同事给予指证。
先说结论
我所认为的结论应该是这样的：
- 获取远程主机的IP地址是可行的（先不讨论使用代理的情况）
- 本地网络下，当我们已知一个IPv4地址后，可以通过ARP请求，获取对应的MAC地址。换句话说，MAC地址，只在本地网络下才有意义。
- 但我们无法透过路由器，获取其它网络下的IPv4节点的MAC地址。
下面一步步解释一下。
HTTP
先从HTTP说起。
HTTP是一个应用层的协议，它建立在TCP协议之上。
HTTP请求就是用来发送一段文本。关于这段文本如何组织，第一行写什么，第二行写什么，哪里加一个空行，就是HTTP协议所要规范的内容。
举个直接的例子，下面是一个简单的HTTP GET请求，有兴趣可以用telnet模拟一下。
GET http://www.fiddler2.com/UpdateCheck.aspx?isBeta=False HTTP/1.1
User-Agent: Fiddler/4.6.3.50306 (.NET 4.0; WinNT 5.1.2600 SP3; zh-CN; 2xx86; Auto Update; Full Instance; Extensions: Geoedge, AutoSaveExt, HostsFile, SAZClipboardFactory, EventLog, SimpleFilter, Timeline, APITesting)
Pragma: no-cache
Host: www.fiddler2.com
Accept-Language: zh-CN
Referer: http://fiddler2.com/client/4.6.3.50306
Accept-Encoding: gzip, deflate
Connection: close
我们可以看到，HTTP的这段请求中，完全找不到客户端的MAC地址，甚至连IP地址都没有描述。
那IP地址是从哪里取到的呢？接下来我们再深入一点，看下一个内容：Socket
Socket
HTTP的客户端和服务端，是通过Socket进行连接的。
Socket是什么呢？Socket是对OSI模型第4层-传输层中的TCP/IP协议的封装。Socket本身并不是协议，而是一个调用接口(API)。Socket和TCP/IP协议没有必然的联系。但通过Socket，我们才能使用TCP/IP协议。应用层不必了解TCP/IP协议细节，直接通过对Socket接口函数的调用完成数据在IP网络的传输。
Socket包含了网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。
所以，因为有了Socket，客户端和服务端完全不需要了解底层细节，直接通过调用Socket来实现就可以了。
这也就是为什么服务器端可以获取到客户端的IP地址的原因，因为Socket中包含了远地主机的IP地址。（当然，通过代理服务器进行访问的除外，这种要依靠HTTP协议的X-Forwarded-For头来确认IP，不在本次的讨论范围中）
那为什么无法获取到客户端的MAC地址呢？很简单，同理，因为Socket中无法取到MAC地址。。。
如果继续发问，为什么Socket中都既然都包含IP地址了，为什么偏偏不包含MAC地址信息呢？看来我们还要更深入一点，看一下OSI模型吧。
OSI七层模型
首先祭出这张经典的OSI七层模型图，计算机网络的基石，请先盯着看一会儿，认真复习一下
这里还有一张OSI七层模型与TCP/IP四层模型的对照图
为了方便理解，再放上一张更直观的，每一层对应的数据型式和主要协议的示意图
通过上图大体可以知道：
- MAC地址是记录在第2层-数据链路层的
- IP地址是记录在第3层-网络层的
- 端口号（TCP/UDP）是位于于第4层-传输层的
- HTTP请求报文是记录在第7层-应用层的
当打开一个URL时，究竟发生了什么
下面举个栗子，当我们在浏览器中打开一个链接后，看看OSI各层倒底发生了什么：
这里撇开DNS解析之类东西，只说一下HTTP报文的发送
1、发送端
首先来看一下发送端（浏览器所在的主机）。参照第一张OSI模型图，按照从上向下的顺序来看。应用层数据其实只有那么几行文本，然后往下，每过一层，都要被加上首部/尾部。这个过程就像是一层一层的穿衣服。
HTTP请求文本：
最后到了数据链路层之后，数据就变成了这个肥肥的样子，最后转换成0和1的电信号发出：
下面看看，现实中，每一层都做了些什么（现实中的分层和OSI模型还是有区别的）：
第7,6,5层，也就是OSI中的应用层,表示层,会话层（也是TCP/IP分层中的应用层），它创建了一个HTTP请求(例如 GET / HTTP/1.1)，并交给下一层。一个普通的HTTP GET请求就是几行纯文本。
处理这三层，是浏览器和WEB服务器所要做的工作，浏览器发出请求，WEB服务器做出响应。第4,3层，也就是传输层/网络层。TCP/IP栈将上层的数据分成包（packets），并将它送往下一层-数据链路层。
IP地址、端口号记录在这两层中。
处理这两层，是操作系统要做的工作，操作系统将这两层封装为了Socket，方便调用。第2层，数据链路层，将包（package）封装成帧（frame），并将它送到下一层物理层。
MAC地址记录在这一层中。
这一层的工作，交由网卡来处理。第1层，物理层，使用电信号来传送0和1。
最后这一层就是传输介质的工作了，例如双绞线、光纤、同轴电缆。
2、数据流转
数据发出去后，再看一下数据在网络上的流转。
数据一般要经过交换机、路由器等网络设备，层层转发，这些设备所做的事情就像是： 脱掉一件或几件衣服，做一些修修补补，然后再重新穿回去。
- 这里先以L2交换机为例看一下，因为L2交换机会认别到帧这一层，记录/学习MAC地址，并将帧发送到目的地。
通过上面这张图，我们就可以理解，MAC地址在本地网络下的重要作用了。也理解了，本地网络下，是可以查出每个节点的MAC地址的。
- 下面，再来看一下路由器。当一个LAN希望连接到另一个LAN时，就必须使用路由器设备了。当然，可以通过构建超大型的LAN，来避免使用路由器，但这时，交换机就需要管理大量的MAC地址，同时进行大量的广播通信，设备的负担就会相当大。路由器会进行路由选择，让数据达到下一跳。
经过路由器后，为了能到达下一跳，数据链路层中的MAC地址就被篡改了，下面这张图很能说明问题：
3、接收端
最后看一下接收端（WEB服务器所在的主机）。参照第一张OSI模型图，按照从下至上的顺序来看，它要做的事情是： 将衣服一件一件全部脱掉 ，最后WEB服务器就取到了最初的应用层数据。
4、结论
所以，当一个以太网帧到达目的主机后，其中的MAC地址早已经不是原来客户端的MAC了，操作系统的Socket自然也无法获取原始的MAC地址了。
可不可以通过其它方式获取MAC地址
上面已经证明了，WEB服务端，是无法获取客户端的MAC地址的。
那么，能不能通过一些trick来绕道实现呢？
想了想，大概可以有如下的思路：
- 通过JavaScrip获取客户端的某块网卡的MAC地址，最好还要同时获取路由表，挑选出走默认路由的那块网卡。
- 将MAC地址，偷偷写入应用层的HTTP协议的Header中（类似Content-Type和User-Agent）
- 服务端直接读Header，就可以取到Mac地址了
那么这个思路可不可行呢？
- 如果客户端是浏览器的话，首先第一步就会被打脸，我想也没有哪个浏览器会允许这种不安全的操作的。但如果硬要通过IE下的ActiveX来取的话，貌似也不是不可以。。。
- 但如果客户端是APP的话，通过WebView+JS Bridge方式调用私有的API，应该也是可行的。。。
记录MAC地址的意义
最后的最后，不禁思考，获取MAC的意义在哪里呢？
如果单纯是为了取证和审计，我想意义是不大的，甚至不如直接记录IP地址。
因为：
- 对于普通的正常用户而言，通过IP地址，是可以直接定位操作人的，即使IP是动态的。
- 对于初级以上Hacker来说，伪造MAC地址和伪造IP地址一样简单，甚至更简单。
所以，一般的安全管控要求下，还是只记录IP吧。
参考资料
- https://www.amazon.cn/图解网络硬件-日-三轮贤一/dp/B01531731E/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1488177601&sr=1-1&keywords=图解网络硬件
- https://www.amazon.cn/图解网络硬件-日-三轮贤一/dp/B01531731E/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1488177601&sr=1-1&keywords=图解网络硬件
- https://www.amazon.cn/HTTP权威指南-美-David-Gourley-Brian-Totty-Marjorie-Sayer-Sailu-Reddy-Aushu-Aggarwal/dp/B00M2DKYRC/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1488178503&sr=1-1&keywords=HTTP权威指南
- http://superuser.com/questions/801788/role-of-osi-layers-when-we-open-a-url-in-browser
