TCP/IP Protocol Suite

2.TCP/IP Protocol Suite

앞에서 우리는 간략한 TCP/IP Protocol의 개요에 대해서 알아 보았다. 2장에서는 TCP/IP Protocol Suite에 포함되어 있는 각각의 프로토콜들이 하는 일이 무엇인지, 왜 그렇게 많은 프로토콜로 구성이 되어 있어야 하는 지에 대해서 정리해 보도록 한다.


[그림2]TCP/IP Protocol Suite의 흐름

TCP/IP는 WAN(Wide Area Network)을 위해서 디자인된 표준 프로토콜 Suite이다.TCP/IP Protocol은 Network Interface, Internet, Transport, Application의 4가지 계층모델에 매핑된다. 가장 기초가 되는 모델은 Network interface Layer이다.이 계층은 실제 네트워크에서 데이터를 전송하는 케이블에 frame이라고 불리우는 데이터를 실어 보내고, 반대로 데이터를 받는 역할을 담당한다.

다음의 계층은 Internet Layer이다. 이 계층은 주소를 관리하고, 포장하고, Routing을 하는 역할을 담당한다. internet layer에는 4가지 프로토콜이 있다. 첫 번째 IP (Internet Protocol)는 호스트들과 네트워크에서 주소를 관리하고, 패킷을 라우팅하는 역할을 한다. ARP (Address Resolution Protocol)은 같은 네트워크에 위치한 호스트들의 하드웨어 어드레스 (MAC Address)를 얻는데 이용된다. ICMP (Internet Control Message Protocol)은 패킷 전송에 관한 에러메세지를 처리하는데 이용된다.

Transport Layer는 호스트들간에 통신을 제공하는 역할을 담당한다. Transport Layer에는 2개의 프로토콜이 있다. TCP (Transmission Control Protocol)과 UDP (User Datagram Protocol)이 그것이다. "Connection oriented Protocol" 이라고 하는 TCP는 일반적으로 많은 양의 데이터를 전송하거나, 데이터를 받았다는 확인메세지를 요구할 필요가 있을 때 사용된다. "Connectionless protocol"이라고 하는 UDP는 패킷의 정확한 전달을 보장하지 않는다.어플리케이션은 일반적으로 적은양의 데이터를 전송할 때 UDP를 사용한다. UDP가 전송에 대한 확신을 주지 않기 때문에 그러한 책임은 상위의 Application이 가지게 되는 것이다.

가장 상위에 있는 모델은 Application Layer이다. 이 계층은 어플리케이션이 네트워크에 접근가능하도록 해 주는 역할을 한다. 마이크로소프트 TCP/IP는 어플리케이션과 transport Layer사이에 Windows Sockets과 NetBIOS interface를 제공한다. Windows Sockets은 많은 전송계층의 프로토콜과 서로 다른 주소체계 사이에서 윈도우 환경에 표준 API를 제공한다. NetBIOS는 TCP/IP, NetBEUI등의 프로토콜들을 이용할 수 있는 표준 interface를 제공한다. 그러면 이제 각 계층의 프로토콜들이 어떻게 연결이 되는 지 보자. 어플리케이션이 다른 호스트로 데이터를 전송했을 때 먼저 데이터는 하위의 프로토콜에게 전달이 되게 된다. 그러면, 하위의 프로토콜은 상위의 계층에서 넘겨 받은 데이터를 캡슐화시키고, 그 데이터앞에 Header라고 불리우는 추가 정보를 덧붙이게 된다. 그 다음 또, 자신의 하위 계층에게 그 데이터를 전달한다. 최종적으로 가장 하위의 계층에 해당하는 Network interface layer는 네트워크에 실어 보낼 수 있는 frame이라는 것을 만들어서 데이터를 전송하게 된다.

받는 쪽의 호스트에서 생각을 해 보자. 받게 되는 것은 물론 해당 호스트의 Network interface layer에서 받게 될 것이다. 그럼 이제 받는 쪽에서는 송신측과는 반대로 각 계층마다 자신들이 이해할 수 있는 상대방 프로토콜이 덧붙여 놓은 Header부분만 제거를 하고, 순수한 데이터 부분만 상위의 계층에 전달하게 되고, 결국 최종적으로는 순수한 데이터만이 어플리케이션에게 전달이 되게 될 것이다. 송신측의 호스트의 어플리케이션이 만든 데이터에 여러 프로토콜들이 Header로서 정보를 추가했던 작업은 네트워크 상에 데이터를 정확히 전달하기 위한 조치였던 것이다.

