메뉴 닫기

굼뱅이 프로토콜 tcp – 레알?

 구글에서 QUIC이라는 프로토콜을 만들었다고 한다.

기존의 TCP 프로토콜이 자신들의 메인 비즈니스 중 하나인 유튜브 동영상 컨텐츠 비즈니스를 하는데 효과적이지 않은 프로토콜이기 때문으로 보인다.

그래서 자신들의 크롬 브라우저에 QUIC 프로토콜을 탑재하여 동영상을 실어 나르는데 30% 이상의 속도 개선 효과를 보았다고 한다.

위키피디아에 실린 글을 보면 QUIC을 만든 이유가 단 한 줄로 깔끔하게 요약 되어 있다.

https://en.wikipedia.org/wiki/QUIC

QUIC’s main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP.[1]

“quic은 tcp 프로토콜을 사용하는 웹 어플리케이션의 반응 퍼포먼스를 개선하기 위해서 개발 되었다.”

zdnet 의 김우용 기자의 기사

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150420092039

이 글은 인터넷 프로토콜 특히 웹의 기본인 http의 뼈대를 이루는 tcp프로토콜의 속성에서  
왜 느린지를 이야기 하고 느린것을 극복하는 여러가지 대안과  그 효과 그리고 실패사례들을 이야기 하고자 한다. 

TCP, TCP TLS, QUIC 프로토콜 간 비교

 

 

TCP 프로토콜은 왜 느릴까?

한국에 사는 사람들은 TCP 프로토콜이 느리다고 하면 고개를 갸우뚱 할 것이다.
국내의 모든 네트워크가 아무리 느려도 10m/sec 이내의 네트워크라 TCP 네트워크가 느린 것인지에 대해 별로 체감하지 못할 것이다.
그러나 한국에서 가까운 일본 만해도 한국으로부터 ping 속도가 50m/sec 이고 우리 회사 중국지사가 있는 연길 지역까지는  100m/sec이다. 실제 연길지사에서 한국에 있는 데이터센터로 사진파일 하나 올리는데도 3~4초 정도까지 걸릴 정도로 한국으로 업로드&다운로드에는 인내심을 요구한다.  
이처럼 네트워크상의 거리가 멀어질 경우 TCP 프로토콜이 느려지는 이유는 무결성을 전제 조건으로 만들어졌기 때문이다. TCP는 네트워크 구간에 병목 지점이 없어도 전송 중 데이터 유실을 막기 위해 작은 단위로 데이터를 쪼개 보낸다. 그리고 계속 전송 성공 여부를 확인한다. 즉, 데이터 무결성 보장에 최적화되다 보니 부가적인 패킷이 많아지고 그 결과 속도가 느려지는 것이다.   

반면에 UDP나 ICMP는 전송이 최우선 목표다. 수신자가 유실된 데이터를 받건 말건 전송을 최우선으로 한다. 좀 더 자세히 비교해보자. UDP 프로토콜은 수신자의 전송 확인 없이 특정 목적지로 데이터를 전송한다. 반면에 TCP는 수신 측에서 보낸 전송 확인 메시지인 ack를 받은 후 다음 데이터를 보낸다. 데이터를 나누는 크기 단위를 윈도우 사이즈(Window size)라 하는데 보통 64Kbyte 단위로 웹 서버와 웹 브라우저 간 데이터를 주고받는다. 소켓 프로그래밍을 이용해 기본(default) 윈도우 사이즈를 변경해 전송 속도를 높일 수 있다. 하지만 일반적인 웹 브라우저에서 사용하는 HTTP는 클라이언트 윈도우 사이즈의 기본값이 고정되어 있어 접속자 별로 사이즈를 유동적으로 조정하는 것이 불가능에 가깝다.
 
