'그림으로 배우는 HTTP & Network Basic' 7장~9장

HTTP & Network Basic - 교보문고

---

[제7장, 웹을 안전하게 지켜주는 HTTPS]

HTTP 의 약점

• 평문(암호화하지 않은) 통신이기 때문에 도청 가능
• 통신 상대를 확인하지 않기 때문에 위장 가능
• 완전성을 증명할 수 없기 때문에 변조 가능

평문이기 때문에 도청 가능

 HTTP 를 사용한 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화되지 않는다. TCP/IP 구조는 통신 경로 도중에 통신 내용을 엿볼 수 있기 때문에 패킷을 수집하는 것만으로도 도청할 수 있다.
도청으로부터 정보를 지키기 위한 방법 중 가장 보급되어 있는 기술은 암호화이다. 암호화에는 몇 가지 대상이 있다.

• 통신 암호화 : SSL (Secure Socket Layer) 이나 TLS (Transport Layer Security) 라는 프로토콜을 조합함으로써 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 한다. SSL 을 조합한 HTTP 를 HTTPS (HTTP Secure) 라고 하는 것이다.
• 콘텐츠 암호화 : HTTP 메세지에 포함되는 콘텐츠 자체를 암호화하는 것이다.

통신 상대를 확인하지 않기 때문에 위장 가능

 HTTP 를 사용한 리퀘스트나 리스폰스에서는 통신 상대가 누구인지 확인하는 처리가 없기 때문에 누구나 리퀘스트가 가능하다. 리퀘스트가 누군지 모르기 때문에 상대가 누구든지 반드시 무언가의 리스폰스를 반환한다. 상대를 확인하지 않는 점이 약점이 되는 이유는 다음과 같다.

• 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 여부를 확인할 수 없다. 위장한 웹 서버일 수 있다.
• 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 여부를 확인할 수 없다. 위장한 클라이언트 일 수 있다.
• 통신하고 있는 상대가 접근이 허가된 상대인지 여부를 확인할 수 없다.
• 어디의 누가 리퀘스트를 했는 지 확인할 수 없다.
• 의미없는 리퀘스트라도 수신하게 된다. 대량의 리퀘스트에 의한 DoS 공격을 방지할 수 없다.

 HTTP 에서는 통신상대를 확인할 수 없지만 SSL 에서는 가능하다. SSL 에서는 상대를 확인하는 수단으로 증명서를 제공하는데, 이 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있다.
*신뢰할 수 있는 제3자란 기본적으로 사회에서 인정된 기업이나 조직을 말한다.

완전성을 증명할 수 없기 때문에 변조 가능

 완전성이란 정보의 정확성이다. 그것을 증명할 수 없다는 것은 정보가 정확한지 아닌지 여부를 확인할 수 없다는 것이 된다. HTTP 가 완전성을 증명할 수 없다는 것은 발신된 리퀘스트나 리스폰스와 수신한 리퀘스트나 리스폰스가 같은지 아닌지를 확인할 수 없다는 것이다.

 이런 경우 중간자 공격 (Man-in-the-Middle)을 당할 수 있다. 중간자 공격이란 공격자가 중간에 리퀘스트나 리스폰스를 빼앗아 공격자가 편한대로 변조하는 공격이다. 클라이언트와 서버에는 정상적으로 통신하고 있는 것처럼 보여지게 위조한다.

 변조를 방지하기 위해 자주 사용되고 있는 방법은 MD5 (단방향성 함수에 의한 해시값) 혹은 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 있다. 하지만 이 방법도 만약 수정되어 있다고 한다면 유저로서는 알 방법이 없다. 확실히 방지하기에는 HTTPS 를 사용할 필요가 있다.

 데이터를 암호화하거나 통신 상대를 인증함으로써 데이터를 보호하는 프로토콜인 SSL 에는 인증이나 암호화, 디지털 증명서 그리고 다이제스트 기능을 제공하고 있다. HTTP 만으로는 완전성을 보증하는 것이 어렵기 때문에 이렇게 다른 프로토콜을 조합함으로써 실현한다.

