Hubbry Logo
Comparison of file transfer protocolsComparison of file transfer protocolsMain
Open search
Comparison of file transfer protocols
Community hub
Comparison of file transfer protocols
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Comparison of file transfer protocols
Comparison of file transfer protocols
Comparison of file transfer protocols
View on Wikipedia
from Wikipedia

This article lists communication protocols that are designed for file transfer over a telecommunications network.

Protocols for shared file systems—such as 9P and the Network File System—are beyond the scope of this article, as are file synchronization protocols.

Protocols for packet-switched networks

[edit]

A packet-switched network transmits data that is divided into units called packets. A packet comprises a header (which describes the packet) and a payload (the data). The Internet is a packet-switched network, and most of the protocols in this list are designed for its protocol stack, the IP protocol suite.

They use one of two transport layer protocols: the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). In the tables below, the "Transport" column indicates which protocol(s) the transfer protocol uses at the transport layer. Some protocols designed to transmit data over UDP also use a TCP port for oversight.

The "Server port" column indicates the port from which the server transmits data. In the case of FTP, this port differs from the listening port. Some protocols—including FTP, FTP Secure, FASP, and Tsunami—listen on a "control port" or "command port", at which they receive commands from the client.

Similarly, the encryption scheme indicated in the "Encryption" column applies to transmitted data only, and not to the authentication system.

Overview

[edit]
Color key:     International standard     Internet Standard     Proposed Standard     Internet Draft
Protocol Original author First published Protocol suite Standard Refs
Full name Abbreviation
Background Intelligent Transfer Service BITS Microsoft 2001 — No [1]
BitTorrent BT Bram Cohen 2001 — No [2]
CCSDS File Delivery Protocol CFDP 2002 — ISO 17355:2007 (v4)
CCSDS 727.0-B-5
Cross File Transfer CFT — No
Ether File Transfer Protocol EFTP John Shoch 1979 PARC Universal Packet No [3][4]
Fast and Secure Protocol FASP Ying Xu, Michelle Munson, Serban Simu 2007 — No [5]
File Delivery over Unidirectional Transport FLUTE Internet Society 2004 — RFC 6726 [6]
File Service Protocol FSP Wen-King Su 1991 — No [7][8]
File Transfer Access and Management FTAM 1988 ISO 8571-4:1988
File Transfer Protocol FTP Abhay Bhushan 1971 Internet protocol suite RFC 959 [9]
FTP Secure FTPS Internet Society 1997 Internet protocol suite RFC 2228, 4217 [10][11]
HTTP Secure HTTPS Taher Elgamal et al. 1995 Internet protocol suite RFC 9110 [12][13]
Host Unix Linkage File Transfer HULFT ? 1993 — No
Hypertext Transfer Protocol HTTP Tim Berners-Lee et al. 1991 Internet protocol suite RFC 9110 [14][15]
Micro Transport Protocol μTP Ludvig Strigeus, Greg Hazel, Stanislav Shalunov, Arvid Norberg, Bram Cohen 2007 — No [16][17]
Multicast Dissemination Protocol MDP 1993 No
Multicast File Transfer Protocol MFTP C. Kenneth Miller et al. 1995 — IETF Draft (1998) [18]
NACK-Oriented Reliable Multicast Transport Protocol NORM 2000 RFC 5740
Odette File Transfer Protocol OFTP Organisation for Data Exchange by Tele Transmission in Europe 1986 X.25 RFC 6726 [19]
Odette File Transfer Protocol 2 OFTP2 Organisation for Data Exchange by Tele Transmission in Europe 2007 X.25, Internet protocol suite RFC 5024 [20]
Reliable Blast UDP RBUDP Eric He et al. 2002 — No [21]
Remote copy rcp ? 1982 Internet protocol suite No [22]
Secure copy SCP Tatu Ylönen 1995 Secure Shell No [23]
Secure Hypertext Transfer Protocol S-HTTP IETF Web Transaction Security Working Group 1999 — RFC 2660 [24]
Simple Asynchronous File Transfer SAFT Ulli Horlacher 1995 — No [25][26]
Simple File Transfer Protocol SFTP Mark K. Lottor 1984 — RFC 913 [27]
SSH file transfer protocol SFTP Tatu Ylönen c. 1997 Secure Shell IETF Draft (2006) [28]
T.127 T.127 ITU[29] 1995 [30] — ITU T.127
Trivial File Transfer Protocol TFTP Noel Chiappa 1980 Internet protocol suite RFC 1350 [31]
Tsunami UDP Protocol Tsunami Mark Meiss et al. 2002 — No [32][33]
Tus open protocol for resumable file uploads tus Felix Geisendörfer, Marius Kleidl et al. 2014 — No [34][35]
UDP-based Data Transfer Protocol UDT Yunhong Gu 2004 — No
UDP-based File Transfer Protocol UFTP Dennis Bush 2001 — No [36]
Unix-to-Unix Copy UUCP Mike Lesk 1979 — No
Warp Speed Data Transfer WDT Laurent Demailly et al. 2015 — No [37]

Features

[edit]

The "Managed" column indicates whether the protocol is designed for managed file transfer (MFT). MFT protocols prioritise secure transmission in industrial applications that require such features as auditable transaction records, monitoring, and end-to-end data security. Such protocols may be preferred for electronic data interchange.[38]

