앞에서 우리는 TCP Sliding Window 에 대해서 알아 보았다. 그러면, 이러한 TCP Window라고 하는 것의 Size의 크기 여부가 네트워크에서 가지는 영향에 대해서 정리를 해 보도록 한다.먼저 정리를 해 보면, NT는 "Window size"는 8K, "Segment Size"는 1K로 설정이 되어 있다. 물론 NT의 Registry를 편집함으로써 수정은 가능하지만 권장하지는 않는다. 이미 우리의 선배들이 시행착오를 거쳐서 최적의 size로서 설정이 되어 있기 때문에 우리는 그러한 문제를 고민하는 것보다는 효율적으로 운영하는데 초점을 두는 것이 바람직하겠다. window size가 너무 작을 경우와 너무 클 경우 어떠한 일이 생길 것인지 알아보자.

(1) Window size가 작은 경우 [그림1~3]

[그림1]

Window size가 1K라고 가정을 해 보면 어떻게 될까? 이제 앞에서 보았던 전송과 응답과정을 이해했다면 금방 알 수 있는 문제다.송신측의 컴퓨터는 1K의 데이터를 전송하고 그것에 대한 응답을 기다릴 것이다. Ack신호가 오면 그 다음 차례인 2번으로 window를 sliding시켜서 또 전송을 시작할 것이다.

하나를 보내고 하나를 받고, 좋아 보이지만 답답한 방법이 아닐 수 없다.

[그림2]      [그림3]

(2) Window size가 큰 경우

Window size가 크다 혹은 작다는 것은 상대적인 개념이다. 네트워크가 얼마나 안정적이며, 또 LAN에서의 통신인지 WAN에서의 통신인지에 따라서 달라질 것이다. 또, WAN구간이라고 할 지라도 56K의 모뎀을 이용하는지 아니면 T3의 빠른 회선을 이용하는 지에 따라서 달라질 수 있다.예제를 통해서 느린 네트워크에서 window size가 큰 경우의 문제를 알아보도록 하자.[그림4]에서는 8K의 window size를 사용하고 있다. 하지만, 문제는 네트워크가 느리다는 데 있다. 속도가 느려서 혹은 트래픽이 많아서 기대되는 응답시간보다 더 오랜시간이 걸려야만 Ack신호를 받을 수 있다고 한다면, 결국엔 송신측 컴퓨터는 미처 Ack신호를 받지 못하고 "Retransmission Timer"의 시간이 만료되어 같은 데이터를 재전송해야 하는 일이 많아지게 될 것이다. 당연히 비효율적인 네트워크가 운영이 될 것이다..

[그림4]

이런 경우라면 오히려 window size를 보다 작은 size로 줄이는 것이 현명한 방법일 것이다. 위의 2가지 예제의 경우에 TCP는 "Connection Oriented protocol"이라는 가장 큰 장점이 오히려 적절하지 못한 window size로 인해서 비효율적인 Protocol이 될 수도 있다. 적절한 window size를 사용하게 된다면 TCP의 장점을 극대화한 최적의 네트워크를 구성하게 될 것이다.

TCP/IP Protocol Suite중의 하나인 TCP는 TCP Host간에 효율적인 데이터 전송을 위하여 "Window"라고 부르는 Buffer를 이용한다. Window는 TCP/IP통신을 원하는 컴퓨터(일반적으로 Host라고 부른다)가 송신, 혹은 수신할 수 있는 size를 가리켜 준다.

이러한 window라는 것을 이용하여 호스트간에 전송을 하고 받는 과정중에, 네트워크의 트래픽 혹은 호스트의 불안한 요소등 여러 가지 원인에 의하여 전송되는 데이터의 손실이 생길 수 있는 경우가 발생하게 된다. 반대로 안정적인 네트워크 상황하에서 보다 많은 데이터를 전송할 수 있음에도 TCP가 제공하는 가장 큰 특징중의 하나인 "확실한 전송"이라는 책임 때문에 오히려 비효율적인 전송을 하게 되는 경우도 있게 될 것이다. 이러한 요소들을 모두 고려하여 가장 효율적인 데이터 전송방법으로써 "Sliding Windows" 라는 기법을 사용하여 호스트 간의 통신에서 최적의 성능을 제공할 수 있게 된다.

그러면, 실제로 호스트간의 TCP/IP통신 중에서 "TCP Sliding windows"라는 기법이 무엇인지, 어떻게 동작을 하는지 차근차근 접근해 보도록 하자.

[그림1]

TCP/IP를 사용하는 모든 호스트들은 각각 2개의 window를 가지고 있다. 하나는 보내기 위한 window, 또 다른 하나는 받기 위한 Window이다.

[그림2]

호스트들은 실제 데이터를 보내기 전에 먼저 "TCP 3-way handshaking"을 통하여 수신컴퓨터의 receive window size에 자신의 send window size를 맞추게 된다. 상대방이 받을 수 있는 크기에 맞추어 전송을 하겠다는 것이다.

[그림2]의 "A"컴퓨터가 "B"컴퓨터에게 10K byte size의 데이터를 전송하려 한다고 가정을 해 보자.또, 이 컴퓨터의 "window size"는 8K이고, "TCP Segment Size"는 1K라고 가정을 한다. 사실 이것은 우리가 가장 많이 사용하는 Ethernet환경에 최적화된 size이기 때문에 NT는 기본적으로 위와 같은 windows와 segment size를 이용한다."TCP Segment Size"는 Application이 만든 데이터를 TCP가 받아서 IP에게 전달해서 통신을 하려고 할 때, IP에게 전달해 주는 데이터 패킷의 크기이다. 결과적으로는 실제 데이터를 TCP가 보다 작은 크기로 나누게 되는데, 이 때 나누게 되는 크기를 가리켜서 "TCP Segment Size"라고 부른다.예제의 경우와 같을 때, "A"컴퓨터는 "B"컴퓨터에게 데이터를 전송하기 위해서 먼저 10K크기의 데이터를 1K크기로 나누게 된다. 당연히 10개의 패킷으로 데이터가 나뉘게 될 것이다. TCP는 1K로 나눈 데이터마다 순서를 붙이게 된다. 1번부터 10번까지 번호를 붙이고, 1번부터 데이터 전송을 시작하게 된다.

TCP의 특징은 "신뢰성있는 전송"을 보장한다는 데 있다. 1번을 보내고, "A"컴퓨터는 "B"컴퓨터로부터 잘 받았다는 확인 메시지(Acknowledgement)를 받을 때까지 기다리게 된다. 마침내 Acknowledgement 메시지가 오면 "A"컴퓨터는 그 다음 순서인 2번 데이터를 전송한다. 생각하기에는 당연한 이야기고 그런대로 쓸 만한 방법이라고 생각할 수도 있겠지만 지극히 비효율적인 방법이다. "A"컴퓨터는 1번 데이터를 보내고 나서도 충분히 다음 데이터를 보낼 여유가 있지만, 응답을 받을 때까지 기다리고만 있어야 한다는 것이다. 만일 회선상의 문제가 있어서 Ack신호가 더욱 지연된다면 그 결과는 당연히 영 아닌 상태의 네트워크 통신을 지켜 봐야만 할 것이다. 이러한 문제점을 해결하기 위해서 TCP는 데이터를 낱개단위로만 처리하지는 않는다는 것이며, 그때 한꺼번에 전송하는 데이터의 크기를 바로 "Window Size"라고 부르는 것이다.

[그림4]

[그림4]처럼 호스트는 자신이 보내야할 전체 데이터 중에서 사용가능한 Window size만큼 데이터를 전송하기 시작한다. 위의 예제에서 window size는 8K이다. 1번부터 8번까지 순차적으로 계속해서 데이터를 내 보내게 되는 것이다. 그리고 나서 이 호스트는 상대방의 응답을 기다리게 된다. 단순하게 생각해도 일단은 하나씩 보내고 응답을 기다리는 것보다는 효율적인 방법일 것이다. 성공적으로 통신이 되어서 상대방으로부터 응답이 온다면 그때 "A"호스트는 나머지 남은 9번, 10번의 데이터를 전송한다.이것이 "TCP Sliding Windows"라는 기법이다. window size만큼 데이터를 전송하고, 상대방으로부터 Ack신호가 올 때까지 기다렸다가 Ack신호가 오면, window를 이동(Slide)시켜 다음 순서의 TCP데이터를 전송하는 방식을 말한다.

하지만, 역시 이것만으로는 뭔가 비효율적인 면이 여전히 남아있다. 1번부터 8번까지 데이터를 전송하고 상대방으로부터 1번부터 시작하여 자신이 보낸 데이터의 마지막인 8번까지의 데이터에 대한 Ack신호가 올 때까지 기다려야 한다면 어리석은 일이 아닐 수 없다. 우리가 생각하는 정도는 이미 TCP/IP를 개발한 개발자들도 충분히 고려했던 부분이었기에 그것에 대한 생각도 물론 했을 것이다. 그렇기 때문에 보다 효율적인 방법을 채택했다.

[그림 5]

일단 보내는 쪽의 TCP는 window size만큼 한꺼번에 데이터를 전송하고, 받는 쪽에서의 Ack신호가 오면 오는대로 바로바로 window를 Sliding시키는 방법이 그것이다. 다시 말하면 굳이 자신이 발송한 마지막 데이터에 대한 Ack신호가 오지 않더라고 일단 그 전의 데이터에 대한 Ack가 오게 되면 그만큼은 여분의 window size가 생긴 것이기 때문에 추가로 더 전송할 여유가 생겼다는 의미이다.

[그림 5]에서 보면 window가 이동한 그림을 볼 수 있다.예제의 경우는 받는 쪽에서 2번까지의 데이터를 잘 받았다는 Ack신호를 발송해 주게 되면 그때 "A"컴퓨터는 1,2번 데이터는 제대로 전송해야 할 책임을 완수했기 때문에 window를 이동시켜서 그 다음 순서의 데이터인 9번과 10번을 전송할 수가 있게 되었다. 추가로, 받는 측인 "B"컴퓨터는 패킷 하나마다 계속해서 Ack신호를 전송한다는 것은 역시 그것도 하나의 트래픽을 발생시키는 것이기에 약속을 해 두었다. 적어도 2개 이상의 연속된 패킷이 들어왔을 때 Ack신호를 전송하도록 한 것이 그것이다.

[그림6]

[그림6]에서처럼 1번과 3번 패킷이 도착을 했지만, 중간에 이빨이 빠진 채로 2번이 아직 도착을 하지 않았다라고 가정을 해 보자. 그렇게 되면, 받는 측의 TCP는 2개이상의 연속된 패킷이 도착하면 전송을 하자는 약속을 해 두었기에 마냥 기다려야 할 것이다.

그래서 만일의 경우를 대비하여 한가지 해결책을 강구해 두었다. 받는 측의 컴퓨터는 패킷이 도착하였을 때, "Delay Acknowledgement Timer"라고 부르는 Timer를 설치하게 된다. 이 Timer의 시간이 만료될 때까지 2번 패킷이 도착하지 않는다면, 받은 1번 패킷에 대한 Ack신호만이라도 전송을 해 주는 것이 보다 효율적이기 때문이다.

[그림7]에서 보면, 받는 측의 TCP는 1번 패킷에 설치해 둔 Timer가 만료되었고, Ack신호를 전송하고 있다.

[그림 7]

