[데이터 통신과 네트워킹] TCP 창, 흐름 제어, 오류 제어

◆ TCP의 창

TCP에서 사용되는 창(WIndow) - TCP는 데이터 전송을 위한 각 방향에 대해서 2개의 창(송신 창, 수신 창)를 사용하며 따라서 양방향 통신을 위하여 4개의 창이 필요 - 하지만 간단한 설명을 위해 통신이 단방향(클라이언트로부터 서버로)으로 이루어지는 상황을 고려 - 양방향 통신은 2개의 단방향 통신과 피기배깅(piggybacking)을 이용하면 유추 가능

TCP의 송신 창

- 여기에서 사용되는 창 크기는 100바이트이지만 뒷부분에서 송신 창 크기는 수신자(흐름 제어)와 하부 네트워크의 혼잡(혼잡 제어)에 의하여 조절됨 - 그림에서는 어떻게 송신 창이 열리고(open), 닫히고(close), 축소(shrink)되는지 보여줌 - 청색은 송신했으나 아직 ACK를 못 받은 상태, 흰색은 송신 대기중 상태 - 검정색 범위가 송신창 크기(수신측에서 광고함) - Sf : Ack 못 받은 첫 데이터(201), Sn : 송신할 첫 데이터(261)

송신창

TCP의 송신창은 선택적 반복 프로토콜과 유사하지만 차이점이 있음

1. 창과 관련된 개체 자체의 차이 - 선택적 반복에서 창은 패킷의 번호이나, TCP의 창은 바이트 번호를 표현 - TCP에서는 세그먼트 단위의 전송이 이루어지나, 창을 제어하는 변수는 바이트로 표현 2. 구현 방법에 따라 약간 차이가 있지만, 여기에서는 송신 TCP가 프로세스로부터 데이터를 수신하자마자 데이터에 대한 세그먼트를 전송할 수 있다고 가정함 3. 타이머의 개수 - 이론적으로 선택적 반복은 전송되는 패킷마다 각각의 타이머를 사용하지만, TCP 프로토콜은 단지 하나의 타이머만 사용 - 오류 제어에서 이러한 타이머를 어떻게 사용하는지에 대해 설명 예정

 

수신창

- 하늘색 : 수신후 ack까지 전달했으나 아직 프로세스에서 가져가지 않음 - 흰색 : 추가적으로 수신할 수 있는 버퍼 영역 - 검정색 : 수신창 크기 - Rn : 다음에 수신 예정인 바이트(261) - 전체 버퍼 영역 : 하늘색 + 검정색

---

◆ 흐름 제어

TCP에서 데이터 흐름과 흐름 제어 피드백

흐름 제어 생산자가 데이터를 만드는 속도와 소비자가 데이터를 사용하는 속도의 균형을 맞추는 것 - TCP는 흐름 제어와 오류 제어를 구분 - 송신과 수신 TCP 사이에 설정된 논리 채널은 오류가 없다고 가정 - 그림은 송신측과 수신측 사이의 단방향 데이터 전송의 경우를 보여주며, 양방향 데이터 전송은 단방향 전송 과정으로부터 유추하기로 함 - 이 그림에서는 송신 프로세스로부터 송신 TCP로, 송신 TCP에서 수신 TCP로, 그리고 수신 TCP에서 수신 프로세스로 데이터가 이동하는 것을 알 수 있음(경로 1, 2, 3). - 흐름 제어 피드백은 수신 TCP에서 송신 TCP로, 그리고 송신 TCP에서 송신 프로세스로 이동(경로 4, 5). - 대부분의 TCP 구현에서는 수신 프로세스로부터 수신 TCP로의 흐름 제어 피드백은 제공하지 않고, 수신 프로세스가 수신할 준비가 되어 있을 때마다 수신 버퍼로부터 데이터를 읽어감 - 즉, 수신 TCP는 송신 TCP를 제어하고, 송신 TCP는 송신 프로세스를 제어 - 송신 TCP로부터 송신 프로세스로의(경로 5) 흐름 제어 피드백은 송신 TCP 창이 다 차면 송신 TCP에 의한 데이터의 이동 거부로 획득 - 즉, 여기에서 흐름 제어에 대한 설명은 수신 TCP로부터 송신 TCP로(경로 4) 전송되는 피드백에 대해서만 집중하면 됨

어리석은 윈드우 신드롬
미닫이 창 동작에서는 전송 응용 프로그램이 데이터를 천천히 발생하거나, 또는 수신 응용 프로그램이 데이터를 천천히 소비하는 경우에 문제 발생

- 아주 적은 수의 데이터를 포함하는 세그먼트의 전송인 경우 동작의 효율은 감소 - 예를 들어, TCP가 단지 1바이트의 데이터를 포함하는 세그먼트를 전송하는 경우단지 1바이트를 전달하기 위해서 41바이트의 데이터그램(20바이트의 TCP 헤더와 20바이트의 IP 헤더)이 전송되어야 함 - 즉 오버헤드는 41/(41+1)이 되고, 네트워크의 용량은 상당히 비효율적으로 사용되며, 이러한 비효율성은 데이터 링크층과 물리층의 오버헤드를 고려하면 더욱 나빠짐 - 이러한 문제를 어리석은 윈도우 신드롬(silly window syndrome)이라 함 - 송신측: 네이글 알고리즘 - 수신측: 클라크 방법, 확인 응답 지연법

