关于内网机器外网怎么找到的

http://bbs.csdn.net/topics/100180750

给楼主一点实际,不要空说。谁不会空口白话呢?
具体代码呢?
—你有病 这是理论 用代码 他看得懂不?

我说吧。LZ问的是信息怎么正确传送到局域网的主机上的,对不对。
所有的局域网内的网络应用程序都是由内网首先向一公网发送一信息开始的(不考虑局域网内主机的情况,那没意思)。至于为什么,这涉及到目前网络现状问题。
大家知道在Internet IPV4协议中一台主机拥有一全球唯一的IP用于网上通信。而电脑及网络的普及,使得这些唯一的IP不足以分配,这就使得新的协议IPV6的出现,但仍不足以解决问题。
而局域网的出现恰是为了解决这一问题,使得一局域网内的大量用户仅靠少量(到少一个)全球唯一的IP就可以实现网上通信。
网关负责管理这一切。网关处维护一张内网用户与外网IP连接所用到的IP 映射。
大家知道Ip一般是以192.  .  .  等开头的。如局域网的全球唯一IP为126.126.126.126
内网一主机一程序发一包对应内网IP为 192.192.192.192(Port 5555)  到外网的一Ip 设为125.125.125.125 (Port 8888)
则网关会接收此主机的数据包并转发给125.125.125.125(5555) 但会对数据包的IP头做一些加工
如 ,替换原内网Ip(192.192.192.192) 和Potr(5555) 改为外网IP(126.126.126.126)和Port(随机分配设为1250) .
网关会将这次包对应内网 IP Port 和使用的外网端口(5555)以及外网Ip(125.125.125.125 5555)之间的映射作为一条信息记录下来。
这样对于所有接收内网用户包的服务端(125.125.125.125 8888),并不知道接收到的主机在内网的Ip信息,而只知道是来自126.126.126.126 (5555),并将所需要回送的包发给126.126.126.126 (5555)。 网关根据记录的映射把包传给映射中记录的对应IP的主机的对应端口。

这就是为何外部服务总能把信息传送到对应的主机上。

————————————————————————————-

个人理解:有点类似于网络代理,这个网关服务器,其实就是类似一个代理,将内网数据传输给外网服务器,接收的外网服务器数据传输给内网机器。
网关内部有一个映射表,用于记录内网的活动请求设备的IP和端口号(同时记录有给其分配的对外随机端口号)。这样,来自外部的数据建立连接后,外部连接包含的信息中的请求端口号就相当于是这个映射表的ID,取出这个ID,就得到了内部设备的IP和端口号,然后将其转发给内网设备。

HHVM提升PHP执行性能的方式

http://www.csdn.net/article/2014-12-19/2823234?foxhandler=rssreadrenderprocesshandler

HHVM提升PHP性能的途径,采用的方式就是替代Zend引擎来生成和执行PHP的中间字节码(HHVM生成自己格式的中间字节码),执行时通过JIT(Just In Time,即时编译是种软件优化技术,指在运行时才会去编译字节码为机器码)转为机器码执行。Zend引擎默认做法,是先编译为opcode,然后再逐条执行,通常每条指令对应的是C语言级别的函数。如果我们产生大量重复的opcode(纯PHP写的代码和函数),对应的则是Zend多次逐条执行这些C代码。而JIT所做的则是更进一步,将大量重复执行的字节码在运行的时候编译为机器码,达到提高执行效率的目的。通常,触发JIT的条件是代码或者函数被多次重复调用。

普通的PHP代码,因为无法固定变量的类型,需要额外添加判断类型的逻辑代码,这样PHP代码是不利于CPU执行和优化的。因此,HHVM通常需要用到Hack写法(为了兼容某种特性而额外添加的技巧性质的代码)的PHP代码来“配合”,就是为了让变量类型固定,方便虚拟机编译执行。PHP追求以一种形式来容纳一切类型,而Hack则可以将被容纳的一切标记上确定的类型。

