Socket的基本背景

在討論這兩個選項的區別時，我們需要知道的是BSD實現是所有socket實現的起源。基本上其他所有的系統某種程度上都參考了BSD socket實現（或者至少是其介面），然後開始了它們自己的獨立發展進化。顯然，BSD本身也是隨著時間在不斷髮展變化的。所以較晚參考BSD的系統比較早參考BSD的系統多一些特性。所以理解BSD socket實現是理解其他socket實現的基石。下面我們就分析一下BSD socket實現。

在這之前，我們首先要明白如何唯一識別TCP/UDP連線。TCP/UDP是由以下五元組唯一地識別的：
{<protocol>, <src addr>, <src port>, <dest addr>, <dest port>}

這些數值組成的任何獨特的組合可以唯一地確一個連線。那麼，對於任意連線，這五個值都不能完全相同。否則的話作業系統就無法區別這些連線了。

一個socket的協議是在用socket()初始化的時候就設定好的。源地址（source address）和源埠（source port）在呼叫bind()的時候設定。目的地址（destination address）和目的埠（destination port）在呼叫connect()的時候設定。其中UDP是無連線的，UDP socket可以在未與目的埠連線的情況下使用。但UDP也可以在某些情況下先與目的地址和埠建立連線後使用。在使用無連線UDP傳送資料的情況下，如果沒有顯式地呼叫bind()

如果我們手動繫結一個埠，我們可以將socket繫結至埠0，繫結至埠0的意思是讓系統自己決定使用哪個埠（一般是從一組作業系統特定的提前決定的埠數範圍中），所以也就是任何埠的意思。同樣的，我們也可以使用一個萬用字元來讓系統決定繫結哪個源地址（ipv4萬用字元為0.0.0.0，ipv6萬用字元為::）。而與埠不同的是，一個socket可以被繫結到主機上所有介面所對應的地址中的任意一個。基於連線在本socket的目的地址和路由表中對應的資訊，作業系統將會選擇合適的地址來繫結這個socket，並用這個地址來取代之前的萬用字元IP地址。

在預設情況下，任意兩個socket不能被繫結在同一個源地址和源埠組合上。比如說我們將socketA繫結在A:X地址，將socketB繫結在B:Y地址，其中A和B是IP地址，X和Y是埠。那麼在A==B的情況下X!=Y必須滿足，在X==Y的情況下A!=B必須滿足。需要注意的是，如果某一個socket被繫結在萬用字元IP地址下，那麼事實上本機所有IP都會被系統認為與其綁定了。例如一個socket綁定了0.0.0.0:21，在這種情況下，任何其他socket不論選擇哪一個具體的IP地址，其都不能再繫結在21埠下。因為萬用字元IP0.0.0.0與所有本地IP都衝突。

以上所有內容基本上在主要作業系統中都相同。而各個中SO_REUSEADDR會有不同的含義。首先我們來討論BSD實現。因為BSD試試其他所有socket實現方法的源頭。

BSD

SO_REUSEADDR

如果在一個socket繫結到某一地址和埠之前設定了其SO_REUSEADDR的屬性，那麼除非本socket與產生了嘗試與另一個socket繫結到完全相同的源地址和源埠組合的衝突，否則的話這個socket就可以成功的繫結這個地址埠對。這聽起來似乎和之前一樣。但是其中的關鍵字是完全。SO_REUSEADDR主要改變了系統對待萬用字元IP地址衝突的方式。

如果不用SO_REUSEADDR的話，如果我們將socketA繫結到0.0.0.0:21，那麼任何將本機其他socket繫結到埠21的舉動（如繫結到192.168.1.1:21）都會導致EADDRINUSE錯誤。因為0.0.0.0是一個萬用字元IP地址，意味著任意一個IP地址，所以任何其他本機上的IP地址都被系統認為已被佔用。如果設定了SO_REUSEADDR選項，因為0.0.0.0:21和192.168.1.1:21並不是完全相同的地址埠對（其中一個是萬用字元IP地址，另一個是一個本機的具體IP地址），所以這樣的繫結是可以成功的。需要注意的是，無論socketA和socketB初始化的順序如何，只要設定了SO_REUSEADDR，繫結都會成功；而只要沒有設定SO_REUSEADDR，繫結都不會成功。

下面的表格列出了一些可能的情況及其結果。

這個表格假定socketA已經成功地綁定了表格中對應的地址，然後socketB被初始化了，其SO_REUSEADDR設定的情況如表格第一列所示，然後socketB試圖繫結表格中對應地址。Result列是其繫結的結果。如果第一列中的值是ON/OFF，那麼SO_REUSEADDR設定與否都與結果無關。

