TIL) HTTP 특징, 요청(Request) & 응답(Response)에서 사용되는 헤더, 콘텐츠 협상 헤더

 

HTTP 역사

응용계층에 속하는 HTTP, 이는 웹 사이트를 이용하기 위해 사용한다. 

HTTP 역사

HTTP/ 1.1 ~ HTTP/2 는 TCP 기반 프로토콜,

HTTP/3 는 UDP 기반 프로토콜

 

 

---

HTTP 특징

• 클라이언트 서버 구조 = 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보낸다. 
• 무상태성 프로토콜 (stateless) = 서버가 클라이언트의  상태를 보존하지 않는다. (클라이언트가 기억해서 데이터 전송)

- 장점 : 서버 확장성 높음(스케일 아웃)

- 단점 : 클라이언트가 추가 데이터 전송,

로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우에는 무상태로 설계할 수 있지만, 로그인이 필요한 서비스라면 유저의 상태를 유지해야 하기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다. 

• 비연결성 (connectionless) = 연결을 유지하지 않는다. (실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다. 최소한의 자원으로 서버 유지를 가능하게 한다. )

- 장점 : 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동한다. 

- 단점 : 트래픽이 많고, 큰 규모의 서비스를 운영할 때는 비연결성에 한계가 나타난다. 

1. TCP/IP 연결시 (3 way handshake) 시간 추가

2. 웹 브라우저로 사이트를 요청하면 html, css, js 등 많은 자원이 함께 다운로드 된다. 

 

👉 HTTP 지속 연결(persistent connections) 로 문제 해결

연결이 이루어지고 난 뒤, 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다. 

• HTTP 메세지
• 단순함, 확장 가능

 

 

---

HTTP 메세지 ( HTTP 헤더 & 바디)

• HTTP 바디 : 데이터 메시지 본문을 통해 표현 데이터를 전달한다. (데이터를 실어나르는 부분 : 페이로드)

*표현은 요청이나 응답에서 전달한 실제 데이터를 뜻하며 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다. 

 

• HTTP 헤더 : HTTP 전송에 필요한 모든 부가정보를 담는다. 

ex) 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...

• HTTP 헤더 형식

<field-name> : <field-value>

(field-name은 대소문자 구분 없다. )

 

표현 헤더

• Content-Type : 표현 데이터의 형식 / 미디어 타입, 문자 인코딩
• Content-Encoding : 표현 데이터의 압축 방식 / 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가 & 데이터 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이 / 바이트 단위 / transfer-encoding 사용하면 content-length 사용하면 안된다. (transfer-encoding은 chunked 방식인데 많은 양의 데이터를 분할해서 보내기 때문에 전체 데이터의 크기를 알 수 없다. )

표현 헤더는 요청, 응답 둘 다 사용.

 

---

HTTP 주요 header

요청(Request)에서 사용되는 헤더

* From: 유저 에이전트의 이메일 정보

검색 엔진에서 주로 사용하고, 일반적으로 잘 사용하지 않는다. 

* Referer: 이전 웹 페이지 주소

현재 요청된 페이지의 이전 웹 페이지 주소,

a -> b 로 이동하는 경우, b를 요청할 때 Referer: a를 포함해서 요청한다. 

유입경로 수집 가능하다. 

* User-Agent: 유저 에이전트 애플리케이션 정보

어떤 종류의 브라우저에서 장애가 발생하는지 파악가능하다. 

통계 정보

 

* Host: 요청한 호스트 정보(도메인) / 필수 헤더

하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용한다. 

하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용한다. 

 

(Host 정보가 없다면 IP 주소만을 가지고 어떤 도메인으로 요청이 왔는지 확인하기 어렵다. )

* Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다. 

응답 헤더의 access-control-allow-origin 과 관련

* Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

토큰의 종류 + 실제 토큰 문자를 전송

 

ex) Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

---

응답(Response)에서 사용되는 헤더

* Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

* Date: 메시지가 발생한 날짜와 시간

* Location: 페이지 리디렉션

웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

201(created) : Location 값은 요청에 의해 생성된 리소스 URI

3xx(redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킨다. 

* Allow: 허용 가능한 HTTP 메서드

405(method not allowed)에서 응답에 포함

ex) Allow : GET, HEAD, PUT

* Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

 

503(service unavailable) : 서비스가 언제까지 불능인지 알려줄 수 있음

 

---

콘텐츠 협상 헤더 = 클라이언트가 선호하는 표현 요청

Accept : 클라이언트가 선호하는 미디어 타입 전달

Accept-Charset : 클라이언트가 선호하는 문자 인코딩

Accept-Encoding : 클라이언트가 선호하는 압축 인코딩

Accept-Language : 클라이언트가 선호하는 자연 언어 / 우선 순위 요청도 가능

if) 한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)이 적용되지 않았다면 서버는 요청으로 받은 우선순위가 없으므로 기본 언어로 설정된 영어로 응답한다.

if) 클라이언트에서 Accept-Language로 KO를 작성해 요청한다면 서버에서는 해당 우선순위 언어를 지원할 수 있기 때문에 한국어로 된 응답을 돌려준다.

 

* 협상 헤더는 요청시에만 사용

 

참고) 

 

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation

 

 

😃 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장에 큰 도움이 됩니다🤓