PHP数据库长连接mysql_pconnect的细节

http://www.nowamagic.net/librarys/veda/detail/95

PHP的MySQL持久化连接,美好的目标,却拥有糟糕的口碑,往往令人敬而远之。这到底是为啥么。近距离观察后发现,这家伙也不容易啊,要看Apache的脸色,还得听MySQL指挥。

对于作为Apache模块运行的PHP来说,要实现MySQL持久化连接,首先得取决于Apache这个web服务器是否支持Keep-Alive。

Keep-Alive

Keep-Alive是什么东西?它是http协议的一部分,让我们复习一下没有Keep-Alive的http请求,从客户在浏览器输入一个有效url地址开始,浏览器就会利用socket向url对应的web服务器发送一条TCP请求,这个请求成功一次就得需要来回握三次手才能确定,成功以后,浏览器利用socket TCP连接资源向web服务器请求http协议,发送以后就等着web服务器把http返回头和body发送回来,发回来后浏览器关闭socket连接,然后做http返回头和body的解析工作,最后呈现在浏览器上的就是漂亮的页面了。这里面有什么问题呢?TCP连接需要三次握手,也就是来回请求三次方能确定一个TCP请求是否成功,然后TCP关闭呢?来回需要4次请求才能完成!每次http请求就3次握手,4次拜拜,这来来回回的不嫌累啊,多少时间和资源都被浪费在socket连接关闭上了,能不能一次socket TCP连接发送多次http请求呢?于是Keep-Alive就应运而生,http/1.0里需要客户端自己在请求头加入Connection:Keep-alive方能实现,在这里我们只考虑http1.1了,只需要设置一下Apache,让它默认就是Keep-Alive持久连接模式(Apache必须1.2+才能支持Keep-Alive)。在httpd.conf里找到KeepAive配置项,果断设置为On,MaxKeepAliveRequests果断为0(一个持久TCP最多允许的请求数,如果过小,很容易在TCP未过期的情况下,达到最大连接,那下次连接就又是新的TCP连接了,这里设置0表示不限制),然后对于mysql_pconnect最重要的选项KeepAliveTimeout设置为15(表示15秒)。

好了,重启Apache,测试一下,赶紧写行东西:

1 <?php
2     echo "Apache进程号:". getmypid();
3 ?>

很简单,获取当前PHP执行者(Apache)的进程号,用浏览器浏览这个页面,看到什么?对,有看到一串进程号数字,15秒内,连续刷新页面,看看进程号有无变化?木有吧?现在把手拿开,交叉在胸前,度好时间,1秒,2秒,3,…15,16。好,过了15秒了,再去刷新页面,进程号有没有变化?变了!又是一个新的Apache进程了,为什么15秒后就变成新的进程了?记得我们在Apache里设置的KeepAliveTimeout吗?它的值就是15秒。现在我们应该大致清楚了,在web服务器默认打开KeepAlive的情况下,客户端第一次http成功请求后,Apache不会立刻断开socket,而是一直监听来自这一客户端的请求,监听多久?根据KeepAliveTimeout选项配置的时间决定,一旦超过这一时间,Apache就会断开socket了,那么下次同一客户端再次请求,Apache就会新开一个进程来相应。所以我们之前15内不停的刷新页面,看到的进程号都是一致的,表明是浏览器请求给了同一个Apache进程。

浏览器是怎么知道不需要重新进行TCP连接就可以直接发送http请求呢?因为http返回头里就会带上Connection:keep-alive,Keep-alive:15两行,意思就是让客户端浏览器明白,这次socket连接我这边还没关闭呢,你可以在15内继续使用这个连接,并发送http请求,于是乎浏览器就知道应该怎么做了。

PHP怎么做

