학교복습용/컴퓨터네트워크

컴퓨터네트워크 6주차 / Transmission Control Protocol

브로콜리여사 2025. 4. 9. 19:16

ACK 세그먼트는 시퀀스 번호를 사용하지 않으며 인식되지 않는다.

데이터가 순서에 맞지 않게 도착하여 수신TCP에 의해 일시적으로 저장될 수 있다.

하지만, TCP는 순서가 맞지 않는 데이터가 프로세스에 전달되지 않도록 보장한다.

 

Normal operation 

normal operation

ACK-delaying timer: 클라이언트가 즉시 ACK를 보내지 않고 잠시 기다리는 타이머 (보통 50ms)

rule 1 : 데이터와 ACK을 합쳐 보냄으로써 별도의 ACK패킷을 줄임.

rule 2 : 타이머만료로 50ms 내에 클라이언트가 보낼 데이터가 없으면 단독 ACK(Ack: 5001)만 전송함.

rule 3 : 50ms 전에 응답할 데이터가 생기면 즉시 ACK 포함해서 보냄

Normal operation에서 rule 1, rule 2, rule 3는 ACK을 줄어보려고 하는 상황이다.

 

Lost segment

 

수신 TCP는 프로세스에 정렬된 데이터만 전달한다.

RTO: Retransmission Timeout (재전송 타이머) : ack을 받아야만 stop이 된다.

Seq: 701–800 전송 → 유실 (lost) : 서버는 이 세그먼트를 받지 못함, 클라이언트는 아직 ACK를 받지 못하므로 RTO 타이머 유지, Seq: 801–900 전송됨: 서버는 701–800이 없는데 801–900을 받음 → 순서가 어긋난 데이터👉 Rule 4 적용:
서버는 out-of-order 데이터를 임시로 버퍼에 저장, 하지만 **여전히 Ack: 701**만 보냄 → 즉, 누락된 구간이 채워지기 전까지는 ACK를 갱신하지 않음, RTO만료 restart : 누락된 세그먼트를 수신하면, 버퍼에 임시저장된 out- of -order 세그먼트와 연결해서 정상처리 그래서 901 응답

 

 

 

 

Fast retransmission

 

Fast Retransmission이란?

패킷이 손실되었을 가능성이 있을 때, (RTO타이머) 타임아웃까지 기다리지 않고 중복ACK을 기반으로 더 빨리 재전송하는 TCP 메커니즘.

TCP는 신뢰성있는 데이터 전송을 위해 ACK(확인응답: 받은 패킷에 대한 응답을 보냄)과 timeout(일정 시간내 ACK가 안오면 손실됐나 하고 다시 전송함.) 을 사용한다. 하지만 타임아웃은 느리다. 그래서 Fast Retransmission이 등장했다.

핵심은 중복된 3개의 ACK가 들어오면 해당 패킷이 없어졌다고 가정하고 빨리 재전송을 하는 것이 fast transmission이다. 

3개의 중복 ACK을 수신한 클라이언트는 RTO타이머가 만료되기 전에 누락된 seq : 301-400을 즉시 재전송

 

 

Lost acknowledgment

 

서버는 601–700까지 받은 후 Ack: 701 전송, 하지만 이 ACK는 네트워크에서 손실(lost)

cummulativ에서 ACK이 손실되어도 신뢰성에 크게 문제가 없는 이유

ACK 누락 수신 확인 응답(ACK)이 손실되어도, 데이터가 잘 도착했으면 수신자는 다음 ACK에서 누락된 것을 누적 커버함
재전송 조건 송신자는 RTO 타이머가 만료되거나 중복 ACK 3번 이상 수신 시 재전송함. 단순 ACK 손실로는 재전송 안 함
누적 ACK TCP는 마지막에 연속적으로 도착한 데이터에 대해 하나의 ACK로 처리하여 효율을 높임

 

 

Lost acknowledgement corrected by resending a segment

ACK:701이 네트워크에서 손실됨. 클라이언트는 ACK을 못 받았기 때문에 타이머(RTO)가 만료될 때 까지 기다림. 서버는 이미 해당 데이터를 받았지만 TCP는 중복데이터라도 다시 ACK을 보낸다.  Rule 6: 중복 데이터 수신 시 ACK 재전송, 받았는데 또 받으면 기다리지 말고 바로 보내자

 

