HLS(HTTP Live Streaming)는 Apple이 개발한 비디오 스트리밍 프로토콜로, 주로 인터넷을 통해 오디오 및 비디오 콘텐츠를 실시간 또는 주문형(on-demand)으로 전달하는 데 사용

핵심 개념

• HTTP 기반
• 콘텐츠를 일반 HTTP 서버를 통해 전송하므로 방화벽, CDN, 캐시 서버와 잘 호환
• Segment(조각) 방식 전송
• 전체 비디오를 작게 분할(보통 2~10초)한 .ts 파일로 쪼개어 순차적으로 전송
• M3U8 플레이리스트 사용
• .m3u8 형식의 플레이리스트 파일을 사용해 어떤 세그먼트를 재생할지 정의
• 적응형 비트레이트 스트리밍(ABR)
• 네트워크 상태에 따라 자동으로 품질(해상도/비트레이트)을 조정해 버퍼링을 최소화

HLS 구성 요소

1. Master Playlist (m3u8)
2. 여러 해상도/비트레이트 버전을 링크한 상위 목록
3. Media Playlist (m3u8)
4. 특정 품질의 세그먼트 목록 (ex: segment1.ts, segment2.ts...)
5. Media Segments (.ts)
6. 실제 오디오/비디오 데이터가 들어 있는 짧은 MPEG-TS 파일들

작동 방식 요약

1. 클라이언트가 .m3u8 플레이리스트 요청
2. 플레이리스트에 있는 세그먼트(.ts) 파일들을 순차 다운로드
3. 다운로드한 세그먼트를 재생
4. 네트워크 상태 따라 다른 품질의 플레이리스트로 전환 가능

어디에 사용되나?

• YouTube, Twitch, Netflix 등 OTT 서비스
• 모바일/웹 브라우저 기반 스트리밍
• 라이브 방송 시스템 (뉴스, 스포츠 등)

장점

• 범용성: 브라우저와 모바일 기기에서 바로 재생 가능
• HTTP 사용: 별도 스트리밍 서버 필요 없음
• 적응형 스트리밍: 다양한 네트워크 환경에서 안정적 재생

M3U8

m3u8은 HLS(HTTP Live Streaming)에서 사용되는 플레이리스트 파일 형식으로, UTF-8 인코딩된 M3U 파일. 쉽게 말해, 재생할 미디어 파일(.ts 세그먼트 등)의 목록과 스트리밍 정보를 담고 있는 텍스트 파일

m3u8 파일이 하는 역할

• 스트리밍할 미디어 세그먼트(.ts) 들의 경로를 나열
• 각 세그먼트의 길이, 순서 정보를 포함
• 경우에 따라 해상도별 스트림 목록(Master Playlist) 역할도 함

m3u8의 두 종류

1. Master Playlist

   #EXTM3U
   #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
   low.m3u8
   #EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=1280x720
   mid.m3u8
   #EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1920x1080
   high.m3u8
   
   

   사용자의 네트워크 상황에 따라 적절한 화질의 Media Playlist를 선택
2. 여러 화질 버전의 Media Playlist를 포함한 상위 목록
3. Media Playlist

   #EXTM3U
   #EXT-X-TARGETDURATION:10
   #EXT-X-VERSION:3
   #EXTINF:9.0,
   segment1.ts
   #EXTINF:10.0,
   segment2.ts
   #EXTINF:8.5,
   segment3.ts
   #EXT-X-ENDLIST
   
   

   위 순서대로 .ts 파일을 다운로드하고 재생
4. 실제 비디오 세그먼트 목록을 나열

주요 태그 설명

m3u8 파일은 어떻게 쓰이나?

• 웹 플레이어에서 .m3u8 주소를 불러와 스트리밍 시작
• 라이브 방송은 .m3u8이 실시간으로 업데이트됨
• 동영상 다운로드 도구에서 .m3u8을 분석해 전체 영상 다운로드 가능

.HLS에서 .ts 파일이란?

HLS 스트리밍에서 .ts는 MPEG-TS (MPEG Transport Stream) 형식의 비디오 세그먼트 파일

• 비디오와 오디오 데이터를 포함한 실시간 전송용 포맷
• .ts = Transport Stream
• 스트리밍을 위해 짧게 나뉜 (예: 5~10초) 미디어 조각들

예시로 비교

파일 종류 확장자 의미

스트리밍에서 .ts 사용 예시

#EXTINF:10.0,
video1.ts
#EXTINF:10.0,
video2.ts
#EXTINF:10.0,
video3.ts

여기서 video1.ts, video2.ts 등은 비디오 데이터 조각들이고, 순서대로 스트리밍

보안설계에서 중요한 키워드 WAF, Zero Trust Network

