[HTTP] HTTP란

프로토콜(protocol)이란?

• 컴퓨터와 컴퓨터 사이, 또는 한 장치와 다른 장치 사이에서 데이터를 원활히 주고받기 위하여 약속한 여러 가지 규약

  • 이 규약에는 신호 송신의 순서, 데이터의 표현법, 오류 검출법 따위가 있음

• 통신 시스템이 데이터를 교환하기 위해 사용하는 통신 규칙

• OSI 7계층 모델에서는 각 계층에서 수행되는 프로토콜이 서로 독립적이라고 간주

  • 따라서 계층 1은 계층 1끼리 통신할 수 있는 프로토콜이 존재하고, 계층 2는 계층 2끼리 통신할 수 있는 프로토콜이 존재

OSI 7계층

네트워크 지원 계층

• 한 장치에서 다른 장치로 데이터를 이동할 때 필요한 물리적인 면 처리

  • 물리적인 면 : 전기적인 규격, 물리적인 연결, 물리 주소, 전송시간과 신뢰도 등

• 1계층 Physical layer (물리층)

  • 물리적 매체를 통해 비트 흐름을 전송하기 위해 필요한 기능들을 조정하고, 인터페이스의 기계적 . 전기적 규격, 전송매체를 다룸

  • 물리적인 장치와 인터페이스가 전송을 위해 필요한 기능과 처리절차를 규정함

• 2계층 Data link layer (데이터링크층)

  • 가공되지 않은 내용의 전송을 담당하는 물리층을 신뢰성 있는 링크로 변환시켜 주고 노드-대-노드 전달(node-to-node delivery)함

• 3계층 Network layer (네트워크층)

  • 패킷을 발신지로부터 여러 네트워크(링크)를 통해 목적지까지 전달함

전송층

• 종단-대-종단까지의 믿을만한 데이터 전송 보장

• 4계층 Transport layer (전송층)

  • 전체 메시지의 프로세스-대-프로세스 전달을 함

사용자 지원계층

• 서로 상관없는 소프트웨어 시스템 사이의 상호연동이 가능하게 함

• 5계층 Session layer (세션층)

  • 네트워크의 대화 조정자로 통신하는 시스템들 사이의 상호작용을 설정/유지하고 동기화 함

• 6계층 Presentation layer (표현층)

  • 두 시스템 사이에서 교환되는 정보의 구문과 의미에 관련되어 변환, 압축 및 암호화를 담당함

• 7계층 Application layer (응용층)

  • 사용자(사람 또는 소프트웨어)가 네트워크에 접근할 수 있도록 함

  • 사용자 인터페이스를 제공하고, 전자우편, 원격 파일접근과 전송, 공유 데이터베이스 관리 및 여러 종류의 분산정보 서비스를 제공함

HTTP(hypertext transfer protocol)

• 인터넷에서 하이퍼텍스트(hypertext) 문서를 교환하기 위하여 사용되는 통신규약

  • 하이퍼텍스트 : 문서 중간중간에 특정 키워드를 두고 문자나 그림을 상호 유기적으로 결합하여 연결시킴으로써, 서로 다른 문서라 할지라도 하나의 문서인 것처럼 보이면서 참조하기 쉽도록 하는 방식을 의미

• 1989년 팀 버너스 리(Tim Berners Lee)에 의하여 처음 설계되어 인터넷을 통한 월드 와이드 웹(World-Wide Web) 기반에서 전 세계적인 정보공유를 이루는데 큰 역할을 함

  • HTTP의 첫번째 버전은 인터넷을 통하여 가공되지 않은 데이터를 전송하기 위한 단순한 프로토콜이었으나, 데이터에 대한 전송과 요구 . 응답에 대한 수정 등 가공된 정보를 포함하는 프로토콜로 개선

• 인터넷 주소를 지정할 때 ‘http://www…’와 같이 하는 것은 www로 시작되는 인터넷 주소에서 하이퍼텍스트 문서의 교환을 http 통신규약으로 처리하라는 뜻

