HTTP

Client-Server

Client

• 터미널의 역할을 수행하는 컴퓨터로 웹 브라우저는 대표적인 터미널이다.
• 사용자의 입력을 주로 수행하며 서버에 대한 응답을 화면에 표시한다.
• 현대의 복잡한 시스템은 클라이언트와 서버의 역할을 동시에 수행하기도 한다

Server

• 서비스를 제공(server)하는 컴퓨터이며 다수의 클라이언트의 요청을 처리하기 위해 존재한다.
  (web server / file server 등...)
• 웹 페이지 지원이나, 공유 데이터의 처리,저장 등의 비즈니스 로직을 주로 수행한다.

Client-Server 커뮤니케이션

• Client-Server는 프로토콜(Protocol) 이라고 불리는 정해진 규약에 따라 메시지를 교환한다.

• 클라이언트는 API라는 추상화된 인터페이스를 바탕으로 원격 서버에 요청을 하고, 응답에 대해 적절한 형태로 화면에 표시한다.

Client-Server MESSAGING PATTERNS

• Request-Response
  대표적으로 HTTP 프로토콜이 사용하는 메시징 패턴으로
  보통 동기적으로 작동하며, 연결이 열리면 응답이 전달될떄까지 기다리거나, timeout 전달한다.
• 이외에도 다른 패턴이 존재하는데 우선 위 패턴을 살펴보자.

인터넷의 작동 원리는?

client & server

아래와 같이 작동한다.

• 브라우저 ➡️ HTTP Request URL + 요청메서드 ➡️ 서버
• 브라우저 ⬅️ HTTP Response 상태코드 + 응답body ⬅️ 서버

HTTP (HyperText Transfer Protocol)

데이터를 주고받을 수 있는 클라이언트와 서버 간 프로토콜(규약, 규칙)

HTTP 메시지

http 메시지는 항상 요청(request)과 응답(response)으로 이루어진다

1. start line : start line에는 요청이나 응답의 상태를 나타내며 항상 첫 번째 줄에 위치한다.
응답에서는 status line이라고 부른다.

2. HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합.

3. empty line : 헤더와 본문을 구분하는 빈 줄.

4. body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 하며 요청과 응답의 유형에 따라 선택적으로 사용합니다.

• 요청이나 응답의 헤드(head): start line과 HTTP headers
• payload : body

HTTP Requests 와 HTTP Response 메시지 상세

1. 작동방식

