[250212] TIL

오늘 한 것

클라이언트 - 서버

클라이언트

• 클라이언트는 서버에게 필요한 자원을 요청하는 역할이다.
• 사용자와 직접 상호작용을 하고 UI/UX를 제공한다.
• 예시: 웹 브라우저, 모바일 앱, 데스크톱 애플리케이션

서버

• 서버는 자원을 관리하고 다수의 클라이언트에게 필요한 자원을 응답하는 역할이다.
• 예시: 웹 서버, 데이터베이스 서버, 파일 서버

DNS (Domain Name System)

• 도메인 이름을 IP 주소로 변환하는 시스템
• 인터넷의 전화번호부 역할이라고 생각하면 더 와닿는다.
• 예시: www.google.com → 172.217.161.36
• IP 주소보다 도메인 이름을 사용해서 기억하기가 쉬운 것이 장점이고, 서버 IP가 바뀌더라도 도메인은 유지 할 수 있다.
• 로드 밸런싱이 가능하다. → 하나의 도메인 주소에 여러 개의 IP 주소가 가능
  • 로드 밸런싱이란, 서버에게 가해지는 부하를 분산 시키는 기술이다. 다수의 서버로 트래픽을 균등하게 분배 가능

Forward Proxy

[Client] → [Forward Proxy] → [Internet] → [Server]

• 클라이언트와 인터넷 사이에 위치한 중계서버
• 클라이언트의 요청을 대신 전달하고 응답을 받아옴
• 주요 기능
  • 캐싱, 익명성 ( 실제 Client IP 숨김), 접근 제어 (허용 하는 네트워크 말고는 차단)
• Reverse Proxy 라고도 있는데 서버를 보호하고 제어함
  • [Internet] → [Reverse Proxy] → [Server]

OSI 7계층

• 각 7계층이 독립적으로 동작하면서 전체 네트워크가 작동함

7. 응용 계층 ( Application Layer )

• 역할 : 사용자와 직접 상호작용
• 프로토콜 : HTTP, FTP, SMTP, DNS

HTTP Request/Response
GET /index.html HTTP/1.1 // GET 메서드, 요청하는 리소스 경로, HTTP 버전
Host: www.example.com  // 호스트 헤더

6. 표면 계층 ( Presentation Layer )

• 역할 : 데이터 형식 변환, 암호화
• 기능 : 인코딩, 암호화, 압축

JAPG, PNG 이미지 변환
ASCII <-> EBCDIC // (변환,7비트 인코딩 -> 8비트 인코딩)
SSL/TLS 암호화

• HTTPS 는 보안을 위해 표현 계층의 SSL/TLS 사용하는 HTTP 이다.

5. 세션 계층 ( Session Layer )

• 역할 : 통신 세션 관리 - 논리적인 연결을 관리함
• 기능 : 연결 수립, 유지, 종료

NetBIOS (컴퓨터 간 통신 세션 관리)
RPC ( Remote Procedure Call, 원격 프로시저 호출 )
SQL ( 데이터 베이스 세션 관리 )
세션 토큰 관리

4. 전송 계층 ( Transport Layer )

• 역할 : 신뢰성 있는 데이터 전송
• 프로토콜 : TCP, UDP

TCP 연결:
SYN → SYN/ACK → ACK
포트 번호: 80, 443

3. 네트워크 계층 ( Network Layer )

• 역할 : 패킷 라우팅, 주소 지정
• 프로토콜 : IP, ICMP, ARP

IP 주소: 192.168.0.1
라우팅 테이블 관리

2. 데이터링크 계층 ( Data Link Layer )

• 역할 : 물리적 주소 지정, 오류 검출
• 프로토콜 : Ethernet, MAC
  • 네트워크 장비의 고유 물리 주소
  • 48비트 길이
  • 전 세계적으로 유일한 값이고 제조 시 부여 된다.
  • NIC(네트워크 카드)에 고정 된다.

