최근들어 놀라운 현대인터넷 (HCN)

원룸이 또 HCN (HCN내에도 지방 케이블임.) 이어서 몇 년전의 악몽… (해외싸이트 따운로드 10KB/s 나오던)을 생각했었는데,
인터넷을 쓰다보니 뭔가 불편함이 전혀 없어서 왠일인가? 하고 경로분석을 시작했다.

일단 speedtest.net에 kdatacenter.com를 타겟으로 측정을하면,
Down은 90Mbps 이상에, Up은 20부터 80까지… 들쭉날쭉.. 스트리밍은 하지 않지만, 스트리밍을 하려면 조금 고민좀 해야겠다. 거의 50이상은 평범하게 나와보인다.

내가 3년전 원룸에서 HCN을 썼고, 이제 다시 사용하는 건데, 그 때 쓰던 것과 현재를 비교해보겠다.

 

논란의 해외망

전체적인 해외망은 기본적으로 Hanaro Telecom (SK), HCN->Dreamline->Boranet(LG), Korea Telecom (KT) 이렇게 라우팅 된다.

현재 아시아의 트래픽 (대부분 일본과 싱가포르, 홍콩)은
SK와 KT의 경우 일본 오사카NTT와 도쿄NTT 중 아무곳으로 먼저 라우팅된다. 문제는 이 구간이 밤이나 주말만 되면, 트래픽을 초월하여 패킷로스가 생기고 엄청난 핑폭이 일어난다.
KT에서 KDDI (일본 인터넷회사)는 직접 연결되는지, KDDI와의 이런 현상은 거의 없어보이는데, 문제는 KDDI와 타통신사는 궁합이 안 좋아 보인다. SK와 LG는 KDDI 네트워크를 가기위해 홍콩을 먼저 들른다. […] LG는 일본의경우 NTT로 가긴하는데, 망에 부하도 별로없고, 일본경유보단 홍콩이나 싱가포르의 경우 거의 직접연결되는걸로 보인다.

를 바탕으로, HCN도 결국엔 SKL 핑을 따라가겠지.. 생각했는데, 내 생각이 틀리게 되었다.

 

결론적으로, HCN은 대부분의 트래픽이 HCN서울동작에서 서울NTT와 교환되어 일본 NTT로 연결되어 쾌적함을 볼 수 있었다.
여기서 차이는, SKL 사에서 응답하는 국제 트래픽과 독립적이라는것이다.

내가 테스트했을 때, 이 경로를 통한 사이트의 핑은 언제나 44ms로 고정되었고지방이라 핑이 좀 높은편이다. 패킷로스 또한 전혀 일어나지 않았다.

NTT 피어링이 주로 되는 GMO 클라우드의 경로를 예를 보이겠다.

서울NTT로 바로 연결되어 쾌적한 핑을 볼 수 있다. 약 44ms

같은 시각 동일한 서버에 Korea Telecom의 한 VPN서버로 연결해서 경로를 추적하였다.

경로추적값에서는 잘 알 수 없지만, kt-osaka-tokyo 구간이 100ms 가 나온다는 것을 알 수 있다.
실제 ping값도 96~104ms로 들쭉날쭉했다.
같은 시각 SKB 쪽으로도 연결했는데 이 곳은 아직은 혼잡하진 않은지, 47 ~ 63ms로 나왔다. 그래도 10±5ms 가량 튀는걸 보니, 안정적인 상태는 아닌듯해 보였다.

뭐 이 정도면 나쁜편은 아니지 않은가?

 

다운로드 속도도 빠질 수 없다.
내 과거의 기억을 되짚어보자면,
일본쪽만 해도 다운로드 속도가 2MB/s,  미국싸이트는 네트워크마다 다른데, 서부는 좋은곳은 1MB/s – 3MB/s, 안 좋은 곳은 400KB/s 에서 오르지 않음,
유럽은 20KB/s ……. 만 있었지만. 현재는, 일본 8MB/s, 미국은 거의 1MB/s 이상 나오고, 유럽도 20KB/s 가 나오는 끔찍한 일은 벌어지지 않았다.

테스트 파일
일본 : https://hnd-jp-ping.vultr.com/vultr.com.1000MB.bin
유럽 : http://ping.online.net/1000Mo.dat
미국 (좋은곳) : http://as8100.net/1gb.bin
미국 (안좋은곳) : http://mirror.dacentec.com/1000MB.bin

 

빠질 수 없는 유튜브

이전의 내 기억이 틀림없다면,
이전에 HCN에서 유튜브를 접속했을 때는, KINX 서버의 캐시서버로 영상을 받게 되었다.
(유튜브나 구글 서버 자체는 BORANET의 공유망을 이용했었다. 속도 약 60ms)
문제는 이 KINX의 유투브 캐시서버가 속도가 저질이었던걸로 기억한다. 직접 서버에 핑을하면 110ms의 응답에 240p 영상 재생이 안되는 수준의 다운로드속도이었다.

현재는 HCN 캐시서버로 잡힌다. 유투브에서 영상 다운로드 소스가 HCN의 아이피로 잡힌다.

구글의 속도도 개선되었다.
구글을 접속했을 당시 BORANET이었던 국제라우팅경로를 가지고 있었는데, 현재는 조금 다르다.

40ms 이내로 쾌적함을 보인다. 중간의 192.145.251.168은 뜬금없이 인도네시아의 아이피인데.. 무언가 의미없는 아이피를 라우터용으로 할당한 것 같아보인다.

 

