9장 HTTP에 기능을 추가한 프로토콜 9.1 HTTP를 기본으로 하는 프로토콜 HTTP의 규격이 만들어졌을 때는 주로 HTML을 주고 받는 용도로 생각했기 때문에 스펙이 간단한 편이었지만, 최근에 용도가 달라지면서 새로운 기능들이 필요해졌다. 9.2 HTTP의 병목 현상을 해소하는 SPDY Google은 2010년에 HTTP의 병목 현상을 해소하고 웹 페이지의 로딩 시간을 50% 단축하는 목표를 세운 SPDY가 있었다. (결과적으로 SPDY와는 폐기되었고 HTTP/2를 지원하는 것으로 결정했다) 9.2.1 HTTP의 병목 현상 트위터같은 사용자가 많은 실시간 서비스를 구현하기 위해서는 HTTP 사양은 한계가 있었다. 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다. 리퀘스트는 클라이언트에서만 시작할 ..
8장 누가 액세스하고 있는지를 확인하는 인증 8.1 인증이란? 아래와 같은 정보들로 인증을 할 수 있다. 패스워드 원타임 토큰 전자 증명서 바이오 매트릭스 IC 카드 HTTP에서 사용하는 인증 방법 BASIC DIGEST SSL 클라이언트 폼 베이스 8.2 BASIC 인증 리퀘스트에 인증이 필요한 경우 401과 함께 인증 방식과 Request-URI의 보호 공간을 식별하기 위한 문자열을 WWW-Authenticate 헤더 필드에 포함해서 리스폰스를 반환한다. 클라이언트는 ID와 패스워드를 콜론으로 연결한 문장을 Base64 형식으로 인코드하여 Authorization 헤더 필드에 포함해서 보낸다. 서버는 인증 정보가 정확한지 판단한다. 8.3 DIGEST 인증 챌린지 리스폰스 방식이 사용되고 있다. 최초..
7장 웹을 안전하게 지켜주는 HTTPS HTTP는 약점이 있다. 평문 통신이기 때문에 도청 가능 통신 상대를 확인하지 않기 때문에 위장 가능 완전성을 증명할 수 없기 때문에 변조 가능 7.1.1 평문이기 때문에 도청 가능 HTTP는 암호화 기능이 없기 때문에 평문으로 메시지를 보낸다. 따라서 통신 경로의 도중에 패킷을 수집하여 도청할 수 있다. 암호화로 도청을 피하는 방법 통신 암호화 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS라고 부른다. 콘텐츠 암호화 콘텐츠의 내용 자체를 암호화해 버리는 방법이다. 7.1.2 통신 상대를 확인하지 않..
6장 HTTP 헤더 6.1 HTTP 메시지 헤더 메시지 헤더: 클라이언트와 서버 처리에 필요한 주요 정보가 거의 다 여기에 있다. 메시지 바디: 사용자와 리소스를 필요로 하는 정보가 있다. HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있다. 메시지 헤더는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기위한 정보가 들어있다. 리퀘스트의 HTTP 메시지 메소드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성되어 있다. 리스폰스의 HTTP 메시지 HTTP 메시지와 HTTP 버전, 상태 코드(코드와 설명), HTTP 헤더 필드 등으로 구성되어 있다. HTTP 요청에서 가장 다양한 정보를 가지고 있는 것이 HTTP 헤더 필드다. 6.2 HTTP 헤더 필드 6.2.1 HTT..
5장 HTTP와 연계하는 웹 서버 웹 서버는 1대의 서버에서 멀티 도메인으로 웹사이트를 실행하거나 중계 서버를 두어 통신 중에 효율을 올릴 수 있다. 5.1 1대로 멀티 도메인을 가능하게 하는 가상 호스트 HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹사이트를 실행할 수 있다. 고객마다 다른 도메인을 가지고, 다른 웹사이트를 실행할 수 있다, 이를 위해 가상 호스트라는 기능을 사용한다. HTTP Request를 보내는 경우에 호스트명과 도메인 명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야만 멀티 도메인을 적용할 수 있다. 5.2 통신을 중계하는 프로그램: 프록시, 게이트웨이, 터널 HTTP는 클라이언트와 서버 이외에도 프록시, 게이트웨이, 터널등으로 서버를 ..
조건부 로직 간소화 조건부 로직은 특별한 경우에 어떤 로직이 실행되는 것인데 도메인이 복잡해질수록 조건식도 복잡해질 수 밖에 없다. 복잡해진 조건식을 잘 다루지 못하면 코드를 읽는게 어렵고 버그가 발생할 확률이 높다. 그래서 잘 다뤄야 한다. 10.1 조건문 분해하기 if(!aDate.isBefore(plan.summerStart) && !aDate.isAfter(plan.summerEnd)) { charge = quantity * plan.summerRate; } else { charge = quantity * plan.summerRate + plan.regularServiceCharge; } if(summer()){ charge = summerCharge(); } else { charge = regu..
4장 결과를 전달하는 HTTP 상태 코드 클라이언트가 HTTP 리퀘스트를 보낸 결과, 즉 서버가 정상적으로 처리되었는지 아니면 에러가 발생했는지를 알려주는게 HTTP 상태 코드다. 4.1 상태 코드는 서버로부터 리퀘스트 결과를 전달한다. 클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것이 상태 코드의 역할이다. 정상적으로 처리했는지 에러였는지 알 수 있다. 200 OK와 같이 3자리 숫자와 설명으로 나타낸다. 1xx(Informational): 리퀘스트를 받아들여 처리중 2xx(Success): 리퀘스트를 정상적으로 처리했음 3xx(Redirection): 리퀘스트를 완료하기 위해서 추가 동작이 필요 4xx(Client Error): 서버는 리퀘스트 이해 불가능..
3장 HTTP 정보는 HTTP 메시지에 있다. HTTP 통신에는 클라이언트에서 서버로 보내는 리퀘스트와 서버에서 클라이언트로 보내는 리스폰스가 있다. 3.1 HTTP 메시지 HTTP에서 교환하는 정보를 HTTP 메시지라고 하고 리퀘스트측 메시지는 리퀘스트 메시지, 리스폰스측 메시지는 리스폰스 메시지라고 한다. HTTP 메시지는 복수행의 데이터로 구성된 텍스트 문자열이고 크게 구분하면 메시지 헤더와 메시지 바디로 구분되며 개행 문자(CR+LF)로 메시지 헤더와 메시지 바디를 구분한다. 메시지 바디가 항상 존재하는 것은 아님(GET, DELETE등) 메시지 헤더: 서버와 클라이언트가 꼭 처리해야 하는 리퀘스트와 리스폰스 내용과 속성등 메시지 바디: 꼭 전송되는 데이터 그 자체 3.2 리퀘스트 메시지와 리스폰..
