6장 : HTTP (Hypertext Transfer Protocol)

웹의 짝궁 HTTP

커피숍에서 주문없이 자리에만 앉아 있으면 커피는 제공되지 않는다.

→ 요청(주문)이 없으면 응답(커피)이 없다.

 

Http(hypertext Transfer Protocol)??

웹 브라우저와 웹 서버간에 데이터를 주고 받기 위해 사용하는 프로코콜

하이퍼텍스트 형태의 데이터뿐만 아니라 이미지나 동영상 형식도 전달가능

 

특징

• 클라이언트/서버 모델을 따른다
  • 서로 관계를 맺고 있는 컴퓨터가 클라이언트와 서버라는 두 역할로 구분된다.
  • 클라이언트와 서버는 서로 HTTP 메세지를 주고 받으며 통신을 하는데 이걸 요청/응답 메세지라고 한다
    • 클라인언트 → 서버 (요청 : 커피 주문)
    • 서버→ 클라이언트 (응답: 커피)
• 상태를 가지지 않는다(stateless), 비연결성 프로토콜
  • 과거의 대화내용을 기억하지 않는다.
  • 첫번째 통신에서 데이터를 주고 받아도 두번째 통신에서는 첫번째 통신에서 주고 받은 데이터를 유지하지 않는다.

장점 : 데이터를 유지하는 비용이 없다

단점 : 요청 할 때마다 3방향 핸드쉐이크를 해야한다.

 

HTTP의 구조

요청 메세지의 구성요소 설명

 

 

	무엇을	어떤방식을 통해	어떻게
커피숍	아메리카노를	최신 커피머신으로	새로 만들어 주세요
HTTP 요청메세지	http.html	HTTP/1.1	POST

헤더

HTTP 메세지에 대한 추가 정볼르 제공하기 위해 사용

빈줄

헤더와 본문을 구별하기 위함

본문

요청 메세지에서는 채워져 있는 경우가 드뭄

사용되는 경우?  회원가입에 필요한 정보를 담기 위한 경우와 같은 경우에 채워져 있다. 

 

응답 메세지의 구성요소 설명

 

상태코드

클라이언트 요청에 따른 서버의 응답상태를 숫자로 나타낸것

참고:  https://joey0203.tistory.com/28

 

본문

요청에 관한 자원이 표시되는 곳

자원이 유형에 맞는 형식으로 표시 ( HTML 코드, 이미지, 동영상, ... )

 

GET vs. POST,  PUT vs. PATCH

요청 메서드의 종류

요청 메서드	역할
GET	데이터 조회
HEAD	헤더 조회
POST	데이터 추가
PUT / PATCH	데이터 수정
DELETE	데이터 삭제
OPTIONS	사용 가능 메서드 조회
CONNECT	양방향 연결시작
TRACE	특정 데이터의 경로 조회

HEAD :  HTTP 헤더 정보만 요청. 웹 서버가 정상적으로 작동하는지 등 서버 상태를 미리 확인 하기 위해 사용

PUT / PATCH

• PUT : 특정 데이터 전체를 교체할 때(수정할 때)
• PATCH : 특정 데이터의 일부를 교체할 때 (수정할 때)

      참고 그림

  

 

OPTION : 서버 측에서 제공 할 수 있는 메서드가 무서인지 알기 위해 사용

 ex) 클라이언트에서 option 메서드를 달아 요청을 보내면  서버에서 다음과 같이 응답  "Allow : GET, POST, HEAD"

 

안전한 메서드, 멱등성을 가진 메서드

안정성 : 클라이언트가 요청을 해도 서버의 자원(데이터)이 변하지 않는 특성을 의미

• 안정성 O  = GET, HEAD, OPTIONS 
• 안정성 X  =  POST, PUT, PATCH, DELETE

멱등성 (idempotent) : 연산을 여러 번 적용을 해도 결과가 달라지지 않는 특성

• 멱등성  O = GET, HEAD, PUT, DELETE, OPIONS
• 멱등성  X = POST, PATCH

 

 

헤더가 왜 중요할까?

TCP/IP 와 HTTP의 공통점은 바로 헤더가 있다는 점.

헤더는 데이터에 대한 추가 정보를 제공하며, 헤더가 커지면 덩달아 전체 데이터의 크기도 커지기 때문에 필요한 정보만 담는 것이 중요하다.

그러므로 헤더에는 해당 데이터에 대한 핵심 정보를 바로 파악할 수 있는 정보가 들어 있다.

 

