▶ HTTP
하이퍼텍스트 전송 프로토콜 ( HTTP, Hypertext Transfer Protocol ) 은 월드 와이드 웹에서 데이터를 액세스 하는 데 주로 사용되는 프로토콜이다. 이 프로토콜은 플레인 텍스트, 하이퍼텍스트, 오디오, 영상 등의 형태로 데이터를 전송한다. 하지만 이 프로토콜이 하이퍼텍스트 전송 프로토콜로 불리는 이유는 문서간의 빠른 이동이 가능한 하이퍼텍스트 환경에서의 효율성 때문이다.
HTTP의 기능은 FTP와 SMTP의 조합과 비슷하다. 이는 파일을 전송하고 TCP의 서비스를 사용한다는 점에서 FTP와 비슷하다. 그러나 이 프로토콜은 단지 하나의 TCP 연결만을(잘 알려진 80port)사용하기 때문에 FTP보다 훨씬 간단하다. 별도의 제어 연결 없이 단지 데이터만 클라이언트와 서버 사이에 전송된다.
HTTP는 SMTP와도 유샇나데, 그 이유는 클라이언트와 서버 사이에 전송되는 데이터가 SMTP 메시지와 비슷하게 보이기 때문이다. 또한 메시지의 형식이 MIME와 비슷한 헤더에 의해 제어된다. 하지만 HTTP는 메시지가 클라이언트와 서버 사이에서 양 방향으로 전송된다는 점에서 SMTP와 다르다. 또 다른 차이점은 SMTP 메시지는 결국 사람이 읽게 되지만, HTTP 메시지는 HTTP서버와 HTTP클라이언트(브라우저)에 의해 읽혀지고 해석된다는 점이다. SMTP 메시지는 저장된 후전달되지만, HTTP 메시지는 즉시 전될되는것도 또 하나의 차이다.
HTTP의 아이디어는 매우 간단하다. 클라이언트는 전자우편과 비슷하게 보이는 요청을 서버에게 보낸다. 서버는 전자우편 응답과 비슷하게 보이는 응답을 클라이언트에 보낸다. 요청과 응답 메시지는 MIME와 비슷한 형식을 갖는 편지 형태로 메이터를 운반한다.
서버에 대한 클라이언트의 명령은 편지 형태의 요청 메시지에 포함된다. 요청되어진 파일의 내용이나 다른 정보도 또한 편지 형태의 응답 메시지에 내장된다.
▶ 트랜잭션
클라이언트와 서버 사이의 HTTP 트랜잭션을 나타내었다. 비록 HTTP가 TCP의 서비스를 이용하지만, HTTP 자체는 상태가 존재하지 않는( STATELESS ) 프로토콜이다. 클라이언트 요청 메시지를 보내어 트랜잭션을 초기화 한다. 서버는 응답을 보내어 대답한다.
HTTP에는 두 가지 일반적인 유형의 메시지가 있다. 이 메시지들은 두곳다 거의 같은 형식을 갖는다.
1. 요청 메시지
요청 메시지는 요청 라인, 헤더 그리고 때때로 본문으로 구성된다.
a ) 요청 라인 ( Request Line )
▨ HTTP 트랜잭션
◑ 메소드는 문서를 검색하는 데 사용되는 프로토콜이다. 문서를 검색하는
데는 여러가지 프로토콜들이 사용될 수 있다. 이들 중에 HTTP와 FTP가
있다. 메소드는 요청 유형
◑ 호스트(Host)
정보가 위치하고 있는 컴퓨터이다. 이 컴퓨터의 이름은 별칭으로 나타낼
수 있다. 웹 페이지들은 보통 컴퓨터에 저장되어 있고, 컴퓨터는 보통 WWW
란 글자로시작되는 별칭 이름을 갖는다. 그러나 이는 강제적인 사항은 아니
므로, 호스트는 웹 페이지를 갖고 있는 컴퓨터에 주어진 어떤 이름도 될 수
있다.
◑ URL에 서버의 포트 번호를 사용하는 것은 선택이다. 만일 포트가 포함된다
면 이는 호스트와 경로 사이에 위치해야 한다. 그리고 콜론을 사용해 호스트
와 분리되어야 한다.
◑ 경로(Path)
정보가 위치하고 있는 파일의 경로 이름. UNIX 운영 체제에서 경로는
서브 디렉토리와 파일들을 디렉토리로부터 분리하는 사선을 사용한다는
점을 유념!
◑ 버전(Version)
현재 대부분의 HTTP 버전이 1.1이지만 HTTP버전 1.0RHK 0.9도 여전히
사용된다.
◁ 메소드
요청 메시지의 요청 종류 필드는 메소드(method)라고 불리는 여러 종류의 메시지를
정의. 요청 메소드는 클라이언트가 서버에게 보내는 실제 명령이거나 요청이다.
◑ GET
클라이언트가 서버로부터 문서를 읽어오기 원할 때 사용된다. 문서의 주소는
URL에 정의되어 있다. 이는 문서를 검색하는 주요 메소드이다. 서버는 오류가 없
는 경우 보통 응답 메시지의 본문에 문서의 내용을 담아서 응답한다.
◑ HEAD
클라이언트가 문서 자체가 아니라 문서에 대한 어떤 정보를 원할 때 사용된다.
이는 GET과 비슷하지만 서버로부터 응답에 본문이 없다는 점이 다르다.
◑ POST
클라이언트가 서버에게 어떤 정보를 제공할 때 사용된다. 예를 들어 서버에게
입력을 보내는 데 사용될 수 있다.
◑ PUT
클라이언트가 서버에 저장될 새 문서 혹은 교체 문서를 제공하기 위해 사용된다.
문서는 요청의 본문에 포함되고 URL에 의해 지정된 위치에 저장될 것이다.
◑ PATCH
PUT과 비슷하나 요청이 기존 파일에서 구현외어야 하는 변경사항의 목록만을
포함하고 있다는 점이 다르다.
◑ COPY
파일을 다른 위치로 복사하기 위해 사용된다. 원본 파일의 위치는 요청 라인
(URL)에서 주어지고 목적지의 위치는 항목 헤더(헤더 절에서 설명 된다.)에서
주어진다.
◑ MOVE
COPY와 동일
◑ DELETE
서버에서 문서를 제거하기 위해 사용된다.
◑ LINK
문서에서 다른 위치로의 링크나 링크들을 생성하기 위해 사용된다. 파일의 위치
는 요청라인에서 주어지고 목적지의 위치는 항목 헤더에서 주어진다.
◑ UNLINK
LINK메소드에 의해 생성된 링크를 삭제하기 위해 사용된다.
◑ OPTION
클라이언트가 서버에게 사용 가능한 옵션을 질의하기 위해 사용된다.
2. 응답 메시지
a ) 응답 메시지는 상태 라인, 헤더 그리고 때때로 본문으로 구성된다.
b ) 상태 라인
상태 라인(status line)은 응답 메시지의 상태를 정의한다.
이는 HTTP 버전, 공백, 상태 코드, 상태 문구로 구성된다.
◑ HTTP 버전
이 필드는 요청 라인의 필드와 동이.
◑ 상태 코드(status code)
상태 코드 필드는 FTP와 SMTP 프로토콜에 있는 것과 유사하다.
이는 세 자리 숫자로 구성된다.
c ) 헤더
헤더는 클라이언트와 서버 사이에 추가적인 정보를 교환한다. 예를 들어
클라이언트가 특별한 형식으로 문서가 전송되도록 요청할 수도 있고, 또는
서버가 문서에 대한 추가적인 정보를 정송할 수도 있다.
헤더는 한 줄 이상의 헤더 라인이 돌 수 있다. 각 헤더 라인은 헤더 이름,
콜론, 공백, 해더 값으로 구성된다.
헤더 라인은 일반 헤더, 요청 헤더, 응답 헤더 그리고 항복(entity)헤더 네 가지
분류 중 하나에 속하게 된다. 요청 메시지는 일반 요청 항목 헤더만을 포함할
수 있다. 반면에 응답 메시지는 일반 응답 항목 헤더만을 포함할 수 있다.
◑ 헤더
1 ) 일반헤더
메시지에 대한 일반적인 정보를 제공하며 요청과 응답에 모두 존재할 수있다.
2 ) 요청 헤더
요청 메시지에만 존재할 수 있다. 이는 클라이언트의 구성과 클라이언트가 선호하는
문서 형식을 지정한다.
3 ) 응답 헤더
응답 메시지에만 존재할 수 있다. 이는 서버의 구성과 요청에 대한 특별한 정보를
지정한다.
4 ) 개체 헤더
문서의 본론에 대한 정보를 제공한다. 이는 주로 응답 메시지에 존재하지만,
POST나 PUT 메소드와 같이 본문을 포함하는 몇 가지 요청 메시지도 또한 이러한
종류의 헤더를 사용한다.
◑ 예제 !!
이 그림은 문서에 대한 정보를 읽어오는 것으로, HEAD 메소드를 사용하여 HTML 문서에 대한 정보를 읽어 온다. 요청 라인은 메소드(HEAD), URL, HTTP 버전(1.1)을 표시한다. 헤더는 한 줄로서 클라이언트가 문서를 어떠한 형식으로도 받을 수 있음(WILDCARD)을 나타낸다. 요청은본문을 포함하지 않는다. 응답 메시지는 상태 라인과 다섯 줄의 헤더를 포함한다. 헤더라인은 날짜, 서버, MIME 버전, 문서의 유형, 문서의 길이를 정의한다. 응답메시지가 본문을 포함하지 않는다는 점을 주의!!!
▶ 영속적 대 비영속적 연결
HTTP 버전 1.0은 비영속적 연결을 사용하였으나, 버전 1.1에서는 영속적 연결이 기본이다.
◑비영속적 연결 ( nonpersistent connection )
- 각 요청/응답에 대해 하나의 TCP연결이 만들어 진다.
1. 클라이언트가 TCP연결을 열고 요청을 보낸다.
2. 서버는 응답을 보내고 연결을 닫는다.
3. 클라이언트는 end-of-file 표시가 나타날 때까지 데이터를 읽고, 그 후 연결을
닫는다.
- 이체제에서는 서로 다른 파일에 있는 N개의 다른 그림들을 위해 연결을 N번 열고
닫아야 한다. 비영속적 연결은 서버에 큰 오버헤드를 부과하게 되는데, 그 이유는
서버가 N개의 다른 버퍼들은 필요로 하고 연결이 열릴 때마다 slow start 과정을
요구하기 때문이다.
◑ 영속적 연결( persistent connection )
버전 1.1에서 기본으로 지정되며, 영속적 연결에서 서버는 응답을 전송한 후에 차후의 요청을 위해 연결을 열어놓은 상태로 유지한다. 서버는 클라이언트에 요청이 있을 때나 타임아웃이 되면 연결을 닫을 수 있다. 서버는 보통 각 응답에 데이터의 길이를 송신한다. 하지만 송신자가 데이터의 길이를 알지 못하는 경우가 가끔 있다. 이는 문서가 동적으로 또는 액티브하게 생성되는 경우이다. 이러한 경우에 서버는 클라이언트에게 길이를 알지 못한다는 것을 알리고 데이터 전송 후 연결을 닫는데, 그 이유는 클라이언트가 데이터의 끝이 어디라는 것을 알리도록 하기 위함이다.
▶ 프록시 서버
HTTP는 프록시 서버(proxy server)를 지원한다. 프록시 서버는 최신 요청에 대한 응답들의 복사본을 갖고 있는 컴퓨터이다. 프록시 서버가 있으면 HTTP 클라이언트는 프록시 서버로 요청을 보낸다.
프록시 서버는 캐시를 검사한다. 만일 응답이 캐시에 저장되어 있지 않으면, 프록시 서버는 적절한 서버로 요청을 보낸다. 들어온 응답은 프록시 서버로 보내지고 다음에 있을 다른 클라이언트의 요청에 대비해 저장된다.
프록시 서버는 원래 서버의 부하를 줄이고, 트랙픽을 감소시키며, 지연을 개선한다. 하지만 프록시 서버를 사용하기 위해서 클라이언트는 대상 서버 대신 프록시를 액세스하도록 설정되어 있어야 한다.
출처 : 데이터통신과 네트워크 , 저자 : 까먹었내요 ㅠ