โปรโตคอลการถ่ายโอนไฟล์ ( FTP ) เป็นโปรโตคอลการสื่อสาร มาตรฐาน ที่ใช้สำหรับการถ่ายโอนไฟล์คอมพิวเตอร์จากเซิร์ฟเวอร์ไปยัง ไคล เอนต์ผ่านเครือข่ายคอมพิวเตอร์ FTP สร้างขึ้นบน สถาปัตยกรรม แบบจำลองไคลเอนต์-เซิร์ฟเวอร์โดยใช้การเชื่อมต่อควบคุมและข้อมูลแยกต่างหากระหว่างไคลเอนต์และเซิร์ฟเวอร์^{[ 1 ]}ผู้ใช้ FTP อาจยืนยันตัวตนด้วย โปรโตคอลการลงชื่อเข้าใช้แบบ ข้อความธรรมดาโดยปกติในรูปแบบของชื่อผู้ใช้และรหัสผ่าน แต่สามารถเชื่อมต่อแบบไม่ระบุตัวตนได้หากเซิร์ฟเวอร์ได้รับการกำหนดค่าให้อนุญาต สำหรับการส่งข้อมูลที่ปลอดภัยซึ่งปกป้องชื่อผู้ใช้และรหัสผ่าน และเข้ารหัสเนื้อหา FTP มักจะได้รับการรักษาความปลอดภัยด้วยSSL/TLS ( FTPS ) หรือแทนที่ด้วยโปรโตคอลการถ่ายโอนไฟล์ SSH (SFTP)

แอปพลิเคชันไคลเอ็นต์ FTP รุ่นแรกเป็นโปรแกรมบรรทัดคำสั่งที่พัฒนาขึ้นก่อนที่ระบบปฏิบัติการจะมีอินเทอร์เฟซผู้ใช้แบบกราฟิกและยังคงมาพร้อมกับระบบปฏิบัติการWindowsและUnix-like ส่วนใหญ่ ^{[ 2 ] [ 3 ]} ตั้งแต่นั้นมา มีการพัฒนา ไคลเอ็นต์ FTP เฉพาะและยูทิลิตี้อัตโนมัติมากมายสำหรับเดสก์ท็อป เซิร์ฟเวอร์ อุปกรณ์เคลื่อนที่ และฮาร์ดแวร์ และ FTP ได้ถูกรวมเข้ากับแอปพลิเคชันเพิ่มประสิทธิภาพการทำงาน เช่นโปรแกรมแก้ไข HTMLและ โปรแกรม จัดการ ไฟล์

เดิมทีไคลเอนต์ FTP มักถูกรวมเข้ากับเว็บเบราว์เซอร์โดยที่เซิร์ฟเวอร์ไฟล์จะถูกเรียกดูด้วยคำนำหน้าURI " " ในปี 2021 Google ChromeและFirefox [ ^{4 ] [ 5 ]}ftp:// ซึ่งเป็นผู้ให้บริการเว็บเบราว์เซอร์รายใหญ่สองราย ได้ยกเลิกการสนับสนุน FTP เนื่องจากถูกแทนที่ด้วยSFTPและFTPS ที่ปลอดภัยกว่า แม้ว่าเบราว์เซอร์ทั้งสองจะไม่ได้นำโปรโตคอลใหม่มาใช้^{ก็ตาม[ 6 ] [ 7 ]}

ข้อกำหนดดั้งเดิมของโปรโตคอลการถ่ายโอนไฟล์เขียนโดยAbhay Bhushanและเผยแพร่เป็นRFC 114เมื่อวันที่ 16 เมษายน 1971 จนถึงปี 1980 FTP ทำงานบนNCPซึ่งเป็นรุ่นก่อนหน้าของTCP/IP [ ^{2 ] ต่อ}มาโปรโตคอลนี้ถูกแทนที่ด้วยเวอร์ชัน TCP/IP คือRFC 765 (มิถุนายน 1980) และRFC 959 (ตุลาคม 1985) ซึ่งเป็นข้อกำหนดปัจจุบัน มาตรฐานที่เสนอหลายฉบับแก้ไขRFC 959ตัวอย่างเช่นRFC 1579 (กุมภาพันธ์ 1994) เปิดใช้งาน FTP ที่เป็นมิตรกับไฟร์วอลล์ (โหมดพาสซีฟ) RFC 2228 (มิถุนายน 1997) เสนอส่วนขยายด้านความปลอดภัยRFC 2428 (กันยายน 1998) เพิ่มการสนับสนุนสำหรับIPv6และกำหนดโหมดพาสซีฟประเภทใหม่^{[ 8 ]}       

FTP อาจทำงานใน โหมด แอคทีฟหรือพาสซีฟซึ่งกำหนดวิธีการสร้างการเชื่อมต่อข้อมูล^{[ 9 ]} (ความหมายของ "โหมด" นี้แตกต่างจากคำสั่ง MODE ในโปรโตคอล FTP)

