2025-01-24T01:44:03

This commit is contained in:
2025-01-24 01:44:03 +09:00
parent 297ea8abaf
commit 3d30ee3192
68 changed files with 1128 additions and 1079 deletions

72
doc/http/01_http.md Normal file
View File

@@ -0,0 +1,72 @@
# HTTP
**HTTP(HyperText Transfer Protocol)**는 웹에서 정보를 주고받기 위해 사용되는 기본적인 통신 규약입니다. 우리가 웹 브라우저를 통해 웹페이지를 보거나, 이미지를 다운로드하거나, 온라인 쇼핑을 할 때 모두 HTTP 프로토콜이 사용됩니다.
## HTTP 프로토콜의 역할
* 웹 페이지 요청: 사용자가 웹 브라우저의 주소창에 URL을 입력하면 브라우저는 해당 URL에 대한 HTTP 요청을 서버로 보냅니다.
* 서버의 응답: 서버는 요청받은 내용을 처리하고, 요청된 웹 페이지의 HTML 코드, 이미지, CSS 파일 등을 포함하는 HTTP 응답을 브라우저로 보냅니다.
* 브라우저의 렌더링: 브라우저는 받은 응답을 해석하여 우리가 보는 웹 페이지로 렌더링합니다.
## HTTP 프로토콜의 특징
* 클라이언트-서버 구조: HTTP는 클라이언트(브라우저)가 서버에 요청을 보내고, 서버가 응답하는 클라이언트-서버 구조를 기반으로 합니다.
* 무상태(Stateless): 각 요청은 독립적이며, 서버는 이전 요청에 대한 정보를 저장하지 않습니다.
* 비연결성(Connectionless): 한 번의 요청-응답이 이루어지면 연결이 끊어집니다.
* 단순성: HTTP는 비교적 간단한 구조로 되어 있어 구현하기 쉽고, 다양한 플랫폼에서 사용될 수 있습니다.
## HTTP 메서드
HTTP 메서드는 클라이언트가 서버에 요청하는 작업의 종류를 나타냅니다. 주요 HTTP 메서드는 다음과 같습니다.
* GET: 특정 자원을 요청합니다. (예: 웹 페이지 조회)
* POST: 서버에 새로운 데이터를 전송합니다. (예: 회원 가입, 게시글 작성)
* PUT: 특정 자원을 업데이트합니다.
* DELETE: 특정 자원을 삭제합니다.
## HTTP 상태 코드
HTTP 상태 코드는 서버가 클라이언트의 요청에 대해 어떻게 처리했는지를 나타내는 숫자 코드입니다.
* 200 OK: 요청이 성공적으로 처리되었습니다.
* 404 Not Found: 요청한 자원이 없습니다.
* 500 Internal Server Error: 서버에서 오류가 발생했습니다.
## HTTP와 HTTPS의 차이점
* HTTP: 일반적인 HTTP는 데이터를 암호화하지 않기 때문에 통신 내용이 도청될 위험이 있습니다.
* HTTPS: HTTPS는 HTTP에 SSL/TLS 암호화를 추가하여 데이터를 안전하게 보호합니다. 따라서 개인정보나 금융 정보를 다루는 웹사이트에서는 HTTPS를 사용하는 것이 필수적입니다.
## HTTP 버전
HTTP는 지속적으로 발전하고 있으며, 현재 주로 사용되는 버전은 HTTP/1.1과 HTTP/2입니다. HTTP/2는 HTTP/1.1보다 더 빠르고 효율적인 통신을 지원합니다.
## HTTP 요청 (HTTP Request)
클라이언트가 서버에 보내는 메시지를 의미합니다. 요청에는 요청 메서드, 요청 URL, 헤더, 본문 등이 포함됩니다.
* 요청 메서드: 수행하고자 하는 작업을 나타냅니다. (GET, POST, PUT, DELETE 등)
* 요청 URL: 요청하려는 자원의 위치를 나타냅니다.
* 헤더: 추가적인 정보를 제공합니다. (User-Agent, Accept 등)
* 본문: 서버로 전송할 데이터 (POST 메서드에서 주로 사용)
```
GET /products HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
```
## HTTP 응답 ( HTTP Response)
서버가 클라이언트에게 보내는 메시지를 의미합니다. 응답에는 상태 코드, 헤더, 본문 등이 포함됩니다.
* 상태 코드: 요청 처리 결과를 나타냅니다. (200 OK, 404 Not Found 등)
* 헤더: 추가적인 정보를 제공합니다. (Content-Type, Content-Length 등)
* 본문: 요청한 데이터
```
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>제품 목록</title>
</head>
<body>
</body>
</html>
```

