[OSI 7 Layer] Network Layer

Neywork Layer

다음으로 3계층 네트워크 레이어에 대하여 살펴보겠다. 3계층의 역할은 네트워크를 거쳐 원하는 목적지까지의 연결성을 제공하는 것이다. 중요한 특징은 3계층은 best-effort 방식으로, 최대한의 노력은 하지만 항상 데이터 전송이 성공하는 것을 보장하지 못한다. 이에 따른 신뢰성 보장은 4계층에서 담당한다. 또한, connection less 라는 특성을 가지기 때문에 TCP 커넥션이 맺어져도 경로는 매번 다를 수 있다. 

3계층의 주요 프토콜은 IP(Internet Protocol)이다. 3계층의 장비들은 서로를 인식하고 통신하기 위해 IP주소를 활용한다. 이 때 3계층의 주요 장비는 라우터이며, 핵심 기능은 forwarding 과 routing 이 있다.

라우터에선 routing algorithm을 수행하며, 그 결과로 forwarding table이 생성된다. 

3계층에선 데이터 송수신시 패킷 스위칭 방식을 활용한다. 여기서 잠깐 패킷 스위칭과, 그와 대비되는 서킷 스위칭에 대해 알아보자.

패킷 스위칭은 말그대로 패킷 단위로 band width 를 full 로 사용하여 데이터를 보내는 방식을 의미한다. 그에비해 서킷 스위칭의 경우 미리 band width 를 나누어 사용한다. 즉, 각 연결된 노드의 개수만큼 band width 를 나눠야 할 것이다. 이에대한 비교는 다음과 같다.

서킷 스위칭 방식에선 10개의 노드를 연결하기 위해서 band width 를 10개로 나누어 사용하게 되고, 이에 따라 각 노드가 데이터전송을 전체 시간의 10% 만 활용한다고 했을 때에도 총 10개의 노드의 데이터 전송만이 가능하다.

그에 비하여 패킷스위칭을 활용할 경우 같은 시간에 35개의 노드의 데이터 전송이 가능하다고 한다. 

실제 네트워크 트래픽은 위 예시의 10% 를 활용하는 상황과 같이 burst 하게 일어나기 때문에 패킷 스위칭 방식이 보다 적절하다고 할 수 있다.

3계층에서 data loss 와 delay 는 어떤 상황에서 발생할까?

패킷이 도착하는 비율이 output link 를 통해 나가는 비율보다 많다면 버퍼에 queueing 되며, 만약 이 버퍼도 가득차게 되었다면 패킷 loss 가 발생한다. 이와 관련한 문제를 3계층에선 스스로 해결할 수 없으며, 실제로는 4계층의 흐름 제어를 통해 완화한다. (이때 4계층 프로토콜이 UDP라면, 드랍된 패킷은 영영 복구될 수 없다)

위 2가지는 라우터 내부에서 발생하는 딜레이다. 그림에선 생략되었지만 routing 알고리즘이 수행되기전까지 기다리는 시간도 딜레이에 포함된다. nodal processing 과정엔 라우팅 알고리즘 수행 시간도 포함될 것이다.

일반적으로 들어오는 속도와 나가는 속도가 동일하다면 delay 가 발생하지 않을 것 같지만, 사실 그렇지 않다. 그 이유는 다음과 같다.

고속도로를 예시로 생각해 보았을 때, 나가는 차와 들어오는 차의 평균 수는 같아도 차량의 이동이 burst 하게 발생한다면 출구 톨게이트 앞쪽에 차가 가득 쌓이기 시작할 것이다. 이는 뒤에 차들과 도로에 영향을 주기 시작하고, 결국 들어오는 차와 나가는 차의 비율은 1에 가까워 질수록 딜레이는 매우 크게 증가할 것이다.

앞서 언급하였듯이 이러한 문제는 3계층에서 해소할 수 없으며 end-to-end 단에서 데이터를 적게 보내는 방식으로 해결해야 한다.

위에서 라우터 내부에서 발생하는 딜레이 2가지를 소개하였는데, 그 외에도 2가지 발생할 수 있는 딜레이가 더 존재한다.

transmission delay 는 output buffer 로 부터 물리적 매체로 한 패킷이 들어가는데 까지 걸리는 시간이며, propagation delay 는 실제 데이터가 전송되는 시간이다. 사실상 3계층의 딜레이의 대부분은 propagation delay 가 차지할 것으로 예상할 수 있다.

