Socket之so_linger与rst

摘要：滑动窗口滑动窗口毫无疑问是用来加速数据传输的。处理程序会在自己认为的异常时刻发送包。序列号问题是与滑动窗口对应的，伪造的包里需要填序列号，如果序列号的值不在之前向发送时的滑动窗口内，是会主动丢弃的。

看Apache HttpClient的源码时，发现abortRequest的时候，调用到socket时代码如下:

public void shutdown() throws IOException {
        Socket socket = (Socket)this.socketHolder.getAndSet((Object)null);
        if (socket != null) {
            try {
                socket.setSoLinger(true, 0);
            } catch (IOException var6) {
                ;
            } finally {
                socket.close();
            }
        }

    }

what is so_linger?这个嘛得先从tcp三次握手与四次挥手说起:

三次握手建立连接：

为了能够说清楚后面的RST攻击，需要结合上图说说：SYN标志位、序号、滑动窗口大小。
建立连接的请求中，标志位SYN都要置为1，在这种请求中会告知MSS段大小，就是本机希望接收TCP包的最大大小。
发送的数据TCP包都有一个序号。它是这么得来的：最初发送SYN时，有一个初始序号，根据RFC的定义，各个操作系统的实现都是与系统时间相关的。之后，序号的值会不断的增加，比如原来的序号是100，如果这个TCP包的数据有10个字节，那么下次的TCP包序号会变成110。
滑动窗口用于加速传输，比如发了一个seq=100的包，理应收到这个包的确认ack=101后再继续发下一个包，但有了滑动窗口，只要新包的seq与没有得到确认的最小seq之差小于滑动窗口大小，就可以继续发。

滑动窗口
滑动窗口毫无疑问是用来加速数据传输的。TCP要保证“可靠”，就需要对一个数据包进行ack确认表示接收端收到。有了滑动窗口，接收端就可以等收到许多包后只发一个ack包，确认之前已经收到过的多个数据包。有了滑动窗口，发送端在发送完一个数据包后不用等待它的ack，在滑动窗口大小内可以继续发送其他数据包。
如果谈到TCP攻击就需要注意，TCP的各种实现中，在滑动窗口之外的seq会被扔掉！

四次握手的正常TCP连接关闭

FIN标志位也看到了，它用来表示正常关闭连接。图的左边是主动关闭连接方，右边是被动关闭连接方，用netstat命令可以看到标出的连接状态。
FIN是正常关闭，它会根据缓冲区的顺序来发的，就是说缓冲区FIN之前的包都发出去后再发FIN包，这与RST不同。

RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。就像上面说的一样，发送RST包关闭连接时，不必等缓冲区的包都发出去（不像上面的FIN包），直接就丢弃缓存区的包发送RST包。而接收端收到RST包后，也不必发送ACK包来确认。
TCP处理程序会在自己认为的异常时刻发送RST包。例如，A向B发起连接，但B之上并未监听相应的端口，这时B操作系统上的TCP处理程序会发RST包。
又比如，AB正常建立连接了，正在通讯时，A向B发送了FIN包要求关连接，B发送ACK后，网断了，A通过若干原因放弃了这个连接（例如进程重启）。网通了后，B又开始发数据包，A收到后表示压力很大，不知道这野连接哪来的，就发了个RST包强制把连接关了，B收到后会出现connect reset by peer错误。

说了这么多好像还没说so_linger.

Linux网络编程中,socket的选项很多.其中几个比较重要的选项有:SO_LINGER(仅仅适用于TCP,SCTP), SO_REUSEADDR.

在默认情况下,当调用close关闭socke的使用,close会立即返回,但是,如果send buffer中还有数据,系统会试着先把send buffer中的数据发送出去,然后close才返回.

SO_LINGER选项则是用来修改这种默认操作的.于SO_LINGER相关联的一个结构体如下:

#include  
struct linger { 
int l_onoff //0=off, nonzero=on(开关) 
int l_linger //linger time(延迟时间) 
} 

当调用setsockopt之后,该选项产生的影响取决于linger结构体中 l_onoff和l_linger的值:

0 = l_onoff
当l_onoff被设置为0的时候,将会关闭SO_LINGER选项,即TCP或则SCTP保持默认操作:close立即返回.l_linger值被忽略.

l_lineoff值非0，0 = l_linger
当调用close的时候,TCP连接会立即断开.send buffer中未被发送的数据将被丢弃,并向对方发送一个RST信息.值得注意的是，由于这种方式，是非正常的4中握手方式结束TCP链接，所以，TCP连接将不会进入TIME_WAIT状态，这样会导致新建立的可能和就连接的数据造成混乱。

