设为首页收藏本站关注微信<<< 抵制 IE6 人人有责 >>>
搜索
热搜: 活动 交友 discuz
查看: 2159|回复: 1
打印 上一主题 下一主题

[windows] TCP的三次握手(建立连接)和四次挥手(关闭连接)

[复制链接]
跳转到指定楼层
楼主
发表于 2015-8-27 22:56:37 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
参照:
http://course.ccniit.com/CSTD/Linux/reference/files/018.PDF
http://hi.baidu.com/raycomer/item/944d23d9b502d13be3108f61

建立连接:
理解:窗口和滑动窗口
TCP的流量控制
TCP使用窗口机制进行流量控制
什么是窗口?
连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端
接收方发送的确认信息中包含了自己剩余的缓冲区尺寸
剩余缓冲区空间的数量叫做窗口
2. TCP的流控过程(滑动窗口)

TCP(Transmission Control Protocol) 传输控制协议
三次握手
TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
客户端TCP状态迁移:
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务器TCP状态迁移:
CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED


各个状态的意义如下:
LISTEN - 侦听来自远方TCP端口的连接请求;
SYN-SENT -在发送连接请求后等待匹配的连接请求;
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;
ESTABLISHED- 代表一个打开的连接,数据可以传送给用户;
FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
FIN-WAIT-2 - 从远程TCP等待连接中断请求;
CLOSE-WAIT - 等待从本地用户发来的连接中断请求;
CLOSING -等待远程TCP对连接中断的确认;
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认;
CLOSED - 没有任何连接状态;

TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接,如图1所示。
(1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认。
(2)第二次握手:服务器B收到SYN包,必须确认客户A的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态。
(3)第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK(ACK=k+1),此包发送完毕,客户端A和服务器B进入ESTABLISHED状态,完成三次握手。
完成三次握手,客户端与服务器开始传送数据。
确认号:其数值等于发送方的发送序号 +1(即接收方期望接收的下一个序列号)。

图1 TCP三次握手建立连接  
TCP的包头结构:
源端口 16位
目标端口 16位
序列号 32位
回应序号 32位
TCP头长度 4位
reserved 6位
控制代码 6位
窗口大小 16位
偏移量 16位
校验和 16位
选项  32位(可选)
这样我们得出了TCP包头的最小长度,为20字节
  • 第一次握手:
    客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口,以及初始序号X,保存在包头的序列号(Sequence Number)字段里。
  • 第二次握手:
    服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时,将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。

  • 第三次握手.
    客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1
下面是具体的例子截图
1.此图包含两部分信息:TCP的三次握手(方框中的内容) (SYN, (SYN+ACK), ACK)
2. TCP的数据传输 ([TCP segment of a reassembled PUD])可以看出,server是将数据TCP层对消息包进行分片传输
(1)Server端收到HTTP请求如GET之后,构造响应消息,其中携带网页内容,在server端的HTTP层发送消息200 OK->server端的TCP层;
(2)server端的TCP层对消息包进行分片传输;
(3)client端的TCP层对接收到的各个消息包分片回送响应;
(4)client端的TCP层每次收到一部分都会用ACK确认,之后server继续传输,client继续确认,直到完成响应消息的所有分片之后,Server发送组合HTTP响应包 200 OK,此时在client端的消息跟踪中才可以显示HTTP 200 OK的消息包
关闭连接:

由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
CP的连接的拆除需要发送四个包,因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作,在socket编程中,任何一方执行close()操作即可产生挥手操作。
(1)客户端A发送一个FIN,用来关闭客户A到服务器B的数据传送。
(2)服务器B收到这个FIN,它发回一个ACK,确认序号为收到的序号加1。和SYN一样,一个FIN将占用一个序号。
(3)服务器B关闭与客户端A的连接,发送一个FIN给客户端A。
(4)客户端A发回ACK报文确认,并将确认序号设置为收到序号加1。
TCP采用四次挥手关闭连接如图2所示。
图2  TCP四次挥手关闭连接

参见wireshark抓包,实测的抓包结果并没有严格按挥手时序。我估计是时间间隔太短造成。

深入理解TCP连接的释放:

由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。
TCP协议的连接是全双工连接,一个TCP连接存在双向的读写通道。
简单说来是 “先关读,后关写”,一共需要四个阶段。以客户机发起关闭连接为例:
1.服务器读通道关闭
2.客户机写通道关闭
3.客户机读通道关闭
4.服务器写通道关闭
关闭行为是在发起方数据发送完毕之后,给对方发出一个FIN(finish)数据段。直到接收到对方发送的FIN,且对方收到了接收确认ACK之后,双方的数据通信完全结束,过程中每次接收都需要返回确认数据段ACK。
详细过程:
    第一阶段   客户机发送完数据之后,向服务器发送一个FIN数据段,序列号为i
    1.服务器收到FIN(i)后,返回确认段ACK,序列号为i+1关闭服务器读通道
    2.客户机收到ACK(i+1)后,关闭客户机写通道
   (此时,客户机仍能通过读通道读取服务器的数据,服务器仍能通过写通道写数据)
    第二阶段 服务器发送完数据之后,向客户机发送一个FIN数据段,序列号为j;
    3.客户机收到FIN(j)后,返回确认段ACK,序列号为j+1关闭客户机读通道
    4.服务器收到ACK(j+1)后,关闭服务器写通道
这是标准的TCP关闭两个阶段,服务器和客户机都可以发起关闭,完全对称。
FIN标识是通过发送最后一块数据时设置的,标准的例子中,服务器还在发送数据,所以要等到发送完的时候,设置FIN(此时可称为TCP连接处于半关闭状态,因为数据仍可从被动关闭一方向主动关闭方传送)。如果在服务器收到FIN(i)时,已经没有数据需要发送,可以在返回ACK(i+1)的时候就设置FIN(j)标识,这样就相当于可以合并第二步和第三步。
读《Linux网络编程》关闭TCP连接章节,作以下笔记:
TCP的TIME_WAIT和Close_Wait状态
面试时看到应聘者简历中写精通网络,TCP编程,我常问一个问题,TCP建立连接需要几次握手?95%以上的应聘者都能答对是3次。问TCP断开连接需要几次握手,70%的应聘者能答对是4次通讯。再问CLOSE_WAIT,TIME_WAIT是什么状态,怎么产生的,对服务有什么影响,如何消除?有一部分同学就回答不上来。不是我扣细节,而是在通讯为主的前端服务器上,必须有能力处理各种TCP状态。比如统计在本厂的一台前端机上高峰时间TCP连接的情况,统计命令:


  • netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  



结果:

除了ESTABLISHED,可以看到连接数比较多的几个状态是:FIN_WAIT1, TIME_WAIT, CLOSE_WAIT, SYN_RECV和LAST_ACK;下面的文章就这几个状态的产生条件、对系统的影响以及处理方式进行简单描述。

TCP状态
TCP状态如下图所示:
可能有点眼花缭乱?再看看这个时序图


下面看下大家一般比较关心的三种TCP状态
SYN_RECV
服务端收到建立连接的SYN没有收到ACK包的时候处在SYN_RECV状态。有两个相关系统配置:

1,net.ipv4.tcp_synack_retries :INTEGER
默认值是5
对于远端的连接请求SYN,内核会发送SYN + ACK数据报,以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN+ACK 数目。不应该大于255,默认值是5,对应于180秒左右时间。通常我们不对这个值进行修改,因为我们希望TCP连接不要因为偶尔的丢包而无法建立。
2,net.ipv4.tcp_syncookies
一般服务器都会设置net.ipv4.tcp_syncookies=1来防止SYN Flood攻击。假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。

这些处在SYNC_RECV的TCP连接称为半连接,并存储在内核的半连接队列中,在内核收到对端发送的ack包时会查找半连接队列,并将符合的requst_sock信息存储到完成三次握手的连接的队列中,然后删除此半连接。大量SYNC_RECV的TCP连接会导致半连接队列溢出,这样后续的连接建立请求会被内核直接丢弃,这就是SYN Flood攻击。

能够有效防范SYN Flood攻击的手段之一,就是SYN Cookie。SYN Cookie原理由D. J. Bernstain和 Eric Schenk发明。SYN Cookie是对TCP服务器端的三次握手协议作一些修改,专门用来防范SYN Flood攻击的一种手段。它的原理是,在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时,不分配一个专门的数据区,而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时,TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法,再分配专门的数据区进行处理未来的TCP连接。

观测服务上SYN_RECV连接个数为:7314,对于一个高并发连接的通讯服务器,这个数字比较正常。
CLOSE_WAIT
发起TCP连接关闭的一方称为client,被动关闭的一方称为server。被动关闭的server收到FIN后,但未发出ACK的TCP状态是CLOSE_WAIT。出现这种状况一般都是由于server端代码的问题,如果你的服务器上出现大量CLOSE_WAIT,应该要考虑检查代码。
TIME_WAIT
根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务。

为什么需要TIME_WAIT?TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。

和TIME_WAIT状态有关的系统参数有一般由3个,本厂设置如下:
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_fin_timeout,默认60s,减小fin_timeout,减少TIME_WAIT连接数量。

net.ipv4.tcp_tw_reuse = 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
net.ipv4.tcp_tw_recycle = 1表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。


为了方便描述,我给这个TCP连接的一端起名为Client,给另外一端起名为Server。上图描述的是Client主动关闭的过程,FTP协议中就这样的。如果要描述Server主动关闭的过程,只要交换描述过程中的Server和Client就可以了,HTTP协议就是这样的。
描述过程:
Client调用close()函数,给Server发送FIN,请求关闭连接;Server收到FIN之后给Client返回确认ACK,同时关闭读通道(不清楚就去看一下shutdown和close的差别),也就是说现在不能再从这个连接上读取东西,现在read返回0。此时Server的TCP状态转化为CLOSE_WAIT状态。
Client收到对自己的FIN确认后,关闭 写通道,不再向连接中写入任何数据。
接下来Server调用close()来关闭连接,给Client发送FIN,Client收到后给Server回复ACK确认,同时Client关闭读通道,进入TIME_WAIT状态。
Server接收到Client对自己的FIN的确认ACK,关闭写通道,TCP连接转化为CLOSED,也就是关闭连接。
Client在TIME_WAIT状态下要等待最大数据段生存期的两倍,然后才进入CLOSED状态,TCP协议关闭连接过程彻底结束。
以上就是TCP协议关闭连接的过程,现在说一下TIME_WAIT状态。
从上面可以看到,主动发起关闭连接的操作的一方将达到TIME_WAIT状态,而且这个状态要保持Maximum Segment Lifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态?
原因有二:
一、保证TCP协议的全双工连接能够可靠关闭
二、保证这次连接的重复数据段从网络中消失
先说第一点,如果Client直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN,此时由于Client已经CLOSED了,就找不到与重发的FIN对应的连接,最后Server就会收到RST而不是ACK,Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失,但是却导致TCP协议不符合可靠连接的要求。所以,Client不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。
再说第二点,如果Client直接CLOSED,然后又再向Server发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达Server,由于新连接和老连接的端口号是一样的,又因为TCP协议判断不同连接的依据是socket pair,于是,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。
各种协议都是前人千锤百炼后得到的标准,规范。从细节中都能感受到精巧和严谨。每次深入都有同一个感觉,精妙。

做个快乐的自己。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?免费注册

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享淘帖
回复

使用道具 举报

沙发
 楼主| 发表于 2015-8-27 22:58:17 | 只看该作者
   在讨论“半开连接”之前,我觉得最重要的一点是,必须弄清楚什么是“半开连接”。
很遗憾,在这个帖子里面回复的绝大部分人,可能包括楼主在内,都不知道什么是“半开连接”,更加不知道微软为什么要进行限制。
所以就有诸如“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的限制。
这是微软对于“半开连接”接受方所采取的一种保护措施,
和对“半开连接”发起方所采取的最大并发连接数限制,
是相辅相成的。
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 免费注册

本版积分规则

QQ|手机版|Archiver|源于生活(个人生活娱乐工作的笔记)css3,html5,学习笔记    

GMT+8, 2024-11-1 07:55 , Processed in 0.156001 second(s), 28 queries .

Powered by Mr.Kevin-ying

© 2004-2015

快速回复 返回顶部 返回列表