다음으로 throughput 의 개념은 다음과 같다.

end-to-end 간의 시간당 보낼 수 있는 데이터양을 의미하며, 일반적으로 bps 단위로 표시된다. 주의할 점은 link capacity 와는 다르다는 것이다. link capacity 는 peer-to-peer 간의 시간당 보낼 수 있는 데이터양을 의미한다.

 

위 Rs < Rc 의 경우 throughput 은 Rs 로 결정 되지만, 밑의 경우 Rc 로 결정되지 않는다. 이유는 위의 고속도로의 예시와 같다.

Routing & Forwarding

라우터에 동작에 대하여 조금 더 자세히 알아보자.

라우터 내부에서는 라우팅 알고리즘을 수행후 그 결과를 forwarding table 에 저장한다. 이는 도착 주소에 따라 output link 를 매핑한 테이블이다. 수많은 도착 주소를 각각 output link 에 매핑하는 것은 비효율적이기 때문에 adress-range 를 매핑시킨다. 그 예시는 다음과 같다.

새로운 패킷이 도착하면 도착 주소를 포워딩 테이블에서 확인하여 output link 를 결정하는데, 이 과정에는 가장 길게 일치하는 range 를 통해 output link 를 결정하는 longest prefix matching 기법을 활용한다. 예를 들어 위 forwarding table에 다음과 같은 도착 주소가 주어졌다고 하자.

 여기서 두가지 도착 주소는 20 비트까지 확인했을 때엔 위 forwarding  table에 모든 range에 포함된다. 한 비트를 더 확인했을 때 첫번째 도착주소는 output link 0번에 정확히 매핑되어 문제없다. 하지만 두번째 도착주소는 끝까지 확인해 보아도 output link 1, output link 2 두가지의 adrress range 에 모두 포함된다. 이 때 longest prefix matching 기법이 사용되어 00011000 과 같이 가장 길게 matching 되는 range 에 해당하는 output link 로 결정되는 것이다.

Router architecture overview

여러개의 input port와 output port를 가지며, switching fabric 은 forwarding table 매핑 이후에 결과에 따라 패킷을 스위칭하여 output link 로 전달하는 역할을 한다. 

input port 의 색으로 구분되어 있는 박스는 각각 1~3계층을 나타내며 3계층에서 forwarding table 을 통해 output link 를 결정하며, 최종적으로 switch 되기 전까지 버퍼에 queuing 된다. 

한 패킷이 스위칭 되는 동안 다른 패킷이 스위칭 되지 못하는  Head-of-the-Linke (HOL) blocking 문제가 발생하기도 한다.

output port 는 input 의 역순으로 3~1 계층 과정을 지나며 동작한다. 마찬가지로 버퍼를 가지며, fabric switching 을 통해 패킷이 output port 로 전달되는 속도가 다음 링크로 transmission 되는 속도가 빠르다면 queuing 된다.

IP datagram format

위 이미지는 IP 패킷의 전체적인 구조를 보여준다. 이는 약 20bytes 크기의 헤더를 가진다.

IP 패킷의 최대 크기는 그보다 하위 계층인 1~2 계층에서 실제로 네트워크를 통해 보낼 수 있는 데이터의 크기에 의하여 결정된다. 사실상 2계층은 이더넷 프로토콜이 시장을 지배하기 때문에, 현실적으로 IP패킷이 가질 수 있는 크기는 46B ~ 1500B 라고 볼 수 있다.

IP패킷은 그 중 헤더를 20B 를 사용하고, 4계층에서도 마찬가지로 20B 헤더를 사용하기 때문에 결론적으로 패킷에 담을 수 있는 최대 데이터 크기 MSS(Maxium Segement Size)는 1460B 라고 볼 수 있다.

하지만 이러한 최대 데이터 크기는 강제되지 않으며, 헤더 bit 수에 의하여 결정되는 논리적인 최대 크기는 이보다 훨씬 크기 때문에 (약 64KB) 1460B 보다 큰 데이터를 실어서 이를 전송하려고 시도할 수 있다. 그렇게 되면 어떤 일이 일어날까? 정답은 IP fragmentation 이 일어난다는 것이다. 

