RDT(Reliable Data Transfer) 복습

지난 시간에 학습한 RDT의 주요 특징들:

1. Cumulative ACK
   • 특정 시퀀스 번호까지의 모든 데이터가 성공적으로 전달되었음을 확인하는 방식
2. Fast Retransmit
   • 타이머 만료 전에 동일한 ACK가 3개 연속으로 도착하면 (총 4개) 해당 세그먼트가 유실되었다고 판단
   • 즉시 재전송을 수행
3. 동적 타임아웃 설정
   • 통신 상황에 따라 타이머 값을 동적으로 조정
4. 흐름 제어(Flow Control)
   • 수신자의 처리 능력에 맞춰 송신 속도를 조절하는 메커니즘

여기서 복습 TCP는 운영체제 커널에 구현되어 있으며, 소켓 API를 통해 프로세스가 TCP 서비스를 이용할 수 있다. 네트워크 각 계층은 상위 계층에게 서비스를 제공하는 구조를 가진다.

흐름 제어(Flow Control)

기본 동작 원리

TCP에서 수신된 데이터를 상위 프로세스로 전달하는 시점은 전적으로 프로세스의 결정에 달려 있다. 프로세스가 read() 시스템 콜을 호출해야만 TCP 수신 버퍼의 데이터가 애플리케이션 계층으로 전달된다.

만약 프로세스가 read() 호출을 자주 하지 않으면:

• 수신 버퍼에 데이터가 지속적으로 축적
• 버퍼 포화 시 추가 세그먼트 유실 위험 발생

수신 윈도우(Receive Window)

수신자는 자신의 수신 버퍼 여유 공간 정보를 송신자에게 전달한다. 이것이 수신 윈도우이며, TCP 헤더의 Window 필드에 포함된다.

송신자는 수신 윈도우 크기 이내에서만 데이터를 전송하여 수신자의 버퍼 오버플로우를 방지한다.

핵심: 윈도우 크기는 수신자에 의해 결정되며, 이는 시퀀스 번호가 송신자에 의해 결정되는 것과 대조적이다.

데드락 상황과 해결책

TCP 세그먼트 전송 조건

TCP 세그먼트가 전송되는 경우:

1. 프로세스의 write() 호출로 인한 데이터 전송
2. 수신한 세그먼트에 대한 ACK 응답 전송

데드락 시나리오

상황: 수신자의 버퍼가 포화 상태 → 송신자가 전송 중단 → 양측 모두 상대방의 응답 대기

문제점:

• 송신자: 수신 윈도우 갱신을 위해 대기
• 수신자: 전송할 데이터가 없어 응답 세그먼트 없음

윈도우 프로브(Window Probe)

해결 방법:

• 수신 윈도우가 0임을 통지받은 송신자가 주기적으로 작은 크기의 윈도우 프로브 세그먼트 전송
• 크기: TCP 헤더(20바이트) + 데이터 1바이트 = 21바이트
• 목적: 수신자의 윈도우 상태 확인

세그먼트 크기 최적화

세그먼트 크기의 딜레마

큰 세그먼트의 장점:

• 적은 세그먼트 수로 효율적 전송
• 각 세그먼트당 오버헤드 최소화

큰 세그먼트의 단점:

• 유실 시 재전송 비용 증가
• 작은 데이터 전송 시 지연 발생

네이글 알고리즘(Nagle Algorithm)

전송 조건 중 하나가 만족될 때까지 버퍼에 데이터 축적:

1. 최대 세그먼트 크기(MSS) 만큼 데이터 축적
2. 이전 세그먼트에 대한 ACK 수신
3. 타이머 만료

동작 예시: 데이터 [0,1,2,3,4]가 있을 때:

• 처음 0번 세그먼트 전송
• ACK 수신 시: 축적된 데이터(예: [1,2]) 즉시 전송
• ACK 미수신 시: 타이머 만료 후 0번 세그먼트 재전송
• MSS 도달 시: ACK와 무관하게 전송

