1-3. TCP/IP 통신의 기본흐름

TCP/IP Protocol Suite를 기초로 하여 이들의 전체흐름을 도식화 해 보았다. 그림에서는 http 라는 프로토콜을 쓰는 응용프로그램이 데이터를 만든 다음 TCP/IP를 이용해서 네트워크 어댑터 카드를 통해서 내 보내기까지의 과정을 계층별로 그린 것이다. 정리를 한다는 기분으로 꼭 한번 생각해 보고 넘어가기 바란다.

<그림1-15. TCP/IP 통신의 흐름>

 

<그림1-15>를 보면서 이해해 보자. 어플리케이션 계층에서는 데이터를 만들었다. 웹서버로부터 홈페이지를 요청하는 http Get Request 일수도 있겠다. 이것을 전송계층의 TCP가 처리를 하도록 아래로 내려보내고 있다.

TCP는 상위로부터 받은 데이터에다가 자신이 해야 할 추가작업을 하고 있다. 목적지 컴퓨터에서 이 데이터를 처리해야 할 포트번호, 자신의 포트 번호와 … 으로 표기가 해 놓은 그 밖의 추가 정보를 TCP헤더라는 이름으로 붙이고 있다. 결국 데이터에 TCP헤더를 추가하여 패킷이 조금 커진 셈이다. 이 패킷을 특별히 세그먼트라고 부른다. 즉 TCP 세그먼트라고 부르는 것이다. TCP 는 이 세그먼트라고 불리우는 패킷을 하위의 계층으로 내려보내주면 역할이 끝난다. 하위의 계층에는 IP가 있다.

 

IP는 역시 TCP가 내려보낸 패킷에 자신이 해야할 일 작업을 더한다. IP가 하는 일은 패킷배달부 역할을 한다. 배달이 제대로 되려면 당연히 주소정보를 추가해야 한다. 받을 컴퓨터 IP주소, 자신의 IP주소 등 기타 추가로 많은 정보를 추가한 IP 헤더라는 것을 붙인다. 이것을 IP Packet 이라고 부른다. IP는 이것을 물리적 계층으로 내려보내야 한다.

 

예제의 네트워크는 이더넷(EtherNet)환경이다. 물리적인 환경에서는 MAC Address를 통해서 각각의 카드를 식별한다고 했다.  ARP를 이용해서 MAC Address를 알아낸 다음 이더넷 이 네트워크에서는 이더넷 환경에서 통신이 가능한 “프레임”이라고 부르는 패킷이 만들어 져야 한다. 이더넷에서는 상위 계층으로부터 받은 IP Packet에 수신측 MAC Address, 송신측 MAC Address 등으로 구성된 이더넷 헤더를 추가하고, 수신측에서 패킷의 손상유무를 확인하기 위한 CRC를 Trailer로써 추가한 다음 비로소 물리적인 네트워크에 전송을 해 주게 된다. 이것이 TCP/IP의 통신의 흐름이다.

 

여기서 응용프로그램이 만든 원본 데이터는 변화가 없었다는 것을 알 수 있다. 다만 각각의 계층에서 프로토콜들이 해야할 작업들을 충실히 했던 것뿐이다. 당연히 하위계층으로 내려갈수록 패킷의 크기는 커질 수 밖에 없다. 헤더가 계속 추가되고 있으니 당연한 결과이다. 각각의 프로토콜에서 처리해야 할 데이터에 해당하는 부분도 역시 점점 더 커지고 있다.  IP계층 입장에서 보자면 데이터에 해당되는 부분은 원본데이터에 TCP헤더부분이 더해진 것이 데이터 부분에 해당한다. 이렇듯 각각의 프로토콜 입장에서 몸통(Body)부분에 해당되는 영역을 Payload 라고 부른다. 정리하면 EtherNet패킷의 Payload 는 IP 패킷이 되고, IP패킷의 Payload는 TCP Segment 가 될 것이며, TCP패킷의 Payload는 응용프로그램의 데이터가 되는 것이다.

 

