HTTP - 헤더(1)

 

1. HTTP 헤더의 역할

HTTP 전송에 필요한 클라이언트와 서버 간의 요청 및 응답을 구체화하고, 데이터 형식, 인증, 연결 관리 등과 같은 부가 정보를 제공한다.

 

2. HTTP 요청 예시

예) www.example.com 웹 서버에 대한 HTTP POST 요청

✔️표현 헤더

- 표현 데이터를 해석할 수 있는 정보를 제공한다.

 

✔️메시지 본문

- 표현 데이터를 전달

 

3. 표현 헤더

데이터의 처리 방식과 관련된 중요한 정보를 제공한다.

 

✔️Content-Type

- HTTP 메시지 본문의 미디어 타입을 지정

- 예를 들어, 'text/html;charset=utf-8', 'application/json', 'image/jpeg' 등이 있다.

이를 통해 서버와 클라이언트는 본문 내용을 어떻게 해석할 지 알 수 있다.

 

✔️ Content-Encoding

- 메시지 본문이 어떤 방식으로 인코딩되었는지를 나타낸다.

- 데이터를 전달하는 곳에서 압축하여 전송 효율을 높이기 위해 사용한다.

- 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제한다.

- 예) gzip, compress, deflate

 

✔️ Content-Language

- 메시지 본문의 자연어를 지정한다. 

- 'en-US, ko, en'등으로 표현한다.

 

✔️ Content-Length

- 메시지 본문의 길이를 바이트 단위로 나타낸다.

- 본문 데이터를 어디까지 읽어야 하는지를 클라이언트나 서버가 알 수 있게 해준다.

- Transfer-Encoding(전송코딩)을 사용하면 Content-Length를 쓰면 안된다.

 

 

4. 협상 헤더

클라이언트가 서버로부터 어떤 형태의 데이터를 받고 싶은지 서버에 알려주는 역할(요청 시에만 사용)

 

1) 종류

✔️Accept

- 클라이언트가 처리할 수 있는 미디어 타입 (콘텐츠 유형)을 서버에 알린다.

- 예시) text/html, application/xml, image/jpeg

 

✔️Accept-Charset

- 서버가 클라이언트에게 해석할 수 있는 인코딩 형태로 응답할 수 있도록 문자 인코딩 집합을 명시한다.

- 예시) utf-8, iso-8859-1

 

✔️Accept-Encoding

- 클라이언트가 지원하는 콘텐츠 인코딩 방식을 서버에 알리는 헤더

-> 서버는 이 헤더에 따라 적절한 인코딩으로 응답을 압축하여 전송한다.

- 예시) gzip, deflate, br

 

✔️Accept-Language

- 클라이언트가 선호하는 자연어(언어)를 서버에 통보

-> 서버는 이 정보를 기반으로 사용자에게 적합한 언어의 콘텐츠를 제공한다.

- 예시) en-US, ko-KR

 

2) 우선순위 Quality Values(q)

: 클라이언트가 서버에게 자신의 선호도를 숫자로 표현하여 전달할 수 있다.

선호도는 0.0에서 1.0 사이의 값을 가진다.

기본 값은 1.0으로 지정을 하지 않으면 가장 높은 선호도로 간주된다.

또한, 더 구체적으로 지정된 것이 우선시 된다.

 

✅선호도 예시

Accept: text/html;q=0.8, application/xhtml+xml, application/xml;q=0.9, */*;q=0.5

application/xhtml+xml를 가장 선호하고 (기본값 1.0), application/xml은 0.9, text/html은 0.8, 그리고 그 외의 모든 유형은 0.5의 우선순위를 가진다.

 

✅구체적 지정 예시

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, */*;q=0.5

우선순위

text/html;level=1   >   text/html   >    text/*   > */*

• text/html;level=1은 가장 구체적인 지정으로, 특정 수준의 HTML 문서를 요구한다.
• text/html은 text/*보다 더 구체적인 HTML 문서를 의미한다.
• text/*는 모든 종류의 텍스트 문서를 포괄하지만, 특정성이 낮다.
• */*는 모든 유형의 문서를 수용하지만, 가장 낮은 구체성을 가진다.

5. 전송 방식

1) 단순 전송

▪️ 가장 기본적인 데이터 전송 방식.

▪️ 클라이언트가 요청을 하면 서버가 전체 데이터를 한 번에 응답으로 보내는 방식.

▪️ 별도의 전송 코딩이나 범위 지정이 없다.

 

✅단순 전송 요청 예시

GET /index.html HTTP/1.1
Host: example.com

 

✅단순 전송 응답 예시

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

[HTML 파일 전체 내용]

 

2) 압축 전송

▪️ 데이터를 압축하여 전송하는 방식

▪️ 네트워크 대역폭을 절약하고 전송 속도를 높일 수 있다.

▪️ Content-Encoding 헤더를 사용하여 데이터가 어떤 방식으로 압축되었는지 명시해야한다.

 