• ในโหมดแอคทีฟ ไคลเอนต์จะเริ่มรอรับการเชื่อมต่อข้อมูลขาเข้าจากเซิร์ฟเวอร์บนพอร์ต M โดยจะส่งคำสั่ง FTP PORT M เพื่อแจ้งให้เซิร์ฟเวอร์ทราบว่ากำลังรอรับการเชื่อมต่อที่พอร์ตใด จากนั้นเซิร์ฟเวอร์จะเริ่มต้นช่องทางข้อมูลไปยังไคลเอนต์จากพอร์ต 20 ซึ่งเป็นพอร์ตข้อมูลของเซิร์ฟเวอร์ FTP
• ในสถานการณ์ที่ไคลเอนต์อยู่หลังไฟร์วอลล์และไม่สามารถรับการเชื่อมต่อ TCP ขาเข้าได้อาจใช้โหมดพาสซีฟ ในโหมดนี้ ไคลเอนต์จะใช้การเชื่อมต่อควบคุมเพื่อส่งคำสั่ง PASV ไปยังเซิร์ฟเวอร์ จากนั้นจะได้รับที่อยู่ IP ของเซิร์ฟเวอร์และหมายเลขพอร์ตของเซิร์ฟเวอร์จากเซิร์ฟเวอร์ ^{[ 9 ]}ซึ่งไคลเอนต์จะใช้เพื่อเปิดการเชื่อมต่อข้อมูลจากพอร์ตไคลเอนต์ใดๆ ไปยังที่อยู่ IP ของเซิร์ฟเวอร์และหมายเลขพอร์ตของเซิร์ฟเวอร์ที่ได้รับ^{[ 10 ]}

โหมดทั้งสองได้รับการอัปเดตในเดือนกันยายน พ.ศ. 2541 เพื่อรองรับIPv6มีการเปลี่ยนแปลงเพิ่มเติมในโหมดพาสซีฟในเวลานั้น โดยอัปเดตเป็นโหมดพาสซีฟแบบขยาย^{[ 11 ]}

เซิร์ฟเวอร์จะตอบกลับผ่านการเชื่อมต่อควบคุมด้วยรหัสสถานะสามหลักในรูปแบบ ASCII พร้อมข้อความเสริม ตัวอย่างเช่น "200" (หรือ "200 OK") หมายความว่าคำสั่งสุดท้ายสำเร็จ ตัวเลขแสดงถึงรหัสสำหรับการตอบกลับ และข้อความเสริมแสดงถึงคำอธิบายหรือคำขอที่มนุษย์อ่านได้ (เช่น <ต้องการบัญชีสำหรับจัดเก็บไฟล์>) ^{[ 1 ]}การถ่ายโอนข้อมูลไฟล์ที่กำลังดำเนินอยู่ผ่านการเชื่อมต่อข้อมูลสามารถยกเลิกได้โดยใช้ข้อความขัดจังหวะที่ส่งผ่านการเชื่อมต่อควบคุม

FTP ต้องการพอร์ตสองพอร์ต (พอร์ตหนึ่งสำหรับส่งและอีกพอร์ตหนึ่งสำหรับรับ) เนื่องจากเดิมทีได้รับการออกแบบให้ทำงานบนNetwork Control Protocol (NCP) ซึ่งเป็นโปรโตคอลแบบซิมเพล็กซ์ที่ใช้ที่อยู่พอร์ต สอง พอร์ต สร้างการเชื่อมต่อสองรายการสำหรับการสื่อสารแบบสองทาง พอร์ตคี่และพอร์ตคู่ถูกสงวนไว้สำหรับแอปพลิเคชันหรือโปรโตคอลแต่ละชั้นแอปพลิเคชัน การกำหนดมาตรฐานของ TCP และ UDP ลดความจำเป็นในการใช้พอร์ตซิมเพล็กซ์สองพอร์ตสำหรับแต่ละแอปพลิเคชันลงเหลือเพียงพอร์ตดูเพล็กซ์หนึ่งพอร์ต^{[ 12 ] : 15} แต่โปรโตคอล FTP ไม่เคยถูกแก้ไขให้ใช้เพียงพอร์ตเดียว และยังคงใช้สองพอร์ตเพื่อความเข้ากันได้กับเวอร์ชันก่อนหน้า

โดยปกติ FTP จะถ่ายโอนข้อมูลโดยให้เซิร์ฟเวอร์เชื่อมต่อกลับไปยังไคลเอนต์หลังจากที่ไคลเอนต์ส่งคำสั่ง PORT แล้ว ซึ่งเป็นปัญหาสำหรับทั้งNATและไฟร์วอลล์ที่ไม่อนุญาตให้มีการเชื่อมต่อจากอินเทอร์เน็ตไปยังโฮสต์ภายใน^{[ 13 ]}สำหรับ NAT ความซับซ้อนเพิ่มเติมคือการแสดงที่อยู่ IP และหมายเลขพอร์ตในคำสั่ง PORT นั้นอ้างอิงถึงที่อยู่ IP และพอร์ตของโฮสต์ภายใน แทนที่จะเป็นที่อยู่ IP สาธารณะและพอร์ตของ NAT

มีสองแนวทางในการแก้ปัญหานี้ แนวทางหนึ่งคือ ไคลเอนต์ FTP และเซิร์ฟเวอร์ FTP ใช้คำสั่ง PASV ซึ่งทำให้การเชื่อมต่อข้อมูลถูกสร้างขึ้นจากไคลเอนต์ FTP ไปยังเซิร์ฟเวอร์^{[ 13 ]}วิธีนี้ใช้กันอย่างแพร่หลายในไคลเอนต์ FTP สมัยใหม่ อีกแนวทางหนึ่งคือ NAT จะทำการเปลี่ยนแปลงค่าของคำสั่ง PORT โดยใช้เกตเวย์ระดับแอปพลิเคชันเพื่อจุดประสงค์นี้^{[ 13 ]}