---

< 네이글 알고리즘 >

송신측에서 발생되는 신드롬 - 송신 TCP가 한 번에 한 바이트씩 데이터를 천천히 발생하는 응용 프로그램을 서비스하는 경우에 어리석은 윈도우 신드롬이 발생 - 응용 프로그램이 송신 TCP의 버퍼에 한 번에 한 바이트씩 쓰는 경우 - 송신 TCP에 어떤 특별한 지시 사항이 없는 경우, 송신 TCP는 한 바이트의 데이터를 포함하는 세그먼트를 만들게 되고, 41바이트 크기의 세그먼트가 인터넷을 통해서 전달 - 이러한 문제를 해결하기 위한 네이글 알고리즘(Nagle algorithm)은 간단함 1. 송신 TCP는 단지 1바이트일지라도 송신 응용 프로그램으로부터 수신하는 첫 데이터를 세그먼트로 만든 후 전송 2. 첫 번째 세그먼트를 전송한 후에 송신 TCP은 1)수신 TCP로부터 확인응답을 수신하거나 또는 2)최대 크기의 세그먼트를 구성할 수 있을 정도로 충분한 데이터가 출력 버퍼에 저장되기 전까지 대기 3. 나머지 전송 기간 동안 두 번째 단계를 반복 *네이글 알고리즘의 장점  1) 매우 간단함 2) 데이터를 발생하는 응용 프로그램의 속도와 네트워크의 데이터 전달 속도를 고려하였다는 것

< 클라크 방법 & 확인 응답 지연법 >

수신 측에서 발생되는 신드롬 - 수신 TCP가 한 번에 1바이트와 같이 천천히 데이터를 소비하는 응용 프로그램에 서비스를 제공하는 경우는 수신 TCP에 어리석은 윈도우 신드롬 현상이 발생 - 송신 응용 프로그램으로부터 1 Kbytes 블록의 데이터가 발생되지만, 수신 응용 프로그램이 한 번에 1바이트씩 소비한다고 가정하고, 이때 수신 TCP의 입력 버퍼는 4 Kbytes라고 가정 - 처음에 송신측에서 4 Kbytes의 데이터를 전송하면, 수신측에서는 수신된 데이터를 버퍼에 저장하고 수신 버퍼는 데이터로 꽉 차게 됨 - 수신 버퍼가 모두 차면, 수신 TCP는 창 크기를 0으로 설정하여 통보하고 이 정보를 수신한 송신측에서는 데이터 전송을 멈춤 - 수신 응용 프로그램이 수신 TCP의 입력 버퍼로부터 첫 번째 바이트의 데이터를 읽으면 입력 버퍼에 1바이트 정도의 공간이 발생 - 수신 TCP는 1바이트의 창 크기를 송신 TCP로 통보하며, 데이터의 전송을 기다리던 송신 TCP는 이 통보를 좋은 소식으로 간주하고 1바이트의 데이터를 포함하는 세그먼트를 전송하고, 이 절차가 반복됨 - 다시 말하면, 1바이트의 데이터가 수신 응용 프로그램으로부터 소비되고 1바이트를 전달하는 세그먼트가 송신 TCP로부터 전송되어, 효율성의 문제와 어리석은 윈도우 신드롬 문제가 다시 발생하게 됨 - 도착하는 속도보다 데이터를 천천히 소비하는 응용 프로그램에 의해서 발생되는 어리석은 윈도우 신드롬 현상을 예방하기 위해 두 가지 방법이 제시 1. 클라크 해결 방법 - 데이터가 도착하자마자 확인응답을 전송하지만, 수신 버퍼에 최대 크기의 세그먼트를 수용할 수 있는 충분한 공간이 있거나, 적어도 수신 버퍼가 반 이상 비어 있기 전까지는 창 크기를 0으로 통보 2. 확인 응답 지연법 - 수신측에서는 세그먼트가 도착하자마자 즉시 세그먼트에 대한 확인응답을 전송하는 대신 수신 버퍼에 충분한 공간이 있을 때까지 세그먼트의 확인응답을 보류 - 지연된 확인응답은 송신 TCP로 하여금 자신의 창만큼의 데이터 전송 후에는 전송을 멈추게 되고, 이 방법을 이용하여 신드롬을 제거 가능

---

◆ 오류 제어

검사합 - 각 세그먼트에는 검사합 필드가 있으며, 이 필드는 세그먼트가 훼손되었는지를 검사하기 위해 사용 - TCP는 모든 세그먼트에 필수 사항인 16비트 검사합을 이용 확인 응답 - TCP는 데이터 세그먼트의 수신을 확인해 주기 위하여 확인응답을 사용 - 데이터를 포함하지는 않지만 하나의 순서 번호를 소비하는 제어 세그먼트도 역시 확인응답 필요. - ACK 세그먼트는 순서 번호를 소비하지도 않고 확인응답도 없음 - 기존 TCP는 확인응답의 한 가지 유형인 누적 확인응답만을 사용하였으나, 현재 구현되는 TCP에서는 선택적 확인응답도 같이 사용

