하루에 한 문제

TCP ( 흐름 제어, 오류 제어) 본문

CS/네트워크

TCP ( 흐름 제어, 오류 제어)

dkwjdi 2021. 3. 31. 02:27

TCP

  • 일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 패킷을 추적 및 관리한다.
  • 신뢰성 있는 데이터 전송을 지원하는 연결 지향형 프로토콜이다.
  • 사전에 3-way handshake라는 과정을 통해 연결을 설정하고 통신을 시작한다.
  • 4-way handshake 과정을 통해 연결을 해제(가상 회선 방식)한다.
  • 흐름 제어, 혼잡 제어, 오류 제어를 통해 신뢰성을 보장한다. 그러나 이 때문에 UDP보다 전송 속도가 느리다는 단점이 있다.
  • 데이터의 전송 순서를 보장하며 수신 여부를 확인할 수 있다.
  • TCP를 사용하는 예로는 대부분의 웹 HTTP 통신, 이메일, 파일 전송에 사용된다.
  • TCP가 가상회선 방식을 제공한다는 것은 송신측과 수신측을 연결하여 패킷을 전송하기 위한 논리적 경로를 배정한다는 뜻이다.

패킷

  • 인터넷 내에서 데이터를 보내기 위한 경로 배정(라우팅)을 효율적으로 하기 위해서 데이터를 여러 개의 조각으로 나누어 존송을 하는데, 이를 패킷이라고 한다.

 

TCP는 패킷을 어떻게 추적하고 관리할까?

  • 데이터는 패킷 단위로 나누어 같은 목적지(IP 계층)으로 전송된다.

한 줄로 서야 하는 A,B,C라는 사람(패킷)이 서울(송신측)에서 출발하여 부산(수신측)으로 가야한다고 가정하다.

A,B,C가 순차적으로 가는 상황에서 B가 길을 잘못 들어서 분실되었다.

하지만 목적지에서는 A,B,C가 모두 필요한지 모르고 A,C만 보고 다 왔다고 착각할 수 있다. 그렇기 때문에 A,B,C라는 패킷에 1,2,3이라는 번호를 부여하여 패킷의 분실 확인 처리를 하기 위해 목적지에서 패킷을 재조립한다.

이런 방식으로 TCP는 패킷을 추적하며, 나누어 보내진 데이터를 목적지에서 받고 재조립할 수 있게 된다.

 

흐름제어

  • 송신측과 수신측 사이의 데이터 처리속도차이를 해결하기 위한 기법이다.
  • 만약 송신측의 전송량>수신측의 처리량일 경우 전송된 패킷은 수신측의 큐를 넘어서 손실될 수 있기 때문에 송신측의 패킷 전송량을 제어하게 된다.

1. Stop and Wait

  • 매번 전송한 패킷에 대한 확인 응답(ACK)을 받고 그 다음 패킷을 전송한다.
  • 이러한 구조때문에 비효율적이다.

2. Sliding Window

  • 수신측에서 설정한 위도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 기법
  • 윈도우 : 송신, 수신 스테이션 양쪽에서 만들어진 버퍼의 크기
  • stop and wait의 단점을 개선한 기법이다.
  • 송신측에서 ACK프레임을 수신하지 않더라도 여러 개의 프레임을 연속적으로 전송할 수 있다.
  • 전송되는 프레임관리를 위해 각 프레임의 모듈러에 의한 번호체계가 부여된다
  • 이 때 번호는 윈도우보다 커야한다. (윈도우보다 번호가 작으면 같은 윈도우에 같은 번호가 들어갈 수 있음)

위와 같은 구조에서 데이터 0,1 을 전송했다고 치면 슬라이딩 윈도우의 구조는 아래와 같이 변하며 윈도우의 크기는 전송한 데이터 프레임만큼 줄어들게 된다.

이 때 수신측에서 보낸 ACK프레임을 받게되면 전송측은 0,1 데이터를 정상적으로 받음을 알게 되고 전송측은 ACK프레임에 따른 프레임의 수만큼 윈도우가 오른쪽으로 확장된다.

 

오류 제어

  • 오류 검출과 재전송을 포함한다.
  • ARQ(Automatic Repeat Request) 기법을 사용해 프레임이 손상되었거나 손실되었을 경우, 재전송을 통해 오류를 복구한다.
  • ARQ 기법은 흐름 제어 기법과 관련되어 있다.