연결 관리(Connection Management)

3-Way Handshake (연결 설정)

1단계: 클라이언트 → 서버 (SYN)

• SYN bit = 1
• 시퀀스 번호 = x (임의값)

2단계: 서버 → 클라이언트 (SYN-ACK)

• SYN bit = 1
• 시퀀스 번호 = y (임의값)
• ACK 번호 = x + 1

3단계: 클라이언트 → 서버 (ACK)

• SYN bit = 0
• ACK 번호 = y + 1
• 이 단계부터 데이터 전송 가능

연결 종료 (Connection Termination)

1단계: 프로세스 close() 호출 → FIN 메시지 전송

2단계: 상대방의 FIN에 대한 ACK 응답 + 상대방도 FIN 전송

3단계: 마지막 ACK 전송

중요: FIN 교환이 완료되어도 TCP 연결이 즉시 종료되지 않는다. 연결 설정과 마찬가지로 양방향 확인 절차가 필요하다.

%%

Flow Control

저번 시간에는 RDT(reliable data transfer)에 대해서 학습했다. 주요한 특징들로는 cumulative ack를 사용해서 특정 지퀀스 번호까지의 모든 데이터가 성공적으로 전달한다는점. 그리고 여기에 fast retransmit 방식을 사용해 타이머가 끝나기 전에 같은 ack가 4개 도착한다면 해당 세그먼트는 유실되었다고 판단하고 즉시 재전송 한다는 점. 그리고 타임아웃 값을 타이머를 통신이 있을때마다 동적으로 정한다는 점.

그리고 또 다른 주요한 특징으로는 흐름 제어Flow control가 있다.

여기서 복습 TCP는 운영체제 커널에 구현되어 있고, 운영체제에서 제공하는 소켓 API를 통해 프로세스가 소켓을 생성하고, 포트에 할당하면 TCP를 사용할 수 있게 된다. 그리고 네트워크의 각 계층은 상위 계층에게 서비스를 제공한다.