TCP 세그먼트 형식

※ 누적 확인 응답(ACK)

- 본래 TCP는 세그먼트의 수신을 누적하여 확인응답할 수 있도록 설계

- 수신 측은 순서에 맞지 않게 저장되거나 수신된 모든 세그먼트들을 무시하고 수신하고자 하는 다음 바이트를 광고

- 일반적으로 긍정 누적 확인응답(positive cumulative acknowledgment) 또는 ACK라고 함

- TCP 헤더에 있는 32비트의 ACK 필드가 누적 확인응답(ACK, Accumulative Acknowledgment)을 위하여 사용되며, 이 필드는 ACK 플래그 비트가 1로 설정된 경우에만 유효

 

※ 선택 확인 응답(SACK)

- 선택 확인응답(SACK, Selective Acknowledgment) 또는 SACK라고 하는 새로운 유형의 확인응답이 점차적으로 많은 구현에 추가되어 사용됨

- SACK는 ACK를 대치하는 것이 아니라 송신측에게 부가 정보를 알려주기 위해 사용

- SACK는 순서에 맞지 않게 들어온 데이터 블록과 중복 세그먼트 블록을 통보

- TCP 헤더에는 이러한 유형의 정보를 추가할 수 있는 여분의 공간이 없기 때문에 SACK는 TCP 헤더 끝에 옵션의 형태로 구현

 

수신측에서 확인응답 생성 시점 TCP에서 몇 가지 규칙이 정의되었으며 구현에 사용 Rule1: 종단 A가 종단 B로 데이터 세그먼트를 보낼 때 수신할 다음 순서 번호를 제공하는 확인응답을 포함(piggyback)해야 한다. Rule2: 수신자가 보낼 데이터가 없고 순서대로(in-order) 세그먼트(예상한_expected 순서 번호 포함)를 수신하고, 이전 세그먼트가 이미 확인응답(ACKed)된 경우 수신자는 다른 세그먼트가 도착할 때까지 또는 일정 기간(일반적으로 500ms)이 지날 때까지 대기 Rule3 : 수신자가 예상한 순서 번호로 세그먼트가 도착하고 이전 순서대로 도착된 세그먼트가 승인되지 않은 경우 수신자는 즉시 ACK 세그먼트를 송부   Rule4: 세그먼트가 예상보다 높은(빠른) 순서에 맞지 않는 번호로 도착하면 수신자는 즉시 다음 예상 (받기를 원하는) 세그먼트의 순서 번호를 알리는 ACK 세그먼트를 송부   Rule5: 누락되었던 세그먼트가 도착하면 수신기는 ACK 세그먼트를 전송하여 예상되는 다음 시퀀스 번호를 통보   Rule6: 중복된 세그먼트가 도착하면 수신자는 세그먼트를 버리지만 예상되는 다음 순서 세그먼트를 나타내는 확인응답(ACK)을 즉시 보냄

 

재전송

오류 제어 메커니즘의 핵심

- 전송된 세그먼트는 확인응답되기 전까지 버퍼에 저장

- 재전송 타이머가 만료되거나 송신측 버퍼에 있는 첫 번째 세그먼트에 대한 3개의 중복 ACK를 수신하는 경우에는 세그먼트가 재전송

RTO 이후의 재전송 - 송신 TCP는 각각의 연결을 위해 하나의 재전송 타임아웃(RTO, Retransmission Time-Out)을 유지하고 타이머를 구동 - 타이머가 만료되어 타임아웃이 발생하면, TCP는 버퍼 앞에 있는 세그먼트를 전송하고 타이머를 재구동 - TCP에서 RTO의 값은 가변적이며 세그먼트의 왕복 시간(RTT, Round Trip Time)을 기반으로 업데이트됨 (RTT는 세그먼트를 목적지로 전송하고, 그 세그먼트에 대한 확인응답을 수신하는 데 걸리는 시간을 나타냄) 3개의 중복 ACK 세그먼트 이후에 재전송 - RTO 값이 크지 않은 경우에는 앞에서 언급한 규칙을 이용하여 세그먼트를 재전송해도 충분함 - 인터넷에서 처리율 향상을 위해 송신측에서 타임아웃을 기다리는 것보다 좀더 빨리 재전송하기 위해 근래에 구현된 대부분의 TCP는 ‘3개의 중복 ACK 규칙’을 따르며 손실로 간주된 세그먼트를 즉시 재전송함 - 이러한 특징을 빠른 재전송(fast retransmission)이라고 함 - 이러한 TCP에서 만일 하나의 세그먼트에 대한 3개의 확인응답이 수신되면, 타임아웃을 기다리지 않고 다음 세그먼트가 즉시 재전송

---

모든 내용은 '데이터 통신과 네트워킹 6판' 책을 공부하여 작성 하였습니다.