즉, MSS 에 헤더까지 포함한 MTU (Maxium Transmission Unit) 값이 1500B를 초과하는 경우에 3계층에서 이를 여러개의 보다 작은 패킷으로 나누어 전송한다. 이렇게 조각화된 패킷은 목적지 까지 조각화된 상태로 전송되어, 최종 호스트에서 조립된다. 중간에 조립하지 않는 이유는 다시 이를 쪼개야 할 경우에 비효율 적이기 때문이다.

하지만 이러한 IP 계층에서의 조각화는 그 과정 자체에서의 오버헤드와, 조각 손실시 원본 패킷 전체를 재전송해야 한다는 단점, 보안 위험등의 이유와 같이 여러 가지 문제를 야기할 수 있으므로 최대한 피하는 것이 좋다.

그렇기 때문에 TCP와 같은 4계층 전송 프로토콜에서 적절한 MSS를 자동으로 협상하여 데이터가 조각화 없이 네트워크가 수용할 수 있는 세그먼트로 전송되도록 한다. 사실상 이더넷이 시장을 지배하기 때문에, 별도의 협상 과정이 없이  MTU를 1500B로 고정하는 정도로도 충분할 것 같다고 추측한다.

IP fragmentation 의 예시는 다음과 같다. 

3980B (4000 byte - 헤더 20byte) = 1480B + 1480B + 1020B

기존 패킷을 쪼개기 위해선 추가적인 IP 패킷 헤더가 필요하기 때문에 최종적으로 기존 패킷에 비하여 40B 가 추가된 것을 확인할 수 있다.

위와 같이 flag 비트를 통해 0이라면 해당 패킷이 조각난 패킷중 마지막이라는 것을, 1이라면 추가로 패킷이 전달될 것임을 수신자에게 알린다. 꼭 패킷이 순서대로 오는것이 보장되지 않기 때문에 offset 을 활용한다. (위 이미지에서 IP 헤더의 Fragment Offset 영역)

IPv4 주소체계

IPv4 주소 클래스

IPv4 주소는 32bit 의 이진수로 표현되며, 이는 3계층 호스트들을 구분하기 위해 필요하다. 

IP 주소를 클래스에 따라 분류하는데, A부터 E클래스까지 총 4,가지 클래스가 존재한다.

위 식별 방식에 따라 A클래스는 약 42억개가 넘는 네트워크 주소 개수의 절반을 차지하며, B는 25%, C는 12.5%, D, E 는 각각 6.25% 씩을 차지한다.

 각 클래스 별로 32비트 중 네트워크ID 로 사용되는 영역과 호스트ID로 사용되는 영역이 구분된다. 예를들어 A클래스의 경우 1byte 영역만 네트워ID로 사용되기 때문에 그 외 나머지 호스트ID 영역을 활용해 각 네트워크 별로 2^24 - 2 (약 1600만, -2 는 네트워크 전체를 의미하는 주소 x.0.0.0 과 모든 호스트를 의미하는 주소 x.255.255.255 를 제외하는 것) 개의 호스트를 할당 수 있다.

 B클래스는 128.x.x.x ~ 191.x.x.x 의 범위내에서 2^16 - 2 개의 호스트 주소를 할당하며, C클래스는 192.x.x.x ~ 223.x.x.x 범위내에서 2^8 - 2 개의 호스트 주소를 할당한다.

사실상 A클래스는 0.x.x.x ~ 127.x.x.x 까지 총 128개의 네트워크, 그 중 특별한 목적을 위해 사용되는 0.x.x.x 와 127.x.x.x 을 제외한 126개의 네트워크가 존재한다. 즉, 고작 126개의 네트워크가 IPv4 체계의 전체 네트워크 주소의 절반을 사용하고 있다는건데, 심지어 A클래스를 할당받은 기관이 해당 네트워크 내에서 그렇게까지 많은 호스트를 구분하지도 않는다. 그 말은 실제로는 아무 역할도 하지 않고 놀고 있는 주소가 많이 존재한다는 것이다.

이는 매우 비효율적이며, 초기 인터넷이 등장할 때엔 이렇게 까지 많은 IP주소가 필요할 거라고 예측하지 못했기 때문에 발생한 문제이다. 이를 해소하기 위해 클래스 기반 시스템에 비해 IP주소를 할당하고 네트워크 라우팅을 관리하는 더 효율적인 방법인 CIDR(Clasless InterDomain Rounting) 이 도입되고 있다. 

