L3 - 4. TTL과 단편화, DHCP, ARP, Ping과 RTT

인터넷은 라우터의 집합체라고 할 수 있는 논리 네트워크이다.

• 인터넷을 구성하는 핵심 요소
  • Router
  • DNS
• Routing의 역할
  • 택배 기사님 혹은 물류 센터
  • 정보 자체를 자신이 수집하는 것이 아닌 라우터를 거쳐서 다른 라우터로 이동하는 역할

TTL(Time To Live)과 단편화(Fragmentation)

TTL

IPv4 Header 형식에 대해서 공부할 때, 헤더의 구성 요소 중 TTL이라는 것이 있다는 것을 공부했다. 그렇다면 TTL이 무엇일까?
만약 Packet이 인터넷을 돌아다니면서 결국 어떤 목적지(Dst)까지 도달해야하는데 간혹 어떤 이유로 도달에 실패하는 경우가 있다. 실패했다는 것은 라우터를 타고 라우팅을 계속 하면서 목적지를 끝내 못 찾은 경우에 해당하는데, 이럴 경우에는 이 Packet을 빨리 찾아서 폐기를 시켜줘야한다. 그렇지 않다면 이 packet은 좀비처럼 계속 살아 남게 되고, 좀비 packet이 네트워크에 넘쳐나서 결국 network가 down되는 문제가 발생할 수 있다. 이걸 막는 역할을 하는 것이 TTL이다.
128 혹은 255의 8bit 값에서 출발을 한다. 만약 128이라는 값에서 출발을 했다면 라우터에서 라우터를 지날 때, 이 hop(하나의 라우터에서 다른 라우터로 옮겨갈 때의 단위) 단위로 지나갈 때마다 TTL값을 128이라는 출발 값에서 -1만큼을 해서 다음 라우터로 보낸다. 계속 -1씩 하다가 라우터를 TTL 값만큼 거쳤음에도 불구하고 목적지를 찾지 못했으면 실패로 판단하고 결국 이 packet을 폐기하는 것이다.

• 세포의 '텔로미어' 같은 역할을 한다.
• 단편화는 MTU크기 차이로 발생한다.
• 단편의 조립은 수신측 Host에서 이루어진다.

단편화(Fragmentation)

작은 packet 하나를 또 자르는 것. 보통 MTU는 1500Bytes의 값을 갖는데 간혹 1400Bytes라던지 일반적인 값보다 작은 값을 갖는게 중간에 끼어 있는 경우가 있다. 이런 경우에는 1400Bytes의 용량을 가진 라우터는 수신 용량의 한계가 1400Bytes 밖에 안되는데 크기가 1500Bytes인 packet을 1400Bytes 라우터에 보내면 수신을 못하게 되어 수신이 유실된다. 따라서 이런 경우에 라우터의 수신 용량이 작으니 1500Bytes를 조각내서 보내는 것이 단편화이다.
그렇다면 어떤 방법으로 자를까?

위의 그림과 같이 payload를 둘로 쪼개어서 쪼갠 payload 둘에 각각 header를 붙이는 방식이다. 두개의 header는 flag, option 등 디테일한 구성에서는 차이가 있지만 기본적인 구성은 같다. 이제 하나였던 packet이 두개가 되어버렸다. 이렇게 단편화가 발생한 packet은 수신측 server에 도착하면 server의 End-point에서 단편화 된 두 개의 packet을 조립을 한다. 이러한 조립 역할은 Server의 L3계층 IP에서 수행하며, 조립이 된 상태에서 L4 계층에서 Segment를 Decaptulation해서 Process로 전달하는 것이다.
단편화는 효율에 부정적인 부하를 줄 수 있기 때문에 가급적이면 발생하지 않는 것이 좋다. 따라서 단편화가 발생하지 않게 하기 위해서 송신측에서부터 라우터 중 가장 낮은 MTU를 가진 크기만큼으로 해서 보내면 단편화를 피할 수 있다.
현대의 네트워크 환경에서 MTU가 1500Bytes가 안되는 경우는 거의 없다. 그렇다면 언제 발생할까? VPN의 경우에 주로 발생할 수 있다.

인터넷 설정 자동화를 위한 DHCP

우리가 집에서 사용하는 인터넷을 사용하기 위해서는 사용 전에 해주어야 하는 설정이 몇가지가 있다.

• IP 주소
• Subnet mask
• Gateway IP주소
• DNS 주소
  그런데 이러한 작업을 우리는 수동으로 직접 해결하지 않는다. 보통은 자동으로 이 과정을 모두 수행해준다. 이 자동으로 수행해주는 과정이 바로 DHCP를 활용하겠다는 의미이다.

