컴퓨터 네트워크: Flow Control

TCP: Transmission Control Protocol

7. Flow Control

 

Flow Control

생산자가 데이터를 생성하는 속도와 소비자가 데이터를 사용할 수 있는 속도의 균형을 유지.

 

 

sliding window

Send window in TCP

1. Sender는 Receiver가 Ack을 보내면서 알려준 rwnd 값을 통해 상대방 버퍼의 빈 공간을 파악하고, 그 빈 공간만큼을 Send window 사이즈로 정한다. window 사이즈는 Receiver가 한번에 받을 수 있는 데이터의 양이다.
2. 데이터 전송 후, 보낸 데이터는 데이터 전송 오류를 대비하여 여전히 Sending Buffer에 남겨둔다.
3. 상대방이 Ack을 보내 해당 데이터를 잘 받았다는 표시를 하면 해당 데이터를 Sending Buffer에서 삭제한다.
4. 데이터를 삭제해서 생긴 빈 공간만큼 생산자가 생성한 데이터를 받아와 Receiver에게 보낼 준비를 한다. 

 

Receive window in TCP

1. Receiver는 연결 과정에서 Sender에게 SYN + ACK을 보내면서 초기 rwnd 즉, Receiving Buffer의 빈 공간을 알려준다.
2. 상대방이 데이터를 보내면 데이터의 양만큼 Receiving Buffer의 빈 공간이 줄어든다.
3. 보낸 데이터를 잘 받았다는 확인을 하기 위해 상대방에게 다음 ACK를 보내면서, 현재 Receiving Buffer의 빈 공간도 함께 알려준다.(rwnd를 이용)
4. read를 통해 읽어 application에게 올려보낸 데이터는 Receiving Buffer에서 삭제한다.

 

stop & wait와 window 방식의 효율성 비교

 

 

TCP/IP protocol suite

 

전체 조감도

 

Send

 

 

Receive

 

 

An example of flow control

• 윈도우 사이즈가 어떻게 변하는지 주의깊게 살펴본다.
• Client가 Sender, Server가 Receiver (단방향)

 

Silly Window Syndrome

<송신 측에서 발생하는 신드롬>

• Nagle 알고리즘

키보드를 한 글자씩 칠 때마다 1byte의 데이터가 receiver에게 전송된다고 생각해 보자.

데이터 전송 시에는 MAC, IP, Port 번호가 반드시 필요하다. (택배는 송장없이 이동할 수 없다.) 따라서 1byte의 데이터를 전송하더라도 수신자의 주소의 정보를 담고 있는 헤더가 반드시 함께 전송되어야 한다. 

그런데 1byte의 데이터를 전송하고자 매번 40byte 이상의 헤더(TCP 헤더 크기: 20 ~ 60byte, IP 헤더 크기: 20byte, MAC/CRC를 제외하더라도 40byte 이상의 헤더가 필요)를 함께 전송하는 것은 효율적이지 못하다. 

이러한 문제점을 해결하고자 조금 더 효율적인 전송방식인 Nagle 알고리즘이 고안되었다. 

 

처음 도착한 키보드의 1byte는 그냥 보내고, 그 뒤로 1byte씩 데이터가 도착하면 그 데이터는 보내지 않고 우선 대기시킨다.

이후 상황은 두 개로 나뉜다.

1. 데이터가 *MSS만큼 쌓이면, 즉시 해당 패킷을 전송한다.

2. 가장 처음 보냈던 1byte에 대한 ACK이 도착할 때까지 데이터가 MSS만큼 쌓이지 않는다면, 데이터가 꽉 차지 않아도 해당 패킷을 전송한다.

 

 

*MSS: Maximum Segment Size(최대 세그먼트 크기), 대략 500byte

 

 

 

<수신 측에서 발생하는 신드롬>