그렇다면 네트워크상 거리가 멀어질 경우 어느 정도 지연이 발생하는지 직접 확인해보자. RTT(ROUND TRIP TIME)를 측정해보면 그냥 답이 나온다. 참고로 윈도우 사이즈로 잘게 나뉜 데이터를 주고받는 데 걸리는 시간을 RTT라고 하는데 이는 ICMP 프로토콜을 이용한 ping 명령으로 확인할 수 있다. 
웹 브라우저로 샌프란시스코에  있는 서버에 접속해 1MB의 720p 사이즈  이미지를 다운로드 받는다고 가정해보자. 네트워크 병목은 없다는 것을 전제로 한다. ping 타임 100msec의 RTT를 갖는 경우라면 1.6초가 답으로 나온다. 아주 간단한 산수다. ‘1024Kbyte/64Kbyte = 16 , 16*100msec = 1.6초’가 나온다. 병목이 없는 조건에서도 TCP 프로토콜의 특성 때문에 1MB의 이미지를 보내는 시간이 길다. 서버가 국내에 있었다면 즉시 올라갈 크기의 파일을 보내는 데 1초 이상이 걸리는 것이다. 우리는 이것을 흔히 ‘지연’이라 부른다. 

 

TCP 프로토콜 속도 지연과 관련된 여러가지 사례

 

사례 1  WAN  가속기

귀사가 해외 지사 를 거느린 대기업 혹은 정부기관이라하자.

본지점간의 거리가 멀어질경우 파일 전송에 문제가 발생한다.  특히 국제 구간에서  거리가 멀어질 경우 TCP 프로토콜의 특성상 속도가 느려 질수 밖에 없다.  

 WAN 가속기는본 지점이 있는 경우 매월 발생하는 전용 회선 요금을 절감하기 위해 쓰이는데,  WAN구간의 경우 본점 지점간 양쪽에  WAN 가속 하드웨어를 설치하여 두 구간의 전송 속도를 개선하는 방법이다.
기본적으로 전송이 자주 있는 파일의 캐시저장,  파일의 압축,  두 구간의 전송을 위한 TCP WINDOWS 사이즈 키우기,  파일이 클경우 여러개의 파일로 쪼개고 커넥션을 여러개를 만든뒤 분할 전송하여 재조립 하는 방법등 다양한 알고리즘으로 전송 속도를 올린다.  

https://www.google.co.kr/webhp?hl=ko#newwindow=1&hl=ko&q=wan+%EA%B0%80%EC%86%8D%EA%B8%B0+

 

 

사례 2  페이스북 사례

전세계적으로 가장 많은 멀티 미디어 파일을 서비스 하는 사이트가 페이스 북이다.  이 사이트를 보면 대략 두가지의  전송 방법이 눈에 띈다.  

CDN(Contents Delivery Network)
페이스북 사례를 통해 CDN(Contents Delivery Network)을 살펴보겠다. 페이스북은 전 세계적으로 가장 많은 멀티미디어 파일을 서비스한다. 페이스북은 기본적으로 CDN을 이용해 전 세계로 이미지와 파일을 전송한다. CDN은 기본적으로 네임 서버에 접속자가 질의를 넣으면 가장 가까운 서버에서 이미지나 파일을 다운로드 하도록 만든 컨텐츠 전송 전용 서비스다. 페이스북은  세계 최대의 CDN 회사인 아카마이(Akamai)의  CDN 망을 이용하여 전 세계로  서비스하는 것으로 보인다. 페이스북의 이미지 링크를 열어 보면 다음 사진과 같이 아카마이 주소가 나온다, 거의 모든 사진 이미지는 아카마이의 네트워크를 타고 전 세계로 배포되는 것으로 보인다. 따라서 캐싱된 이미지나 파일의 경우 서버가 해외에 있지만, 국내에 있는 서버 속도와 같은 수준으로 나온다. 그러나 캐싱되지 않은 이미지는 로딩하는데 국제망 네트워크 병목이 있거나 망 장애가 있을 경우 타임아웃이 걸리는 경우도 종종 있다.

스크린샷, 2015-08-31 19:21:26

 

 

유저가 파일을 페이스 북으로 업로드 할경우 

