最近在線上遇到一個TCP動態端口相關的問題，之前沒有留意過此類問題，做個筆記記錄在這里，希望也能給大家提供個參考。
簡單介紹下問題的場景：Windows服務器上，部署了網關程序SG和RPC進程，其中RPC進程監聽本地8003端口。問題發生在一次線上常規發布的時候，RPC程序會重啟一次加載新部署的程序文件。然而卻啟動失敗了，直接原因是”通常每個套接字地址(協議/網絡地址/端口)只允許使用一次。“。於是檢查本地端口占用情況，發現8003端口確實被占用了，而且是被網關程序占用，如下圖所示。
背景資料
-
TCP/IP協議傳輸層建立連接時請求方和目標方都需要分配一個端口號。目標方的端口號自然是提前分配並創建連接時確定具體端口的，但是請求方的端口就采用本地動態端口的策略隨機分配1個使用。
-
動態端口的分配也不是純隨機的，而是根據OS設置，在一個范圍內隨機。可以通過命令查看：
netsh int ipv4 show dynamicport tcp
其中啟動端口就是起始端口，端口數就是動態端口可分配的個數。
也可以通過命令設置起始端口和數量：
netsh int ipv4 set dynamicport tcp start=32765 num=30000
- Windows上動態端口的設置不是一成不變的，簡單來說： 在Windows vista和windows server 2008以前的系統中動態的客戶端端口范圍是1025到5000；在Windows vista和windows server 2008中，為了遵守IANA的推薦，把范圍擴展成49152到65535。
原因分析
根據以上內容，查看了服務器的動態端口配置，發現確實有問題：
也就是說，作為Socket連接請求方的網關進程，確實可能會從OS獲取到8003端口准備發起連接，所以RPC進程重啟時再次綁定8003自然就失敗了。
解決方案
修改本地動態端口范圍，避開常用的服務端口范圍。
擴展延申
查閱資料時，看到有文章提到端口回收到重用會有時間間隔，根據 RFC793 規范，此值應是網絡上最大段生存期的兩倍（2msl），處於這個階段的連接狀態未TIME_WAIT。可以通過注冊表配置此值，路徑：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\TCPIP\Parameters，鍵TcpTimedWaitDelay。