CIDR

이는 클래스 기반 시스템을 완전히 대체하진 못하였으나, 유연성이 뛰어나고 IP 주소 공간을 보다 효율적으로 사용할 수 있어 IP 주소 할당 및 라우팅의 주요 방법으로 자리 잡았다. 즉, 기존 클래스 기반 시스템으로 할당했던 IP주소 중 몇개를 돌려받거나, 아직 클래스 기반 시스템으로 할당하지 않았던 주소들을 새롭게 CIDR 방법을 통해 분배했다고 받아들이면 될 것 같다. 

서브넷 기법

 하나의 IP 네트워크 주소를 내부에서 적절히 분할하여 실제로는 여러 개의 서로 연결된 지역 네트워크로 사용하는 것을 서브넷이라고 한다.

위 네트워크는 141.x.x.x 로 시작하기 때문에 B클래스임을 파악할 수 있고, 이에 따라 2bytes 까지가 네트워크 주소임을 알 수 있다. 이미지상 서브넷을 4개로 분리하고, CIDR 로 18을 표기한 것을 보면 그 2bytes 네트워크 주소 내에서 다시 4개의 서브넷 주소를 사용하겠다는 것을 파악할 수 있다. 즉, 18bit 까지는 네트워크 주소로 활용하며, 나머지 14bit 는 각 네트워크에 호스트 주소로 할당될 것이다.

이 경우  서브넷  마스크는 255.255.255.192 가 된다.

사설 IP

사설 IP는 공인 IP (인터넷 할당 번호 기관 IANA 에서 할당하는 주소)와 대비되는 개념으로, 사설 네트워크 내에서 사용하기 위해 예약된 주소이다. 

홈, 사무실, 학교 네트워크 등 여러 개인 네트워크에서 중복으로 사용될 수 있는 주소로, 이는 공인 IP 주소가 부족한 문제점을 해결해 줄 뿐만 아니라, 외부에서 내부로는 직접 접근이 불가능해 보안 또한 강화 된다. 

사설 IP를 무선 네트워크 공유기에서 관리하는 경우를 예를들면, 새로운 디바이스(핸드폰, 노트북 등)가 해당 와이파이에 연결되었을 때 동적으로 192.168.0.1, 192.168.0.2 와 같이 사설 IP 주소를 할당하는 방식으로 동작한다. 다만 만약 옆방에 무선 네트워크 공유기가 설치된다면 192.168.100.x 와 같이 다른 네트워크 주소를 사용해야 할 것이다.

또한, 결국 로컬 네트워크 외부로 나가려면 공인 IP 주소가 필요한데, 이는 공유기에서 NAT(Network Address Translation) 프로그램을 통해 사설 IP 와 공인 IP 를 매핑하는 방식으로 이루어진다. NAT 에 관한 내용은 추후에 살펴보도록 하자. 

DHCP

dynamic host configuration protocol 의 약자로, 호스트에게 dynamic 하게 유동 IP를 할당하는 프로토콜이다. DHCP client, server 가 함께 동작해야 하며 주로 AP나 gateway 에서 DHCP server 역할을 수행한다.

사실 DHCP는 응용계층의 프로토콜이다. 그럼에도 3계층에서 소개하는 이유는 IP와 관련한 동작이 핵심인 프로토콜이기 때문이다. DHCP client server 는 다음과 같이 동작한다. 



위 과정에 내부 데이터를 들여다 보면 다음과 같다.

68번 포트는 DHCP client 를 나타내며, 67번 포트는 DHCP server 를 나타낸다. 이는 http 가 port 80을 사용하기로 약속한 것처럼 이는 미리 정해져있는 규약이다. 자세한 동작 방식은 다음과 같다.

