[1주차] HTTP 프로토콜

HTTP 프로토콜 개념

ㆍ 인터넷 상에서 데이터를 송수신하기 위해 클라이언트/서버 모델을 따르는 프로토콜
ㆍ 일반적으로 TCP/IP 통신 위에서 동작하며 Application Layer의 프로토콜
ㆍ 기본 포트: 80번
ㆍ 다양한 데이터를 전송할 수 있도록 설계됨 (HTML문서, 이미지, 동영상, 음성 등)

HTTP 특징

1. 클라이언트-서버 구조(요청-응답 모델)
   : 클라이언트가 요청을 보내면 서버는 요청을 처리하여 응답을 반환함
   : 클라이언트 - 웹에 접근할 수 있는 소프트웨어(IE, Chrome, Safari 등의 브라우저)
   : 서버 - 요청에 응답할 수 있는 소프트웨어(Apache, nginx, IIS 등의 웹 서버)

2. 무상태성(Stateless)
   : 데이터 요청이 독립적으로 관리가 됨
   : 이전 요청과 다음 요청은 서로 관련이 없음

3. 비연결성(Connectionless)
   : 요청을 주고 받을 때만 연결을 유지하며, 요청이 끝나면 연결을 끊음

4. 쿠키(Cookie)
   : 클라이언트와 서버의 상태 정보를 가지고 있는 데이터
   : HTTP는 무상태성과 비연결성 특징을 지니고 있어 이전 상태의 정보를 알 수 없음. 이를 해결 하기 위해 쿠키를 이용함

---

HTTP 동작 방식

1. connect: 클라이언트가 원하는 서버에 접속
2. request: 클라이언트가 서버에 요청
   1) 요청 헤더: 요청메서드, 요청URL, HTTP프로토콜 버전
   2) 요청 바디: 요청할 때 함께 보낼 데이터를 담는 부분(POST, PUT)
3. response: 서버가 응답 결과를 보냄
   1) 응답 헤더: HTTP프로토콜 버전, 상태 코드, 응답메시지
   2) 응답 바디: 응답 리소스 데이터

request 코드 예시

response 코드 예시

HTTP 헤더

ㆍ 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해주는 것

1. General Header

요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련없는 헤더

ㆍ Connection: Keep-Alive - 메시지 교환 후 TCP 연결 유지
ㆍ Connection: Close - 메시지 교환 후 TCP 연결 종료

2. Request Header

업데이트될 자원이나 클라이언트 자체에 대한 정보를 포함하는 헤더

ㆍ Accept: 클라이언트가 선호하는 미디어 타입 전달
ㆍ Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
ㆍ Accept-Language: 클라이언트가 선호하는 자연 언어
ㆍ Referer: 이전 웹 페이지 주소
ㆍ Host: 요청한 호스트 정보(도메인)
ㆍ User-Agent: 유저 에이전트 애플리케이션 정보
ㆍ Cookie: 클라이언트가 서버에서 받은 쿠키 저장, HTTP 요청시 서버로 전달

3. Response Header

서버에 대한 자세한 정보를 포함하는 헤더

ㆍ Date: HTTP 메시지를 생성한 일시
ㆍ Server: 요청을 처리하는 서버의 정보
ㆍ Location: 페이지 리다이렉션(상태코드 3xx에서 사용)
ㆍ Allow: 서버 측에서 지원 가능한 HTTP 메서드 리스트
ㆍ Set-Cookie: 서버에서 클라이언트로 쿠키 전달

4. Entity(Representation) Heaader

컨텐츠 길이나 바디에 대한 자세한 정보를 포함하는 헤더

ㆍ Content-Encoding: 표현 데이터 압축
ㆍ Content-Language: 표현 데이터의 자연 언어
ㆍ Content-Type: 표현 데이터의 형식을 설명함
ㆍ Content-Length: 표현 데이터 길이

HTTP 요청 메서드

ㆍ 클라이언트가 원하는 요청의 종류를 서버에 알려주기 위해 사용함

ㆍ GET: 자원 요청, 조회(SELECT)
ㆍ POST: 자원 생성(INSERT)
ㆍ PUT: 자원 전체 업데이트(UPDATE)
ㆍ PATCH: 자원 일부 업데이트(UPDATE)
ㆍ DELETE: 자원 삭제(DELETE)
ㆍ HEAD: 헤더 정보 요청
ㆍ OPTIONS: 웹서버가 지원하는 메서드 종류를 요청
ㆍ TRACE: 클라이언트의 요청 그대로 반환(서버 결과 확인을 위해 사용)

더 알아보기

< GET vs POST >

ㆍ GET - 데이터 조회 / 요청바디 없음 / 길이제한 있음 / 데이터 길이 제한 / 멱등성 보장
ㆍ POST - 데이터 생성 / 요청바디 있음 / 길이제한 없음 / 데이터 길이 무제한 / 멱등성 무보장

** 멱등성: 항상 같은 결과를 반환하는 것

URL

ㆍ 클라이언트가 자원의 위치를 알기 위해 사용하는 프로토콜

URL 예시

HTTP 상태 코드

ㆍ 클라이언트의 요청에 따른 서버 상태를 코드로 반환하는 것

