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

http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf

이 paper를 읽으니, 재미가 있었다. 기억에 남는 것은 thread 방식의 문제를 compiler가 고치면 된다고 했다. dynamic stack growth, live state management, synchronization 등의 문제에 대해서 compiler의 도움을 얻는다면 성능이 잘 나올 수 것 같다고 작성했다.

------

내가 다니고 있는 회사의 웹 서버에서 사용하는 수많은 서버들의  web 서버들은 여전히 apache http가 가장 편하고 안정적이기 때문에 이를 사용하고 있다. 또한 nginx를 일부 사용하고 있다. was인 tomcat과 연동해서 사용할 때는 대부분 apache http 서버를 사용하고 있고, 주로 static 서버로 사용할 때는 nginx 를 사용하고 있다. 물론 nginx는 tomcat과 연동해서 쓰고 있다.

event-driven이든, fork/thread 방식이든 상관없이 이미 안전하고 운영하기 편리한 것으로 검증 받는 것으로 가는 것은 사람의 기본 심리인 것 같다.

2003년도에 thread나 event 방식의 개발 중에 어느 것이 더 좋은 것인지 학자들끼리 토론하는 것이 있었던 것 같다. 나는 그 때 머했나? 음. 당시에 다니던 전직 회사에서는 thread에 대한 부담감이 많이 있었다. 미들웨어 개발 당시에 thread의 남발로 인한 부작용이 심각했다. 너무 많은 thread들이 돌아다니면서 conditional 코드들이 생기고 코드는 점점 복잡해져 갔고, 무거워져 갔다. 성능이 느려지기 시작했다. 또한 코드 또한 복잡해졌다. 당시에 쓰레드를 남발하고 synchronized 블럭을 잘 써서 개발자라면 능력 있는 개발자로 여기는 행태도 있었다.

운영체제에서 쓰는 one thread에서 동작하는 polling 방식의 event 방식으로 구현하는 것은 어떨까 고민하고 구현하던 중이던 시점인 것 같다. event driven 구현 방식도 api를 제공이나 내부 구현의 복잡성, 속도에 대해서 한계가 존재했다.

구현 후 느낀 점은.. 어떻게 구현해도 만족시키지 못했던 것 같다. 각각 장/단점이 있었던 것 같다. 그 틀에서 어떻게 좀더 성능을 높인다는 것은 뼈를 깎는 고통인 것으로 기억한다. 나의 무식과 무지가 많이 드러나서 힘들었다.  웹 환경에서는 장비를 늘리고, scalabity를 지원하는 오픈소스를 사용하는 지금의 모습과는 많이 다른 것 같다.