이러한 과정을 거쳐서 네트워크로 나간 패킷은 어떻게 될까? 이 패킷의 헤더에는 목적지의 MAC Address가 있으므로 패킷을 받게 되는 네트워크 어댑터 카드들은 자신의 MAC Address에 해당하는 패킷인지를 확인한 후 맞다면 받아들이게 되고, 자신의 패킷이 아니라면 무시한다. ARP Broadcast와 같은 브로드캐스트 패킷은 네트워크의 모든 컴퓨터들이 받게 되는 메시지이다. 이것도 당연히 받아들이게 된다. 결국 자신의 MAC Address에 해당하는 패킷과 브로드캐스드 주소를 가진 패킷이 네트워크 어댑터 카드들이 받아 들이게 되는 패킷이다.

 

패킷을 받은 네트워크 어댑터 카드는 이 패킷을 꼬리에 붙어 있는 CRC를 통해서 손상이 없음을 확인한 다음 이더넷 헤더부분을 제거하고 처리해야 할 몸통부분만을 상위의 프로토콜에게 올려준다. IP는 역시 헤더부분을 들여다 보는데 여기에는 목적지의 IP Address정보가 제공된다. 이것이 자신의 IP Address인지 확인을 한다. 아니라면? 역시 버리고, 목적지의 IP Address가 자신의 IP Address와 일치하다면 헤더를 제거하고, 상위의 프로토콜인 TCP나 UDP에게 올려보낸다. 어떤 프로토콜에게 올려보낼것인지는 IP헤더에 기록이 되어 있다. 예제의 경우는 TCP였다. IP계층으로부터 패킷을 넘겨받은 TCP는 헤더를 읽어서 목적지 포트번호를 확인한 다음 헤더를 제거하고 포트번호에 해당하는 응용프로그램에 데이터를 올려보낸다. 예제에서는 http 프로토콜이었으니 포트번호 80번이었을 것이다. 웹서비스에게 이 데이터를 넘겨주면 통신을 마치게 된다. 이런 과정을 통해서 송신측 컴퓨터의 응용프로그램이 만든 데이터는 아무런 손상없이 수신측 응용프로그램까지 전달 될 수가 있었다. 이 모든 것은 TCP/IP 프로토콜이 해 주고 있는 작업이었다는 것을 알 수 있다.

 

지금까지 설명한 내용은 앞의 내용을 잘 이해했다면 알 수 있는 내용이었다. 다시금 정리를 했던 이유는 바로 다음의 내용때문이다. 이것을 조금 더 응용해서 하나의 그림만 더 살펴보고 이번 장을 마친다.

 

IP 패킷이 라우터를 경유해서 어떻게 다른 네트워크로 흘러가는가? 이것을 이해하는 것은 TCP/IP통신을 이해하는 것에 있어서 아주 중요한 대목이다. TCP/IP Protocol은 LAN에서 혹은 WAN에서 매체나 통신방법을 가리지 않고 사용할 수 있는 범용의 산업표준 프로토콜이다. 이번 그림을 통하여 IP Packet이 생성되어 라우터를 건너 목적지에 도착할 때까지 패킷의 변화를 살펴보고 흐름을 이해해 보고자 한다.

 

<그림1-16. IP Packet의 기본흐름 이해>

위의 예제에서는 A호스트와 B호스트는 라우터로 분리된 서로 다른 네트워크에 있고, TCP/IP 통신을 하고자 한다. IP Address와 MAC Address를 실제로 예를 들지 않고, IP4, MAC2 등과 같이 표현하였다. 실제로는 192.168.5.3 등과 같은 IP가 들어 있어야 한다. 물론 MAC Address 항목에는 6바이트로 이루어진 12자리의 숫자가 있어야 할 것이다. 상위의 계층은 고려하지 않고, Network계층과 Physical 계층만을 고려한 것이다.

A호스트가 명령프롬프트에서 “ping IP4”라고 명령을 내렸다고 가정해 보겠다.

