Http 프로토콜

Posted Nov 6, 2023

By futuremaker

18 min read

Http 프로토콜

HTTP 프로토콜

HTTP는 OSI 7계층에서 7계층 애플리케이션 계층 프로토콜이다. 또한 HTTP HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. 클라이언트-서버 프로토콜이란 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온 하위문서를 재구성한다.

클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(Request)라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(Response)라고 부른다.

출처 : https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

HTTP 요청/응답 모델

HTTP는 메시지를 통해 요청과 응답을 한다. HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록이다. 요청은 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔 하는 메시지고, 응답은 요청에 대한 서버의 답변이다.

메시지는 클라이언트, 서버, 프록시 사이를 흐른다. 메시지가 서버로 향하는것을 인바운드, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는것은 아웃바운드 라고 한다.

요청

- Method: 클라이언트가 수행하고자 하는 동작을 정의

- Path: 가져오려는 리소스의 경로

- Protocal: HTTP 프로토콜 버전

- Header: 서버에 대한 추가 정보를 전달

응답

- Protocal: HTTP 프로토콜 버전

- 상태코드: 요청의 성공 여부와 이유를 나타냄

- 상태 메시지: 상태코드 설명

- Header: 서버에서 전송되는 header

출처

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
HTTP 완벽가이드

HTTP 메서드

요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야하는지 말해준다. HTTP 명세는 공동 요청 메서드의 집합을 정의한다.

메서드	설명	메시지 본문 유무
GET	서버에서 어떤 문서를 가져온다	없음
HEAD	서버에서 어떤 문서에 대한 헤더만 가져온다.	없음
POST	서버가 처리해야 할 데이터를 보낸다.	있음
PUT	서버에 요청 메시지의 본문을 저장한다.	있음
TRACE	메시지가 프록시를 거쳐 서버에 도달하는 과정을 추적한다.	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다.	없음
DELETE	서버에서 문서를 제거한다.	없음

HTTP 메서드 중 GET과 POST의 차이점

GET

서버에게 리소스를 요청하기 위해 쓰인다.
요청 시, URL 주소에 파라미터를 포함하여 전송하며 이부분을 쿼리 스트링이라고 한다.
요청 성공시 200 상태코드를 나타내며, XML, JSON 외에 여러 데이터(HTML, TEXT 등) 형식의 데이터와 함께 반환한다.
캐시 됨
브라우저 기록에 남는다.
북마크에 추가할 수 있다.
데이터의 길이가 제한된다.
멱등성을 가진다. (연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질)

POST

데이터를 생성 및 추가하기 위해 사용
요청 시, 전송할 데이터는 HTTP 메시지의 Body에 담아서 전송한다.
요청 성공시 201(created) 상태코드를 보낸다.
캐시 안됨
브라우저 기록에 남지 않음
북마크에 추가할 수 없음
데이터 길이에 대한 제한이 없음
멱등성을 가지지 않는다.

출처 : https://velog.io/@songyouhyun/Get%EA%B3%BC-Post%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%A5%BC-%EC%95%84%EC%8B%9C%EB%82%98%EC%9A%94

HTTP PUT, PATCH의 차이

PUT

HTTP PUT 메서드는 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체한다.

PUTCH

HTTP PATCH 메소드는 리소스의 부분적이 수정을 할 때에 사용한다.

HTTP 상태코드란, 상태코드 종류

클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 역할을 한다.
응답은 5개의 그룹으로 나뉘어진다.

	클래스	설명
1xx	Informational	리퀘스트를 받아들여 처리중
2xx	Success	리퀘스트를 정상적으로 처리했음
3xx	Redirection	리퀘스트를 완료하기 위해서 추가 동작이 필요
4xx	Client Error	서버는 리퀘스트 이해 불가능
5xx	Server Error	서버는 리퀘스트 처리 실패

	상태 코드	상태 메시지	설명
2xx	200	OK	서버가 요청을 처리함
	201	Created	성공적으로 요청되어 서버가 새 리소스를 작성
3xx	302	Found	요청한 리소스의 URI가 일시적으로 변경되었음을 의미함. 새롭개 변경된 URI는 나중에 만들어 질수 있음
4xx	400	Bad Request	서버가 요청 구문을 인식하지 못함
	403	Forbidden	클라이언가 콘텐츠에 접근할 권리를 가지고 있지 않으며, 이에 서버가 요청을 거부
	404	Not Found	서버가 요청한 페이지를 찾을 수 없다, 서버에 존재하지 않는 페이지를 찾을시 나타남
	405	Mathod not Allowed	요청에 지정된 방법을 사용할 수 없다. POST 방식으로 정의된 요청을 GET 요청으로 보냈을 시
5xx	500	Intenal Server Error	서버에 오류가 발생하여 요청을 수행 할 수 없음

400 : 서버가 클라이언트 오류를 감지해 요청을 처리할 수 없다는 의미
404 : 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미함

출처

https://ko.wikipedia.org/wiki/HTTP%EC%83%81%ED%83%9C%EC%BD%94%EB%93%9C
그림으로 배우는 HTTP & Network basic

HTTP 헤더란, 헤더의 종류

HTTP 헤더는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 도와준다.

HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더를 포함하며 이 메시지 헤더에는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보를 담는다. HTTP 헤더는 대소문자를 구분하지 않으며, 이름과 콜론 다음에 오는 값으로 이루어져있다. 값 앞에 붙은 문자열은 무시된다.

