전송계층2 - TCP, segment구조, RTT, 타임아웃

TCP 개요

 

Point-to-point (점대점 통신):

• 하나의 샌더엔 하나의 리시버

Reliable, in-order byte stream (신뢰할 수 있고 순서가 보장된 바이트 스트림):

• TCP는 바이트 단위로 데이터를 전송하며, "메시지 경계"가 없이 신뢰성 있게 데이터가 순서대로 도착합니다.

Pipelined (파이프라인 전송):

• TCP는 혼잡 제어나 흐름 제어를 통해 윈도우 크기를 설정하고, 여러 패킷을 동시에 전송할 수 있습니다.

Send & receive buffers (송신 및 수신 버퍼):

• 송신 버퍼는 데이터를 보내기 전에 저장하고, 수신 버퍼는 받은 데이터를 처리할 때까지 저장합니다. (selective repeat)
• 파이프라인의 윈도우도 버퍼. 손실되면 버퍼에 있는걸로 재전송
• 양방향 통신 : 모두가 샌더이자 리시버이기 때문에, 소켓 하나에 샌드 버퍼와 리시브 버퍼 2개가 다 있음

Full duplex data (양방향 데이터 통신):

• 같은 연결에서 양방향으로 데이터가 흐릅니다. 송신과 수신이 동시에 가능합니다.
• MSS(최대 세그먼트 크기): 전송할 수 있는 최대 데이터 크기를 설정합니다.

Connection-oriented (연결 지향형):

• 데이터를 전송하기 전에 송신자와 수신자 간의 상태를 초기화하는 과정이 필요합니다. 이 과정을 핸드셰이킹이라고 합니다.

Flow controlled (흐름 제어):

• 송신자는 수신자가 처리할 수 있는 만큼만 데이터를 전송합니다. 수신자가 과부하에 걸리지 않도록 조정합니다.

TCP segment 구조

포트 범위 : 0~ 65535 (2^16개)

 

 

• source port #: 데이터를 보내는 쪽의 포트 번호입니다.
• dest port #: 데이터를 받는 쪽의 포트 번호입니다.
• sequence number: 송신자가 보낸 데이터의 첫 번째 바이트에 해당하는 번호입니다. TCP는 바이트 단위로 데이터를 전송합니다.
• acknowledgement number: 송신자가 수신한 데이터의 다음으로 받을 바이트의 번호입니다.
• header length: TCP 헤더의 길이를 나타냅니다.
• URG: 이 플래그가 설정되면 긴급 데이터를 나타냅니다.
• ACK: 이 플래그가 설정되면 acknowledgement number가 유효함을 나타냅니다.
• PSH: 이 플래그가 설정되면 데이터를 즉시 상위 계층으로 전달하도록 지시합니다.
• RST, SYN, FIN: 연결 설정, 해제 및 재설정을 위한 제어 플래그입니다.
  • RST: 연결 재설정
  • SYN: 연결 설정
  • FIN: 연결 해제
• receive window: 수신자가 현재 수용할 수 있는 바이트 수를 나타냅니다. 이는 흐름 제어(flow control)에 사용됩니다.
• checksum: 데이터 오류를 검사하기 위한 필드입니다.
• urgent pointer: URG 플래그가 설정되었을 때 긴급 데이터의 끝을 가리킵니다.
• options: 선택적 필드로, 가변적인 길이를 가질 수 있습니다.
• application data: 실제로 전송되는 데이터입니다.

Seq번호와 Ack번호

 

 

