<div id="readability-page-1" class="page"><div><h2 id="tcp-의-특징">TCP 의 특징</h2>
TCP (Transmission Control Protocol) 는 이름에서 알 수 있듯이, 패킷 교환 방식 네트워크에서 패킷들이 안전하게 이동할 수 있도록 보장해주는 프로토콜이다. 크게 흐름제어, 혼잡제어 동작을 수행하는데, 이번 포스팅에선 그 중에서도 흐름제어 기법에 대해 살펴볼 것이다.
<h2 id="흐름제어란">흐름제어란?</h2>
<ul>
<li>송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법</li>
</ul>
즉, 수신측이 너무 많은 패킷을 수신받지 않도록 하기 위함이다. 수신측에는 패킷을 수신받는 버퍼의 크기가 정해져있는데, 만약 송신측의 전송 속도가 너무 빨라 한 번에 수많은 패킷을 수신받아버린다면, 버퍼가 가득차 손실되는 패킷들이 발생할 것이다.
수신측의 처리 속도가 더 빠른 것은 문제가 되지 않지만, 위와 같은 상황처럼 송신측의 처리 속도가 더 빠를 경우 분명히 이를 제어할 수단이 필요하다. 따라서 TCP 에서는 흐름제어 기법을 사용한다.
<blockquote>
흐름제어의 기본 개념은, 수신측이 송신측에게 자신의 상태를 계속하여 알리는 것이다. 즉, 데이터를 더 받을 준비가 되어있다는 피드백이 이루어졌을 때 송신측에서 패킷을 이어서 보내도록 하는 것이다.
</blockquote>
 
<h2 id="패킷-전송-과정">패킷 전송 과정</h2>
우선, TCP/IP 계층에 의거하여 패킷이 전송되는 과정을 간략히 살펴보자.
<ol>
<li>
Application Layer : 송신측 Application Layer 가 소켓에 데이터를 입력
</li>
<li>
Transport Layer : 데이터를 세그먼트로 감싸고 Network Layer 에 전달
</li>
<li>
수신측 노드로 세그먼트가 전송됨. 동시에 송신측의 Send Buffer 와 수신측의 Receive Buffer 각각에 데이터가 저장됨.
</li>
<li>
수신측 Application Layer 에서 준비가 되면, Receive Buffer 에 있는 데이터를 읽기 시작함
</li>
<li>
따라서, Receive Buffer 가 넘쳐나지 않도록 하는 것이 흐름 제어의 핵심!
→ 이를 위해 RWND(Receive Window, Receive Buffer 의 남은 공간) 을 송신측에 계속하여 피드백함
</li>
</ol>
 
<h2 id="흐름제어-기법-종류">흐름제어 기법 종류</h2>
<h3 id="stop-and-wait">Stop-And-Wait</h3>
매번 전송한 패킷에 대한 확인 응답을 받아야만 그 다음 패킷을 전송하는 기법
<img src="https://media.vlpt.us/images/haero_kim/post/d0d48e5e-55df-4936-8328-796fa8b53f56/263B7D4E5715ECEB32.png">
<h3 id="sliding-window-go-back-n-arq">Sliding Window (Go-Back-n ARQ)</h3>
수신측에서 설정한 윈도우 크기만큼 송신측에서 패킷 각각에 대한 확인 응답없이 세그먼트를 전송하게 하고, 데이터 흐름을 동적으로 조절하는 기법
<blockquote>
<h4 id="전송은-되었으나-ack-을-받지-못한-byte-크기를-파악하기-위해-사용">전송은 되었으나, ACK 을 받지 못한 Byte 크기를 파악하기 위해 사용</h4>
LastByteSent - LastByteAcked ≤ ReceiveWindowAvertised 
→ 마지막에 보낸 바이트 수 - 마지막에 확인된 바이트 수 ≤ 버퍼 남은 공간 
(현재 이도저도 못하고 있는 패킷 수 ≤ 슬라이딩 윈도우 크기)
</blockquote>
윈도우 크기만큼 패킷을 모두 전송하고, 그 패킷들의 전달이 확인되는대로 해당 윈도우를 옆으로 슬라이딩하면서 그 다음 패킷을 전송하는 방식으로 동작한다.
<img src="https://media.vlpt.us/images/haero_kim/post/193e1e14-c3bb-4049-a07f-df0a2c9de843/253F7E485715ED5F27.png">
TCP/IP 를 사용하는 모든 호스트들은 송신 그리고 수신을 위한 2개의 Window 를 가지고 있다. 호스트들은 실제 데이터를 보내기 전에 3-Way Handshake 를 통해 연결 설정을 해줄 때 수신 호스트의 Receive Window 크기에 자신의 Send Window 크기를 맞춰 설정한다.
세부 동작을 살펴보면 다음과 같다.
 
<ol>
<li>송신 버퍼</li>
</ol>
<img src="https://media.vlpt.us/images/haero_kim/post/71089f91-675e-43dd-8874-0521a0a3c211/22532F485715EDF218.png">
<ul>
<li>200 이전 바이트는 전송 성공했고, 확인 응답을 받은 상태</li>
<li>그런데 200~202 바이트는 아직 확인 응답을 받지 못한 상태</li>
<li>203~211 바이트는 아직 전송이 되지 않은 상태</li>
</ul>
 
<ol start="2">
<li>수신 윈도우</li>
</ol>
<img src="https://media.vlpt.us/images/haero_kim/post/239f4dbf-7e74-4b55-bf23-1a92e9abcf36/25403A485715EE362B.png">
 
