공부

HTTP 커넥션을 생성하고 최적화하는 HTTP 기술에 대해서 알아보자. 우선 잘못 이해하는 Connection 헤더에 대해 먼저 알아보자.

HTTP는 클라이언트와 서버 사이에 프락시 서버, 캐시 서버 등과 같은 중개 서버가 놓이는 것을 허락한다. HTTP 메시지는 클라이언트에서 서버(혹은 리버스 서버)까지 중개 서버들을 하나하나 거치면서 전달된다.

HTTP Connection 헤더 필드는 커넥션 토큰을 쉼표로 구분하여 가지고 있으며, 그 값들은 다른 커넥션에 전달되지 않는다. 예를 들어, 다음 메시지를 보낸 다음 끊어져야 할 커넥션은 Connection: close 라고 명시할 수 있다.

Connection 헤더에는 다음 세 가지 종류의 토큰이 전달될 수 있기 때문에 혼란스러울 수 있다.

• HTTP 헤더 필드 명은, 이 커넥션에만 해당되는 헤더들을 나열한다.
• 임시적인 토큰 값은, 커넥션에 대한 비표준 옵션을 의미한다.
• close 값은, 커넥션이 작업이 완료되면 종료되어야 함을 의미한다.

커넥션 토큰이 HTTP 헤더 필드 명을 가지고 있으면, 해당 필드들은 현재 커넥션 만을 위한 정보이므로 다음 커넥션에 전달하면 안 된다.

Connection 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에 삭제되어야 한다.

HTTP 애플리케이션이 Connection 헤더와 함께 메시지를 전달받으면, 수신자는 송신자에게서 온 요청에 기술되어 있는 모든 옵션을 적용한다. 그리고 다음 홉에 메시지를 전달하기 전에 Connection 헤더와 Connection 헤더에 기술되어 있던 모든 헤더를 삭제한다.

순차적인 트랜잭션 처리에 의한 지연

커넥션 관리가 제대로 안되면 TCP 성능이 매우 안 좋아질 수 있다. 예를 들어 3개의 이미지가 있는 웹페이지가 있다고 해보자. 브라우저가 이 페이지를 보여주려면 네 개의 HTTP 트랜잭션을 만들어야 한다. 하나는 해당 HTML을 받기 위해, 나머지 세 개는 첨부된 이미지를 받기 위한 것이다. 각 트랜잭션이 새로운 커넥션을 필요로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것이다.

이를 해결하기 위해 다음과 같은 기술이 있다.

1. 병렬(parallel) 커넥션 : 여러 개의 TCP 커넥션을 통한 동시 HTTP 요청
2. 지속(persistent) 커넥션 : 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위한 TCP 커넥션의 재활용
3. 파이프라인(pipelined) 커넥션 : 공유 TCP 커넥션을 통한 병렬 HTTP 요청
4. 다중(multiplexed) 커넥션 : 요청과 응답들에 대한 중재

1. 병렬 커넥션 

HTTP 클라이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 된다. 만약 4개의 이미지를 전달받는다면 할당받은 각 TCP 커넥션상의 트랜잭션을 토해 병렬로 내려받는다.

각 커넥션의 지연 시간을 겹쳐 총 지연시간을 줄이고, HTML 먼저 내려받고 남은 세 개의 트랜잭션이 각각 별도의 커넥션에서 동시에 처리된다. 이미지들을 병렬로 내려받아 커넥션 지연이 겹쳐짐으로써 총 지연시간이 줄어든다.

하지만 병렬 커넥션이 항상 더 빠르지는 않다.

만약 클라이언트의 네트워크 대역폭이 좁다면 대부분 시간을 데이터를 전송하는 데만 쓸 것이다. 여러 개의 객체를 병렬로 내려받는 경우, 이 제한된 대역폭 내에서 각 객체를 전송받는 것은 느리기 때문에 성능상의 장점은 거의 없어진다.

또한 다수의 커넥션은 메모리를 많이 소모하고 자체적인 성능 문제를 발생시킨다.  백 명의 가상 사용자가 각각 100개의 커넥션을 맺고 있다면, 서버는 총 10,000개의 커넥션을 맺게 되는 것이다. 이는 서버의 성능을 크게 떨어뜨린다. 

브라우저는 이러한 이유로 실제 병렬 커넥션을 사용하긴 하지만 적은 수(대부분 4개)의 병렬 커넥션만을 허용한다.

병렬 커넥션의 단점

• 각 트랜잭션마다 새로운 커넥션을 맺고 끊기 때문에 시간과 대역폭이 소요된다.
• 각각의 새로운 커넥션은 TCP 느린 시작 때문에 성능이 떨어진다.
• 실제로 연결할 수 있는 병렬 커넥션의 수에는 제한이 있다.

2. 지속 커넥션

HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용 할 수 있다. 처리가 완료된 후에도 계속 연결된 상태로 있는 TCP 커넥션을 지속 커넥션이라고 부른다. 비지속 커넥션은 각 처리가 끝날 때마다 커넥션을 끊지만, 지속 커넥션은 클라이언트나 서버가 커넥션을 끊기 전까지는 트랜잭션 간에도 커넥션을 유지한다. 해당 서버에 이미 맺어져 있는 지속 커넥션을 재사용함으로써, 커넥션을 맺기 위한 준비작업에 따르는 시간을 절약할 수 있다. 게다가 이미 맺어져 있는 커넥션은 TCP의 느린 시작으로 인한 지연을 피함으로써 더 빠르게 데이터를 전송할 수 있다.

그렇다면 지속 커넥션과 병렬 커넥션 중 어떤것이 더 빠를까?

지속 커넥션은 병렬 커넥션에 비해 몇 가지 장점이 있다. 커넥션을 맺기 위한 사전 작업과 지연을 줄여주고, 튜닝된 커넥션을 유지하며, 커넥션의 수를 줄여준다.  하지만 지속 커넥션을 잘못 관리할 경우, 계속 연결된 상태로 있는 수많은 커넥션이 쌓이게 된다. 이는 로컬의 리소스 그리고 원격의 클라이언트와 서버의 리소스에 불필요한 소모를 발생시킨다.

지속 커넥션은 병렬 커넥션과 함께 사용될 때에 가장 효과가 좋다.  두 가지 지속 커넥션 타입이 있다.

1. HTTP/1.0+ : keep-alive
2. HTTP/1.1 : 지속 커넥션

HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection:Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 응답에 Connection:Kepp-Alive 헤더가 없으면, 클라이언트는 서버가 keep-alive를 지원하지 않으며, 응답 메시지가 전송되고 나면 서버 커넥션을 끊을 것이라 추정한다.

Keep-Alive 헤더 사용 다음의 예는 서버가 약 5개의 추가 트랜잭션이 처리될 동안 커넥션을 유지하거나, 2분 동안 커넥션을 유지하라는 내용의 Keep-Alive 응답 헤더다.

HTTP/1.1의 지속 커넥션

HTTP/1.1에서는 keep-alive 커넥션을 지원하지 않는 대신, 설계가 더 개선된 지속 커넥션을 지원한다. 

기본적으로 활성화 되어 있으며 별도 설정을 하지 않는 한, 모든 커넥션을 지속 커넥션으로 취급한다. HTTP/1.1 애플리케이션은 트랜잭션이 끝난 다음 커넥션을 끊으려면 Connection: close 헤더를 명시해야 한다. 하지만 헤더가 없더라도 커넥션을 영원히 유지하겠다는 것을 뜻하지는 않는다.

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다. 이 데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다. 이 메시지는 클라이언트, 서버, 프락시 사이를 흐른다.

'인바운드', '아웃바운드', '업스트림', '다운스트림'은 메시지의 방향을 의미하는 용어이다.

메시지는 원 서버 방향을 인바운드로 하여 송신된다

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메시지가 원 서버로 향하는 것은 인바운드로 이동한느 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것이다.

다운스트림으로 흐르는 메시지

HTTP 메시지는 강물과 같이 흐른다. 요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

메시지의 각 부분

HTTP 메시지는 단순한, 데이터의 구조화된 블록이다. 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다. 시작줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있으며, 본문은 아예 없을 수도 있다.

시작줄 

모든 HTTP 메시지는 시작줄로 시작한다. 요청 메시지의 시작줄은 무엇을 해야 하는지 말해준다. 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.

요청줄

요청 메시지는 서버에게 리소스에 대해 무언가를 해달라고 부탁한다. 요청 메시지의 시작줄, 혹은 요청줄에는 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 그 동작에 대한 대상을 지칭하는 요청 URL이 들어있다. 또한 요청줄은 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에 알려주는 HTTP 버전도 포함한다.

 이 모든 필드는 공백으로 구분된다. 위 그림에서 요청 메서드는 GET이고, 요청 URL은 /test/hi-there.txt 이며, 버전은 HTTP/1.1이다. 

응답줄

응답 메시지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다. 응답 메시지의 시작줄 혹은 응답줄에는 응답 메시지에서 쓰인 HTTP의 버전, 숫자로 된 상태 코드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있다.

이 모든 필드는 공백으로 구분된다. 위 그림에서 HTTP 버전은 HTTP/1.0이고, 상태 코드는 200(성공)이며, 사유 구절은 OK로 문서가 성공적으로 반환되었음을 의미한다.

메서드

요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다. 예를 들어, 'GET/specials/saw-blase.gif HTTP/1.0' 이라는 줄에서 메서드는 GET이다.

상태 코드