1. WAF (Web Application Firewall)

정의

웹 애플리케이션 계층(L7)의 보안 방화벽

HTTP 요청/응답을 검사해서 악의적인 공격을 차단하는 역할

WAF가 막아주는 공격 유형:

공격 설명

WAF는 어디에 위치하냐면:

[클라이언트]
   ↓
[WAF] ← 모든 HTTP 요청 검사
   ↓
[웹 서버 / 프록시 서버]
   ↓
[WAS]

WAF 종류

구분 예시

2. Zero Trust Network (제로 트러스트 네트워크)

정의

"절대 아무도 신뢰하지 마라.

네트워크 내부든 외부든 모든 요청을 검증하고 최소한의 권한만 허용하라."

핵심 개념:

개념 의미

Zero Trust 흐름 예시:

[사용자 또는 디바이스 요청]
      ↓
[인증 시스템 (IDP, MFA 등)]
      ↓
[Zero Trust 게이트웨이 (ZTNA Proxy)]
      ↓
[애플리케이션]

구성 요소 예시:

요소 예시

WAF vs Zero Trust 비교

항목 WAF Zero Trust

한 줄 정리

용어 요약

목적

API Gateway의 목적은 클라이언트와 백엔드 서비스 간의 중간 계층 역할을 하면서 다양한 기능들을 수행하여 시스템의 효율성과 보안성을 높이는 것

특징

1. 단일 진입점 제공 (Single Entry Point)

• 클라이언트는 여러 백엔드 서비스를 직접 호출하지 않고, API Gateway 하나만 호출하면 됨.
• 마이크로서비스 아키텍처에서 특히 유용.

2. 요청 라우팅 (Request Routing)

• 들어오는 요청을 적절한 백엔드 서비스로 라우팅
• 예: /user → 사용자 서비스, /order → 주문 서비스

3. 보안 관리

• 인증(Authentication), 인가(Authorization)를 중앙에서 처리
• JWT 토큰 검사, API 키 체크 등

4. 로깅 및 모니터링

• 요청 로그를 수집하거나, 트래픽 분석 등 관측 기능을 제공
• 성능 모니터링, 트래픽 제어 등도 가능

5. 요청/응답 변환

• 요청 또는 응답의 포맷을 변환 (예: XML ↔ JSON)
• 백엔드는 단순하게 유지하고, 클라이언트 맞춤 응답 제공 가능

6. 로드 밸런싱 및 장애 처리

• 여러 백엔드 인스턴스 사이에서 트래픽 분산
• 장애 발생 시 다른 인스턴스로 우회

7. 속도 제한 및 트래픽 제어 (Rate Limiting)

• 남용 방지를 위해 호출 빈도 제한
• 과도한 요청에 대한 보호

8. 캐싱

• 빈번한 요청 결과를 캐싱하여 응답 속도 개선 및 서버 부하 감소.

API Gateway는 다음과 같은 역할을 하며 시스템을 더 안전하고, 효율적이며, 확장 가능하게 도움을 준다.

API Gateway의 부하 분산

1. API Gateway가 부하 병목이 될 수 있는 이유

• 모든 요청을 한 곳(API Gateway)으로 집결시키므로, 트래픽 집중이 발생.
• 트래픽이 급증하면, API Gateway가 요청을 처리하는 데 시간이 오래 걸릴 수 있음.

2. 부하를 분산시키는 방법

2.1 수평 확장(Scaling Out)

• API Gateway 서버를 여러 대 운영하고, 그 앞단에 로드 밸런서(Load Balancer) 를 두어 부하를 분산
• 예: Nginx, AWS ALB, Google Cloud Load Balancing 등

2.2 캐싱(Caching) 활용

• 자주 요청되는 결과를 캐싱하면, Gateway가 각 요청마다 백엔드까지 직접 호출할 필요가 없어짐
• 응답 속도 향상 및 서버 부하 감소

2.3 비동기 처리(Async)와 메시지 큐(Message Queue)

• 어떤 요청은 즉시 처리가 필요하지 않을 수 있습니다(예: 이메일 전송, 비동기 트랜잭션 등)
• 메시지 큐(Kafka, RabbitMQ 등)를 통해 처리할 수 있도록 하여 Gateway가 동기 처리 부담을 완화

2.4 서버리스(Serverless) 사용

• AWS API Gateway + Lambda 조합 등으로 필요한 시점에만 자동 확장이 가능하도록 설계
• 초당 수백만 건의 요청도 일정 수준까지는 감당하도록 구성 가능

2.5 API Gateway 경량화