那么,PHP的MySQL连接资源是怎么被hold住的呢,这需要查看PHP的mysql_pconnect的函数代码,我看了下,大概的做法就是mysql_pconnect根据当前Apache进程号,生成hash key,找hash表内有无对应的连接资源,没有则推入hash表,有则直接使用。有些代码片段可以说明(具体可查看PHP5.3.8源码ext/mysql/PHP_mysql.c文件690行PHP_mysql_do_connect函数)

01 #1.生成hash key
02 user=php_get_current_user();//获取当前PHP执行者(Apache)的进程唯一标识号
03 //hashed_details就是hash key
04 hashed_details_length = spprintf(&hashed_details, 0, "MySQL__%s_", user);
05 #2.如果未找到已有资源,就推入hash表,名字叫persistent_list,如果找到就直接使用
06 /* try to find if we already have this link in our persistent list */
07 if (zend_hash_find(&EG(persistent_list), hashed_details, hashed_details_length+1, (void **) &le)==FAILURE) { 
08     /* we don't */
09     ...
10     ...
11     /* hash it up(推入hash表) */
12     Z_TYPE(new_le) = le_plink;
13     new_le.ptr = mysql;
14     if (zend_hash_update(&EG(persistent_list), hashed_details, hashed_details_length+1, (void *) &new_le, sizeof(zend_rsrc_list_entry), NULL)==FAILURE) {
15         ...
16         ...     
17         }
18     }
19     else
20     {/* The link is in our list of persistent connections(连接已在hash表里)*/
21         ...
22         ...
23         mysql = (PHP_mysql_conn *) le->ptr;//直接使用对应的sql连接资源
24         ...
25         ...
26     }

zend_hash_find比较容易看明白,原型是zend_hash_find(hash表,key名,key长,value);如果找到,value就有值了。

MySQL的wait_timeout和interactive_timeout

说完Keep-Alive,该到MySQL家串串门了,说的是mysql_pconnect,怎么能绕开MySQL的设置。影响mysql_pconnect最重要的两个参数就是wait_timeout和interactive_timeout,它们是什么东西?先撇一边,首先让我们把上面的代码改动一下PHP代码

1 <?php
2     $conn = mysql_pconnect("localhost","root","123456") or die("Can not connect to MySQL");
3     echo "MySQL线程号:". MySQL_thread_id($conn). "<br />";
4     echo "Apache进程号". getmypid();
5 ?>

以上的代码没啥好解释的,让我们用浏览器浏览这个页面,看到什么?看到两个显眼的数字。一个是MySQL线程号,一个是Apache进程号,好了,15秒后再刷新这个页面,发现这两个id都变了,因为已经是新的Apache进程了,进程id是新的,hash key就变了,PHP只好重新连接MySQL,连接资源推入persistent list。如果15内刷新呢?Apache进程肯定不变,MySQL线程号会变吗?答案得问MySQL了。首先这个MySQL_thread_id是什么东西?shell方式登录MySQL后执行命令’show processlist;’,看到了什么?

1 mysql> show processlist;
2 +-----+------+-----------+------+--------+-----+------+-----------------+
3 | Id  | User | Host      | db   | Command| Time| State| Info            |
4 +-----+------+-----------+------+--------+-----+------+-----------------+
5 | 348 | root | localhost | NULL | Query  |    0| NULL | show processlist|
6 | 349 | root | localhost | NULL | Sleep  |    2|      | NULL            |
7 +-----+------+-----------+------+--------+-----+------+-----------------+

