HTTP & Network Basic

제1장. 웹과 네트워크의 기본에 대해 알아보자

1.7.2 URL 포맷

http://user:pass@www.exxample.jp:80/dir/index.htm?uid=1#ch1

스키마, 자격정보 (크리덴셜), 서버주소, 서버포트, 계층적 파일 패스, 쿼리 문자열, 프래그먼트 식별자 

• 서버주소: DNS 이름, IPv4 주소, IPv6 주소를 대괄호를 묶어서 지정 [0:0:0:0:0:0:0:1]
• 계층적 파일 패스: UNIX 디렉토리 지정 방법과 비슷 
• 프래그멘트 식별자: 주로 취득한 리소스에서 서브 리소스 (도큐먼트 중간에 위치) 를 가리키기 위해서 사용 

제2장. 간단한 프로토콜 HTTP

• HEAD: 메시지 헤더 취득: URI 유효성과 리소스 갱신 시간을 확인하는 목적 
• OPTIONS: 제공하고 있는 메소드 조사 
• TRACE: 루프백을  발생 
• CONNECT: 프록시에 터널링 요구. 주로 SSL 이랑 TLS 등의 프로토콜로 암호화된 것을 터널링 시키기 위해서 사용 

2.7 지속 연결로 접속량을 절약 

2.7.1 지속 연결

TCP 연결을 계속 유지 

2.8 쿠키를 사용한 상태 관리 

쿠키는 서버에서 리스폰스로 보내진 Set-Cookie 라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됩니다. 다음 번에 클라이언트가 같은 서버로 리퀘스트를 보낼 때, 자동으로 쿠키 값을 넣어서 송신합니다. 

 

리스폰스 

<Set-Cookie: sid=13420...; path=/;expires=Wed, => 10-Oct-12 07:12:20 GMT>

 

리퀘스트 

Cookie: sid=1342077..

 

제3장. HTTP 정보는 HTTP 메시지에 있다

3.3 인코딩으로 전송 효율을 높이다 

3.3.2 압축해서 보내는 콘텐츠 코딩 

• gzip (GNU zip)
• compress (UNIX 의 표준 압축)
• deflate (zlib) 
• identity (인코딩 없음) 

3.3.3 분해해서 보내는 청크 전송 코딩 

3.4 여러 데이터를 보내는 멀티파트

MIME (Multipurpose Internet Mail Extensions: 다목적 인터넷 메일 확장 사양) 

MIME 의 확장 사양에 있는 멀티파트 (Multipart) 라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 사용하고 있음 

• multipart/form-data: 파일 업로드에 사용 
• multipart/byteranges

HTTP 메시지로 멀티파트를 사용할 때에는 Content-type 헤더 필드를 사용합니다. 

3.5 일부분만 받는 레인지 리퀘스트 

레인지 리퀘스트에 대한 리스폰스는 상태 코드 206 Partial Content 라는 리스폰스 메시지가 되돌아옴 

3.6 최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션 

콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 판단하고 있습니다. 

• Accept 
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language 

서버 구동형 네고시에이션 (Server-driven Negotiation) 

서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리를 합니다. 

브라우저가 보내는 정보를 근거로 합니다. 

 

에이전트 구동형 네고시에이션 (Agent-driven Negotiation) 

OS 의 종류나 브라우저의 종류 등에 의해서 PC용과 스마트폰용의 웹 페이지를 자동으로 전환하는 것이 이에 해당합니다. 

 

트랜스페어런트 네고시에이션 (Transparent Negotiation) 

서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식입니다. 

 

제4장. 결과를 전달하는 HTTP 상태 코드 

HTTP 상태 코드는 RFC2616 에 실려있는 것 만도 40종류가 있고 게다가 WebDAV (RFC4918, 5842) 와 Additional HTTP Status Codes (RFC6585) 등의 확장을 포함하면 60종류 이상이 있지만, 실제로 자주 사용되고 있는 것은 그 중에서 14종류 정도입니다. 

 

