본문 바로가기


냐옹아 멍멍해봐(How to Speak IT)/테크(IT) 문법

쉽게 이해하는 네트워크 17. TCP 프로토콜의 기능 및 특징 - 패킷 분할과 연결형 통신

반응형

TCP 프로토콜의 기능, 특징 - 세그먼트, 연결형 통신

TCP 프로토콜의 기능 및 특징

 

TCP 프로토콜의 기능과 특징

전송 계층의 대표적인 프로토콜인 TCP는 신뢰할 수 있고 정확한 데이터를 전달하기 위해 연결형 통신을 사용하는 프로토콜입니다.

 

연결형 통신 자세히 ⇒ 전송 계층과 포트 번호

 

TCP 프로토콜은 데이터를 패킷(패킷 교환 방식의 패킷을 의미합니다)이라는 여러 개의 작은 조각으로 분할하고, 패킷의 전송 속도를 조절하며, 패킷이 수신지까지 제대로 전송되는지 확인합니다. 인터넷 계층에서 각각 독립적으로 전송되는 패킷은 네트워크의 혼잡도와 라우팅에 따라 송신되는 순서와 수신되는 순서가 서로 다를 수 있습니다. 전송 계층의 TCP는 모든 패킷이 수신지에 제대로 도착했는지 확인하고 수신한 데이터의 순서를 송신한 순서대로 재설정하여 패킷들을 재조립함으로써 전체 데이터가 올바르게 전송되도록 합니다.

 

패킷 교환 방식 자세히 ⇒ TCP/IP와 패킷 교환

 

이렇게 TCP는 데이터를 패킷으로 분할하여 전송하고, 패킷 전송 과정을 연결형 통신 방식으로 제어하며, 수신한 패킷들을 재조립하는 방식으로 데이터 전송의 정확성과 신뢰성을 확보하고 있습니다.

 

TCP 프로토콜의 데이터 단위 - 패킷 분할과 조립

전송 계층의 TCP 프로토콜이 응용 계층의 데이터 단위인 메시지를 받아 작은 조각으로 분할한 데이터 단위를 세그먼트라고 합니다. 즉, TCP 프로토콜에 따라 분할된 데이터에 TCP 헤더가 붙어 캡슐화된 전송 계층의 패킷이 세그먼트입니다.

 

세그먼트와 패킷의 관계 자세히 ⇒ TCP/IP와 패킷 교환

 

캡슐화 자세히 ⇒ TCP/IP에서의 데이터 통신(ft. 캡슐화와 역캡슐화)

 

TCP에서 데이터를 분할하는 단위를 MSS(Maximum Segment Size, 최대 세그먼트 길이)라고 하며, MSS는 송신지와 수신지가 원활한 통신을 하기 위해 서로 합의하여 결정합니다. 일반적으로 사용하는 MSS의 표준 크기는 1,460 바이트입니다. TCP는 MSS를 넘는 크기의 데이터를 MSS 단위로 분할합니다.

 

분할된 데이터에 순서 번호(Sequence Number)를 부여하여 전송 과정에서 전송 순서가 뒤바뀌더라도 수신지에서 원래의 데이터로 재조립할 수 있습니다.

 

분할된 데이터에 순서 번호와 송신지 포트 번호, 수신지 포트 번호 등 수신지까지 데이터를 제대로 전송하기 위해 필요한 정보가 담긴 TCP 헤더가 붙어 세그먼트가 만들어지고, 이 세그먼트가 인터넷 계층으로 전송됩니다.

 

<그림 1> tCP 프로토콜의 데이터 단위

 

TCP 통신 과정

연결형 통신인 TCP 프로토콜은 데이터를 전송하기 전에 먼저 상대방이 데이터를 수신할 수 있는지 여부를 확인하여 상대방과의 연결을 확립한 후 통신을 시작합니다. 이렇게 TCP는 데이터 전송 전에 정상적인 통신이 가능한지 확인하는 과정을 거치고 통신 중에도 상대방과 계속적인 연락을 취함으로써 데이터 전송의 확실성을 높입니다.

 

