240130 CS 스터디 - 네트워크

목차

 

 

DHCP(Dynamic Host Configuration Protocol)

PC 사용자에게 IP 주소, 네임서버 주소, 서브넷마스크, 게이트웨이 주소 등 TCP/IP 프로토콜의 기본 설정 값들을 자동으로 할당해주는 것을 의미하고, 해당 클라이언트에게 일정 기간 임대를 하는 동적 주소 할당 프로토콜.

 

DHCP의 구성

DHCP 서버: 클라이언트에게 IP 할당 요청이 들어오면 IP를 부여해주고 할당 가능한 IP들을 관리한다.

DHCP 클라이언트: DHCP 서버로부터 IP를 부여받으면 TCP/IP 설정은 초기화되고 다른 호스트와 TCP/IP를 사용해 통신할 수 있다.

 

DHCP의 원리

DCP 서버가 IP 주소를 영구적으로 단말에 할당하는 것이 아니고, 임대기간(IP Lease Time)을 명시하여 그 기간동안 단말이 IP 주소를 사용하도록 한다. 단말은 임대기간 이후에도 계속 해당 IP 주소를 사용하고자 한다면 IP 주소 임대기간 연장(IP Address Renewal)을 DHCP 서버에 요청해야 하고, 단말은 임대받은 IP 주소가 필요치 않게 되면 IP 주소 반납(IP Address Release)를 수행하게 된다.

 

장점

PC의 수가 많거나 PC 자체 변동사항이 많은 경우 IP 설정이 자동으로 되기 때문에 효율적으로 사용 가능하고, IP를 자동으로 할당해주기 때문에 IP 충돌을 막을 수 있다.

 

단점

DHCP 서버에 의존되기 때문에 서버가 다운되면 IP 할당이 제대로 이루어지지 않는다.

 

DHCP 프로토콜

 

IP 주소 할당(임대) 절차 (단말 <-> DHCP 서버)

 

DHCP Discover

브로드캐스트 메시지 (Destination MAC = FF:FF:FF:FF:FF:FF)

단말이 DHCP 서버를 찾기 위한 메시지.

LAN상에 (동일 subnet 상에) 브로드캐스팅을 하여 "거기 혹시 DHCP 서버 있으면 내게 응답해주세요" 라고 외친다.

 

DHCP Offer

브로드캐스트 메시지 (Destination MAC = FF:FF:FF:FF:FF:FF) 이거나 Unicast 일 수 있다.

(단말이 보낸 DHCP Discover 메시지 내의 Broadcast Flag 값이 1이면 Broadcast로, 0이면 Unicast로 보낸다.)

DHCP 서버가 "저 여기 있어요~"라고 응답하는 메시지.

단순히 DHCP 서버의 존재만을 알리지 않고, 단말에 할당할 IP 주소 정보를 포함한 다양한 네트워크 정보 (IP주소, 서브넷마스크, 게이트웨이 주소 등) 를 실어서 단말에 전달한다.

 

DHCP Request

브로드캐스트 메시지 (Destination MAC = FF:FF:FF:FF:FF:FF)

단말이 DHCP 서버(들)의 존재와 DHCP 서버가 단말에 제공할 네트워크 정보를 알았다. 이제 단말은 DHCP Request 메시지를 통해 하나의 DHCP 서버를 선택하고, 해당 서버에게 :딴말이 사용할 네트워크 정보"를 요청한다. 

 

DHCP Ack

브로드캐스트 메시지 (Destination MAC = FF:FF:FF:FF:FF:FF) 이거나 Unicast 일 수 있다.

(단말이 보낸 DHCP Request 메시지 내의 Broadcast Flag 값이 1이면 Broadcast로, 0이면 Unicast로 보낸다.)

DHCP 절차의 마지막 메시지로, DHCP 서버가 단말에게 "네트워크 정보"를 전달해주는 메시지. 앞선 DHCP Offer의 "네트워크 정보"와 동일한 파라미터가 포함된다.

 

