[인터넷] HTTP(1)

공수정·2021년 11월 23일
http인터넷
0

인터넷

목록 보기
2/7

HTTP란

텍스트 기반의 통신규약, 인터넷에서 데이터를 주고 받을 수 있는 프로토콜
이렇게 정해진 규약에 맞춰 개발을하기 때문에 서로 정보를 교환할 수 있게 됨

역사

  1. HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
  2. HTTP/1.0 1996년: 메서드, 헤더 추가
  3. HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
  4. HTTP/2 2015년: 성능개선
  5. HTTP/3 진행중: TCP -> UDP 사용, 성능 개선

동작

클라이언트 서버 구조


클라이언트(=사용자)가 브라우저 등을 통해서 요청(request)하면 서버에서 해당 요청사항에 맞는 결과를 클라이언트에게 응답(response)하는 형태로 동작
통신을 할 때 HTML 문서도 많이 주고 받지만, JSON이나 XML 형태의 정보도 주고 받을 수 있음

요청: client->server
응답: server->client
형태: HTML, JSON, XML, Plain text 등

특징

TCP/IP를 이용한 응용 프로토콜

HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석

무상태(Stateless) 프로토콜

서버가 클라이언트의 상태를 보존하지 않음, 이전에 어떤 요청을 했는지 관계없이 각 요청을 독립적인 트랜잭션으로 취급함

  • 장점: 서버의 확장성이 높음
  • 단점: 클라이언트가 각 요청을 할 때마다 추가 정보를 같이 보내야함

Stateful과 Stateless

상태 프로토콜과 무상태 프로토콜이 어떻게 다른지 예시를 통해 알아보자.

  • Stateful
    손님A: 새우깡 얼만가요?
    직원A: 1000원입니다.
    손님A: 3개 주세요.
    직원A: 3천원 입니다.(3개 달라고 하는 것이 새우깡인걸 알고 있음, 새우깡 상태유지)
    손님A: 카드로 할게요
    직원A: 결제 완료되었습니다.(새우깡 3개를 결제하는 상황을 알고 있음, 새우깡과 3개 상태유지)

  • Stateless(제대로 안된 예시)
    손님A: 새우깡 얼만가요?
    직원A: 1000원입니다.
    손님A: 3개 주세요.
    직원B: 어떤걸 3개 드릴까요?(3개 달라고 하는 것이 어떤 것인지 모름)
    손님A: 카드로 할게요.
    직원C: 결제 완료되었습니다.(어떤것을 결제하려고 하는지 모름)

예시와 같이 무상태 프로토콜은 이전의 요청과 관계없이 해당 요청을 독립적으로 처리하기 때문에 무상태에서 제대로 동작하기 위해서는 손님이 추가 정보를 보내야한다.

  • Stateless(제대로 된 예시)
    손님A: 새우깡 얼만가요?
    직원A: 1000원입니다.
    손님A: 새우깡 3개 주세요.(새우깡이라는 정보를 추가로 제공)
    직원B: 3천원 입니다.
    손님A: 새우깡 3개 카드로 할게요.(새우깡과 3개라는 정보를 추가로 제공)
    직원C: 결제 완료되었습니다.

Stateful은 중간에 직원A에서 다른 직원으로 변경이 되면 제대로 된 처리를 할 수 없지만, Stateless는 다른 직원으로 변경 되더라도 문제 없이 처리가 가능하다. 이게 Stateless의 장점인 서버의 확장성이 높다는 것이다.
만약 Stateful인데 client1이 server1에 요청을 보내서 처리를 했다면, 중간에 server1가 장애가 생기면 client1의 요청은 처리할 수 없다. 또는 서버를 추가해도 client1은 server1에서만 가능하기때문에 새로운 client가 아닌 이상 추가된 서버에는 요청을 보내지 않을 것이다.

이와 반대로 Stateless는 중간에 server가 바뀌어도, 추가되어도 client1과 다른client의 요청을 잘 처리할 수 있다.

한계

이렇게 모든 것을 Stateless로 설계하면 좋지만 그럴수 없는 경우도 있는데 예시로는 로그인이 있다. 이러한 로그인 상태를 유지하는 것은 쿠키와 세션을 통해 상태를 유지한다.
하지만 이런 상태유지는 최소한만으로 사용하는 것이 좋다.

비연결성

연결


client가 접속 순간부터 연결을 계속 해서 하고있다면, 가만히 있어도 서버의 자원이 계속 소모되고 있어서 비효율적이다. client가 늘어날 수록 더더욱 비효율적으로 서버를 사용하게 된다.

비연결


그래서 요청을 보내면서 연결되고, 응답을 보내면서 연결을 종료한다. 이렇게 하면 가만히 있는 순간에는 서버의 자원을 효율적으로 사용 할 수 있다.
요청과 응답의 속도는 매우 빠르기 때문에, 속도는 많이 느려지지 않고 서버의 자원은 매우 효율적이게 된다.

