正文

tcptimedwaitdelay

發(fā)布時間：2023-03-13 12:51:45 稿源：創(chuàng)意嶺閱讀： 54 問大家

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關于tcptimedwaitdelay的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

ChatGPT國內免費在線使用，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關鍵詞，就能返回你想要的內容，越精準，寫出的就越詳細，有微信小程序端、在線網頁版、PC客戶端

官網：https://ai.de1919.com

本文目錄:

1、windows系統(tǒng)下的tcp參數優(yōu)化
2、DDOS攻擊的具體步驟？
3、Window中TCP連接耗盡解決辦法
4、TPS不穩(wěn)定，隊列產生大量的TIME_WAIT？

tcptimedwaitdelay

一、windows系統(tǒng)下的tcp參數優(yōu)化

　通常會采用修改注冊表的方式改進Windows的系統(tǒng)參數。下面將為大家介紹Windows系統(tǒng)下的TCP參數優(yōu)化方式，適用于Windows 2003、Windows XP、Windows 7以及Server版。對于具體的系統(tǒng)環(huán)境與性能需求，優(yōu)化方式會有所差異，效果也不盡相同，僅是個人的建議。所有的優(yōu)化操作都通過修改注冊表實現，需要使用regedit命令進入注冊表并創(chuàng)建或修改參數，修改完成后需要重啟系統(tǒng)，以使之生效。以下使用的參數值均為10進制。

1. TCPWindowSize

TCPWindowSize的值表示TCP的窗口大小。TCP Receive Window（TCP數據接收緩沖）定義了發(fā)送端在沒有獲得接收端的確認信息的狀態(tài)下可以發(fā)送的最大字節(jié)數。此數值越大，返回的確認信息就越少，相應的在發(fā)送端和接收端之間的通信就越好。此數值較小時可以降低發(fā)送端在等待接收端返回確認信息時發(fā)生超時的可能性，但這將增加網絡流量，降低有效吞吐率。TCP在發(fā)送端和接收端之間動態(tài)調整一個最大段長度MSS（Maximum Segment Size）的整數倍。MSS在連接開始建立時確定，由于TCP Receive Window被調整為MSS的整數倍，在數據傳輸中完全長度的TCP數據段的比例增加，故而提高了網絡吞吐率。

缺省情況下，TCP將試圖根據MSS來優(yōu)化窗口大小，起始值為16KB，最大值為64KB。TCPWindowSize的最大值通常為65535字節(jié)（64KB），以太網最大段長度為1460字節(jié)，低于64KB的1460的最大整數倍為62420字節(jié)，因而可以在注冊表中將TCPWindowSize設置為62420，作為高帶寬網絡中適用的性能優(yōu)化值。具體操作如下：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為TCPWindowSize的REG_DWORD值，該值的范圍是從0到65535，將該值設置為62420。

2. TCP1323Opts　

為了更高效地利用高帶寬網絡，可以使用比上述TCP窗口大得多的TCP窗口大小，此特性是Windows 2000和Windows Server 2003中的新特性，稱為TCP Window Scaling，它將以前的65535字節(jié)（64KB）的限制提高到了1073741824字節(jié)（1GB）。在帶寬與延遲的乘積值很高的連接上（例如衛(wèi)星連接），可能需要將窗口的大小增加到64KB以上。使用TCP Window Scaling，系統(tǒng)可以允許確認信息間更大數據量的傳輸，增加了網絡吞吐量及性能。發(fā)送端和接收端往返通信所需的時間被稱為回環(huán)時間（RTT）。TCP Window Scaling僅在TCP連接的雙方都開啟時才真正有效。TCP有一個時間戳選項，通過更加頻繁地計算來提高RTT值的估測值，此選項特別有助于估測更長距離的廣域網上連接的RTT值，并更加精確地調整TCP重發(fā)超時時間。時間戳在TCP報頭提供了兩個區(qū)域，一個記錄開始重發(fā)的時間，另一個記錄接收到的時間。時間戳對于TCP Window Scaling，即確認信息收到前的大數據包傳送特別有用，激活時間戳僅僅在每個數據包的頭部增加12字節(jié)，對網絡流量的影響微乎其微。數據完整性與數據吞吐率最大化哪個更為重要是個需要評估的問題。在某些環(huán)境中，例如視頻流傳輸，需要更大的TCP窗口，這是最重要的，而數據完整性排在第二位。在這種環(huán)境中，TCP Window Scaling可以不打開時間戳。當發(fā)送端和接收端均激活TCP Window Scaling和時間戳時，此特性才有效。不過，若在發(fā)包時加入了時間戳，經過NAT之后，如果前面相同的端口被使用過，且時間戳大于這個連接發(fā)出的SYN中的時間戳，就會導致服務器忽略該SYN，表現為用戶無法正常完成TCP的3次握手。初始時生成小的TCP窗口，之后窗口大小將按照內部算法增大。具體操作如下：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為TCP1323Opts的REG_DWORD值，該值的具體含義為：0（缺省值）表示禁用TCP Window Scaling和時間戳；1表示只啟用TCP Window Scaling；2表示只啟用時間戳；3表示同時啟用TCP Window Scaling和時間戳。TCP1323Opts設置為激活TCP Window Scaling后，可以將上文中的注冊表項TCPWindowSize的值增大，最大能達到1GB，為了達到最佳性能，這里的值最好設置成MSS的倍數，推薦值為256960字節(jié)。

