[CS] 가상 메모리와 HTTP vs. HTTPS

1. 가상 메모리

1. 가상 메모리란?

가상 메모리는 프로세스가 실제 물리 메모리인 RAM의 크기와 관계없이 자신만의 연속된 메모리 공간을 사용하는 것처럼 보이게 하는 메모리 관리 기법.

 

각 프로세스는 독립적인 가상 주소 공간을 사용하며 CPU가 생성한 가상 주소는 MMU에 의해 실제 RAM의 물리 주소로 변환된다.

 

가상 메모리는 일반적으로 메모리를 일정한 크기의 페이지로 나누어 관리한다. 이에 대응하여 물리 메모리는 같은 크기의 프레임으로 나뉜다.

• 페이지 : 가상 메모리를 나눈 고정 크기의 블록
• 프레임 : 물리 메모리를 나눈 고정 크기의 블록
• 페이지 테이블 : 가상 페이지와 물리 프레임의 대응 관계를 저장하는 자료구조

예를 들어 프로세스가 가상 페이지 3에 접근하면 페이지 테이블을 확인하여 해당 페이지가 실제 RAM의 어떤 프레임에 저장되어 있는지 찾는다.

2. 가상 메모리를 사용하는 이유

1. 프로세스 마다 독립된 주소 공간을 제공한다.

 

각 프로세스는 자신만의 가상 주소 공간을 사용해서 다른 프로세스의 메모리에 직접 접근하기 어렵고, 프로세스 간 메모리를 안전하게 격리할 수 있다.

두 프로세스가 동일한 가상 주소를 사용하더라도 실제로는 서로 다른 물리 메모리를 사용할 수 있다.

 

2. 물리 메모리보다 큰 프로그램을 실행할 수 있다.

 

프로그램의 모든 데이터를 RAM에 한 번에 적재하지 않고 현재 필요한 부분만 RAM에 올릴 수 있다.

당장 사용하지 않는 페이지는 디스크의 스왑 영역 등에 보관했다가 필요할 때 RAM으로 가져온다. 따라서 프로세스의 전체 가상 주소 공간이 물리 메모리보다 크더라도 프로그램을 실행할 수 있다.

 

다만 디스크는 RAM보다 훨씬 느리기 때문에 페이지 교체가 자주 발생하면 성능이 크게 저하될 수 있다.

 

3. 메모리를 효율적으로 사용할 수 있다.

 

프로그램 전체가 아니라 실제로 접근하는 페이지만 RAM에 적재하는 요구 페이징을 사용할 수 있다.

이를 통해 사용하지 않는 코드와 데이터를 처음부터 모두 메모리에 올리는 낭비를 줄일 수 있다.

3. 페이지 폴트란?

프로세스가 접근하려는 가상 페이지가 현재 물리 메모리에 존재하지 않을 때 발생하는 예외다.

 

페이지 폴트라는 이름 때문에 항상 오류라고 생각할 수 있지만, 요구 페이징을 사용하는 운영체제에서는 정상적으로 발생할 수 있는 상황이다.

 

예를 들어 프로그램이 처음으로 특정 코드나 데이터에 접근했는데 해당 페이지가 아직 RAM에 적재되지 않았다면 페이지 폴트가 발생한다.

4. 페이지 폴트 처리 과정

1. CPU가 가상 주소에 접근한다.
2. MMU가 페이지 테이블을 확인한다.
3. 해당 페이지가 RAM에 없으면 페이지 폴트 예외가 발생한다.
4. CPU의 제어권이 운영체제의 페이지 폴트 처리 루틴으로 넘어간다.
5. 운영체제가 해당 메모리 접근이 유효한지 확인한다.
6. 유효한 접근이라면 디스크에서 필요한 페이지를 찾는다.
7. 비어 있는 프레임에 페이지를 적재한다.
8. 빈 프레임이 없다면 페이지 교체 알고리즘을 통해 기존 페이지를 내보낸다.
9. 페이지 테이블을 갱신한다.
10. 중단되었던 명령어를 다시 실행한다.

페이지 폴트가 발생했다고 해서 무조건 디스크의 스왑 영역에서 데이터를 가져오는 것은 아니다. 실행 파일이나 메모리 매핑 파일에서 페이지를 읽어올 수도 있으며, 처음 사용하는 메모리라면 운영체제가 새로운 페이지를 할당할 수도 있다.

5. 유효한 페이지 폴트와 잘못된 메모리 접근

