一千萬個為什麽

搜索

網絡內部的反向代理和TCP優化



Need to make some optimizations and have been reading articles such as linux-tcp-tuning

在負載均衡器和反向代理的世界中,調整網絡內部的TCP連接是否有任何價值? 據我所知(如果我錯了請糾正我),負載均衡器和服務器之間幾乎沒有延遲,也沒有數據包丟失。

所以我想知道如果沒有在負載均衡器上設置,更改net.ipv4.tcp_window_scaling,net.ipv4.tcp_timestamps,net.ipv4.tcp_sack等參數會有什麽影響。 謝謝!

修改</強>

其他參數改進了我的服務器模擬。我設置net.ipv4.tcp_fin_timeout = 5,net.ipv4.tcp_keepalive_probes = 5並且它為更多客戶端服務(沒有負載均衡器)。我只是不知道它是否會與負載均衡器產生相同的效果。/proc/sys/net/ipv4 /下有很多TCP參數。在單個服務器上測試它們是一回事。使用負載均衡器和許多服務器測試它們是一項巨大的工作。我只是不知道是否值得嘗試使用許多服務器和負載均衡器測試這些參數。

轉載註明原文: 網絡內部的反向代理和TCP優化

一共有 1 個回答:

調整已識別的參數肯定會產生影響 - 降低性能。例如,net.ipv4.tcp_window_scaling是開啟或關閉選項</一>。同樣,net.ipv4.tcp_sack可以打開或關閉。兩者在Linux和所有負載均衡器上都默認為on值。這兩個都在RFC1323中定義,RFC1323是為了使我們能夠實現10/100以太網網絡而發布的。如果沒有這個RFC,網絡每秒限制在10 Mbps,因此禁用這些將導致巨大,即時和顯著的性能損失。

這些性能優勢是因為“幾乎”零延遲和零延遲之間存在巨大差異。使用滑動TCP窗口允許設備使用選擇性確認(SACK)來同時確認收到數百個數據包。因此,如果網絡上的延遲為10毫秒,沒有SACK,則必須確認每個數據包,並且即使在理論最小延遲時間內,10毫秒延遲也會非常快速地增加。這意味著我發送數據包A,然後在發送數據包B之前必須等待對數據包A的響應。但事實證明,我可以發送剩余的字母表,然後在等待ACK到數據包B時發送一些。輸入SACK - 這些允許接收器發信號通知它已成功接收並包括Z包。同時,發送方已經發送了包AA-ZZ。

這導致稱為“TCP窗口大小”的東西,它是客戶端可以緩沖/處理的最大數據量。由於內存可能是一個問題,如果收件人只能存儲和處理數據包A-F,如果我們發送A-Z,一些數據將會丟失。因此,接收者必須發出接收數據的信號 - 即“我只能緩沖這麽多數據包”。這實際上取決於接收者清空緩沖區並將數據傳輸到第7層的速度。通常會看到TCP窗口從空縮放到滿(最大窗口大小從0開始,表示窗口完全用於最大值,表示窗口完全可用),這是在網絡上識別吞吐量瓶頸的一種方法。

TCP窗口擴展提供兩個主要好處:

  1. 電線上沒有閑置的時間 - 我們沒有坐在那裏等待確認,我們已經成功擊敗了道具。延遲(延遲)。
  2. 減少擁塞控制的時間=更多的數據時間。擁塞控制消息可能會影響您的傳輸時間和帶寬。即使使用TCP窗口縮放,仍然可能會出現
  3. Congestive Collapse ,其中整個TCP窗口可能會出現需要重新傳輸並且可能需要擁塞控制。

最後,更新net.ipv4.tcp_timestamps的唯一真正原因是提供額外的安全性,因為它基於服務器正常運行時間。由於您在負載均衡器後面代理,因此調整此設置幾乎沒有價值,除非您使用類似

Performance Layer 4個人資料。我懷疑調整這會產生很大的不同,盡管它只會降低,但不會提高性能。

