우분투 TCP window scaling 관련(Flow control)

서버개발캠프 프로젝트 중

부하 테스트를 진행하며 좀 더 서버의 성능을 올려보기 위해 건드렸던 것이

TCP window size였다. 

작년에 컴퓨터통신 과목을 들었을 때 공부했던 기억이 어렴풋이 나서

프로젝트 중에 정말 반가웠다. 

더 잊어먹기 전에 복습도 할 겸 정리를 하려고 한다. 

 

 

 

 TCP의 window라는 개념은 TCP가 지원하는 여러 기능 중에 (당연히 UDP는 이런거 없다.)

Flow control(흐름 제어)로 부터 만들어졌다.

 

 흐름 제어는 Sender(S)와 Receiver(R)간의 송수신 속도 차이를 해결하기 위해 나온 것이다.

R이 S보다 빠르다면 상관없겠지만

만약 S가 R보다 빠르다면? 언젠가는 R의 수신 버퍼가 꽉 차게 될 것이고

결국 나머지 데이터는 소실될 수 있다.

 

Congestion Control과 Flow Control을 혼동하지 말것

Congestion Control은 네트워크 - 호스트간 제어

Flow Control은 호스트 - 호스트간 제어

 

 

 따라서 수신자를 주체로 이 데이터 전송을 제어해주는 것이 흐름 제어이다.

먼저 고안된 방식은 Stop & Wait 방식인데

대략 하나 보내고 응답받고 다음꺼 보내고하는 방식이다.

듣기만 해도 속도가 느려보인다.

 

따라서 고안된 방식이 바로 'Window'이다.

TCP/IP에서 각 호스트는 2개의 Window를 가지고 있다. (송 / 수신).

하나씩 보내고 받고하던 방식을 떠나 이제는 수신자의 Window 크기 만큼

ACK를 받지 않고 송신자는 한번에 메세지를 전송하고

그 안의 메세지가 모두 ACK를 받으면 다음 메세지를 전송하고 하는 방식이다.

 

그 Window의 크기는 소켓 연결시 수행되는 3-way handshake에서 맞춰진다고 한다.

1. SYN(C->S) 2. SYN+ACK(S->C) 3. ACK(C->S) 순으로 동작되는데

1)과 2)에서 서로의 버퍼 크기를 알려주게 되고

3)에서 해당 버퍼 크기와 RTT등 여러 요소들을 토대로

결정된 Window 크기를 수신자측에 보내주게 된다.

 

이때 정해진 Window크기는 초기 설정대로 고정되는 것이 아니라

통신 중간에도 동적으로 사이즈가 조절된다.

 

이를 통해 Sliding window라는 흐름 제어 기법이 수행된다.

먼저 Window 크기만큼 수신자에게 메세지를 전송한다.

그러면 수신자는 메세지를 받은 후 

자신의 수신 버퍼가 얼만큼 더 받을 수 있는지

ACK로 응답한다.

 

송신자는 해당 ACK를 보고 더 보낼 수 있는 만큼 

Window를 밀어(Sliding) 다른 메세지들을 보내고

아직 ACK를 못받은 메세지는 그대로 Window안에서 기다린다.

 

만약 이 ACK에서 수신자의 수신 버퍼 잔여 크기가

송신 Window보다 크다면

처리 속도가 빨라진 것으로 알아듣고 Window크기가 늘어나지 않을까? - 내 생각

 

 

 

 

 

그래서 EC2 우분투 서버의 Window사이즈는 늘렸지만

송신자의 버퍼크기를 고려하지 않고 정한 사이즈인데

이게 과연 실효성이 있는지 궁금하다.

(없다는게 아니라 정말 궁금하다.)