0524, 0629 HTTP

이인우·2023년 5월 24일

1. HTTP ?

✔️ HTTP Messages

HTTP Messages는 클라이언트와 서버 사이에서 데이터가 교환되는 방식을 의미하며 요청(Request), 응답(Response) 2가지 유형이 있습니다. HTTP Messages는 몇 줄의 텍스트 정보로 구성되며, 구성파일 • API • 기타 인터페이스에서 자동으로 완성합니다.

요청과 응답 구조

[그림] HTTP Message 구조 (출처 : 코드스테이츠)

start line : start line에는 요청이나 응답의 상태를 나타내고, 항상 첫 번째 줄에 위치하며 응답에서는 status line이라고 부름
HTTP Headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
empty line : 헤더와 본문을 구분하는 빈 줄 존재
body : 요청과 관련된 데이터나 응답과 관련된 데이터 or 문서 포함, 요청과 응답의 유형에 따라 선택적 사용

Stateless

상태를 가지지 않는다는 뜻이며 HTTP로 클라이언트와 서버가 통신을 주고받는 과정에서, HTTP가 클라이언트나 서버의 상태를 확인하지 않습니다. 즉, 클라이언트에서 발생한 모든 상태를 HTTP 통신이 추적하지 않습니다. 이때 필요에 따라 쿠키-세션, API 등과 같은 방법을 이용해 상태를 확인할 수 있습니다.

✔️ HTTP Requests

클라이언트가 서버에 보내는 메시지를 의미하며 Start line에 3가지 요소가 있습니다.

수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냅니다.
요청대상(URL, URI) 혹은 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다. 이 요청은 HTTP method 마다 다릅니다.
- origin : '?'와 쿼리 문자열이 붙는 절대 경로입니다. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용합니다.
  
  ㉠ POST / HTTP 1.1
  ㉡ GET /background.png HTTP/1.0
  ㉢ HEAD /test.html?query=alibaba HTTP/1.1
  ㉣ OPTIONS /anypage.html HTTP/1.0
- absolute : 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 사용합니다.
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
- authority : 도메인 이름과 포트 번호로 이루어진 URL 일부이며 HTTP 터널을 구축하는 경우 CONNECT와 함께 사용합니다.
CONNECT developer.mozilla.org:80 HTTP/1.1
- asterisk : OPTIONS와 함께 별표(*)로 서버 전체를 표현합니다.
OPTIONS * HTTP/1.1
HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력합니다.

요청의 Headers는 기본 구조를 따르며, 헤더 이름(대소문자 구분 없는 문자열), 클론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
Request headers : fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다. Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.

요청의 본문(Body)은 HTTP Messages 구조의 마지막에 위치하며, 모든 요청에 body가 필요하지는 않습니다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다. POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.

Single-resource bodies(단일-리소스 본문) : 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
Multiple-resource bodies(다중-리소스 본문) : 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다. 보통 HTML form과 관련이 있습니다.

✔️ HTTP Responses

서버가 클라이언트에게 보내는 메시지를 의미하며, 응답의 첫 줄을 Status line이라고 부릅니다.

현재 프로토콜의 버전(HTTP/1.1)
상태 코드 - 요청의 결과를 나타냅니다. (ex. 200, 302, 404 등)
상태 텍스트 - 상태 코드에 대한 설명

응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있습니다. 대소문자 구분 없는 문자열, 콜론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다.

General headers : 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
Response headers : 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
Representation headers : 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.

응답의 본문은 HTTP messages 구조의 마지막에 위치합니다. 모든 응답에 body가 필요하지는 않습니다. 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다.

Single-resource bodies(단일-리소스 본문) :
- 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩 되어 있습니다.
Multiple-resource bodies(다중-리소스 본문) : 서로 다른 정보를 담고 있는 body입니다.

06.29

2. HTTP (심화)

✔️ 패킷교환 방식

패킷교환 방식은 패킷이라는 단위로 데이터를 잘게 나누어 전송하는 방식이며, 각 패킷에는 출발지, 목적지 정보가 있고 이에 따라 패킷이 목적지를 향해 가장 효율적인 방식으로 이동할 수 있습니다. 때문에 특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적으로 데이터를 전송할 수 있습니다.

그래서 인터넷 프로토콜, 줄여서 IP는 출발지와 목적지의 정보를 IP 주소라는 특정한 숫자값으로 표기하고 패킷단위로 데이터를 전송하게 되었습니다.

😀 IP / IP Packet

복잡한 인터넷 망 속 수많은 노드 (서버 컴퓨터)를 지나 클라이언트와 서버가 통신하기 위해 규칙이 필요한데, 이때 IP 주소를 컴퓨터에 부여하여 통신합니다. IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달을 합니다.

IP 패킷에서 패킷은 pack 과 bucket이 합쳐진 단어 즉, 소포에 비유할 수 있고, IP 패킷은 이를 데이터 통신에 적용한 것입니다. IP 패킷은 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있습니다.

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달하며 이를 통해 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있습니다. 서버 역시 IP 패킷을 이용해 클라이언트에 응답을 전달합니다.

😱 IP의 한계

비연결성

만약 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기에 패킷을 그대로 전송하게 됩니다.
비신뢰성

