이것은 이상한 질문입니다.
FTP 서버로 vsftpd를 실행하는 centOS 7 기반 서버가 있습니다.
filezilla를 사용하여 centOS 상자에서 로컬 클라이언트로 파일을 복사하는 경우 약 128MB 중 몇 MB(때때로 그 이하)가 전송된 후 전송이 실패합니다.
그런 다음 CentOS 서버에 SSH를 통해 로그인한 다음 filezilla를 사용하기 전과 마찬가지로 FTP 다운로드를 반복하면 파일 전송이 완전하고 빠릅니다.
SSH를 통해 서버에 연결하는 것이 FTP 전송에 영향을 미치는 이유를 평생 알 수 없습니다. 누구든지 이 동작에 대한 이유를 생각할 수 있습니까?
답변1
FTP 전송이 서버에 대한 SSH 세션을 열 때만 작동한다면 다음과 같은 이유 때문일 수 있습니다.
방화벽 또는 보안 설정: 서버의 방화벽 또는 보안 설정에서 SSH 연결은 허용하지만 FTP는 허용하지 않을 수 있습니다. FTP 트래픽이 허용되는지 확인하려면 서버 구성을 확인해야 합니다.
포워드 포트: FTP는 데이터 및 제어 연결에 서로 다른 포트를 사용합니다. 서버가 NAT 라우터 뒤에 있는 경우 FTP 연결을 허용하도록 포트 전달을 설정해야 할 수도 있습니다.
수동 FTP: 수동 FTP를 사용하는 경우 특정 범위의 포트를 사용하도록 FTP 클라이언트를 구성해야 할 수도 있습니다. 서버의 수동 FTP 설정을 확인하고 클라이언트가 그에 따라 설정되었는지 확인하세요.
서버 구성: 컴퓨터의 FTP 서버에 문제를 일으키는 특정 구성 설정이 있을 수 있습니다. 잠재적인 문제를 식별하려면 FTP 서버의 설정과 로그를 확인하세요.
사용자 권한: FTP에 사용하는 사용자 계정에 파일 액세스 및 전송에 필요한 권한이 있는지 확인하십시오. SSH 세션에는 기본적으로 다른 권한이 부여될 수 있습니다.
SSH 세션을 열지 않고 FTP 전송이 실패하는 이유를 확인하려면 이러한 영역을 조사하고 이에 따라 서버 또는 클라이언트 구성을 조정해야 합니다.
답변2
활동이 없어 방화벽이 연결을 끊었을 가능성이 높습니다.
FTP 클라이언트는 파일 전송 중에 서버에 아무 것도 보낼 필요가 없습니다. 물론 클라이언트는 수신된 모든 데이터 청크에 대해 TCP ACK를 보냅니다. 그러나 문제는 FTP가 두 개의 채널(데이터용 채널과 명령용 채널)을 사용한다는 것입니다. 후자는 전송 중에 침묵을 유지합니다.
따라서 파일이 매우 크면 전송하는 데 오랜 시간이 걸리고 지나치게 열성적인(그리고 멍청한) 방화벽은 명령 채널이 죽었다고 생각하여 이를 "닫을" 것입니다(아마도 전통적인 방식이 아닐 수도 있음 = 때로는 작동을 중지할 수도 있음) 어느 쪽도 이를 인식하지 못한 채 NAT에 접속하면 데이터 전송이 최종적으로 완료되지 않습니다.
해결책? 연결 유지를 사용하세요. TCP 연결 유지 또는 애플리케이션 계층 연결 유지(작업 명령 없음).
FileZilla에 연결 유지 옵션이 있는 것을 봤습니다.설정->연결->FTP->FTP 연결 유지 명령 보내기. 한번 시도해 보세요(그러나 빈도에 대한 설정이 표시되지 않으며 너무 짧아질 수 있습니다).
SSH 연결로 인해 연결이 끊어지는 것을 방지하는 이유는 미스터리이므로 처음에 연결을 끊는 사람에게 물어봐야 합니다(예: 어떤 기준에 따라?).
마지막으로 Chris Davies의 의견에서 알 수 있듯이 scp, sftp, ssh+tar 또는 ssh+rsync를 사용하면 하나의 채널만 사용하고 유연한 연결 유지 메커니즘을 통합하므로 이러한 골치 아픈 일을 피할 수 있습니다.