Programing

SFTP를 통해 파일을 전송할 때 FTP보다 시간이 오래 걸리는 이유는 무엇입니까?

lottogame 2020. 12. 28. 07:45
반응형

SFTP를 통해 파일을 전송할 때 FTP보다 시간이 오래 걸리는 이유는 무엇입니까?


수동으로 파일을 서버에 복사하고 동일한 파일을 SFTP 서버에 복사합니다. 파일은 140MB입니다.

FTP : 11MB / s의 속도가 있습니다.

SFTP : 속도가 4.5MB / s입니다.

파일을 보내기 전에 암호화해야한다는 것을 이해합니다. 파일 전송에 대한 유일한 영향입니까? (실제로 이것은 정확히 전송 시간이 아니라 암호화 시간입니다).

나는 그런 결과에 놀랐다.


저는 HPN-SSH의 저자이고 여기에 댓글을 달아 달라는 요청을 받았습니다. 몇 가지 배경 항목부터 시작하겠습니다. 먼저 SSHv2는 다중 프로토콜 (단일 TCP 연결을 통한 다중 채널)이라는 점을 명심하는 것이 중요합니다. 따라서 SSH 채널은 기본적으로 TCP에서 사용하는 기본 흐름 제어 알고리즘을 인식하지 못합니다. 이는 SSHv2가 자체 흐름 제어 알고리즘을 구현해야 함을 의미합니다. 가장 일반적인 구현은 기본적으로 슬라이딩 윈도우를 다시 구현합니다. 즉, TCP 슬라이딩 창 위에 SSH 슬라이딩 창이 있습니다. 최종 결과는 수신 버퍼의 유효 크기가 두 슬라이딩 윈도우의 수신 버퍼 중 최소 크기라는 것입니다. Stock OpenSSH의 최대 수신 버퍼 크기는 2MB이지만 실제로는 ~ 1.2MB에 가까워집니다. 대부분의 최신 OS에는 최대 4MB의 유효 크기까지 확장 할 수있는 버퍼가 있습니다 (자동 조정 수신 버퍼 사용). 이것이 왜 중요합니까? 수신 버퍼 크기가 대역폭 지연 제품 (BDP)보다 작 으면 시스템 속도에 관계없이 파이프를 완전히 채울 수 없습니다.

이는 SFTP가 TCP 및 SSH 흐름 제어에 흐름 제어의 다른 계층을 추가한다는 사실로 인해 복잡합니다. SFTP는 미해결 메시지 개념을 사용합니다. 각 메시지는 명령, 명령의 결과 또는 대량 데이터 흐름 일 수 있습니다. 미해결 메시지는 특정 데이터 그램 크기까지 될 수 있습니다. 따라서 또 다른 수신 버퍼로 생각할 수있는 것으로 끝납니다. 이 수신 버퍼의 크기는 데이터 그램 크기 * 최대 미해결 메시지 (둘 다 명령 줄에서 설정할 수 있음)입니다. 기본값은 32k * 64 (2MB)입니다. 따라서 SFTP를 사용할 때 TCP 수신 버퍼, SSH 수신 버퍼 및 SFTP 수신 버퍼가 모두 충분한 크기인지 확인해야합니다 (너무 크지 않거나 대화 형 세션에서 오버 버퍼링 문제가 발생할 수 있음).

HPN-SSH는 최대 버퍼 크기가 약 16MB이므로 SSH 버퍼 문제를 직접 해결합니다. 더 중요한 것은 TCP 연결의 버퍼 크기에 대한 proc 항목을 폴링하여 버퍼가 동적으로 적절한 크기로 커진다는 것입니다 (기본적으로 레이어 3과 4 사이에 구멍을 뚫음). 이는 거의 모든 상황에서 오버 버퍼링을 방지합니다. SFTP에서는 처리되지 않은 요청의 최대 수를 256 개로 늘 렸습니다. 적어도 그렇게해야합니다. 변경 사항이 6.3 패치 세트에 예상대로 전파되지 않은 것 같습니다 (6.2에 있지만 곧 수정하겠습니다. ). 6.3 패치가 6.4 (6.3의 한 줄 보안 수정)에 대해 깔끔하게 패치되기 때문에 6.4 버전이 없습니다. sourceforge에서 패치 세트를 얻을 수 있습니다.