DHCP(Dynamic Host Configuration Protocol)

network 상의 server가 존재한다. 이 서버에서는 자동화 하는데 필요한 모든 설정의 정보를 가지고 있는 pool이 있다. 클라이언트가 접속을 하면 서버에 자동화하는데 필요한 정보를 알려주라고 하면 서버가 해당 정보를 알려주는 것이다.
Dynamic이라는 이름이 붙은 것은 Static하게 값이 고정되어 있는 것이 아니라 사용 중에 동적으로 이러한 과정이 이루어지기 때문이다.

• DCHP체계는 주소를 할당하는 서버와 할당 받으려는 클라이언트로 구성된다.
• 복잡한 인터넷 설정을 자동으로 해준다고 볼 수 있는데 핵심은 사용할 IP주소를 서버가 알려준다는 것에 있다.

DHCP의 동작 방법은 다음과 같다.
Client PC가 네트워크망 전체에 "DHCP Server 있어?" 라는 내용의 broadcast를 발생시킨다(discovery). 그러면 이 요청을 받은 DHCP 서버는 "여기 있어"라는 응답을 보낸다. 응답을 보내면 다시 Client PC는 "나 000.000.0.0 IP 사용해도 돼?" 라고 묻고 이에 응답으로 DHCP가 "응 써도 돼" 혹은 "아 그거 다른 애가 쓰고있으니 안돼. 대신 000.000.0.1 이걸 써" 라고 응답을 보내주고 그 응답을 기준으로 Client PC는 필요한 설정을 하게 되는 것이다. 예시에서는 단순히 IP주소만 입력했지만 실제로 응답값에는 인터넷 설정에 필요한 정보들이 모두 담겨져있다.

ARP(Address Resolution Protocol)

ARP에서 얘기하는 address는 무엇을 의미하는 걸까? IPv4 주소 + MAC 주소를 이야기한다. 이 두 주소는 보통 쌍을 이룬다.
그렇다면 ARP는 무엇일까? 바로 IP주소로 MAC주소를 알아낼 때 활용한다. 이보다 중요한 것은 이런 경우가 대체 언제일까? 우리는 Gateway의 MAC주소를 알지 못하면 인터넷을 사용할 수 없기 때문에 Gateway의 MAC주소를 찾아내기 위해 ARP Request(broadcast)가 발생하며, 이에 대응하는 Reply로 MAC주소를 알 수 있다.
기본적인 작동 방식은 DHCP와 비슷하다. Naver의 DNS의 IP주소가 3.3.3.3이고, Client PC의 IP주소가 192.168.0.100이며 Gateway의 IP주소는 192.168.0.1이라고 가정을 한다. 컴퓨터의 전원을 키면 DHCP 서버에 요청을 보내고 그 응답으로 인터넷 사용에 필요한 설정을 마친 후에 MAC address를 얻기 위해 다시 한 번 ARP Request를 보내는 broadcasting을 한다. 이 broadcasting을 받은 Gateway가 주소를 알려주는 것이다. 이때 Gateway의 Reply는 "내 IP주소는 192.168.0.1 이고 MAC 주소는 ~야."의 형태로 오게 된다.
추가로 Client가 naver에 접속하려고 할 때 Packet이 생성되어 전달이 되는데, 이 packet은 다음과 같은 형태로 이루어져있다.

위의 구조에서 가장 중요한 것은 목적지 MAC Address가 Gateway의 MAC Address로 잡힌다는 것이다. 이후 Gateway가 목적지의 IP를 보고 이 목적지로 움직이는 것이다.
PC 입장에서는 한번 Gateway의 주소를 알아내고 나면 알아냈는데 매번 다시 묻는것은 비효율적이니 이 Gateway주소에 대한 내용을 Caching하여 memory에 저장해놓는다.
이 정보를 직접 확인해보기 위해서는 arp -a 옵션을 명령 프롬프트에 입력하면 직접 확인해 볼 수 있다.

Ping과 RTT(Round Trip Time)

Ping은 결국 하나의 프로그램인데 ICMP(Internet Control Message Protocol)를 이용해서 RTT(Round Trip Time)를 측정하는 목적으로 사용한다. 그렇다면 RTT는 무엇을 이야기하는걸까?
내가 게임을 하고 있는데, 게임 서버와 통신을 하기 위해서 게임 서버와 요청과 응답을 주고 받는데 걸린 시간을 이야기 한다. 이 측정한 RTT는 인터넷의 회선 속도를 결정하기 위해 사용하며, 이 RTT를 측정하는데 사용하는 가장 보편화된 프로그램이 ping인 것이다.