MAC 주소: 00:00:5e:00:53:af
프레임 단위 전송

1. 물리 계층 ( Physical Layer )

• 역할 : 비트 단위 데이트 전송
• 매체 : 케이블, 허브, 리피터

전기 신호, 광 신호
RS-232C, 이더넷 케이블

데이터 흐름

[응용] → [표현] → [세션] → [전송] → [네트워크] → [데이터링크] → [물리]
     데이터 캡슐화 (Encapsulation)
     
[물리] → [데이터링크] → [네트워크] → [전송] → [세션] → [표현] → [응용]
     데이터 역캡슐화 (Decapsulation)

각 계층별 PDU ( Protocol Data Unit )

L7-L5: 데이터 (Data)
L4: 세그먼트 (Segment)
L3: 패킷 (Packet)
L2: 프레임 (Frame)
L1: 비트 (Bit)

Mac 과 IP 비교

MAC 주소:
- 물리적 주소
- L2 계층
- 변경 어려움
- 전역적으로 유일

IP 주소:
- 논리적 주소
- L3 계층
- 쉽게 변경 가능
- 네트워크별로 할당

TCP ( Transmission Control Protocol )

• 정의 : 신뢰성 있는 데이터 전송을 보장하는 프로토콜
• 계층 : 전송 계층 ( L4 )
• 특징 : 연결 지향적 (두 개의 호스트를 연결) , 순서 보장, 오류 검출

3way-handshake

• TCP/IP 네트워크 프로토콜에서 연결을 초기화 하는 과정임

[클라이언트]          [서버]
     |                 |
     |---SYN(seq=x)-->|   # 1단계
     |                 |
     |<-SYN+ACK-------|   # 2단계
     |   (seq=y,ack=x+1)  
     |                 |
     |---ACK(ack=y+1)->|   # 3단계
     |                 |

1단계 : SYN ( Synchronzie ) 단계

클라이언트 → 서버
- SYN 플래그 설정
- 초기 시퀀스 번호(ISN) 전송

• 클라이언트가 서버에 접속을 요청하는 SYN 패킷을 보냄
• 패킷에는 클라이언트가 세션을 시작할 준비가 되었다는 신호랑, 클라이언트 초기 시퀀스 번호(ISN) 이 포함
• 패킷 하나하나에 번호를 붙이고, 패킷들이 빠진게 있는지 확인할 수 있음
• 예) 클라이언트 -> 서버: SYN (SEQ = 1000)
  • 클라이언트 : “내 시작 번호는 1000이야”

2단계 : SYN-ACK ( Synchronize-Acknowledgment ) 단계

• 서버가 SYN 요청을 받고, 클라이언트에게 SYN-ACK 패킷을 보냄
• 서버의 초기 스퀀스 번호도 포함되어있음
• 예) 서버 -> 클라이언트: SYN-ACK (SEQ = 2000, ACK = 1000 + 1 = 1001)
• 서버 : “내 시작 번호는 2000이고, 너의 다음 번호는 1001을 기대할게”

3단계 : ACK ( Acknowledgment ) 단계

• 클라이언트가 서버의 시퀀스 번호를 받았고, 서로 간의 연결이 정상적으로 수립 되었다는 것을 확인
• 예) 클라이언트 -> 서버: ACK (SEQ = 1001, ACK = 2000 + 1 = 2001)
• 클라이언트 : “알겠어, 너의 다음 번호는 2001을 기대할게”

SEQ ( Sequence Number )

• 정의 : 전송하는 데이터의 순서 번호
• 초기값 : 보안상의 이유로 랜덤하게 선택 된다.
• 위 예시는 클라이언트 초기 SEQ = 1000 (랜덤)

ACK ( Acknowledgment Number )

• 정의 : 다음에 받기를 기대하는 SEQ 번호
• 계산 : 받은 SEQ + 1
• “여기까지 받았으니, 다음 번호를 보내주세요.”

ESTABLISHED