• 분산 하이퍼미디어 환경에서 빠르고 간편하게 데이터를 전송하는 프로토콜

• HTTP는 80번 포트를 사용하도록 정의

  • 따라서 HTTP 서버는 80번 포트에서 대기하고, 클라이언트는 TCP를 사용해 연결을 설정

• 웹 브라우저는 사용자가 요청하는 자원을 가리키는 URL 주소에 사용할 응용 프로토콜을 표현할 수 있음

  • URL 주소의 첫 번째 부분을 사용해 서비스의 유형을 표현

  • 예) HTTP 서버로부터 웹 정보를 얻으려면 http://www.korea.co.kr과 같이 URL주소에 HTTP를 사용한다고 명시
    FTP 서버에 접근하려면 ftp://www.korea.co.kr로, 텔넷(Telnet) 서버를 사용하면 telnet://www.korea.co.kr로 표현

  • HTTP의 명령에 해당하는 HTTP 메소드 (HTTP Method)를 이용해 클라이언트가 서버에 데이터를 전송하고, 반대로 서버에서 클라이언트로 데이터를 회신할 수 있음
    클라이언트가 서버에 데이터를 요청할 때는 GET 메소드를 클라이언트에서 서버로 회신할 때는 POST메소드를 사용

• RFC 2016으로 발표된 HTTP 1.1버전은 클라이언트의 요청(Request)와 서버의 응답(Reply)에 동작하는 아주 간단한 프로토콜

• 동작 원리

  • HTTP 클라이언트가 서버에 요청을 전송
    요청 내용에는 프로토콜 명령에 해당하는 요청 메소드(method), URL, HTTP 버전, 기타 클라이언트의 요청 내용에 관련된 부가 정보 포함.

  • HTTP 서버는 요청을 처리한 결과를 의미하는 프로토콜 응답코드가 포함된 상태 정보를 회신
    클라이언트가 요청한 기타 정보도 함께 회신

• HTTP는 비상태(Stateless) 프로토콜로 분류

  • TCP 연결이 하나 설정되면서 요청과 응답 과정이 진행되고,
    이후 바로 TCP 연결이 해제되기 때문에 둘 사이에는 연결 존재에 따른 상태 정보가 존재하지 않음

  • 이런 단발성의 연결 방식은 웹 문서가 작고 간단할 때는 상관 없지만, 웹 문서의 내용이 복잡하면 문제를 야기함
    즉, 웹 문서 하나가 다양한 그림 정보, 데이터 파일과 연관되기 때문에 성능이 저하될 수 있음

• HTTP의 요청 – 응답 메시지는 MIME(Multipurpose Internet Message Extensions) 유사 구조를 사용해 데이터를 전송

  • 웹 브라우저에서 발생하는 모든 메시지는 MIME 개체와 거의 유사하게 표현되며, 서버에서 전송된 데이터도 MIME 개체로 표현

• HTTP에서 얘기하는 MIME 유사 개체와 RFC 2045에 기술된 MIME 개체의 큰 차이

  • HTTP의 MIME 유사 개체에는 Content-Length라는 헤더 필드가 존재
    Content-Length 필드는 개체를 전송하는 데 필요한 바이트 수

  • HTTP의 MIME 유사 개체는 MIME 표준인 Content-Transfer-Encoding 헤더 필드 대신
    Content-Encoding과 Transfer-Encoding 필드를 사용함

HTTP 요청 메시지 구조

• 클라이언트가 서버에 보내는 요청 메시지(Request Message)

  • = 요청문 + 헤더 + 공백 한 줄 + 바디

• 요청문(Request Line)

  • <요청 메소드="">

• 요청 메소드(Request Method)

• 클라이언트가 서버에 실행을 요구하는 명령을 기술

• 주요 명령 : GET / POST / HEAD / PUT (이외 delete 등이 있음)

