저번에 다룬 OSI 7 layer model에서 Application 계층 프로토콜인 HTTP와 HTTPS에 대해 정리해보겠다.
HTTP란?
HTTP(HyperTextTransferProtocol) 은 HTML과 같은 하이퍼텍스트 문서를 전송하기 위한 애플리케이션 계층 프로토콜이다.
하이퍼 텍스트:
"하이퍼"는 그리스어 "hyper-"에서 유래한 접두사로, "위", "넘어", "초과"를 의미한다. 하이퍼텍스트는 웹 페이지와 같은 문서 내에서 다른 문서나 자원으로 연결되는 텍스트를 가리킨다. 예를 들어, 웹 사이트에서 하이퍼링크를 클릭하면 해당 링크가 가리키는 다른 페이지나 리소스로 이동할 수 있다. 이렇게 하이퍼링크를 통해 연결된 텍스트들을 하이퍼텍스트라고 한다.
쉽게 말해 HTTP는 웹 문서를 주고 받기 위한 통신 프로토콜이다.
HTTP는 요청(Request)과 응답(Response)으로 구성되어 있으며, 일반적으로 80번 포트를 사용한다. 예를 들어 '클라이언트가 웹 페이지에서 링크가 걸려있는 텍스트를 클릭(요청)하면 링크를 타고 새로운 페이지로 넘어간다(응답)'. 따라서 우리가 사용하는 웹 브라우저에서 인터넷 주소 맨 앞에 들어가는 http://가 바로 이 프로토콜을 사용해서 정보를 교환하겠다는 표시인 것이다(참고로 //는 멋을 위한 것으로 치지 않아도 동작에 영향이 없다). HTTP는 TCP/IP 기반이다.
구조
앞서 말했듯 HTTP는 요청과 응답으로 이루어져있다. 클라이언트가 서버에게 요청을 하고 서버가 클라이언트에게 응답을 하는 것이다.
HTTP는 통신을 HTTP 메시지라는 데이터 단위로 한다.
HTTP 메시지의 구조
HTTP 메시지 구조를 살펴보면 요청 메시지와 응답 메시지의 구조가 다른 것을 알 수 있다.
HTTP 요청(Request) 메시지 구조
-
요청 라인: 요청 URI(Uniform Resource Identifier), 요청 방법(GET, POST, PUT, DELETE 등), HTTP 버전(HTTP/1.0, HTTP/1.1, HTTP/2, HTTP/3)등을 담고 있다.
-
헤더:
key:value형태로 구성된 추가정보들이다. 주로 다음의 내용들이 들어간다.- Host: 요청이 전송되는 target의 host url(ex, google.com)
- User-Agent: 요청을 보내는 클라이언트의 대한 정보: 예를 들어, 웹브라우저에 대한 정보.
- Accept: 해당 요청이 받을 수 있는 응답(response) 타입.
- Connection: 해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분.
- Content-Type: 해당 요청이 보내는 메세지 body의 타입. 예를 들어, JSON을 보내면 application/json.
- Content-Length:메세지 body의 길이.
-
빈 줄: 헤더의 끝을 나타내며 헤더와 바디를 구분한다.
-
바디: 요청을 하는 실제 메시지 내용(데이터)이 담긴다. GET 방식은 바디에 아무것도 담기지 않는다.
HTTP 응답(Response) 메시지 구조
- 상태 라인: 상태 코드(Status Code; ex,
200), 상태 텍스트(Status Text; ex, Not Found), HTTP 버전(HTTP/1.0,HTTP/1.1,HTTP/2,HTTP/3)등을 담고 있다. - 헤더: User-Agent가 Server헤더가 들어가는 부분을 제외하면 요청 메시지의 헤더와 동일하다.
- 빈 줄: 헤더의 끝을 나타내며 헤더와 바디를 구분한다.
- 바디: 응답을 하는 실제 메시지 내용(데이터)가 담긴다. 만약 데이터를 전송할 필요가 없으면 아무것도 담기지 않는다.
HTTP 요청 방식(Request Method)
GET
- 클라이언트는 GET 요청을 사용하여 서버로부터 리소스를 요청하며, 주로 데이터를 가져오는 데 사용된다.
- GET 요청은 서버의 상태를 변경하지 않으며, 요청된 리소스에 대한 응답을 클라이언트에게 돌려준다.
POST
- 클라이언트는 POST 요청을 사용하여 서버에 새로운 데이터를 제출하거나 리소스를 생성하며, 주로 양식(form) 데이터를 제출하거나 새로운 리소스를 생성하는 데 사용된다.
- POST 요청은 서버에 상태 변경(새로운 데이터 추가)을 일으킬 수 있다.
PUT
- 클라이언트는 PUT 요청을 사용하여 지정된 URI에 새로운 데이터를 저장하거나 업데이트하며, 주로 리소스의 전체 내용을 업데이트하는 데 사용된다.
- 클라이언트가 보낸 데이터는 서버의 리소스를 대체한다.
PATCH
- 클라이언트는 PATCH 요청을 사용하여 리소스의 일부를 수정한다.
- PUT과 마찬가지로 리소스를 업데이트하지만, PATCH는 전체 리소스를 대체하는 대신 변경할 부분만을 보낸다.
- 대규모 데이터를 업데이트하는 데 효율적이다.
DELETE
- 클라이언트는 DELETE 요청을 사용하여 지정된 URI의 리소스를 삭제한다.
- 서버에서는 해당 리소스를 제거하고 성공적으로 삭제되었음을 클라이언트에게 알린다.
여러 요청 방식이 있지만 대부분 GET과 POST만 사용하는 추세이다.
HTTP 상태코드(Status Code)
200 OK
- 클라이언트의 요청이 성공적으로 처리되었음을 나타낸다.
301 Moved Permanently
- 요청한 리소스가 새로운 위치로 영구적으로 이동되었음을 나타낸다.
- 주로 리소스의 URL이 변경되었을 때 사용되며, 클라이언트에게 새로운 URL로 리디렉션하도록 요청하여 브라우저가 자동으로 리디렉션한다.
400 Bad Request
- 클라이언트의 요청이 잘못되었거나 서버가 요청을 이해하지 못하는 경우이다.
- 예를 들어, 잘못된 구문을 갖는 요청이나 필수 매개변수가 누락된 요청 등이 있을 수 있다.
401 Unauthorized
- 클라이언트가 인증되지 않았거나 인증 정보가 유효하지 않은 경우이다.
- 이는 보호된 리소스에 접근하려는 클라이언트가 올바른 인증 정보를 제공하지 않은 경우에 반환된다.
- 주로 로그인을 하지 않은 경우 발생한다.
403 Forbidden
- 클라이언트가 요청한 리소스에 접근할 권한이 없는 경우이다.
- 서버가 클라이언트의 요청을 이해했지만 권한이 없기 때문에 요청을 거부할 때 사용도된다.
- 주로 로그인을 했지만 접근할 수 없는(관리자 영역 등) 영역에 접근했을 때 발생한다.
404 Not Found
- 요청한 리소스가 서버에서 찾을 수 없는 경우이다.
- 클라이언트가 잘못된 URL을 요청했거나, 요청한 리소스가 삭제되었거나 이동되었을 때 반환된다.
500 Internal Server Error
- 서버가 요청을 처리하는 동안 내부적인 오류가 발생한 경우이다.
- 일반적으로 서버 측에서 처리할 수 없는 예기치 않은 문제가 발생한 경우에 반환된다.
- 백엔드 개발을 하면 가장 자주 만나는 오류이다 😥
HTTP의 특징
1. 비연결성(Connectionless)
HTTP의 비연결성은 웹 통신에서 한 번의 요청과 응답이 완료되면 그 연결이 닫히는 개념이다. 다시말해 클라이언트가 서버에 요청을 보내면 서버가 해당 요청에 대한 응답을 보내고 연결을 종료한다는 것이다.
비연결성의 장점
- 자원 절약
매번 연결을 유지하는 대신, 한 번의 요청과 응답 후 연결을 닫음으로써 서버의 리소스를 효율적으로 관리할 수 있다.- 더 많은 클라이언트 지원
매번 연결을 유지하는 것보다 비연결성을 사용하면 서버가 동시에 더 많은 클라이언트를 처리할 수 있다.- 빠른 요청 및 응답
비연결성을 통해 요청과 응답이 빠르게 처리된다. 연결을 유지할 필요가 없으므로 데이터 전송이 빨라진다.
비연결성의 단점
- 클라이언트가 여러 개의 리소스를 요청할 때마다 매번 새로운 연결을 설정해야 하므로 오버헤드가 발생할 수 있다.
- 이를 해결하기 위해 HTTP/1.0 버전부터
Keep-Alive기능이 도입되어 단일 연결을 유지하고 여러 요청과 응답을 처리할 수 있게 되었다.
HTTP 성능을 향상 시키기 위한 기술
HTTP Keep-Alive
HTTP 연결 시 일정시간 동안 요청을 유지할 수 있도록 사용하는 HTTP 확장 기능이다. 클라이언트에서 HTTP 요청을 보낼 때 연결 헤더에 Keep-Alive를 추가해서 보내면 서버에서 연결을 유지할 시간을 Keep Alive 헤더에 추가하여 응답한다.
HTTP의 기본적인 동작 방식은 클라이언트가 요청을 보내면 서버가 해당 요청에 응답하고 연결을 종료하는 것이다. 그러나 Keep-Alive를 사용하면 연결을 닫지 않고 유지하며, 클라이언트가 추가 요청을 보낼 때마다 같은 연결을 재사용하여 효율적으로 데이터를 주고 받을 수 있다.
이 기능을 사용하면 매번 새로운 연결을 설정하는 오버헤드를 줄일 수 있으며, 특히 웹 페이지에 포함된 다수의 리소스를 가져오는 경우에 유용하다. 또한 Keep-Alive를 통해 지속적인 연결이 가능해지므로 웹 페이지 로딩 시간을 단축시키고 성능을 향상시킬 수 있다.
HTTP Piplelining(파이프라이닝)
클라이언트가 서버로 여러 개의 요청을 한 번에 보내고, 서버가 그 요청에 대한 응답을 순서대로 반환하는 기술이다. 일반적으로 HTTP는 요청과 응답 사이에 순차적으로 연결이 이루어지기 때문에, 하나의 요청에 대한 응답을 받은 후에야 다음 요청을 보낼 수 있다. 그러나 파이프라이닝을 사용하면 이전 요청의 응답을 기다리지 않고도 여러 요청을 한 번에 보낼 수 있다.
이를 통해 네트워크 지연을 줄이고 성능을 향상시킬 수 있지만 파이프라이닝은 서버나 클라이언트에서 모두 지원되어야만 동작한다. 또한, 순차적으로 응답이 도착하지 않을 수 있으므로 클라이언트는 응답의 순서를 보장받지 못할 수 있다.
2. 무상태성(Stateless)
HTTP의 무상태성은 HTTP 프로토콜이 클라이언트와 서버 간의 통신을 처리할 때 상태 정보를 유지하지 않는다는 개념이다. 각각의 요청은 독립적으로 처리되며 이전 요청과는 관련이 없다. 서버는 클라이언트의 상태나 이전 요청에 대한 정보를 유지하지 않고, 각 요청을 독립적으로 처리한다.
무상태성의 장점
- 단순성
서버가 각각의 요청을 개별적으로 처리하기 때문에 서버 및 클라이언트의 구현이 단순해진다.- 확장성
상태를 유지하지 않기 때문에 서버는 수많은 클라이언트 요청을 효율적으로 처리할 수 있다.- 신뢰성
서버나 네트워크 장애가 발생해도 클라이언트와 서버 간의 통신은 이전 요청과는 독립적으로 처리되므로 상태 복구가 필요하지 않다. 즉, 특정 서버가 문제가 생겨도 다른 서버가 응답하는 데에 문제가 없다.
무상태의 단점
상태 정보가 필요한 경우에는 추가적인 처리가 필요하다.
예를 들어 사용자 인증 정보나 세션 정보를 유지해야 할 경우에는 클라이언트와 서버 간의 상태를 관리해야 하므로 상태 정보를 관리하기 위해 쿠키나 세션 등의 메커니즘을 사용해야한다.
HTTP 버전별 특징
HTTP/0.9
- 가장 초기의 버전으로, 1991년에 등장했다.
- 단순한 기능만을 제공하며, 단일 요청 방식만 지원한다.
- 헤더를 사용하지 않고, HTML 문서만을 전송하는 용도로 사용됐다.
HTTP/1.0
- 1996년에 등장한 더 발전된 버전이다.
- 헤더와 여러 요청 메서드(GET, POST 등)를 도입했다.
- 지속적인 연결을 위한
Keep-Alive기능을 도입했다.- 하지만 파이프라이닝의 기능은 지원하지 않았다.
HTTP/1.1
- 1997년에 나온 가장 널리 사용되는 버전이다.
- 지속적인 연결을 위한 Keep-Alive를 기본으로 사용한다.
- 파이프라이닝을 지원하여 여러 요청을 동시에 보낼 수 있다.
- 호스트 헤더, 캐시 관리, 커넥션 관리 등의 기능이 추가되었다.
HTTP/2
- 2015년에 등장한 현재의 주요 표준이며 이전 버전과 비교하여 성능 및 보안을 향상시켰다.
- 텍스트 프로토콜이 아닌 이진 프로토콜로 만들어 헤더 압축 및 병렬 전송을 지원한다.
- 한 번에 여러 요청 및 응답을 처리할 수 있는
다중화기능을 제공한다.
다중화(Multiplexing)
다중화는 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 동시에 처리하는 기술이다. 하나의 연결에서 여러 요청과 응답을 병렬로 전송하여 네트워크 사용을 최적화하고 성능을 향상시킨다.
위에 나온 파이프라이닝과의 차이점은 아래와 같다.
파이프라이닝: 하나의 TCP 연결을 통해 여러 개의 요청을 순차적으로 보내고, 서버는 요청에 대한 응답을 순서대로 반환하는 기술
다중화: 하나의 TCP 연결을 통해 여러 개의 요청과 응답을 동시에 처리하는 기술
즉, 파이프라이닝은 하나의 연결을 통해 여러 요청 순차적으로 보내고 순차적으로 응답을 받고, 다중화는 하나의 연결을 통해 동시에 여러개의 요청과 응답이 가능하다.
HTTP/3:
- 2020년에 공식 승인된 최신 버전이다.
- TCP 대신 UDP 기반의
QUIC(Quick UDP Internet Connections)프로토콜을 사용하여 성능을 향상시켰다.- QUIC는 HTTP 연결에 대해 보다 빠른 설정과 낮은 대기 시간을 제공하도록 설계되었다.
연결 설정 및 향상된 오류 복구 기능을 제공한다.
HTTPS란?
HTTPS(HyperText Transfer Protocol Secure)는 이름에서 알 수 있듯 보안이 강화된 HTTP 프로토콜이다. HTTPS는 데이터의 안전한 전송을 보장하기 위해 OSI 4번째 계층인 Transport 계층의 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용한다. 이를 통해 일반적으로 웹 서버와 웹 브라우저 간의 통신을 암호화하여 중간자 공격과 데이터 변조를 방지한다.
HTTPS의 특징
- 데이터 보안
데이터가 암호화되므로 중간자 공격으로부터 보호된다.- 신원 인증
SSL 또는 TLS 인증서를 통해 웹 사이트의 신원을 확인할 수 있다.- 검색 엔진 최적화(SEO)
Google 등의 검색 엔진에서 HTTPS를 사용하는 웹 사이트를 우선적으로 취급한다.- 신뢰성
사용자들은 HTTPS를 통해 안전한 연결을 사용할 수 있음을 인식하고 있으므로 신뢰도가 높다.
SSL/TLS 란?
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 모두 네트워크 통신에서 보안을 제공하기 위한 프로토콜이다. TLS는 SSL의 후속 버전이다.
SSL (Secure Sockets Layer)
SSL은 웹 브라우저와 서버 간의 보안된 통신을 위해 처음에 넷스케이프(Netscape)에 의해 개발된 보안 프로토콜이다. SSL은 공개키 암호화 시스템을 사용하여 데이터를 암호화하고, 디지털 인증서를 통해 서버의 신원을 확인한다. SSL은 여러 버전이 있으며, SSL 3.0이 가장 널리 사용되었다. 그러나 SSL 3.0은 보안 취약점이 발견되어 안전하지 않다는 평가를 받았고, 이를 해결하기 보완하기 위해 TLS가 개발되었다.
TLS (Transport Layer Security)
TLS는 SSL의 후속 버전으로, SSL의 보안 취약점을 보완하고 기능을 확장하여 보다 안전하고 강력한 보안을 제공하며 안전한 통신을 위한 표준 프로토콜이다. TLS는 공개키 암호화, 대칭키 암호화, 디지털 서명 등 다양한 보안 기술을 사용하여 데이터를 암호화하고 인증한다. TLS는 여러 버전이 있으며, 주요 버전으로는 TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 등이 있다. 각 버전은 보안 강화와 성능 향상을 위한 업데이트가 이루어졌다.
일반적으로 현재의 웹 보안은 SSL보다는 TLS를 사용한다. 위에서 정리한 것처럼 SSL과 TLS는 암호화 프로토콜이므로 SSL과 TLS를 잘 이해하려면 암호화 방식에 대해 잘 알아야한다.
1. 대칭키 암호화 방식
대칭키 암호화는 데이터를 암호화하고 해독하는 데에 동일한 키를 사용하는 암호화 방식이다. 즉 암호화된 데이터를 해독하기 위해서는 동일한 키가 필요하다. 이러한 키를 공유하는 것이 중요하다.가장 널리 사용되는 대칭키 알고리즘에는 AES(Advanced Encryption Standard), DES(Data Encryption Standard)등이 있다.
장점
- 속도가 빠름
대칭키 알고리즘은 암호화와 해독이 빠르고 효율적이다. 따라서 대용량 데이터의 암호화나 해독에 유용하다. - 간단함
대칭키 알고리즘은 구현이 간단하며, 키 관리가 비교적 쉽다.
단점
- 키 관리의 어려움
대칭키를 안전하게 공유하는 것이 어렵다. 대칭키를 공유하기 위해서는 안전한 채널이 필요하며, 키 관리에 대한 보안적인 문제가 발생할 수 있다. - 인증의 부족
대칭키 암호화는 통신 상대의 신원을 인증하지 않기 때문에중간자 공격(man-in-the-middle attack)과 같은 보안 공격에 취약하다. - 확장성의 한계
대칭키 암호화는 통신하는 모든 사용자가 동일한 키를 사용해야 하므로, 대규모 네트워크에서의 확장성이 제한될 수 있다.
2. 비대칭키(공개키) 암호화 방식
비대칭키 암호화는 암호화와 해독에 서로 다른 두 개의 키를 사용하는 암호화 방식이다. 공개키(Public Key)와 비밀키(Private Key)라는 두 개의 키를 사용하며, 공개키는 누구나 알 수 있지만 비밀키는 소유자만이 알고 있다.
데이터를 암호화할 때는 공개키로 암호화하고, 암호화된 데이터를 해독할 때는 비밀키를 사용한다. 대표적인 비대칭키 알고리즘에는RSA,ECC(Elliptic Curve Cryptography)등이 있다.
- 서버가 공개키와 비공개키를 생성 후 공개키를 공개한다.
- 클라이언트가 서버의 공개키로 평문을 암호화해서 서버에게 보낸다.
- 서버는 개인키로 복호화 하여 내용을 확인한다.
장점:
- 키 교환의 용이성
비대칭키 방식은 키 교환의 어려움을 해결한다. 공개키를 공개하여 누구나 이를 사용하여 메시지를 암호화할 수 있으므로, 키를 안전하게 교환할 필요가 없다. - 인증의 용이성
공개키를 통해 암호화된 메시지를 해독할 수 있는 사용자는 해당 공개키의 소유자로 인증된다. 이를 통해 송신자와 수신자 간의 인증이 가능하다. - 전자 서명
비대칭키 방식은 전자 서명에 이용될 수 있다. 개인 키로 문서에 서명하여, 해당 서명이 소유자에 의해 생성되었음을 증명할 수 있다.
단점
- 속도가 느림
비대칭키 암호화는 대칭키 암호화보다 속도가 느리다. 따라서 대용량 데이터를 암호화하거나 서명하는 데에는 시간이 더 많이 소요될 수 있다. - 보안 위험
비대칭키 방식은 공개키를 사용하여 암호화되었더라도, 중간자 공격과 같은 공격에 취약할 수 있다.
3. 전자 서명
전자 서명은 전자적으로 생성된 서명으로, 데이터의 무결성을 보장하고 인증하기 위해 사용된다. 전자 서명은 보통 공개키 암호화 기술을 기반으로 하며, 데이터의 무결성을 보장하는 데 사용된다.
과정
- 송신자가 자신의 공개키와 비공개키를 생성한다.
- 송신자가 자신의 공개키를 공개한다.
- 수신자가 송신자의 공개키를 가져온다.
- 송신자가 평문 메시지와 평문메시지를 자신의 비공개키로 암호화한 메시지를 같이 담아서 수신자에게 보낸다.
- 수신자가 송신자로부터 받은 암호화된 메시지를 송신자의 공개키로 복호화한 뒤 평문 메시지와 같은지 확인한다.
- 만약 같다면 송신자가 진짜임을 확인할 수 있고, 같지 않다면 가짜임(해커 등)을 확인할 수 있다.
HTTPS 암호화 과정
HTTPS는 SSL 핸드셰이크 과정을 통해 연결을 시작한다.
SSL 핸드셰이크 과정은 클라이언트(브라우저)와 서버 간의 HTTPS 연결을 설정하기 위한 초기 단계다. 이 과정은 클라이언트와 서버 간의 암호화 통신을 시작할 수 있도록 신분을 확인하고 필요한 정보를 교환하는 과정이다.
- Client Hello: 클라이언트가 서버에 접속하고 SSL/TLS 연결을 시작하기 위해 전송하는 메시지로, 클라이언트가 지원하는 SSL/TLS 버전, 암호화 알고리즘 목록, 임의의 난수 등의 정보를 포함한다.
- Server Hello: 서버는 클라이언트의 요청에 응답하여 SSL/TLS 연결 설정에 필요한 정보를 클라이언트에 제공한다. 이 메시지에는 서버가 선택한 SSL/TLS 버전, 암호화 알고리즘, 임의의 난수, 서버의 디지털 인증서 등의 정보가 포함된다.
- 인증: 클라이언트는 서버의 디지털 인증서를 받아서 인증서의 유효성을 확인하고, 신뢰할 수 있는 CA에 의해 서명되었는지를 확인한다.
- Premaster Secret 생성: 클라이언트는 서버의 공개키를 사용하여 세션 키인 Premaster Secret을 생성하고 이를 서버에게 전송한다.
- 세션 키 생성: 서버는 Premaster Secret을 복호화하여 세션 키를 생성하고 이를 사용하여 공유 비밀키인 Master Secret을 생성한다. 이로부터 세션 키가 생성되고 이를 사용하여 향후 통신에 사용된다.
- SSL 핸드셰이크 완료: SSL 핸드셰이크가 완료되면 클라이언트와 서버는 안전한 HTTPS 연결을 구축하고, 이후의 모든 데이터 교환은 암호화되어 전송된다.
세션키
세션 키(Session Key)는 대칭 암호화에서 사용되는 키로, 통신 세션 동안 메시지를 암호화하거나 복호화하는 데 사용된다.
참고:
- 기술면접대비 CS전공 핵심 요약집(이수진, 길벗출판사)
- https://developer.mozilla.org/ko/docs/Web/HTTP
- https://developer.mozilla.org/ko/docs/Glossary/QUIC
- https://velog.io/@teddybearjung/HTTP-%EA%B5%AC%EC%A1%B0-%EB%B0%8F%ED%95%B5%EC%8B%AC-%EC%9A%94%EC%86%8C
- https://namu.wiki/w/%ED%95%98%EC%9D%B4%ED%8D%BC
- https://rachel-kwak.github.io/2021/03/08/HTTPS.html
- https://blog.naver.com/chodahi/221406287669
- https://yozm.wishket.com/magazine/detail/1852/
- 생활코딩
