javaweb 程序怎么知道放在哪一个服务器IP 上运行了?

您好，Java语言是开源的，如果您的源码被盗用，那么随之的源码内容很可能会被修改。如果对方没有发现您内部实现的这个功能，可能您还可以发现被盗用后锁存放的ip地址，如果对方发现有这个功能，那么直接删除或者修改，您就没有办法了。如下几种方案供您参考：

1,混淆肯定要做不然再好的保护,被反编译了,修改代码,验证的方法照样被修改取消

2,数字签名,参照java安全机制,给你的jar签名,写自己专门的类加载classloader

3,参照单机软件保护措施,用非对称加密手段,保存自己的私钥

4,某些lib可以运行时加载,动态加载到内存里面,静态的lib是加密的,只有解密后的lib才可以加载运行

5,jni本地方法

采用多种验证方式,多个地方验证一般破解的受到挫折,就不干了

其实也不是很复杂,呵呵

你的web软件加上一个安装步骤,要求输入密钥,才能运行,呵呵

一、简单的说：

如果你的是winxp，

第一，右键网上邻居，选属性，

第二，右键本地连接，选属性，

第三，双击“internet协议”，选择“使用下面IP地址”，

第四，ip地址为“1921681”－－为2－225中任意的数

子网掩码，默认就可以，－－一般为“2552552550”

默认网关“19216811”－－你的路由器地址

首选DNS服务器，“19216811”－－也是你的路有器ip地址。

差不多了！希望对你有帮助！

二、复杂的说：

宽带路由器默认具有一个IP地址，且采用Web页管理方式。我们可以在

IE浏览器地址栏中输入

http://19216811