• Get : 클라이언트가 서버에 URL이 가리키는 웹 문서의 내용을 전송하도록 요구
  문서 내용은 서버가 회신하는 응답메시지의 바디에 포함된다.

• POST : 클라이언트가 서버에 정보를 전송할 수 있도록 함
  보통 게시판, 방명록처럼 사용자로부터 입력된 정보를 서버에 전달하는 용도로 사용

• HEAD : 문서 내용보다는 특정 문서 정보를 원할 때 사용

• PUT : 클라이언트가 서버에 문서를 전달하려고 사용. 문서 내용은 바디에 포함

• 예) 클라이언트의 요청문 - GET/ HTTP/1.1

  • 요청 메소드 GET

  • URL은 /

  • HTTP 버전은 HTTP/1.1

  • 웹 서버의 최상위(/)에 위치한 자원을 얻고자 함을 의미

  • 클라이언트가 HTTP 버전 1.1을 지원함을 알 수 있음

• 요청문 밑의 헤더는 클라이언트와 서버 사이의 부가 정보를 전달하는 목적으로 사용
  형식 : ‘<헤더 이름=""> : <헤더 값="">'

HTTP 응답 메시지 구조

• 클라이언트로부터 요청 메시지를 수신한 서버는 해당 요구를 처리한 후에 그 결과를 응답 메시지 형식으로 회신

• 응답 메시지(Reply Message)의 구조는 요청메시지와 거의 동일

  • = 상태문 + 헤더 + 공백 한 줄 + 바디

  • 요청문 대신 처리 결과를 의미하는 상태문(Status Line)이라는 용어를 사용

• 상태문의 내용

  • <상태 코드=""> <상태 이름="">

  • HTTP 버전 : 요청 메시지와 의미 동일

  • 상태코드/상태이름 : 일반 인터넷 응용 프로그램과 구조 동일

• HTTP에 정의된 주요 상태 코드와 상태 이름

  • 200 OK : 요청이 성공적으로 수행되었다.

  • 202 Accepted : 클라이언트의 요청을 수신하였으나, 즉각 실행되지 않고 있다.

  • 400 Bad Request : 요청 메시지의 내용에 문법 오류가 존재한다.

  • 401 Unauthorized : 요청의 실행에 필요한 적절한 권한이 존재하지 않는다.

  • 403 Forbidden : 서비스 요청이 거부되었다.

  • 404 Not Found : 원하는 문서를 찾을 수 없다.

  • 500 Internal Server Error : 서버에 불가피한 오류가 발생하였다.

  • 501 Not Implemented : 요청 사항을 수행할 수 없다.

HTTP 요청 메시지 스펙

Request-Line
*(( general-header | request-header | entry-header) CRLF)
CRLF
[ message-body ]

• 첫 줄 : Request Line, 여러 종류의 헤더, 줄 바꿈 2회(한 줄 공란), 메시지 바디

• Request Line

  • 요청의 첫 줄은 Request Line이라고 부르는데 스펙상은 Method SP Request-URI SP HTTP-Version CRLF와 같이 정의

  • 요청Method + SP + 요청URI + SP + HTTP버전 + CRLF

  • GET /index.html HTTP/1.1 ←과 같이 생김

• Request Line’s 요청 Method(8가지)

  • GET : 요청 URI의 정보를 가져옴

  • POST : 요청 URI의 리소스의 새로운 정보를 보냄

  • HEAD : GET 요청에서 body는 제외하고 헤더만 가져옴

  • OPTIONS : 요청 URI에서 사용할 수 있는 Method를 물어봄

  • PUT : 요청 URI에 저장될 정보를 보냄

  • DELETE : 요청 URI의 리소스를 삭제

  • TRACE : 보낸 메시지를 다시 돌려보냄

  • CONNECT : 프록시에 사용하기 위한 예약된 메서드

• Request Line’s 요청 URI

  • /index.html

  • URL

  • 절대경로의 URI가 될 수도 있고 *이 될 수도 있음

