[네트워크] HTTP 프로토콜 총 정리(Stateless, 매서드, 상태코드, 헤더, keep-alive, 파이프라이닝, http 버전별 특징)

李🌸·2023년 9월 15일

CS 네트워크

네트워크

목록 보기

2/7

웹브라우저의 구조

🚨 HTTP 프로토콜

HTTP는 웹 브라우저(클라이언트)와 웹 서버의 테이터 통신을 위한 하이퍼텍스트 전송 프로토콜이다.

일반적으로 웹 사이트는 하이퍼링크(임의의 그림이나 글자를 클릭하면 연결된 부분으로 바로 이동)로 연결된 문서의 집합이다.

하아퍼텍스트는 문서를 쉽게 검색하도록 문서 일부를 다른 문서와 하이퍼링크로 연결한 텍스이다.

이처럼 인터넷 사용자가 필요한 정보를 자유롭게 검색하게 해주는 하이퍼텍스트 방식의 정보를 교환하기 위한 규칙이 HTTP (Hyper Text Transfer Protocol)이다.

HTTP 특징

애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.
클라이언트 서버 구조이다.
무상태(Stateless) 이다.
비 연결성(Connectionless) 이다.

🚨 HTTP 요청/응답 모델

HTTP 처리과정은 서버/클라이언트 모델을 따른다.

클라이언트가 서버에 요청(request) 메시지를 보내면 서버는 응답(response) 메시지를 보낸다.

🚨 HTTP 무상태성(Stateless)

서버가 클라이언트 상태를 보존하지 않는다.
장점: 서버 확장성이 높다.(scale out)
단점: 클라이언트가 추가 데이터 전송

무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다.

고객: 사과 10개 사고 싶은데 얼마인가요?
점원A: 만원입니다.
고객: 신용카드로 결제할께요.
점원B: 결제완료 됐습니다.

그러나, Stateful 상태유지에는 점원이 A에서 B로 바꼈을 때 점원B는 "어떤 제품을 결제하실 건가요?" 라고 되물을 것이다. 왜냐하면 고객이 사고자 하는 사과10개에 대한 정보는 점원A에게 있기 때문이다.

따라서,
➕ Stateful 상태유지는 항상 같은 서버가 유지되어야 한다.
만약 서버에 장애가 상긴다면 유지되던 정보가 다 날라가므로 처음부터 다시 서버에 요청해야 한다.

무상태는 클라이언트가 요청할때 필요한 데이터를 모두 담아 보내기 때문에 아무 서버나 호출해도 되며, 서버 장애가 생기면 다른 서버에서 응답을 전달하면 되므로 클라이언트는 다시 요청할 필요가 없다.

갑자기 고객 증가해도 점원 대거 투입 가능
=갑자기 클라이언트 요청 증가해도 서버를 대거 투입할 수 있다.
=> 무상태는 응답 서버를 쉽게 바꿀 수 있다.
=> 무한한 서버 증설 가능 =수평확장 유리

➕ 연결성과 비연결성

연결성 모델 (Connection Oriented)
TCP/IP의 경우 기본적으로 연결을 유지한다. 클라이언트는 요청을 보내지 않아도 계속 연결을 유지해야 한다. 이러한 경우 연결을 유지하는 서버의 자원이 계속 소모가 된다.

비연결성 모델 (Connectionless)
클라이언트와 서버가 연결 되어있지 않다는 것.
비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다. 최소한의 자원으로 서버를 유지한다.

🚨 HTTP 메서드

주요 메서드

GET : 리소스 조회 (데이터 가져올 때)

POST : 요청 데이터 처리, 주로 데이터(새로운 리소스) 등록에 사용

PUT : 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 새로운 리소스 생성

PATCH : 리소스를 일부만 변경

DELETE : 리소스 삭제

HTTP 메서드 속성

안전 (리소스 변경x)
멱등
(캐시가능)

✅안전

Get은 리소스를 변경하지 않기 때문에 안전하다.
Post, Put, Patch, Delete는 리소스의 변경이 있으므로 안전하지 않다.

멱등성이란❓
어떤 대상에 같은 연산을 여러번 적용해도 결과가 달라지지 않는 성질이다.

Ex) f(x)= x * 1 함수는 항상 x를 반환한다. (연산을 1번 적용하던 100번 적용하던 동일.)

✅멱등성을 HTTP 주요 메서드에 적용해보면,

멱등성 O

GET: 단순히 조회만 하므로 여러번 호출해도 리소스 변화 X.

PUT: 결과를 완전히 대체하는 것으로 여러번 호출해도 최종결과 동일

DELETE: 결과를 삭제하는 것으로 여러번 호출해도 삭제된 결과 동일
⏩모두 멱등 => 재요청 해도 된다.

