학교
[컴퓨터 네트워크] Chapter 3. Transport Layer (Part2) - (3)
일자 : 24-2 8주차 1차시
5. 연결 지향 전송: TCP
[1] TCP 개요 (RFCs: 793, 1122, 2018, 5681, 7323)
포인트-투-포인트 통신:
한 송신자와 한 수신자 간의 통신
신뢰성 있는 순차적 바이트 스트림:
“메시지 경계” 없이 데이터가 전송됨
전이중 데이터:
동일한 연결에서 양방향 데이터 흐름 지원
MSS(최대 세그먼트 크기): 전송 가능한 최대 데이터 크기
cumulative(누적) ACK:
이전에 수신된 데이터를 확인하는 ACK 사용
파이프라이닝:
TCP 혼잡 제어와 흐름 제어가 윈도우 크기 설정
connection-oriented(연결 지향):
데이터 전송 전에 송신자와 수신자 상태를 초기화하기 위한 핸드셰이킹(제어 메시지 교환) 수행
흐름 제어:
송신자가 수신자를 과부하시키지 않도록 제어
[2] TCP segment structure
[32비트] 시퀀스 번호: 바이트 스트림에서 데이터를 바이트 단위로 카운트 (세그먼트 단위 아님)
[32비트] ACK 번호: 다음에 예상되는 바이트의 시퀀스 번호
헤더 길이: TCP 헤더의 길이
C, E: 혼잡 알림
A 비트: ACK임을 표시
RST, SYN, FIN: 연결 관리 플래그
[16비트] 수신 윈도우: 흐름 제어 - 수신자가 수락할 수 있는 바이트 수
[16비트] 체크섬: 인터넷 체크섬 (데이터 무결성 확인)
[32비트] 옵션: TCP 옵션 (확장 기능에 사용)
애플리케이션 데이터 (가변 길이): 애플리케이션이 TCP 소켓에 전송한 데이터
[3-1] TCP sequence numbers, ACKs
시퀀스 번호:
세그먼트 데이터의 첫 번째 바이트에 할당된 바이트 스트림 "번호"
예를 들어, 송신자가 시퀀스 번호 1000으로 데이터를 전송하면, 이 값은 해당 세그먼트의 첫 번째 바이트가 스트림에서 차지하는 위치를 나타낸다.
ACK (응답 번호):
상대방으로부터 다음에 예상되는 바이트의 시퀀스 번호
누적 ACK 사용
예를 들어, 수신자가 시퀀스 번호 1500을 ACK로 송신하면, 이는 시퀀스 번호 1499까지의 데이터가 제대로 수신되었음을 의미하며, 송신자는 시퀀스 번호 1500부터의 데이터를 전송해야 함을 알게 된다.
Q. 수신자가 순서가 뒤바뀐 세그먼트를 어떻게 처리하는가?
A. TCP 사양에는 명확한 지침이 없으며, 구현자의 재량에 맡겨져 있음.
일반적으로 수신자는 순서가 맞지 않는 세그먼트를 버리거나 버퍼에 저장해 두었다가 나중에 올바른 순서로 재정렬할 수 있다.
[3-2] TCP 시퀀스 번호와 ACK
1) 간단한 텔넷 시나리오
(1) 과정
호스트 A: 사용자가 'C'를 입력함
→ Seq = 42, ACK = 79, 데이터 = 'C'호스트 B: 'C' 수신을 ACK하고, 'C'를 다시 보냄
→ Seq = 79, ACK = 43(42+1), 데이터 = 'C'호스트 A: 에코된 'C'를 수신한 후 ACK를 보냄
→ Seq = 43, ACK = 80(79+1)즉, 호스트 B가 호스트 A가 보낸 'C'를 그대로 받아서 다시 송신하는 것을 "에코(Echo)"라고 한다.
(2) 간단한 설명:
: 이 시나리오는 TCP 통신에서의 시퀀스 번호(Seq)와 확인 응답(ACK)의 흐름을 보여준다.
Seq는 전송되는 데이터의 순서를 나타내고,
ACK는 상대방이 보낸 데이터를 정상적으로 받았음을 알려주는 응답이다.
'C'라는 데이터를 주고받으면서 각 호스트는 그 데이터를 보낸 순서와 받았음을 ACK로 표시한다.
알겠다. 비유를 각 항목 아래에 넣어 설명하겠다.
[4-1] TCP 왕복 시간 (RTT)과 타임아웃
Q: TCP 타임아웃 값을 어떻게 설정하나?
타임아웃은 RTT보다 길어야 한다. 하지만 RTT는 변동이 크기 때문에 정확히 맞추기 어렵다.
비유: 타임아웃은 버스를 기다리는 시간과 비슷하다. 너무 짧게 기다리면 버스가 오기도 전에 떠나버리고, 너무 길게 기다리면 버스가 안 오더라도 계속 기다려야 한다.
너무 짧으면: 타임아웃이 일찍 발생해서 불필요한 재전송이 일어난다.
비유: 마치 너무 일찍 기다려서 버스가 떠난 줄 알고 집으로 돌아가는 것과 같다. 실제로는 버스가 금방 올 수 있었는데, 너무 일찍 떠나 버린 것이다.
너무 길면: 세그먼트 손실에 대한 반응이 느려지기 때문에 효율적이지 않다.
비유: 중요한 일이 생겨도 너무 늦게 반응하는 사람처럼, 손실된 데이터를 처리하는 속도가 느려진다.
Q: RTT는 어떻게 추정하나?
SampleRTT는 세그먼트를 전송하고 ACK를 받을 때까지의 시간을 측정한 것이다.
재전송은 무시하고, 실제 전송된 세그먼트의 왕복 시간만 측정한다.
비유: 우편물을 보낸 후, 상대방이 확인 도장을 찍어 다시 보내오는 데 걸린 시간을 재는 것과 같다. 단, 우편물이 다시 오지 않으면 그 시간은 제외된다.
SampleRTT는 변동이 있기 때문에, 하나의 값만 사용하면 불안정하다. 그래서 여러 번의 측정을 평균내어 estimated(예상) RTT를 더 부드럽게 만든다.
비유: 여러 번 우편물을 보내고 그 시간을 평균내어 더 정확한 왕복 시간을 측정하는 것과 같다. 한 번의 시간만 측정하면 변수가 많아 정확하지 않다.
[4-2] TCP 왕복 시간 (RTT)과 타임아웃
$EstimatedRTT = (1- \alpha) * EstimatedRTT + \alpha * SampleRTT$
지수 가중 이동 평균 (EWMA)
과거 샘플의 영향이 지수적으로 빠르게 감소한다.
과거의 RTT 값에 점차적으로 더 작은 가중치를 두고, 최근의 값에 더 많은 가중치를 둔다.
즉, 새로운 값일수록 더 중요하게 반영된다.
일반적인 값: $\alpha$ = 0.
[4-3] TCP 왕복 시간 (RTT)과 타임아웃
타임아웃 간격: EstimatedRTT에 "안전 마진"을 더한 값
EstimatedRTT에 큰 변동이 있을 경우 더 큰 안전 마진이 필요하다.
TimeoutInterval = EstimatedRTT + 4 * DevRTT
DevRTT: SampleRTT가 EstimatedRTT에서 얼마나 벗어나는지를 나타내는 지수 가중 이동 평균 (EWMA)
SampleRTT와 EstimatedRTT의 차이를 기반으로, 그 차이를 평균내는 방법이다.
이 값을 통해 RTT의 변동성을 측정할 수 있다.
DevRTT = (1-$\beta$) $\times$ DevRTT + $\beta$ $\times$ |SampleRTT-EstimatedRTT|
(일반적으로 $\beta$ = 0.25)
[5] TCP 수신기: ACK 생성
수신기에서의 이벤트 | TCP 수신기 동작 |
|---|---|
예상되는 순서 번호의 정렬된 세그먼트 도착. 이미 예상 순서 번호까지의 모든 데이터는 ACK됨 | 지연 ACK. 최대 500ms까지 다음 세그먼트를 기다린다. 만약 다음 세그먼트가 없으면 ACK 전송 |
예상되는 순서 번호의 정렬된 세그먼트 도착. 다른 세그먼트 하나가 ACK 대기 중 | 즉시 누적 ACK 전송, 두 개의 정렬된 세그먼트를 모두 ACK |
예상 순서 번호보다 큰 순서 번호를 가진 정렬되지 않은 세그먼트 도착. 간격 감지됨 | 즉시 중복 ACK 전송, 다음 예상 바이트의 순서 번호를 나타냄 |
간격을 부분적으로 또는 완전히 채우는 세그먼트 도착 | 즉시 ACK 전송, 세그먼트가 간격의 하위 부분에서 시작하는 경우에만 |
간단 요약:
지연 ACK: 예상 순서 번호의 세그먼트가 도착했을 때, 다음 세그먼트가 오기를 최대 500ms 기다린 후 ACK를 전송한다.
누적 ACK: 여러 개의 세그먼트가 도착할 때, 하나의 ACK로 모든 정렬된 세그먼트를 ACK한다.
중복 ACK: 예상 순서 번호보다 큰 번호를 가진 세그먼트가 도착하면, 그 순서 번호를 기준으로 중복 ACK를 전송한다.
ACK 전송: 간격을 메우는 세그먼트가 도착하면 즉시 ACK를 전송한다.
[6] TCP 재전송 시나리오
1) ACK 손실 시나리오
(1) 설명
Host B가 Host A에 대한 ACK를 보냈지만, ACK가 손실된 상황이다. 이때 Host A는 ACK를 받지 못해 동일한 데이터(Seq = 92)를 다시 전송한다. Host B는 이 데이터를 중복 수신하게 되지만, 이미 ACK를 보냈으므로 동일한 ACK(ACK = 100)을 다시 Host A로 전송한다.
(2) 과정 정리
Host A -> Host B:Seq = 92, 8 bytes of data 전송Host B -> Host A:ACK = 100(손실 발생)Host A -> Host B:Seq = 92, 8 bytes of data (재전송)Host B -> Host A:ACK = 100(ACK 재전송)
(3) 확인
TCP는 중복된 데이터를 수신했을 때 기존 ACK를 다시 보냄으로써 ACK 손실 문제를 해결한다.
2) 사전 Timeout
설명:
여기서는 Host A가 두 개의 패킷을 전송했으나, 첫 번째 패킷의 ACK를 받기 전에 타임아웃이 발생했다. 따라서 Host A는 첫 번째 패킷(Seq = 92)을 재전송한다. Host B가 첫 번째 패킷을 다시 수신하면서 ACK를 보내며, 이어서 누적된 ACK를 통해 다음 데이터까지 확인하게 된다.
(2) 과정 정리
Host A -> Host B:Seq = 92, 8 bytes of data 전송 (전송1)Host A -> Host B:Seq = 100, 20 bytes of data 전송 (전송2)Timeout 발생: ACK가 오지 않아
Seq = 92재전송 (전송3)Host B -> Host A:ACK = 100(전송1 ACK, SendBase = 100)Host B -> Host A:ACK = 120(전송2 ACK, SendBase = 120)Host B -> Host A:ACK = 120(전송3 ACK, 누적 ACK for 120)
(3) 확인
누적된 ACK를 통해 타임아웃으로 인한 재전송이 효율적으로 처리된다.
3) 이전에 손실된 ACK에 대한 누적 ACK 커버리지
(1) 설명
Host A가 여러 패킷을 전송했으나, 중간에 Host B의 ACK = 100이 손실된 상황이다. 이때 Host B는 추가로 데이터(Seq = 120까지)를 수신하면서 누적 ACK(ACK = 120)을 보내 ACK 손실을 커버한다.
(2) 과정 정리
Host A -> Host B:Seq = 92, 8 bytes of data 전송 (전송1)Host A -> Host B:Seq = 100, 20 bytes of data 전송 (전송2)Host B -> Host A:ACK = 100(손실 발생)Host B -> Host A:ACK = 120(누적된 ACK 전송)Host A -> Host B:Seq = 120, 15 bytes of data 전송
(3) 확인
누적 ACK 메커니즘을 통해 ACK 손실이 발생해도 이후 누적된 ACK를 통해 데이터 수신을 보장한다.
[7] TCP fast retransmit
1) TCP fast retransmit란?
: 송신자가 같은 데이터에 대해 3개의 추가 ACK(즉, 동일한 ACK가 3번 반복) 수신 시, ACK되지 않은 가장 작은 시퀀스 번호의 세그먼트를 재전송한다.
이는 해당 세그먼트가 손실된 것으로 판단하여 타임아웃을 기다리지 않고 바로 재전송을 수행하는 방식이다.
2) 세그먼트 손실 가능성
: 3개의 중복 ACK가 수신(Receipt)된 경우, 손실된 세그먼트 이후의 3개의 세그먼트가 수신되었음을 의미한다(indicates). 이는 세그먼트 손실 가능성이 높음을 나타내므로, 즉시 재전송을 진행한다.
3) Fast Retransmit이 동작하는 원리
송신자가 동일한 ACK를 3번 연속으로 수신하면, 해당 ACK는 손실된 세그먼트 이후의 데이터를 수신했음을 의미한다.
송신자는 타임아웃 없이 중복 ACK를 바탕으로 손실된 세그먼트를 즉시 재전송한다.
5. 연결 지향 전송: TCP
[1] TCP 흐름 제어
Q: 네트워크 응용 프로그램 계층이 소켓 버퍼에서 데이터를 제거하는 속도보다 더 빠르게 데이터를 전달하면 어떻게 되는가?
1) 흐름 제어의 위치
2) 흐름 제어란?
: 수신자가 송신자를 제어하여 송신자가 너무 많은 데이터를 너무 빠르게 전송하지 않도록 하는 것이다.
흐름 제어: 수신자가 수용할 수 있는 바이트 수
3) 특징
TCP 수신자는 TCP 헤더의
rwnd필드에서 사용 가능한 버퍼 공간을 “알린다(advertises).”RcvBuffer크기는 소켓 옵션을 통해 설정된다 (일반적으로 기본값은 4096 바이트이다).많은 운영체제에서
RcvBuffer크기를 자동으로 조정한다.
송신자는 수신된
rwnd에 따라 확인되지 않은 ("전송 중(in-flight)") 데이터의 양을 제한한다.수신 버퍼가 오버플로우 되지 않도록 보장한다(guarantees).
