구글 TCP Fast Open paper (TFO)를 읽고

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

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가 리눅스 커널에 적용된다고 여러 어플에 적용된다면 좋을 수도 있겠다는 생각이 든다.