PUT과 PATCH의 차이점

PUT은 지정한 데이터를 전부 수정(대체)하는 Method이지만 PATCH는 정보의 일부분이 변경되는 방법이다. 그래서 PUT은 멱등하지만, PATCH는 멱등하다고 볼 수 없다.

Put
기존 데이터가 {name: ssohan, age: 20} 일 때 { age: 30 } 를 Put으로 보내면 name이 날아가고 { age:30 }로 변경된다.

Patch
기존 데이터가 {name: ssohan, age: 20} 일 때 { age: 30 } 를 Patch으로 보내면 { name: ssohan, age:30 } 와 같이 age만 변경된다.

🚨 HTTP 상태코드

HTTP는 클라이언트와 서버 간의 통신에서 상태코드(status code)를 사용하여 요청의 처리 결과를 나타내어, 웹 개발자들이 요청에 대한 처리를 할 수 있도록 돕는다.

100번대 (Informational) -> 정보성 응답
200번대 (Successful) -> 요청 정상 처리 성공 응답
300번대 (Redirection) -> 리다이렉션, 클라이언트의 추가 조치 필요하므로 다시 돌려보냄
400번대 (Client Error) -> 클라이언트 오류로 서버가 요청 수행 불가.
500번대 (Server Error) -> 서버 오류로 서버가 정상적인 요청 처리 못함.

대표적인 상태코드

200 OK : 요청이 성공적으로 처리되었다.
201 Created: 요청이 처리되어 서버가 새 리소스를 생성했다.
202 Accepted: 요청은 접수하였지만, 처리가 완료되지 않았다. (클라이언트 다시 요청 보냄)
400 Bad Request: 요청의 구문이 잘못되었다.
401 Unauthorized: 이 요청은 인증이 필요하다. (액세스 권한이 없다.)
403 Forbidden: 지정한 리소스에 대한 액세스가 금지되었다.
404 Not Found : 요청한 페이지나 리소스를 찾을 수 없다.
500 Internal Server Error : 서버 내부 오류가 발생하여 요청을 처리할 수 없다.
501 Not Implemented: 요청한 URI 메소드에 대해 서버가 구현하지 않았다.
502 Bad Gate: 잘못된 응답을 받았다.

HTTP 헤더

요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본 구조를 따른다. 대소문자 구분없는 문자열 다음에 콜론(':')이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라진다.

General 헤더: Via와 같은 헤더는 메시지 전체에 적용된다.
Request 헤더: User-Agent (en-US), Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정한다.
Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용된다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않는다.

HTTP Keep-Alive

HTTP keep-alive란, HTTP 프로토콜에서 클라이언트와 서버 간 여러 요청을 단일 TCP 연결을 재사용하는 방식을 말한다.

HTTP는 sateless이며 connectionless이므로, HTTP/1.1 이전에는 클라이언트와 서버 사이에 트랜잭션 한번이 일어나면 HTTP Connection 이 끊어졌었다.

(ex. 문의전화했을 때 질문 1번할때마다 대답을 듣고 전화가 끊어짐 -> 매우 불편)

keep alive를 설정하면 지정한 시간 내에서 데이터를 계속 주고 받을 수 있다.

장점:
o 네트워크 지연시간이 줄어든다.
o 데이터를 빈번히 주고 받을 때 유용하다.

단점:
o 사용자가 많다면 연결이 늘어나서 새로운 사용자를 받아들이지 못하는 경우가 생긴다.
o 성능 하락의 주범이 될 수 있다.

HTTP 파이프라이닝

첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째, 세번째 요청 전송을 가능하게 한다. (=요청 병렬처리)

(http 버전별 특징에서 추가 설명)

HTTP 버전별 특징

✅ HTTP 1.1

HTTP 1.0과 비교해보면,

Persistent Connection (keep-Alive) 추가
파이프라이닝 추가

그러나 파이프라이닝은 동시에 여러개의 요청을 처리해 응답보내진 않는다. 따라서, 먼저 받은 요청이 끝나지 않으면 뒤 요청이 끝나도 먼저 온 요청이 끝날때까지 순차적으로 기다려야 한다.

이를 HOLB(Head Of Line Blocking) 문제라고 한다.

✅ HTTP 2

Stream 개념 등장
HTTP 메시지 전송 방식의 전환
=> 바이너리 형식 사용으로 파싱속도, 전송속도 빨라지고 오류 발생 가능성 낮아졌다.
Multiplexed Streams
o stream 통해 동시에 여러 요청을 처리하는 것이 가능해졌다. =>HOLB 문제 해결
o 요청과 응답이 동시에 이루어지니 여러 요청과 응답이 뒤섞여 있다.