• 암호화는 전송하는 데이터를 암호화해서 중간에 누군가 패킷을 가로채더라도 그 안의 내용을 해석하지 못하도록 하는 기능이다.
• 메시지 다이제스트는 메시지(데이터)의 해시값(다이제스트 값)을 계산하여 데이터와 함께 전송하는 방법이다. 중간에 누군가가 패킷을 변조하더라도 다이제스트 값을 확인하면 데이터의 변조 사실을 확인할 수 있다. 데이터의 무결성을 보장해준다.
• 디지털 증명서는 서버가 신뢰할 수 있는 서버인지 증명하는 파일이다. 중간에 누군가 접속 경로를 바꾸어 가짜 서버에 접속했을 때 확인할 수 있도록 하는 기능이다.

HTTP 에 암호화와 인증과 완전성 보호를 더한 HTTPS

 HTTP 통신은 암호화되지 않은 평문으로 실시되기 때문에 정보의 정확성을 증명할 수 없다. 이러한 HTTP 에 암호화나 인증 등의 구조를 더한 것을 HTTPS 라고 부른다. HTTPS 가 유효한 웹사이트에 접속하면 자물쇠 마크를 볼 수 있다.

 HTTPS 는 새로운 프로토콜은 아니다. HTTP 통신을 하는 소켓 부분을 SSL 이나 TLS 라는 프로토콜로 대체하고 있을 뿐이다. 보통 HTTP 는 직접 TCP 와 통신하지만 SSL 을 사용한 경우에는 HTTP는 SSL 과 통신하고, SSL 이 TCP 와 통신하게 된다.

상호간에 키를 교환하는 공개키 암호화 방식

 SSL 에서는 공개키 암호화 방식을 사용하고 있는데, 공개키 암호화 방식이란 암호화와 복호화에 하나의 키를 사용하는 공통키 암호의 보안 이슈를 보완한 것이다. 공통키 암호화 방식은 상대방에게 키를 넘겨주어야 하기 때문에 네트워크를 이용해서 키를 넘겨줄 때 통신이 도청되어 공격자에게 키를 빼앗길 위험이 있다.

• 공개키 암호화 방식이란, 서로 다른 두 개의 키 페어 (비밀키 + 공개키)를 사용하는 것이다. 비밀키는 누구에게도 알려지면 안되는 키이며, 공개키는 누구에게나 알려져도 괜찮은 키이다. 상대의 공개키를 이용해 암호화한 후, 암호화된 정보를 받은 상대는 자신의 비밀키를 사용해 복호화를 실시한다. 이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해 키를 빼앗길 위험이 없다.

 공개키 암호만 사용하기에는 공통키 암호보다 처리가 느린 단점이 있기 때문에 모든 통신에 공개키를 사용하는 것은 비효율적이다. HTTPS 는 공통키 암호와 공개키 암호의 장점을 살린 성질을 가진 하이브리드 암호 시스템이다. 키를 교환하는 곳에서는 공개키 암호를 사용하고, 그 후의 통신에서 메시지를 교환하는 곳에서는 공통키 암호를 사용한다.

공개키가 정확한지 아닌지를 증명하는 증명서

 하지만 공개키 암호에도 문제점이 있다. 바로 공개키가 진짜인지 아닌지를 증명할 수 없다는 것이다. 서버와 통신을 시작하려 하는 도중에 공격자가 공개키를 바꿔치기 해버려도 그게 바뀐 암호인지 정상적인 암호인지를 알 수 없다는 것이다.

 이 문제를 해결하기 위해 인증기관에서 그 기관이 발행하는 공개키 증명서를 사용하여 서버가 올바른 통신 상대임을 증명할 수 있다. 인증 기관이란 클라이언트와 서버가 모두 신뢰하는 제3자의 기관이다. 인증기관은 다음과 같이 이용된다.