당연히 수신측의 호스트는 그러한 정보를 기반으로 하여 내가 받은 데이터가 온전한 모양의 데이터인지 계산하고 자신의 최종목적지인 가장 상위의 어플리케이션에게는 단지 상대방의 어플리케이션이 만든 데이터만을 전달하게 되는 것이 TCP/IP Protocol Suite의 동작원리인 것이다. 그러면 이제는 보다 자세히 각각의 계층과 프로토콜의 특징과 역할에 대해서 검토해 보도록 하겠다.

(1) Network Interface Layer

이 계층은 실제 네트워크에서 데이터를 전송하는 케이블에 frame이라고 불리우는 데이터를 실어 보내고, 반대로 데이터를 받는 역할을 담당한다. 상위의 계층(IP)에서 패킷이 도착하면 그 패킷에 서두(Preamble)과 CRC(Cyclic Redundancy Check)를 추가하게 된다. Preamble은 프레임의 시작을 정의하는 바이트의 일련번호이다. CRC는 프레임이 손상되지 않았음을 검증하는 수학적 계산값을 말한다. 송신측의 호스트는 실제 프레임의 크기를 계산하여 CRC에 그 값을 첨부하게 된다. 그 프레임이 수신측의 호스트에게 도착하였을 때 수신측의 호스트는 CRC를 다시 계산하게 되고, 결과값과 실제 도착한 프레임의 크기가 일치하면 정상적인 프레임으로 판단하여 프레임의 헤더부분에 들어있는 목적지의 MAC Address를 참조하여 Broadcast유형의 주소이거나, 자신의 MAC Address와 일치하면 상위의 계층으로 올려보내고, 다르다면 버려지게 된다. 네트워크상에서 에러를 체크하기 위한 첫 번째 배려이다.

(2) Internet Layer

이 계층은 패킷의 주소를 결정하고, 라우팅하는 역할을 담당한다.

- IP (Internet Protocol)

IP역시 UDP처럼 "연결없는 전송서비스 (Connectionless delivery service)"를 제공한다. "연결없는 전송서비스"라는 것은 패킷을 전달하기 전에 대상 호스트와 아무런 연결도 필요하지 않다는 것을 의미한다. 또, IP는 전송을 위해서 최선을 다하지만, 책임은 지지 않게 때문에 그것에 대한 책임은 상위의 계층의 프로토콜(TCP)이 담당하거나, 어플리케이션 차원에서 해결을 해야만 한다. 어플리케이션이 만든 데이터를 상위의 프로토콜로부터 전달받았을 때, IP는 그 패킷에 IP자신의 헤더정보를 추가한다. IP헤더에는 많은 정보가 들어 있다. Internetwork상을 돌아다니면서 수많은 라우터를 건너 원하는 목적지까지 도달할 수 있도록 많은 헤더정보가 필요한 것이다.


[그림3] IP Packet 구조

많은 헤더 중에서 가장 중요한 헤더정보는 IP Address라고 할 수 있겠다. IP헤더는 자신의 IP Address, 목적지의 IP Address 등의 Address정보, 상위의 계층 중 어느 프로토콜을 이용할 것인지를 알려주는 Protocol정보, 패킷이 제대로 왔는지를 확인하기 위한 용도로 사용이 되는 Checksum 필드, 네트워크 상에서 존재하지 않는 호스트를 찾기 위해 끝없는 방황을 하는 것을 막기 위한 TTL등의 정보가 들어 있다.

IP가 하는 일은 이러한 헤더정보를 이용하여 패킷을 전달하는 역할을 한다. 그 때 참조하는 것이 바로 Routing Table이며, 만약에 Routing Table에 정보가 없다면 자신의 Default Gateway로 설정이 되어 있는 Router에게 패킷을 전달하게 된다.

IP상의 라우터들은 4가지 일을 하고 있다.

첫 번째는 IP호스트로부터 받은 패킷의 헤더에 들어 있는 TTL(Time to Live)을 감소시킨다. 보통 1을 감소시키나, 라우터가 상당히 혼잡한 상태라면 1이상이 감소될 수도 있다. 만일 TTL이 "0"이 된다면 그 패킷은 버려지게 된다. 이렇게 라우터들이 IP패킷의 TTL을 감소시킴으로써 TTL이 "0"이 되는 시점이 되면 더 이상 패킷을 전달시키지 않기 때문에 잘못된 IP정보를 가진 패킷이 무한정 순환을 하게 되는 일은 막아주게 된다.

