Http 프로토콜

참고 - https://ko.wikipedia.org/wiki/HTTP

**HTTP(Hypertext Transfer Protocol)**는 웹에서 정보를 주고받기 위한 프로토콜로, 인터넷 상에서 서버와 **클라이언트(웹 브라우저)**가 어떻게 데이터를 주고받을지에 대한 규칙을 정의하고 있어. 이 프로토콜은 월드 와이드 웹(WWW)의 기초 기술 중 하나로, 우리가 웹 페이지를 보고, 데이터를 전송하는 방식에 직접적으로 관련돼 있어.

HTTP의 동작 방식

HTTP는 **요청(Request)**과 **응답(Response)**으로 구성된 클라이언트-서버 모델을 사용해. 웹 브라우저와 같은 클라이언트가 서버에게 특정 작업을 요청하면, 서버가 해당 요청을 처리하고 응답을 보내는 구조야. 예를 들어, 네가 브라우저에서 www.example.com 같은 URL을 입력하면, 브라우저는 이 웹 사이트에 접속하기 위해 HTTP 요청을 서버에 보내고, 서버는 웹 페이지의 데이터를 응답으로 반환해.

HTTP의 주요 특징

1. 비연결성(Connectionless)

• HTTP는 기본적으로 비연결성을 갖고 있어. 즉, 클라이언트가 서버에 요청을 보내고, 서버가 응답을 반환한 후, 그 연결은 바로 끊겨. 이렇게 매번 요청과 응답이 끝나면 연결이 종료되기 때문에 서버는 클라이언트의 상태를 기억하지 않아.

• 이 방식은 서버 자원을 절약하는 데 유리하지만, 매번 새로운 요청을 보낼 때마다 연결을 새로 맺어야 하므로, 같은 클라이언트로부터의 요청이라도 이전 연결 정보를 기억하지 않아.

2. 무상태성(Stateless)

• HTTP는 무상태성을 가지고 있어. 즉, 한 번 요청이 끝나면 서버는 클라이언트의 상태나 이전 요청을 기억하지 못해. 이 때문에 로그인 상태 유지나 사용자 정보 관리를 위해 쿠키(Cookie), 세션(Session) 같은 기술이 필요해.

• 무상태성은 서버가 각 요청을 독립적으로 처리할 수 있게 하지만, 클라이언트의 상태를 유지해야 하는 경우 추가적인 데이터 관리가 필요하게 돼.

3. 메시지 기반 통신

• HTTP는 텍스트 기반 프로토콜로, 요청과 응답 모두 **헤더(Header)**와 **본문(Body)**으로 구성된 메시지 형태로 데이터를 주고받아.

• 예를 들어, 클라이언트가 요청할 때 헤더에는 요청 방법(예: GET, POST), URL, 브라우저 정보가 포함되고, 본문에는 실제 데이터(예: 폼 데이터)가 담겨 있어.

• 서버의 응답도 마찬가지로 헤더에는 상태 코드(예: 200 OK), 응답 타입(예: HTML, JSON), 서버 정보가 포함되고, 본문에는 요청한 데이터(예: 웹 페이지 내용)가 들어 있어.

HTTP 요청 메서드 (HTTP Methods)

HTTP는 클라이언트가 서버에 요청을 보낼 때 다양한 요청 메서드를 사용해 요청의 종류와 목적을 구분해. 가장 흔한 메서드는 다음과 같아:

• GET: 서버에서 리소스(데이터)를 가져오기 위한 요청. 웹 페이지를 볼 때 주로 사용되며, 서버로부터 데이터를 받아와 브라우저에 표시해.

• 예시: 네가 www.example.com을 입력하면, 브라우저는 GET 요청을 통해 서버에 웹 페이지를 요청해.

• POST: 서버에 데이터를 전송하는 요청. 주로 웹 페이지의 폼 데이터를 전송하거나, 파일 업로드할 때 사용해. 서버는 이 데이터를 처리하고 결과를 반환해.

• 예시: 로그인 폼을 제출할 때, 사용자의 로그인 정보(ID, 비밀번호)가 POST 요청을 통해 서버로 전송돼.

• PUT: 서버에 존재하는 리소스를 수정할 때 사용해. 기존 데이터가 있으면 이를 갱신하거나 새롭게 추가해.

• 예시: 사용자가 자신의 프로필을 수정할 때 해당 데이터를 서버에 저장할 때 PUT을 사용할 수 있어.

• DELETE: 서버의 데이터를 삭제할 때 사용해.

• 예시: 사용자가 자신의 계정을 삭제하는 경우, 클라이언트는 DELETE 요청을 보낼 수 있어.

• HEAD: GET과 비슷하지만, 응답 본문을 제외하고 헤더 정보만 요청해. 주로 리소스의 존재 여부나 서버 상태를 확인하는 데 사용해.

• OPTIONS: 특정 리소스에서 사용할 수 있는 HTTP 메서드의 목록을 요청할 때 사용돼.

HTTP 상태 코드 (HTTP Status Codes)

서버는 클라이언트의 요청을 처리한 후, 그 결과를 상태 코드로 클라이언트에게 알려줘. 상태 코드는 요청이 성공했는지, 오류가 발생했는지 등을 알려주는 숫자야. HTTP 상태 코드는 크게 5개의 범주로 나뉘어:

1. 1xx (정보): 요청이 수신되었으며, 작업을 계속하고 있음을 나타냄.

• 100 Continue: 클라이언트가 요청을 계속할 수 있음.