上面討論了SO_REUSEADDR對萬用字元IP地址的作用，但其並不只有這一作用。其另一作用也是為什麼大家在進行伺服器端程式設計的時候會採用SO_REUSEADDR選項的原因。為了理解其另一個作用及其重要應用，我們需要先更深入地討論一下TCP協議的工作原理。

每一個socket都有其相應的傳送緩衝區（buffer）。當成功呼叫其send()方法的時候，實際上我們所要求傳送的資料並不一定被立即傳送出去，而是被新增到了傳送緩衝區中。對於UDP socket來說，即使不是馬上被髮送，這些資料一般也會被很快傳送出去。但對於TCP socket來說，在將資料新增到傳送緩衝區之後，可能需要等待相對較長的時間之後資料才會被真正傳送出去。因此，當我們關閉了一個TCP socket之後，其傳送緩衝區中可能實際上還仍然有等待發送的資料。但此時因為send()返回了成功，我們的程式碼認為資料已經實際上被成功傳送了。如果TCP socket在我們呼叫close()之後直接關閉，那麼所有這些資料都將會丟失，而我們的程式碼根本不會知道。但是，TCP是一個可靠的傳輸層協議，直接丟棄這些待傳輸的資料顯然是不可取的。實際上，如果在socket的傳送緩衝區中還有待發送資料的情況下呼叫了其close()方法，其將會進入一個所謂的TIME_WAIT狀態。在這個狀態下，socket將會持續嘗試傳送緩衝區的資料直到所有資料都被成功傳送或者直到超時，超時被觸發的情況下socket將會被強制關閉。

作業系統的kernel在強制關閉一個socket之前的最長等待時間被稱為延遲時間（Linger Time）。在大部分系統中延遲時間都已經被全域性設定好了，並且相對較長（大部分系統將其設定為2分鐘）。我們也可以在初始化一個socket的時候使用SO_LINGER選項來特定地設定每一個socket的延遲時間。我們甚至可以完全關閉延遲等待。但是需要注意的是，將延遲時間設定為0（完全關閉延遲等待）並不是一個好的程式設計實踐。因為優雅地關閉TCP socket是一個比較複雜的過程，過程中包括與遠端主機交換數個數據包（包括在丟包的情況下的丟失重傳），而這個資料包交換的過程所需要的時間也包括在延遲時間中。如果我們停用延遲等待，socket不止會在關閉的時候直接丟棄所有待發送的資料，而且總是會被強制關閉（由於TCP是面向連線的協議，不與遠端埠交換關閉資料包將會導致遠端埠處於長時間的等待狀態）。所以通常我們並不推薦在實際程式設計中這樣做。TCP斷開連線的過程超出了本文討論的範圍，如果對此有興趣，可以參考這個頁面。並且實際上，如果我們禁用了延遲等待，而我們的程式沒有顯式地關閉socket就退出了，BSD（可能包括其他系統）會忽略我們的設定進行延遲等待。例如，如果我們的程式呼叫了exit()方法，或者其程序被使用某個訊號終止了（包括程序因為非法記憶體訪問之類的情況而崩潰）。所以我們無法百分之百保證一個socket在所有情況下忽略延遲等待時間而終止。

這裡的問題在於作業系統如何對待處於TIME_WAIT階段的socket。如果SO_REUSEADDR選項沒有被設定，處於TIME_WAIT階段的socket任然被認為是繫結在原來那個地址和埠上的。直到該socket被完全關閉之前（結束TIME_WAIT階段），任何其他企圖將一個新socket繫結該該地址埠對的操作都無法成功。這一等待的過程可能和延遲等待的時間一樣長。所以我們並不能馬上將一個新的socket繫結到一個剛剛被關閉的socket對應的地址埠對上。在大多數情況下這種操作都會失敗。

然而，如果我們在新的socket上設定了SO_REUSEADDR選項，如果此時有另一個socket繫結在當前的地址埠對且處於TIME_WAIT階段，那麼這個已存在的繫結關係將會被忽略。事實上處於TIME_WAIT階段的socket已經是半關閉的狀態，將一個新的socket繫結在這個地址埠對上不會有任何問題。這樣的話原來繫結在這個埠上的socket一般不會對新的socket產生影響。但需要注意的是，在某些時候，將一個新的socket繫結在一個處於TIME_WAIT階段但仍在工作的socket所對應的地址埠對會產生一些我們並不想要的，無法預料的負面影響。但這個問題超過了本文的討論範圍。而且幸運的是這些負面影響在實踐中很少見到。

