✅ P27 문제 해결을 위한 필수 개념 요약
1. TCP Sequence Number
- 정의: TCP 세그먼트의 시퀀스 번호는 해당 세그먼트가 전송하는 데이터 중 첫 번째 바이트의 번호입니다.
- 예시: 바이트 127부터 80바이트 전송 시 → 시퀀스 번호는 127이고, 다음 세그먼트의 시퀀스 번호는 127 + 80 = 207입니다.
📚 참고: {ch3.pdf} 235~236쪽 (Section 3.4 Reliable Data Transfer)
2. TCP Acknowledgment Number
- 정의: 수신 측이 다음으로 기대하는 바이트의 번호를 의미합니다.
- ✅ 누적 ACK(Cumulative Acknowledgment) 사용
→ 중간 일부만 도착하더라도, 가장 처음 누락된 바이트까지만 ACK 합니다.
📚 참고: {ch3.pdf} 235~238쪽 (Section 3.4), 258쪽 부근 (TCP ACK Generation)
3. 세그먼트 도착 순서에 따른 ACK 동작
-
✅ 순서대로 도착한 경우:
- 첫 번째 세그먼트: ACK = 127 + 80 = 207
- 두 번째 세그먼트: ACK = 207 + 40 = 247
-
⚠️ 두 번째 세그먼트가 먼저 도착한 경우:
- 예상 시퀀스가 아닌 세그먼트가 오면 → 중복 ACK 생성: ACK = 127
📚 참고: {ch3.pdf} 258쪽 부근
4. TCP Port Numbers
- TCP 세그먼트는 다음 정보를 포함합니다:
- Source Port Number
- Destination Port Number
- 일반적으로 연결 세션 동안 포트 번호는 동일하게 유지됨
📚 참고: {ch3.pdf} 221~224쪽 (Section 3.2 Multiplexing and Demultiplexing)
5. ACK 손실과 Timeout 처리
- ACK가 손실될 경우, 송신 측은 타이머가 만료될 때까지 ACK를 기다립니다.
- ⏰ 타이머가 만료되면 해당 세그먼트를 재전송합니다.
📚 참고: {ch3.pdf} 240쪽 (rdt3.0 개념에서 설명)
✅ P28 문제 해결을 위한 필수 개념 요약
1. TCP Flow Control (흐름 제어)
- 목적: 송신자가 너무 빠르게 데이터를 보내서 수신자의 수신 버퍼를 넘치게 하지 않도록 제어하는 기능.
- 이는 송신자의 속도를 수신자의 읽기 속도에 맞추는 속도 일치 서비스(speed-matching service)입니다.
📄 관련 페이지: {ch3.pdf} 280~282쪽
2. TCP Receive Buffer와 관련 변수
수신자는 TCP 연결마다 receive buffer(RcvBuffer)를 할당하며, 다음 변수가 정의됩니다:
LastByteRead: 수신 응용 프로그램이 버퍼에서 읽은 마지막 바이트LastByteRcvd: 수신 버퍼에 도착한 마지막 바이트- Receive Window (rwnd): 버퍼의 여유 공간
계산식:
[
rwnd = RcvBuffer - (LastByteRcvd - LastByteRead)
]
📄 관련 페이지: {ch3.pdf} 281~282쪽
3. 수신자가 송신자에게 rwnd 전달 방식
- 수신자는 자신의 rwnd 값을 ACK 세그먼트의 "Receive Window" 필드에 담아 송신자에게 전달함.
- 송신자는 다음을 보장해야 함:
[
LastByteSent - LastByteAcked \leq rwnd
]
즉, 수신자가 허용한 만큼만 데이터를 전송할 수 있습니다.
📄 관련 페이지: {ch3.pdf} 281쪽
4. rwnd가 0이 되었을 때의 처리
- 만약 수신 버퍼가 가득 차서 rwnd = 0이 되면 송신자는 블로킹됨.
- 이 경우 송신자가 아무것도 못 보내는 것을 방지하기 위해 1바이트 세그먼트를 계속 보내어 수신자의 rwnd 변화를 감지하도록 명시되어 있음.
📄 관련 페이지: {ch3.pdf} 282쪽
5. TCP 흐름 제어 vs 혼잡 제어
- 흐름 제어는 수신자의 속도에 맞추기 위한 것
- 혼잡 제어는 네트워크 내 혼잡을 방지하기 위한 것
- 둘 다 송신자의 속도를 제한하지만, 이유와 메커니즘이 다름
📄 관련 페이지: {ch3.pdf} 280쪽
✅ P32 문제 해결을 위한 필수 개념 요약
1️⃣ Round-Trip Time (RTT)의 정의
- RTT (Round-Trip Time)는 세그먼트를 전송하고 해당 세그먼트에 대한 ACK(확인 응답)를 수신하는 데 걸리는 시간입니다.
- TCP는 이를 샘플 RTT (SampleRTT)라고 부르며, 재전송된 세그먼트는 RTT 측정 대상에서 제외합니다.
📄 {ch3.pdf} 269쪽 설명 참조
2️⃣ RTT 측정의 어려움과 평균의 필요성
- SampleRTT 값은 혼잡, 라우터 큐 대기, 시스템 부하 등에 따라 변동성이 매우 큽니다.
- 따라서 TCP는 단일 SampleRTT를 그대로 사용하지 않고, 지속적으로 평균을 유지하면서 새로운 값을 반영하는 방식을 사용합니다.
3️⃣ EstimatedRTT의 정의와 업데이트 공식
- TCP는 SampleRTT의 평균값을 EstimatedRTT라는 이름으로 유지합니다.
- 업데이트 공식은 다음과 같습니다:
[
\text{EstimatedRTT} = (1 - \alpha) \cdot \text{EstimatedRTT} + \alpha \cdot \text{SampleRTT}
]
- 여기서 α는 보통 0.125 (1/8)이 추천됩니다. (문제에서는 α = 0.1 사용)
📄 {ch3.pdf} 270쪽 설명 참조
4️⃣ 지수 이동 평균 (Exponential Weighted Moving Average, EWMA)
- 위 공식은 통계적으로 지수 이동 평균 (EWMA)이라고 불립니다.
- 이전 값에 더 많은 가중치를 두되, 새로운 SampleRTT도 점진적으로 반영합니다.
- 왜 “exponential”인가?
→ 예전 SampleRTT는 시간이 지날수록 가중치가 지수적으로 줄어들기 때문입니다.
📄 {ch3.pdf} 270쪽 중간 설명 참조
5️⃣ DevRTT (편차)와 TimeoutInterval
- DevRTT는 SampleRTT가 EstimatedRTT로부터 얼마나 벗어나는지를 측정하는 변동성 지표입니다.
[
\text{DevRTT} = (1 - \beta) \cdot \text{DevRTT} + \beta \cdot |\text{SampleRTT} - \text{EstimatedRTT}|
] - β는 보통 0.25로 추천됨
- 최종적으로, 재전송 타이머(TimeoutInterval)는 다음과 같이 설정됩니다:
[
\text{TimeoutInterval} = \text{EstimatedRTT} + 4 \cdot \text{DevRTT}
]
📄 {ch3.pdf} 270~271쪽 설명 참조
6️⃣ 왜 이 방식이 유용한가?
- 최근의 RTT 변화에 빠르게 적응하면서도, 예외적인 SampleRTT로 인해 예측이 급변하지 않도록 완충 역할을 합니다.
- 따라서 TCP는 네트워크의 불안정한 RTT 상황 속에서도 안정적으로 타이머를 관리할 수 있습니다.
✅ P34를 해결하기 위한 필수 개념 정리
🔹 SendBase (송신 측 변수)
SendBase는 가장 오래된 미확인 바이트의 시퀀스 번호를 나타냅니다.- 즉, 아직 ACK를 받지 못한 데이터 중 가장 앞선 바이트 번호입니다.
SendBase - 1은 수신자가 정상적으로 수신하고 ACK로 확인한 마지막 바이트 번호가 됩니다.
📄 관련 설명: {ch3.pdf} 273~274쪽, Section 3.5.4
🔹 LastByteRcvd (수신 측 변수)
LastByteRcvd는 수신자가 네트워크로부터 받은 마지막 바이트의 번호입니다.- 즉, TCP 세그먼트가 도착하여 수신 버퍼에 저장된 마지막 바이트 번호입니다.
📄 관련 설명: {ch3.pdf} 281쪽, Section 3.5.5
✅ 두 변수 간의 관계
SendBase는 송신자가 수신자로부터 ACK를 받았는지 여부에 따라 추적되는 값입니다.- 반면
LastByteRcvd는 수신자가 물리적으로 받은 바이트 수를 추적합니다. - 이 두 변수는 간접적으로 연결됩니다:
➤ 송신자가SendBase를 갱신하는 것은, 수신자가 데이터를 받아LastByteRcvd를 증가시킨 후 ACK를 보냈기 때문입니다.
🔁 요약하자면:
LastByteRcvd가 증가하고 → 수신자가 ACK를 보냄 →- 이 ACK를 받은 송신자가 →
SendBase를 증가시킴
따라서 두 변수는 TCP 연결 양쪽에서 서로 상호작용하며 TCP의 신뢰성 보장을 위해 함께 동작하는 핵심 요소라고 볼 수 있습니다.
✅ P35를 해결하기 위한 필수 개념 정리
🔹 y (Section 3.5.4, 송신 측 ACK 필드)
y는 수신자로부터 도착한 ACK 세그먼트의 ACK 번호 값입니다.y는 수신자가 “바이트 y-1까지 수신했음을” 의미합니다.- 송신 측은
y > SendBase일 경우SendBase = y로 갱신합니다.
📄 참고: {ch3.pdf} 273~274쪽
🔹 LastByteRcvd (Section 3.5.5, 수신 측 변수)
LastByteRcvd는 수신자가 네트워크로부터 실제로 받은 가장 마지막 바이트의 번호입니다.- 즉, TCP 세그먼트가 도착하여 수신 버퍼에 저장된 가장 높은 바이트 번호입니다.
📄 참고: {ch3.pdf} 281쪽
🔁 두 변수 간의 관계
y는 수신자가 ACK로서 보낸 다음으로 기대하는 바이트 번호입니다.
즉,y = LastByteRcvd + 1가 되는 경우가 많습니다.- 이 경우 송신자는
y를 받아SendBase = y로 설정하고, 이는 수신자의LastByteRcvd를 기준으로 자신의 송신 상태를 갱신하는 것입니다.
✅ 정리된 설명
LastByteRcvd는 수신자 측에서 실제 수신된 가장 마지막 바이트의 시퀀스 번호y는 ACK 메시지에서 나타나는 수신자의 다음 기대 바이트 번호- 따라서
y = LastByteRcvd + 1이고, 이로 인해 송신자는 자신이 보낸 데이터가 수신 측에서 확인되었음을 판단합니다.
이러한 구조를 통해 TCP는 송신 측과 수신 측의 상태 정보를 정확히 동기화하며 신뢰성 있는 데이터 전송을 구현합니다.
✅ 문제 P36을 풀기 위한 개념 정리
1. Duplicate ACK의 의미
- Duplicate ACK는 송신자가 이미 ACK를 받은 세그먼트에 대해 다시 ACK가 도착하는 것.
- 수신자는 예상보다 높은 sequence number를 가진 세그먼트를 받았을 때, 중간에 누락된 세그먼트가 있다는 뜻으로 duplicate ACK를 보냄.
- 이 방식은 TCP가 NAK(Negative ACK) 없이도 세그먼트 손실을 간접적으로 탐지할 수 있게 합니다
2. 왜 1개 duplicate ACK만으로는 빠른 재전송을 하지 않는가?
- 세그먼트 손실이 아닌, 단순히 세그먼트가 재정렬(out-of-order) 되어 도착했을 가능성도 있습니다.
- 네트워크 상황에 따라 임시적인 패킷 순서 뒤바뀜이 있을 수 있으며, 이는 실제 손실과는 무관합니다.
- 이런 상황에서 단 1개의 duplicate ACK만 보고 재전송을 하면 불필요한 재전송이 발생할 수 있습니다.
3. 3개 duplicate ACK의 의미
- TCP는 3개의 duplicate ACK가 도착하면 이를 신뢰할 수 있는 손실 신호로 간주합니다.
- 왜냐하면 송신자는 일반적으로 여러 세그먼트를 백투백으로 전송하고, 수신자도 연속적으로 ACK를 보냅니다.
- 따라서 같은 ACK가 3번 중복되어 도착하면, 중간에 있는 세그먼트가 손실되었고, 그 뒤의 세그먼트들이 도착했다는 것을 유력하게 추론할 수 있습니다
4. Fast Retransmit의 조건 요약
- TCP는 세 번째 duplicate ACK가 도착하면, 그 시점에서 fast retransmit을 수행합니다.
- 이는 타이머 만료를 기다리지 않고 빠르게 손실을 복구함으로써 end-to-end delay를 줄이기 위한 전략입니다
✅ P40을 풀기 위한 필수 개념 정리 (유기적 흐름)
📦 1️⃣ Congestion Window (cwnd)
- 정의: TCP 송신자가 네트워크 혼잡을 고려해 동시에 보낼 수 있는 최대 바이트 양(또는 세그먼트 수)를 의미.
- 역할: cwnd 값은 전송 속도를 제한하는 핵심 변수이며, 시간에 따라 지속적으로 증가/감소함.
📘 관련: 혼잡 제어 알고리즘의 기반이 되는 변수
🚀 2️⃣ TCP Slow Start
- 동작 조건: 연결 시작 시 또는 timeout 발생 후, cwnd는 1로 초기화되고 지수적으로 증가함 (
cwnd *= 2). - 종료 조건: cwnd가 ssthresh(slow start threshold)를 초과하면 slow start 종료 → congestion avoidance 진입
📘 효과: 네트워크 상태를 빠르게 탐색하며 가능한 전송률까지 증가
📈 3️⃣ TCP Congestion Avoidance
- 동작 조건:
cwnd >= ssthresh가 된 시점부터, cwnd는 매 RTT마다 선형적으로 증가 (cwnd += 1) - 목적: 혼잡을 일으키지 않도록 천천히 전송 속도를 조정
📘 특징: 혼잡이 감지되지 않는 한, 네트워크에 부하를 최소화하며 신중하게 윈도우 증가
📬 4️⃣ Loss Detection via Triple Duplicate ACKs (Fast Retransmit + Fast Recovery)
- 조건: 같은 ACK를 3번 이상 받으면, 중간 세그먼트 손실로 간주
- TCP Reno 동작:
ssthresh = cwnd / 2cwnd = ssthresh- 손실된 세그먼트를 즉시 재전송 (timeout보다 빠름)
📘 장점: timeout을 기다리지 않고 빠르게 복구함 → "fast retransmit"
⏰ 5️⃣ Loss Detection via Timeout
- 조건: ACK를 일정 시간 내에 받지 못하면 타이머 만료
- 모든 TCP 버전 공통 동작:
ssthresh = cwnd / 2
- TCP Reno:
cwnd = 1(slow start로 다시 진입)
- TCP Tahoe:
- 동일하게
cwnd = 1,ssthresh = cwnd / 2→ 반드시 slow start로 재시작
- 동일하게
📘 특징: 가장 보수적인 복구 방법, 전송 속도 급감
🎚️ 6️⃣ Slow Start Threshold (ssthresh)
- 역할: slow start와 congestion avoidance를 구분하는 경계값
- 갱신 시점: 손실 발생 시마다
ssthresh = cwnd / 2로 갱신됨 - TCP의 회복 행동은 이 값에 따라 달라짐
📘 연관: ssthresh는 네트워크의 혼잡도를 판단하고 향후 증가 전략을 조정하는 기준선
🔁 7️⃣ TCP Tahoe vs Reno 차이
| 동작 조건 | TCP Reno | TCP Tahoe |
|---|---|---|
| Triple duplicate ACK | Fast retransmit + fast recovery (cwnd → ssthresh) | Fast retransmit + slow start 재진입 (cwnd → 1) |
| Timeout | cwnd → 1, ssthresh = cwnd/2 | 동일 (cwnd → 1, ssthresh = cwnd/2) |
📘 이 차이는 (j), (k)와 같은 질문에 매우 중요함
⌛ 8️⃣ Transmission Round의 의미
- Transmission round = 한 라운드 내에서 가능한 한도까지 segment를 보낸 후, 해당 ACK가 도착할 때까지 기다리는 시간
- 각 round에서 cwnd 크기만큼 segment 전송 가능
📘 그래프의 x축 단위 해석의 기준이 되는 개념
🧮 9️⃣ Segment 수 계산 방법
- 각 round에서 보낼 수 있는 세그먼트 수는 해당 round의 cwnd 값과 동일
- 누적합을 통해 몇 번째 세그먼트가 어떤 round에서 전송되었는지 추적 가능
📘 (h), (k)와 같은 문항에 필수
이처럼 P40은 단일 개념이 아니라, TCP 혼잡 제어 알고리즘 전반의 흐름과 조건 간 전이 원리를 종합적으로 파악하는 문제입니다.
그래서 각 질문은 단순 수치 이상의 개념 간 상호작용에 기반해 풀어야 해요.
Move forward