CS 강의 10. HTTP/HTTPS

출처 : 내일배움캠프

 

1. HTTP

1 - 1. HTTP 개요

Hypertext Transfer Protocol

- 서로 다른 시스템들 사이에서 통신을 주고받게 하는 가장 기본적인 프로토콜

- 서버에서 브라우저로 데이터를 전송하는 용도로 가장 많이 사용

- 전송되는 요청/ 응답 정보가 기본적을 암호화되지 않아 보안정보 도난의 위험이 있다

 

IP가 네트워크 계층, TCP가 전송 계층 프로토콜이라면 HTTP은 어플리케이션 계층 프로토콜이다

 

~ 클라이언트와 서버 간 자원을 교환하기 위한 TCP/IP 기반 통신 프로토콜

1) 요청 정보

2) 응답 정보

특징

1) 단방향성 : 서버가 먼저 응답을 보낼 수 없고 클라이언트가 요청을 보내야만 응답할 수 있다(HTTP 2 이전)

2) 비연결성 : 클라이언트의 요청으로 서버와 연결된 후, 요청에 대한 응답 데이터를 전송하면 연결을 종료한다. 따라서 실시간 통신을 할 수 없다

 

문제점

- HTTP는 평문 통신이기 때문에 도청이 가능하다

- 통신 상대가 검증된 상대인지 확인하지 않기 때문에 위장이 가능하다

- 완전성을 증명할 수 없기 때문에 변조가 가능하다

 

HTTP 버전별 발전 ~ 1.0 > 1.1 > 2.0 > 3.0 : 현재 1.1이 가장 많이 사용됨

HTTP 1의 한계

연결을 생성해도 일회용(요청별로 한번밖에 사용할 수 없다)으로만 활용 가능

 

1.1이 되며 개선된 점

지정한 Timeout동안 연결을 해제하지 않도록 해서 지정한 시간동안 재사용 가능하도록 한 방식

 

HTTP 2의 핵심 개선점

1) Head Of Line Blocking 문제 해결

HTTP 1에서는 병렬로 요청을 수신해도 동시에 응답했어야 하는 문제가 있었다. 이를 HTTP 2에서 요청을 순서 상관없이 처리하도록 개선했다

2) Server Push

HTTP 2에서는 연결 생성 후 클라이언트 요청 없이도 서버가 응답해줄 수 있다

 

~ HTTP 2의 점유율이 현재 40% 정도로, HTTP 3에서는 아직 지원하는 곳이 많지 않다 -> 네이버, 인스타그램, 페이스북 등

~ HTTP 3은 TCP가 아닌 UDP 기반이다

 

+ 채팅같은 실시간 통신이 필요한 경우 일반적으로 웹소켓 프로토콜을 따른다

- 웹소켓 프로토콜은 TCP 기반 통신 프로토콜이며, 데이터 전송이 끝나고 연결을 해제하지 않고 양방향 통신이 가능하다

- 웹소켓이 나오기 이전엔 HTTP와 폴링, 롱폴링, 스트리밍 등 실시간 통신처럼 보일 수 있게끔하는 방식을 사용

- 웹소켓의 구현체를 뜯어보면, 웹소켓을 지원하지 않는 환경에서는 HTTP의 롱폴링 등으로 활용하기도 한다

2 - 2. HTTP 메서드

HTTP 메서드는 클라이언트가 웹 서버에게 요청할 때 그 요청의 목적과 종류를 알리는 수단이다

 

주요 메서드

1) GET : 리소스 조회시 사용하며, 서버에 전달하고 싶은 데이터는 쿼리를 통해 전달한다. 메세지 바디를 사용해 데이터를 전달할 수 있으나, 지원하지 않는 곳이 많아 권장하지 않는다

2) POST : 주로 리소스를 새롭게 생성할 때 사용하며, 서버에 전달하고 싶은 데이터는 메세지 바디를 통해 전달한다

3) PUT : 리소스가 있으면 대체하고 리소스가 없으면 생성한다. ~ 데이터를 덮어쓴다 

4) PATCH : PUT과 마찬가지로 리소스를 수정할 때 사용하지만, PATCH는 리소스를 일부분만 변경할 때 사용

5) DELETE : 리소스를 제거할 때 사용

 

메서드 속성

1. 안전 : 계속 호출해도 리소스를 변경하지 않는다

 

2. 멱등 : 동일한 요청을 여러 번 보내도 결과는 똑같다 ~ GET, PUT, DELETE는 멱등하지만, POST, PATCH는 멱등하지 않다

 

