항상 최상의 속도로 국제데이터를 이용하는방법(리눅스 데이터 포워딩)

HYEONG HWAN, MUN/ 6월 12, 2016/ 미분류/ 20 comments

알면 쉽고 모르면 어려운 것이다.
엄청 대단한건 아니지만 알아두면 유용한 지식을 공유하고자 한다.

[노하우] + [상황에 맞는 적절한 프로그램 사용] 으로 문제를 해결할 것이다.

먼저 몇가지 이론을 알고 가도록 하자.

 


몇가지 이론

1. TCP 와 UDP

장황한 컴퓨터공학 이론 말고 대강의 뜻만 이해하도록 하자.

TCP7

그림 및 내용 참조 : https://www.pluralsight.com/blog/it-ops/networking-basics-tcp-udp-tcpip-osi-models

TCP 는 신뢰된 데이터 전송을 위한 프로토콜이다. 100개의 데이터를 올바르게 순서대로 모두 전송할 때 쓰는 것이다.
UDP 는 신뢰되지 않은 데이터 전송을 위한 프로토콜이다. 100개의 데이터를 보내지만 도착여부등을 전혀 신경쓰지 않는다.
TCP 는 웹문서(예를들어 HTML) 등을 읽을때 사용한다.
UDP 는 인터넷 동영상 재생시에 사용한다. (손실을 허용하는 통신)

라고 배웠으나, 인터넷 동영상도 TCP 통신하더라. (99.99% 이상)

DNS 서비스는 UDP 를 사용한다. (0.01% 이하)
아무튼 “통신한다” 라는 말을 듣게되면 모두 TCP 라고 추정하면 된다.

참고로 왜 TCP 를 신뢰된 데이터 전송이라고 하는지 궁금하면 구글에 3-Way handshakeTransport Layer 를 검색해보도록 하여라.

 

2. 속도 제한을 거는법 (bandwidth Limit)

초당 100발을 발사할 수 있는 총이 있다고 해보자.
이 총을 초당 30발을 발사하게 제한을 거는 방법이 있다. 0.3초간 발사를 허용하고, 0.7초간은 발사를 하지 못하게 막는 것이다.
이렇게 시간의 공백을 주게되면 초당 100발을 발사하는 총을 가지고도 원하는 속도로 제한을 걸 수 있다.

인터넷 속도도 이렇게 특정 속도가 넘으면 빈프레임을 줌으로써 속도제한을 구현할 수 있다.

 

3. 중계 서버 (Proxy Server)