구분	요청 (Requests)	응답(Response)
start / status line	1. HTTP 메서드: 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST 등 2.가져오려는 리소스의 경로 (Path) : 예를 들면 프로토콜(http://), 도메인(developer.mozilla.org), TCP 포트(80)인 요소들을 제거한 리소스의 URL 3.HTTP 프로토콜의 버전	1. 현재 프로토콜의 버전(HTTP/1.1) 2.상태 코드 - 요청의 결과를 나타냅니다. (ex. 200, 302, 404 등) 3.상태 텍스트 - 상태 코드에 대한 설명
Headers	General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더. Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화한다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있다. Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더.	General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더. Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공. Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더.
body	요청의 본문은 HTTP messages 구조의 마지막에 위치. 모든 요청에 body가 필요하지 않다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용한다. body는 두 종류로 나눌 수 있다. 1.Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성된다. 2.Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지니며 보통 HTML form과 관련이 있다.	응답의 본문은 HTTP messages 구조의 마지막에 위치. 모든 응답에 body가 필요하지 않다. 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않다. 응답의 body는 다음과 같이 두 종류로 나눌 수 있다. 1.Single-resource bodies(단일-리소스 본문) : 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의한다. 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있다. 2.Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body 이다.

2. 구성

기본적으로 HTTP request와 response 모두 header와 body를 가진다.

header	body
- origin(어디서 보내는 요청인가?) - content-type(컨텐츠 타입은 무엇인가?) - user-agent(어떤 클라이언트를 이용해 보냈는가?) 등의 정보를 가진다.	- 서버에 데이터를 보내기 위한 공간으로 활용한다. - body에는 method들이 존재한다. ( GET, POST, PUT, DELETE, OPTIONS 등 )

MDN HTTP 헤더에 대한 자세한 내용은 👉️ 이곳 참고

Request & Response header (둘 다 사용하는 공통 헤더)

공통 헤더	Request & Response header
Date	HTTP 메시지가 만들어진 시각. 자동생성. (Date: Thu, 12 Jul 2018 03:12:27 GMT)
Connection	(Connection: keep-alive)
Cache-Control	중요 캐시관련!!! 참고
Content-Length	요청과 응답 메시지의 본문 크기를 바이트 단위로 표시 (Content-Length: 52)
Content-Type	컨텐츠의 타입(MIME)과 문자열 인코딩(utf-8 등등)을 명시 (Content-Type: text/html; charset=utf-8)
Content-Language	사용자의 언어
Content-Encoding	컨텐츠 압축 방식 (Content-Encoding: gzip, deflate)

Request header (요청 헤더)

요청 헤더	Request header
Host	서버의 도메인 네임이 나타나는 부분 (Host: www.zerocho.com)
User-Agent	현재 사용자가 어떤 클라이언트(운영체제와 브라우저 같은 것)를 이용해 요청을 보냈는지에 대한 정보 (User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36)
Accept	요청을 보낼 때 서버에 이런 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할 때 사용 (Accept: text/html image/png, image/gif)..
Authorization	인증 토큰(JWT든, Bearer 토큰이든)을 서버로 보낼 때 사용하는 헤더 (Authorization: Bearer XXXXXXXXXXXXX)
Origin	POST같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타내는 정보 요청을 보낸 주소와 받는 주소가 다르면 CORS 문제가 발생
Referer	이 페이지 이전의 페이지 주소 정보

• 이 중 Authorization 과 Origin 은 잘 알아두자.

3. 속성

• stateless : http의 각 요청은 모두 독립적이다.
  -> http 매 요청은 독립적 이기 때문에 state라는 것이 없다.
  즉, HTTP는 통신 규약일 뿐이므로, 상태를 저장하지 않는다.
  HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않는다.
  상태를 가지지 않으며 Stateless(무상태성)는 HTTP의 특징이다.

• connectionless : 한번의 요청에는 한번의 응답을 한다.
  -> 응답 이후에는 연결이 끊기기 때문에, 더이상 응답을 할 수 없다.

4. 요청 (request) 메서드

자세한건 MDN 참고
GET : 서버에 자원을 요청
GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.

POST : 서버에 자원을 생성 / 데이터를 서버로 제출하는 용도로 사용하며, 서버 상태의 변화를 일으킴
POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.

PUT : 서버의 자원을 수정 / POST와 비슷하나, 연속적인 요청시에도 같은 효과를 가져옴. 기존 데이터를 교체하는 용도로 쓰일 수 있음
PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.

PATCH
PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

DELETE : 서버의 자원을 제거
DELETE 메서드는 특정 리소스를 삭제합니다.

HEAD
HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.

OPTIONS
OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.

In CORS에서 프리플라이트 요청 (preflight, 사전 전달), 즉 사전 요청을 보내 서버가 해당 parameters를 포함한 요청을 보내도 되는지에 대한 응답을 줄 수 있게 한다.

CONNECT
CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.

TRACE
TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.

5. 응답 (response) 상태 (status) 코드

자세한건 MDN 참고
개발시 중요하므로 알아두자!

성공 상태 코드

• 200 - OK : GET 요청 성공
• 201 - CREATED : POST 요청의 성공
• 204 - NO CONTENT : DELETE 요청의 성공

• 304 - NOT MODIFIED: 반복된 요청 시 "이미 원하는 데이터 가지고 있어" 라고 알려주는 코드

클라이언트 오류 상태 코드

• 400 - BAD REQUEST : 잘못 된 요청시 발생
• 401 - UNATHORIZED : 인증되지 않은 경우 발생
• 403 - FORBIDDEN : 인증되었으나 컨텐츠에 접근할 권한 없음
• 404 - NOT FOUND : 요청받은 리소스를 사용할 수 없음, 해당 리소스 없음

서버 오류 상태코드

• 500 - INTERNAL SERVER ERROR: 서버가 처리할 수 없는 요청, (서버사망)

http로 제어할 수 있는 것

1. 캐시
2. origin제약사항 완화
3. 인증
4. 프록시와 터널링
5. 세션