置任務

在通過FTP進行文件操作之前，需完成以下任務：

• 終端與設備之間路由可達。
• 終端支持FTP客戶端軟件。

配置流程

須知：使用FTP協議存在安全風險，建議使用SFTP V2、SCP或FTPS方式進行文件操作。

通過FTP進行文件操作的配置流程如表1所示。

表1 通過FTP進行文件操作的配置流程

缺省配置

表2 缺省配置

操作步驟

配置FTP服務器功能及參數

表3 配置FTP服務器功能及參數

如果變更端口號前FTP服務已經啟動，則不能變更成功。需執行undo ftp [ ipv6 ] server命令關閉FTP服務，再進行端口號變更。

當客戶端與設備之間的文件操作結束后，請執行undo ftp [ ipv6 ] server命令，及時關閉FTP服務器功能，從而保證設備的安全。

配置FTP本地用戶

當用戶通過FTP進行文件操作時，需要在作為FTP服務器的設備上配置本地用戶名及口令、指定用戶的服務類型以及可以訪問的目錄，否則用戶將無法通過FTP訪問設備。

表4 配置FTP本地用戶

（可選）配置FTP訪問控制

ACL是一系列有順序的規則組的集合，這些規則根據數據包的源地址、目的地址、端口號等來描述。ACL通過規則對數據包進行分類，這些規則應用到路由設備，路由設備根據這些規則判斷哪些數據包可以接收，哪些數據包需要拒絕。

用戶可以配置FTP訪問控制列表，實現只允許指定的客戶端登錄到設備，以提高安全性。

ACL規則：

• 當ACL的rule配置為permit時，則允許匹配該rule規則的其他設備與本設備建立FTP連接。
• 當ACL的rule配置為deny時，則拒絕匹配該rule規則的其他設備與本設備建立FTP連接。
• 當ACL配置了rule，但來自其他設備的報文沒有匹配該rule規則時，則拒絕其他設備與本設備建立FTP連接。
• 當ACL未配置rule時，則允許任何其他設備與本設備建立FTP連接。

表5 （可選）配置FTP訪問控制

用戶通過FTP訪問設備

從終端通過FTP訪問設備，可以選擇使用Windows命令行提示符或第三方軟件。此處以Windows命令行提示符為例進行配置。

• 執行Windows命令ftp ip-address，通過FTP方式訪問設備。
• 此處輸入的IP地址為設備上配置的IP地址，且與用戶終端IP地址路由可達。
• 根據提示輸入用戶名和口令，按Enter鍵，當出現FTP客戶端視圖的命令行提示符，如ftp>，此時用戶進入了FTP服務器的工作目錄。（以下顯示信息僅為示意）

C:\Documents and Settings\Administrator> ftp 192.168.150.208
連接到 192.168.150.208。
220 FTP service ready.
用戶(192.168.150.208:(none)):huawei
331 Password required for huawei.
密碼:
230 User logged in.
ftp>

通過FTP命令進行文件操作

用戶訪問FTP服務器后，可以通過FTP命令進行文件操作，包括目錄操作、文件操作、配置文件傳輸方式、查看FTP命令在線幫助等。

說明：用戶的操作權限受限于服務器上對該用戶的權限設置。由于文件系統對根目錄下的文件個數有限制，當根目錄中文件個數大于50個時，繼續在根目錄中創建文件可能會失敗。

以下各操作沒有嚴格順序，可根據需求選擇一種或多種操作項目。

表6 通過FTP命令進行文件操作

（可選）更改登錄用戶

設備可以在不退出FTP客戶端視圖的情況下，以其他的用戶名登錄到FTP服務器。所建立的FTP連接，與執行ftp命令建立的FTP連接完全相同。

斷開與FTP服務器的連接

用戶可以在FTP客戶端視圖中選擇不同的命令斷開與FTP服務器的連接。

檢查配置結果

• 使用display [ ipv6 ] ftp-server命令，查看FTP服務器的配置和狀態信息。
• 使用display ftp-users命令，查看登錄的FTP用戶信息。

