[컴퓨터 네트워크] HTTP

HTTP

World Wide Web에서 정보를 주고받을 수 있게해주는 프로토콜

네트워크 통신을 작동하게 하는 기본 기술

 

 

HTTP 특징

-클라이언트 서버 구조

-무상태 프로토콜, 비연결성

-단순함, 확장가능

 

 

HTTP 무상태 프로토콜

-Http 서버는 클라이언트의 요청 내역을 기억하지 않음

-따라서 서버는 클라이언트가 누구인지 식별하지 못함

-클라이언트가 누구인지 식별 해야하는 경우 상태유지기술인 쿠키와 세션을 사용

 

 

 

HTTP Header

클라이언트와 서버가 요청 또는 응답을 부가적인 정보를 전송할 수 있게 해줌

대소문자를 구분하지않는 이름과 콜론 ' : ' 다음에 오는 값으로 이루어져 있음

 

종류

 

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

Request header: 페치 될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.

Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.

Entity header: 콘텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

 

 

 

 

HTTP 1.0 / 1.1 / 2 / 3

HTTP 1.0

 

한 연결당 하나의 요청을 처리하도록 설계

서버에게 요청 시 매번 연결과 해제의 과정을 반복해야 했기에 RTT가 오래걸린다는 문제점

• RTT: 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간 (패킷 왕복 시간)

 

HTTP 1.1

-Persistent Connection 추가

• HTTP/1.0을 보완하여 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 일정 시간동안 연결 상태를 유지

HTTP keep-alive란

=> persistent connection을 맺는 기법중 하나

하나의 TCP Connection을 활용하여 여러개의 HTTP request/response를 주고받을 수 있도록 해줌

 

 

 

 

-Pipelining 추가

• TCP의 특성상 요청 후 응답을 기다려야하는 문제를 보완
• 클라이언트는 앞 요청의 응답을 기다리지 않고 순차적으로 요청 전송, 서버는 요청이 들어온 순서대로 응답

• OL Blocking (Head Of Line Blocking) 문제
  • 앞의 요청(패킷)에 대한 응답이 늦어지면 뒤의 모든 요청들은 모두 blocking되어 응답이 지연됨
• 연속된 요청 간에 헤더의 많은 중복이 생긴다는 문제

 

 

HTTP 2.0

• HTTP/1.x의 시간 지연 문제를 해결
• Multiplexed streams (멀티플렉싱)
  • HTTP/1.1의 Pipelining은 한번의 연결에서 여러 요청을 보낼 수는 있었지만 동시에 여러 요청을 처리하진 못했음
  • 하나의 커넥션 내에 여러개의 스트림(stream, 양방향 데이터 흐름)을 사용하여 송수신
  • 메시지가 이진화된 텍스트인 프레임(frame)으로 나뉘어 요청마다 구분되는 스트림(stream)을 통해 전달
  • 프레임(frame)이 각 요청의 스트림(stream)을 통해 전달되며, 하나의 커넥션 안에 여러개의 스트림(stream)을 가질 수 있게되어 다중화(multiplexing)가 가능해짐
  • 스트림(stream)을 통해 각 요청의 응답 순서가 의미가 없어져 HTTP/1.x의 HOL Blocking 문제 해결

 

 

 

 

• Header Compression (헤더 압축)
  • 요청과 응답 헤더의 메타데이터를 압축해서 기존의 연속된 요청에서의 중복 헤더로 인한 오버헤드 문제를 해결
  • 이전에 표시된 헤더를 제외한 필드를 허프만 코딩을 활용해서 압축
• Server Push (서버 푸시)
  • 클라이언트가 서버에 요청하지 않아도 클라이언트에게 필요한 리소스를 서버가 추가적으로 push해주는 기능
• 각 요청마다 stream으로 구분해 병렬적으로 처리함에도 불구하고 TCP 고유의 HOL Blocking이 여전히 존재하는 문제
  • 서로 다른 stream이 전송되고 있을 때, 하나의 Stream에서 유실이 발생되거나 문제가 생기면 결국 다른 Stream도 문제가 해결될 때 까지 지연되는 현상이 발생

