오늘은 HTTP에 대해 알아보고 이에 관련된 지식에 대해 정리하려고 합니다.
HTTP가 뭐예요?
HTTP는 서버와 클라이언트간의 데이터(자원)을 주고 받을 때 사용하는 하나의 통신 규약을 의미합니다. 그래서 Hypertext Transfer Protocol이라고 부릅니다.
HTTP는 지난 포스팅에서 다루었던 TCP/IP 4계층 내 응용계층에 수많은 프로토콜 중에 하나입니다. 클라이언트와 서버는 HTTP 메세지를 통해 서로 데이터를 주고받죠.
어떻게 자원을 주고 받을까?
클라이언트는 서버에게 url이나 다른 것을 통해 요청(Request) 을 하면 서버는 Json, Plain Text, XML 등 다양한 문서를 통해 클라이언트에게 응답(Response) 을 합니다.
요청(Request)
클라이언트가 서버에게 요청을 할 때, 다음과 같은 요청 HTTP 메세지를 보내게 됩니다.
헤더 이후에 한줄 띄고 작성된 정보는 엔티티(Entity)라고 하며 요청에 대한 페이로드(부가물)라고 합니다.
💡 HTTP 메소드
요청을 할때는 다음과 같은 HTTP 메소드를 사용합니다.
- GET : 리소스를 가져올 수 있도록 요구하는 메소드
- POST : 데이터 처리 결과를 돌려주는 메소드(생성)
- HEAD : GET과 동일한 기능이지만 메세지의 Body는 돌려주지 않습니다.
- PUT : 파일의 수정을 요청하는 메소드
- DELETE : 파일 삭제를 요청하는 메소드
- OPTIONS : 해당 URI로 지정한 메소드를 조사하기 위한 메소드
- CONNECT : SSL이나 TLS등 암호화된 것을 터널링 하기 위해 사용하는 메소드 (프록시에 터널링 요구)
응답(Response)
서버가 클라이언트에 대한 요청을 답변하는 것을 말합니다. 요청과 동일하게 응답 HTTP 메세지를 보냅니다.
Last-Modified : 서버에서 보낸 응답으로 가장 마지막 수정한 날짜를 보여준다.
💡 상태 코드
- 1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
- 2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
- 3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
- 4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
- 5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
연결을 유지하지 않는다구요?
비연결성 프로토콜
맞습니다. HTTP의 가장 큰 특징으로 비연결성(Connectionless) 프로토콜이라는 점인데요. 비연결성이라는 의미는 연결을하고 응답까지 원활하게 되었다면 연결을 끊어버리는 뜻입니다.
- 장점 : 원래 HTTP는 다수의 통신을 위해 연결을 유지하는 리소스들을 줄이면 더 많은 연결이 가능하다는 특징
- 단점 : 매번 연결을 하고 해제하는 과정을 거쳐야하므로 그만큼의 오버헤드가 발생
결론적으로 위와 같은 비연결성으로 인한 오버 헤드를 줄이기 위해 Keep-Alive라는 속성을 사용합니다. 이는 지정된 시간동안 패킷 교환이 없으면 패킷을 주기적으로 보내는 방식인데 이때 패킷에 대한 반응이 없으면 접속이 끊어지게 됩니다. 그러나 KeepAlive가 단점을 해결하여 완벽한 방법은 아닙니다. 서버가 만약 바쁜 환경이라면 KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 합니다.
무상태
비연결성으로 인해 서버는 클라이언트를 온전히 식별할 수 없습니다. 매번 일 끝나면 연결을 끊어버리기 때문에(내 머리속 지우개) 클라이언트를 식별할 수 없죠. 이러한 상태를 무상태(Stateless)라고 합니다.
그러나 이러한 상태를 기억하기 위한 다양한 방법들이 존재합니다.
쿠키(Cookie)
헤더에 set-cookie를 추가하여 쿠키를 저장하면, 서버가 클라이언트를 식별할 수 있을 것입니다.
세션(Session)
그러나 쿠키는 브라우저에 유저 정보가 저장되기 때문에 위변조나 해킹에 대한 문제가 발생합니다. 세션을 사용하면 서버단에서 정보를 저장하기 때문에 쿠키보다는 안전할 수 있습니다. 물론, 중간에 뺏어갈 수도 있어 이 점도 주의해야합니다. 또 세션은 서버에 유저 정보를 저장하기 때문에 메모리가 쌓이게되어 과부화의 원인이 됩니다.
토큰(Token)
두가지의 단점을 보완하기 위해 토큰 기반의 인증 방식이 도입되었습니다.
데이터를 토큰으로 치환하여 원본 대신 토큰을 사용하는 방법인데 대표적으로 OAuth 또는 JWT가 있습니다. 반드시 토큰이 베스트라고는 볼 수 없어요.
HTTPS의 등장
기존 HTTP에서 암호화가 되어있지 않아 무상태로 인한 위장 가능성, 중간자 공격 가능성등 보안 이슈들이 있었습니다. 이러한 보안 이슈들을 해결하기 위해 텍스트를 암호화하여 전달하는 방식을 HTTPS라고 합니다. 기존 HTTP에 Secure를 붙인 방식입니다.
Https는 http와 다르게 443번 포트를 사용하며 데이터를 주고받기 전에 세션 키를 교환하는 특징이 있습니다. 소켓 부분을 SSL이나 TLS 프로토콜로 대체하여 기존 HTTP-TCP 통신을 이 프로토콜이 담당하게 됩니다.
SSL과 TLS 프로토콜
SSL과 TLS 프로토콜은 과연 무엇일까?
이 둘은 전송계층에서 보안을 제공하는 프로토콜입니다. 해당 웹사이트가 SSL/TLS 인증서로 보호되는 경우 URL에는 Http 대신에 Https로 표시가 되는 것입니다. 주로 결제 페이지를 만들거나 로그인, 블로그 등 유저 보호를 위해 HTTPS가 필요합니다.
암호화 알고리즘
SSL와 TLS 인증서에는 공개 키라는 것이 포함됩니다. 공개 키 덕분에 서버에 암호화해서 전달할 수 있죠. 그리고 개인 키를 통해 암호화된 데이터를 복호화할 수 있습니다.
- SSL이나 TLS와 같은 인증서는 CA(Certificate Authority)에서 발급받을 수 있습니다.
- 인증서는 유효성 검사에 따라 도메인 개수에 따라 종류나 유형이 달라집니다.
대칭키(Symmetric Key)
암호화와 복호화와 같은 키를 사용하는 알고리즘으로 속도는 매우 빠르지만 해킹에 대한 위험이 있습니다.
비대칭키, 공개키(Asymmetric Key, Public Key)
대칭키의 문제점을 해결하기 위해 자신이 가지고 있는 비밀키로만 복호화 할 수 있습니다.
예를 들어, 위 그림과 같이 A가 자신의 비밀키와 공개키로 암호화 하여 B에게 보내면 B는 자신의 비밀키로 복호화 합니다. 이런식으로 대칭키만 주고 받아 서로 암호화하여 통신할 수 있는 것이죠.
SSL
위와 같은 암호화 알고리즘 기반으로 SSL이 생겨난 것입니다.
SSL(Secure Sockets Layer)은 암호화 기반의 보안 프로토콜입니다. SSL 프토토콜은 클라이언트와 서버간에 핸드쉐이크 동작 방식을 통해 신뢰성 여부를 확인하는 인증을 할 수 있습니다. 이런식으로 데이터를 암호화하여 웹에 전송할 수 있습니다.
TLS
TLS는 SSL에서 더욱 향상된 안전한 버전입니다. 물론 일반적인 용어로 SSL이라고 부르는 경우가 많습니다. 사실 SSL은 취약성이 있는 부분이 여러개 있기 때문에 SSL을 사용 중단하고 그 대안으로 TLS가 등장했습니다.
사이버 슈트 전달
- 먼저 클라이언트는 서버에게 사이버 슈트를 전달합니다.
- 사이버 슈트 : 프로토콜 버전, AEAD 사이퍼 모드(암호화 알고리즘, 암호화 기술), 해싱 알고리즘(압축 방식)을 포함
- 서버는 응답으로 클라이언트에게 SSL인증서, 가능한 암호화 알고리즘, 압축 방식을 포함하여 보냅니다.
인증 매커니즘
- 인증 메커니즘으로 클라이언트가 서버의 인증서를 CA에 유효한지 검증합니다.
- 다시 클라이언트는 암호화된 공개키를 서버에게 전달합니다.
- 서버는 개인키를 통해 공개키와 함께 복호화합니다.
세션 키 생성 및 통신
- 클라이언트와 서버는 지금까지의 키를 통해 세션키를 생성합니다.
- 클라이언트는 세션키로 암호화된 완료 메세지를 전달합니다.
- 서버도 세션키로 암호화된 완료 메세지를 전달합니다.
- 이렇게 핸드 셰이크가 끝나면 세션 키로 통신을 진행합니다.
💡 해싱 알고리즘
데이터를 요리조리 섞어서 만든 알고리즘입니다. 대표적으로 SHA-256과 SHA-384가 있습니다.
- SHA-256 알고리즘은 256비트인 알고리즘이 해싱(데이터 → 해시)해야할 메세지에 1을 추가하고 전처리한 후 전처리된 메서지를 기반으로 해시를 반환합니다. 주로 블록체인 시스템에 많이 사용합니다.
웹서버와 연관된 HTTPS
HTTP는 통신의 효율을 높이기 위해 다양한 일을 하고 있습니다.
대표적으로 가상 호스트(Virtual Host) 를 통해 물리적인 서버는 하나로 두고 가상으로 여러개 있는 것 처럼 설정하는 기능입니다. 예를 들어, 하나의 IP주소에 여러개의 도메인이 있는 경우를 생각하면 됩니다.
이러한 경우 HTTP 요청을 할 때 호스트명과 도메인 명을 완전히 포함한 URI를 지정하거나 Host 헤더 필더에서 지정해야 합니다. 이 외에도 HTTP는 통신을 중계하는 역할을 합니다. 대표적으로 프록시(Proxy), 게이트 웨이(Gateway), 터널(Tunnel)이 있죠.
- 프록시(Proxy) : 단지, 경유용으로 사용되는 서버입니다. URI 변경 없고 여러대가 경유에 사용될 수 있습니다. 사용법에 따라 캐싱 프록시와 투명 프록시가 있다.(요청 시, Via 헤더 필드를 추가해야 한다.)
- 투명 프록시(Transparent Proxy) : 클라이언트와 서버가 중계할 때 메세지를 변경하지 않은 타입의 프록시를 말합니다. 역으로 변경을 가하는 비투과 프록시도 존재합니다.
- 게이트 웨이(Gateway) : 프록시와 비슷하게 경유 용도로 사용됩니다. 추가로, HTTP 이외 서비스를 제공하는 서버입니다. 예를 들어, 결제 시스템을 연동할 때 사용한다.
- 터널(Tunnel) : 다른 서버와의 안전한 통신로를 확립합니다. SSL 같은 암호화 통신을 통해 안전한 통신을 하기 위해 사용됩니다.
로드 밸런싱(Load Balancing)
로드 밸런싱은 트래픽 감당을 해결하기 위해 여러대의 서버가 나눠서 트래픽을 분산(Scale-out)시켜주는 것을 말합니다. 로드 밸런서를 통해 웹 서버의 부하를 해결할 수 있습니다.
SEO(Search Engine Optimization)
구글에서는 HTTPS 서비스를 하는 사이트가 그렇지 않은 사이트보다 SEO가 높다고 합니다. 여기서 SEO(Search Engine Optimization)은 검색을 했을 때 많은 사람들이 볼 수 있도록 상단에 노출시키는 최적화 방법을 말합니다. 이를 위해 캐노니컬을 설정하거나 메타를 설정하거나 페이지 속도를 개선하거나 사이트 맵을 관리하는 방법들이 있습니다.
- 캐노니컬 설
<link rel="canonical" href="https://example.com/page2.php" />- 메타 설정
html 가장 상단에 메타<meta property="analytics">를 잘 설정해야 하는 것을 말합니다. - 페이지 속도 개선
구글의 PageSpeedInsights등으로 자신의 서비스에 대한 리포팅을 주기적으로 관리합니다.