Protocol Encryption
(data)		 Transfer
resuming		 Multicast
capable		 Managed Refs
BITS Optional TLS / AES-128[a] Yes No No
BitTorrent None[b] Yes Peer-to-peer No [39][40]
CCSDS File Delivery Protocol (CFDP) Yes No No
Cross File Transfer (CFT) TLS / SSL Yes [41][42]
Ether File Transfer Protocol (EFTP) None ? No No [43]
Fast and Secure Protocol (FASP) AES-256 / AES-192 / AES-128 Yes No [44][45][46]
File Delivery over Unidirectional Transport (FLUTE) Optional/Unspecified[c] No Yes [47][48][49]
File Service Protocol (FSP) None Yes No No [50][51]
File Transfer Access and Management (FTAM) ?[d] [52]
File Transfer Protocol (FTP) None Yes[e] No No [53][54][55][56][57]
FTP Secure (FTPS) TLS / SSL Yes No No
HTTP Secure (HTTPS) TLS / SSL Yes No No [15][58][59]
Host Unix Linkage File Transfer (HULFT) AES ? No [60][61][62][63]
Hypertext Transfer Protocol (HTTP) None
(see HTTPS and S-HTTP)		 Yes No No [15][64]
Micro Transport Protocol (μTP) None Yes Peer-to-peer No [16]
Multicast Dissemination Protocol (MDP) None Yes Yes [65][66]
Multicast File Transfer Protocol (MFTP) None Yes Yes No [67][68]
NACK-Oriented Reliable Multicast Transport Protocol (NORM) IPsec Yes Yes [69][70]
Odette File Transfer Protocol (OFTP) None Yes [19]
Odette File Transfer Protocol 2 (OFTP2) TLS Yes [20]
Reliable Blast UDP (RBUDP) None No No [21][71][72]
Remote copy (rcp) None No No No [73]
Secure copy (SCP) Secure Shell No No No
Secure Hypertext Transfer Protocol (S-HTTP) CMS / MOSS / other No No No [74]
Simple Asynchronous File Transfer (SAFT) PGP ? No No [25][26][75]
Simple File Transfer Protocol (SFTP) None Yes No No [76]
SSH file transfer protocol (SFTP) Secure Shell Yes No No [77]
T.127 None Yes Yes No [78][79][80]
Trivial File Transfer Protocol (TFTP) None No No No [81]
Tsunami UDP Protocol None No No No [82][83]
Tus open protocol for resumable file uploads (tus) Optional/Unspecified[f] Yes No No [34][35]
UDP-based Data Transfer Protocol (UDT) Experimental No No No [83][84][85]
UDP-based File Transfer Protocol (UFTP) AES-256 / AES-128 / 3DES / DES[g] Yes Yes No [83][36][86]
Unix-to-Unix Copy (UUCP) None Some[h] No No [87][88]
Warp Speed Data Transfer (WDT) AES-128 (OFB / CTR) Yes No No [89][90][91]
  1. ^ TLS when BITS is used with HTTPS, AES-128 when used with SMB 3, none with HTTP or SMB version below 3.0
  2. ^ Some implementations can obfuscate traffic using RC4 et al. See BitTorrent protocol encryption.
  3. ^ RFC 6726 suggests IPSec as one option.
  4. ^ One implementation, Fujitsu openFT, applies AES.
  5. ^ RFC 1123 (1989) extends and corrects the provisions for restart/resume that were published in RFC 959 (1985). RFC 3659 (2007) provides for resuming in stream mode.
  6. ^ It's recommended to use HTTPS provided by a webserver, proxy, or SSL terminator.
  7. ^ These are the options in the reference implementation, which uses OpenSSL.
  8. ^ The BNU implementation of UUCP can resume an interrupted file transfer.

Ports

[edit]

In the table below, the data port is the network port or range of ports through which the protocol transmits file data. The control port is the port used for the dialogue of commands and status updates between client and server.

The column "Assigned by IANA" indicates whether the port is listed in the Service Name and Transport Protocol Port Number Registry, which is curated by the Internet Assigned Numbers Authority (IANA). IANA devotes each port number in the registry to a specific service with a specific transport protocol. The table below lists the transport protocol in the "Transport" column.

Protocol Data port Control port Assigned
by IANA		 Assignee Refs
Server Client Transport Server Client Transport
BITS 80/443[a] / 137–139[b] TCP / UDP No —
BitTorrent 6881[c] 6881 TCP 6881 6881 TCP No — [92]
CCSDS File Delivery Protocol (CFDP)
Cross File Transfer (CFT) 1761[d] TCP / X.25 [41][42]
Ether File Transfer Protocol (EFTP) — — None — — None — —
Fast and Secure Protocol (FASP) ≥33001 UDP 22 TCP No — [92]
File Delivery over Unidirectional Transport (FLUTE) 4001 UDP No — [92]
File Service Protocol (FSP) Chosen by user[e] UDP No — [92]
File Transfer Access and Management (FTAM) 4800 / 102 TCP [93]
File Transfer Protocol (FTP) Active mode 20 20 TCP[f] 21 ≥1024 TCP Yes Jon Postel [92]
Passive mode ≥1024[g] ≥1024
FTP Secure (FTPS) 989 TCP 990 TCP Yes Christopher Allen [92]
HTTP Secure (HTTPS) 443 TCP TCP Yes IESG [92]
Host Unix Linkage File Transfer (HULFT) 30000 TCP TCP No — [92]
Hypertext Transfer Protocol (HTTP) 80 TCP TCP Yes Tim Berners-Lee [92]
Micro Transport Protocol (μTP) UDP No — [92]
Multicast Dissemination Protocol (MDP) Chosen by user UDP [94][66]
Multicast File Transfer Protocol (MFTP) 5402 UDP Yes Steve Bannister [92]
NACK-Oriented Reliable Multicast Transport Protocol (NORM) UDP [69][70]
Odette File Transfer Protocol (OFTP) 3305 TCP / X.25 TCP / X.25 [19]
Odette File Transfer Protocol 2 (OFTP2) 6619 TCP / X.25 TCP / X.25 [20]
Reliable Blast UDP (RBUDP) Chosen by user UDP No — [92]
Remote copy (rcp) 514 TCP TCP Yes [92]
Secure copy (SCP) 22 TCP TCP Yes [92]
Secure Hypertext Transfer Protocol (S-HTTP) 80 TCP TCP No — [92]
Simple Asynchronous File Transfer (SAFT) 487 TCP Yes Ulli Horlacher [92]
Simple File Transfer Protocol (SFTP) 115 TCP TCP Yes Mark Lottor [92]
SSH file transfer protocol (SFTP) 22 TCP TCP Yes [92]
T.127 1503 TCP TCP Yes Jim Johnston [92]
Trivial File Transfer Protocol (TFTP) 69 UDP Yes David Clark [92]
Tsunami UDP Protocol Chosen by user UDP TCP No — [92]
Tus open protocol for resumable file uploads (tus) 80[h] TCP TCP No — [92]
UDP-based Data Transfer Protocol (UDT) Chosen by server UDP No — [92]
UDP-based File Transfer Protocol (UFTP) 1044 UDP No — [92]
Unix-to-Unix Copy (UUCP) 540 TCP TCP Yes [92]
Warp Speed Data Transfer (WDT) Chosen by server or by user TCP TCP No — [92]
  1. ^ When used with HTTP/HTTPS, configurable
  2. ^ When used with SMB
  3. ^ Typically, if port 6881 is unavailable as a listening port, the peer incrementally tries 6882–6889. Another port may be specified in software.
  4. ^ 1761 is the default port, but 1761–1768 are allocated by IANA.
  5. ^ UDP port 21 is sometimes chosen for FSP.
  6. ^ FTP was originally designed for NCP, a protocol used on ARPANET before the advent of TCP. The TCP implementation of FTP was standardized in RFC 959.
  7. ^ The server listens on TCP port 21 (the control port), and the client sends commands to this port from a random port above 1023. To transfer data in active mode, the server initiates a connection from port 20 to the client at the randomly selected port number.
    In passive mode, the client uses a random port above 1023 as a control port, and from this initiates file transfer. The server sends or receives data from a randomly selected port above 1023, and the client sends or receives data from one port number above its own randomly selected control port.
  8. ^ Can be chosen by user, but layers on top of HTTP(S) so often 80/443

