Nagle演算法

A. win10游戲延遲卡頓

主要取決於電腦硬體性能，而不是系統，所以問題不是"win10"玩游戲很卡，而是你的當前電腦玩游戲很卡。舉個例子，電腦有不同價位的，而一個win10家庭版價格是固定的，所以問題不主要在系統上。
系統提供基本的功能，自然不會要求太高的計算能力。
游戲有復雜的畫面和其它物理光影效果，需要龐大的計算量。
計算機的處理速度跟不上，自然產生延遲卡頓。

由於游戲自身或者是游戲伺服器等的網路情況不穩定或過慢，所造成的游戲卡頓情況。建議：使用網游加速器；等游戲伺服器穩定後再玩，避開高峰時段。
系統垃圾過多，或是中了病毒，又或是硬體的驅動程序未正確安裝、更新等，都可能會造成游戲卡頓。建議：使用安全軟體徹底清理系統垃圾、病毒，如無效也可以直接重裝系統；使用智能更新驅動軟體對硬體驅動進行安裝、更新。
游戲對硬體的要求較高，而電腦自身配置達不到游戲推薦配置的性能，造成卡頓也是必然情況。其次電腦如果還有硬體故障也是可能原因之一。建議：適當降低所玩游戲的特效和解析度，升級電腦硬體配置以提升性能。送到電腦售後檢查電腦的各項硬體情況，一般情況顯卡、硬碟問題居多。

B. 簡單解釋nagle演算法 急

nagle演算法:它用於自動連接許多的小緩沖器消息；這一過程（稱為nagling）通過減少必須發送包的個數來增加網路軟體系統的效率。

C. 簡述在tcp/ip體系中，流量控制和擁塞控制的不同

1. 利用滑動窗口實現流量控制
如果發送方把數據發送得過快，接收方可能會來不及接收，這就會造成數據的丟失。所謂流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP連接上實現對發送方的流量控制。
設A向B發送數據。在連接建立時，B告訴了A：「我的接收窗口是 rwnd = 400 」(這里的 rwnd 表示 receiver window) 。因此，發送方的發送窗口不能超過接收方給出的接收窗口的數值。請注意，TCP的窗口單位是位元組，不是報文段。TCP連接建立時的窗口協商過程在圖中沒有顯示出來。再設每一個報文段為100位元組長，而數據報文段序號的初始值設為1。大寫ACK表示首部中的確認位ACK，小寫ack表示確認欄位的值ack。

從圖中可以看出，B進行了三次流量控制。第一次把窗口減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B重新發出一個新的窗口值為止。B向A發送的三個報文段都設置了 ACK = 1 ，只有在ACK=1時確認號欄位才有意義。
TCP為每一個連接設有一個持續計時器(persistence timer)。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個零窗口控測報文段（攜1位元組的數據），那麼收到這個報文段的一方就重新設置持續計時器。
2. 必須考慮傳輸速率
可以用不同的機制來控制TCP報文段的發送時機。如： <1>. TCP維持一個變數，它等於最大報文段長度MSS。只要緩存中存放的數據達到MSS位元組時，就組裝成一個TCP報文段發送出去。<2>. 由發送方的應用進程指明要求發送報文段，即TCP支持的推送( push )操作。<3>. 發送方的一個計時器期限到了，這時就把已有的緩存數據裝入報文段(但長度不能超過MSS)發送出去。
Nagle演算法：若發送應用進程把要發送的數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發送出去，把後面到達的數據位元組都緩存起來。當發送方接收對第一個數據字元的確認後，再把發送緩存中的所有數據組裝成一個報文段再發送出去，同時繼續對隨後到達的數據進行緩存。只有在收到對前一個報文段的確認後才繼續發送下一個報文段。當數據到達較快而網路速率較慢時，用這樣的方法可明顯地減少所用的網路帶寬。Nagle演算法還規定：當到達的數據已達到 發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。
另，糊塗窗口綜合證： TCP接收方的緩存已滿，而互動式的應用進程一次只從接收緩存中讀取1位元組（這樣就使接收緩存空間僅騰出1位元組），然後向發送方發送確認，並把窗口設置為1個位元組（但發送的數據報為40位元組的的話）。接收，發送方又發來1個位元組的數據（發送方的IP數據報是41位元組）。接收方發回確認，仍然將窗口設置為1個位元組。這樣，網路的效率很低。要解決這個問題，可讓接收方等待一段時間，使得或者接收緩存已有足夠空間容納一個最長的報文段，或者等到接收方緩存已有一半空閑的空間。只要出現這兩種情況，接收方就發回確認報文，並向發送方通知當前的窗口大小。此外，發送方也不要發送太小的報文段，而是把數據報積累成足夠大的報文段，或達到接收方緩存的空間的一半大小。