ในขณะที่ถ่ายโอนข้อมูลผ่านเครือข่าย จะมีการกำหนดประเภทข้อมูลห้าประเภท: ^{[ 2 ] [ 3 ] [ 8 ]}

• ASCII (ประเภท A): ใช้สำหรับข้อความ ข้อมูลจะถูกแปลงหากจำเป็น จากรูปแบบการแสดงอักขระของโฮสต์ผู้ส่งเป็น"ASCII 8 บิต"ก่อนการส่ง และ (หากจำเป็นอีกครั้ง) แปลงเป็นรูปแบบการแสดงอักขระของโฮสต์ผู้รับ รวมถึงการขึ้นบรรทัดใหม่ด้วยเหตุนี้ โหมดนี้จึงไม่เหมาะสมสำหรับไฟล์ที่มีข้อมูลอื่นที่ไม่ใช่ ASCII
• โหมดรูปภาพ (ประเภทที่ 1 หรือที่เรียกกันทั่วไปว่า โหมด ไบนารี ): เครื่องส่งจะส่งไฟล์แต่ละไฟล์ทีละไบต์ และผู้รับจะจัดเก็บสตรีมไบต์ตามที่ได้รับ (แนะนำให้รองรับโหมดรูปภาพสำหรับ FTP ทุกเวอร์ชัน)
• EBCDIC (ประเภท E): ใช้สำหรับการส่งข้อความธรรมดาระหว่างโฮสต์โดยใช้ชุดอักขระ EBCDIC
• แบบโลคอล (TYPE L n ): ออกแบบมาเพื่อรองรับการถ่ายโอนไฟล์ระหว่างเครื่องที่ไม่ใช้ไบต์ 8 บิต เช่นระบบ 36 บิตอย่างเช่น DEC PDP-10ตัวอย่างเช่น "TYPE L 9" จะใช้สำหรับการถ่ายโอนข้อมูลในรูปแบบไบต์ 9 บิต หรือ "TYPE L 36" สำหรับการถ่ายโอนข้อมูลในรูปแบบเวิร์ด 36 บิต ไคลเอนต์/เซิร์ฟเวอร์ FTP ส่วนใหญ่ในปัจจุบันรองรับเฉพาะ L 8 ซึ่งเทียบเท่ากับ I
• ไฟล์ข้อความUnicode ที่ใช้ UTF-8 (TYPE U): กำหนดไว้ในInternet Draft ที่หมดอายุ ^{[ 14 ]}ซึ่งไม่เคยกลายเป็น RFC แม้ว่าจะถูกนำไปใช้โดยไคลเอ็นต์/เซิร์ฟเวอร์ FTP หลายตัวก็ตาม

โปรดทราบว่าประเภทข้อมูลเหล่านี้โดยทั่วไปเรียกว่าโหมดแม้ว่าคำนี้จะมีความหมายกำกวมในที่นี้ โดยอาจหมายถึงโหมดการสื่อสารแบบแอคทีฟเทียบกับแบบพาสซีฟ (ดูด้านบน) และโหมดที่ตั้งค่าโดยคำสั่ง MODE ของโปรโตคอล FTP (ดูด้านล่าง)

สำหรับไฟล์ข้อความ (ประเภท A และประเภท E) มีตัวเลือกการควบคุมรูปแบบสามแบบให้เลือกใช้เพื่อควบคุมวิธีการพิมพ์ไฟล์:

• ไฟล์ที่ไม่สามารถพิมพ์ได้ (ประเภท AN และประเภท EN) – ไฟล์นี้ไม่มีอักขระควบคุมการขึ้นบรรทัดใหม่ใดๆ ที่มีไว้สำหรับเครื่องพิมพ์
• Telnet (TYPE AT และ TYPE ET) – ไฟล์นี้มีอักขระควบคุมการขึ้นบรรทัดใหม่ของ Telnet (หรืออีกนัยหนึ่งคือ ASCII C0) (CR, LF เป็นต้น)
• ASA (ประเภท AA และประเภท EA) – ไฟล์นี้มีอักขระควบคุมการขึ้นบรรทัดใหม่แบบ ASA

รูปแบบเหล่านี้ส่วนใหญ่เกี่ยวข้องกับเครื่องพิมพ์แบบบรรทัดต่อบรรทัดเท่านั้น ไคลเอนต์/เซิร์ฟเวอร์ FTP ส่วนใหญ่ในปัจจุบันรองรับเฉพาะการควบคุมรูปแบบเริ่มต้นคือ N เท่านั้น

การจัดระเบียบไฟล์ระบุโดยใช้คำสั่ง STRU โครงสร้างไฟล์ต่อไปนี้ถูกกำหนดไว้ในส่วนที่ 3.1.1 ของ RFC959:

• โครงสร้าง ไฟล์ (แบบสตรีม) ไฟล์ถูกมองว่าเป็นลำดับของไบต์ อักขระ หรือคำที่ไม่ตายตัว นี่คือโครงสร้างไฟล์ทั่วไปในระบบ Unix และระบบอื่นๆ เช่น CP/M, MS-DOS และ Microsoft Windows (ส่วนที่ 3.1.1.1)
• โครงสร้างไฟล์ แบบ Rหรือ RECORD (แบบเน้นระเบียน) ไฟล์จะถูกมองว่าแบ่งออกเป็นระเบียน ซึ่งอาจมีความยาวคงที่หรือแปรผันได้ การจัดระเบียบไฟล์แบบนี้พบได้ทั่วไปในระบบเมนเฟรมและระบบขนาดกลาง เช่น MVS, VM/CMS, OS/400 และ VMS ซึ่งรองรับ ระบบไฟล์ แบบเน้นระเบียน
• โครงสร้างไฟล์ แบบ Pหรือ PAGE (แบบแบ่งหน้า) ไฟล์จะถูกแบ่งออกเป็นหน้า ซึ่งแต่ละหน้าอาจมีข้อมูลหรือเมตาเดตา และแต่ละหน้าอาจมีส่วนหัวที่ระบุคุณลักษณะต่างๆ โครงสร้างไฟล์นี้ได้รับการออกแบบมาโดยเฉพาะสำหรับ ระบบ TENEXและโดยทั่วไปแล้วไม่ได้รับการสนับสนุนบนแพลตฟอร์มอื่นๆ RFC1123 ส่วนที่ 4.1.2.3 แนะนำว่าไม่ควรนำโครงสร้างนี้ไปใช้

ไคลเอนต์และเซิร์ฟเวอร์ FTP ในปัจจุบันส่วนใหญ่รองรับเฉพาะ STRU F เท่านั้น STRU R ยังคงใช้งานอยู่ในแอปพลิเคชันการถ่ายโอนไฟล์ในเมนเฟรมและมินิคอมพิวเตอร์

การถ่ายโอนข้อมูลสามารถทำได้ในสามโหมด: ^{[ 1 ] [ 2 ]}

• โหมดสตรีม (MODE S): ข้อมูลจะถูกส่งเป็นสตรีมต่อเนื่อง ทำให้ FTP ไม่ต้องประมวลผลใดๆ การประมวลผลทั้งหมดจึงตกอยู่กับTCPไม่จำเป็นต้องมีตัวบ่งชี้สิ้นสุดไฟล์ เว้นแต่ข้อมูลจะถูกแบ่งออกเป็นระเบียน
• โหมดบล็อก (MODE B): ออกแบบมาเพื่อถ่ายโอนไฟล์แบบบันทึก (STRU R) เป็นหลัก แม้ว่าจะสามารถใช้ถ่ายโอนไฟล์ข้อความแบบสตรีม (STRU F) ได้เช่นกัน FTP จะแบ่งข้อมูลแต่ละระเบียน (หรือบรรทัด) ออกเป็นหลายบล็อก (ส่วนหัวของบล็อก จำนวนไบต์ และฟิลด์ข้อมูล) แล้วส่งต่อไปยัง TCP ^{[ 8 ]}
• โหมดบีบอัด (โหมด C): ต่อยอดจากโหมด B โดยเพิ่มการบีบอัดข้อมูลโดยใช้การเข้ารหัสแบบ Run-Length Encoding

โปรแกรมไคลเอนต์และเซิร์ฟเวอร์ FTP ส่วนใหญ่ในปัจจุบันไม่ได้ใช้งานโหมด B หรือโหมด C ยกเว้นโปรแกรมไคลเอนต์และเซิร์ฟเวอร์ FTP สำหรับระบบปฏิบัติการเมนเฟรมและมินิคอมพิวเตอร์

ซอฟต์แวร์ FTP บางตัวยังใช้ โหมดการบีบอัดแบบ DEFLATEซึ่งบางครั้งเรียกว่า "โหมด Z" ตามคำสั่งที่เปิดใช้งาน โหมดนี้ได้รับการอธิบายไว้ในร่างอินเทอร์เน็ตแต่ไม่ได้มีการกำหนดมาตรฐาน^{[ 15 ]}

GridFTPกำหนดโหมดเพิ่มเติม ได้แก่ MODE E ^{[ 16 ]}และ MODE X ^{[ 17 ]}เป็นส่วนขยายของ MODE B

การใช้งาน FTP รุ่นใหม่กว่ารองรับ คำสั่ง Modify Fact: Modification Time (MFMT) ซึ่งช่วยให้ไคลเอ็นต์สามารถปรับแอตทริบิวต์ไฟล์ นั้น จากระยะไกลได้ ทำให้สามารถรักษาแอตทริบิวต์นั้นไว้ได้เมื่ออัปโหลดไฟล์^{[ 18 ] [ 19 ]}

ในการดึงข้อมูลการประทับเวลาของไฟล์ระยะไกล จะมี คำสั่ง MDTMเซิร์ฟเวอร์ (และไคลเอนต์) บางตัวรองรับไวยากรณ์ที่ไม่เป็นมาตรฐานของ คำสั่ง MDTMที่มีอาร์กิวเมนต์สองตัว ซึ่งทำงานในลักษณะเดียวกับMFMT ^{[ 20 ]}