Serial protocols

[edit]
A 9-pin to 25-pin RS-232 adapter cable

The following protocols were designed for serial communication, mostly for the RS-232 standard. They are used for uploading and downloading computer files via modem or serial cable (e.g., by null modem or direct cable connection). UUCP is one protocol that can operate with either RS-232 or the Transmission Control Protocol as its transport. The Kermit protocol can operate over any computer-to-computer transport: direct serial, modem, or network (notably TCP/IP, including on connections secured by SSL, SSH, or Kerberos). OBject EXchange is a protocol for binary object wireless transfer via the Bluetooth standard. Bluetooth was conceived as a wireless replacement for RS-232.

Overview

[edit]
Protocol Author First released License Description Refs
BiModem Erik Labs 1989 Bi-directional transfers.
BLAST Communications Research Group 1981 Powerful protocol originating on the Data General Nova minicomputer, and then ported to micros and mainframes. [95]
C-MODEM Lavio Pareschi 1989 Packet lengths from 32 to 4096 bytes, optional (but normally used) streaming mode.
B protocol CompuServe 1981 Offered file transfer as well as a command stream.
JMODEM Richard B. Johnson ? XMODEM derivative with blocks from 512 to 8192 bytes and RLE compression.
HS/Link Samuel H. Smith 1991 [96]
Kermit Frank da Cruz et al. 1981 Open Source (BSD) as of 2011 Transport- and platform-independent transfer of text and binary files across full- or half-duplex connections with conversion of text file formats and character sets. [97]
LeechModem Sam Brown ? Variations of X and Y that faked failed downloads in order to avoid BBS download quotas.
Lynx Matthew Thomas 1989 Similar to Kermit: 64-byte packets, 2 to 16 packets per window, CRC-32. Little or no support outside the Lynx program itself.
NMODEM L. B. Neal 1990 Essentially XMODEM-CRC with 2048 byte blocks.
OBEX File Transfer Protocol ? ? A synchronous file transfer protocol in the OBject EXchange (OBEX) Bluetooth profile.
OBEX Push ? ? An asynchronous file transfer protocol in the OBject EXchange (OBEX) Bluetooth profile. [98]
Punter Steve Punter ? Suite of similar-but-different XMODEM-like protocols for various Commodore machines.
SEAlink Thom Henderson 1986 A MODEM7/XMODEM-compatible protocol with sliding window support developed to avoid propagation delays in satellite transmissions and packet networks. [99][100][101]
SMODEM Arisoft ?
TMODEM Mike Bryeans ?
UUCP Mike Lesk 1979 Suite of protocols for copying files between Unix machines, used for many purposes including the distribution of email. Also allows commands to be sent, which led to the first internet worms. The file transfer protocol within UUCP is the "g" protocol. [102]
MODEM7 Mark M. Zeigler, James K. Mills 1980 Slight extension of XMODEM to add filename support and batch transfers. [103]
XMODEM Ward Christensen 1977 Public domain Very simple protocol that saw widespread use and provided the pattern for many following protocols. [104]
WXMODEM Peter Boswell 1986 Public domain Version of XMODEM with sliding windows for higher performance. [105][106]
YMODEM Chuck Forsberg 1985 Public domain Series of optional expansions on XMODEM for higher performance. [105]
ZMax Mike Bryeans c. 1991 Modifications to ZMODEM to allow packets up to 32 kB in length.
ZMODEM Chuck Forsberg 1986 Public domain Streaming protocol that forsakes XMODEM compatibility but offers a wide variety of new features and improved performance. Became almost universal on BBS systems in the early 1990s. [105]

Features

