Network - HTTP, HTTPS, REST

0. 다양한 응용 계층 Protocols

컴퓨터 네트워크에서 응용 계층 프로토콜은 사용자의 요구를 처리하고 응용 프로그램 간 데이터 통신을 담당합니다.

이 중에서도 다음 프로토콜은 일상적으로 자주 사용되며, 기본적인 이해가 중요합니다.

• HTTP/HTTPS (HyperText Transfer Protocol)
  웹사이트의 정보를 주고받는 데 사용되는 프로토콜로, 인터넷 상에서 가장 많이 활용됩니다.

• DNS (Domain Name System)
  사용자가 입력한 도메인 이름을 IP 주소로 변환해주는 프로토콜로, 인터넷 통신에서 필수적인 역할을 합니다.

• FTP (File Transfer Protocol)
  파일을 업로드 및 다운로드하기 위한 표준 프로토콜입니다.

• SMTP/POP3 (Simple Mail Transfer Protocol / Post Office Protocol)
  이메일 송수신에 사용되며, SMTP는 메일 송신, POP3는 메일 수신 프로토콜입니다.

---

1. HTTP

HTTP는 인터넷(WWW, World Wide Web)에서 정보를 주고받는 데 사용되는 프로토콜입니다.

• 인터넷 상의 웹 브라우저와 서버 간의 통신을 지원합니다.

1.1 인터넷(WWW, Web)의 주요 요소

• HTML (HyperText Markup Language)
  • 웹 페이지를 작성하는 데 사용하는 마크업 언어입니다.
  • 하이퍼텍스트와 하이퍼링크를 통해 페이지 간 이동을 지원합니다.
• URL (Uniform Resource Locator)
  • 인터넷 상의 자원의 위치를 나타내는 주소 체계입니다.
• HTTP (HyperText Transfer Protocol)
  • 웹 서버와 클라이언트 간 데이터를 주고받기 위한 규약입니다.

1.2 HTTP의 기본 동작

HTTP는 클라이언트-서버 모델을 기반으로 동작하며, 클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환합니다.

• HTTP는 Connectionless(연결 유지 없음) 프로토콜로, 요청과 응답이 1회성으로 이루어집니다.

1.3 HTTP/1.0과 HTTP/1.1

HTTP/1.0

• 서버와 클라이언트 간 통신은 한 번의 요청과 응답 후 연결이 종료됩니다.
• Connectionless 특성으로 인해 매번 새로운 연결을 생성해야 합니다.

HTTP/1.1

• Keep-Alive 기능
  • 하나의 연결을 유지한 채로 여러 요청과 응답을 처리합니다.
  • 이를 통해 TCP 3-way 핸드셰이크 과정의 오버헤드를 줄일 수 있습니다.
• 일반적으로 현재 웹에서 가장 널리 사용되는 HTTP 버전입니다.

1.4 HTTP 요청/응답 구조

HTTP 통신은 요청(Request)과 응답(Response)의 형태로 이루어집니다.

• Request
  • HTTP 메서드(GET, POST 등)
  • 요청 URL(Path) 및 HTTP 버전
  • 헤더 정보 (Host, User-Agent 등)
  • 요청 본문 (필요한 경우)
    

• Response
  • 응답 상태 코드 (200 OK, 404 Not Found 등)
  • 헤더 정보 (Content-Type, Content-Length 등)
  • 응답 본문 (HTML, JSON 등)
    

1.5 주요 HTTP Method & HTTP Response Code

HTTP Method

HTTP는 클라이언트와 서버 간의 작업을 정의하는 다양한 메서드를 제공합니다.

• GET (Read)

  • 서버로부터 데이터를 요청하며, URL에 쿼리 파라미터로 데이터를 전달합니다.
  • 예) 브라우저에서 웹 페이지를 요청.

• POST (Create)

  • 서버에 데이터를 전송하여 리소스를 생성하거나 처리합니다.
  • 예) 회원가입 양식 제출.

• PUT (Update)

  • 서버의 기존 리소스를 수정합니다.
  • 예) 사용자의 프로필 정보 업데이트.

• DELETE (Delete)

  • 서버의 특정 리소스를 삭제합니다.
  • 예) 게시글 삭제 요청.

HTTP Response Code

HTTP 응답 코드는 클라이언트의 요청에 대한 서버의 응답 상태를 나타냅니다.

상태 코드	의미	설명
1xx (정보)	100 Continue	요청이 초기 단계에서 정상적으로 처리되었음을 나타냅니다.
2xx (성공)	200 OK	요청이 성공적으로 처리되었습니다.
	201 Created	요청에 의해 새로운 리소스가 생성되었습니다.
