Windows上创建硬链接
[ 2010/09/27 16:33 | by selboo ]
Unix上可以方便的创建软链接和硬链接。可以提供额外的访问文件的接口而无需复制文件,大大减小了重复文件的空间浪费和维护问题,也减少了大文件复制的开销。
Windows上只能创建硬链接(快捷方式有点类似软链接,不过还是有不小的区别的),要求Win2000以上,而且只能在NTFS分区上用,也不能跨分区创建链接。但起码比没有好。
下面这个程序就是用来创建硬链接的。建立以后,修改一下其中一个文件,看一下另一个是不是也一起变了。^_^
用法:编译以后,比如生成nthl.exe。
nthl 目标链接 原始文件
如果发生错误,会输出错误信息。
源代码:
[code]/* nthl.cpp */
/**
* 创建硬链接
*
* @author XieZhenye
*
*/
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT<br/
Windows上只能创建硬链接(快捷方式有点类似软链接,不过还是有不小的区别的),要求Win2000以上,而且只能在NTFS分区上用,也不能跨分区创建链接。但起码比没有好。
下面这个程序就是用来创建硬链接的。建立以后,修改一下其中一个文件,看一下另一个是不是也一起变了。^_^
用法:编译以后,比如生成nthl.exe。
nthl 目标链接 原始文件
如果发生错误,会输出错误信息。
源代码:
[code]/* nthl.cpp */
/**
* 创建硬链接
*
* @author XieZhenye
*
*/
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT<br/
在Windows下写PHP的C扩展
[ 2010/06/23 13:55 | by selboo ]
查找目标失效,点击没反应的恢复方法
[ 2010/05/26 21:10 | by selboo ]
MSDN 正式公布简体中文版Windows 7
[ 2009/08/25 12:08 | by selboo ]
Windows 7 Ultimate (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_ultimate_x86_dvd_x15-65907.iso 邮寄日期 (UTC): 8/23/2009 10:16:24 PM SHA1: B589336602E3B7E134E222ED47FC94938B04354F ISO/CRC: E6FDF910 Windows 7 Ultimate (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_ultimate_x64_dvd_x15-66043.iso 邮寄日期 (UTC): 8/23/2009 10:16:25 PM SHA1: 4A98A2F1ED794425674D04A37B70B9763522B0D4 ISO/CRC: 05E9026C
Windows 7 Enterprise (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x86_dvd_x15-70737.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: 50F2900D293C8DF63A9D23125AFEEA7662FF9E54 ISO/CRC: CEEE9884
Windows 7 Enterprise (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x64_dvd_x15-70741.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: EE20DAF2CDEDD71C374E241340DEB651728A69C4 ISO/CRC: 18FF22E5
Windows 7 Professional (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_professional_x86_dvd_x15-65790.iso 邮寄日期 (UTC): 8/23/2009 10:16:03 PM SHA1: EBD595C3099CCF57C6FF53810F73339835CFBB9D ISO/CRC: 55F360AB
Windows 7 Professional (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_professional_x64_dvd_x15-65791.iso 邮寄日期 (UTC): 8/23/2009 10:16:03 PM SHA1: 5669A51195CD79D73CD18161D51E7E8D43DF53D1 ISO/CRC: 998E430C
Windows 7 Home Premium (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_home_premium_x86_dvd_x15-65717.iso 邮寄日期 (UTC): 8/23/2009 10:15:52 PM SHA1: CBA410DB30FA1561F874E1CC155E575F4A836B37 ISO/CRC: E4819CB1
Windows 7 Home Premium (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x86_dvd_x15-70737.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: 50F2900D293C8DF63A9D23125AFEEA7662FF9E54 ISO/CRC: CEEE9884
============ 下载分割线============
Windows 7 Ultimte (x86) - DVD (Chinese-Simplified)
下载地址:
Windows 7 Professional (x86) - DVD (Chinese-Simplified)
下载地址:
Windows 7 Enterprise (x86) - DVD (Chinese-Simplified)
下载地址:
文件名 cn_windows_7_ultimate_x86_dvd_x15-65907.iso 邮寄日期 (UTC): 8/23/2009 10:16:24 PM SHA1: B589336602E3B7E134E222ED47FC94938B04354F ISO/CRC: E6FDF910 Windows 7 Ultimate (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_ultimate_x64_dvd_x15-66043.iso 邮寄日期 (UTC): 8/23/2009 10:16:25 PM SHA1: 4A98A2F1ED794425674D04A37B70B9763522B0D4 ISO/CRC: 05E9026C
Windows 7 Enterprise (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x86_dvd_x15-70737.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: 50F2900D293C8DF63A9D23125AFEEA7662FF9E54 ISO/CRC: CEEE9884
Windows 7 Enterprise (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x64_dvd_x15-70741.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: EE20DAF2CDEDD71C374E241340DEB651728A69C4 ISO/CRC: 18FF22E5
Windows 7 Professional (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_professional_x86_dvd_x15-65790.iso 邮寄日期 (UTC): 8/23/2009 10:16:03 PM SHA1: EBD595C3099CCF57C6FF53810F73339835CFBB9D ISO/CRC: 55F360AB
Windows 7 Professional (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_professional_x64_dvd_x15-65791.iso 邮寄日期 (UTC): 8/23/2009 10:16:03 PM SHA1: 5669A51195CD79D73CD18161D51E7E8D43DF53D1 ISO/CRC: 998E430C
Windows 7 Home Premium (x86) - DVD (Chinese-Simplified)
文件名 cn_windows_7_home_premium_x86_dvd_x15-65717.iso 邮寄日期 (UTC): 8/23/2009 10:15:52 PM SHA1: CBA410DB30FA1561F874E1CC155E575F4A836B37 ISO/CRC: E4819CB1
Windows 7 Home Premium (x64) - DVD (Chinese-Simplified)
文件名 cn_windows_7_enterprise_x86_dvd_x15-70737.iso 邮寄日期 (UTC): 8/23/2009 10:15:32 PM SHA1: 50F2900D293C8DF63A9D23125AFEEA7662FF9E54 ISO/CRC: CEEE9884
============ 下载分割线============
Windows 7 Ultimte (x86) - DVD (Chinese-Simplified)
下载地址:
下载文件 (已下载 187 次)
Windows 7 Professional (x86) - DVD (Chinese-Simplified)
下载地址:
下载文件 (已下载 187 次)
Windows 7 Enterprise (x86) - DVD (Chinese-Simplified)
下载地址:
下载文件 (已下载 170 次)
深度分析“Windows 半开连接数限制“
[ 2009/07/09 16:29 | by selboo ]
在讨论“半开连接”之前,我觉得最重要的一点是,必须弄清楚什么是“半开连接”。
很遗憾,在这个文章里面回复的绝大部分人,可能包括我没有看到这个之前在内,都不知道什么是“半开连接”,更加不知道微软为什么要进行限制。
所以就有诸如“2003是服务器,如果限制了基本网站就不要用了”之类可笑的观点了。
我们先来普及一下基本常识吧,下面的文字可能有点晦涩:
建立TCP连接的标准过程是这样的:
首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;
第二步,服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一,ACK即确认(Acknowledgement)。
第三步,客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加一,到此一个TCP连接完成。
以上的连接过程在TCP协议中被称为三次握手(Three-way Handshake)。
问题就出在TCP连接的三次握手中,
假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),
这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接。
这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,
但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。
实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)。
此时从正常客户的角度看来,服务器失去响应,
这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。
上面的文字可能很多人看不懂,那我们用比较简单的例子来解释:
1.第一次握手-----------电脑:服务器,你有陈冠希的照片吗?
2.第二次握手-----------服务器:有,你是不是想要?
3.第三次握手-----------电脑:当然想,你传给我。
4.正式建立连接,双方开始传输照片。
在上面的例子中,如果电脑没有回答服务器的问题,就是第三次握手还没有完成,这样的连接就叫做“半开连接”。
微软为了防止SYN洪水攻击,在XP SP2中,限制了最大并发半开连接数为10。
也就是说,使用XP SP2的电脑,最多可以同时向十台服务器询问:“服务器,你有陈冠希的照片吗”。
如果电脑不回答服务器的发问:“有,你是不是想要?”的话,
它就不能向第十一台服务器询问了。
它必须先对前面十台服务器中的随便某一台回答“当然想,你传给我”,完成一次连接之后,才能向第十一台服务器进行询问。
说到这里,大家应该明白了吧?
微软所谓的半开连接数限制,只是针对发起方(也就是上面例子中的电脑)的,不是针对接受方(也就是上面例子中的服务器)!
一台使用XP SP2的电脑,如果它是半开连接的发起方,它就会受到这个限制。
如果它是半开连接的接受方,那么,它是不会受到这个半开连接数的限制的!
以上只是针对XP SP2的分析,如果是使用2003或者2008的电脑呢?
也是同样的道理,如果2003或者2008是接受方,比如我们常见的WEB服务器或者FTP服务器,那它们也不会受到半开连接数的限制!
哪怕它们的最大并发半开连接数同样是10,也不会对它们的HTTP服务,或者FTP服务,有任何影响!
那么,该回到主题了,到底2003有没有限制最大并发半开连接数呢?
楼主的分析已经很清楚了:
以英文企业版Windows 2003 SP2的tcpip.sys为例,TCPMaxHalfOpen是5000。
这很好的说明了,
微软对英文企业版2003 SP2的最大并发半开连接数的限制为5000!
我们再想一想,现在互联网上有很多使用2003来架构的网站或者论坛,
它们的最大同时访问量往往是用数万为单位来计算的,
但是用户访问网站或者登陆论坛却没有感受到什么影响,除非是服务器受到SYN洪水攻击。
这不正好说明了,微软所谓的半开连接数限制,只是针对发起方的吗?
所以我们可以得出一个结论:
2003或者2008,同样有半开连接数的限制,
只不过,只有当它们作为连接的发起方,比如BT下载的客户端,P2P网络电视的使用者时,才会受到这个限制;
在它们作为连接的接受方,比如WEB服务器,或者FTP服务器时,是不会受到限制的。
最后再解释一下注册表中的TCPMaxHalfOpen相关项目的设置和用途:
首先,SynAttackProtect的键值,类型为REG_DWORD,取值范围是0,1。从WIN2003 SP1开始默认值是1。
这个值决定了系统受到SYN攻击时采取的保护措施,包括减少系统SYN+ACK的重试的次数等。
其次,TcpMaxHalfOpen的键值,类型为REG_DWORD,取值范围是100-0xFFFF,这个值是系统允许同时打开的半连接。
默认情况下WIN2K PRO和SERVER是100,ADVANCED SERVER是500,WIN2003是5000。
然后,TcpMaxHalfOpenRetried的键值,类型为REG_DWORD,取值范围是80-0xFFFF,这个值决定了在什么情况下系统会打开SYN攻击保护。
默认情况下WIN2K PRO和SERVER是80,ADVANCED SERVER是400,WIN2003是2500。
Win2003的SYN攻击保护机制是这样的:
正常情况下,WIN2003对TCP连接的三次握手有一个常规的设置,
包括SYN Timeout时间、SYN-ACK的重试次数和SYN报文从路由器到系统再到Winsock的延时等。
这个常规设置是针对系统性能进行优化的(安全和性能往往相互矛盾),所以可以给用户提供方便快捷的服务。
一旦服务器受到攻击,SYN半连接的数量超过TcpMaxHalfOpenRetried的设置,系统会认为自己受到了SYN Flood攻击。
此时,设置在SynAttackProtect键值中的选项开始作用,SYN Timeout时间被减短,SYN-ACK的重试次数减少,
系统也会自动对缓冲区中的报文进行延时,避免对TCP/IP堆栈造成过大的冲击,力图将攻击危害减到最低。
如果攻击强度不断增大,超过了TcpMaxHalfOpen值,此时系统已经不能提供正常的服务了,更重要的是保证系统不会崩溃,
系统将会丢弃任何超出TcpMaxHalfOpen值范围的SYN报文(应该是使用随机丢包策略),保证系统的稳定性。
所以,把TcpMaxHalfOpen值改小,只是为了加强系统对SYN洪水攻击的防御能力;
改大,再大也超不过TCPIP.SYS的限制。
这是微软对于“半开连接”接受方所采取的一种保护措施,
和对“半开连接”发起方所采取的最大并发连接数限制,
是相辅相成的。
很遗憾,在这个文章里面回复的绝大部分人,可能包括我没有看到这个之前在内,都不知道什么是“半开连接”,更加不知道微软为什么要进行限制。
所以就有诸如“2003是服务器,如果限制了基本网站就不要用了”之类可笑的观点了。
我们先来普及一下基本常识吧,下面的文字可能有点晦涩:
建立TCP连接的标准过程是这样的:
首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;
第二步,服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一,ACK即确认(Acknowledgement)。
第三步,客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加一,到此一个TCP连接完成。
以上的连接过程在TCP协议中被称为三次握手(Three-way Handshake)。
问题就出在TCP连接的三次握手中,
假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),
这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接。
这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,
但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。
实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小)。
此时从正常客户的角度看来,服务器失去响应,
这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。
上面的文字可能很多人看不懂,那我们用比较简单的例子来解释:
1.第一次握手-----------电脑:服务器,你有陈冠希的照片吗?
2.第二次握手-----------服务器:有,你是不是想要?
3.第三次握手-----------电脑:当然想,你传给我。
4.正式建立连接,双方开始传输照片。
在上面的例子中,如果电脑没有回答服务器的问题,就是第三次握手还没有完成,这样的连接就叫做“半开连接”。
微软为了防止SYN洪水攻击,在XP SP2中,限制了最大并发半开连接数为10。
也就是说,使用XP SP2的电脑,最多可以同时向十台服务器询问:“服务器,你有陈冠希的照片吗”。
如果电脑不回答服务器的发问:“有,你是不是想要?”的话,
它就不能向第十一台服务器询问了。
它必须先对前面十台服务器中的随便某一台回答“当然想,你传给我”,完成一次连接之后,才能向第十一台服务器进行询问。
说到这里,大家应该明白了吧?
微软所谓的半开连接数限制,只是针对发起方(也就是上面例子中的电脑)的,不是针对接受方(也就是上面例子中的服务器)!
一台使用XP SP2的电脑,如果它是半开连接的发起方,它就会受到这个限制。
如果它是半开连接的接受方,那么,它是不会受到这个半开连接数的限制的!
以上只是针对XP SP2的分析,如果是使用2003或者2008的电脑呢?
也是同样的道理,如果2003或者2008是接受方,比如我们常见的WEB服务器或者FTP服务器,那它们也不会受到半开连接数的限制!
哪怕它们的最大并发半开连接数同样是10,也不会对它们的HTTP服务,或者FTP服务,有任何影响!
那么,该回到主题了,到底2003有没有限制最大并发半开连接数呢?
楼主的分析已经很清楚了:
以英文企业版Windows 2003 SP2的tcpip.sys为例,TCPMaxHalfOpen是5000。
这很好的说明了,
微软对英文企业版2003 SP2的最大并发半开连接数的限制为5000!
我们再想一想,现在互联网上有很多使用2003来架构的网站或者论坛,
它们的最大同时访问量往往是用数万为单位来计算的,
但是用户访问网站或者登陆论坛却没有感受到什么影响,除非是服务器受到SYN洪水攻击。
这不正好说明了,微软所谓的半开连接数限制,只是针对发起方的吗?
所以我们可以得出一个结论:
2003或者2008,同样有半开连接数的限制,
只不过,只有当它们作为连接的发起方,比如BT下载的客户端,P2P网络电视的使用者时,才会受到这个限制;
在它们作为连接的接受方,比如WEB服务器,或者FTP服务器时,是不会受到限制的。
最后再解释一下注册表中的TCPMaxHalfOpen相关项目的设置和用途:
首先,SynAttackProtect的键值,类型为REG_DWORD,取值范围是0,1。从WIN2003 SP1开始默认值是1。
这个值决定了系统受到SYN攻击时采取的保护措施,包括减少系统SYN+ACK的重试的次数等。
其次,TcpMaxHalfOpen的键值,类型为REG_DWORD,取值范围是100-0xFFFF,这个值是系统允许同时打开的半连接。
默认情况下WIN2K PRO和SERVER是100,ADVANCED SERVER是500,WIN2003是5000。
然后,TcpMaxHalfOpenRetried的键值,类型为REG_DWORD,取值范围是80-0xFFFF,这个值决定了在什么情况下系统会打开SYN攻击保护。
默认情况下WIN2K PRO和SERVER是80,ADVANCED SERVER是400,WIN2003是2500。
Win2003的SYN攻击保护机制是这样的:
正常情况下,WIN2003对TCP连接的三次握手有一个常规的设置,
包括SYN Timeout时间、SYN-ACK的重试次数和SYN报文从路由器到系统再到Winsock的延时等。
这个常规设置是针对系统性能进行优化的(安全和性能往往相互矛盾),所以可以给用户提供方便快捷的服务。
一旦服务器受到攻击,SYN半连接的数量超过TcpMaxHalfOpenRetried的设置,系统会认为自己受到了SYN Flood攻击。
此时,设置在SynAttackProtect键值中的选项开始作用,SYN Timeout时间被减短,SYN-ACK的重试次数减少,
系统也会自动对缓冲区中的报文进行延时,避免对TCP/IP堆栈造成过大的冲击,力图将攻击危害减到最低。
如果攻击强度不断增大,超过了TcpMaxHalfOpen值,此时系统已经不能提供正常的服务了,更重要的是保证系统不会崩溃,
系统将会丢弃任何超出TcpMaxHalfOpen值范围的SYN报文(应该是使用随机丢包策略),保证系统的稳定性。
所以,把TcpMaxHalfOpen值改小,只是为了加强系统对SYN洪水攻击的防御能力;
改大,再大也超不过TCPIP.SYS的限制。
这是微软对于“半开连接”接受方所采取的一种保护措施,
和对“半开连接”发起方所采取的最大并发连接数限制,
是相辅相成的。