View File

@@ -0,0 +1,47 @@
# HTTP 메서드
HTTP 메서드는 웹 서버에 요청을 보낼 때 수행하고자 하는 작업의 종류를 명시하는 명령어입니다. 각 메서드는 서버에 특정한 동작을 요구하며, 이를 통해 웹 애플리케이션의 다양한 기능을 구현할 수 있습니다.
## GET
특정 자원을 요청하여 읽기 위한 메서드입니다.
서버에 있는 데이터나 리소스를 가져오는 데 사용됩니다. 예를 들어, 웹 페이지를 조회하거나 이미지 파일을 다운로드할 때 사용합니다.
* 요청 URL에 파라미터를 포함하여 서버에 추가적인 정보를 전달할 수 있습니다.
* 요청 결과는 캐시될 수 있습니다.
안전한 메서드로 간주되어 데이터를 변경하지 않습니다.
## POST
서버에 새로운 데이터를 생성하기 위한 메서드입니다.
새로운 사용자를 등록하거나, 게시글을 작성할 때 사용됩니다.
* 요청 본문에 데이터를 포함하여 서버로 전송합니다.
* 데이터를 변경하기 때문에 안전하지 않은 메서드로 간주됩니다.
## PUT
특정 자원을 전체적으로 업데이트하기 위한 메서드입니다.
기존 자원을 완전히 새로운 데이터로 대체할 때 사용됩니다.
* 요청 본문에 새로운 데이터를 포함하여 서버로 전송합니다.
* 자원이 존재하지 않으면 새로 생성될 수도 있습니다.
## DELETE
특정 자원을 삭제하기 위한 메서드입니다.
더 이상 필요 없는 데이터를 삭제할 때 사용됩니다.
## PATCH
특정 자원을 부분적으로 업데이트하기 위한 메서드입니다.
특정 필드만 변경하고 싶을 때 사용됩니다.
* 요청 본문에 변경할 부분만 포함하여 서버로 전송합니다.
## HEAD
GET과 유사하지만, 응답 본문 없이 헤더 정보만 받아옵니다.
## OPTIONS
서버가 지원하는 HTTP 메서드를 확인합니다.
## CONNECT
HTTP를 통해 다른 프로토콜(예: HTTPS)을 사용하는 터널을 생성합니다.
## TRACE
요청 메시지를 그대로 서버로 보내고, 서버에서 받은 메시지를 그대로 클라이언트로 반환합니다.

View File