3xx (리다이렉션)	301 Moved Permanently	요청한 리소스가 영구적으로 새로운 위치로 이동되었습니다.
	302 Found	요청한 리소스가 임시적으로 다른 위치로 이동되었습니다.
4xx (클라이언트 오류)	400 Bad Request	클라이언트의 요청이 잘못되어 서버에서 처리할 수 없습니다.
	401 Unauthorized	인증이 필요한 요청이지만, 인증 정보가 없거나 잘못되었습니다.
	403 Forbidden	클라이언트가 요청한 리소스에 대한 접근 권한이 없습니다.
	404 Not Found	요청한 리소스를 찾을 수 없습니다.
5xx (서버 오류)	500 Internal Server Error	서버에서 요청을 처리하는 중 오류가 발생했습니다.
	503 Service Unavailable	서버가 일시적으로 사용 불가능한 상태입니다.

1.6 쿠키(Cookie)와 세션(Session)

HTTP의 Stateless 특성과 문제점

HTTP는 Stateless(상태를 유지하지 않음) 프로토콜입니다.

• 즉, 클라이언트와 서버 간의 요청/응답이 끝나면 연결 정보가 유지되지 않습니다.
• 이러한 특성으로 인해, 로그인 상태 유지나 장바구니 기능과 같은 지속적인 데이터 관리가 어려워집니다.

이를 해결하기 위해 쿠키(Cookie)와 세션(Session)을 사용합니다.

쿠키(Cookie)

• 정의
  • 클라이언트(브라우저)에 저장되는 작은 데이터 파일로, 서버가 클라이언트 상태 정보를 저장하고 관리할 수 있게 해줍니다.
• 특징
  • 클라이언트 측에 저장됨.
  • 클라이언트가 서버로 요청할 때마다 쿠키를 함께 전송.
  • 유효 기간(expires) 설정 가능:
    • 기간 설정 시: 로컬 디스크에 저장(만료 시 자동 삭제).
    • 기간 미설정 시: 메모리에 저장(브라우저 종료 시 삭제).
• 활용 사례
  • 로그인 상태 유지.
  • 사용자 맞춤 광고.

세션(Session)

• 정의
  • 서버에 저장되는 상태 정보로, 클라이언트별로 고유한 세션 ID를 통해 식별됩니다.
• 특징
  • 서버 측에 저장됨.
  • 브라우저 종료 시 세션이 기본적으로 만료되지만, 필요 시 설정으로 만료 시간을 변경할 수 있음.
• 활용 사례
  • 로그인 인증.
  • 임시 데이터 관리(예: 장바구니).

쿠키와 세션의 차이점

구분	쿠키(Cookie)	세션(Session)
저장 위치	클라이언트(브라우저)	서버
보안	보안에 취약(클라이언트 저장)	상대적으로 안전(서버 저장)
속도	서버 부담 적음	서버 부담 있음
유효 기간	유효 기간 설정 가능	기본적으로 브라우저 종료 시 만료

1.7 URL & URI

URL (Uniform Resource Locator)

URL은 인터넷 상의 자원의 위치를 나타내는 주소 체계입니다.

• 예를 들어, https://example.com/index.html은 특정 웹 페이지의 위치를 가리킵니다.

• 구성 요소

  • 프로토콜: https:// (데이터 통신 방식 정의)
  • 도메인: example.com (서버 주소)
  • 경로: /index.html (리소스 위치)
  • 쿼리 스트링: ?id=1&name=user (추가 데이터 전달)

URI (Uniform Resource Identifier)

URI는 인터넷 상의 리소스를 식별하기 위한 방법으로, URL을 포함하는 더 넓은 개념입니다.

• URL이 리소스의 위치를 표현한다면, URI는 위치뿐만 아니라 리소스 자체를 식별할 수 있습니다.

• URL과 URI의 관계

  • URL: 리소스의 위치를 가리킴.
    • 예: https://example.com/index.html
  • URI: 리소스의 위치와 식별자를 포함.
    • 예: https://example.com/index.html?id=1&name=user

URL과 URI의 주요 차이점

구분	URL	URI
정의	리소스의 위치를 나타냄	리소스의 식별자 역할
예시	https://example.com	https://example.com?id=1
포함 관계	URI의 하위 개념	URL을 포함하는 상위 개념

참고
URL과 URI는 실제로 혼용해서 사용되는 경우가 많으므로, 두 개념을 유연하게 이해하는 것이 중요합니다.

