[CS] HTTP / HTTPS

Youngwoo Lee·2021년 5월 12일

UDP http http 1.1 http 2.0 http method https tcp

CS

목록 보기

2/5

최근 REST API를 활용한 프로젝트를 진행하게 되면서, HTTP 통신을 많이 사용하게 되었다. HTTP 메세지의 구조는 어떠한지 그리고 HTTP와 HTTPS의 차이점은 무엇인지에 대해서 알아보자!

HTTP와 HTTPS

웹상에서 클라이언트와 서버 간 통신을 위한 프로토콜이며, OSI 7계층에서는 제일 위 Application Layer에 속한다

일단 HTTP와 HTTPS에 대해 알아보기 전에 TCP와 UDP에 대해서 알아보자!
왜냐고? HTTP는 TCP를 기반으로 만들어진 프로토콜이니깐!

HTTP 구조 정리

참고) https://programmer93.tistory.com/60

HTTP 기본 구조

시작 라인 (Start line)
기본적으로 HTTP 버젼에 대한 정보를 가지고 있으며, Response인지 Request인지에 따라 약간 형태가 다르다.
헤더 (Header)
header-field : field-value 으로 구성되어 있다.
HTTP 전송에 필요한 모든 부가정보를 가지고 있다.
메시지 본문 (Message Body)
메세지의 본문, 통신을 통해 보내고자 하는 Data를 담고 있다.

HTTP Request 구조

Start Line

HTTP Method - 요청시 보내는 HTTP 메소드 형태이다. (GET, POST, PUT, PATCH, DELETE, 기타)
Request Target - 어디로 보내는지에 대한 URI 이다.
HTTP Version - HTTP 버젼으로 현재까지는 대부분이 HTTP/1.1이고 HTTP/2, HTTP/3 까지도 있다.

Header

Host - 호스트 URL 이다.
User-Agent - 클라이언트 정보다.
Accept - 서버에서 해당 타입에 데이터를 보내달라고 요청하는 헤더이다.
Authorization - JWT 같은 인증 토큰을 서버로 보낼 때 사용하는 헤더이다.
기타 등등

HTTP Response 구조

Start Line

HTTP Version - Response 메시지의 HTTP 버젼 정보이다.
Status Code - 응답 코드이다 ex)200, 404(Not Founded)
Status text - 응답 상태이다.

Header

Date - 응답온 일시이다.
Content-Type - 응답 데이터의 타입이다.
Cache-Control - 캐시용 헤더이다.
기타 등등

Body

Content-Type에 맞는 응답 메세지에 실어서 보낸 Data

HTTP의 메서드 종류

참고) https://feel5ny.github.io/2019/08/16/HTTP_003_02/

HTTP 메서드

HTTP 메시지 중 Request에 존재하는 메서드에 대해서 알아보자. Request 메서드에 따라서 서버에서 처리되는 과정, 반환되는 메시지의 형태가 달라진다. HTTP/1.1에 정의한 메서드에는 총 9가지가 존재하며, 서비스에 따라서 커스텀한 확장 메서드를 만날 수도 있다

특징

모든 서버가 모든 메서드를 구현하지 않는다
모든 메서드를 구현하지 않았다 하더라도 대부분 제한적으로 사용될 것이다
일반적으로 서버 설정에 의해 메서드의 제한이 정해져 있으며, 따라서 사이트마다 또 서버마다 다를 수 있다.

각 메서드 설명HTTP 메서드

GET : URL가 가진 정보를 검색하기 위해 서버측에 요청하는 형태

POST : 내용 전송 (파일 전송 가능) 클라이언트에서 서버로 어떤 정보를 제출함

HEAD : 메세지 헤더 (문서 정보) 취득, GET과 비슷하나 문서를 요청하는 것이 아닌 문서 정보를 요청한다

이에 따라 응답에서는 Body 없이 HTTP 헤더 정보만을 보낸다

PUT : 내용 갱신 위주(파일 전송 가능), POST처럼 정보를 서버로 제출하는 것으로 형식은 동일하나 갱신 위주이다

이에 의해 갱신된 리소스에 대한 주소 정보를, POST와 달리 서버측 응답메세지의 HTTP헤더 항목 중 Location에 대한 내용은 보내지 않아도 된다

Patch Patch는 일부를 교체하는 의미.

PUT 와의 차이점 : PUT의 경우는 데이터 전체를 수정하는 것이며, PATCH 의 경우는 데이터의 일부를 수정하는 것을 의미한다.
Patch 의 경우는 멱등성을 항상 보장할 수 없다
만약 하나의 필드값을 10 증가하도록 하는 operation을 요청하는 Patch 라면 멱등하지 않기 때문이다. 서버 설계에 따라 멱등성을 지킬 수 있는지 없는지 알 수 없다.

DELETE : 파일 삭제, 웹 리소스를 제거

OPTIONS : OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰임

TRACE : 요청 리소스가 수신되는 경로를 보여줌

CONNECT : CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다

멱등성
멱등(idempotent) 의미는 같은 작업을 계속 반복적으로 수행해도 같은 결과가 나오는 경우를 의미한다. 동일한 자원에 대한 GET요청이라면 클라이언트에 반환되는 모든 응답은 동일해야 한다. 하지만, POST 요청의 경우는 새로운 자원을 생성하는 요청을 반복적으로 요청하면, 계속해서 새로운 자원이 생성되기 때문에, 멱등하지 못하다

HTTP Status Code의 의미

100번대

1xx (조건부 응답)
요청을 받았으며 작업을 계속한다.

이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는
부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다.
HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고
HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.

100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며
나머지를 기다리고 있음을 나타낸다.
101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
102(처리, RFC 2518)

