HTTP

Web/Common 2011. 12. 29. 17:14

HTTP

위키백과, 우리 모두의 백과사전.
인터넷 프로토콜 스위트
응용 계층BGPDHCPDNSFTPHTTP,IMAPIRCLDAPMGCP,NNTPNTPPOP3RIPRTP,RTSPSDPSIPSMTP,SNMPSOAPSSHTELNET,XMPP, ...
전송 계층TCPUDPDCCPSCTP,RSVP, ...
네트워크 계층IP(v4/v6), ICMPIGMP,ARP/RARP, ...
데이터링크 계층MAC(이더넷토큰링FDDI),PPP, ...
물리적 계층EIA RS-232EIA RS-422EIA RS-449EIA RS-485, ...

HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는WWW 상에서 정보를 주고 받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고 받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년1.1이 각각 발표되었으며, 현재 가장 널리 쓰이는 버전이 1.1이다.

HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다. 이 정보가 모니터와 같은 출력 장치를 통해 사용자에게 나타나는 것이다.

HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있다.

목차

  [숨기기

[편집]요청 메시지

클라이언트가 서버에게 보내는 요청 메시지는 다음을 포함한다.

  • 요청 내용
보기) GET /images/logo.gif HTTP/1.1
  • 헤더
보기) Accept-Language: en
  • 빈 줄 (empty line)
  • 기타 메시지를 포함하여 표시된다

[편집]요청 방법

요청 내용에 포함되는 요청 방법으로는 아래의 8가지가 있다.

HEAD
GET과 같은 요청이지만, 자료에 대한 정보(meta-information)만을 받는다.
GET
URL에 해당하는 자료의 전송을 요청한다.
POST
서버가 처리할 수 있는 자료를 보낸다.
PUT
해당 URL에 자료를 저장한다.
DELETE
해당 URL의 자료를 삭제한다.
TRACE
이전에 요청한 내용을 들을 것을 요청한다.
OPTIONS
서버가 특정 URL에 대해 어떠한 HTTP Method를 지원하는지 묻는다.
CONNECT
프록시가 사용하는 요청.

[편집]오류 코드

클라이언트가 서버에 접속하여 어떠한 요청을 하면, 서버는 세 자리 수로 된 오류 코드와 함께 응답한다. HTTP의 오류 코드는 다음과 같다.

코드메시지설명
1XX Informational(정보) 정보 교환.
100 Continue 클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내주길 바람. (HTTP 1.1에서 처음 등장)
101 Switching Protocols 서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임. (HTTP 1.1에서 처음 등장)
2XX Success(성공) 데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음.
200 OK 오류 없이 전송 성공.
202 Accepted 서버가 클라이언트의 요청을 수락함.
203 Non-authoritavive Information 서버가 클라이언트 요구중 일부만 전송.
204 Non Content 클라이언트의 요구를 처리했으나 전송할 데이터가 없음.
205 Reset Content 새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 함. (브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용됨.) (HTTP 1.1에서 처음 등장)
206 Partial Content 클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음. (HTTP 1.1에서 처음 등장)
3XX Redirection(방향 바꿈) 자료의 위치가 바뀌었음.
300 Multiple Choices 최근에 옮겨진 데이터를 요청.
301 Moved Permanently 요구한 데이터를 변경된 URL에서 찾았음.
302 Moved Permanently 요구한 데이터가 변경된 URL에 있음을 명시. 301과 비슷하지만 새 URL은 임시 저장 장소로 해석됨.

[1]