[edit]
Protocol Data block size
(bytes)		 Data
compression		 Error detection Transfer
resuming		 Bidirectional Sliding window Refs
BiModem Yes
BLAST 84–1024+ RLE CRC Yes Yes Yes [107]
C-MODEM 32–4096 CRC Yes
B protocol 128–2048 CRC-32 / CRC-16 / 8-bit checksum Yes Yes
JMODEM 64–8192 RLE
HS/Link CRC-32 Yes Yes
Kermit ≤9024 (negotiated) RLE (run length encoding, negotiated) Checksum or CRC-16 (negotiated) Yes (binary files only, negotiated) No Over full-duplex only (negotiated) [108]
LeechModem
Lynx RLE CRC-32 Yes
NMODEM 2048
OBject EXchange
Punter
SEAlink Yes Yes
SMODEM Yes
Tmodem No
UUCP "g" ≤4096 No No [109][110]
MODEM7 128 No Checksum Stop-and-wait ARQ
XMODEM 128 No Checksum Stop-and-wait ARQ
WXMODEM ≤512 Yes
YMODEM 1024 No CRC-16
ZMax ≤~32,768 CRC-32
ZMODEM 256 / 1024 No CRC-32 Yes Yes

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Comparison of file transfer protocols

View on Grokipedia
from Grokipedia
File transfer protocols are standardized communication rules designed to facilitate the reliable and efficient exchange of files between computers or devices over networks or direct serial connections. These include both IP-based and serial protocols. Comparisons of these protocols typically examine critical attributes such as (e.g., and methods), (e.g., speed and bandwidth efficiency), ease of implementation (e.g., firewall compatibility and port usage), reliability (e.g., error handling and resume capabilities), and specific use cases like bulk transfers, , or real-time . The most widely discussed protocols in such comparisons include the foundational , defined in RFC 959, which operates over TCP using separate control (port 21) and data (port 20) channels but transmits data in plaintext, making it vulnerable to interception. In response to FTP's security shortcomings, secure alternatives emerged: FTPS (FTP over SSL/TLS) extends FTP by adding encryption layers compliant with TLS standards, preserving compatibility with existing FTP infrastructure while enabling authenticated, encrypted sessions over explicit (ports 21/990 and 20/989) or implicit modes. SFTP (SSH File Transfer Protocol), which operates over SSH (per RFC 4251 architecture) and is specified in IETF drafts, provides robust encryption and authentication via a single port (22), simplifying firewall traversal and supporting advanced file operations like directory management, though it requires SSH infrastructure. Other notable protocols address specialized needs: SCP (Secure Copy Protocol), also SSH-based, prioritizes simplicity for one-off file copies with strong encryption but lacks interactive features like browsing. Rsync, an open-source utility often layered over SSH, excels in efficient synchronization by transferring only file differences (), making it ideal for backups over unreliable connections despite no native encryption. For web-centric transfers, HTTP/HTTPS (RFC 7231) and extensions like WebDAV enable file handling within browsers, with providing TLS encryption for secure, ubiquitous access but potentially lower throughput for large files due to overhead. Niche options like TFTP (Trivial FTP) (RFC 1350) offer lightweight, unauthenticated transfers for simple tasks such as , while enterprise protocols like AS2 (RFC 4130) focus on compliant, encrypted EDI exchanges. In comparisons, FTP is often deemed obsolete for sensitive due to its insecurity, favoring SFTP or for modern secure transfers where SFTP edges out in simplicity and performance on high-latency networks. Protocol choice ultimately depends on factors like sensitivity, network constraints, and regulatory requirements (e.g., HIPAA or GDPR), with managed (MFT) solutions increasingly integrating multiple protocols for centralized control, auditing, and automation.

General concepts

Definition and history

File transfer protocols are standardized sets of rules and conventions that govern the exchange of files between computer systems, either over packet-switched networks or direct serial connections, emphasizing file integrity, resumability, and management features that distinguish them from broader data transfer mechanisms like raw socket streams. These protocols ensure reliable delivery by incorporating error detection, acknowledgments, and sometimes , tailored specifically for file-oriented operations such as upload, download, and directory navigation. The origins of protocols trace back to the early amid the development of the ARPANET, the U.S. Department of Defense's experimental packet-switching network launched in 1969, which necessitated standardized methods for resource sharing across heterogeneous hosts. The File Transfer Protocol (FTP) emerged as the first such protocol, initially specified in RFC 114 in April 1971 by to enable file exchanges between MIT-hosted systems on the ARPANET. This was followed by refinements, including RFC 354 in 1972, which formalized FTP for broader ARPANET use, and RFC 454 in 1973, establishing it as an official specification. Concurrently, serial-based protocols arose for direct modem connections; XMODEM, developed by Ward Christensen in 1977, became one of the earliest widely adopted methods for transferring files between personal computers over dial-up lines, using simple checksums for error detection. The 1980s marked a pivotal integration with the TCP/IP suite, as the transitioned from the Network Control Program (NCP) to TCP/IP on January 1, 1983—known as ""—allowing FTP to leverage reliable transport for internet-scale transfers, as updated in RFC 765 (1980) and standardized in RFC 959 (1985). The 1990s and saw the rise of internet-driven protocols amid growing web adoption, with security becoming paramount; the (SFTP), developed as part of the (SSH) version 2 standard by the IETF SECSH starting in the mid-1990s, provided encrypted file transfers and was first detailed in draft specifications around 2000, with version 3 gaining widespread support by the early . Post-2010, vulnerabilities in legacy protocols like unencrypted FTP—exposed in numerous breaches due to transmission and weak authentication—drove a shift toward secure alternatives, including SFTP and , to mitigate risks in an era of heightened cyber threats. As of 2025, current trends emphasize , integration with for scalable high-speed transfers, and compliance with regulations like GDPR and HIPAA, reflecting the dominance of multi-cloud environments where protocols like SFTP enable secure, automated file handling across distributed systems.

Fundamental principles

