3. 전송 계층 4

3.5 연결지향형 트랜스포트 TCP

 

TCP 연결

• connection-oriented: 애플리케이션 프로세스가 데이터를 다룬 다른 프로세스에게 보내기 전에, 두 프로세스가 서로 <핸드셰이크>를 먼저 해야 함.
• full-duplex: 호스트 A의 프로세스와 호스트 B의 프로세스 사이에 TCP 연결이 있다면, 애플리케이션 계층 데이터는 B에서 A로 흐르는 동시에 A에서 B로 흐를 수 있음.
• point-to-point: 단일 송신자와 단일 수신자 사이에 데이터가 전송됨.
• reliable-in-order: 데이터라 전송된 순서대로 신뢰 가능하게 데이터를 보냄.
• piplined: 한꺼번에 여러 데이터를 전송함.
• send & receiver buffer: 모든 호스트가 send buffer와 receiver buffer를 갖고 있음.
• flow control: receiver가 받을 수 있을 만큼만 sender가 데이터를 전송함
• TCP 프로토콜은 오직 종단 시스템에서만 동작하고 중간의 네트워크 요소(라우터, 브리지)에서는 동작하지 않음.

 

 

TCP 세그먼트 구조

• 출발지 포트 넘버 필드(16bit), 목적지 포트 넘버 필드(16bit): 상위 계층 애플리케이션으로부터 다중화, 역다중화를 하는데 사용.
• 체크섬 필드: error detection에 사용.
• 순서번호 필드(32bit): 신뢰적인 데이터 전송 서비스 구현에서 TCP 송신자와 수신자에 의해 사용.
• 확인응답번호 필드(32bit): 신뢰적인 데이터 전송 서비스 구현에서 TCP 송신자와 수신자에 의해 사용.
• 헤더 길이(4bit): TCP 헤더 길이 표시
• 옵션(가변적): 송신자와 수신자가 최대 세그먼트 크기를 협상하거나 고속 네트워크에서 사용하기 위한 윈도우 확장 요소로 사용.
• 플래그(6bit)

 

 

텔넷(Telnet): 순서번호와 확인번호 사례 연구

• 순서번호: 데이터 필드 안에 있는 첫번째 바이트의 순서번호.
• 확인번호: 호스트가 기다리는 다음 바이트의 순서번호.

• 첫번째 세그먼트
  • 호스트A -> 호스트B
  • 데이터 필드 안의 문자 'C'의 바이트 ASCII 표현 포함
  • 순서번호 필드: 42
  • 확인번호 필드: 79
• 두번째 세그먼트
  • 호스트B -> 호스트A
    • 목적 1: 호스트A에게 확인응답 전달
      • 확인응답 필드: 43 (42까지 잘 받았어!)
    • 목적 2: 호스트A에게 문자 'C' 전달
      • 순서번호 필드: 79
• 세번째 세그먼트
  • 호스트A -> 호스트 B
    • 목적: 호스트B로부터 수신한 데이터 확인응답
      • 확인응답 필드: 80 (79까지 잘 받았어!)
      • 순서번호 필드: 43

 

왕복시간(RTT) 예측과 타임아웃

 

왕복시간 예측

 

 

 

• SampleRTT
  • 세그먼트가 송신된 시간(IP에게 넘겨진 시간)으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간까지의 시간 길이.
  • 라우터에서의 혼잡과 종단 시스템에서의 부하 변화 때문에 세그먼트마다 다름.
• EstimatedRTT
  • SampleRTT의 평균값.
  • 새로운 SampleRTT를 획득하면 EstimatedRTT 갱신.
    • EstimatedRTT = (1-α) * EstimatedRTT + α*SampleRTT (권장되는 α값은 0.125)
    • EstimatedRTT = 0.875 * EstimatedRTT + 0.125*SampleRTT
• DevRTT
  • RTT의 변화율 (SampleRTT가 EstimatedRTT로부터 얼마나 벗어나는지)
  • DevRTT = (1-β)*DevRTT * β * |SampleRTT - EstimatedRTT|

 

