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