1. 서버 운영자가 인증 기관에 공개키를 제출한다.
2. 인증기관이 공개키에 디지털 서명을 한 후 공개키를 생성한다.
3. 공개키 인증서에 서명이 끝난 공개키를 담는다.
4. 서버는 공개키 인증서를 클라이언트에 보내고, 공개키 암호로 통신한다.

 이 인증 기관의 공개키는 안전하게 클라이언트에게 전달되어야 한다. 어떤 방법을 사용하더라도 안전성을 확보하는 것은 어렵기 때문에 많은 브라우저는 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있다.

EV SSL 증명서와 클라이언트 증명서

 증명서의 역할은 서버가 올바른 통신 상대임을 증명하는 것이지만, 상대가 실제로 있는 기업인지를 확인하는 역할도 있다. 그러한 역할을 가진 증명서를 EV SSL 증명서라고 한다. 운영하는 조직의 실재성을 확인하는 방법을 엄격히 규정하고 있기 때문에 웹 사이트의 신뢰성을 높일 수 있다.

 
 브라우저의 주소창의 색이 녹색으로 변하면 EV SSL 증명서로 증명된 웹사이트인 것을 시각적으로 확인할 수 있다. 그리고 주소창의 옆에는 SSL 증명서에 기재되어 있는 조직명 및 증명서를 발행한 인증기관명이 표시된다.

 HTTPS 에서는 클라이언트 증명서도 이용할 수 있다. 서버 증명서와 같이 서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명하는 클라이언트 인증 방식의 증명서이다.

 하지만 클라이언트 인증서는 클라이언트의 실재를 증명할 뿐 사용자의 존재 유무를 증명하는 증명서는 아니다. 클라이언트 증명서가 들어간 컴퓨터를 사용할 권한이 있다면 누구든지 클라이언트 증명서를 이용할 수 있다. 또한 유료로 구입해야 하기 때문에 유저 수만큼 비용이 들게 된다. 이러한 이슈들 때문에 많은 비용을 들일 필요가 있는 은행 인터넷 뱅킹 같은 곳에서만 사용한다.

SSL의 통신 지연

 HTTPS 에도 문제는 있다. 바로 SSL 을 사용하면 처리가 늦어지게 된다는 점이다. 통신이 지연되는 이유에는 두 가지가 있다.

 첫 번째는 통신 속도가 떨어지는 것이다. 네트워크 부하는 HTTP 를 사용하는 경우에 비해 2배에서 100배까지 느려질 수 있다.

 두 번째는 SSL 통신만큼 CPU 나 메모리 등의 네트워크 리소스를 다량으로 소비함으로써 처리가 느려지는 것이다. SSL 은 반드시 암호화 처리를 하고 있기 때문에 서버나 클라이언트에서 암호화나 복호화를 위한 계산을 해야 한다. 그렇기 때문에 서버나 클라이언트의 리소스를 소비하게 되어 HTTP 에 비해 부담이 커진다.

 왜 항상 HTTPS 를 사용하지 않느냐는 질문에 대한 답이 여기에 있다. 평문 통신에 비해 암호화 통신인 CPU 나 메모리 등 리소스가 많이 필요하기 때문에 통신할 때마다 암호화를 하면 많은 리소스를 소비하게 되고 그 결과 한 대당 처리할 수 있는 리퀘스트의 수가 줄어들게 된다. 그렇기 때문에 민감한 정보를 다룰 때만 HTTPS 에 의한 암호화 통신을 사용한다. 그 외에는 증명서를 구입하는 비용을 절약하기 위한 이유도 있다.

 느려지는 것에 대한 근본적인 해결 방법은 없고, SSL 엑셀레이터라는 하드웨어 (appliance 서버) 를 사용하기도 한다. SSL 엑셀레이터는 SSL 을 처리하기 위한 전용 하드웨어인데, 소프트웨어로 SSL 을 처리할 때보다 몇 배 더 빠른 계산을 할 수 있고 부하의 분산이 가능하다.

 

[제8장, 누가 액세스하고 있는지를 확인하는 인증]

인증이란?

서버에서 액세스 하고 있는 사람이 권한을 가졌는지 여부를 확인하기 위해서는 '등록된 본인만이 알고 있는 정보' 나 '등록한 본인만이 가지고 있는 정보' 등으로 확인할 필요가 있다. 이러한 정보에는 다음과 같은 것들이 사용된다.