DHCP 없이 수동으로 IP 주소를 할당하면 어떨까?
비효율적이고 시간이 지나치게 많이 소요되며 오류가 발생할 가능성이 높다.

 

참고

 

서브네팅(Subnetting)

IP 주소를 효율적으로 사용하기 위해 네트워크를 분할하는 개념.

IPv4 주소(32bit)의 고갈 문제를 해결하기 위해 등장.

 

IP 주소의 클래스

IP 주소는 크게 5개(A, B, C, D, E)의 클래스로 나누어진다.

 

 

장점

네트워크 영역은 클래스 단위로 나누게 되는데, 이때 클래스 단위로 부여하게 되면 실제 사용하는 ip는 몇 개 안되어 낭비되는 ip가 많아져 굉장히 비효율적이다.

 

예를 들어, A 클래스의 ip를 부여받음 -> A 클래스에는 16,777,214개나 되는 호스트에 IP를 할당할 수 있다.

자그마한 회사나 일반적인 사용자에게 IP를 부여하면 남는 ip들은 모두 낭비된다.

또한 A 클래스에 브로드캐스팅이 있다면 최대 16,777,214개의 호스트에 모든 데이터가 전송된다.

이는 굉장한 부하가 있어 성능저하 및 장애로 이루어질 수 있다.

 

 

 

서브넷을 만들 때 사용되는 것이 서브넷 마스크(subnet mask)

서브넷 마스크는 IP 주소에서 네트워크 주소(1)와 호스트 주소(0)를 구분하기 위해 사용.

 

참고

 

NAT (Network Address Translation)

IP 패킷에 있는 출발지 및 목적지의 IP 주소를 바꿔 재기록하면서 네트워크 트래픽을 주고받을 수 있게 하는 기술

 

동작 원리

집에서 사용하는 인터넷 공유기를 통해 외부에 있는 웹 서버로 접근하고자 할 때, 요청 패킷은 반드시 해당 공유기(게이트웨이)를 거치게 되어 있다.

이 때, 출발지의 사설망 IP 주소가 그대로 외부 인터넷에 나가게 될 경우 수신측 웹서버는 알 수 없는 사설망의 IP 이므로 패킷을 어디로 보내야 할 지 알 수 없다.

사설 네트워크와 외부 인터넷 사이의 NAT

 

따라서 NAT는 아래 과정을 거친다.

 

- PC(호스트)에서 출발

# 출발지 IP 주소 : 10.0.0.1

# 목적지 IP 주소 : 200.100.10.1

패킷 헤더에 출발지와 목적지 주소를 기록한다. 이 때 출발지는 자신의 사설망 IP 주소를 기록.

 

- 기본 게이트웨이에서 다시 출발

# 출발지 IP 주소 : 10.0.0.1 -> 150.150.0.1 (재기록하여 변경)

# 목적지 IP 주소 : 200.100.10.1

기본 게이트웨이(공유기 등)에서는 외부로 나가는 패킷을 인식하게 되면, 출발지의 IP를 게이트웨이 자신의 공인 IP 주소로 변경한다. 이 때, 별도의 NAT 테이블을 보관한다.

NAT 테이블

외부로 나가는 패킷을 어떻게 인식하는걸까? 

 

- 웹 서버에서 출발

# 출발지 IP 주소 : 200.100.10.1

# 목적지 IP 주소 : 150.150.0.1

웹 서버에서 수신한 데이터를 처리한 후, 응답하여 보내는 패킷에 위와 같이 기록하여 보낸다. 이 때, 목적지 IP 주소는 호스트의 기본 게이트웨이 공인 IP 주소가 된다.

 

- 기본 게이트웨이에서 다시 출발

# 출발지 IP 주소 : 200.100.10.1

# 목적지 IP 주소 : 150.150.0.1 -> 10.0.0.1 (재기록하여 변경)

