해시넷
HTTP
HTTP(에이치티티피)는 Hypertext Transfer Protocol의 약자로서, 월드 와이드 웹(WWW: World Wide Web)을 이용하여 HTML로 작성된 하이퍼 텍스트(Hyper Text) 문서를 주고받을 수 있는 프로토콜이다. HTTP 통신규약을 이용하여 웹서버와 웹브라우저 사이에서 정보를 주고받을 수 있다. 포트 번호는 80번이다. 에이치티티피라고 읽는다. 보통 "http://"와 같이 소문자로 쓴다.
목차
개요
HTTP는 웹 상에서 클라이언트와 서버 간에 통신을 위해 개발된 프로토콜이다. 웹의 정식 명칭은 월드 와이드 웹으로 전 세계에 거미줄처럼 연결된 망이라는 뜻이다. 다양한 하이퍼 텍스트 문서들이 웹 상에서 서로 연결되어 있다. 하이퍼 텍스트 문서란 참조 혹은 링크를 통해 한 문서에서 다른 문서로 접근할 수 있는 문서를 말한다. 대표적인 하이퍼 텍스트 문서로 HTML이 있다. 주로 80/tcp 포트를 사용하며 1991년 초기버전(0.9)이 발표된 이후 1996년 1.0버전, 1999년 1.1버전이 발표되어 널리 사용되고 있다. HTTP 통신은 클라이언트 요청(Request)과 서버 응답(Response)으로 이루어져 있다. HTTP/1.1 버전부터 Connection 헤더에 Keep-Alive 옵션이 추가되었다, 이는 TCP 연결 상태를 웹 서버 설정에 따라 일정시간 지속시키는 옵션으로 한 번의 연결 이후에 요청/응답을 반복할 수 있다. HTTP 응답 메시지를 분석해보면, 일반적으로 이미지, 스크립트 등 다수의 추가 자원 요청이 발생한다. 따라서 TCP 연결 설정 및 종료에 대한 부하를 줄이면서 효율적으로 클라이언트 요청을 처리하기 위해 연결 상태를 일정시간 유지하는 옵션이 추가되었다.[1]
역사
- 1965년 : 제너두 프로젝트에서 테드 넬슨에 의해 하이퍼텍스트라는 용어가 만들어졌으며, 제너두 프로젝트는 'As We May Think(1945년)'라는 수필에서 마이크로필름 기반 정보 수신 및 관리 "메멕스" 시스템을 기술한 버니바 부시의 비전(1930년대)에 의해 영감을 받았다.
- 1989년 : 팀 버너스 리와 그의 팀은 CERN에서 HTML뿐 아니라 웹 브라우저 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP을 발명하였다. 버너스 리는 최초로 "월드와이드웹" 프로젝트를 제안하였으며, 이것이 현재의 월드 와이드 웹이다. 이 프로토콜의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다. 서버로부터의 응답은 무조건 HTML 문서였다.
- 1991년 : 문서화된 최초의 HTTP 버전은 HTTP V0.9(1991년)이다.
- 1995년 : 데이브 레겟은 HTTP 워킹 그룹(HTTP WG)을 이끌었으며 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 또 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜을 확장하기를 바랐다.
- 1995년 12월 : HTTP WG는 새로운 표준을 출간하기로 계획하였으며 당시 개발 중인 RFC 2068(이른바 HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초에 주요 브라우저 개발자들에 의해 빠르게 채택되었다.
- 1996년 : RFC 1945는 공식적으로 HTTP v1.0을 도입하였다.
- 1996년 3월 : 이전 표준 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 호환이라고 보고하였다.
- 1997년 1월 : RFC 2068에 정의된 HTTP/1.1 표준이 공식적으로 출시되었다.
- 1999년 6월 : HTTP/1.1 표준에 대한 개선과 업데이트가 RFC 2616으로 출시되었다.
- 2007년 : 부분적으로 HTTP/1.1 사양을 개정하고 분명히 하기 위해 HTTPbis 워킹 그룹이 창설되었다.
- 2014년 6월 : WG는 RFC 2616를 obsolete 처리하는, 업데이트된 6 파트 사양을 출시하였다.
- 2015년 5월 : HTTP/2가 RFC 7540로 출판되었다.[2]
특징
- TCP/IP를 이용하는 응용 프로토콜(application protocol) 이다. 컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 인터넷을 통해 원하는 정보를 주고 받는 기능을 이용하는 응용 프로콜로 포트 번호는 기본적으로 80번을 사용한다.
- HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다. 예를 들면 브라우저를 통해 사용자의 요청(Request)에 따라 서버와 접속하여 요청에 대한 응답(Response)의 데이터를 전송 후 연결 종료한다. 이러한 심플한 상태이기 때문에 전산 자원이 적게 든다는 장점이 있다. 하지만, 연결이 지속적이지 않기에 사용자와 종료 후 추가적인 요청을 처리할 수 없다는 단점이 있다. 이런 단점을 해소하기 위한 방법으로 Cookie, Session, URL Rewriting, Hidden Form Field 등이 사용된다. 참고로 HTTP와 반대로 연결 상태 유지하는 프로토콜은 FTP, Telnet이 있다.
- HTTP는 연결 상태를 유지하지 않는 프로토콜이기 때문에 요청(Request)/응답(Response)방식으로 동작한다. 서버가 먼저 응답하지 않으며 사용자의 요청 한개에 대해 한개의 응답을 하는 방식이다.[3]
동작방식
HTTP는 연결 상태를 유지하지 않는 프로토콜이기 때문에 요청/응답(request/response)방식으로 동작한다.
- 클라이언트 연결
- 클라이언트 측 브라우저에서 웹 리소스를 얻기 위해 브라우저에서 URL 발급
- HTTP Request
- 서버에서 Request 메세지를 해석하고 사용자에게 요청한 자원 오류 메세지 등의 적절한 Http Response 반환
메시지 포맷
클라이언트와 서버 사이의 소통은 평문(ASCII) 메시지로 이루어진다. 클라이언트는 서버로 요청메시지를 전달하며 서버는 응답메시지를 보낸다.
요청 메시지
- 요청 내용
보기) GET /images/logo.gif HTTP/1.1
- 헤더
보기) Accept-Language: en
- 빈 줄 (empty line)
- 기타 메시지를 포함하여 표시된다.
요청 내용과 헤더 필드는 <CR><LF>로 끝나야 한다. 즉, 캐리지 리턴(Carriage Return) 다음에 라인 피드(Line Feed)가 와야 한다. 빈 줄(empty line)은 <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 line): 상태코드(status code)와 reason message를 포함한다. (예. HTTP/1.1 200 OK. 클라이언트의 요청이 성공적으로 전달되었음을 표시)
- 응답 헤더필드 (예.Content-Type: text/html)
- 빈 줄 (empty line)
- 기타 메시지[2]
응답 코드
1xx (조건부 응답)
요청을 받았으며 작업을 계속한다. 이 상태의 상태 코드는 상태-라인과 선택적 헤더(컴퓨터에서 출력될 때 각 페이지 맨 윗부분에 자동으로 붙는 부분)만을 포함하는 임시의 응답을 나타내고 빈 라인에 의해서 종결된다. HTTP/1.0이래로 어떤 1XX 상태 코드들도 정의 되지 않았다. 서버들은 1XX 응답을 실험적인 상태를 제외하고 HTTP/1.0 클라이언트(서버에 연결된 컴퓨터)로 보내면 안 된다.
- 100(계속): 요청자는 요청을 계속해야 한다. 서버는 이 코드를 제공하여 요청의 첫 번째 부분을 받았으며 나머지를 기다리고 있음을 나타낸다.
- 101(프로토콜 전환): 요청자가 서버에 프로토콜 전환을 요청했으며 서버는 이를 승인하는 중이다.
- 102(처리, RFC 2518)
2xx (성공)
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
- 200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
- 201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
- 202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
- 203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
- 204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
- 205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
- 206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
- 207(다중 상태, RFC 4918)
- 208(이미 보고됨, RFC 5842)
- 226 IM Used (RFC 3229)
3xx (리다이렉션 완료)
클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
- 300(여러 선택항목): 서버가 요청에 따라 여러 조치를 선택할 수 있다. 서버가 사용자 에이전트에 따라 수행할 작업을 선택하거나, 요청자가 선택할 수 있는 작업 목록을 제공한다.
- 301(영구 이동): 요청한 페이지를 새 위치로 영구적으로 이동했다. GET 또는 HEAD 요청에 대한 응답으로 이 응답을 표시하면 요청자가 자동으로 새 위치로 전달된다.
- 302(임시 이동): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
- 303(기타 위치 보기): 요청자가 다른 위치에 별도의 GET 요청을 하여 응답을 검색할 경우 서버는 이 코드를 표시한다. HEAD 요청 이외의 모든 요청을 다른 위치로 자동으로 전달한다.
- 304(수정되지 않음): 마지막 요청 이후 요청한 페이지는 수정되지 않았다. 서버가 이 응답을 표시하면 페이지의 콘텐츠를 표시하지 않는다. 요청자가 마지막으로 페이지를 요청한 후 페이지가 변경되지 않으면 이 응답(If-Modified-Since HTTP 헤더라고 함)을 표시하도록 서버를 구성해야 한다.
- 305(프록시 사용): 요청자는 프록시를 사용하여 요청한 페이지만 액세스할 수 있다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 하다.
- 307(임시 리다이렉션): 현재 서버가 다른 위치의 페이지로 요청에 응답하고 있지만 요청자는 향후 요청 시 원래 위치를 계속 사용해야 한다.
- 308(영구 리다이렉션, RFC에서 실험적으로 승인됨)
4xx (요청 오류)
4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.
- 400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
- 401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.
- 402(결제 필요): 이 요청은 결제가 필요합니다.
- 403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
- 404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
- 405(허용되지 않는 방법): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
- 406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
- 407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
- 408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
- 409(충돌): 서버가 요청을 수행하는 중에 충돌이 발생했다. 서버는 응답할 때 충돌에 대한 정보를 포함해야 한다. 서버는 PUT 요청과 충돌하는 PUT 요청에 대한 응답으로 이 코드를 요청 간 차이점 목록과 함께 표시해야 한다.
- 410(사라짐): 서버는 요청한 리소스가 영구적으로 삭제되었을 때 이 응답을 표시한다. 404(찾을 수 없음) 코드와 비슷하며 이전에 있었지만 더 이상 존재하지 않는 리소스에 대해 404 대신 사용하기도 한다. 리소스가 영구적으로 이동된 경우 301을 사용하여 리소스의 새 위치를 지정해야 한다.
- 411(길이 필요): 서버는 유효한 콘텐츠 길이 헤더 입력란 없이는 요청을 수락하지 않는다.
- 412(사전조건 실패): 서버가 요청자가 요청 시 부과한 사전조건을 만족하지 않는다.
- 413(요청 속성이 너무 큼): 요청이 너무 커서 서버가 처리할 수 없다.
- 414(요청 URI가 너무 긺): 요청 URI(일반적으로 URL)가 너무 길어 서버가 처리할 수 없다.
- 415(지원되지 않는 미디어 유형): 요청이 요청한 페이지에서 지원하지 않는 형식으로 되어 있다.
- 416(처리할 수 없는 요청범위): 요청이 페이지에서 처리할 수 없는 범위에 해당되는 경우 서버는 이 상태 코드를 표시한다.
- 417(예상 실패): 서버는 Expect 요청 헤더 입력란의 요구사항을 만족할 수 없다.
- 418(I'm a teapot, RFC 2324 ,https://google.com/teapot)
- 420(Enhance Your Calm, 트위터)
- 422(처리할 수 없는 엔티티, WebDAV; RFC 4918)
- 423(잠김,WebDAV; RFC 4918): 접근하려는 리소스가 잠겨 있다.
- 424(실패된 의존성, WebDAV; RFC 4918)
- 424(메쏘드 실패, WebDAV)
- 425(정렬되지 않은 컬렉션, 인터넷 초안)
- 426(업그레이드 필요, RFC 2817): 클라이언트는 업그레이드 헤더 필드에 주어진 프로토콜로 요청을 보내야 한다.
- 428(전제조건 필요, RFC 6585)
- 429(너무 많은 요청, RFC 6585): 사용자가 일정 시간 동안 너무 많은 요청을 보냈다.
- 431(요청 헤더 필드가 너무 큼, RFC 6585)
- 444(응답 없음, Nginx)
- 449(다시 시도, 마이크로소프트)
- 450(윈도 자녀 보호에 의해 차단됨, 마이크로소프트)
- 451(법적인 이유로 이용 불가, 인터넷 초안)
- 451(리다이렉션, 마이크로소프트)
- 494(요청 헤더가 너무 큼, Nginx)
- 495(Cert 오류, Nginx)
- 496(Cert 없음, Nginx)
- 497(HTTP to HTTPS, Nginx)
- 499(클라이언트가 요청을 닫음, Nginx)
5xx (서버 오류)
서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.
- 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
- 501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
- 502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
- 503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
- 504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
- 505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
- 506(Variant Also Negotiates, RFC 2295)
- 507(용량 부족, WebDAV; RFC 4918)
- 508(루프 감지됨, WebDAV; RFC 5842)
- 509(대역폭 제한 초과, Apache bw/limited extension)
- 510(확장되지 않음, RFC 2774)
- 511(네트워크 인증 필요, RFC 6585)
- 520(Unknown Error, 알 수 없음)
- 598(네트워크 읽기 시간초과 오류, 알 수 없음)
- 599(네트워크 연결 시간초과 오류, 알 수 없음)[4]
HTTPS
HTTPS는 월드 와이드 웹 통신(WWW) 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신에서의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는443이다. 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. HTTPS를 사용하는 웹페이지의 URL은 'http://'대신 'https://'로 시작한다. 웹에서 신용카드를 사용하는 사람들 사이의 흔한 오해 중 하나는, HTTPS를 이용할 때 HTTPS가 “완벽한”보호를 제공해준다고 생각하는 점이다. 그러나 실제로 이것은 웹 서버와 브라우저 간에 전송되는 카드 정보만이 암호화될 뿐이다. 카드 정보는 보통 서버 데이터베이스에 저장되며 (많은 경우 신용카드 처리기에는 전송되지도 않는다), 대개의 정보 유출은 내부 인력에 의해 이루어진다.[5]
각주
- ↑ 공대냥이, 〈IT 용어 정리 - HTTP 란?〉, 《티스토리》, 2018-10-19
- ↑ 2.0 2.1 HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP
- ↑ 달나라 곰돌이, 〈(기본)HTTP란?〉, 《헬로우월드》, 2018-07-18
- ↑ HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드
- ↑ islove8587, 〈HTTP란?〉, 《네이버 블로그》, 2008-03-07
참고자료
- 공대냥이, 〈IT 용어 정리 - HTTP 란?〉, 《티스토리》, 2018-10-19
- HTTP 위키백과 - https://ko.wikipedia.org/wiki/HTTP
- 달나라 곰돌이, 〈(기본)HTTP란?〉, 《헬로우월드》, 2018-07-18
- HTTP 상태 코드 위키백과 - https://ko.wikipedia.org/wiki/HTTP_상태_코드
- islove8587, 〈HTTP란?〉, 《네이버 블로그》, 2008-03-07
같이 보기