데이터를 취합해서 전달하는 서버를 프록시 서버(Proxy Server) 라고 한다.
활동 주체에 따른 분류로 Forward Proxy 와 Reverse Proxy 로 나뉘는데, 궁금하면 이 글(https://blog.lael.be/post/1023)을 읽어보도록 하여라.

그냥 단순히 중계 서버 라고 이해하면 된다.

 

4. 망중립성 (Net neutrality)

망 중립성이란 인터넷 네트워크로 전송되는 모든 트래픽은 내용과 유형, 서비스나 단말 종류, 수/발신자와 관계없이 동등하게 취급되어야 한다는 원칙을 말한다.

https://namu.wiki/w/%EB%A7%9D%EC%A4%91%EB%A6%BD%EC%84%B1

참고로 한국은 망중립적이지 않다. 널리 알려진 사례로는 삼성스마트TV, 카카오톡 사례가 있다.

이 문서도 참조하여라.
http://biz.chosun.com/site/data/html_dir/2015/02/13/2015021301738.html

 

5. 인터넷 교환망 (Internet eXchange; IX)

한 통신사업자와 다른 통신사업자가 통신하기 위해서는 인터넷 교환망(IX)를 지나야 한다. 비유하자면 지하철 환승역이라고 생각하면 된다.
국내 서버간 통신은 어느 곳을 선택하더라도 빠르기 때문에 굳이 IX를 고려할 필요가 없는데, 국내-해외 간의 통신은 속도제한이 자주 걸리고 있으므로 IX에 대해 알아두어야 할 것이다.

https://www.kinx.net/ix/information/concept

https://www.uplus.co.kr/biz/bzin/inie/InitBzInIeIx.hpi

http://cusee.net/2461038

 


중계 서버 세팅 방법

위의 이론을 모두 사용할 것이다.
먼저 해외망이 느릴때, 내가 사용할 수 있는 국내 모든서버에 대해 해외통신의 품질을 측정해보았다.

인터넷 교환망 KINX 내부의 Amazon Seoul 망만 유일하게 평소와 같은 - 최적의 - 속도를 유지하더라.

 

1. 중계 서버로 사용할 클라우드 서버 신청

https://aws.amazon.com/ko/

아마존 클라우드에서 Seoul 지역(지역코드 ap-northeast-2)을 선택한 후 클라우드 서버를 신청하도록 하자.
반드시 Amazon WebService - Seoul 을 신청해야한다.

v2

참고로, Amazon 과 비슷한 망을 사용할 것 같은 국내 사업자 KINX Cloud 도 빠르지 않을까 생각되어 속도를 측정해 봤는데 여기는 느리더라.

 

Amazon Seoul 은 별도의 망이 있으며 잘 관리되고 있다 라고 추측할 수 있다.

 

따라서 유일하게 항상 정상적인 속도를 제공하는 Amazon 망을 사용해서 통신할 것이다.

Amazon Seoul 에서 Subnet 은 아무거나 선택하고, 인스턴스 타입t2.microt2.small 을 선택하세요.

운영체제는 Ubuntu Server 를 선택해주세요. (소스 다운받아서 컴파일 설치할 줄 아시는 분이나, RPM 구해서 설치할 줄 아시는 분은 아무 운영체제나 선택하셔도 됩니다.)

 

아 그리고 팁을 드리자면 주 작업환경 컴퓨터Mac 으로 하시면 웹/서버 작업이 많이 편해집니다. (백문이 불여일견;百聞不如一見;이라고 직접 써보면 그 이유를 알게 될 것입니다.)

 

중계 서버로 사용할 - 방금 신청한 - 아마존 클라우드 서버에 접속한다.

서버의 Availability Zoneap-northeast-2a(또는 ap-northeast-2c) 인 서버로 접속해야 한다.

 

2. 리눅스 내에 설치된 기본 패키지 정보 업데이트

 

# apt-get update
# apt-get upgrade

 

3. 중계 서버 프로그램 설치

rinetd 라는 툴을 사용할 것이다.

# apt-cache search rinetd
rinetd - Internet TCP redirection server

y1

rinetd 는 TCP 전달 서버이다.

 

rinetd 설치

# apt-get install rinetd

 

프로그램은 설치 후 바로 실행되지만 설정을 하지 않았기 때문에 아무런 동작을 하지 않을 것이다.

 

4. 중계 서버 설정

# vi /etc/rinetd.conf

설정 예시


#
# this is the configuration file for rinetd, the internet redirection server
#
# you may specify global allow and deny rules here
# only ip addresses are matched, hostnames cannot be specified here
# the wildcards you may use are * and ?
#
# allow 192.168.2.*
# deny 192.168.2.1?
allow 123.100.78.125
allow 175.120.167.143
allow 220.154.175.*

#
# forwarding rules come here
#
# you may specify allow and deny rules after a specific forwarding rule
# to apply to only that forwarding rule
#
# bindadress bindport connectaddress connectport
0.0.0.0 25565 testsite.com 25565
0.0.0.0 30000 another-domain.co.kr 80
0.0.0.0 8080 221.156.192.40 8080

# logging information
logfile /var/log/rinetd.log

# uncomment the following line if you want web-server style logfile format
# logcommon

 

이 설정 파일의 주석문자는 # 입니다.

allow, deny 둘중 하나만 쓰세요.
allow 만 쓰게되면 그 아이피만 허용합니다.
deny 만 쓰게되면 그 아이피만 차단합니다.

allow, deny 모두 사용하지 않으면 모든 아이피에 대해 허용합니다.
포워딩 규칙(forwarding rule) 은 다음의 형식으로 작성합니다.
0.0.0.0 로컬포트 원격지주소 원격지포트

원격지주소(connectAddress) 위치에 아이피(IP) 또는 주소(hostname)를 적을 수 있습니다.

 

5. 중계 프로그램 환경설정 적용

# service rinetd reload

reload 를 사용하면 현재 사용중인 세션은 그대로 유지하고 설정을 변경합니다.

restart 를 사용하면 현재 사용중인 세션을 모두 강제종료한 후 rinetd 프로그램을 종료하고 다시 실행합니다.

 

6. 테스트

제가 취미로 운영하고 있는 게임서버인 마인크래프트 서버로 테스트해보았습니다. (현재 4년 3개월째 운영하고 있습니다.)

서울에 위치한 서로 다른 세 장소에서 속도를 체크하였습니다.
한 곳은 아래와 같은 결과이었고, 나머지 두 곳은 항상 중계서버가 빨랐습니다. (?!)

참고로 서울<->일본 의 거리35ms 라고 알려져 있고, 국내<->국내5ms 미만 으로 알려져있습니다.

 

먼저 대조군을 위해서 정상상태(normal state)에 대해서 측정하였습니다.

v1

v2

- 일본서버 직접접속 : 32ms
- 서울아마존 중계접속 : 36ms (32ms + 4ms 중계지연)

 

속도 제한이 걸릴 경우

v3

v4

- 일본서버 직접접속 : 65ms (32ms + 33ms 추가 지연)
- 서울아마존 중계접속 : 36ms (32ms + 4ms 중계지연)

 

검증을 위해서 이틀 후 다시 측정

v5

v6

- 일본서버 직접접속 : 73ms (32ms + 41ms 추가 지연)
- 서울아마존 중계접속 : 34ms (32ms + 2ms 중계지연)

 


마치면서

한국은 미국으로의 direct Line 이 없기 때문에 반드시 Korea -> Japan -> USA  를 거쳐 통신해야 합니다.

즉 아마존 중계 서버를 세팅하거나, 아마존 클라우드를 사용하면 항상 더 빠른 서비스를 제공할 수 있습니다. (의도적인 속도 제한에 걸리지 않음)

 


추가

중계 서버를 2개 세팅(한국에 하나 일본에 하나, 그 후 두개 연결)하면 더 안정적으로 글로벌 트래픽 (국제 트래픽)을 사용할 수 있습니다.

대충 다음과 같은 그림일 것 입니다.

점(Vertex)은 패킷 길안내 를 하는 라우터(Router)를 의미하며 라우터 덩어리를 네트워크 코어(Network Core) 라고 부릅니다.

참조 : https://www.techopedia.com/definition/6641/core-network

v17

< 화백 라엘님의 그림 - Network Core >

 

20 Comments

  1. 본문의 주제와는 별로 관련이 없지만…

    “아 그리고 팁을 드리자면 주 작업환경 컴퓨터를 Mac 으로 하시면 웹/서버 작업이 많이 편해집니다.”

    이 부분에 대해서 자세히 설명해 주실 수 있으신가요??

    1. 답변하기 정말 어려운 질문이네요.
      장점이 너무 많아요. 글로 이해하기보다는 그냥 써보시면 바로 알 수 있습니다.
      예를들어 카카오의 경우 전 직원은(강제로) Mac을 사용합니다. 신생 IT 기업 대부분 Mac 을 사용하고요.
      개발자 세미나나(술먹는 세미나 말고), 외국 개발자와 협업시에도 대다수가 Mac 이라는 것을 알 수 있습니다.

  2. 안녕하세요.
    저번에 서버 호스팅 게시글에서 Vultr 일본 서버 핑이 너무 높다고 도와달라고 했던 사람입니다.
    기다렸는데 드디어 올라왔네요.
    우선 시간 내서 정성드린 글 작성해주셔서 정말 감사드립니다.

    다름이 아니고, 이를 토대로 아마존에서 만들고 하려고 하는데,
    이게 위 내용대로 중계 서버 설정만 끝나면 그 다음은 어떻게 적용해야 하는 것인가요?

    본 서버에는 적용할 게 없고 그저 원래대로 본 서버 IP로 접속을 하면 알아서 되는 건가요?
    아니면 중계서버를 거쳐서 본서버(게임서버)로 연결하려면 본서버에서 뭐 다른 것을 해야하는지 궁금합니다.
    또한, 제3자가 서버에 접속할 때의 IP는 본서버로 설정해야하는지, 중계서버로 해야하는지도 궁금합니다.

    제가 이쪽에 문외한이라 많이 귀찮게 해드리네요.
    염치없지만 답변 기다리겠습니다.
    늘 좋은 정보 감사드립니다.

    1. 본 서버에서는 따로 작업할 사항이 없습니다.
      굳이 보안 설정을 한다면 해당 TCP 포트에 대해서 중계 서버에서의 접속만 허용하도록 해주는 것이죠.
      제 3자는 (포트포워딩이 설정된) 중계서버IP 로 접속해야합니다.

      1. 잘 됩니다. 정말 감사드립니다.
        혹시 작성자분이 글에 올리신 사진처럼 중계서버로 거쳤을 때의 핑과 그렇지 않았을 때의 핑을 시각적으로 비교할 수 있는 방법이 무엇이 있나요?

        1. 별도의 모니터링 소프트웨어를 사용해야 합니다. 주기적으로 측정한 후 그래프를 그리는 것이죠.

          1. 그렇군요.
            그런데 궁금한 것은, 직접서버에 접속하는 것은 ping -t 서버 ip를 통해 핑 확인이 가능하지만, 중계서버를 통해 접속하는 것의 지연 시간은 어떻게 확인이 가능한지 궁금합니다.
            ping -t 중계서버 IP를 한다면 중계서버로만의 지연 속도를 확인할 수밖에 없어서.. 궁금합니다.

            1. 포트핑이 따로 있어요.
              http://www.elifulkerson.com/projects/tcping.php 를 참조해보세요.

            2. 계속 귀찮게해드려서 정말 죄송한데.. 중계서버의 핑만 나오지 이 중계서버가 포워딩되어서 실제서버의 핑이 나오게 하는 걸 모르겠습니다.ㅠㅠ

              1. [최종핑] = [나-중계] + [중계-최종서버] 로 덧셈 계산하면 됩니다.
                정확한 결과를 얻으려면 소프트웨어가 PING을 측정하도록 제작되어 있어야 합니다. 본문에 예시로 사용한 소프트웨어는 PING측정 기능이 자체 내장된 프로그램입니다.

  3. rinetd를 사용하면 방문자의 실제 IP 주소를 전혀 알 수 없게 되어 운영상에 여러 가지 불편이 생깁니다. IP 주소를 몰라도 되는 서비스라면 상관없겠지만, 웹 어플리케이션이라면 rinetd 대신 일반적인 http proxy를 사용하는 편이 나을 것 같습니다. nginx에서 모든 호스트, 모든 요청을 무조건 proxy하도록 설정하는 것은 어렵지 않으니까요.

    1. 제 생각에도 http 라면 원래 proxy 용도로 나온 nginx 사용을 권장할 것 같아요.
      하지만 그외에 TCP라면 ip주소 추적의 패널티가 있더라도 성능 향상을 위해 이렇게 사용하게 할 것 같아요.

  4. 항상 좋은 포스팅 감사합니다.
    혹시 letsencrypt.org를 다뤄 보실 의향이 없으신지요?
    글재주가 없다보니 항상 까먹고 검색하면서 사용하고 있네요 ㅎㅎㅎ

    1. 네. 잘 지내시죠?
      저는 SSL 인증서 필요하면 StartSSL 에서 자체발급 해버리거든요.
      혹시나 추후에 LetsEncrypt 쓰게 된다면 작성해보겠습니다.

      1. 넵, 항상 라엘님의 블로그를 기웃거리고 있습니다 ㅎㅎㅎ
        저도 startssl을 쓰다가 우사인으로 넘어갔었습니다.
        둘다 모바일이 안되서 letsencrypt를 시작 하게 됬습니다.
        쓰다보니 꾀 좋더라구요.

        앞으로도 좋은 포스팅 부탁 드리겠습니다!

        1. 모바일 안되나요? 이 블로그에도 StartSSL 적용해두었는데.

  5. startssl도 이제 모바일이 되네요!
    쓴지가 오래되서…
    오늘도 좋은 정보 업어 가네요 ㅎㅎㅎ

  6. KT는 미국을 직접 넘어가는 회선으로 TPE나 CUCN을 이용하고 있는 것으로 알고 있습니다.
    http://www.ajunews.com/view/20160807092240904

    이번 올림픽때는 TPE가 백업회선으로서 스탠바이 하고 있었군요.
    무조건 일본을 거쳐야만 인터넷이 되는건 아닌 것 같습니다.

    1. 알려주셔서 감사합니다. 조금 더 조사해 보고 본문에 반영하도록 하겠습니다.

    2. 찾아봤는데 미국으로 가는 트래픽이 일본을 거치지 않고 China-US Cable Network 이나 Trans-Pacific Express 에 연결되어 직접 연결되는군요.
      하지만 일본은 글로벌네트워크 Hub 이고, 사용자가 CUCN 이나 TPE 라인을 선택해서 통신할 수 없으니, 무조건 트래픽을 일본으로 보내는 본문글은 바람직하다고 판단됩니다.

Leave a Comment

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*