@@ -0,0 +1,31 @@
# 상태 코드
HTTP 응답 코드는 웹 서버가 클라이언트의 요청에 대해 어떻게 처리했는지를 알려주는 3자리 숫자 코드입니다. 이 코드는 요청의 성공 여부, 오류 발생 시 원인 등 다양한 정보를 담고 있어 웹 개발 과정에서 매우 중요한 역할을 합니다.
HTTP 응답 코드는 크게 다음과 같은 5가지 카테고리로 나눌 수 있습니다.
* 1xx (정보): 요청이 받아졌으며 처리가 계속되고 있음을 나타냅니다.
- 100 Continue: 서버가 요청을 받았으며, 클라이언트가 요청 본문을 보내도 된다는 의미입니다.
- 101 Switching Protocols: 프로토콜을 변경해야 한다는 의미입니다. (예: HTTP에서 WebSocket으로 전환)
* 2xx (성공): 요청이 성공적으로 처리되었음을 나타냅니다.
- 200 OK: 요청이 성공적으로 처리되었습니다.
- 201 Created: 새로운 자원이 생성되었습니다.
- 202 Accepted: 요청이 수락되었지만 아직 처리되지 않았습니다.
- 204 No Content: 요청은 성공했지만, 응답 본문에 내용이 없습니다.
* 3xx (리다이렉션): 요청을 완료하기 위해 추가적인 조치가 필요함을 나타냅니다.
- 301 Moved Permanently: 요청한 자원이 영구적으로 다른 URL로 이동했습니다.
- 302 Found: 요청한 자원이 임시로 다른 URL로 이동했습니다.
- 304 Not Modified: 요청한 자원이 변경되지 않았습니다.
- 307 Temporary Redirect: 302와 유사하지만, HTTP 메서드를 유지합니다.
* 4xx (클라이언트 오류): 클라이언트 측에서 오류가 발생했음을 나타냅니다.
- 400 Bad Request: 요청이 잘못되었습니다. (예: 잘못된 문법, 누락된 필드)
- 401 Unauthorized: 인증이 필요합니다.
- 403 Forbidden: 권한이 없습니다.
- 404 Not Found: 요청한 자원이 없습니다.
- 405 Method Not Allowed: 허용되지 않은 HTTP 메서드를 사용했습니다.
* 5xx (서버 오류): 서버 측에서 오류가 발생했음을 나타냅니다.
- 500 Internal Server Error: 서버에서 예상치 못한 오류가 발생했습니다.
- 502 Bad Gateway: 게이트웨이 또는 프록시 서버에서 잘못된 응답을 받았습니다.
- 503 Service Unavailable: 서버가 일시적으로 오버로드되거나 유지보수 중입니다.
- 504 Gateway Timeout: 게이트웨이 또는 프록시 서버가 타임아웃되었습니다.

View File

@@ -0,0 +1,38 @@
# HTTP 헤더
HTTP 헤더는 클라이언트(보통 웹 브라우저)와 서버 간의 통신에서 추가적인 정보를 주고받기 위해 사용되는 메타데이터입니다. HTTP 요청과 응답 메시지에 포함되어 있으며, 요청이나 응답의 내용, 전송되는 데이터의 형식, 캐싱 정보 등 다양한 정보를 담고 있습니다.
## HTTP 헤더의 역할
* 요청 헤더: 클라이언트가 서버에 요청할 때, 어떤 종류의 데이터를 원하는지, 어떤 브라우저를 사용하는지 등의 정보를 전달합니다.
* 응답 헤더: 서버가 클라이언트에게 응답할 때, 응답 데이터의 종류, 콘텐츠 길이, 캐싱 관련 정보 등을 전달합니다.
## HTTP 헤더의 종류
HTTP 헤더는 크게 다음과 같은 종류로 나눌 수 있습니다.
* General Header: 요청과 응답 모두에 사용되며, 메시지 자체에 대한 일반적인 정보를 포함합니다.
- Date: 메시지가 생성된 시간을 나타냅니다.
- Cache-Control: 캐싱 관련 지시를 포함합니다. (예: no-cache, max-age)
* Request Header: 요청 메시지에만 사용되며, 클라이언트에 대한 정보나 요청하는 리소스에 대한 정보를 포함합니다.
- User-Agent: 클라이언트(브라우저)의 종류와 버전 정보를 나타냅니다.
- Accept: 클라이언트가 수용할 수 있는 콘텐츠 형식(MIME type)을 나타냅니다.
- Accept-Language: 클라이언트가 선호하는 언어를 나타냅니다.
- Accept-Encoding: 클라이언트가 지원하는 인코딩 방식을 나타냅니다.
- Authorization: 인증 정보를 포함합니다.
- Cookie: 서버가 클라이언트의 브라우저에 저장한 쿠키 정보를 포함합니다.
- Referer: 현재 요청된 페이지의 이전 페이지 URL을 나타냅니다.
* Response Header: 응답 메시지에만 사용되며, 서버에 대한 정보나 응답 데이터에 대한 정보를 포함합니다.
- Content-Type: 응답 데이터의 형식(MIME type)을 나타냅니다.
- Content-Length: 응답 데이터의 크기를 바이트 단위로 나타냅니다.
- Last-Modified: 자원이 마지막으로 수정된 시간을 나타냅니다.
- ETag: 자원의 버전을 나타내는 문자열입니다.
Location: 리소스가 다른 URL로 이동했을 때 새로운 URL을 나타냅니다.
- Set-Cookie: 클라이언트의 브라우저에 새로운 쿠키를 설정합니다.
* Entity Header: 메시지 본문(entity-body)에 대한 정보를 포함합니다.
- Content-Encoding: 응답 데이터가 압축된 방식을 나타냅니다.
- Content-Language: 응답 데이터의 언어를 나타냅니다.
## HTTP 헤더의 활용
* 캐싱: Last-Modified, ETag 헤더를 이용하여 브라우저에서 자원을 캐싱하고, 불필요한 데이터 전송을 줄일 수 있습니다.
* 인증: Authorization 헤더를 이용하여 사용자를 인증하고, 권한을 부여할 수 있습니다.
* 콘텐츠 협상: Accept 헤더를 이용하여 클라이언트가 선호하는 콘텐츠 형식을 선택할 수 있습니다.
* 웹 크롤링: User-Agent 헤더를 변경하여 다른 브라우저처럼 행동할 수 있습니다.