A호스트는 B호스트의 IP Address인 IP4를 목적지로 하는 IP Packet을 만들어내고, 이것을 네트워크에 내 보내기 위해서는 해당 네트워크의 프레임이 생성이 되어야만 한다. IP4를 쓰는 B호스트의 MAC Address인 MAC4를 목적지로 하는 이더넷프레임이 만들어 진다. 그 다음에 이것을 네트워크에 흘려보내게 되면 안타깝게도 결과는 “Reply from IP4”라는 성공의 응답이 날아오는 것이 아니라 “Request Timeout”이라는 에러메시지를 받게 된다.

A호스트가 B와 직접 통신을 할 수가 있을까? 단순히 그림상으로 봐도 안 된다는 걸 알 것이다. 중간에 라우터라고 하는 장비가 있고, A와 B가 통신을 위해서는 이 라우터를 넘어가야만 한다.

왜 직접 통신이 되지 않는 것인지 구체적으로 살펴보자. 지금 이 프레임의 목적지 MAC Address는 MAC4이다. A호스트가 네트워크에 패킷을 내 보냈을 때 A호스트가 속해 있는 모든 컴퓨터들이 이 패킷을 받게 된다. 라우터도 물론 이 패킷을 받게 된다. 이 패킷을 B호스트가 받기 위해서는 라우터가 넘겨줘야만 한다. 네트워크가 나뉘어 있기 때문이다.

라우터는 어떻게 동작할까? 호스트와 똑같이 생각하면 된다. 라우터의 NIC가 받아들이는 패킷은 목적지가 자신의 MAC Address인 MAC2이거나 브로드캐스트 어드레스인 패킷이다. 하지만 지금 라우터가 받은 MAC4는 그러한 것들에 해당되지 않는다. 당연히 라우터는 MAC4를 목적지로 하는 이더넷 프레임을 받게 되긴 하지만 그냥 버려버리고 만다. 자신이 처리할 패킷이 아니기 때문이다. 이런 이유로 통신이 실패하게 되는 것이다.

그래서 위와 같은 상황에서는 A호스트와 B호스트는 직접 통신을 할 방법은 없다. 반드시 라우터의 도움을 받아야만 한다. 하지만 분명히 우리는 위와 같은 상황보다 훨씬 복잡한 인터넷 환경에서도 원활하게 통신을 진행하고 있다. 어떻게 처리되는지를 이해해 보자. 바로 위에서 통신이 안되는 상황을 경험했었다. 하지만 자신과 같은 네트워크에 있는 호스트와 통신하는 방법과 자신과 다른 네트워크에 있는 호스트와 통신방법을 다르게 사용하면 해결할 수가 있다. 상대방 컴퓨터가 자신과 같은 네트워크에 있다면 직접 통신을 시도하고, 다른 네트워크에 있다면 라우터에게 전달요청을 맡기면 된다.

그래서 A호스트는 B호스트에게 데이터를 보내고자 할 때 가장 먼저 하는 작업이 바로 B호스트가 자신과 같은 로컬 네트워크에 있는지, 라우터 건너의 원격지 네트워크에 있는지를 판단한다. 그 판단의 방법으로 로컬 서브넷 마스크를 이용해서 상대방의 IP주소중에서 네트워크 ID를 구별해 내고, 자신이 속해있는 네트워크 ID와 비교작업을 한다. (여기에 대해서는2장.IP Address관리에서 자세히 다룬다.) 판단결과, 로컬네트워크라는 결과가 나오면 직접 해당 호스트의 MAC주소를 찾기위한 ARP브로드캐스트를 사용하고, 원격지 네트워크라면 라우터에게 전송을 요청하기 위해 라우터의 NIC에 해당하는 MAC주소를 찾기 위한 ARP브로드캐스트를 전파한다.

또 한 이유로, 만일 A호스트가 IP4에 해당하는 MAC Address를 찾는 ARP Request Broadcast 메시지를 만들어서 네트워크에 전파한다면 역시 에러가 발생한다. ARP메시지가 브로드캐스트이기 때문에 라우터는 이 ARP 요청을 라우터 건너편으로 넘겨주지 않기 때문이다. 라우터로 분리가 된 네트워크에서는 라우터 바깥의 네트워크, 즉 원격지 네트워크의 호스트와 통신을 할때는 라우터의 도움이 필수적인 것이다.