File transfer protocols typically employ a client-server to manage the exchange of files, with variations in how communication channels are structured. Some protocols, such as FTP, use separate channels: a control channel for exchanging commands and responses, and a data channel for the actual transfer of file contents. The control channel, often established first, facilitates session initiation through a process involving commands such as user identification and password exchange, ensuring secure session establishment before data transfer begins. In contrast, protocols like SFTP operate over a single provided by SSH, combining control and data operations without separation, which simplifies deployment but requires SSH infrastructure. Data transfer considerations include formatting to handle different file types and ensure compatibility. For example, in FTP, ASCII mode converts text data to a standardized 8-bit network virtual terminal (NVT-ASCII) representation, adjusting end-of-line markers to carriage return-line feed (CRLF) sequences, while binary mode transmits raw data without modification. Other protocols may use different encoding schemes or transfer data in blocks with metadata. To address firewall and , some protocols like FTP support active and passive modes: in active mode, the server initiates the data connection to a client-specified , while passive mode allows the client to connect to a server-listening , reducing the need for inbound server access. Protocols like SFTP avoid such complexities by using a single (typically 22). Reliability in file transfer protocols is achieved through mechanisms that detect and recover from errors or losses during transmission, often leveraging underlying transport protocols or implementing application-level checks. For instance, when using TCP as the , acknowledgment (ACK) packets confirm the receipt of data segments, with the receiver sending an ACK specifying the next expected sequence number to verify ordered delivery. Upon failure to receive an ACK within a calculated retransmission timeout (RTO), the sender retransmits the unacknowledged segments, ensuring complete and accurate file reconstruction at the receiver. Serial protocols like XMODEM use block-based acknowledgments and retransmissions at the application level. Data integrity is protected by checksums, such as CRC-16 in various implementations, which compute the remainder of the data polynomial divided by a generator polynomial like x16+x15+x2+1x^{16} + x^{15} + x^{2} + 1. Flow control principles prevent overwhelming the receiver and manage network resources effectively. When relying on TCP, windowing employs a sliding size advertised by the receiver, limiting the sender to transmitting only within the current of unacknowledged bytes, thereby avoiding buffer overflows by aligning transmission rates with receiver capacity. Throttling adjusts the transmission rate in response to signals, such as duplicate ACKs or timeouts, reducing the size multiplicatively to probe for available bandwidth and prevent further . Application-level protocols may implement additional controls, such as pacing in , to ensure stable transfers across varying network conditions.

IP-based protocols

Overview of common protocols

IP-based file transfer protocols operate over TCP/IP networks, enabling file exchange across local or wide-area connections. They support features like authentication, encryption, and error recovery, making them suitable for modern networked environments from local LANs to internet-based transfers. The foundational , defined in RFC 959, uses separate TCP control (port 21) and data (port 20) channels for command issuance and file transfer, supporting basic operations like upload, download, and directory listing but lacking built-in security. FTPS (FTP Secure) extends FTP with SSL/TLS encryption (RFC 4217), providing explicit (starting with AUTH command on port 21) or implicit (direct TLS on port 990) modes to secure data in transit while maintaining FTP's command structure. SFTP (SSH File Transfer Protocol), part of the SSH-2 protocol suite (RFC 4251), runs over a single SSH connection (port 22), offering encrypted file operations including transfers, directory management, and permissions handling. SCP (Secure Copy Protocol), also SSH-based, focuses on simple, secure file copying between hosts without interactive features like browsing, using the same port 22. WebDAV (Web-based Distributed Authoring and Versioning), defined in RFC 2518 and extended by RFC 4918, builds on HTTP/HTTPS (ports 80/443) to enable collaborative file management, including locking and versioning, integrated with web browsers and tools. SMB (Server Message Block), evolved to SMB 3.x, primarily uses port 445 for direct connections, supporting , printing, and authentication in Windows environments, with Linux support via Samba; it emphasizes persistent shares over networks. These protocols, standardized since the and updated through the , address diverse needs from simple copies to enterprise sharing, with security enhancements driven by evolving threats.

Feature and performance comparison

IP-based file transfer protocols vary significantly in their feature sets, which directly impact for tasks like batch transfers and interrupted session recovery. Common protocols such as FTP, , SFTP, SCP, , and SMB each support different levels of multi-file handling, resumability, and remote directory navigation, influencing their suitability for diverse network environments. For instance, FTP and its secure variants like and SFTP excel in supporting multiple concurrent file operations, while SCP remains more constrained to simpler, single-operation transfers. The following table outlines key feature differences among these protocols, based on their standard implementations:
ProtocolMulti-File SupportResume CapabilityDirectory Listing
FTPYesYes (via command)Yes
FTPSYesYes (via command)Yes
SFTPYesYes (via byte offsets)Yes
SCPLimited (recursive for directories)NoLimited (no native browsing)
Yes (multiple files and folders)Yes (HTTP range requests)Yes
SMBYes (batch sharing)Yes (resilient handles in SMB 3.x)Yes
These features enable protocols like SFTP and to handle complex workflows, such as uploading directories with progress recovery after interruptions, whereas SCP's design prioritizes simplicity over advanced management. Performance in IP-based protocols is largely determined by overhead from connection management and data encoding, with throughput benchmarks on Gigabit Ethernet networks revealing notable disparities. For example, unencrypted FTP can achieve near-line speeds of over 100 MB/s for large files, but SFTP typically ranges from 10-50 MB/s due to SSH encryption processing, while FTPS often outperforms SFTP by 20% in downloads thanks to optimized TLS handling. Recent 2025 tests on high-latency WANs show SCP edging out SFTP for single-file transfers by up to 15% in speed, attributed to reduced protocol commands. WebDAV, leveraging HTTP/2 multiplexing, delivers efficient throughput for multiple small files, often 10-20% faster than FTP in collaborative scenarios, though it lags for bulk uploads. SMB 3.x, with multichannel support, saturates Gigabit links at 90-110 MB/s in local networks but drops to 20-40 MB/s over WANs without QUIC enhancements. Emerging UDP-based variants, such as those inspired by FASP or SMB over QUIC in Windows Server 2025, demonstrate up to 3-100x gains over TCP-based protocols like SFTP on lossy connections by minimizing retransmission delays. Compatibility across platforms further differentiates these protocols, with offering the broadest support through native HTTP integration in browsers and tools like macOS Finder or Windows Explorer, making it ideal for heterogeneous environments. In contrast, SMB remains Windows-centric, though enables /Unix interoperability, supporting seamless in mixed-domain setups. Bandwidth efficiency favors HTTP-based protocols like for small-file transfers, where overhead is under 5% compared to 10-15% for command-heavy FTP on similar payloads. SCP and SFTP, both SSH-derived, provide strong compatibility but require dedicated clients on non- systems. Despite these strengths, limitations persist: FTP's lack of native hinders reliability over unstable links, exposing transfers to interception, while SCP's single-file focus restricts it from efficient directory operations without additional scripting. FTPS and SFTP mitigate some issues but introduce compatibility challenges with legacy firewalls due to requirements. WebDAV's can degrade in non-optimized servers, and SMB's Windows may necessitate extra configuration for cross-platform use, potentially reducing effective throughput by 20-30% in non-native setups.