TCP 통신은 ① 정상적인 통신이 가능한 상태인지를 확인하는 연결(또는 커넥션, connection) 확립에서 시작하여 ② 데이터를 전송하고 ③ 연결을 해제하는 과정을 순차적으로 거치게 됩니다.

 

<그림 2> TCP 통신 과정

 

① 연결 확립 ()

3-way 핸드 셰이크

 

보통 한 컴퓨터에서 여러 애플리케이션을 동시에 사용합니다. 또한, 애플리케이션 사이의 통신은 데이터 전송 한 번으로 끝나지 않습니다. 이메일 송수신, 웹 사이트 접속 등 대부분의 경우 여러 데이터가 연속해서 전송됩니다. 애플리케이션마다 연속으로 전송되는 데이터를 가상의 이동 통로를 만들어 전송함으로써 애플리케이션별로 데이터의 흐름을 관리할 수 있게 됩니다. 즉, 연결 확립을 통해 애플리케이션 간에 일대일 통신을 할 수 있는 가상 연결 통로를 만드는 것입니다.

 

연결 확립은 3-way 핸드 셰이크(3-way handshake)라고 하는 3단계 과정을 거쳐 확립됩니다.

 

통신을 하려면 수신 호스트의 허락을 받아야 하므로 먼저 송신 호스트는 수신 호스트에 연결 확립 허가를 받기 위한 요청을 보냅니다. 연결 요청은 데이터 없이 TCP 헤더만으로 된 커넥션 확립 요청 패킷을 보내는 방법으로 이루어집니다. TCP 헤더에는 연결 요청 코드 값인 SYN을 사용합니다

 

송신 호스트가 보낸 요청을 받은 수신 호스트는 연결 확립을 허가한다는 응답을 하기 위해 연결 확립 응답 코드 ACK를 TCP 헤더에 담은 패킷을 수신 호스트로 보냅니다. 동시에 수신 호스트도 송신 호스트로부터 데이터 전송 허가를 받기 위해 연결 확립 요청(SYN)을 보냅니다.

 

수신 호스트의 요청을 받은 송신 호스트는 수신 호스트에게 데이터 전송을 허가한다는 응답으로 연결 확립 응답(ACK)을 보냅니다.

 

이렇게 데이터를 보내기 전에 패킷을 3번 교환하면서 통신 상대방과 연결 확립을 하는 과정이 상대방을 확인하고 악수를 하는 과정과 비슷하다고 하여 3-way 핸드 셰이크라고 부릅니다.

 

<그림 3> 3 - way 핸드 셰이크에 의한 연결 확립

 

3 - way 핸드 셰이크에 의한 연결 확립 과정에서 송신 호스트와 수신 호스트의 상호 합의 하에 MSS가 결정되고*, MSS에 크기에 맞춰 데이터를 분할하여 패킷을 만듭니다. 분할된 데이터가 몇 번째 데이터인지 알려 주는 역할을 하는 순서 번호의 초기값도 연결 확립이 이루어질 때 32비트로 구성된 임의의 숫자로 결정됩니다.

 

*. 각 호스트는 연결 확립 요청을 보낼 때 TCP헤더에 MSS 옵션을 붙여 자신의 통신 환경에 적합한 MSS를 통지합니다. 양쪽의 값 중 적은 쪽의 값이 MSS로 사용됩니다.

 

③ 연결 해제

데이터 전송이 완료된 후에는 연결을 끊기 위한 요청을 교환해야 합니다. 연결을 요청할 때는 SYN과 ACK라는 코드를 사용했지만, 연결을 종료할 때는 연결 종료를 뜻하는 FIN과 ACK를 사용합니다.

 

먼저 송신 호스트는 수신 호스트로 연결 종료 요청(FIN)을 보냅니다.

 

수신 호스트는 송신 호스트로 연결 종료 응답(ACK)을 반환하고, 동시에 수신 호스트는 송신 호스트로 연결 종료 요청(FIN)을 보냅니다.

 

송신 호스트는 수신 호스트로 연결 종료 응답(ACK)을 반환합니다.

 

<그림 4> 3 - way 핸드 셰이크에 의한 연결 종료

 

데이터 전송

