3장 트랜스포트 계층(3)

(본 글은 “컴퓨터 네트워킹 하향식 접근” 도서 및 네트워크 프로그래밍 수업 내용을 정리한 글 입니다.)

3.5 TCP의 개요

특징

1:1통신
메세지의 경계가 없다.

UDP와 다르게 1:1통신이므로 무조건 자기 자신에게 온다.

따라서 100byte , 100byte 두 차례에 걸쳐 메세지를 보내면 하나처럼 붙어서 구분하지 않으며 tcp에서 receive할 때 한번에 200byte를 받을 수도 있다.
파이프라인 방식

윈도우라는 개념이 있어 그 크기만큼 데이터를 보낸다.

윈도우의 크기는 시스템파라메터로 TCP의 혼잡제어 & 흐름제어 알고리즘에 의해 윈도우 사이즈를 유동적으로 조절
누적 ACK 사용 , 1개의 타이머 사용

(순서가 틀린 세그먼트는 구현이슈에 해당한다. 저장할 수도 있고 버릴수도 있음)
양방향 데이터 흐름
연결 지향형
- 데이터 교환 이전 HandShaking을 수행
흐름제어 (송신자가 수신자의 처리 능력을 넘어서지 않음)

3.5.1 TCP세그먼트의 구조

순서번호 : 세그먼트의 첫 바이트의 바이트스트림 (번호)
ACK(n) : n-1번째 까지 잘 받았다는 의미 (“N번 순서번호의 데이터 줘”)
수신윈도우 : 수신자가 받을 수 있는 바이트 수
기타
- R : 1이라면 리셋의 신호를 보낸다 (초기화)
- S : 싱크 (hanshaking에 사용되는 싱크정보)
  
  순서번호와 수신윈도우크기를 담아 보낸 후 S에 1을 설정한다
- F : 1이라면 종료신호를 의미
- A : 1이라면 ACK정보를 담고 있다는 의미
- C, E : 혼잡상황이 발생했음을 의미 (window크기를 조절한다)
- U : 긴급
- 긴급 데이터 포인트 : U가 1일때 긴급데이터의 범위를 알림
- R, S ,F : 연결과 관련
3.5.2 TCP의 타임아웃

적절한 타이머의 만료시간은? - 적어도 RTT보다는 길게 설정해야한다. (응답을 주고받는데 걸리는 최소시간)

너무 짧으면 - Premature Timer : 불필요한 재전송 발생

너무 길면 - 뒤늦게 확인 해 그만큼 딜레이가 발생한다
EstimatedRTT 방법
- (1-a) _ EstimatedRTT + a _ SampleRTT
  
  SampleRTT : 세그먼트를 송신해 긍정응답이 도착한 시점까지의 시간을 의미
- 지수이동평균계산 방식
- 이전 SampleRTT의 영향이 점점 감소 (최근 RTT의 비중이 높음)
- 일반적으로 가중치는 0.125값 사용 (가중치가 클 수록 최근값의 비중이 올라간다)
- 그러나 단순히 EstimatedRTT값을 타이머의 만료시간으로 지정해서는 안된다.
  
  (평균값보다 조금이라도 빠르게 타이머 시간을 잡히면 항상 Premature에 해당하므로)
- EstimatedRTT편차 * 4를 여유값으로 지정해 EstimatedRTT의 값에 더한다 -> 최종 타이머 만료시간

3.5.3 동작 과정

송신자
- 순서번호를 붙여 세그먼트를 생성
- 만약 타이머가 실행중이 아니라면 Timer실행
- 타임아웃 시 세그먼트 재전송 & 타이머 재시작
- 확인응답 수신 시 확인 응답을 받지 못한 세그먼트가 있다면 타이머 재시작
수신자
- case1) 순차적으로 데이터가 도착
  - 바로 ACK를 보내지 않고 딜레이를 시킨다 Delayed ACK
  - 최대 500ms까지 기다리다가 데이터가 오지않으면 그 때 ACK를 보낸다
- case2) 순차적으로 데이터가 잘 왔는데 이미 송신대기중인 세그먼트가 존재
  - 바로 ACK를 보낸다 두 개에 대한 하나의 누적 ACK
- case3) 순서가 틀린 세그먼트가 도착
  - 바로 ACK를 보낸다. 내가 필요한 순서번호 N에 대한 ACK(N)