• 연결이 수립된 것을 확인하고 데이터 전송 준비 완료 됐음을 의미

와이어샤크

• 네트워크 패킷 분석하는 도구, 패킷을 뜯어볼 수 있음

흐름제어 ( Flow Control )

• 목적 : 송신자와 수신자 간의 데이터 처리 속도 차이 해결
• 방식 : 수신자의 버퍼 상태에 따라 송신 속도 조절
• 수신자 버퍼 오버플로우 방지

[수신자 버퍼]
여유 공간: 1000바이트
→ 송신자에게 윈도우 크기 1000 알림
→ 송신자는 최대 1000바이트까지만 전송

혼잡제어 ( Congestion Control )

• 목적 : 네트워크 혼잡 상태 관리
• 방식 : 네트워크 상황에 따라 전송 속도 조절
• 패킷 손실 최소화

슬라이딩 윈도우 ( Sliding Window )

• 목적 : 효율적인 데이터 전송
• 방식 : 여러 패킷을 연속해서 전송하고 한번에 확인
• 연속 전송으로 효율성 향상

slow start

• 목적 : 초기 네트워크 부하 방지
• 방식 : 전송량을 점진적으로 증가
• 안전한 초기 연결, 점진적 속도 증가

UDP

• 빠르고 간단한 통신을 위해 연결 설정 없이 데이터를 전송하는 네트워크 프로토콜
• TCP 보다는 신뢰성 낮습니다.
• 빠른 전송이 최대 장점

CDN

• 사용자에게 가장 가까운 서버에서 응답을 함
• 로딩 시간을 줄이고, 대역폭 사용을 최적화하며, 전반적인 사용자 경험을 향상 시킴
• 사용자가 여기 저기 흩어져 있어서 여러 지역에 CDN 이라는 거점을 만들어서 사용자에게 응답을 전달할 때 좀 더 빠르게 전달하는 것

Cloudflare, Amazon CloudFront, Microsoft Azure CDN, Google Cloud CDN

HTTP / HTTPS

HTTP

• 암호화 되지 않은 텍스트를 데이터를 전송
• 보안에 취약하지만 통신 속도는 빠르다.
• 80번 포트 사용
• OSI 7계층에서 7계층 응용 계층에 속한다.

HTTPS

• 암호화 된 데이터를 전송
• 안전한 전송을 보장한다. ( SSL/TLS 암호화 )
• 처음앤 비대칭키를 이용해서 신원을 검증하고, 이후엔 대칭키를 이용해 암호화해서 데이터를 주고 받는다.
  • 이렇게 하는 이유는? 비대칭키가 더 안전하게 신원 확인할 수 있고, 대칭키가 빠른 암/복호화가 가능해서 효율적이기 때문이다.
• OSI 7계층과 6계층에 속한다. ( SSL/TLS 가 표현 계층, 암호화 부분을 말함)

HTTP Method 요청의 종류

• GET (조회)
• POST (생성)
• PUT (전체 수정)
• DELETE (삭제)
• PATCH (부분 수정)

참고

• HTTP Method 는 요청의 종류/동작을 나타내는 방식
• REST API : HTTP Method를 포함한 API 설계 규칙

HTTP Header/Body 구조

[Start Line]
GET /index.html HTTP/1.1

[Headers]
Host: www.example.com
Content-Type: application/json
...

[Empty Line]

[Body]
{
    "name": "John",
    "age": 30
}

// Request
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123

{
    "name": "John",
    "email": "john@example.com"
}

// Response
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
Set-Cookie: session=abc123

{
    "id": 1,
    "status": "success"
}

HTTP 상태 코드

1xx (정보) - Information

100: Continue (계속)
101: Switching Protocols (프로토콜 전환)
102: Processing (처리 중)

2xx (성공) - Success

200: OK (요청 성공)
201: Created (생성 성공)
202: Accepted (요청 접수)
204: No Content (성공, 내용 없음)
206: Partial Content (부분 성공)

