ファイル転送プロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ファイル転送プロトコル
通信プロトコル
目的ファイル転送
開発者RFC959のAbhayBhushan
序章1971年4月16日; 50年前 (1971-04-16)
OSI層アプリケーション層
ポート制御用に21、データ転送用に20
RFC(s)RFC 959

ファイル転送プロトコルFTP )は、サーバーからコンピューターネットワーク上のクライアントへのコンピューターファイル転送に使用される標準の通信プロトコルです。FTPは、クライアントとサーバー間の個別の制御およびデータ接続を使用して、クライアントサーバーモデルアーキテクチャ上に構築されています。[2] FTPユーザーは、通常はユーザー名とパスワードの形式で、クリアテキストのサインインプロトコルを使用して自分自身を認証できますが、サーバーがそれを許可するように構成されている場合は匿名で接続できます。ユーザー名とパスワードを保護し、コンテンツを暗号化する安全な送信のために、FTPは多くの場合次のように保護されますSSL / TLSFTPS )またはSSHファイル転送プロトコル(SFTP) に置き換えられました。

最初のFTPクライアントアプリケーションは、オペレーティングシステムグラフィカルユーザーインターフェイスが搭載される前に開発されたコマンドラインプログラムであり、現在でもほとんどのWindowsUnix、およびLinuxオペレーティングシステムに付属しています。[3] [4]それ以来、多くのFTPクライアントと自動化ユーティリティがデスクトップ、サーバー、モバイルデバイス、ハードウェア向けに開発され、FTPはHTMLエディターなどの生産性アプリケーションに組み込まれています

2021年1月、FTPプロトコルのサポートはGoogle Chrome 88 [5]で無効になり、Firefox88.0で無効になりました。[6] 2021年7月、Firefox 90はFTPを完全に削除し[7]、Googleは2021年10月に追随し、Google Chrome95でFTPを完全に削除しました。[8]

FTPサーバーの履歴

ファイル転送プロトコルの元の仕様は、Abhay Bhushanによって作成され、1971年4月16日にRFC  114として公開されました。1980年まで、FTPはTCP / IPの前身であるNCPで実行されていました。[3]プロトコルは後に、TCP / IPバージョン、RFC 765(1980年6月)およびRFC 959(1985年10月)、現在の仕様に置き換えられました。いくつかの提案された標準はRFC959を修正ます。たとえば、RFC 1579(1994年2月)はファイアウォールに優しいFTP(パッシブモード)を有効にし、RFC 2228(1997年6月)はセキュリティ拡張、RFCを提案します      2428(1998年9月)は、IPv6のサポートを追加し、新しいタイプのパッシブモードを定義します。[9]

プロトコルの概要

通信とデータ転送

ポート21を使用してパッシブ接続を開始する図

FTPは、データ接続の確立方法を決定するアクティブモードまたはパッシブモードで実行できます。[10](この「モード」の意味は、FTPプロトコルのMODEコマンドの意味とは異なり、代わりにPORT / PASV / EPSV / etcコマンドに対応します。)どちらの場合も、クライアントはからTCP制御接続を作成します。FTPサーバーコマンドポート21 へランダムな(通常は非特権の)ポートN。

  • アクティブモードでは、クライアントはポートMでサーバーからの着信データ接続のリッスンを開始します。クライアントはFTPコマンドPORT Mを送信して、リッスンしているポートをサーバーに通知します。次に、サーバーは、FTPサーバーのデータポートであるポート20からクライアントへのデータチャネルを開始します。
  • クライアントがファイアウォールの背後にあり、着信TCP接続を受け入れることができない状況では、パッシブモードが使用される場合があります。このモードでは、クライアントは制御接続を使用してPASVコマンドをサーバーに送信し、サーバーからサーバーIPアドレスとサーバーポート番号を受信します[10]。次に、クライアントはこれを使用して任意のクライアントからデータ接続を開きます。受信したサーバーIPアドレスとサーバーポート番号へのポート。[11]

両方のモードは、IPv6をサポートするために1998年9月に更新されました。当時、パッシブモードにさらに変更が加えられ、拡張パッシブモードに更新されました。[12]