- case4) 3번상황에서 오류난 부분을 받아 간격이 채워지는 경우
  - 바로 ACK를 보낸다.

빠른 재전송

일반적으로 송신자의 데이터를 받지 못하면 수신자에서는 필요 ACK(N)를 보내게 된다.

이 응답은 제대로된 데이터를 보내줄 때 까지 계속 반복되는데

사실상 송신자의 입장에서는 타이머가 만료될 때 N번째 순서번호부터 세그먼트를 다시 보낸다.

즉 손실된 패킷의 재전송까지 긴 지연시간이 발생한다.

-> 송신자가 같은 데이터에 대해 3개의 ACK를 받으면 타이머의 시간이 만료되기 전에 바로 세그먼트를 재 전송한다.

흐름제어

송신자에게 자신의 버퍼크기를 계속 알리는 전략을 적용한 방법

Q. 왜 필요한가? : 송신자와 수신자의 속도차이가 발생할 경우 버퍼에 데이터가 쌓일 수 있다.

가장 최악의 경우인 방식패킷이 가득차서 버려지는 경우를 방지하기 위함

수신자는 세그먼트에 RcvWindow크기를 알려 남은 버퍼의 공간을 알려주면 송신자에서 이를 확인

3.5.4 연결 관리

TCP에서는 데이터 세그먼트를 교환하기전 연결 설정이 필요

3-Handshake (연결)

클라이언트는 자신의 Syn(seq번호와 버퍼크기 정보)를 보내준다.
서버에서도 똑같이 자신의 Syn(seq번호와 버퍼크기 정보)를 보내주고 1번에 대한 응답 ACK를 보낸다
클라이언트는 2번에 대한 응답 ACK를 보낸다.

여기까지 준비가 되었다면 이제 클라이언트와 서버간의 데이터 교환이 이루어질 수 있다.

4-Handshake (종료)

클라이언트에서 종료 FIN을 보낸다
서버에서 1번에 대한 ACK를 보낸 후 자기도 정리를 마치고 FIN을 보낸다
클라이언트는 2번에 대한 ACK를 보낸 후 일정 시간 대기한다

자기가 보낸 ACK가 잘 도착했는 지 알 수 없기 때문이다.

만약 자신의 ACK가 잘 도착하지 않았다면 서버에서는 FIN을 다시 보낸다.
서버에서 클라이언트의 ACK를 받으면 종료한다.

정리 및 순서

클라이언트
- [SYN_SENT] -> TCP 연결 시작, SYN 전송
- [ESTABLISHED] -> 서버의 SYN,ACK수신 , ACK전송
- [FIN_WAIT_1] -> 데이터 주고 받다가 … FIN 전송
- [FIN_WAIT_2] -> ACK수신
- [TIME_WAIT] -> FIN 수신 및 ACK 송신
- [CLOSE] -> 30초간 대기
서버
- [LISTEN] -> listen socket 생성
- [SYN_RECV] -> SYN수신, 자신의 SYN,ACK 전송
- [ESTABLISHED] -> ACK 수신
- [CLOSE_WAIT] -> FIN 수신 , ACK 송신
- [LAST_ACK] -> FIN 전송
- [CLOSE] -> ACK수신

3.5.5 혼잡제어

네트워크가 처리하기에 너무 빠르고 많은 데이터를 송신자가 전송하면 혼잡 현상이 발생
패킷 손실및 긴 지연시간발생

[시나리오 1]

이상적 , 무한 버퍼크기를 가진 한 개의 라우터 -> 손실이 생기지 않고 이에 따른 재전송이 존재하지 않는다.

출력링크용량이 R이라고 할 떄 연결당 최대 처리량은R/2
값이 점점 증가하다가 어느순간부터 나가는양이 고정된다 (나머지는 다 큐에 들어간다)
Delay의 경우 점점 증가하다가 R/2지점에서 급격하게 증가한다.

트래픽의 평균치이기때문에 R/2이전 지점에서도 delay는 발생할 수 있다.

[시나리오 2]

유한한 버퍼크기를 가진 한 개의 라우터 -> 손실이 생기며 재전송 존재

(a) : 손실이 될 수 있지만 패킷손실이 일어나지 않은 경우(이상적)

(b) : R/2까지 전송은 되었으나 재전송으로 인해 실제 카운팅되는 부분이 줄어들었다.

[시나리오3]

하나의 라우터가 아니라 여러 라우터를 고려