การเข้าสู่ระบบ FTP ใช้รูปแบบชื่อผู้ใช้และรหัสผ่านปกติในการให้สิทธิ์การเข้าถึง^{[ 2 ]}ชื่อผู้ใช้จะถูกส่งไปยังเซิร์ฟเวอร์โดยใช้คำสั่ง USER และรหัสผ่านจะถูกส่งโดยใช้คำสั่ง PASS ^{[ 2 ]}ลำดับนี้ไม่ได้เข้ารหัส "ระหว่างการส่ง" ดังนั้นจึงอาจเสี่ยงต่อการโจมตีการดักฟังเครือข่าย[ 21 ^{]หากเซิร์ฟเวอร์}ยอมรับข้อมูลที่ไคลเอนต์ให้มา เซิร์ฟเวอร์จะส่งคำทักทายไปยังไคลเอนต์และเซสชันจะเริ่มต้นขึ้น^{[ 2 ]}หากเซิร์ฟเวอร์รองรับ ผู้ใช้สามารถเข้าสู่ระบบได้โดยไม่ต้องระบุข้อมูลประจำตัวการเข้าสู่ระบบ แต่เซิร์ฟเวอร์เดียวกันอาจอนุญาตให้เข้าถึงได้เพียงจำกัดสำหรับเซสชันดังกล่าว^{[ 2 ]}

โฮสต์ที่ให้บริการ FTP อาจให้การเข้าถึง FTP แบบไม่ระบุตัวตน^{[ 2 ]}โดยทั่วไปผู้ใช้จะเข้าสู่ระบบด้วยบัญชี 'ไม่ระบุตัวตน' (ตัวพิมพ์เล็กและคำนึงถึงตัวพิมพ์ใหญ่-เล็กในเซิร์ฟเวอร์ FTP บางแห่ง) เมื่อระบบขอให้ป้อนชื่อผู้ใช้ แม้ว่าโดยทั่วไปผู้ใช้จะถูกขอให้ส่ง ที่อยู่ อีเมลแทนรหัสผ่าน^{[ 3 ]} แต่ ในความเป็นจริงแล้วจะไม่มีการตรวจสอบข้อมูลที่ให้มา^{[ 22 ]}โฮสต์ FTP จำนวนมากที่มีจุดประสงค์เพื่อให้บริการอัปเดตซอฟต์แวร์จะอนุญาตให้เข้าสู่ระบบแบบไม่ระบุตัวตนได้^{[ 3 ]}

FileZillaและWinSCPเป็นซอฟต์แวร์ไคลเอ็นต์ FTP ยอดนิยมสองตัวที่ทำงานบนระบบปฏิบัติการ Windows

โปรแกรมจัดการไฟล์หลายโปรแกรมมีการใช้งานการเข้าถึง FTP เช่นFile Explorer (เดิมคือ Windows Explorer) บนMicrosoft Windows แนะนำให้ใช้ไคลเอนต์นี้สำหรับการถ่ายโอนไฟล์ขนาดเล็กจากเซิร์ฟเวอร์เท่านั้น เนื่องจากมีข้อจำกัดเมื่อเทียบกับ ^{ซอฟต์แวร์}ไคลเอนต์เฉพาะ^{[ 23 ]}และไม่รองรับSFTP [ ^{24 ]}

ทั้งโปรแกรมจัดการไฟล์ดั้งเดิมของKDEบน Linux ( DolphinและKonqueror ) รองรับทั้ง FTP และ SFTP ^{[ 25 ] [ 26 ]}

บนAndroidโปรแกรมจัดการไฟล์ My Files บนSamsung Galaxy มี ไคลเอ็นต์ FTP และ SFTPในตัว^{[ 27 ]}

เป็นเวลานานแล้วที่เว็บเบราว์เซอร์ ทั่วไปส่วนใหญ่ สามารถดึงไฟล์ที่โฮสต์บนเซิร์ฟเวอร์ FTP ได้ แม้ว่าบางเบราว์เซอร์จะไม่รองรับส่วนขยายโปรโตคอล เช่นFTPSก็ตาม^{[ 3 ] [ 28 ]} เมื่อมีการระบุ URLของ FTP แทนที่จะเป็น HTTP เนื้อหาที่เข้าถึงได้บนเซิร์ฟเวอร์ระยะไกลจะถูกนำเสนอในลักษณะที่คล้ายกับที่ใช้สำหรับเนื้อหาเว็บอื่นๆ

Google Chrome ได้ลบการสนับสนุน FTP ออกไปโดยสิ้นเชิงใน Chrome 88 ซึ่งส่งผลกระทบต่อ เบราว์เซอร์ที่ใช้ Chromium อื่นๆ เช่นMicrosoft Edgeด้วย^{[ 29 ]} Firefox 88 ปิดใช้งานการสนับสนุน FTP โดยค่าเริ่มต้น และ Firefox 90 ได้ยกเลิกการสนับสนุนโดยสิ้นเชิง^{[ 30 ] [ 4 ]}

FireFTPเป็นส่วนขยายเบราว์เซอร์ที่เลิกใช้งานแล้ว ซึ่งได้รับการออกแบบให้เป็นไคลเอนต์ FTP ที่มีคุณสมบัติครบถ้วนเพื่อใช้งานภายในFirefoxแต่เมื่อ Firefox เลิกสนับสนุน FTP นักพัฒนาส่วนขยายจึงแนะนำให้ใช้Waterfoxแทน^{[ 31 ]}เบราว์เซอร์บางตัว เช่นLynxซึ่งเป็นเบราว์เซอร์แบบข้อความ ยังคงรองรับ FTP อยู่^{[ 32 ]}