두 번째, 그리고 나면 IP Router는 헤더정보에서 TTL이 바뀌었기 때문에 거기에 맞는 Checksum을 다시 계산하게 된다.

세 번째, 패킷을 전달해야 할 라우터의 MAC Address를 알아낸다.

네 번째, 해당 라우터로 패킷을 전달한다. 이 과정을 바로 Routing이라고 하는 것이며, 이 작업을 담당하는 하드웨어를 우리는 "라우터"라고 부르는 것이다.

인터네트워크 상의 모든 라우터들은 위의 4가지 작업을 반복하게 되며, 결국 원하는목적지의 라우터까지 도착하고, 그 라우터를 통해서 목적지의 호스트에게까지 데이터를 전달시킬 수 있게 된다.

이번에는 라우터가 전송할 수 없는 너무 큰 크기의 패킷을 받았다고 가정을 해 보자.이 때도 역시 라우터는 패킷을 여전히 전송시킬 수 있는 방법을 포함하고 있다. 라우터의 IP는 파킷을 수용할 수 있는 작은 조각(Chunk)으로 나눈다. 그렇게 작은 크기로 나누어서 전송하게 되면, 받는 호스트에서는 잘게 나뉜 패킷을 원래 크기로 조합하는 작업을 하여 상위의 어플리케이션에 데이터를 전송하게 된다. 이 과정을 가리켜서 fragmentation(조각내기)와 reassembly(재조립)이라고 한다.

예를 들면 이더넷과 토큰링이 조합된 네트워크 환경을 들 수가 있다. 만일 1.5KB크기의 IP패킷이 라우터로 들어 왔을 때, 라우터가 전송해야 할 네트워크에서는 1.5KB를 수용할 수 없고 단지 500byte의 크기만을 지원한다고 해 보자. 그 때 라우터의 IP는 1.5KB의 원본패킷을 500byte 단위로 잘게 쪼개게 될 것이다. 결국 3개의 패킷이 생성이 될 것이고, 라우터는 이 3개의 패킷을 전송하게 된다. 만일 라우터의 IP가 이렇게 나뉘어진 패킷을 아무 생각없이 단순히 전송을 해 버린다고 생각을 해보면 도대체 받는 호스트 입장에서는 답답한 노릇이 아닐 수 없을 것이다. 도대체 이것이 조각난 패킷인지, 온전한 패킷인지. 또, 조각난 것을 알았다 하더라도 원본이 어떻게 생겼는지를 알아야 다시 조립할 수가 있을 것이다. 그러한 이유로 패킷을 조각내는 라우터의 IP는 조각낸 패킷에 수신호스트가 구분할 수 있는 데이터를 추가하게 된다. flag, fragment ID, fragment Offset이 바로 그것이다. flag는 이 패킷이 완전한 패킷이 아닌 조각나 있음을 보여준다. fragment ID는 조각난 패킷들이 원래 같은 패킷의 일부분이었음을 보여주는 정보이다. 동일한 패킷에서 조각난 패킷들은 같은 fragment ID를 가지게 되는 것이다. fragment Offset은 수신측 호스트가 어떻게 조각난 패킷을 조립할 것인지를 알려준다. 조각들의 순서를 알려주는 것이다. 수신측 호스트는 이러한 패킷을 fragment offset순서에 따라서 조립을 한 다음 완전한 패킷을 만들고, 상위 계층의 프로토콜인 TCP나 UDP에게 보내게 된다. 물론 이때 TCP에게 보내야 할 것인지, UDP에게 보내야 할 것인지의 정보는 IP헤더에서 제공을 해 주고 있다.

- ARP (Address Resolution Protocol)

IP가 패킷을 라우팅할 때는 물리적인 통신을 담당하는 네트워크 어댑터 카드 (NIC)가 인식할 수 있는 하드웨어 어드레스가 필요하게 된다. 이것이 바로 MAC Address이며 IP는 이러한 MAC Address를 알아 내야만 통신을 할 수가 있게 되는 것이다. 이러한 IP의 요구에 해답을 제공하는 것이 바로 ARP (Address Resolution Protocol)이다.