페이스북에 접속해도, SKL와 독립적인 NTT라인을 타서 일본서버로 진입하게 되어, 매우 쾌적하고, 페이스북 사진서버는 HCN이름으로 된 CDN을 이용하게 된다.
최근 페이스북 갖고 SK와 KT가 무단 경로 변경의 이유로 싸운 것을 보면, 음… 나랑은 상관없는 일처럼 보인다. 왜냐? 내 것은 빠르기 때문이다

클라우드플레어 (CloudFlare CDN)

무조건 ICN로 잡힌다.

 

뭐 이 정도면 케이블 치고 매우 개선된 것이 아니겠는가?

SoftEther VPN IPv6 NAT

IPv6 에 NAT이라니;;
쓰는 호스팅이 IPv6 을 단 1 개만 줘서 어쩔수없이 NAT을 쓰게되었다.

DHCP 서버 설정

/etc/dnsmasq.conf

softether tap 인터페이스에 ip 할당 (IP는 필요하지 않음)

Centos 7 IPv6 Forward 활성화

/etc/sysctl.conf

ip6tables를 통한 SNAT 적용

SoftEther VPN에 VPN 클라이언트 어댑터를 하나 더 추가. 이 어댑터에는 IPv4 비활성화. IPv6만 활성화.

 

 

시외고속버스 자동 긴급제동 시스템 (AEBS) 발동 후기

시외 나갈 일이 없는 한 아싸가, 얼마 전 일 좀 보려고 시외에 나갔다가 돌아오는 길에는 우등고속버스로 탔는데 이 때 버스에서 자동긴급제동이 발동하여 받은 놀라운 감격을 표출하기 위해 글을 쓴다.

돌아오는 길에 우등버스에선, 맨 앞자리에 탑승했다. 그래서 전방이 훤히 보이게 되었다. 고속도로로 진입하기 전 신호에서, 차가 줄이어 직진하는데, 아마 내 자리보다 운전석 자리가 더 낮기 때문에, 기사님은 앞의 교통상황을 나보다는 알 수 없었을 것이다. 약 10대의 차량이 줄이어 교차로를 속력이 제법 있는 상태로 통과하는데, 앞에서 머뭇거림이 발생하였지만, 버스는 앞 차와의 거리가 조금 많았기 때문에 속력을 유지하여 갔다. 그러나 앞서 말하다시피 앞에서 머뭇거림이 생겨서 앞 차량이 급정거를 하게 되었다.

앞 차량은 소형SUV 차량으로 보였다. 앞 차량은 정지 했지만, 버스는 속력을 줄이지 않았다. 기사님의 실수이었을까? 우연이었을까? 뭐, 기사님이 인지 하고 풀 브레이크를 밟았을 수도 있었겠지?

좌석에서 전방을 보던 나는 이 속력이라면 분명 저 차가 찌그러질거라고, 생각했는데, 그 순간 차량은 경보음 (삐)을 여러번 울린 뒤, 버스가 급정지했다. 안전벨트를 메고 있어서 몸이 앞으로 쏠리기만 했는데, 안전벨트를 메고 있지 않았더라면, 분명 앞으로 날라갈만한 충격을 받았다.

단순한 접촉사고를 일으킬 만한 상황이었지만, (아닐 수 도있다.) 그래도 충돌을 감지하고 충돌을 실제로 예방하였기 때문에, 얼마나 신 기술이 좋은지 뼈저리게 느끼게 되었다.

P.S : 내가 탄 버스가 AEB가 장착되어있던게 아니라면??????

게이밍 마우스 장패드 두께

컴퓨터 마우스패드로 장패드를 사용하는데, 요즘 사용하는데 매우 불편한 감을 느낀다. 책상이 높아져서, 컴퓨터 하는데 자세가 불편하다. 사실 책상 탓이 가장 크지만, 이 장패드도 불편함을 느끼는것에 어느정도 기여를 하고 있다.

내 몸에 알맞게, 책상 높이 형편에 맞춰 장패드의 두께를 고려하여 구매하도록 하자.

지인 서버의 업타임이 1078일을 지나가고 있다

지인의 서버 업타임이 1078일을 지나가고 있다.
서버는 클라우드서버라서 중간에 호스트서버가 점검등의 이유로, 메모리를 세이브 해놓고 재부팅을 했을지는 모르겠다만. 일단 핵심은 리눅스서버를 1000일 이상 켜놨다는 것이다.

사실 중요한 서비스거나, 앞으로도 운영에 문제가 없다면 이런 업타임을 가지는게 당연할 수도 있겠다만, 내 눈앞에서 (?) 컴퓨터가 1000일 넘게 돌아가고 있다는 것에 너무 신기할 따름이다. 현업에 종사하고 있는 사람들은 대수롭게 여길지도 모르겠다.

업타임 1000일 찍었다고 자랑스러워 하면 안 되는 것이,
그 기간동안 발견되고 오픈된 취약점이 무수히 많을 것이다. 대응되는 보안패치도 적용이 안 되었을거고. 즉, 관리를 하지 않은 서버라고도 말 할 수 있다!!

리눅스 htop 프로그램에서도 업타임 100일이 지난 서버에도 (!) 경고성 느낌표를 추가해버린다.

그래도 그 기간 서버가 살아있다는 것에 대한 자기만족.