最後，關於SO_REUSEADDR，我們還要注意的一件事是，以上所有內容只要我們對新的socket設定了SO_REUSEADDR就成立。至於原有的已經繫結在當前地址埠對上的，處於或不處於TIME_WAIT階段的socket是否設定了SO_REUSEADDR並無影響。決定bind操作是否成功的程式碼僅僅會檢查新的被傳遞到bind()方法的socket的SO_REUSEADDR選項。其他涉及到的socket的SO_REUSEADDR選項並不會被檢查。

SO_REUSEPORT

許多人將SO_REUSEADDR當成了SO_REUSEPORT。基本上來說，SO_REUSEPORT允許我們將任意數目的socket繫結到完全相同的源地址埠對上，只要所有之前繫結的socket都設定了SO_REUSEPORT選項。如果第一個繫結在該地址埠對上的socket沒有設定SO_REUSEPORT，無論之後的socket是否設定SO_REUSEPORT，其都無法繫結在與這個地址埠完全相同的地址上。除非第一個繫結在這個地址埠對上的socket釋放了這個繫結關係。與SO_REUSEADDR不同的是 ，處理SO_REUSEPORT的程式碼不僅會檢查當前嘗試繫結的socket的SO_REUSEPORT，而且也會檢查之前已綁定了當前嘗試繫結的地址埠對的socket的SO_REUSEPORT選項。

SO_REUSEPORT並不等於SO_REUSEADDR。這麼說的含義是如果一個已經綁定了地址的socket沒有設定SO_REUSEPORT，而另一個新socket設定了SO_REUSEPORT且嘗試繫結到與當前socket完全相同的埠地址對，這次繫結嘗試將會失敗。同時，如果當前socket已經處於TIME_WAIT階段，而這個設定了SO_REUSEPORT選項的新socket嘗試繫結到當前地址，這個繫結操作也會失敗。為了能夠將新的socket繫結到一個當前處於TIME_WAIT階段的socket對應的地址埠對上，我們要麼需要在繫結之前設定這個新socket的SO_REUSEADDR選項，要麼需要在繫結之前給兩個socket都設定SO_REUSEPORT選項。當然，同時給socket設定SO_REUSEADDR和SO_REUSEPORT選項是也是可以的。

SO_REUSEPORT是在SO_REUSEADDR之後被新增到BSD系統中的。這也是為什麼現在有些系統的socket實現裡沒有SO_REUSEPORT選項。因為它們在這個選項被加入BSD系統之前參考了BSD的socket實現。而在這個選項被加入之前，BSD系統下沒有任何辦法能夠將兩個socket繫結在完全相同的地址埠對上。

Connect()返回EADDRINUSE？

有些時候bind()操作會返回EADDRINUSE錯誤。但奇怪的是，在我們呼叫connect()操作時，也有可能得到EADDRINUSE錯誤。這是為什麼呢？為何一個我們嘗試令當前埠建立連線的遠端地址也會被佔用呢？難道將多個socket連線到同一個遠端地址的操作會有什麼問題產生嗎？

正如本文之前所說，一個連線關係是由一個五元組確定的。對於任意的連線關係而言，這個五元組必須是唯一的。否則的話，系統將無法分辨兩個連線。而現在當我們採用了地址複用之後，我們可以將兩個採用相同協議的socket繫結到同一地址埠對上。這意味著對這兩個socket而言，五元組裡的{<protocol>, <src addr>, <src port>}已經相同了。在這種情況下，如果我們嘗試將它們都連線到同一個遠端地址埠上，這兩個連線關係的五元組將完全相同。也就是說，產生了兩個完全相同的連線。在TCP協議中這是不被允許的（UDP是無連線的）。如果這兩個完全相同的連接種的某一個接收到了資料，系統將無法分辨這個資料到底屬於哪個連線。所以在這種情況下，至少這兩個socket所嘗試連線的遠端主機的地址和埠不能相同。只有如此，系統才能繼續區分這兩個連線關係。

所以當我們將兩個採用相同協議的socket繫結到同一個本地地址埠對上後，如果我們還嘗試讓它們和同一個目的地址埠對建立連線，第二個嘗試呼叫connect()方法的socket將會報EADDRINUSE的錯誤，這說明一個擁有完全相同的五元組的socket已經存在了。

Multicast Address

相對於用於一對一通訊的unicast地址，multicast地址用於一對多通訊。IPv4和IPv6都擁有multicast地址。但是IPv4中的multicast實際上在公共網路上很少被使用。

SO_REUSEADDR的意義在multicast地址的情況下會與之前有所不同。在這種情況下，SO_REUSEADDR允許我們將多個socket繫結至完全相同的源廣播地址埠對上。換句話說，對於multicast地址而言，SO_REUSEADDR的作用相當於unicast通訊中的SO_REUSEPORT。事實上，在multicast情況下，SO_REUSEADDR和SO_REUSEPORT的作用完全相同。

