이 글은 충남대학교 김기일 교수님의 컴퓨터 네트워크 수업 내용을 바탕으로 작성하였습니다.
데이터 통신에서는 physical layer와 datalink layer에 대해서 배웠다. 컴퓨터 네트워크 시간에는 이들의 상위계층인 network layer에 대해서 학습할 것이다.
1. Network layer Service
이 그림이 우리가 배울 내용을 다 나타내고 있다. 데이터 통신 시간에 배웠듯이 같은 네트워크에 있다면 ARP를 보내 MAC 주소를 받아서 직접 통신을 할 수 있다. 하지만 같은 네트워크에 있지 않다면 라우터를 통해 네트워크를 서로 연결해야한다. 어떤 경로로 보내느냐는 내가 데이터를 어느 목적지에 보내느냐에 따라서 달라진다. 다른 네트워크를 찾아갈 때 그리디와 같은 알고리즘을 이용한다.
정리하면 라우터에는 여러 개의 경로가 연결되어있는데 라우터는 데이터를 나보다 목적지에 가까운 네트워크에 경로를 찾아서 전달한다. 이때 라우터는 Shortest path 알고리즘을 이용하여 여러 경로 중 하나의 경로를 선택한다.
위 그림에서 예시를 하나 보자.
R2 -> R4 : 네트워크 레이어는 어떤 인터페이스로 갈지 경로를 정했으므로 Datalink layer를 통해서 데이터를 보낸다. 여기서 우리는 상위 layer는 하위 layer의 서비스를 이용할 수 있음을 알 수 있다! 마지막 목적지에 도착해면 Decapsulation을 하여 상위 계층으로 전달한다.
# Packetizing
데이터를 작은 조각으로 나누는 것을 말한다.
encapsulation : payload(실제 데이터)에 헤더를 붙여 보냄
decapsulation : payload(실제 데이터)에 헤더를 떼서 보냄
그렇다면 왜 데이터를 조각낼까? 큰 데이터를 그냥 한번에 보내면 안될까?
3가지 이유를 들 수 있다.
1. 하나가 에러가 났을 때 고치기 힘들다.
2. 다시 보내는효율이 비효율적이다.
3. 다른 호스트들이 쓰는 차례가 늦어진다.
# Forwarding과 Routing (네트워크의 가장 중요한 요소)
forwarding : 패킷을 하나 input으로 받아서 다른 쪽으로 보내는 것이다.
Routing : 목적지 주소를 보고 인터페이스를 정하는 것이다. 어떤 Table을 참조하여 데이터를 전송하는데 이 table을 만드는 작업을 의미한다! (이 테이블은 뒤에...)
아까부터 자꾸 보이는 단어가 하나 있다. 인터페이스는 뭘까?
인터페이스란 경로를 통해 데이터를 전송하기 위해 라우터가 사용하는 출구 지점,
즉 경로의 일부이자 다음 네트워크로 이동하기 위해 반드시 거쳐야하는 연결 지점을 말한다!
정리하면 라우팅으로 결정하고 포워딩으로 보낸다!
이 그림을 예시로 보면 forwarding process와 Interface가 각각 4개씩 있다.
따라서 1번에서 data를 받았다 => 2,3,4 중 택 1
포워딩 테이블을 만들어서 테이블에 따라서 보낸다. 이 때 table을 간단하게 만드는 것이 중요하다!
뒤에 배우겠지만 IPv4 주소 체계에서 테이블의 엔트리를 하나씩 관리하려면 2^32개의 엔트리가 필요하다. 하지만 default를 이용하면 2^32개의 엔트리를 유지할 필요가 없다! (default에 대한 내용도 뒤에 나온다). 즉 내가 찾았을 때 찾으면 그 경로로, 아니면 무조건 디폴트로 보낸다. 이때 주의해야 할 점이 디폴트가 잘못 설정되어 있다면, 루프로 인해 목적지로 가지 못하고 다시 돌아올 수 있다.
Forwarding Value : 목적지 주소
Output Interface : 패킷이 다음 네트워크로 이동하기 위해 사용해야할 출구
Q. 위 그림에서 만약 B가 2가 아닌 3으로 간다면 어떻게 될까?
A. 그 다음에 어디로 갈지 모르니까 알 수 없다...
Q. 그러면 B가 3이 되면 안되는 것인가?
A. 2번 네트워크 선이 고장나면 바꿀 수 있다. 고장이 났을 때 얼마나 빨리 발견해서 다른 인터페이스로 바꿀 수 있는지도 중요한 알고리즘이 필요하다!
우리가 중요하게 생각해야 하는 것은 성능이다. 네트워크 성능을 따질 때 가장 중요한 것이 Delay이다
Delay가 적으려면 라우팅 테이블에서 찾는 시간이 적어야 한다. 즉 Routing table이 작아야 한다! 이때 서치 시간을 줄이기 위해 이진 탐색 등 알고리즘을 이용할 수도 있다.
2. Packet Switching
# Packet Switching
패킷을 목적지 주소로 전달하기 위해 최적의 경로를 선택하고, 해당 경로로 전달하는 과정이다. Router, 스위치망이 이 역할을 담당한다. 장점은 utilization이 좋다!
Router : 서로 다른 네트워크 간 IP 주소기반의 패킷 스위칭
스위치망 : 같은 네트워크 내에서 MAC 주소 기반의 프레임 스위칭
# Datagram Approach
데이터를 보낼 때 datagram 단위로 나누게 되고 데이터를 보낼 때 소스나 데스트네이션에 대해서 각 패킷을 독립적으로 처리하는 방식이다.
즉 Network layer는 송신지에서 수신지까지 패킷을 전달하는 것만 책임진다. 이 과정에서 동일한 메세지 내 패킷들이 서로 다른 경로를 통해 목적지에 도달할 수도, 아닐 수도 있다!
왜 connectionless죠?
소스부터 목적지까지 데이터를 보낼 때 connection을 만들지 않고, 라우팅 테이블에 따라서 데이터를 보내기 때문!
1. R1 => R4 => R5 2. R1 => R2 => R5 3. R1 => R3 => R4 => R5 4. R1 => R3 => R5
라우터의 결정에 따라서 data를 보낸다. 이렇게 되면 목적지로는 데이터를 보내니까 네트워크 레이어의 역할을 잘 수행한다고 볼 수 있다.
왜 경로가 바뀌죠?
Table을 수시로 업데이트 하기 때문이다! 예를 들어 설명하자면 라우터가 알고리즘에 따라 고민해보니 R3로도 보내고 R4로도 보낸다. 즉 다른 경로로 가기 때문에 순서가 바뀌어서 도착한다!
# Circuit Switching
이 친구는 패킷 스위칭과 다르게 physical link가 있는 스위치를 가지고 연결하므로 connection이다. 따라서 경로가 바뀌지 않아 순서가 바뀌지 않게 한번에 보낸다. 이 말은 경로는 하나로 정해져 있으므로 라우팅 테이블이 필요없다는 것이다! 이에 따라 딜레이가 거의 없다. 서킷 스위칭의 예시로는 전화 네트워크가 있다. 전화는 번호를 누르면 경로를 찾고 받을 때까지 연결한다. 그런데 서킷 스위칭에는 단점이 존재하는데 한번 연결하면 이 통신이 끝날 때까지 다른 사람이 쓸 수 없다는 점이다. 즉 utilization이 안좋다.
둘의 장단점을 잘 기억하자
패킷 스위칭
- 순서대로 보낼 수 없지만 링크를 훨씬 더 많이 쓸 수 있다.(utilization Good)
- 지터, 딜레이가 발생한다.
서킷 스위칭
- 순서가 바뀌지 않지만 누군가 통신을 쓰고 있다면 아무도 못쓴다(utilization Bad)
- 지터, 딜레이가 거의 없다
왜 딜레이 여부가 차이가 날까?
라우팅 테이블에서 엔트리를 찾고 경로를 선택해야하기 때문에 이 시간이 딜레이가 된다!
우리가 지금 사용하는 인터넷은 datagram 방식인데 왜 카톡을 보냈을 때 순서가 바뀐 적이 없을까?
네트워크 레이어는 자원을 필요하면 이용하는 ON_DEMAND 방식이다.
레이어 아키텍쳐에서 Network layer에선 순서를 맞춰주는 기능을 제공하지 않는다. 따라서 상위 layer인 transport layer, application layer에서 이 기능을 구현해 준다. 만약 서킷 스위칭 방식을 쓴다하면 이 기능은 필요없다.
# TCP 와 UDP
TCP : 순서 조정 기능이 있음
UDP : 순서 조정 기능이 없음
# Virtual - Circuit Approach ( Packet Switching + Circuit Switching)
패킷 스위칭과 서킷 스위칭의 장점을 뽑아서 만든 방식이다.
- 서킷을 만들기는 하는데 자원을 reserve하지 않음. 즉 필요할 때마다 쓴다.
- 서킷 스위칭과의 차이는 경로는 똑같이 가게 만들지만 데이터를 보낼 때는 datagram 방식을 취한다!
즉, datagram 방식을 통해 패킷이 보내질 때마다 서킷 스위칭 방식으로 반드시 path를 하나 만들어야 한다. 이때 path는 자원을 reserve하지 않았기에 여러명이 같이 자원을 쓰게 해주면 된다.
Q. 왜 virual이라는 단어가 붙는 건가요?
A. 물리적으로 스위치를 통해서 만들면 한 명만 사용 가능하다. 이를 해결하기 위해선 자원을 reserve 하지 않게 해야한 다. 따라서 virtual이라고 한다.
이 방식은 아까처럼 목적지만 보고 가면 안된다. Path 정보를 가지고 와서 data를 forwarding 해줘야 한다.
1. Sender로부터 Receiver까지 데이터를 보낼 virtual path를 만든다.
2. 만들어진 path 번호를 보고 data를 보내준다.
3. "여기서부터 여기까지 가는데 path 번호 2번이야, 1번 path는 이쪽으로 가, 2번 path는 저쪽으로 가" 처럼 미리 경로를 설정한다.
이렇게 경로를 미리 설정하는 방식을 통해서 데이터를 보내는 방식을 virtual circuit 방식이라고 한다.
Q. 경로가 여러개 생길 수 있고 그들 사이에서 data를 보낼 때 같이 보낼 수 있어야 하지 않나요?
A. Label이라는 것을 만든다(table이 새로 만들어짐)! 이 Label에 path 정보를 담으면 이걸 통해서 데이터 포워딩 시 같은 경로로 간다. 이 Label, table의 in-out은 경로가 생성될 때 만들어진다.
EX 1)
Label = L1이면 2번 part L2로 가라. 즉 L1 붙은 애가 1번으로 들어오면 L2를 붙여서 port 2번으로 보낸다.
몇 번 포트로 ~데이터가 ~라벨로 갔구나! (서울로 가기 위해 대전 IC를 지나 경부고속도로를 탔다)
즉 목적지 주소를 볼 필요가 없다. Virtual path 생성 후 Label만 이용하면 된다. 그리고 내가 쓴 Label로 포워딩 테이블을 채워 나간다(= 데이터를 보내면서 table을 계속 만들어 간다). 이때 포워딩 테이블은 연결된 path의 개수만큼 엔트리가 생성되므로 엔트리 수가 적다. 필요한만큼 만들기 때문에 utilization도 좋다!
EX 2)
내가 연결 요청 시 incoming에 대한 번호를 설정하고, 다시 올 때는 패킷이 갈 때 아웃고잉의 번호를 설정한다.
가는 경로 : 14 => 66 => 22 => 77
오는 경로 : 77 => 22 => 66 => 14
결국 자기 번호를 제너레이션하고 그 번호를 상대방의 아웃고잉하고 매칭시켜주면 된다.
그런데 다음 경로를 어떻게 찾아내죠?
Table을 만들기 전에 데이터그램 방식으로 한 번 경로를 찾아가야 한다. 그 후엔 table만 보면서 찾아간다.
virtual circuit 방식은 delay가 존재한다. 대신 테이블을 줄여서 사용이 가능하다.
==> 근데 지금은 복잡해서 안쓴다. 현재는 datagram 방식을 사용한다!
두가지 방식을 생각해낼 수 있다.
상위 계층에서 복잡한 기능을 처리할 것인가, 네트워크에서 복잡한 기능을 처리할 것인가
네트워크 장비가 복잡해지면 처리 속도가 느려진다. 따라서 TCP에사 복잡한 일은 Router가 아니라 송/수신자 사이에서 처리한다.
이렇게 가운데 코어는 간단하게 하던 기능만, 복잡한 기능들은 다 바깥쪽으로 뺀 것을 엔드-투-엔드 원칙이라 한다.
3. Network-layer Performance
# Network Performance 비교
서킷 방식이 딜레이가 없으므로 제일 빠르다. 라우터는 데이터를 먼저 store해야 한다. 이때 buffer가 반드시 필요하다. 그 후에 데이터를 가지고 forwarding한다.
즉, 데이터를 버퍼에 저장해놓고 하나를 뽑아서 목적지를 보고 어디로 갈지 결정한다. 다시 말해 딜레이가 일정하지 않다. 왜냐하면 버퍼가 얼마나 차있냐에 따라서, 쓰는 사람이 많으냐에 따라서 딜레이가 달라지기 때문이다. 딜레이가 일정하지 않아서 데이터가 일률적으로 오지 않기 때문에 지터가 발생한다!
Q. 버퍼가 가득차면 어떡하죠? (= 큐잉을 한다는 것(큐에서 얼마나 빠르게 나올 수 있는가!))
A. data 손실이 발생한다.
두 가지 해결방법이 있다.
1. 버퍼를 늘린다 (얼마나 기다릴지 알 수 없다)
2. 다른 길을 찾는다(상위 계층에서 조치)
=> Loss가 발생하더라도 buffer를 한정시켜서 다른 길을 찾도록 하는 것이 좋다.
따라서 버퍼가 다 차기 전에 다른 길로 보내라고 알려주자
1. nodal processing은 일반적으로 데이터를 갖고 오면 목적지를 보고 테이블을 서칭하는 시간과 에러를 확인하는 시간이다. table이 간단하면 시간이 덜 걸린다. 기본적으로 min sec 정도로 굉장히 작은 부분을 차지한다.(거의 상수)
2. Queueing delay는 buffer 내에서 순서가 되기까지 기다리는 시간이다(가장 중요하다!) 즉, 현재 시점에 내 라우터가 얼마나 혼잡되어 있는지에 따라 달라지는 가변적인 시간이다.
3. transmission delay는 링크를 table을 보고 결정하고 링크로 옮기는 시간이다. 내가 쓰는 bandwidth에 따라 달라진다. 보통 속도의 단위는 bit/s이며 내가 사용하는 전파 매질이 얼마나의 속도를 가지며 다음 라우터와의 거리가 어떤지에 따라 결정된다(내 신호의 속도 및 거리: 거의 상수)
=> 데이터의 딜레이는 큐잉에서 발생한다! 얼마나 많은 혼잡도가 있는지에 따라서 딜레이가 발생한다.
# Caravan Analogy
EX 1)
차 10대, 거리가 100km/h라면 1시간 소요될 것이다. toll을 지나가는데 12초가 필요하다.
=> 모든 차가 가게 될 때는 1시간 + 12 x 10 = 62분
시간을 줄이는 방법은 도로를 빠르게 달리는 것 + toll을 빠르게 서비스하여 보내는 것
EX 2)
차 10대, 1000km/h라면 6분 소요될 것이다. toll을 지나가는데 1분 필요하다.
=> 첫번 째 toll에서 모든 차가 처리되는데 걸리는 시간 : 10 x 1m/대 = 10분
따라서 10분 - 6분 = 4분, 3대는 처리되지 않음
# Throughput
네트워크에서 특정 포인트에서 지나가는 패킷(비트)의 수를 말한다. 즉, 실제 데이터가 보내지는 양이다!
데이터를 보내는데 보내는 양은 다르다. 이때 병목현상(BottleNeck)이 발생하게 된다. 병목 현상은 네트워크에서 특정 구간이 다른 구간에 비해 더 느린 속도로 데이터를 처리할 때 전체 데이터 처리 속도가 느려지는 현상이다. 보낼 수 있는 양이 100kbps로 내가 쓸 수 있는 가장 적은 양이 기준이 되게 한다. 네트워크를 지나가다보면 다른 이들도 네트워크를 쓰게 되니깐 throughput이 줄어들게 된다. Throughput은 TR1과 TR2 중의 최솟값으로 정해지게 된다. 따라서 네트워크의 throughput은 내가 지나가는 네트워크가 얼마나 처리할 수 있는지에 따라 결정된다!
10개가 연결되어 있다면, 10개로 나눠서 결정한다. Data rate를 빠르게 하려면 중앙 통로 외에 개인 통로들의 성능을 높인다. (Rs : 송신측 전송속도, Rc : 수신 측 전송속도, R/10 : 중앙 통로 전송 속도
# LOSS
버퍼가 가득 찼을 때 생긴다. 즉 패킷이 손실되는 것이다.
에러 처리 방법에는 두가지가 있다.
1. 에러 복구 2. 데이터를 버리고 재전송
이때 재전송은 자원을 두번 쓰고 시간도 걸리니 Loss가 좋지 않다. 라우터는 버퍼를 갖고 있고, 버퍼가 가득차면 Loss가 발생한다. 반대로 말하면 버퍼가 가득차지 않으면 Loss가 발생하지 않을 것이다!
그럼 버퍼를 늘리면...? 큐잉 딜레이가 늘어나서 Bad!
한정된 버퍼를 가지고 있다. 패킷을 보고 어느 곳으로 갈지 선택해서 보낸다. 패킷이 가득 차면 Loss가 발생하는데 이때 Retransmission을 해줘야 한다. 궁극적으로 buffer가 가득 차지만 않으면 된다.
# Congestion Control
버퍼가 가득 차지 않게 라우터에 데이터를 전해주는 것을 조절하는 것을 말한다.
- 데이터를 네트워크가 허용하는만큼 최대로 보내줘야 성능이 좋다(빠른 시간 내에 데이터 보내기)
- Throughput을 높이다가, 데이터가 버퍼에서 계속 차게 되면서 Loss가 발생할 수도 있다. a에서 throughput이 늘어나게 되면서 딜레이가 커지게 된다. 더 높아지는 지점에서는 패킷에서 Loss가 발생하여 시간 측정이 안되게 한다.
==> Loss가 발생하지 않을만큼만 보내야 한다!
EX)
1. 3번에서 congestion이 발생한다. 버퍼를 보니 패킷이 Loss 되었다. 따라서 나한테 데이터를 주는 애에게 데이터 전송을 제한하도록 한다.
2. 패킷을 줄여달라고 source에게 알려준다(이게 바로 congestion control). 라우터에서 이 역할은 실제 제공되고 있지 않으나 실제로는 사용하고 있다. Network layer에서는 이 기능을 제공하지 않는다(=라우터들은 기능x). 따라서 이 기능은 상위 계층에서 제공한다. 성능을 위해서는 기본적으로 사용되어야 한다. TCP라는 것이 이것을 이용해서 데이터들이 네트워크로 가는 양을 직접 조절하고 있다.
Q. 왜 네트워크 레이어에서는 사용하지 않는가?
A. 라우터들의 기능이 복잡해지고, 네트워크 성능이 떨어지기 때문이다.
==> 라우터는 원래 자신의 기능만 하고, 복잡한 기능은 host에게 다 줘버린다. 이를 통해 네트워크가 혼잡해지는 것을 막는다.
패킷이 손실되지 않도록 데이터양을 조절하는 건 네트워크 레이어의 상위 계층에 있으며 굉장히 intelligent한 알고리즘을 갖는다.
4. IPv4 Addresses
구조를 이해하는게 중요하다. 어떠한 호스트를 가지고 있는지 파악하기 위해 어드레스를 사용하는데 identification으로 사용하려고 한다.
- TCP/IP에서 사용하는 Logical address(software에서 만들어짐), 호스트를 찾아갈 때 사용한다.
- 32 bits 주소를 사용한다(2^32개를 붙일 수 있다)
- 유니크하고 universally하게 정의되어야 한다.
physical address는 local identification이 이더뎃 어드레스를 통해 변하지 않는다, 하지만 logical address는 어떤 네트워크에 속해있냐에 따라 달라진다. 또한 피지컬을 ARP를 통해 직접 통신하는데 사용하고 Logical은 목적지를 찾아가는데 사용된다.
- IPv4는 0~42억의 범위를 가진다. 이 말은 호스트를 구별하고 연결해야하니 42억개만큼 연결이 가능하다. 그 이상은 identification이 안되서 불가능하다.
- .은 원래 없는 것이다. 부르기 쉽게 하려고 쓴 것이다.
- 한 byte씩 4byte, 음수는 불가능하고 0~255의 수를 넣을 수 있다.
핵심은 이 주소를 어떻게 관리해야 하는가
- 4 byte가 있어도 만들어질 때, 32bit에서 n 비트는 prefix로 네트워크를 구별한다. 그 이후 32-n bit의 suffix는 네트워크 안의 host를 구분한다.
- 호스트를 찾아올 때, 네트워크를 먼저 찾아온다. n비트를 통해 네트워크 주소를 찾고 그 다음에 호스트를 찾는다.
- 내가 호스트를 알아와서 직접 통신하려면 이더넷 주소를 ARP를 통해서 알아온다.
- suffix 결정은 네트워크 관리자가 몇개의 호스트를 사용할 지를 생각해서 결정된다.
EX) 1000개의 host를 필요
2^10 = 1024, suffix = 10, 32- n = 10 => n = 22 = prefix
자신의 네트워크 주소를 받고, host 번호를 조합해서 32비트 주소를 골라낼 수있다.
# Classful Addressing
- 네트워크를 처음 만들었을 때, fixed-prefix로 했다. 즉 prefix를 고정시켜서 해당 주소를 보고 어디인지 바로 파악한다. 그렇게 클래스를 나눈다.
어드레스를 보며 어떤 클래스에 속했는지 보고 어디가 네트워크인지 호스트인지 구별한다.
- Class A : 첫 비트를 0으로 두고, prefix를 8비트로 쓰고 나머지를 suffix로 사용한다.
EX) 01111111 => 0 ~ 127
92.1.5.7 => 92는 0~127이므로 A
- Class B : 첫 비트를 10으로 두고, prefix를 16bit로 쓰고 나머지를 suffix로 사용한다.
EX) 10111111 => 128 ~ 191
163.172.0.7 => B
163.127.5.7 =====> 163.127.7.21 : 같은 네트워크아므로 직접 통신하면 됨!
168.188.1.5 =====> 163.127.7.21 : 다른 네트워크와 연결되는 라우터로 연결해야함
=> 둘 다 클래스 B에 속하므로 네트워크 주소는 prefix인 16bit를 보면 된다. 즉 주소만 보고 어떤 클래스인지 파악하여 호스트를 찾아갈 수있다.
- Class C : 첫 비트를 110으로 두고, prefix를 24bit로 쓰고 나머지를 suffix로 사용한다.
EX) 11011111 => 192~223
- Class B : 첫 비트를 1110으로 두고, prefix를 32bit로 쓰고 나머지를 suffix로 사용한다.
EX) 11101111 => 224 ~ 239
- Class B : 첫 비트를 1111으로 두고, prefix를 32bit로 쓰고 나머지를 suffix로 사용한다.
EX) 11111111 => 240 ~ 255
그러면 프리픽스가 동적으로 변하는건 없을까?
# Classless Addressing
Classful address 체계를 쓰다보니 인터넷이 발전, but 주소가 할당되면 관리자의 통제 하에 다른 이들은 사용할 수 없으니 낭비되는 주소가 생기기도 한다.
EX)
A class의 네트워크 주소가 하나 부여됐을 때, 사용하지 않는 주소가 있어도 다른 네트워크에서는 같은 네트워크 주소를 사용할 수 없다.
=> 42억개 중에 못 쓰는 경우가 많다.
Why? 32bit만 사용하니까! 그러면 기존에 안쓰는 주소를 다른 네트워크의 사람이 쓸 수 있게 하면 되지 않을까?
=> 내 주소를 작게, 서브넷으로 만들어서 서브넷 간 라우터를 배치해서 다른 네트워크 사용자가 쓸 수 있게 하자! (variable한 prefix)
EX) C 클래스 212.5.7.4
212.5.7.0 ~ 255까지 사용 가능 => 212.5.7.0 ~ 212.5.7.127 과 212.5.7.128 ~ 212.5.7.255로 나누어 사용한다.
=> 몇 개로 쪼갰는냐에 따라 네트워크 주소가 결정된다!
- 마지막 n이 prefix, n은 계속 바뀌는 network이다.
- 서브넷 마스크로 표현 가능!
EX) 12.24.76.8/8 => 12.0.0.0 ~ 12.255.255.255
/뒤의 8이 서브넷 마스크를 나타낸다고 보면 된다. 12.12는 동일하고 나머지를 255.0.0.0으로 연산한다.
=> 서브넷 마스크를 통해 자기의 네트워크 주소를 찾아낼 수 있다!
23.14.37.92/12 => 네트워크 주소가 12비트까지 가능
11111111.11110000.00000000.00000000 = 255.240.0.0 (서브넷 마스크)
00010111.00001110.0.000011.0.0101110 을 and 연산하면
= 00010111.00000000.00000000.00000000 = 23.0.0.0
이 주소가 start address가 된다. 이 주소를 192.168.00과 비교하면 네트워크가 다름을 알 수 있다.
Gateway란 라우터를 의미한다. 타 네트워크와 통신하려면 라우터에게 데이터를 보내야 한다. 어떤 토폴로지 네트워크를 구성하냐에 따라 서브넷 마스크가 바뀐다. 위 예시에서 n=16이면 같은 네트워크에 속하게 된다.
=> prefix의 서브넷 마스크를 어떻게 설정하느냐에 따라 네트워크 구성이 달라진다
- n의 prefix에서 32-n만큼의 호스트를 사용 가능하다.
EX) 32개의 호스트
32 - n = 5 , n = 27 즉 27비트의 prefix 구성
- 첫 호스트는 고정된 prefix와 0으로 채워진 suffix부터 1로 채워진 suffix까지!
EX) 00000 ~ 11111
- 전화번호를 보면 prefix를 볼 수 있다(지역 번호)
EX)
17.12.14.0/26 이라는 주소가 주어져 있다.
=> 11111111 11111111 11111111 11000000 = 255.255.255.192
n = 26이니까 suffix는 6이다. 따라서 내가 사용할 수 있는 주소는 0~63까지이다.
17.2.14.0 ~ 17.12.14.63까지 같은 네트워크에 속한다. 17.12.14.5와 17.12.14.60은 서브넷 마스크와 and 연산한 network address가 같으므로 같은 네트워크에 속한다.
여기에서는 개존의 17.12.14.0 ~ 17.12.14.63의 주소를 2개의 네트워크로 나눈다. 즉 prefix를 한 비트 더 주면 나눠진다.(suffix는 줄어듬). 네트워크에 할당할 수 있는 숫자는 줄어들었지만 네트워크는 그대로 늘어나게 된다. 이를 통해 collision을 줄일 수 있다. 예를 들면 64명이 같이 쓸 때보다 32명씩 나눠쓰면 충돌이 일어날 확률이 줄어들게 된다.
block address : 특정 IP 주소 범위의 시작과 끝을 나타내는 주소
- prefix가 한 비트 늘어날 때마다 네트워크의 개수는 2^n개만큼 증가하게 된다
- 3개로 나누는 방법은 일단 2개로 먼저 나눈다. 나눈 것 중에 하나를 다시 2개로 나눈다.
- 쪼개진 3개의 네트워크는 다 다른 네트워크로 볼 수 있다. (서브넷 마스크만 보고 그림 그릴 수 있어야 되요~)
- 마지막 사진에서 파란색 내의 비트 수가 1 증가한 것을 알 수 있다. 이 수는 suffix가 줄어든 수라고 볼 수 있다.
이 유형은 예제를 많이 풀어보는 것이 중요하다. 시험에도 꼭 나온다! 예제를 보도록 하자
EX) 190.100.0.0 / 16의 서브넷 마스크
11111111.11111111.00000000.00000000 = 255.255.0.0
Start address를 구하면
10111110.01100100.00000000.00000000 과
11111111.111111111.111111111.00000000 를 and 연산을 하면
10111110.01100100.00000000.00000000 = 190.100.0.0이 나온다.
여기서 마지막 16비트는 전부 0이므로 host에게 할당 가능한 부분이다!
(a) 64개의 네트워크, 256개의 호스트
suffix=2^8 , prefix = 32 - 8 = 24 => 190.100.0.0/24 (190.100.0.0 ~ 190.100.0.255)
각 customer가 256개씩 필요로 하니까
첫번째 호스트 : 190.100.0.0 ~ 190.100.0.255
두번째 호스트 : 190.100.1.0 ~ 190.100.1.255
* * *
64번째 호스트 : 190.100.63.0 ~ 190.100.63.255
(b) 남은 주소 : 190.100.63.0 ~ 190.100.255.255
suffix = 2^7 , prefix = 32 - 7 = 25
각 customer가 128개씩 필요로 하니까
65번째 고객 : 190.100.64.0 ~ 190.100.64.127
66번째 고객 : 190.100.64.128 ~ 190.100.65.255
***
192번째 고객 : 190.100.127.128 ~ 190.100.127.255
(c) 남은 주소 : 190.100.128.0 ~ 190.100.255.255
suffix = 2^6 , prefix = 32 - 6 = 26
각 customer가 64개씩 필요로 하니까
193번째 고객 : 190.100.128.0 ~ 190.100.128.63
194번째 고객 : 190.100.128.64 ~ 190.100.128.127
***
320번째 고객 : 190.100.159.192 ~ 190.100.159.255
=> 전체 주소 : 65,536
할당 주소 : 40,960
남는 주소 : 24,576
prefix가 24비트이긴 하지만 뒤의 16비트는 0이므로 호스트에게 주소할당할 때 사용 가능! 단 동일 네트워크인지 확인할 때는 prefix를 비교하므로 190.100.0.0과 190.100.1.0은 다른 네트워크에 속한다.
prefix : 27 , suffix : 32 - 27 = 5 따라서 2^5
서브넷 마스크 : 11111111.11111111.11111111.11100000 and
10100111.11000111.10101010.01010010
= 10100111.11000111.10101010.01000000
start address : 167.199.170.64
suffix가 32이므로 last address = 167.199.170.95
주소를 나누어서 사용하고 있는데 나를 가장 잘 표현하는 네트워크는 prefix가 가장 긴 것!
네트워크까지 찾아가서 호스트로 가니까 여기선 호스트 주소말고 네트워크 주소만 찾아가면 될 것이다.
이때 prefix가 가장 큰 애를 찾아가면 된다!
1000은 2^n이 아니므로 2^10을 받아야한다. prefix는 32 - 10 = 22 따라서 18.14.12.0 / 22
suffix : 2^8 = 256 , prefix : 24 니까 서브넷 마스크 : 11111111.11111111.11111111.00000000
block address : 14.24.74.0 ~ 14.25.74.255
14.24.74.0 /25 ~ 14.24.74.127 / 25 *** 100개 해결
14.24.74.128 / 25 ~ 14.24.74.255 / 25 를
14.24.74.128 / 26 ~ 14.24.74.191 / 26 *** 60개 해결
14.24.74.192/28 ~ 14.24.74.207 / 28 *** 10개 해결
이 네트워크는 n이 26짜리로 4개 나눠져 있다. 오리지날 블록은 n = 24 였을 것이다. 이 라우터는 내가 속해 있는 네트워크를 알려 주느 역할을 한다. 4개를 하나에 다 알려주기도 하고, 1개의 주소를 아려주기도 한다. 밖에서는 24를 쓰던 26을 쓰던 다른 네트워크에서 봤을 땐 똑같다. 엔트리를 하나만 알려준다. 그렇지 않으면 테이블에 엔트리가 4개일 것이다. 하나만 알려줘도 되니까 라우터에 24를 준다. 왼쪽은 네트워크를 나누고 타 네트워크에 보낼 땐 모아서 보낸다.
==> aggregation(군집화)
서브넷은 하나의 네트워크를 나누는데, aggregation은 모아서 보내는데 사용한다.
전체적인 flow를 한번 살펴보자.
# 전체적인 Flow
앨리스에서 밥까지 가자. 각자의 어드레스에 서브넷 마스크를 적용해서 둘이 동일하면 같은 네트워크에 속해 있는지 알 수 있다. 다를 경우 ARP를 보내 라우터를 찾는다. 데이터가 라우터에 도착한 후 Forwarding table을 확인하여 데이터를 보낼 링크를 확인한다. 마지막으로 라우터에서 포워딩 테이블을 확인해 목적지 IP가 네트워크에 있는 지 확인 후, 있다면 ARP를 이용해 밥의 MAC 주소를 요청한다.
5. Forwarding of IP Packets
# DHCP
통신을 하려면 반드시 주소가 할당되어야 한다. 이때 네트워크 주소를 얻으면 네트워크 관리자가 각각의 호스트와 라우터를 메뉴얼하게 할당한다.
=> 실수 때문에 문제 발생 가능
따라서 어드레스를 할당할 때 automatically하게 즉 software로 한다. 이게 바로 DHCP이다!
이 방법을 쓰면 어느 호스트가 네트워크에 접근했을 때 해당되는 IP 주소, 서브넷 마스크, 디폴트 게이트웨이 정보(다른 네트워크로 데이터를 보낼 때 사용하는 사용하는 라우터의 IP 주소)를 자동으로 받게 된다.
EX) 하나의 서버가 존재
DHCP server가 존재한다 = 서버가 할당할 수 있는 주소 범위를 가진다.
하나의 client가 브로드캐스트 메세지를 통해 모든 서버에게 요청을 하고, 이 메세지를 받은 서버들은 자기가 할당할 수 있는 주소가 있다면 이 주소를 request한다. 이를 client가 쓰겠다고 하면 해당 주소를 빌려준다.
=> DHCP는 client가 주소가 없는 상태로 네트워크에 도착했을 때, 주소를 요청하여 사용할 수 있게 하는 것!
- 4개의 과정을 거치는데 실제 과정을 전달하기 위한 메세지 포맷
- OP 코드를 보면 요청 시 1, 답하면 2 이를 통해 client가 전달하는지 받는지 확인한다.
- 실제 사용해야할 주소가 들어오면 이를 통해 데이터를 받는다. 이 때 DHCP는 주소를 임대해서 사용하므로 시간이 정해져 있다. 따라서 2시간 동안만 데이터를 받을 수 있다.
- 앞선 예시의 더 구체적 메시지를 보여준다. 사진의 DHCP는 UDP 위에서 동작한다.
- 자기 주소를 알지 못하는 client가 서버에 사용가능한 주소 요청 => 서버가 사용가능한 주소 offer => client가 어떤 주소를 쓸 것인지 명령해서 데이터 보낸다
Q. IP 요청하고 서버한테 내가 쓸 수 있는 주소 받았는데 왜 다 request하고 ack를 받는 과정을 거치는가?
A. client가 주소가 요청할 때 broadcast 메시지를 보낸다 .응답을 여러 개 받을 수 있는데 하나를 찾아서 요청하고 응답을 받아서 사용한다. 따라서 다른 서버에게 해당 서버의 주소를 쓴다고 알려주는 메세지를 보내서 다른 서버들도 이해할 수 있도록 하기 위해서이다.
# NAT
호스트에서 메세지를 보내면 라우터를 통해 외부로 전달한다. 노란색 부분을 private network라고 하는데 이는 실제 외부에서 접근이 불가능한 자신만의 어드레스를 쓰는 것이다. (반대 : public 주소) => NAT는 프라이빗 주소를 썼을 때 이것들이 통신할 수 있는 방법을 제공하는 것이다!
private network의 어떤 주소를 사용하던 데이터를 전송한 라우터에서 전송할 때 소스 주소를 public으로 바꾸는 방법을 사용한다. 외부의 호스트는 데이터가 public 주소를 통해 왔기 때문에 이 주소로 피드백한다. 그 후 라우터가 다시 프라이빗 주소로 바꿔서 데이터를 전달한다
=> 라우터는 내*외부 사이의 주소를 변환시켜주는 기능을 제공(NAT)
장점은 프라이빗 네트워크가 많이 만들어지더라도 우리가 필요한 주소는 하나만 존재한다(주소 문제를 해결)
=> 라우터에서 매핑 테이블을 가지고 있고 매핑 테이블을 통해서 주소를 바꾼다.
프라이빗 네트워크에 있는 애가 소스와 데스티네이션을 가지고 데이터를 보낸다 => 라우터에 데이터가 도착하면 라우터는 NAT 기능을 사용해서 table을 설정 => source 주소와 private 주소를 매핑시키고 데이터를 보낼 때 퍼블릭 주소로 바꿔서 보낸다.
Q. private 주소가 여러 개면 어떤 문제가?
A. 데이터가 돌아올 때 public 주소가 겹친다. 즉, 실제 데이터가 누구한테 왔는지 알 수 없다.
=> 다중 통신을 할 때 문제가 생긴다
- 추가적인 identifier를 넣어야 한다. 이때 포트번호를 사용한다. 이러면 여러 host들에서 데이터를 보낼 때 문제가 없다. But 잘 보면 문제가 있다. external port는 잘 알려진 port를 쓰기 때문에 겹칠 확률이 존재한다. ex) 172.18.3.1 1400port , 172.17.3.3 1400port 면 라우터에 같은 형태로 데이터가 들어온다.
- 호스트 A랑 B가 데이터를 보내게 되는데 보낼 때 NAT를 통해서 IP 주소를 바꾸게 되있기도 하지만 port 번호도 따로 만들게 한다.
NAT를 설계할 때 주소도 변환하지만 추가적인 identifier 가 필요하다!
# Forwarding of IP Packet
- 네트워크 레이어의 가장 핵심 디바이스는 라우터이다.
- 목적지 주소를 보고 데스티네이션을 찾아가는 과정을 자세히 알아보자
호스트 A에서 B로 갈 때 두 개의 라우터를 지나게 된다. 라우터들은 반드시 목적지 주소를 보고 어디로 갈지 결정하는 테이블을 유지해야한다.
=> 이를 보고 내가 어디로 갈지 결정
route, next hop 방식이 있다. 모든 데스티네이션에 대해 R1, R2, Host B 이렇게 쓸 수도 있고 다음에 어디로 가야할지 나타낼 수 있다.
=> 라우팅 테이블의 모든 경로를 다 쓸 필요 없다, 다음 갈 곳만!
후자가 엔트리 수가 적어서 더 좋다(서치 시간 감소)
N2를 제외하고는 나머지는 다 R2를 통해서 연결된다. 데스티네이션이라는 테이블을 next hop 방식으로 만들고 네트워크 specific 주소를 사용한다. 나머지는 다 인터넷으로 R2에 연결되어 있는데 나머지는 다 한 엔트리로 집어넣고 R2를 보내라고 만들 수 있다.
=> Default method
테이블을 유지하는 3가지 핵심 : next hop, 네트워크 specific, default method
라우터가 3개의 인터페이스를 가지고 있는데 각각 네트워크 주소를 다음과 같이 인터페이스로 지정한다. => 패킷이 들어오게 되면 destination address를 뽑아내고 테이블을 찾게 된다 => prefix들을 가지고 자신의 데스티네이션 어드레스에 대한 것을 prefix에 적용해서 그 주소가 나오게 되면 같은 네트워크에 속함으로 그 인터페이스로 데이터를 보낸다.
=> 데이터가 오면 table을 찾고 prefix를 이용해서 어떤 네트워크에 속하는지 찾아서 인터페이스로 보낸다.
- 테이블의 마지막엔 무조건 default method가 존재한다.
- 각각의 table은 토폴로지에 맞게 정의하면 된다.
EX) 목적지 주소로 180.75.65.140을 가진 데이터가 하나 왔다
1. 첫 번째 마스크 prefix=26을 적용한다(255.255.255.192)
=> 180.70.65.128이므로 180.70.65.192와 다른 네트워크 주소
2. 두번째 마스크 prefix=25를 적용한다(255.255.255.128)
=> 180.70.65.128이므로 180.70.65.128과 같은 네트워크
# Address aggregation
- R1을 보면 4개의 네트워크를 쓰고 있는데 이는 24 하나를 가진 효과와 같다. 당연히 R1은 24와 디폴트로 구성된다.
- 140.24.7.0은 m0 인터페이스를 통해서 다음 라우터로 전달되기 때문에 주소를 aggregation해서 보낸다.
데이터를 축약해서 사용한다.
# Longest Mask matching
- 하나의 네트워크를 보게 되면 가장 prefix가 큰게 자기를 제일 잘 나타내는 것이다.
엔트리가 있으면 라우팅 테이블을 검색할 때 끝까지 가서 더 자세한 주소가 있는지 확인해야 한다.
# Hierarchical routing with ISP
실제로 우리가 사용하는 라우팅 테이블은 사람이 집어넣는게 아니라 프로토콜을 통해 자동적으로 주소를 교환해서 만들어진다.
=> 이를 Hierarchical을 가지고 있다라고 한다!
테이블을 유지할 때는 원본으로, 하나의 엔트리가 유지되게 한다.
=> 테이블을 유지하기 위해 aggregation 사용, 서치할 때는 Longest mask matching을 따라야 한다.
컴퓨터 네트워크를 이해하기 위해서는 데이터 통신 내용을 알고 있다는 전제하에 전체적인 흐름을 이해하고 세부적으로 뜯어보면 이해하는데 조금 더 도움이 되지 않을까 싶다.
