一種無丟包零停機重啟網(wǎng)絡服務的方法和系統(tǒng)的制作方法【
技術領域：
】[0001]本發(fā)明涉及一種重啟網(wǎng)絡服務技術，更具體而言，涉及一種零停機重啟網(wǎng)絡服務的方法和系統(tǒng)，使得在重啟網(wǎng)絡服務時不僅能正常處理所有的新連接，而且不會造成連接中斷?！?br>背景技術：
】[0002]在現(xiàn)有的各種網(wǎng)絡服務中，某些網(wǎng)絡服務必須重新啟動進程才能完成重啟或者重新載入配置文件。典型的例子是在很多負載特別大的web站點中所提供的HAProxy網(wǎng)絡服務。此網(wǎng)絡服務通過使用S0_REUSEP0RT選項，將新進程綁定到與舊進程完全相同的IP地址和端口開始監(jiān)聽新的連接，再發(fā)送信號通知老進程關閉監(jiān)聽端口的套接字(socket)。但是，當新老兩個進程都綁定到同一個IP和端口，并且老進程的監(jiān)聽套接字還未關閉的短暫時間間隙中新的連接可能會到來。根據(jù)Linux內核中S0_REUSEP0RT的實現(xiàn)，新連接的第一個報文(SYN報文)可能會被分配給新老進程中的任意一個。如果這個SYN報文被分配給老進程，而緊接著老進程的監(jiān)聽套接字又被關閉，根據(jù)TCP協(xié)議，服務端會發(fā)送一個TCPRST報文給客戶端重置這條連接。這會造成一條正常的連接被無條件重置。雖然客戶端可以重新發(fā)起連接，但這無疑增加了整個數(shù)據(jù)傳輸所需要的時間，也給連接客戶端與服務器的網(wǎng)絡線路增加了不必要的負擔。除了在上述HAProxy網(wǎng)絡服務中存在必須重新啟動進程才能完成重啟或者重新載入配置文件的問題之外，還有許多網(wǎng)絡服務存在同樣的問題，例如:nginX網(wǎng)絡服務等。[0003]針對所述網(wǎng)絡服務中存在的這一問題，目前已經提供了一些解決方案。一種簡單的做法是在進程重載期間配置iptables規(guī)則來丟棄掉新收到的SYN報文。根據(jù)TCP協(xié)議，客戶端在沒有收到SYN/ACK報文一段時間后就會重新發(fā)送SYN報文，這樣，重新發(fā)送的SYN報文就能被已經完成重載的新進程順利接收，從而解決了所述問題。但是，這一方案的不足之處在于，客戶端必須等待一段時間直到超時以重新發(fā)送SYN報文。而這段等待時間通常都很長，例如在1秒種以上，但進程重載的時間往往只需要幾十毫秒，這就導致已經完成重載的新進程必須多等待例如1秒左右的時間才能接收到重新發(fā)送的SYN報文。因此，盡管在這一方案中的新連接不會被重置，但卻帶來了較長時間的延時。[0004]另一個可行的現(xiàn)有解決方案是利用Linux的流量控制工具(tc)。先使用iptables來標記新流入的SYN報文，再用tc工具暫時緩存這些報文。在進程完成重載之后，再釋放這些SYN報文。相比于上一解決方案，這一方案所引起的延時相對較短。但是，由于tc工具只能控制流出的流量，因而使用場景受到了一定的限制。例如，在服務進程作為監(jiān)聽進程監(jiān)聽并接受客戶端連接時，由于此時SYN報文為流入流量，所述的使用tc工具的方案就無法被用于解決上述問題。[0005]因此，存在一種對能夠提供一種具有沒有延時、對傳出傳入的連接都有效且使用場景不受限制等優(yōu)點的重啟網(wǎng)絡服務的技術的需求?！?br/>發(fā)明內容】[0006]為了解決現(xiàn)有技術中的所述缺陷，本發(fā)明提供了一種新的無丟包零停機重啟網(wǎng)絡服務的方法和系統(tǒng)。相比于現(xiàn)有的其它方法，其具有無延時，對傳出傳入的連接都有效且使用場景不受限制等優(yōu)點。[0007]在本發(fā)明的一個方面，提供了一種重啟網(wǎng)絡服務的方法，所述方法包括:[0008]a)所述網(wǎng)絡服務的舊進程在一端口上進行監(jiān)聽；[0009]b)配置并啟動過渡進程，所述配置包括使得所述過渡進程在與舊進程不同的另一端口上進行監(jiān)聽；[0010]c)在連接跟蹤模塊運行的同時，添加iptables規(guī)則來將定向到所述一端口的連接重定向到所述另一端口，使得原本應連接到所述一端口上的后續(xù)連接被全部重定向到在所述另一端口上監(jiān)聽的所述過渡進程;d)—直等待直到所述舊進程上的已有連接全部處理完畢后，才退出所述舊進程；[0011]e)使用新的配置文件在所述一端口上啟動新進程；[0012]f)重新配置iptables規(guī)則以取消端口的重定向，這樣，原本應連接到所述一端口上的后續(xù)新連接不再被重定向，還是連向在所述一端口上監(jiān)聽的新進程；以及[0013]g)—直等待直到所述過渡進程上的已有連接全部處理完畢后，退出過渡進程。[0014]根據(jù)本發(fā)明的另一方面，提供了一種重啟網(wǎng)絡服務的系統(tǒng)，其特征在于，所述系統(tǒng)包括:[0015]服務端，所述服務端是提供各種網(wǎng)絡服務的web站點；[0016]客戶端，所述客戶端向所述服務器端提出重啟網(wǎng)絡服務的請求；[0017]網(wǎng)絡環(huán)境，通過所述網(wǎng)絡環(huán)境，所述服務端和所述客戶端可以進行數(shù)據(jù)通信；[0018]其中，所述服務端被配置為執(zhí)行下述步驟以實現(xiàn)網(wǎng)絡服務的重啟:[0019]a)所述網(wǎng)絡服務的舊進程在一端口上進行監(jiān)聽；[0020]b)配置并啟動過渡進程，所述配置包括使得所述過渡進程在與舊進程不同的另一端口上進行監(jiān)聽；[0021]c)在連接跟蹤模塊運行的同時，添加iptables規(guī)則來將定向到所述一端口的連接重定向到所述另一端口，使得原本應連接到所述一端口上的后續(xù)連接被全部重定向到在所述另一端口上監(jiān)聽的所述過渡進程;d)—直等待直到所述舊進程上的已有連接全部處理完畢后，才退出所述舊進程；[0022]e)使用新的配置文件在所述一端口上啟動新進程；[0023]f)重新配置iptables規(guī)則以取消端口的重定向，這樣，原本應連接到所述一端口上的后續(xù)新連接不再被重定向，還是連向在所述一端口上監(jiān)聽的新進程；以及[0024]g)—直等待直到所述過渡進程上的已有連接全部處理完畢后，退出過渡進程。[0025]提供本概述是為了以簡化的形式介紹將在以下詳細描述中進一步描述的一些概念。本概述不旨在標識出所要求保護的主題的關鍵特征或必要特征，也不旨在用于幫助確定所要求保護的主題的范圍?！靖綀D說明】[0026]為了描述可獲得本發(fā)明的上述和其它優(yōu)點和特征的方式，將通過參考附圖中示出的本發(fā)明的具體實施例來呈現(xiàn)以上簡要描述的本發(fā)明的更具體描述?？梢岳斫?，這些附圖只描繪了本發(fā)明的各典型實施例，并且因此不被認為是對其范圍的限制，將通過使用附圖并利用附加特征和細節(jié)來描述和解釋本發(fā)明，在附圖中:[0027]圖1示出了在其中可以實現(xiàn)根據(jù)本發(fā)明的實施例的示例環(huán)境。[0028]圖2示出了根據(jù)本發(fā)明的實施例的一種零停機重啟網(wǎng)絡服務的方法的流程圖?！揪唧w實施方式】[0029]下面結合附圖和實施例對本發(fā)明作進一步的描述。[0030]首先，描述下實現(xiàn)本發(fā)明的實施例的系統(tǒng)環(huán)境。在圖1中示出了實現(xiàn)根據(jù)本發(fā)明的實施例的示例環(huán)境100。在所述示例環(huán)境100中，包括網(wǎng)絡環(huán)境110進行通信的客戶端(客戶機)120和服務端(服務器)130?？蛻舳撕头掌魉幍木W(wǎng)絡環(huán)境可以是局域網(wǎng)、因特網(wǎng)或其它廣域網(wǎng)。所述服務端130可以是提供各種網(wǎng)絡服務的web站點，例如，HAProxy網(wǎng)絡服務，其中所述網(wǎng)絡服務必須重新啟動進程才能完成重啟或者重新載入配置文件。而所述客戶端120則通過因特網(wǎng)110來向服務端130請求網(wǎng)絡服務。[0031]在介紹完本發(fā)明的示例環(huán)境之后，現(xiàn)在就本發(fā)明的原理加以說明。[0032]首先，Netfilter是Linux內核中的一個與網(wǎng)絡功能相關的子系統(tǒng)。它作為一個通用的、抽象的框架，提供了數(shù)據(jù)包過濾、數(shù)據(jù)包修改、網(wǎng)絡地址轉換(NetworkAddressTranslat1n,NAT)等功能。[0033]連接跟蹤(conntrack)機制是Netfilter框架中的一個重要功能，也是包過濾、地址轉換的基礎。其基本功能是跟蹤并且記錄連接狀態(tài)。它作為一個獨立的模塊運行。采用連線跟蹤技術在協(xié)議棧低層截取數(shù)據(jù)包，將當前數(shù)據(jù)包及其狀態(tài)信息與歷史數(shù)據(jù)包及其狀態(tài)信息進行比較，從而得到當前數(shù)據(jù)包的控制信息，根據(jù)這些信息決定對網(wǎng)絡數(shù)據(jù)包的操作，達到保護網(wǎng)絡的目的。具體而言，Linux的Netfilter框架為每一個經過網(wǎng)絡棧的數(shù)據(jù)包，生成一個新的連接記錄項。此后，所有屬于此連接的數(shù)據(jù)包都被唯一地分配給這個連接，并標識連接的狀態(tài)。連接跟蹤是Netfi11er的狀態(tài)檢測的基礎，同時也是實現(xiàn)網(wǎng)絡地址轉換(NAT)功能的前提。[0034]當下層網(wǎng)絡接收到初始化連接同步(Synchronize，SYN)數(shù)據(jù)包后，該數(shù)據(jù)包將由netfilter規(guī)則庫進行檢查。該數(shù)據(jù)包將在規(guī)則鏈中依次序進行比較。如果該包應被丟棄，發(fā)送一個復位(Reset，RST)數(shù)據(jù)包到遠端主機，否則連接被接收。這次連接的信息將被保存在連線跟蹤信息表中，并表明該數(shù)據(jù)包所應有的狀態(tài)。這個連線跟蹤信息表位于內核模式下，其后的網(wǎng)絡數(shù)據(jù)包就將與此連線跟蹤信息表中的內容進行比較，根據(jù)信息表中的信息來決定該數(shù)據(jù)包的操作。因為數(shù)據(jù)包首先是與連線跟蹤信息表進行比較，只有SYN包才與規(guī)則庫進行比較，并且數(shù)據(jù)包與連線跟蹤信息表的比較都是在內核模式下進行的，所以處理速度很快。[0035]而本發(fā)明正是巧妙利用了Netfilter的連接跟蹤機制的所述特點:根據(jù)連接跟蹤機制的實現(xiàn)，相關規(guī)則只匹配每條連接的第一個報文，后續(xù)的報文則由連接跟蹤機制自動處理。從而，我們可以利用這一點，區(qū)分新連接和老連接，并將新連接全部引導給新進程，同時不影響與老進程上的舊連接。[0036]不過，許多線上機器出于性能方面的考慮，關閉了連接跟蹤機制。因此，本發(fā)明需要在網(wǎng)絡服務重載，進行進程切換時，臨時開啟連接跟蹤機制來實現(xiàn)所述方案。在下述圖2的詳細步驟中，假設服務器運行時關閉了連接跟蹤機制。[0037]現(xiàn)在參考圖2，在圖2中示出了根據(jù)本發(fā)明的實施例的一種零停機重啟網(wǎng)絡服務的方法200的流程圖。[0038]首先，在步驟210，假設網(wǎng)絡服務的舊進程在A端口監(jiān)聽。注意所述A端口僅僅是為了方便說明而起的端口名，并不是要將所述進程局限于某個特定端口。[0039]當網(wǎng)絡服務重載而需要進行進程切換時，在步驟220，配置并啟動過渡進程。修改網(wǎng)絡服務的配置文件，配置過渡進程在與舊進程不同的端口上監(jiān)聽，并啟動該過渡進程。此處假設過渡進程在B端口上監(jiān)聽。如上所述，所述B端口僅僅是為了方便說明不同于A端口的一個端口，并不是要將所述進程局限于某個特定端口。[0040]隨后，由于假設服務器運行時關閉了連接跟蹤機制以提高性能，因此當前第1頁1 2