サーバーは、制御接続を介して、オプションのテキストメッセージを含むASCIIの3桁のステータスコードで応答します。たとえば、「200」(または「200 OK」)は、最後のコマンドが成功したことを意味します。数字は応答のコードを表し、オプションのテキストは人間が読める説明または要求を表します(例:<ファイルを保存するためのアカウントが必要>)。[2]データ接続を介したファイルデータの進行中の転送は、制御接続を介して送信される割り込みメッセージを使用して中止できます。

FTPは、元々ネットワーク制御プログラム(NCP)で動作するように設計されていたため、2つのポート(送信用と受信用)が必要です。これは、双方向通信用に2つのポートアドレスを使用して2つの接続を確立するシンプレックスプロトコルでした。奇数ポートと偶数ポートは、アプリケーション層のアプリケーションまたはプロトコルごとに予約されています。TCPとUDPの標準化により、アプリケーションごとに2つのシンプレックスポートを使用する必要性が1つのデュプレックスポートに削減されました[13] :15 が、FTPプロトコルは1つのポートのみを使用するように変更されることはなく、下位互換性のために2つを使用し続けました。 。

NATおよびファイアウォールトラバーサル

FTPは通常、クライアントからPORTコマンドが送信された後、サーバーをクライアントに接続してデータを転送します。これは、インターネットから内部ホストへの接続を許可しないNATとファイアウォールの両方で問題があります。 [14] NATの場合、さらに複雑なのは、PORTコマンドでのIPアドレスとポート番号の表現が、NATのパブリックIPアドレスとポートではなく、内部ホストのIPアドレスとポートを参照することです。

この問題を解決するには2つのアプローチがあります。1つは、FTPクライアントとFTPサーバーがPASVコマンドを使用することです。これにより、FTPクライアントからサーバーへのデータ接続が確立されます。[14]これは最近のFTPクライアントで広く使用されています。別のアプローチは、この目的のためにアプリケーションレベルゲートウェイを使用して、NATがPORTコマンドの値を変更することです。[14]

データ型

ネットワークを介してデータを転送する際、次の4つのデータタイプが定義されます。[3] [4] [9]

  • ASCII(TYPE A):テキストに使用されます。データは、必要に応じて、送信前に送信側ホストの文字表現から「8ビットASCII」に変換され、 (必要に応じて)受信側ホストの文字表現に変換されます。結果として、このモードはプレーンテキスト以外のデータを含むファイルには不適切です。
  • 画像(タイプI、一般にバイナリモードと呼ばれます):送信側のマシンは各ファイルをバイト単位で送信し、受信者は受信時にバイトストリームを保存します。(FTPのすべての実装でイメージモードのサポートが推奨されています)。
  • EBCDIC(TYPE E):EBCDIC文字セットを使用するホスト間のプレーンテキストに使用されます。
  • ローカル(TYPE L n ): DEC PDP-10などの36ビットシステムなど、8ビットバイトを使用しないマシン間のファイル転送をサポートするように設計されていますたとえば、「TYPE L 9」は、9ビットバイトでデータを転送するために使用され、「TYPE L 36」は、36ビットワードを転送するために使用されます。最新のFTPクライアント/サーバーのほとんどは、Iと同等のL8のみをサポートしています。

期限切れのインターネットドラフトは、 UTF-8を使用してUnicodeテキストファイルを転送するためのTYPEUを定義しました[15]ドラフトがRFCになることはありませんでしたが、いくつかのFTPクライアント/サーバーによって実装されました。

これらのデータ型は一般に「モード」と呼ばれますが、あいまいなことに、この単語はアクティブ対パッシブ通信モード(上記を参照)およびFTPプロトコルMODEコマンドによって設定されるモード(以下を参照)を指すためにも使用されます。

テキストファイル(タイプAおよびタイプE)の場合、ファイルの印刷方法を制御するために、3つの異なるフォーマット制御オプションが提供されています。

  • 非印刷(TYPEANおよびTYPEEN)–ファイルにはプリンター用のキャリッジ制御文字が含まれていません
  • Telnet(TYPEATおよびTYPEET)–ファイルにはTelnet(つまり、ASCII C0)キャリッジ制御文字(CR、LFなど)が含まれています
  • ASA(TYPEAAおよびTYPEEA)–ファイルにはASAキャリッジ制御文字が含まれています