패킷이 중간에 소실될 수 있습니다. 따라서 클라이언트는 이를 파악할 방법이 없습니다.

전달 데이터의 용량이 큰 경우 패킷 단위로 데이터를 전달하는데 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있습니다. 따라서 패킷이 순서대로 도착하지 않을 수 있습니다.

😀 TCP/UDP

IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있습니다.

HTTP 메시지가 생성되면 Socket을 통해 전달됩니다.

프로그램이 네트워크에서 데이터를 송수신할 수 있도록, 네트워크 환경에 연결할 수 있게 만들어진 연결부를 소켓이라고 합니다.

✔️ TCP 특징

연결 지향 TCP 3 way handshake (가상 연결)
데이터 전달 보증
순서 보장
신뢰할 수 있는 프로토콜

TCP는 같은 계층에 속한 UDP에 비해 상대적으로 신뢰할 수 있는 프로토콜입니다. TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜입니다.

✔️ UDP 특징

하얀 도화지에 비유 (기능이 없음)
비 연결지향 - TCP 3 way handshake X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
신뢰성보다는 연속성이 중요한 서비스에 사용

UDP는 IP에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜입니다. 앞서 TCP 특징과 비교해 보면 신뢰성은 낮지만 3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교해 빠른 속도를 보장합니다.

HTTP3는 UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있습니다.

✔️ OSI 7계층 모델, TCP/IP 4계층 모델

✔️ HTTP Headers 종류와 특징

HTTP 헤더 형식은 <field-name> : <field-value> field-name은 대 소문자 구분이 없습니다.

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용합니다.

HTTP 전송에 필요한 모든 부가정보 (e.g.메시지 body 내용, 메시지 body 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...)

표현 헤더는 Content-Type - 표현 데이터의 형식 , Content-Encoding - 표현 데이터의 압축 방식 , Content-Language - 표현 데이터의 자연 언어 , Content-Length - 표현 데이터의 길이 를 설명하는 헤더이며, 요청 응답 둘 다 사용합니다.

✔️ HTTP 요청/응답 주요 헤더

😀 Text 1. 요청(Request)에서 사용되는 헤더

From : 유저 에이전트의 이메일 정보
1. 일반적으로 잘 사용 x
2. 검색엔진에서 주로 사용
Referer : 이전 웹 페이지 주소
1. 현재 요청된 페이지의 이전 웹 페이지 주소
2. A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
3. Referer를 사용하면 유입경로 수집 가능
4. referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
⭐ User-Agent: 유저 에이전트 애플리케이션 정보
1. 클라이언트의 애플리케이션 정보(웹 브라우저 정보)
2. 통계정보
3. 어떤 종류의 브라우저에서 장애가 발생하는지 파악 o
4. 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

Host: 요청한 호스트 정보(도메인)
1. 필수 헤더
2. 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
3. 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
1. 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
2. 응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
1. “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
2. e.g.
  Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

😀 Text 2. 응답(Response)에서 사용되는 헤더

Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
1. e.g
  - Server : Apache/2.2.22 (Debian)
  - Server : nginx
Date : 메시지가 발생한 날짜와 시간
1. e.g
  - Date : Tue, 15 Nov 1994 08:12:31 GMT
Location : 페이지 리디렉션
1. 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
2. 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
3. 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow : 허용 가능한 HTTP 메서드
1. 405(Method Not Allowed)에서 응답에 포함
2. e.g
  Allow: GET, HEAD, PUT
Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
1. 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
2. e.g
  - Retry-After : Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  - Retry-After : 120(초 단위 표기)

🤔 HTTP 와 HTTPS의 차이

HTTPS는 HTTP Secure의 약자로 HTTP 프로토콜을 더 안전하게 사용할 수 있음을 의미합니다. 단지 S가 붙었을 뿐인데 HTTPS가 HTTP와 달리 요청과 응답으로 오가는 내용을 암호화하기 때문에 보다 더 안전합니다.

✔️ 암호화 방식

데이터를 암호화 할 때 사용할 키, 암호화한 것을 해석(복호화)할 때 사용할 키가 필요합니다. 이때 암호화와 복호화 키가 동일하다면 대칭 키 암호화 방식, 다르다면 공개 키 (비대칭 키) 암호화 방식이라고 합니다.

서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 SSL 또는 TLS이라고 말하고, HTTP에 SSL/TLS 프로토콜을 더한 것을 HTTPS라고 합니다.

대칭 키 암호화 방식
1. 하나의 키 사용, 암호화할 때 사용한 키로만 복호화 가능
2. 연산속도가 빠름
3. 키를 관리하는데 많은 신경 필요
공개키(비대칭 키) 암호화 방식
1. 두 개의 키 사용, 암호화할 때 사용한 키와 다른 키로만 복호화 가능
2. 보안성이 좋음
3. 복잡한 연산이 필요하여 많은 시간 소모

✔️ 인증서와 CA(Certificate Authority)

HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있고, 인증서는 서버의 신원을 보중해줍니다. 이때 인증서를 발급해주는 공인된 기관들을 CA(Certificate Authority)라 부릅니다.

서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달합니다. CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급합니다.

이인우

안녕하세요 ! 프론트엔드 개발자 취업을 목표로 하는 이인우 입니다!