한계와 극복

한계

TCP/IP는 연결을 새로 할 때마다 3way handshake을 하는 시간이 추가로 필요한데, 웹사이트 한페이지만 요청을해도 필요한 파일이 html뿐 아니라 javascript, css, 이미지 등이 있기 때문에3way handshake시간이 많이 소모가 된다.

극복

HTTP에서는 이 부분을 HTTP 지속 연결로 문제를 해결했다.
연결을 끊는 시간을 조금 늘려서 한 페이지에 대한 resource를 다 받고 나면 그 이후에 연결을 끊도록 되어있다.

HTTP 메시지

Request

request

클라이언트가 서버에게 연락하는 것, 요청을 할 때에는 요청에 대한 정보를 HTTP 메시지에 담아서 서버로 보냄

method

이름설명
GET자료를 요청할 때 사용, 데이터를 쿼리스트링을 통해 전송
HEAD자료를 요청할 때 사용, 단 서버에서 HTML 본문을 return하지 않음(상태확인용도)
POST자료의 생성, 변경을 요청할 때 사용, 데이터를 HTTP 메시지 body에 담아서 전송(주로 데이터 생성목적)
PUT자료의 수정을 요청할 때 사용, 자료가 없다면 새로운 자료를 생성해 달라고 요청하는 용도(주로 데이터 수정 목적, 전체 데이터)
DELETE자료의 삭제를 요청할 때 사용, 특정 자료를 삭제함
PATCH자료의 수정를 요청할 때 사용, (주로 일부 데이터를 수정 목적)

PUT과 PATCH 차이

PUT: 리소스를 완전히 대체함
PATCH: 리소스의 일부분 수정함

HTTP 메서드의 속성

  • 안전: GET, HEAD 등, 여러번 호출해도 리소스를 변경하지 않음
  • 멱등: GET, PUT, DELETE 등, 여러번 호출해도 결과가 같음
  • 캐시가능: GET, HEAD, POST, PATCH 등, 응답결과를 캐시해서 사용할 수 있음(실제로는 GET, HEAD 정도만 캐시로 사용함)

메세지 예시

GET https://velog.io/@0_sujeong HTTP/1.1			// 시작줄
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...	// 헤더
Upgrade-Insecure-Requests: 1
  • 시작줄: 메서드 구조 버전으로 구성, HTTP method / 사이트 주소 / HTTP 버전
  • 헤더: 요청에 대한 정보
  • 공백: 헤더와 본문을 구분짓는 공백(필수)
  • 본문: 본문은 헤더에서 한줄을 띄어 구분, 요청시 함께 보낼 데이터를 담는 부분

Response

response

서버가 요청에 대한 답변을 클라이언트에게 보내는 것

status code

상태 코드는 세 자리로 이루어져 있으며, 아래와 같이 분류 할 수 있다.

코드설명
1XX조건부 응답, 응답을 받았으며 작업을 계속함
2XX성공, 클라이언트가 요청한 동작을 수신하여 이해하고 승낙한 뒤 성공적으로 처리함
3XX리다이렉션 완료, 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 함
4XX요청 오류, 클라이언트에게 오류가 있음
5XX서버 오류, 서버가 요청을 수행하지 못했음

2XX: 성공

주요코드
  • 200 OK: 요청 성공
  • 201 Created: 요청에 성공해서 새로운 리소스가 생성됨
    생성된 리소스는 Location 헤더 필드로 식별
  • 202 Accepted: 요청이 접수되었으나 처리가 완료되지 않았음
    ex) n분 뒤에 실행되는 요청 등
  • 204 No Content: 서버가 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없음
    ex) 문서 편집기의 저장버튼

3XX: 리다이렉션

리다이렉션의 종류
  • 영구 리다이렉션: URI가 영구적으로 변경 되었을때, 검색 엔진 등에서도 변경 인지
    ex) /members -> /users , /members는 다시 사용하면 안됨
  • 일시 리다이렉션: 일시적인 변경
  • 특수 리다이렉션: 결과 대신 캐시를 사용
주요코드
  • 301 Moved Permanently: 영구 리다이렉션, 리다이렉션시 GET으로 요청되고 본문이 제거될 수 있음
  • 308 Permanent Redirect: 영구 리다이렉션, 리다이렉션시 요청메서드, 본문 유지, 사용빈도 적음
  • 302 Found: 일시 리다이렉션, 리다이렉션시 GET으로 요청되고(가능성) 본문이 제거될 수 있음
  • 307 Temporary Redirect: 일시 리다이렉션, 리다이렉션시 요청메서드, 본문 유지
  • 303 See Other: 일시 리다이렉션, 302와 같은 기능, 리다이렉션시 GET으로 요청(무조건)
  • 304 Not Modified: 특수 리다이렉션, 캐시를 재사용하라는 의미로 캐시로 리다이렉트함, 응답에 메시지 바디가 없어야함(로컬 캐시 사용해야하니까)