l_onoff和l_linger都是非0
在这种情况下，回事的close返回得到延迟。调用close去关闭socket的时候，内核将会延迟。也就是说，如果send buffer中还有数据尚未发送，该进程将会被休眠直到一下任何一种情况发生：
1) send buffer中的所有数据都被发送并且得到对方TCP的应答消息（这种应答并不是意味着对方应用程序已经接收到数据，在后面shutdown将会具体讲道）
2) 延迟时间消耗完。在延迟时间被消耗完之后，send buffer中的所有数据都将会被丢弃。

上面1),2)两种情况中，如果socket被设置为O_NONBLOCK状态，程序将不会等待close返回，send buffer中的所有数据都将会被丢弃。所以，需要我们判断close的返回值。在send buffer中的所有数据都被发送之前并且延迟时间没有消耗完，close返回的话，close将会返回一个EWOULDBLOCK的error.

1.默认操作的close，close立即返回

说明：我们已经知道write操作返回成功只能说明数据已经发送到套接字的发送缓冲区，不能代表对端已经成功收到数据，close的默认返回成功也只是成功发出了一个FIN分节，也不代表对端已经确认

2.设置SO_LINGER套接字选项且l_linger为正值时的close：【数据ack了，并收到FIN了】 才返回

说明：这种情况下客户的close要到它的数据和FIN已经被服务器的TCP确认以后才会返回；

3.设置SO_LINGER套接字选项且l_linger为偏小正值时的close：时间到了 返回-1，EWOULDBLOCK错误

说明：在服务端的确认到达之前，SO_LINGER套接字选项设置的延滞时间到，close将会返回EWOULDBLOCK错误，且套接字发送缓冲区中的任何残留数据被丢弃。

总结：设置SO_LINGER套接字选项以后，close的成功返回只是告诉我们先前发送的数据的FIN已经由对端TCP确认，而不能告诉我们对端应用进程是否已经读取数据，如果不设置该套接字选项，那么我们连对端TCP是否确认了数据都不知道。

l_onoff 非0，l_linger为0，丢弃发送缓冲区的任何数据，并发送rst给对端，没有四分组连接终止序列--没有fin，这样一来避免了TIME_WAIT状态，但是在2MSL秒内创建该连接的新化身，导致来自刚刚终止的连接上的旧数据被不正确的传送到新的化身上

回到这段代码

public void shutdown() throws IOException {
        Socket socket = (Socket)this.socketHolder.getAndSet((Object)null);
        if (socket != null) {
            try {
                socket.setSoLinger(true, 0);
            } catch (IOException var6) {
                ;
            } finally {
                socket.close();
            }
        }

    }

设置的是上述第三点:设置SO_LINGER套接字选项且l_linger为偏小正值时的close：时间到了 返回-1，EWOULDBLOCK错误. 为0立即返回，然后收到FIN之后发送RST，不会进入TIME_WAIT状态。

A和服务器B之间建立了TCP连接，此时C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，就是RST攻击了。实际上从上面RST标志位的功能已经可以看出这种攻击如何达到效果了。
那么伪造什么样的TCP包可以达成目的呢？我们至顶向下的看。
假定C伪装成A发过去的包，这个包如果是RST包的话，毫无疑问，B将会丢弃与A的缓冲区上所有数据，强制关掉连接。
如果发过去的包是SYN包，那么，B会表示A已经发疯了（与OS的实现有关），正常连接时又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接。

这两种方式都能够达到复位攻击的效果。似乎挺恐怖，然而关键是，如何能伪造成A发给B的包呢？这里有两个关键因素，源端口和序列号。
一个TCP连接都是四元组，由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以，如果C要伪造A发给B的包，要在上面提到的IP头和TCP头，把源IP、源端口、目标IP、目标端口都填对。这里B作为服务器，IP和端口是公开的，A是我们要下手的目标，IP当然知道，但A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以搞定的。
序列号问题是与滑动窗口对应的，伪造的TCP包里需要填序列号，如果序列号的值不在A之前向B发送时B的滑动窗口内，B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决，因为一个sequence长度是32位，取值范围0-4294967296，如果窗口大小像上图中我抓到的windows下的65535的话，只需要相除，就知道最多只需要发65537（4294967296/65535=65537）个包就能有一个序列号落到滑动窗口内。RST包是很小的，IP头＋TCP头也才40字节，算算我们的带宽就知道这实在只需要几秒钟就能搞定。

那么，序列号不是问题，源端口会麻烦点，如果各个操作系统不能完全随机的生成源端口，或者黑客们能通过其他方式获取到source port，RST攻击易如反掌，后果很严重。

http://blog.csdn.net/russell_...
https://www.cnblogs.com/my_li...
http://blog.csdn.net/le119126...
《UNIX Network ProgrammingVolume 1, Third Edition: TheSockets Networking API》
http://blog.csdn.net/yusiguyu...
http://blog.csdn.net/yusiguyu...
http://www.cs.northwestern.ed...