我有一個運行 Centos7 的網路伺服器,它向其他資源發出curl 請求。以每秒 5-10 個請求的速率,一切正常,除了每 2-10 分鐘出現不同的捲曲錯誤。我認為,隨著時間的推移,隨著請求數量的增加,這種情況開始發生,這讓我認為這與網路有關,但我對此完全是新手。如何找出導致這些錯誤的原因以及我能採取什麼措施?
Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read
答案1
很可能,導致這些錯誤的原因通常可以歸類為「問題」......情況正常,一切都已結束。
互聯網是一個由互連的電腦和網路設備組成的龐大網路。那些你無法控制的其他機器並不總是做它們應該做的事情。他們遭受停電之苦。他們有硬體故障。他們受到宇宙輻射的攻擊。事情發生了。
支援互聯網的網路技術在設計時就考慮到了這一點。網路之所以能夠發揮作用,是因為有大量的冗餘。如果嘗試透過一條路由連接到目的地失敗......該鏈中有效的最後一個「躍點」將記住該失敗並嘗試不同的「下一躍」以進行將來的通訊。實際上比這複雜得多……但你明白了要點。
大多數 Web 應用程式都會重試失敗的連接,以充分利用這種冗餘。然而,並非全部。應用程式越簡單,失敗的可能性就越大。對於應用小型單一作業工具 *nix 原理的終端應用程式來說尤其如此。重試是另一個工具的工作。curl
就是這樣的一個應用程式。按照線上說明curl
頁:
- 重試
如果curl嘗試執行傳輸時返回暫時性錯誤,它會在放棄之前重試此次數。將數字設為 0 會使curl 不重試(這是預設的)。 瞬時錯誤意味著:逾時、FTP 4xx 回應代碼或 HTTP 408 或 5xx 回應代碼。
我不確定您用於curl
檢索資源的特定用例是什麼,但如果您使用curl 以自動方式提供資源,您肯定需要使用--retry
值為 3-5 的標誌來配置它。因為像您所顯示的錯誤是完全正常的......並且需要考慮。
2. 為什麼生產伺服器的可靠性比本地電腦的可靠性差?
在一個完美的世界裡與任何家庭或辦公室網路連線相比,生產伺服器始終能夠與基於網路的資源建立更可靠的連線。既然這裡的情況並非如此,那麼您對原因感興趣是正確的。然而,這並不一定意味著您應該擔心,因為這不一定是您的伺服器引起的問題。
請注意,您的本機電腦和伺服器幾乎肯定不會共享通往相關資源的相同路徑。例如。如果我traceroute
從本地家庭伺服器執行 a 說...superuser.com
我得到這個:
user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 rtr.scrapyard.local (10.5.0.1)
2 96.120.58.37 (96.120.58.37)
3 po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
4 162.151.221.209 (162.151.221.209)
5 be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
6 * * *
7 50.242.151.138 (50.242.151.138)
8 151.101.1.69 (151.101.1.69)
但是,如果我從一台生產伺服器執行相同的命令,我會得到以下結果:
user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
1 * * *
2 ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
3 ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
4 kanc-b1-link.telia.net (80.239.196.109)
5 dls-b22-link.telia.net (62.115.125.159)
6 fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
7 151.101.1.69 (151.101.1.69)
這兩條路由唯一的共同點是目的地。他們經過的每台其他機器都是不同的。因此,如果dls-b22-link.telia.net
行為不當,它會影響我的伺服器與 superuser.com 通訊的嘗試...但不會影響我的家用電腦嘗試執行相同的操作。
不幸的是,如果有曾是問題是dls-b22-link.telia.net
我無能為力。考慮到問題的間歇性,一開始就很難確定dls-b22-link.telia.net
問題的根源。
所以...
2b.這真的是個問題嗎?
您應該做的第一件事是確認這是否導致了實際問題,僅重試失敗的連線無法修復。這意味著您的生產伺服器在執行其工作時會以某種方式受到損害。我想當你設定這個目標時,你心裡已經有一個目標了。是否仍以不需要採取行動的方式實現該目標?這是關鍵問題。
回到我之前所說的,像這樣間歇性的問題只是網路的一部分。在一個完美的世界中,它們不會發生,但我們並不生活在一個完美的世界中……這就是為什麼冗餘是互聯網所基於的所有技術的基本原則。這就是為什麼在此類連線失敗後重試是標準操作程序。以及為什麼您不必過度擔心此類故障,除非它們會嚴重損害您的伺服器。
2c.它在你的掌控之下嗎?
您需要縮小問題的潛在根源。為此,只需執行您已經完成的相同測試(計算給定時間範圍內的失敗次數),但這次讓伺服器從完全不同的地方請求資源。我建議在您的家庭電腦上設定一個簡單的網頁伺服器,其中包含一些與您一直在使用的文件類似的文件,並curl
在伺服器上使用這些文件。
如果伺服器在執行此操作時沒有遇到任何故障,則問題不太可能出在您的伺服器或伺服器的託管提供者上。您現有的測試已經消除了本地網路和 ISP 以及資源本身託管的潛在問題來源。這使得節點位於您的託管提供者和資源託管提供者之間,並且完全屬於「您無法控制的事情」。
如果伺服器做如果在上述測試中遇到問題,因為您已經排除了本地網路/ISP 的問題,所以您幾乎可以確定問題出在您的伺服器或伺服器的託管提供者上。這意味著它是在您的控制之下進行修復的。這也意味著您有更多的故障排除工作要做。
2d.接下來是什麼?
如果問題不在於您的伺服器、伺服器的託管提供者或您正在查詢的資源......那麼原因本身不在您的控制之下。在這種情況下,最好的選擇是重新定位伺服器(聯絡您的主機供應商並查看他們可以為您提供哪些選項)。這希望這樣做的好處是,您將不再需要使用故障節點的路由。但這是相當嚴峻的考驗,不能保證有效。它甚至可能導致新的問題。因此,為什麼在採取這樣的步驟之前,這肯定需要成為一個嚴重的問題。
另一方面,如果您已將問題範圍縮小到您的伺服器或伺服器的託管供應商,那麼您可能可以解決它。如果您有託管協議,請致電您的託管提供者並讓他們修復它。如果您沒有託管協議,那麼您需要消除伺服器配置作為潛在的罪魁禍首。不幸的是,那是我下車的地方。我們已經達到了我的專業知識的極限。
一般來說,如果它是由伺服器引起的間歇性問題,則可能與網路緩衝有關或某種自動化的結果。一些有根據的猜測:
- 您是否採取了任何措施來強化您的伺服器以抵禦惡意探測和攻擊?
- 您是否弄亂了您的
/etc/sysctl.conf
文件或其中的文件/etc/sysctl.d/
? - 您是否設定過任何類型的狀態資料包檢查或入侵偵測軟體(基於 iptables/netfilter 的防火牆、snort 等)?
無論如何,如果您正在對伺服器本身進行故障排除,我的建議是利用您收集的資訊並提出一個新問題伺服器故障。那裡的人比超級用戶這裡的人在伺服器問題上有更多的經驗,並且更有可能知道下一步要嘗試什麼。
3.關於錯誤的表觀一致性
現在,為什麼你會一遍又一遍地遇到相同的特定錯誤?很難說。假設它真的像發條一樣每 5 分鐘發生一次……仍然可能是任何事情。這些設備內含時鐘和定時器,用途廣泛。可能是其中一個人每五分鐘做一次的事情導致了這個小小的問題。
有可能是你的伺服器有問題。或是您的託管提供者的問題。或者是您的託管提供者的 ISP 存在問題。或是您的家庭/辦公室 ISP 的問題。或介於兩者之間的任何地方。如果它不是您的伺服器,而且它可能不是基於您告訴我的內容,那麼最重要的是您對此無能為力......除非確保您已設定為重試失敗的連線。例如,所有現代網頁瀏覽器在放棄從網頁伺服器檢索資源之前都會重試幾次。
編輯
- 加入第二和第三部分以回應要求進一步澄清的評論
- 重寫了第二部分以進行更正。