本次是2020年在生產環境遇到的問題手稿記錄，解決的問題是 ftp 操作導致大量的【TIME_WAIT】，現整理發出，希望幫助到有需要的人。

一、問題描述

這個問題是在生產環境出現的，由于測試環境數據量小，程序很快運行完成，ftp 連接能被快速釋放，所以一直沒出現這個問題。

運維反饋，在 ftp 服務器監控到大量的連接【TIME_WAIT】，經查是一些 .net 程序導致的，如下前面三個都是部署了 .net 程序的服務器：

后面的是部署在 docker 容器中的 java 程序，數據還比較正常。

這些程序用的工具類可能是同一個（或者大同小異），所以批量出現了。

二、問題分析與解決

由于測試環境沒有重現這個問題，那么要解決這個問題需要在測試環境重現一下，好對癥下藥。

程序偽代碼邏輯主要如下：

void Start()
{
    foreach (int item in list)
    {
       ...

       DownloadFile(...,path);

       ...

       UploadPdf(...);
    }
}

byte[] DownloadFile(...,string path)
{
    var ftpUtil=new FtpUtil("10.10.60.16", "ftp", "123");
    return ftpUtil.DownloadFile(...,path);
}

int UploadPdf(...,byte[] buffer)
{
    var ftpUtil=new FtpUtil("10.10.60.16", "ftp", "123");
    ftpUtil.UploadFile(..., buffer);
}

由上可看出代碼是有缺陷的，首先一點，由于 ftp 對象初始化都是一樣的，沒必要每處理一次就 new 一個 FtpUtil 對象實例，這意味著每次都會建立一個新的FTP連接，這樣做可能會導致連接池溢出或者頻繁地創建和關閉連接，影響性能并增加TIME_WAIT連接的數量。

第一個優化點：將FtpUtil實例創建移到循環外部，以便在整個循環過程中重用同一個實例，從而減少連接建立和關閉的次數。

程序涉及到 ftp 操作是先下載文件，然后上傳文件，問題應該是出現在 ftp 工具類中實現下載和上傳的兩個方法中。

編寫了一個單元測試項目用來重現此問題，就是模擬取一定量的訂單實現上面的下載和上傳邏輯，當只實現下載的時候問題沒出現，加了上傳邏輯才出現問題，說明上次方法有問題。

基本信息：

• 本機客戶端 ip：10.138.30.229
• ftp ip ：10.138.60.16
• ftp 端口：21

上傳過程中發現：

本次設置了100次，運行完成后統計發現產生了100次 連接：

當程序關閉后一兩分鐘后終于被釋放（公共的 ftp 服務器其它程序也會用）：

問題終于復現了。

這到底啥原因呢？

要了解原因，首先要了解 TIME_WAIT 是什么意思？

TIME_WAIT 表示的是客戶端在操作 ftp 后進入的等待狀態。

那為什么會出現大量的 TIME_WAIT 呢？

經查代碼發現 FtpWebRequest 類有個屬性【KeepAlive】，指定在請求完成之后是否關閉到 FTP 服務器的控制連接，源碼解釋如下：

    //
    // 摘要:
    //     獲取或設置一個 System.Boolean 值，該值指定在請求完成之后是否關閉到 FTP 服務器的控制連接。
    //
    // 返回結果:
    //     如果不應銷毀到服務器的連接，則為 true；否則為 false。默認值為 true。
    //
    // 異常:
    //   T:System.InvalidOperationException:
    //     對于一個已在進行的請求為此屬性指定了一個新值。
    public bool KeepAlive { get; set; }

默認是 true，但是在上傳方法中設置的是 false，則表示客戶端在請求完成之后要關閉 FTP 服務器的控制連接，但是由于服務端是在收到客戶端發送關閉連接命令之后才會去主動關閉連接，由于有大批量的請求，所以造成服務器上比較容易出現大量的 TIME_WAIT 狀態的連接，特別是并發量較大時更易出現。

如果不設置這個屬性，那么默認是 true，整個程序生命周期中只有一個連接，請求完成之后不會關閉，一直會處于 ESTABLISHED 狀態，直到程序結束才會被釋放，如：