• Request Line’s HTTP 버전

  • 스펙상으로는 “HTTP”, “/”. 1*DIGIT, “.” 와 같이 정의

• Request Line’s SP

  • 줄 바꿈

  • SP : space; 커서를 한 칸 띄움

• Request Line’s CRLF

  • 줄 바꿈

  • CR : carriage return; 커서를 현재 라인의 맨 앞으로 이동

  • LF : linefeed; 커서는 놔둔 채 문서 내용이 한 줄 위로 이동

• Headers

  • Request-Line 다음에는 header가 위치

  • general-header, request-header, entity-header 3가지 종류가 있고 요청에 따라 필요한 헤더만 사용

  • name : content의 형식
    각 값들은 공백이나 탭으로 구분

  • 각 헤더는 CRLF로 구분

• Headers’s General Header

  • Cache-Control, Connection, Data, Pragma, Trailer, Transfer-Enco, Upgrade, Via, Warning

• Headers’s Request Header

  • Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, IF-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent 등

• Headers’s Entity Header

  • Allow, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified, extension-header

HTTP 응답 메시지 스펙

Status-Line
*(( general-header | response-header | entry-header) CRLF)
CRLF
[ message-body ]

• 요청 메시지와 형태가 거의 비슷함

  • 요청라인 대신 상태라인, 요청헤더 대신 응답헤더

• Status Line

  • HTTP-Version SP Status-Code SP Reason-Pharse CRLF로 정의

  • HTTP버전 + SP + 상태코드 + SP + 상태메시지 + CRLF

  • HTTP/1.1 200 OK ←와 같이 생김

• HTTP 버전 / SP / CRLF

  • 요청부분에서 설명한 것과 동일

• 상태코드(Status-Code)는 흔히 보는 3가지 숫자로 된 상태를 나타내는 코드, 각 번호대 별로 의미를 가지고 있음

  • 1xx : 정보성

  • 2xx : 성공

  • 3xx : 리다이렉트

  • 4xx : 클라이언트 오류

  • 5xx : 서버 오류

• 상태메시지

  • 상태 코드에 해당하는 메시지

• Headers

  • General Header / Entity Header : 요청부분에서 설명한 것과 동일

  • Response Header : Accept-Ranges, Age, ETag, Location, Proxy-Authenticate, Retry-After, Server, Vary, WWW-Authenticate

요청 메시지의 예

• HTTP 클라이언트가 전송하는 메시지를 위와 같은 형식으로 작성할 수 있음

  • 가정) HTTP 클라이언트는 임의의 호스트
    HTTP 서버는 uu.ac.kr
    요청 메시지에는 요청문, 헤더 한 행, 공백 한 행이 있으며, 바디는 존재하지 않음

• 요청문

  • GET : 요청 메소드

  • /index.php : URL

  • HTTP/1.1 : HTTP 버전

• 헤더

  • Host: uu.ac.kr의 uu.ac.kr은 클라이언트가 요청하는 자원이 있는 서버의 주소

• 위의 요청 메시지는 HTTP 서버 uu.ac.kr의 최상위 디렉토리 밑에 있는 index.php 파일의 전송을 요청하는 것

응답 메시지의 예

• 앞의 요청메시지를 수신한 HTTP 서버 uu.ac.kr이 회신하는 응답 메시지는 다음과 같은 형식이 가능함

• 상태문 : HTTP/1.1 200 OK

  • HTTP/1.1 : HTTP 버전

  • 200 : 상태코드

  • OK : 상태이름

  • 200 OK는 클라이언트의 요청이 성공적으로 수행되었음을 의미

• 헤더 :

  • 응답 헤더들이 위치

• 바디 :

  • 상태문이 200 OK로, 클라이언트의 요청이 성공적으로 수행되었음을 의미

  • 바디의 내용은 클라이언트가 요청한 index.php 파일의 내용이 포함