これらのフォーマットは主にラインプリンターに関連していました。最新のFTPクライアント/サーバーのほとんどは、デフォルトのフォーマット制御であるNのみをサポートしています。

ファイル構造

ファイル編成は、STRUコマンドを使用して指定します。次のファイル構造は、RFC959のセクション3.1.1で定義されています。

  • FまたはFILE構造(ストリーム指向)。ファイルは、バイト、文字、または単語の任意のシーケンスとして表示されます。これは、UnixシステムおよびCP / M、MS-DOS、MicrosoftWindowsなどの他のシステムでの通常のファイル構造です。(セクション3.1.1.1)
  • RまたはRECORD構造(レコード指向)。ファイルは、固定長または可変長のレコードに分割されて表示されます。このファイル編成は、レコード指向のファイルシステムをサポートするMVS、VM / CMS、OS / 400、VMSなどのメインフレームおよびミッドレンジシステムで一般的です
  • PまたはPAGE構造(ページ指向)。ファイルはページに分割され、データまたはメタデータのいずれかが含まれる場合があります。各ページには、さまざまな属性を与えるヘッダーが含まれる場合もあります。このファイル構造は、 TENEXシステム用に特別に設計されたものであり、通常、他のプラットフォームではサポートされていません。RFC1123セクション4.1.2.3では、この構造を実装しないことを推奨しています。

最新のFTPクライアントおよびサーバーのほとんどはSTRUFのみをサポートしています。STRURは、メインフレームおよびミニコンピューターのファイル転送アプリケーションで引き続き使用されています。

データ転送モード

データ転送は、次の3つのモードのいずれかで実行できます。[2] [3]

  • ストリームモード(モードS):データは連続ストリームとして送信され、FTPによる処理が不要になります。むしろ、すべての処理はTCPに任されていますデータがレコードに分割されていない限り、ファイルの終わりインジケータは必要ありません
  • ブロックモード(モードB):主にレコード指向ファイル(STRU R)の転送用に設計されていますが、ストリーム指向(STRU F)テキストファイルの転送にも使用できます。FTPは、データの各レコード(または行)をいくつかのブロック(ブロックヘッダー、バイトカウント、およびデータフィールド)に配置してから、TCPに渡します。[9]
  • 圧縮モード(モードC):ランレングスエンコーディングを使用したデータ圧縮でモードBを拡張します。

最新のFTPクライアントおよびサーバーのほとんどは、モードBまたはモードCを実装していません。メインフレームおよびミニコンピューターオペレーティングシステム用のFTPクライアントおよびサーバーはその例外です。

一部のFTPソフトウェアは、DEFLATEベースの圧縮モードも実装しています。これは、それを有効にするコマンドの後に「モードZ」と呼ばれることもあります。このモードはインターネットドラフトで説明されていますが、標準化されていません。[16]

GridFTPは、追加のモード、MODE E [17]およびMODEX、[18]をMODEBの拡張として 定義します。

追加コマンド

FTPの最近の実装では、Modify Fact:Modification Time(MFMT)コマンドがサポートされています。これにより、クライアントはそのファイル属性をリモートで調整でき、ファイルのアップロード時にその属性を保持できます。[19] [20]

リモートファイルのタイムスタンプを取得するには、MDTMコマンドがあります。一部のサーバー(およびクライアント)は、MFMTと同じように機能する2つの引数を持つMDTMコマンドの非標準構文をサポートしています[21]。

ログイン

FTPログインは、アクセスを許可するために通常のユーザー名とパスワードのスキームを使用します。[3]ユーザー名はUSERコマンドを使用してサーバーに送信され、パスワードはPASSコマンドを使用して送信されます。[3]このシーケンスは「ネットワーク上」で暗号化されていないため、ネットワーク盗聴攻撃に対して脆弱である可能性があります。[22]クライアントから提供された情報がサーバーによって受け入れられると、サーバーはクライアントに挨拶を送信し、セッションが開始されます。[3]サーバーがそれをサポートしている場合、ユーザーはログイン資格情報を提供せずにログインできますが、同じサーバーはそのようなセッションに対して制限されたアクセスのみを許可できます。[3]

匿名FTP