Security considerations

Security considerations for IP-based file transfer protocols primarily revolve around protecting data in transit and at rest, authenticating users and servers, and mitigating known attack vectors. Protocols like FTP transmit data in , exposing credentials and file contents to , while secure variants such as SFTP and incorporate cryptographic protections to address these risks. SFTP, built on the SSH protocol, employs strong symmetric such as AES-256 in counter (CTR) mode for data confidentiality, with key exchange typically handled via Diffie-Hellman groups to establish session keys securely. integrates TLS for , adhering to TLS 1.3 as the current standard in 2025, which mandates perfect through exchanges like ECDHE to prevent decryption of past sessions even if long-term keys are compromised. In contrast, plain FTP lacks any native , making it highly susceptible to man-in-the-middle (MITM) attacks where attackers can eavesdrop on or alter transmitted files and credentials. Authentication mechanisms vary significantly across these protocols. SFTP and SCP support robust methods including password-based authentication and using algorithms like RSA or Ed25519, where clients prove possession of a private key corresponding to a server-stored public key. leverages TLS for certificate-based authentication, employing certificates to verify server identity and optionally client identity, reducing reliance on shared secrets. However, FTP's basic username-password authentication transmits credentials in cleartext, leading to frequent breaches in the ; for instance, the 2013 Target involved stolen vendor credentials that attackers used to access internal FTP servers, resulting in the compromise of millions of records. Compliance with regulations like GDPR and PCI DSS mandates encryption for file transfers involving personal or cardholder data. Under GDPR Article 32, controllers must implement encryption to secure processing, including data in transit, to mitigate risks of unauthorized access. Similarly, PCI DSS Requirement 4.1 requires strong cryptography, such as TLS 1.2 or higher, for transmitting cardholder data over public networks to prevent interception. In 2025, trends toward zero-trust architectures extend to protocols like SMB 3.1.1, which incorporates mandatory signing using AES-based message authentication to detect tampering and supports encryption for end-to-end protection, aligning with principles of continuous verification in untrusted environments. Notable vulnerabilities highlight the urgency of adopting secure protocols. The 2014 Heartbleed bug (CVE-2014-0160) in allowed attackers to read server memory, potentially exposing private keys and session data in FTPS implementations using vulnerable versions, leading to widespread recommendations for certificate rotation. Additionally, major browsers have deprecated FTP support since 2020 to curb its insecurity; Chrome removed FTP URLs in version 88, citing the lack of and proxy support as key factors. These measures underscore best practices like enforcing encrypted channels and to minimize exposure in IP-based file transfers.

Network ports and configurations

File transfer protocols over IP rely on designated network ports for establishing control and data connections, as standardized by the Internet Assigned Numbers Authority (IANA). These ports ensure interoperability while allowing for secure and reliable communication. The default assignments vary by protocol, with most using TCP for ordered delivery and error recovery. The table below outlines the standard ports for key IP-based file transfer protocols:
ProtocolControl PortData Port(s)Transport ProtocolReference
FTP21 (TCP)20 (TCP)TCPRFC 959
FTPS (Explicit)21 (TCP)Dynamic (passive range)TCP with TLSRFC 4217
FTPS (Implicit)990 (TCP)989 (TCP)TCP with TLSRFC 4217
SFTP/SCP22 (TCP)Integrated over SSHTCPRFC 4251
WebDAV80 (TCP, HTTP) or 443 (TCP, HTTPS)Integrated over HTTP/HTTPSTCP with optional TLSRFC 2518
SMB445 (TCP)IntegratedTCPRFC 1001
Configuration of these protocols involves specifying ports during server setup and client connections, often through configuration files or command-line options. For FTP and , active mode requires the server to initiate the data connection from its port 20 (or equivalent) to a client-specified , which can complicate firewall rules. In contrast, passive mode has the server listen on a designated (typically in the range –) and inform the client via the control channel, allowing the client to initiate the data connection. This passive approach aids firewall and by minimizing unsolicited inbound traffic to clients, as the client controls both control and data connection origins. All major IP-based file transfer protocols employ TCP as the underlying transport for reliability, ensuring ordered packet delivery and retransmission of lost data. Security enhancements, such as TLS wrapping, are applied atop TCP in protocols like (via RFC 4217) and HTTPS-based , encrypting both control and data channels without altering port assignments. An notable exception is the FASP protocol, an UDP-based variant developed for high-speed transfers, which prioritizes throughput over native reliability by implementing custom congestion control and uses UDP port 33001 by default. As of November 2025, IANA port reservations for these protocols remain unchanged and stable, reflecting their long-established standards. Administrators may configure custom ports to mitigate risks from automated scanning of standard assignments, though this practice serves as an obfuscation layer rather than comprehensive protection. Port exposure on public interfaces can amplify attack surfaces, underscoring the need for layered defenses as outlined in security considerations.

Serial protocols

Overview of common protocols