송신컴퓨터는 이렇게 수신컴퓨터의 Ack신호를 받고, window를 sliding시켜서 다음 신호를 전송하는 방식을 쓰고 있지만, 또 한가지 문제가 여전히 남아 있다. 만일 무슨 이유에선지 Ack신호가 전혀 오지 않는 상황이라면 어떻게 해야 할까? 이러한 문제를 해결하기 위해서 송신컴퓨터의 TCP는 자신이 보낼 수 있는 Window Size만큼 데이터를 전송하고 자신이 보낸 데이터에 대해서 각 Segment마다 "Retransmission Timer"라고 불리우는 timer를 설치 해 둔다. 만일 이 timer의 시간이 만료될 때까지 Ack신호가 도착하지 않으면 재전송을 하기 위한 배려이다.

[그림 8]  

결국, TCP는 window size를 이용해서 한꺼번에 일정량의 데이터를 전송하며, 보다 효율을 기하기 위해서 이러한 window를 Sliding시키는 방식을 이용하여 계속적인 데이터 전송을 할 수 있도록 하고 있다. 여기에서 생길 수 있는 문제점들을 "Delay Acknowledgement Timer"와 "Retransmission Timer"를 이용해서 대비책을 마련해 두고 있는 것이다.

이상 TCP Sliding windows에 대해서 정리해 보았다. 다음엔 이어서 TCP Window Size가 네트워크에 미치는 Performance에 대해서 알아보도록 하자.  

앞의 'IP Address의 이해'장에서 IP Address의 개요에 대한 설명을 한 바 있다. IP Address는 네트워크ID와 호스트ID로 나누어진 다는 것을 알았다. 저번 예제에서 동과 우체국으로 나뉘어졌던 것을 대신해서 이번에는 실제로 라우터와 컴퓨터를 놓고, IP Address를 할당해 보았다. <그림2-15>를 보면서 이야기한다. 예제는 131.107.0.0 과 1331.108.0.0 이라는 두 개의 네트워크로 구성된 환경이다. 이들 네트워크에는 A,B,C라는 세대의 컴퓨터가 있고 각각 적절한 IP Address, Subnet Mask, Default Gateway가 할당되어 있다.  

<그림2-15. 2개의 네트워크 ID>

 

예제에서 131.107.0.0네트워크에 있는 "B"는 "C"와 통신을 하고자 한다. 통신의 종류는 너무나도 다양하다. 간단하게 B에서 "ping 131.108.0.2"라는 명령을 날릴 경우도 있을 것이고, C컴퓨터가 서비스하는 웹서비스에 B가 웹 브라우저를 띄우고 "http://131.108.0.2"를 입력한 경우도 있을 수 있다. 어떠한 종류의 작업이건 결국은 IP Address를 이용한 통신을 하는 것이기에 B는 C의 IP Address를 목적지로 하는 메시지를 날려 보내야만 한다.

 

이 단원의 처음에 "같은 동에 속한 사람들끼리는 직접 편지를 교환하고, 다른 동으로 편지를 보내기 위해서는 반드시 우체국을 이용해야 한다."라는 가정을 한 바 있다. 바꿔 말하면 컴퓨터는 TCP/IP통신을 할 때 자신과 같은 네트워크에 속한 컴퓨터와는 직접 통신을 하고, 다른 네트워크에 속한 컴퓨터와 통신을 할 때는 '라우터"를 이용해야 한다는 것을 말한다.

 

이러한 이유로 B가 C에게 메시지를 보내고자 할 때 첫 번째 해야 할 일은 "C"라는 컴퓨터가 자신과 같은 네트워크에 있는지(로컬인지), 아니면 다른 네트워크에 있는지(원격지인지)를 결정해야 한다는 것이다. 이것을 구분하는 컴퓨터는 IP Address중에서 Network ID부분을 가려낸 다음 Network ID를 서로 비교해 보게 된다. 자신의 네트워크 ID와 상대방 컴퓨터의 네트워크ID가 같다면 당연히 같은 네트워크 임을 의미하고, 네트워크ID가 서로 다르다면 서로 다른 네트워크에 존재한다는 것을 나타내기 때문이다.

 

문제는 IP Address중에서 도대체 어디까지가 네트워크ID가 차지하는 부분인지를 알 방법이 필요하다는 것이다. 조금 더 자세히 말한다면 IP Address로 사용되는 32비트의 숫자중에서 몇비트가 네트워크ID가 사용하는 부분인지를 알아내야 할 필요성이 있는 것이다. 그것을 가리켜주는 것이 바로 Subnet Mask의 역할이다.

 

2-2-1. Subnet Mask

 

Subnet Mask는 IP Address중에서 네트워크ID 부분을 가려내는 역할을 담당한다. Subnet Mask를 잘못 입력하는 것은 통신불가능이라는 문제점을 야기시킬 수 있다. 서브넷 마스크가 IP Address중에서 네트워크ID를 가려내는 일을 하므로 서브넷 마스크가 잘못 할당되어 있으면 IP Address중에서 네트워크ID가 틀리게 가려질 수 있다. 결국은 같은 네트워크에 존재하는 호스트와 서로 다른 네트워크ID를 사용하게 되는 등의 문제가 생길수 있는 것이다. 서브넷 마스크를 제대로 사용하는 것은 중요한 일이다.

 

좀더 구체적으로 Subnet Mask를 통해서 어떻게 상대방 컴퓨터가 로컬인지 원격지인지를 가려내는지를 알아보겠다. 아래의 <그림2-16>에서는 B의 네트워크ID와 C의 네트워크 ID를 계산하는 방법을 그림으로 표현하였다. B컴퓨터는 통신을 하고자 할 때 가장 먼저 자신의 서브넷 마스크를 이용해서 자신의 IP Address와 상대방의 IP Address로부터 Network ID를 계산한다.

<그림2-16. 목적지 컴퓨터가 로컬인지 원격인지 결정하는 방법>

 

<그림2-16>의 "(1)B의 네트워크ID계산"을 보면, 131.107.3.100을 이진수로 전환했다. 자신의 서브넷 마스크인 255.255.0.0역시 이진수로 전환을 한 다음 And연산을 이용해서 두 수(bit)를 결합시켰다. Bit 에 대한 And연산은 두 수가 1일 때만 1이라는 결과를 나타낸다. (And연산 -> 1=참, 0=거짓, 둘다 참일 때만 참).

 

값을 계산해 보면 세 번째의 그림인 Network ID결과값을 얻을 수 있다. 이것을 가만히 살펴보면 네트워크 ID결과값중에서 두 개의 옥텟은 IP Address의 두 개의 옥텟과 일치함을 알 수 있다. 서브넷 마스크의 두 개의 옥텟이 11111111.11111111 이므로 당연히 IP Address 쪽의 수자를 따라가게 된 것이다.  세, 네 번째 옥텟은 00000000.00000000 이라는 결과를 보여주는데, 서브넷 마스크의 세,네 번째 옥텟이 00000000.00000000 이므로 (두 수중 둘 다 1일 때만 1, 결국 한쪽이라도 0이면 0이 나온다는 Bit And연산에 따라) 결과값 역시 00000000.00000000 이 나온 것이다. 결국 나온 결과값은 이것을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID를 얻어낼 수 있다.

 

10000011.01101011.00000000.00000000 이라는 결과값을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID가 계산된다. 당연한거 아닌가 싶지만 우리는 전체적인 그림을 보니까 당연해 보이지만 호스트 입장에서는 IP Address만 가지고 목적지 컴퓨터가 도대체 어느 위치에 존재하는지 심지어는 자신이 어느 위치에 존재하는지도 알 턱이 없다. 이들이 알고 있는 것이라고는 단지 IP Address, Subnet Mask 등의 숫자 몇 개가 고작인 것이다.

 

같은 방법으로 (2)에서는 C의 네트워크ID를 계산했다. 그 다음에 할 일은 B는 자신의 네트워크ID와 상대방인 C의 네트워크ID를 비교하는 일이다. 이 결과값이 일치하다면 이들 둘은 같은 네트워크ID를 사용하고 있다는 것을(로컬) 의미하며, 다르다면 다른 네트워크ID를 사용하고 있다는(원격지) 것을 의미한다.

 

결과값이 같다면 직접 로컬에서 통신을 시도할 것이지만 결과가 다르다면 로컬의 라우터의 도움을 받아야 C와 통신을 할 수가 있게 된다. 예제에서는 131.107.0.0과 131.108.0.0이라는 서로 다른 결과를 보여준다. 서로 다른 물리적인 네트워크에 있다는 결과가 나왔다. 제대로 계산이 나왔다.

 

Subnet Mask가 잘못 입력된다면 통신이 실패한다는 말을 했는데 한가지 상황을 가정해 보겠다.

 

<그림2-15>에서 A와 B는 같은 네트워크에 있으며, 같은 네트워크ID인 131.107.0.0을 사용하고 있다. 만일 B컴퓨터의 Subnet Mask를 255.255.0.0이 아닌 255.255.255.0을 할당했다고 가정을 하고 결과를 살펴보겠다. B컴퓨터는 일단 A가 로컬에 있는지 원격지에 있는지를 알아내고자 시도를 할 것이고 자신의 서브넷 마스크인 255.255.255.0을 통해서 자신의 IP와 상대방의 IP중에서 네트워크 ID를 계산해 낼 것이다. <그림2-16>을 참고로 해서 결과값을 계산해 보면, B는 131.107.3.0이라는 결과가 나오고, A는 131.107.4.0이라는 결과가 나온다.

 

이것은 B와 A가 서로 다른 네트워크에 있음을 보여준다. 결국 실제로는 물리적으로 같은 네트워크에 있지만 서로 다른 네트워크ID를 가졌으므로 B는 직접 로컬통신을 시도하지 않고 라우터에게 패킷전송을 요청하게 된다. 이 패킷은 131.107.4.0 네트워크를 찾아서 외부로 나가게 되고, 결국 통신은 실패하게 된다. 이렇듯 잘못된 Subnet Mask를 부여했을 때에는 B는 A와 통신하는 것이 불가능하다. 같은 네트워크에 존재하면서도 네트워크ID가 다르다는 결과가 나왔기 때문이다.

 

또 한가지 경우, 만일 B의 서브넷 마스크가 255.0.0.0이 할당되어 있다면 어떻게 될까? 결과부터 말한다면 이번에는 같은 네트워크의 A와는 통신할 수 있지만 C와는 통신하는 것이 불가능하다. 차근차근 결과를 계산해보면 답이 나온다. 255.0.0.0 서브넷 마스크를 이용해서 B와 C의 IP Address에서 Network ID를 각각 계산해 보면 같은 결과인 131.0.0.0이 나온다. 물리적으로는 다른 네트워크에 위치해 있으면서 서로 같은 네트워크ID를 사용하게 되면 이들 둘은 통신을 할 수가 없게 되는 것이다.

이렇듯 Subnet Mask도 IP Address못지 않은 중요한 역할을 담당하고 있는데 이러한 Subnet Mask는 어떻게 할당되는 것일까? 이것도 기본적인 원칙이 있다.  

서브넷 마스크 결정방법 IP Address중 네트워크ID 부분은 1로 기록하고, 호스트ID  부분은 0으로 기록한다.

앞에서 각 클래스별로 Network ID가 사용하는 옥텟을 이야기한 바 있다. 거기에 따른 서브넷 마스크를 정리하면 <그림2-19>과 같다.

<그림2-19. Default Subnet Mask>

 