FTPサービスを提供するホストは、匿名FTPアクセスを提供する場合があります。[3]ユーザーは通常、ユーザー名の入力を求められたときに、「匿名」(一部のFTPサーバーでは小文字で大文字と小文字が区別されます)アカウントでサービスにログインします。ユーザーは通常、パスワードの代わりに自分の電子メールアドレスを送信するように求められますが、 [4]提供されたデータに対して実際に検証は実行されません。[23]ソフトウェアアップデートを提供することを目的とする多くのFTPホストは、匿名ログインを許可します。[4]

HTTPとの違い

HTTPは基本的に、Webページで一般的な多くの小さな一時的な転送に使用するのを不便にするFTPのバグを修正します。

FTPには、現在の作業ディレクトリとその他のフラグを維持するステートフル制御接続があり、転送ごとに、データの転送に使用されるセカンダリ接続が必要です。「パッシブ」モードでは、このセカンダリ接続はクライアントからサーバーへの接続ですが、デフォルトの「アクティブ」モードでは、この接続はサーバーからクライアントへの接続です。アクティブモードでのこの明らかな役割の逆転、およびすべての転送のランダムなポート番号が、ファイアウォールとNATゲートウェイがFTPで非常に苦労している理由です。HTTPはステートレスであり、既知のポート番号でクライアントからサーバーへの単一の接続を介して制御とデータを多重化します。これは、NATゲートウェイを簡単に通過し、ファイアウォールで簡単に管理できます。

FTP制御接続のセットアップは、必要なすべてのコマンドを送信して応答を待機するラウンドトリップ遅延のために非常に遅いため、制御接続を立ち上げて、ドロップして再転送するのではなく、複数のファイル転送のために開いたままにするのが通例です。 -毎回セッションを新たに確立します。対照的に、HTTPは元々、転送が非常に安価だったため、転送のたびに接続を切断しました。その後、HTTPはTCP接続を複数の転送に再利用できるようになりましたが、概念モデルは依然としてセッションではなく独立した要求です。

FTPがデータ接続を介して転送しているとき、制御接続はアイドル状態です。転送に時間がかかりすぎると、ファイアウォールまたはNATが制御接続が無効であると判断し、追跡を停止して、接続を事実上切断し、ダウンロードを混乱させる可能性があります。単一のHTTP接続はリクエスト間でのみアイドル状態であり、通常であり、タイムアウト後にそのような接続がドロップされることが予想されます。

ソフトウェアサポート

Webブラウザ

ほとんどの一般的なWebブラウザーは、FTPサーバーでホストされているファイルを取得できますが、 FTPSなどのプロトコル拡張機能をサポートしていない場合があります[4] [24] HTTPではなくFTPのURLが提供されると、リモートサーバー上のアクセス可能なコンテンツは、他のWebコンテンツに使用されるのと同様の方法で表示されます。FireFTPは、フル機能のFTPクライアントとして設計されたブラウザ拡張機能であり、以前はFirefox内で実行できましたが、現在はWaterfoxを使用することをお勧めします。

GoogleChromeはChrome88でFTPサポートを完全に削除しました。[25] 2019年の時点で、Mozillaは、コードを簡素化するために使用されなくなった古いFTP実装のサポートのみを削除するなどの提案について話し合っていました。[26] [27] 2021年4月、MozillaはFirefox 88.0をリリースし、デフォルトでFTPサポートを無効にしました。[28] 2021年7月、Firefox90はFTPサポートを完全に廃止しました。[7]

構文

FTP URL構文は、RFC 1738で次の形式で説明されています(括弧で囲まれた部分はオプションです)。  ftp://[user[:password]@]host[:port]/url-path

たとえば、URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txtは、サーバーpublic.ftp-servers.example.comのディレクトリmydirectoryにあるファイルmyfile.txtをFTPリソースとして表します。 URL ftp:// user001:[email protected]/mydirectory/myfile.txtは、このリソースにアクセスするために使用する必要のあるユーザー名とパスワードの仕様を追加します。

ユーザー名とパスワードの指定の詳細については、ブラウザのドキュメント(Firefox [29]InternetExplorer [30]など)を参照してください。デフォルトでは、ほとんどのWebブラウザーはパッシブ(PASV)モードを使用します。これは、エンドユーザーのファイアウォールをより簡単に通過します。

ユーザーのルート以外のホームディレクトリがある場合に、さまざまなブラウザがパス解決を処理する方法には、いくつかのバリエーションがあります。[31]

