TFTP

It was built so a diskless machine could pull a boot image. It is not a sharing product, and it is not FTP with the security removed as an afterthought. The security was never there.

The exchange is short. The client sends a read or write request to port 69. The server answers from a new port. Data blocks are 512 bytes, the last block is shorter, and each block waits for an acknowledgement before the next is sent. There is no directory listing, no password, and no TLS. Anyone who can reach the server can request a file the server is willing to serve. That is why production networks keep TFTP off the public internet and pointed at a dedicated boot directory.

A phone boots, has no operating system, and sends a TFTP read for `phone-sip.cfg` to a local server. The server returns 40 blocks. One block is lost. The client retransmits the acknowledgement, the server resends that block, and the phone writes the file and boots. The same pattern fails a 4 GB video. At one block outstanding, a 50 ms round trip caps the rate near 512 bytes per 50 ms, about 80 kilobits per second, before you count loss. Operators who "just TFTP the build" across a campus wait all afternoon and still have no checksum stronger than the block retransmission.

TFTP is the wrong tool for client delivery, expiring links, or anything confidential. FTP at least has an account. SFTP has SSH. TFTP has a filename. If a vendor still says TFTP for firmware inside a closed VLAN, that matches the original job. If they say TFTP for a customer handoff, they are naming the wrong protocol.