호스트으ㅔ 기본 게이트웨이에서 웹 서버가 보낸 패킷을 받으면, 기록해두었던 NAT 테이블을 참조하여 최종 목적지인 호스트의 사설 IP 주소로 변경하여 해당 호스트로 패킷을 전달한다.

 

한 대의 호스트가 아닌 여러 대의 호스트가 같은 목적지와 통신하고자 할 때, 되돌하오는 패킷의 최종 목적지가 어디가 되어야 하는지 모르는 혼선 -> PAT (NPAT) 방식

 

정리

- 외부로 나가는 경우 : 사설 IP -> 공인 IP

- 내부로 들어오는 경우 : 공인 IP -> 사설 IP

 

공인 IP 와 사설 IP

공인 IP : 전 세계에 유일하게 할당받은 하나의 IP, 외부에 공개

사설 IP (=로컬 IP, 가상 IP) : 외부에서 접근할 수 없는 IP, 일반 가정 or 회사 내부에서 사용하는 목적

 

NAT를 통해 얻는 이점은, 외부와 통신하는 관점에서 내부 사설 IP를 노출하지 않아도 되기 때문에 보안에 유리하다.

 

대칭키 암호화 방식

암복호화에 사용하는 키가 동일한 암호화 방식

 

대표적인 알고리즘 : DES, 3DES, AES

 

Symmetric Encrytion

 

장점

공개키(=비대칭키) 암호화 방식에 비해 연산 속도가 빠르다.

 

단점

키 교환 문제 : 키를 교환하는 중 탈취될 수도 있다.

사용자가 증가할수록 각각의 키가 필요하기에, 관리해야할 키가 방대하게 많아진다.

 

이러한 문제를 해결하기 위해 키의 사전 공유, 키 배포 센터 사용, Diffie-Hellman 키 교환, 공개키 암호화 방식 등이 있다.

 

비대칭키(=공개키) 암호화 방식 

암복호화에 사용되는 키가 서로 다른 암호화 방식.

효율은 떨어지지만, 대칭키 암호화 방식의 키 교환 문제를 해결하기 위해 등장.

 

대표적인 알고리즘 : Diffie-Hellman, RSA, DSA, ECC

 

Asymmetric Encrytion

 

A가 B에게 데이터를 보낸다고 하자.

A는 B의 공개키로 데이터를 암호화해서 보내고, B는본인의 개인키로 복호화해서 보게 된다.

-> 암호화된 데이터는 B의 공개키에 대응되는 개인키를 가지고 있는 B만이 볼 수 있게 된다.

 

공개키는 키가 공개되어 있기 때문에 키 교환이 필요 없다.

중간 공격자가 B의 공개키를 얻는다고 해도 B의 개인키로만 복호화가 가능하다.

-> 키 전달 문제를 해결하여 더 안전하지만, 암호화와 복호화를 위해 복잡한 수학 연산을 수행하기 때문에 대칭키 알고리즘에 비해 속도가 느리다는 단점이 있다.

 

HTTPS

대칭키만을 사용하면 키가 탈취될 수 있다는 위험이 존재한다.

그렇다고 공개키만을 사용하면 HTTP 메시지의 길이가 큰 경우에 큰 부하가 발생할 수 있다. (공개키 알고리즘은 암호화, 복호화 과정이 매우 복잡하기 때)

 

그래서 HTTPS 에서는 공개키(=비대칭키) 방식으로 대칭키를 전달하고, 서로 공유된 대칭키를 가지고 통신하게 된다.

 

1. A는 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화해서 B에게 보낸다.

2. B는 암호문을 받고 자신의 비밀키로 복호화한다.

3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보낸다.

4. A는 자신의 대칭키로 암호문을 복화화한다.

5. 앞으로 해당 대칭키로 계속 통신한다.

 

즉 사용자 측에서는 공개키(=비대칭키) 알고리즘을 통해 안전하게 키 교환을 한 후, 교환한 키로 대칭키 알고리즘을 통해 통신하게 된다.

 