ไวยากรณ์ URL ของ FTP อธิบายไว้ในRFC 1738โดยมีรูปแบบดังนี้: โดยจำเป็นต้องระบุเฉพาะโฮสต์เท่านั้น  ftp://user:password@host:port/path

รายละเอียดเพิ่มเติมเกี่ยวกับการระบุชื่อผู้ใช้และรหัสผ่านสามารถพบได้ในเอกสารประกอบของเบราว์เซอร์ (เช่นFirefox ^{[ 33 ]}และInternet Explorer ^{[ 34 ]} ) โดยค่าเริ่มต้น เบราว์เซอร์เว็บส่วนใหญ่จะใช้โหมดพาสซีฟ (PASV) ซึ่งสามารถผ่านไฟร์วอลล์ของผู้ใช้ปลายทางได้ง่ายกว่า

มีความแตกต่างบางประการในวิธีการที่เบราว์เซอร์ต่างๆ จัดการกับการแก้ไขเส้นทางในกรณีที่มีไดเร็กทอรีโฮมที่ไม่ใช่รูทสำหรับผู้ใช้^{[ 35 ]}

โปรแกรมจัดการดาวน์โหลดทั่วไปส่วนใหญ่สามารถรับไฟล์ที่โฮสต์อยู่บนเซิร์ฟเวอร์ FTP ได้ ในขณะที่บางโปรแกรมยังมีอินเทอร์เฟซสำหรับแสดงรายการไฟล์ที่โฮสต์อยู่บนเซิร์ฟเวอร์ FTP อีกด้วย

LibreOfficeประกาศว่าการสนับสนุน FTP ของตนถูกยกเลิกตั้งแต่เวอร์ชัน 7.4 และต่อมาได้ลบออกในเวอร์ชัน 24.2 ^{[ 36 ] [ 37 ]} Apache OpenOfficeซึ่งเป็นอีกโปรแกรมหนึ่งที่สืบทอดมาจาก OpenOffice.org ยังคงรองรับ FTP อยู่^{[ 38 ] [ 39 ] [ 40 ]}

FTP ไม่ได้ถูกออกแบบมาให้เป็นโปรโตคอลที่ปลอดภัย และมีจุดอ่อนด้านความปลอดภัยมากมาย^{[ 41 ]}ในเดือนพฤษภาคม พ.ศ. 2542 ผู้เขียนRFC 2577ได้ระบุช่องโหว่ต่อปัญหาต่อไปนี้:  

• การโจมตีด้วยกำลังดุร้าย
• การโจมตีแบบ FTP bounce
• การจับภาพแพ็กเก็ต
• การขโมยพอร์ต (การเดาพอร์ตที่ว่างถัดไปและแย่งใช้การเชื่อมต่อที่ถูกต้อง)
• การโจมตีแบบปลอมแปลง
• การแจงนับชื่อผู้ใช้
• DoS หรือ DDoS

FTP ไม่เข้ารหัสการรับส่งข้อมูล การส่งทั้งหมดเป็นข้อความธรรมดา และชื่อผู้ใช้ รหัสผ่าน คำสั่ง และข้อมูลสามารถอ่านได้โดยใครก็ตามที่สามารถดักจับแพ็กเก็ต ( sniffing ) บนเครือข่ายได้^{[ 2 ] [ 41 ]}ปัญหานี้เป็นเรื่องปกติสำหรับข้อกำหนดโปรโตคอลอินเทอร์เน็ตหลายรายการ (เช่นSMTP , Telnet , POPและIMAP ) ที่ได้รับการออกแบบก่อนการสร้างกลไกการเข้ารหัส เช่นTLSหรือ SSL ^{[ 8 ]}

วิธีแก้ปัญหาทั่วไปสำหรับปัญหานี้ ได้แก่:

1. การใช้โปรโตคอลที่ปลอดภัยกว่าแทนโปรโตคอลที่ไม่ปลอดภัย เช่นFTPSแทน FTP และ TelnetS แทน Telnet
2. โดยใช้โปรโตคอลอื่นที่ปลอดภัยกว่าซึ่งสามารถ จัดการงานนั้นได้ เช่นโปรโตคอลการถ่ายโอนไฟล์ SSHหรือโปรโตคอลการคัดลอกที่ปลอดภัย
3. โดยใช้ช่องทางที่ปลอดภัย เช่นSecure Shell (SSH) หรือเครือข่ายส่วนตัวเสมือน (VPN)

FTP ผ่าน SSH คือการปฏิบัติในการสร้างอุโมงค์เซสชัน FTP ปกติผ่านการเชื่อมต่อ Secure Shell ^{[ 41 ]}เนื่องจาก FTP ใช้ การเชื่อมต่อ TCP หลายรายการ (ซึ่งผิดปกติสำหรับโปรโตคอล TCP/IP ที่ยังคงใช้งานอยู่) จึงเป็นเรื่องยากเป็นพิเศษที่จะสร้างอุโมงค์ผ่าน SSH ด้วยไคลเอนต์ SSH จำนวนมาก การพยายามตั้งค่าอุโมงค์สำหรับช่องควบคุม (การเชื่อมต่อไคลเอนต์ไปยังเซิร์ฟเวอร์เริ่มต้นบนพอร์ต 21) จะปกป้องเฉพาะช่องนั้นเท่านั้น เมื่อมีการถ่ายโอนข้อมูล ซอฟต์แวร์ FTP ที่ปลายทั้งสองด้านจะตั้งค่าการเชื่อมต่อ TCP ใหม่ (ช่องข้อมูล) ดังนั้นจึงไม่มีการรักษา ความลับหรือการป้องกันความสมบูรณ์