进入管理页面来对它进行设置(

大部分路由器出厂时默认的IP地址是“19216811”，

子网掩码为“2552552550")。我们要注意，现在直接在计算机的IE浏览器地址栏中输入“

http://19216811

”是无法访问管理页面的，道理很简单：IP地址要处于同一个网段才可以进行访问。于是我们首先要修改计算机本地连接的IP地址。

进入局域网中任意一台计算机系统“本地连接”的"TCP／IP属性”对话框。在该对话框中，将IP地址设置为"1921681X”(x为2-253的自然数)，同时将网关设置为“19216811"。连续两次“确定”后，设置立即生效。现在，我们可以在IE地址栏中输入

http://19216811

进入

TL-R402的管理页面了。

在出现的登录页面左侧登录框输入默认密码“admin”进入管理页面。然后点下一步

来将

WAN类型更

改

为“PPPoE”

(局域网上的点对点协议)，这是因为ADSL拨号采用的是该协议。在这里，我们要填写ADSL的账号和密码(即ISP提供给你的ADSL用户名和密码)，以后，拨号的任务就交给TL-R402了。填写完毕后保存设置。

在IE地址栏中输入“

http://19216811

”并“回车”，然后输入管理密码进入TL-R402管理页面，点状态里边的连接按钮进行拨号连接。等待约5秒钟后，连接成功，同时TL-R402将显示获得的公有IP地址、ISP的DNS服务器地址等信息

现在客户机可以上网了。打开IE，输入网址——

GO！！

以后要上网时，只要将

ADSL

MODEM和TL—R402的电源打开，TL—R402就会自动拨号连接上

Internet。这时计算机登录后，就可以直接上网了，无须任何额外的操作。如果不想上网了，关闭TL-R400的电源即可。

虚拟服务器设置：定义了广域网服务端口与局域网服务器的映射关系，轻松组建WEB服务器，FTP服务器。

如果你的本地连接TCP/IP的协议IP是19216812那么别人的机子就是19216813等等向下排就是了好了现在可以上网了

你的描述有点混乱，我理解到的意思是这样的，你看对不对：

1、需求：web服务器由防火墙映射到公网地址222185223x上，现在想实现内网终端（A和B），可以通过访问222185223x这个地址打开网站。

2、分析：现在由于只做了一条NAT规则，也就是把web服务器映射到公网上。当内网终端访问公网地址的时候，防火墙把数据包的目的地址转化为web服务器的内网地址后，发给了服务器，服务器回包的时候，源地址写终端的内网地址，所以该数据包直接通过核心交换就给了客户端，客户端看到回包地址不是防火墙的公网地址，所以就丢掉了这个数据包。

3、解决：

在防火墙再做一条规则，凡是由内网终端网段去往访问web服务器地址（1921680x），都需要进行源地址转换，转换成防火墙任意一个接口地址即可，例如防火墙接华为S3900的那个接口地址即可。

客户端首先访问最近的一台DNS服务器（客户端的TCP/IP设置中填写的DNS服务器地址），假设要查询wwwlabglasscomcom这台Web服务器的相关信息（图116①）。

由于最近的DNS服务器中没有存放wwwlabglasscomcom域名对应的信息，所以需要从顶层开始向下查找。

最近的DNS服务器中保存了根域DNS服务器的信息，因此它会将来自客户端的查询消息转发给根域DNS服务器（图116②）。

根域服务器中也没有这个域名，但根据域名结构可以判断这个域名属于com域，因此根域DNS服务器会返回它所管理的com域中的DNS服务器的IP地址。

接下来，最近的DNS服务器又会向com域的DNS服务器发送查询消息（图116③）。

com域中也没有wwwlabglasscomcom这个域名的信息，和刚才一样，com域服务器会返回它下面的glasscomcom域的DNS服务器的IP地址。

以此类推，只要重复前面的步骤，就可以顺藤摸瓜找到目标DNS服务器（图116⑤），只要向目标DNS服务器发送查询消息，就能得到wwwlabglasscomcom的IP地址了。

当然，DNS服务器有一个 缓存 功能，可以记住之前查询过的域名。如果要查询的域名和相关信息在缓存中，就可以直接返回响应，接下来的查询可以从缓存的位置开始向下进行。

这个缓存机制中有一点需要注意，那就是信息被缓存后，原本的注册信息可能会发生改变，这时缓存中的信息就有可能是不正确的。因此，DNS服务器中保存的信息都设置有一个 有效期 ，当缓存中的信息超过有效期后，数据就会从缓存中删除。而且，在对查询进行响应时，DNS服务器也会告知客户端这一 响应的结果是来自 缓存中 还是来自 负责管理该域名的DNS服务器。

本文摘取自周自恒翻译的户根勤编写的《网络是怎样连接的》。

   获得项目服务器的IP大概做法是在配置文件里面进行配置，可以使服务器已启动便执行，示例如下：

启动服务器的时候启动一个类，可以在webxml中配置，如下：

<servlet>

    <servlet-name></servlet-name>

    <servlet-class></servlet-class>

    <init-param>

      <param-name>basedir</param-name>

      <param-value></param-value>

    </init-param>

    <load-on-startup>1</load-on-startup>

  </servlet>

指明你需要启动的servlet即可

起因是某个同事接到了领导安排下来的一个需求，要在一个Web应用（Java+Tomcat）中，记录用户登录时的IP地址和MAC地址，用于安全审计，于是咨询我如何实现。

第一反应是，这个需求本身是不成立的，根据以往的了解，MAC地址应该是过不了路由器的才对。

以往做开发，都是用engineer的思维：先动手做，遇到问题再解决问题。但这个需求，应当用scientist的思维去思考：首先确定能不能做，然后才是怎么做。

翻查了一些资料，想来证实" 为什么WEB服务器，可以获取到客户端的IP地址，但获取不到MAC地址 "，看着看着才发现，这是个挺大的命题，够写一篇BLOG了。

PS：由于个人对这块内容了解的不够彻底， 本文很可能会有谬误 ，请读者先不要太当真，另外希望平台组的同事给予指证。

我所认为的结论应该是这样的：

下面一步步解释一下。

先从HTTP说起。

HTTP是一个应用层的协议，它建立在TCP协议之上。

HTTP请求就是用来发送一段文本。关于这段文本如何组织，第一行写什么，第二行写什么，哪里加一个空行，就是HTTP协议所要规范的内容。

举个直接的例子，下面是一个简单的HTTP GET请求，有兴趣可以用telnet模拟一下。

我们可以看到，HTTP的这段请求中，完全找不到客户端的MAC地址，甚至连IP地址都没有描述。

那IP地址是从哪里取到的呢？接下来我们再深入一点，看下一个内容：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七层模型与TCP/IP四层模型的对照图

为了方便理解，再放上一张更直观的，每一层对应的数据型式和主要协议的示意图

通过上图大体可以知道：

下面举个栗子，当我们在浏览器中打开一个链接后，看看OSI各层倒底发生了什么：

这里撇开DNS解析之类东西，只说一下HTTP报文的发送

首先来看一下发送端（浏览器所在的主机）。参照第一张OSI模型图，按照从上向下的顺序来看。应用层数据其实只有那么几行文本，然后往下，每过一层，都要被加上首部/尾部。 这个过程就像是一层一层的穿衣服 。

HTTP请求文本：

数据发出去后，再看一下数据在网络上的流转。

数据一般要经过交换机、路由器等网络设备，层层转发，这些设备所做的事情就像是： 脱掉一件或几件衣服，做一些修修补补，然后再重新穿回去 。

通过上面这张图，我们就可以理解，MAC地址在本地网络下的重要作用了。也理解了，本地网络下，是可以查出每个节点的MAC地址的。

经过路由器后，为了能到达下一跳，数据链路层中的MAC地址就被篡改了，下面这张图很能说明问题：

最后看一下接收端（WEB服务器所在的主机）。参照第一张OSI模型图，按照从下至上的顺序来看，它要做的事情是： 将衣服一件一件全部脱掉 ，最后WEB服务器就取到了最初的应用层数据。

所以，当一个以太网帧到达目的主机后，其中的MAC地址早已经不是原来客户端的MAC了，操作系统的Socket自然也无法获取原始的MAC地址了。

上面已经证明了，WEB服务端，是无法获取客户端的MAC地址的。

那么，能不能通过一些trick来绕道实现呢？

想了想，大概可以有如下的思路：

那么这个思路可不可行呢？

最后的最后，不禁思考，获取MAC的意义在哪里呢？

如果单纯是为了取证和审计，我想意义是不大的，甚至不如直接记录IP地址。

因为：

所以，一般的安全管控要求下，还是只记录IP吧。