• Gateway 레이어에 지나치게 많은 기능(인증/인가, 변환, 로깅 등)을 몰아넣으면 부하가 커지기에 잘 고려해야함
• 꼭 필요한 기능만 Gateway에서 처리하고, 나머지는 별도 마이크로서비스 혹은 다른 계층에서 담당하게 하여 Gateway의 역할을 경량화

3. 단일 장애 지점을 피하는 고가용성(HA) 구성

• API Gateway가 멈추면 모든 서비스가 사실상 중단될 가능성이 있음
• 따라서, 멀티 AZ(가용 영역), 멀티 리전 또는 다중 Gateway 인스턴스 구성을 통해 장애 발생 시에도 서비스 중단이 최소화되도록 하는 구성이 필요

4. 결론

• API Gateway가 모든 트래픽의 단일 진입점으로 동작하므로, 제대로 설계하고 확장 전략을 마련하지 않으면 병목 및 장애 지점이 될 수 있다.
• 하지만 수평 확장, 캐싱, 비동기 처리, 고가용성 구성 등을 통해 충분히 분산 설계가 가능함
• 즉, 잘못 설계하면 병목이 되지만, 올바른 인프라/아키텍처 구성과 모니터링을 통해 API Gateway의 이점(중앙 집중 관리, 보안, 모니터링 등)을 극대화하면서도 부하 문제 완화가능

워터마크(Watermark)란?

워터마크(Watermark)는 디지털 콘텐츠(이미지, 영상, 오디오, 문서 등)에 저작권 보호, 출처 표기, 위변조 방지 등의 목적으로 삽입되는 표식이다. 워터마크는 가시적(Visible)과 비가시적(Invisible) 방식으로 나뉜다.

1. 가시적 워터마크 (Visible Watermark)

• 정의

이미지, 영상, 문서 등에 눈에 보이는 형태로 삽입된 워터마크를 의미한다.

• 특징
  • 사람이 직접 볼 수 있음 (예: 로고, 텍스트, 투명한 마크)
  • 저작권 보호 및 출처 표시 목적
  • 복제 방지를 위한 억제 효과
  • 그러나 이미지 편집 기술(포토샵 등)로 제거 가능
• 예시
  • 사진에 삽입된 "© 2025 PhotographerName" 표시
  • 영상의 한쪽 구석에 있는 방송국 로고 (예: "KBS", "MBC")
  • PDF 문서의 배경에 투명하게 삽입된 회사명

2. 비가시적 워터마크 (Invisible Watermark)

• 정의

사람의 눈에는 보이지 않지만, 디지털 신호(이미지, 영상, 오디오, 문서)에 숨겨진 형태로 삽입된 워터마크를 의미한다.

• 특징
  • 사람이 직접 볼 수 없음 (특정 소프트웨어나 알고리즘을 통해 확인 가능)
  • 저작권 보호 및 원본 출처 확인
  • 변형, 편집 후에도 검출 가능 (강인성에 따라 다름)
  • 이미지, 오디오, 영상에 널리 사용됨
• 기술적 기법
  • 공간 영역 기법: 픽셀값에 미세한 변화 삽입
  • 주파수 영역 기법: 푸리에 변환(DFT), 웨이브렛 변환(DWT) 등을 활용해 삽입
  • 양자화 지수 변조(QIM): 특정 패턴을 신호에 삽입하여 탐지
• 예시
  • 사진 속 특정 픽셀에 디지털 서명 숨기기
  • 영화나 음악 파일에 저작권 정보 삽입
  • 문서에 특정한 패턴을 추가해 출처 확인

3. 가시적 vs 비가시적 워터마크 비교

결론

• 가시적 워터마크는 저작권 보호를 강조하고 쉽게 알아볼 수 있는 장점이 있지만 제거될 가능성이 있다.
• 비가시적 워터마크는 콘텐츠의 무결성을 유지하면서도 추적이 가능하지만, 분석 도구가 필요하다.
• 두 가지 방법을 함께 사용하면 보안성과 저작권 보호 효과를 극대화할 수 있다.

아키텍처 간략 정리

1. MVC (Model-View-Controller)

구성 요소

• Model: 데이터와 비즈니스 로직을 관리합니다.
• View: 사용자에게 정보를 시각적으로 표시합니다.
• Controller: 사용자 요청을 처리하고 Model과 View를 연결합니다.

특징

• 역할이 분리되어 코드의 가독성과 재사용성이 높습니다.
• 사용자가 View와 상호작용하면 Controller가 이를 처리하고 Model을 업데이트한 후, View에 결과를 표시합니다.

활용

• 웹 애플리케이션(스프링 MVC, Ruby on Rails 등)
• 데스크톱 애플리케이션

2. MVVM (Model-View-ViewModel)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: UI 요소.
• ViewModel: View와 Model 사이의 중간 계층으로, View의 상태를 관리하고, 데이터 바인딩을 지원합니다.