ACK가 제대로 처리되지 않으면 deadlock이 발생할 수 있습니다. 만약 rule 6을 지키지 않고, 서버가 중복 데이터에 대해 ack을 다시 보내지 않으면, 클라이언트는 ack을 계속 못받음. 서버는 이미 받은 데이터라 새로 응답안함. >> 결과적으로 양쪽모두 멈춘 상태 : deadlock

Deadlock

ACK 하나가 없어졌을 경우에 deadlock이 발생할 수 있다. 데이터가 가고 ACK이 왔는데 RWND=0 (Window size = 0)으로 가거나 Clarck으로 인해 0으로 갈 수 있다. 이때 MSS만큼 빈공간이 생기거나 반 이상의 reciever buffer가 있을 때 제대로 된 RWND를 보낸다. 이때 제대로 갈 때 보내는 ACK이 없어질 수도 있다. 이때 reciever는 데이터를 기다리고, sender는 RWND = 0으로 착각해서 서로 deadlock이 걸리게 된다. RWND=0을 받을 때 sender에서는 persistence timer를 킨다. Timer가 만료되면 작은 사이즈의 패킷을 먼저 보낸다. 이 데이터를 probe segment라고 한다. 상대방은 이것을 받고 ACK을 보낸다. 이때 ACK과 RWND를 같이 보낸다. RWND=K로 받으면 아까 보낸 ACK이 없어졌을 것이라고 가정하고 데이터를 K만큼 보내기 시작한다. 이거를 좀 자세히 설명해줘

 

상황 요약: RWND=0 + ACK 손실 → Deadlock 가능

💥 발생 배경

  • TCP 수신자는 자신이 감당할 수 있는 수신 버퍼 크기를 RWND(Receiver Window)로 광고함.
  • 수신자 버퍼가 꽉 차면 → RWND = 0 으로 보냄
  • 송신자는 RWND = 0을 받으면 전송을 멈춤
    (= 더는 보낼 수 없다는 의미)

⚠️ 문제가 되는 경우

  • 수신자 쪽 버퍼가 비었지만, ACK + 새로운 RWND 광고 패킷이 손실됨
  • 송신자는 여전히 RWND=0으로 알고 있어 아무것도 안 보냄
  • 수신자는 버퍼가 비었는데도 송신자가 데이터를 안 줌

➡ 서로가 서로를 기다리는 상태 → Deadlock

✅ 해결책: Persistence Timer + Zero Window Probe

TCP는 이러한 상황을 막기 위해 Persistence Timer라는 타이머를 사용합니다.

🔧 Persistence Timer란?

  • 송신자가 RWND = 0을 받았을 때 시작하는 타이머
  • 만료되면, **작은 데이터(1바이트 또는 0바이트)**를 보내서
    수신자에게 “버퍼 좀 생겼냐?”고 탐지함
  • 이 패킷을 Zero Window Probe라고 부름

✅ Zero Window Probe 동작 과정

1. Sender가 RWND = 0을 받음

  • 수신자: "지금 바빠. 버퍼 없음"
  • 송신자: 데이터 전송 중단 + Persistence Timer 시작

2. 수신자 버퍼에 공간이 생김

  • 예: MSS만큼 공간 or 50% 이상 공간 생기면, ACK + RWND > 0을 송신
  • ❗ 하지만 이 패킷이 유실되면 송신자는 계속 RWND=0인 줄 앎

3. Persistence Timer 만료

  • 송신자는 Zero Window Probe (1바이트 or 0바이트 세그먼트) 전송

4. Receiver가 이 Probe를 받음

  • 수신자는 정상적으로 ACK 응답을 보냄 (이 때 RWND = K 포함)

5. Sender가 ACK+RWND를 받음

  • 송신자는 이제 "버퍼 생겼구나!"라고 판단
  • RWND = K만큼 데이터를 다시 보내기 시작

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://ys-cs17.tistory.com/66

 

Transmission Control Protocol (TCP) (4)

TCP에서 내가 보낸 ACK을 상대가 받았는지 못 받았는지 모른다. TCP의 특성 중 가장 중요한 것은 신뢰성 보장이다. 이는 데이터 전송 실패 시 재전송한다는 의미이다. 중간에 받지 못한 데이터를 재

ys-cs17.tistory.com