대칭키 알고리즘은 기밀성을 제공하고, 무결성/인증/부인방지를 제공하지 않는다.

공개키 알고리즘은 기밀성/인증/부인방지 기능을 제공한다.

 

 

여기서 무결성은 대칭키, 공개키 알고리즘 모두 성립하지 않는다.

따라서 전자 서명(인증서)을 추가함으로써 무결성을 보장한다.

 

참고

 

SSL (Secure Socket Layer)

SSL이란, 웹 서버와 클라이언트의 통신 암호화 프로토콜이다.

 

SSL이 적용되지 않은 경우, 평문이 그대로 전송되어 제 3자가 패킷을 탈취했을 때 그 내용을 쉽게 확인할 수 있다.

SSL을 적용하면, 요청을 암호화해서 보내므로 통신 패킷이 탈취되어도 복호화 키가 없으면 그 내용을 알 수 없다. 데이터 송/수신 과정에서 암/복호화가 발생하므로 속도가 느리다.

 

SSL Handshake

클라이언트와 서버 간의 요청/응답을 반복하며 통신에 필요한 사전 작업을 한다.

좌: 서버 / 우: 클라이언트

 

ClientHello

클라이언트가 특정 주소에 접근하면, 해당하는 서버에 요청을 보낸다. 이때 클라이언트의 주요 정보를 서버에 전송하여, 해당 클라이언트를 식별하고 어떤 암호화를 사용할 수 있는지 등의 정보를 서버가 인지하도록 한다.

 

ServerHello

서버가 ClientHello 요청을 받으면, 아래 정보를 담아 화답을 보낸다.

클라이언트가 사용 가능하다고 통보한 암호화 기법 중 서버에서 활용할 암호화 기법을 전달하여 동일한 암호화 기법으로 송수신할 수 있도록 한다. 이때 인증서 정보와 함께 서버 공개키도 전달한다. 클라이언트가 서버의 공개키로 데이터를 암호화하면, 서버는 이를 받아 개인키로 복호화하여 요청을 분석할 수 있다.

 

인증서 검토

서버가 전달한 인증서가 실제 해당 서버의 인증서인지, 신뢰할 수 있는 CA에서 발급된 것인지, 실제 해당 CA에서 발급받았는지 등 인증서를 검토한다.

 

Premaster Secret 송수신

클라이언트에서 ClientHello, ServerHello에서 송수신한 난수(Random) 데이터를 조합하여 Premaster Secret(=대칭키)을 생성한다.

이를 ServerHello에서 전달받았던 서버의 공개키로 암호화한다. 이 데이터는 서버가 가진 개인키로만 복호화가 가능하다.

서버는 수신된 데이터를 복호화하여 클라이언트와 동일한 Premaster Secret을 저장할 수 있다. 이제 클라이언트와 서버 모두 Premaster Secret을 가지고 있게 된다.

 

통신 키(Session Key) 생성

서버와 클라이언트 모두 Premaster Secret을 일련의 과정을 거쳐서 Master Secret으로 만든다.

이렇게 만든 Master Sercret으로 Session Key를 생성한다. 

 

데이터 송수신

서버와 클라이언트가 실제로 데이터를 주고받는 단계이다.

Session Key를 이용해 대칭키 암호화 방식으로 암/복호화하여 통신한다.

 

세션 종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알리고 사용했던 Session Key는 폐기한다.

 

 

SSL은 1996년 이후 업데이트 되지 않았으며, 보안취약점으로 인해 현재는 퇴출된 상태다.

현재는 모두 TLS로 교체되었지만, SSL 자체가 고유명사가 되어 넓은 의미의 통신 보안 프로토콜을 명칭하는 의미로 쓰인다.

 

참고 1

참고 2

참고 3

 

TLS (Transport Layer Security)

 

 

로드밸런싱

로드밸런싱이란 말그대로 서버가 처리해야할 업무 혹은 요청(Load)을 여러 대의 서버로 나누어(Balancing) 처리하는 것을 의미한다. 한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리하여, 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적이다.

 