위와 같이 클래스별로 고정된 Subnet Mask를 할당하게 되는데 이것을 가리켜 "Default Subnet Mask"라고 부른다. 특별히 Default라는 표현을 썼다는 것은 뭔가 냄새를 풍긴다. 그렇지 않을 수도 있다는 것을 의미하는데, 각각 8비트, 16비트, 24비트 등으로 고정된 길이만큼 네트워크ID가 사용되는 것이 아닌, 클래스개념을 무시한 IP Address관리방법이 제공되기 때문이다. 이것을 CIDR(Classless Inter Domain Routing)이라고 한다. IP Address를 효율적으로 관리하기 위한 필수적인 개념인만큼 정리를 해 보도록 하겠다. 다음 장에서 CIDR, VLSM등에 대해서 설명한다.

 

2-2-2. Default Gateway

 

호스트가 TCP/IP통신을 할 때 가장 먼저 목적지 호스트가 자신과 같은 로컬에 있는지 원격지에 있는지를 판단한다고 했다. 이때 원격지에 있는 결과가 나오면 컴퓨터는 Default Gateway를 이용해서 통신을 하게 된다. 결국 Default Gateway를 정리하면 "자신의 네트워크에 있는 라우터의 로컬 인터페이스의 IP Address"라고 할 수 있다.

 

라우터도 역시 자신의 네트워크에 있는 하나의 호스트처럼 생각하면 된다. 하는일이 다를 뿐이지 통신에 있어서는 차이가 없다. 만일 목적지 호스트가 로컬에 있다면? 그때는 Default Gateway는 쓰임새가 없다. Default Gateway가 없어도 로컬네트워크와의 통신에는 아무런 문제가 없음을 말하는 것이다.

 

<그림2-20. 로컬 컴퓨터의 라우팅 테이블>

 

위의 그림은 Windows환경의 OS에서 라우팅 테이블을 확인해 보았다. Ipconfig 를 통해서 Default Gateway가 192.168.5.1인 것을 알 수 있다. 그 다음에 Route print 명령을 실행하니 라우팅 테이블을 보여준다. 하이라이트된 부분을 보니 다음과 같다.

Network Destination            Netmask              Gateway              Interface               Metric 0.0.0.0                    0.0.0.0              192.168.5.1           192.168.5.5                  1

0.0.0.0 이 Default Gateway를 나타내는 테이블이다. 만일 이 호스트에서 “Ping 192.168.6.200”이라고 명령을 실행하였다면 192.168.6.0네트워크는 라우팅 테이블에 명시되어 있지 않은 네트워크이기 때문에 어디로 패킷을 내 보내야 할지 모르게 된다.

이때 이 호스트는 0.0.0.0 으로 시작하는 이 테이블을 이용해서 통신을 시도하게 된다. 네트워크로의 통신은 이 테이블 항목을 사용해서 통신을 시도한다. 이것을 해석해 보면, 192.168.5.5로 셋팅된 네트워크 어댑터 카드를 통해서 192.168.5.1에게 패킷을 내 보내라는 것을 의미한다. 결국, 네트워크 경로에 명시되지 않은 모든 네트워크를 목적지로 하는 패킷은 192.168.5.1에게 보내서 통신을 처리하라는 것을 알 수 있다. 이것이 기본게이트웨이 이다.

간혹 TCP/IP 등록정보에서 볼때는 기본게이트웨이가 잘 셋팅되어 있지만 라우팅테이블이 없어지는 경우가 발생한다. 이럴 경우는 당연히 이 호스트는 외부 인터넷 환경으로는 접근이 되지 않게 되는데 그때는 문제해결이 쉽지 않다. 문제해결을 위해 TCP/IP등록정보를 확인해 봐도 아무런 문제가 없기 때문이다. 그때 route print 명령을 이용하여 0.0.0.0 경로가 잘 살아있는지를 확인해 볼 필요가 있다. 만일 없다면 기본게이트웨이가 설정이 되어 있지만 없는것과 마찬가지이다. 그럴 때는 route add 명령을 이용해서 직접 추가해 주거나, TCP/IP등록정보를 열고 기본게이트웨이를 지웠다가 다시 생성해 주면 해결된다. 라우팅 테이블에 0.0.0.0 경로가 살아났는지 확인하는 것은 당연한 일이다.

<그림2-7>에서의 호스트는 IP Address로써 "192.168.5.3"이라는 숫자를 사용하고 있다. 이 IP Address를 살펴보면 3자리 숫자가 4개가 모여있고, 사이사이에는 dot로써 구분을 해 주고 있다. 이 3자리 숫자는 우리에게 익숙한 10진법으로 표기가 되어 있는 것을 알 수 있다.

<그림2-7. TCP/IP 등록정보>

 

그렇다면 아래의 그림을 보자.

 

<그림2-8. IP Address 입력 오류 메시지>

 

TCP/IP 구성을 수동으로 하다 보면 가끔 <그림2-8>와 같은 메시지를 받는 경우가 있다. <그림2-8>의 메시지를 보면 256이라는 숫자를 입력하려고 시도했을 때 "256의 항목이 올바르지 않다. 0~255사이의 값을 지정하라"는 메시지를 보여주고 있다. 이상한 생각이 든다. 10진수라면 3자리를 가지고 만들 수 있는 가장큰 수는 999 여야 하는데, 256을 넣었더니 입력이 되지 않고 0부터 255사이의 값을 지정하라고 한다. 그렇다. 10진수로 표기를 하고 있지만 내부적으로는 10진수가 아닌 것이다. 그렇다면 어떻게 구성이 되어 있을까?

 

IP Address는 디자인될 때 32개의 비트를 사용하여 IP Address를 만들어졌다. 다시 말하면 0 아니면 1인 값이 32개가 나란히 늘어서 있는 것이 IP Address를 구성하고 있다는 것을 의미한다. 아래의 <그림2-9>를 보면서 설명한다.

<그림2-9. IP Address 표기>

 

<그림2-9>에서는 192.168.5.2 라는 IP Address를 예제로 보여주고 있다. IP Address는 십진수도 아니고 세자리 숫자 4개가 3개의 dot(.)로 구분된 것도 아니다. 단지 0 아니면 1인 비트가 32자리가 쓰여 있을 뿐인 것이다. 32bit이니 결국 4Byte이다. 현재 우리가 사용하는 IP Address의 버전은 "4(Four)"이고 이 버전 4는 32bit 즉 4Byte체계의 IP Address를 사용하고 있다. 이러한 32bit숫자를 그대로 시스템의 IP Address로 사용한다면 우리가 사용하기는 꽤 어려울 것이다. 0아니면 1인 숫자가 32자리가 배열이 되어 있으면 사용하기가 어려울 수 밖에 없다. 그런 이유로 보다 편한 표기법을 채택하고 있다. 일단 8bit씩 나눠서 구분을 한다. 8bit면 1Byte이니 구분하기가 한결 용이해진다. 이렇게 나뉜 하나하나의 단위를 "8"을 나타내는 "옥텟 (Octet)"라고 부른다. 32bit를 8bit씩 나누니 4개의 8bit. 즉 4개의 octet가 생겼다. 이들 octet와 octet를 구분하기 쉽게 하기 위해 dot(.)를 구분자로 사용하였다. 마지막으로 각각의 옥텟 단위별로 2진수를 10진수로 변환하여 놓은 것이 바로 우리가 사용하고 있는 IP Address이다.

 

아래의 <그림2-10>을 보겠다. 3단계로 나눠서 보면, 맨 위의 그림은 32개의 자리수를 가진 빈 상자가 있다. 여기에 0, 1 둘중의 한가지 숫자를 채울 수가 있을 것이다. 첫 번째의 옥텟만 가지고 계산을 해 보았다. 8bit 자리에 넣을 수 있는 가장 큰 숫자는 여덟 개의 비트 전체가 "1"로 만들어지는 숫자가 된다. "11111111"을 십진수로 계산하면 "255"라는 결과를 얻을 수 있다. 이렇게 되면 위에서의 의문이 풀린다. 왜 IP Address로 할당할 수 있는 최대숫자가 999가 아닌 255가 되는지를 알 수 있을 것이다. 그렇게 전체 옥텟을 채워보면 255.255.255.255가 나온다. 이것이 IP Address로 사용될 수 있는 가장 큰 주소이다.

<그림2-10. 현 IP Address체계에서의 가장 큰 수>

 

위에서 우리는 IP Address가 32개의 bit로 이루어진 값이라는 사실을 알 게 되었다. 이제 그러면 이러한 IP Address가 어떠한 체계로 관리가 되는지 알아보도록 하자. 현재 IP Address는 IANA(Internet Assigned Numbers Authority)라는 기관에서 관리되고 있다. IANA는 전체 IP Address를 관리하며 ISP(Internet Service Provider)들에게 IP Address를 발급하고, 일반 사용자들은 그러한 ISP로부터 IP를 할당받아서 호스트에게 할당하고 인터넷에 액세스하게 되는 것이다. 당연히 IP Address가 무작위로 할당되지는 않는다. 이 IP Address는 Class 라는 특별한 개념에 근거하여 관리되고 있다. 자세히 알아보자.

네트워크 통신을 위해TCP/IP를 사용하는 모든 컴퓨터들은 IP Address를 가지고 있다. 이 IP Address는 당신의 컴퓨터를 네트워크에서 유일하게 구분해 줄 수 있는 고유번호를 의미한다. 굳이 TCP/IP를 전혀 모르더라도 집에서 전화, ADSL, 케이블모뎀 등을 통해서 인터넷에 접근한다거나,  친구에게 E-mail을 전송하고, PC방에서 어디 있는지 모르는 누군가와 채팅을 하거나, 네트워크 게임을 즐기고 있다면 이미 당신은 TCP/IP를 사용하고 있고 당신의 컴퓨터는 IP Address를 가지고 있어야만 한다. 네트워크 관리자가 이러한 IP Address의 체계에 대해서 잘 이해하고 관리할 수 있어야 한다는 것은 필수적이다.

 

이번 장에서는 TCP/IP를 구성하고 있는 IP Address, Subnet Mask, Default Gateway등의 역할들에 대해서 살펴보고, IP Address에 대해서 구체적으로 살펴보도록 한다.

 

컴퓨터에서 TCP/IP등록정보에 접근해 보면 아래의 <그림2-1> 혹은 <그림2-2>와 같은 두가지 유형의 설정을 확인할 수 있다.

<그림2-1.수동(정적) IP구성>

 

<그림2-2.자동(동적) IP구성>

 

분명히 위의 두 그림은 달라 보이지만, <그림2-2>의 경우도 보조프로그램의 명령프롬프트를 열고 "ipconfig"를 입력해 보면 TCP/IP의 구성을 확인할 수 있다.

<그림2-3. IPCONFIG Utility를 이용한 TCP/IP 구성 확인>

 

이렇듯 TCP/IP를 사용하기 위해서는 IP Address, Subnet Mask, Default Gateway등의 정보들이 구성이 되어 있어야 하는데 네트워크 관리자라면 당연히 이들의 역할들에 대한 명확한 이해를 해야 할 것이다. 어려운 수학은 아니지만 아무래도 숫자만 나오면 머리가 아파지기 시작하는 우리들로서는 차근차근 접근해 볼 필요가 있다. 먼저 IP Address에 대한 설명을 하도록 한다.

 

IP Address는 Network ID와 Host ID로 구성되어 있다. 갑자기 무슨 소리인가 싶겠지만 이것은 IP Address를 공부하는데 아주 중요한 개념이다.

 

IP Address = Network ID + Host ID

 

다른 통신도 마찬가지이긴 하지만 특히 TCP/IP통신은 우리들의 생활과도 아주 밀접한 연관성이 있다. 우리가 현실에서 외부 누군가와 편지를 주고 받는 과정이 TCP/IP통신과정과 아주 유사하다. 우리가 편지를 주고 받을 때의 상황을 상기하면서 이해를 하면 쉽다.

 