3. 캐시가능 : 응답 결과를 서버에 캐시해 사용해도 되는 메서드 ~ GET, HEAD, POST, PATCH가 캐시가능하지만 구현이 어려워 실제로는 GET, HEAD에 주로 캐시를 사용한다

2 - 3. HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태 또는 결과를 응답에서 알려주기 위한 정보

 

종류

1-- : 요청이 수신되어 처리중

2-- : 처리 성공

~ 200 : 요청 성공

~ 201 : 요청 성공해서 새로운 리소스 생성

~ 202 : 요청이 접수되었으나 처리가 완료되지 않음

~ 204 : 서버가 요청을 성공적으로 수행했으나, 응답 페이로드 본문에 보낼 데이터가 없다

3-- : 추가 요청이 필요하다 ~ 요청을 완료하려면 추가 행동이 필요 : 일반적으로 리다이렉션 처리

~ 301 : URL 일시 이동 ~ 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다

~ 302 : URL 영구 이동 ~ 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다

~ 303 : 리다이렉트 시 요청 메서드가 GET으로 변한다

~ 304 : 캐시를 목적으로 사용

~ 307 : 리다이렉트 시 요청 메서드와 본문 유지(302와 다른 점으로, 비교 가능하다), 요청 메서드를 변경하면 안된다

~ 308 : 리다이렉트 시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

4-- : 잘못된 클라이언트의 요청

~ 400 : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없다

~ 401 : 클라이언트가 해당 리소스에 대한 인증이 필요하다

~ 403 : 서버가 요청을 이해했으나 승인을 거부했다

~ 404 : 요청 리소스를 찾을 수 없다

5-- : 서버가 요청에 응답할 수 없는 상태

~ 500 : 서버 문제로 오류 발생

~ 501 : 서버에 해당 기능이 없음

~ 502 : 게이트웨이(서로 다른 프로토콜을 연결해주는 장치)가 잘못된 프로토콜을 연결하거나, 어느 쪽 프로토콜에 문제가 있어 통신이 제대로 되지 않은 상황

~ 503 : 서비스 이용 불가(서버 다운)

2 - 4. HTTP 통신흐름

브라우저에 naver.com을 타이핑(요청을 보내면) 일어나는 일

1. URL 주소 중 도메인 네임 부분을 DNS 서버에 검색하고, DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소로 찾아온다

2. HTTP 프로토콜을 사용해 페이지 URL 정보와 찾아온 IP 주소를 포함하는 HTTP 요청 메세지를 생성하고, 생성된 HTTP 요청 메세지는 TCP/IP 프로토콜을 사용해 인터넷 망을 통해 해당 IP 주소 컴퓨터로 전송된다

3. HTTP 요청 메세지를 받은 컴퓨터(서버)는 웹 페이지 URL 정보 중 PATH와 HTTP 메서드에 맞는 응답 작업을 수행한다

4. 생성된 응답 데이터는 또 다시 HTTP 프로토콜을 사용해 HTTP 응답 메세지로 만들어지고 TCP/IP 프로토콜을 사용해 인터넷 망을 통해 요청했던 컴퓨터(클라이언트)로 전송된다

5. 도착한 HTTP 응답 메세지는 웹 브라우저에 의해 브라우저 렌더링 과정을 거쳐 화면에 출력되어 사용자가 볼 수 있게 된다

 

+ 브라우저 렌더링 과정

1. HTML, CSS를 파싱해 DOM Tree, CSSOM Tree를 만든다

2. 두 Tree를 결합해 Rendering Tree를 만든다

3. 렌더링 트리에서 각 노드의 위치와 크기를 계산한다

4. 계산된 값을 이용해 각 노드를 화면 상 실제 픽셀로 변환하고, 레이어를 만든다

5. 레이어를 합성해 실제 화면에 출력한다

3. HTTPS

3 - 1. HTTPS 개요

Hypertext Transfer Protocol Secure

- HTTP는 전송되는 요청/ 응답 정보가 기본적으로 암호화 되지 않아 보안정보 도난의 위험이 있다

- 이를 위해 SSL을 사용한다

 

TLS : 전송 계층 보안

- SSL의 더욱 안전한 버전, DigiCert에서 SSL을 구입할 시 최신의 TLS 인증서를 얻을 수 있다

