結論：
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應答時間過長， 服務器阻塞的時間就會很長，影響服務器性能.