• 200 
• 204: 표시되는 화면 변하는 일 없음 
• 206 Partial Content 
• 301 Moved Permanently 
• 302 Found 
• 303 See Other 

301, 302, 303 리스폰스 코드가 되돌아 오면, 대부분의 브라우저에서는 POST 를 GET 으로 바꾸어서 리퀘스트의 엔티티 바디를 삭제하고 리퀘스트를 자동적으로 재송싱하도록 되어 있습니다. 

 

• 304 Not Modified: 리스폰스 바디에 어떤 것도 포함되면 안됨. 리다이렉트와는 관계 없음 
• 307 Temporary Redirect
• 400 Bad Request: 브라우저는 이것을 200 OK 와 같이 취급합니다. 
• 401 Unauthorized 
• 403 Forbidden 
• 404
• 500
• 503 Service Unavaliable: 서버 과부하, 점검중. 이 상태가 해소되기까지 시간이 걸리는 경우에는 Retry-After 헤더 필드에 따라 클라이언트에 전달하는 것이 바람직핣니다. 

제5장. HTTP 와 연계하는 웹 서버 

5.1 1대로 멀티 도메인을 간으하게 하는 가상 호스트 

HTTP/1.1 에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있습니다. 예를 들면, 웹 호스팅을 제공하고 있는 사업자는 1대의 서버에 여러 고객의 웹사이트를 넣을 수 있습니다. 고객마다 다른 도메인을 가지고, 다른 웹사이트를 실행할 수 있습니다. 이를 위해 가상 호스트 (Virtual Host) 라는 기능을 사용하고 있습니다. 

가상 호스트 기능을 사용하면 물리적으로는 서버가 1대지만 가상으로 여러 대가 있는 것 처럼 설정하는 것이 가능합니다. 

 

가상호스트 

• www trcoder jp 
• xss.hackr.jp
• www.hackr.jp 

 

같은 서버 상에 같은 IP 주소의 웹 서버에서 www.tricoder.jp  와 www.hackr.jp  이 실행되고 있을 때 DNS 로 이름을 해결하면, 그 어느 쪽도 같은 수신인이 되어 버립니다. 

 

같은 IP 주소에서 다른 호스트명과 도메인 명을 가진 여러 개의 웹 사이트가 실행되고 있는 가상 호스트의 시스템이 있기 때문에, HTTP 리퀘스트를 보내는 경우에는 호스트명과 도메인 명을 완전하게 포함한 URI 를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 합니다. 

 

5.2 통신을 중계하는 프로그램 : 프록시, 게이트웨이, 터널 

HTTP 는 클라이언트와 서버 이외에 프록시 (Proxy), 게이트웨이 (Gateway), 터널 (Tunnel) 와 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능합니다. 이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당합니다. 

 

프록시

서버와 클라이언트의 양쪽 역할을 하는 중계 프로그램으로, 클라이언트로부터의 리퀘스트를 서버에 전송하고, 서버로부터의 리스폰스를 클라이언트에 전송합니다.

 

게이트웨이

다른 서버를 중계하는 서버로, 클라이언트로부터 수신한 리퀘스트를 리소르를 보유한 서버인 것 처럼 수신합니다. 경우에 따라서는 클라이언트는 상대가 게이트웨이라는 것을 알지 못하는 경우도 있습니다.

 

터널

서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램입니다.

 

5.2.1 프록시

리소스 본체를 가진 서버를 오리진 서버 (Origin Server) 라고 부릅니다. 

프록시 서버를 경유해서 리퀘스트와 리스폰스를 릴레이 할 때 마다 "Via" 헤더 필드에 정보를 추가합니다. (proxy2, proxy1) 

 

프록시 서버를 사용하는 이유는 나중에 설명할 캐시를 사용해서 네트워크 대역 등을 효율적으로 사용하는 것과 조직 내에 특정 웹 사이트에 대한 액세스 제한, 액세스 로그를 획득하는 정책을 철저하게 지키려는 목적으로 사용하는 경우도 있습니다. 

 