3xx (리다이렉션) - Redirection

300: Multiple Choices (여러 선택)
301: Moved Permanently (영구 이동)
302: Found (임시 이동)
304: Not Modified (변경 없음)
307: Temporary Redirect (임시 리다이렉션)
308: Permanent Redirect (영구 리다이렉션)

4xx (클라이언트 오류) - Client Error

400: Bad Request (잘못된 요청)
401: Unauthorized (인증 필요)
403: Forbidden (권한 없음)
404: Not Found (찾을 수 없음)
405: Method Not Allowed (허용되지 않은 메소드)
409: Conflict (충돌)
429: Too Many Requests (요청 횟수 초과)

5xx (서버 오류) - Server Error

500: Internal Server Error (서버 내부 오류)
501: Not Implemented (구현되지 않음)
502: Bad Gateway (게이트웨이 오류)
503: Service Unavailable (서비스 이용 불가)
504: Gateway Timeout (게이트웨이 시간 초과)

상태 코드 그룹별 의미 

1xx: "잠깐만요..."
2xx: "성공했어요!"
3xx: "다른 곳으로 가보세요"
4xx: "클라이언트가 잘못했어요"
5xx: "서버가 잘못했어요"

TLS / SSL ( Transport Layer Security / Secure Sockets Layer )

• 데이터 암호화 프로토콜 (보안 통신을 위해 방법과 규칙의 모음 느낌)
• HTTPS의 보안 계층이다.
• 현재는 SSL → TLS 로 발전함
• TLS/SSL Handshake 가 교재에 나와 있는 비대칭키로 서로 신원 먼저 확인하고 대칭키로 데이터를 주고 받는 과정

[1단계: 서버 인증 & 암호화 방식 결정]

클라이언트 → 서버: "Client Hello"
- 지원가능한 암호화 방식
- 클라이언트 랜덤 데이터

서버 → 클라이언트: "Server Hello"
- 서버 인증서 (서버 공개키 포함)
- 선택된 암호화 방식
- 서버 랜덤 데이터

[2단계: 대칭키 교환]

클라이언트:
- CA 공개키로 서버 인증서 검증
- 클라이언트/서버 랜덤 데이터로 대칭키 생성
- 서버 공개키로 대칭키 암호화

클라이언트 → 서버: 암호화된 대칭키 전송

서버:
- 개인키로 암호화된 대칭키 복호화

[3단계: 대칭키 통신 시작]

이후 모든 통신: 대칭키로 암호화/복호화

QUIC, HTTP 버전별 특징 비교, HTTP/2 Multiplexing

• 잘 와닿지 않아서 정리만 했음

QUIC (Quick UDP Internet Connection)

특징:
- UDP 기반 프로토콜
- TCP+TLS+HTTP/2 기능을 통합
- 연결 설정 시간 감소
- 향상된 혼잡 제어

장점:
- 빠른 연결 수립 (0-RTT)
- 향상된 패킷 손실 복구
- 연결 마이그레이션 지원

HTTP 버전별 특징

HTTP/1.0 (1996)

- 연결당 하나의 요청
- 매 요청마다 새로운 연결
- Connection: keep-alive 없음

HTTP/1.1 (1997)

- 지속 연결 (keep-alive)
- 파이프라이닝 도입
- 호스트 헤더 필수
- HOL(Head of Line) Blocking 문제

HTTP/2 (2015)

- 멀티플렉싱
- 헤더 압축 (HPACK)
- 서버 푸시
- 스트림 우선순위
- 바이너리 프로토콜

HTTP/3 (2022)

- QUIC 기반
- 향상된 멀티플렉싱
- 개선된 혼잡 제어
- 0-RTT 연결

HTTP/2 Multiplexing 상세 설명

• HTTP/1.1 에서는 요청을 순차적으로 처리를 해서 요청이 지연 되는 문제가 있었다.
• 단일 연결로 여러 요청을 처리함