대한민국의 가구수가 얼마나 될까? 뭐 중요한 건 아니다. 얼마 전 뉴스를 보니 90년대 이후 빠르게 핵가족화가 진행 중이라는데, 남한의 가구수가 1,600만가구를 넘었다고 한다. 각 가구들을 구별하기 위해서 우리는 "번지"라는 개념을 사용하는데 그 번지가1번지부터 1,600만 번지까지 존재하는 것은 아니다. 행정구역이라는 개념으로 시, 도, 동... 등을 구분하여 사용하며 최종적으로 번지라는 단위로써 각각의 가구들을 구분해 주고 있다.

 

만일 이러한 세부적인 단위를 사용하지 않고 전체가구가 개별적인 번지수 하나만으로 주소를 이루고 있다면 어떻게 될까? 물론 이 경우도 편지를 주고 받는 데는 문제가 없다. 1번지에 사는 사람은 100번지에 사는 사람에게 편지를 보내기 위해 편지 겉봉에 받을 사람 주소를 쓰고 우체국에 편지를 부칠 것이며, 우체국에서는 100번지인 주소를 찾아서 편지를 배달해 줄 것이다. 이때 우체국에서는 큰 노력이 필요하다. 대한민국 전체를 오로지 "번지"로만 나누었기에 100번지가 어디쯤 있는지 지도책을 펴 놓고 찾을 것이며 직접 그곳까지 배달을 해야 할 것이다. 우체국 입장에서는 자신이 배달해야 할 경로가 총 1600만 가지의 경우의 수가 있는 것이다.

 

조금 더 편한 방법은 무엇일까? 당연히 그것은 그룹으로 나누는 방법에서 찾을 수 있다. 여러개의 번지를 묶어서 그룹으로 나누면 그만큼 경로의 수가 줄어들기 때문에 배달업무에 효율성을 기할 수 있게 될 것이다. 개별적인 번지수까지 신경 쓸 이유는 없어지고 다만 그 주소가 속해있는 그룹에게 편지를 배달해 주면 되기 때문이다. Network ID도 바로 그러한 것이다.

 

전체 IP Address를 따로 따로 관리하기 보다는 Network ID라는 이름으로 그룹을 만들어서 Network ID 단위로 IP Address를 관리하면 그만큼 효율적으로 IP Address를 관리하고 무엇보다도 보다 원활한 편지배달작업에 해당하는 라우팅(Routing)이 가능해질 수 있기 때문이다.

 

Network ID에 관련한 중요한 개념 한가지를 챙겨보도록 하겠다. 그림을 예로 들어 설명을 한다. 우리가 실생활에서 편지를 보낼 때의 절차를 통해서 정리를 할 것인데, 먼저 2가지를 가정한다.

 

(1) 편지의 주소는 "동"과 "번지"만으로 이루어져 있다.

(2) 같은 동에 속한 사람들끼리는 직접 편지를 교환하고, 다른 동으로 편지를 보내기 위해서는 반드시 우체국을 이용해야 한다.

 

예제에서는 "삼성동"과 "대치동"사이에 어떻게 편지가 교환이 되는지에 대한 그림을 보여준다. 예제에서 "동"에 해당하는 것이 "Network ID"이고, "번지"에 해당하는 것이 "Host ID"가 된다. 우체국은 다른 네트워크 패킷을 라우팅해 주는 "라우터(Router)"에 해당한다.

<그림2-4. Network ID의 이해>

 

위의 <그림2-4>는 "삼성동 100번지"에 사는 사람이 "대치동 100번지"로 편지를 발송하는 상황이다.

 

"삼성동 100번지"에서는 편지(data)를 쓴 다음 겉봉투(packet)에 넣고 수신인 란에는 "대치동 100번지"라고 기록을 했다. 그 다음 편지를 발송하기 위해 첫 번째로 하는 일은 수신처가 자신과 같은 "동(Network ID)"에 있는지 다른"동"에 있는지를 파악하는 일이다(①). 같은 "동"이라면 직접 편지를 배달할 것이고, 다른 "동"이라면 "자신의 관할 우체국(로컬 라우터)"에게 편지배달을 요청해야 하기 때문이다. 

 

예제에서 수신처가 자신과는 다른 "대치동"관할에 있으므로 두 번째로 할 일은 "삼성동 우체국"으로 편지를 보내러 가야 한다(②).

 

삼성동우체국에서는 발신자의 주소는 중요하게 취급되지 않는다. 중요한 정보는 수신자의 주소인 "대치동 100번지"가 되는데, 그 중에서도 "대치동"이라는 "동(Network ID)"정보가 필요할 뿐이다. 100번지라는 "번지(Host ID)"수는 의미가 없다. 자신이 직접 최종목적지까지 편지를 배달할 것은 아니기 때문이다. 그래서 삼성동우체국에서는 "대치동"이라는 목적지를 확인한 다음 그 목적지로 가기 위한 경로(Routing Table)를 확인하여 대치동 우체국으로 편지를 발송한다. 이때 발송방법은 여러 가지가 있을 것이다. 비행기, 자동차, 선박 등을 이용해서 상대방 우체국까지 편지를 발송해주게 된다(③).

 

대치동 우체국에서 편지를 받고서 자신의 관할영역임을 확인한 다음, 편지겉봉의 수신처 주소중 "번지"를 확인하게 된다. "100번지"라는 번지를 근거로 "대치동 100번지"의 우체통에 편지를 배달해 줄 수가 있게 된다.(④) 이렇듯 다른 "동(Network ID)"으로 편지를 보내기 위해서는 반드시 자신의 관할 우체국(Local Router)의 도움을 받아야 하는 것을 확인할 수 있다.

 

 <그림2-5. Network ID의 이해 2>

 

<그림2-5>는 같은 "동"에 있는 "삼성동 200번지"로 편지를 배달하고 있다. 과정은 앞의 예제와 다를바가 없다. 다만 편지를 작성한 다음 가장 먼저 수신처가 자신과 같은 동에 있는지 다른 동에 있는지를 판단해서 같은 동에 있다는 판단을 하였기에 우체국에 편지를 부치지 않고 직접 편지를 배달하고 있다.

 

당연한 것을 왜 설명하는지 의아해 하는 독자가 있을 것이다. 하지만 여기서 중요한 원칙 하나가 나온다. 물리적으로 같은 "동"에 위치한 집들은 반드시 같은 "동"의 주소를 할당받아야 하고 다른 "동"에 위치한 집들은 반드시 다른 "동"의 주소를 할당받아야 한다는 것이다. 다시 정리하면 같은 네트워크에 존재하는 컴퓨터들은 반드시 같은 "Network ID"를 사용해야 하고, 다른 네트워크에 존재하는 컴퓨터는 반드시 다른 "Network ID"를 사용해야 한다는 것을 의미한다. 아래의 <그림2-6>을 통해서 설명하도록 한다.

 

 <그림2-6. Network ID의 이해 3>

 

<그림2-6>의 상황은 "삼성동200번지"에 살던 <B>라는 사람이 "대치동"으로 이사를 했다. 당연히 대치동에서 새로운 번지를 할당 받아야 하겠지만 고집스럽게도 <B>는 물리적으로는 "대치동"관할에 있으면서 주소는 예전 그대로 "삼성동200번지"를 사용하고 있다고 가정해 보겠다. 결과적으로는 <B>는 어느 누구와도 편지를 주고 받을 수 없다. 왜 그럴지 살펴보겠다.

 

먼저 "삼성동100번지"에 있는 <A>와의 통신을 고려해 보면 <A>는 <B>에게 편지를 보내기 위해 편지 겉봉에 "삼성동200번지"라는 주소를 기록할 것이다. 같은 "동(네트워크ID)"에 있는 사람이기에 우체국에 편지를 부치는 것이 아니라 직접 편지를 배달하려고 시도를 하겠지만 실제로는 다른 "동"으로 이사를 가 버린 <B>에게는 편지가 도착될 수가 없게 된다. 이번엔물리적으로 같은 "동"에 위치한 "대치동100번지"의 <C>와 <B>의 통신을 고려해 보겠다. <C>는 역시 <B>에게 편지를 부치기 위해 편지겉봉에 수신처주소에는 "삼성동200번지"를 사용할 것이다. 자신과 다른 "동"에 위치해 있다는 것을 알 게 되고 직접 발송하는 것이 아니라 "대치동 우체국"에 발송을 요청하게 될 것이다. 대치동우체국에서는 목적지가 "삼성동"으로 되어 있으므로 "삼성동우체국"으로 편지를 보낼 것이고, 우체국에서는 번지를 확인해서 "200번지"를 찾게 되지만 실제로는 이사를 해 버린 <B>를 찾을 수가 없게 된다. 역시 편지발송이 실패하게 된다.

 

위에서 예제에 따르면 "같은 동에 사는 사람들은 주소역시 같은 동의 주소를 가져야 하며, 다른 동에 사는 사람과는 다른 동의 주소를 사용하여야 한다"라는 결과가 나온다. TCP/IP통신에 맞춰서 얘기해 보면 다음과 같다.

 

"같은 물리적인 네트워크에 존재하는 컴퓨터들은 반드시 같은 "Network ID"를 사용해야 하고, 다른 네트워크에 존재하는 컴퓨터는 반드시 다른 "Network ID"를 사용해야 한다".

 

이것은 TCP/IP를 사용하는 컴퓨터들간의 통신을 위해서 반드시 지켜져야 하는 원칙이다. 예를 들면 192.168.5.0이라는 네트워크 ID를 할당한 세그먼트에 A와 B가 있다면 이들 둘의 통신을 위해서는 A와 B는 동일하게 192.168.5.0 네트워크 ID를 사용하는 Host ID가 할당되어야만 한다. A에게 192.168.5.1을 할당하고, B에게 192.168.5.20을 할당했다면 둘은 통신이 되겠지만, 만일 B에게 192.168.6.20을 할당했다면 둘은 통신을 할 수가 없게 된다. 물리적으로 같은 네트워크에 서로 다른 네트워크ID가 할당되었기 때문이다. 192.168.5.1과 192.168.6.20이 어디가 어떻게 다른 것인가? 이제부터 그런 내용을 배우게 된다.

 

잘 아는 사람들에게는 불필요한 정도로 부연설명을 했다. 하지만 이 개념은 IP Addressing, TCP/IP통신의 흐름을 이해라는데 필요한 너무나 중요한 개념이다. 꼭 이해하시고 넘어갈 것은 당부한다. 이제 본격적으로 IP Address에 대해서 살펴보도록 하겠다.

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 계층 하위 계층에서의 변화만으로 전송이 가능하다는 것이다.

네트워크 어댑터 카드와 네트워크 어댑터 카드간의 통신

이 계층은 실제 네트워크에서 데이터를 전송하는 케이블에 프레임(frame)이라고 불리우는 데이터를 실어 보내고, 반대로 데이터를 받는 역할을 담당한다. 상위의 계층(IP)로부터 패킷이 도착하면 그 패킷에 서두(Preamble)와 CRC(Cyclic Redundancy Check)를 추가한다. 물리적인 네트워크에서 이것을 들여다 보고 올바른 컴퓨터에게 패킷을 전달할 수 있다.