• 패스워드 : 본인만이 알고 있는 문자열 정보
• 원타임 토큰 : 본인만이 가지고 있는 기기에 표시되는 한 번 쓰고 버리는 패스워드 등의 정보
• 전자 증명서 : 본인(혹은 단말기) 만이 가지고 있는 정보
• 바이오 매트릭스 : 지문이나 홍채 등 본인의 신체 정보
• IC 카드 : 본인만이 가지고 있는 정보

HTTP/1.1 에서 사용하는 인증 방법

• Basic 인증
• Digest 인증
• SSL 클라이언트 인증
• 폼 베이스 인증

Basic 인증

 웹 서버와 대응하고 있는 클라이언트 사이에서 이루어지는 인증 방식이다. Basic 인증에서는 Base64 라는 인코딩 형식을 사용하고 있지만 이것은 암호화는 아니기 때문에 아무런 부가 정보 없이도 복호화 할 수 있다. 그렇기 때문에 통신 경로 상에서 도청된 경우 복호화된 유저 ID 와 패스워드를 빼앗길 위험이 있다. 그 외에도 한 번 인증을 하면 일반 브라우저에서는 로그아웃 되지 않는다.

 인증 수순은 아래와 같다.

• 인증 리퀘스트가 오면 서버는 상태 코드 401 (Authorization Required) 로 응답해서 인증이 필요하다는 것을 전달한다.
• 상태 코드 401 을 받은 클라이언트는 인증을 위해 유저 ID 와 패스워드를 (아이디:패스워드) 형식으로 ";" 콜론을 이용해 문자열로 연결한다.
• 연결한 문장을 Base64 라는 형식으로 인코딩하고, 이 문자열을 Authorization 헤더 필드에 포함해서 리퀘스트를 송신한다.
• 리퀘스트를 받은 서버는 인증 정보가 정확한 지 판단한 후, 정확하다면 Request URI 리소스와 함께 상태코드 200 으로 응답한다.
• 만약 인증이 실패했을 경우 다시 상태 코드 401 로 응답한다.

Digest 인증

 Basic 인증의 약점을 보안하며 HTTP/1.1 에 소개되어 있다. Digest 인증에는 챌린지 리스폰스 방식이 사용되고 있어서 Basic 인증과 같이 패스워드를 그대로 보내는 일은 없다. 챌린지 리스폰스 방식은 최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산한다. 이 값을 상대에게 송신하여 인증하는 방법이다. 리스폰스 코드라는 패스워드와 챌린지 코드를 이용해서 계산한 결과를 상대에게 보내기 때문에 패스워드가 누출될 가능성이 줄어든다.

 하지만 이 방식은 패스워드의 도청을 방지하기 위한 보호 기능은 제공하지만 위장을 방지하는 기능은 제공하고 있지 않다.

SSL 클라이언트 인증

 유저 ID 와 패스워드를 사용한 인증 방식은 이 두 가지 정보가 정확하다면 본인으로서 인증할 수 있다. 그러나 이 정보가 도난되었을 때에는 제3자가 위장을 하는 경우가 있다. 이를 방지하기 위한 대책 중 하나인 SSL 클라이언트 인증은 HTTPS 의 클라이언트 인증서를 이용한 인증 방식이다.

폼 베이스 인증

 폼 베이스 인증은 HTTP 프로토콜로서 사양이 정의되어 있는 인증방식은 아니다. 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보를 송신하여 그 자격 정보의 검증 결과에 따라 인증하는 방식이다.

 인증의 대부분은 폼 베이스 인증이다. 웹 사이트의 인증 기능으로서 요구되는 기능의 레벨을 충족시킨 표준적인 것이 존재하지 않기 때문에 웹 애플리케이션에서 각각 구현하는 폼베이스 인증을 채용하는 수 밖에 없다. 공통사양이 결정되어 있지 않으므로 다양한 폼베이스 방식이 존재한다.