이미지 처리가 중요한 서비스라면 페이스북의 방식이 유용할 것이다. 이미지를 업로드 하면 PC의 경우는 동시에 3~4개의 커넥션을  동시에 맺고, 이중 먼저 커넥션이 맺어진 것부터 업로드한다. 한번에 모두 커넥션을 맺을 경우 서버가 부하 부담이 클 것으로 보여 3~4개 단위로 커넥션을 맺어 업로드를 하는 것으로 보인다. 이런 경우 TCP 윈도우 사이즈가 커넥션 맺은 숫자만큼 증가 하게 되는 효과가 따라온다. 전 세계 시장으로 이미지 배포를 하는 앱을 개발한다면 고려할만하다. 

faceup   

 

 

 

사례3 :  대용량  해외 파일 전송을 빠르게 하는 TIP

찾아보면 CDN이나 WAN 가속기가 아니라도 방법이 있다. 만약 100GB 크기의 압축하지 않은 영상 원본을 한국 배급사로 전송해야 한다고 가정해보자. 어떻게 보낼 것인가? FTP로 목적지 서버에 파일을 업로드 하기에는 크기가 좀 크다. 심할 경우 일주일 이상 걸릴 것이다. 오히려 국제 특송 서비스를 이용해 파일이 저장된 미디어를 보내는 편이 더 빠를 것이다. 하지만 최근 한 판례에 따르면 파일을 저장한 하드디스크에 세금이 매겨진다는 문제가 있다(http://slownews.kr/39639). 참고로 전자적 전송만 면세다. 
이런 경우 선택할 수 있는 방법은 TCP 윈도우 사이즈를 100배 늘리는 것이다. 파일을 100개로 쪼개고, 100개의 커넥션을 맺은 뒤, 한국에 있는 서버로 동시에 업로드하고, 한국에서 다시 조합하는 방법을 사용하면 된다. 시스템 관리 전문가라면 이 작업을 배치 파일화하여 일괄 프로세스로 만들 것이다. 이 경우 하루 자고 나면 다음 날 전송이 마무리될 것이다. 만약 개발자라면 프로그램을 직접 짜는 것도 방법이다. 수년 전에 삼성SDS에서 관련 프로그램을 오픈 소스로 배포한 적이 있다(http://www.bloter.net/archives/42438).

 

사례4 : <참사> 국내 서비스 동영상을 해외 클라우드에.

최근 국내 스타트업 중 해외 클라우드 서비스에서 사업을 시작하는 곳을 간간이 본다. 선택은 기업의 몫이다. 하지만 충분한 사전 고려 없이 글로벌이란 단어에 현혹되어 해외 클라우드 서비스를 통해 경쟁력만 까먹는 경우를 종종 본다. 앞서 장황하게 TCP의 맹점을 설명한 것은, 차세대 표준 프로토콜이 널리 쓰이지 않는 이상 해외 서비스 이용은 득보다 실이 많을 수 있다는 것을 설명하기 위해서다.

<모 동영상 서비스 사례>
영상 서비스를 해외 클라우드 서버에 올려놓고 한국 사용자에게 서비스한 기업이 있었다. 이 기업의 사례는 해외 IaaS를 이용하면 개발이 편하다는 메시지를 담고 홍보되었다. 이 기업의 대표는 해외 사례를 참조해 의사결정을 했다고 한다. 하지만 중요한 사실을 놓쳤다. 사용자가 국내에 있다는 것, TCP는 느리다는 것을 간과한 것이다. 서비스 개시 후 이 기업은 잦은 해외망 장애와 느린 전송 속도 문제에 직면했고, CDN 서버를 국내에 배치하는 등 나름 대응을 했지만 결국 서비스를 정리할 수밖에 없었다. 해외 IaaS 도입에 결정적인 역할을 한 개발 이사는 글로벌 서비스 이용 경험을 자신의 역량인양 포장해 다른 회사로 이직했다는 후문이다. 여기서 우리가 얻어야 할 교훈은? 사례는 대부분 성공 포인트만 짚어 낸다는 것이다. 실패 사례는 분명히 있다. 

 

사례 5 : 경쟁사는 1초를 즐긴다.

<모 소셜커머스 사례>
한국에는 우리 서비스를 해결할 사업자가 없다고 큰 소리치며 해외 서비스를 이용했던 모 소셜커머스 업체가 있었다. 이 기업은 이미지가 전체 트래픽의 90%가 넘었다. 큰 소리치며 미국에 서버를 둔 결과는? 경쟁사보다 1초 늦은 이미지 로딩 속도였다. 1초의 경쟁력을 잃어 버린 것이다. 당시 이 사이트에 접속하기 위해 도메인 주소를 웹 브라우저에 입력하면 마치 누가 뒤에서 잡았다 놔준 것 같은 느낌이었다. 결국 이 기업은 1초의 지연을 이기지 못하고 서버를 국내로 옮겼다. 클라우드 업계에 널리 퍼진 후문에 따르면 한국에서 자사를 감당할 인프라가 없다는 큰 소리와 달리 실제 한국으로 인프라를 옮겨와 보니 판매 이벤트와 같은 피크 타임에도 접속 처리에 하프랙 규모의 서버도 차고 넘쳤다고 한다. 이건 수문이 아니라 목격담이라 봐도 된다.  

 

<모 만화 사이트 사례>
최근 만화로 창업에 뛰어든 스타트업들이 많다. 이 중 몇몇 기업은 GB급 트래픽을 쓸 정도로 시장에 성공적으로 진입한 곳도 있다. 모 코믹스의 사례가 떠오른다. 서비스 개시 1년 만에 큰돈을 번다고 소문만 기업이었는데, 모 코믹스는 해외 PaaS 서비스가 유일하게 자사의 필요에 맞았다고 말했다. 그들의 필요란? 이미지 보호가 되는 캐시 서비스였다. 모 코믹스는 G사의 PaaS가 최고였다고 동영상 등을 통해 자사의 경험을 세상에 알렸다. 
하지만 최근 시장에 도전하는 신생 만화 서비스 업체들의 접근법은 좀 다르다. 해외 서버 이용이 자칫 문제가 될 수 있음을 알아서인지 신생 기업들은 G사의 PaaS를 최고로 꼽지 않는다. 신생 기업들은 국내 클라우드 사업자의 서비스를 이용한다. 대부분 이용 형태를 보면 NGNIX로 이미지 인증을 처리하고, SSD를 주 스토리지로 사용한다. 고도의 전송이나 보안이 아니라 최적의 속도 보장을 우선시하는 구성이다. 국내 클라우드 서비스 이용 만화 서비스 기업들은 해외에서 서비스하는 기업보다 1초 이상 빠른 속도와 네트워크 병목이나 장애 없는 안정성에 만족한다. 더불어 G사 서비스와 비교해 1/4 수준의 비용에도 만족감을 표현하고 있다. 컨텐츠 경쟁력이 있으면 보통 3개월 이내에 투자비를 회수하는 경우도 있다. 
 
정리하자면 온라인 서비스 세상에서 1초는 매우 큰 차이를 만든다. 대형 업체들이 왜 해외에 나갈 때 가능한 한 직접 인프라를 구축하는지 그 이유는 명확하다. 그래야 빠르다. 국내가 주요 무대인데 해외에 서버를 둔다는 우를 범하지 않으려면? TCP가 갖는 한계는 곧 글로벌 클라우드 서비스가 갖는 한계이기도 하다는 사실을 직시해야 한다. 그리고 스타트업은 주요 고객이 어디에 있는지를 고려해 서비스 사업자를 골라야 한다는 기본을 잊지 말아야 한다. 
Subscribe
Notify of
guest
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback

[…] 아래는 TCP 프로토콜과 해외 접속에 대해서 쓴 우리 회사 블로그 글입니다.    – 굼뱅이 프로토콜 tcp – 레알? http://idchowto.com/?p=12883   2. 해외 API를 […]

1
0
Would love your thoughts, please comment.x
()
x