Preamble은 프레임의 시작을 정의하는 바이트의 일련번호이다. CRC는 프레임이 손상되지 않았음을 검증하는 수학적 계산값을 말한다. 송신측의 호스트는 실제 프레임의 크기를 계산하여 CRC에 그 값을 첨부한다. 수신측에서는 실제 프레임을 근거로 CRC를 다시 계산하게 되고, 결과값과 실제 도착한 프레임의 CRC와 일치하면 정상적인 프레임으로 판단하여 올바른 패킷으로 처리하지만 결과값이 다르다면 버려지게 된다. 패킷이 손상이 생겼다는 것을 의미하기 때문에 계속 처리를 해 봐야 결국엔 쓰지 못하는 데이터가 되기 때문이다. 네트워크상에서 에러를 체크하기 위한 첫 번째 배려이다.

<그림1-14. 네트워크 모니터로 캡처한 그림 – Physical Layer>

그림의 중간 패널의 하이라이트된 부분을 살펴보면 다음과 같다.

              ETHERNET : Destination address : 0000E878DE90

이 부분이 Physical Layer에 해당하는 부분이다. 여기서 중요한 정보를 한 가지 알 수 있다. 네트워크 통신에서 사용되는 패킷이라는 하는 녀석들은 반드시 가져야 할 요건이 있다. “이 패킷은 어디에서 어디로 가는 것이다”라는 것을 알려주는 주소(Address)가 바로 그것이다.

Physical Layer는 네트워크 어댑터 카드와 네트워크 어댑터 카드간의 물리적인 통신이 진행되는 계층인데 이 때 사용하는 주소는 무엇일까? 당연히 이 주소는 물리적인 통신을 담당하는 네트워크 어댑터 카드들이 인식할 수 있는 주소를 사용해야 할 것이다. 바로 Physical Address를 의미한다. 이것을 가리켜서 MAC(Media Access Control) Address 또는 Hardware Address 라고 부른다. 물리적인 주소인 MAC Address와는 상대적으로 IP Address는 사용자에 의해 임의로 할당되는 논리적인 주소이다.

네트워크 어댑터 카드들은 IP Address 라는 것은 알지 못한다. 계층모델로 이야기하자면 자신들의 계층이 아니기 때문이다. 너무 단순한가? 하지만 각각의 계층에서는 자신들이 맡은일만 최선을 다해서 처리하면 되는 것이 네트워크 통신이라고 말한 바 있다.

위의 예제에서 0000E878DE90 부분이 바로 물리적인 통신에서 사용되는 MAC Address이다. 익숙하지 않은 숫자일텐데, 이것은 보는 대로12자리 숫자이다. 2자리씩 묶어서 1바이트를 차지하고 있다. 결국 6바이트짜리 숫자라는 것을 알 수 있다. 이 주소중에서 앞의 6자리, 즉 처음 3바이트는 벤더(3com, Intel, Compaq등의 제조회사)에게 할당된 주소체계이고, 뒤의 6자리 즉 뒤의 3바이트는 벤더에서 생산하는 NIC마다 할당하는 일련번호로 구성이 된다. 예전에는 Xerox 라는 회사에서 이것을 관리했다고 하지만, 지금은 IEEE 라는 협회에서 관리를 하고 있다. 이렇듯 물리적인 주소가 원칙을 가지고 관리되고 있기 때문에 “네트워크에 존재하는 모든 NIC는 저마다의 고유한 물리적인 주소인 MAC Address를 가지고 있다”라고 이해하면 되겠다.

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

Network Layer ; 계층은 패킷의 주소를 결정하고, 라우팅을 하는 과정

- IP (Internet Protocol) : 패킷 전송 담당자

IP역시 UDP처럼 "연결없는 전송서비스 (Connectionless delivery service)"를 제공한다. "연결없는 전송서비스"라는 것은 패킷을 전달하기 전에 대상 호스트와 아무런 연결도 필요하지 않다는 것을 의미한다. 또, IP는 전송을 위해서 최선을 다하지만 책임은 지지 않기 때문에 그것에 대한 책임은 상위의 계층의 프로토콜(TCP)이 담당하거나, 어플리케이션 차원에서 해결을 해야만 한다.

 어플리케이션이 만든 데이터를 상위의 프로토콜로부터 전달받았을 때, IP는 그 패킷에 IP자신의 헤더정보를 추가한다. IP헤더에는 많은 정보가 들어 있다. Internetwork세상을 돌아다니면서 수많은 라우터를 건너 원하는 목적지까지 데이터를 실어 나르기 위해서는 많은 헤더정보가 필요한 것이다.

<그림1-9. 네트워크 모니터로 캡처한 그림 – IP 패킷>

IP패킷에는 상당히 많은 헤더정보가 있다. 이 정보를 가지고 전세계에 어디에 있는지도 모르는 서버들을 찾아다니는 인터넷 환경까지 지원을 하고 있으니 조금 많은 것이 당연하겠다는 생각이 든다. 경중을 따진다는 것이 무의미하겠지만 많은 헤더 중에서 가장 중요한 헤더정보는 IP Address라고 할 수 있다. IP헤더에는 자신의 IP Address, 목적지의 IP Address 등의 Address정보, 상위의 계층 중 어느 프로토콜을 이용할 것인지를 알려주는 프로토콜 정보, 패킷이 제대로 왔는지를 확인하기 위한 용도로 사용이 되는 Checksum 필드, 네트워크 상에서 존재하지 않는 호스트를 찾기 위해 끝없는 방황을 하는 것을 막기 위한 TTL등의 정보가 들어 있다.

IP가 하는 일은 이러한 헤더정보를 이용하여 패킷을 전달하는 역할을 한다. 그 때 참조하는 것이 바로 라우팅 테이블이며, 만약에 라우팅 테이블에 정보가 없다면 자신의 기본 게이트웨이로 설정되어 있는 라우터에게 패킷을 전달한다. 갑자기 조금 다른 내용이 나왔는데 잘 이해가 안 돼도 괜찮다. 이 부분에 대해서는 다음 장에서 자세히 설명한다.

일반적인 호스트의 IP와는 달리 라우터의 IP는 몇가지 일을 더 하고 있다. 우리가 사용하는 각각의 컴퓨터들도 IP를 사용하고, 이들 컴퓨터들이 서로 다른 네트워크간에 통신이 되려면 라우터가 있어야 하는데, 이들도 역시 IP라는 것을 사용한다. 다만 하는 역할이 조금 다를뿐이다.

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

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

세 번째, 패킷을 전달해야 할 라우터의 MAC Address를 알아낸다. 이렇듯 우리가 사용하는 컴퓨터에 설치된 NIC(Network Interface Card; 네트워크 어댑터 카드)뿐만이 아니라 라우터도 역시 NIC를 가지고 있으며 그들도 역시 MAC Address 주소를 가지고 네트워크에서 식별된다.

네 번째, 해당 라우터로 패킷을 전달한다. 이 과정을 바로 라우팅(Routing)이라고 하는 것이며, 라우팅을 담당하는 하드웨어를 우리는 "라우터"라고 부른다. Windows 서버 OS를 가지고도 라우터를 구현할 수 있다. 다만 여러분들이 일상적으로 ‘라우터’라고 부르는 것은 라우팅 기능을 전문적으로 구현하도록 만들어진 하드웨어 장비를 일컫는다.

인터네트워크 상의 모든 라우터들은 위의 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헤더에서 제공을 해 주고 있다. TCP/IP를 공부하다 보면 대단하다는 생각이 든다. TCP/IP라는 프로토콜도 사람이 만든 것이긴 하지만 대단히 논리적인 사고를 하는 사람들의 작품이라는 생각이다.

- ARP (Address Resolution Protocol)

단순하지만 아주 중요한 내용이다. 지금까지의 과정을 정리해보면 응용프로그램이 데이터를 만들었고 이 데이터를 TCP나 UDP에게 내려보냈다. TCP나 UDP는 자신들이 원본데이터에 각각 “헤더”라고 부르는 정보를 추가한 다음 이 패킷을 전달하는 역할을 하는 IP에게 내려보내고, IP는 상대방 컴퓨터의 IP Address를 근거로 해서 IP Packet이라는 것을 만들어 내게 된다. 많은 과정이 있었지만 아직까지는 실제 통신이 일어난 것이 아니다. 실제 통신이 일어나기 위해서는 어떤 형태로든 상대방 컴퓨터에게 이 패킷을 전달해야 할 것이다. 그 방법으로 우리는 케이블이 연결된 네트워크 어댑터 카드(NIC)를 이용한다.

 문제는 이 네트워크 어댑터 카드는 IP Address라는 논리적인 주소를 통해서 통신을 하지는 못하는데 있다.

네트워크 어댑터 카드는 위에서 시키는 대로 그대로 행동에 옮길 뿐이다. 보다 상위 계층에서 사용하는 IP Address는 뭔지 모르는게 당연하다. 이들은 MAC Address라는 물리적인 주소를 이용해서 통신을 진행한다. 다시 한번 정리를 해 보면, IP가 패킷을 라우팅할 때는 물리적인 통신을 담당하는 네트워크 어댑터 카드 (NIC)가 인식할 수 있는 하드웨어 어드레스가 필요하게 되는데 이것이 바로 MAC Address이며, IP는 이러한 MAC Address를 알아 내야만 통신을 할 수가 있게 되는 것이다. 이어지는 Physical Layer에서 다시 한번 설명하겠다. 일단은 “IP Address가 네트워크 통신의 다음단계를 진행하기 위해서는 MAC Address를 알아내야만 한다”라고 정리해 둔다.

이러한 IP의 요구에 해답을 제공하는 것이 바로 ARP (Address Resolution Protocol)이다. 통신을 원하는 상대방 호스트의 MAC Address가 요청될 때 가장 먼저 ARP Cache를 찾아서 그곳에 원하는 IP Address와 MAC Address의 정보가 있는지를 알아보게 된다. 최근에 해당 호스트와 통신을 했던 적이 있다면 ARP Cache에는 그러한 정보가 남아 있기 때문이다. 만약 해당 IP Address와 MAC Address가 매핑된 정보가 ARP Cache에 없다면, ARP는 목적지의 IP Address를 근거로 하여 MAC Address를 찾기 위한 ARP요청 프레임을 만들고, 그것을 브로드캐스트(Broadcast)통신방법을 이용해서 네트워크에 뿌리게 된다. 브로드캐스트이기 때문에 같은 네트워크에 존재하는 모든 호스트가 ARP요청을 받게 되지만, 결국 응답하는 호스트는 해당 IP Address와 일치하는 IP를 가진 호스트만이 응답을 하고 나머지는 버려지게 된다. 그 응답으로 ARP는 상대방 IP주소를 이용해서 MAC Address를 알아내게 되었다.

이런 ARP의 도움을 받아서 IP는 목적지 호스트의 MAC Address를 알아내기 때문에 MAC Address를 기반으로 하는 통신을 할 수가 있는 것이다. ARP정보를 들여다 볼 수 있는 유틸리티가 기본적으로 제공된다. 유틸리티 이름 역시 arp.exe 인데, 이것을 통해서 간단하게 ARP 정보를 조회해 보도록 하겠다. Arp는 명령프롬프트에서 동작하는 유틸리티이다. 명령프롬프트에 접근하기 위해서는 “시작à프로그램à보조프로그램à명령프롬프트”를 실행하거나, 시작à실행창에 “cmd”라고 입력하면 된다. 시스템 관리자라면 명령프롬프트(Command Prompt)에서 해야 하는 일들이 아주 많다. 그만큼 자주 들락거려야할 것인데, 필자의 경험으로는 cmd를 입력해서 접근하는 것이 가장 편하다.

앞으로 명령프롬프트를 통해서 작업한 내용들을 여러 번 볼 수 있을 것이다. 굵은 글씨로 보이는 부분이 직접 키보드를 통해서 입력한 내용이고 보통 글씨로 보여지는 것은 명령에 따른 결과로 나온 그림이다. 괄호안의 내용은 부연설명이다.