<ol start="3">
<li>송신 윈도우</li>
</ol>
<img src="https://media.vlpt.us/images/haero_kim/post/b24a934c-a837-4ea3-aee5-f7165e871af5/2520244B5715EE6A14.png">
<ul>
<li>수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하여 흐름제어</li>
</ul>
 
<ol start="4">
<li>송신 윈도우 슬라이딩 (이동)</li>
</ol>
<img src="https://media.vlpt.us/images/haero_kim/post/b25f6bcf-0668-4ae0-af95-b6b951a3f9af/227DC8505715EEBA0A.png">
<ul>
<li>Before 에서 203~204를 전송하면 수신측에서는 확인응답 203을 보내고, 송신측은 이를 받아 After 상태와 같이 송신 윈도우를 203~209로 이동함</li>
<li>After 는 205~209가 전송 가능한 상태</li>
</ul></div></div>

해로, HAERO, 海路

TCP 의 특징
TCP (Transmission Control Protocol) 는 이름에서 알 수 있듯이, 패킷 교환 방식 네트워크에서 패킷들이 안전하게 이동할 수 있도록 보장해주는 프로토콜이다. 크게 흐름제어, 혼잡제어 동작을 수행하는데, 이번 포스팅에선 그 중에서도 흐름제어 기법에 대해 살펴볼 것이다.
흐름제어란?
송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
즉, 수신측이 너무 많은 패킷을 수신받지 않도록 하기 위함이다. 수신측에는 패킷을 수신받는 버퍼의 크기가 정해져있는데, 만약 송신측의 전송 속도가 너무 빨라 한 번에 수많은 패킷을 수신받아버린다면, 버퍼가 가득차 손실되는 패킷들이 발생할 것이다.
수신측의 처리 속도가 더 빠른 것은 문제가 되지 않지만, 위와 같은 상황처럼 송신측의 처리 속도가 더 빠를 경우 분명히 이를 제어할 수단이 필요하다. 따라서 TCP 에서는 흐름제어 기법을 사용한다.
흐름제어의 기본 개념은, 수신측이 송신측에게 자신의 상태를 계속하여 알리는 것이다. 즉, 데이터를 더 받을 준비가 되어있다는 피드백이 이루어졌을 때 송신측에서 패킷을 이어서 보내도록 하는 것이다.
패킷 전송 과정
우선, TCP/IP 계층에 의거하여 패킷이 전송되는 과정을 간략히 살펴보자.
Application Layer : 송신측 Application Layer 가 소켓에 데이터를 입력
Transport Layer : 데이터를 세그먼트로 감싸고 Network Layer 에 전달
수신측 노드로 세그먼트가 전송됨. 동시에 송신측의 Send Buffer 와 수신측의 Receive Buffer 각각에 데이터가 저장됨.
수신측 Application Layer 에서 준비가 되면, Receive Buffer 에 있는 데이터를 읽기 시작함
따라서, Receive Buffer 가 넘쳐나지 않도록 하는 것이 흐름 제어의 핵심!
 → 이를 위해 RWND(Receive Window, Receive Buffer 의 남은 공간) 을 송신측에 계속하여 피드백함
흐름제어 기법 종류
Stop-And-Wait
매번 전송한 패킷에 대한 확인 응답을 받아야만 그 다음 패킷을 전송하는 기법
Sliding Window (Go-Back-n ARQ)
수신측에서 설정한 윈도우 크기만큼 송신측에서 패킷 각각에 대한 확인 응답없이 세그먼트를 전송하게 하고, 데이터 흐름을 동적으로 조절하는 기법
전송은 되었으나, ACK 을 받지 못한 Byte 크기를 파악하기 위해 사용
LastByteSent - LastByteAcked ≤ ReceiveWindowAvertised
→ 마지막에 보낸 바이트 수 - 마지막에 확인된 바이트 수 ≤ 버퍼 남은 공간
(현재 이도저도 못하고 있는 패킷 수 ≤ 슬라이딩 윈도우 크기)
윈도우 크기만큼 패킷을 모두 전송하고, 그 패킷들의 전달이 확인되는대로 해당 윈도우를 옆으로 슬라이딩하면서 그 다음 패킷을 전송하는 방식으로 동작한다.
TCP/IP 를 사용하는 모든 호스트들은 송신 그리고 수신을 위한 2개의 Window 를 가지고 있다. 호스트들은 실제 데이터를 보내기 전에 3-Way Handshake 를 통해 연결 설정을 해줄 때 수신 호스트의 Receive Window 크기에 자신의 Send Window 크기를 맞춰 설정한다.
세부 동작을 살펴보면 다음과 같다.
송신 버퍼
200 이전 바이트는 전송 성공했고, 확인 응답을 받은 상태
그런데 200~202 바이트는 아직 확인 응답을 받지 못한 상태
203~211 바이트는 아직 전송이 되지 않은 상태
수신 윈도우
송신 윈도우
수신 윈도우보다 작거나 같은 크기로 송신 윈도우를 지정하여 흐름제어
송신 윈도우 슬라이딩 (이동)
Before 에서 203~204를 전송하면 수신측에서는 확인응답 203을 보내고, 송신측은 이를 받아 After 상태와 같이 송신 윈도우를 203~209로 이동함
After 는 205~209가 전송 가능한 상태

TCP 흐름제어 기법 살펴보기

댓글