Serial file transfer protocols enable direct, point-to-point data exchange over physical connections like or USB serial ports, without relying on network infrastructure, making them suitable for environments where IP-based methods are impractical or unavailable. These protocols emerged in the era of dial-up modems and early personal computing, prioritizing reliability over speed to handle noisy or low-bandwidth links. Unlike IP protocols that support and concurrent sessions, serial protocols focus on simple, error-checked block transfers between two directly connected devices. One of the earliest serial protocols is XMODEM, developed by Ward Christensen in 1977 as part of his MODEM.ASM terminal program for the operating system. It operates by dividing files into 128-byte blocks, appending a simple for error detection, and retransmitting failed blocks upon negative acknowledgment from the receiver, ensuring basic integrity over unreliable serial lines. XMODEM's straightforward design made it widely implemented in early bulletin board systems (BBS) and terminal software. YMODEM, introduced in the early by Forsberg as an extension of XMODEM, added support for transfers and larger 1K-byte blocks to improve efficiency. It includes a header block with file metadata such as name, size, and , allowing multiple files to be sent in a single session, and uses (CRC) for enhanced error detection over the basic of XMODEM. This made YMODEM popular for transferring multiple small files in modem-based environments. ZMODEM, also developed by Chuck Forsberg in 1986, advanced serial transfers with streaming capabilities and crash recovery features, enabling resumption from the point of interruption without restarting the entire file. It employs variable-length blocks up to 1K bytes, 32-bit CRC for robust error checking, and a full-duplex mechanism for faster acknowledgments, achieving higher throughput on reliable connections while maintaining compatibility with noisy ones. ZMODEM became a standard in BBS software due to its balance of speed and reliability. Kermit, originating in the early 1980s at , was designed for robust transfers over highly error-prone connections like telephone lines or early networks. It uses short, variable-length packets with strong sliding-window flow control and to compress data, making it particularly effective for noisy serial environments; the protocol was later standardized in part through RFC 2839 for extensions. Kermit's emphasis on adaptability and security features, such as in later versions, distinguished it from simpler protocols. These asynchronous protocols, including XMODEM, YMODEM, ZMODEM, and Kermit, were historically dominant in dial-up modem communications and early embedded systems for tasks like updates or data logging. Their use declined after the 1990s with the rise of TCP/IP networks, but they persist in niche applications as of 2025, such as serial debugging in IoT devices and resource-constrained microcontrollers where direct cabling avoids network overhead. While synchronous variants like BISYNC (Binary Synchronous Communication) employ HDLC-inspired framing for clocked serial links in industrial settings, the asynchronous protocols remain prevalent for their simplicity in ad-hoc connections.

Feature comparison

Serial file transfer protocols, such as XMODEM, ZMODEM, and Kermit, are designed for point-to-point transfers over serial connections, differing in their operational attributes to balance reliability, efficiency, and compatibility in low-bandwidth environments. These protocols emerged in the late 1970s and as solutions for transferring files between computers lacking network capabilities, with XMODEM providing a simple checksum-based approach, ZMODEM introducing streaming for higher throughput, and Kermit emphasizing cross-platform file attribute handling. Key attributes vary significantly, as summarized in the table below, highlighting differences in block handling, achievable speeds, and session capabilities.
ProtocolBlock SizeTypical Speed (Baud Rate)Multi-Session Support
XMODEM128 bytesUp to 115,200 No
ZMODEMVariable (up to 1 KB)Up to 115,200 Yes
KermitVariable (up to 9 KB)Up to 115,200 Yes
XMODEM employs fixed 128-byte blocks for straightforward implementation, while ZMODEM and Kermit support larger, variable blocks to reduce overhead on higher-speed links. All three protocols operate at baud rates up to 115,200, the practical limit for standard serial interfaces, though actual throughput is constrained by protocol overhead. Kermit uniquely enables multi-session transfers through its server mode, allowing batch handling of multiple files without manual intervention per file, unlike the single-file focus of XMODEM; ZMODEM also supports batch transfers for multiple files. In terms of usability, ZMODEM offers an advantage with auto-start detection, where the sender can initiate transfers without requiring the receiver to explicitly invoke the protocol, streamlining operations in terminal environments. Kermit excels in preserving , including timestamps and permissions, and supports transfers to handle without corruption on connections with parity bits. These protocols depend on hardware like serial ports or USB-to-serial adapters, often requiring null-modem cables to cross transmit and receive lines for direct device-to-device connections. In 2025, they remain relevant for legacy hardware, such as CNC machines that rely on serial interfaces for program uploads in industrial settings where modern networking is absent or impractical. A primary limitation is the absence of native , exposing transfers to on untrusted links, as these protocols predate widespread concerns. Additionally, their low throughput—capped at approximately 14 KB/s on standard 115,200 serial connections due to overhead and line delays—makes them unsuitable for large files in contemporary applications.

Error handling and reliability

Serial file transfer protocols employ various checksum methods to detect transmission errors over noisy physical connections, such as lines, where bit flips or dropouts are common due to electrical interference or signal degradation. XMODEM uses an 8-bit arithmetic , computed as the sum of all data bytes 256, which provides basic error detection but misses certain multi-bit errors. YMODEM improves upon this with a 16-bit CRC using the 0x1021 (x^{16} + x^{12} + x^5 + 1), offering higher integrity by detecting nearly all single- and double-bit errors as well as most burst errors up to 17 bits. ZMODEM further enhances reliability with a 32-bit CRC applied to each block, significantly reducing the probability of undetected errors to approximately one in four billion bits transmitted. For recovery from detected errors, these protocols rely on block-level acknowledgments and retransmissions. In XMODEM and , the receiver sends a negative acknowledgment (NAK) upon failure, prompting the sender to retransmit the erroneous block, with a typical limit of 10 retries before aborting the transfer. ZMODEM employs a sliding window mechanism for more efficient recovery, allowing multiple blocks to be sent before acknowledgment while using NAKs or position requests (ZRPOS) to retransmit only affected segments, minimizing idle time on high-latency links. Kermit uses timeout-based recovery, with a configurable default of 5 seconds per packet; if no acknowledgment arrives, the sender retransmits, and the protocol supports up to 5 retries per packet before notification. To tolerate noise and connection instability, Kermit stands out with support for long packets up to 9024 bytes, verified by a single CRC-16 at the end (Type 3 ), though it lacks explicit sliding checksums within packets; instead, it uses to compress repeated characters and reduce exposure to errors. Kermit also features auto-baud rate sensing during initialization, adapting to line speeds without manual configuration, which aids reliability over varying . For handling line drops, Kermit provides session resumption in its server mode, allowing interrupted transfers to restart from the last acknowledged packet upon reconnection, unlike the stop-and-restart approach of XMODEM or . ZMODEM similarly supports crash recovery, resuming at a specified file offset after interruptions. As of 2025, these serial protocols are rarely used in modern networking due to the prevalence of higher-speed IP-based alternatives, but they remain emulated in software tools for vintage computing enthusiasts restoring legacy systems like or early PCs, where physical serial interfaces are still employed for authenticity.

