이 블로그는 내가 쓴 쓴글에 대한 후속이다. 

http://knight76.tistory.com/entry/Google%EC%9D%98-TCP-Fast-Open-paper 
 

 

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//pubs/archive/37517.pdf

 

예전에 RTOS의 통신 프로토콜, 방송용 전송 프로토콜(mpeg2, dab 프로토콜,)을 일부 구현하면서 transport layer에 대해서 관심이 많다. 이번에 구글에서 나온 TCP Fast Open을 보고, “TCP / IP Illustrated, Volume 1”을 다시 보았다. 그리고, “Blind TCP/IP hijacking is stall alive(TCP 하이재킹)” 블로그도 읽었다.

 

최근 웹 페이지 분석 자료.

(참조 : http://code.google.com/intl/ko-KR/speed/articles/web-metrics.html)

 

이 paper는 TCP 연결 기본과 관찰력으로 나왔다고 볼 수 있다.  파일을 읽고 쓰는 것보다 파일을 열고 닫는 것이 리소스가 많이 드는 것처럼 네트웍 소켓을 열고 닫는 부분에 대해서 고민하는 것과 비슷하다.  이 paper는 TCP 연결의 여는 부분에 대해서 고민했다.

크롬 브라우져와 구글 서버간의 통신 상태를 2011년에 28일 동안 분석해보았다. 33%정도가 Http persistent 연결이었다. 최신 브라우져는 서버당 연결 개수를 높여 빠르게 로딩하려고 하고 있다.
(TCP 3-way handshake 방식은 connection마다 이루어지기 때문에 서버와 클라이언트에 부하를 이룬다. 그러나 DDOS 나 트래픽이 너무 몰릴 때에는 안좋을 수 있어서 Keep Alive를 하지 않는 경우가 많다. Apache Http 서버의 기본 설정이 keep alive가 아닌 것으로 바뀐 것은 의미가 있다. 그렇지만 역시 keep alive 상태로 해서 http permanent connection인 경우에는 확실히 부하를 적게 할 뿐 아니라 브라우져의 병렬 처리 소켓 개수로 인해서 속도를 높일 수 있어서 점차 사용이 확대되고 있다. )

새로운 TCP 연결에 대한 요청은 Cold Request, 이미 연결된 TCP 연결에 대한 요청을 Warn request라고 정의했다. 새로운 TCP를 연결(Cold request) 하는데 Cost가 많이 들었다. Cold request는 8~28%의 Cost가 더 든다.

 

Cold request가 50% 정도 느리다.

 

TCP 3 way handshaking은 delay와 중복 syn 패킷을 처리하기 위해서 만들어졌다. Tcp Fast Open은  이 철학을 잘 이해하고 이 부분에 좀 더 보강을 했다. TCP 패킷은 security “Cookies” 값을 추가했다. 기존에 hijacking당할 수 있는 TCP에 보안적인 부분을 염두해서 보강했다. 클라이언트는 cookie 요청을 하지만, 실제로 cookie generation은 서버에서 하게 한다. 클라이언트는 cookie를 캐쉬해두고 사용한다. 서버는 이 쿠키를 validate한다.

TFO의 중요한 포인트는 client와 server간의 3 way handshaking 을 하면서 데이터가 전달되게 하는 것이다.  이렇게 함으로서 보다 많은 패킷을 전달할 수 있다.

 

 

그리고, TCP의 congestion control은 따로 수정할 필요가 없으며 sendto, sendmsg 와 같은 시스템콜을 수정하여 편하게 쓸 수 있게 했다.

 

좋아진 결과는 4~10% 정도였다. RTT가 늦어야 효과가 높았다. 떄로는 41%까지 좋아졌다.

현재는 IETF에 제안서(http://tools.ietf.org/html/draft-cheng-tcpm-fastopen-00)를 넣은 상태이다.

 
2012년 1월 까지 리눅스 커널에 패치되지는 않은 상태이다.
 

마치며..

response time이 긴 웹 서버의 경우의 서버, 국내용 서버라면 쓰기 어려운 부분이 있지만 세계를 배경으로 하는 웹 서버에 대해서는 쓸만한 대안이 될 수 있겠다는 생각이 들었다. 현재 필리핀이나 중국에서 한국 웹 서버를 접근하는데 시간이 오래 소요된다고 한다. TFO가 리눅스 커널에 적용된다고 여러 어플에 적용된다면 좋을 수도 있겠다는 생각이 든다.

Posted by '김용환'
,

 

구글에서 TCP Fast Open paper를 발표했다.

<광고 동영상>

 

Let's make TCP faster

http://googlecode.blogspot.com/2012/01/lets-make-tcp-faster.html 에 간단한 요약자료가 있다.

 

1. TCP initial congestion window 를 10으로 늘리자. TCP connection 처음에는 3패킷만 전달되게 되어 있는데. 이를 수정하면 10% 이상의 지연시간을 줄 일 수 있다.

2. 초기 timeout을 3에서 1로 줄이자.

3. TCP Fast Open를 사용하자. 기존의 33%의 HTTP 요청은 TCP 연결에 사용 된다. 이를 개선한 TCP Fast Open은 Page Load 시간을 평균 10%, 때로는  40%까지 줄일 수 있다.

4. Proportional Rate Reduction for TCP를 사용하자. 네트웍으로 전달되는 패킷 손실은 순서가 꼬이거나 충돌로 문제가 될 수 있다. 새로운 recovery 알고리즘이 필요하여 부드럽게 재전송을 하도록 해서 빠르게 할 필요가 있다. 현재 이 것은 리눅스 커널에 탑재되어 있고, TCP 표준에 추가될 예정이다.

 

TCP Fast Open paper 링크는 아래와 같다.

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//pubs/archive/37517.pdf

 

Proportional Rate Reduction for TCP 에 대한 paper 링크는 다음과 같다.

http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//pubs/archive/37486.pdf

 

시간 될 때 봐야겠다.

Posted by '김용환'
,