HTTP 헤더의 특징

• 사람이 읽을 수 있는 형태로 작성
• 자유로운 형식
• 클라이언트와 서버가 필요한 만큼 헤더를 작성 가능
  • 각 정보의 위치가 정해져 있는 것 이 아니라 원하는 위치에 알아서 필요한 만큼 정보 입력 가능
  • 급식판이 아닌 뷔페에 가면 있는 큰 접시와 같은 느낌.

크롬 브라우저에서 직접 헤더 확인하기

F12 를 누른 후 -> Network 탭 선택 -> 보이는 데이터를 선택하 -> header 탭을 선택하면 확인 가능 

 

HTTP 헤더의 종류

<그림>

 

공통 헤더 (General header)

• 요청 메세지와 응답메세지가 모두 적용되는 헤더
• 대표적인 헤더 예시
  • Date - 메세지가 발생한 날짜와 시각을 표현
  • Cache-Control - 기존에 받은 데이터를 저장할지 여부를 정함

요청 헤더 (Request header)

• 요청 메세지를 작성
• 클라이언트에 대한 정보 또는 변경될 데이터에 관한 내용을 포함
• 대표적인 헤더 예시
  • Host - 데이터를 요청하는 서버의 호스트 이름
  • User-Agent - 클라이언트의 정보

응답 헤더 (Response header)

• 응답 메세지에 대한 정보를 담고 있는 헤더
• 대표적인 헤더 예시
  • 웹 서버의 종류(server) 등 서버에 대한 정보가 있음

엔티티 헤더 E(Entity header)

• 메세지 본문에  대한 정보를 포함하는 헤더
• 대표적인 헤어 예시
  • 본문의 길이 ( Content-length)
  • 자원의 미디어 타입(Content-type)
  • 본문의 언어(content-language)

(추가)

accept - 접두어 : 이 헤더는 이런 응답만 허용하겠다는 의미

 

상태 코드로 통신 상태 한눈에 파악하기 

상태코드란?

클라이언트의 요청에 따른 서버의 응답 상태를 세 자리 숫자로 나타낸것

예) Status Code : 200 

5 가지 클래스로 알아보는 상태코드

<사진>

 

1XX Class  조건부 응답, 웹 서버가 현재 요청을 받았으며 작업을 진해하고 있다는 의미

2XX Calss  클라이언트가 요청한 작업을 서버가 성공적으로 처리 했음을 의미

3XX Calss  리다이렉션 완료 응답, 요청을 완료하기 위해 재전송이 필요하는 의미

4XX Class 클라이언트 측에 오류가 있음을 의미

5XX Class 서버가 요청을 수행하지 못했을 을 의미

 

자주 쓰이는 상태코드 설명 여기 참고 : https://joey0203.tistory.com/28

보안을 책임지는 요소들 : SSL, TLS, HTTPS

HTTP의 한계, 보안

HTTP의 문제점

1. 누구나 볼 수 있게 암호화하지 않은 상태로 전송

2. 통신 상대를 확인 하지 않는다

 

이로 인한 대표적인 보안문제 -> 중간자 공격 (Man in the middle attack, MITM)

네트워크 통신 도중 중간자가 침입해 통신 내용을 도청하거나 조작하는 공격 기법.

ex) 중간에서 공인인증서 위조, 회원가입시 비밀번호 유출

 

해결책 -> HTTPS (Hypertext Transfer Protocol Secure)

보안을 책임지는 HTTPS

누구나 볼 수 있었던 메세지를 통신하는 당사자만 볼 수 있게 암호화

URL 이 https:// 로 시작하고 앞에 자물쇠 아이콘이 달린모습으로 우리에게 보인다.

SSL과 TLS는 무엇이 다를까?

HTTPS의 암호화를 담당하는 곳

-> SSL (Secure Socket Layer), 클라이언트와 서버가 서로 데이터를 암호화해 통신할 수 있게 돕는 보안 계층

 

TLS (Transport Layer Security) ? 

SSL 과 같은 보안 프로토콜, SSL 3.0 버전 다음 부터 등장한 이름

대다수의 보안 프로토콜이 TLS 사용

 

대칭키, 공개키로 안전하게 암호화하기

대칭키 

 

하나의 키로 암호화와 복호화를 둘 다 할 수 있는 암호화

 

장점 : 공개키 방식에 비해 속도가 빠르다

 

단점 : 서로 키를 안전하게 교환하기가 어렵다, 중간에서 누군가 키를 가로챌 위험 존재 

 

 

 

 

