首先了解下TCP报文
16位源端口号：16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。
16位目的端口号：16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。
32位序号：32位的序列号由接收端计算机使用，重新分段的报文成最初形式。当SYN出现，序列码实际上是初始序列码（Initial Sequence Number，ISN），而第一个数据字节是ISN+1。这个序列号（序列码）可用来补>偿传输中的不一致。
32位确认序号：32位的序列号由接收端计算机使用，重组分段的报文成最初形式。如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。
4位首部长度：4位包括TCP头大小，指示何处数据开始。
保留（6位）：6位值域，这些位必须是0。为了将来定义新的用途而保留。
标志：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。
16位窗口大小：用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小>是一个16字节字段，因而窗口大小最大为65535字节。
16位校验和：16位TCP头。源机器基于数据内容计算一个数值，收信息机要与源机器数值 结果完全一样，从而证明数据的有效性。检验和覆盖了整个的TCP报文段：这是一个强制性的字段，一定是由发送端计算和存储，
并由接收端进行验证的。
16位紧急指针：指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。
选项：长度不定，但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。
数据：该TCP协议包负载的数据。
在上述字段中，6位标志域的各个选项功能如下。
URG：urgent紧急标志。紧急标志为"1"表明该位有效。
ACK：acknowledge确认标志。表明确认编号栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号（w+1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
PSH：push推标志。该标志置位时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。在处理Telnet或rlogin等交互模式的连接时，该标志总是置位的。
RST：restart复位标志。用于复位相应的TCP连接。
SYN：同步标志。表明同步序列编号栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端（一般是客户端）的初始序列编号。在这里，可以把TCP序列编
号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
FIN：结束标志。TCP三次握手:
第一次握手:1,client将数据包标志位SYN置为1,随即产生一个值seq=J
2,client发送数据包(SYN=1,seq=J),进入SYN_SENT状态
第二次握手:1,server收到包,发现SYN=1,知道是请求连接.
2,server将数据包标志位SYN=1,ACK=1,ack=J+1,随机产生seq=K
3,server发送数据包(SYN=1,ACK=1,ack=J+1,seq=K),进入SYN_RCVD状态
第三次握手:1,client收到包,发现ACK=1,ack=J+1.
2,client将数据包标志位ACK=1,ack=K+1,
3,client发送数据包(ACK=1,ack=K+1,seq=J+1),进入ESTABLISHED状态
4,server收到包,发现ACK=1,ack=K+1,也进入ESTABLISHED状态.完成握手,建立了连接
在server处于SYN_RECV状态即是半连接状态.SYN攻击是典型的ddos攻击,client伪造大量ip让server处于SYN_RECV状态.在超时之前,这些SYN包占满了队列,从而导致正常的SYN被丢弃.而server在client未回复ACK时,会认为发送的SYN/ACK包丢失,从而不断重复发送,直至超时.
查看是否遭到攻击,可以通过natstat -nap|grep SYN_RECV 进行查看. -n numeric显示ip而不是域名 -a显示所有连接中的 socket. -p显示所有使用socket的programs -t显示tcp.
TCP四次挥手:
第一次挥手:1,client发送一个FIN包(seq=M,FIN=1),并进入FIN_WAIT_1状态
第二次挥手:1,server收到FIN包,立刻发送ACK包(seq=v,ack=M+1,ACK=1),并进入CLOSE_WAIT状态.
2,client收到ACK包,进入FIN_WAIT_2状态,此时是半连接状态.
第三次挥手:1,server将需要发送的数据包发送完毕.
2,server发送FIN包(seq=N,ack=M+1,FIN=1,ACK=1),进入LAST_ACK状态
3,client收到FIN后,进入TIME_WAIT状态
第四次挥手: 1,client立刻发送ACK包(seq=M+1,ack=N+1,ACK=1).
2,server收到ACK包,进入CLOSED状态.完成挥手.
在client处与TIME_WAIT状态后,需要等待2MSL.为什么呢?第一,确保TCP连接正常关闭.第二,确保网络中的延迟数据从网络中消失.
1,如果client不等待2MSL,由于ip协议不可靠,ACK包可能丢掉,导致server收不到ACK包,第四次挥手不成功.于是server在超时后,以为第三次挥手对方没收到FIN,便重复发送.
a,server此时找不到FIN对应的client连接了,底层可能就会发送一个RST,server收到后,就会报连接错误.虽然不会有数据丢失,但这明显不符合TCP可靠性连接的要求.
b,特殊情况:此时有个新client使用了同样的端口,此时FIN仍在网络中传输,由于tcp判断连接依据的是socketpair,于是网络就会认为FIN包是新连接的.从而造成数据包混淆.
TCP连接探测中的keepalive和心跳包:
如果客户端非正常断开,服务器没设置SO_KEEPALIVE选项,则socket将不关闭.
如果设置了SO_KEEPALIVE:
/* Argument structure for SIO_KEEPALIVE_VALS */
struct tcp_keepalive {
u_long onoff;
u_long keepalivetime;
u_long keepaliveinterval;
};
对于一个已经建立的tcp连接。如果在keepalivetime时间内双方没有任何的数据包传输，则开启keepalive功能的一端将发送 keepalive数据包，若没有收到应答，则每隔keepaliveinterval时间再发送该数据包，发送keepalive_probes次。一直没有收到应答，则发送rst包关闭连接。若收到应答，则将计时器清零。默认值:
The default settings when a TCP socket is initialized sets the keep-alive timeout to 2 hours and the keep-alive interval to 1 second. The number of keep-alive probes cannot be changed and is set to 10.
即2hour内无数据交互,则发送探测报文.
如何及时有效地检测到一方的非正常断开，一直有两种技术可以运用。一种是由TCP协议层实现的Keepalive，另一种是由应用层自己实现的心跳包。
TCP默认并不开启Keepalive功能，因为开启Keepalive功能需要消耗额外的带宽和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。并且，默认的Keepalive超时需要7,200,000 milliseconds，即2小时，探测次数为5次。
对于实用的程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。
// 开启KeepAlive
BOOL bKeepAlive = TRUE;
int nRet = ::setsockopt(socket_handle, SOL_SOCKET, SO_KEEPALIVE, (char*)&bKeepAlive, sizeof(bKeepAlive));
if (nRet == SOCKET_ERROR)
{
return FALSE;
}
// 设置KeepAlive参数
tcp_keepalive alive_in = {0};
tcp_keepalive alive_out = {0};
alive_in.keepalivetime = 5000; // 开始首次KeepAlive探测前的TCP空闭时间
alive_in.keepaliveinterval = 1000; // 两次KeepAlive探测间的时间间隔
alive_in.onoff = TRUE;
unsigned long ulBytesReturn = 0;
nRet = WSAIoctl(socket_handle, SIO_KEEPALIVE_VALS, &alive_in, sizeof(alive_in),
&alive_out, sizeof(alive_out), &ulBytesReturn, NULL, NULL);
if (nRet == SOCKET_ERROR)
{
return FALSE;
}
开启Keepalive选项之后，对于使用IOCP模型的服务器端程序来说，一旦检测到连接断开，GetQueuedCompletionStatus函数将立即返回FALSE，使得服务器端能及时清除该连接、释放该连接相关的资源。对于使用select模型的客户端来说，连接断开被探测到时，以recv目的阻塞在socket上的select方法将立即返回SOCKET_ERROR，从而得知连接已失效，客户端程序便有机会及时执行清除工作、提醒用户或重新连接。
另一种技术，由应用程序自己发送心跳包来检测连接的健康性。客户端可以在一个Timer中或低级别的线程中定时向发服务器发送一个短小精悍的包，并等待服务器的回应。客户端程序在一定时间内没有收到服务器回应即认为连接不可用，同样，服务器在一定时间内没有收到客户端的心跳包则认为客户端已经掉线。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
windows下此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因.
有两种方法可以检测:
1.TCP连接双方定时发握手消息
2.利用TCP协议栈中的KeepAlive探测 第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测, 所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试) Windows 2000平台下 头文件
- #include <MSTcpIP.h>
- //开启keepalive功能，并修改默认的keepalive
- //用于心跳包检测
- //开启keepalive
- BOOL bKeepAlive=TRUE;
- ret=setsockopt(listenSocket,SOL_SOCKET,SO_KEEPALIVE,(char*)&bKeepAlive,sizeof(bKeepAlive));
- if(ret ==SOCKET_ERROR)
- {
- cerr<<"开启keepalive功能失败！"<<endl;
- cerr<<"error code:"<<WSAGetLastError()<<endl;
- closesocket(listenSocket);
- WSACleanup();
- exit(1);
- }
- //修改keepalive参数
- tcp_keepalive aliveIn;
- aliveIn.onoff=1;
- aliveIn.keepalivetime=900 * 1000; // TCP连接多长时间(毫秒)没有数据就开始发送心跳包，有数据传递的时候不发送心跳包。//系统默认2小时，我设置15分钟，不宜设置过小
- aliveIn.keepaliveinterval=1000; //当keepalivetime时间到达后，每隔多长时间(毫秒)发送一个心跳包，发5次(系统默认值)
- tcp_keepalive aliveOut;
- DWORD uiBytesReturn=0;
- ret=WSAIoctl(listenSocket,SIO_KEEPALIVE_VALS,&aliveIn,sizeof(aliveIn),&aliveOut,sizeof(aliveOut),&uiBytesReturn,NULL,NULL);
- if(ret ==SOCKET_ERROR)
- {
- cerr<<"修改keepalive参数失败！"<<endl;
- cerr<<"error code:"<<WSAGetLastError()<<endl;
- closesocket(listenSocket);
- WSACleanup();
- exit(1);
- }
ps:收到RST包:1,port未打开.2,请求超时.3,提前关闭.4,在一个已经关闭的socket上收到数据.