응용
https://teamsparta.notion.site/c5b46b4b4eaa42f1ac25dc93c4d37b82
네트워크
https://teamsparta.notion.site/Wrap-Up-39dbbfb4fcf54e9fa89c17039427afef
https://teamsparta.notion.site/c5b46b4b4eaa42f1ac25dc93c4d37b82
응용계층
스테이트리스 프로토콜
HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜입니다.
이는 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미입니다.
자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없게 됩니다.
HTTP의 스테이트리스(stateless) 특성은 효율성과 확장성을 위한 핵심 요소로 작용하며, 여러 가지 장점을 제공합니다. 이를 정리하면 다음과 같습니다:
1. 서버 부담 감소
서버가 클라이언트 상태 정보를 유지하지 않으므로, 서버의 메모리나 리소스를 효율적으로 사용할 수 있습니다.
동시 접속 클라이언트가 많아질수록 상태 정보를 유지하는 비용이 증가하므로, 스테이트리스는 서버의 확장성을 높이는 데 기여합니다.
2. 단순한 설계
요청이 독립적으로 처리되므로 서버 구현이 단순해집니다.
서버는 클라이언트의 상태를 추적할 필요가 없어, 복잡한 상태 관리 로직이 제거됩니다.
3. 확장성 향상
상태 정보를 공유하지 않으므로 여러 서버를 이용한 로드 밸런싱이 쉬워집니다.
클라이언트는 특정 서버에 종속되지 않아, 서버 간 분산 처리나 장애 복구가 용이합니다.
4. 클라이언트 독립성
클라이언트가 각 요청마다 필요한 정보를 포함하여 보내므로, 서버 간 상태 정보 동기화가 필요 없습니다.
특정 서버에 문제가 생기더라도 다른 서버에서 요청을 처리할 수 있습니다.
5. 오류 허용성
요청이 독립적으로 처리되기 때문에 동일한 요청이 여러 번 전송되더라도 서버는 이를 별개 요청으로 간주합니다. 따라서 일관된 응답을 제공할 수 있습니다.
6. 다양한 애플리케이션 활용
REST API와 같은 현대 웹 애플리케이션 디자인 패턴은 HTTP의 스테이트리스 특성을 활용하여 확장성과 효율성을 극대화합니다.
HTTP의 스테이트리스 특성은 웹 서비스의 안정성, 확장성, 효율성을 보장하는 데 중요한 역할을 하며, 특히 대규모 시스템에서 필수적인 설계 요소로 자리 잡고 있습니다.
클라이언트의 요청이 선행 되어야만 서버가 응답을 하는 구조. (통념상. 안그런 경우도 있음)
HTTP의 구성요소
HTTP 메서드
GET : 자원을 습득하기 위한 메서드
HEAD : GET과 동일하나 헤더만을 응답받는 메서드
POST : 서버로 하여금 특정 작업을 처리하게끔 하는 메서드
PUT : 자원을 대체하기 위한 메서드
PATCH : 자원에 대한 부분적 수정을 위한 메서드
DELETE : 자원을 삭제하기 위한 메서드
CONNECT : 자원에 대한 양방향 연결을 시작하는 메서드
OPTIONS : 사용 가능한 메서드 등 통신 옵션을 확인하는 메서드
TRACE : 자원에 대한 루프백 테스트를 수행하는 메서드
상태 코드
| 200대 (성공) | |
| 200 | HTTP 요청이 성공적으로 수행됨 |
| 201 | (Created) 요청한 리소스 생성이 성공적으로 수행됨 (보통 POST 요청에 사용) |
| 300대 (리다이렉션) | |
| 301 | 요청한 리소스의 경로가 변경되었음을 의미 (예: bit.ly/axlxlxlx) |
| 304 | 클라이언트에게 응답이 수정되지 않았음을 의미 (캐시 사용 시 주로 사용) |
| 400대 (클라이언트 오류) | |
| 400 | 클라이언트가 약속과 다른 형식으로 서버에 요청 |
| 401 | 인증되지 않은 사용자의 접근 시도 |
| 403 | 인가되지 않아 리소스에 접근할 수 없음 |
| 404 | 요청한 리소스를 찾을 수 없음 |
| 500대 (서버 오류) | |
| 500 | 서버에서 처리 방법을 알 수 없는 오류가 발생 |
| 502 | 프로토콜 문제나 게이트웨이와 오리진 서버 간 문제 발생 |
| 503 | 서버가 요청을 처리할 수 없는 상태 (예: 과부하 또는 유지보수 중) |
| 504 | 서버 게이트웨이에서 응답을 받지 못하는 경우 |
https://teamsparta.notion.site/Wrap-Up-39dbbfb4fcf54e9fa89c17039427afef
네트워크 Wrap-Up
전송 계층과 응용 계층의 지식들은 게임 개발을 하며 종종 마주할 것들이기에 조금 더 시간을 내어 공부하면 좋을 것 같아요.
서버가 터지는 것을 막기
안정성은 특정 기능을 언제든 균일한 성능으로 수행할 수 있는 특성으로 정의할 수 있습니다.
가용성이란 컴퓨터 시스템이 특정 기능을 실제로 수행할 수 있는 시간의 비율을 의미
가용성은 전체 사용 시간 중에서 정상적인 사용 시간을 의미합니다.
정상적인 사용 시간을 업타임, 정상적인 사용이 불가능한 시간을 다운 타임이라고 하며,
[가용성 = 업타임/업타임 + 다운타임] 이라고 할 수 있습니다.
(재대로 돌아가는 시간 / 전체 시간)
이중화
가용성을 높이기 위해서는 SPOF를 이중화하는 것이 좋습니다.
이중화란 말 그대로 무언가를 이중으로 두는 기술입니다.
이중화할 수 있는 대상 : 서버 컴퓨터, 네트워크 인터페이스, 스위치와 같은 물리적 장비 뿐만 아니라 데이터베이스, 서버 프로그램 등도 이중화의 대상입니다.
이중화 할 수 있는 대상은 대부분 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상이라는 공통점이 있습니다.
단일 장애점(Single Point Of Failure, 이하 SPOF) SPOF는 문제가 발생할 경우 시스템 전체가 중단될 수 있는 대상을 뜻함. 최대한 없애는 것이 좋습니다.
액티브/스탠바이로 구성하면 액티브 상태인 시스템에 문제가 발생할 경우 스탠바이 시스템이 자동으로 액티브 시스템을 대신하여 동작합니다.
액티브 시스템에 문제가 생겼을 경우 예비된 스탠바이 시스템으로 자동 전환되는 기능을 페일오버(failover)라고 합니다.
액티브/액티브는 두 시스템 모두를 가동 상태로 두는 이중화 구성 방식
부하를 분산시킬 수 있고, 두 시스템이 함께 가동되므로 성능상의 이점도 있습니다.
다만 한 시스템에 문제가 발생하면 순간적으로 다른 시스템에 부하가 급증할 수 있으며, 이로 인해 추가적인 문제가 발생할 수 있습니다.
이중화 기술은 더욱 확장될 수 있습니다. 이중화를 무언가를 이중으로 두는 기술이라고 설명했는데요.
다중화는 무언가를 여러 개 두는 기술을 의미합니다. 이중화를 넘어 다중화가 된다면 더욱 안정적인 운영이 가능합니다.
하지만 운영 상 부담도 커지니 트레이드 오프를 고려하여 선택해야 합니다.
로드 밸런싱
트래픽 분배
트래픽의 사전적 정의는 주어진 시점에 네트워크를 경유한 데이터의 양입니다만,
일반적으로 트래픽 측정은 노드에서 이루어지므로 주어진 시점에 특정 노드를 경유한 패킷의 양을 트래픽이라고 볼 수 있습니다.
과도한 트래픽은 서버의 가용성을 떨어뜨립니다. 이는 서버를 다중화해도 마찬가지입니다.
특정 서버에만 트래픽이 몰릴 경우 가용성이 떨어질 수 있습니다.
트래픽의 고른 분배를 위해 사용되는 기술이 로드(부하) 밸런싱(균형)입니다.
로드 밸런서는 L4 스위치, L7 스위치라 불리는 네트워크 장비로도 수행할 수 있지만,
로드 밸런싱 기능을 제공하는 소프트웨어를 설치하면 일반 호스트도 로드 밸런서로 사용할 수 있습니다.
로드 밸런서는 일반적으로 이중화나 다중화된 서버와 클라이언트 사이에 위치합니다.
클라이언트들은 로드 밸런서에 요청을 보내고, 로드 밸런서는 해당 요청을 각 서버에 균등하게 분배합니다.
이미지----
상태체크
다중화된 서버 환경에서는 현재 문제가 있는 서버는 없는지, 현재 요청에 대해 올바른 응답을 할 수 있는 상태인지를 주기적으로 검사하는 경우가 많습니다.
이러한 검사를 헬스 체크라고 합니다. 서버의 건강 상태를 주기적으로 모니터링하고 체크하는 것입니다.
헬스 체크는 주로 로드 밸런서에 의해 이루어지는 경우가 많습니다.
부하가 균등하게 분산되도록 부하 대상을 선택하는 방법을 로드 밸런싱 알고리즘이라 부릅니다.
단순히 서버를 돌아가며 선택하거나, 연결이 적은 서버부터 우선적으로 선택하거나,
단순히 무작위로 선택하거나, 해시라는 자료 구조를 이용하여 선택하거나, 응답 시간이 가장 짧은 서버를 선택하기도 합니다.
용어 설명할 수 있어야 함
암호와 인증서
이 뒤는 다음 시간에
가용성, 안정적인 서버, 하는 방법, 고려사항, 과정 등
본인의 언어로 정리해 말할 수 있어야 함.
____________________________________________________________________________________
https://teamsparta.notion.site/Wrap-Up-39dbbfb4fcf54e9fa89c17039427afef
암호와 인증서
| 구분 | 대칭 키 암호화 | 비대칭 키 암호화 |
| 키의 사용 방식 | 암호화와 복호화에 동일한 키 사용 | 암호화 키(공개 키)와 복호화 키(개인 키) 다름 |
| 보안성 | 키를 안전하게 전달하기 어려움 | 키 공유가 안전함 (공개 키를 이용) |
| 속도 및 성능 | 암호화/복호화 속도가 빠름, 부하가 적음 | 암호화/복호화 속도가 상대적으로 느림, 부하가 큼 |
| 주요 문제점 | 키가 유출되면 보안에 치명적 | 암호화/복호화의 처리 시간이 더 오래 걸림 |
| 주요 활용 | 빠른 데이터 전송이 필요할 때 | 키 교환, 디지털 서명, 인증 등 높은 보안이 필요할 때 |
| 예시 | AES, DES | RSA, ECC |
암호화 및 인증서와의 관계
암호화: 데이터를 보호하기 위해 원문을 알아볼 수 없는 형태로 변경하는 과정.
대칭 키와 비대칭 키 방식 모두 암호화에 사용되며, 목적에 따라 선택적으로 사용.
인증서: 비대칭 키 암호화에서 공개 키의 신뢰성을 보장하기 위해 사용.
공개 키가 진짜 특정 사용자에게 속하는지 확인하기 위해 신뢰할 수 있는 기관(CA, 인증 기관)이 인증서를 발급.
주요 활용 시나리오
단독 사용:
대칭 키: 데이터 전송 시 빠른 처리 속도가 중요한 경우 사용.
비대칭 키: 초기 키 교환이나 보안 민감 데이터 보호에 사용.
혼합 사용:
첫 전달만 개인키로 비밀리에 전달한다
공개 키로 대칭 키를 암호화해 안전하게 전달 → 전달받은 대칭 키로 데이터를 암호화 및 복호화.
이 방식에서 사용되는 대칭 키를 "세션 키"라고 부름.
(요청하는 쪽에서 대칭키를 보내는군요)
안나가 ‘대칭키’를 가지고 있음
대칭키 : 암호화, 복호화할 때 키가 동일함
2. 안나가 B에게 공개키 요구
B 가 공개키 보냄
3. 안나가 대칭키를 B의 공개키(개인키)로 안나의’대칭키‘를 암호화 하여 B에게 보냄
4. B는 전달받은 암호화된 대칭 키를 B의 개인키(공개키)로 복호화.
5. B는 전달받은 대칭 키로 데이터를 암호화 및 복호화.
인증서와 디지털 서명
네트워크에서 인증서는 일반적으로 공개 키 인증서를 뜻함.
공개 키 인증서란 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서입니다.
서버에서 전달받은 공개 키가 정말 신뢰할 수 있는 것인지, 전송 도중에 조작되지는 않았는지 확신하기 위해 서버는 공개 키 뿐만 아니라 누가 생성했는지, 조작되지는 않았는지, 유효 기간은 언제까지인지 등의 내용을 포함한 인증서를 전송합니다.
서버는 인증키를 인증 기관에서 미리 받아두고 요청이 오면 기타 정보와 함께 클라이언트에게 전달함.
인증서는 인증 기관(Certification Authority, CA)이라는 제3의 기관에서 발급합니다.
인증 기관은 인증서의 발급, 검증, 저장과 같은 역할을 수행할 수 있는 공인 기관입니다.
CA가 발급한 인증서에는 서명 값(Signature)이 있습니다. 클라이언트는 이 서명 값을 바탕으로 인증서를 검증할 수 있습니다.
/*************** 의도한 곳에서인증서 발급한 인증서가 맞는가 확인 ****************/
서명 값은 ‘인증서 내용에 대한 해시 값을 CA의 개인 키로 암호화’하여 만들어 집니다.
CA는 이 서명 값을 클라이언트에게 인증서와 함께 전송합니다.
“인증서 내용 : ABC”, ⇒ 해시 : 3dsafd
“인증서 내용을 해시처리하고 개인키로 암호화한 값 : asdfasdf” ⇒ 공개키로 복호화 : 3dsafd(인증서 내용을 해시 처리한 값)
서명 값이 붙은 인증서를 전달 받았다고 가정해봅시다.
인증서 검증을 위해 가장 먼저 할 일은 서명 값과 인증서를 분리하는 것입니다.
서명 값은 ‘인증서 내용에 대한 해시 값을 CA의 개인 키로 암호화’한 것입니다.
CA의 공개 키는 공개되어 있기에, 서명 값은 CA의 공개 키로 복호화할 수 있습니다.
서명 값을 CA의 공개 키로 복호화하면 ‘인증서 내용에 대한 해시 값’을 얻을 수 있습니다.
해당 해시 값을 실제 받은 인증서를 해시한 값과 비교하여 일치하는지 확인합니다.
만약 값이 일치한다면 전달받은 인증서는 확실히 CA의 개인 키로 만들어졌다고 보장할 수 있습니다.
이렇게 개인 키로 암호화된 메시지를 공개 키로 복호화함으로써 신원을 증명하는 과정을 디지털 서명이라고 부릅니다.
인증을 신뢰할 수 있도록 하는 기관이 존재.
클라이언트가 인증서를 신뢰하기 위해 서버에서 받은 서명 값을 CA의 공개키로 복호화 하고 이 값이 인증서의 해시한 값과 같아야 함. 일치 하지 않으면(정상적인 발급아님) 안받던가 하는 처리를 해줘야함
주기적으로 인증서를 갱신하고 통신마다 어느 인증서로 확인할지 알려준다.
정보가 변조되었는지 확인하기 위해 인증서를 붙이는 거라 인증서를 복호화할 수 있는 키는 공개해도 됩니다
개인키로 암호화하면 공개키로
복호화 공개키로 암호화하면 개인키로 암호화
개인 키로 암호화한 다음에 공개 키를 보내줘서 현재 보낸 데이터를 복호화하고 인증서를 해시한 값을 확인한다 이런 절차
인증서와 디지털 서명을 우리는 어떻게 사용
https는 앞서 우리가 학습한 인증서와 디지털 서명 개념이 활용되었습니다.
인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 합니다.
그리고 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부른다고 배웠습니다.
웹 브라우저는 미리 CA 리스트와 함께 각 CA의 공개키를 알고 있습니다.
인터넷 사이트(서버)는 공개키와 개인키를 만들고, 신뢰할 수 있는 인증 기관(CA)에 자신의 정보와 공개키를 관리해달라고 계약하고 (경우에 따라) 돈을 지불합니다.
이 때, 계약을 완료한 인증 기관은 기관만의 공개키와 개인키가 있습니다. 인증 기관은 사이트가 제출한 데이터를 검증하고, 인증 기관의 개인키로 사이트에서 제출한 정보를 암호합니다.
인증서를 만들어 인터넷 사이트에 제공합니다.
인증 기관은 웹 브라우저에게 자신의 공개키를 제공합니다.
사용자가 사이트에 접속합니다.
서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 보냅니다.
웹 브라우저는 미리 알고 있던 인증기관의 공개키로 인증서를 해독하여 검증합니다. 그러면 사이트의 정보와 서버의 공개키를 알 수 있게 됩니다.
이렇게 얻은 서버의 공개키로 대칭키를 암호화해서 다시 사이트에 보냅니다.
사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고받을 수 있게 된다.
이 뒤는 수요일에.
오늘배운 내용 복슴하고 이해 안되는 부분은 수요일에 질문하기
'내일배움캠프_게임서버(202410) > 분반 수업 스텐다드' 카테고리의 다른 글
| cpu 조사 (2) | 2025.01.03 |
|---|---|
| 전송계층 정리 241227 (1) | 2024.12.27 |
| 응용 계층(Application Layer) 조사 (0) | 2024.12.26 |
| 전송계층 - TIL1223 (0) | 2024.12.23 |
| OSI 4계층 전송 계층(Transport Layer) (0) | 2024.12.18 |