Microsoft Windows XP <Version 5.1.2600> (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\wssong>ping 192.168.5.1  (192.168.5.1 IP Address를 사용하는 호스트에게 Ping을 이용한 연결테스트를 하고 있다.) Pinging 192.168.5.1 with 32 bytes of data: Reply from 192.168.5.1: bytes=32 time<1ms TTL=128 Reply from 192.168.5.1: bytes=32 time<1ms TTL=128 Reply from 192.168.5.1: bytes=32 time<1ms TTL=128 Reply from 192.168.5.1: bytes=32 time<1ms TTL=128 Ping statistics for 192.168.5.1:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 0ms, Maximum = 0ms, Average = 0ms   C:\Documents and Settings\wssong>arp –a  (arp cache 를 보여달라는 명령)   Interface: 192.168.5.3 --- 0x3   Internet Address      Physical Address      Type   192.168.5.1           00-00-e8-78-de-90     dynamic  (ping을 이용해서 통신을 했던 컴퓨터의 IP Address와 MAC Address의 매핑 테이블을 보여준다.) C:\Documents and Settings\wssong>arp –d  (arp cache 를 삭제하는 명령) C:\Documents and Settings\wssong>arp -a No ARP Entries Found  (arp cache가 삭제되고 아무런 정보가 없음을 보여준다) C:\Documents and Settings\wssong>

<그림1-11. 네트워크 모니터로 캡처한 그림 – ARP Request 패킷>

캡처한 그림은 ARP Request Broadcast 패킷이다. 그림에서 타원으로 표시한 부분을 보면 Target Protocol Address가 192.168.5.1로 되어 있고, Target Hardware Address가 000000000000 으로 되어 있음을 주목한다. 이것은 192.168.5.3 호스트가 192.168.5.1 IP Address를 사용하는 호스트의 네트워크 어댑터 카드의 MAC Address를 찾는 패킷임을 확인할 수 있다. 그 다음엔 당연히 192.168.5.1 호스트로부터 자신의 MAC Address를 알려주는 응답메시지가 와야 한다. 다음의 <그림1-12>에서 응답패킷을 확인할 수 있다.

<그림1-12. 네트워크 모니터로 캡처한 그림 – ARP Reply 패킷>

간단하지만 네트워크 모니터를 통해서 이러한 패킷들을 들여다 보면 꽤 재미있을 것이다. 책에서 보던 내용들을 그대로 네트워크에서 찾아볼 수 있을 테니 말이다. 그냥 외우던 것에 비하면 잊혀지지 않는 경험이 될 것이다.

-ICMP (Internet Control Message Protocol)

 만일 패킷을 라우팅하는 도중에 문제가 발생한다면 어떻게 해야 할까? 그 때 바로 ICMP (Internet Control Message Protocol)의 역할이 필요해진다.  ICMP는 원본호스트에게 에러를 보고하는 일을 한다. 예를 들어서 라우터를 통과하려는 패킷이 많아서 혼잡해 진다면, ICMP는 "Source quench Message"를 보내게 된다. Source quench Message는 호스트에게 전송속도를 늦춰줄 것을 요청하는 메시지이다. 또, 라우터가 혼잡한 상황에서 보다 나은 길(route)을 발견하였을 때 역시 redirect 메시지로써 다른 길을 찾도록 한다. 마지막으로 "Destination Host Unreachable"메시지를 전달할 때도 ICMP를 이용한다. "Destination Host Unreachable"은 회선이 다운되어서 라우팅 할 수 없거나 라우팅 테이블에 목적지의 네트워크 정보가 없을때 발생되는 메시지이다. 이상으로 ICMP의 역할 몇 가지를 알아 보았는데, 하는 일이 비슷하다는 것을 알 수 있다. 결국 에러를 처리하는데 초점이 맞춰져 있다.

ICMP는 IP가 패킷을 전달하는 동안에 발생할 수 있는 문제점을 보고하는 역할을 하는 프로토콜이다.

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

C:\>ping 192.168.5.1 Pinging 192.168.5.1 with 32 bytes of data: Reply from 192.168.5.1: bytes=32 time=361ms TTL=128 Reply from 192.168.5.1: bytes=32 time=430ms TTL=128 Reply from 192.168.5.1: bytes=32 time=300ms TTL=128 Reply from 192.168.5.1: bytes=32 time=460ms TTL=128 Ping statistics for 192.168.5.1:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 300ms, Maximum = 460ms, Average = 387ms C:\>ping 192.168.5.2 Pinging 192.168.5.2 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.5.2:     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\>

위의 상황에서 네트워크를 캡처해 보았다. ICMP 패킷이 잡힌 것을 확인할 수 있다.

<그림1-13. 네트워크 모니터로 캡처한 그림 – ICMP 패킷>

캡처한 그림을 보면 ICMP라는 프로토콜로 보여지는 것이 총 8개이다. Ping 을 통해서 상대방 컴퓨터와 연결성을 테스트했을 때 응답이 4개가 왔었다. 요청 역시 4개가 날아갔던 것이다. 그래서 ICMP Echo 패킷이 4개, ICMP Reply 패킷이 4개. 총 8개의 패킷이 보여지게 되는 것이다.

-IGMP (Internet Group Message Protocol)

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

TCP 3 Way Handshake가 진행되는 과정에 대해서 알아보도록 하겠다. TCP/IP Protocol에 대해서 처음 공부하는 독자라면 일단 지나쳐도 좋다. 하지만 다음에 다시 한번 들여다 봐야 할 것이다.

TCP 3 Way Handshake는 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정을 의미한다. 이름이 재미있다. 영어 그대로 보면 “세방향으로 악수를 한다?” 라고 표현을 했는데, 맞는 표현이다. 이 과정에서 송신측과 수신측에 총 3개의 패킷이 생성이 되기 때문이다. 캡처한 그림을 들여다 보라.

<그림1-6. 네트워크 모니터로 캡처한 그림 – TCP 3 Way Handshake1>

그림에서 하이라이트된 부분을 보면 192.168.5.3 이라는 IP주소를 사용하는 컴퓨터가 BLUEAPPLE이라는 이름의 컴퓨터로 HTTP Get Request를 보내는 것을 알 수 있다. BLUEAPPLE이 웹서비스를 하고 있다. 그런데 웹서비스를 요청하는 패킷의 앞에 TCP 패킷 3개가 더 있다는 것을 알 수 있다. 주의 깊게 보면 192.168.5.3이 BLUEAPPLE에게 TCP패킷을 보내고 있고, BLUEAPPLE은 그에 대한 응답을 하고 있고, 다시 192.168.5.3이 뭔가 패킷을 보내고 있는 것이 보일 것이다. 이 과정이 TCP 3 Way handshake 이다. 그렇다면 이 과정에서 어떤 일이 생길까? 구체적으로 보도록 하자.

<그림1-7. TCP 3 way handshake의 과정>

먼저 송신측 호스트는 상대방과 통신을 원하고 있음을 알리는 뜻으로 TCP헤더의 SYN(Synchoronize) Flag 를 켠다. 켠다는(on) 것은 “1”로 설정함을 의미한다. 그리고 이 세그먼트(보통 TCP 패킷을 세그먼트라고 부른다.)의 일련번호(S/N)를 붙여서 세그먼트의 시작번호를 상대방에게 알려준다.(TCP 3 way handshake의 첫번째 과정)

수신측 호스트는 이 SYN Flag 신호에 대해서 응답을 하게 되는데 송신측 호스트가 보낸 패킷을 잘 받았다는 표시로 응답메시지를 만든다. ACK(Acknowledgement) Flag를 켜고, 상대방의 S/N에 대한 확인메시지를 발송해 주는 것이다. 예제에서 상대방의 S/N는 100번이었기 때문에 S/N=100번을 잘 받았다는 응답으로 수신측 호스트는 다음에 받을것으로 기대되는 일련번호를 응답한다. 결국 100번에 1을 더하여 101번이라는 응답을 주게 된다. 그런 이유로 위의 예제에서 두번째 패킷의 ACK No는 101번이 되었다. 이걸로 끝이 아니다. 자신이 보낼 패킷의 일련번호도 역시 발송하게 되므로 SYN Flag=on, 자신의 Sequence Number는 200번부터 시작한다는 정보를 담아서 세그먼트를 만들게 되는데 이것은 결국 송신측과 수신측이 양방향 세션을 수립함을 의미하는 것이다.(TCP 3 way handshake의 두번째 과정)

마지막으로 송신측 호스트는 두번째 패킷에 대한 응답을 해 주게 되고, 그때부터 데이터의 전송이 시작된다. (TCP 3 way handshake의 세번째 과정)

조금 복잡한듯 하지만 익숙해 지면 간단히 찾을 수 있다. 네트워크모니터를 보면 설명부분에서 순서대로 S, A..S, A 로 시작하는 패킷이 있는 것이 보일 것이다 이 부분이 TCP 3 Way handshake를 하는 과정이다.

<그림1-8. 네트워크 모니터로 캡처한 그림 – TCP 3 Way Handshake2>

 

1-2-2. Transport Layer ; 통신의 두 컴퓨터간의 연결성을 보장해 주는 계층

Transport Layer는 TCP/IP Protocol을 가진 두 호스트간의 통신을 위한 방법을 제공해 주는 계층이다. 이 계층에 해당하는 UDP와 TCP는 두 호스트를 연결해 주는 하나의 지점으로서 "Port"라고 부르는 “창구”를 통해서 통신을 한다.

웹서비스의 예를 들어보겠다. 웹서비스를 하기 위해서는 분명히 웹서비스가 동작하는 컴퓨터가 한대 있어야 한다. 하지만 이 컴퓨터는 웹서비스 뿐만이 아니라 추가로 FTP서비스, SMTP서비스 등 수많은 TCP/IP기반 서비스를 처리할 수 있다. 클라이언트가 웹서비스를 하고 있는 시스템에게 웹서비스를 요청하기 위해서는 자신이 원하는 서비스가 웹서비스임을 명확히 밝힐 필요가 있다. 그렇지 않으면 서버 입장에서는 클라이언트가 무슨 서비스를 원하는지 알 방법이 없기 때문이다.

이 방법으로써 TCP/IP에서는 "포트(Port)"라고 부르는 번호를 이용해서 서비스를 구분하고, 클라이언트 쪽에서 제공한 포트와 자신이 제공하고 있는 서비스의 포트를 연결시킴으로써 정상적인 서비스를 하게 되는 것이다. 그리고 이러한 서버측의 포트로 클라이언트가 접근할 수 있도록 하기 위해서 일반적으로 사용되는 서비스는 Well-Known port (잘 알려진 포트)라는 것으로 약속되어 있다. 예를 들면Web서비스는 80번, SMTP서비스는 25번, Telnet서비스는 23번등으로 되어 있다. 일반적으로 사용되는 이러한 서비스들과 포트들에 대해서는 다시 한번 다루도록 하겠다. 보안이라는 측면을 다루기 위해서는 이러한 포트를 이해하는 것은 필수적인 개념이다.

- TCP (Transmission Control Protocol)

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

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

두 번째, TCP는 Sequence Number (일련번호)와 Acknowledgements (확인신호)를 이용하여 신뢰성 있는 전송을 보장한다. Sequence Number는 여러개의 데이터를 한꺼번에 전송해도 뒤섞이지 않도록 해 주며, 또 수신측의 호스트에서는 그 순서대로 재조합을 할 수 있는 방법을 제공한다. Acknowledgements는 송신측의 호스트로부터 데이터를 잘 받았다는 수신측의 확인메시지를 의미한다. 보내는 모든 패킷마다 일련번호를 붙여서 보내고 또 수신측에서는 송신측이 보낸 패킷마다 확인메시지를 전송해 주게 되니 당연히 신뢰할만한 통신이 보장된다. 그런 이유로 TCP를 이용한 통신방법은 잘못된 전송을 허용하지 않는다.

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

<그림1-4. 네트워크 모니터로 캡처한 그림 – Transport Layer – TCP 패킷>

<그림1-4>는 한 컴퓨터가 다른 컴퓨터로 TCP/IP를 이용한 통신을 시도한 상황을 패킷캡처한 것이다. 갑자기 이게 왠 이해할 수 없는 그림? 그림의 제목을 보면 “네트워크 모니터”라는 이름을 달고 있다. 이 툴에 대한 사용법은 이번장의 마지막 부분에서 다룰 것이다. 지금부터 TCP/IP 부분을 설명하면서 계속 필자가 네트워크를 캡처해서 얻은 그림을 통해서 설명할 것이다. 보면서 이해하는 편이 가장 빠를 거라는 생각에서다. 그림의 가운데 부분을 보면 하이라이트된 부분에서 TCP로 시작되는 부분을 찾을 수 있다. 이 패킷은 TCP를 사용하는 패킷이다.  하이라이트된 부분 아래로 Source Port, Destination Port, Sequence Number, Acknowledgement Number.. 등이 출력되어 있는 것 보인다. 이것이 TCP프로토콜의 Header에 들어있는 내용들이다.

응용프로그램으로부터 상대방 컴퓨터에 전송해야 할 데이터를 넘겨받은 TCP는 헤더부분에 특별한 정보들을 추가하는 것으로 자신이 해야 할 일을 한다. 자신이 상대방으로부터 응답을 받아들이기 위한 준비를 위해 Source Port를 명시하고, 상대방 응용프로그램에 명확히 연결하기 위해서 Destination Port도 기록을 했다. 그리고 자신이 보내는 패킷의 순서를 매겨서 Sequence Number에 담고, 상대방이 이 패킷 전에 보냈던 것에 대한 응답으로써 Acknowledgement Number도 기록을 했다. Destination Port가 뭐라고 되어 있는지 그림을 보라. Hypertext Tranfer Protocol 이라고 되어 있는 것이 보인다. 즉 HTTP라는 것을 알 수 있다. 이 메시지를 통해서 <그림1-4>에서 보여지는 캡처한 패킷이 “웹서버”로 가는 트래픽이라는 것을 알 수 있겠다.

어렴풋이 네트워크 패킷에 대해 감이 잡힐 것이라는 생각이 드는데, 만일 이 부분이 흥미있게 생각되는 독자라면 아마 당신은 며칠밤을 잠 못자고 고생을 좀 해야 할 것이다. 아마도 언제 어디서나 네트워크 모니터를 실행해 놓고 잡히는 패킷들을 분석하느라고 한동안 시간을 보내야 할 테니까. 이 책에서는 TCP/IP에 대한 완전한 내용을 다루지는 못한다. 여러분들이 Windows Networking을 공부하는데 최소한의 내용을 다루고 있을 뿐이다. 별도로 TCP/IP 전문서적 한권 정도는 따로 공부하면 도움이 많이 될 것이다. 필자의 개인웹사이트에서 참고할 만한 서적들의 리스트를 찾을 수 있다.

흔히 볼수 있는 FTP, HTTP, DNS Zone transfer 등의 통신이 TCP를 이용하고 있다.

- UDP (User Datagram Protocol)

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

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

두 번째, UDP는 메시지의 확실한 전송을 보장하지 않는다. 그래서 UDP데이터는 순서없이 도착할 수 있고, 중복될 수도 있다. UDP는 이러한 것들을 해결해 줄 수 없다. UDP가 처리해 주지 못하는 이러한 부분들은 보다 상위의 계층에서 해결해 줘야 한다. 즉, 어플리케이션이 확실한 전송을 보장해 주기 위한 부분까지 담당을 해야 한다는 것이다.

이상한 생각이 들 것이다. 위에서 설명한 TCP에 비해서 UDP는 상대적으로 뭔가 열악해 보인다는 생각이 들지 않는가? 그런데도 왜 UDP를 사용해야 할까?  그것은 UDP역시 나름대로 필요한 영역이 있기 때문인데, 주로 화상회의, 리얼오디오, 인터넷방송 등에서 사용이 되는 것을 보면 그 쓰임새를 짐작할 수 있다. 우리는 화상회의를 할 때 깨끗한 그림만을 제공받지는 못한다. 끊기기도 하고, 잠시동안 멈추기도 하지만, 계속 실시간으로 서비스를 받을 수 있게 된다. 만일 TCP를 사용한다면 이러한 일들은 어렵게 된다. TCP는 중간에 손상된 패킷을 받는다면 반드시 재전송을 요청해야 한다. 실시간 데이터를 받는다는 것과는 어째 어울리지 않는 통신방법이라는 생각이 들 것이다.

또, 서버의 문제를 관리자에게 알려주기 위한 긴급한 메시지의 경우를 생각해 보면, 이런 긴급한 상황에 TCP처럼 사전세션을 맺는 과정을 처리하고, 느긋한(?) 통신을 하는 것은 어울리지 않는다는 것을 알 수 있다. 당장 서버가 다운이 되는 상황이면 이 사실을 가장 빠르게 알릴수 있는 방법이 필요하다. UDP가 그러한 통신을 진행한다.

마지막으로 아주 소량의 데이터를 전송하는 경우를 예를 들 수 있다. 데이터를 전송해야 하는데 그 크기가 500byte 정도의 작은 크기의 데이터라고 해 보겠다. 이것은 패킷하나만 가지면 충분히 전송할 수 있는 크기이지만 TCP를 이용하면 상황은 달라진다. 먼저 사전연결인 TCP 3 way handshake를 위해서 패킷 3개, 실제 데이터 전송 1개, Ack패킷 1개, TCP세션을 종료하는 패킷 2개. 이렇게 총 7개의 패킷이 네트워크에 발생되어야 한다. 이럴 경우에는 역시 UDP가 보다 현명한 방법이라는 생각이 든다. UDP는 패킷 하나만으로 위의 상황을 처리해 줄 수 있기 때문이다.  

이런 이유로 UDP도 분명히 필요한 protocol이다. 아래에 UDP패킷을 캡처한 그림이 있다.

<그림1-5. 네트워크 모니터로 캡처한 그림 – Transport Layer – UDP 패킷>

TCP패킷에 비해서 상대적으로 간소한 헤더로 구성되어 있음을 알 수 있을 것이다. 당연한 결과이다. 하지만 UDP역시 Source Port, Destination Port 등의 포트번호를 사용하고 있음을 기억할 필요가 있다. 이렇듯 TCP와 UDP는 포트번호라는 것을 통해서 상대방 응용프로그램과의 연결성을 명확히 해 주는 역할을 담당하고 있다. 이렇게 TCP와 UDP는 각각의 임무인 헤더를 추가하는 작업을 한 다음 이 패킷을 다른 호스트에게 배달하는 일을 담당하고 있는 IP프로토콜에게 넘겨주게 된다.

Application Layer ; 응용프로그램이 동작하는 계층

마이크로소프트는 자사의 TCP/IP 프로토콜에서 이 계층을 위하여 두 가지의 프로토콜을 제공한다. WinSOCK과 NetBIOS over TCP/IP이다. TCP/IP를 사용하여 네트워크 통신을 하는 2가지 형태의 네트워크 프로그램을 지원하기 위한 인터페이스에 해당한다. 이들에 대해서는 앞으로 네트워크 서비스 단원에서 다시 다룰 기회가 있을 것이다. “Socket 기반의 전형적인 TCP/IP 어플리케이션은 WinSOCK 이라는 인터페이스를 통해서 TCP나 UDP 등의 프로토콜을 호출하게 되고, NetBIOS 어플리케이션은 NetBIOS over TCP/IP를 통해서 TCP나 UDP등의 프로토콜을 호출하여 네트워크 통신을 진행하게 된다”라고 정리해 두자. 누가 결정해 줄까? 물론 응용프로그램을 만드는 개발자들이 프로그래밍을 할 때 어플리케이션의 성격에 따라 구현하는 방법이 달라지는 것이다. 간단히 Socket응용프로그램과 NetBIOS응용프로그램을 구분하고 넘어간다.

-Socket 응용프로그램 : Socket 이름을 필요로 하는 응용프로그램. 보통 TCP/IP 프로그램이라고 하면 Socket응용프로그램을 말한다. 전형적인 TCP/IP 프로그램인 셈이다. 이들은 “IP Address + TCP 또는 UDP + 포트번호”로 만들어진 Socket 이름이라는 것을 사용하여 통신을 한다. 우리가 사용하는 www, ftp, mail, telnet 등 대부분의 응용프로그램에 해당한다. 이것을 지원하기 위해서 마이크로소프트는 TCP/IP Protocol Suite에서 WinSOCK 이라는 인터페이스를 제공하고 있다.

-NetBIOS 응용프로그램 : NetBIOS 이름을 사용하는 응용프로그램. Net.exe, 파일및프린트 공유, 브라우져서비스 등 마이크로소프트의 네트워크 프로그램들이 주로 이에 해당된다. 이들 응용프로그램의 네트워킹을 위해서 NetBEUI라는 자사의 프로토콜을 제공했었지만 NetBEUI 프로토콜이 가지는 제한성 때문에 TCP/IP를 채택하고 이들 구형 응용프로그램을 TCP/IP환경에서도 지원하기 위해서 TCP/IP Protocol Suite에서 NetBIOS over TCP/IP (=NetBT = NBT) 라는 인터페이스를 제공하고 있다. 구형 응용프로그램이라고 표현은 했지만 회사 환경의 내부 네트워크에서는 아직도 상당부분에서 이러한 NetBIOS 응용프로그램이 사용되고 있다.

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

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

<그림1-3>에서는 TCP/IP통신의 흐름을 송신측과 수신측으로 구분하여 그려보았다. 꽤 복잡해 보이지만 잠깐만 들여다 보면 그다지 복잡한 그림이 아니다.  송신측에서는 응용프로그램에서 시작하여 아래쪽으로 화살표가 내려오고 있고, 수신측에서는 아래쪽에서부터 응용프로그램 쪽으로 화살표가 올라가고 있는 것을 알 수 있다.  TCP/IP통신을 할 때 이렇듯 계층구조를 따라서 통신이 이루어지고 있다. 일단은 그것을 확인하는 것만으로도 충분하다.

그림을 보면 송신측에서 먼저 응용프로그램을 실행한후 만든 데이터를 다른 호스트로 전송했을 때 데이터는 먼저 하위의 프로토콜에게 전달이 된다. 그러면, 하위의 프로토콜은 상위의 계층에서 넘겨 받은 데이터를 캡슐화시키고, 그 데이터앞에 Header라고 불리우는 추가 정보를 덧붙인다. 그 다음 또, 자신의 하위 계층에게 그 데이터를 전달한다. 최종적으로 가장 하위의 계층에 해당하는 Physical Layer는 네트워크에 실어 보낼 수 있는 프레임(frame)이라는 것을 만들어서 데이터를 전송한다.

수신측의 호스트에서 생각을 해 보겠다. 실제로 데이터를 받게 되는 것은 당연히 해당 호스트의 Physical layer에서 받게 된다. 즉 네트워크 어댑터 카드에서 데이터를 받게 될 것이다. 그럼 이제 받는 쪽에서는 송신측과는 반대로 각 계층마다 자신들이 이해할 수 있는 상대방 프로토콜이 덧붙여 놓은 Header부분만 제거를 하고, 순수한 데이터 부분만 상위의 계층에 전달하게 되고, 결국 최종적으로는 순수한 데이터만이 어플리케이션에게 전달된다.

송신측의 호스트의 어플리케이션이 만든 데이터에 여러 프로토콜들이 Header로서 정보를 추가했던 작업은 네트워크 상에 데이터를 정확히 전달하기 위한 조치였던 것이다. 당연히 수신측의 호스트는 그러한 정보를 기반으로 하여 내가 받은 데이터가 온전한 모양의 데이터인지 계산하고 자신의 최종목적지인 가장 상위의 어플리케이션에게는 단지 상대방의 어플리케이션이 만든 데이터만을 전달하게 되는 것이다. 이것이 기본적인 계층모델을 따른TCP/IP Protocol Suite의 동작원리이다.

각각의 계층별로 프로토콜에 대해서 간단히 정리를 해 보겠다. 자세한 사항은 뒤에서 이어가도록 한다. TCP/IP는 LAN(Local Area Network)과 WAN(Wide Area Network)을 위해서 디자인된 표준 프로토콜 Suite이다. 가장 기초가 되는 모델은 Physical(Network interface) Layer이다. 이 계층은 실제 네트워크에서 데이터를 전송하는 케이블에 프레임이라고 불리우는 데이터를 실어 보내고, 또 한편으로는 데이터를 받는 역할을 담당한다.

다음의 계층은 Network Layer이다. 이 계층은 주소를 관리하고, 포장하고, 라우팅하는 역할을 담당한다. Network 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 Layer이다. 이 계층은 어플리케이션이 네트워크에 접근가능하도록 해 주는 역할을 한다. 마이크로소프트 TCP/IP는 어플리케이션과 transport Layer사이에 Windows Sockets과 NetBIOS interface를 제공한다. Windows Sockets은 많은 전송계층의 프로토콜과 서로 다른 주소체계 사이에서 윈도우 환경에 표준 API(Application Programming Interface)를 제공한다. NetBIOS는 TCP/IP, NetBEUI등의 프로토콜들을 이용할 수 있는 표준 인터페이스를 제공한다.

위의 설명만으로도 충분하다고 여겨진다면 바로 다음 단원인 IP Address로 넘어가도 좋다. 하지만 어렵거나 조금 더 자세히 알고자 한다면 계속해서 자세히 각각의 계층과 프로토콜의 특징과 역할에 대해서 검토해 보도록 하겠다.

개별적인 하나하나의 컴퓨터들이 서로간에 자원을 공유하기 위해서는 네트워크가 필요하다. 이를테면 컴퓨터들이 네트워크를 이용해서 데이터를 주고 받는다거나 다른 컴퓨터에 연결된 프린터를 이용해서 내 컴퓨터에서 만든 문서를 출력한다거나 하는 작업을 하는 것을 말하는데, 이것이 안정적으로 이루어지기 위해서는 그들이 네트워크에 데이터를 실어서 상대방에게 정확히 전달하기 위한 서로간의 약속이 필요하다. 데이터를 보내는 방법, 잘 받았는지 확인하는 방법, 문제가 생겼을 때 다시 보낼 수 있는 방법, 등등. 이러한 모든 약속들을 정해서 제대로 된 데이터의 전송을 보장 함으로써 성공적인 네트워킹이 가능하도록 하는 방법이 필요하다.

 

네트워크 통신에서 이러한 약속을 “프로토콜(Protocol)”이라고 부른다. 네트워크상에서 컴퓨터들은 프로토콜을 통해서 데이터를 전송하고 있다. TCP/IP, NetBEUI, IPX/SPX, AppleTalk 등이 바로 대표적인 프로토콜의 종류이다.

 

그 중에서도 TCP/IP 프로토콜은 가장 인기있고 널리 사용되는 인터넷의 표준 프로토콜이고, 네트워크 관리자라면 반드시 이 프로토콜의 각 구성요소에 대해서 제대로 인지를 하고 있어야 한다. 몰라도 잘 쓸 수는 있다. 누군가가 잘 구성해 놓은 환경에서 쓰기만 하는 사용자라면 그럴 수 있다. 그건 잘 돌아가기만 하는 네트워크 환경에서 얘기일 뿐, TCP/IP를 알지 못하고서 그것에 따른 문제를 해결해 내기란 참 어려운 일이다. 하지만 TCP/IP 프로토콜의 기본원리를 잘 깨우치고 있으면 그것을 이용한 각종 어플리케이션의 학습능력도 향상될 뿐만 아니라 네트워크에서 컴퓨터들이 겪는 문제점을 해결할 때 보다 빠른 시간에 정확하게 문제점을 집어 낼 수 있는데 큰 도움을 준다.

 

마이크로소프트의 윈도우 환경에서도 역시 TCP/IP를 자사의 OS에서 충실히 지원하고 있고 Windows 2000부터는 아예 기본 프로토콜로 채택하여 TCP/IP 프로토콜이 없이는 네트워크가 움직이지 않는다고 해도 과언이 아닐 정도로 중요한 프로토콜이 되었다.

본론으로 들어가서 TCP/IP 프로토콜에 대한 이야기를 해 보도록 하자. TCP/IP라는 프로토콜은 너무나도 유명하여 네트워크를 한다는 사람뿐만 아니라 컴퓨터를 조금이라도 다룰 줄 알고 인터넷이라는 것을 접근하기 위해서 한번이라도 네트워크 설정을 해 본 경험이 있는 사용자라면 누구나 한번쯤 들어보았을 이름이다.

하지만 실제로 우리가 아는 것만큼 TCP/IP는 간단하지만은 않다. 지금처럼 인기있는 표준 프로토콜로 발전할 수 있었던 것은 TCP/IP가 서로 다른 여러 기종의 시스템을 연결할 수도 있고, 또 정확한 전송처리를 위해서 많은 대비책을 내포하고 있어서 네트워크에서 믿을 만한 통신을 제공하였기 때문에 가능한 일이었다. 그러한 일들을 처리하기 위해서는 당연히 많은 내부적인 요소들을 포함하고 있기 때문에 그만큼 복잡하기도 하고, 공부할 꺼리도 많은 프로토콜이기도 하다.

TCP/IP는 이름 그대로 TCP와 IP가 합쳐진 프로토콜이다. 하지만 이 TCP/IP프로토콜은 TCP와 IP뿐만이 아니라 각각 맡은바 임무를 충실히 수행하는 몇 가지 프로토콜이 더 모여서 하나의 TCP/IP라는 커다란 프로토콜 셋트로 구성되어 있다. 이런 연유로 일반적으로 TCP/IP를 가리킬 때 "TCP/IP Protocol Suite"라는 용어를 사용한다. 우리가 보통 부르는 TCP/IP를 정확히 TCP/IP Protocol Suite라고 부른다. Suite라는 표현을 많은 번역서들에서 '묶음, 집합, 한벌' 등의 용어를 빌어서 사용하지만 명확히 그것들을 처리해 줄 만한 표현으로는 부족하다고 생각된다. 그래서 지금부터는 원어 그대로 TCP/IP Protocol Suite라고 부르기로 한다. 이제 우리는 TCP/IP Protocol에 대해서 그 구조부터 차근 차근 접근해 보도록 하자.

TCP/IP Protocol은 위에서 설명한 OSI 계층모델을 간소화하여 Application, Transport, Network, Physical 이라는 네 개의 계층 모델에 연결 시킬 수 있다.

위의 그림에서 보면, TCP/IP라는 프로토콜이 단순히 TCP와 IP의 집합만이 아니라 UDP, ICMP, IGMP, NetBT 등 그 밖에도 여러 개의 프로토콜이 모여 있다는 것을 알 수 있다. 이 모든 프로토콜들이 각각의 쓰임새가 다르고 역할이 다르다. 이런 전체적인 프로토콜의 집합이 바로 우리가 사용하고 있는 TCP/IP 라는 프로토콜을 이루어 내고 있다.

OSI 7Layer에서 그랬듯이 TCP/IP Protocol Suite 역시 하나의 흐름이라고 볼 수 있다. 가장 상위에 있는 Socket응용프로그램, NetBIOS응용프로그램 들은 데이터를 생성한다. 그 데이터를 네트워크 어댑터 카드(NIC)에 실어서 다른 컴퓨터에게로 보내기까지의 하나의 흐름을 Suite에서 보여주고 있는 것이다.

어플리케이션에서 데이터를 만들어서 그것을 로컬 하드디스크가 아닌 원격지의 파일서버에 저장을 해야 한다고 가정을 해 보겠다. 어플리케이션에서는 파일서버로 데이터를 전송하기 위해서 Network을 호출할 수 있는 방법이 필요할 것이고, 그러한 역할을 담당해 주는 것이 바로 Windows Socket과 NetBT라고 하는 Interface가 되는 것이다. NetBIOS와 WinSock은 네트워크로 전송을 하기 위해서 필요한 프로토콜을 호출할 수 있는 방법을 제시한다.

WinSock이나 NetBIOS over TCP/IP (NetBT)를 통해서 그 아래에 존재하는 Transport계층에 해당하는 TCP나 UDP를 이용하게 되고, TCP와 UDP는 상대방 컴퓨터의 응용프로그램과 잘 통신할 수 있도록 데이터의 머리부분(Header)에 몇가지 정보를 추가한 후 Network계층에 해당하는 IP에게 데이터를 전달할 임무를 맡긴다. IP가 하는 일은 상위로부터 받은 패킷을 전달하는 배달부 역할을 하고 있다. 그러면 IP는 ICMP, ARP등의 도움을 받아서 어댑터 카드에 데이터를 실을 수 있도록 준비를 한다. 그렇게 흘러내려온 데이터가 마침내 Ethernet 혹은 TokenRing등의 네트워크에서 사용하는 그들만의 Frame이 생성되어 네트워크 상에 전송된다.

단순하게 생각하면 내가 가지고 있는 데이터를 다른 컴퓨터로 옮기는 작업이 뭐 얼마나 대단할까 하고 생각할 수도 있겠지만, 조금만 네트워크를 이해해 보면 만만치 않은 작업이라는 것을 알 수 있게 된다. 내가 원하는 컴퓨터를 찾는 방법은 무엇을 사용할 것이며, 나만이 아닌 여러 사용자들이 같이 사용하고 있는 네트워크에서 남들이 보내는 데이터와 섞이지 않도록 무슨 방법을 강구해야 할 것인지.. 또, 데이터의 크기가 아주 크다면 이것을 효율적으로 보내기 위해서 작게 나누어야 할 것인데, 어떠한 방법으로 얼마만큼 작은 크기로 나눌 것인지, 데이터가 가다가 손실이 생기면 손상된 부분에 대해서는 어떻게 처리를 할 것인지 등등 수많은 문제들이 내포되어 있기 때문에 이러한 것들에 대한 대비책을 미리 만들어 두어야만 효율적인 네트워크를 운영할 수 있을 것이다.

이런 내용들을 정의해 둔 것이 바로 Protocol이라고 위에서 설명한 바 있다. TCP/IP역시 하나의 Protocol이며 네트워크를 운영하는 데 있어서 필요한 내용들을 담고 있다.

그러면, 이제부터는 TCP/IP Protocol Suite가 가지고 있는 여러 가지 Protocol에 대해서 하나씩 차례대로 정리를 해 보기로 한다.