참고 (URL Rule)
URL을 작성하는 일반적인 명명법의 관례가 있습니다. (참고로 알아두시면 좋습니다.)

• 마지막에 /를 포함하지 않는다.
• _(언더바) 대신 -(대시)를 사용한다.
• 소문자를 사용한다
• 행위(method)는 URL에 포함되지 않는다. (GET, POST, 등)

2. HTTPS

2.1 HTTPS란?

HTTPS는 HTTP에 보안 계층(SSL/TLS)을 추가한 프로토콜로, 데이터를 암호화하여 클라이언트와 서버 간의 통신을 보호합니다.

• HTTP 통신의 취약점을 보완하기 위해 등장했으며, 인터넷에서 데이터의 기밀성, 무결성, 인증을 보장합니다.

• 기본 포트: 443 (HTTP는 기본 포트 80 사용)

• URL: https://로 시작

2.2 HTTPS의 동작 원리

HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security)를 사용하여 데이터를 암호화합니다.

1. SSL/TLS Handshake 과정

   • 클라이언트와 서버가 암호화 방식을 협의.
   • 서버는 디지털 인증서(SSL 인증서)를 통해 자신의 신원을 증명.
   • 클라이언트는 서버의 인증서를 검증.
   • 대칭키를 생성하여 이후 데이터 통신을 암호화.

2. 데이터 전송

   • 암호화된 데이터를 송수신.
   • 클라이언트와 서버만 데이터를 복호화할 수 있음.

3. 결과

   • 데이터 도청, 변조, 위조를 방지하여 안전한 통신을 보장.

2.3 네트워크 보안: SSL/TLS와 암호화 방식

대칭키 암호화 (Symmetric Key Encryption)

• 특징
  • 암호화와 복호화에 동일한 비밀키를 사용.
  • 처리 속도가 빠름.
• 단점
  • 키가 노출되면 보안이 깨짐.
  • 클라이언트와 서버 간 키를 안전하게 공유하는 것이 어려움.
• 사용 알고리즘: AES, DES, SEED 등.

비대칭키 암호화 (Asymmetric Key Encryption)

• 특징
  • 공개키(Public Key)와 개인키(Private Key)를 사용.
    • 공개키: 데이터를 암호화.
    • 개인키: 암호화된 데이터를 복호화.
  • 공개키는 누구나 접근 가능, 개인키는 소유자만 보관.
• 장점
  • 키 공유가 필요 없음.
  • 공개키만 제공하면 안전한 통신 가능.
• 단점
  • 대칭키 암호화보다 처리 속도가 느림.
• 사용 알고리즘: RSA, ECC 등.

SSL/TLS의 결합 방식

• 초기: 비대칭키를 사용하여 대칭키를 안전하게 교환.
• 이후: 대칭키로 데이터를 암호화하여 빠르고 안전한 통신을 유지.

네트워크 보안 개념 정리

1. 대칭키와 비대칭키 비교

구분	대칭키 암호화	비대칭키 암호화
사용 키 개수	하나(비밀키 공유)	두 개(공개키, 개인키)
속도	빠름	느림
보안성	키 공유 시 위험	공개키로만 암호화, 높은 보안성
주요 사용처	대량 데이터 암호화	인증, 키 교환

2. HTTPS의 암호화 과정 요약
   1. 클라이언트가 서버의 SSL 인증서를 요청.
   2. 서버가 공개키와 인증서를 제공.
   3. 클라이언트가 인증서를 검증.
   4. 클라이언트가 대칭키를 생성하고, 서버의 공개키로 암호화해 전송.
   5. 서버는 개인키로 복호화해 대칭키를 확보.
   6. 대칭키로 데이터 암호화 통신 진행.

2.4 HTTPS의 이점

• 보안성 강화:
  데이터를 암호화하여 도청과 중간자 공격(Man-in-the-Middle Attack)을 방지.

• 데이터 무결성 보장:
  전송 중 데이터가 변조되지 않음.

• 신뢰성 확보:
  SSL 인증서를 통해 서버의 신원을 보증.

• SEO 우대:
  Google 등 검색 엔진에서 HTTPS를 사용하는 웹사이트를 우대.

3. REST API

3.1 REST란?

REST는 REpresentational State Transfer의 약자로, 자원의 표현을 통해 상태를 전달하는 아키텍처 스타일입니다.

• HTTP 프로토콜을 기반으로 설계되어, 클라이언트와 서버 간 효율적이고 직관적인 통신을 가능하게 합니다.

3.2 REST의 기본 원칙

