(네트워크) TCP/IP 쉽게, 더 쉽게 목차 리뷰 - 4장 라우팅과 인터넷 계층
오래전에 이 책을 추천받았으나 최근에 읽어보게 되었다.
백엔드 개발자로 일하면서 프론트 엔드 개발자와 의사소통을 원활히 하기 위해서는 서로 네트워크에 대한 기본 지식이 있어야하는 것 같다.
이 글은 빠르게 목차를 리뷰하며 백엔드에게 필요한 내용인지, 프론트에게 필요한 내용인지, 공통적으로 알아야하는 내용인지 개인적인 기준에서 분류해봤다.
들어가기에 앞서
내가 여태까지 봐왔던 네트워크 계층 설명글들은 대부분 OSI 7 Layer를 기준으로 설명을 풀어나가고 있다.
OSI 7 Layer는 각 계층이 하는 역할이 명확해서 설명하기가 명쾌하다.
하지만 이론과 현실 사이의 괴리감이랄까… OSI 7 Layer는 구현하기가 복잡하거나, 성능 등등의 이슈(굳이 여러 계층으로 쪼갤 필요 없이 하나의 장비가 여러 역할을 수행하는 게 더 나을 때도 있으므로)로 인해
실제 구현된 건 대부분 4계층으로 구성된 TCP/IP Stack으로 구현이 많이 돼있다.
이 책은 신기하게도 TCP/IP Stack에 기반해서 각 계층의 역할을 설명하고 있다.
따라서 진짜 구현된 모델에 대한 이해를 증진시키는 데는 좋은 것 같으나 당장 AWS나 다른 글들을 보면 L4니 L2니 L7이니 해서 OSI 7 Layer로 설명된 글들이 많아서
OSI 7 Layer와 책에 설명된 TCP/IP Stack을 매핑시켜 이해하기 위해 책 앞 부분을 많이 왔다갔다 해야하는 단점이 존재하는 것 같다.
또한 책이 TCP/IP Stack에 대한 전반적인 내용을 200페이지도 안 되는 분량으로 녹여내다보니 전반적인 흐름을 알기는 좋으나
각각의 계층에 대해 딥하게는 다루지 않고, 그림도 아기자기 잘 설명돼있어서(+풀컬러) 입문 서적으로 좋은 것 같다.
여기서부터는 프론트는 딱히 몰라도 된다고 생각하는 내용이므로 목차 뒤에 F/B를 구분해서 달지 않겠다.
예를 들면 프론트는 클라이언트 측에 웹서비스를 제공해주는 일을 하는데 그 중에서 서버가 제공해주는 API로 통신을 해서 데이터를 땡겨와야 한다.
웹서비스를 제공하기 위해서는 HTTP(S) 프로토콜을 사용하고, 서버의 API와 통신할 때도 HTTP(S)로 통신을 한다.
HTTP 프로토콜은 정보 공유를 위해 만들어진 프로토콜이므로 엄청난 수의 클라이언트가 접속하게 된다.
통신을 위한 통로에 수십만명이 한 번에 들어오게 끔 하면 가능한지도 모르겠고, 매번 그 만큼의 사람이 들어오는 것도 아니고, 비용 낭비도 엄청날 것이다.
따라서 통신을 위한 통로를 독점하는 게 아니라 항상 연결을 맺고 끊어서 다른 사람들이 원활하게 접속을 하게 해준다.
예를 들면 이 통로를 통해서는 동시에 100명만 들어올 수 있게 만들고 나한테 볼 일이 끝난 애들은 다 연결을 끊는 것이다.(사실 이런 설정은 백엔드가 한다.)
이 때 연결을 위해 사용하는 프로토콜이 TCP 프로토콜이다. (UDP 프로토콜도 있지만 웹 서비스 내에서는 대부분 데이터를 손실없이 전달해주는 TCP 프로토콜을 사용한다.)
따라서 프론트 엔드 개발자라면 HTTP 프로토콜은 물론이고 TCP 프로토콜까지 알아야 어떻게 하면 통신을 최적화 할 수 있을지 생각할 수 있게 된다.
백엔드의 경우에는 HTTP(S), TCP 프로토콜만 안다고 해서 끝나는 게 아니다.
SSH 프로토콜을 이용해서 서버에 원격으로 붙어서 명령어를 날리기도 하고, FTP 프로토콜을 이용해서 파일 업로드/다운로드가 가능한 서버를 설계해야할 수도 있기 때문이다.
SSH 프로토콜을 사용하려면 여러 인증 방식 중에 키로 인증하는 방식이 있는데 그럼 공개키, 비공개키, 대칭키, 비대칭키 막 이런 내용이 나오는데 이런 보안적인 요소도 알아야한다.
이 내용은 HTTPS에 사용되는 TLS 인증서의 암호화 방식에도 적용된다.
또한 동영상 스트리밍 서버를 만든다고 하면 UDP 프로토콜을 사용한다.
기본적으로 TCP 프로토콜은 해주는 일이 많으므로(데이터 전송에 실패하면 재전송 처리 등등) 성능이 안 받쳐주는데
UDP 프로토콜(보내기만 할 뿐, 잘 받았는지 확인을 하지 않는다. 그래서 가끔 동영상이 깨져서 나오는 현상들이 나온다.
하지만 크리티컬한 이슈는 아니고 매번 똑같은 부분에서 동영상이 깨져나오는 게 아니고 네트워크 상황에 따라 달라지기 때문이다.)은 그거보다 성능이 낫기 때문이다.
또한 AWS를 사용하다보면 그 아랫단인 IP/Router/Subnet Mask 등등의 영역도 잘 알아야한다.
보안을 위해 외부에서 접근이 가능한 요소(다양한 요청을 분산해주는 로드 밸런서)와 내부에서만 접근이 가능한 요소(웹서버, DB 등등)을 구성해야하는데…
그러면 네트워크를 어떻게 구성해야할 것이며, 이 네트워크 안에 서버는 몇 대를 둘 것이며, 퍼블릭 요소들과 프라이빗 요소들은 어떻게 통신을 할 것이며
어떤 요청들을 받고 말지 네트워크부터 보안에 대한 요소들을 직접 다뤄야하는 경우가 오는데 이럴 때 이 내용들을 알고 있으면 정말 무릎을 탁 치게 되는 날이 온다.
더 아랫단이나 부가적인 요소들은 알면 +@, 몰라도 그만인 것 같은데 호기심이 충만하면 알고 싶을 것이다.
위에서 설명하지 않은 모뎀, 이더넷 카드, 랜선 등등은 사실 하드웨어 단으로 내려가는 거니 백엔드가 굳이 알 필요가 있나 싶다.(물론 알면 좋다.)
또한 데이터 전송에 실패했을 때 어떤 전략으로 재전송시킬 것인지(어플리케이션 단이 아닌 하드웨어 단에서 패킷을 처음부터 전송할 건지, 실패한 부분을 알아내서 그거부터 전송할 것인지)
이런 내용들은 내가 봤을 때는 굳이 알 필요가 있나 싶은데 분명 알아두면 어딘가는 써먹을 일이 있을테니 공부해둬야할 것 같긴 하다.
목차
4장, 라우팅과 인터넷 계층
OSI 7 Layer 기준 L3(Network Layer)이다.
IP 주소를 가지고 송신지로부터 수신지로 데이터를 전달하는 역할을 수행한다.
유선 전화번호가 지역 번호를 내장하고 있는 것과는 달리 IP 주소는 지역 정보로 구분되는 게 아니라 네트워크 단위로 할당이 된다.
따라서 IP들을 보면 같은 네트워크에 속해있는지, 소규모 네트워크인지 대규모 네트워크인지 정도만 알 수 있다.
그리고 각 네트워크들은 라우터라는 장비를 통해 연결이 되므로 라우팅 테이블이 복잡하게 연결돼있으면 지리상으로 가까운데도 불구하고
데이터 전송을 하는데 오래 걸리는 경우도 존재한다.
반대로 지리상으로 먼데 라우팅 테이블이 잘 설계돼있으면 금방 데이터가 도착할 수도 있다.
4-1. 인터넷 계층의 역할
IP 주소로 데이터를 전달하는 역할을 한다.
바로 다이렉트로 목적지 IP 어드레스를 찌르는 게 아니라 라우터(Router)라는 장비들을 통해서 전송이 이루어진다.
클라이언트는 인접한 라우터를 찾고 그 라우터는 또 인접한 라우터들을 찾아서 데이터를 보내려는 목적지와 인접한 라우터까지 이 과정이 반복되고
최종 라우터에서 목적지로 데이터를 보낸다.
이렇게 라우터를 통해 목적지의 경로를 찾아가는 작업을 라우팅(Routing)이라고 부른다.
간단하게 가정집을 시나리오로 생각해보자.
- 내가 웹 브라우저를 통해 네이버로 접속하려고 한다.
- 내 컴퓨터가 공유기(라우터의 역할을 수행한다)로 데이터를 쏜다.
- 공유기는 모뎀(얘가 라우터의 역할도 한다)로 데이터를 쏜다.
- 공유기는 다른 라우터들을 통해서 ISP(올레나 SK 브로드 밴드 등등의 인터넷 서비스 제공자) 라우터로 토스를 한다.
- 그 라우터가 다른 수많은 라우터를 거쳐 네이버 서버와 연결된 라우터까지 간다.
- 해당 라우터가 네이버에게 요청을 보낸다.
요즘 들어 핸드폰이며 TV며 냉장고며 IoT가 나오기도 하고 온갖 사물들이 인터넷과 통신을 하면서 IP 주소를 막 할당받기 시작했다.
그러면서 진작부터 IP 주소가 고갈되기 시작했다.
그래서 등장한 것이 Private IP(사설 IP)이다.
공유기를 쓰면 내 컴퓨터와 다른 사람의 컴퓨터가 다른 IP를 사용하는 것 같은데
이건 내부적으로 사용하는 private IP나 다른 것이지 외부로 달고 나가는(외부에서 접속 가능한) Public IP(공용 IP)는 하나만 존재한다.
그리고 외부에서는 하나의 IP만 할당한 것으로 보이기 때문에 이런 방식으로 IP 주소 부족의 문제를 해결하고 있다.
이런 방식과는 별개로 IPv4 주소가 32비트(2^32, 약 42억)여서 42억 개의 IP만 할당이 가능한 데 비해
IPv6의 경우에는 128비트(2^128, 3.4028237e+38)로 단위로 표현할 수도 없는 갯수의 IP 할당이 가능하다.
하지만 여러 기술의 도입으로 인해 아직 IPv6를 사용하지 않아도 되는 수준인지 IPv6는 딱히 써본 적이 없다.
IPv4는 IP 프로토콜을 사용하는데 반해 IPv6는 IPSec이라는 프로토콜을 지원해서 패킷 자체를 암호화하고 있다.
그리고 IPv4는 사람한테 익숙한 10진수를 쓰긴 했는데 마지막 자리가 255라는 애매한 숫자로 떨어지는데
IPv6는 16진수를 사용해서 마지막 자리가 FF로 떨어져서 그나마 가독성이 조금 올라간 것 같다.
4-2. IPv4와 IPv6
4-2-1. IPv4는 32비트 어드레스
IP 주소는 인터넷 계층(혹은 L3) 장비에만 할당되기 때문에 이더넷 카드나 모뎀 등등에는 할당되지 않는다.
4-2-2. IPv4 헤더
IPv4 패킷의 헤더에는 송수신지 IP 어드레스나 생존기간, 프로토콜, 체크섬, 버전, 우선순위, 패킷 전체의 길이 등등을 담고 있다.
4-2-3. IP 패킷에도 유통기한이 있다.
HTTP 1.1 스펙에서 Keep-Alive를 통해 TCP 커넥션의 유효기간을 설정하듯이
IP 패킷에도 생존기간을 설정할 수 있다.
IP 패킷의 TTL(Time to Live)를 7홉(Hop)으로 설정하면 라우터를 하나 탈 때마다 TTL이 하나씩 깎인다.
7홉 내에서 목적지까지 도착하지 못하면 해당 패킷은 소멸된다.
패킷을 라우터를 찾기 위해 무한정 뺑뺑이 돌리면 효율이 떨어지므로 TTL이 있는 것 같다.
4-2-4. 좁은 길을 지날 때는 작게 분할해서 지나간다.
한 번에 전송할 수 있는 데이터 크기를 MTU(Maximum Transmission Unit)라고 하고
통신 경로의 상태(라우터의 상태)에 따라 달라진다.
패킷을 보낼 때 다음 라우터의 MTU보다 작으면 해당 MTU 만큼 패킷을 쪼개서 보낸다.
하지만 패킷이 중간에 유실되면 복구하기 어려우므로 처음부터 전체 경로에 대해서 MTU를 구하고 해당 MTU만큼 보내는 게 제일 안전하다.
4-2-5. 데이터를 분할하고 복원하는 방법
패킷 헤더를 보면 아래와 같은 필드로 데이터를 분할하고 복원한다.
- 식별자: 같은 데이터인지 식별하기 위한 16비트 숫자 값
- 분할 플래그: 분할 허가 플래그와 이후에 남은 분할이 있는지 표시하기 위한 플래그
- 프래그먼트 옵션: 원래 데이터에서의 위치 값을 표현하는 13비트 숫자
위 헤더 필드를 통해 데이터를 분할하고 복원하게 된다.
4-2-6. IPv6
IPv4 주소(32비트)의 고갈로 인해 등장(128비트)했는데 private IP 등등의 기술로 인해 IPv4에 산소호흡기를 달아놓은 상태이다.
헤더를 보면 버전, 패킷의 우선순위를 결정하는 트래픽 클래스, 데이터 부분의 길이를 담당하는 페이로드의 길이, TTL을 나타내는 홉 리미트, 송수신지 IP 어드레스 등등이 있다.
4-2-7. IPv6로 갈아타기
소프트웨어를 새로운 버전으로 마이그레이션 하거나 다른 소프트웨어로 마이그레이션 하는 것은 상당한 일이다.
IPv4와 IPv6의 패킷은 서로 호환이 되지 않기 때문에 송신지는 IPv6를 쓰는데 수신지는 IPv4를 쓰는 난감한 상황이 존재하기 마련이다.
이런 점을 방지하고자 하나의 장비에서 IPv4, IPv6 두 어드레스를 지원하는 듀얼스택(Dual Stack)이란 기술도 있고,
터널링(tunneling)이라는 기술을 통해 IPv6가 오면 IPv4로, IPv4가 오면 IPv6로 변환해주는 기술들이 존재한다.
4-3. IP 어드레스의 활용
4-3-1. 네트워크 부와 호스트 부
IP 어드레스는 네트워크 부분과 호스트 부분으로 구성된다.
호스트는 네트워크에 구성된 장비(PC, 스마트폰 등등)을 의미한다.
라우터는 송신지 IP 어드레스의 네트워크 부분을 보고 자신과 같은 네트워크에 있는지 외부의 네트워크에 있는지 판단한다.
네트워크 부분과 호스트 부분을 나눈 이유는 모든 호스트들을 하나의 네트워크로 묶어두면 관리하기 어렵다는 측면에서 나오게 되었다.
4-3-2. 어드레스 클래스
하나의 IP 어드레스를 봤을 때 어디까지가 네트워크 부분이고 어디까지가 호스트 부분인지 알 수가 없다.
A, B, C, D 클래스에 따라서 네트워크 부분과 호스트 부분의 경계를 알 수 있는데
해당 IP를 보고 어떤 클래스에 속했는지는 32비트 중에 앞에 2비트만 보면 알 수 있다.
앞에 1비트가 0이면 A 클래스, 앞에 2비트가 10이면 B 클래스, 앞에 3비트가 110이면 C클래스가 된다.
예를 들면 116.322.45.26을 32비트로 바꾸면 아래와 같다.
01110100 101000010 00101101 00011010
앞에 1비트가 0이므로 A 클래스에 속하는 IP 주소가 된다.
A 클래스의 IP 범위는 0.0.0.0 ~ 127.255.255.255가 되고,
B 클래스의 범위는 128.0.0.0 ~ 191.255.255.255가 되고,
C 클래스의 범위는 192.0.0.0 ~ 223.255.255.255가 되고,
D 클래스는 멀티 캐스트를 위해 사용되는데 224.0.0.0 ~ 239.255.255.255까지 사용되고, 특이하게 네트워크 부분으로 32비트 전체를 다 사용하고,
E 클래스는 240.0.0.0 ~ 255.255.255.255로 미래를 위해 만들어뒀다고 한다.
A 클래스는 8비트까지가 네트워크 부분인데 앞에 1비트인 0은 고정이므로 실제는 7비트만 사용 가능하고 따라서 128개의 네트워크를 만들 수 있을 거 같은데 책에는 126개라고 나와있다.
또한 호스트는 24비트를 사용가능해서 약 1677만개의 호스트가 하나의 네트워크로 묶일 수 있다.
매우 대규모의 호스트를 수용할 수 있으므로 특수한 정부 기관 등등에서 쓰이지 않을까 싶다.
B 클래스는 16비트까지가 네트워크 부분인데 앞에 2비트인 10은 고정이므로 실제는 14비트만 사용해서 약 만 6천 개의 네트워크를 구성할 수 있다.
그리고 호스트 부분은 16비트를 사용할 수 있어서 약 6만 5천대의 장비를 연결할 수 있다.
아마 대기업/중견기업 정도에서 쓰지 않을까 싶다.
C 클래스는 24비트까지가 네트워크 부분인데 앞에 3비트인 110은 고정이므로 실제는 21비트만 사용해서 약 209만 개의 네트워크를 만들 수 있다.
그리고 호스트 부분은 8비트만 사용해서 약 254개의 장비를 연결할 수 있다.
일반 가정집이나 중소 기업에 어울리는 네트워크 클래스인 것 같다.
8비트라 256개라고 생각할 수 있지만 호스트의 마지막 부분인 255는 브로드캐스팅을 위한 IP로 사용된다.
모든 호스트가 브로드캐스팅 IP를 리스닝 하고 있다고 생각하면 된다.
그리고 호스트의 첫 번째 부분인 0은 네트워크 주소로써 해당 호스트에 속한 모든 IP를 관리하기 위한 IP이다.
따라서 8비트(0~255) 중에 0과 255는 특수한 목적으로 쓰이기 때문에 호스트는 총 254개만 사용 가능한 것이다.
VPC는 가상의 네트워크라고 보면 된다.
IP 주소 범위를 보면 10.2.0.0으로 0.0.0.0 ~ 127.255.255.255에 속하니까 A 클래스 IP 주소이다.
4-3-3. 어드레스 클래스의 제약
클래스 A 같은 경우에 1677만대가 연결된 완전 초대규모 네트워크라고 볼 수 있다.
하지만 실제로 하나의 네트워크에서 1677만대의 호스트를 전부 연결하는 곳은 거의 없기 때문에
많은 IP 어드레스가 사용되지 않고 낭비된다는 단점이 존재한다.
당장 내가 위에 만든 VPC만 봐도 A 클래스인데 과연 1677만대의 호스트를 등록할 일이 있을까?
또한 126개의 네트워크보다 더 많은 네트워크를 구성하고 싶을 수도 있을 때는 어떻게 해야할까?
4-3-4. 서브넷 마스크(Subnet Mask)
A클래스의 IP이지만 최대 2만대의 호스트만 수용할 예정이라면 15비트(약 3만대의 호스트 수용 가능)만 호스트 부분으로 사용하고,
32비트에서 15비트를 뺀 17비트를 네트워크 부분으로 사용하면 어드레스의 낭비를 훨씬 줄일 수 있다.
A 클래스의 IP이지만 A 클래스보다 훨씬 적은 호스트를 수용할 예정이고, A 클래스 보다 많은 개의 네트워크를 구성해야한다면 서브넷 마스크를 사용하면 된다.
위의 경우에는 앞에 IP 주소 17비트만 맞으면 동일한 네트워크라고 인식을 시켜야한다.
주어진 IP 주소와 서브넷 마스크를 논리 비트 연산자인 &로 AND 연산을 수행했을 때 참이 나오게 해야한다.
따라서 17비트에 대한 서브넷 마스크는
11111111 11111111 10000000 00000000
앞에 17비트를 1로 설정하면 되고, 10진수로 표현하면 255.255.128.0이 된다.
그리고 CIDR 블록이란 걸 적용시켜서 표현해보자면 10.2.0.0/17이 된다.
위 스크린샷에서는 10.2.0.0/16이므로 사실상 A 클래스의 IP 주소를 B 클래스의 IP 주소와 같이 분할을 시킨 것이다.
위 공식을 적용시켜 보자면 A 클래스는 네트워크 부분이 8비트이므로 기본 서브넷마스크는 255.0.0.0이 되고 CIDR 블록으로 0.0.0.0/8 과 같은 형태로 표시된다.
B 클래스는 네트워크 부분이 16비트이므로 기본 서브넷 마스크는 255.255.0.0이 되고 CIDR 블록으로 적용시켜 보면 128.0.0.0/16과 같은 형태가 된다.
C 클래스는 네트워크 부분이 24비트이므로 기본 서브넷 마스크는 255.255.255.0이 되고 CIDR 블록으로 적용시켜 보면 192.0.0.0/24와 같은 형태가 된다.
기본적으로 가정집에서는 C 클래스의 IP를 사용하고 서브넷 마스크를 기본적으로 설정하지 않으면 디폴트 서브넷 마스크인 255.255.255.0이 적용된다.
4-3-5. IP 어드레스의 할당 방법
IP 어드레스는 네트워크 상에서 호스트(컴퓨터, 라우터, 스마트폰 등등)을 식별하기 위해 사용되는데,
전체 32비트 중 네트워크 부를 제외한 호스트 부분만 자유롭게 할당할 수 있다.
이 때 호스트 부분이 모두 0인 건 네트워크 주소로 사용되고, 모두 1인 건 브로드캐스트 주소로 사용된다.
4-3-6. 서브넷 마스크로 네트워크 세분화하기
다시 한번 AWS의 VPC를 보자.
원래는 A클래스인 걸 네트워크 부분을 16비트로 바꿔서 B클래스로 바꿨으니 이것도 네트워크를 세분화 했다고 할 수 있다.
이런 걸 서브넷(Sub Network)라고 부른다.
하지만 여기서 끝이 아니다, B클래스를 다시 C클래스나 다른 서브넷 마스크를 사용해서 서브넷 안에 서브넷을 또 만들 수 있다.
기존에 10.0.2.0/16이었던 네트워크를 다시 CIDR Block을 10.2.0.0/24로 나누었다.
서브넷 마스크는 255.255.255.0이 됐고, 네트워크 부분이 24비트이므로 C클래스 IP 주소로 네트워크를 쪼갰다.
이렇게 서브넷 마스크를 통해 서브넷을 만드는 행위를 서브넷팅(Subnetting)이라고 부른다.
하지만 이렇게 클래스가 큰 규모에서 더 많은 네트워크를 사용하기 위해, 적은 규모의 호스트를 수용하기 위해 서브넷팅하는 건 매우 효율적이다.
하지만 C 클래스의 IP 주소는 애초에 254개의 호스트만 수용 가능하고, 호스트 부분을 1비트씩 줄일 수만 있고 늘릴 수는 없으므로
그의 절반인 126개, 62개, 30개, 14개, 6개, 2개, 0개 이렇게 줄어들다보니
애초부터 수용가능한 호스트의 갯수가 적은 환경에서는 서브넷팅이 크게 효율적이진 않다.
4-3-7. 가정이나 사무실에서 자유롭게 사용하는 프라이빗 IP 어드레스
프라이빗 어드레스는 같은 네트워크 내에서 충돌만 일어나지 않으면 자유롭게 사용할 수 있는 IP 주소다.
옆집 철수의 private ip가 192.168.1.7이고, 나도 private ip가 192.168.1.7인데 통신이 잘 되는 이유는
둘은 서로 다른 네트워크 상에 존재하기 때문이다.
즉, 다른 공유기에 연결됐기 때문이라고 생각하면 된다.
A 클래스의 프라이빗 IP 어드레스 범위는 10.0.0.0 ~ 10.255.255.255이고,
B 클래스의 프라이빗 IP 어드레스 범위는 172.0.0.0 ~ 172.255.255.255이고,
C 클래스의 프라이빗 IP 어드레스 범위는 192.168.0.0 ~ 192.168.255.255이다.
이 외의 주소들은 전부 퍼블릭 IP이다.
IP 어드레스의 할당 방법을 통해 봤듯이 private ip도 마찬가지로 호스트 부분 내에서 할당 받는다.
이 때 DHCP란 프로토콜을 통해 브로드캐스트 트래픽으로 사용중인 IP 목록들을 파악해서 사용 가능한 ip를 새로운 호스트에게 할당하는 방식으로 진행되는 것 같다.
4-3-8. 퍼블릭 IP 어드레스의 관리
위에 적어놓은 프라이빗 ip는 같은 네트워크 내에서 통신하기 위한 주소이고, 외부 네트워크와 통신하기 위해서는 퍼블릭 IP가 필요하다.
따라서 퍼블릭 IP는 어떠한 경우에도 중복이 일어나면 정상적인 통신이 이루어지지 않는다.
따라서 별도의 기관에서 퍼블릭 IP 주소 할당에 대해 관리를 하고, ISP(올레나 SK 브로드밴드 등등)에서 그런 기관으로부터 미리 IP 주소를 대량으로 임대를 하고
인터넷 가입자들에게 제공해주는 것이다.
그리고 브로드캐스트 주소, 네트워크 주소와 별개로
예약된 IP 주소가 하나 있는데 바로 자기 자신을 가리키는 127.0.0.1이라는 주소이다.
자기 자신을 가리키는 주소이기 때문에 루프백 주소라고 부르기도 한다.
4-4. 라우팅이란?
데이터를 목적지의 IP 주소까지 전달하는 경로를 탐색하는 과정을 라우팅이라고 부른다.
4-4-1. 라우팅과 경로 탐색
라우팅을 통해 찾은 최적의 경로로 데이터를 전달하는데 만약 중간에 다음 라우터에 장애가 발생했으면 다른 라우터로 우회해서 데이터를 전달한다.
4-4-2. 라우팅 프로토콜
데이터가 전송될 경로를 찾기 위해 네트워크 상의 각 라우터는 서로 어떤 라우터와 어떤 라우터가 연결돼있는지 정보를 교환한다.
이 때 라우팅 프로토콜이 사용되는데 대표적으로 BGP, OSPF, RIP 등이 있다고 한다.
4-4-3. 자율 시스템
ISP 같이 규모가 큰 네트워크에서는 몇 개의 네트워크를 하로 묶어 AS(Autonomous System, 자율 시스템)이라는 단위로 관리를 한다.
네트워크 경로를 하나하나 찾는 것보다 AS 같은 큰 덩어리로 라우팅 하면 멀리있는 컴퓨터와도 더 빠른 속도로 통신할 수 있게 된다.
4-5. 라우터와 라우팅 프로토콜
4-5-1. 라우터의 역할
라우터는 네트워크 간의 패킷을 전달하는 역할을 한다.
이 때 라우터는 자신이 가고자하는 목적지의 IP 주소로 가기위해 라우터의 정보를 파악해서 최적의 경로를 구성하게 되는데
라우터는 자기 자신이 가야할 바로 다음 라우터의 주소만 알고 있으면 된다.
그 이전의 라우터의 경로도 몰라도 되고, 다다음 라우터의 경로를 몰라도 된다.
단지 바로 자기가 바로 당장 가야할 경로 그 하나만 알면 그 다음 책임은 그 다음 라우터에게 전가한다.
마치 자기 다음 데이터에 대한 참조값만 알고 있는 자료구조인 링크드 리스트와 매우 유사한 느낌이 든다.
그런 관점에서 링크드리스트의 노드를 라우터에 빗대어 생각해보면 도움이 많이 될 것이다.
그럼 일반적인 인터넷 공유기를 사용하는 가정집에서 네이버로 요청을 보내는 시나리오를 상상해보자.
- 우선 네트워크 내부에 호스트는 프라이빗 ip를 쓰니 192.1.0.3이 프라이빗 IP라고 가정해보자.
- 192.1.0.3 호스트에서는 자기와 제일 인접한 라우터인 인터넷 공유기로 패킷을 보낸다.
- 호스트와 공유기는 같은 네트워크에 속하므로 프라이빗 ip로 통신하고, 대부분 공유기(라우터)의 ip는 호스트 부분이 1인 경우가 많으니 192.168.0.1로 데이터를 보낸다.
- 공유기는 프라이빗 ip와 동시에 퍼블릭 ip도 가지고 있는데 그건 isp로부터 임대받은 ip이다.
- 프라이빗 IP를 퍼블릭 ip로 세탁(전문적으로는 NAT, Network Address Translation, 네트워크의 주소를 변환하는 걸 말한다.)해서 ISP에서 준 모뎀으로 패킷을 보낸다.
- 모뎀에서는 다시 ISP 쪽으로 라우팅을 하면 지지고 볶고 알아서 네이버로 패킷을 전달해서 네이버는 안전하게 데이터를 전달받을 것이다.
5번 과정을 보면 공유기에서 private ip를 public ip로 nat 시켰는데 이는 외부에서는 private ip를 알지 못하기 때문에 응답을 받기 위해선 public ip로 요청을 해야한다.
그러면 공유기에 연결된 모든 private ip가 같은 public ip로 바인딩되서 나가나 생각할 수 있는데 별도의 설정이 없다면 내가 아는 한도 내에서는 그렇다.
4-5-2. 라우팅 테이블
라우터는 라우팅을 위해서 목적지 ip 주소와 목적지로 가기 위한 바로 다음 라우터 주소를 저장한 라우팅 테이블을 들고 있다.
같은 VPC(네트워크) 내부인 10.2.0.0/16에서는 private ip로 통신을 한다는 얘기이고,
그 이외의 ip인 0.0.0.0/0(모든 트래픽)에서는 인터넷 게이트웨이라는 문지기에게 패킷을 보내는데 얘가 라우터 역할까지 수행한다고 보면 된다.
여담으로 aws에서 라우팅 테이블은 특정 서브넷에 적용시킬 수 있다.
4-5-3. 정적 라우팅과 동적 라우팅
라우팅 테이블을 만드는 방법에는 크게 두 가지가 있는데 관리자가 수동으로 라우팅 테이블을 만드는 정적 라우팅과
라우팅 프로토콜을 사용해서 자동으로 경로 정보를 수집해서 라우팅 테이블을 설정하는 게 동적 라우팅이다.
aws의 라우팅 테이블 같은 경우에는 개발자가 직접 세팅하므로 정적 라우팅에 속한다.
대부분의 네트워크는 경로가 매우 복잡하므로 동적 라우팅을 사용한다.
4-5-4. 라우팅 테이블에 목적지 정보가 없을 경우
인터넷에는 수많은 네트워크가 연결돼있기 때문에 모든 네트워크의 통신 경로를 저장하는 건 사실상 불가능하다.
그래서 한 라우터에 목적지에 대한 정보가 없다면 디폴트 라우터를 사용하는데 디폴트 라우터는 0.0.0.0/0으로 세팅돼있다.
디폴트 라우터도 설정돼있지 않고, 목적지에 대한 경로도 설정돼있지 않다면 아마 패킷을 제대로 전달하지 못하고 패킷은 혼자 사망할 것이다.
4-5-5. 동적 라우팅 알고리즘
- 거리 벡터형(RIP, Routing Information Protocol이 사용함.)
목적지까지의 거리를 살펴보는데 이 거리는 지리상 거리가 아니라 라우터를 몇 개 거치느냐를 뜻하며
라우터 하나를 거치는 단위를 1 홉(Hop)이라고 부른다.
가장 홉이 낮은 경로로 라우팅 테이블을 설계한다. - 링그 상태형(OSPF, Open Shortest Path First 프로토콜이 사용함.)
단순히 거리만 보고 판단하는 게 아니라 어떤 네트워크가 고속이며 덜 혼잡한지까지 파악해서
홉은 좀 높더라도 좀 더 빨리 전달할 수 있는 경로로 라우팅 테이블을 설계한다.
4-6. 네트워크 오류를 통보하는 ICMP
ICMP(Internet Control Message Protocol)은 주로 데이터 전송 중에 문제가 생길 경우,
장애 상황을 통보해야할 때 사용한다.
데이터가 제대로 동작하지 않았으면 3번 타입을 보내고,
네트워크에 새로 연결된 장비가 라우터(공유기)를 찾기 위해 10번 타입으로 브로드캐스팅하고,
그 요청을 받은 라우터는 새로운 호스트에게 9번 타입으로 자신의 정보를 알려준다.
ICMP 헤더는 IP 헤더 + 타입 + 코드 + 체크섬으로 구성된다.
4-7. 어드레스 변환
4-7-1. 네트워크 어드레스 변환(NAT)의 동작 방식
내부 네트워크의 호스트가 외부의 네트워크가 통신을 하려면 퍼블릭 ip가 필요하므로 라우터(공유기)에서 퍼블릭 ip로 변환하고 그걸 통해 외부와 통신을 하게 된다.
하지만 외부에서 봤을 때는 여러 호스트들을 하나의 퍼블릭 ip로 퉁쳐서 내보내기 때문에 정확히 어떤 호스트에게 응답을 해줘야하는지 모르게 된다.
이런 상황을 방지하고자 라우터는 NAT 하기 전에 프라이빗 ip를 기억해두고 있다가 응답을 받으면 그 프라이빗 ip로 다시 요청을 전송하는 역할을 한다.
AWS에서 NAT를 쓰는 이유는 주로 두 가지이다.
- 퍼블릭 IP가 없이 프라이빗 IP만 존재하는 서브넷(프라이빗 서브넷, 외부에서 접근 불가능)에서 외부와 통신을 해야할 일이 있을 때
퍼블릭 IP가 존재해야 외부의 응답을 받을 수 있으므로 외부에 요청을 보내고 응답을 받기 위해 NAT Gateway를 사용한다. - 외부로 나가는 IP(Outgoing IP)를 하나로 통제하고자 할 때 사용한다.
외부 연동사에 IP 등록 요청을 해야하는데 네트워크 내의 모든 서버의 IP를 등록해달라고 하기 거시기 하기 때문에 outgoing ip를 하나로 통제할 때 쓰곤 한다.
물론 상황에 따라 네트워크가 속한 지역이나 가용영역 등등에 따라 하나로 통일을 못 하기도 하기는 한다.
4-7-2. NAT에서 발생할 수 있는 제약 사항
서버에서 요청에 대한 응답을 처리해줄 수 있는 것은 라우터에서 어떤 프라이빗 아이피가 퍼블릭 아이피로 매핑됐는지 정보를 기억하고 있기 때문이다.
하지만 역으로 서버 쪽에서 클라이언트 쪽을 찌를 때 라우터는 퍼블릭 IP만을 가지고는 프라이빗 ip를 찾을 수 없어서 통신이 불가능한 상황이 발생한다.
4-7-3. 네트워크 어드레스 포트 변환
공교롭게도 같은 네트워크 상의 호스트가 동일한 목적지로 요청을 보내는데 둘의 포트가 같아버리면
private ip -> public ip 과정에서 포트 충돌이 일어난다.
이러한 상황을 대비해서 NAPT(Network Address Port Translation), 즉 포트까지 같이 변환해야한다.
만약에 포트가 충돌나면 라우터는 포트까지 같이 변환하고 원래 포트를 기억하고 있다가 서버에 대한 응답을 올바르게 전달해준다.
4-7-4. 외부에서 접속이 가능하게 하기.
4-7-4-1. 메시지의 자동 확인
SNS 같은 경우에 보면 알림이 있으면 클라이언트 쪽으로 push notification을 준다.
이는 서버가 클라이언트한테 바로 notification을 주는 게 아니라 내부적으로 클라이언트가 서버를 계속해서 호출해서 가능한 것이다.
아니면 소켓을 하나 뚫어놓고(연결을 맺어놓고 끊지 않고), 알림을 줘야할 내용이 있을 때마다 알림을 주는 경우도 있다.
4-7-4-2. 포트포워딩
포워딩이 가지는 느낌을 정확하게 모르겠는데 내가 가지고 있는 느낌을 어느 방향으로 향하게 하는 걸 포워딩이라고 부르는 것 같다.
포트포워딩은 특정 포트를 어떤 포트 쪽으로 향하게 하는 그런 느낌이라고 이해하면 될 것 같다.
라우터(공유기)의 IP 주소를 입력해서 접속하자.
간혹가다가 무선 인터넷을 통해서는 보안 때문인지 아예 접속조차 안 되고, 유선랜의 경우에만 접근을 허락하는 공유기들도 존재한다.
공유기의 기본 ID/PW는 메뉴얼이나 공유기 아랫 부분이나 어디 스티커로 붙어있거나 공유기 제조 홈페이지를 참고하며 된다.
그리고 또 메뉴얼을 참고해서 포트포워딩 메뉴로 오면 되는데 대부분 일반 유저들은 쓰지 않는 메뉴기 때문에 고급 쪽에 붙어있는 경우가 많다.
포트 포워딩을 보기 전에 몇가지 재밌는 메뉴들을 살펴보자.(공유기에 따라 정보를 노출하지 않거나 제공하지 않는 기능일 수도 있으니 그냥 재미로만 보자.)
직접 라우터의 IP 주소와 네트워크의 서브넷 마스크도 조절이 가능한 것 같은데 뭔가 무서워서 함부로 건들지 못하겠다 ㅋㅋ
또한 이더넷 카드의 Physical Address인 Mac Address도 있다.
IP 주소는 ISP로부터 할당받은 Public IP를 뜻하고,
기본 게이트웨이는 모뎀(이자 라우터 역할도 함)의 퍼블릭 IP를 말하는 것 같다.
기본/보조 DNS는 URL 창에 IP <-> Domain을 하기 위해 도메인들이 각각 저장된 도메인 네임 서버를 의미하는 것 같다.
그리고 고정 IP는 기본적으로 돈이 들기 때문에 IP 주소 변경에 민감한 웹서버에서 주로 사용한다.
IP 주소 대역을 보아하니 호스트는 100~199까지 총 100대만 연결이 가능한 네트워크인 모양이다.
또한 임대 시간이 나와있는데 해당 시간을 초과한다고 해서 무조건적으로 IP 주소가 바뀌는 건 아닐 것이다.
웬만하면 기본값인 1500바이트를 건들 일은 없어 보인다.
근거리 통신(LAN)에는 192.168.0.0/24인 네트워크를 통해 통신이 되고,
WAN의 경우에는 xxx.149.166.0/25인 네트워크를 타고 통신이 된다.
그 외의 경우에는 디폴트 라우팅 테이블에 있는 모뎀(라우터)의 IP 어드레스를 타고 나가게 된다.
만약 배틀넷 서버가 클라이언트(192.168.0.181)에게 8123 포트로 요청을 보낸다고 하면
위와 같이 등록을 해두면 된다.
만약에 클라이언트(192.168.0.181)에서 웹서버를 8080 포트로 열었다고 할 때
위와 같이 설정해놓으면 외부에서는 퍼블릭 ip만 입력하면 바로 내가 연 웹서버로 들어올 수 있다. (대표 포트는 생략 가능하기 때문)
하지만 이런 포트포워딩에도 단점이 존재하는데 포트의 충돌이 일어나기 때문에 하나의 포트는 하나의 호스트 밖에 사용하지 못한다.
4-8. 도메인명
IP는 숫자로 구성돼있어서 인간 친화적이지 않으므로, 사람이 알아보기 편한 영단어들과 일부 기호들의 집합으로 이루어진 걸 도메인명이라고 한다.
4-8-1. 호스트명과 도메인명
서로 다른 컴퓨터를 구분하는 식별자로 IP 어드레스와 호스트명이 있는데, 이걸 관리하기 위해 DNS(Domain Name System)이 등장했다.
우선 도메인을 보기 전에 URL이 어떻게 생겨먹었는지 보자.scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
scheme는 프로토콜이라고 보면 된다.
그리고 나는 프로토콜 뒤에 무조건 ://이 붙는 줄 알았는데 mailto 프로토콜의 경우에는 mailto:someone@example.com와 같이 //이 붙지 않는 프로토콜도 존재한다.
그리고 (s)ftp의 경우에는 ftp://testid:testpass@file.example.com처럼 인증에 필요한 user:password 정보가 URL에 포함돼있는 경우도 존재한다.
ssh 프로토콜을 보면 대부분 터미널을 통해서 ssh 라는 명령어를 통해서 접속을 시작하지만 엄연히 URL을 가진다.ssh://ec2-user@52.178.112.131과 같은 형태로 접속이 가능하다.
위 URL을 보면 user@host의 형태도 보인다.
일반적인 웹의 경우에는 user, password, @가 빠진 https://js.org/와 같이 scheme://host/만으로도 URL을 표현할 수도 있다.http://121.1.33.57:8080/board?no=1#notice와 같이 host 부분은 IP 주소가 돼도 되고, 해당 서비스를 대표하는 대표 포트가 아닐 경우에는 포트번호 생략이 불가능해진다.
포트 뒤에 board라는 path가 나왔고, 그 뒤에 ?no=1이라는 쿼리 스트링도 붙었다.
그리고 #notice라는 fragment를 통해 현재 해당 리소스의 어느 부분?부터 리소스가 보이게 끔 하기도 한다.
4-8-2. DNS 서버에 질의하기
도메인명에 대응하는 IP 정보가 알고 싶다면 DNS 서버에게 물어보면 된다.
위에 라우터(공유기) 설정 스샷에서도 봤듯이 DNS 서버가 컴퓨터 혹은 라우터에 등록이 돼있어야한다.
4-8-3. 도메인의 계층 구조
도메인 명은 아래와 같은 계층 구조를 가지고 있다.
- 루트
- 탑 레벨 도메인(TLD, 1차 도메인) - com, org, kr, uk
- 2단계 도메인(ANS, Authoritative Name Server, 2차 도메인) - co, go, ac, seoul, busan
- 3단계 도메인(3차 도메인)
위 구조는 예시일 뿐, 실제로는 더 복잡한 계층일 수도 있다.
4-8-4. DNS 서버의 계층 구조
도메인이 계층 구조를 가지듯이 DNS 서버도 계층적인 구조를 가지고 있다.
- 루트 네임 서버
- kr, uk 도메인을 관리하는 DNS 서버
- ISP 등에서 관리하는 DNS 서버
위 구조는 예시일 뿐, 실제로는 더 복잡한 계층일 수도 있다.
도메인명 데이터를 직접 관리하는 서버를 DNS 콘텐츠 서버라고 부른다.
4-8-5. DNS 서버에 질의 처리하는 과정
- 우선 클라이언트는 DNS 캐시 서버에게 도메인을 던진다.
- DNS 캐시 서버는 자신에게 해당 도메인에 대한 IP가 등록돼있는지 확인한다.
- 있으면 바로 IP 주소를 리턴하고, 없으면 루트 네임 서버에 도메인을 던진다.
- 루트 네임 서버는 본인이 해당 도메인에 대한 IP가 등록돼있는지 확인한다.
- 있으면 IP 주소를 리턴하고, 없으면 해당 정보를 가지고 있는 탑 레벨 도메인 서버의 주소를 던진다.
- DNS 캐시 서버는 다시 탑 레벨 도에민 서버에게 도메인을 던진다.
- 있으면 IP 주소를 리턴하고, 없으면 해당 정보를 가지고 있는 다른 DNS 서버의 주소를 던진다.
- DNS 캐시 서버는 다시 응답받은 DNS 서버의 주소로 도메인을 던진다.
- DNS 서버는 자기가 해당 도메인에 대한 IP를 들고 있다면 IP를 리턴하고 없으면 또 다른 DNS 주소를 응답한다.
- DNS 캐시 서버는 도메인에 대한 IP 주소를 받아서 클라이언트에게 응답한다.
아래 링크와 동영상도 참고하자.
그리고 DNS에서 생략되는 게 하나 있는데 바로 루트를 의미하는 . 이다.
http://d2.naver.com./helloworld/238638 으로 접속하면 com.뒤에 뭔가 올 거 같은데 입력하지 않고 바로 저렇게 입력해도 잘 접속이 된다.
바로 루트를 의미하는 .은 있어도 되고, 없으면 자동으로 내부적으로 붙여주기 때문이다.
DNS 캐시 서버는 하드웨어 단의 캐시 서버이고 자바 같이 소프트웨어 단에서도 DNS 캐시를 설정할 수 있다.
운영체제 별로 hosts 파일이 존재한다.
인터넷 초창기에는 도메인과 IP 주소를 매핑하기 위해 텍스트 형태의 파일인 hosts 파일을 사용해서 ip 주소를 변환했다.
요즘 OS에도 이 파일이 있어 DNS에 등록하기 전의 서버나 DNS에 등록할 수 없는 서버에 접근해야할 때 이 파일을 사용한다.
개발 중인 서버를 내부 테스트 할 때 사용하기도 하는데 자신의 컴퓨터에만 적용되기 때문에 테스트하는 모든 컴퓨터가 hosts 파일 자체를 수정하기가 번거로운 경우에는
사설 DNS를 직접 구성하기도 하는 것 같다.
맥의 경우에는 /etc/에 해당 파일이 존재한다.
맨 밑에 IP와 asdf.com은 내가 테스트로 등록한 건데, 네이버의 IP이다.
이제 내 컴퓨터에서 asdf.com을 입력하면 네이버로 접속이 된다.
4-8-6. DNS에 도메인 등록하기
도메인은 IP와 마찬가지로 별도로 관리해주는 기관이 있다.
ISP 업체가 IP를 임대받아서 개인에게 IP를 할당해주듯이
도메인도 마찬가지로 큰 기관에서 전체적으로 관리하고, 등록 대행 업체(ISP 같은 애라고 보면 됨) 같은 사이트에서 관리를 하게 된다.
GoDaddy, Route53 등등의 사이트에서 도메인을 등록할 수 있다.
과정이 궁금한 사람은 (DNS) 1331원에 .com 도메인 사기 (feat. GoDaddy)을 참고하면 된다.
DNS 서버에 등록되는 정보를 리소스 레코드라고 부르고, 리소스 레코드가 등록된 파일을 존 파일이라고 한다.
4-8-7. 리소스 레코드의 의미
각각의 레코드에 대해서는 나도 아직 공부하는 중이므로 아래 링크를 참조하자 ㅠㅠ
DNS Zone 파일에 쓰이는 레코드 설명
SOA(Start of authority)
해당 도메인을 관리하는 DNS 서버를 기술, 링크를 보면 1차 네임 서버(Primary), 2차 네임 서버(Secondary) 사이에 싱크를 맞추기 위한 시간 설정이나
재시도를 위한 시간 등등의 설정도 할 수 있다.NS(Name Server)
Primary, Secondary DNS 서버를 기술, 도메인에 대한 정보를 찾을 수 없으면 이 NS로 보내서 도메인에 대한 정보를 뒤지는 모양이다.A
도메인과 IP 어드레스를 연결, Route53 같은 경우에는 IP 주소 대신에 AWS Resource에 대한 도메인을 등록할 수 있다.CNAME(Canonical Name)
도메인에 별칭을 부여한다.
해당 도메인을 부르는 이름이 따로 있는데 그거에 대한 별명을 쓴다고 생각하면 된다.
내 블로그만 해도 원래는 perfectcle.netlify.com이라는 도메인이 있는데 이 도메인에 blog라는 별칭을 줬다.
루트 도메인(Zone Apex, Naked Domain이라고 부르기도 한다.)인 perfectacle.com을 내 돈 주고 샀고, blog라는 서브 도메인을 등록한 것이다.
루트 도메인만 돈 내고 쓰면 되고, 서브 도메인은 마음껏 쭉쭉 추가할 수 있고
위와 같이 1뎁스가 아니라 dev.blog와 같이 몇 뎁스 씩 쭉쭉 늘려가면서 등록할 수 있다.MX(Mail eXchanger)
xxx@domain 과 같은 형식의 메일 주소와 메일 서버를 연결할 때 사용한다.
4-9. IP 어드레스를 자동으로 할당하는 DHCP
DHCP는 네트워크에 속한 호스트들에게 IP 어드레스를 자동으로 부여해 사람이 직접 IP를 설정하고 관리하는 수고를 덜어준다.
4-9-1. DHCP의 장점
TCP/IP가 제대로 동작하려면 네트워크에 속한 호스트의 IP 어드레스가 중복되면 안 된다.
퍼블릭 IP는 ISP에서 알아서 할당해주고, 프라이빗 IP도 누군가가 할당을 해줘야한다.
그래서 각 네트워크의 호스트한테 일일이 프라이빗 IP를 수동으로 등록해주는 건 매우 번거롭고 힘든 일이다.
이걸 자동으로 해주는 게 DHCP인데 대부분의 공유기가 이 역할까지 수행해준다.
4-9-2. IP 어드레스 할당 방법
공유기에 새로운 컴퓨터를 연결하면, 아직 IP 주소가 할당되지 않은 상태이고 DHCP 서버(공유기의 IP 주소) 조차 모르는 상황이다.
따라서 DHCP 서버를 찾아서 IP 주소를 할당받기 위해 브로드캐스팅을 해야한다.
- 신규로 연결한 장비는 네트워크에 브로드캐스팅으로 자신의 새로 들어왔음을 알린다.
이 때 자신의 IP 주소도 모르므로 IP 프로토콜로 통신하는 게 아니라 ICMP 프로토콜로 통신을 한다.
ICMP 타입 10번(Router Solicitation)을 보낸다. - 그럼 DHCP 서버가 아닌 애들은 자신과 무관한 내용이므로 해당 패킷을 버린다.
그럼 그 요청을 받은 DHCP 서버는 브로드캐스팅으로 사용해야하는 IP 주소를 알려준다.
이 때 라우터는 ICMP 타입 9번 메시지(Router Advertisement)를 응답한다. - 그럼 그 요청을 받은 새로운 장비는 IP 주소가 할당되고, 나머지 애들은 자신과 상관 없으니까 또 패킷을 버린다.
4-10. ipconfig 명령과 ping 명령
윈도우에서는 cmd에서 ipconfig 명령을 날리면 라우터 주소, 프라이빗 IP 주소, 서브넷 마스크 등등을 알 수 있다.
유닉스 환경(linux, mac 등등)에서는 ifconfig를 때리면 된다.
근데 맥에서 해당 명령어를 날려보니 보기가 매우 요상해서 Network Utility나 환경 설정의 네트워크 쪽에서 보는 게 더 보기는 편한 것 같다.
노트북의 경우에는 무선/유선 이더넷 아마 두 개가 나올 것이고(아마 무선은 꼭 나올 것이다.),
데스크탑의 경우에는 대부분 유선 이더넷 하나만 나올 것이다.
무선 이더넷 카드가 없는 경우에는 와이파이로 연결이 안 되니 외/내장 무선 이더넷 카드를 사야한다.
ping 명령어는 서버와 통신할 수 있는지 없는지 알기 위한 명령어이다.
해당 서버로부터 응답을 받는데까지 얼마나 알 수도 있기 때문에 네트워크의 혼잡도도 어느정도 파악이 된다.
사실 ping 명령어는 ICMP 프로토콜을 사용한다.
ICMP 타입 8번 메시지인 echo(수신 측 장비가 존재하는지 확인)를 서버에 날리고,
에코 요청을 받은 서버는 0번 타입 메시지인 에코 응답(서버 측 장비가 존재함)을 응답한다.
4-11. tracert 명령으로 통신경로 확인하기
unix 환경에서는 traceroute 명령어이다.
백문이 불여일견 그냥 샘플을 봐보자.
CNAME으로 blog를 등록했더니 원래 도메인인 perfectacle.netlify.com의 경로를 추적했고,
최종적으로 54.250.174.92이런 IP를 찾아낸 것 같다.
- 공유기 (192.168.0.1)
- 모뎀(xxx.xxx.166.1)
- 루트(.) DNS 서버(172.21.1.253)
- .com DNS 서버(172.21.0.229)
…
이런 순서인 것 같다.
네이버는 IP가 여러 개 물려있고, 그 중에 www.naver.com.nheos.com이라는 도메인을 선택해서 추적한 것 같다.
- 공유기 (192.168.0.1)
- 모뎀(xxx.xxx.166.1)
- 루트(.) DNS 서버(172.21.1.253)
- .com DNS 서버(172.21.0.229)
…
이런 순서인 것 같다.
302 Moved Temporarily 응답을 받은 걸 볼 수 있다.
그리고 실제로 210.89.160.88으로 접속해도 마찬가지의 응답을 볼 수 있다.
tracert/traceroute도 서버의 생존 여부를 파악하기 위해 ICMP 프로토콜을 이용한다.
요청을 보낼 때 ICMP 타입 8번(에코)를 날리고, 만약 맥시멈 라우트 홉까지 가고도 경로를 찾지 못했으면
ICMP 타입 11번(생존 기간이 지난 패킷이라 삭제됨) 응답을 알려준다.
꼭 도메인일 필요는 없고 IP 주소를 날려도 상관이 없다.
4-12. nslookup 명령으로 IP 어드레스 알아내기
윈도우의 CMD나 유닉스 기반 운영체제의 터미널에서 nslookup domain을 입력하면 해당 IP 어드레스와 DNS 서버 정보도 표시해준다.
위와 반대로 nslookup ip주소 를 입력해서 도메인 정보를 알아내는 reverse DNS Query라는 것도 있다.