HTTP 3.0

• TCP 위에서 돌아가는 HTTP/2.0와는 달리 QUIC라는 계층 위에서 돌아가며 TCP기반이 아닌 UDP 기반
• HTTP/2.0의 장점(멀티플렉싱 등)의 기능을 가지고 있음
• 초기 연결 설정 시 지연 시간 감소라는 대표적 특징 (UTP기반)
  • 초기 연결(통신 시작) 시 3-way handshaking 과정을 거치지 않아 1-RTT만 소요
  • 클라이언트와 서버거 한번 신호를 주고받은 후 바로 통신 시작
• TCP의 stream은 하나의 chain으로 연결되는 것과 달리 각 stream당 독립된 stream chain을 구성하여 TCP의 HOL Blocking을 해결

HTTP Request

시작라인

Http method

request target

Http version

 

GET /test.html HTTP/1.1
[HTTP Method] [Request target] [HTTP version]

 

 

 

 

HTTP Method

Get 메서드

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

Post 메서드

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

 

Post 요청 데이터를 어떻게 처리한다는 뜻일까? 예시

• 스펙: POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다. (구글 번역)
• 예를 들어 POST는 다음과 같은 기능에 사용됩니다.)
  • HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공)
    • 예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용)
  • 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시)
    • 예) 게시판 글쓰기, 댓글 달기)
  • 서버가 아직 식별하지 않은 새 리소스 생성)
    • 예) 신규 주문 생성)
  • 기존 자원에 데이터 추가)
    • 예) 한 문서 끝에 내용 추가하기)
• 정리: 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음)

Post 정리

1.새 리소스 생성(등록)

1. 요청 데이터 처리
2. 다른 메서드로 처리하기 애매한 경우 : Post 사용

Put 메서드

• 리소스를 대체
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 쉽게 이야기해서 덮어버림
• 중요! 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI 지정

Patch 메서드

•리소스 부분 변경

 

-put은 리소스의 모든 부분을 업데이트 하지만 patch는 리소스 일부를 업데이트 함

Delete 메서드

• 리소스 제거

 

 

 

 

HTTP Response

 

HTTP 상태코드

1xx

거의 사용하지 않음

2xx - 성공

클라이언트의 요청을 성공적으로 처리

• 200 OK : 요청 성공
• 201 Created : 요청 성공해서 새로운 리소스가 생성됨
• 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
• 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

3xx - 리다이렉션

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

리다이렉션 종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
• 일시 리다이렉션 - 일시적인 변경
• 특수 리다이렉션 - 결과 대신 캐시 사용

영구 리다이렉션 (301 , 308)

• 리소스의 URI가 영구적으로 이동
• 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지

301 : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
308 : 301과 기능은 같음 / 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시적인 리다이렉션 (302, 307, 303)

• 리소스의 URI가 일시적으로 변경
• 따라서 검색 엔진 등에서 URL을 변경하면 안됨

302 : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
307 : 302와 기능은 같음 / 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
303 : 302와 기능은 같음 / 리다이렉트시 요청 메서드가 GET으로 변경

PRG: Post/Redirect/Get (일시적인 리다이렉션 - 예시)

• POST로 주문후에 새로 고침으로 인한 중복 주문 방지
• POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청

그래서 뭘 써야 하나요?

• 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
• 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

기타 리다이렉션

300: 안쓴다.
304 : 캐시를 목적으로 사용

4xx : 클라이언트 오류

오류의 원인이 클라이언트에 있음

400 : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
401 : 클라이언트가 해당 리소스에 대한 인증이 필요함
403 : 서버가 요청을 이해했지만 승인을 거부함
404 : 요청 리소스를 찾을 수 없음

5xx : 서버 오류

오류의 원인이 서버에 있음

500 : 서버 문제로 오류 발생, 애매하면 500 오류
503 : 서비스 이용 불가

 

 

 

 

 

#참고자료

https://zu-techlog.tistory.com/113

[네트워크] HTTP/1.X, HTTP2, HTTP3 버전 차이, 특징