1. client 는 처음 와이파이 등에 접속했을 때 IP주소를 할당받지 못한 상태에서, 시작 주소는 0.0.0.0 으로, 시작포트는 68 로 설정한 후, 브로드캐스팅을 위해 도착 주소는 255.255.255.255 로, 도착포트는 67번으로 설정하여 데이터를 전송한다.
2. 해당 데이터를 전송받은 인접한 노드들은 4계층에서 전송받은 세그먼트의 헤더에서 포트를 확인한다. DHCP 서버만 67번 포트를 사용하기 때문에 discover 요청은 DHCP 서버 기능을 수행하는 노드에 무사히 도달할 수 있다.
3. DHCP offer 과정에서 yiaddr 에 새롭게 유동 IP 주소를 할당하여 클라이언트에게 돌려준다. 여전히 해당 클라이언트는 IP주소가 없는 상태이기 때문에, 도착 주소는 브로드 캐스팅을 위해 255.255.255.255 로 설정되고, 도착포트는 68번으로 설정된다.
4. 해당 데이터를 전송받은 인접 노드 중 68번 포트를 사용하는 클라이언트가 해당 요청이 자신에게 온 것임을 확인한다. 
5. 그 이후 동작으로 클라이언트는 자신이 해당 IP주소를 사용하겠다는 의사를 보내고, DHCP는 이를 승인해주어 클라이언트는 해당 유동 IP를 할당받게 된다. 

DHCP offer 과정에선  lifetime 을 설정하여, lifetime 시간이 지나면 다시 해당 유동 IP를 돌려받는다.

 DHCP offer 과정에서 여러 클라이언트가 동시에 68번 포트를 열고 IP 주소를 할당받기를 기다리는 상황을 가정해보자. 해당 상황에서 DHCP offer 를 전달받은 두 클라이언트는 모두 자신이 해당 유동 IP주소를 사용하고 싶다고 요청을 보내게 될 것이다. 그렇게 된다면 DHCP 서버가 이를 판단하여 DHCP ACK은 하나의 클라이언트에게만 전달하는 방식으로 처리될 것이고, 이에 따라 실제로 같은 네트워크에서 두 클라이언트가 같은 IP주소를 가지는 일은 없을 것이다.

만약 위 문제를 2계층 MAC 주소를 활용하는 방법으로 해결한다면, DHCP request 가 겹치는 일은 없을 것이다(discover 과정에서 클라이언트가 자신의 MAC 주소를 보내고, 서버는 다시 그 MAC주소를 통해 응답하는 방식). 다만, 이는 사실상 구현의 차이에 불과하며 실제로 동시에 DHCP 요청이 겹치는 경우는 많지 않아 MAC 주소 또한 브로드캐스팅으로 처리하는 경우가 많다고 한다.

DHCP 는 유동 IP 주소를 할당하는 기능 외에도 gateway 주소, network mask, name and IP address of DNS server 와 같은 정보를 제공하는 역할 또한 수행한다.  

NAT

network address translation 의 약자이다. 사설 IP 주소를 공인 IP 주소로 바꿔주는 역할을 의미하며, 대부분 게이트웨이에 어플리케이션 레이어에 구현되어 있다. DHCP와 마찬가지로 3계층에 속하진 않지만, IP주소와 관련한 핵심 동작을 수행하기 때문에 중요하다. 다음 이미지는 NAT의 동작방식을 잘 설명한다.

하지만 만약 외부에서 로컬 네트워크에서 먼저 요청을 보내는 경우는 어떻게 처리해야 할까? 로컬네트워크에 서버 컴퓨터가 존재하는 상황을 예로 들 수 있다. 

이와 같은 경우에는 미리 게이트웨이에 해당 서버의 주소와 포트를 매핑해 놓는 방법으로 해결하며, 이를 포트 포워딩이라고 한다.

ICMP

이는 internet control message protcol 의 약자로 3계층 프로토콜에 속한다. IP와 같은 계층에 속하지만, 이는 사실 IP 위에서 동작한다. 즉, 데이터를 전송할 땐 IP의 방식을 그대로 따른다.

ICMP 에선 host 나 router 간의 다양한 네트워크 관련 정보 교환을 위해 오류 보고, 에코 기능 등 여러가지 타입과 코드들을 정의해 두었다. 정보의 타입을 ICMP 헤더에 명시하는 방식으로 정보 교환이 이루어진다. 

ICMP 헤더의 구조는 다음과 같다.

수신된 IP 패킷의 대한 정보를 전달하기 위해 해당 헤더를 보존하며, 그 헤더에 다시 ICMP헤더를 붙이고, 이를 전송하기 위해 IP헤더를 붙여서 이를 전송한다. 

그 뒤에 8bytes 는 정보를 교환할 때 추가로 필요한 데이터가 존재한다면 사용하는 공간으로, 간단한 에러 정보 교환에는 사실상 쓰이지 않을 것이다.