01. HTTP

---

🔨 1. HTTP의 역사

• HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜이다.

🔨 2. HTTP의 특징

🔧 2-1. 클라이언트 서버구조

• 클라이언트 : 서버에 요청을 보내고, 응답을 대기하면
• 서버 : 요청에 대한 결과를 만들어 응답한다.

🔧 2-2. 무상태 프로토콜(Stateless)

💡 HTTP는 무상태 프로토콜? : HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다.

• 장점 : 서버의 확장성이 높다(스케일 아웃)
• 단점 : 클라이언트가 추가 데이터를 전송한다.

1️⃣ 상태 유지 : 중간에 다른 점원으로 바뀌면 안됨

• 중간에 다른 점원으로 바뀔 경우 → 상태 정보를 해당 점원에게 미리 알려줘야 한다

2️⃣ 무상태 : 무상태에선 고객이 자신의 주문을 기억하고 있기 때문에 → 중간에 다른 점원으로 바뀌어도 된다.

• 따라서 갑자기 고객이 증가해도 점원을 대거 투입 가능하다

  *⇒ 즉 갑자기 클라이언트 요청이 증가해도 → 서버를 대거 투입할 수 있다.*

• 무상태는 응답 서버를 쉽게 바꿀 수 있는 장점이 있어 → 무한 서버 증설이 가능하다.

• 프로토콜 관점에서 본다면 → 무상태 프로토콜에선 클라이언트가 요청에 + 필요한 데이터를 담아서 보내기 때문에
  → 아무 서버나 호출해도 된다.
  ⇒ 따라서 응답서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능하다.

3️⃣ 무상태의 실무적 한계

• 무상태의 실무적한계는 모든 것을 무상태로 설계할 수 없음에서 온다.
• 로그인이 필요 없는(단순한 서비스 소개)화면에선 → 무상태 설계 가능
• 로그인이 필요한 서비스는 유저의 상태를 유지해야 함으로 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 → 상태를 유지해야 한다.

🔧  2-3. 비연결성(Connectionless)

• TCP/IP의 경우 기본적으로 연결을 유지한다.

  → 연결을 유지하는 모델에서는 클라이언트가 요청을 보내지 않더라고 계속 연결을 유지하기때문에 → 연결 서버의 자원이 계속적으로 소모된다는 문제가 있다.

• 비연결성을 가지는 HTTP 에서는 실제로 요청을 주고받을 때만 연결을 유지하고, 응답을 주고 나선 TCP/IP 연결을 끊는다.

  → 이를 통해 최소한의 자원으로 서버 유지를 가능하게 한다.

1️⃣ HTTP는 연결을 유지하지 않는 모델

• HTTP 1.0 기준으로, HTTP는 연결을 유지하지 않는 모델이다.
• 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우 → 비연결성의 특징은 효율적으로 작동한다.
• ex) 한 시간동안 수천명이 서버를 사용해도, 실제 서버에서 초당 처리 요청 개수는 수십개에 불과하다.
• 하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 땐 → 비연결성은 한계가 발생한다.

2️⃣ 비연결성의 한계와 극복

✓ 한계

1. TCP/IP 연결을 새로 맺어야 한다 → 3 way handshake 시간이 추가된다.

2. 웹 브라우저로 사이트를 요청하면 HTML 뿐 아니라 자바스크립트, CSS, 추가 이미지등 수많은 자원이 함께 다운로드 된다.

   → 해당 자원들을 각각 보낼 때마다 연결을 끊고 다시 반복하는 것은 비효울적이다.
   ✓ 극복

• 지금은 HTTP 지속 연결로 문제를 해결하고 있으며
• HTTP/2 ,HTTP/3에서 더 많은 최적화가 이뤄지고 있다.

3️⃣ HTTP 지속 연결

• HTTP 초기엔 → 각각의 자원을 다운로드하기위해 연결과 종료를 반복해야 했다면

연결 - 요청/HTML응답 - 종료 
요청/JS 응답 - 종료
.. 반복

• HTTP 지속 연결에서는 → 연결이 이뤄지면 각각의 모든 자원에 대한 요청, 응답이 돌아온 후 연결이 종료된다.

연결 -
요청/HTML응답 
요청/JS 응답
...
- 종료

02. HTTP Headers의 종류와 특징

---

🔨 1. 표현 헤더(Representation Headers)

표현헤더 === HTTP 헤더이다.

🔧 1-1. HTTP 헤더란

• HTTP 메세지는 헤더와 바디로 구분할 수 있다.