IP가 통신을 원하는 호스트의 MAC Address가 요청될 때 ARP는 가장 먼저 ARP Cache를 찾아서 그곳에 원하는 IP Address와 MAC Address의 정보가 있는지를 알아보게 된다. 최근에 해당 호스트와 통신을 했던 적이 있다면 ARP Cache에는 그러한 정보가 남아 있기 때문이다. 만약 없다면, ARP는 목적지의 IP Address를 근거로 하여 MAC Address를 찾기 위한 ARP요청 frame을 만들고, 그것을 네트워크에 broadcast하게 된다. 그러면 broadcast이기 때문에 네트워크에 존재하는 모든 호스트가 ARP요청을 받게 되지만, 결국 응답하는 호스트는 해당 IP Address와 일치하는 IP를 가진 호스트만이 응답을 하고 나머지는 버려지게 된다. 이제 IP는 ARP를 통해서 목적지 호스트의 MAC Address를 알아냈기 때문에 MAC Address를 기반으로 하는 통신을 할 수가 있게 되었다.


[그림4] ARP패킷의 구조

-ICMP (Internet Control Message Protocol)

만일 패킷을 라우팅하는 도중에 문제가 발생한다면 어떻게 해야 할까? 그 때 바로 ICMP (Internet Control Message Protocol)이 필요해 진다. ICMP는 원본호스트에게 에러를 보고하는 일을 한다. 예를 들어서 라우터를 통과하려는 패킷이 많아서 혼잡해 진다면, ICMP는 "Source quench Message"를 보내게 된다. Source quench Message는 호스트에게 전송속도를 늦춰줄 것을 요청하는 메시지이다. 또, 라우터가 혼잡한 상황에서 보다 나은 길(route)을 발견하였을 때 역시 Redirect 메시지로써 다른 길을 찾도록 한다. 마지막으로 "Destination Unreachable"메시지를 전달할 때도 ICMP를 이용한다.

"Destination Unreachable"은 회선이 다운되어서 라우팅 할 수 없을 때 발생되는 메시지이다. 이상 몇 가지를 보았는데, 하는 일이 비슷하다는 것을 알 수 있다. ICMP는 IP가 패킷을 전달하는 동안에 발생할 수 있는 문제점을 보고하는 역할을 하는 프로토콜이다.

가장 쉽게 알 수 있는 방법은 Ping을 이용해서 호스트와의 연결성을 테스트했을 때의 작업이다. 아래 상자안의 내용은 ping을 이용해서 테스트를 해본 결과이다. 첫 번째 IP로부터는 정상적인 응답이 왔지만, 두 번째 IP로부터는 응답이 오지 않았다. 이러한 일을 처리해주는 일이 ICMP의 몫이다.

D:\>ping 203.239.60.254 Pinging 203.239.60.254 with 32 bytes of data: Reply from 203.239.60.254: bytes=32 time<10ms TTL=127 Reply from 203.239.60.254: bytes=32 time<10ms TTL=127 Reply from 203.239.60.254: bytes=32 time<10ms TTL=127 Reply from 203.239.60.254: bytes=32 time<10ms TTL=127 Ping statistics for 203.239.60.254: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms D:\>ping 203.234.60.254 Pinging 203.234.60.254 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 203.234.60.254: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

-IGMP (Internet Group Message Protocol)

다른 프로토콜에 비해서는 비교적 쓰임새가 한정적인 프로토콜이다. IGMP는 multicast메시지와 관련이 있다. IGMP를 사용하는 라우터는 멀티캐스트를 받아야할 호스트컴퓨터를 판단하고, 다른 라우터로 멀티캐스트 정보를 전달할 수 있다. IGMP패킷은 IP데이타그램을 통해서 전달된다.

※참고 : TCP/IP 통신의 유형 -Unicast (Direct) : tcp/ip호스트간의 1:1통신 -Multicast : 1:多 통신, (5명이 참여하고 있는 화상회의를 생각해보자. 이때 통신방법을 unicast를 이용한다면, 송신컴퓨터는 총 4개의 IP패킷을 전송해야 할 것이다. 하지만, Multicast를 사용하면, 1개의 패킷만으로 처리를 할 수가 있게 된다. 이러한 경우에 효율적인 방법이다.) -Broadcast : 1:all 통신, 목적지 컴퓨터의 IP를 알 수 없는 상황에 사용하게 된다.

(3) Transport Layer

