FTP協議

      問題： 在生產環境中遇到的一個FTP問題：

       

1 ftp: connect: No route to ho2008-11-11 10:42
2 【討論】ftp: connect: No route to host
3 230 Login successful.
4 Remote system type is UNIX.
5 Using binary mode to transfer files.
6 ftp> ls
7 227 Entering Passive Mode (172,16,1,20,91,29)
8 ftp: connect: No route to host
9 ftp> 

      登陸的時候提示成功，但ls或者有數據傳輸的時候就報錯：No route to host,如何着手排查故障？

       暫且先把故障放一邊，從FTP的原理開始：

       FTP的工做原理和模型

        FTP的工做模型是雙鏈接的方式，即控制鏈接和數據鏈接。控制鏈接保持始終在線，數據鏈接按需建立。（爲何要用這種模型）

        其中控制鏈接採用server端21端口，數據鏈接根據傳輸模式的不一樣多是20或隨機端口。

       傳輸模式：主動與被動

       對於控制鏈接，都是由CLI去連server端的21端口。

       區別在於數據鏈接，主動與被動是以server端爲對象而言的，因此主動模式就是server端的20端口主動去連CLI端的隨機端口，CLI的隨機端口監聽；而被動模式就是反過來，

       server端的隨機端口被CLI端連，server端的隨機端口監聽被鏈接。

        FZ上被動模式是被推薦使用的，可能的緣由是主動模式有一個弊端，server端去連CLI端的隨機端口，若是CLI上有防火牆須要預先對隨機端口進行放行，並且CLI端

        還須要一個外部IP讓server端去鏈接。這對CLI端是很麻煩的一件事情，從設計原理上來說，應該把麻煩的事情讓server本身解決掉，因此推薦用被動模式。那被動模式，

       CLI端去連server端的20端口，server端一樣要放行一些隨機端口，server端如何知道開放哪些高位隨機端口呢？暫且不表。

        FTP鏈接的併發性：

         FTP是支持併發的，被動模式下端口的鏈接只是負責創建，若是所有由這個20端口來收發數據將會不堪重負。因此創建之後會生成子進程採用隨機端口來收發數據。

         FTP客戶端與服務端的鏈接也是基於TCP/IP的套接字，因此鏈接須要知道IP和端口才能創建端到端的鏈接。

          咱們來看一下Oracle數據庫的鏈接時怎麼作的。Oracle鏈接有兩種，專用服務器模式和共享服務器模式。專用服務器經過一個會話建立一個服務器進程來處理會話提交的SQL，

          這個弊端是很明顯的，若是有成千上萬個會話將會建立成千上萬個服務器進程，因此有另外一種共享服務器模式。其原理在於，經過調度程序把客戶端請求放入SGA的請求隊列，

          而服務器進程是共享，哪一個空了就接收請求並響應。

          Oracle的鏈接基於TCP/IP，經過客戶端的TNSNAME文件告訴客戶端要鏈接的主機名，監聽端口，服務名等來創建端到端的鏈接。

          FTP客戶端與服務端的鏈接，好比FTP 176.128.7.1，有IP，server端的隨機端口監聽會發送給客戶端來創建數據鏈接，這樣就打開了一個到服務端的套接字鏈接。  而解決鏈接

         併發的問題，也是經過建立多個子進程來實現的。這個和Oracle的專用服務器模式相似。在FZ客戶端上併發鏈接的設置是1-10，仍是可控的。

           Oracle的鏈接要更爲複雜些，有專門的監聽器用來創建鏈接，監聽器用本身的配置文件檢查這個鏈接請求，若是須要則fork（）一個服務器進程來創建客戶端到服務器的鏈接。

           或者監聽程序將鏈接轉給調度程序，由調度進程來把請求放到SGA隊列中。

           

         FTP文件傳輸格式：

        支持二進制和ASCII，二進制文件不能經過文本文件傳輸，不然傳到對端後會被破壞。

          問題的解決：

          再回來看前面的問題，能夠看到控制鏈接已經創建，對端是unix系統，默認使用二進制傳輸，默認使用被動模式。

          由前面的原理咱們能夠知道，被動模式的數據鏈接也是由客戶端發起的隨機端口到服務端的隨機端口的鏈接，若是鏈接有問題，有多是防火牆沒有開放高位隨機端口。

           後來這個緣由被排除了。那會是什麼緣由呢？FTP客戶端到服務端的TCP/IP鏈接仍是比較簡單的，只要IP,端口應該就能創建鏈接啊。

            這裏牽扯到另外一個問題，客戶端去連公網的服務端的時候，實際上連的是服務端的公網地址，而要作數據傳輸須要作NAT，因此被動模式須要安裝ip_nat_ftp，ip_conntrack

            幾個模塊，這幾個模塊沒有編譯進內核，須要使用modprobe 載入。

            ip_conntrack不清楚具體功能是什麼，有多是對被動模式服務端須要開放的高位隨機端口作跟蹤的。

 

           擴展：

           1.因而可知，一個故障的解決，是綜合性知識的體現，最終歸結爲網絡問題，解決方法是內核模塊的加載。

            2.對於一個知識點，能夠從不一樣的角度去理解，但整體上能夠區分爲設計者的角度和使用者的角度。

                好比FTP協議，知道主動和被動模式原理，能夠幫助分析爲何數據鏈接創建不了的緣由。這是幫助解決平常使用上的問題。

                咱們去弄明白FTP鏈接的併發性原理，並不能直接的去解決平常的使用問題，一般咱們只在客戶端設置1-10個併發便可，不須要知道原理。但爲何咱們要去弄懂原理？

                 我想這是從設計者的角度去思考問題了，即設計者是如何解決鏈接的併發性問題的？從和Oracle鏈接的原理比較來看，有些思路是共通的，即經過多進程的方式來解決併發鏈接

                 的問題，同時從原理咱們也知道了FTP的鏈接1-10管理上不會有問題，可是若是是數據庫，會話有成千上萬的就要引發更加複雜的鏈接管理機制了，好比監聽器，共享服務進程，請求

                 隊列等等。設計者角度思考問題，會提高咱們思考問題的高度，並且有些原理在不一樣的場合上是思路相近的，能夠互相借鑑。