세션 관리와 쿠키에 의한 폼 베이스 인증 과정

 폼 베이스 인증은 표준적인 사양이 결정되어 있지는 않지만 일반적으로 자주 사용되는 방법으로는 세션 관리를 위해서 쿠키를 사용하는 방법이 있다. 폼 베이스의 인증 자체는 서버 측의 웹 애플리케이션 등에 의해 클라이언트가 송신해온 유저 ID 와 패스워드가 사전에 등록되어 있는 것과 일치하는지 검증하면서 이루어진다.

 그러나 HTTP 는 stateless 프로토콜이기 때문에 방금 전에 인증에 성공했다고 하더라도 그 상태를 프로토콜 레벨에서는 유지할 수 없다. 즉 상태관리가 안되기 때문에 다음에 그 유저가 액세스 했다고 하더라도 다른 유저와 구별하지 못한다. 그래서 세션 관리와 쿠키를 사용하여 HTTP 에 없는 상태 관리 기능을 보충한다.

 인증 과정은 아래와 같다.

• 클라이언트는 서버에 유저 ID 나 패스워드 등의 자격 정보를 포함한 리퀘스트를 보낸다. 보통은 POST 메서드가 사용된다.
• 서버 측은 유저를 식별하기 위해 유저에게 세션 ID 를 발행한 후, 이 인증 상태를 세션 ID 와 함께 서버에 기록한다.
• 기록한 후, 클라이언트측에 전달할 때 Set-Cookie 헤더 필드에 세션 ID 를 저장해서 리스폰스를 반환한다.
• 서버로부터 세션 ID 를 받은 클라이언트는 그것을 쿠키로 저장한다. 
• 다음에 서버에 리퀘스트를 보낼 때는 브라우저가 자동으로 세션 ID 가 저장되어 있는 쿠키를 서버로 송출한다.

 

[제9장, HTTP에 기능을 추가한 프로토콜]

HTTP 의 병목 현상

 HTTP를 처음 만들었을 때는 주로 HTML 로 작성된 문서를 전송하기 위한 프로토콜이었지만 지금의 HTTP 의 용도는 웹으로 크게 확장되었다. 하지만 아무리 기능이 커지고 충분하다고 하더라도 결코 효율적이라고 할 수는 없다. HTTP 라는 프로토콜의 제한이나 한계가 있기 때문이다.

 웹 브라우저에서 많은 유저가 동시에 메시지를 작성한다고 하면 웹에 그 정보들이 추가되면서 단시간에 대량의 갱신된 정보가 발생한다. 이 갱신된 정보를 가능한 빨리 실시간으로 클라이언트의 화면에 반영해주어야 하는데 HTTP 에서는 이 처리를 제대로 할 수 없다. 

 HTTP 에서는 서버의 정보가 갱신되었는 지 알기 위해서는 (실제로 갱신된 정보가 없어도) 클라이언트가 항상 서버측에 갱신된 정보가 있는 지를 확인하러 가야 한다. 만약 갱신된 정보가 없을 경우 불필요한 통신이 발생하게 된다. 이 불필요한 과정들을 해소하기 위한 몇 가지 방법들이 있다.

Ajax 에 의한 해결 방법

 Ajax (Asynchronous JavaScript+XML) 은 JavaScript 나 DOM(Document Object Model) 조작 등을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다. 기존의 동기식 통신에 비해 페이지의 일부분만 갱신되기 때문에 리스폰스로 전송되는 데이터 양은 줄어든다는 장점이 있다.

 Ajax 의 핵심 기술은 XMLHttpRequest 라는 API 로, JavaScript 등의 스크립트 언어로 서버와 HTTP 통신을 할 수 있다. 이것을 사용함으로써 이미 읽어 들인 웹 페이지부터 리퀘스트를 발행할 수 있기 때문에 페이지의 일부 데이터만 받는 것이 가능해진다.

 하지만 Ajax 를 이용해 실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생한다는 문제점이 있고, 또 Ajax 자체만으로는 HTTP 프로토콜이 가지고 있는 문제점을 해결할 수 있는 것은 아니어서 근본적인 해결 방법이라고 할 수는 없겠다.

