검수요청.png검수요청.png

"HTTP"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(클라이언트: 사용자 에이전트)
잔글
 
(사용자 2명의 중간 판 6개는 보이지 않습니다)
1번째 줄: 1번째 줄:
'''HTTP'''(에이치티티피)는 Hypertext Transfer Protocol의 약자로서, 월드 와이드 웹(WWW: World Wide Web)을 이용하여 [[HTML]]로 작성된 [[하이퍼 텍스트]](Hyper Text) 문서를 주고받을 수 있는 [[프로토콜]]이다. HTTP 통신규약을 이용하여 [[웹서버]]와 [[웹브라우저]] 사이에서 정보를 주고받을 수 있다. [[포트]] 번호는 80번이다. '''에이치티티피'''라고 읽는다. 보통 "http://"와 같이 소문자로 쓴다.
+
'''HTTP'''(에이치티티피)는 "Hypertext Transfer Protocol"의 약자로서, [[]](web)을 이용하여 [[HTML]]로 작성된 [[하이퍼텍스트]](hypertext) 문서를 주고받을 수 있는 [[프로토콜]]이다. HTTP 통신규약을 이용하여 [[웹서버]]와 [[웹브라우저]] 사이에서 정보를 주고받을 수 있다. [[포트]] 번호는 80번이다. '''에이치티티피'''라고 읽는다. 보통 "http://"와 같이 소문자로 쓴다.
  
 
==개요==
 
