為什麼 FTP 被動模式需要一個埠範圍而不是一個埠？
我很難理解為什麼所有 FTP 伺服器都需要為被動模式數據通道使用一個埠範圍，而不是只為所有傳入數據通道連接使用一個數據埠。
FTP 伺服器在埠 21 上處理許多同時連接的客戶端。Web 伺服器在埠 80 上處理許多同時連接的客戶端。等等。
那麼為什麼 FTP 伺服器不能對所有傳入的被動數據連接只使用一個數據通道埠（並且仍然能夠處理該埠上的許多同時連接的客戶端，比如埠 1024）？
或者可以嗎？
我有興趣了解為什麼這是不可能或不推薦的技術細節。
關於將數據埠鎖定到僅一個埠時的多個並發 FTP 會話問題的清晰技術解釋是我最感興趣的深入了解。什麼時候能用，什麼時候不能用，為什麼不推薦等等。
這將是一個瘋狂的猜測，因為我還沒有測試過，你應該自己嘗試一下，看看是否還有其他我可能遺漏的問題。
我想您可以將被動埠範圍限制為一個埠。事實上，您可以在這個問題中看到在實踐中使用了小埠範圍。理論上，要支持多個並發連接，您只需要 4 個值：本地 IP、本地埠、遠端 IP、遠端埠是唯一的。這就是您辨別不同連接的方式。
如果您將伺服器上的埠鎖定為一個值，那麼剩下的唯一變數就是客戶端使用的埠。這不是問題，只要客戶端有足夠大的免費臨時埠池可供選擇。除非它正在執行一些繁重的 NAT，否則您不必擔心這一點。現在，請注意，這純粹是理論上的東西：如果您在伺服器上使用了多個埠，您可以通過啟用來增加假設的並發連接數
number of ports in range每個埠客戶端的連接數。但它在實踐中不會發生，因為我懷疑是否有任何支持這一點的 FTP 客戶端實現（因為它沒有多大意義）。另外，如果客戶必須以這種方式共享他的臨時埠並且不能只打開一個新埠，那麼他需要處理的問題要嚴重得多。因此，從這個角度來看，使用單個埠應該是完全安全的。讓我們想想為什麼單個埠可能不夠用。
首先，我可能會想到一個非常有問題的 FTP 伺服器實現僅使用本地埠號作為辨識客戶端數據傳輸的方式的情況。再一次，我認為任何體面的 FTPd 都不會這樣做。
真正的問題（是的，您可以將以上所有內容視為主要題外話;-)）是被動埠範圍在非特權範圍內。
這意味著您選擇的埠號本身不是保留 的，實際上任何使用者程序（不需要root權限）都可以在您的 FTP 伺服器之前獲取它。如果您有大量埠可供選擇，您只需隨機選擇一個免費埠即可。如果您一定要使用唯一的一個並且它已經被使用過，您將無法正確處理轉移。
對不起，如果答案似乎有點過於投機。老實說，我努力尋找不應該使用單個埠的原因，除了最後一點，我想不出任何反對它的確鑿證據。然而，您提出了一個有趣且具有挑戰性的問題。