????? 今天運行了寫好的程序，出現了錯誤。java.net.BindException: Address in use: connect。查找網上資源，說主要原因是因為連接太多，socket綁定端口在短時間內不能釋放。
java.net.ConnectException: Address already in use
???????? at java.net.PlainSocketImpl.socketConnect(Native Method)
???????? at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
???????? at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
???????? at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
???????? at java.net.Socket.connect(Socket.java:426)
???????? at com.nec.adams.app.mp.ups.Session.setup(Session.java:383)
???????? at com.nec.adams.app.mp.ups.StateActive.run(StateActive.java:197)
???????? at com.nec.adams.app.mp.ups.UPSServer.runService(UPSServer.java:248)
???????? at com.nec.adams.app.mp.ups.UPSServer.main(UPSServer.java:155)
程序的流程如下：
?????? socket = new Socket();
?????? socket.setReuseAddress(true);
?????? socket.bind(new InetSocketAddress(127.0.0.1, 19760));
?????? socket.connect(new InetSocketAddress(192.168.0.5, 5111), 1000);
???????
最開始的時候，沒有使用"socket.setReuseAddress(true);"這句，出現的是
"java.net.BindException: Address already in
use"。仔細分析，引來對socket的bind和connect的調查。
??????? 普通情況下的socket關閉，兩個連接端點都需要發送FIN (final)
包，并且兩個端點都應該回應ACK
(acknowledge)對方的FIN包，然后socket關閉完成。FIN包由應用程序的close(),shutdown(),exit()這些發
起，而ACK包在close()完成后由系統內核發送。
???????
???????
上圖顯示了所有可能的正常關閉情況，根據事情發生的不同順序。注意到如果你發起關閉，另一端會出現一個“TIME_WAIT"的狀態?！?
TIME_OUT"狀態在這個過程完成后會幫定這個port幾分鈡。具體timeout的時間根據不同的操作系統而定。不過典型的時間是1到4分鐘。
??????? 為了避免綁定失敗，可以使用setReuseAddress(true)方法，這樣系統允許一個進程綁定哪怕是處在TIME_WAIT狀態的端口。這是最簡單有效的消除“Address already in use"錯誤的方法。
???????
奇怪的是，這樣又帶來更復雜的問題。setReuseAddress(true)允許你用一個正在TIME_WAIT的端口，但是你仍然不能與上次你連接
的地址建立連接。什麼？假設我選擇了端口1010，去連接foobar.com的端口300，然后在本地關閉，讓那個端口處在TIME_WAIT狀態。這
個時候我立刻可以用端口1010去連接除了foobar.com的端口300。在這個時候出現的就是
"java.net.ConnectException:Address already in
use"。在這個時候使用setReuseAddress(true)是無效的，應該避免。
???????
有些人不喜歡使用setReuseAddress(true)的另外一個原因是它帶來一個安全問題。在一些操作系統上它允許不同的進程同時使用相同的端口
區連接不同的地址。這是一個問題，因為大多數的服務器綁定在這個端口上，但是它并沒有幫定到一個地址（這就是為什麼netstat的輸出會出現
*.8080這種情況)。於是如果這個服務器綁定*.8080，另外一個惡意的用戶能夠幫定local-machine.8080，去竊聽你的連接的特定
信息。
???????
通過上面的圖，可以看到TIME_WAIT可以被避免，如果遠程端口發起關閉。如是服務器能避免這個問題，通過讓客戶端首先關閉連接。應用層協議必須被設
計成客戶端知道什麼時候關閉連接。服務器端能完全地關閉，通過客戶端的回應EOF。
但是，它仍然需要設置一個timeout，如果客戶端不正常斷開了網絡。在多數情況下在服務器關閉之前等上幾秒就足夠了。
參考文章：
http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
??????? 在讀了W. Richard Stevens 的《TCP/IP Illustated》之后，才明白，為什么會有這個TIME_WAIT狀態，和為什么等待的時間是大約4分鐘，而且各個系統不一樣。
2MSL連接
???????
TIME_WAIT狀態也稱為2MSL等待狀態。每個TCP必須選擇一個報文段最大生存時間MSL（Maximun Segment
Lifetime）。它是任何報文段被丟棄前在網絡的最長時間。RFC 793(Postel
1981c)指出MSL為2分鐘。然而，實現中的常用值是30秒，1分鐘，或2分鐘。
??????? 對一個具體實現所給定的MSL值，處理的原則是：當TCP執行一個主動關閉，并發回最后一個ACK，該連接必須在TIME_WAIT狀態停留的時間為2倍的MSL。這樣可讓TCP再次發送最后的ACK以防這個ACK丟失（另一端超時并重發最后的FIN）。
??????? 這種2MSL等待的另一個結果是這個TCP連接在2MSL等待期間，定義這個連接的Socket（客戶的IP地址和端口號，服務器的IP地址和端口號）不能再被使用。這個連接只能在2MSL結束后才能被使用。
??????? 遺憾的是，大多數的TCP實現（如柏克利版）強加了更為嚴格的限制。在2MSL等待期間，Socket中使用的本地端口在默認情況下不能被再次使用。
??????? 某些實現和API提供了一種避開這個限制的方法。使用Socket API時，可說明其中的SO_REUSEADDR選項。它可讓調用者對處于2MSL等待的本地端口進行賦值，但我們將看到TCP原則上仍將避免使用處于2MSL連接中的端口。
???????
一個Socket對（即包含本地IP地址、本地端口、遠端IP地址、遠端端口的4元組）在它處于2MSL等待時，將不能再被使用。盡管許多具體的實現中允
許一個進程重新使用仍處于2MSL等待的端口（通常是設置選項SO_REUSEADDR），但TCP不能允許一個新的連接建立在相同的Socket對上。