2. 2xx (성공): 요청이 성공적으로 처리되었음을 나타냄.

• 200 OK: 요청이 성공적으로 처리되었고, 응답이 정상적으로 반환됨.

• 201 Created: 요청이 성공적으로 처리되었고, 새로운 리소스가 생성됨.

3. 3xx (리다이렉션): 요청한 리소스가 다른 곳으로 이동했음을 나타냄.

• 301 Moved Permanently: 요청한 리소스가 영구적으로 다른 URL로 이동함.

• 302 Found: 요청한 리소스가 일시적으로 다른 URL로 이동함.

4. 4xx (클라이언트 오류): 클라이언트의 요청에 오류가 있음을 나타냄.

• 400 Bad Request: 잘못된 요청(예: 문법 오류).

• 401 Unauthorized: 인증이 필요함.

• 404 Not Found: 요청한 리소스를 찾을 수 없음.

5. 5xx (서버 오류): 서버가 요청을 처리하는 중에 오류가 발생했음을 나타냄.

• 500 Internal Server Error: 서버에서 처리 중에 내부 오류가 발생함.

• 503 Service Unavailable: 서버가 현재 요청을 처리할 수 없는 상태임.

HTTP의 한계

HTTP는 데이터를 전송할 때 데이터를 암호화하지 않기 때문에 보안에 취약해. 네트워크 상에서 데이터를 가로채거나 변조하는 공격(예: 중간자 공격)이 발생할 수 있어. 이런 보안 문제를 해결하기 위해 HTTPS가 등장했어.

HTTPS (HTTP Secure)

HTTPS는 HTTP에 SSL/TLS(보안 소켓 계층/전송 계층 보안)를 추가해 데이터를 암호화해서 전송해. 이를 통해 서버와 클라이언트 간의 통신이 안전하게 이루어져, 중요한 정보(예: 비밀번호, 개인 정보 등)를 보호할 수 있어. HTTPS는 주로 금융 서비스, 로그인 페이지, 전자상거래 사이트 등 보안이 중요한 웹사이트에서 사용돼.

요약

• HTTP는 웹 상에서 클라이언트와 서버 간에 데이터를 주고받기 위한 기본 프로토콜이야.

• 비연결성과 무상태성을 가지고 있으며, 각 요청과 응답이 독립적으로 처리돼.

• GET, POST 같은 다양한 요청 메서드를 통해 데이터를 요청하거나 전송하고, 응답 상태는 200 OK, 404 Not Found 같은 상태 코드로 전달돼.

• 보안이 중요한 경우, 데이터를 암호화하는 HTTPS를 사용해.

HTML에서 경로나 URL에서 **/ (슬래시)**는 중요한 의미를 가지고 있으며, 경로의 위치를 나타내는 데 사용돼. 이를 이해하기 위해, 절대 경로와 상대 경로에서의 /의 의미를 살펴보자.

1. 절대 경로에서의 /

절대 경로는 웹 서버에서 루트 디렉토리(/, root directory)를 기준으로 경로를 나타내. 이 경우의 /는 웹 서버의 최상위 디렉토리를 의미해.

예시:

<a href="/images/logo.png">로고</a>

이 코드에서 /images/logo.png는 절대 경로야. /는 웹 서버의 루트 디렉토리를 의미하므로, images 폴더가 루트 디렉토리 아래에 있는 logo.png 파일을 가리키게 돼.

절대 경로의 특징:

• 웹 서버의 루트 디렉토리를 기준으로 경로를 설정.

• URL이 어느 페이지에 있어도 항상 같은 파일을 가리킴.

예를 들어, https://www.example.com/about 페이지에서 위의 <a> 태그가 있으면, 링크는 https://www.example.com/images/logo.png를 가리키게 돼.

2. 상대 경로에서의 /