3. TCP 控制塊表

對于每個TCP連接，控制變量保存在一個稱為TCP控制塊（TCB）的內存塊中。TCB表的大小由注冊表項MaxHashTableSize控制。在活動連接很多的系統(tǒng)中，設定一個較大的表可以降低系統(tǒng)定位TCB表的時間。在TCB表上分區(qū)可以降低對表的訪問的爭奪。增加分區(qū)的數量，TCP的性能會得到優(yōu)化，特別是在多處理器的系統(tǒng)上。注冊表項NumTcbTablePartitions控制分區(qū)的數量，默認是處理器個數的平方。TCB通常預置在內存中，以防止TCP反復連接和斷開時，TCB反復重新定位浪費時間，這種緩沖的方式促進了內存管理，但同時也限制了同一時刻允許的TCP連接數量。注冊表項MaxFreeTcbs決定了處于空閑等待狀態(tài)的TCB重新可用之前的連接數量，在NT架構中常設置成高于默認值，以確保有足夠的預置的TCB。從Windows 2000開始添加了一個新特性，降低超出預置TCB運行的可能性。如果處于等待狀態(tài)的連接多于MaxFreeTWTcbs中的設置，所有等待時間超過60秒的連接將被強制關閉，以后再次啟用。此特性合并到Windows 2000 Server和Windows Server 2003后，MaxFreeTcbs將不再用于優(yōu)化性能。具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為MaxHashTableSize的REG_DWORD值，該值的范圍是從1到65536，并且必須為2的N次方，缺省值為512，建議設為8192。然后在Parameters子鍵下創(chuàng)建或修改名為NumTcbTablePartitions的REG_DWORD值，該值的范圍是從1到65536，并且必須為2的N次方，缺省值為處理器個數的平方，建議設為處理器核心數的4倍。

4. TcpTimedWaitDelay

TcpTimedWaitDelay的值表示系統(tǒng)釋放已關閉的TCP連接并復用其資源之前，必須等待的時間。這段時間間隔就是以前的Blog中提到的TIME_WAIT狀態(tài)（2MSL，數據包最長生命周期的兩倍狀態(tài)）。如果系統(tǒng)顯示大量連接處于TIME_WAIT狀態(tài)，則會導致并發(fā)量與吞吐量的嚴重下降，通過減小該項的值，系統(tǒng)可以更快地釋放已關閉的連接，從而為新連接提供更多的資源，特別是對于高并發(fā)短連接的Server具有積極的意義。

該項的缺省值是240，即等待4分鐘后釋放資源；系統(tǒng)支持的最小值為30，即等待時間為30秒。具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為TcpTimedWaitDelay的REG_DWORD值，該值的范圍是從0到300，建議將該值設置為30。

5. MaxUserPort

MaxUserPort的值表示當應用程序向系統(tǒng)請求可用的端口時，TCP/IP可分配的最大端口號。如果系統(tǒng)顯示建立連接時出現異常，那么有可能是由于匿名（臨時）端口數不夠導致的，特別是當系統(tǒng)打開大量端口來與Web service、數據庫或其他遠程資源建立連接時。