특징

• 양방향 데이터 바인딩을 통해 View와 ViewModel의 동기화를 자동으로 처리합니다.
• View는 데이터에 대한 의존성을 최소화합니다.

활용

• WPF(Windows Presentation Foundation)
• Angular, Vue.js, React + Redux/MobX와 같은 SPA(Single Page Application) 프레임워크

3. MVP (Model-View-Presenter)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: 사용자 인터페이스(UI).
• Presenter: View의 로직을 담당하며 Model과 상호작용한 후 데이터를 View에 전달합니다.

특징

• View는 단순히 UI를 표시하는 역할만 하고, 모든 로직은 Presenter에서 처리됩니다.
• View와 Presenter는 1:1 관계를 갖습니다.

활용

• 안드로이드 애플리케이션
• 레거시 데스크톱 애플리케이션

4. Clean Architecture

구성 요소

• Entities: 애플리케이션의 비즈니스 규칙을 캡슐화.
• Use Cases: 애플리케이션의 특정 작업이나 기능을 정의.
• Interface Adapters: 데이터와 UI의 변환 계층.
• Frameworks & Drivers: 데이터베이스, UI, 외부 API 등.

특징

• 의존성 규칙: 안쪽 계층은 바깥쪽 계층을 알지 못합니다.
• 비즈니스 로직이 프레임워크와 독립적이어서 확장성과 유지보수가 용이합니다.

활용

• 대규모 시스템
• 멀티 플랫폼 애플리케이션

5. Layered Architecture (계층형 아키텍처)

구성 요소

• Presentation Layer: 사용자 인터페이스.
• Application Layer: 비즈니스 로직.
• Data Layer: 데이터베이스 및 데이터 액세스.

특징

• 계층 간 명확한 분리가 이루어집니다.
• 단순하고 이해하기 쉬운 구조지만, 복잡한 시스템에서 성능 저하가 있을 수 있습니다.

활용

• 전통적인 웹 애플리케이션(3-tier 아키텍처)
• 엔터프라이즈 애플리케이션

6. Microservices Architecture

구성 요소

• 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 나눕니다.
• 각 서비스는 고유한 비즈니스 기능을 담당하며 API로 통신합니다.

특징

• 독립적인 배포와 확장이 가능합니다.
• 서비스 간 통신 오버헤드가 있고, 분산 시스템의 복잡성이 증가할 수 있습니다.

활용

• 대규모 분산 시스템
• 클라우드 네이티브 애플리케이션

7. Event-Driven Architecture

구성 요소

• Event Producer: 이벤트를 생성하고 발행.
• Event Consumer: 이벤트를 처리.
• Event Broker: 이벤트를 전달하거나 중개.

특징

• 비동기 통신을 기반으로 설계되어 높은 확장성을 제공합니다.
• 복잡한 이벤트 흐름을 관리하기 위한 설계가 필요합니다.

활용

• IoT 시스템
• 실시간 애플리케이션(채팅, 트랜잭션 시스템)

8. Hexagonal Architecture (Ports and Adapters)

구성 요소

• Core (Application Logic): 애플리케이션의 핵심 비즈니스 로직.
• Ports: 외부와의 상호작용을 정의하는 인터페이스.
• Adapters: 특정 구현을 제공하여 Core와 통신.

특징

• 비즈니스 로직과 외부 시스템 간의 의존성을 최소화합니다.
• 높은 테스트 가능성과 확장성을 제공합니다.

활용

• 복잡한 도메인 로직이 있는 시스템
• 시스템 간 통합이 필요한 애플리케이션

9. Serverless Architecture

구성 요소

• 클라우드 기반 서비스와 함수(Function-as-a-Service)를 이용하여 애플리케이션을 실행.
• 서버를 관리하지 않고도 클라우드 제공자가 모든 인프라를 처리.

특징

• 확장성과 비용 효율성이 높습니다.
• 서버 환경에 대한 제어가 제한적입니다.

활용

• 이벤트 중심 애플리케이션
• 간단한 API 백엔드

10. CQRS (Command Query Responsibility Segregation)

구성 요소

• Command: 데이터 변경 작업(쓰기).
• Query: 데이터 읽기 작업.

특징

• 읽기와 쓰기를 분리하여 각 작업을 최적화합니다.
• 복잡한 시스템에서 동시성과 확장성을 지원합니다.

활용

• 이벤트 소싱 시스템
• 고성능 읽기/쓰기 작업이 필요한 시스템

11. Pipe and Filter Architecture

구성 요소

• Filters: 데이터를 처리하는 독립적인 컴포넌트.
• Pipes: 필터 간 데이터를 전달.

특징