상대 경로는 현재 문서의 위치를 기준으로 경로를 정의해. 상대 경로에서 **/**는 디렉토리 간의 경로 구분자 역할을 해.

예시 1 (현재 디렉토리 기준):

<a href="images/logo.png">로고</a>

이 경우는 상대 경로로, 현재 문서가 위치한 디렉토리에서 images 폴더 아래의 logo.png 파일을 찾게 돼.

예시 2 (상위 디렉토리로 이동):

<a href="../images/logo.png">로고</a>

이 코드는 현재 디렉토리의 상위 디렉토리로 이동한 후, 그 안의 images 폴더에서 logo.png 파일을 찾는다는 뜻이야.

3. URL에서의 /

URL에서 /는 경로를 나타내며, 각 디렉토리나 리소스의 구분자로 사용돼.

예시:

<a href="https://www.example.com/about/contact">Contact Us</a>

• https://www.example.com/ → 루트 경로

• /about/ → about 디렉토리

• /contact → about 디렉토리 내의 contact 리소스

요약:

• /는 절대 경로에서 웹 서버의 루트 디렉토리를 나타내며, 루트 경로를 기준으로 리소스를 찾음.

• 상대 경로에서 /는 디렉토리 간의 경로 구분자 역할을 함.

• URL에서 /는 각 디렉토리나 파일을 구분하는 데 사용됨.

**HTML(HyperText Markup Language)**과 **CSS(Cascading Style Sheets)**는 웹 개발의 기본적인 두 가지 기술이야. 이 둘은 함께 사용되어 웹 페이지를 구성하고 디자인하는 데 중요한 역할을 해. 각자의 역할을 구분해서 설명할게.

1. HTML (HyperText Markup Language)

HTML은 웹 페이지의 구조와 내용을 정의하는 마크업 언어야. 웹 페이지를 작성할 때 텍스트, 이미지, 링크, 비디오 등 다양한 요소를 정의하는 데 사용돼. HTML은 브라우저가 웹 페이지를 어떻게 구성할지 알려주는 기초 골격을 제공해.

HTML의 주요 특징:

• 콘텐츠의 구조를 정의: HTML은 웹 페이지에서 제목, 단락, 목록, 이미지, 링크 등을 정의해. 웹 페이지의 기본적인 내용과 그 내용을 어떻게 배치할지 결정해.

• **태그(tag)**를 사용: HTML은 각 요소를 정의하기 위해 태그를 사용해. 태그는 < > 안에 작성되며, 닫는 태그 </ >로 해당 요소의 끝을 명시해.

HTML의 구조:

HTML 문서는 기본적으로 태그들로 이루어져 있어. 몇 가지 주요 태그를 보면:

• <html>: 문서의 시작과 끝을 나타내는 최상위 태그.

• <head>: 메타데이터나 스타일시트, 스크립트와 같은 웹 페이지의 정보를 담고 있어.

• <title>: 웹 페이지의 제목을 정의하며, 브라우저 탭에 표시됨.

• <body>: 웹 페이지의 본문 콘텐츠를 담고 있는 태그. 사용자가 직접적으로 볼 수 있는 텍스트, 이미지, 링크 등이 여기에 포함돼.

HTML 예시:

<!DOCTYPE html>
<html>
  <head>
    <title>나의 첫 웹 페이지</title>
  </head>
  <body>
    <h1>환영합니다!</h1>
    <p>이곳은 나의 첫 HTML 웹 페이지입니다.</p>
    <a href="https://www.example.com">더 알아보기</a>
  </body>
</html>

• <h1>: 제목을 표시하는 태그.

• <p>: 단락을 표시하는 태그.

• <a>: 링크를 생성하는 태그. href 속성으로 이동할 URL을 지정.

2. CSS (Cascading Style Sheets)

CSS는 **HTML의 디자인(스타일)**을 정의하는 언어야. HTML이 웹 페이지의 구조와 내용을 제공한다면, CSS는 그 구조에 스타일을 입혀서 색상, 글꼴, 레이아웃 등을 제어해. CSS는 웹 페이지가 어떻게 보여야 할지 브라우저에게 알려주는 역할을 하지.

CSS의 주요 특징:

• 스타일 지정: HTML 문서의 각 요소에 대해 배경색, 글꼴 크기, 테두리, 여백 등을 지정할 수 있어.

• 레이아웃 관리: CSS를 사용해 요소들의 배치(예: 그리드, 플렉스박스 등)를 제어하고, 화면 크기에 따라 반응형 웹 디자인도 가능해.

• 분리된 스타일링: HTML과 스타일을 분리할 수 있어. 즉, 하나의 CSS 파일로 여러 HTML 문서의 스타일을 관리할 수 있기 때문에 유지보수도 용이해.

CSS의 적용 방식:

• 인라인 스타일: HTML 태그에 직접 스타일을 적용.

• 내부 스타일: HTML 문서의 <head> 태그 안에 <style> 태그를 사용해 정의.

• 외부 스타일시트: CSS 파일을 별도로 만들어 HTML 문서에서 <link> 태그로 연결.

CSS 예시:

/* 외부 CSS 파일 */
body {
  background-color: lightblue;
  font-family: Arial, sans-serif;
}

h1 {
  color: darkblue;
  text-align: center;
}

p {
  color: gray;
  font-size: 18px;
}

위 CSS를 적용하면, 웹 페이지의 배경이 lightblue가 되고, 제목(h1)은 darkblue 색상으로, 본문 단락(p)은 회색 글씨로 표시돼.

HTML과 CSS 함께 사용 예시:

<!DOCTYPE html>
<html>
  <head>
    <title>HTML과 CSS 예시</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <h1>CSS로 스타일 적용!</h1>
    <p>CSS를 사용하면 HTML에 스타일을 더할 수 있습니다.</p>
  </body>
</html>

위의 HTML은 **styles.css**라는 외부 스타일시트 파일을 불러와서 HTML 문서에 스타일을 적용해.

3. HTML과 CSS의 관계

• HTML은 웹 페이지의 구조를 정의하고, 콘텐츠를 표시하는 역할을 해.

• CSS는 그 구조를 디자인하고, 시각적인 스타일을 적용하는 역할을 해.

따라서 HTML이 웹의 뼈대라면, CSS는 그 뼈대를 꾸며주는 옷이라고 할 수 있어. HTML은 웹 페이지의 요소를 정의하고, CSS는 그 요소들이 화면에 어떻게 보일지를 정의해.

HTML과 CSS를 함께 사용할 때의 장점:

• 분리된 구조와 스타일: HTML과 CSS는 분리되어 있기 때문에, 유지보수나 디자인 변경이 쉬워져.

• 재사용 가능: 여러 HTML 파일에서 하나의 CSS 파일을 불러올 수 있어서 일관성 있는 디자인을 유지할 수 있어.

• 반응형 웹 디자인: CSS를 사용해 디바이스 화면 크기에 따라 레이아웃을 유연하게 변경할 수 있어.

**프록시(Proxy)**는 HTTP에서 중개 서버 역할을 하는 시스템이나 애플리케이션을 의미해. 클라이언트(예: 웹 브라우저)와 서버(예: 웹사이트) 사이에 위치하여 클라이언트의 요청을 서버에 전달하고, 서버의 응답을 클라이언트에 다시 전달하는 역할을 해. 즉, 프록시는 클라이언트와 서버 간의 중간자 역할을 하면서 네트워크 통신을 간접적으로 처리해.

