HTTP란?
HTTP(Hyper Text Transfer Protocol)은 HT(Hyper Text)를 전송하는 프로토콜로 HTML(Hyper Text Markup Language)은 대표적인 하이퍼 텍스트이기 때문에, 모든 HTML 웹 사이트는 HTTP로 통신을 주고 받습니다.
HTTP는 TCP를 사용하여 신뢰적 전달의 혜택을 받고, 비 상태(Stateless) 프로토콜로써 같은 URL이면, 같은 내용이 원칙인 구조를 가지고 있습니다. URL(Uniform Resource Locator)은 URI(Uniform Resource Identifier)의 하위 구조로 인터넷 자원(URI=식별자)의 일부분인 자원의 주소(URL)를 말합니다.
HTTP는 신뢰적 전달 + 비상태를 사용해서 얻는 간단한 구조가 장점이 되어 상당히 많은 곳에서 편리하게 쓰이는 규약이지만, 이는 태생적인 한계를 나타내기도 합니다.
그 이유는 다음과 같습니다.
- TCP를 고정한다는 것은 속도, 한계 그리고 트랙픽 요구량이 증가한다는 단점이 있습니다.
- 비 상태(Stateless)를 사용한다는 것은 클라이언트에 관계없이 페이지를 보여주기 때문에 로그인 같은 커스텀 상태나 admin 페이지 등의 권한 상태 등을 검증하지 못한다는 의미가 됩니다.
물론, 오늘날에는 이 두가지 문제들을 최대한 해결하기 위한 기술들이 많이 탄생하여 사용되고 있지만, 이는 태생적인 HTTP의 특징 때문이라는 것을 기억해야 합니다.
HTTP/2, HTTP/3은 보안을 강화하거나, QUIC(Reliable UDP기반)를 사용한 최신 기술들 입니다.
HTTP Request(Format) 요청
처음 HTTP는 클라이언트가 먼저 URL로 요청을 보내야 시작이 됩니다. 이때, 웹 엔진은 사용자로 부터 URL을 받으면, URL을 이용해서 요청라인을 작성한 뒤 (GET 고정), 헤더라인에 도메인과 커넥션 상태, 사용자가 사용하는 엔진과 버전, 사용 언어 등등 다양한 내용을 기입합니다.
body는 URL 뒤에 ?를 이용한 쿼리나 직접적인 값(페이로드)를 주면 추가적인 요청을 같이 보낼 수 도 있습니다.
HTTP 요청은 반드시 \r\n을 붙여 데이터가 분리됨을 알려줘야 하고, 마지막 라인 뒤에는 \r\n\r\n을 붙여 HTTP 요청 내용의 끝을 명시해야 합니다.
웹 엔진은 GET 요청을 기본적으로 수행하며, POST, PUT, DELETE 요쳥을 보내려면 개발자 도구에서 요청을 다시 보내기를 하거나, 콘솔 명령에서 curl를 사용하면 좀 더 세부적으로 작성할 수 있습니다.
POSTMan은 curl를 좀 더 사용하기 편하게 해주는 사이트로 Dev-Ops로도 자주 사용하는 툴 사이트 입니다.
HTTP Response(Format) 응답
서버는 클라이언트에 차별하지 않고, 비 상태에 걸맞게 응답을 해줘야 합니다.
상태라인은 응답의 결과를 넘버링으로 보여주고, 간단한 스트링으로 세부 내용을 넘겨 줍니다. 이를 상태 코드라고 하고, 100~109는 메시지 정보, 200~206은 요청 성공, 300~305는 Redirection, 400~415는 ClientError, 500~505는 ServerError로 보시면 됩니다.
헤더라인은 요청과 비슷하게 서버정보, 타임 스태프들과 함께 응답의 총 길이나 값의 형태를 미리 언급하여 웹 엔진이 어떻게 파싱하면 될 지 알려줄 수 도 있습니다.
공백 라인은 요청과 동일하게 라인의 끝으 \r\n을 명시하고, 응답의 끝에는 \r\n\r\n을 붙여 끝임을 명시해야 합니다.
요청을 받은 다음 물리적으로 시간이 오래 지나면, 내용을 업데이트 하기 위해 다시 한번 GET 요청을 보낼 때가 있는데, 이때 여전히 바뀐 정보가 없다면, 같은 정보를 두 번 주는 것 보다 300 계열의 Redirection 코드를 주면 정보를 보다 효율적으로 사용할 수 있을 것입니다.
HTTP Cookie
HTTP는 비 상태 프로토콜입니다. 이는 모든 클라이언트에게 무차별적으로 라우팅 된 내용을 보여줘야 한다는 뜻이 됩니다.
대부분의 경우는 문제가 없지만, 로그인이나 개인정보를 저장, admin 권한의 작업을 수행하는 경우, 라우팅을 숨기는 방식의 보안처리를 할 수 밖에 없을 것입니다.
HTTP Cookie는 서버로 통신하려는 클라이언트가 서버에게 특정상태임을 같이 보내는 것으로 이를 활용하면 클라이언트의 로그인 상태를 유지하면서 웹 사이트를 사용하거나, admin 권한이 있는지 서버가 검증하여 조건부로 들여 보낼 수 있게 됩니다.
처음 클라이언트가 로그인을 수행한다면, 서버는 클라이언트에게 Set-Cookie : ~의 내용으로 쿠키를 변경하라는 명령을 헤더로부터 받아 처리한 뒤 (쿠키등록을 한 뒤), 다음부터는 해당 쿰키를 요청 헤더에 Cookie로 매번 보내어 로그인 과정을 건너뛰거나 페이지를 보기 위한 권한을 획득하는 구조를 가지게 됩니다.
오늘날에는 단순한 쿠키 값을 사용해서는 보안의 문제가 될 수 있기 때문에, 쿠키 값에 암호화 된 세션 값을 넣어 서버 측에서 반드시 검증해야 하는 구조로 이를 해결합니다. (주로 Session과 Web Token을 사용합니다.)
HTTPS
HTTP는 L5계층의 프로토콜 입니다. HTTP의 통신 내용은 패킷을 통해 분석이 가능하고, HTTP는 통신의 과정에서 암호화가 전혀 진행되지 않기 때문에, MTIM(Man In the Middle) 공격에 취약한 상태로 통신이 진행됩니다.
이를 막기 위해서는 L4 계층인 TCP로 가기전에 전체 문장을 암호화 한 뒤 TCP를 통해 도달 하고, 도착지에서만 열 수 있는 복호 열쇠로 복호화해서 다시 원래의 HTTP 파일을 보는 방식을 사용합니다.
쉽게 HTTP -> SSL(암호화) -> TCP -> 네트워크 -> TCP -> SSL(복호화) -> HTTP 순서로 진행되어 통신과정에서 가로채기 어렵게 만들 수 있습니다.
오늘날에는 SSL보다 성능이 더 뛰어난 TLS1.x를 사용하여 보안을 강화하고 있습니다.