TCP가 받은 데이터를 언제 가져갈지는 프로세스의 재량이다. 프로세스가 read()를 해야 TCP층에서 수신 버퍼 안에 있는 데이터를 올려줄 수 있다. 만약에 read()를 자주 하지 않으면 버퍼에 계속해서 데이터가 쌓이게 된다. 만약에 버퍼가 꽉 찼는데 계속해서 세그먼트가 도착한다면 어차피 유실될것이니까, 수신자는 자신의 수신 버퍼에 남은 공간에 대한 정보를 보낸다. 이를 수신 윈도우라고 한다. (이전시간 헤더에 Window라고 되어있는 부분. 송신자는 피드백 헤더에 있는 수신 윈도우 크기만큼만 데이터를 보낸다. 즉 윈도우 사이즈는 수신자에 의해 정해진다. 송신자 측의 시퀀스 번호와 마찬가지로 윈도우 사이즈도 수신자 측에 의해 결정되는 것이다.

데드락 상황

TCP에서 세그먼트가 나가는 경우는 두 가지가 있다.

1. 프로세스에서 write()를 해서 송신 버퍼에서 보낼 세그먼트가 있을 때.
2. 보낼 데이터가 없더라도, 수신한 세그먼트에 대한 피드백을 보낼 때.

만약에 수신자 측에서 수신 버퍼가 포화상태라고 알린다면, 송신자는 세그먼트를 보내지 않고 기다릴것이다. 언제까지? 다음에 도착하는 세그먼트에서 업데이트된 수신 윈도우 상황을 확인할 때 까지. A와 B 사이에서 이런 상황이 발생했다고 하고, B는 A의 버퍼가 여유가 생길 때 까지 기다리고 있다. 그런데 A는 B측에서 전송되는 세그먼트가 없으니 보낼 응답이 없고, 그래서 A 프로세스가 B 프로세스에 보낼 데이터가 있으면 거기에 같이 보내야하는데 만약 A 프로세스가 보낼 데이터가 전혀 없다면?

윈도우 프로브

이에 대한 해결책은 의외로 간단하다. B가 만약에 A로부터 수신 윈도우가 0이라는 소식을 받으면, 주기적으로 (TCP 헤더는 40바이트 정도 크기인데, 여기에 전송할 데이터의 첫 바이트만 담은) 41바이트의 작은 윈도우 프로브 Window Probe 세그먼트를 보낸다.

세그먼트의 크기는?

생각해보면 세그먼트의 가능한 제일 큰게 좋을것이다. 그래야 최대한 적은 수의 세그먼트를 주고 받을것이고 tcp 통신에서 각 세그먼트마다 적지 않은 비용이 든다는 점에서 최대한 세그먼트의 수를 줄이는게 좋을것이다. 그런데 세그먼트의 크기를 마구 늘리면, 일단 한번 유실됐을때 다시 전송해야되는 데이터의 양이 같이 커지면서 재전송 부담이 증가한다는 단점이 있고, 그리고 만약에 프로세스가 write()하는 데이터의 양이 적으면 하염없이 기다려야 된다는 단점이 있다.

이런 문제를 해결하기 위해 만들어진 Nagle 알고리즘은 이 문제를 간단히 해결한다.

네이글 알고리즘

네이글 알고리즘에서는 다음 조건 중 하나가 만족될 때 까지 버퍼에 데이터들을 모아둔다.

• 최대 세그먼트 크기(MSS)만큼 데이터가 모였을 때
• 이전에 전송한 세그먼트에 대한 피드백이 도착했을 때
• 타임아웃

[0,1,2,3,4]가 있으면 처음에 0을 전송한다. 그리고 다음과 같은 경우의 수가 있다.

1. ACK 도착
2. ACK가 오지 않음 (유실)

1번의 경우 ACK가 도착하는 사이에 그것이 얼마나 쌓여있든 프로세스가 전달한 데이터들, 예를들어 [1,2]가 있으면 이것을 전송한다. 2번의 경우는 결국 0 번 세그먼트에 대한 타임아웃이 발생하게 되고 다시 0번 세그먼트를 전송한다. 그런데 계속 프로세스가 데이터를 생산해서 MMS만큼 데이터가 버퍼에 쌓이게 되면 그건 0번 세그먼트와 상관 없이 전송한다.

Connection Management

Three way handshake를 통해 양측이 연결되어있음을 확인한다.

1. 클라이언트가 SYN 메시지를 전송한다. 헤더에 SYN bit가 1로 입력되어있고, 임의의 Seq 번호 x를 가진다.
2. 서버가 SYN ACK 응답을 전송한다. (마찬가지로 SYNbit가 체크되어있음) 마찬가지로 헤더에 SYNbit가 1로 체크되어 있고, 임의의 Seq번호 y를 가진다. 그리고 ACK번호는 클라이언트 측의 Seq 번호인 x를 사용해서 x+1이 된다.
3. 클라이언트가 다시 서버측 응답에 대한 응답 ACK를 전송한다. SYNbit는 체크되어있지 않고 ACK번호는 서버측의 Seq 번호 y를 사용해 y+1. 여기서부터는 데이터를 넣을 수 있다.

연결 닫기

1. 프로세스가 소켓을 close()하면 TCP에서는 FIN 메시지를 전송한다
2. 상대측에서는 FIN에 대한 응답 ACK를 전송. 동시에 상대측에서도 전송할 데이터가 없으면 FIN 전송
3. 여기서도 이에 대한 ACK를 전송한다.

그런데 서로 FIN을 전송했다고 TCP 연결이 바로 끊기는것은 아니다. 왜냐하면 연결을 닫을때도 연결을 시작할 때 처럼 확인을 해야되기 때문이다. %%