라우터들이 있음
프로토콜 IP 패킷에 segment가 담긴다
라우터들은 IP 패킷 포맷의 정보만 전달할 수 있다.
각각의 라우터들은 네트워크 계층까지만 갖고 있음. 그 위 App, Trans 계층 갖고있지 않음
라우터의 주요 기능 2가지
forwarding
- 인터페이스로 패킷이 들어오면, 목적지 주소를 보고 데이터를 정확히 forwarding 해준다.
- 작업 자체는 단순하지만, 빠르게 처리해야 한다.
- Best Effort 방식으로 패킷 전달 : 최선을 다한다. = 유실, 딜레이에 대한 guarantee X
- 따라서 상위 계층인 TCP가 그런 부분을 보장해줌
routing
- 라우터 내부의 forwarding table entry를 채우는 것이 routing이다.
forwarding table
longest prefix matching
패킷의 목적지 주소와 맞는 범위를 찾을 때, 가장 길게 prefix부분이 매칭되는 범위를 선택하여 포워딩한다
라우터의 구조 (참고)
- 라우터의 인터페이스마다 별도로 포워딩 테이블과 버퍼 등이 있음
- 병렬처리가 가능 -> 빠른 처리를 위함
IP : Internet Protocol
현재 인터넷은 TCP/IP 기반이다.
무조건 IP 패킷 형태로 포맷이 되어있어야지만 목적지로 데이터를 전달할 수 있다는 뜻
TTL(Time To Live)
- 패킷의 수명
- 라우터를 거칠 때마다 1씩 줄어듦
- 0이 되면 패킷은 사라진다
- 네트워크 상황의 문제 발생으로 인해 무한루프 도는 상황에서, 패킷이 영원히 남아있지 않도록 하기 위한 방지책
헤더의 최소 크기는 40 byte
크기가 딱 40byte짜리인 애들은? : TCP ACK용도의 패킷
IP address(IPv4)
- 32-bit의 주소공간을 가진 2진수의 집합
- IP주소는 특정 호스트를 지정하는 것이 아니다
- 정확히는 네트워크 인터페이스를 지칭하는 것
- 한 기기에 인터페이스가 여러 개인 경우도 있음 : 라우터!
Scalability Challenge
- 필요할 때마다 IP주소를 주면 포워딩 테이블 엔트리 개수가 무지막지하게 커짐
- 포워딩 테이블이 커진다 = 매칭 시간이 오래 걸린다
Scalability Improved
- Scalability Challenge를 해결하기 위해서는 IP주소를 계층화 해야 한다
- 32비트의 공간을 통으로 사용하는 것이 아니라 계층화해서 prefix 부분(=네트워크 ID 부분)과 host부분으로 나눈다
- 그렇게 되면 포워딩 테이블의 엔트리가 단순해지고 매칭도 빨라짐 + 관리도 쉬움. 새로운 호스트 등장하면 네트워크 아이디 이미 있으니까 host 아이디만 새로 배정해주면 됨
*subnet mask
어디까지가 네트워크 아이디인지 기계가 이해하기 쉽도록 한 것이 subnet mask
IP주소 중에서 어디까지가 서브넷 ID인지를 나타내는 것
Classful Addressing
네트워크 아이디 부분의 크기 설정 이슈
- 과거에는 IP 주소를 8비트씩 고정해서 클래스로 나눠서 분리
- 네트워크 아이디 부분을 제외한 나머지가 호스트 부분인데, 호스트 부분(개수)이 충분하지 않을 수 있다.
- 그렇다고 또 호스트를 크게 줘버리면 전 세계에서 사용할 수 있는 네트워크 개수가 적어짐.
네트워크, 호스트 크기를 고정할 수 없음. 기관마다 네트워크 크기가 다르기 때문
CIDR : Classes Inter-Domain Routing
- 따라서 현대에는 IP주소 크기를 고정시키지 않고 가변적으로 사용하고 있음
- 8비트씩 고정해서 나누는 것이 아니라, 네트워크 기관 크기에 맞게 유동적으로 배정
서브넷
- 같은 네트워크 id를 가진 인터페이스의 집합
- 라우터를 거치지 않고 접근할 수 있는 인터페이스들의 집합(같은 서브넷에 있으면 라우터 거치지 않고 서로 직접 접근 가능)
*라우터 : 인터페이스가 여러 개 있는 디바이스. 인터페이스만큼 ip주소를 갖는다. 각각 인터페이스의(ip 주소의) 서브넷이 다르다. 교집합. 다른 서브넷으로 가려면 라우터를 거칠 수밖에 없음
라우터 사이의 연결도 서브넷이다!
개같이 발전하자 개발