View File

@@ -0,0 +1,46 @@
# 쿠키와 세션
웹 서핑을 하다 보면 자주 접하게 되는 용어인 쿠키와 세션은 웹 애플리케이션에서 사용자 상태를 관리하는 데 필수적인 요소입니다. 둘 다 사용자 정보를 저장하고, 이를 바탕으로 맞춤형 서비스를 제공하는 데 사용되지만, 저장 위치와 용도에 따라 차이점이 있습니다.
## 쿠키 (Cookie)
웹 서버가 클라이언트(웹 브라우저)에 보내는 작은 크기의 데이터 파일입니다. 클라이언트는 이 파일을 로컬 디스크에 저장하고, 이후 같은 서버에 요청을 보낼 때마다 함께 전송합니다.
### 특징
* 저장 위치: 클라이언트 측 (브라우저)
* 용도
- 사용자 식별 (로그인 상태 유지)
- 사용자 설정 저장 (테마, 언어 설정)
- 사이트 방문 기록 추적
- 장바구니 정보 저장
* 종류
- 세션 쿠키: 브라우저를 닫으면 자동으로 삭제됩니다.
- 영구 쿠키: 만료 날짜가 설정되어 해당 날짜까지 유효합니다.
### 장점
* 서버 부담 감소: 서버에 사용자 정보를 저장하지 않아 서버 자원을 절약할 수 있습니다.
### 단점
* 보안 취약성: 클라이언트 측에 저장되므로, 해킹이나 악성 코드에 노출될 위험이 있습니다.
* 용량 제한: 저장할 수 있는 데이터의 크기가 제한적입니다.
* 사용자의 프라이버시 침해 가능성: 사용자의 행동을 추적하는 데 악용될 수 있습니다.
## 세션 (Session)
사용자와 서버 간의 연결 상태를 유지하기 위한 일련의 상호 작용을 의미합니다.
### 특징
* 저장 위치: 서버 측
* 용도
- 사용자 세션 관리 (로그인 상태 유지, 장바구니 정보 관리)
- 사용자 활동 기록
* 작동 방식
- 서버는 각 사용자에게 고유한 세션 ID를 부여하고, 이를 쿠키를 통해 클라이언트에 전달합니다.
- 클라이언트는 이후 요청 시 세션 ID를 함께 보내고, 서버는 해당 ID를 통해 사용자 정보를 조회합니다.
### 장점
* 보안성 향상: 서버 측에 저장되므로 쿠키보다 보안성이 높습니다.
* 대용량 데이터 저장 가능: 쿠키보다 더 많은 양의 데이터를 저장할 수 있습니다.
### 단점
* 서버 부담 증가: 서버에 사용자 정보를 저장해야 하므로 서버 자원을 소모합니다.
* 세션 만료 문제: 세션 유효 시간이 지나면 사용자 정보가 사라질 수 있습니다.