发现了很重要的信息,这个processlist列表就是记录了正在跑的线程,忽略Info列为show processlist那行,那行是你当前shell登录MySQL的线程。PHP连接MySQL的线程就是Id为349那行,如果读者自己做测试,应该知道这个Id=349在你的测试环境里是另外一个值,我们把这个值和网页里输出的MySQL_thread_id($conn)做做比较,对!他们是一样的。接下来最重要的是观察Command列和Time列,Command = Sleep,表明什么?表明我们mysql_pconnect连接后就一直在sleep,Time字段就告诉我们,这个线程Sleep了多久,那么Sleep了多久这个线程才能作废呢?那就是wait_timeout或者interactive_timeout要做的工作了,他们默认的值都是8小时,天啊,太久了,所以如果说web服务器关掉KeepAlive支持,那个这个processlist很容易就被撑爆,就爆出那个Too many connections的错误了,max_connectiosns配置得再多也没用。为了观察这两个参数,我们可以在MySQL配置文件my.cnf里设置这两个值,找到[MySQLd]节点,在里面设置多两行

1 interactive_timeout = 60
2 wait_timeout        = 30

配置完后,重启MySQL,shell登录MySQL,这时候show processlist可以发现只有当前线程。然后运行那个带有mysql_pconnect的PHP页面,再回来MySQL端show processlist可发现,多了一个Commond为Sleep的线程,不停的show processlist(方向键上+enter键)观察Time列的变化2,5,10…14!,突然那个Sleep线程程被kill掉了,咋回事,还没到30秒呢,噢!忘了修改一下Apache keepalive的参数了,把KeepAliveTimeOut从15改成120(只为观察,才这么改),重启Apache。刷新那个页面,好,开始不停的show processlist,2..5..10..14,15,..20…26….28,29!线程被kill,这次是因为wait_timeout起了作用,浏览器那边停了30秒,30内如果浏览器刷新,那这个Time又会从0开始计时。这种连接不属于interactive connection(MySQL shell登录那种连接就属于interactive connection),所以采用了wait_timeout的值。如果mysql_pconnect的第4个参数改改呢

1 <?php
2 $conn = mysql_pconnect('localhost','root','123456',MySQL_CLIENT_INTERACTIVE);
3 echo "MySQL线程号:".MySQL_thread_id($conn)."<br />";
4 echo "Apache进程号:".getmypid();
5 ?>

刷新下页面,MySQL那边开始刷show processlist,这回Time > 30也不会被kill,>60才被kill了,说明设置了MySQL_CLIENT_INTERACTIVE,就会被MySQL视为interactive connection,那么这次PHP的MySQL连接在120秒内未刷新的情况下,何时作废将取决于MySQL的interactive_timeout的配置值。

总结

PHP的mysql_pconnect要达到功效,首先必须保证Apache是支持keep alive的,其次KeepAliveTimeOut应该设置多久呢,要根据自身站点的访问情况做调整,时间太短,keep alive没啥意义,时间太长,就很可能为一个闲客户端连接牺牲很多服务器资源,毕竟hold住socket监听进程是要消耗cpu内存的。最后Apache的KeepAliveTimeOut配置得和MySQL的time out配置要有个平衡点,联系以上的观察,假设mysql_pconnect未带上第4个参数,如果Apache的KeepAliveTimeOut设置的秒数比wait_timeout小,那真正对mysql_pconnect起作用的是Apache而不是MySQL的配置。这时如果MySQL的wait_timeout偏大,并发量大的情况下,很可能就一堆废弃的connection了,MySQL这边如果不及时回收,那就很可能Too many connections了。可是如果KeepAliveTimeOut太大呢,又回到之前的问题,所以貌似Apache。KeepAliveTimeOu不要太大,但比MySQL。wait_timeout 稍大,或者相等是比较好的方案,这样可以保证keep alive过期后,废弃的MySQL连接可以及时被回收。

PDO防注入原理分析以及使用PDO的注意事项

http://zhangxugg-163-com.iteye.com/blog/1835721

我们都知道,只要合理正确使用PDO,可以基本上防止SQL注入的产生,本文主要回答以下两个问题:

为什么要使用PDO而不是mysql_connect?

为何PDO能防注入?

使用PDO防注入的时候应该特别注意什么?

一、为何要优先使用PDO?

PHP手册上说得很清楚:

Prepared statements and stored procedures
Many of the more mature databases support the concept of prepared statements. What are they? They can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize its plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down an application if there is a need to repeat the same query many times with different parameters. By using a prepared statement the application avoids repeating the analyze/compile/optimize cycle. This means that prepared statements use fewer resources and thus run faster.

The parameters to prepared statements don’t need to be quoted; the driver automatically handles this. If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur(however, if other portions of the query are being built up with unescaped input, SQL injection is still possible).

即使用PDO的prepare方式,主要是提高相同SQL模板查询性能、阻止SQL注入

同时,PHP手册中给出了警告信息

Prior to PHP 5.3.6, this element was silently ignored. The same behaviour can be partly replicated with the PDO::MYSQL_ATTR_INIT_COMMAND driver option, as the following example shows.
Warning

The method in the below example can only be used with character sets that share the same lower 7 bit representation as ASCII, such as ISO-8859-1 and UTF-8. Users using character sets that have different representations (such as UTF-16 or Big5) must use the charset option provided in PHP 5.3.6 and later versions.

意思是说,在PHP 5.3.6及以前版本中,并不支持在DSN中的charset定义,而应该使用PDO::MYSQL_ATTR_INIT_COMMAND设置初始SQL, 即我们常用的 set names gbk指令。

我看到一些程序,还在尝试使用addslashes达到防注入的目的,殊不知这样其实问题更多, 详情请看http://www.lorui.com/addslashes-mysql_escape_string-mysql_real_eascape_string.html

还有一些做法:在执行数据库查询前,将SQL中的select, union, ….之类的关键词清理掉。这种做法显然是非常错误的处理方式,如果提交的正文中确实包含 the students’s union , 替换后将篡改本来的内容,滥杀无辜,不可取。

二、为何PDO能防SQL注入?
请先看以下PHP代码:

<?php

$pdo = new PDO(“mysql:host=192.168.0.1;dbname=test;charset=utf8″,”root”);

$st = $pdo->prepare(“select * from info where id =? and name = ?”);

$id = 21;

$name = ‘zhangsan’;

$st->bindParam(1,$id);

$st->bindParam(2,$name);

$st->execute();

$st->fetchAll();

?>

环境如下:

PHP 5.4.7

Mysql 协议版本 10

MySQL Server 5.5.27

为了彻底搞清楚php与mysql server通讯的细节,我特别使用了wireshark抓包进行研究之,安装wireshak之后,我们设置过滤条件为tcp.port==3306, 如下图:

如此只显示与mysql 3306端口的通信数据,避免不必要的干扰。

特别要注意的是wireshak基于wincap驱动,不支持本地环回接口的侦听(即使用php连接本地mysql的方法是无法侦听的),请连接其它机器(桥接网络的虚拟机也可)的MySQL进行测试。

然后运行我们的PHP程序,侦听结果如下,我们发现,PHP只是简单地将SQL直接发送给MySQL Server :