✅압축 전송 요청 예시

GET /data.json HTTP/1.1
Host: example.com
Accept-Encoding: gzip

 

✅압축 전송 응답 예시 

HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: gzip
Content-Length: 456

[압축된 JSON 데이터]

 

3) 분할 전송

▪️  서버가 데이터를 일정한 크기의 청크(chunk)로 나누어 전송하는 방식

▪️  주로 데이터 크기를 미리 알 수 없거나 동적으로 생성되는 데이터를 전송할 때 사용

▪️ 각 청크의 길이는 16진수로 인코딩되어 있으며, 마지막 청크는 길이가 0인 청크로 표시

▪️ 분할 전송할 때는 content-length를 보내면 안된다.(길이 예상이 안되니까.) 

▪️ \r \n은 줄바꿈 문자다.

 

✅분할 전송 예시

HTTP/1.1 200 OK
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

 

4) 범위 전송

▪️ 클라이언트가 요청한 데이터의 특정 범위만 전송하는 방식

▪️ 대용량 파일의 일부분만 필요할 때 유용

▪️ 클라이언트는 Range 헤더를 사용하여 원하는 범위를 지정하고, 서버는 Content-Range 헤더를 사용하여 응답

 

✅범위 전송 요청 예시

GET /largefile.zip HTTP/1.1
Host: example.com
Range: bytes=500-999

 

✅범위 전송 응답 예시

HTTP/1.1 206 Partial Content
Content-Type: application/zip
Content-Range: bytes 500-999/2000
Content-Length: 500

[파일의 500번째 바이트부터 999번째 바이트까지의 내용]

 

6. 일반 정보

✔️ From

요청을 보낸 사용자의 이메일 주소.

일반적으로 잘 사용되지 않는다.

 

✔️ Referer

현재 요청된 페이지로 사용자를 안내한 이전 웹 페이지의 URL

서버는 사용자가 어떤 경로를 통해 현재 페이지에 도달했는지 알 수 있다.

주로 분석 목적으로 사용한다.

 

✔️ User-Agent

요청을 보낸 클라이언트 소프트웨어에 대한 정보.

브라우저의 종류, 운영 체제, 브라우저 버전 등이 포함된다.

💡특정 브라우저에서만 버그가 생긴다면, 로그를 파싱해보면 어떤 종류의 브라우저에서 장애가 발생하는 지 알 수 있다! 

 

✔️ Server

응답을 생성한 서버 소프트웨어에 대한 정보를 제공.

 

✔️ Date

메시지가 생성된 날짜와 시간을 포함.

 

7. 특별한 정보

✔️Host

클라이언트가 요청을 보낼 때 사용되는 서버의 호스트명과 포트 번호를 지정.

💡필수헤더다!! 왜냐하면, 가상호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버일 수 있기 때문이다.(애플리케이션 여러개 구동)

 

✅예시

Host: www.example.com:8080

 

✔️Location

주로 리다이렉션 응답(상태 코드 3xx)과 함께 사용되어 클라이언트를 새 URL로 안내.

201(Created)응답과 함께 사용되었다면, 요청에 의해 생성된 리소스 URI다.

 

✅예시

HTTP/1.1 301 Moved Permanently
Location: http://www.example.com/newpage

 

✔️Allow

주로 405 Method Not Allowed 응답과 함께 사용되며, 서버가 허용하는 메서드들을 명시한다.

 

✅예시

Allow: GET, POST, PUT

 

✔️Retry-After

서버가 현재 요청을 처리할 수 없지만 일정 시간 후에 다시 시도할 수 있음을 알린다.

주로 503 Service Unavailable 또는 429 Too Many Requests 응답과 함께 사용된다.

 

✅예시

Retry-After: Wed, 15 May 2024 12:34:56 GMT

 

8. 인증

✔️Authorization

클라이언트 인증 정보를 서버에 전달.

클라이언트가 특정 리소스에 접근할 권한이 있는지 판단하는 역할.

 

✅Basic 인증 예시

Base64로 인코딩된 사용자 이름과 비밀번호를 사용한다.

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

 

✅Bearer 토큰 인증 예시

주로 OAuth2.0에서 사용한다. 서버에 접근할 수 있는 토큰을 제공.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

 

✅Digest 인증 예시

비밀번호를 해시하여 보냄으로써 보안 수준을 높인다.

Authorization: Digest username="admin", realm="example", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

• username : 클라이언트의 사용자 이름
• realm : 보호된 리소스의 영역. 서버가 관리하는 리소스 집합에 대한 이름
• nonce : 서버가 임의로 생성한 문자열. 한번만 사용되는 값이다.
• uri :  클라이언트가 요청하는 리소스의 URI
• response : 클라이언트가 생성한 응답 해시 값. 이를 통해 클라이언트가 올바른 자격 증명을 가지고 있는지 확인한다.
• opaque : 서버가 클라이언트에게 전달하는 임의 문자열. 클라이언트와 서버 간 세션을 식별하거나 인증 과정 무결성 유지에 사용된다.

 

