-
웹 개발자라면 무조건 알아야 하는 HTTP [그림으로 배우는 HTTP & Network Basic]책을 읽자 2022. 10. 7. 17:51
그림으로 배우는 HTTP & Network Basic은 우리가 하루에도 수 없이 많이 쓰는, 없는 삶은 상상하기도 어려운 웹을 지탱하고 있는 HTTP에 대한 책이다.
우리가 웹 사이트를 방문할 때마다 우리는 HTTP로 서버에게 GET요청을 하는 것이고,
우리가 로그인을 하는 등 어떤 데이터를 입력한다는 것은 HTTP로 서버에게 POST요청을 한다는 것이다.
즉, 우리는 알게 모르게 HTTP를 계속 사용하고 있었다.
그렇다면 HTTP란 뭘까?
HTTP는 문서 전송 프로토콜(약속)이다.
우리가 어떤 웹페이지의 리소스를 받고 싶을 때 서버에게 웹 브라우저(클라이언트)가 요청을 하게 되는데,
서버와 클라이언트는 HTTP 프로토콜로 통신을 한다.
즉, HTTP는 서버와 클라이언트가 어떻게 메시지를 주고 받을지에 대한 규칙이다.
클라이언트는 서버에게 요청을 하고, 서버는 클라이언트에게 응답을 해주기 때문에 요청(request)과 응답(response)으로 구성되어 있다.
클라이언트는 어떻게 요청을 할까?
클라이언트가 요청할 수 있는 방식이 몇 가지 있는데, 그 중에서 GET, POST, PUT, DELETE를 주로 사용한다.
GET은 받아올 때 사용하고, 웹사이트 URL을 브라우저에 입력하면 GET요청이 서버에 가게 된다.
POST는 서버에 데이터를 보낼 때 사용한다.
PUT은 서버에 있는 데이터를 수정할 때 사용하고,
DELETE는 서버에 있는 데이터를 지울 때 사용한다.
클라이언트가 HTTP프로토콜을 통해 서버에 메시지를 보낼 때는 아래와 같은 형식으로 보내게 된다.가장 윗 줄은 리퀘스트 라인이다.
메소드, URL과 프로토콜 버전을 적어준다.
그리고 헤더와 바디로 구성된다.
바디는 없을 수도 있다.
리퀘스트 헤더는 Cookies, Accept-xxx, Content-Type, Content-Length, Authorization, User-Agent등의 헤더를 주로 사용한다.
서버는 어떻게 응답할까?
가장 윗 줄은 상태 라인이다.
프로토콜 버전, 상태 코드, 상태 메시지를 적어준다.
그리고 헤더와 바디로 구성된다.
리스폰스 헤더는 Server, Set-Cookie, Content-Type, Content-Length, Date등의 헤더를 주로 사용한다.
상태 코드에는 어떤 값들이 있을까?
웹사이트를 이용하면서 404 Not Found나 500 Internal server error등을 마주쳤을 수 있다.
별 이상이 없는 경우 200번대의 코드에 해당된다.
만약 다른 곳에 한 번 더 요청을 보내야 하는 경우 (redirection) 300번대 코드에 해당된다.
그리고 우리가 쉽게 접할 수 있는 에러들인 400번대 에러에는 400 Bad request (리퀘스트를 잘못 보낸 경우),
401 Unauthorized (로그인이 필요한 서비스에 로그인 없이 접근하는 등 유저 인증이 필요한 경우), 403 Forbidden (액세스가 거부된 경우), 404 Not Found (요청한 리소스가 서버에 없는 경우 등) 등이 있다.
400번대 상태 코드는 클라이언트 측 원인으로 에러가 발생한 경우에 해당되고,
500번대 상태 코드는 서버 측 원인으로 에러가 발생한 경우이다.
500 Internal server error는 서버에서 리퀘스트를 처리하는 중에 문제가 생긴 경우에 해당한다.
HTTP는 어떤 특징을 가지고 있을까?
매우 단순해서 다양한 곳에서 사용되고, 상태를 관리하고 있지 않아서 많은 요청을 빠르고 확실하게 처리하는 범위성을 가지고 있다.
상태를 관리하지 않는다는 것은 매 요청을 새롭게 받아들여서 그 요청이 단골 손님이 한 요청인지 기억하지 않고 매 번 새로운 요청으로 인식한다는 말이다.
따라서 로그인 상태를 유지하는 등 상태를 관리해야 되는 경우 쿠키 등을 이용해야 한다.
HTTPS는 HTTP와 뭐가 다를까?
HTTP는 기본적으로 보안 기능이 없다.
HTTP는 암호화하지 않은 통신이기 때문에 도청이 가능하다.
TCP/IP 계층 위에서 HTTP프로토콜이 동작하는데, TCP/IP 구조 통신은 통신 경로 상에 엿볼 수 있기 때문에 암호화와 관계없이 통신 내용을 엿볼 수 있다.
다만 암호화를 하면 도청으로부터 정보를 지킬 수 있게 된다.
SSL이라는 프로토콜은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공한다.
SSL이나 SSL과 비슷한 TLS등으로 HTTP통신을 하는 소켓 부분을 대체한 것이 HTTPS이다.
따라서 HTTPS는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다.
그리고 SSL이나 TLS를 사용하기 때문에 암호화와 증명서와 완전성 보호를 이용할 수 있다.HTTPS통신 흐름을 살펴보면 클라이언트가 ClientHello메시지를 보내면서 SSL통신을 시작하고 서버가 SSL 통신이 가능하다면 ServerHello메시지로 응답하고, 공개키 증명서가 포함된 Certificate 메시지와 ServerHelloDone 메시지를 보내서 최초 SSL네고시에이션이 끝났음을 통지한다.
SSL 최초 네고시에이션이 끝나면 클라이언트가 통신을 암호화하는데 사용하는 Pre-Master secret이 포함된 ClientkeyExchange메시지를 공개키 증명서에서 꺼낸 공개키로 암호화해서 보내고, ChangeCipherSpec 메시지를 보내서 앞으로의 통신은 암호키를 사용해서 진행한다는 것을 알려주고, Finished 메시지도 보낸다.
그리고 서버도 ChangeCipherSpec과 Finished메시지를 보내면서 SSL 접속이 확립되고, HTTP리퀘스트를 보내면 이 통신은 이제 SSL에 의해 보호되고 있는 상태이다.
서버가 HTTP리스폰스를 하고, 클라이언트가 close notify메시지로 접속을 끊고 TCP FIN메시지를 보내고 TCP통신을 종료하게 된다.
하지만 HTTPS는 HTTP에 비해 2~100배 느리다는 단점이 있다.
HTTPS가 느린 이유는 프로토콜이 하나 더 늘어나는 만큼 통신 처리에 시간이 더 걸리고, 암호화, 복호화에 CPU나 메모리 등의 리소스를 소비하기 때문이다.
따라서 민감한 정보를 다루지 않을 때는 HTTP를 사용하고 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용해야 한다.마치며
HTTP에 대한 방대한 내용을 다루는 책이라서 새롭게 알게 된 내용이 많았다.
하지만 문장의 호응이 맞지 않는 문장들이 있어서 이해가 되지 않는 부분이 조금 있어서 살짝 아쉬웠다.'책을 읽자' 카테고리의 다른 글
항상 사용하고 있는 웹에 대해 알아보자, [웹 개발자를 위한 웹을 지탱하는 기술] (0) 2022.10.29 프로그램을 유연하게 만들어주는 객체 지향, [개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴] (0) 2022.10.10 웹의 두 기둥 HTML과 CSS [웹디자이너를 위한 HTML5], [새로운 CSS 레이아웃] (1) 2022.09.30 객체 지향 프로그래밍 너의 정체를 드러내라 [객체지향의 사실과 오해] (0) 2022.09.12 하고 싶은 목표를 달성하기 위한 [아주 작은 습관의 힘] (0) 2022.08.12