3-way 핸드 셰이크로 송신 호스트와 수신 호스트 사이에 연결 확립이 되면 데이터를 전송할 수 있는 연결 통로가 만들어집니다. 연결 확립 상태에서 송신 호스트가 데이터를 전송하면 데이터를 수신한 호스트는 반드시 데이터 도착 여부를 확인해서 송신 호스트에게 알려줍니다.

 

TCP에서는 송신 호스트가 전송한 데이터가 수신 호스트에 도착하면 수신 호스트가 확인 응답(ACK)을 보냅니다. 확인 응답으로 데이터 도착의 신뢰성을 구현하는 것입니다. 확인 응답은 수신 호스트가 몇 번째 데이터를 수신했는지, 다음에 전송할 데이터는 몇 번째 데이터인지 알려주는 확인 응답 번호(acknowledgement number)로 이루어집니다.

 

아래 <그림 5>와 <그림 6>을 통해 TCP 통신에서 데이터가 전송되는 흐름을 살펴보도록 하겠습니다.

 

연결 확립 단계에서 두 호스트 간의 통신에 사용할 MSS가 1460바이트, 순서 번호의 초기값이 0번으로 결정된 경우입니다. 송신 호스트가 수신 호스트에게 보낼 데이터가 8000바이트인 경우 송신 호스트는 <그림 5>와 같이 6개의 패킷으로 데이터를 분할합니다. 패킷의 순서 번호는 초기값부터 시작해 패킷의 크기(MSS)만큼 증가한 값이 할당됩니다. 따라서 첫 번째 패킷의 순서 번호는 0, 두 번째 패킷의 순서 번호는 1460 (0+1460), 세 번째 패킷의 순서 번호는 2920(1460+1460)이 됩니다.

 

<그림 5> 순서 번호

 

먼저 송신 호스트에서 순서 번호가 0인 첫 번째 패킷, 즉 1460 바이트의 데이터를 전송합니다.

 

수신 호스트는 송신 호스트가 보낸 데이터를 수신하면 잘 받았다는 확인 응답의 의미로 다음에 받을 데이터 번호를 송신 호스트로 보냅니다. 확인 응답 번호로 어디까지 데이터를 수신했는지, 다음에 보낼 데이터가 무엇인지를 알 수 있습니다.

<그림 6>에서 수신 호스트는 첫 번째 데이터 1460 바이트를 수신하고 다음에 수신하고자 하는 데이터의 순서 번호 1460을 확인 응답 번호에 넣어 전송합니다.

 

수신 호스트로부터 확인 응답을 받은 송신 호스트는 순서 번호 1460의 패킷을 전송합니다.

 

수신 호스트는 1460바이트를 수신하고 다음에 수신하고자 하는 데이터의 순서 번호 2920을 확인 응답 번호에 넣어 전송합니다.

 

데이터의 전송이 완료될 때까지 이러한 과정을 반복합니다.

 

데이터 전송 과정에 오류가 발생해서 수신 호스트에 데이터가 도착하지 않을 경우 수신 호스트는 확인 응답 번호를 반환하지 않습니다. 송신 호스트는 수신 호스트의 확인 응답을 일정 시간 기다리다가 확인 응답이 오지 않을 경우 데이터를 재전송하여 데이터 전송의 신뢰성을 확보합니다.

 

<그림 6> TCP 통신의 흐름 - 순서 번호와 응답 확인 번호

 

TCP 흐름 제어

통신의 신뢰성 확보를 위해 하나의 패킷(세그먼트)을 전송할 때마다 확인 응답을 거치면, 송신 호스트는 확인 응답이 돌아올 때까지의 시간 동아 아무 일도 하지 않고 기다리기 때문에 패킷의 전송 속도가 지연됩니다. 통신에서 신뢰성만큼 중요한 것이 통신 속도이기에 TCP는 흐름 제어(flow control)를 통해 전송 효율을 높이고 있습니다.

 

흐름 제어는 패킷 단위가 아닌 패킷보다 큰 단위로 확인 응답을 하는 방법으로 이루어집니다. 즉, 하나의 패킷을 보내고 응답을 기다리는 대신 여러 패킷을 한꺼번에 연속해서 전송한 후 확인 응답을 받음으로써 전송 효율을 높이는 것입니다.

 

<그림 7> 패킷 단위 응답과 윈도우 제어

 