나는 이것이 이상하게 들리지만 버퍼 크기를 올바르게 조정하는 것이 성능 측면에서 가장 중요한 변경 사항이라는 것을 알고 있습니다. 많은 사람들이 암호화가 대부분의 경우 성능 저하의 실제 원인 아니라고 생각하지만, 점점 더 멀리 떨어져있는 소스로 데이터를 전송하여이를 스스로 증명할 수 있습니다 (RTT 측면에서). RTT가 길수록 처리량이 낮아집니다. 이는 이것이 RTT 종속 성능 문제임을 분명히 나타냅니다.

어쨌든,이 변경으로 저는 최대 2 배의 향상을보기 시작했습니다. TCP를 이해한다면 이것이 왜 그런 차이를 만들 었는지 이해할 것입니다. 데이터 그램의 크기 나 패킷 수 등이 아닙니다. 네트워크 경로를 효율적으로 사용 하려면 두 호스트간에 전송할 수있는 데이터 양과 동일한 수신 버퍼가 있어야 하기 때문에 전체 입니다. 이것은 또한 경로가 충분히 빠르고 충분히 길지 않으면 개선되지 않을 수도 있음을 의미합니다. BDP가 1.2MB 미만인 경우 HPN-SSH는 가치가 없을 수 있습니다.

병렬화 된 AES-CTR 암호는 종단 간 전체 암호화가 필요한 경우 다중 코어가있는 시스템에서 성능을 향상시킵니다. 일반적으로 대부분의 데이터가 그다지 민감하지 않기 때문에 NONE 암호 스위치 (암호화 된 인증, 대량 데이터 전달)를 사용하는 사람 (또는 서버와 클라이언트 모두를 제어 할 수 있음)을 제안합니다. 그러나 이것은 SCP와 같은 비대화 형 세션에서만 작동합니다. SFTP에서는 작동하지 않습니다.

다른 성능 향상도 있지만 버퍼의 적절한 크기와 암호화 작업만큼 중요한 것은 없습니다. 여유 시간이 생기면 아마도 HMAC 프로세스 (현재 성능에 가장 큰 영향을 미침)를 파이프 라인하고 약간의 최적화 작업을 수행 할 것입니다.

그렇다면 HPN-SSH가 너무 훌륭하다면 OpenSSH가 채택하지 않은 이유는 무엇입니까? 그것은 긴 이야기이고 OpenBSD 팀을 아는 사람들은 아마도 이미 답을 알고있을 것입니다. 나는 그들의 많은 이유를 이해합니다. 이것은 그들의 끝에서 추가 작업이 필요한 큰 패치이고 (그리고 그들은 작은 팀입니다), 그들은 보안만큼 성능에 관심이 없습니다 (HPN-SSH에 대한 보안 영향은 없지만 ) 등. 그러나 OpenSSH는 HPN-SSH를 사용하지 않지만 Facebook은 사용합니다. Google, Yahoo, Apple, 가장 큰 규모의 연구 데이터 센터, NASA, NOAA, 정부, 군대 및 대부분의 금융 기관도 마찬가지입니다. 이 시점에서 꽤 잘 조사되었습니다.

질문이있는 사람이 있으면 언제든지 질문 할 수 있지만이 포럼에 대한 최신 정보를 얻지 못할 수 있습니다. 언제든지 HPN-SSH 이메일 주소 (google it)를 통해 메일을 보낼 수 있습니다.


업데이트 : 댓글 작성자가 지적했듯이 아래에 요약 한 문제는이 게시물 이전에 수정되었습니다. 그러나 나는 HP-SSH 프로젝트에 대해 알고 있었고 저자에게 의견을 물었습니다. 그들이 (정당하게) 가장 찬성 된 답변에서 설명했듯이 암호화는 문제의 원인 아닙니다 . 이메일과 나보다 똑똑한 사람들에게 예이!