메서드가 서버에게 무엇을 해야 하는지 말해주는 것처럼, 상태 코드는 클라이언트에게 무엇이 일어났는지 말해준다. 상태 코드는 응답의 시작줄에 위치한다. 예를 들어, 'HTTP/1.0 200 OK'라는 줄에서 상태 코드는 200이다.

GET 

GET은 가장 흔히 쓰이는 메서드다. 주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다. 

HEAD

HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다. 엔터티 본문은 결코 반환되지 않는다. 이는 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해준다. HEAD를 사용하면,

• 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
• 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다.

PUT

GET 메서드가 서버로부터 문서를 읽어 들이는데 반해 PUT 메서드는 서버에 문서를 쓴다. 어떤 발행 시스템은 사용자가 PUT을 이용해 웹페이지를 만들고 웹 서버에 직접 게시할 수 있도록 해준다.

PUT 메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다. PUT은 콘텐츠를 변경할 수 있게 해주기 때문에, 많은 웹 서버가 PUT을 수행하기 전에 사용자에게 비밀번호를 입력하여 로그인을 하도록 요구할 것이다.

POST

POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다. 실제로, HTML 폼을 지원하기 위해 흔히 사용된다. 채워진 폼에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는 곳에 보낸다. 

URL(Uniform Resource Locator)은 인터넷의 리소스를 가리키는 표준이름이다. URL은 전자정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.

인터넷의 리소스 탐색하기

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷상의 수십억 개의 리소스를 찾고 사용하며 공유할 수 있다. 그리고 URL을 통해 사람이 HTTP 및 다른 프로토콜을 통해 접근할 수 있다. 사용자는 브라우저에 URL을 입력하고 브라우저는 화면 뒤에서 사용자가 원하는 리소스를 얻기 위해 적잘한 프로토콜을 사용하여 메시지를 전달한다.

예를들어

http://www.joes-hardware.com/seasonal/index-fall.html 이라는 URL을 불러오고 싶다고 가정해보자.

• URL의 첫 부분인 http는 URL의 스킴이다. 스킴은 웹 클라이언트가 리소스에 어떻게 접근하는지 알려준다. 이 경우에, URL이 HTTP프로토콜을 사용한다.
• URL의 두 번째 부분인 www.joes-hardware.com은 서버의 위치이다. 이는 웹 클라이언트가 리소스가 어디에 호스팅 되어 있는지 알려준다.
• URL의 세 번째 부분인 /seasonal/index-fall.html은 리소스의 경로이다. 경로는  서버에 존재하는 로컬 리소스들 중에서 요청받은 리소스가 무엇인지 알려준다.

URL은 HTTP 프로토콜이 아닌 다른 가용한 프로토콜을 사용할 수도 있다. 

• mailto:president@withehouse.gov

는 이메일 주소를 가리키며,

• ftp://ftp.lots-o-books.com/pub/complete-price-list.xls

는 FTP(File Transfer Protocol) 서버에 올라가 있는 파일을 가리키고 

• rstp://www.joes-hardware.com:554/interview/cto_video

는 스트리밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영화를 가리킨다. 이렇게 URL은 인터넷에 있는 어떤 리소스든지 가리킬 수 있다.

URL 문법

URL로 인터넷상의 모든 리소스를 찾을 수 있지만, 그 리소스들은 다른 스킴(예들들어 HTTP, FTP, SMTP)을 통해 접근할 수 있으며, URL문법은 스킴에 따라서 달라진다. 

다른 URL 스킴을 사용한다는 것이 전혀 다른 문법을 사용한다는 뜻일까? 사실을 그렇지 않다.

대부분의 URL 스킴의 문법은 일반적으로 9개의 부분으로 나뉜다.

이 모든 컴포넌트를 가지는 URL은 거의 없다. URL의 가장 중요한 세 가지 컴포넌트는 스킴, 호스트, 경로다.

예들 들어 http://www.joes-hardware.com:80/index.html 이라는 URL이 있다고 가정했을때

스킴은 'http'

호스트는 'www.joes-hardware.com'

포트는 '80'

경로는 'index.html'

이 된다.

스킴 : 사용할 프로토콜

스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다. 이는 URL을 해석하는 애플리케이션이 어떤 프로콜을 사용하여 리소스를 요청해야 하는지 알려준다. 위에서 예로 사용한 URL의 스킴은 'http' 이다.

스킴 컴포넌트는 알파벳으로 시작해야 하고 URL의 나머지 부분들과 첫 번째 ':' 문자로 구분한다. 스킴 명은 대소문자를 가리지 않기 때문에

'http://www.joes-hardware.com'와 HTTP://www.joes-hardware.com' 는 같다.

호스트와 포트

애플리케이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.

URL의 호스트와 포트 컴포넌트는 그 두 가지 정보를 제공해준다.