ダウンロードマネージャー

最も一般的なダウンロードマネージャーは、FTPサーバーでホストされているファイルを受信できますが、FTPサーバーでホストされているファイルを取得するためのインターフェイスを提供するものもあります。DownloadStudioとInternetDownload Acceleratorを使用すると、FTPサーバーからファイルをダウンロードできるだけでなく、FTPサーバー上のファイルのリストを表示することもできます。[32] [33]

セキュリティ

FTPは安全なプロトコルとして設計されておらず、多くのセキュリティ上の弱点があります。[34] 1999年5月、RFC 2577の作成者は、次の問題に対する脆弱性をリストしました。  

FTPはトラフィックを暗号化しません。すべての送信はクリアテキストであり、ユーザー名、パスワード、コマンド、およびデータは、ネットワーク上でパケットキャプチャ(スニッフィング)を実行できる人なら誰でも読み取ることができます。[3] [34]この問題は、 TLSやSSLなどの暗号化メカニズムを作成する前に設計されたインターネットプロトコル仕様(SMTPTelnetPOPIMAPなど)の多くに共通しています。[9]

この問題の一般的な解決策は次のとおりです。

  1. 安全でないプロトコルの安全なバージョンを使用します。たとえば、 FTPの代わりにFTPSを使用し、Telnetの代わりにTelnetSを使用します。
  2. SSHファイル転送プロトコルセキュアコピープロトコルなど、ジョブを処理できる別のより安全なプロトコルを使用します
  3. Secure Shell(SSH)や仮想プライベートネットワーク(VPN)などの安全なトンネルを使用する。

FTP over SSH

FTP over SSHは、SecureShell接続を介して通常のFTPセッションをトンネリングする方法です。[34] FTPは複数のTCP接続を使用するため(まだ使用されているTCP / IPプロトコルでは珍しい)、SSHを介したトンネリングは特に困難です。多くのSSHクライアントでは、制御チャネル(ポート21での最初のクライアント/サーバー接続)にトンネルを設定しようとすると、そのチャネルのみが保護されます。データが転送されると、FTPソフトウェアはどちらかの端で新しいTCP接続(データチャネル)をセットアップするため、機密性整合性の保護はありません。

それ以外の場合は、SSHクライアントソフトウェアがFTPプロトコルに関する特定の知識を持ち、FTP制御チャネルメッセージを監視および書き換え、FTPデータチャネルの新しいパケット転送を自律的に開く必要があります。このモードをサポートするソフトウェアパッケージは次のとおりです。

派生物

FTPS

明示的FTPSは、クライアントがFTPセッションの暗号化を要求できるようにするFTP標準の拡張機能です。これは、「AUTHTLS」コマンドを送信することによって行われます。サーバーには、TLSを要求しない接続を許可または拒否するオプションがあります。このプロトコル拡張はRFC4217で定義されてますImplicit FTPSは、SSLまたはTLS接続の使用を必要とするFTPの古い標準です。プレーンFTPとは異なるポートを使用するように指定されました。  

SSHファイル転送プロトコル

SSHファイル転送プロトコル(時系列でSFTPと略される2つのプロトコルの2番目)はファイルを転送し、ユーザー向けに同様のコマンドセットを備えていますが、ファイルの転送にはSecure Shellプロトコル(SSH)を使用します。FTPとは異なり、コマンドとデータの両方を暗号化し、パスワードと機密情報がネットワークを介してオープンに送信されるのを防ぎます。FTPソフトウェアとの相互運用はできません。

トリビアルファイル転送プロトコル

Trivial File Transfer Protocol(TFTP)は、クライアントがリモートホストからファイルを取得したり、リモートホストにファイルを配置したりできるようにするシンプルなロックステップFTPです。TFTPの実装は非常に簡単であるため、その主な用途の1つは、ローカルエリアネットワークからの起動の初期段階です。TFTPにはセキュリティがなく、ファイル転送プロトコルなどのより堅牢なファイル転送プロトコルによって提供される高度な機能のほとんどがありません。TFTPは1981年に最初に標準化され、プロトコルの現在の仕様はRFC1350に記載されてます 

シンプルなファイル転送プロトコル

