结论：
linux开启SO_LINGER时，如果设置l_linger为非0， 不管是阻塞socket，非阻塞socket， 在这里都会发生阻塞， 而并不是UNP所讲到的( 非阻塞socket会立即返回EWOULDBLOCK)
测试结果见这里
https://www.nybek.com/blog/2015/03/05/cross-platform-testing-of-so_linger/
说明: close的行为受SO_LINGER选项影响
1.默认情况
l_onoff = 0
l_linger = 0
close会将FIN包送入发送缓冲区，并立即返回，发送缓冲区的数据由系统接管，系统将数据发送完后，释放fd.
2.开启SO_LINGER
l_onoff = 1
l_linger = 0
close会立即返回，发送缓冲区的数据将丢弃，并给对端发送RST信号，重置连接， close发送方直接进入CLOSED状态，中间没有time_wait，
所以有些人在处理time_wait过多的情况时，建议采用这种方式， 这种方式的缺点是， 发送缓冲区的数据丢了，
如果是服务端就不建议这样搞了， 一是不建议服务端主动发起close， 二是这样会给客户端的数据会丢
3.开启SO_LINGER, 同时引入超时时间
l_onoff = 1
l_linger > 0
close会延迟返回， 在linux环境下有两种情况， (其它平台下，会有不同的表现，本文只是说linux)
a.在超时时间内，阻塞，直到收到对端ACK返回时，返回
b.在超时时间内，阻塞， 若对端没有ACK应答，则在超时时间到达后返回
这种方式，服务端不建议使用，因为服务端调用close时，一但对端没有应答，或者ACK应答时间过长， 服务器阻塞的时间就会很长，影响服务器性能.