프록시의 기본 개념

프록시는 클라이언트가 직접 서버에 접근하지 않고, 프록시 서버를 통해 요청을 전달함으로써 여러 가지 이점을 제공해. 프록시 서버는 여러 목적에 맞게 설정될 수 있으며, 다양한 방식으로 작동해.

프록시 서버의 주요 기능:

1. 프라이버시 보호:

• 클라이언트의 IP 주소를 서버로부터 숨길 수 있어. 서버는 프록시 서버의 IP 주소만 인식하므로, 클라이언트의 실제 IP 주소는 노출되지 않아.

2. 캐싱(Caching):

• 프록시 서버는 서버에서 가져온 데이터를 캐시하여, 동일한 요청이 들어올 경우 원본 서버 대신 프록시 서버가 응답을 제공함. 이를 통해 네트워크 대역폭을 절약하고 응답 속도를 개선할 수 있어.

3. 콘텐츠 필터링:

• 조직이나 학교, 회사에서는 프록시 서버를 사용해 특정 웹사이트에 대한 접근을 제한하거나, 불필요한 콘텐츠를 차단할 수 있어.

4. 보안 강화:

• 프록시는 클라이언트와 서버 간의 트래픽을 감시하거나, 악의적인 요청을 차단할 수 있어. 이를 통해 DDoS 공격방지 등 다양한 보안 기능을 제공할 수 있어.

5. 접근 제어:

• 특정 네트워크 환경에서 프록시 서버를 통해서만 인터넷에 접근하도록 제한할 수 있어. 이렇게 하면 관리자가 트래픽을 감시하거나 제한할 수 있어.

프록시 서버의 동작 원리

1. 클라이언트 요청:

• 클라이언트는 웹 브라우저에서 특정 웹 페이지에 접속하려고 할 때, 프록시 서버에 요청을 보내. 이 요청에는 사용자가 방문하려고 하는 서버의 URL이 포함돼.

2. 프록시 서버 처리:

• 프록시 서버는 클라이언트의 요청을 받아 원래 목적지 서버(예: 웹사이트)로 해당 요청을 대신 전송해. 이때, 프록시 서버는 요청을 캐시하거나 변경할 수 있어.

3. 서버 응답:

• 목적지 서버는 요청을 처리하고 응답을 프록시 서버로 전송해.

4. 프록시 서버 응답:

• 프록시 서버는 서버에서 받은 응답을 클라이언트에게 전달해. 이때 프록시 서버는 응답을 캐시에 저장해 나중에 동일한 요청이 들어왔을 때 더 빠르게 처리할 수 있어.

프록시 서버의 종류

1. 포워드 프록시(Forward Proxy):

• 일반적인 프록시 서버로, 클라이언트 측에 위치해. 클라이언트가 특정 웹사이트에 직접 접속하는 대신 프록시 서버를 통해 접속하는 방식이야.

• 사용자나 조직이 프라이버시를 보호하거나 콘텐츠를 차단할 때 주로 사용돼.

예시:

• 회사에서 직원들이 인터넷에 접속할 때, 포워드 프록시를 통해 외부 웹사이트에 접근하도록 설정할 수 있어.

2. 리버스 프록시(Reverse Proxy):

• 리버스 프록시는 서버 측에 위치해, 서버 앞단에서 클라이언트의 요청을 받아 처리해.

• 주로 로드 밸런싱, 보안 강화, 캐싱을 위해 사용돼. 클라이언트는 리버스 프록시가 서버인지 인식하지 못하고, 실제로 서버가 여러 대일 경우도 리버스 프록시를 통해 하나의 서버처럼 보이게 할 수 있어.

예시:

• 대형 웹사이트에서 리버스 프록시를 사용하여 여러 서버로 트래픽을 분산시키고, 서버 과부하를 방지할 수 있어.

프록시의 사용 사례

1. 회사 네트워크 보안:

• 많은 회사에서는 직원들이 프록시 서버를 통해서만 외부 웹사이트에 접속할 수 있도록 설정해. 이렇게 하면 보안을 강화하고 불필요한 사이트 접속을 차단할 수 있어.

2. 콘텐츠 차단:

• 학교나 공공 기관에서는 프록시 서버를 사용해 특정 웹사이트(예: 소셜 미디어, 성인 콘텐츠 등)를 차단할 수 있어.

3. 캐싱을 통한 성능 개선:

• ISP(인터넷 서비스 제공자)나 대규모 웹 서비스에서는 프록시 서버가 요청을 캐시하여 동일한 요청에 대해 더 빠른 응답을 제공해. 이렇게 하면 네트워크 성능을 최적화하고, 대역폭을 절감할 수 있어.

4. 익명성 보호:

• VPN이나 특정 서비스에서는 포워드 프록시를 통해 클라이언트의 실제 IP 주소를 숨기고, 인터넷 사용자의 익명성을 보호할 수 있어.

프록시와 HTTPS

HTTPS(HTTP Secure)는 클라이언트와 서버 간의 데이터를 암호화하는 프로토콜이기 때문에, 프록시 서버가 요청 내용을 쉽게 읽거나 수정할 수 없어. 하지만 프록시 서버는 HTTPS 요청도 처리할 수 있어. 이를 위해 MITM(Man-In-The-Middle) 프록시 같은 기술이 사용되며, HTTPS 트래픽을 암호 해제하고 다시 암호화해서 전송하는 방법을 사용해.