มิเช่นนั้น ซอฟต์แวร์ไคลเอ็นต์ SSH จำเป็นต้องมีความรู้เฉพาะเกี่ยวกับโปรโตคอล FTP เพื่อตรวจสอบและเขียนทับข้อความช่องควบคุม FTP และเปิดการส่งต่อแพ็กเก็ต ใหม่ สำหรับช่องข้อมูล FTP โดยอัตโนมัติ แพ็กเกจซอฟต์แวร์ที่รองรับโหมดนี้ได้แก่:

• Tectia ConnectSecure (Win/Linux/Unix) ^{[ 42 ]}ของชุดซอฟต์แวร์SSH Communications Security

ไม่ควรสับสนระหว่าง FTP ผ่าน SSH กับSSH File Transfer Protocol (SFTP)

FTPS แบบระบุชัดเจน (Explicit FTPS) เป็นส่วนขยายของมาตรฐาน FTP ที่อนุญาตให้ไคลเอ็นต์ร้องขอการเข้ารหัสเซสชัน FTP โดยการส่งคำสั่ง "AUTH TLS" เซิร์ฟเวอร์มีตัวเลือกในการอนุญาตหรือปฏิเสธการเชื่อมต่อที่ไม่ร้องขอ TLS ส่วนขยายโปรโตคอลนี้ถูกกำหนดไว้ในRFC 4217ส่วน FTPS แบบไม่ระบุชัดเจน (Implicit FTPS) เป็นมาตรฐาน FTP ที่ล้าสมัยซึ่งกำหนดให้ใช้การเชื่อมต่อ SSL หรือ TLS และกำหนดให้ใช้พอร์ตที่แตกต่างจาก FTP ทั่วไป  

โปรโตคอลการถ่ายโอนไฟล์ SSH (ซึ่งเป็นโปรโตคอลลำดับที่สองจากสองโปรโตคอลที่ย่อว่า SFTP) ใช้ในการถ่ายโอนไฟล์และมีชุดคำสั่งที่คล้ายคลึงกันสำหรับผู้ใช้ แต่ใช้ โปรโตคอล Secure Shell (SSH) ในการถ่ายโอนไฟล์ แตกต่างจาก FTP ตรงที่ SSH เข้ารหัสทั้งคำสั่งและข้อมูล ป้องกันไม่ให้รหัสผ่านและข้อมูลสำคัญถูกส่งผ่านเครือข่ายอย่างเปิดเผย SSH ไม่สามารถทำงานร่วมกับซอฟต์แวร์ FTP ได้ แม้ว่าซอฟต์แวร์ไคลเอ็นต์ FTP บางตัวจะรองรับโปรโตคอลการถ่ายโอนไฟล์ SSH ด้วยเช่นกัน

โปรโตคอลการถ่ายโอนไฟล์แบบง่าย (TFTP) เป็นโปรโตคอล FTP ที่เรียบง่ายและมีขั้นตอนการทำงานที่แน่นอน ซึ่งช่วยให้ไคลเอนต์สามารถรับหรือส่งไฟล์ไปยังโฮสต์ระยะไกลได้ การใช้งานหลักอย่างหนึ่งคือในขั้นตอนแรกของการบูตจากเครือข่ายบริเวณท้องถิ่น เนื่องจาก TFTP นั้นง่ายต่อการใช้งานมาก TFTP ขาดความปลอดภัยและคุณสมบัติขั้นสูงส่วนใหญ่ที่มีในโปรโตคอลการถ่ายโอนไฟล์ที่แข็งแกร่งกว่า เช่น FTP ( File Transfer Protocol) TFTP ได้รับการกำหนดมาตรฐานครั้งแรกในปี 1981 และข้อกำหนดปัจจุบันของโปรโตคอลนี้สามารถพบได้ในRFC 1350 

โปรโตคอลการถ่ายโอนไฟล์แบบง่าย (โปรโตคอลแรกย่อว่า SFTP) ตามที่กำหนดไว้ในRFC 913ถูกเสนอให้เป็นโปรโตคอลการถ่ายโอนไฟล์ (ที่ไม่ปลอดภัย) ที่มีระดับความซับซ้อนอยู่ระหว่าง TFTP และ FTP โปรโตคอลนี้ไม่เคยได้รับการยอมรับอย่างกว้างขวางบนอินเทอร์เน็ตและปัจจุบันได้รับการจัดสถานะเป็นโปรโตคอลประวัติศาสตร์โดยIETFโปรโตคอลนี้ทำงานผ่านพอร์ต 115 และมักใช้ชื่อย่อว่าSFTPมีชุดคำสั่ง 11 คำสั่ง และรองรับการส่งข้อมูลสามประเภท ได้แก่ASCII , ไบนารีและต่อเนื่อง สำหรับระบบที่มีขนาดคำที่เป็นพหุคูณของ 8 บิต การใช้งานไบนารีและต่อเนื่องจะเหมือนกัน โปรโตคอลนี้ยังรองรับการเข้าสู่ระบบด้วยรหัสผู้ใช้และรหัสผ่าน โฟลเดอร์แบบลำดับชั้น และการจัดการไฟล์ (รวมถึงการเปลี่ยนชื่อลบอัปโหลดดาวน์โหลดดาวน์โหลดพร้อมเขียนทับและดาวน์โหลดพร้อมเพิ่มข้อมูล )  