RFC 913で定義されているSimpleFile Transfer Protocol(SFTPと略される最初のプロトコル)は、TFTPとFTPの中間のレベルの複雑さを持つ(セキュリティで保護されていない)ファイル転送プロトコルとして提案されました。インターネットで広く受け入れられることはなく、現在IETFによって履歴ステータスが割り当てられています。ポート115を介して実行され、多くの場合、SFTPの初期化を受け取ります。 11個のコマンドのコマンドセットがあり、 ASCIIバイナリ、および連続の3種類のデータ送信をサポートします。ワードサイズのシステムの場合 つまり、8ビットの倍数であり、バイナリと連続の実装は同じです。このプロトコルは、ユーザーIDとパスワードを使用したログイン、階層フォルダー、およびファイル管理(名前変更削除アップロードダウンロード上書きを使用たダウンロード、追加を使用したダウンロードを含む)もサポートしています。

FTPコマンド

FTP応答コード

以下は、FTPサーバーから返される可能性のあるFTP応答コードの要約ですこれらのコードは、IETFによってRFC959で標準化されてます応答コードは3桁の値です。最初の数字は、成功、失敗、またはエラーや不完全な応答の3つの可能な結果のいずれかを示すために使用されます。  

  • 2yz –成功の返信
  • 4yzまたは5yz–失敗の応答
  • 1yzまたは3yz–エラーまたは不完全な応答

2桁目は、エラーの種類を定義します。

  • x0z –構文。これらの応答は、構文エラーを参照しています。
  • x1z –情報。情報の要求に応答します。
  • x2z –接続。制御およびデータ接続を参照して応答します。
  • x3z –認証とアカウンティング。ログインプロセスとアカウンティング手順の返信。
  • x4z –定義されていません。
  • x5z –ファイルシステム。これらの応答は、サーバーファイルシステムからのステータスコードを中継します。