요약

• **프록시(Proxy)**는 클라이언트와 서버 사이에서 통신을 중개하는 역할을 하는 서버야.

• 포워드 프록시는 클라이언트가 서버에 접근할 때 중간에서 요청을 처리하고, 리버스 프록시는 서버가 클라이언트의 요청을 처리할 때 앞단에서 중개 역할을 해.

• 주요 기능으로는 프라이버시 보호, 캐싱, 콘텐츠 필터링, 보안 강화가 있어.

• 프록시는 기업, 학교, ISP 등에서 네트워크 보안을 강화하고 성능을 최적화하는 데 널리 사용돼.

프록시 서버를 이용하면 클라이언트와 서버 간의 데이터를 중개하는 동안 다양한 보안 및 최적화 기능을 추가할 수 있어.

HTTP의 Stateless(스테이트리스) 특성은 **“무상태성”**을 의미해. 이는 각 HTTP 요청이 서로 독립적이라는 것을 뜻해. 즉, 클라이언트가 서버에 요청을 보낼 때, 서버는 이전 요청과의 관계를 기억하지 않으며, 각 요청은 완전히 독립적인 상태로 처리돼.

HTTP Stateless의 의미:

1. 독립적인 요청:

• HTTP 요청은 서로 독립적이며, 서버는 클라이언트의 상태를 유지하지 않아. 클라이언트가 여러 번의 요청을 보낸다고 하더라도, 서버는 각 요청을 개별적으로 처리하며, 이전 요청이 무엇이었는지 기억하지 않아.

2. 상태 저장이 없음:

• 서버는 요청에 대한 상태 정보를 저장하지 않기 때문에, 각 요청에서 필요한 모든 정보를 클라이언트가 포함하여서버로 보내야 해. 예를 들어, 로그인된 상태로 계속 작업을 하려면, 매 요청마다 세션 토큰 또는 쿠키 같은 인증 정보를 함께 보내야 해.

3. 쉽게 확장 가능:

• HTTP의 무상태성 덕분에 서버는 각 요청을 독립적으로 처리할 수 있어, **수평적 확장(서버 추가)**이 용이해. 서버는 각 요청을 개별적으로 처리하기 때문에 여러 대의 서버로 요청을 분산할 수 있고, 그 결과 웹 애플리케이션이 쉽게 확장 가능해.

HTTP Stateless의 동작 예시:

• 사용자가 웹사이트에 로그인한 후 여러 페이지를 방문한다고 가정하자. HTTP가 스테이트리스하기 때문에, 사용자가 로그인한 후 각 페이지에 접근할 때마다 서버는 사용자가 로그인했는지 알지 못해. 이를 해결하기 위해, 세션 쿠키나 토큰을 사용해 각 요청에 인증 정보를 포함하여 서버에 전달하는 방식을 사용해.

예시 1: 로그인 요청

POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "username": "jinsu",
  "password": "mypassword"
}

서버는 사용자의 로그인 요청을 처리한 후 세션 토큰이나 쿠키를 발급할 수 있어. 그러나 서버는 상태를 저장하지 않기 때문에, 이후 모든 요청에 이 토큰이나 쿠키를 포함해야만 사용자의 로그인 상태를 유지할 수 있어.

예시 2: 로그인 후 페이지 요청

GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123

여기서 **쿠키(Cookie)**에 저장된 세션 정보를 통해 서버는 사용자가 로그인한 상태임을 확인하고, 적절한 데이터를 반환할 수 있어. 그러나 서버는 여전히 무상태성을 유지하고, 세션 정보 없이 다른 요청이 들어오면 클라이언트가 누군지 알지 못해.

Stateless의 장점:

1. 확장성: 서버는 각 요청을 독립적으로 처리하므로, 여러 서버에서 요청을 나눠서 처리하기가 쉬워. 따라서 대규모 트래픽을 처리할 수 있어.

2. 단순성: 서버가 클라이언트의 상태를 유지하지 않기 때문에, 복잡한 상태 관리를 하지 않아도 돼. 이는 서버 설계와 운영을 단순하게 만들어.

3. 빠른 복구: 서버가 상태를 유지하지 않기 때문에, 특정 서버가 문제가 생겨도 다른 서버가 동일하게 요청을 처리할 수 있어.

Stateless의 단점:

1. 클라이언트가 매번 인증 정보나 세션 데이터를 제공해야 함: 무상태성 때문에 매번 필요한 정보를 클라이언트가 서버에 보내야 해. 이로 인해 트래픽이 증가할 수 있어.

2. 복잡한 애플리케이션에선 추가적인 상태 관리 필요: 세션 유지가 필요한 애플리케이션에서는 세션이나 토큰을 사용해 클라이언트 상태를 관리해야 하는 부담이 추가됨.

상태를 유지하는 방법:

HTTP는 기본적으로 무상태지만, 세션 관리 또는 쿠키, 토큰을 통해 상태를 유지하는 방식이 많이 사용돼:

• 세션: 서버가 세션을 관리하고, 클라이언트가 세션 ID를 포함해 요청을 보낼 수 있어.

• 쿠키: 서버가 클라이언트에 쿠키를 설정해, 클라이언트가 쿠키를 통해 상태를 유지함.

• 토큰 기반 인증: 클라이언트가 로그인 시 발급받은 JWT 토큰 등을 통해 상태를 유지할 수 있어.

요약:

• HTTP는 기본적으로 Stateless(무상태). 즉, 서버는 각 요청을 독립적으로 처리하며 이전 요청의 상태를 기억하지 않아.

• 무상태성 덕분에 HTTP는 확장성이 뛰어나고, 여러 서버에 요청을 분산하기가 용이해.

• 하지만 상태가 필요한 애플리케이션에서는 세션, 쿠키, 토큰 등의 방법을 통해 상태를 유지해야 해.

이 무상태성 덕분에 HTTP는 단순하고 확장 가능한 프로토콜로 사용되고 있지만, 상태 유지가 필요한 경우 추가적인 방법을 사용해야 하는 점을 이해하면 돼.

**“HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다”**라는 말은, HTTP의 무상태성(Stateless) 특성을 극복하고, **쿠키(Cookie)**를 사용해 서버와 클라이언트 간의 상태를 유지하는 방법을 설명하는 거야.

HTTP의 무상태성(Stateless):

HTTP는 기본적으로 Stateless(무상태) 프로토콜이야. 즉, 서버는 클라이언트가 여러 번 요청을 보내도, 각 요청을 독립적으로 처리하고 이전 요청의 상태를 기억하지 않아. 예를 들어, 사용자가 로그인한 후 다른 페이지를 방문하더라도, 서버는 그 사용자가 로그인한 상태라는 것을 알 수 없어.

이런 무상태성 때문에, 클라이언트와 서버 간에 상태를 유지하는 방법이 필요하게 돼. 이때 HTTP 쿠키가 사용돼.

쿠키(Cookie)란?

쿠키는 클라이언트(브라우저)에 작은 데이터를 저장하고, 이 데이터를 통해 서버가 상태를 유지할 수 있도록 도와주는 역할을 해. 즉, 서버는 클라이언트의 상태 정보를 쿠키에 저장하고, 클라이언트가 다시 서버에 요청을 보낼 때 이 쿠키를 포함시켜서 서버가 이전 상태를 기억하도록 할 수 있어.

쿠키의 동작 원리:

1. 서버가 쿠키를 생성하고 클라이언트에 저장:

• 클라이언트가 서버에 로그인하면, 서버는 그 사용자를 식별하기 위해 세션 ID나 사용자 정보를 담은 쿠키를 생성해. 서버는 이 쿠키를 HTTP 응답 헤더를 통해 클라이언트에 전달하고, 클라이언트는 이 쿠키를 로컬에 저장해.

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Expires=Wed, 09 Jun 2024 10:18:14 GMT; Path=/

여기서 Set-Cookie는 서버가 클라이언트에게 쿠키를 저장하라고 명령하는 HTTP 헤더야. 쿠키는 session_id=abc123이라는 데이터를 담고 있어, 이는 클라이언트가 로그인한 상태를 추적하는 데 사용될 수 있어.

2. 클라이언트가 쿠키를 서버에 다시 전송:

• 클라이언트는 다음에 서버에 요청을 보낼 때, 저장된 쿠키를 HTTP 요청과 함께 서버에 전송해.

GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123

여기서 Cookie: session_id=abc123는 클라이언트가 서버에 보낸 요청에 포함된 쿠키 정보야. 이를 통해 서버는 클라이언트가 이전에 인증된 사용자인지 확인할 수 있어.

3. 서버가 쿠키를 이용해 상태를 유지:

• 서버는 요청에 포함된 쿠키를 통해 클라이언트가 이전에 인증된 사용자인지, 또는 특정 세션에 속하는 사용자인지를 알 수 있어. 이를 통해 사용자가 로그인 상태를 유지하거나 개인화된 콘텐츠를 제공할 수 있어.

쿠키를 사용한 상태 유지 예시:

1. 로그인 상태 유지:

• 사용자가 웹사이트에 로그인할 때, 서버는 세션 ID를 생성하고, 이를 쿠키로 클라이언트에게 전달해. 이후 클라이언트가 다른 페이지로 이동할 때마다 이 세션 ID가 서버로 전송되므로, 서버는 클라이언트가 여전히 로그인 상태임을 인식할 수 있어.

2. 장바구니 유지:

• 쇼핑몰 웹사이트에서, 사용자가 로그인을 하지 않고도 장바구니에 물건을 추가할 때 쿠키를 사용해 상태를 유지할 수 있어. 사용자가 페이지를 이동해도, 서버는 쿠키를 통해 사용자가 이전에 장바구니에 넣은 물건 정보를 기억할 수 있어.

3. 개인화된 경험 제공:

• 웹사이트는 쿠키를 사용해 사용자의 선호 설정(예: 테마, 언어 설정 등)을 저장하고, 클라이언트가 웹사이트를 재방문했을 때 이 설정을 적용해 개인화된 경험을 제공할 수 있어.

쿠키와 세션의 연관성:

쿠키와 **세션(Session)**은 밀접한 관계가 있어. 쿠키는 클라이언트 쪽에 저장되지만, 세션 정보는 주로 서버 쪽에서 관리돼. 세션 ID는 클라이언트의 쿠키에 저장되어 클라이언트가 서버에 다시 요청할 때마다 전송돼. 서버는 이 세션 ID를 통해 각 클라이언트의 상태를 확인하고, 로그인 상태나 사용자 데이터를 유지하는 데 사용해.

요약:

• HTTP는 무상태(Stateless) 프로토콜이기 때문에, 클라이언트의 상태를 기억하지 않아.