재전송과 관련없이 다른 라우터의 혼잡도가 미치는 영향을 고려

종단 간 제어

네트워크 계층의 어떠한 지원도 없음
TCP에서 사용하는 방식

네트워크 지원 제어

네트워크 계층의 라우터에서 혼잡에 대한 정보를 송신자에게 제공하는 방법
ATM ABR 혼잡제어
- RM Cell : 라우터 입장에서는 혼잡여부를 파악할 수 있고 이 정보를 RM셀에 담아 송신측에 알린다
  - NI비트 : 혼잡이 있을 것 같을 때 증가시키지 않도록 알림(약한 혼잡)
  - CI비트 : 혼잡상황이 발생 시 알림
  - ER비트 : 송신자에서 보낼 수 있는 최대 사용 가능한 속도
- RM Cell과 Data Cell의 비율
  
  RM셀의 빈도가 늘어나면 혼잡여부 파악은 쉽지만 데이터 셀의 비율이 줄어든다.
  
  반데로 데이터 셀의 비율을 늘리면 혼잡상황을 완벽하게 파악하기 어렵다
  
  -> Data Cell에 혼잡을 나타내는 비트 EFCI비트를 넣고 혼잡여부를 알리며
  
  RM Cell이 목적지에 도착했을 때 최근 수신된 Data Cell의 EFCI비트가 1이였다면 CI비트를 1로 설정해서 혼잡을 알린다.

3.5.6 TCP의 혼잡제어

송신자는 혼잡상황에 따라 전송률을 제한시킨다.

송신률 = ConWin / RTT

AIMD
- 가법증가 : 손실 감지 까지 CongWin의 값을 1 MSS만큼 올림
- 승법감소 : 손실이 발생하면 CongWin의 값을 1/2감소
  
  CongWin : 전송률 && 윈도우 크기 (한 번에 CongWin크기 만큼 보낼 수 있다)
  
  MSS : TCP세그먼트의 최대 바이트 수 (전송하고자 하는 데이터가 저장될 수 있는 최대 길이)
Slow Start
- 처음에는 1MMS로 시작해서 최초 손실까지 ConWin의 크기를 2배로 늘린다
손실 상황에 대한 반응
- 타임아웃이 발생하면 1MMS로 줄임
- 3개의 중복 ACK를 수신하면 CongWin의 크기를 1/2로 줄임
(타임아웃의 발생은 혼잡상황에서 더 심각한 상황이라고 인식)
- 타임아웃이 발생한 지점의 1/2를 ThresHold지점으로 정의한다
- ThresHold지점까지는 CongWin의 크기를 2배씩 증가하다가 해당 지점을 넘어서면 1씩 증가시킨다.

TCP의 처리율

손실이 발생했을 때 CongWin의 크기가 W였다면 처리율은 W/RTT

손실 직후 CongWin의 크기는 1/2로 감소하고 처리율은 W/2RTT

결과적으로 평균 처리율은 3/4 W/RTT

(AIMD만 가정했을 때)

TCP의 공평성

TCP의 혼잡제어에 의해 특정 연결 세션의 트래픽이 높더라도 승법 감소에 의해 1/2씩 줄고 가법 증가에 의해 처리율은 1씩 증가한다면 결국 가운데로 수렴해서 시간이 지나면 각 연결마다 트래픽이 골고루 분산되는 효과가 있음
공평성과 UDP
- TCP관점에서 UDP는 공평하지 못하다 혼잡제어를 하지 않기 때문인데 동시에 사용했을 때 UDP가 TCP의 트래픽을 밀어버릴 가능성이 있다.
공평성과 병렬 TCP
- 하나의 어플리케이션에서 여러 스레드를 만들고 다중 병렬 TCP을 사용한다면 하나의 어플리케이션에서 트래픽을 불공평하게 가져간다.

ECN

ECN (=명시적 혼잡표시) : 최근에는 네트워크 계층에서 TCP의 혼잡제어에 도움을 주는 형식이 등장

혼잡 발생 시 네트워크 계층의 IP헤더에 위치한 Tos필드의 2비트에 1 1을 할당
목적지 호스트에서 비트값을 확인
목적지 호스트는 TCP헤더의 ECN비트(E)에다가 1을 할당
송신 호스트는 데이터를 받아 CWR비트(C)에 1을 할당하고 CongWin을 1/2로 감소

teawon