FTP 접속이 느립니다.
글쓴이: xinherjar / 작성시간: 금, 2003/07/18 - 11:38오전
FTP 접속으로 하면 서버접속화면에서 로긴창이 나오기까지 약 20초 걸리네요.
이번에 한국통신 VDSL로 바꾸고 나서 생긴 현상입니다.
(기존에는 삼성APT 전용 랜선을 이용하고 있었는데 접속이 아주 빨랐습니다.)
혹시 VDSL 을 사용하시는 분중에 이런 경험 있으신 분 없습니까 ?
서버환경은 레드햇7.3이고 wu-ftp를 사용하고 있습니다.
유동ip이지만, 고정ip로 포워딩서비스를 이용하고 있고,(www.nameip.co.kr)
한통은 대부분의 포트를 다 열어두고 있네요.
서버에서 그냥
ftp localhost하면 빠른데,
ftp 도메인/ip 으로 들어가든가, 외부에서 ftp 도메인/ip 으로 들어가면
무척느립니다.
직접 ip로 접속해도 느리고 # host 아무ip 를 해보면 응답속도는 빠릅니다.
웹포트/텔넷포트등은 바로 접속이 되는데,
imap/ftp/pop 등이 느려 졌습니다.
한국통신 서버 문제일까요 ?
ftp xin.nameip.net 으로 시도해보시고 많은 조언부탁드립니다.
Forums:
ftp 접속시 느려지는 현상은 네임서버 문제입니다.저의 경우에는
ftp 접속시 느려지는 현상은 네임서버 문제입니다.
저의 경우에는 localhost 조차도 느려진적이 있었습니다.
그래서, 원인규명을 해보니, ftp 접속시 찾는 네임서버에서 계속 돌다가
결국 못찾고, 다시 돌아와서 접속이 되어버려서
30초 가량 걸렸습니다.
그래서, 찾는 네임서버를 자체로 돌려놓고 보니, 다시 빨라지더군여
아마도, 네임서버에서 문제가 있는듯 싶습니다.
네임서버를 교체를 해보심이 좋을듯 싶습니다.
아바타 제작기간~~ 무려 5초!!!
Name server가 잘못된 경우.Gateway가 잘못 지정되는 경
Name server가 잘못된 경우.
Gateway가 잘못 지정되는 경우.
Gateway가 아예 없는 경우.
제가 느낀 실수는 이런것이 있었습니다.
클라이언트에서 passive 모드로 접속하시고..서버로 passive
클라이언트에서 passive 모드로 접속하시고..
서버로 passive 모드로 되어 있으면 잘될겁니다..
접속시 지연현상은 passive 모드로 동작하는 서버의 FTP에서 많이 발생하더군요...
특히나 공유기나 공유 형태로 사용하는 사람들은 위의 두가지를 받드시 활성화 해야 ftp 사용에 문제가 안 생깁니다.
=================================
:: how about a cup of tea ? ::
=================================
ip로도 접속이 느려지면 Name server문제가 아니지 않나요 ?
현재 IP로 직접 접속을 해도 느려지고,
# host 아무도메인 으로 해보면 빠르게 ip를 가져옵니다.
이걸로 봐선 네임서버문제는 아닌듯 합니다. 그렇죠 ?(제가 잘 몰라서ㅡㅡ)
물론 네임버서에 어떤 설정을 바꾼적이 없어서 함 시도는 해보겠습니다.
두번째로 FTP서버에 passive모드설정을 어떻게 하는지 알려주세요.
wu-ftp를 사용하고 있는데 설정을 어디서 하는지 알려주시면
감사하겠습니다.
참고로, VDSL 한국통신포트 문제인줄 알았는데,
윈도우에서 FTP서버를 띄우고 접속하니까 빠르네요.
리눅스에서 FTP서버접속이 느려지는걸로 봐선 자체문제인듯 합니다.
답변 감사합니다.
tcp wrapper, resolv.conf 와 telnet, ftp간의 관계
호스팅 업체인 인터넷제국의 고객지원 기술 문서중에 있던
글을 훔쳐 왔습니다. ^^;
----------------------------------
1. 문제제기
Linux를 이용하는 이용자들이 이런 이야기를 할 때가 있습니다.
\"이상하게 telnet 이나 ftp를 이용할 때 login prompt가 나올 때까지
걸리는 시간이 매우 길다. 30초에서 60초 가량. 그런데, login 후부터
느리지는 않다. web 접속 및 전송속도는 양호하다\".
본인도 2000년 5월에 이러한 문의를 접하고 문제점이 무엇일까 원인을
찾아보려고 노력을 했었습니다. 그리고, 결국 원인을 찾아 대처를
했었습니다. 그런데 관련 문서를 만들지 않고 있었는데 오늘 다시
동일한 문의가 있어서 이제는 미루지 말고 만들때가 되었구나라고
판단이 되어 이 글을 씁니다.
2. 힌트
위 문제의 원인은 tcp wrapper, resolv.conf, 그리고 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영하지 못하는 것들이 복합되어서 나타나는
것입니다. 그것에 대해서는 다시 언급하겠습니다.
만약 제기된 문제점을 해결하려면 tcp wrapper를 이용하지 않거나,
resolv.conf를 교묘하게 처리하거나, 아니면 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영해주면 됩니다. 그러나, 국내 몇몇 ISP들이
DNS 서버를 올바르게 운영해 주길 바라는 것은 (지난 몇년간의
경험을 바탕으로 판단하건데) Non-sense입니다.
따라서 서버를 운영하는 자신이 tcp wrapper와 resolv.conf를 조작해야만
합니다.
3. NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로 관계없음.
tcp wrapper를 이용하는 서버만 해당.
* 국내에서 많이 이용하는 Redhat Linux를 기준으로 설명하겠습니다.
Redhat Linux를 기본으로 설치하면 telnet, ftp, pop3 등은
tcp wrapper (/usr/sbin/tcpd)의 영향을 받게 됩니다.
/etc/inetd.conf를 뒤져보면 아래와 같은 것을 볼 수 있습니다.
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
만약 tcpd의 영향을 받지 않으려면 다음과 같이 수정을 하면 됩니다.
ftp stream tcp nowait root /usr/sbin/in.ftpd
telnet stream tcp nowait root /usr/sbin/in.telnetd
pop-3 stream tcp nowait root /usr/sbin/ipop3d
그러나, tcpd를 삭제해 버리면 접근제한(access control)을 할 수 없게
되는 단점이 있으므로 권장하고 싶은 사항은 아닙니다. 그러므로,
tcp wrapper가 어떻게 동작하는지를 이해하여 문제를 해결해 나갈 필요가
있습니다.
참고로 NT, Windows 2000 서버는 tcp wrapper를 이용하지 않으므로
여기에서 말하는 문제는 없습니다.
4. TCP wrapper의 역할
서버address 3.3.3.3
/usr/sbin/tcpd in.telnetd
/etc/resolv.conf
nameserver 127.0.0.1
PC-address 2.2.2.2
2.2.2.2에 대한 reverse zone을 갖고 있다고 지정된
DNS서버 1.1.1.1
만약 PC가 서버에 telnet으로 접근을 하게 되면 서버의 tcpd는 PC의
address 2.2.2.2에 대해서 reverse lookup을 합니다
(본인도 tcp wrapper에 대해 상세하게 모르지만 reverse lookup을 하는
것만은 확실합니다).
참고: www.inempire.com ---> 210.124.122.135 : forward lookup
210.124.122.135 ---> www.inempire.com : reverse lookup
서버안에서 발생하는 모든 DNS lookup은 /etc/resolv.conf에 지정된
nameserver로 전달됩니다. 이 예에서는 서버 자신입니다.
서버의 DNS 설정을 살펴보면 자신이 2.2.2.2에 대한 reverse
lookup을 담당하는 서버가 아님을 알게 됩니다. 따라서, PC address에
대해 reverse lookup query 과정을 실시하게 됩니다 (이 과정은 일반적인
forward lookup 과정과 100% 동일합니다). DNS cache에 어떤 정보가
남아 있는지에 따라 조금씩 다르지만 최종적으로 2.2.2.2에
대한 reverse lookup을 담당하는 DNS server까지 도달하게 됩니다.
그런데 만약 최종 DNS server 1.1.1.1이 자신은 2.2.2.2에 대한
reverse zone file을 갖고 있다고 선언되어 있지 않다면 어떻게 될까요?
그 경우 최종 DNS server 1.1.1.1은 서버 3.3.3.3 과 마찬가지로
2.2.2.2에 대한 reverse query를 하게 됩니다. 그 query는 서버
1.1.1.1로 다시 돌아오게 되므로 결국 looping이 발생하게 됩니다.
이 경우 서버 3.3.3.3은 계속 reverse query가 끝나기를 기다리고
있습니다. 그러나 무한정 계속 기다릴 수는 없어 일정시간(timeout)이
지나면 reverse lookup을 포기하게 됩니다.
(질문: 이 timeout은 tcp wrapper에서 지정된 timeout일까요?
아니면 reverse lookup의 timeout일까요?)
그리고 PC 2.2.2.2에게 login prompt를 전달하게 됩니다. 따라서,
reverse lookup에 문제가 있는 경우 PC 2.2.2.2는 서버 3.3.3.3으로
부터 login prompt를 받을 때까지 30~60초가량 기다려야만 하는
것입니다.
5. 국내 몇몇 ISP들의 DNS Server 운영 문제점
가. 위 4.에서 발생된 문제는 해당 IP address를 관리하는 ISP가 자신의
DNS Server에 reverse zone을 선언해 놓지 않았기 때문입니다.
모든 PTR record를 선언해 놓는 것이 어렵기 때문에 그것까지는
필요없다고 하더라도 반드시 reverse zone은 선언해 놓아야 합니다.
나. reverse zone은 선언해 놓았더라도 reverse lookup이 자주
실패하는 상태로 DNS server를 운영하는 경우도 문제입니다.
이런 경우 어떤 때는 접속이 빠르다가 바쁜 오후 혹은 저녁에 login
prompt를 전달받기까지 걸리는 시간이 들쭉날쭉하게 됩니다.
DNS server를 잘 구성해 운영해 주길 희망합니다.
6. 목마른 사람이 우물을 판다
위 5.에서의 언급한 사항을 잘하고 있는 국내 ISP는 많지 않습니다.
따라서, 내가 문제를 스스로 해결할 수 밖에 없습니다.
문제를 해결하는 방법은 크게 2가지가 있습니다. 첫번째는 tcp wrapper의
기능을 off시키는 것이고, 두번째는 reverse lookup 과정을 조작하는
것입니다. 첫번째는 access control이 필요한 경우 할 수 없으므로
두번째에 대해서 서술하겠습니다.
2가지 방법(아래 7. 과 8.)이 있습니다.
7. reverse lookup을 자기(서버 3.3.3.3)가 모두 직접 처리하게 함
서버 3.3.3.3이 자신이 모든 IP address에 대해 reverse lookup에 대한
master라고 선언하여 reverse query가 다른 서버로 전달되지 않게 하는
방법입니다. 이것의 장점은 신속하게 reverse query에 대한 reply를
받게 되므로 PC에게 빨리 login prompt를 전달해 줄 수 있습니다. 단점은
traceroute, tracert, 혹은 기타 필요에 의해서 reverse lookup이 필요한
경우 hostname을 알 수 없다는 것입니다.
방법은 간단합니다. 그러나 조금은 무식합니다. 그러나 확실합니다.
* 아래 문법이 조금 틀릴 수 있으니 주의하세요.
o named.conf에 모든 IP address에 대해 자기가 master라고 선언
zone \"1.in-addr.arpa\" {type master; file \"zone.1.in-addr.arpa\";}
zone \"2.in-addr.arpa\" {type master; file \"zone.2.in-addr.arpa\";}
zone \"3.in-addr.arpa\" {type master; file \"zone.3.in-addr.arpa\";}
......생략........
zone \"223.in-addr.arpa\" {type master; file \"zone.223.in-addr.arpa\";}
o 해당 reverse zone file을 생성해 줌
$ more zone.1.in-addr.arpa
@ IN SOA ns.haha.com root.ns.haha.com (
2 ; serial number
10800 ; refresh
3600 ; retry
86400 ; expire
21600 ) ; minimum TTL
@ NS ns.haha.com.
@ NS ns2.haha.com.
1.1.1 PTR dummy.haha.com.
$ ln -s zone.1.in-addr.arpa zone.2.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.3.in-addr.arpa
$ ln -s zone.1.in-addr.arpa zone.4.in-addr.arpa
....... 생략 ......
$ ln -s zone.1.in-addr.arpa zone.223.in-addr.arpa
* PTR record는 1개 밖에 선언하지 않았습니다.
아무 의미없는 것입니다. 마음대로 하세요.
8. 위 가.의 서버를 /etc/resolv.conf에 등록하기만 하면 됨
$more resolv.conf
nameserver 3.3.3.3
9. 인터넷제국의 고객들께
위 7.에서 제시한대로 해도 되고, 8.에서 제시한대로 인터넷제국의
DNS server를 resolv.conf에 등록을 해도 됩니다.
이상입니다. 도움이 되기를 바랍니다.
/장우현
인터넷제국 운영센터
TEL+82-2-2140-4500
opcenter@inempire.com
서버호스팅전문기업 인터넷제국
TEL+82-2-2106-6300
http://www.inempire.com/
해결 했습니다.
ruseel 님이 올려주신 글을 보고 해결했습니다.
제 증상에 딱 맞는 글을 주셔서 감사드립니다.
다른 많은 분들도 좋은 답변 주셔서 도움이 많이 되었습니다.
제가 급한 마음에 쓰레드를 두개를 달았네요 관리자님 죄송합니다.
지우셔도 됩니다 --;;
ruseel님이 올려주신 참고문서를 보고 그냥 간단히 네임서버를
교체해서 해결했습니다.
한국통신의 DNS서버 설정이 제대로 안되어 있는것 같네요 ..
정말 훌륭한 사이트같네요..
많은 분들이 관심을 가지고 지켜봐 주시니까요 .
제 경우도 이러한 증상이 있어서, 해결책을 찾던중...russel님이
제 경우도 이러한 증상이 있어서, 해결책을 찾던중...
russel님이 알려주신 방법으로 해결을 시도했으나, 해결되지 않았습니다.
제 경우는 단순히 FTP 데몬을 바꾸어 이 문제를 해결했으나, 아직 정확한 이유는 파악하고 있질 못합니다.
FTP 데몬은 wu-ftp(version wu-2.6.1-18)에서 vsftp(version vsFTPd 1.0.1)로 변경하였습니다.
만약, 직접 관리하시는 서버에 접속하는 경우라면/etc/hosts 에
만약, 직접 관리하시는 서버에 접속하는 경우라면
/etc/hosts 에 접속시의 ip를 넣어주세요.
그러면 해결될겁니다. ^^
----------------------------------------------
한번뿐인 인생....
미친듯이 살아보자!
----------------------------------------------
음.. 비슷한 증상을
음.. 비슷한 증상을 격고있는데 위의 해결책으로 해결이 안되네요..
/etc/hosts 에 클라이언트ip 추가해도 안되구요. 쩝...
--- tip ---
돈이 나올 때 까지 땅을 파라...
요즘의 daemon 들은
요즘의 daemon 들은 왠만해서 dnslookup 을 하지 않는 옵션들을 제공합니다. proftpd 의 경우
와 같이 설정을 해서 name resoving 을 하지 않도록 할 수 있습니다. vsftpd 는 써 본적이 없어서 모르겠군요.
아.. 이런 옵션도
아.. 이런 옵션도 있었군요...
감사합니다.
--- tip ---
돈이 나올 때 까지 땅을 파라...
댓글 달기