• **쿠키(Cookie)**는 클라이언트가 서버와의 통신에서 상태를 유지할 수 있게 해줌. 서버는 쿠키에 상태 정보를 저장하고, 클라이언트가 쿠키를 포함한 요청을 보낼 때 서버는 이를 통해 상태를 확인할 수 있어.

• 로그인 상태 유지, 장바구니 기능, 개인화된 사용자 경험 등 다양한 기능에서 쿠키가 중요한 역할을 해.

따라서, **“HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다”**라는 말은, 기본적으로 무상태인 HTTP 프로토콜에서 쿠키를 사용해 세션을 유지하고, 클라이언트의 상태를 기억하는 방법을 설명하는 거라고 할 수 있어.

HTTP/0.9는 1990년에 도입된 HTTP의 최초 버전으로, 웹 브라우저와 웹 서버 간의 기본적인 요청-응답 모델을 제공하는 매우 단순한 프로토콜이었어. 이 버전의 HTTP는 텍스트 기반이고, 오직 GET 요청만을 지원하며, 헤더가 없는 간단한 형태로 동작했어.

HTTP/0.9의 동작 원리

HTTP/0.9 동작 원리

클라이언트(브라우저)서버

브라우저에서 URL 입력 예: www.example.com	➡️	클라이언트의 요청을 대기 중
서버에 GET 요청 전송 GET /index.html	➡️	클라이언트의 GET 요청 수신
응답 대기	⬅️	HTML 문서를 응답으로 전송 <html>...</html>
HTML 문서를 수신하여 렌더링	⬅️	요청 처리 완료 후 연결 종료

HTTP/1.1 동작 원리

HTTP/1.1 동작 원리

클라이언트(브라우저)서버

브라우저에서 URL 입력 예: www.example.com	➡️	클라이언트의 요청 대기
서버에 GET 요청 전송 GET /index.html HTTP/1.1 헤더 포함 (Keep-Alive, Host)	➡️	클라이언트의 GET 요청 수신 헤더 처리
응답 대기	⬅️	HTML 문서 응답 전송 HTTP/1.1 200 OK 헤더와 콘텐츠 포함
HTML 문서를 수신하여 렌더링	⬅️	Keep-Alive로 연결 유지 가능

설명:

• HTTP/1.1에서는 헤더가 추가되고, 클라이언트와 서버가 헤더 정보를 주고받아 Keep-Alive로 연결을 유지할 수 있어. 따라서 여러 요청을 하나의 연결로 처리할 수 있는 기능이 도입됐어.

• 요청과 응답에 HTTP 상태 코드(예: 200 OK)가 포함되고, 헤더를 통해 더 많은 정보가 주고받아져.

HTTP/2 동작 원리

HTTP/2 동작 원리

클라이언트(브라우저)서버

브라우저에서 URL 입력 예: www.example.com	➡️	클라이언트의 요청 대기
서버에 GET 요청 전송 GET /index.html HTTP/2 멀티플렉싱 지원	➡️	요청 스트림 수신 헤더 압축 처리
응답 대기	⬅️	멀티플렉싱으로 여러 리소스 동시 응답 HTTP/2 200 OK
HTML, CSS, JS 등 여러 리소스 동시 수신	⬅️	헤더 압축 및 응답 완료 지속적인 연결 유지

설명:

• HTTP/2는 **멀티플렉싱(Multiplexing)**을 지원해서, 하나의 연결로 여러 리소스를 동시에 전송할 수 있어. 즉, HTML, CSS, JS 등 다양한 파일을 한꺼번에 전송하는 것이 가능해져 성능이 크게 향상됐지.

• 헤더 압축을 통해 데이터 전송량을 줄이고, 더 빠르게 응답을 처리할 수 있어.

• HTTP/2는 요청/응답의 병렬 처리와 성능 최적화를 위한 많은 기능을 제공해.

**HTTP 인증(Authentication)**과 **인가(Authorization)**는 웹 애플리케이션에서 중요한 개념이야. 이 두 개념은 클라이언트(사용자)가 웹 서버에 요청을 보낼 때, 그 사용자가 누구인지 확인하고, 그 사용자가 요청하는 리소스에 접근할 수 있는 권한이 있는지 결정하는 데 사용돼.

1. HTTP 인증 (Authentication)

인증은 클라이언트가 **“누구인지 확인하는 과정”**을 의미해. 서버는 클라이언트의 신원을 확인하기 위해 인증 절차를 요구할 수 있고, 사용자는 아이디와 비밀번호 같은 자격 증명을 통해 자신의 신원을 증명해.

인증의 주요 방법:

1. 기본 인증 (Basic Authentication):

• 클라이언트가 아이디와 비밀번호를 HTTP 요청 헤더에 Base64로 인코딩하여 서버에 전송하는 방식이야.

• 예시:

GET /private-page HTTP/1.1
Host: www.example.com
Authorization: Basic YWRtaW46cGFzc3dvcmQ=

여기서 Authorization: Basic YWRtaW46cGFzc3dvcmQ=는 admin:password를 Base64로 인코딩한 값이야. 서버는 이 값을 디코딩해 사용자의 자격 증명을 확인해.

• 보안 위험: 기본 인증은 암호화되지 않은 상태로 전송되기 때문에 TLS(HTTPS) 없이 사용하면 **중간자 공격(Man-in-the-middle attack)**에 취약해.

2. 다이제스트 인증 (Digest Authentication):

• 기본 인증의 보안 문제를 개선하기 위해 등장한 방식이야. 사용자 자격 증명을 해시(Hash) 방식으로 인코딩해서 서버에 전송해. 서버는 해시된 자격 증명을 확인함으로써 사용자를 인증해.