페이지 폴트가 발생했을 때 운영체제는 접근한 주소가 정상적인 가상 주소 공간에 포함되는지 확인한다.

 

유효한 접근

 

프로세스에 할당된 주소이지만 페이지가 아직 RAM에 적재되지 않은 경우다.

운영체제가 페이지를 RAM으로 가져온 후 명령어를 다시 실행한다.

 

유효하지 않은 접근

 

프로세스에 할당되지 않은 주소에 접근했거나 쓰기 권한이 없는 페이지를 수정하려는 경우다.

이 경우 운영체제는 요청을 정상적으로 처리할 수 없으므로 프로세스를 종료하거나 예외를 전달한다. 대표적으로 Segmentation Fault가 발생할 수 있다.

 

따라서 모든 페이지 폴트가 프로그램 오류인 것은 아니지만, 잘못된 메모리 접근 역시 페이지 폴트를 통해 감지될 수 있다.

6. 페이지 폴트가 성능에 미치는 영향

페이지 폴트를 처리하면서 디스크 접근이 필요한 경우 RAM 접근보다 훨씬 많은 시간이 필요하다.

 

메모리가 부족하여 페이지를 RAM과 디스크 사이에서 계속 교체하면 CPU는 실제 작업보다 페이지 교체에 더 많은 시간을 사용하게 된다. 이러한 현상을 스래싱(Thrashing)이라고 한다.

2. HTTP와 HTTPS

1. HTTP란?

클라이언트와 서버가 요청과 응답을 주고받기 위한 애플리케이션 계층 프로토콜

기본적인 HTTP 통신은 데이터를 암호화하지 않는다. 네트워크 구간에서 패킷이 노출되면 요청 URL, 헤더, 쿠키, 요청 본문 등의 내용을 읽을 수 있다.

또한 통신 상대가 실제 서버인지 검증하거나 데이터가 중간에 변조되지 않았음을 보장하는 기능도 HTTP 자체에는 없다.

2. HTTPS란?

HTTPS(HTTP Secure)는 HTTP 데이터를 TLS로 암호화하여 전송하는 방식이다.

HTTPS는 다음 세 가지를 제공한다.

특징	설명
기밀성	데이터를 암호화하여 제3자가 내용을 읽기 어렵게 한다.
무결성	데이터가 전송 중 변조되었는지 확인한다.
인증	인증서를 통해 접속한 서버의 신원을 확인한다.

3. HTTP와 HTTPS의 차이

구분	HTTP	HTTPS
암호화	제공하지 않음	TLS를 통해 암호화
데이터 보호	평문이 노출될 수 있음	암호화된 데이터 전송
서버 인증	제공하지 않음	인증서를 통해 서버 확인
무결성 검증	제공하지 않음	데이터 변조 여부 검증
기본 포트	80	443
URL	http://	https://

 

HTTPS가 사용되더라도 통신 양 끝인 브라우저나 서버 자체가 해킹된 경우까지 해결하는 것은 아니다. HTTPS는 기본적으로 클라이언트와 서버 사이의 전송 구간을 보호한다.

4. 대칭키와 비대칭키

대칭키 암호화

평문 + 대칭키 -> 암호문
암호문 + 같은 대칭키 -> 평문

 

연산 속도가 빨라 실제 데이터를 암호화하는데 적합하다. 하지만 클라이언트와 서버가 같은 키를 가져야 하므로 통신 전에 키를 안전하게 공유하는 방법이 필요하다. 대칭키가 유출되면 해당 키로 암호화한 데이터를 복호화할 수 있다.

 

비대칭키 암호화

 

공개키와 개인키라는 서로 다른 두 개의 키를 사용하는 방식이다.

• 공개키 : 외부에 공개할 수 있는 키
• 개인키 : 소유자만 보관해야 하는 키

비대칭키 암호화는 대칭키 암호화보다 연산 비용이 크다. HTTPS에서는 모든 데이터를 비대칭키로 암호화하지 않고 서버 인증과 안전한 키 합의에 활용한다.

5. TLS가 데이터를 안전하게 전송하는 과정

HTTPS 통신은 크게 TLS Handshake와 실제 데이터 전송 과정으로 나눌 수 있다.

 

1단계: 클라이언트가 연결을 요청한다

 

클라이언트는 서버에 TLS 연결을 요청하면서 다음과 같은 정보를 전달한다.