303 See Other 요구한 데이터를 변경하지 않았기 때문에 문제가 있음.
304 Not modified 클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨 (보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우). [2]
305 Use Proxy 요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. (HTTP 1.1에서 처음 등장)
307 Temporary Redirect 자료가 임시적으로 옮겨짐.
4XX Client Error(클라이언트 오류) 클라이언트 측의 오류. 주소를 잘못 입력하였거나 요청이 잘못 되었음.
400 Bad Request 요청 실패. 문법상 오류가 있어서 서버가 요청사항을 이해하지 못함, [3]
401.1 Unauthorized 권한 없음 (접속실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않음. [4]
401.2 Unauthorized 권한 없음 (서버설정으로 인한 접속 실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지않음. [5]
401.3 Unauthorized 권한 없음 (자원에 대한 ACL에 기인한 권한 없음). 클라이언트가 특정 자료에 접근할 수 없음. [6]
401.4 Unauthorized 권한 없음 (필터에 의한 권한 부여 실패). 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음. [7]
401.5 Unauthorized 권한 없음 (ISA PI/CGI 애플리케이션에 의한 권한부여 실패). 이용하려는 서버의 주소에 ISA PI나 CGI프로그램이 설치되어 있고, 권한을 부여할 수 없음. [8]
402 Payment Required 예약됨.
403.1 Forbidden 금지 (수행접근 금지). 수행시키지 못하도록 되어있는 디렉터리 내의 실행 파일을 수행하려고 하였음.
403.2 Forbidden 금지 (읽기 접근 금지). 접근한 디렉터리에 가용한 기본 페이지가 없음. [9]
403.4 Forbidden 금지 (SSL 필요함). 접근하려는 페이지가 SSL로 보안유지 되고 있음. [10]
403.5 Forbidden 금지 (SSL 128필요함). 페이지가 128비트의 SSL로 보안유지 되고 있음. [11]
403.6 Forbidden 금지 (IP 주소 거부됨). 사용자가 허용되지 않은 IP로부터 접근함.
403.7 Forbidden 금지 (클라이언트 확인 필요). 클라이언트가 자료에 접근할 수 있는지 확인 요함. [12]
403.8 Forbidden 금지 (사이트 접근 거부됨). 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것이 허락되지 않음.
403.9 Forbidden 접근금지 (연결된 사용자수 과다). 서버가 BUSY 상태에 있어서 요청을 수행할 수 없음.
403.10 Forbidden 접근금지 (설정이 확실 하지 않음).
403.11 Forbidden 접근금지 (패스워드 변경됨). 잘못된 암호를 입력했음.
403.12 Forbidden 접근금지(Mapper 접근 금지됨). 클라이언트 인증용 맵이 해당 웹 사이트에 접근하는 것이 거부됨.
404 Not Found 문서를 찾을 수 없음. 서버가 요청한 파일이나 스크립트를 찾지 못함.
405 Method not allowed 메서드 허용 안됨. 요청 내용에 명시된 메서드를 수행하기 위해 해당 자원의 이용이 허용되지 않음. [13]
406 Not Acceptable 받아들일 수 없음. [14]
407 Proxy Authentication Required 프록시 서버의 인증이 필요함. [15]
408 Request timeout 요청 시간이 지남.
409 Conflict 요청을 처리하는 데 문제가 있음. 보통 PUT 요청과 관계가 있다. 보통 다른 버전의 파일을 업로드할 경우 발생함. (HTTP 1.1에서 새로 등장)
410 Gone 영구적으로 사용할 수 없음.
411 Length Required 클라이언트가 헤더에 Content-Length를 포함하지 않으면 서버가 처리할 수 없음.(HTTP 1.1에서 새로 등장)
412 Precondition Failed 선결조건 실패. 헤더에 하나 이상의 선결조건을 서버에서 충족시킬 수 없음. [16]
413 Request entity too large 요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. [17] (HTTP 1.1에서 새로 등장)
414 Request-URI too long 요청한 URI가 너무 김. [18]
415 Unsupported media type 요청이 알려지지 않은 형태임. (HTTP 1.1에서 새로 등장)
5XX Server Error(서버 오류) 서버 측의 오류로 올바른 요청을 처리할 수 없음.
500 Internal Server Error 서버 내부 오류. [19]
501 Not Implemented 필요한 기능이 서버에 설치되지 않았음. [20]
502 Bad gateway 게이트웨이 상태 나쁨. [21]
503 Service Unavailable 외부 서비스가 죽었거나 현재 멈춘 상태 또는 이용할 수 없는 서비스. [22]
504 Gateway timeout 프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있음. 초기 서버가 원격 서버로부터 응답을 받을 수 없음. (HTTP 1.1에서 새로 등장)
505 HTTP Version Not Supported 해당 HTTP 버전을 지원하지 않음.

[편집]같이 보기

[편집]참고 문헌

[편집]주석

  1.  이 메시지는 HTTP 1.0에서는‘Moved Temporarily’였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 C_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동적으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메서드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader("Location", url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 <http://host/~user> (마지막에 '/'가 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보라.
  2.  서버는 클라이언트에게 캐시에 저장된 이전 문서를 계속 사용해야 한다고 말할 것이다.
  3.  클라이언트는 수정없이 요청 사항을 반복하지 않기 바람.
  4.  이 경우, 여러분이 요청한 자원에 접근할 수 있는 권한을 부여받기 위해 서버 운영자에게 요청해야 할 것이다.
  5.  이것은 일반적을 으로 적절한 www-authenticate head field를 전송하지 않아서 발생한다.
  6.  이 자원은 페이지가 될 수도 있고, 클라이언트의 주소 입력란에 명기된 파일일 수도 있다. 아니면 클라이언트가 행당 주소로 들어갈 때 이용되는 또 다른 파일일 수도 있다. 여러분이 접근할 전체 주소를 다시 확인해 보고 웹 서버 운영자에게 여러분이 자원에 접근할 권한이 있는지를 확인해 본다.
  7.  서버에 접속하는 데 이용되는 인증 과정이 이런 필터 프로그램에 의해 거부되었다.
  8.  서버에 접속하는 데 이용되는 인증 과정이 이 프로그램에 의해 거부되었다.
  9.  아니면 Eecute나 Script로 분한이 부여된 디렉터리에 들어있는 HTML페이지를 보려했을 때 발생한다.
  10.  이것을 보기 위해서 여러분은 주소를 입력하기 전에 먼저 SSL을 이용할 수 있어야 한다.
  11.  이 자원을 보기 위해서는 여러분의 브라우저가 SSL의 행당 레벌을 지원해야 한다. 여러분의 브라우저가 128비트의 SSL을 지원하는지를 확인해 본다.
  12.  여러분이 접근하려는 자료가 서버가 인식하기 위해 여러분의 브라우저에게 클라이언트 SSL을 요청하는 경우 발생한다. 이것은 여러분이 자원을 이용할 수 있는 상용자임을 입증하는 데 사용된다.
  13.  여러분이 요청한 자원에 적절한 MIME 타입을 갖고 있는지 확인해 본다.
  14.  요청 사항에 필요한 자원은 요청 사항으로 전달된 Acceptheader에 따라 "Not Acceptable"인 내용을 가진 Response 개체만을 만들 수 있다.
  15.  해당 요청이 수행되도록 프록시 서버에게 인증을 받아야 한다. 프록시 서버로 로그온 한 후에 다기 시도해 본다.
  16.  현재 자원의 메타-정보가 하나 이상의 자원에 적용되는 것을 막기 위한 클라이언트 선결조건이 의도되었다.
  17.  만약 서버에서 나중에 다룰 수 있다고 생각되면 Retry-After 헤더를 포함시켜야 한다.
  18.  요청한 URI가 너무 길어서 서버가 요청 사항의 이행을 거부했다. 이렇게 희귀한 상황은 아래와 같은 경우에만 발생한다. 클라이언트가 긴 탐색용 정보를 가지고 POST 요청을 GET으로 부적절하게 전환했다. 클라이언트가 Redirection 문제를 접하게 되었다. 서버가, 몇몇 서버가 사용하고 있는 요청한 URI 를 읽고 처리하는 고정된 길이의 메모리 버퍼를 이용해 보안체계에 들어가려는, 클라이언트에 의한 공격을 받고 있다.
  19.  서버가 요청사항을 수행할 수 없다. 다시 한 번 요청해 본다.
  20.  서버가 요청사항을 수행하는 데 필요한 기능을 지원하지 않는다. 오류가 발생한 URL을 확인한 후에, 문제가 지속될 경우에는 웹 서버 운영자에게 연락한다.
  21.  서버의 과부하 상태Gateway나 proxy로 활동하고 있는 서버가 요구 사항을 접수한 upstream 서버로부터 불명확한 답변을 접수 했을 때 발생한다. 만약 문제가 지속된다면 웹 서버 운영자와 상의해 본다.
  22.  서버는 현재 일시적인 과부하 또는 관리(유지,보수) 때문에 요청을 처리할 수 없다. 이것은 약간의 지연 후 덜게 될 일시적인 상태를 말한다. Retry-After 헤더에 지연의 길이가 표시될 수도 있다. 만약 Retry-After를 받지 못했다면 클라이언트는 500 응답을 위해 하고자 했는 것처럼 응답을 처리해야 한다. 상태코드의 존재는 서버가 과부하가 걸릴때 그것을 사용해야한다는 것을 말하는 것이 아니다. 몇몇 서버는 접속을 거부하는 것을 바랄지도 모른다.

'Web > Common' 카테고리의 다른 글

웹 서비스(Web Service)  (0) 2012.01.16
Sun ONE  (0) 2012.01.13
HTTP1.0과 1.1 차이점  (0) 2011.12.29
[2012년, HTML5 혁명 온다] <상> 모바일 생태계 지각변동  (0) 2011.12.26
was vs webserver  (0) 2011.12.13
Posted by linuxism
,

JSP Container(Tomcat)는 invoke 메소드 내에서 서블릿 클래스의 로드, service 메소드 호출, session 관리,
error 메세지의 로딩 등 다양한 일을 한다.

 

public abstract void invoke(Request request, Response response)

org.apache.catalina.connector.Request
org.apache.catalina.connector.Response

 

API link :
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/Container.html#invoke(org.apache.catalina.connector.Request,%20org.apache.catalina.connector.Response)

 

________________________________________________________________

 

invoke
void invoke(Request request,
            Response response)
            throws java.io.IOException,
                   javax.servlet.ServletExceptionProcess the specified Request, and generate the corresponding Response, according to the design of this particular Container.

Parameters:
request - Request to be processed
response - Response to be produced
Throws:
java.io.IOException - if an input/output error occurred while processing
javax.servlet.ServletException - if a ServletException was thrown while processing this request


________________________________________________________________

 

<servlet>
    <servlet-name>invoker</servlet-name>
    <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class>
   
    <init-param>
    <param-name>debug</param-name>
    <param-value>0</param-value>
    </init-param>
   
    <load-on-startup>2</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>invoker</servlet-name>
    <url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

 

==============================================================================================


출처 - http://blog.naver.com/PostView.nhn?blogId=estern&logNo=110012023046&widgetTypeCall=true


서블릿 Invoker

  Servlet Invoker는 서블릿을 web.xml에 설정하지 않아도 서블릿 클래스를 classes아래에서 찾아서 호출하여 줍니다. 3.x대에서는 이러한 방식으로 개발을 많이 하였습니다.

예를들어 다음과 같은 요청은 example.HelloServlet라는 서블릿 클래스를 CLASSPATH에서 찾아서 호출하여 줍니다. 하지만 보안상의 이유 등으로 권장사항이 아닙니다.

 

   http://localhost/servlet/example.HelloServlet 

 

Tomcat 4.1.x
 
  4.1.12 이후로 부터는 디폴트로 Servlet Invoker가 설정되어 있지않습니다. 따라서 4.1.12 이후 버젼에서 invoker를 사용하고자 할 경우는 /conf/web.xml 파일에서 주석 처리된 servlet-mapping의 주석을 제거하거나 주석내의 내용을 Context의 WEB-INF 폴더 아래의 web.xml에 추가해야합니다.
 

 

    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>
 
 
<!--
    이 부분이 4.1.12 부터는 이와 같이 주석처리 되어 있습니다.
    물론 이전 버젼에서는 주석 처리가 되어 있지않습니다.
    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>
-->
 
 
 
Tomcat 5.0
 
  5.0에서는 서블릿 매핑 뿐만 아니라 invoker 서블릿 설정도 주석 처리되어 있습니다.  invoker를 사용하고자 할 경우는 /conf/web.xml 파일에서 주석 처리된 servlet 정의 부분 및 servlet-mapping의 주석을 제거하거나 주석내의 내용을 Context의 WEB-INF 폴더 아래의 web.xml에 추가해야합니다.
권장 사항은 conf/web.xml의 내용을 변경하기 보다는 Context의 WEB-INF 폴더 아래의 web.xml에 추가하는 것입니다.conf/web.xml의 설정을 변경하면 서버에 설정된 모든 Context에 적용되기 때문입니다.
 

 

<!--
    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>
-->
 
<!-- The mapping for the invoker servlet -->
<!--
    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>
-->
 
 
 
Tomcat 5.5
  5.5는 5.0과 동일합니다.
  

 

<!--
    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>
-->
 
<!-- The mapping for the invoker servlet -->
<!--
    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>
-->
       
Posted by linuxism
,
김우용 기자 yong2@zdnet.co.kr 2011.12.01 / PM 04:32 서버x86유닉스IBMHP

세계 서버시장이 HP와 IBM의 양강구도가 더욱 강해지고 있다. HP이 출하량 기준으로, IBM이 매출 기준으로 각각 1위를 달리면서, 후발주자를 멀찌감치 따돌리는 모습. 한국 서버 시장 전체는 전년보다 14% 커졌다. 

 

시장조사업체 가트너는 2011년 3분기 서버시장 보고서를 통해 HP가 전체 시장에서 약 25% 점유율을 기록하면서 출하량 기준 1위 자리를 지켰고, IBM은 매출 기준으로 약 42% 점유율을 기록했다고 30일 밝혔다. 

 

레노버는 중국의 모든 주요 버티컬 마켓에서 공격적으로 대응하면서, 전년동기 대비 매출이 2배 이상 증가했다. 델은 인터넷 기업들의 DCS 구매에 힘입어 3분기에 전년대비 성장률 2위를 기록했다. 

 

▲ 2011년 3분기 서버출하량 기준 업체별 순위(자료:가트너)

▲ 2011년 3분기 서버매출 기준 업체별 순위(자료:가트너)

세계 서버시장 중 아시아 태평양 지역 서버시장은 전년동기 대비 출하량 23.9%, 매출은 18.5% 상승하면서 2011년 3분기에도 계속해서 두 자리 수 성장을 이어나갔다. 아태지역 국가들의 서버 출하량은 호주 20%, 한국 14%, 싱가포르 18% 씩 증가해 전년대비 두 자리 수 성장을 기록했다. 벤더 매출은 지난해 3분기 대비 호주와 싱가포르가 각각 6%, 한국은 2%의 성장세를 보여 소폭 상승세를 이어갔다. 

 

아태지역에서 x86 서버 플랫폼의 3분기 매출은 29%, 출하량은 25% 가 늘면서 해당 플랫폼의 전년대비 최대 성장을 기록했다. 아태지역에서 진행되는 x86서버 가상화 실행과 더불어 인터넷 기업의 수요가 특히 중국을 중심으로 계속 증가세를 보이면서 아태지역의 주요 서버 성장 동력의 역할을 했다. 금융 및 통신 부분을 중심으로 핵심 인프라 구축이 진행되면서, RISC/아이태니엄 유닉스 서버 매출은 전년동기 대비 11% 늘었다.

 

블레이드는 전년 동기 대비 출하대수 기준으로는 8% 성장에 그쳤으나, 매출은 14.5% 늘었다. 같은 기간 랙(rack) 최적화 서버는 출하량 32%, 매출 22% 증가를 기록하면서 가장 큰 폭으로 성장했다. 

 

에리카 가줄리 가트너 수석애널리스트는 “아태지역은 계속해서 2011년3분기에도 서버 출하량에서 가장 높은 성장을 기록했다”면서 “대중화권(중국, 홍콩, 대만 전체)의 점유율은 전년도 동기 대비 2% 포인트가 늘어나 아태지역 전체 시장의 69.7%를 차지했다”고 밝혔다.  
Posted by linuxism
,