• 예시:

Authorization: Digest username="admin", realm="example.com", nonce="...", uri="/private-page", response="..."

• 해시된 값이 전송되기 때문에 중간에서 자격 증명을 훔쳐가도 유효한 비밀번호를 알아내기 어렵다는 점에서 보안이 강화돼.

3. 토큰 기반 인증 (Token-based Authentication):

• 세션과 쿠키를 사용하지 않고 인증을 유지하는 방식이야. 클라이언트가 로그인하면 서버에서 JWT(JSON Web Token) 같은 토큰을 발급받아, 이 토큰을 모든 요청에 포함시켜 인증하는 방식이야.

• JWT는 일반적으로 **헤더(Authorization: Bearer)**에 포함돼 전송돼:

GET /private-page HTTP/1.1
Authorization: Bearer <jwt_token>

• 이 방식은 확장성이 높고, 모바일 앱이나 API 인증에서 많이 사용돼.

4. OAuth:

• 사용자가 웹사이트나 애플리케이션에 로그인할 때, **다른 서비스(Google, Facebook 등)**를 통해 인증할 수 있게 해주는 방식이야.

• OAuth는 **액세스 토큰(access token)**을 발급해 클라이언트가 이 토큰을 통해 서버에 요청할 수 있게 해.

인증의 기본 흐름:

1. 클라이언트가 서버에 접근을 시도.

2. 서버는 인증이 필요함을 클라이언트에 알림.

3. 클라이언트가 **자격 증명(아이디/비밀번호, 토큰 등)**을 서버에 제출.

4. 서버는 클라이언트의 자격 증명을 확인하고, 올바른 경우 접근을 허가함.

2. HTTP 인가 (Authorization)

**인가(Authorization)**는 클라이언트가 인증된 후, 특정 리소스에 대한 접근 권한을 가지고 있는지를 결정하는 과정이야. 즉, **“무엇을 할 수 있는지”**를 판단하는 단계라고 할 수 있어.

• 인가는 클라이언트가 특정 작업(리소스에 접근, 수정, 삭제 등)을 수행할 권한이 있는지 서버에서 확인하는 과정이야.

• 인가는 인증 후에 이루어지며, 사용자가 누구인지(인증된 신원)에 따라 접근 권한을 제한하거나 허용할 수 있어.

인가의 주요 방식:

1. 역할 기반 접근 제어 (Role-based Access Control, RBAC):

• 사용자가 속한 **역할(관리자, 일반 사용자, 게스트 등)**에 따라, 리소스에 접근할 수 있는 권한을 설정하는 방식이야.

• 예를 들어, 관리자는 모든 데이터를 조회하고 수정할 수 있지만, 일반 사용자는 자신의 데이터만 조회할 수 있음.

2. 정책 기반 접근 제어 (Policy-based Access Control, PBAC):

• 특정 정책에 기반해 접근 권한을 부여하는 방식이야. 사용자의 속성(예: 부서, 직급 등), 환경(예: 시간대, 네트워크 상태) 등을 기준으로 접근을 제어할 수 있어.

3. OAuth와 인가:

• OAuth를 사용하면 사용자 권한을 제어할 수 있어. 사용자가 다른 서비스의 리소스에 접근할 수 있도록 토큰을 발급받았을 때, 이 토큰에 사용자의 권한 정보가 포함되어 있어. 이를 통해 사용자가 할 수 있는 작업을 제어할 수 있어.

인증과 인가의 차이:

• 인증(Authentication): “사용자가 누구인지 확인하는 과정”. 클라이언트가 자신의 신원을 서버에 증명.

• 인가(Authorization): “사용자가 무엇을 할 수 있는지 결정하는 과정”. 클라이언트가 특정 리소스에 대해 어떤 권한이 있는지 확인.

예시로 보는 인증과 인가:

1. 인증:

• 클라이언트가 웹사이트에 로그인할 때, 사용자 이름과 비밀번호를 입력하고 서버가 이를 확인해서 이 사용자가 누구인지 증명하는 과정이야.

2. 인가:

• 로그인 후, 사용자가 관리자 페이지에 접근하려고 하면, 서버는 이 사용자가 관리자 권한을 가지고 있는지 확인해서 권한이 있는지 없는지 결정하는 과정이야.

요약:

• 인증은 사용자가 누구인지 확인하는 과정이고, 인가는 사용자가 무엇을 할 수 있는지 결정하는 과정이야.

• 인증은 아이디와 비밀번호, 토큰, OAuth 등을 통해 이루어지며, 인가는 역할이나 정책을 기반으로 접근 권한을 부여해.

• 이 두 과정은 웹 애플리케이션에서 보안을 유지하는 데 필수적인 요소로 사용돼.

HTTP 인증과 인가를 제대로 이해하면, 웹 애플리케이션에서 사용자의 신원을 확인하고, 권한에 맞는 리소스에 접근하도록 제어할 수 있어.

'Network' 카테고리의 다른 글

Https 프로토콜 (3)	2024.09.27
CORS, WebSocket, 그리고 Base64 (6)	2024.09.27
UDP 소켓 프로그래밍 (0)	2024.09.26
TCP 소켓 프로그래밍 (0)	2024.09.26
네트워크 프로토콜 (4)	2024.09.26

HTTP/0.9 동작 원리

HTTP/1.1 동작 원리

HTTP/2 동작 원리

'Network' 카테고리의 다른 글

티스토리툴바