공개키 

 

대칭키 단점을 보완하기 위해 탄생

서로 다른 키 두 개로 암호화와 복호화를 한다.

사용하는 두개의 키는 공개키, 개인키, 이 두 키는 늘 한 쌍으로 동작

 

>  암호화 / 복호화 방법

상자를 빨간 (파란) 열쇠로 잠구면,
남아있는 파란 (빨간) 열쇠로만 상자를 열기 가능 

 

> 장점 : 대칭키보다 더 안전하게 데이터를 주고 받을 수 있다.

 

> 단점 : 암호화 과정이 복잡하여 속도가 느리다.

 

 

 

SSL 동작 과정 : 핸드셰이크, 세션, 세션종료

 

1 단계 : 서버에게 인사 = 서버에 데이터 전송
             → < 랜덤데이터 : "Hi",  현재 지원가능한 암호화 방식을 서버에 전달>

2 단계 : 클라이언트에 데이터 전송
             → < 랜덤데이터 : "Hello", 지원가능한 암호화 방식, 발급 받은 서버 인증서 >
                   *인증서 = CA(Certificate Authority) 에서 발급받은 문서 : 서버가 신뢰할 수 있는지 보장하는 문서  

3 단계 : 인증서 검증, 인증서 복호화

             → CA에서 공유하는 공개키로 인증서 복호화

4 단계 : 대칭키 생성 및 암호화하여 서버에 전달

             → 임시 대칭키 생성 ( 주고 받은 랜덤데이터를 이용 : "Hi" + "Hello"),  공개키로 암호화하여 서버에 전달

5 단계 : 비밀키로 복호화( 암호 해독 ) 

             → 서버가 가지고 있던 비밀키로 암호를 해독하여 클라이언트와 같은 임시 대칭키를 보유

6 단계 : 세션키 생성
             → 클라이언트와 서버가 가지고 있는 키를 일련의 과정을 거쳐서 세션키로 변경

 

SSL 은 두 개의 암호화 방식 (대칭키 기법, 공개키 기법)을 사용해 신뢰할 수 있는 데이터 통신환경을 제공

간략히 보는 HTTP 변천사

초기 HTTP 

GET 메소드만 지원

 

HTTP의 시작, HTTP/1.0

GET + HEAD, POST 지원

클라이언트와 서버간의 원활한 통신 가능

요청 마다 새로운 연결을 맺아야 한다.

표준,  HTTP/1.1

• 지속적 연결 상태 ( Persist Connection) :  요청마다 TCP 연결을 해야하는 문제(1.0 버전)를 해결, 메모리 자원 절약
• 파이프라이닝 ( Pipelining) : 응답이 도착해야만 다음 요청을 보낼수 있는 문제(1.0 버전)을 해결, 통신 지연문제 해결

더 빠르게,  HTTP/2

SPDY 프로토콜을 도입하여  성능 및 속도 개선

 

성능 및 속도를 개선한 방법

1. 스트림 다중화 (Multiplexed Streams)  한 연결 안에서 여러 개 의 메세지를 주고 받을 수 있게 됨

 

2. 서버 푸쉬(server push)  이용하여 클라인언트가 굳이 요청하지 않아도 서버에 미리 필요한 리소스를 푸쉬 가능

3. 바이너리 프레이밍 (binary framing)  HTTP 메세지를 더 작은 단위로 쪼개 010101 같은 바이너리 형태로 캡슐화 

       이로 인해서 스트림 다중화와 서버 푸쉬가 가능해졌다.

 

따끈한 새 버전, HTTP/3

HTTP/2 에서 해결하지 못한 문제를 해결

 

* TCP 는 데이터를 무조건 순서대로 처리

병목현상

 

 

(문제) HOLB(head of line blocking) :

중간에 일부 데이터가 손실되면 이를 해결하는 동안 다른 데이터 처리 불가능

병목현상 발생

 

 

 

 

 

 

 

해결책

QUIC ( Quick UDP Internt Connection) : TCP 가 아닌 UDP 기반에서 작동하는 프로토콜

• 빠른 속도 보장
  • TCP 의 3 방향 핸드쉐이크 생략
  • TLS 에서 암호화과정 생략
• 데이터 검증을 통한 신뢰성 보장

• 멀티플렉싱(Multiplexing) 기법 : 데이터를 독립적으로 다룸 -> TCP 에서의 병목현상 해결

 

• TLS 대체 : TLS 에서 데이터 암호화과정 생략 됨