40
doc/http/06_restful.md Normal file
View File

@@ -0,0 +1,40 @@
# RESTful
RESTful API는 웹 서비스를 설계하는 데 사용되는 아키텍처 스타일 중 하나입니다. Representational State Transfer의 약자로, HTTP 프로토콜을 기반으로 자원(resource)을 표현하고, 이 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 수행하는 방식을 의미합니다.
## 특징
* 자원 중심: 각각의 데이터는 자원(resource)으로 취급되며, URI(Uniform Resource Identifier)를 통해 고유하게 식별됩니다.
* HTTP 메서드 활용:
- GET: 자원 조회
- POST: 새로운 자원 생성
- PUT: 기존 자원 전체 업데이트
- DELETE: 자원 삭제
- PATCH: 자원 부분 업데이트
* Stateless: 각 요청은 독립적이며, 서버는 이전 요청에 대한 정보를 저장하지 않습니다.
* Client-Server: 클라이언트와 서버는 분리되어 있으며, 각자의 역할을 수행합니다.
* Cacheable: 응답을 캐싱하여 시스템 성능을 향상시킬 수 있습니다.
* Uniform Interface: 일관된 인터페이스를 제공하여 다양한 클라이언트에서 쉽게 사용할 수 있습니다.
## 장점
* 단순성: HTTP 프로토콜을 기반으로 하므로 이해하기 쉽고 구현하기 간편합니다.
* 확장성: 새로운 자원을 추가하거나 기존 자원을 수정하는 것이 용이합니다.
* 다양한 플랫폼 지원: HTTP 프로토콜을 지원하는 모든 플랫폼에서 사용 가능합니다.
* 캐싱: 응답을 캐싱하여 시스템 성능을 향상시킬 수 있습니다.
* RESTful API는 JSON 또는 XML 형식의 데이터를 주고받는 방식으로, 다양한 프로그래밍 언어와 플랫폼에서 쉽게 사용할 수 있습니다.
## 설계 시 고려 사항
* URI 설계: 자원을 명확하게 표현하고, 계층적인 구조를 유지합니다.
- URI의 마지막에는 '/'를포함하지 않습니다.
- 언더바(\_)는 사용하지 않습니다. 대신 하이픈(-)을 사용합니다.
- URI에는 행위(동사)가 아닌 결과(명사)를 포함합니다. 행위는 HTTP 메서드로 표현할 수 있어야 합니다.
- URI는 소문자로 작성해야 합니다.
- 파일의 확장자는 URI에 포함하지 않습니다. 대신 HTTP의 Accept 헤더를 사용하는 것이 좋습니다.
* HTTP 메서드 활용: 각 메서드의 의미를 정확하게 이해하고 적절하게 사용합니다.
* 응답 코드: HTTP 상태 코드를 활용하여 요청 결과를 명확하게 전달합니다.
* 에러 처리: 예외 상황 발생 시 적절한 에러 메시지를 반환합니다.
* 버전 관리: API 변경 시 버전을 관리하여 호환성 문제를 해결합니다.
## RESTful API를 사용하는 이유
* 다양한 클라이언트 지원: 웹 브라우저, 모바일 앱, IoT 장치 등 다양한 클라이언트에서 사용 가능합니다.
* 데이터 공유: 서로 다른 시스템 간에 데이터를 쉽게 공유할 수 있습니다.
* 마이크로서비스 아키텍처: 각 서비스를 RESTful API로 구현하여 시스템을 분산하고 확장성을 높일 수 있습니다.