✔️WWW-Authenticate

서버가 클라이언트에게 인증을 요청할 때 사용.

리소스 접근시 필요한 인증 방법 정의.

401 Unauthorized응답과 함께 사용.

 

✅Basic 인증 요청 예시

서버가 클라이언트에게 사용자 이름과 비밀번호를 제공하도록 요구

WWW-Authenticate: Basic realm="User Visible Realm"

 

✅Bearer 인증 요청 예시

서버가 클라이언트에게 Bearer 토큰을 제공하도록 요구

WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="The access token expired"

 

✅Digest 인증 요청 예시

서버가 클라이언트에게 해시된 자격 증명을 제공하도록 요구

WWW-Authenticate: Digest realm="example", qop="auth", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"

 

9. 쿠키

1) 쿠키란 무엇인가?

HTTP는 무상태 프로토콜이라, 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.

클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.

그래서 클라이언트와 서버 간의 상태 정보를 유지하기 위해 사용되는 것이 '쿠키'!!

웹브라우저 내부에는 쿠키 저장소가 있다. 

Set-Cookie로 받은 정보를 쿠키 저장소에 저장해놓고, 클라리언트가 로그인 이후 다시 페이지에 접근(HTTP 요청)하면 쿠키 저장소에서 조회한 값을 서버로 전달한다.

단, 보안에 민감한 정보는 저장하면 안된다.(신용카드 정보, 주민번호 등)

 

2) 사용처

- 사용자 로그인 세션 관리

- 광고 정보 트래킹

 

3) 쿠키정보는 항상 서버에 전달된다.

- 네트워크 트래픽 추가 유발

- 최소한의 정보만 사용해야한다. ( 세션 id, 인증 토큰 )

- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 localStorage, sessionStorage를 사용.

 

✔️Set-Cookie

서버에서 클라이언트로 쿠키 전달(응답)

사용법: Set-Cookie: <쿠키이름>=<값>; 옵션

 

✅Set-Cookie 예시 

Set-Cookie: sessionId=abc123; Max-Age=3600; HttpOnly; Secure

 

✔️Cookie

클라이언트가 서버에서 받은 쿠키를 저장, HTTP 요청시 서버로 전달

사용법: Cookie: <쿠키이름>=<값>; <쿠키이름2>=<값2>;

 

✅Cookie 예시 

Cookie: sessionId=abc123; theme=light; rememberMe=true

rememberMe는 사용자 로그인 상태를 유지하는 쿠키

 

4) 쿠키 옵션

✔️Expires

쿠키의 만료 날짜와 시간을 지정. 이 시간이 지나면 쿠키는 자동 삭제된다.

만료 날짜를 생략하면 브라우저 종료시 까지만 유지된다.

 

✅Expires 예시 

Set-Cookie: username=John; Expires=Wed, 21 Oct 2024 07:28:00 GMT

 

✔️Max-Age

쿠키의 유효기간을 초 단위로 지정. 이 시간이 지나면 쿠키는 자동 삭제된다.

 

✅Max-Age 예시 

Set-Cookie: sessionId=abc123; Max-Age=3600

 

✔️Domain 

쿠키가 전송될 도메인을 지정. 쿠키는 설정된 도메인과 하위 도메인에 대해 전송된다.

생략하면, 쿠키가 하위 도메인에 전송되지 않는다.

 

✅Domain 예시 

Set-Cookie: sessionId=abc123; Domain=example.com

 

✔️Path

쿠키가 전송될 경로 지정. 쿠키는 설정된 경로와 그 하위 경로에 대해 전송된다.

일반적으로 'path=/루트'로 지정한다.

 

✅Path 예시 

Set-Cookie: sessionId=abc123; Path=/users

 

✔️Secure

쿠키가 HTTPS 연결을 통해서만 전송되도록 한다.

 

✅Secure 예시 

Set-Cookie: sessionId=abc123; Secure

 

✔️HttpOnly

클라이언트의 JavaScript 코드에서 쿠키에 접근할 수 없도록 한다.

XSS 공격을 방지한다.

HTTP 전송에만 사용한다.

 

✅HttpOnly 예시 

Set-Cookie: sessionId=abc123; HttpOnly

 

✔️SameSite

쿠키가 사이트 간 요청에서 전송되는 방식을 제어. 

요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송을 할 때 사용한다.

CSRF 공격을 방지하는 데 도움이 된다.

(*CSRF공격은 사용자가 의도하지 않은 요청을 다른 웹사이트에 보내게 하여 사용자의 권한으로 비정상적인 동작을 수행하게 만든다.)

 

✅SameSite 예시 

Set-Cookie: sessionId=abc123; SameSite=Strict