예제에서는 서로 다른 네트워크 ID라는 결과가 나왔기 때문에 원격지에 있다고 판별이 되었다. 그러면 A호스트는 라우터를 건너야만 목적지의 시스템에 접근할 수 있다는 판단을 하고 라우터의 도움을 얻어서 전송을 하고자 한다. 먼저 A호스트의 Network Layer에서 IP는 B호스트의 IP Address인 IP4를 목적지로 하는 패킷을 만든다.(그림1-16- ①) 그렇지만 A호스트는 IP4의 MAC Address를 찾고자 하는 ARP 브로드캐스트 요청을 만드는 것이 아니라 대신 메시지를 넘겨줄 라우터의 IP Address인 IP2의 MAC Address를 찾는 ARP 브로드캐스트 요청을 만들어서 네트워크에 내 보내게 된다.

라우터는 이 ARP 요청에 대한 응답으로 자신의 MAC Address인 MAC2를 담은 ARP응답 메시지를 만들어서 A호스트에게 전달하게 되고 이렇게 되면 A호스트는 라우터의 MAC Address를 알게 된 것이다. 이 MAC Address를 목적지로 하는 이더넷 프레임을 만들었다.(그림1-16-②)

A호스트는 B호스트로 보내기 위한 IP Packet을 라우터에게 요청하는 이더넷 프레임을 만드는 것이 가능해 진 것이다.

그 프레임은 라우터가 받아들이게 되고, 자신의 네트워크 인터페이스 카드가 가지는 MAC주소와 일치하기 때문에 CRC를 통해서 프레임의 무결성을 확인한 후, 헤더를 제거하고 데이터 부분에 해당하는 IP패킷을 네트워크 어댑터 카드 드라이버를 통해서 상위 계층에 해당하는 IP에게 전달한다.

라우터의 IP가 네트워크 어댑터 카드로부터 패킷을 받아서 목적지IP주소를 확인해 보면, MAC Address는 자신의 것이 맞았지만 목적지의 IP Address는 자신의 IP 주소와 하고, 그 패킷을 받아야 할 최종 목적지가 자신이 아니고 다른 호스트임을 알게 된다. 라우터가 아닌 일반호스트라면 이러한 경우에 자신의 패킷이 아니므로 버리면 그만이겠지만 라우터는 다르다. 이 패킷을 목적지까지 라우팅을 해 주는 것이 라우터의 임무이기 때문이다.

그때 라우터는 미리 정의된 자신의 라우팅 테이블을 근거로 목적지로 가기 위한 최적의 경로를 판단하고(그림1-16-③), 해당 네트워크로 새로운 물리적인 프레임을 만들어서 전송한다. (그림1-16-④) 이때 라우터가 만드는 프레임의 목적지 MAC주소는 또 다른 라우터의 MAC주소일 수도 있고, 특별한 호스트의 MAC주소일 수도 있다. 예제에서는 직접 IP4의 MAC에 해당하는 MAC4 라는 주소를 목적지의 주소로 사용을 하였다. (그림1-16-⑤)

지금까지 <그림1-16>에 대한 설명을 했다. 차근차근 그림을 한번 들여다 보자. 특히 A호스트에서 라우터로 넘어가는 패킷, 라우터에서 B호스트로 가는 패킷의 IP Address, MAC Address부분의 변화를 신경쓰면서 이해해 보기 바란다.

여기서 한가지 알고 가야 할 것이 있다. 라우터를 통해서 다른 네트워크 패킷이 넘어가지만 IP주소의 변화는 전혀 없는 것을 알 수 있다. 단지 물리적인 네트워크의 프레임만 변화가 있을 뿐이다. 이것은 큰 의미를 준다. 우리가 IP 을 사용하여 지구 반대편의 웹서버를 찾아갈 때 웹 브라우저에서 발생시킨 패킷은 크고 작은, 혹은 서로 다른 수많은 네트워크를 경유해서 전송되지만 IP 계층 위의 계층의 데이터는 변화가 없다. 단지 그때 그때 상황에 맞도록 IP 계층 하위 계층에서의 변화만으로 전송이 가능하다는 것이다.