Nagel算法的原理是什么

本篇內(nèi)容介紹了“Nagel算法的原理是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

TCP是一個(gè)復(fù)雜的協(xié)議，每個(gè)機(jī)制在帶來優(yōu)勢(shì)的同時(shí)也會(huì)引入其他的問題。 Nagel算法和delay ack機(jī)制是減少發(fā)送端和接收端包量的兩個(gè)機(jī)制， 可以有效減少網(wǎng)絡(luò)包量，避免擁塞。但是，在特定場(chǎng)景下， Nagel算法要求網(wǎng)絡(luò)中只有一個(gè)未確認(rèn)的包， 而delay ack機(jī)制需要等待更多的數(shù)據(jù)包， 再發(fā)送ACK回包， 導(dǎo)致發(fā)送和接收端等待對(duì)方發(fā)送數(shù)據(jù)， 造成死鎖， 只有當(dāng)delay ack超時(shí)后才能解開死鎖，進(jìn)而導(dǎo)致應(yīng)用側(cè)對(duì)外的延時(shí)高。 其他文字已經(jīng)介紹了相關(guān)的機(jī)制， 已經(jīng)有一些文章介紹這種時(shí)延的場(chǎng)景。本文結(jié)合具體的tcpdump包，分析觸發(fā)delay ack的場(chǎng)景，相關(guān)的內(nèi)核參數(shù)， 以及規(guī)避的方案。

背景

給redis加了一個(gè)proxy層， 壓測(cè)的時(shí)候發(fā)現(xiàn)， 對(duì)寫入命令，數(shù)據(jù)長度大于2k后， 性能下降非常明顯， 只有直連redis-server的1/10. 而get請(qǐng)求影響并不是那么明顯。

分析

觀察系統(tǒng)的負(fù)載和網(wǎng)絡(luò)包量情況， 都比較低， 網(wǎng)絡(luò)包量也比較小， proxy內(nèi)部的耗時(shí)也比較短。 無賴只能祭出tcpdump神奇， 果然有妖邪。

22號(hào)tcp請(qǐng)求包， 42ms后服務(wù)端才返回了ack。 初步懷疑是網(wǎng)絡(luò)層的延時(shí)導(dǎo)致了耗時(shí)增加。Google和km上找資料， 大概的解釋是這樣： 由于客戶端打開了Nagel算法， 服務(wù)端未關(guān)閉延遲ack， 會(huì)導(dǎo)致延遲ack超時(shí)后，再發(fā)送ack，引起超時(shí)。

原理

Nagel算法

if there is new data to send

  if the window size >= MSS and available data is >= MSS

    send complete MSS segment now

  else

    if there is unconfirmed data still in the pipe

      enqueue data in the buffer until an acknowledge is received

    else

      send data immediately

    end if

  end if

end if

簡(jiǎn)單講， Nagel算法的規(guī)則是：

1. 如果發(fā)送內(nèi)容大于1個(gè)MSS， 立即發(fā)送；

2. 如果之前沒有包未被確認(rèn)， 立即發(fā)送；

3. 如果之前有包未被確認(rèn)， 緩存發(fā)送內(nèi)容；

4. 如果收到ack， 立即發(fā)送緩存的內(nèi)容。

延遲ACK的源碼如下：net/ipv4/tcp_input.c

基本原理是：

1. 如果收到的數(shù)據(jù)內(nèi)容大于一個(gè)MSS， 發(fā)送ACK；

2. 如果收到了接收窗口以為的數(shù)據(jù)， 發(fā)送ACK；

3. 如果處于quick mode， 發(fā)送ACK；

4. 如果收到亂序的數(shù)據(jù)， 發(fā)送ACK；

5. 其他， 延遲發(fā)送ACK

其他都比較明確， quick mode是怎么判斷的呢？ 繼續(xù)往下看代碼：

影響quick mode的一個(gè)因素是 ping pong的狀態(tài)。 Pingpong是一個(gè)狀態(tài)值， 用來標(biāo)識(shí)當(dāng)前tcp交互的狀態(tài)， 以預(yù)測(cè)是否是W-R-W-R-W-R這種交互式的通訊模式， 如果處于， 可以用延遲ack， 利用Read的回包， 將Write的回包， 捎帶給發(fā)送方。

如上圖所示， 默認(rèn)pingpong = 0， 表示非交互式的， 服務(wù)端收到數(shù)據(jù)后， 立即返回ACK， 當(dāng)服務(wù)端有數(shù)據(jù)響應(yīng)時(shí)，服務(wù)端將pingpong = 1， 以后的交互中， 服務(wù)端不會(huì)立即返回ack，而是等待有數(shù)據(jù)或者ACK超時(shí)后響應(yīng)。

問題

按照前面的的原理分析，應(yīng)該每次都有ACK延遲的，為什么我們測(cè)試小于2K的數(shù)據(jù)時(shí)， 性能并沒有受到影響呢？
繼續(xù)分析tcpdump包：

按照Nagel算法和延遲ACK機(jī)制， 上面的交互如下圖所示， 由于每次發(fā)生的數(shù)據(jù)都包含了完整的請(qǐng)求， 服務(wù)端處理完成后， 向客戶端返回命令響應(yīng)時(shí)， 將請(qǐng)求的ACK捎帶給客戶端，節(jié)約一次網(wǎng)絡(luò)包。

再分析2K的場(chǎng)景：

觸發(fā)場(chǎng)景

一次tcp請(qǐng)求的數(shù)據(jù)， 不能在服務(wù)端產(chǎn)生一次響應(yīng)，或者小于一個(gè)MSS

規(guī)避方案

只有同時(shí)客戶端打開Nagel算法， 服務(wù)端打開tcp_delay_ack才會(huì)導(dǎo)致前面的死鎖狀態(tài)。 解決方案可以從TCP的兩端來入手。

服務(wù)端：

1. 關(guān)閉tcp_delay_ack, 這樣， 每個(gè)tcp請(qǐng)求包都會(huì)有一個(gè)ack及時(shí)響應(yīng)， 不會(huì)出現(xiàn)延遲的情況。 操作方式：
   echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack
   但是， 每個(gè)tcp請(qǐng)求都返回一個(gè)ack包， 導(dǎo)致網(wǎng)絡(luò)包量的增加，關(guān)閉tcp延遲確認(rèn)后， 網(wǎng)絡(luò)包量大概增加了80%，在高峰期影響還是比較明顯。
   

2. 設(shè)置TCP_QUICKACK屬性。 但是需要每次recv后再設(shè)置一次。 對(duì)應(yīng)我們的場(chǎng)景不太適合，需要修改服務(wù)端redis源碼。

客戶端：

1. 關(guān)閉nagel算法，即設(shè)置socket tcp_no_delay屬性。

   static void _set_tcp_nodelay(int fd) {
   int enable = 1;
   setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*)&enable, sizeof(enable));
   }

   
   

2. 避免多次寫， 再讀取的場(chǎng)景， 合并成一個(gè)大包的寫；避免一次請(qǐng)求分成多個(gè)包發(fā)送， 最開始發(fā)送的包小于一個(gè)MSS，對(duì)我們的場(chǎng)景， 把第22號(hào)包的1424個(gè)字節(jié)緩存起來， 大于一個(gè)MSS的時(shí)候，再發(fā)送出去， 服務(wù)端立即返回響應(yīng)， 客戶端繼續(xù)發(fā)送后續(xù)的數(shù)據(jù)， 完成交互，避免時(shí)延。

“Nagel算法的原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！