Transport Layer는 TCP/IP Protocol을 가진 두 호스트간의 통신을 위한 방법을 제공해 주는 계층이다. 이 계층에 해당하는 UDP와 TCP는 두 호스트를 연결해 주는 하나의 지점으로서 "Port"라고 부르는 점(창구)을 가지고 통신을 한다. 웹서비스의 예를 들어보자. 웹서버는 웹서비스를 하고 있지만, 추가로 FTP서비스, SMTP서비스 등 수많은 TCP/IP기반 서비스를 처리하고 있다. 클라이언트가 웹서비스를 하고 있는 시스템에게 웹서비스를 요청하기 위해서는 자신이 원하는 서비스를 명확히 밝힐 필요가 있게 된다. 그렇지 않으면 서버 입장에서는 클라이언트가 무슨 서비스를 원하는지를 알 방법이 없기 때문이다. 이 방법으로서 TCP/IP에서는 "Port"라고 부르는 번호를 이용해서 서비스를 구분하고, 클라이언트 쪽에서 제공한 포트와 자신이 제공하고 있는 서비스의 포트를 연결시킴으로써 정상적인 서비스를 하게 되는 것이다.

- UDP (User Datagram Protoocl)

UDP는 보통 적은 양의 데이터를 전송하는 데 사용하며 2가지 특징을 가지고 있다.

첫 번째, UDP는 Connectionless Protocol이다. 이것은 실제 데이터를 전송하기 전에 먼저 어떤 연결도 맺지 않는 다는 것을 의미한다. 그렇지만 UDP는 broadcast를 이용하여 한꺼번에 많은 수의 호스트들에게 데이터를 전송할 수 있다.

두 번째, UDP는 메시지의 확실한 전송을 보장하지는 않는다. 그래서 UDP Data는 순서가 없이 도착할 수 있고, 중복될 수도 있다. UDP는 이러한 것들을 해결해 줄 수 없다. UDP가 처리해 주지 못하는 이러한 부분들은 보다 상위의 계층에서 해결해 줘야 한다. 결국 Application이 확실한 전송을 보장해 주기 위한 부분까지 담당을 해야 한다는 것이다.그렇다면 굳이 상대적으로 불안정한 UDP를 왜 사용해야 할까? 주로, 화상회의, 리얼오디오, 인터넷방송 등에서 사용이 되는 것을 보면 그 쓰임새를 짐작할 수 있다. 우리는 화상회의를 할 때, 깨끗한 화면만을 제공받진 못한다. 끊기기도 하고, 잠시동안 멈추기도 하지만, 계속 실시간으로 서비스를 받을 수 있게 된다. 만일 TCP를 사용한다면 이러한 일들은 어려워졌을 것이다. 또, 서버의 문제를 관리자에게 알려주기 위한 긴급한 메시지의 경우를 생각해 보면, 이런 긴급한 상황에 TCP처럼 사전세션을 맺는 과정을 처리하고, 느긋한(?) 통신을 하는 것은 어울리지 않는 일일 것이다. 이런 이유로 UDP도 분명히 필요한 protocol이 된다.

UDP패킷의 구조는 아래의 그림과 같다.


[그림5] UDP패킷의 구조

- TCP (Transmission Control Protocol)

TCP는 보통 큰 사이즈의 데이터를 전송하는 데 사용되며 3가지의 특징을 가지고 있다.

첫 번째, TCP는 connection-oriented protocol이라고 불리운다. 이것은 실제 데이터를 전송하기 전에 먼저 TCP Session을 맺는 과정이 필요함을 의미한다. 이 과정을 "TCP 3-way handshaking"이라고 부른다.

두 번째 TCP는 Sequence Number (일련번호)와 Acknowledgements (확인신호)를 이용하여 신뢰성 있는 전송을 보장한다. Sequence Number는 여러개의 데이터를 한꺼번에 전송해도 뒤섞이지 않도록 해 주며, 또 수신측의 호스트에서는 그 순서대로 재조합을 할 수 있는 방법을 제공해 준다. Acknowledgements는 송신측의 호스트로부터 데이터를 잘 받았다는 수신측의 확인메시지를 의미한다.

세 번째, TCP는 Byte-stream Communication을 한다. Byte-Stream이라는 의미는 TCP가 데이터의 의미는 중요하지 않고, 단지 byte단위로 데이터를 나눠서 전송하는 것을 말한다.


[그림6] TCP패킷의 구조

지금까지 간략하지만, TCP/IP Protocol Suite와 각 Protocol의 쓰임새에 대해서 정리를 해 보았다. TCP/IP는 인터넷표준프로토콜이다. 종이 몇장 가지고는 설명하기가 턱없이 부족한 이 시대의 인터넷을 이끌어가고 있는 프로토콜이다. TCP/IP에 대해서 관심이 있다면 관련서적 한권쯤은 정독을 할 것을 권장한다. 그러한 내용이 기본이 되었을 때, 어떤 내용이든지 네트워크라는 관련된 공부를 하는데 보다 빠른 이해를 도울 수 있게 될 것이다.