==개요==
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.
+
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 보통 브라우저인 수신자에 의해 요청이 초기화되는 것을 의미하는, 웹과 클라이언트·서버 모델 상에서 모든 데이터 교환이 기초다. 하나의 완전한 문서는 페치(Fetch)된 또 다른 하위 문서, 텍스트, 레이아웃 설명, 이미지, 비디오. 스크립트 등으로 구성된다. 데이터스트림과 대조적으로 클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신한다. 보통 클라이언트에 의해 전송되는 메시지를 요청(request)이라고 부르며, 그에 대한 서버의 응답으로 전송되는 메시지를 응답(response)이라고 부른다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든 사용할 수 있으나 [[TCP]] 혹은 암호화된 TCP 연결인 [[TLS]]를 통해 전송한다. HTTP의 확장성 덕분에 오늘날 하이퍼 텍스트 문서뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트하기 위해 사용된다. 또한, 필요할 때마다 웹페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.<ref NAME="IT 용어 정리">Minkuk Jo, 〈[https://blog.naver.com/mingooddev/221532243113 IT 용어 정리 - HTTP 란?]〉, 《네이버 블로그》, 2019-05-08</ref>
HTTP는 보통 브라우저인 수신자에 의해 요청이 초기화되는 것을 의미하는, 웹과 클라이언트·서버 모델 상에서 모든 데이터 교환이 기초다.
 
하나의 완전한 문서는 페치(Fetch)된 또 다른 하위 문서, 텍스트, 레이아웃 설명, 이미지, 비디오. 스크립트 등으로 구성된다.
 
클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신한다.(데이터스트림과 대조적)
 
보통 클라이언트에 의해 전송되는 메시지를 요청(request)이라고 부르며, 그에 대한 서버의 응답으로 전송되는 메시지를 응답(response)이라고 부른다.
 
HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송한다. HTTP의 확장성 덕분에 오늘날 하이퍼 텍스트 문서뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트하기 위해 사용된다. 또한, 필요할 때마다 웹페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.
 
  
==구성요소==
+
HTTP의 주요 특성은 비연결성(Connectionless)이다. 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징이다. HTTP는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 접속을 끊는 특성이 있다. 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 [[디폴트]]다. HTTP가 TCP 위에서 구현되었기 때문에(TCP는 연결지향, UDP는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 비연결성의 연결비용을 줄이는 것을 장점으로 비연결지향이라 한다. HTTP의 또다른 특징은 무상태(Stateless), 통신이 끝나면 상태를 유지하지 않는다. 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 두 가지 특징이자 약점을 보완하기 위해서 [[쿠키]](cookie)와 [[세션]](session)을 사용한다. 예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때마다 계속 로그인을 해야 한다. 쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지하게 된다. <ref>라이언곰돌이푸, 〈[https://interconnection.tistory.com/74 쿠키와 세션 개념]〉, 《티스토리》, 2019-09-01</ref>
HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시(Proxy))에 의해 전송된다. 각각의 개별적인 요청은 서버로 전송되며, 서버는 요청을 처리하고 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하고, 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다. 실제 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들(라우터, 모뎀 등)이 존재한다. 웹의 계층적인 설계 덕분에 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP는 애플리케이션 계층의 최상위에 있다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없다.
 
 
 
===클라이언트 (사용자 에이전트)===
 
사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구를 뜻한다. 웹페이지를 표시하기 위해 브라우저는 페이지의 HTTL 문서를 가져오기 위한 요청을 전송한 뒤, 파일의 구문을 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(이미지, 비디오 등)을 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다.
 
그런 뒤 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 그 리소스들을 혼합한다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹페이지를 갱신하게 된다.
 
 
 
===웹 서버===
 
통신 채널의 반대편에는 클라이언트 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 사실상 논리적으로 단일 기계이다. 이는 로드밸런싱 혹은 그때그때 다른 컴퓨터(캐시, DB 서버, E-커머스 등)와 같은 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합일 수도 있기 때문이다. 서버는 반드시 단일 기계일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있다. HTTP/1.1과 host 헤더를 이용해 동일한 IP 주소를 공유할 수도 있다.
 
 
 
===프록시===
 
웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 중계한다. 웹 스택의 계층 구조 덕분에 이들 대부분은 전송, 네트워크 혹은 물리적 수준에서 동작하며, 이것들이 성능상 상당한 영향을 갖고 있음에도 불구하고 HTTP 계층에서는 눈에 보이지 않는다. 애플리케이션 계층에서 이렇게 중계하는 것을 프록시라고 부른다. 프록시가 눈에 보이거나 그렇지 않을 수 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능을 수행할 수 있다.
 
*캐싱 : 캐시는 공개 또는 비공개될 수 있다.<예: 브라우저 캐시>
 
*필터링 : 바이러스 백신 스캔, 유해 컨텐츠 차단<자녀 보호 기능>
 
*로드밸런싱 :여러 서버들이 서로 다른 요청을 처리하도록 허용
 
*인증 : 다양한 리소스에 대한 접근 요청
 
*로깅 : 이력 정보를 저장<ref>Minkuk Jo, 〈[https://blog.naver.com/mingooddev/221532243113 IT 용어 정리 - HTTP 란?]〉, 《네이버 블로그》, 2019-05-08</ref>
 
  
 
==역사==
 
==역사==
*1965년 : 제너두 프로젝트에서 [[테드 넬슨]]에 의해 하이퍼텍스트라는 용어가 만들어졌으며, 제너두 프로젝트는 'As We May Think(1945년)'라는 수필에서 마이크로필름 기반 정보 수신 및 관리 "메멕스" 시스템을 기술한 버니바 부시의 비전(1930년대)에 의해 영감을 받았다.  
+
*1965년 : 제너두 프로젝트(Project Xanadu)에서 [[테드 넬슨]](Theodor Nelson)에 의해 하이퍼텍스트라는 용어가 만들어졌으며, 제너두 프로젝트는 '우리가 생각한 대로(As We May Think)'라는 수필에서 마이크로필름 기반 정보 수신 및 관리 메멕스(Memex) 시스템을 기술한 버니바 부시(Vannevar Bush)의 비전(1930년대)에 의해 영감을 받았다.  
*1989년 : [[팀 버너스 리]]와 그의 팀은 CERN에서 [[HTML]]뿐 아니라 [[웹 브라우저]] 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 "월드와이드웹" 프로젝트를 제안하였으며, 이것이 현재의 월드 와이드 웹이다. 이 [[프로토콜]]의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다. 서버로부터의 응답은 무조건 HTML 문서였다.
+
*1989년 : [[팀 버너스 리]](Timothy Berners Lee)와 그의 팀은 유럽원자핵공동연구소 세른(CERN)에서 HTML뿐 아니라 웹브라우저 및 텍스트 기반 웹브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 월드와이드웹(world wide web) 프로젝트를 제안하였으며, 이것이 현재의 월드와이드웹이다. 이 [[프로토콜]]의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다. 서버로부터의 응답은 무조건 HTML 문서였다.
*1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0.9(1991년)이다.  
+
*1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0.9이다.  
*1995년 : [[데이브 레겟]]은  HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다.  
+
*1995년 : [[데이브 레겟]](Dave Raggett)은  HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다.  
 
*1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다.
 
*1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다.
 
*1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다.
 
*1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다.
*1996년 3월 : 이전 표준 HTTP/1.1을 지원한 웹 브라우저로 아레나, 넷스케이프 2.0, 넷스케이프 내비게이터 골드 2.01, 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0이 있다. 새로운 브라우저의 최종 사용자 채택 속도를 빨랐다.  
+
*1996년 03월 : 이전 표준 HTTP/1.1을 지원한 웹브라우저로 아레나, 넷스케이프 2.0, 넷스케이프 내비게이터 골드 2.01, 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0이 있다. 새로운 브라우저의 최종 사용자 채택 속도를 빨랐다.  
*1996년 3월 : 한 웹 호스팅 회사의 보고에 따르면 인터넷 상에서 사용 중인 브라우저 중 40% 이상이 HTTP 1.1과 호환되었다. 같은 웹 호스팅 회사는 1996년 6월 기준으로 서버에 접근하는 모든 브라우저들 가운데 65%가 HTTP/1.1 호환이라고 보고하였다.  
+
*1996년 03월 : 한 웹호스팅 회사의 보고에 따르면 인터넷 상에서 사용 중인 브라우저 중 40% 이상이 HTTP 1.1과 호환되었다. 같은 웹 호스팅 회사는 1996년 6월 기준으로 서버에 접근하는 모든 브라우저들 가운데 65%가 HTTP/1.1 호환이라고 보고하였다.  
*1997년 1월 : RFC 2068에 정의된 HTTP/1.1 표준이 공식적으로 출시되었다.  
+
*1997년 01월 : RFC 2068에 정의된 HTTP/1.1 표준이 공식적으로 출시되었다.  
*1999년 6월 : HTTP/1.1 표준에 대한 개선과 업데이트가 RFC 2616으로 출시되었다.
+
*1999년 06월 : HTTP/1.1 표준에 대한 개선과 업데이트가 RFC 2616으로 출시되었다.
 
*2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다.  
 
*2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다.  
*2014년 6월 : WG는 RFC 2616를 obsolete 처리하는, 업데이트된 6 파트 사양을 출시하였다.
+
*2014년 06월 : WG는 RFC 2616를 옵솔리트(obsolete) 처리하는, 업데이트된 6 파트 사양을 출시하였다.
*2015년 5월 : HTTP/2가 RFC 7540로 출판되었다.<ref name="위키백과">HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP</ref>
+
*2015년 05월 : HTTP/2가 RFC 7540로 출판되었다.<ref name="위키백과">HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP</ref>
  
 
==특징==
 
==특징==
===비연결성 (Connectionless)===
+
===구성요소===
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징이다. HTTP는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 접속을 끊는 특성이 있다. 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다. HTTP가 TCP 위에서 구현되었기 때문에(TCP는 연결지향, UDP는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 비연결성의 연결비용을 줄이는 것을 장점으로 비연결지향이라 한다.
+
HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트 또는 그것을 대신하는 [[프록시]](Proxy)에 의해 전송된다. 각각의 개별적인 요청은 서버로 전송되며, 서버는 요청을 처리하고 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하고, [[게이트웨이]] 또는 [[캐시]] 역할을 하는 프록시 등이 있다. 실제 브라우저와 요청을 처리하는 서버 사이에는 좀 많은 컴퓨터들(라우터, 모뎀 등)이 존재한다. 웹의 계층적인 설계 덕분에 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP는 [[애플리케이션]] 계층의 최상위에 있다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없다.
 
===무상태 (Stateless)===
 
통신이 끝나면 상태를 유지하지 않는 특징이다. 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.
 
 
 
쿠키와 세션은 위의 두 가지 특징을 해결하기 위해 사용한다. 예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때마다 계속 로그인을 해야 한다. 쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지하게 된다.
 
 
 
===쿠키 (Cookie)===
 
쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일이다. 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다. 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다. 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 소지가능, 하나의 쿠키값은 4KB까지 저장한다. Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다. 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 요청시에 Request Header를 넣어서 자동으로 서버에 전송한다.
 
 
 
*구성 요소
 
#이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
 
#값 : 쿠키의 이름과 관련된 값
 
#유효시간 : 쿠키의 유지시간
 
#도메인 : 쿠키를 전송할 도메인
 
#경로 : 쿠키를 전송할 요청 경로
 
 
 
*쿠키의 동작 방식
 
#클라이언트가 페이지를 요청
 
#서버에서 쿠키를 생성
 
#HTTP 헤더에 쿠키를 포함 시켜 응답
 
#브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
 
#같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
 
#서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답
 
 
 
*쿠키의 사용 예
 
#방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
 
#쇼핑몰의 장바구니 기능
 
#자동로그인, 팝업에서 "오늘 이상 이 창을 보지 않음" 체크, 쇼핑몰의 장바구니
 
 
 
===세션 (Session)===
 
세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다. 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다. 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능하다. 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다. 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다. 클라이언트가 요청을 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는데 이것이 세션ID다.
 
 
 
*동작방식
 
#클라이언트가 서버에 접속 시 세션 ID를 발급받는다.
 
#클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있다.
 
#클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 서버에 전달해서 사용한다.
 
#서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져온다.
 
#클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답한다.
 
  
*특징
+
* '''클라이언트''' : 사용자를 대신하여 동작하는 모든 도구를 뜻한다. 웹페이지를 표시하기 위해 브라우저는 페이지의 HTTL 문서를 가져오기 위한 요청을 전송한 뒤, 파일의 구문을 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(이미지, 비디오 등)을 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다. 그런 뒤 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 그 리소스들을 혼합한다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹페이지를 갱신하게 된다.
#각 클라이언트에게 고유 ID를 부여
 
#세션 ID로 클라이언트를 구분해서 클라이언트의 요구에 맞는 서비스를 제공
 
#보안 면에서 쿠키보다 우수
 
#사용자가 많아질수록 서버 메모리를 많이 차지하게 됨
 
  
*세션의 사용 예
+
* '''웹서버''' : 통신 채널의 반대편에는 클라이언트 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 사실상 논리적으로 단일 기계이다. 이는 로드밸런싱 혹은 그때그때 다른 컴퓨터(캐시, DB 서버, 전자상거래 등)와 같은 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 [[소프트웨어]]의 복잡한 부분을 공유하는 서버들의 집합일 수도 있기 때문이다. 서버는 반드시 단일 기계일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있다. HTTP/1.1과 호스트 헤더를 이용해 동일한 IP 주소를 공유할 수도 있다.
로그인 같이 보안상 중요한 작업을 수행할 때 사용<ref>라이언곰돌이푸, 〈[https://interconnection.tistory.com/74 쿠키와 세션 개념], 《티스토리》, 2019-09-01</ref>
 
  
==메시지 포맷==
+
* '''프록시''' : 웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 중계한다. 웹 스택의 계층 구조 덕분에 이들 대부분은 전송, 네트워크 혹은 물리적 수준에서 동작하며, 이것들이 성능상 상당한 영향을 갖고 있음에도 불구하고 HTTP 계층에서는 눈에 보이지 않는다. 애플리케이션 계층에서 이렇게 중계하는 것을 프록시라고 부른다. 프록시가 눈에 보이거나 그렇지 않을 수 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능을 수행할 수 있다.
 +
# 캐시 : 공개 또는 비공개될 수 있다.(예: 브라우저 캐시)
 +
# 필터링 : 바이러스 백신 스캔, 유해 컨텐츠 차단(예 : 자녀 보호 기능)
 +
# 로드밸런싱 :여러 서버들이 서로 다른 요청을 처리하도록 허용
 +
# 인증 : 다양한 리소스에 대한 접근 요청
 +
# 로깅 : 이력 정보 저장<ref NAME="IT 용어 정리"></ref>
  
HTTP는 요청과 응답으로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP는 FTP나 텔넷과는 다르게 비연결식이다. FTP나 텔넷은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.<ref>HTTP 나무위키 - https://namu.wiki/w/HTTP</ref>
+
===메시지 포맷===
 +
HTTP는 요청과 응답으로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP는 [[FTP]]나 [[텔넷]]과는 다르게 비연결식이다. FTP나 텔넷은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.<ref>HTTP 나무위키 - https://namu.wiki/w/HTTP</ref>
  
===요청 메시지===
+
* '''요청 메시지''' : 요청 내용(GET /images/logo.gif HTTP/1.1)과 헤더(Accept-Language: en), 빈 줄 (empty line), 기타 메시지를 포함하여 표시된다. 요청 내용과 헤더 필드는 CR, LF로 끝나야 한다. 즉, 캐리지 리턴(carriage return) 다음에 라인 피드(line feed)가 와야 한다. 빈 줄은 CR, LF로 구성되며 그 외 다른 화이트스페이스(whitespace)가 있어서는 안된다. 이를 정리 및 요약하면 다음과 같다.
*요청 내용
 
보기) GET /images/logo.gif HTTP/1.1
 
*헤더
 
보기) Accept-Language: en
 
*빈 줄 (empty line)
 
*기타 메시지를 포함하여 표시된다.
 
요청 내용과 헤더 필드는 <CR><LF>로 끝나야 한다. 즉, 캐리지 리턴(Carriage Return) 다음에 라인 피드(Line Feed)가 와야 한다. 빈 줄(empty line)은 <CR><LF>로 구성되며 그 외 다른 화이트스페이스(whitespace)가 있어서는 안된다.
 
  
:{|class=wikitable width=900 style="background-color:#f8fa9fa"
+
::{|class=wikitable width=900 style="background-color:#f8fa9fa"
|+<big>'''요약표'''</big>
 
 
!align=center style="background-color:#eaecf0"|HTTP 메소드
 
!align=center style="background-color:#eaecf0"|HTTP 메소드
 
!align=center style="background-color:#eaecf0"|RFC
 
!align=center style="background-color:#eaecf0"|RFC
189번째 줄: 123번째 줄:
 
|}
 
|}
  
===응답 메시지===
+
* '''응답 메시지''' : 상태코드(status code)와 요청 메시지(reason message)를 포함하는 상태표시 행(예 : HTTP/1.1 200 OK. 클라이언트의 요청이 성공적으로 전달되었음을 표시)응답 헤더필드(예 : Content-Type: text/html), 빈 줄, 기타 메시지로 구성된다.<ref name="위키백과"></ref>
*상태표시 행(status line): 상태코드(status code)와 reason message를 포함한다. (예. HTTP/1.1 200 OK. 클라이언트의 요청이 성공적으로 전달되었음을 표시)
 
*응답 헤더필드 (예.Content-Type: text/html)
 
*빈 줄 (empty line)
 
*기타 메시지<ref name="위키백과"></ref>
 
  
==응답 코드==
+
===응답 코드===
 
클라이언트가 서버에 접속하여 어떠한 요청을 하면, 서버는 세 자리 수로 된 응답 코드와 함께 응답한다. HTTP의 응답 코드는 다음과 같다.  
 
클라이언트가 서버에 접속하여 어떠한 요청을 하면, 서버는 세 자리 수로 된 응답 코드와 함께 응답한다. HTTP의 응답 코드는 다음과 같다.  
  
===1xx (조건부 응답)===
+
====1xx====
요청을 받았으며 작업을 계속한다.
+
조건부 응답으로, 요청을 받았으며 작업을 계속한다. 이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.
이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.
+
*100 Continue (계속) : 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
*100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
+
*101 Switching Protocols (프로토콜 전환) : 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
*101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
+
*102 Processing (처리, RFC 2518)
*102(처리, RFC 2518)
+
*103 Early Hints (사전로딩) : 링크헤더와 함께 사용되며 주로 서버가 응답을 준비하는 동안 사용자가 사전로딩(PreLoading)을 할수 있도록 하는 응답코드이다.
  
===2xx (성공)===
+
===2xx===
 
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.  
 
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.  
*200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
 
*201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
 
*202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
 
*203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
 
*204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
 
*205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
 
*206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
 
*207(다중 상태, RFC 4918)
 
*208(이미 보고됨, RFC 5842)
 
*226 IM Used (RFC 3229)
 
  
===3xx (리다이렉션 완료)===
+
* 200 OK (성공) : 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
 +
* 201 Created (작성됨) : 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
 +
* 202 Accepted (허용됨) : 서버가 요청을 접수했지만 아직 처리하지 않았다.
 +
* 203 Non-Authoritative Information (신뢰할 수 없는 정보) : 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
 +
* 204 No Content (콘텐츠 없음) : 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
 +
* 205 Reset Content (콘텐츠 재설정) : 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 요청자가 문서 보기를 재설정할 것을 요구한다.
 +
* 206 Partial Content (일부 콘텐츠) : 서버가 GET 요청의 일부만 성공적으로 처리했다.
 +
* 207 Multi-Status (다중 상태, RFC 4918)
 +
* 208 Already Reported (이미 보고됨, RFC 5842)
 +
* 226 IM Used (의무 완료, RFC 3229)
 +
 
 +
===3xx===
 
클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.  
 
클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.  
*300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
+
 
*301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
+
*300 Multiple Choices (여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
*302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
+
*301 Moved Permanently (영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
*303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
+
*302 Found (임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
*304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
+
*303 See Other (기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
*305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
+
*304 Not Modified (수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
*307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
+
*305 Use Proxy (프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
*308(영구 리다이렉션, RFC에서 실험적으로 승인됨)
+
*306 Unused (사용 중지) : 초기 HTTP/1.1까지만 해도 스위치 프록시 요청으로 다음 요청시 지정한 프록시 서버를 사용하라는 응답 코드로 초안이 각성되었으나, 정작 사용이 되지 않았고 지금은 305 Use Proxy 응답이 사용 중지되어 문서에서 삭제, 예약코드로 있다.
 +
*307 Temporary Redirect (임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
 +
*308 Permanent Redirect (영구 리다이렉션, RFC에서 실험적으로 승인됨)
  
 
===4xx (요청 오류)===
 
===4xx (요청 오류)===
4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.  
+
4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.
*400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
+
 
*401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
+
*400 Bad Request (잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
*402(결제 필요): 이 요청은 결제가 필요합니다.
+
*401 Unauthorized (권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
*403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
+
*402 Payment Required (결제 필요): 이 요청은 결제가 필요합니다.
*404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
+
*403 Forbidden (거부됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
*405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
+
*404 Not Found (찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
*406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
+
*405 Method Not Allowed (허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
*407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
+
*406 Not Acceptable (받아들일 수 없음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
*408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
+
*407 Proxy Authentication Required (프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
*409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
+
*408 Request Timeout (요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
*410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
+
*409 Conflict (충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
*411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
+
*410 Gone(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
*412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
+
*411 Length Required (길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
*413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
+
*412 Precondition Failed (사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
*414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
+
*413 Payload Too Large (요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
*415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
+
*414 URI Too Long (요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
*416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
+
*415 Unsupported Media Type (지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
*417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
+
*416 Requested Range Not Satisfiable (처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
*418(I'm a teapot, RFC 2324 ,https://google.com/teapot)
+
*417 Expectation Failed (예측 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
*420(Enhance Your Calm, 트위터)
+
*418 I'm a teapot (나는 찻주전자이다, RFC 2324 ,https://google.com/teapot) : 찻주전자로는 커피를 만들 수 없다. 이는 하이퍼텍스트 커피 포트 제어 프로토콜(HTCPCP)(RFC 2324)에서 사용되는 코드이다.
*422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
+
*420 (Enhance Your Calm, 트위터)
*423(잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
+
*421 Misdirected Request(잘못된 요청): 서버로 유동된 요청된 응답을 서버에서 생성할 수 없을때 응답하는 코드로 주로 TLS 인증서가 여러개 설치된 상태에서 꼬였을 경우 뜨는 오류다.
*424(실패된 의존성, WebDAV; RFC 4918)
+
*422 Unprocessable Entity (처리할 수 없는 개체, WebDAV; RFC 4918)
*424(메쏘드 실패, WebDAV)
+
*423 Locked (잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
*425(정렬되지 않은 컬렉션, 인터넷 초안)
+
*424 Failed Dependenc (실패된 의존성, WebDAV; RFC 4918)
*426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
+
*424 (method 실패, WebDAV)
*428(전제조건 필요, RFC 6585)
+
*425 Too Early (정렬되지 않은 컬렉션, 인터넷 초안) : 서버가 재생될 수 있는 요청을 처리하는 데 위험을 감수하지 않는다는걸 알릴때 사용되는 코드이다.[RFC8470] 클라이언트가 파이어폭스 58 이후 버전이 아닌이상 재대로 해석하지는 않는다.
*429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
+
*426 Upgrade Required (업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
*431(요청 헤더 필드가 너무 큼, RFC 6585)
+
*428 Precondition Required (전제조건 필요, RFC 6585)
*444(응답 없음, Nginx)
+
*429 Too Many Requests (너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
*449(다시 시도, 마이크로소프트)
+
*431 Request Header Fields Too Large (요청 헤더 필드가 너무 큼, RFC 6585)
*450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
+
*444 (응답 없음, Nginx)
*451(법적인 이유로 이용 불가, 인터넷 초안)
+
*449 (다시 시도, 마이크로소프트)
*451(리다이렉션, 마이크로소프트)
+
*450 (윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
*494(요청 헤더가 너무 큼, Nginx)
+
*451 Unavailable For Legal Reasons (법적인 이유로 이용 불가, 인터넷 초안)
*495(Cert 오류, Nginx)
+
*451 (리다이렉션, 마이크로소프트)
*496(Cert 없음, Nginx)
+
*494 (요청 헤더가 너무 큼, Nginx)
*497(HTTP to HTTPS, Nginx)
+
*495 (Cert 오류, Nginx)
*499(클라이언트가 요청을 닫음, Nginx)
+
*496 (Cert 없음, Nginx)
 +
*497 (HTTP to HTTPS, Nginx)
 +
*499 (클라이언트가 요청을 닫음, Nginx)
  
 
===5xx (서버 오류)===
 
===5xx (서버 오류)===
 
서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
 
서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
*500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
+
 
*501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
+
*500 Internal Server Error (내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
*502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
+
*501 Not Implemented (구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
*503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
+
*502 Bad Gateway(불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
*504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
+
*503 Service Temporarily Unavailable (일시적으로 서비스를 사용할 수 없음) : 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
*505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
+
*504 Gateway Timeout (게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
*506(Variant Also Negotiates, RFC 2295)
+
*505 HTTP Version Not Supported (HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
*507(용량 부족, WebDAV; RFC 4918)
+
*506 Variant Also Negotiates (서버 내부 구성에 오류가 있음, RFC 2295) : 서버 내부 구성에 오류가 있어 반환되는 값에 콘텐츠 협상이 순환 참조로 이루어져 있다는걸 알려주는 코드이다.
*508(루프 감지됨, WebDAV; RFC 5842)
+
*507 Insufficient Storage (용량 부족, WebDAV; RFC 4918) : 서버 내부 구성(값)에 오류가 있어 선택된 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 과정에서 적절한 끝점이 아님을 알려주는 코드이다.
*509(대역폭 제한 초과, Apache bw/limited extension)
+
*508 Loop Detected (루프 감지됨, WebDAV; RFC 5842) : 서버가 요청을 처리하는 동안 무한 루프를 발견하였을 때 뜨는 응답코드이다.
*510(확장되지 않음, RFC 2774)
+
*509 (대역폭 제한 초과, Apache bw/limited extension)
*511(네트워크 인증 필요, RFC 6585)
+
*510 Not Extended (확장되지 않음, RFC 2774)
 +
*511 Network Authentication Required (네트워크 인증 필요, RFC 6585)
 
*520(Unknown Error, 알 수 없음)
 
*520(Unknown Error, 알 수 없음)
*598(네트워크 읽기 시간초과 오류, 알 수 없음)
+
*598 (네트워크 읽기 시간초과 오류, 알 수 없음)
*599(네트워크 연결 시간초과 오류, 알 수 없음)<ref name"위키백과">HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드</ref>
+
*599 (네트워크 연결 시간초과 오류, 알 수 없음)<ref name"위키백과">HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드</ref>
  
==HTTPS==
+
===비교===
HTTPS는 월드 와이드 웹 통신(WWW) 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신에서의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다.
+
[[HTTPS]]는 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신에서의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈(Netscape Communications)가 개발했으며, 전자상거래에서 널리 쓰인다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다. 보호의 수준은 웹브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. HTTPS를 사용하는 웹페이지의 [[URL]]은 'http://'대신 'https://'로 시작한다. 웹에서 신용카드를 사용하는 사람들 사이의 흔한 오해 중 하나는, HTTPS를 이용할 때 HTTPS가 완벽한 보호를 제공해준다고 생각하는 점이다. 그러나 실제로 이것은 웹 서버와 브라우저 간에 전송되는 카드 정보만이 암호화될 뿐이다. 카드 정보는 보통 서버 데이터베이스에 저장되며 (많은 경우 신용카드 처리기에는 전송되지도 않는다), 대개의 정보 유출은 내부 인력에 의해 이루어진다.<ref>islove8587, 〈[http://bitly.kr/uwn74W HTTP란?]〉, 《네이버 블로그》, 2008-03-07</ref>
HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 [[세션]]데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는443이다.
 
보호의 수준은 [[웹 브라우저]]에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다.
 
HTTPS를 사용하는 웹페이지의 [[URL]]은 'http://'대신 'https://'로 시작한다. 웹에서 신용카드를 사용하는 사람들 사이의 흔한 오해 중 하나는, HTTPS를 이용할 때 HTTPS가 “완벽한”보호를 제공해준다고 생각하는 점이다. 그러나 실제로 이것은 웹 서버와 브라우저 간에 전송되는 카드 정보만이 암호화될 뿐이다. 카드 정보는 보통 서버 데이터베이스에 저장되며 (많은 경우 신용카드 처리기에는 전송되지도 않는다), 대개의 정보 유출은 내부 인력에 의해 이루어진다.<ref>islove8587, 〈[http://bitly.kr/uwn74W HTTP란?]〉, 《네이버 블로그》, 2008-03-07</ref>
 
  
 
{{각주}}
 
{{각주}}

2020년 8월 24일 (월) 00:20 기준 최신판

HTTP(에이치티티피)는 "Hypertext Transfer Protocol"의 약자로서, (web)을 이용하여 HTML로 작성된 하이퍼텍스트(hypertext) 문서를 주고받을 수 있는 프로토콜이다. HTTP 통신규약을 이용하여 웹서버웹브라우저 사이에서 정보를 주고받을 수 있다. 포트 번호는 80번이다. 에이치티티피라고 읽는다. 보통 "http://"와 같이 소문자로 쓴다.

개요[편집]

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 보통 브라우저인 수신자에 의해 요청이 초기화되는 것을 의미하는, 웹과 클라이언트·서버 모델 상에서 모든 데이터 교환이 기초다. 하나의 완전한 문서는 페치(Fetch)된 또 다른 하위 문서, 텍스트, 레이아웃 설명, 이미지, 비디오. 스크립트 등으로 구성된다. 데이터스트림과 대조적으로 클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신한다. 보통 클라이언트에 의해 전송되는 메시지를 요청(request)이라고 부르며, 그에 대한 서버의 응답으로 전송되는 메시지를 응답(response)이라고 부른다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송한다. HTTP의 확장성 덕분에 오늘날 하이퍼 텍스트 문서뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트하기 위해 사용된다. 또한, 필요할 때마다 웹페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있다.[1]

HTTP의 주요 특성은 비연결성(Connectionless)이다. 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징이다. HTTP는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 접속을 끊는 특성이 있다. 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이것이 디폴트다. HTTP가 TCP 위에서 구현되었기 때문에(TCP는 연결지향, UDP는 비연결지향) 네트워크 관점에서 keep-alive는 옵션으로 비연결성의 연결비용을 줄이는 것을 장점으로 비연결지향이라 한다. HTTP의 또다른 특징은 무상태(Stateless)로, 통신이 끝나면 상태를 유지하지 않는다. 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다. 두 가지 특징이자 약점을 보완하기 위해서 쿠키(cookie)와 세션(session)을 사용한다. 예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때마다 계속 로그인을 해야 한다. 쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 어떠한 방식에 의해서 그 사용자에 대한 인증을 유지하게 된다. [2]

역사[편집]

  • 1965년 : 제너두 프로젝트(Project Xanadu)에서 테드 넬슨(Theodor Nelson)에 의해 하이퍼텍스트라는 용어가 만들어졌으며, 제너두 프로젝트는 '우리가 생각한 대로(As We May Think)'라는 수필에서 마이크로필름 기반 정보 수신 및 관리 메멕스(Memex) 시스템을 기술한 버니바 부시(Vannevar Bush)의 비전(1930년대)에 의해 영감을 받았다.
  • 1989년 : 팀 버너스 리(Timothy Berners Lee)와 그의 팀은 유럽원자핵공동연구소 세른(CERN)에서 HTML뿐 아니라 웹브라우저 및 텍스트 기반 웹브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 월드와이드웹(world wide web) 프로젝트를 제안하였으며, 이것이 현재의 월드와이드웹이다. 이 프로토콜의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다. 서버로부터의 응답은 무조건 HTML 문서였다.
  • 1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0.9이다.
  • 1995년 : 데이브 레겟(Dave Raggett)은 HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다.
  • 1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다.
  • 1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다.
  • 1996년 03월 : 이전 표준 HTTP/1.1을 지원한 웹브라우저로 아레나, 넷스케이프 2.0, 넷스케이프 내비게이터 골드 2.01, 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0이 있다. 새로운 브라우저의 최종 사용자 채택 속도를 빨랐다.
  • 1996년 03월 : 한 웹호스팅 회사의 보고에 따르면 인터넷 상에서 사용 중인 브라우저 중 40% 이상이 HTTP 1.1과 호환되었다. 같은 웹 호스팅 회사는 1996년 6월 기준으로 서버에 접근하는 모든 브라우저들 가운데 65%가 HTTP/1.1 호환이라고 보고하였다.
  • 1997년 01월 : RFC 2068에 정의된 HTTP/1.1 표준이 공식적으로 출시되었다.
  • 1999년 06월 : HTTP/1.1 표준에 대한 개선과 업데이트가 RFC 2616으로 출시되었다.
  • 2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다.
  • 2014년 06월 : WG는 RFC 2616를 옵솔리트(obsolete) 처리하는, 업데이트된 6 파트 사양을 출시하였다.
  • 2015년 05월 : HTTP/2가 RFC 7540로 출판되었다.[3]

특징[편집]

구성요소[편집]

HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트 또는 그것을 대신하는 프록시(Proxy)에 의해 전송된다. 각각의 개별적인 요청은 서버로 전송되며, 서버는 요청을 처리하고 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하고, 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다. 실제 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들(라우터, 모뎀 등)이 존재한다. 웹의 계층적인 설계 덕분에 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP는 애플리케이션 계층의 최상위에 있다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없다.

  • 클라이언트 : 사용자를 대신하여 동작하는 모든 도구를 뜻한다. 웹페이지를 표시하기 위해 브라우저는 페이지의 HTTL 문서를 가져오기 위한 요청을 전송한 뒤, 파일의 구문을 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(이미지, 비디오 등)을 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다. 그런 뒤 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 그 리소스들을 혼합한다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹페이지를 갱신하게 된다.
  • 웹서버 : 통신 채널의 반대편에는 클라이언트 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 사실상 논리적으로 단일 기계이다. 이는 로드밸런싱 혹은 그때그때 다른 컴퓨터(캐시, DB 서버, 전자상거래 등)와 같은 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합일 수도 있기 때문이다. 서버는 반드시 단일 기계일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있다. HTTP/1.1과 호스트 헤더를 이용해 동일한 IP 주소를 공유할 수도 있다.
  • 프록시 : 웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 중계한다. 웹 스택의 계층 구조 덕분에 이들 대부분은 전송, 네트워크 혹은 물리적 수준에서 동작하며, 이것들이 성능상 상당한 영향을 갖고 있음에도 불구하고 HTTP 계층에서는 눈에 보이지 않는다. 애플리케이션 계층에서 이렇게 중계하는 것을 프록시라고 부른다. 프록시가 눈에 보이거나 그렇지 않을 수 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능을 수행할 수 있다.
  1. 캐시 : 공개 또는 비공개될 수 있다.(예: 브라우저 캐시)
  2. 필터링 : 바이러스 백신 스캔, 유해 컨텐츠 차단(예 : 자녀 보호 기능)
  3. 로드밸런싱 :여러 서버들이 서로 다른 요청을 처리하도록 허용
  4. 인증 : 다양한 리소스에 대한 접근 요청
  5. 로깅 : 이력 정보 저장[1]

메시지 포맷[편집]

HTTP는 요청과 응답으로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP는 FTP텔넷과는 다르게 비연결식이다. FTP나 텔넷은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.[4]

  • 요청 메시지 : 요청 내용(GET /images/logo.gif HTTP/1.1)과 헤더(Accept-Language: en), 빈 줄 (empty line), 기타 메시지를 포함하여 표시된다. 요청 내용과 헤더 필드는 CR, LF로 끝나야 한다. 즉, 캐리지 리턴(carriage return) 다음에 라인 피드(line feed)가 와야 한다. 빈 줄은 CR, LF로 구성되며 그 외 다른 화이트스페이스(whitespace)가 있어서는 안된다. 이를 정리 및 요약하면 다음과 같다.
HTTP 메소드 RFC 요청에 Body가 있음 응답에 Body가 있음 안전 멱등(Idempotent) 캐시 가능
GET RFC 7231 아니오
HEAD RFC 7231 아니오 아니오
POST RFC 7231 아니오 아니오
PUT RFC 7231 아니오 아니오
DELETE RFC 7231 아니오 아니오 아니오
CONNECT RFC 7231 아니오 아니오 아니오
OPTIONS RFC 7231 선택 사항 아니오
TRACE RFC 7231 아니오 아니오
PATCH RFC 5789 아니오 아니오
  • 응답 메시지 : 상태코드(status code)와 요청 메시지(reason message)를 포함하는 상태표시 행(예 : HTTP/1.1 200 OK. 클라이언트의 요청이 성공적으로 전달되었음을 표시)과 응답 헤더필드(예 : Content-Type: text/html), 빈 줄, 기타 메시지로 구성된다.[3]

응답 코드[편집]

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

1xx[편집]

조건부 응답으로, 요청을 받았으며 작업을 계속한다. 이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.

  • 100 Continue (계속) : 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
  • 101 Switching Protocols (프로토콜 전환) : 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
  • 102 Processing (처리, RFC 2518)
  • 103 Early Hints (사전로딩) : 링크헤더와 함께 사용되며 주로 서버가 응답을 준비하는 동안 사용자가 사전로딩(PreLoading)을 할수 있도록 하는 응답코드이다.

2xx[편집]

이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.

  • 200 OK (성공) : 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
  • 201 Created (작성됨) : 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
  • 202 Accepted (허용됨) : 서버가 요청을 접수했지만 아직 처리하지 않았다.
  • 203 Non-Authoritative Information (신뢰할 수 없는 정보) : 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
  • 204 No Content (콘텐츠 없음) : 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
  • 205 Reset Content (콘텐츠 재설정) : 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 요청자가 문서 보기를 재설정할 것을 요구한다.
  • 206 Partial Content (일부 콘텐츠) : 서버가 GET 요청의 일부만 성공적으로 처리했다.
  • 207 Multi-Status (다중 상태, RFC 4918)
  • 208 Already Reported (이미 보고됨, RFC 5842)
  • 226 IM Used (의무 완료, RFC 3229)

3xx[편집]

클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.

  • 300 Multiple Choices (여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
  • 301 Moved Permanently (영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
  • 302 Found (임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
  • 303 See Other (기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
  • 304 Not Modified (수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
  • 305 Use Proxy (프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
  • 306 Unused (사용 중지) : 초기 HTTP/1.1까지만 해도 스위치 프록시 요청으로 다음 요청시 지정한 프록시 서버를 사용하라는 응답 코드로 초안이 각성되었으나, 정작 사용이 되지 않았고 지금은 305 Use Proxy 응답이 사용 중지되어 문서에서 삭제, 예약코드로 있다.
  • 307 Temporary Redirect (임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
  • 308 Permanent Redirect (영구 리다이렉션, RFC에서 실험적으로 승인됨)

4xx (요청 오류)[편집]

4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.

  • 400 Bad Request (잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
  • 401 Unauthorized (권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
  • 402 Payment Required (결제 필요): 이 요청은 결제가 필요합니다.
  • 403 Forbidden (거부됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
  • 404 Not Found (찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
  • 405 Method Not Allowed (허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
  • 406 Not Acceptable (받아들일 수 없음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
  • 407 Proxy Authentication Required (프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
  • 408 Request Timeout (요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
  • 409 Conflict (충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
  • 410 Gone(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
  • 411 Length Required (길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
  • 412 Precondition Failed (사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
  • 413 Payload Too Large (요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
  • 414 URI Too Long (요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
  • 415 Unsupported Media Type (지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
  • 416 Requested Range Not Satisfiable (처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
  • 417 Expectation Failed (예측 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
  • 418 I'm a teapot (나는 찻주전자이다, RFC 2324 ,https://google.com/teapot) : 찻주전자로는 커피를 만들 수 없다. 이는 하이퍼텍스트 커피 포트 제어 프로토콜(HTCPCP)(RFC 2324)에서 사용되는 코드이다.
  • 420 (Enhance Your Calm, 트위터)
  • 421 Misdirected Request(잘못된 요청): 서버로 유동된 요청된 응답을 서버에서 생성할 수 없을때 응답하는 코드로 주로 TLS 인증서가 여러개 설치된 상태에서 꼬였을 경우 뜨는 오류다.
  • 422 Unprocessable Entity (처리할 수 없는 개체, WebDAV; RFC 4918)
  • 423 Locked (잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
  • 424 Failed Dependenc (실패된 의존성, WebDAV; RFC 4918)
  • 424 (method 실패, WebDAV)
  • 425 Too Early (정렬되지 않은 컬렉션, 인터넷 초안) : 서버가 재생될 수 있는 요청을 처리하는 데 위험을 감수하지 않는다는걸 알릴때 사용되는 코드이다.[RFC8470] 클라이언트가 파이어폭스 58 이후 버전이 아닌이상 재대로 해석하지는 않는다.
  • 426 Upgrade Required (업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
  • 428 Precondition Required (전제조건 필요, RFC 6585)
  • 429 Too Many Requests (너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
  • 431 Request Header Fields Too Large (요청 헤더 필드가 너무 큼, RFC 6585)
  • 444 (응답 없음, Nginx)
  • 449 (다시 시도, 마이크로소프트)
  • 450 (윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
  • 451 Unavailable For Legal Reasons (법적인 이유로 이용 불가, 인터넷 초안)
  • 451 (리다이렉션, 마이크로소프트)
  • 494 (요청 헤더가 너무 큼, Nginx)
  • 495 (Cert 오류, Nginx)
  • 496 (Cert 없음, Nginx)
  • 497 (HTTP to HTTPS, Nginx)
  • 499 (클라이언트가 요청을 닫음, Nginx)

5xx (서버 오류)[편집]

서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

  • 500 Internal Server Error (내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
  • 501 Not Implemented (구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
  • 502 Bad Gateway(불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
  • 503 Service Temporarily Unavailable (일시적으로 서비스를 사용할 수 없음) : 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
  • 504 Gateway Timeout (게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
  • 505 HTTP Version Not Supported (HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
  • 506 Variant Also Negotiates (서버 내부 구성에 오류가 있음, RFC 2295) : 서버 내부 구성에 오류가 있어 반환되는 값에 콘텐츠 협상이 순환 참조로 이루어져 있다는걸 알려주는 코드이다.
  • 507 Insufficient Storage (용량 부족, WebDAV; RFC 4918) : 서버 내부 구성(값)에 오류가 있어 선택된 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 과정에서 적절한 끝점이 아님을 알려주는 코드이다.
  • 508 Loop Detected (루프 감지됨, WebDAV; RFC 5842) : 서버가 요청을 처리하는 동안 무한 루프를 발견하였을 때 뜨는 응답코드이다.
  • 509 (대역폭 제한 초과, Apache bw/limited extension)
  • 510 Not Extended (확장되지 않음, RFC 2774)
  • 511 Network Authentication Required (네트워크 인증 필요, RFC 6585)
  • 520(Unknown Error, 알 수 없음)
  • 598 (네트워크 읽기 시간초과 오류, 알 수 없음)
  • 599 (네트워크 연결 시간초과 오류, 알 수 없음)[5]

비교[편집]

HTTPS는 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신에서의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈(Netscape Communications)가 개발했으며, 전자상거래에서 널리 쓰인다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다. 보호의 수준은 웹브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. HTTPS를 사용하는 웹페이지의 URL은 'http://'대신 'https://'로 시작한다. 웹에서 신용카드를 사용하는 사람들 사이의 흔한 오해 중 하나는, HTTPS를 이용할 때 HTTPS가 완벽한 보호를 제공해준다고 생각하는 점이다. 그러나 실제로 이것은 웹 서버와 브라우저 간에 전송되는 카드 정보만이 암호화될 뿐이다. 카드 정보는 보통 서버 데이터베이스에 저장되며 (많은 경우 신용카드 처리기에는 전송되지도 않는다), 대개의 정보 유출은 내부 인력에 의해 이루어진다.[6]

각주[편집]

  1. 1.0 1.1 Minkuk Jo, 〈IT 용어 정리 - HTTP 란?〉, 《네이버 블로그》, 2019-05-08
  2. 라이언곰돌이푸, 〈쿠키와 세션 개념〉, 《티스토리》, 2019-09-01
  3. 3.0 3.1 HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP
  4. HTTP 나무위키 - https://namu.wiki/w/HTTP
  5. HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드
  6. islove8587, 〈HTTP란?〉, 《네이버 블로그》, 2008-03-07

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 HTTP 문서는 인터넷에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.