応答コードの3桁目は、2桁目で定義された各カテゴリの追加の詳細を提供するために使用されます。

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ a b c Forouzan、BA(2000)。TCP / IP:プロトコルスイート(第1版)。インド、ニューデリー:Tata McGraw-Hill Publishing CompanyLimited。
  3. ^ a b c d e f g h i j Kozierok、Charles M.(2005)。「TCP / IPガイドv3.0」Tcpipguide.com。
  4. ^ a b c d e Dean、Tamara(2010)。Network +ネットワークガイドデルマー。pp。168–171。
  5. ^ 「Chrome87の非推奨と削除」2020年11月18日取得
  6. ^ 「Firefox88.0、すべての新機能、アップデート、修正を見る」2021年4月23日取得
  7. ^ a b Vonau、マヌエル(2021年7月7日)。「FirefoxはChromeの足跡をたどり、FTPサポートを終了します(APKダウンロード)」Android警察2021年7月12日取得{{cite web}}: CS1 maint: url-status (link)
  8. ^ 「FTPサポートの削除-Chromeプラットフォームのステータス」www.chromestatus.com 2021年9月2日取得
  9. ^ a b c d クラーク、MP(2003)。データネットワークIPとインターネット(第1版)。イギリス、ウエストサセックス:John Wiley&Sons Ltd.
  10. ^ a b 「アクティブFTPとパッシブFTP、決定的な説明」Slacksite.com。
  11. ^ RFC 959(標準)ファイル転送プロトコル(FTP)。Postel、J。&Reynolds、J。(1985年10月)。 
  12. ^ IPv6、NAT、および拡張パッシブモードのRFC 2428 (提案された標準)拡張。Allman、M。&Metz、C。&Ostermann、S。(1998年9月)。 
  13. ^ スティーブンス、W。リチャード(1994)。TCP / IP図解ボリュームI。1.米国マサチューセッツ州レディング:Addison-Wesley PublishingCompany。ISBN 0-201-63346-9
  14. ^ a b c Gleason、Mike(2005)。「ファイル転送プロトコルとファイアウォール/ NAT」Ncftp.com。
  15. ^ クレンシン、ジョン。国際化されたテキストのFTPTYPE拡張IDdraft-klensin-ftpext-typeu-00 2020年6月9日取得
  16. ^ Preston、J。(2005年1月)。FTPの送信モードをデフレートしますIETFIDdraft-preston-ftpext-deflate-03 2016年1月27日取得
  17. ^ Allcock、W。(2003年4月)。「GridFTP:グリッド用のFTPへのプロトコル拡張」(PDF)
  18. ^ Mandrichenko、I。(2005年5月4日)。「GridFTPv2プロトコルの説明」(PDF)
  19. ^ 「MFMTFTPコマンド」support.solarwinds.com2018年10月11日。
  20. ^ 「FTPコマンド:DSIZ、MFCT、MFMT、AVBL、PASS、XPWD、XMKD | Serv-U」www.serv-u.com
  21. ^ 「MDTMFTPコマンド」support.solarwinds.com2018年10月11日。
  22. ^ プリンス、ブライアン。「組織はセキュリティのためにFTPを廃止すべきですか?」セキュリティウィークセキュリティウィーク2017年9月14日取得
  23. ^ RFC 1635(情報)匿名FTPの使用方法。P.&Emtage、A。&Marine、A。(1994年5月)。 
  24. ^ Matthews、J。(2005)。コンピュータネットワーク:インターネットプロトコルの実行(第1版)。マサチューセッツ州ダンバーズ:John Wiley&Sons Inc.
  25. ^ スネドン、ジョーイ(2021年1月26日)。「Linuxリリースのまとめ:GParted、Lightworks、GoogleChromeなど」omgubuntu.co.uk 2021年1月30日取得
  26. ^ 「1574475-FTPサポートを削除します」
  27. ^ 「FTPサポートの廃止-Chromeプラットフォームのステータス」
  28. ^ 「Firefoxの新機能を見る:88.0Firefoxリリース」mozilla.org2021年4月19日2021年4月20日取得
  29. ^ 「FTPサーバーへのアクセス|方法| Firefoxヘルプ」Support.mozilla.com。2012年9月5日2013年1月16日取得
  30. ^ WaybackMachineのInternetExplorerでFTPサイトパスワードを入力する方法2015年7月2日アーカイブ)IEバージョン6以前用に作成されました。新しいバージョンで動作する可能性があります。
  31. ^ ユッカ「ユッカ」コルペラ(1997年9月18日)。「FTPURL」「ITとコミュニケーション」(jkorpela.fi)2020年1月26日取得
  32. ^ 「DownloadStudio-インターネットダウンロードマネージャーおよびダウンロードアクセラレータ-機能」コンセイバ2021年10月19日取得
  33. ^ 「インターネットダウンロードアクセラレータ|機能」WestByte 2021年10月20日取得
  34. ^ a bc 「SSHを使用し FTPの保護」Nurdletech.com。
  35. ^ 「情報保証プラットフォームのコンポーネント(セクションTectia ConnectSecure)」ssh.com2020年7月31日にオリジナルからアーカイブされました。

さらに読む

  • RFC  697 –FTPのCWDコマンド。1975年7月。
  • RFC  959 –(標準)ファイル転送プロトコル(FTP)。J.ポステル、J。レイノルズ。1985年10月。
  • RFC  1579 –(情報)ファイアウォールに優しいFTP。1994年2月。
  • RFC  1635 –(情報)匿名FTPの使用方法。1994年5月。
  • RFC  1639 –ビッグアドレスレコードを介したFTP操作(FOOBAR)。1994年6月。
  • RFC  1738 –ユニフォームリソースロケーター(URL)。1994年12月。
  • RFC  2228 –(提案された標準)FTPセキュリティ拡張。1997年10月。
  • RFC  2389 –(提案された標準)ファイル転送プロトコルの機能ネゴシエーションメカニズム。1998年8月。
  • RFC  2428 –(提案された標準)IPv6、NAT、および拡張パッシブモードの拡張。1998年9月。
  • RFC  2577 –(情報)FTPセキュリティの考慮事項。1999年5月。
  • RFC  2640 –(提案された標準)ファイル転送プロトコルの国際化。1999年7月。
  • RFC  3659 –(提案された標準)FTPの拡張。P.ヘスモン。2007年3月。
  • RFC  5797 –(提案された標準)FTPコマンドおよび拡張レジストリ。2010年3月。
  • RFC  7151 –(提案された標準)仮想ホスト用のファイル転送プロトコルHOSTコマンド。2014年3月。
  • IANA FTPコマンドおよび拡張機能レジストリ–FTPコマンドおよび拡張機能の公式レジストリ

外部リンク