• HTTP 바디에는 데이터 메세지 본문(Message body)을 통해 표현(Representation) 데이터를 전달하는데

  → 여기서 데이터를 실어 나르는 부분을 페이로드(Payload)라고 한다.

즉 **메세지 본문** = **페이로드(Payload**)

• 표현은 : 요청이나 응답에서 전달한 실제 데이터를 뜻하며
• 표현헤더는 : 표현 데이터를 해석할 수 있는 정보를 제공한다.
  • 데이터 유형(html, json), 데이터길이, 압축 정보 등

🔧 1-2. HTTP 헤더 형식

• 헤더 형식은 : 대소문자 구분이 없다.
  

🔧 1-3. HTTP 헤더의 용도

• HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기위해 사용한다.
• 대표적인 부가정보 : 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시관리 정보 등

표현헤더의 구성요소

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

1. Content-Type : 표현 데이터의 형식

Content-Type **:** Text/html; charset=utf-8

미디어 타입, 문서 인코딩
- Text/html; charset=utf-8
- application/json
- Image/png

1. Content-Encoding : 표현 데이터의 압축 방식

Content-Encoding: gzip

표현 데이터를 압축하기 위해 사용하며
데이터를 전달하는 곳에서 압축 후 인코딩 헤어데 추가한다.
데이터를 읽는 족에선 인코딩 헤더의 정보로 압축을 헤제한다.
- gzip
- deflate
- identity

1. Content-Language : 표현 데이터의 자연 언어

Content-Language : ko

표현 데이터의 자연 언어를 표현한다.
- ko
- en
- en-US

1. Content-Length : 표현 데이터의 길이

Content-Length : 5

- 바이트 단위를 말하며
- **Content-Encoding** 대신 Transfer-Encording(전송 코딩)을 사용하는 경우엔 -> **Content-Length**를 사용하면 안된다.

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

1️⃣ From : 유저 에이전트의 이메일 정보

• 요청에서 사용
• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용

2️⃣ Referer: 이전 웹 페이지 주소

• 요청에서 사용
• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
• Referer를 사용하면 유입경로 수집 가능
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

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

• 요청에서 사용
• 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• e.g. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
  537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

4️⃣ Host: 요청한 호스트 정보(도메인)

• 요청에서 사용
• 필수 헤더
• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용

case1. Host 정보가 없을 경우
`GET/hello HTTP/ 1.1`
- IP주소만으로는 어떤 도메일으로 요청이 왔는지 확인 하기 어려움.

case2. Host 정보가 있는 경우
`GET/hello HTTP/ 1.1`
`Host : aaa.com`
- 서버가 가상 호스트를 통해 여러 도메인을 한번에 처리하고 있는 경우 HOST를 통해 요청한 도메인을 찾을 수 있다.

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

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• 응답 헤더의 Access-Control-Allow-Origin와 관련

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

• “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
• e.g. Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

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

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

• 응답에서 사용
• e.g.
  - Server: Apache/2.2.22 (Debian)
  - Server: nginx

2️⃣ Date: 메시지가 발생한 날짜와 시간

• 응답에서 사용
• e.g. Date: Tue, 15 Nov 1994 08:12:31 GMT

3️⃣ Location: 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

4️⃣ Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함
• e.g. Allow: GET, HEAD, PUT

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

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• e.g.
  - Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  - Retry-After: 120(초 단위 표기)

🔨 4. 콘텐츠 협상 헤더

콘텐츠 협상(Content negotiation)

• 클라이언트가 선호하는 표현 요청으로, 협상 헤더는 요청시에만 사용 가능하다.

Accept : 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset : 클라이언트가 선호하는 문자 인코딩
Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
Accept-Language : 클라이언트가 선호하는 자연 언어

1. Accept-Language 적용 전
서버는 요청으로 받은 우선순위가 없으므로 -> 기본언어로 설정된 영어로 응답한다.
2. Accept-Language 적용 후
클라이언트에서  Accept-Language로 KO를 작성해 요청한다면 -> 서버는 해당 우선순위 언어를 지원해 한국어로 응답을 돌려준다.
3. Accept-Language의 우선순위대로 요청을 하고 싶다면 -> 1부터 0순위까지 우선순위를 부여해 요청한다
- 0~1, 클수록 우선순위로, 생략하는 경우는 1이다.
`Accept-Language : ko-KR(;q=1 생략가능), ko;q=0,9, en-US;9= 0.8, en;q=0.7;`