프록시의 사용 방법은 여러 가지가 있는데, 2개의 기준으로 분류합니다. 

 

캐싱 프록시 (Cashing Proxy) 

프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시입니다. 

 

투명 프록시 (Transparent Proxy) 

메시지 변경을 하지 않는 타입의 프록시를 투명 프록시라고 합니다. 

 

5.2.2 게이트웨이

게이트웨이의 동작은 프록시와 매우 유사합니다. 게이트웨이의 경우에는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버가 됩니다. 클라이언트와 게이트웨이 사이를 암호화하는 등으로 안전 (Secure) 하게 접속함으로써 통신의 안정성을 높이는 역할 등을 합니다. 

 

5.2.3 터널 

터널은 요구에 따라서 다른 서버와의 통신 경로를 확립합니다. 이 때 클라이언트는 SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용합니다. 

터널 자체는 HTTP 리퀘스트를 해석하려고 하지 않습니다. 결국 리퀘스트를 그대로 다음 서버에 중계합니다. 그리고 터널은 통신하고 있는 양쪽 끝의 접속이 끊어질 때에 종료합니다. 

 

5.3.2 클라이언트 측에도 캐시가 있다 

브라우저에서도 캐시를 가질 수 있습니다. 

 

HTTP 가 등장하기 이전의 프로토콜 

 

FTP (File Transfer Protocol)

파일을 전송할 때 사용되는 프로토콜로서 그 역사는 오래되어 TCP/IP 가 등장하기 이전인 1973년경부터 있었습니다. 1995년경에는 HTTP 의 트래픽 양에 지고 말았습니다.

 

NNTP (Network News Transfer Protocol) 

전자 회의실에서 메시지를 전송하는데 사용되는 프로토콜입니다. 

 

Archie

Anonymous FTP 가 공개되어 있는 파일 정보를 검색하기 위한 프로토콜입니다.

 

WAIS (Wide Area Information Servers) 

복수의 데이터베이스를 키워드 검색하기 위한 프로토콜입니다.

 

Gopher

인터넷에 접속한 컴퓨터에 어떠한 정보가 있는지를 검색하기 위한 프로토콜입니다. 

 

 

 

제9장. HTTP 에 기능을 추가한 프로토콜 

9.2 HTTP 의 병목 현상을 해소하는 SPDY 

Google 이 2010년에 발표한 스피디는 HTTP 의 병목현상을 해소하고 웹 페이지 로딩 시간을 50% 단축한다는 목표를 갖고 있음 

 

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

ajax 와 Comet 을 사용한 통신은 웹 브라우징을 고속화하지만 HTTP 라는 프로토콜을 사용하고 있는 이상, 병목 현상을 해결할 수 없습니다.

 

9.3.2 WebSocket 프로토콜

서버 푸시 기능 

서버에서 클라이언트에 데이터를 푸시하는 서버 푸시 기능을 제공합니다. 

 

통신량의 삭감 

HTTP 에 비해서 자주 접속을 하는 오버헤드가 적어지고, 또 헤더의 사이즈도 작기 때문에 통신량을 줄일 수 있습니다. 

WebSocket 으로 통신을 하려면 한번 HTTP 에 접속을 확립하고, WebSocket 에 의해 통신을 하기 위해 핸드쉐이크 (handshake) 절차를 밟을 필요가 있습니다. 

 

핸드쉐이크/리퀘스트

WebSocket 으로 통신을 하려면 HTTP 의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시합니다. 

• Upgrade: websocket
• Set-WebSocket-Protocol: 사용하는 서브 프로토콜. 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶을 때 이름을 붙여서 정의 

 

핸드쉐이크/리스폰스

101 Switcing Protocols 로 반환 

WebSocket URL 형식 

ws://example.com/

wss://example.com/ 

 

The WebSocket API (http://www.w3.org/TR/websockets/)