REST는 다음과 같은 원칙을 따릅니다:

1. 자원의 식별 (Resource Identification)

   • URI(Uniform Resource Identifier)를 통해 자원을 식별합니다.
   • 예: /users/123 (id가 123인 사용자)

2. 자원의 표현 (Resource Representation)

   • 자원은 JSON, XML 등 다양한 형식으로 표현됩니다.
   • 예: GET /users/123 → JSON으로 사용자 데이터 반환.

3. 메서드 기반 작업 정의

   • HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 자원의 행위(작업)를 정의합니다.
   • 예: GET → 조회, POST → 생성.

4. Stateless(무상태성)

   • 서버는 클라이언트의 상태를 유지하지 않습니다.
   • 각 요청은 필요한 모든 정보를 포함해야 합니다.

5. Self-descriptive Messages

   • HTTP 메시지는 필요한 정보(URI, 메서드, 헤더 등)를 자체적으로 포함합니다.

3.3 REST API란?

REST API는 REST 원칙을 따르는 API로, 클라이언트와 서버 간의 통신을 정의합니다.

• 활용 분야

  • 웹 애플리케이션, 마이크로서비스, 모바일 애플리케이션 등 다양한 환경에서 사용됩니다.

• 장점

  • 표준 HTTP 프로토콜 사용.
  • 설계가 간단하고 확장성이 뛰어남.
  • 언어와 플랫폼에 독립적.

• 단점

  • 고정된 HTTP 메서드 외에 추가 작업이 어려움.
  • 상태 유지가 필요한 작업에 적합하지 않음.

REST API의 HTTP 메서드와 CRUD 매핑

HTTP 메서드	CRUD 작업	예시	설명
GET	Read (조회)	GET /users/123	사용자 정보 가져오기
POST	Create (생성)	POST /users	새로운 사용자 생성
PUT	Update (수정)	PUT /users/123	사용자 정보 업데이트
DELETE	Delete (삭제)	DELETE /users/123	사용자 정보 삭제

3.4 RESTful의 특징

REST API가 RESTful하려면 다음 규칙을 준수해야 합니다:

1. URL 설계

   • URI는 리소스를 나타내야 하며, 행위(Method)는 포함하지 않아야 합니다.
   • 예: POST /users → /users 생성
   • 잘못된 예: /users/insert

2. HTTP 상태 코드 사용

   • 요청에 대한 서버 응답은 표준 HTTP 상태 코드를 사용해야 합니다.

   • 예:

     • 200 OK → 요청 성공.
     • 201 Created → 리소스 생성 성공.
     • 404 Not Found → 리소스 없음.

3. Self-descriptive Messages

   • 요청과 응답이 각각 완전한 정보를 포함해야 합니다.

4. Stateless

   • 서버는 클라이언트의 상태 정보를 저장하지 않고, 클라이언트는 필요한 정보를 매 요청마다 제공해야 합니다.

3.5 REST API 설계 예시

1. 사용자 데이터 관리 API:

작업	HTTP 메서드	URL	설명
사용자 목록 조회	GET	/users	모든 사용자 데이터 가져오기
사용자 정보 조회	GET	/users/{id}	특정 사용자 데이터 가져오기
사용자 생성	POST	/users	새 사용자 데이터 생성
사용자 정보 수정	PUT	/users/{id}	특정 사용자 데이터 수정
사용자 삭제	DELETE	/users/{id}	특정 사용자 데이터 삭제

2. 상태 코드 예시:

상태 코드	설명
200 OK	요청 성공
201 Created	요청 성공 및 리소스 생성 완료
400 Bad Request	잘못된 요청
404 Not Found	리소스를 찾을 수 없음
500 Internal Server Error	서버 내부 오류

마무리

이번 포스팅에서는 HTTP, HTTPS, REST API를 중심으로 네트워크의 핵심 개념을 살펴보았습니다.

• HTTP/HTTPS: 인터넷 통신의 기반이 되는 프로토콜로, HTTPS는 보안을 강화한 HTTP의 확장 버전입니다.
• REST API: 웹 애플리케이션에서 가장 널리 사용되는 API 설계 원칙으로, 효율적이고 직관적인 데이터 교환을 지원합니다.

추천 학습 자료 및 참고 링크

• MDN Web Docs - HTTP Overview
• RESTful API Design - Best Practices

다음 포스팅에서는 널리 쓰이는 또다른 응용 계층 프로토콜인 DNS, Mail Protocols(SMTP/POP3), FTP에 대해서 다루어 보도록 하겠습니다.