ด้านล่างนี้คือสรุปของรหัสตอบกลับ FTPที่อาจส่งกลับมาจากเซิร์ฟเวอร์ FTP รหัสเหล่านี้ได้รับการกำหนดมาตรฐานไว้ในRFC 959โดย IETF รหัสตอบกลับเป็นค่าสามหลัก หลักแรกใช้เพื่อระบุผลลัพธ์ที่เป็นไปได้สามอย่าง ได้แก่ สำเร็จ ล้มเหลว หรือเพื่อระบุข้อผิดพลาดหรือการตอบกลับไม่สมบูรณ์:  

• 2yz – ตอบกลับสำเร็จ
• 4yz หรือ 5yz – การตอบกลับล้มเหลว
• 1yz หรือ 3yz – ข้อผิดพลาดหรือการตอบกลับไม่สมบูรณ์

ตัวเลขหลักที่สองจะระบุประเภทของข้อผิดพลาด:

• x0z – ไวยากรณ์ คำตอบเหล่านี้เกี่ยวข้องกับข้อผิดพลาดทางไวยากรณ์
• x1z – ข้อมูล การตอบคำขอข้อมูล
• x2z – การเชื่อมต่อ การตอบกลับที่อ้างอิงถึงการเชื่อมต่อควบคุมและข้อมูล
• x3z – การตรวจสอบสิทธิ์และการบันทึกบัญชี คำตอบสำหรับกระบวนการเข้าสู่ระบบและขั้นตอนการบันทึกบัญชี
• x4z – ไม่ได้กำหนดค่าไว้
• x5z – ระบบไฟล์ ข้อความตอบกลับเหล่านี้ส่งต่อรหัสสถานะจากระบบไฟล์ของเซิร์ฟเวอร์

ตัวเลขหลักที่สามของรหัสตอบกลับจะใช้เพื่อระบุรายละเอียดเพิ่มเติมสำหรับแต่ละหมวดหมู่ที่กำหนดโดยตัวเลขหลักที่สอง

• RFC  697 – คำสั่ง CWD ของ FTP กรกฎาคม 1975
• RFC  959 – โปรโตคอลการถ่ายโอนไฟล์ (FTP) (มาตรฐาน) J. Postel, J. Reynolds ตุลาคม 1985
• RFC  1579 – (ข้อมูล) FTP ที่เป็นมิตรกับไฟร์วอลล์ กุมภาพันธ์ 1994
• RFC  1635 – (ข้อมูล) วิธีการใช้งาน FTP แบบไม่ระบุตัวตน พฤษภาคม 1994
• RFC  1639 – การดำเนินการ FTP ผ่านระเบียนที่อยู่ขนาดใหญ่ (FOOBAR) มิถุนายน 1994
• RFC  1738 – ตัวระบุตำแหน่งทรัพยากรสากล (URL) ธันวาคม 1994
• RFC  2228 – (มาตรฐานที่เสนอ) ส่วนขยายด้านความปลอดภัยของ FTP ตุลาคม 1997
• RFC  2389 – (มาตรฐานที่เสนอ) กลไกการเจรจาคุณสมบัติสำหรับโปรโตคอลการถ่ายโอนไฟล์ สิงหาคม 1998
• RFC  2428 – (มาตรฐานที่เสนอ) ส่วนขยายสำหรับ IPv6, NAT และโหมดพาสซีฟแบบขยาย กันยายน 1998
• RFC  2577 – ข้อควรพิจารณาด้านความปลอดภัยของ FTP (เชิงข้อมูล) พฤษภาคม 1999
• RFC  2640 – (มาตรฐานที่เสนอ) การรองรับหลายภาษาของโปรโตคอลการถ่ายโอนไฟล์ กรกฎาคม 1999
• RFC  3659 – (มาตรฐานที่เสนอ) ส่วนขยายสำหรับ FTP P. Hethmon. มีนาคม 2550
• RFC  5797 – (มาตรฐานที่เสนอ) ทะเบียนคำสั่งและส่วนขยาย FTP มีนาคม 2010
• RFC  7151 – (มาตรฐานที่เสนอ) คำสั่ง HOST ของโปรโตคอลการถ่ายโอนไฟล์สำหรับโฮสต์เสมือน มีนาคม 2014
• ทะเบียนคำสั่งและส่วนขยาย FTP ของ IANA – ทะเบียนอย่างเป็นทางการของคำสั่งและส่วนขยาย FTP

• เครือข่ายการสื่อสาร/โปรโตคอลการถ่ายโอนไฟล์ที่วิกิบุ๊ก
• โปรแกรมทดสอบเซิร์ฟเวอร์ FTP ออนไลน์: การตรวจ สอบสิทธิ์, การเข้ารหัส, โหมด และการเชื่อมต่อ
• เซิร์ฟเวอร์ FTP นิรนามตามรหัสประเทศTLD (2012): "อินเทอร์เน็ตนอกกระแส - การเข้าถึงสาธารณะ - FTP" . www.jumpjet.info . 2012. เก็บถาวรจากต้นฉบับเมื่อ 28 มีนาคม 2023 . เรียกดูเมื่อ16 มกราคม 2020 .