• 클라이언트가 지원하는 TLS 버전
• 지원하는 암호화 알고리즘
• 키 합의에 필요한 정보
• 임의의 값 
•  
• 클라이언트 → 서버 "사용 가능한 TLS 버전과 암호화 방식은 이것입니다."

2단계: 서버가 인증서를 전달한다

 

서버는 사용할 TLS 설정을 선택하고 자신의 인증서를 클라이언트에게 전달한다.

인증서에는 일반적으로 다음 정보가 포함된다.

• 서버의 도메인
• 서버의 공개키
• 인증서 유효 기간
• 인증서를 발급한 인증기관
• 인증기관의 전자서명

서버의 개인키 자체가 클라이언트에게 전달되는 것은 아니다. 개인키는 서버만 안전하게 보관한다.

 

3단계: 클라이언트가 인증서를 검증한다

 

클라이언트는 브라우저나 운영체제가 신뢰하는 인증기관(CA)의 정보를 이용하여 인증서를 검증한다.

주요 검증 내용은 다음과 같다.

• 신뢰할 수 있는 인증기관이 발급했는가?
• 인증서의 전자서명이 올바른가?
• 현재 접속한 도메인과 인증서의 도메인이 일치하는가?
• 인증서의 유효 기간이 지나지 않았는가?
• 인증서가 폐기되지 않았는가?

검증에 성공하면 클라이언트는 인증서에 포함된 공개키가 해당 서버의 것이라고 신뢰할 수 있다.

 

4단계: 키 합의를 통해 세션 키를 만든다

 

클라이언트와 서버는 비대칭키 기반의 키 합의 과정을 통해 이후 통신에서 사용할 대칭키를 생성한다.

 

과거의 일부 TLS 방식에서는 클라이언트가 대칭키 생성에 사용할 값을 서버의 공개키로 암호화하여 전달했다. 서버는 자신의 개인키로 이를 복호화했다.

 

하지만 현대 TLS에서는 주로 ECDHE와 같은 키 합의 방식을 사용한다. 클라이언트와 서버는 각자 비밀값을 유지하면서 공개 정보를 교환하고, 양쪽에서 동일한 공유 비밀을 계산한다. 이 공유 비밀로부터 실제 통신에 사용할 세션 키를 만든다.

 

이때 서버는 자신의 개인키로 핸드셰이크 정보에 서명하여 자신이 인증서의 실제 소유자임을 증명한다.

서버의 공개키·개인키
→ 서버 인증과 핸드셰이크 서명

ECDHE 등의 키 합의
→ 공유 비밀 생성

공유 비밀
→ 데이터 암호화용 대칭키 생성

즉, 비대칭키는 서버 인증과 안전한 키 합의에 사용되고, 실제 HTTP 데이터는 대칭키로 암호화된다.

 

5단계: 핸드셰이크의 무결성을 확인한다

 

클라이언트와 서버는 지금까지 주고받은 핸드셰이크 메시지가 변조되지 않았는지 확인한다.

양쪽이 동일한 키를 생성했고 핸드셰이크 내용에도 문제가 없다는 것이 확인되면 TLS 연결이 성립한다.

 

6단계: 대칭키로 HTTP 데이터를 암호화한다

 

TLS 연결이 완료된 후에는 합의된 대칭키를 사용하여 실제 HTTP 요청과 응답을 암호화한다.

HTTP 요청
   ↓ 대칭키로 암호화
암호화된 데이터 전송
   ↓ 대칭키로 복호화
서버가 HTTP 요청 처리

 

실제 데이터 통신에는 빠른 대칭키 암호화가 사용된다. 또한 인증 태그 등을 통해 데이터가 전송 중 변조되지 않았는지도 확인한다.

6. 대칭키와 비대칭키를 함께 사용하는 이유

비대칭키 암호화는 안전한 인증과 키 합의에 유리하지만 연산 비용이 크다. 반면 대칭키 암호화는 빠르지만 키를 안전하게 공유하는 것이 어렵다.

 

TLS는 두 방식의 장점을 결합한다.

암호화 방식	TLS에서의 역할
비대칭키	서버 인증, 전자서명, 안전한 키 합의
대칭키	핸드셰이크 이후 실제 HTTP 데이터 암호화

 

따라서 HTTPS는 비대칭키로 모든 데이터를 암호화하는 방식이 아니다. 비대칭키 기술을 이용해 상대를 인증하고 안전하게 세션 키를 합의한 뒤, 실제 데이터는 빠른 대칭키로 암호화한다.