서버와 클라이언트는 요청과 응답을 주고 받기 위해서 다양한 방법을 사용할 수 있다. 그 중에서 소켓을 이용해서 데이터를 주고 받는 것과 HTTP 요청을 통해서 데이터를 주고 받는 것은 어떤 차이점이 있을까?
HTTP는 애플리케이션 계층의 프로토콜이며, 연결은 전송 계층의 TCP 연결을 이용해 이루어진다. 그러나 HTTP는 연결이 필수는 아니지만, 연결 기반 프로토콜인 TCP에 의존한다. (위의 그림에서 TCP 상위에 HTTP가 위치하므로 HTTP는 TCP에 의존한다고 말한다.)
또한 TCP에서 서로 다른 두 프로세스 간에 연결을 하기 위해서는 소켓을 필수적으로 사용한다.
이러한 흐름을 정리해보자면 HTTP는 TCP 연결을 기반으로 이루어지고, TCP 연결은 반드시 소켓을 통해 이루어져야 하므로 HTTP를 이용한 통신은 곧 소켓 통신을 하는 것이라고 말할 수 있는 것이다.
소켓 통신을 HTTP 통신이라고 말하는 것은 옳지 않다. HTTP 통신을 하기 위해서는 반드시 소켓을 이용한 TCP 연결이 이루어져야 하지만, 소켓을 이용해서 통신을 한다고해서 꼭 HTTP 규약에 따라 통신을 해야하는것은 아니기 때문이다.
HTTP의 경우에는 기본적으로 연결을 유지하지 않고, 요청이 들어올 때마다 새로운 TCP connection을 만들어 통신하게 된다(Connection : keep-alive
라는 옵션을 사용하면 HTTP도 커넥션을 유지할 수 있다). 이것은 요청시마다 3 hand-shake와 4 hand-shake가 일어남을 의미하며, 이는 곧 처리 속도가 소켓 통신에 비해 더 오래 걸린다는 것을 의미한다.
또한 HTTP는 클라이언트의 요청이 있을때만 서버가 응답하여 처리하는 단방향 통신이기 때문에, 서버가 클라이언트로 먼저 요청을 보낼수는 없다.
이러한 특성 때문에, HTTP 통신을 사용하는 서비스는 실시간성을 필요로하는 서비스보다는 필요한 경우에만 클라이언트가 서버에 요청을 해서 컨텐츠를 제공 받는 서비스를 구현할 때 적합하다. 이와 같은 서비스는 필요한 경우에만 클라이언트의 요청을 받으면 되기 때문에, 소켓과 같이 계속 연결을 유지하는 것보다 서버 자원과 비용을 절감하는데 있어서 유리하다.
소켓 통신은 기본적으로 서버와 클라이언트가 최초 연결했던 TCP connection을 유지한다. 소켓 통신만 이용할 경우에는 최초 3 hand-shake와 최종적으로 4 hand-shake가 각각 한번씩만 호출되기 때문에, 여러 요청에 대한 처리 속도가 HTTP 통신에 비해 빠르다.
또한 클라이언트만 서버로 단방향적으로 요청이 가능했던 HTTP 통신과는 다르게, 소켓 통신에서는 서버가 먼저 클라이언트에게 요청을 보낼수도 있다.
이러한 특성 때문에, 소켓 통신을 사용하는 서비스는 실시간 동영상 스트리밍과 같이 계속해서 실시간으로 데이터를 주고 받아야 하는 서비스나 채팅과 같은 기능을 구현하는데 주로 사용된다. 동영상 스트리밍 데이터를 전송하는데 HTTP를 이용해서 소켓을 계속해서 열었다 닫는다면, 딜레이나 심한 부하가 발생할 것이기 때문이다.
이 처럼 소켓 통신과 HTTP 통신이 필요한 경우를 잘 판단해서 서비스를 구현해야 서버 자원을 보다 효율적으로 사용할 수 있게 된다.