該項的缺省值是十進制的5000，這也是系統(tǒng)允許的最小值。Windows默認為匿名（臨時）端口保留的端口號范圍是從1024到5000。為了獲得更高的并發(fā)量，建議將該值至少設為32768以上，甚至設為理論最大值65534，特別是對于模擬高并發(fā)測試環(huán)境的Client具有積極的意義。具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為MaxUserPort的REG_DWORD值，該值的范圍是從5000到65534，缺省值為5000，建議將該值設置為65534。

6. 動態(tài)儲備

動態(tài)儲備的值使系統(tǒng)能自動調整其配置，以接受大量突發(fā)的連接請求。如果同時接收到大量連接請求，超出了系統(tǒng)的處理能力，那么動態(tài)儲備就會自動增大系統(tǒng)支持的暫掛連接的數量（即Client已請求而Server尚未處理的等待連接數，TCP連接的總數包括已連接數與等待連接數），從而可減少連接失敗的數量。系統(tǒng)的處理能力和支持的暫掛連接的數量不足時，Client的連接請求將直接被拒絕。

缺省情況下，Windows 不啟用動態(tài)儲備，可以通過以下操作進行開啟和設置：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAFDParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改下列名稱的REG_DWORD值。

EnableDynamicBacklog，值為1，表示開啟動態(tài)儲備。
MinimumDynamicBacklog，值為128，表示支持的最小暫掛連接的數量為128。
MaximumDynamicBacklog，值為2048，表示支持的最大暫掛連接的數量為2048。對于高并發(fā)短連接的Server，建議最大值設為1024及以上。
DynamicBacklogGrowthDelta，值為128，表示支持的暫掛連接的數量的增量為128，即數量不足時自增長128，直到達到設定的最大值，如2048。

7. KeepAliveTime

KeepAliveTime的值控制系統(tǒng)嘗試驗證空閑連接是否仍然完好的頻率。如果該連接在一段時間內沒有活動，那么系統(tǒng)會發(fā)送保持連接的信號，如果網絡正常并且接收方是活動的，它就會響應。如果需要對丟失接收方的情況敏感，也就是說需要更快地發(fā)現是否丟失了接收方，請考慮減小該值。而如果長期不活動的空閑連接的出現次數較多，但丟失接收方的情況出現較少，那么可能需要增大該值以減少開銷。

缺省情況下，如果空閑連接在7200000毫秒（2小時）內沒有活動，系統(tǒng)就會發(fā)送保持連接的消息。通常建議把該值設為1800000毫秒，從而丟失的連接會在30分鐘內被檢測到。具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為KeepAliveTime的REG_DWORD值，為該值設置適當的毫秒數。

8. KeepAliveInterval

KeepAliveInterval的值表示未收到另一方對“保持連接”信號的響應時，系統(tǒng)重復發(fā)送“保持連接”信號的頻率。在無任何響應的情況下，連續(xù)發(fā)送“保持連接”信號的次數超過TcpMaxDataRetransmissions（下文將介紹）的值時，將放棄該連接。如果網絡環(huán)境較差，允許較長的響應時間，則考慮增大該值以減少開銷；如果需要盡快驗證是否已丟失接收方，則考慮減小該值或TcpMaxDataRetransmissions值。

缺省情況下，在未收到響應而重新發(fā)送“保持連接”的信號之前，系統(tǒng)會等待1000毫秒（1秒），可以根據具體需求修改，具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為KeepAliveInterval的REG_DWORD值，為該值設置適當的毫秒數。

9. TcpMaxDataRetransmissions

TcpMaxDataRetransmissions的值表示TCP數據重發(fā)，系統(tǒng)在現有連接上對無應答的數據段進行重發(fā)的次數。如果網絡環(huán)境很差，可能需要提高該值以保持有效的通信，確保接收方收到數據；如果網絡環(huán)境很好，或者通常是由于丟失接收方而導致數據的丟失，那么可以減小該值以減少驗證接收方是否丟失所花費的時間和開銷。

缺省情況下，系統(tǒng)會重新發(fā)送未返回應答的數據段5次，可以根據具體需求修改，具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為TcpMaxDataRetransmissions的REG_DWORD值，該值的范圍是從0到4294967295，缺省值為5，根據實際情況進行設置。

10. TcpMaxConnectRetransmisstions