• 시퀀스 번호(Seq. #):
  • 각 세그먼트의 첫 번째 바이트에 할당된 번호입니다.
• ACK 번호:
  • 다음에 수신자가 기대하는 바이트의 번호를 나타냅니다.
• 누적 ACK(Cumulative ACK):
  • TCP에서는 누적 ACK 방식을 사용하여 모든 데이터가 정상적으로 수신되었음을 나타냅니다. ACK 번호는 수신한 가장 높은 연속된 바이트의 다음 번호를 나타냅니다.
• 순서가 맞지 않는 세그먼트(Out-of-order segments):
  • 만약 세그먼트가 순서대로 도착하지 않는 경우, TCP 명세에서는 어떻게 처리할지 구체적으로 명시되어 있지 않습니다.
  • 이 부분은 구현자에게 달려 있으며, 일반적으로는 수신한 데이터를 임시로 버퍼링하거나 무시하는 방식으로 처리됩니다.

타임아웃 (RTT 함수)

패킷 손실 여부를 타임아웃으로 판단한다.

 

 

• TCP 타임아웃 설정 방법:
  
  • 타임아웃이 너무 짧으면 불필요한 재전송이 발생할 수 있습니다.
  • 반대로 너무 길면 패킷 손실에 대한 반응이 느려질 수 있습니다.
    • 타임아웃은 RTT보다 길어야 합니다. 그러나 RTT는 상황에 따라 변화합니다.
• RTT 추정 방법:
  •  RTT (Round Trip Time) : 패킷 왕복시간
  • SampleRTT는 세그먼트를 전송한 후 ACK를 받기까지 걸리는 시간을 측정합니다.

(P) SampleRTT는 매번 다르다 (편차가 크다)

ㅡ> 세그먼트마다 경로도 다르고, 라우터 큐잉딜레이도 그때그때 달라서

(S) EstimatedRTT

ㅡ> 추정된 RTT를 더 부드럽게 만들기 위해 최근 측정값들을 평균화

ㅡ> 이는 현재의 SampleRTT만 보는 것이 아니라 여러 측정값을 종합적으로 반영하는 방식

 

 

EstimatedRTT = (1 - α) * EstimatedRTT + α * SampleRTT

 

위 그래프를 보면

(P) EstimatedRTT가 너무 타이트해서 타임아웃이 너무 많이 발생

(S) TimeoutInterval

ㅡ> EstimatedRTT에 마진( DevRTT )을 더한다

• DevRTT 계산: 이 값은 SampleRTT와 EstimatedRTT 간의 차이(편차)를 반영하여 RTT의 변화량을 추정하는 값입니다.
  • DevRTT는 지수 가중 이동 평균 방식을 사용하여 계산됩니다. 최근의 변화가 더 많이 반영되고 과거 값의 영향은 점점 줄어드는 방식입니다.
  • 여기서 베타 값(β)은 보통 0.25로 설정됩니다.

• TimeoutInterval 설정:
  • EstimatedRTT에 DevRTT의 4배를 더해서 타임아웃 값을 설정합니다.
  • EstimatedRTT는 RTT의 예상값이고, DevRTT는 그 예상값에서 실제 측정값이 얼마나 벗어나는지를 나타냅니다. 타임아웃을 설정할 때 이러한 편차를 반영한 '안전 마진'을 추가하여 너무 짧거나 너무 긴 타임아웃이 발생하지 않도록 합니다

TCP reliable data transfer

 

• TCP는 IP의 '신뢰할 수 없는 서비스' 위에 ' 신뢰성 있는 데이터 전송(rdt) 서비스'를,  구현:
• 파이프라인된 세그먼트 (Pipelined segments):
  • TCP는 한 번에 여러 세그먼트를 보내고 ACK(확인 응답)를 받습니다. 이를 통해 전송의 효율성을 높입니다.
• 누적 ACK (Cumulative ACKs):
  • TCP는 누적된 확인 응답을 사용합니다.
  • 예를 들어, 특정 시퀀스 번호까지 모든 데이터를 제대로 받았음을 알리는 ACK를 보냅니다.
• 단일 재전송 타이머 사용:
  • 송신측에서 타이머 1개로 재전송 관리
    • 타이머가 1개인건, go-back-n과 비슷
    • 그러나 tcp는 go-back-n처럼 되돌아가지 않고, 타임아웃 된 것만 재전송
• 재전송은 두 가지 이벤트에 의해 발생:
  • Timeout events: ACK가 제 시간에 도착하지 않으면 TCP는 타임아웃이 발생하고 데이터를 다시 전송합니다.
  • Duplicate ACKs: 동일한 ACK를 반복적으로 받으면, 그 사이의 데이터가 손실되었을 가능성을 인식하고 데이터를 재전송합니다.
• 단순화된 TCP 송신기 고려:
  • 초기에는 중복 ACK, 흐름 제어, 혼잡 제어 등을 무시하는 단순한 TCP 송신기를 가정하여 동작을 설명할 수 있습니다.

TCP sender event

 

 

• 응용 프로그램에서 데이터가 수신되었을 때 (data rcvd from app):
  • 세그먼트 생성: 송신기는 세그먼트를 생성하고, 세그먼트의 시퀀스 번호(seq #)를 할당합니다. 이 시퀀스 번호는 세그먼트 내의 첫 번째 데이터 바이트에 해당합니다.
  • 타이머 시작: 만약 아직 타이머가 작동 중이지 않다면, 가장 오래된 "인증받지 못한(unacked)" 세그먼트를 기준으로 타이머를 시작합니다. 타이머는 TimeOutInterval 동안 작동합니다.
• 타임아웃이 발생했을 때 (timeout):
  • 세그먼트 재전송: 타임아웃이 발생한 세그먼트를 재전송합니다.
  • 타이머 재시작: 재전송 후 타이머를 다시 시작합니다.
• ACK를 수신했을 때 (Ack rcvd):
  • 미인증 세그먼트 확인: 수신된 ACK가 이전에 인증받지 못한 세그먼트를 인증할 경우, 어떤 세그먼트가 인증되었는지 갱신합니다.
  • 타이머 관리: 만약 아직 인증받지 못한 세그먼트가 남아 있다면, 타이머를 다시 시작합니다.

TCP : retransmission scenarios

Ack 손실

 

1. Host B는, sea99까지 받아서 ack100을 보낸다.
2. Host A는 타임아웃이 발생한 seq92를 보낸다.
3. 그러나 B는 seq92는 이미 받았기 때문에, 버리고(버퍼x) ack100을 보낸다.
4. A는 ack93을 못받았지만, ack100을 받았기 때문에, 그전꺼는 잘 받았다 판단하고(버퍼비움) seq100부터 보낸다.

조기 타임아웃

Cumulative Ack 

최신 ack가 들어오면

그전 ack는 안들어와도 무시할 수 있는게

cumulative ack의 장점

fast retransmit

같은 ack가 여러번 오면

타임아웃이 발생하기전부터 손실을 판단

Fast Retransmit 동작 과정:

1. 중복 ACK 수신:

TCP는 수신자가 같은 ACK을 여러 번 받으면, 이는 중간의 세그먼트가 손실되었음을 암시합니다.

예를 들어, 송신자가 세그먼트 1, 2, 3을 보냈는데 세그먼트 2가 손실되었다면, 수신자는 세그먼트 3을 받았을 때도 세그먼트 2를 기다리고 있다고 알려주는 중복 ACK를 보냅니다.

즉, 송신자는 세 번째 중복 ACK을 받게 됩니다.

 

2. 세 번째 중복 ACK:

일반적으로 TCP는 동일한 ACK가 3번 중복으로 수신되면, 타임아웃이 발생하기 전에 손실된 것으로 추정되는 세그먼트를 재전송합니다.

 

3. 손실된 세그먼트 재전송:

중복 ACK가 3번 수신되면, TCP는 타임아웃 없이 바로 손실된 세그먼트를 재전송합니다.

이 과정 덕분에 네트워크 성능이 향상되고 불필요한 지연이 줄어듭니다.

 

※ 중복ACK가 3개라는건, 같은 Ack를 4번 받았다는 것

※ 타이머는 꼭 필요한거고, fast retransmit은 꼭 필요하진 않는데 되는데 효율을 위해 존재