• 데이터 흐름을 직관적으로 표현할 수 있습니다.
• 처리 단계가 많아지면 성능 저하가 발생할 수 있습니다.

활용

• 데이터 처리 파이프라인
• 이미지 또는 오디오 프로세싱

12. Service-Oriented Architecture (SOA)

구성 요소

• 독립적인 서비스들로 구성되며, 각 서비스는 특정 비즈니스 기능을 제공합니다.
• 서비스는 표준 프로토콜(예: SOAP, REST)을 통해 통신합니다.

특징

• 서비스 간 의존성이 낮아 확장성과 재사용성이 높습니다.
• 복잡한 통합과 관리가 필요합니다.

활용

• 엔터프라이즈 애플리케이션
• 분산 시스템

CSR에서 자바 스프링 백엔드 아키텍처

1. 계층형 아키텍처 사용 (Layered Architecture)
2. RESTful API 서버로 프론트엔드와 데이터 통신
3. JPA + Hibernate를 통한 데이터베이스 연동
4. JWT를 통한 보안 및 인증 처리
5. 마이크로서비스 및 API Gateway 적용 가능 (Spring Cloud Gateway)
6. 비즈니스 로직, 예외 처리, 로깅, 모니터링 구성

➡️ CSR 환경에서는 프론트엔드가 주로 UI를 렌더링하고, 자바 스프링 백엔드는 데이터 제공, 비즈니스 로직 처리, 보안, 데이터베이스 연동을 주로 담당합니다.

아키텍처 패턴 선택 가이드

1. 프로젝트 규모:
   • 작은 프로젝트: MVC, MVP
   • 대규모 프로젝트: Microservices, Clean Architecture
2. 프론트엔드 및 백엔드 협업:
   • 단일 애플리케이션: MVVM, MVC
   • 분리된 환경: RESTful API 기반 MC
3. 확장성 요구:
   • 높은 확장성: Microservices, Serverless
4. 실시간 처리:
   • 실시간 데이터: Event-Driven, CQRS

언어별 연산 속도

단순 연산 기준으로 나눠본 언어별 연산 속도 + 특징

Python

• 인터프리터 언어
• 연산 속도 : 1초에 1억
• C 기반의 확장 라이브러리(ex:Numpy)를 활용해 연산이 빠를 수 있음
• PyPy (JIT 컴파일러) 약 2~10배 빠름

JavaScript

• 인터프리터 언어
• 연산 속도 : 1초에 1억 ~ 5억
• JIT 컴파일러를 통해 연산속도 보완

Java

• 컴파일 언어
• 연산 속도 : 1초에 5억 ~ 10억
• Java는 JVM 위에서 실행되며, JIT컴파일링, 런타임 최적화 등이 있음, 기본 연산속도로 따졌을 때 Python보다 약 1020배, JavaScript보다 약 25배 빠름

C / C++

• 컴파일 언어
• 연산 속도 : 1초에 10억 ~ 50억
  • C와 C++은 컴파일 언어로, 코드가 기계어로 직접 변환되기에 가장 빠른 속도
• 하드웨어와 매우 가까운 수준에서 작업 가능

C#

• 연산 속도 : 1초에 5억 ~ 10억
• C#은 Java와 유사한 속도, .NET의 JIT 컴파일러와 런타임 최적화가 되어있음

PHP

• 인터프리터 언어
• 1초에 약 1억 ~ 2억
• C 기반으로 구현된 함수와 라이브러리를 호출

데이터 베이스 구현 언어

현재 주력 데이터베이스들인 MySQL, PostgreSQL, Oracle등 대부분의 데이터베이스는 C 또는 C++로 구현되어 있어 기계어에 가까운 최적화된 실행 성능을 갖고 있다.

정리

기본 연산속도가 가장 빠른 언어는 C, 그 외의 언어는 연산속도를 보장하기 위해 JIT 컴파일러, c언어 기반의 최적화된 라이브러리 등을 지원하여, 연산속도를 보완한다.

추가로 개발자들이 사용하는 것들(ex: MySQL, PHP, 파이썬 라이브러리)이 C 기반으로 만들어지는 이유를 추측하자면, 연산속도를 포함하여 low한 레벨에서 하드웨어에 가깝게 빠른 동작을 실행하려면 메모리, Disk I/O등 C언어 방식으로 직접 관리하는 것이 가장 최적화에 도움을 주는 방식이기 때문이 아닐까 생각된다.

Context Switching(문맥 교환)

병렬처리에 관해 이야기할 때 항상 등장하는 단어인 Context Switching에 대해 공부 해보았다. 해당 단어를 꺼내기 위해서는 기본적으로 알아둬야 할 사전지식이 필요하다. 해당 사전지식도 가볍게 다루며 콘텍스트 스위칭에 대하여 작성해보자.

