알면 쉽고 모르면 어려운 것이다.
엄청 대단한건 아니지만 알아두면 유용한 지식을 공유하고자 한다.
[노하우] + [상황에 맞는 적절한 프로그램 사용] 으로 문제를 해결할 것이다.
먼저 몇가지 이론을 알고 가도록 하자.
몇가지 이론
1. TCP 와 UDP
장황한 컴퓨터공학 이론 말고 대강의 뜻만 이해하도록 하자.
그림 및 내용 참조 : 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 handshake 나 Transport 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
중계 서버 세팅 방법
위의 이론을 모두 사용할 것이다.
먼저 해외망이 느릴때, 내가 사용할 수 있는 모든 국내서버에 대해 해외통신의 품질을 측정해보았다.
인터넷 교환망 KINX 내부의 Amazon Seoul 망만 유일하게 평소와 같은 - 최적의 - 속도를 유지하더라.
1. 중계 서버로 사용할 클라우드 서버 신청
아마존 클라우드에서 Seoul 지역(지역코드 ap-northeast-2)을 선택한 후 클라우드 서버를 신청하도록 하자.
반드시 Amazon WebService - Seoul 을 신청해야한다.
참고로, Amazon 과 비슷한 망을 사용할 것 같은 국내 사업자 KINX Cloud 도 빠르지 않을까 생각되어 속도를 측정해 봤는데 여기는 느리더라.
즉 Amazon Seoul 은 별도의 망이 있으며 잘 관리되고 있다 라고 추측할 수 있다.
따라서 유일하게 항상 정상적인 속도를 제공하는 Amazon 망을 사용해서 통신할 것이다.
Amazon Seoul 에서 Subnet 은 아무거나 선택하고, 인스턴스 타입은 t2.micro 나 t2.small 을 선택하세요.
운영체제는 Ubuntu Server 를 선택해주세요. (소스 다운받아서 컴파일 설치할 줄 아시는 분이나, RPM 구해서 설치할 줄 아시는 분은 아무 운영체제나 선택하셔도 됩니다.)
아 그리고 팁을 드리자면 주 작업환경 컴퓨터를 Mac 으로 하시면 웹/서버 작업이 많이 편해집니다. (백문이 불여일견;百聞不如一見;이라고 직접 써보면 그 이유를 알게 될 것입니다.)
중계 서버로 사용할 - 방금 신청한 - 아마존 클라우드 서버에 접속한다.
서버의 Availability Zone 이 ap-northeast-2a(또는 ap-northeast-2c) 인 서버로 접속해야 한다.
2. 리눅스 내에 설치된 기본 패키지 정보 업데이트
# apt-get update
# apt-get upgrade
3. 중계 서버 프로그램 설치
rinetd 라는 툴을 사용할 것이다.
# apt-cache search rinetd
rinetd - Internet TCP redirection server
rinetd 는 TCP 전달 서버이다.
rinetd 설치
# apt-get install rinetd
프로그램은 설치 후 바로 실행되지만 설정을 하지 않았기 때문에 아무런 동작을 하지 않을 것이다.
4. 중계 서버 설정
# vi /etc/rinetd.conf
설정 예시
[code title="rinetd.conf" language="bash"]
#
# 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
[/code]
이 설정 파일의 주석문자는 # 입니다.
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)에 대해서 측정하였습니다.
- 일본서버 직접접속 : 32ms
- 서울아마존 중계접속 : 36ms (32ms + 4ms 중계지연)
속도 제한이 걸릴 경우
- 일본서버 직접접속 : 65ms (32ms + 33ms 추가 지연)
- 서울아마존 중계접속 : 36ms (32ms + 4ms 중계지연)
검증을 위해서 이틀 후 다시 측정
- 일본서버 직접접속 : 73ms (32ms + 41ms 추가 지연)
- 서울아마존 중계접속 : 34ms (32ms + 2ms 중계지연)
마치면서
한국은 미국으로의 direct Line 이 없기 때문에 반드시 Korea -> Japan -> USA 를 거쳐 통신해야 합니다.
즉 아마존 중계 서버를 세팅하거나, 아마존 클라우드를 사용하면 항상 더 빠른 서비스를 제공할 수 있습니다. (의도적인 속도 제한에 걸리지 않음)
추가
중계 서버를 2개 세팅(한국에 하나 일본에 하나, 그 후 두개 연결)하면 더 안정적으로 글로벌 트래픽 (국제 트래픽)을 사용할 수 있습니다.
대충 다음과 같은 그림일 것 입니다.
점(Vertex)은 패킷 길안내 를 하는 라우터(Router)를 의미하며 라우터 덩어리를 네트워크 코어(Network Core) 라고 부릅니다.
참조 : https://www.techopedia.com/definition/6641/core-network
< 화백 라엘님의 그림 - Network Core >
Conversation
In the margins
0 notes
No comments yet. Be the first to leave a note.