TcpMaxConnectRetransmisstions的值表示TCP連接重發(fā)，TCP退出前重發(fā)非確認連接請求（SYN）的次數。對于每次嘗試，重發(fā)超時是成功重發(fā)的兩倍。在Windows Server 2003中默認超時次數是2，默認超時時間為3秒（在注冊表項TCPInitialRTT中）。速度較慢的WAN連接中超時時間可相應增加，不同環(huán)境中可能會有不同的最優(yōu)化設置，需要在實際環(huán)境中測試確定。超時時間不要設置太大否則將不會發(fā)生網絡連接超時時間。具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注冊表子鍵，在Parameters子鍵下創(chuàng)建或修改名為TcpMaxConnectRetransmisstions的REG_DWORD值，該值的范圍是從0到255，缺省值為2，根據實際情況進行設置。然后在Parameters子鍵下創(chuàng)建或修改名為TCPInitialRTT的REG_DWORD值，同樣根據實際情況進行設置。

11. TcpAckFrequency

TcpAckFrequency的值表示系統(tǒng)發(fā)送應答消息的頻率。如果值為2，那么系統(tǒng)將在接收到2個分段之后發(fā)送應答，或是在接收到1個分段但在200毫秒內沒有接收到任何其他分段的情況下發(fā)送應答；如果值為3，那么系統(tǒng)將在接收到3個分段之后發(fā)送應答，或是在接收到1個或2個分段但在200毫秒內沒有接收到任何其他分段的情況下發(fā)送應答，以此類推。如果要通過消除應答延遲來縮短響應時間，那么建議將該值設為1。在此情況下，系統(tǒng)會立即發(fā)送對每個分段的應答；如果連接主要用于傳輸大量數據，而200毫秒的延遲并不重要，那么可以減小該值以降低應答的開銷。

缺省情況下，系統(tǒng)將該值設為2，即每隔一個分段應答一次。該值的有效范圍是0到255，其中0表示使用缺省值2，可以根據具體需求修改，具體操作：

瀏覽至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParametersInterfacesxx（xx由網絡適配器決定）注冊表子鍵，在xx子鍵下創(chuàng)建或修改名為TcpAckFrequency的REG_DWORD值，該值的范圍是從1到13，缺省值為2，根據希望每發(fā)送幾個分段返回一個應答而設置該值，建議百兆網絡設為5，千兆網絡設為13。

https://www.cnblogs.com/larry-luo/p/11064346.html

二、DDOS攻擊的具體步驟？

1、首先在[開始]按鈕右擊點擊其中的【運行】或者“win+R”打開運行框

2、接著，在運行框里面輸入“cmd”然后點擊確定

3、在“

DDOS名詞解釋，分布式拒絕服務(DDoS:Distributed Denial of Service)攻擊指借助于客戶/服務器技術，將多個計算機聯合起來作為攻擊平臺，對一個或多個目標發(fā)動DDoS攻擊，從而成倍地提高拒絕服務攻擊的威力。

一流的攻擊速度以及強大的隱蔽性能，使得DDOS集合了市面上所有攻擊軟件優(yōu)點成為了最熱的攻擊方式。接下來本文將簡單的介紹一下三種最為流行的DDOS攻擊方式

三、Window中TCP連接耗盡解決辦法

Windows 服務器中，如果對外發(fā)起大量連接時，可能會出現端口耗盡的情況，原因如下：

一、動態(tài)端口較少。

二、TCP默認的Time Wait Delay時間為2分鐘。

新增值 TcpTimedWaitDelay，類型REG_DWORD , 設置為十進制30

四、TPS不穩(wěn)定，隊列產生大量的TIME_WAIT？

問題現象：

在高并發(fā)的壓力測試時候，有時候會TPS不穩(wěn)定或者上不去的現象，同時觀察到隊列產生大量的TIME_WAIT。

基本的分析思路：

使用netstat -an|find "TCP"，發(fā)現大量的TIME_WAIT狀態(tài)的隊列。以至于部分客戶端連接不上去，導致TPS不穩(wěn)定或者上不去，成功率下降。

發(fā)現這種情況表示有較多的隊列在等待，原因是服務器端或者客戶端的連接數有限制。

可能的情況有：服務器系統(tǒng)端口數量不夠。

我們先來看一張圖：

TCP連接的建立可以簡單的稱為三次握手，而連接的中止則可以叫做四次握手。

建立連接

在TCP/IP協議中，TCP協議提供可靠的連接服務，采用三次握手建立一個連接。