Request Header

요청 헤더는 서버가 응답을 맞춤화 할 수 있도록 요청 컨텍스트에 대한 정보를 제공하기 위해 HTTP 요청에서 사용할 수 있는 헤더이다.

메시지 헤더
- 메소드, URI, HTTP 버전
  - 리퀘스트 라인
- HTTP 헤더 필드
  - 리퀘스트 헤더 필드
  - 일반 헤더 필드
  - 엔티티 헤더 필드
개행 문자 (CR + LF)
메시지 바디

  
GET /home.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/testpage.html
Connection: keep-alive
Upgrade-Insecure-Requests: 1
If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT
If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"
Cache-Control: max-age=0

헤더 필드명	설명
Accept	유저 에이전트가 처리 가능한 미디어 타입
Host	요구된 리소스의 호스트
Authorization	웹 인증을 위한 정보
User-Agent	HTTP 클라이언트의 정보

Reponse Header

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

메시지 헤더
- HTTP 버전, 상태 코드
  - 상태라인
- HTTP 헤더 필드
  - 리스폰스 헤더 필드
  - 일반 헤더 필드
  - 엔티티 헤더 필드
개행 문자
메시지 바디

  
200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8                            # 오브젝트의 타입
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
X-Backend-Server: developer2.webapp.scl3.mozilla.com
X-Cache-Info: not cacheable; meta data too large
X-kuma-revision: 1085259
x-frame-options: DENY

헤더 필드명	설명
Accept-Ranges	바이트 단위의 요구를 수신할 수 있는지 없는지 여부
Location	클라이언트를 지정한 URL 에 리다이렉트
Server	HTTP 서버 정보

출처

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers
그림으로 배우는 HTTP & Network basic

HTTP 무상태성

HTTP는 요청과 응답과정에서 상태를 관리하지 않는다. 이러한 이유로 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성 확보가 가능하다. 또한 응답 서버를 쉽게 바꿀수 있기 때문에 무한한 서버 증설이 가능하다.

무상태성으로 인해 클라이언트를 식별할 수 없어 쿠키, 세션, 토큰 방식으로 클라이언트와의 상태를 기억한다.

출처 : https://velog.io/@rmaomina/network-http

HTTP Keep-Alive

비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말한다.

장점

서버가 다수의 클라이언트와 연결을 계속 유지해야 한다면, 많은 리소스가 낭비된다. 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있다.

단점

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css 등의 자원을 받는데, 해당 자원들을 각각 보낼때마다 연결을 끊고 다시 맺는것을 반복하면 비효율적이다.

TCP 커넥션의 연결과 종료로 반복되는 오버헤드를 줄이기 위해 HTTP의 Keep-Alive 속성을 사용할 수 있다. Keep-Alive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 연결을 지속하기 위해 패킷을 주기적으로 보내는 것을 말한다. 이때 패킷에 반응이 없으면 접속을 끊게 된다.

출처

https://victorydntmd.tistory.com/286
그림으로 배우는 HTTP & Network basic

HTTP 파이프라이닝

지속 연결 (Keep-Alive)은 여려 리퀘스트를 보낼수 있도록 파이프라인화를 가능하게 한다. 파이프라인에 의해 응답을 기다린뒤에 요청을 발행했던것을, 응답을 기다리지 않고 바로 다음 요청을 보낼 수 있다. 이로인해 여러 리퀘스트를 병행해서 보내는 것이 가능하기 때문에 일일이 리스폰스를 기다릴 필요가 없다.

ex) 한 페이지에 10개의 이미지를 포함한 웹 페이지 요청시 개별로 보내는 요청보다 지속연결이 빠르며, 파이프라인이 보다 빠르다.

HTTP/1.1, HTTP/2, HTTP/3 의 특징들

1.1

HTTP의 첫 번째 공식 표준 버전. GET, POST 외에도 PUT과 DELETE 추가됨, 또한 TCP 연결을 재사용해 많은 콘텐츠를 전달할수 있는 Keep-alive, 파이프라이닝 추가

2.0

요청과 응답이 길이가 정의된 한개 이상의 프레임에 담겨 스트림을 통해 보내진다. 하나의 커넥션 위에 여러개의 스트림(한쌍의 응답과 요청 처리)이 동시에 만들어 질 수 있어, 여러 요청과 응답을 처리하는 것이 가능하다.
스트림은 우선순위를 가질수 있다.
헤더 압축
- HTTP 헤더를 압축하여 전송한다. 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식으로 중복 전달을 제거한다.
서버 푸시
- 서버가 하나의 요청에 여러개의 리소스를 보낼 수 있도록 해준다. 서버가 클라이언트에서 어떤 리소스를 요구할 것인지 미리 알 수 있는 상황에서 유리하다.

3.0

구글에서 개발한 QUIC
UDP를 채택해 TCP의 성능을 개선하는 기술이다.
전달 속도의 향상과 더불어 클라이언트와 서버 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 특징

출처 : https://github.com/dongkyun-dev/TIL/blob/master/web/HTTP1.1%EA%B3%BC%20HTTP2.0%2C%20%EA%B7%B8%EB%A6%AC%EA%B3%A0%20%EA%B0%84%EB%8B%A8%ED%95%9C%20HTTP3.0.md

Network

HTTP 프로토콜 메서드 헤더 stateless keep-alive 파이프라이닝 1.1/2/3 study

This post is licensed under CC BY 4.0 by the author.