Comet 에 의한 해결 방법

 Comet 은 서버 측의 콘텐츠에 갱신이 있을 경우, 클라이언트로부터 리퀘스트를 기다리지 않고 클라이언트에 보내기 위한 방법이다. 보통 리퀘스트가 오면 리스폰스를 바로 반환하지만, Comet 에서는 리스폰스를 보류 상태로 해 두고 서버의 콘텐츠가 갱신되었을 때 바로 리스폰스를 반환한다. 이런 방식으로 서버에서 갱신된 콘텐츠가 있으면 바로 클라이언트에 반영할 수 있다.

 하지만 콘텐츠를 실시간으로 갱신할 수는 있지만 리스폰스를 보류하기 위해서 커넥션을 유지하는 시간이 길어진다. 이렇게 길어진 만큼 리소스를 소비하는 것은 당연하다. 또한 Ajax 와 마찬가지로 HTTP 자체의 문제가 해결되는 것도 아니다.

SPDY 의 목표

 Ajax 나 Comet 처럼 사용성을 쾌적하게 하는 여러 기술들이 등장해서 어느 정도 개선은 되었으나 HTTP 라는 프로토콜의 제약을 없앨 수는 없었다. 근본적인 문제를 해결하기 위해서는 프로토콜 단계에서의 개선이 필요하게 되었다. 

 SPDY 는 HTTP 가 안고 있던 병목 현상을 프로토콜 단계에서 해소하기 위해 개발이 진행되고 있다. SPDY 는 HTTP 를 완전히 바꿔놓는 것이 아니라 TCP/IP 의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다. 또한 SPDY 보안을 위해 표준으로 SSL 을 사용하도록 되어 있다. (아래 사진의 애플리케이션 계층의 TLS 는 SSL 로 봐도 무방하다.)

SPDY 설계

 SPDY 가 세션 계층으로서 그 사이에 들어감으로써 데이터의 흐름을 제어하지만 HTTP 의 커넥션은 확립되어 있다. 그래서 HTTP 의 GET 이나, POST 같은 메서드나 쿠키, HTTP 메시지 등은 그대로 사용할 수 있다.

SPDY 를 사용하는 경우 HTTP 에 추가되는 기능

1) 다중화 스트림 : 단일 TCP 접속을 통해서 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있다. 한 번의 TCP 접속으로 리퀘스트를 주고 받는 것이 가능하기 때문에 TCP 의 효율이 높아진다.

2) 리퀘스트의 우선 순위 부여 : SPDY 는 무제한으로 리퀘스트를 병렬 처리할 수 있지만, 각 리퀘스트에 우선 순위를 할당할 수 있다. 이것은 복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결하기 위해서이다.

3) HTTP 헤더 압축 : 리퀘스트와 리스폰스의 HTTP 헤더를 압축한다. 이로 인해 보다 적은 패킷 수와 송신 바이트 수로 통신할 수 있다.

4) 서버 푸시 기능 : 서버에서 클라이언트로 데이터를 푸시하는 서버 푸시 기능을 지원한다. 그래서 서버 측은 클라이언트에서 리퀘스트를 기다리지 않고 데이터를 보내줄 수 있다.

5) 서버 힌트 기능 : 서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안할 수 있다. 클라이언트가 자원을 발견하기 전에 리소스의 존재를 알 수 있기 때문에 이미 캐시를 가지고 있는 상태라면 불필요한 리퀘스트를 보내지 않아도 된다.

SPDY 는 웹의 병목현상을 해결하는가?

 HTTP 기능이 부족하다고 한다면 그것을 보완하는 새로운 프로토콜을 만들 수 있겠지만 HTTP 대신 다른 프로토콜을 사용하기에는 이미 웹브라우저라는 환경은 전 세계적으로 퍼져있다. 그래서 HTTP 를 기반에 추가된 형태로 새로운 프로토콜 몇 가지가 구현되었다. 그 중 하나는 Google 이 2010년 발표한 SPDY 이다. HTTP 의 병목 현상을 해소하고 웹 페이지 로딩 시간을 50% 단축한다는 목표를 세우고 개발되었다.

 하지만 SPDY 는 기본적으로 한 개의 도메인 (IP 주소)과의 통신을 다중화할 뿐이기 때문에 하나의 웹 사이트에서 복수의 도메인으로 리소스를 사용하고 있는 경우에는 그 효과가 한정적이게 된다. 