확인 응답을 기다리지 않고 송신할 수 있는 데이터의 크기를 윈도우 사이즈(window size)라고 합니다. 다시 말해 윈도우 사이즈는 데이터를 전송할 때 한 번에 전송할 수 있는 전체 패킷의 크기를 의미합니다. 송신 호스트는 윈도우 사이즈만큼 수신 호스트의 확인 응답을 기다리지 않고 패킷을 보낼 수 있습니다.

 

송신 호스트가 많은 양의 데이터를 한꺼번에 보내면 수신 호스트에서 제때 처리하지 못해 송신 호스트가 같은 데이터를 다시 보내는 쓸 데 없는 통신이 생길 수 있습니다. 따라서 윈도우 사이즈는 수신 호스트가 한 번에 받아낼 수 있는, 다시 말해 수신 가능한 버퍼*의 크기가 되어야 합니다.

 

*. 버퍼(Buffer)는 컴퓨터 메모리 상에 위치하여 송수신하는 패킷을 일시적으로 저장하는 장소를 뜻합니다.

 

특히 수신 호스트의 컴퓨터 성능이나 동시에 동작하는 애플리케이션의 개수 등 수신 호스트의 사정에 따라 송신 호스트가 보내는 데이터의 속도보다 수신 호스트가 데이터를 수신하는 속도가 느려지는 경우 처리할 수 없는 데이터가 넘쳐흐르는 오버플로*(ove flow) 문제가 발생하기 때문에 윈도 크기는 수신 호스트의 상황에 따라 변경되어야 합니다. 따라서, 윈도우 사이즈는 수신 호스트가 결정해야 하며, 수신 호스트의 상황이 수시로 반영되어야 효율적인 통신을 할 수 있게 됩니다.

 

*. 수신한 데이터의 크기가 버퍼 크기를 넘어서는 것을 오버플로라고 합니다.

 

윈도 사이즈는 3-way 핸드 셰이크에 의한 연결 확립 시 수신 호스트가 초기값을 결정하며 수신 호스트는 확인 응답을 보낼 때 TCP 헤더에 윈도우 사이즈를 지정하여 현재 어느 정도까지 수신이 가능한지를 수시로 알려줍니다. 이렇게 TCP는 수신 호스트가 윈도우 크기를 변경하는 방법으로 송신 호스트에게 데이터 전송량을 지시함으로써 데이터의 흐름을 제어하고 전송 효율을 높입니다.

 

위 <그림 6> 예제에서 수신 호스트의 버퍼 크기가 5000 바이트라면 수신 호스트는 연결 확립시 윈도우 사이즈가 5000 바이트라고 송신 호스트에게 알려 줍니다.

아래 <그림 8>과 같이 송신 호스트는 윈도우 사이즈 5000 바이트를 초과하지 않도록 패킷 3개( 4380 바이트)를 함께 보낸 후 응답 확인을 기다립니다. 수신 호스트는 버퍼에 패킷 3개를 임시로 저장하면서 버퍼에 저장한 데이터를 순차적으로 처리하고, 수신한 패킷에 대해 확인 응답을 하면서 버퍼 크기를 반영한 윈도우 사이즈를 송신 호스트에 알려줍니다.

응답 확인을 받고 윈도우 크기를 확인한 송신 호스트는 윈도우 사이즈에 맞춰 송신할 패킷의 양을 조절하며 데이터의 흐름을 제어합니다.

 

 

<그림 8> 윈도우 사이즈에 의한 흐름 제어

 

TCP와 UDP를 사용하는 애플리케이션

지금까지 살펴본 것처럼 TCP는 정확하고 신뢰성 있는 데이터 전달을 위해 연결 확립, 데이터 분할과 조립, 응답 확인과 윈도 사이즈에 의한 흐름 제어 등 다양한 기능을 제공하고 있습니다.