References

  1. https://www.goanywhere.com/blog/compare-the-top-file-transfer-protocols
  2. https://www.cerberusftp.com/blog/every-file-transfer-protocol-explained/
  3. https://datatracker.ietf.org/doc/html/rfc959
  4. https://www.jscape.com/blog/understanding-key-differences-between-ftp-ftps-and-sftp
  5. https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13
  6. https://www.couchdrop.io/learn/what-is-sftp-and-how-are-ftp-sftp-scp-and-rsync-different
  7. https://rsync.samba.org/
  8. https://datatracker.ietf.org/doc/html/rfc7231
  9. https://datatracker.ietf.org/doc/html/rfc1350
  10. https://datatracker.ietf.org/doc/html/rfc4130
  11. https://www.rfc-editor.org/rfc/rfc114.html
  12. https://www.rfc-editor.org/rfc/rfc354.html
  13. https://www.historyofinformation.com/detail.php?id=4992
  14. https://www.internetsociety.org/blog/2016/09/final-report-on-tcpip-migration-in-1983/
  15. https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer
  16. https://www.ibm.com/think/topics/file-transfer
  17. https://www.techradar.com/best/secure-file-transfer-solutions
  18. https://www.ietf.org/rfc/rfc9293.html
  19. https://erg.abdn.ac.uk/users/gorry/eg3576/crc.html
  20. https://www.ietf.org/rfc/rfc793.txt
  21. https://datatracker.ietf.org/doc/html/rfc4217
  22. https://datatracker.ietf.org/doc/html/rfc4251
  23. https://www.openssh.com/manual.html
  24. https://datatracker.ietf.org/doc/html/rfc4918
  25. https://datatracker.ietf.org/doc/html/rfc1001
  26. https://www.integrate.io/blog/the-complete-guide-to-ftp-ftps-sftp-and-scp/
  27. https://www.cerberusftp.com/blog/which-file-transfer-protocol-should-you-support/
  28. https://longsight.screenstepslive.com/s/sakai_help/m/90033/l/1124660-how-do-i-transfer-files-to-resources-using-webdav
  29. https://www.theknowledgeacademy.com/blog/what-is-samba-server/
  30. https://sftptogo.com/blog/sftp-vs-ftps-benchmarks/
  31. https://serverfault.com/questions/559501/ftp-ftps-sftp-scp-speed-comparison
  32. https://sftpcloud.io/learn/ftp/ftp-vs-webdav
  33. https://docs.netapp.com/us-en/ontap/smb-hyper-v-sql/configure-smb-multichannel-performance-task.html
  34. https://blog.axway.com/product-insights/managed-file-transfer/transfer-cft/transfer-cft-speed-benchmarks
  35. https://newsblaze.com/business/security/cifs-vs-smb-in-2025-which-network-protocol-should-you-use-for-file-sharing_207810/
  36. https://www.myworkdrive.com/blog/webdav-vs-ftp
  37. https://datatracker.ietf.org/doc/html/rfc4253
  38. https://www.commerce.senate.gov/services/files/24d3c229-4f2f-405d-b8db-a3a67f183883
  39. https://gdpr-info.eu/art-32-gdpr/
  40. https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf
  41. https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-security
  42. https://techcommunity.microsoft.com/blog/filecab/configure-smb-signing-with-confidence/2418102
  43. https://developer.chrome.com/blog/chrome-88-deps-rems
  44. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
  45. https://www.ibm.com/docs/en/aspera-connect/4.2.x?topic=configuration-network
  46. https://learn.microsoft.com/en-us/answers/questions/2279799/opening-a-port-on-my-router-is-it-safe
  47. https://www.embedded.com/serial-protocols-compared/
  48. https://jacobfilipp.com/DrDobbs/articles/CUJ/1990/9009/ward/ward.htm
  49. http://moscova.inria.fr/~doligez/zmodem/ymodem.txt
  50. https://documentation.help/SecureCRT/Overview_of_Ymodem.htm
  51. https://www.tuhs.org/Usenet/comp.sources.unix/1986-May/004372.html
  52. https://wiki.preterhuman.net/ZMODEM_PROTOCOL_REFERENCE
  53. https://www.columbia.edu/kermit/about.html
  54. https://kermitproject.org/onlinebooks/usingckermit3e.pdf
  55. https://datatracker.ietf.org/doc/html/rfc2839
  56. https://www.columbia.edu/kermit/faq-c-zmo.html
  57. https://www.geeksforgeeks.org/computer-networks/difference-between-bisync-and-hdlc-features/
  58. https://www.adontec.com/xmodem-protocol.htm
  59. https://www.kermitproject.org/kproto.pdf
  60. https://d1.amobbs.com/bbs_upload782111/files_47/ourdev_694606WMEA1R.pdf
  61. https://www.kermitproject.org/perf.html
  62. https://www.startech.com/en-us/cards-adapters/icusb232ftn
  63. https://www.gdcompt.com/news/serial-ports-explained/
  64. https://techheap.packetizer.com/communications/modems/xmodem-ymodem_reference.html
  65. https://b0b.com/ZMODEM.TXT
Add your contribution
Related Hubs
User Avatar
No comments yet.