재전송 타임아웃 주기의 설정  및 관리

• 타임아웃 값은 EstimatedRTT값에 약간의 여유 값을 더한 값으로 설정하는 것이 바람직함.
• TimeoutInterval = EstimatedRTT + 4 * DevRTT

 

 

신뢰적인 데이터 전달

• TCP 송신자의 데이터 전송/재전송에 관련된 세가지 주요 이벤트
  1. 상위 애플리케이션으로부터 수신된 데이터
     • TCP는 애플리케이션으로부터 데이터를 받으면
     • 세그먼트로 이 데이터를 캡슐화하고
     • IP에게 이 데이터를 넘김.
  2. 타임아웃
     • 타임아웃을 일으킨 세그먼트에 대해 재전송하여 응답하고
     • TCP 타이머를 다시 시작.
  3. 수신자로부터 ACK 수신
     • SendBase(수신 확인응답 되지 않은 가장 오래된 바이트의 순서 번호)와 ACK값을 비교하고
     • y > SendBase이면 이전에 확인응답 안된 하나 이상의 세그먼트를 확인.(누적 ACK이므로)

 

몇 가지 흥미로운 시나리오

 

 

• 시나리오 1
  • 호스트 A가 순서번호 92와 8바이트의 데이터 전송.
  • 호스트 A는 순서번호 100 기다림.
  • 호스트 B는 순서번호 92와 8바이트의 데이터 세그먼트 전송받음.
  • 호스트 B는 ACK 100 전송.
  • ACK 100 중간에 유실.
  • 호스트 A 타임아웃.
  • 호스트 A 순서번호 92와 8바이트의 데이터 재전송

• 시나리오 2
  • 호스트 A가 순서번호 92와 8바이트의 데이터 전송. (첫번째 세그먼트)
  • 호스트 A가 순서번호 100와 20바이트의 데이터 전송. (두번째 세그먼트)
  • 호스트 B는 순서번호 92와 8바이트의 데이터 세그먼트 전송받음.
  • 호스트 B는 ACK 100 전송.
  • 호스트 B는 순서번호 100와 20바이트의 데이터 세그먼트 전송받음.
  • 호스트 B는 ACK 120 전송.
  • 호스트 A 첫번째 세그먼트에 대한 타임아웃 발생.
  • 호스트 A가 순서번호 92와 8바이트의 데이터 재전송. (첫번째 세그먼트)
  • 호스트 A는 ACK 120 전송 받음 -> 호스트 A가 순서번호 100와 20바이트의 데이터는 재전송하지 않음.

• 시나리오 3
  • 호스트 A가 순서번호 92와 8바이트의 데이터 전송. (첫번째 세그먼트)
  • 호스트 B는 순서번호 92와 8바이트의 데이터 세그먼트 전송받음.
  • 호스트 B는 ACK 100 전송.
  • ACK 100 유실.
  • 호스트 A가 순서번호 100와 20바이트의 데이터 전송. (두번째 세그먼트)
  • 호스트 B는 순서번호 100와 20바이트의 데이터 세그먼트 전송받음.
  • 호스트 B는 ACK 120 전송.
  • 호스트 A는 ACK 120 전송 받음 -> 호스트 A가 순서번호 92와 8바이트의 데이터는 재전송하지 않음.

 

빠른 재전송

• 타임아웃이 유발하는 재전송의 문제: 타임아웃의 주지가 때때로 비교적 길다는 점,
• 빠른 재전송fast retransmit
  • TCP 송신자가 같은 데이터에 대해 3개의 중복 확인응답을 수신한다면
  • ACK된 세그먼트의 다음 3개의 세그먼트가 분실되었음을 의미
  • 이 경우 TCP는 세그먼트의 타이머가 만료되기 전에 손실 세그먼트를 재전송함.

 

ACK 지연

• ACK 지연delayed ACK
  • 또 다른 순서가 맞는 세그먼트의 도착을 위해 500msec까지 기다렸다가 한번에 누적 ACK를 보냄.