TCP의 데이터 제어 기능으로 TCP 헤더에는 송신지 포트 번호와 수신지 포트 번호 외에 순서 번호, 응답 확인 번호, 윈도우 사이즈 등 다양한 부가 정보가 담깁니다. TCP의 제어 기능 덕분에 데이터의 신뢰성이 보장되고, 상위 계층에서는 데이터 제어를 신경 쓸 필요 없이 애플리케이션 본연의 기능을 구현하는데만 집중할 수 있습니다. 하지만 TCP의 복잡한 제어가 때로는 애플리케이션의 기능을 구현하는데 문제를 일으키기도 하고 데이터 전송 속도를 느리게 만드는 원인이 되기도 합니다.

 

반면 전송 계층의 또 다른 프로토콜인 UDP는 비연결 통신이기 때문에 위에서 설명한 데이터 제어에 관한 어떠한 기능도 없고 오직 전송 계층에서 애플리케이션에 데이터를 배분하는 역할만 합니다. 따라서 UDP 헤더에는 송신지 포트 번호와 수신지 포트 번호 외에 다른 부가 정보가 없습니다. 부가 정보의 크기가 적고, 응답 확인을 하지 않는 비연결 통신이기 때문에 UDP의 데이터 전송 효율이 TCP 보다 좋다는 장점이 있습니다. 하지만 데이터에 대한 제어를 전혀 하지 않기 때문에 수신지 애플리케이션에 데이터가 도착했는지 알 수가 없습니다. 데이터가 수신지까지 도착했는지 확인하는 등의 기능이 애플리케이션에 필요하다면 애플리케이션을 개발할 때 그러한 기능을 만들어서 반영해야 합니다.

 

이처럼 TCP와 UDP가 각각의 장단점이 있기 때문에 만들고자 하는 애플리케이션에 따라 어떤 프로토콜을 적용할지 결정해야 합니다. 정확한 데이터 전송보다 빠른 전송이 필요한 애플리케이션이나 애플리케이션 자체에서 데이터에 대한 세세한 제어를 하고 싶은 경우는 UDP를 사용하는 것이 좋지만, 데이터 제어 부분이 어렵거나 생각하고 싶지 않을 때는 TCP에 데이터 제어에 관한 모든 것을 맡기고 애플리케이션 개발에 집중하는 것이 좋습니다.

 


참고 자료

 

정기철, 「인공지능 시대를 위한 컴퓨터 과학 개론」, 한빛아카데미, 2020.

다케시타 다카후미 외 3인, 이영란 역, 「마스터링 TCP/IP 입문편」, 성안당, 2019.

ANK CO., Ltd., 이영란 역, 「TCP/IP가 보이는 그림책」, 성안당, 2019.

강환수 외 3인, 「컴퓨터 개론」, 인피니티북스, 2019.

진혜진, 「네트워크 개론」, 한빛아카데미, 2019.

삼성SDS 기술사회, 「정보통신」, 한울아카데미, 2019.

정진욱 외 4인, 「컴퓨터 네트워크」, 생능출판사, 2018.

김현정, 「소프트웨어 개념사전」, 궁리, 2019.

이영호 외 1인, 「당신이 지금 알아야 할 AWS」, 비제이 퍼블릭, 2019.

김종훈, 「소프트웨어 세상을 여는 컴퓨터 과학」, 한빛아카데미, 2018.

Gene, 김성훈 역, 「그림으로 배우는 네트워크 원리」, 영진 닷컴, 2020.

Ryuji Kitami, 이영란 역, 「그림 한 장으로 보는 최신 네트워크 용어 해설」, 정보문화사, 2016.

미즈구치 카즈야, 이승룡 역, 「모두의 네트워크」, 2018.

리브로웍스, 신상재 역, 「TCP/IP 쉽게, 더 쉽게」 , 제이펍, 2016.

Gene, 진솔 역, 「손으로 익히며 배우는 네트워크 첫걸음」, 한빛미디어, 2017.

아미노 에이지, 김현주 역, 「하루 3분 네트워크 교실」, 영진닷컴, 2016.

김석준, 「문과생을 위한 ICT 이야기 」, 커뮤니케이션즈북스, 2019.

James F. Kurose외 1인, 「컴퓨터 네트워킹」, 퍼스트북, 2017.

Tsutomu Tone, 이도희 역, 「성공과 실패를 결정하는 1%의 네트워크 원리」, 성안당, 2018.

백금란 외 1인, 「TCP/IP 이해하기」, 북스홀릭퍼블리싱, 2015.

반응형