TCP的擁塞控制
1. 擁塞：即對資源的需求超過了可用的資源。若網路中許多資源同時供應不足，網路的性能就要明顯變壞，整個網路的吞吐量隨之負荷的增大而下降。
擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提：網路能夠承受現有的網路負荷。擁塞控制是一個全局性的過程，涉及到所有的主機、路由器，以及與降低網路傳輸性能有關的所有因素。
流量控制：指點對點通信量的控制，是端到端正的問題。流量控制所要做的就是抑制發送端發送數據的速率，以便使接收端來得及接收。
擁塞控制代價：需要獲得網路內部流量分布的信息。在實施擁塞控制之前，還需要在結點之間交換信息和各種命令，以便選擇控制的策略和實施控制。這樣就產生了額外的開銷。擁塞控制還需要將一些資源分配給各個用戶單獨使用，使得網路資源不能更好地實現共享。
2. 幾種擁塞控制方法
慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復( fast recovery )。
2.1 慢開始和擁塞避免
發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變數。擁塞窗口的大小取決於網路的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞。
發送方控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口就再增大一些，以便把更多的分組發送出去。但只要網路出現擁塞，擁塞窗口就減小一些，以減少注入到網路中的分組數。
慢開始演算法：當主機開始發送數據時，如果立即所大量數據位元組注入到網路，那麼就有可能引起網路擁塞，因為現在並不清楚網路的負荷情況。因此，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口 cwnd 設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口 cwnd ，可以使分組注入到網路的速率更加合理。

每經過一個傳輸輪次，擁塞窗口 cwnd 就加倍。一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過「傳輸輪次」更加強調：把擁塞窗口cwnd所允許發送的報文段都連續發送出去，並收到了對已發送的最後一個位元組的確認。
另，慢開始的「慢」並不是指cwnd的增長速率慢，而是指在TCP開始發送報文段時先設置cwnd=1，使得發送方在開始時只發送一個報文段（目的是試探一下網路的擁塞情況），然後再逐漸增大cwnd。
為了防止擁塞窗口cwnd增長過大引起網路擁塞，還需要設置一個慢開始門限ssthresh狀態變數（如何設置ssthresh）。慢開始門限ssthresh的用法如下：
當 cwnd < ssthresh 時，使用上述的慢開始演算法。
當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。
當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。
擁塞避免演算法：讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規律緩慢增長，比慢開始演算法的擁塞窗口增長速率緩慢得多。
無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方窗口值的一半（但不能小於2）。然後把擁塞窗口cwnd重新設置為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
如下圖，用具體數值說明了上述擁塞控制的過程。現在發送窗口的大小和擁塞窗口一樣大。

<1>. 當TCP連接進行初始化時，把擁塞窗口cwnd置為1。前面已說過，為了便於理解，圖中的窗口單位不使用位元組而使用報文段的個數。慢開始門限的初始值設置為16個報文段，即 cwnd = 16 。
<2>. 在執行慢開始演算法時，擁塞窗口 cwnd 的初始值為1。以後發送方每收到一個對新報文段的確認ACK，就把擁塞窗口值另1，然後開始下一輪的傳輸（圖中橫坐標為傳輸輪次）。因此擁塞窗口cwnd隨著傳輸輪次按指數規律增長。當擁塞窗口cwnd增長到慢開始門限值ssthresh時（即當cwnd=16時），就改為執行擁塞控制演算法，擁塞窗口按線性規律增長。
<3>. 假定擁塞窗口的數值增長到24時，網路出現超時（這很可能就是網路發生擁塞了）。更新後的ssthresh值變為12（即變為出現超時時的擁塞窗口數值24的一半），擁塞窗口再重新設置為1，並執行慢開始演算法。當cwnd=ssthresh=12時改為執行擁塞避免演算法，擁塞窗口按線性規律增長，每經過一個往返時間增加一個MSS的大小。
強調：「擁塞避免」並非指完全能夠避免了擁塞。利用以上的措施要完全避免網路擁塞還是不可能的。「擁塞避免」是說在擁塞避免階段將擁塞窗口控制為按線性規律增長，使網路比較不容易出現擁塞。

D. Java netty的option(ChannelOption.SO_BACKLOG, backLog)什麼意思

這個都是socket的標准參數，並不是netty自己的。

具體為：

• ChannelOption.SO_BACKLOG,1024

BACKLOG用於構造服務端套接字ServerSocket對象，標識當伺服器請求處理線程全滿時，用於臨時存放已完成三次握手的請求的隊列的最大長度。如果未設置或所設置的值小於1，Java將使用默認值50。

• ChannelOption.SO_KEEPALIVE,true

是否啟用心跳保活機制。在雙方TCP套接字建立連接後（即都進入ESTABLISHED狀態）並且在兩個小時左右上層沒有任何數據傳輸的情況下，這套機制才會被激活。

• ChannelOption.TCP_NODELAY,true

在TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。為了盡可能的利用網路帶寬，TCP總是希望盡可能的發送足夠大的數據。這里就涉及到一個名為Nagle的演算法，該演算法的目的就是為了盡可能發送大塊數據，避免網路中充斥著許多小數據塊。

TCP_NODELAY就是用於啟用或關於Nagle演算法。如果要求高實時性，有數據發送時就馬上發送，就將該選項設置為true關閉Nagle演算法；如果要減少發送次數減少網路交互，就設置為false等累積一定大小後再發送。默認為false。

E. 設置tcp哪個socket參數 nagle演算法

UDP和TCP編程步驟也有些不同，如下：TCP編程的伺服器端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();4、開啟監聽，用函數listen()；5、接收客戶端上來的連接，用函數accept()；6、收發數據，用函數send()和recv()，或者read()和write();7、關閉網路連接；8、關閉監聽；TCP編程的客戶端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();*可選4、設置要連接的對方的IP地址和埠等屬性；5、連接伺服器，用函數connect()；6、收發數據，用函數send()和recv()，或者read()和write();7、關閉網路連接；與之對應的UDP編程步驟要簡單許多，分別如下：UDP編程的伺服器端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();4、循環接收數據，用函數recvfrom();5、關閉網路連接；UDP編程的客戶端一般步驟是：1、創建一個socket，用函數socket()；2、設置socket屬性，用函數setsockopt();*可選3、綁定IP地址、埠等信息到socket上，用函數bind();*可選4、設置對方的IP地址和埠等屬性;5、發送數據，用函數sendto();6、關閉網路連接；

F. 設置tcp哪個socket參數會影響nagle

Nagle演算法是避免發送大量的小包來提高網路利用。Nagle演算法的基本定義是任意時刻，最多隻能有一個未被確認的小包。 所謂「小包「，指的是小於MSS尺寸的數據塊，所謂「未被確認」，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。

Nagle演算法的規則（可參考tcp_output.c文件里tcp_nagle_check函數注釋）：

（1）如果包長度達到MSS，則允許發送；
（2）如果該包含有FIN，則允許發送；
（3）設置了TCP_NODELAY選項，則允許發送；
（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小於MSS）均被確認，則允許發送；
（5）上述條件都未滿足，但發生了超時（一般為200ms），則立即發送。

影響tcp Nagle演算法參數有TCP_NODELAY和TCP_CORK。

接收端的延遲ACK對Nagle演算法也有一定的影響。

G. win10優化電腦游戲性能

win10系統已經發布一段時間了，穩定性也比較好，不過有時候win10系統玩游戲總一卡一卡，不管是什麼游戲都一樣，有什麼辦法優化一下，讓游戲運行速度更加流暢？方法當然有的，這里給大家准備win10提高游戲性能的四種優化方法。

一. 關閉nagle演算法

很多人對於Nagle演算法並不了解，簡單來說，這是TCP協議里的一套演算法

可以將數據小包統一打包成為一堆再發送，減少傳輸次數，主要用來提高帶寬利用率避免網路擁堵。

不過Nagle也是一柄雙刃劍，它的最大問題就是導致某些在線操作延遲過高，進而導致網游卡頓。

1. 按下快捷鍵Win+R，調出「運行」對話框，輸入「regedit」進入注冊表編輯器;

2. 將下列地址粘貼到注冊表編輯器的地址欄中：計算機HKEY_LOCAL_;

和之前系統相比，Win10在游戲方面其實更強。特別是一些新技術的加入

讓很多新游戲多了更多可發揮的空間。不過要是你比較青睞老游戲

或者電腦的配置原本不高，就需要對Win10進行一番調教了。

以上和大家分享win10玩游戲總一卡一卡的四種優化方法，趕緊設置試試看！希望對你有所幫助

H. Nagle演算法的演算法

TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。為了盡可能的利用網路帶寬，TCP總是希望盡可能的發送足夠大的數據。（一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據）。Nagle演算法就是為了盡可能發送大塊數據，避免網路中充斥著許多小數據塊。Nagle演算法的基本定義是任意時刻，最多隻能有一個未被確認的小段。 所謂「小段」，指的是小於MSS尺寸的數據塊，所謂「未被確認」，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。Nagle演算法的規則（可參考tcp_output.c文件里tcp_nagle_check函數注釋）：
（1）如果包長度達到MSS，則允許發送；
（2）如果該包含有FIN，則允許發送；
（3）設置了TCP_NODELAY選項，則允許發送；
（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小於MSS）均被確認，則允許發送；
（5）上述條件都未滿足，但發生了超時（一般為200ms），則立即發送。
Nagle演算法只允許一個未被ACK的包存在於網路，它並不管包的大小，因此它事實上就是一個擴展的停-等協議，只不過它是基於包停-等的，而不是基於位元組停-等的。Nagle演算法完全由TCP協議的ACK機制決定，這會帶來一些問題，比如如果對端ACK回復很快的話，Nagle事實上不會拼接太多的數據包，雖然避免了網路擁塞，網路總體的利用率依然很低。
Nagle演算法是silly window syndrome(SWS)預防演算法的一個半集。SWS演算法預防發送少量的數據，Nagle演算法是其在發送方的實現，而接收方要做的是不要通告緩沖空間的很小增長，不通知小窗口，除非緩沖區空間有顯著的增長。這里顯著的增長定義為完全大小的段（MSS）或增長到大於最大窗口的一半。注意：BSD的實現是允許在空閑鏈接上發送大的寫操作剩下的最後的小段，也就是說，當超過1個MSS數據發送時，內核先依次發送完n個MSS的數據包，然後再發送尾部的小數據包，其間不再延時等待。（假設網路不阻塞且接收窗口足夠大）
舉個例子，比如之前的blog中的實驗，一開始client端調用socket的write操作將一個int型數據（稱為A塊）寫入到網路中，由於此時連接是空閑的（也就是說還沒有未被確認的小段），因此這個int型數據會被馬上發送到server端，接著，client端又調用write操作寫入『 』（簡稱B塊），這個時候，A塊的ACK沒有返回，所以可以認為已經存在了一個未被確認的小段，所以B塊沒有立即被發送，一直等待A塊的ACK收到（大概40ms之後），B塊才被發送。整個過程如圖所示：
這里還隱藏了一個問題，就是A塊數據的ACK為什麼40ms之後才收到？這是因為TCP/IP中不僅僅有nagle演算法，還有一個TCP確認延遲機制 。當Server端收到數據之後，它並不會馬上向client端發送ACK，而是會將ACK的發送延遲一段時間（假設為t），它希望在t時間內server端會向client端發送應答數據，這樣ACK就能夠和應答數據一起發送，就像是應答數據捎帶著ACK過去。在我之前的時間中，t大概就是40ms。這就解釋了為什麼' '（B塊）總是在A塊之後40ms才發出。當然，TCP確認延遲40ms並不是一直不變的，TCP連接的延遲確認時間一般初始化為最小值40ms，隨後根據連接的重傳超時時間（RTO）、上次收到數據包與本次接收數據包的時間間隔等參數進行不斷調整。另外可以通過設置TCP_QUICKACK選項來取消確認延遲。2. TCP_NODELAY 選項
默認情況下，發送數據採用Nagle 演算法。這樣雖然提高了網路吞吐量，但是實時性卻降低了，在一些交互性很強的應用程序來說是不允許的，使用TCP_NODELAY選項可以禁止Nagle 演算法。
此時，應用程序向內核遞交的每個數據包都會立即發送出去。需要注意的是，雖然禁止了Nagle 演算法，但網路的傳輸仍然受到TCP確認延遲機制的影響。3. TCP_CORK 選項
所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數據先不發出去，等到拔去塞子後再發出去。設置該選項後，內核會盡力把小數據包拼接成一個大的數據包（一個MTU）再發送出去，當然若一定時間後（一般為200ms，該值尚待確認），內核仍然沒有組合成一個MTU時也必須發送現有的數據（不可能讓數據一直等待吧）。然而，TCP_CORK的實現可能並不像你想像的那麼完美，CORK並不會將連接完全塞住。內核其實並不知道應用層到底什麼時候會發送第二批數據用於和第一批數據拼接以達到MTU的大小，因此內核會給出一個時間限制，在該時間內沒有拼接成一個大包（努力接近MTU）的話，內核就會無條件發送。也就是說若應用層程序發送小包數據的間隔不夠短時，TCP_CORK就沒有一點作用，反而失去了數據的實時性（每個小包數據都會延時一定時間再發送）。4. Nagle演算法與CORK演算法區別Nagle演算法和CORK演算法非常類似，但是它們的著眼點不一樣，Nagle演算法主要避免網路因為太多的小包（協議頭的比例非常之大）而擁塞，而CORK演算法則是為了提高網路的利用率，使得總體上協議頭佔用的比例盡可能的小。如此看來這二者在避免發送小包上是一致的，在用戶控制的層面上，Nagle演算法完全不受用戶socket的控制，你只能簡單的設置TCP_NODELAY而禁用它，CORK演算法同樣也是通過設置或者清除TCP_CORK使能或者禁用之，然而Nagle演算法關心的是網路擁塞問題，只要所有的ACK回來則發包，而CORK演算法卻可以關心內容，在前後數據包發送間隔很短的前提下（很重要，否則內核會幫你將分散的包發出），即使你是分散發送多個小數據包，你也可以通過使能CORK演算法將這些內容拼接在一個包內，如果此時用Nagle演算法的話，則可能做不到這一點。