4XX: 클라이언트 오류

주요코드
  • 400 Bad Request: 클라이언트가 잘못요청해서 처리할 수 없음
  • 401 unauthorized: 클라이언트가 해당 리소스에 대한 인증이 필요함, 인증이 되지 않음
    ex)로그인
    WWW-Authenticate헤더와 함께 인증 방법을 설명
  • 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함, 인증은 되었으나 자격이 없음
    ex)접근 권한
  • 404 Not Found: 요청 리소스를 찾을 수 없음, 리소스가 없거나 권한이 없는 리소스 접근시 리소를 숨기기위해

5XX: 서버 오류

주요코드
  • 500 Internal Server Error: 서버 문제로 오류 발생
  • 503 Service Unavailable: 일시적인 과부하 or 예정된 작업으로 잠시 요청을 처리 할 수 없음

메시지 예시

HTTP/1.1 200 OK			// 시작줄
Connection: keep-alive		// 헤더
Content-Encoding: gzip												 
Content-Length: 35653
Content-Type: text/html;

<!DOCTYPE html><html lang="ko" data-reactroot=""><head><title...
  • 시작줄: 버전 상태코드 상태메시지로 구성
  • 헤더: 응답에 대한 정보
  • 공백: 헤더와 본문을 구분짓는 한 줄(필수)
  • 본문: 요청에 대한 결과, HTML이 담겨 있다면 이 HTML을 브라우저가 받아 화면에 렌더링

헤더와 바디

헤더

HTTP 전송에 필요한 모든 부가정보가 있으며, 표준 헤더가 너무 많다. 또 필요하면 임의의 헤더를 추가해서 사용할 수 있다.

헤더의 종류

  • General 헤더: 메시지 전체에 적용되는 정보
  • Request 헤더: 요청 정보
  • Response 헤더: 응답 정보
  • 표현 헤더: 표현 데이터를 해석할 수 있는 정보

바디

메시지 본문을 통해 표현 데이터(=요청이나 응답에서 전달할 데이터)전달

표현 헤더

request 메시지와 response 메시지 둘 다 사용

  • Content-Type
    : 표현 데이터의 형식, 미디어 타입, 문자 인코딩 (text/html;charser=utf-8 등)
  • Content-Encoding
    : 표현 데이터의 압축 방식, 표현 데이터를 압축하기 위해 사용 (gzip 등)
  • Content-Language
    : 표현 데이터의 자연 언어 (ko, en, en-US 등)
  • Content-Length
    : 표현 데이터의 길이, 바이트 단위, Transfer-Encoding(전송 인코딩)을 사용하면 Content-Length를 사용하면 안됨

Reqeust 헤더

request 메시지에서만 사용하는 헤더

협상(콘텐츠 네고시에이션)

클라이언트가 선호하는 표현 요청에 대한 헤더 정보

  • Accept
    : 클라이언트가 선호하는 미디어 타입 전달

우선순위
구체적인 것을 우선
ex)
Accept: text/*,text/plain,*/*
1위: text/*
2위: text/plain
3위: */*

  • Accept-Charset
    : 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding
    : 클라이언트가 선호하는 압축 인코딩
  • Accept-Language
    : 클라이언트가 선호하는 자연 언어

우선순위
우선순위 값이 있어 높은 값을 사용, 0~1사이, 클수록 높은 우선순위, 생략하면 1
ex)
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
1위: ko-KR(q생략) ->ko-KR
2위: ko;q=0.9 ->ko
3위: en-US;q=0.8 ->en-US
4위: en;q=0.7 ->en

일반 정보

  • From
    : 유저 에이전트 이메일 정보
  • Referer
    : 이전 웹 페이지 주소, 현재 요청도니 페이지의 이전 웹 페이지 주소, 유입 경로 분석가능
  • User-Agent
    : 클라이언트의 애플리케이션 정보(웹 브라우저 정보 등)

특별한 정보

  • Host
    : 요청한 호스트 정보(도메인),하나의 서버가 여러 도메인을 처리해야 할 때

Response 헤더

일반 정보

  • Server
    : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
  • Date
    : 메시지가 발생한 날짜와 시간

특별한 정보

  • Location
    : 페이지 리다이렉션, 응답 코드가 3XX 일때 사용되는 경로
  • Allow
    : 허용 가능한 HTTP 메서드, 응답 코드 405에서 응답에 포함해야함
  • Retry-After
    : 유처 에이전트가 다음 요청할때까지 기다려야하는 시간, 응답 코드 503일때 사용

출처
1. [HTTP Method] GET POST PUT HEAD PATCH DELETE 차이
2. HTTP란 무엇인가?
3. 모든 개발자를 위한 HTTP 웹 기본 지식
4. 무상태 프로토콜

profile
공수정
계속해서 공부하는 개발자입니다 :)
이전 포스트

[인터넷]인터넷 동작 원리

다음 포스트

[인터넷]브라우저의 작동 원리(1)

0개의 댓글