프로세스

프로세스는 컴퓨터에서 프로그램이 실행될 때 사용되는 실행 단위로, 실행 중인 프로그램의 인스턴스다. 메모리와 CPU 자원을 할당받아 동작하는 상태를 의미하며, 우리가 코드를 통해 만든 하나의 애플리케이션이 실행될 때 생성된다.

멀티 프로세스, 멀티 스레드

• 멀티 프로세스는 여러 개의 독립된 프로세스를 생성하여 각각의 메모리 공간을 가지고 병렬로 동작
• 멀티 스레드는 하나의 프로세스 내에서 여러 스레드가 메모리 자원을 공유하며 동작

CPU의 동작

CPU는 하나의 프로세스만을 담당하는 것이 아니라, 컴퓨터에서 실행된 모든 프로그램의 동작을 담당해야 한다.

CPU는 여러 프로그램을 동시에 처리하는 것처럼 보이지만, 사실은 매우 짧은 시간 간격으로 각 프로세스의 작업을 번갈아가며 처리하고 있다. 이 때 각 프로세스는 자신이 중단된 지점의 상태, 즉 레지스터, 스택 포인터, 프로그램 카운터 등의 정보를 저장하고, 다른 프로세스의 상태를 불러와 실행을 이어간다. 이 정보를 Context(문맥) 라고 한다.

Context Switching(문맥 교환)

문맥 교환(Context Switching)은 여러 프로세스나 스레드가 CPU를 사용할 수 있도록 문맥을 저장하고 불러오는 작업을 의미한다. 이 과정에서 실행 중인 프로세스의 상태를 저장하고 다른 프로세스의 상태를 복원하는 작업이 필요하므로 일정한 오버헤드(비용) 가 발생한다. 따라서 병렬 처리를 통해 성능을 개선하려면, 문맥 교환의 빈도와 그로 인한 오버헤드가 전체 성능에 미치는 영향을 신중하게 고려해야 한다.

해시 - 솔트치기

이번 카카오페이 사건을 통해 대충만 알고있던 솔트에 대해 정리하는 시간을 가져봤다.

암호화를 했는데 왜 문제인가?

보도자료(상세) | 보도자료 | 보도·알림 |

카카오페이에서 외부 api(알리페이)와 통신할 때 사용자의 개인정보 값에 대한 암호화 처리를 제대로 하지 않았다.

보도자료의 랜덤값 없이 단순하게 해시처리(암호화) 라는 말은 암호화 작업을 하긴 했지만 암호화 작업의 기본인 랜덤값(솔트)을 넣지 않았다고 하는 것인데, 이 작업을 진행하지 않고 단순 해시처리를 한다면 레인보우 테이블 공격에 취약하다.

이번 주제에서 설명하는 해시(암호화)는 단방향 암호화인 MD5, SHA256 등의 암호화 즉 디코딩 할 수 없는 값을 기준으로 설명 할 것이다.

암호화 테스트 링크 : https://emn178.github.io/online-tools/sha256.html

해시

우리가 hello 를 회원가입 할 때 입력받아 암호화 하여 데이터베이스에 저장한다고 가정해보자.

회원가입 할 때 받은 비밀번호를 단순 해시화 하여 값을 저장했을 때

SHA256(hello) → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 의 값으로 단방향 해시되어 데이터베이스에는 암호화 된 값을 저장할 것이다. 그래야 데이터베이스를 탈취당해도 유저의 실제 암호는 알 수 없기 때문인데

사실은 값을 찾아낼 수 있다.

레인보우 테이블

복호화를 하지 못하는데 값을 어떻게 찾을 수 있는지 의문이 들지만 해시된 값이 그저 단순 문자열로 이루어진 고정 값이라면 레인보우테이블 기법을 통해 해시된 값을 알아낼 수 있다.

레인보우 테이블이란 기존 문자들을 미리 암호화 처리하여 사전처럼 해시값 기준으로 원래의 문자열을 알아낼 수 있는 형태의 테이블이다.

레인보우 테이블이란 암호화된 해시값을 키로 두고, 키에 대한 원조 값을 찾아낼 수 있는 값을 value로 두는 사전이라고 볼 수 있는데 예시 테이블을 참고해서 보자면

만약 이러한 테이블을 저장한 레인보우 테이블이 있을 때 해커는 hello의 값을 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 해시 검색을 통해 알아낼 수 있을 것이다.

코드 예시

import java.util.*;

public class main
{
    public static void main(String[] args)
    {

                // 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824의 값이 저장됨
        String passwordSave = sha256("hello");

        //만들어져 있는 레인보우 테이블이라고 가정
        Map<String, String> rainbowTable = new HashMap<>();
        rainbowTable.put(sha256("hello"), "hello");

        //얻은 해시값
        System.out.println(rainbowTable.get("2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"));
    }