200번대

2xx (성공)
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리
이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
207(다중 상태, RFC 4918)
208(이미 보고됨, RFC 5842)
226 IM Used (RFC 3229)

300번대

3xx (리다이렉션 완료)
클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.

300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할
작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로
이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를
계속 사용해야 한다.
303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를
표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의
콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면
이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면
요청자가 사용할 프록시를 가리키는 것이기도 하다.
307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래
위치를 계속 사용해야 한다.
308(영구 리다이렉션, RFC에서 실험적으로 승인됨)

400번대

4xx (요청 오류)
4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.

400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다.
상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에
더 가깝다.
402(결제 필요): 이 요청은 결제가 필요합니다.
403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을
갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에
존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에
GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야
한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다.
서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와
비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로
이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를
표시한다.
417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
418(I'm a teapot, RFC 2324 ,https://google.com/teapot)
420(Enhance Your Calm, 트위터)
422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
423(잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
424(실패된 의존성, WebDAV; RFC 4918)
424(메쏘드 실패, WebDAV)
425(정렬되지 않은 컬렉션, 인터넷 초안)
426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
428(전제조건 필요, RFC 6585)
429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
431(요청 헤더 필드가 너무 큼, RFC 6585)
444(응답 없음, Nginx)
449(다시 시도, 마이크로소프트)
450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
451(법적인 이유로 이용 불가, 인터넷 초안)
451(리다이렉션, 마이크로소프트)
494(요청 헤더가 너무 큼, Nginx)
495(Cert 오류, Nginx)
496(Cert 없음, Nginx)
497(HTTP to HTTPS, Nginx)
499(클라이언트가 요청을 닫음, Nginx)

500번대

5xx (서버 오류)
서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할
때 이 코드를 표시한다.
502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서
잘못된 응답을 받았다.
503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할
수 없다. 이는 대개 일시적인 상태이다.
504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을
받지 못했다.
505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
506(Variant Also Negotiates, RFC 2295)
507(용량 부족, WebDAV; RFC 4918)
508(루프 감지됨, WebDAV; RFC 5842)
509(대역폭 제한 초과, Apache bw/limited extension)
510(확장되지 않음, RFC 2774)
511(네트워크 인증 필요, RFC 6585)
520(Unknown Error, 알 수 없음)
598(네트워크 읽기 시간초과 오류, 알 수 없음)
599(네트워크 연결 시간초과 오류, 알 수 없음)

HTTPS와 HTTP의 차이점

HTTP
- 네트워크 보안X → 네트워크상에서 정보를 열람, 수정 가능
- HTTPS에 비해 빠른 속도
- HTTPS보다 트래픽이 적게 발생 → 상대적으로 적은 비용으로 유지 가능
HTTPS
- HTTPS 장점
  - HTTP의 보안상 문제점 해결
    - SSL 사용(보안소켓계층)을 통하여 암호화된 정보를 브라우저와 서버간에 주고받을 수 있음
    - TLS(전송보안계층)를 사용하여 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공
- HTTPS 단점
  - HTTPS는 설치 및 인증서를 유지하는 데 추가 비용이 발생
  - 암호화하는 과정이 웹 서버에 부하를 줌
  - HTTP에 비해 속도가 느림
  - 인터넷의 연결이 끊긴 경우 재인증 시간이 소요
    - HTTP는 비연결형으로 웹페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있음
    - HTTPS는 소켓(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷의 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 재인증이 필요
- HTTPS가 필요한 이유
  - 클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공
  - 웹 페이지(HTML)는 텍스트이고, HTTP를 통해 이런 텍스트 정보를 교환하는 것
  - 이때 주고 받는 정보들은 네트워크를 통해 공유되고, 이런 정보들 중 개인정보 또는 보안상 민감한 정보인 경우, 보안상 큰 문제가 된다
  - 즉, 중간에 중요한 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것

HTTP v1.1와 v.2의 차이점

HTTP v1.0에서

매번 새로운 연결로 성능 저하가 되었고
서버 부하 비용이 증가한 것을 막기 위해서

HTTP v1.1에서

Persistent Connection
지정한 timeout 동안 커넥션을 닫지 않는 방식
Pipelining
하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법

문제점

Head Of Line Blocking
Piplelining을 통해서 여러 요청을 연속적으로 하나의 파이프내에서 보낼 수 있었지만 앞 순서의 요청에 대한 처리가 오래걸리면 같이 보낸 요청이 처리가 늦어지는 문제가 생기게 되었다
Header 구조의 중복
연속된 요청의 경우 같은 헤더를 가지는 경우가 많은데도, 모든 데이터가 같은 헤더를 중복적으로 가져서 낭비가 생김

해결방법 HTTP v2.0

기존 버전의 성능향상에 초점을 맞춰, 대체가 아닌 확장의 개념
HTTP 메시지 전송방식의 변화 - 바이너리 프레이밍 계층 사용 (Text가 아닌 바이너리로 인코딩하여 보냄)
- 파싱, 전송 속도 향상, 오류 발생 가능성 낮아짐
기존과 다르게 응답은 순서에 상관없이 stream으로 주고받게 되었다. 여러 요청을 쪼개서 순서 상관 없이 보내게 됨
- 도착된 것들을 조립하는 식으로 하여, 서버에서 처리함. -> 요청의 순서가 상관 없게 됨 -> Head of blocking 해결
Stream Prioritization
-> 리소스간 우선 순위를 설정 가능 (Stream에 우선순위를 줄 수 있다)
Server Push
클라이언트가 요청하지 않은 것을 보내줄 수 있는 기능
Header Compression
헤더의 크기를 줄여 페이지 로드 시간 감소