1970~80년대에는 서로 다른 시스템끼리 통신이 불가능했고, 모든 제조사가 따를 수 있는 공통 규약을 제시하여 통신이 가능하도록 탄생했다.
OSI 모델 자체는 훌륭한 개념적 프레임워크로 성공했지만, 실제 구현(OSI 프로토콜 스위트)는 복잡하고 무거워서 실패함..
데이터 전송 시: 7계층 -> 1계층 (캡슐화)
데이터 수신 시: 1계층 -> 7계층 (역캡슐화)
[7계층] - Application (응용 계층)
사용자가 웹 브라우저에서 "www.example.com" 입력하면, HTTP, FTP, SMTP, DNS 등의 프로토콜이 동작하는 계층
[6계층] - Presentation (표현 계층)
데이터를 네트워크에서 전송 가능한 형식으로 변환한다. 문자 인코딩(ASCII, UTF-8), 암호화/복호화(SSL/TLS) 와 같은 작업
[5계층] - Session (세션 계층)
통신 세션의 생성, 유지, 종료를 관리
[4계층] - Transport (전송 계층)
세그먼트로 데이터를 분할해서 포트 번호로 애플리케이션을 식별하도록 하는 작업, TCP, UDP 헤더를 데이터에 추가해서 흐름, 오류등을 제어함
[3계층] - Network (네트워크 계층)
서로 다른 네트워크 간의 경로 설정 및 논리적 주소를 지정한다. IP 주소로 목적지를 식별하고 패킷 단위로 처리한다.
[2계층] - Data Link (데이터 링크 계층)
같은 네트워크 내에서 물리적 주소로 데이터 전송, 오류 검출, MAC 주소로 하드웨어 식별을 한다.
[1계층] - Physical (물리 계층)
실제 물리적 매체를 통한 비트 전송 - UTP 케이블, 광섬유를 타고 디지털 데이터를 전기신호로 전송
데이터에 TCP/UDP 헤더를 추가해서 세그먼트
여기에 IP 헤더를 추가해서 패킷
여기에 Ethernet 헤더, FCS를 추가해서 프레임
이것을 비트 스트림으로 전송하게 된다.
군사적 목적 때문에 핵전쟁 시에도 살아남을 수 있는 네트워크 구축을 목적으로 태어났다. 그래서 일부 노드가 파괴되어도 통신이 계속 가능한 분산형 네트워크가 필요했다.
[4계층] - Application Layer (OSI의 응용+표현+세션)
HTTP/HTTPS: 웹 브라우징 - 80/443
FTP: 파일 전송 - 20/21
SMTP: 이메일 전송 - 25
DNS: 도메인 이름 해석 - 53
SSH: 원격 접속 - 22
Telnet: 원격 터미널 - 23
www.google.com -> DNS로 도메인을 IP 주소로 변환 -> HTTP 요청 메시지 생성 (GET / HTTP / 1.1 / Host: www.google.com)
[3계층] - Transport Layer (전송 계층)
TCP 3-Way Handshake (연결 설정)
1. 연결 요청 - SYN (seq=100)
2. 연결 수락 - SYN + ACK (seq=300,ack=101)
3. 연결 확립 - ACK (ack=301)
TCP 헤더에는 Sequence Number, Acknowledgment Number, Flags, Window Size 와 같은 정보가 담겨서 신뢰성을 보장할 수 있음 (연결 지향)
UDP 헤더에는 Source Port, Destination Port 와 같은 기본 적인 헤더만 들어가(8 byte) 빠르지만 신뢰성이 없음 (비연결 지향)
[2계층] - Internet Layer (인터넷 계층)
이제 만들어진 세그먼트를 목적지까지 전달하기 위한 경로를 설정 해서 패킷으로 만든다.
IPv4 주소 : 192.168.1.100 (32비트 약 43억 개의 주소)
현재 43억개로 부족해버림..
IPv6 주소 : 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (128비트 10의 36승 개 주소)
그렇지만 기존 IPv4 방식으로 완전히 대체는 힘들고 아껴 쓰자
[1계층] - Network Access Layer (OSI의 데이터링크+물리)
MAC 주소를 지정하고 프레임을 구성하여 물리적 전송을 담당한다.
Ethernet 프레임 구조로
Preamble + Dest MAC + Source MAC + Type + Data + FCS 로 구성된다.
Application Layer
사용자: "www.google.com" 입력
DNS: www.google.com → 142.250.196.174
HTTP GET 요청 생성
Transport Layer
TCP 3-way handshake로 연결 설정
출발지 포트: 54321 (임의)
목적지 포트: 80 (HTTP)
TCP 헤더 추가
Internet Layer
출발지 IP: 192.168.1.100 (내 PC)
목적지 IP: 142.250.196.174 (Google)
IP 헤더 추가
라우팅 테이블 확인 → 게이트웨이로 전송
Network Access Layer
ARP로 게이트웨이 MAC 주소 확인
Ethernet 헤더 추가
물리적 신호로 변환하여 전송
아까 IPv4 가 주소가 부족하다고 했는데 이를 해결하기 위한 방법이 바로 서브넷 마스크와 서브넷 분할이다.
초기 IPv4는 클래스로만 나눠서 주소를 할당할 때 낭비가 발생했다. 그렇기 때문에 주소를 필요한 만큼 정확하게 나눠서 사용할 수 있도록 할 수 있다.
[동작원리]
쉽게 설명하자면 기존에 클래스 별 분리 방식은 10.0.0.0 을 받으면 10.0.0.0 부터 10.255.255.254 까지 약 1600만개를 배정 받았다. A클래스는 1600만개, B클래스는 6만개, C클래스는 254개 로 세밀한 분배 불가능!
그것을 서브넷 마스크와의 AND 연산을 통해서 세밀하게 분배할 수 있게 되었다!
네트워크를 분리해서 브로드캐스트 때문에 네트워크 속도가 느려지는 것을 방지하고, 네트워크 망분리를 통해 보안을 강화하고, IP도 효율적으로 사용할 수 있다.
[동작원리]
호스트 비트 일부를 빌려서 네트워크 비트로 만들어서 내부에서 분리하여 사용한다.
만약 각 부서별로 나눈다고 하였을 때 필요 인원(비트)을 분석한 후 큰 서브넷부터 할당한다.
그렇게 분리한 후 독립적으로 관리되어 보안, 효율성을 가질 수 있다.
이제 이렇게 많은 IP를 할당 받았는데 사람들에게 일일이 설정해줘야 할까?
DHCP 프로토콜을 사용하면 PC를 네트워크에 연결만 하면 자동으로 IP 주소 할당, 서브넷 마스크 설정, 게이트웨이 설정, DNS 서버 설정, 임대 시간 관리 모든 것이 자동으로 된다!
유니캐스트 = 1 : 1 통신
브로드캐스트 = 1 : ALL 통신
멀티캐스트 = 1 : GROUP 통신
애니캐스트 = 1 : 가장 가까운 하나 통신
DHCP를 사용하지 않고 수동으로 설정한 IP 주소를 고정해서 계속 사용하는 것이 Static IP 인데 각각의 장단점을 비교하자면
[장점]
1. DHCP를 사용하면 애플리케이션 설정 파일을 계속 수정(host)이 필요하고, 연결이 끊기는 것이 발생할 수 있다.
2. DHCP 서버 의존성이 없고, 접속이 용이하다.
3. 공유기 설정이 변하지 않고, 보안 정책을 적용하는 것이 용이하다. (관리가 편함)
[단점]
1. 초기 설정이 너무 힘들고, 수정 시 번거롭다.
2. IP 주소 낭비가 발생할 수 있고, 유연성이 부족하다.
3. 모바일 기기에 부적합하다.
위에 Static IP 과 반대로 굉장히 편리하고 유연하다.
단점으로는 DHCP 서버 의존성이 생기고, 악의적인 DHCP 서버 공격이 가능해진다.
또한, 트러블 슈팅이 어려워지고, 네트워크 부하가 생길 수 있다.(브로드캐스트 트래픽)
[Static IP 영역] (192.168.1.1~50)
게이트웨이: .1
DNS 서버: .10
DHCP 서버: .11
웹 서버: .20
DB 서버: .21
프린터: .30~35
관리자 PC: .40~45
[DHCP 풀] (192.168.1.100~254)
일반직원 PC, 노트북, 모바일
이런식으로 분리해서 유연하게 하이브리드 방식으로 각각의 장단점에 맞춰서 운영한다.