    public static String sha256(String needEncodingString){
            //해싱처리
        //hello -> sha256 -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
        return "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824";
    }
}

---------
출력 값 : hello

솔트 치기

솔트를 치는 이유는 보안 강화이며, 단순한 해시화는 앞에서 보았던 것 처럼 쉽게 예측이 가능한 것을 보았다.
해시작업을 할 때 기존의 문자열만으로 해시하는 것이 아니라 기존 문자열과 함께 서버에서만 알 수 있는 문자열을 부여해서 두 문자를 합친 해시값을 만드는 것이다.
예를 들면 sha256(hello + "qwerafaad" ) 와 같이 암호와 관련이 없는 문자열을 해시하기 전 추가해서 전혀 다른 해시값을 만드는 것이다. 이 때 암호와 관련이 없는 문자열을 솔트(소금)이라고 부른다.

또 솔트를 칠 때 주의해야 할 점이 있는데 이에 대해 알아보자

솔트값

소금 값은 짧지 않은 값으로 생성되어야 한다.
평범한 비밀번호로 구성되어있는 룩업 테이블(레인보우 테이블) 등의 경우 837G 만으로 전체 룩업 테이블을 구성할 수 있다. 이 837GB에서 “asd” 라는 문자가 추가되는 테이블을 만들었다고 했을 때 해커 입장에서는 부담스럽지 않은 값으로 해당 테이블의 조합을 만들어 낼 수 있을 것이다.

때문에 소금 값은 보통 해시 알고리즘을 사용해서 완성되는 해시길이로 생성한다.
ex ) SHA256 알고리즘은 32바이트 이기에 소금 값도 랜덤한 32바이트

유저별로 랜덤한 문자열을 생성

랜덤한 문자열을 만들어놓고 그 값을 그대로 재사용 해서는 안된다. 소금 값의 의미가 없어지는데, 예를 들어 하나의 유저의 비밀번호가 뚫렸다고 생각해보자

• “hello”(비밀번호) + “adad”(소금)

해커는 hello라는 비밀번호에 대해 adad의 소금 값을 알아냈다.

• 모든 유저의 비밀번호를 하나의 소금값으로 사용
• 비밀번호가 유출된 유저가 비밀번호 재설정을 했을 때

위의 두가지 상황에서 해커는 소금값을 알기 때문에 쉽게 찾아낼 수 있을 것이다.
위와 같은 이유로 소금을 칠 때는 반드시 두가지 규칙(짧지 않은 소금 값, 재사용 금지)을 따라야 한다.

정리하면 다음과 같다.

• 소금값(Salt) 생성
  • 사용자 계정을 생성하거나 비밀번호를 변경할 때, 새로운 임의의 랜덤 소금값을 생성합니다. 이 소금값은 절대 재사용하지 않으며, 충분히 길고 다양한 값을 가지도록 해야 한다. 일반적으로 소금값의 길이는 해시 함수의 출력 길이와 동일하게 해야한다.
• 비밀번호 해싱
  • 사용자가 입력한 비밀번호에 생성된 소금값을 추가(일반적으로 결합)한 후, 그 결합된 값을 해시 함수에 전달하여 해시된 비밀번호를 생성한다.
• 저장
  • 생성된 소금값과 해시된 비밀번호를 사용자 계정 테이블에 저장합니다. 이때 소금값은 별도로 저장되며, 해시된 비밀번호와 함께 보관.

참조

https://starplatina.tistory.com/entry/비밀번호-해시에-소금치기-바르게-쓰기

레인보우 테이블 : https://en.wikipedia.org/wiki/Rainbow_table

CGI(Common Gateway Interface)

서버 사이드에서 사용자의 프로그램을 동작하도록 하기 위한 프로토콜

CGI는 웹 서버에서 동적인 클라이언트의 요구에 응답하기 위해 만들어졌다.

CGI의 역할 및 흐름

• 보통의 경우 클라이언트가 HTTP요청을 했을 때 웹 서버에서는 요청이 백엔드 서버까지 들어가서 프로그램을 실행해야 하는지, 정적인 콘텐츠(html, css, js, image 등)만을 Response할지를 정함
• 로직 처리 프로그램에 넘겨야 한다면 서버에서 CGI프로토콜로 HTTP요청을 변환하여 백엔드 서버로 넘김
• 백엔드 서버에서 요청을 처리 후 CGI프로토콜로 서버에 Response 반환
• 상당히 많은 언어가 이러한 프로토콜(FastCGI API)을 지원 ( 파이썬, PHP, JAVA, Node.js 등 )

FastCGI