其实,这与我们平时使用mysql_real_escape_string将字符串进行转义,再拼接成SQL语句没有差别(只是由PDO本地驱动完成转义的),显然这种情况下还是有可能造成SQL注入的,也就是说在php本地调用pdo prepare中的mysql_real_escape_string来操作query,使用的是本地单字节字符集,而我们传递多字节编码的变量时,有可能还是会造成SQL注入漏洞(php 5.3.6以前版本的问题之一,这也就解释了为何在使用PDO时,建议升级到php 5.3.6+,并在DSN字符串中指定charset的原因。

针对php 5.3.6以前版本,以下代码仍然可能造成SQL注入问题:

$pdo->query(‘SET NAMES GBK’);

$var = chr(0xbf) . chr(0x27) . ” OR 1=1 /*”;

$query = “SELECT * FROM info WHERE name = ?”;

$stmt = $pdo->prepare($query);

$stmt->execute(array($var));

原因与上面的分析是一致的。

而正确的转义应该是给mysql Server指定字符集,并将变量发送给MySQL Server完成根据字符转义。

那么,如何才能禁止PHP本地转义而交由MySQL Server转义呢?

PDO有一项参数,名为PDO::ATTR_EMULATE_PREPARES ,表示是否使用PHP本地模拟prepare,此项参数默认值未知。而且根据我们刚刚抓包分析结果来看,php 5.3.6+默认还是使用本地变量转,拼接成SQL发送给MySQL Server的,我们将这项值设置为false, 试试效果,如以下代码:

<?php

$pdo = new PDO(“mysql:host=192.168.0.1;dbname=test;”,”root”);

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

$st = $pdo->prepare(“select * from info where id =? and name = ?”);

$id = 21;

$name = ‘zhangsan’;

$st->bindParam(1,$id);

$st->bindParam(2,$name);

$st->execute();

$st->fetchAll();

?>

红色行是我们刚加入的内容,运行以下程序,使用wireshark抓包分析,得出的结果如下:

看到了吗?这就是神奇之处,可见这次PHP是将SQL模板和变量是分两次发送给MySQL的,由MySQL完成变量的转义处理,既然变量和SQL模板是分两次发送的,那么就不存在SQL注入的问题了,但需要在DSN中指定charset属性,如:

$pdo = new PDO(‘mysql:host=localhost;dbname=test;charset=utf8’, ‘root’);

如此,即可从根本上杜绝SQL注入的问题。如果你对此不是很清楚,可以发邮件至zhangxugg@163.com, 一起探讨。

三、使用PDO的注意事项

知道以上几点之后,我们就可以总结使用PDO杜绝SQL注入的几个注意事项:

1.  php升级到5.3.6+,生产环境强烈建议升级到php 5.3.9+ php 5.4+,php 5.3.8存在致命的hash碰撞漏洞。

2. 若使用php 5.3.6+, 请在在PDO的DSN中指定charset属性

3. 如果使用了PHP 5.3.6及以前版本,设置PDO::ATTR_EMULATE_PREPARES参数为false(即由MySQL进行变量处理),php 5.3.6以上版本已经处理了这个问题,无论是使用本地模拟prepare还是调用mysql server的prepare均可。在DSN中指定charset是无效的,同时set names <charset>的执行是必不可少的。

4. 如果使用了PHP 5.3.6及以前版本, 因Yii框架默认并未设置ATTR_EMULATE_PREPARES的值,请在数据库配置文件中指定emulatePrepare的值为false。

那么,有个问题,如果在DSN中指定了charset, 是否还需要执行set names <charset>呢?

是的,不能省。set names <charset>其实有两个作用:

A.  告诉mysql server, 客户端(PHP程序)提交给它的编码是什么

B.  告诉mysql server, 客户端需要的结果的编码是什么

也就是说,如果数据表使用gbk字符集,而PHP程序使用UTF-8编码,我们在执行查询前运行set names utf8, 告诉mysql server正确编码即可,无须在程序中编码转换。这样我们以utf-8编码提交查询到mysql server, 得到的结果也会是utf-8编码。省却了程序中的转换编码问题,不要有疑问,这样做不会产生乱码。

那么在DSN中指定charset的作用是什么? 只是告诉PDO, 本地驱动转义时使用指定的字符集(并不是设定mysql server通信字符集),设置mysql server通信字符集,还得使用set names <charset>指令。

如果图片丢失,可以发邮件至zhangxugg@163.com, 索取PDF版本。

我真想不通,一些新的项目,为何不使用PDO而使用传统的mysql_XXX函数库呢?如果正确使用PDO,可以从根本上杜绝SQL注入,我强烈建议各个公司的技术负责人、一线技术研发人员,要对这个问题引起重视,尽可能使用PDO加快项目进度和安全质量。

不要再尝试自己编写SQL注入过滤函数库了(又繁琐而且很容易产生未知的漏洞)。