ㆍ 1xx(조건부 응답): 요청을 받았으며 작업을 계속함

ㆍ 2xx(성공): 클라이언트의 요청을 처리함

ㆍ 3xx(리다이렉션): 클라이언트가 요청한 리소스를 그대로 제공하지 않고, 다른 위치로 이동해야 할 때 사용됨
   ㆍ 302(FOUND): 리소스가 임시적으로 다른 위치에 존재함. 따라서 새로운 URL로 요청을 다시 보내야함. (로그인 성공 후 메인 페이지로 리다이렉트)

ㆍ 4xx(요청 오류): 클라이언트의 요청에 오류가 있음
   ㆍ 400(잘못된 요청)
   ㆍ 401(권한없는 요청): 헤더 오류
   ㆍ 403(금지): 자원 접근 금지
   ㆍ 404(찾을 수 없음): 요청한 데이터가 서버에 존재하지 않음

ㆍ 5xx(서버 오류): 서버가 유효하지 않음

---

HTTP 버전 별 특징

1. HTTP/0.9

ㆍ GET 메서드만 사용 가능
ㆍ 헤더가 존재하지 않았기에 HTML 문서만 주고 받았음

2. HTTP/1.0

ㆍ POST, HEAD 메서드 추가
ㆍ 상태 코드 추가
ㆍ 요청/응답에 헤더 추가
   : 헤더의 Content-Type 속성으로 HTML 문서 외 다양한 문서를 주고 받을 수 있게 됨
ㆍ 단점: Connection을 재사용하지 못함
   : (Connection 하나 당 한 데이터만 주고 받고 서버 연결이 종료됨 = Connectionless)

3. HTTP/1.1

ㆍ PUT, DELETE, TRACE, OPTIONS 등 메서드 추가
ㆍ Keep-Alive 로 Connection 재사용이 가능해짐
ㆍ Pipelining을 통해 연속적인 요청이 가능해짐
ㆍ 단점: 앞선 요청에 의해 뒤 요청이 지연되는 현상 발생 (HOL Blocking)

 
더 알아보기

< Keep-Alive >

ㆍ Connection을 재사용하여 클라이언트와 서버 간 여러 요청을 처리하는 기능
ㆍ 요청 및 응답 과정에서 발생하는 오버헤드를 줄일 수 있음

< Pipelining >

ㆍ 요청에 대한 응답이 완전히 전송되기 이전에 다른 요청 전송을 가능하게 하는 기능
ㆍ 치명적인 단점(HOL Block)으로 후에 Multiplexed Streams로 대체됨

4. HTTP/2

ㆍ 메시지 구성 변화 (Plain Text -> Binary Format)
   : 패킷을 Frame으로 Binary Encoding하여 더 작은 단위로 관리함
   : 파싱 및 전송 속도가 향상되고 오류 발생 가능성이 낮아짐
ㆍ HOL Block 문제를 해결하기 위해 Multiplexed Streams 적용
   : 하나의 Connection으로 동시에 여러 요청을 받을 수 있으며, 요청 순서 없이 먼저 들어온 응답을 처리함
ㆍ Stream Prioritization 지원
   : 응답에 대한 우선순위를 정해 중요 데이터를 먼저 처리함
ㆍ Header Compression
   : 데이터를 절약하기 위해 HPACK 압축방식을 사용함
   : 이전 Header와 중복되는 필드를 재전송하지 않도록 함
ㆍ Server Push
   : 클라이언트에서 별도로 요청하지 않아도 서버 측에서 리소스를 보내는 기능
ㆍ 단점: 오류가 발생했을 경우 오류가 해결될 때까지 다음 요청들이 대기함

5. HTTP/3

ㆍ UDP 기반의 QUIC 프로토콜 사용
   : 기존 TCP 위에서 작동하던 버전과 달리 UDP 기반으로 작동함
   : TCP의 신뢰성을 확보하면서 데이터 전송의 속도를 향상함
ㆍ 향상된 Multiplexed Streams 사용
   : 오류 발생 시 해당 스트림만 중단되고, 다른 스트림에 영향을 주지 않음
ㆍ 헤더 압축 방식으로 QPACK을 사용함

---

참고

ㆍ https://shlee0882.tistory.com/107
ㆍ https://csj000714.tistory.com/m/733?category=1103243
ㆍ https://joshua1988.github.io/web-development/http-part1/
ㆍ https://velog.io/@sujeong/2-%EC%9B%B9%EC%9D%98-%EB%8F%99%EC%9E%91-HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%9D%B4%ED%95%B4
ㆍ https://noahlogs.tistory.com/35
ㆍhttps://code-lab1.tistory.com/257
ㆍhttps://velog.io/@cjh8746/HTTP-Keep-Alive-%EC%99%80-pipelining-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Multiplexed-Streams%EC%9D%84-%EA%B3%B5%EB%B6%80%ED%95%98%EB%8B%A4%EA%B0%80-%EC%95%8C%EA%B2%8C%EB%90%9C-%EB%B2%84%EC%A0%84%EC%97%B4-HTTP0.9-2.0-%EC%A0%95%EB%A6%AC
ㆍhttps://velog.io/@minu/HTTP1.0-HTTP1.1-HTTP2-and-QUIC