호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다. 해당 값은 위에서와 같이 ('www.joes-hardware.com') 호스트 명이나 IP주소로 제공한다. 

• http://www.joes-hardware.com:80/index.html
• http://125.92.228.48:80/index.html

포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킨다. 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 사용한다.

경로

URL의 경로 컴포넌트는 리소스가 서버의 어디에 있는지 알려준다. 해당 경로는 아래 예와 같이 계층적 파일 시스템 경로와 유사한 구조를 가진다. 

• http://www.joes-hardware.com:80/seasonal/index-fall.html

이 URL의 경로는 '/seasonal/index-fall.html'로 유닉스 파일 시스템의 파일 경로와 유사하다. 경로는 서버가 리소스의 위치를 찾는데 사용하는 정보다. HTTP URL에서 경로 컴포넌트는 '/' 문자를 기준으로 경로조각으로 나눈다. 

웹에서 쓰이는 일번 스킴들의 포맷

메시지

HTTP 메시지는 단순한 줄 단위의 문자열이다. 

웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지를 요청 메시지라고 부른다. 서버에서 클라이언트로 가는 메시지는 응답 메시지라고 부른다. 그 외의 HTTP 메시지는 없다. HTTP 요청과 응답 메시지의 형식은 굉장히 비슷하다.

- 시작줄 

  메시지의 첫 줄은 시작줄로, 요청이라면 무엇을 해야 하는지 응답이라면 무슨 일이 일어났는지 나타낸다.

- 헤더

  시작줄 다음에는 0개 이상의 헤더 필드가 이어진다. 각 헤더 필드는 쉬운 구문분석을 위해 쌍점(:)으로 구분되어 있는 하나의 이름과 하나의 값으로 구성된다.

- 본문

  빈 줄 다음에는 어떤 종류의 데이터든 들어갈 수 있는 메시지 본문이 필요에 따라 올 수 있다. 요청의 본문은 웹 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다.

TCP 커넥션

TCP / IP

HTTP는 애플리케이션 계층 프로토콜이다. HTTP는 네트워크 통신의 핵심적인 세부사항에 대하여 신경 쓰지 않는다. 대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP 에게 맡긴다.

TCP가 제공한는 것

• 오류 없는 데이터 전송
• 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다)
• 조각나지 않는 데이터 스트림(언제든 어떤 크기로 보낼 수 있다)

TCP/IP 는 TCP 와 IP가 층을 이루는, 패킷 교환 네트워크 프로토콜의 집합이다. 어떤 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해 준다.

일단 TCP 커넥션이 맺어지면, 클라이언트와 서버 컴퓨터 간에 교환되는 메시지가 없어지거나, 손상되거나, 순서가 뒤바뀌어 수신되는 일은 결코 없다.

네트워크 개념상, HTTP 프로토콜은 TCP 위의 계층이다. HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용한다. 

접속, IP 주소 그리고 포트번호

HTTP 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.

TCP 커넥션을 맺는 것은 다른 회사 사무실에 있는 누군가에게 전화를 거는 것과 다소 비슷하다. 

TCP에서는 서버 컴퓨터에 대한 IP 주소와 그 서버에서 실행중인 프로그램이 사용중인 포트번호가 필요하다.

URL을 사용하여 IP주소와 포트번호를 알아낸다.

예시 ) http://www.netscape.com:80/index.html 

URL은 도메인 이름 혹은 호스트 명, IP 주소가 있으며 포트번호(80)을 가지고 있다. 호스트 명은 도메인 이름 서비스(DNS)라 불리는 장치를 통해 쉽게 IP로 변환될 수 있다.

웹의 구성요소

1. 프락시 : 클라이언트와 서버 사이에 위치한 HTTP 중개자
2. 캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
3. 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버
4. 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
5. 에이전트 : 자동화된 HTTP 요청을 만드는 웹클라이언트

1. 프락시

웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소인 HTTP 프락시 서버에 대해 살펴보자.

그림과 같이 프락시는 클라이언트와 서버 사이에 위치하며 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. 이 애플리케이션은 사용자를 위한 프락시로 동작하며 사용자를 대신해 서버에 접근한다.

프락시는 주로 보안을 위해 사용된다. 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 한다. 또한 프락시는 요청과 응답을 필터링한다. 예를 들어 무언가를 다운받을 때 바이러스를 검출한다.

2. 캐시

웹캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해 두는, 특별한 종류의 HTTP 프락시 서버다. 클라이언트는 멀리 떨어진 웹 서버보다 근처의 캐시에서 더 빨리 문서을 다운 받을 수 있다. HTTP는 , 캐시를 효율적으로 동작하게 하고 캐시된 콘텐츠를 최신 버전으로 유지하면서 동시에 프라이버시도 보호하기 위한 많은 기능을 정의한다.