application - presentation - session - transport - network - data link - physical 순으로 네트워크를 표현한 것.
사용자가 애플리케이션을 이용해서 네트워크로 어떤 요청을 보낸다고 했을 때 애플리케이션 계층에서 사용자가 커뮤니케이션을 하고, presentation 계층에서 데이터를 암호화/복호화하는 등의 작업을 한다. 세션 계층에서는 논리적 연결 단위인 세션을 만들고 관리한다.
transport 계층에서는 tcp/udp 등의 프로토콜을 통해 패킷을 주고 받는다. 이때 tcp는 신뢰성 있는 연결을 위해 패킷의 순서와 손실 등을 확인하는 프로토콜이고 udp는 그냥 패킷을 보내는 프로토콜이다. 이 계층에서 port 정보를 헤더에 붙여준다.
network 계층은 ip 주소를 통해 목적지를 찾아 패킷을 전달하는 계층이다. data link는 mac 주소를 통해 실제 endpoint를 찾아 패킷을 전달하는 역할을 하는 계층이다. physical 계층은 실제 구리선과 같이 데이터를 전기적 신호로 바꿔 전달하는 역할을 한다.
application 계층에는 HTTP, DNS, FTP, SSH 등의 프로토콜이 있다.
presentation 계층에는 SSL, SSH, JPEG 등의 프로토콜이 있다.
실제로 적용되는 기준이 OSI 7계층에 딱 맞지 않는 부분이 있어서 이를 축약해서 사용하는 네트워크 모델이 TCP/IP 모델임.
5,6,7계층을 모아서 하나의 application 계층으로, transport는 그대로, network는 internet 계층으로, data link와 physical은 모아서 네트워크 액세스 계층으로 만든 4계층 모델이다.
4,5,6계층에서는 각각 데이터에 헤더를 붙이는데 이 헤더가 차례대로 바깥에 붙는다.
따라서 3계층의 data와 4계층의 헤더를 합쳐서 세그먼트 또는 데이터 그램이라 부르고, 이것이 5계층에서의 데이터가 된다. 5계층에서 이 데이터에 헤더를 붙여 패킷이라 부른다. 그리고 6계층에서 패킷에 6계층의 헤더를 붙이면 프레임이 된다.
data link에서는 MAC 주소, network에서는 IP 주소와 각종 플래그나 체크섬이 붙는다. transport에서는 port 정보와 ACK,SYN등 오류 제어 흐름제어를 위한 플래그 정보가 붙는다. udp 프로토콜을 쓰면 오류 제어, 흐름 제어를 하지 않아 port 정보와 체크섬 정도만 있다.
웹상에서 데이터를 주고 받기 위해 사용하는 프로토콜.
상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.
메소드에는 GET, POST, PATCH, PUT, DELETE, HEAD 등이 있다.
요청 시 헤더에는 Accept, Host, Authorization, Origin 등의 정보를 담을 수 있고,
응답 시 상태 코드와 함께 헤더에 Content-type, Set-Cookie, Server, Acess-Control-Allow-Origin 등의 정보를 담을 수 있다.
HTTP에 SSL 프로토콜이 추가된 것이 HTTPS.
SSL 프로토콜은 인증서를 기반으로 데이터를 암호화/복호화하기 위한 프로토콜임.
서버에서 인증서를 건네주면 클라이언트가 CA의 공개키로 인증서를 복호화하여 나온 정보로 서버가 일치함을 확인하고 인증서를 복호화해서 나온 서버의 공개키로 세션키를 암호화해서 서버에 전달한다.
그럼 서버는 가지고 있는 개인키로 복호화해서 세션키를 확인한다.
이후 이 세션키로 데이터를 암호화 복호화해서 소통함.
인증 과정은 비대칭키를 통해 안전하게 하고 이후 데이터를 주고받는 과정에서는 대칭키로 빠르게 소통.
비대칭키의 역할*
(인증서는 서버가 CA에 공개키와 서버 정보를 주면 CA가 자기 개인키로 암호화해서 인증서를 만들어줌. 그럼 서버가 이 인증서를 가지고 자기를 인증할 수 있음) - 디지털 서명
(클라이언트는 CA를 통해 전달받은 공개키로 세션키를 암호화해서 보내면 서버가 자기만 가지고 있는 개인키로 복호화해서 내용을 확인할 수 있음. 중간에 탈취되더라도 개인키를 가지고 있지 않은 공격자는 내용을 확인할 수 없음) - 공개키 암호화
둘다 같은 건데 이름만 바꾼거. 버전 차이라고 생각하면 됨.
주요 차이점은 SSL은 MAC을 이용해 메시지 변조를 확인, TLS는 MAC이 아니라 암호화 등을 이용해 확인한다고 함.
TCP는 신뢰성 있는 전송을 보장하기 위해 오류 제어, 흐름 제어, 속도 제어 등을 지원함.
이때 ACK, SYN, FIN 등의 플래그를 이용.
UDP는 신뢰성을 보장하지 않지만 대신 빠른 전송이 가능.
3-way handshaking을 통해 처음에 연결을 수립함.
클라가 SYN = 1 을 보내면 서버가 ACK=1, SYN=1을 보내고, 이걸 받은 클라가 ACK=1을 보내면 연결이 수립되고 이후부터 데이터를 보냄.
데이터를 보낼 때도 SYN=2와 같이 순서를 명시해서 보내면 서버가 이 SYN을 ACK로 바꿔서 ACK=2, SYN=3
www.naver.com 같은 도메인 주소를 치면 먼저 dns 서버에 요청을 보내 실제 ip 주소를 알아냄. ip 주소가 같은 서브넷이 아닌 경우, arp 테이블을 통해 라우터 mac 주소를 알아낸 후 라우터로 패킷을 전달함(목적지 ip 주소는 네이버 ip, 목적지 MAC 주소는 라우터이자 default gateway mac 주소)
라우터는 NAT를 통해 출발지 ip 주소를 자기 공인 ip로 바꾸고 라우팅을 통해 네이버 ip 주소를 찾아간다.
각 라우터는 네이버 ip를 찾아가기 위해 거쳐야 하는 다음 next_hop router를 찾고 해당 라우터의 MAC 주소를 destination으로 바꿔가며 전달한다.
네이버 서버 LAN의 라우터까지 도착하면 NAT를 통해 실제 private ip 주소를 찾고 패킷을 전달한다.
라우팅 참고: https://run-it.tistory.com/24
NAT 참고: https://run-it.tistory.com/24
목적지 ip 주소의 MAC 주소를 알아내기 위한 프로토콜이다.
같은 네트워크 내에 브로드캐스트하여 ip 주소에 해당하는 컴퓨터가 자신의 MAC 주소를 응답해줌.
목적지 주소 ip가 같은 네트워크 내에 있으면 브로드캐스트로 찾고,
같은 네트워크가 아니면 라우터(default gateway)의 MAC 주소를 찾아서 라우터로 패킷을 전달함.
사설 IP를 공인 IP로, 공인 IP를 사설 IP로 바꿔주는 것.
static NAT, dynamic nat, pat가 있음.
static NAT는 기본적으로 1:1로 매칭해놓은 것. 이건 공인 IP 절약 효과가 없음.
dynamic NAT는 라우터가 공인 IP를 5개 가지고 있고 연결된 장치가 10개라고 하면 그때그때 요청이 나갈 때 장치마다 공인 IP 하나씩 할당해서 NAT 테이블에 갖고 있는 것. 할당된 공인 IP보다 많은 장치를 커버할 수 있지만 동시에 공인 IP를 사용할 수 있는 장치 수가 제한됨. 만약 5개 장치가 이미 공인 IP를 하나씩 할당받고 있으면 다른 5개 장치는 요청을 못 보냄.
PAT는 port 정보까지 활용해 매핑하는 것. 예를 들어 장치가 5개면 A 장치의 5000번 포트에서 요청이 나갈 때 라우터 공인 IP와 port 3000번을 매핑해주는 것. 하나의 공인 IP로 여러대의 서버에 연결 가능함.
네트워크에서 사용하는 주소임.
IPv4와 IPv6가 있음.
IPv4는 8 bit씩 4옥텟으로 이루어진 주소 구조임. 전체 2^32만큼의 주소가 있음.
이중 앞에서부터 서브넷 마스크만큼의 비트가 네트워크 주소, 나머지 비트는 호스트 주소를 나타냄.
IPv6는 16 bit씩 8옥텟으로 이루어짐. 즉 2^128개 만큼의 주소가 있음.
Classless Inter-Domain Routing
서브넷 마스크로 네트워크 크기를 식별하는 것.
이전에는 class 기법을 사용해서 A,B,C,D,E 클래스를 두고 각각 ip 주소 영역과 크기를 식별했음. 각 클래스별로 가용 가능한 호스트 개수가 고정되어있고 각 클래스마다 그 개수가 심하게 차이났음. 그래서 애매하게 사용되지 않고 남는 호스트 주소가 많았음.
서브넷 마스크로 비트 단위로 네트워크/호스트 주소 범위를 조정할 수 있게 한 게 CIDR임.
192.168.10.1/24 와 같은 경우 맨 뒤 / 뒤에 붙은 게 서브넷 마스크.
24라는 값은 네트워크 주소를 의미하고 32에서 24를 뺀 값이 호스트 주소임.
IPv4는 8 bit씩 4 옥텟이므로 192.168.10까지 네트워크 주소고, 1이 호스트 주소임.
호스트 주소 범위가 0~255로 이중 0은 게이트웨이, 255는 브로드캐스트 주소임. 즉, 서브넷 마스크가 24면 254개의 호스트를 가질 수 있음.
네트워크 랜카드에 있는 주소. 장치마다 모두 각각 다른 고유한 주소를 가지고 있음. ARP 프로토콜을 통해 같은 네트워크 내에 존재하는 장치에 대해 MAC 주소를 알아낼 수 있음.
사람이 읽을 수 있는 도메인 주소를 실제 IP 주소로 변환해주는 프로토콜.
dns 서버는 계층 구조로 root dns 서버아래에 TLD dns 서버, 그 아래에 second-level dns 서버가 있음
(root - .com TLD - .example.com SLD 와 같은 순서)
우리가 컴퓨터에서 dns 프로토콜을 요청하면 kt와 skt 같은 네트워크 제공자에서 제공하는 local dns 서버(아니면 직접 구축한 local dns 서버도 가능)로 일단 요청이 감.
로컬 dns 서버에서 모르는 dns면 root dns로 요청을 보냄. 그럼 root dns가 .com TLD 주소를 줌. 그럼 로컬 dns 서버가 .com TLD로 요청을 보냄. 그 친구도 모르면 .example.com dns 서버 주소를 줌. 그럼 다시 거기로 요청을 보냄. 만약에 .example.com 이 실제로 www.example.com 도메인 주소에 대한 ip 매핑 값을 가지고 있으면 .example.com 도메인 서버를 authoritative dns 서버(권한 있는 dns 서버)라고 함.
다시 말해, 권한 있는 dns 서버는 실제 도메인과 그에 매핑되는 ip 주소 레코드를 가지고 있는 dns 서버임.
한번 찾아온 dns는 캐싱을 통해 기억해두고 다음 번에 동일한 도메인이 들어오면 빠르게 응답함.
dns 캐싱을 통해 더 빨리 응답 받을 수 있고, 네트워크 트래픽을 줄일 수 있으며, 루트 서버나 권한 서버가 받는 부하를 줄일 수 있음.
이때 dns 캐싱은 여러 위치에서 수행할 수 있음.
1) 브라우저
2) 운영체제
3) 일부 라우터
4) Local DNS 서버 (=Recursive DNS 서버)
참고: https://velog.io/@cieroyou/DNS-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
참고: https://ssudalim.tistory.com/4
dns 캐시 중독(캐시에 있는 ip를 악성 웹 사이트 주소로 수정),
dns 반사 공격(dns 서버에 요청을 보내는데 요청 주소를 피해자 주소로),
dns 리소스 소진 공격(가짜 dns 서버 만들고 권한 dns 서버를 피해자 주소로 응답)
참고: https://www.itworld.co.kr/tags/1037/DNS/108921
direct server return
로드 밸런서를 통해 들어온 패킷을 다시 로드 밸런서를 거치지 않고 클라이언트에게 바로 응답하기 위한 방법.
응답시 source ip를 로드 밸런서의 vip로 설정하여 클라이언트가 패킷을 버리지 않고 사용하도록 속임.