요청1 ---->
요청2 ---->
요청3 ---->
         응답2 ---->
         응답1 ---->
         응답3 ---->
(동시 처리 가능)

대칭키, 비대칭키 암호화 방식

대칭키 암호화 방식

• 하나의 키로 암호화/복호화를 한다.
• 속도가 빠르다.
• 키 공유가 어렵다. → 누군가가 탈취했을 때 그 누군가도 암호화/복호화가 가능해지기 때문
  • 해결 방안으로는 비대칭키로 먼저 안전한지 신원 검사를 먼저 한다.
• 예시 알고리즘 : AES, DES, 3DES

[암호화]
평문 + 대칭키 → 암호문

[복호화]
암호문 + 대칭키 → 평문

비대칭키 암호화 방식

• 공개키/개인키 쌍으로 사용
• 속도가 느리지만 안전한 키 교환이 가능하다.
• 예시 알고리즘 : RSA, ECC, DSA

[암호화]
평문 + 공개키 → 암호문
암호문 + 개인키 → 평문

[전자서명]
문서 + 개인키 → 서명
서명 + 공개키 → 검증

HTTP Cache

• 웹 사이트나 프록시 서버가 자주 사용하는 자원(이미지, JS, CSS 등)을 임시 저장해서 재사용 사용하는 것을 말한다.
• 서버 부하를 줄이고 성능을 향상 시키는 기술이다.
• 프록시 서버란 ? 클라이언트와 서버 사이의 중계 서버를 말한다. (Forward Proxy, Reverse Proxy)

API

• API란 두 객체 사이에 서로 소통을 위해 만들어진 접점
• 서로 다른 시스템이나 애플리케이션 간에 데이터를 교환하고 기능을 공유하기 위해 사용한다.
• 기능을 재사용 할 수 있다.
• 유연하고 확장 가능한 시스템을 구축할 수 있다.

API Gateway

• 클라이언트와 백엔드 서비스 사이의 중간 계층
• 모든 API 요청의 진입점이다.
• 주요 기능으로는 라우팅, 인증/인가 (JWT, API 키 확인, OAuth ), 로드밸런싱(요청 분산 처리), 캐싱이 있다.
• 보안을 강화, 성능 최적화, 모니터링/로깅, 유연성이 강화된다.

[클라이언트]
     ↓
[API Gateway]
     ↓
┌────┼────┐
↓    ↓    ↓
인증  주문  상품
서비스 서비스 서비스

REST 아키텍처 스타일

• 자원을 중심으로 API 를 설계하는 스타일을 말함
  • 자원 = 클라와 서버가 주고 받는 데이터
• REST는 소프트웨어 아키텍처 스타일 중 하나이다.
  1. Uniform Interface
  • 모든 API 가 일관된 방식으로 통신하도록 함
  • 단순성과 상호 운용성을 보장해야 한다.
    1. Client-Server
  • 클라이언트와 서버가 독립적으로 구분되어 있어야 한다.
    1. Stateless
  • 서버는 클라이언트 정보를 저장하지 않아야 한다.
    1. Cachable
  • 응답은 캐싱이 가능하도록 명시 되어야 한다.
    1. Layered System
  • 클라이언트는 서버가 단일 서버인지, 다층 계층을 통해 데이터를 전달하는 중계서버를 거치는지 알 수 없어야 한다.
    1. Self-Descriptiveness
  • 메세지 자체가 충분한 정보를 담고 있어서, 클라이언트가 어떻게 처리해야 할 지 알 수 있어야 한다.

REST API

• REST 아키텍처 스타일을 따르는 응용 프로그램 인터페이스
• 개발자 관의 일관된 통신 규칙을 통해 업무 효율을 높이기 위해 사용한다.
• 단순한 URL 구조를 보고도 어떤 요청인지 이해할 수 있도록 한다.
• 행위에 따라 GET PUT DELETE 등으로 HTTP 메소드를 활용하면 RESTful 하다고 한다.