第一次握手：建立連接時，客戶端發(fā)送syn包(syn=j)到服務器，并進入SYN_SEND狀態(tài)，等待服務器確認；

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手。

完成三次握手，客戶端與服務器開始傳送數據，也就是ESTABLISHED狀態(tài)。

結束連接

TCP有一個特別的概念叫做half-close，這個概念是說，TCP的連接是全雙工（可以同時發(fā)送和接收）連接，因此在關閉連接的時候，必須關閉傳和送兩個方向上的連接。客戶機給服務器一個FIN為1 的TCP報文，然后服務器返回給客戶端一個確認ACK報文，并且發(fā)送一個FIN報文，當客戶機回復ACK報文后（四次握手），連接就結束了。

LISTEN：表示監(jiān)聽狀態(tài)。服務端調用了listen函數，可以開始accept連接了

SYN_SENT：表示客戶端已經發(fā)送了SYN報文。當客戶端調用connect函數發(fā)起連接時，首先發(fā)SYN給服務端，然后自己進入SYN_SENT狀態(tài)，并等待服務端發(fā)送ACK+SYN。

SYN_RCVD：表示服務端收到客戶端發(fā)送SYN報文。服務端收到這個報文后，進入SYN_RCVD狀態(tài)，然后發(fā)送ACK+SYN給客戶端。

ESTABLISHED：表示連接已經建立成功了。服務端發(fā)送完ACK+SYN后進入該狀態(tài)，客戶端收到ACK后也進入該狀態(tài)。

FIN_WAIT_1：表示主動關閉連接。無論哪方調用close函數發(fā)送FIN報文都會進入這個這個狀態(tài)。

CLOSE_WAIT：表示被動關閉方等待關閉。當收到對方調用close函數發(fā)送的FIN報文時，回應對方ACK報文，此時進入CLOSE_WAIT狀態(tài)。

FIN_WAIT_2：表示被動關閉方同意關閉連接。主動關閉連接方收到被動關閉方返回的ACK后，會進入該狀態(tài)。

LAST_ACK：表示被動關閉方發(fā)送FIN報文后，等待對方的ACK報文狀態(tài)，當收到ACK后進入CLOSED狀態(tài)。

TIME_WAIT：表示收到對方的FIN報文并發(fā)送了ACK報文，就等2MSL后即可回到CLOSED狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到對方同時帶FIN標志和ACK標志的報文時，可以直接進入TIME_WAIT狀態(tài)，而無須經過FIN_WAIT_2狀態(tài)。

CLOSED:結束

TCP要保證在所有可能的情況下使得所有的數據都能夠被投遞。當你關閉一個socket時，主動關閉一端的socket將進入TIME_WAIT狀態(tài)，而被動關閉一方則轉入CLOSED狀態(tài)，這的確能夠保證所有的數據都被傳輸。當一個socket關閉的時候，是通過兩端互發(fā)信息的四次握手過程完成的，當一端調用close()時，就說明本端沒有數據再要發(fā)送了。這好似看來在握手完成以后，socket就都應該處于關閉CLOSED狀態(tài)了。

但這有兩個問題：

首先，我們沒有任何機制保證最后的一個ACK能夠正常傳輸。

第二，網絡上仍然有可能有殘余的數據包(wandering duplicates)，我們也必須能夠正常處理。

我們再來看看TIME_WAIT:

TIME_WAIT是TCP連接斷開時必定會出現的狀態(tài)。是沒有辦法避免掉的。

TCP連接是全雙工的，因此每個方向必須單獨進行關閉。客戶端與服務器端建立TCP/IP連接后關閉socket，服務端連接的端口狀態(tài)未TIME_WAIT.主動關閉的一方在發(fā)送最后一個ACK后，就會進入TIME_WAIT狀態(tài)。

總結主要的原因有兩點：

1、防止上一次連接中的包，迷路后重新出現，影響新的連接

2、可靠的關閉TCP連接：在主動關閉方發(fā)送最后一個ACK(FIN),有可能會丟失，這個時候被動方會重新發(fā)送FIN，如果這時主動方處于closed狀態(tài)，就會響應RST而不是ACK。所以主動方要處于TIME_WAIT狀態(tài)，而不是CLOSED。

修改的方法：

增加服務器端口數量或者增加服務器的數量

縮短超時時間