So TCP is connection oriented. We have acknowledgments. If the transmission is lost, we should be able to continue it.
"Orientado para conexão" não significa automaticamente que as transferências usando-o podem ser retomadas. "Orientado para conexão" significa simplesmente que os aplicativos que usam TCP podem usá-lo como um "canal" - ou seja, enviar mensagens de comprimento arbitrário para o outro lado e, em seguida, o TCP garantirá que a mensagem chegue lá (retransmitindo se ocorrerem erros) na mesma ordem ela foi enviada. Se uma conexão TCP expira porque um lado pára de transmitir por qualquer razão (isto é, eles perderam sua conexão com a Internet, travaram, etc.), uma segunda conexão TCP em si não necessariamente sabe nada sobre o primeiro. O software aplicativo usando conexões TCP para transferir dados em ambos os lados teria que acompanhar isso e dar suporte a isso iniciando uma nova conexão.
But my problem is, when we are downloading a file such as MP3, if the connection is lost, we need to download the file again. So then isn't it using the FTP protocol?
Eu não sei porque você está pensando que, se algo precisa ser baixado novamente, ele deve estar usando o FTP. O HTTP suporta a retomada de downloads interrompidos, mas o servidor, além do cliente, precisa suportá-lo. Nem todos os clientes e servidores suportarão todos os recursos de todos os protocolos em todos os momentos. HTTP por exemplo - normalmente você pode retomar um download interrompido, mas alguns servidores não permitem isso.
Isn't it TCP? So if it is UDP, can you please explain what kind of protocol is that? TFTP ? I have no idea.
O fato de que os downloads podem ser retomados ou não tem nada a ver com a identificação do protocolo. Existem muitos protocolos que se comportam dessa maneira, e apenas porque o seu download se comportou dessa maneira não significa que um protocolo específico estava em uso.