• Clark 해결방법

   - read 속도가 느려서 버퍼가 1byte씩 비워지는 상황.

   - 수신 버퍼가 MSS만큼, 또는 전체 버퍼크기의 1/2만큼 비어 있는 경우에만 상대에게 정상적인 응답(ACK)을 보내주고 그렇지 않을 경우 window size를 0으로 해서 전송(rwnd = 0)

   - Sender는 Receiver가 가리킨 곳에서 데이터 송신 stop (즉시 전송 중단. 받은 ACK의 rwnd가 0이기 때문에 Receive Buffer가 꽉 찼다고 판단해 데이터를 보내지 않음)

   - ACK 전송을 하기는 하는데, window size를 0으로 해서 전송

• 확인응답의 지연

   - 일정 크기 이상의 empty space 생겼을 때만 ACK 보냄.

   - Sender는 rwnd 받은 만큼(window size만큼) 데이터를 보내고 stop (Clark 방법보다 데이터 전송이 조금 더 이루어짐)

   - ACK 전송을 아예 안 하고 미룸.

 

 

SYN Flooding = DoS (denial-of-service, 서비스 거부)

한꺼번에 여러 대의 컴퓨터에서 접속하는 경우, DDos(Distributed Denial of Service )

 

서버와 클라이언트의 통신

Client는 서버소켓에 SYN을 보내 서버 연결 요청을 한다. 서버가 SYN + ACK을 보내주면 Client는 연결 요청 대기 큐에 들어간다. 

Client에게서 ACK이 오면 Accept 함수가 리턴이 되어서 생성된 새로운 소켓과 Client가 연결되고, Client는 Server와 통신을 할 수 있게 된다.

새로 생성된 소켓과 Client1이 정보를 송수신하고 있는 도중 다른 Client가 연결을 요청하면, 해당 클라이언트를 연결 요청 대기 큐에 넣는다.

참고: 이전에 포스팅했던 글 중 서버-클라이언트 connection 이미지

 

 

SYN Flooding

서버는 클라이언트가 연결 요청을 했을 때 연결이 수락될 때까지 해당 클라이언트를 연결 요청 대기 큐에 집어넣는다. 클라이언트들은 연결 요청 대기 큐에 들어가서 연결을 기다린다.

클라이언트는 서버가 보낸 SYN + ACK을 받고 최종적으로 서버에 ACK을 전송해야만 서버와 연결이 가능하다. 따라서 클라이언트의 ip주소가 잘못된 경우 SYN + ACK이 엉뚱한 IP주소로 보내지고 서버는 클라이언트로부터 ACK을 받지 못하게 된다. 

 

RAW소켓은 헤더 정보들에 대해 프로그래머가 직접 제어할 수 있게 해주는 소켓이다. 즉, RAW소켓을 사용하면 IP헤더와 TCP헤더를 직접 제어할 수 있다. (출처: https://mangkyu.tistory.com/16 [MangKyu's Diary])

이를 악용하여 누군가 의도적으로 Client의 IP 주소를 변경해 서버에 여러 번 접속을 시도한다면, 서버가 SYN+ACK을 보낸 IP주소에서 ACK이 돌아오지 않으므로 클라이언트와 서버 간 연결이 정상적으로 이루어지지 않는다.

서버와 연결되지 못한 클라이언트가 대기큐에 쌓여 대기큐가 가득 차면 정상적으로 서버에 접속하고자 하는 사용자는 서비스를 이용하지 못하게 된다.

이러한 현상을 SYN Flooding(SYN 홍수), 또는 DDoS(denial-of-service, 서비스 거부)라고 한다. 

 

---

자료 출처:

• TCP/IP Protocol Suite 4th Edition Slide
  (Behrouz A. Forouzan 저, McGraw-Hill, 2010)

 

서버-클라이언트 연결 참고: 

2021.10.01 - [CS/컴퓨터 네트워크] - 컴퓨터 네트워크: State transition diagram

컴퓨터 네트워크: State transition diagram

 

 

SYN Flooding

Silly Window Syndrome