遠遠地,更有可能幫助的是調整發送和接收緩沖區大小並使用 Jumbo Frames。這將允許您處理具有相同開銷量的更多數據(處理比標準MTU 1500減少75%。這些是達到10 Gbps連接所需的主要更改。否則,請確保您有足夠的CPU從TCP堆棧中提取數據並了解您的traff模式(例如,避免像 C10K問題)。

修改</強>

tcp_fin_timeout doesn't actually improve performance, instead it defeats resource constraints. This setting could actually be a major player in a load balancer implementation. The problem is that for any given client and server, the server will be hosting a web server (for example) on 192.168.1.5:80. Every TCP connection must have both a source IP and source port as well as a destination port and destination IP. Source ports are chosen by the client from a pool of "ephemeral" ports. This results in a theoretical maximum of 65534 connections (the maximum number of ports) between a given client to port 80 on that server. When using load balancers, this can result in "port exhaustion" when the pool of ephemeral ports is depleted when SNAT (Secure Network Address Translation) is used on the load balancer, which results in a theoretical maximum of 65534 between the load balancer and the server. There are two basic solutions to this problem: 1) use a SNAT pool where 2 source IPs for the load balancer * 65534 = 131068 connections and 4 IPs X 65534 = 262136 max connections, and so forth or 2) don't use a SNAT. For this to work, the load balancer needs to be part of the default route back to your clients. If you are testing with a single actual client simulating multiple clients, this is a poor real-world test and you may actually support many more clients than you think because you are exhausting your ephemeral ports, where real clients would never do that because they come from unique IPs and two clients can use the same ephemeral port if you are not using SNAT on the load balancer.

現在,我一直提到這是理論上的最大值但實際情況是,在Linux服務器上,有一個定義範圍的短暫端口,所以通常你會看到端口耗盡大約是理論最大值的一半。您可以通過調整/ proc/sys/net/ipv4/ip_local_port_range中的臨時端口範圍來查看類似於調整 tcp_fin_timeout 的結果。

這讓我想到了最後一篇, TIME_WAIT 狀態由 tcp_fin_timeout 控制,默認為60秒。這使得每個端口在返回到臨時端口池之前使用了60秒的“冷卻期”。這就是您在測試中看到性能提升的原因。此設置假設是TCP協議定義的最大段壽命的2倍,因為理論上可能對於此設置低於1 X的FIN數據包最大段壽命(30秒)仍然在途中。實際上,這是不太可能的,但從技術上講,您通過調整此設置來破壞RFC合規性。但是,如果向下調整此設置,則需要確保在 Load Balancer's上向下調整此設置。 TCP配置文件(因此tcp_fin_timeout對應於時間等待,而不是F5上的FIN等待)。

最終,這是一個很好的例子,使用負載均衡器和許多服務器進行測試會導致巨大的性能差異 - 因為您的測試可能並不反映真實世界的架構。這不是對客戶體驗的良好模擬。

但是,調整短暫的端口設置和使用Keepalive是兩種不同的流量管理策略。事實上,如果您使用 OneConnect 等設置,則根本不再需要調整短暫的端口範圍和超時,因為連接被循環使用,多個客戶端可以在同一個連接上流動(註意,這僅適用於HTTP流量,但是如果你想要的話,用 tcp_keepalive_probes 可以實現類似的功能這樣配置,因為客戶端不再需要等待三次握手 - 他們可以簡單地開始傳輸。)

結論

這裏沒有輕拍的答案。你在問“這項工作值得做嗎?” - 我不知道。是嗎?什麽是可接受的商業風險水平?如果你弄錯了瓶頸,你的業務成本是多少?

最終,我覺得你基本上要問兩件事1)所有這些設置做了什麽以及調整它們的效果是什麽? 2)我可以采取任何捷徑嗎?

不幸的是,你沒有提供足夠的信息來回答這兩個問題(這就是為什麽你的最後一個問題被關閉了,而這個問題將會被投票。)首先,我沒有時間解釋proc中的每個TCP設置(也沒有)我知道我的頭腦,我實際上是在谷歌上搜索這些。)但其次(更重要的是)如果不知道你的服務是如何構建的,就不可能確定它們的效果。可能會從系統中擠出性能,但內核TCP參數幾乎可以調整到可以在不破壞TCP/IP RFC的情況下安全地進行的最佳配置。您正在做的是進入可以安全的領域,但前提是您了解架構和TCP/IP協議。你應該學習它。如果你想成為房間裏最聰明的人,學習TCP/IP。拿起 TCP/IP Illustrated 和/或使用TCP/IP進行網絡互連並將基礎知識提交給內存。了解HTTP請求和SSL握手的工作方式。學習如何閱讀wireshark中的pcap,並根據這些協議講述正在發生的事情的故事。無論您是進入系統管理,網絡還是編程,我都會在生活中走得很遠(我在所有這三個領域都使用過這方面的知識)。簡單地說,沒有什麽可以替代你知道你到底在做什麽,這不是你將能夠從Stack Exchange回答的東西。這就是你支付顧問的原因 - 因為如果他們很好,他們就會知道這個問題的來龍去脈。一旦你理解了1)你的架構和2)設置實際做了什麽以及它們會產生什麽影響你最好能夠判斷你是否可以采取任何捷徑(也就是說,我不需要調整這個設置;它是這種測試毫無價值,因為它不能模擬客戶體驗。