- 웹사이트가 SSL/TLS 인증서로 보호되는 경우 HTTPS가 URL에 표시된다. 사용자는 브라우저 표시줄의 자물쇠 기호를 클릭해 발급기관 및 웹사이트 소유자의 상호를 포함한 인증서 세부 정보를 볼 수 있다.

=> 웹사이트가 SSL/TLS 인증서로 보호되는 경우 HTTPS가 URL에 표시된다

 

SSL : Secure Sockets Layer ~ Netscape에서 웹 서버와 웹 브라우저 간 보안을 위해 만든 프로토콜, 대칭키와 비대칭키 기반으로 사용한다

1) 대칭키 방식

- 서버와 클라이언트가 같은 키를 사용하는 방식

- 암호화 및 복호화에 드는 비용이 적으나, 키를 상대방과 함께 사용해야 하므로 전달이 상대적으로 어렵다

 

2) 비대칭키 방식

- 암호화와 복호화 간 서로 다른 키를 사용하는 방식

- 수학적인 공식으로부터 만들어진 한 쌍의 키로 구성되며, 하나는 외부 공개 키로 사용하고 다른 하나는 개인 키로 사용한다

- 공개 키로 암호화하면 반드시 같은 쌍 개인 키로만 복호화가 가능하고, 개인 키로 데이터를 암호화하면 해당 공개 키로만 복호화할 수 있다

- 보안이 뛰어나지만, 구현이 어렵고 암복호화 속도가 느려진다

- 주로 전자서명과 메세지 송신에 사용된다

~ 전자서명 : 내 공개 키로 암호화된 것을 내 개인키로 복호화해 본인인증할 수 있다

~ 메세지 송신 : 상대방의 공개 키로 암호화해 보내면 개인 키를 갖고 있는 상대방만 복호화할 수 있어 안전하게 메세지 교환이 가능하다

 

HTTPS 프로세스

- 대칭 키와 공개 키/개인 키를 사용하는 방법 : 총 3가지의 키를 사용하는 방법

- 서버의 공개 키를 통해 클라이언트가 대칭 키를 암호화한다 => 서버는 암호화된 대칭 키를 개인 키로 복호화하므로 암호문 통신이 가능하다

 

1) 클라이언트에서 서버로 접속 요청

2) 개인 키를 가지고 있는 서버가 암호화할 수 있는 공개 키를 클라이언트에게 전달

3) 클라이언트는 자신의 대칭 키를 서버의 공개 키로 암호화

4) 클라이언트는 서버의 공개 키로 암호화한 대칭 키를 서버에 전달

5) 서버는 암호화된 대칭 키를 전달받아 자신의 개인 키로 복호화 ~ 서버도 암호화된 대칭 키를 가지게 된다

6) 서버는 복호화된 대칭 키 원본을 가지고 클라이언트와 암호문으로 통신

3 - 2. SSL Handshake

- HTTPS 연결할 때 추가로 인증하는 방식

- 대칭 키/ 비대칭 키 방식을 모두 사용해 요청/응답 정보를 모두 사용해 요청/ 응답 정보를 모두 암호화하며, 외부 인증기관(외부 서버)가 사이트가 신뢰가능한지 보증한다

 

1) 웹 서버가 CA(보증기관)으로부터 보증서를 발급받는다

2) 웹 서버는 CA에 자신의 도메인 정보와 서버 측 공개 키를 보낸다

3) CA는 받은 두 데이터를 자신의 개인 키로 암호화한 CA 인증서를 서버로 보낸다

4) 클라이언트가 요청을 보내 서버와 TCP 연결한다

5) 서버는 브라우저가 보낸 Ciper Suite 중 하나를 고르고, 자신의 SSL/TLS 프로토콜 버전을 브라우저에게 알리며, 서버 자신의 도메인에 대한 CA 인증서를 보낸다

6) 브라우저는 내장된 CA 공개 키를 이용해 CA 인증서를 복호화하며 인증서가 유효한지 검증한 후, 서버 츠그이 공개 키를 얻는다

7) 브라우저는 추후 서버와 통신할 때 암호화룰 위해 필요한 대칭 키를 만들고, 그 대칭 키를 사이트 공개 키로 암호화해 서버로 보낸다

8) 서버는 자신의 개인 키를 사용해 암호화된 것을 복호화해 사용자 대칭 키를 얻는다

9) 이렇게 얻은 대칭 키를 활용해 서버와 클라이언트가 서로 데이터를 안전하게 암복호화해 지속적으로 통신할 수 있다