기존 CGI의 변형된 버전으로 주요 목적은 웹 서버와 CGI 프로그램 간 통신 시 발생되는 부하를 줄이며, 더 많은 요청을 관리할 수 있게 하는 것이다.

FastCGI 특징

• 여러 웹 서버들이 FastCGI를 구현하며, 다양한 언어로 만들어진 프로그램을 api호출할 수 있다
• Nginx같은 웹 서버들은 이 FastCGI통신을 하기 위해 게이트웨이 역할(프로토콜 변환)을 포함한다.

WebServer와의 상관관계

아래의 자료와 함께 Nginx Web Server를 예시로 설명을 하자면

1. 클라이언트가 웹 서버에 보내는 HTTP 또는 HTTPS 요청
2. Nginx에서 HTTPS요청이였다면 HTTP로 변환 후 FastCGI프로토콜로 다시 담아 FastCGI API를 지원하는 언어에 요청
3. 애플리케이션 프로그램은 요청된 로직을 처리 후 FastCGI 프로토콜로 Nginx측에 반환
4. Nginx는 응답받은 FastCGI 데이터를 HTTPS였다면 HTTPS로, HTTP였다면 HTTP로 반환
5. 통신 종료

정리

• 위에서 Nginx는 WS의 정적 페이지 반환, 게이트웨이 역할, FastCGI API와 연계하며 WAS의 역할을 모두 수행
• CGI, FastCGI는 웹 서버에서 사용 언어의 제약없이 통신에 활용할 수 있는 프로토콜
• 현 시점에서는 CGI가 아닌 FastCGI로 동적 데이터 처리를 주로 하고있음

출처 : https://ko.wikipedia.org/wiki/FastCGI

WebServer

웹 서버의 주요 기능

• 정적 콘텐츠 제공
  • HTML, CSS, JavaScript, 이미지파일 등과 같은 정적 파일을 클라이언트에게 제공하는 역할
  • 클라이언트가 URL을 통해 요청한 파일을 디스크에서 찾아 클라이언트에게 반환
• HTTP 요청 처리
  • 웹 서버는 클라이언트로부터 HTTP 요청을 받고 이에 대한 HTTP 응답을 반환
  • GET, POST, PUT, DELETE등 HTTP메서드를 처리
• 로드 밸런싱
  • 웹 서버는 여러 대의 서버에 요청을 분산시켜 처리 성능을 향상시키고 서버 과부하를 방지
• SSL/TLS 암호화
  • 웹 서버는 HTTPS를 통해 클라이언트와의 통신을 암호화하여 데이터의 기밀성과 무결성을 보호

Apach (1995)

• 기본적으로는 요청을 받기위한 프로세스가 생성되어있고, 프로세스를 미리 만들어두는 Prefork 방식을 사용.
• 새로운 요청이 들어올 때 미리 만들어 둔 프로세스를 가져다 사용하는 방식
• 만들어진 프로세스를 모두 사용하고 있다면 추가 프로세스를 만들어 할당
• 첫 도입 때부터 이용자가 상당히 많았지만 절대적인 컴퓨터를 사용하는 유저가 적어 프로세스 생성 형식이 문제가 없었지만, 컴퓨터의 보급이 많이 이뤄진 후에는 그만큼 많은 요청이 들어왔고 결국 C10K (Connection 10,000) 의 문제가 발생
• 많은 프로세스로 메모리 부족현상 발생

Nginx

• 트래픽이 많은 웹사이트의 WAS를 돕는 비동기 이벤트 기반 경량화 웹 서버
• WS의 역할만을 위해 활용되기도 하고, Reverse Proxy Server로 활용해 WAS의 부하를 줄일 수 있는 로드밸런서 역할도 가능
  • Reverse Proxy Server : 클라이언트가 리버스 프록시 서버에 요청하면 프록시 서버가 배후 서버(실제 응답서버)에서 데이터를 가져오는 형태
• C10K 문제 해결의 핵심은 비동기 이벤트 기반구조
• Nginx의 구조
  • 멀티 프로세스(master process)
    • master process는 서버의 설정, worker process를 관리하며 워커 프로세스의 생성, 관리 작업을 수행
  • 싱글 스레드(worker process)
    • 생성된 worker process에서는 각각 독립적으로 이벤트 루프 동작이 실행하며 루프의 큰 틀은 아래와 같음
      • 이벤트 감시
      • 이벤트 큐에 추가 : 이벤트 발생 시 이벤트 큐에 추가
      • 이벤트 처리 : 이벤트 큐에서 이벤트를 꺼내 non-blocking 비동기적으로 여러 요청을 수행
      • 반복

Nginx는 여러 프로세스를 사용하기 때문에 수 천개의 동시 연결을 처리할 수 있다.