브라우저에서 양방향 통신을 하는 WebSocket

 Ajax 와 Comet 을 사용한 통신은 웹 브라우징을 고속화하지만 HTTP 라는 프로토콜을 사용하고 있는 이상, 병목현상의 근본적 문제를 해결할 수는 없다. WebSocket (이하 웹소켓) 은 Ajax 나 Comet 에서 사용하는 XMLHttpRequest 의 결점을 해결하기 위한 기술로서 개발이 진행되고 있다.

 웹소켓은 웹 서버와 클라이언트가 한 번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON 이나 XML, HTML 이나 이미지 등 임의 형식의 데이터를 보내게 된다. HTTP 에 의한 접속의 출발점이 클라이언트에 있다는 것에는 변함이 없지만 한 번 접속을 확립하면 웹소켓을 사용하여 서버와 클라이언트 어느 쪽에서도 송신을 할 수 있게 된다.

WebSocket 프로토콜의 주요 특징

1) 서버 푸시 기능 : 서버에서 클라이언트에 데이터를 푸시하는 기능이다. 그래서 서버는 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.

2) 통신량의 삭감 : 웹소켓은 접속을 한 번 확립하면 접속을 유지하려고 한다. HTTP 에 비해 자주 접속을 하는 오버헤드가 적어지고, 헤더의 사이즈도 작기 때문에 통신량을 줄일 수 있다. 웹소켓으로 통신하려면 한 번 HTTP 에 접속한 후 핸드쉐이크 (handshake) 절차를 밟아야 한다. 

*핸드쉐이크/리퀘스트 : 웹소켓으로 통신하려면 HTTP 의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시한다. 

GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

 Sec-WebSocket-Key 에는 핸드쉐이크에 필요한 키가 저장되고, Set-WebSocket-Protocol 에는 사용하는 서브 프로토콜이 저장된다. 서브 프로토콜은 웹소켓 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶을 때 이름을 붙여 정의한다.

*핸드쉐이크/리스폰스 : 위의 리퀘스트에 대한 리스폰스는 상태코드 [101 Switching Protocols] 로 반환된다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

 Sec-WebSocket-Accept 는 Sec-WebSocket-Key 의 값에서 생성된 값이 저장된다. 핸드쉐이크에 의해 웹소켓 커넥션이 확립된 후에는 HTTP 가 아닌, 웹소켓 독자적인 데이터 프레임을 이용해 통신한다.

왜 HTTP 는 이렇게까지 사용되고 있는가?

많은 이유가 있겠지만 그 중 하나는 기업이나 조직 등의 방화벽 설정과 크게 관련되어 있다. 방화벽의 기본 기능 중에 지정된 프로토콜이나 포트 번호 이외의 패킷은 통과시키지 않는 기능이 있어서 이로 인해 새로운 프로토콜이나 포트 번호를 이용할 경우 변경해야 할 필요가 생긴다.

 인터넷에서 가장 많이 활용되고 있는 분야는 웹이다. 웹은 HTTP 에서 동작하고 있기 때문에 방화벽 설정에서 HTTP(80/tcp) 나 HTTPS(443/tcp) 을 허가해 둘 필요가 있다. 이렇게 HTTP는 많은 회사나 조직에서 허가된 통신 환경인 경우가 많기 때문에 방화벽의 설정을 변경할 필요가 없고 HTTP 라면 도입이 용이하다는 장점이 있다. 이것이 HTTP 를 놓을 수 없는 이유이다.

 다른 이유로는 HTTP 클라이언트인 브라우저가 보급되어 있는 것이나 HTTP 서버가 많이 보급되고 있는 것 등의 이유도 있다.