오답 밖에없는 1 년 된 질문입니다. 그러나 동일한 질문을했을 때 속도 저하가 암호화 때문이라고 가정했음을 인정해야합니다. 그러나 다음 논리적 질문을 스스로에게 물어보십시오. 컴퓨터가 데이터를 얼마나 빨리 암호화하고 해독 할 수 있습니까? 속도가 OP (.5625MB 또는 5.5 "플로피 디스크 용량의 절반 !)에서 보고 한 4.5Mb / 초 근처라고 생각되면 몇 번이나 커피를 마시고 같은 질문을 다시 한 번 해보십시오. .

그것은 분명히 패킷 크기 선택에서 감독해야 할 양과 관련이 있거나 적어도 LIBSSH2 작성자가 말한 것입니다 .

SFTP의 특성과 전송하는 모든 작은 데이터 청크에 대한 ACK는 대기 시간이 긴 네트워크를 통해 데이터를 전송할 때 초기 순진한 SFTP 구현에 심각한 문제를 야기합니다. 각 32KB의 데이터에 대해 수백 밀리 초를 기다려야한다면 빠른 SFTP 전송은 없을 것입니다. 이런 종류의 순진한 구현은 libssh2 1.2.7까지 libssh2가 제공 한 것입니다.

따라서 속도 저하는 작은 패킷 크기 x 각 패킷에 대한 필수 ack 응답으로 인한 것입니다.

고성능 SSH / SCP (HP-SSH) 프로젝트는 분명히 암호화를 병렬화뿐만 아니라 내부 버퍼를 개선하는 OpenSSH의 패치 세트를 제공합니다. 그러나 병렬화되지 않은 버전도 일부 댓글 작성자가 얻은 암호화되지 않은 속도 인 40Mb / s 이상의 속도로 실행되었습니다. 수정은 OpenSSH가 암호가 아닌 암호화 라이브러리를 호출하는 방식을 변경하는 것과 관련이 있으며 AES128과 AES256 사이에 속도 차이가 없습니다. 암호화에는 시간 걸리지 만 한계가 있습니다. 90 년대에 문제가되었을 지 모르지만 (Java와 C의 속도처럼) 더 이상 중요하지 않습니다.


SFTP 전송 속도에 영향을 미치는 여러 요소 :

  1. 암호화. 대칭 암호화는 빠르지 만 눈에 띄지 않는 것은 그렇게 빠르지 않습니다. 고속 네트워크 (100mbit 이상)에서 속도를 비교하면 암호화가 프로세스의 중단이됩니다.
  2. 해시 계산 및 확인.
  3. 버퍼 복사. SSH 위에서 실행되는 SFTP는 최상의 경우 데이터를 전혀 복사하지 않고 네트워크 인터페이스로 전달할 수있는 일반 FTP에 비해 각 데이터 블록이 최소 6 회 (각면에 3 회) 더 많이 복사됩니다. 그리고 블록 복사도 약간의 시간이 걸립니다.

암호화에는 CPU뿐만 아니라 네트워크 오버 헤드도 있습니다.


이것을 할 수있는 모든 종류의 일이 있습니다. 한 가지 가능성은 "트래픽 쉐이핑"입니다. 이는 일반적으로 업무상 중요한 활동을 위해 대역폭을 예약하기 위해 사무실 환경에서 수행됩니다. 매우 유사한 이유로 웹 호스팅 회사 또는 ISP에서 수행 할 수도 있습니다.

집에서도 아주 간단하게 설정할 수 있습니다.

예를 들어 FTP에 대해 최소 대역폭을 예약하는 규칙이있는 반면 SFTP는 "기타 모든"규칙에 해당 할 수 있습니다. 또는 SFTP에 대한 대역폭 제한 규칙이있을 수 있지만 다른 사람도 사용자와 동시에 SFTP를 사용하고 있습니다.

그래서 : 어디에서 파일을 전송하고 있습니까?


SFTP는 SSH를 통한 FTP가 아니며 다른 프로토콜이며 SCP와 유사하며 더 많은 기능을 제공 합니다 .


비교를 위해 Raring Ringtail Ubuntu alpha 2 라이브 CD를 실행하는 i5 노트북에서 Ubuntu 12.04.1을 실행하는 i7 데스크톱으로 299GB ntfs 디스크 이미지를 전송 해 보았습니다. 보고 된 속도 :

Wi-Fi + 전력선 사용 : scp : 5MB / 초 (40Mbit / 초)

기가비트 이더넷 + 넷기어 G5608 v3 :

scp : 44MB / 초

sftp : 47MB / 초

sftp -C : 13MB / 초

So, over a good gigabit link, sftp is slightly faster than scp, 2010-era fast CPUs seem fast enough to encrypt, but compression isn't a win in all cases.

Over a bad gigabit ethernet link, though, I've had sftp far outperform scp. Something about scp being very chatty, see "scp UNBELIEVABLY slow" on comp.security.ssh from 2008: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/ldPV3msFFQw http://fixunix.com/ssh/368694-scp-unbelievably-slow.html


Your results make sense. Since FTP operates over a non-encrypted channel it is faster than SFTP (which is subsystem on top of the SSH version 2 protocol). Also remember that SFTP is a packet based protocol unlike FTP which is command based.

Each packet in SFTP is encrypted before being written to the outgoing socket from the client and subsequently decrypted when received by the server. This of-course leads to slow transfer rates but very secure transfer. Using compression such as zlib with SFTP improves the transfer time but still it won't be anywhere near plain text FTP. Perhaps a better comparison is to compare SFTP with FTPS which both use encryption?

Speed for SFTP depends on the cipher used for encryption/decryption, the compression used e.g. zlib, packet sizes and buffer sizes used for the socket connection.


SFTP will almost always be significantly slower than FTP or FTPS (usually by several orders of magnitude). The reason for the difference is that there is a lot of additional packet, encryption and handshaking overhead inherent in the SSH2 protocol that FTP doesn't have to worry about. FTP is a very lean and comparatively simple protocol with almost no data transfer overhead, and the protocol was specifically designed for transferring files quickly. Encryption will slow FTP down, but not nearly to the level of SFTP.

SFTP runs over SSH2 and is much more susceptible to network latency and client and server machine resource constraints. This increased susceptibility is due to the extra data handshaking involved with every packet sent between the client and server, and with the additional complexity inherent in decoding an SSH2 packet. SSH2 was designed as a replacement for Telnet and other insecure remote shells, not for very high speed communications. The flexibility that SSH2 provides for securely packaging and transferring almost any type of data also contributes a great deal of additional complexity and overhead to the protocol.

However, it is still possible to get a data transfer rate of several MB/s between client and server using SFTP if the right network conditions are present. The following are items to check when trying to maximize SFTP transfer speeds:

Is there a firewall or network device inspecting or throttling SSH2 traffic on your network? That might be slowing things down. Check you firewall settings. We've had users report solving extremely slow SFTP file transfers by modifying their firewall rules. The SFTP client you use can make a big difference. Try several different SFTP clients and see if you get different results. Network latency will drastically affect SFTP. If the link you are on has a high degree of latency then that is going to be a problem for fast transfers. How powerful is the server machine? Encryption with SFTP is very intensive. Make sure you have a sufficiently powerful machine that isn't being overtaxed during SFTP file transfers (high CPU utilization).

See more: https://support.cerberusftp.com/hc/en-us/articles/203333215-Why-is-SSH2-SFTP-so-much-slower-than-FTP-and-FTPS-


Yes, encryption add some load to your cpu, but if your cpu is not ancient that should not affect as much as you say.

If you enable compression for SSH, SCP is actually faster than FTP despite the SSH encryption (if I remember, twice as fast as FTP for the files I tried). I haven't actually used SFTP, but I believe it uses SCP for the actual file transfer. So please try this and let us know :-)

ReferenceURL : https://stackoverflow.com/questions/8849240/why-when-i-transfer-a-file-through-sftp-it-takes-longer-than-ftp

반응형