1. Stop and Wait ARQ

  • 송신측에서 1개의 프레임을 송신하고, 수신측에서 수신된 프레임의 에러 유무 판단에 따라 ACK or NAK를 보내는 방식이다.
  • 식별을 위해 데이터 프레임과 ACK 프레임은 각각 0,1 번호를 번갈아가며 부여한다.
  • 수신측이 데이터를 받지 못했을 경우, NAK를 보내고 NAK를 받은 송신측은 데이터를 재전송한다.
  • 만약, 데이터나 ACK가 분실되었을 경우 일정 간격의 시간을 두고 타임아웃이 되면, 송신측은 데이터를 재전송한다.

2. Go-Back-n ARQ(슬라이딩 윈도우)

  • 전송된 프레임이 손상되거나 분실된 경우 그리고 ACK 패킷의 손실로 인한 TIME_OUT이 발생한 경우, 확인된 마지막 프레임 이후로 모든 프레임을 재전송한다.
  • 슬라이딩 윈도우는 연속적인 프레임 전송 기법으로 전송측은 전송된 모든 프레임의 복사본을 가지고 있어야 하며, ACK와 NAK 모두 각각 구별해야 한다.
  • ACK : 다음 프레임을 전송.
  • NAK : 손상된 프레임 자체 번호를 반환.

 

재전송 되는 경우!!

1. NAK 프레임을 받았을 경우

  • 만약 수신측에서 0~5를 보냈다고 치자
  • 수신측에서는 데이터를 받았음을 확인하는 ACK를 중간중간 보낸다
  • 만약 수신측에서 데이터 오류 프레임2를 발견하고 NAK2를 보낸다고 해보자
  • 이 때 Gbn ARQ특징은 데이터를 재전송하는 부분이다. NAK(n)을 받아 n 데이터 이후의 모든 데이터를 재전송 한다.

2.전송 데이터 프레임의 분실

  • GBn ARQ의 특징은 확인된 데이터 이후의 모든 데이터 프레임 재전송과 수신측의 폐기이다.
  • 수신측에서 데이터 1을 받고 다음 데이터로 3을 받게 된다면 데이터 2를 받지 못했으므로 수신측에서는 데이터 3을 폐기하고 데이터 2를 받지 못했다는 NAK2를 전송측에 보낸다.
  • NAK를 받은 전송측은 (1) 경우와 같이 NAK(n) 데이터로부터 모든 데이터를 재전송하며 수신측은 기존에 받았던 데이터 중 NAK(n)으로 보냈던 대상 데이터 이후의 모든 데이터를 폐기하고 재전송 받는다.

위 그림처럼 0,1,3,4 는 잘 받았지만 2를 중간에 분실했다.

이 때 수신측은 2이후의 데이터를 모두 폐기시킨다.

송신측은 2번부터 다시 데이터를 보낸다.

 

3. 지정된 타임 아웃 내의 ACK 프레임 분실 (Lost ACK)

  • 전송측은 분실된 ACK를 다루기 위해 타이머를 가지고 있다.
  • 전송측에서는 이 타이머의 타임 아웃 동안 수신측으로부터 ACK 데이터를 받지 못했을 경우, 마지막 ACK된 데이터부터 재전송한다.

  • 전송측은 NAK 프레임을 받았을 경우, NAK 프레임 번호부터 데이터를 재전송한다.
  • 수신측은 원하는 프레임이 아닐 경우, 데이터를 모두 폐기 처리한다.
  • 타임아웃(ACK 분실)의 경우, 마지막 ACK된 데이터부터 재전송한다.

 

3.SR(Selective-Reject)ARQ

  • GBn ARQ의 확인된 마지막 프레임 이후의 모든 프레임을 재전송하는 단점을 보완한 기법이다.
  • SR ARQ는 손상된, 손실된 프레임만 재전송한다.
  • 그렇기 때문에 별도의 데이터 재정렬을 수행해야 하며, 별도의 버퍼를 필요로 한다.
  • 수신측에 버퍼를 두어 받은 데이터의 정렬이 필요하다.

 

참고

wildpup.cafe24.com/archives/469

github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/TCP.md

'CS > 네트워크' 카테고리의 다른 글

주소창에 naver.com을 치면 일어나는 일  (1) 2021.03.31
UDP  (1) 2021.03.31
OSI 7계층 & TCP/IP 4계층  (0) 2021.03.31
TCP 3 Way-Handshake & 4 Way-Handshake  (0) 2021.03.30
Cookie & Session  (0) 2021.03.30
Comments