쿠키와 세션

HTTP의 특징

- connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어버리는 특징

- stateless : 통신이 끝나면 상태 보를 유지하지 않는 특징

따라서 서버는 클라이언트가 누구인지 매번 확인해야 한다. 이 특성을 보완하기 위해 쿠키와 세션을 사용하는 것이다.

 

쿠키란?

클라이언트(브라우저) 로컬에 저장되는, 키와 값이 들어있는 작은 데이터 파일

 

쿠키의 동작 방식

1. 클라이언트가 페이지를 요청

2. 서버에서 쿠키를 생성

3. 서버에서 응답할 때, HTTP 헤더에 쿠키를 포함시켜 응답

4. 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음

5. 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄

6. 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

 

세션이란?

세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.

서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증 상태를 유지한다.

사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지한다.

 

세션의 동작 방식

1. 클라이언트가 서버에 접속 시 세션 ID를 발급 받음

2. 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있음

3. 클라이언트는 서버에 요청할 때 이 쿠키의 세션 ID를 같이 서버에 전달

4. 서버는 세션 ID를 전달받아서 별다른 작업 없이 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용

5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답

 

쿠키와 세션은 비슷한 역할을 하며 동작 원리도 비슷하다. 그 이유는 세션도 결국 쿠키를 사용하기 때문이다. 가장 큰 차이점은 사용자의 정보가 저장되는 위치이다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용한다.

 

세션을 사용하면 좋은데 왜 쿠키를 사용할까?

세션은 서버의 자원을 사용하기 때문에 무분별하게 만들다보면 서버의 메모리가 감당할 수 없어질 수 있기 때문에 쿠키가 유리한 경우가 있다.

 

쿠키와 세션의 차이점?

보통 쿠키와 세션의 차이를 물어볼 때 저장위치나 보안에 대해서는 잘 말하는데, 사실 중요한 것은 "라이프사이클"이다.

 

쿠키/세션과 캐시는 어떻게 다를까?

캐시는 이미지나 css, js 파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것.

한번 한 번 캐시에 저장되면 브라우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경되지 않게 보일 수 있다.

이런 부분을 캐시를 지워주거나 서버에서 클라이언트로 응답을 보낼 때 헤더에 캐시 만료 시간을 명시하는 방법 등을 이용할 수 있다.

 

참고

 

프록시 서버

프록시 = 대리자

프록시 서버는 클라이언트와 오리진 서버(원 서버, 본래 서비스를 제공하는 서버)를 중개하는 역할을 한다.

 

 

장점

- 보안적으로, 프록시 서버에서 기본적인 필터링과 엑세스 제어 등을 제공하기 때문에, 원 서버로의 직접 공격을 막을 수 있다.

- 클라이언트는 프록시 서버의 IP로 우회하여 익명성을 보장할 수 있다.

- 프록시 서버는 자주 요청되는 리소스를 캐싱하기 때문에, 원 서버의 부하도 줄여주고 응답 속도도 개선해준다.

 

프록시 캐시 서버

프록시 서버의 캐싱 기능을 메인으로 하는 서버.

 

 

클라이언트가 리소스를 서버에 요청할 때, 프록시 서버는 먼저 캐시에 리소스가 있는지 확인한다. 리소스가 있으면, 멀리 있는 원 서버를 거칠 필요없이 프록시 서버의 캐시 데이터를 전달한다.

이를 통해 응답 속도도 크게 향상시킬 수 있고 원 서버의 부하도 낮출 수 있다.

 

CDN (Contents Delivery Network)

웹 컨텐츠 전달을 목적으로 전 세계에 분산된 배포 서버 네트워크

 

각각의 CDN들은 원 서버와 캐시 동기화로 최신 상태를 유지하며, 클라이언트의 요청 시 가장 가까운 CDN으로부터 컨텐츠를 전달받는다.

 

참고