FreeBSD/OpenBSD/NetBSD

所有這些系統都是參考了較新的原生BSD系統程式碼。所以這三個系統提供與BSD完全相同的socket選項，這些選項的含義與原生BSD完全相同。

MacOS X

MacOS X的核心程式碼實現是基於較新版本的原生BSD的BSD風格的UNIX，所以MacOS X提供與BSD完全相同的socket選項，並且它們的含義也與BSD系統相同。

iOS

iOS事實上是一個略微改造過的MacOS X，所以適用於MacOS X的也適用於iOS。

Linux

在Linux3.9之前，只有SO_REUSEADDR選項存在。這個選項的作用基本上同BSD系統下相同。但其仍有兩個重要的區別。
第一個區別是如果一個處於監聽（伺服器）狀態下的TCP socket已經被繫結到了一個萬用字元IP地址和一個特定埠下，那麼不論這兩個socket有沒有設定SO_REUSEADDR選項，任何其他TCP socket都無法再被繫結到相同的埠下。即使另一個socket使用了一個具體IP地址（像在BSD系統中允許的那樣）也不行。而非監聽（客戶）TCP socket則無此限制。
第二個區別是對於UDP socket來說，SO_REUSEADDR的作用和BSD中SO_REUSEPORT完全相同。所以兩個UDP socket如果都設定了SO_REUSEADDR的話，它們就可以被繫結在一組完全相同的地址埠對上。
Linux3.9加入了SO_REUSEPORT選項。只要所有socket（包括第一個）在繫結地址前設定了這個選項，兩個或多個，TCP或UDP，監聽（伺服器）或非監聽（客戶）socket就可以被繫結在完全相同的地址埠組合下。同時，為了防止埠劫持（port hijacking），還有一個特別的限制：所有試圖繫結在相同的地址埠組合的socket必須屬於擁有相同使用者ID的程序。所以一個使用者無法從另一個使用者那裡“偷竊”埠。
除此之外，對於設定了SO_REUSEPORT選項的socket，Linux kernel還會執行一些別的系統所沒有的特別的操作：對於綁定於同一地址埠組合上的UDP socket，kernel嘗試在它們之間平均分配收到的資料包；對於綁定於同一地址埠組合上的TCP監聽socket，kernel嘗試在它們之間平均分配收到的連線請求（呼叫accept()方法所得到的請求）。這意味著相比於其他允許地址複用但隨機將收到的資料包或者連線請求分配給連線在同一地址埠組合上的socket的系統而言，Linux嘗試了進行流量分配上的優化。比如一個簡單的伺服器程序的幾個不同例項可以方便地使用SO_REUSEPORT來實現一個簡單的負載均衡，而且這個負載均衡有kernel負責， 對程式來說完全免費！

Android

Android的核心部分是略微修改過的Linux kernel，所以所有適用於Linux的操作也適用於Android。

Windows

Windows僅有SO_REUSEADDR選項。在Windows中對一個socket設定SO_REUSEADDR的效果與在BSD下同時對一個socket設定SO_REUSEPORT和SO_REUSEADDR相同。但其區別在於：即使另一個已繫結地址的socket並沒有設定SO_REUSEADDR，一個設定了SO_REUSEADDR的socket總是可以繫結到與另一個已繫結的socket完全相同的地址埠組合上。這個行為可以說是有些危險的。因為它允許了一個應用從另一個引用已連線的埠上偷取資料。微軟意識到了這個問題，因此添加了另一個socket選項：SO_EXCLUSIVEADDRUSE。對一個socket設定SO_EXCLUSIVEADDRUSE可以確保一旦該socket綁定了一個地址埠組合，任何其他socket，不論設定SO_REUSEADDR與否，都無法再綁定當前的地址埠組合。

Solaris

Solaris是SunOS的繼任者。SunOS從某種程度上來說也是一個較早版本的BSD的一個支路。因此Solaris只提供SO_REUSEADDR，且其表現和BSD系統中基本相同。據我所知，在Solaris系統中無法實現與SO_REUSEPORT相同的功能。這意味著在Solaris中無法將兩個socket繫結到完全相同的地址埠組合下。

與Windows類似的是，Solaris也為socket提供獨佔繫結的選項——SO_EXCLBIND。如果一個socket在繫結地址前設定了這個選項，即使其他socket設定了SO_REUSEADDR也將無法繫結至相同地址。例如：如果socketA繫結在了萬用字元IP地址下，而socketB設定了SO_REUSEADDR且繫結在一個具體IP地址和與socketA相同的埠的組合下，這個操作在socketA沒有設定SO_EXCLBIND的情況下會成功，否則會失敗。