최근 수정 시각 : 2024-12-12 13:00:19

HTTP



파일:나무위키+유도.png  
은(는) 여기로 연결됩니다.
펌프 잇 업의 수록곡에 대한 내용은 HTTP(펌프 잇 업) 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.

파일:나무위키+유도.png  
은(는) 여기로 연결됩니다.
TLS를 통한 보안이 적용된 버전에 대한 내용은 HTTPS 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.
1. 개요2. 설명3. 역사4. 구조
4.1. 요청4.2. 응답
5. 메시지 종류
5.1. 요청5.2. 응답 코드
6. HTTPS와의 차이점

1. 개요

HyperText Transfer Protocol 또는 HyperTexT Protocol의 약자이다. 문서를 전송하기 위한 프로토콜.

2. 설명

하이퍼텍스트를 빠르게 교환하기 위한 프로토콜의 일종으로, 서버 클라이언트의 사이에서 어떻게 메시지를 교환할지를 정해 놓은 규칙이다. 요청(Request)과 응답(Response)으로 구성되어 있으며, 일반적으로 80번 포트를 사용한다. 예를 들면 '클라이언트가 웹 페이지에서 링크가 걸려있는 텍스트를 클릭(요청)하면 링크를 타고 새로운 페이지로 넘어간다(응답)'. 따라서 우리가 사용하는 웹 브라우저에서 인터넷 주소 맨 앞에 들어가는 http://가 바로 이 프로토콜을 사용해서 정보를 교환하겠다는 표시인 것이다.

사실 // 부분은 치지 않아도 정상 접속 된다. 이이 대해 팀 버너스리는 고안 당시 멋으로 만든 것이라고 설명했다.

3. 역사

CERN에서 일하던 팀 버너스리와 그의 팀원들이 1989년에 월드 와이드 웹을 제안하면서 시작되었다. 최초 규격인 HTTP/0.9가 1991년에 나왔다. 1996년에는 첫 상용화 버전인 HTTP/1.0가 발표되었고, 1999년에 HTTP/1.1, 2015년에 HTTP/2가 공식적으로 발표되었고, 현재는 HTTP/3를 도입 중이다.

HTTP/2는 구글이 발표한 SPDY라는 기술을 기반으로 했고, HTTP/3도 구글이 발표한 QUIC 기술을 기반으로 한다. HTTP/1.0 ~ HTTP/2까지는 TCP 연결을 사용하고, HTTP/3는 UDP 연결을 사용한다.

대부분의 사이트들은 HTTP/1.1과 HTTP/2를 동시 지원 하고 있고, HTTP/3를 도입하는 곳들도 점차 늘어나고 있다. HTTP/2는 HTTPS 연결에서만 작동하며, HTTP 연결일 경우에는 브라우저와 서버에서 HTTP/2를 지원하더라도 HTTP/1.1로 연결된다.

4. 구조

HTTP는 요청(Request)와 응답(Response)로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP는 FTP 텔넷과는 다르게 비연결식이다. FTP나 Telnet은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다. 우리가 나무위키에 접속을 했다고 가정하자. 접속하면 클라이언트는 GET 명령을 나무위키 서버에 전송한다. GET 요청을 받은 나무위키는 응답 코드와 메시지를 전송하고, 그것을 브라우저가 화면에 뿌려주는 것이다. 다만 1.1버전에서는 Connection Header의 Keep-Alive 옵션을 통해 TCP연결을 일정시간 유지할 수도 있다.

4.1. 요청

다음 요청 메시지는 namu.wiki의 index.html을 보여 달라는 요청이다.
GET /index.html HTTP/1.1  -  헤더
Host: namu.wiki  -  호스트
- 공백 -

4.2. 응답

요청을 받은 서버는 다음과 같이 응답한다.
HTTP/1.1 200 OK
<헤더>

<HTML>
    <HEAD>
        <TITLE>Hello!</TITLE>
    </HEAD>

    <BODY>
        <p>World!</p>
    </BODY>
</HTML>

'HTTP/1.1'은 HTTP의 버전이며, '200 OK'는 자료 전송이 성공했다는 의미이다. 헤더 부분엔 서버 정보와 요청받은 시각 등이 전송되고, 그 밑에 응답 본문이 전송된다. 일반적인 웹 문서를 요청했을 경우에는 <HTML>로 시작하는 웹 문서가 전송된다.

5. 메시지 종류

5.1. 요청

HTTP에서 지원하는 요청 메시지는 다음과 같다.
  • GET: 클라이언트가 서버에게 URL에 해당하는 자료의 전송을 요청한다.
  • HEAD: GET 요청으로 반환될 데이터 중 헤더 부분에 해당하는 데이터만 요청한다.
  • POST: 클라이언트가 서버에서 처리할 수 있는 자료를 보낸다. 예를 들어, 게시판에 글을 쓸 때 클라이언트의 문서가 서버로 전송되어야 한다. 멱등성을 보장하지 않는다.
  • PATCH: 클라이언트가 서버에게 지정한 URL의 데이터를 부분적으로 수정할 것을 요청한다.
  • PUT: 클라이언트가 서버에게 지정한 URL에 지정한 데이터를 저장할 것을 요청한다.
  • DELETE: 클라이언트가 서버에게 지정한 URL의 정보를 제거할 것을 요청한다.
  • TRACE: 클라이언트가 서버에게 송신한 요청의 내용을 반환해 줄 것을 요청한다.
  • CONNECT: 클라이언트가 특정 종류의 프록시 서버에게 연결을 요청한다.
  • OPTIONS: 해당 URL에서 지원하는 요청 메세지의 목록을 요청한다.

이 중 GET 과 HEAD 요청은 원칙적으로 이를 호출한다고 해서 서버 측의 데이터에 변화가 있어서는 안 된다. 이를 Safe Method라고 분류한다. 또한, GET, HEAD, PUT, DELETE는 동일한 요청이 한 번 전송되었을 때와 여러 번 연속하여 전송되었을 때의 서버 측의 처리 결과가 동일해야 한다. 이를 Idempotent Method라고 분류한다.

5.2. 응답 코드

파일:상세 내용 아이콘.svg   자세한 내용은 HTTP/응답 코드 문서
번 문단을
부분을
참고하십시오.

6. HTTPS와의 차이점

HTTPS로 연결하면 전송 내용이 암호화되어 전달된다. 2021년 1월부터 크롬 브라우저에서는 HTTPS 연결이 아닐 경우 주소창 앞에 'Not Secure' 또는 '주의 요함'이라는 경고 메시지를 표시한다. 모바일로 접속할 경우, 위험 표시가 표시된다. HTTPS로 접속하면 잠금 아이콘이 뜬다.

HTTPS가 사용되지 않았을 경우, 비밀번호 신용카드 번호 등의 정보가 도용될 수 있다. 한국의 경우, 인터넷 결제나 인터넷 뱅킹 등의 개인 정보 입력이 필요한 사이트에서는 법적으로 반드시 HTTPS를 사용해야 한다.

프로그레시브 웹 앱을 만들 때, 일반적으로는 HTTP로는 연결할 수 없다.[1] HTTP를 쓰려면 따로 플래그를 선언해야 하며, 그나마도 이 상태로 구글 플레이 App Store, Galaxy Store, 원스토어에 올리면 높은 확률로 반려된다.

여담으로, 토르 브라우저 네트워크 사이트들은 운영진이 SSL 발급을 하지 않거나[2]Tor 자체적으로 end-to-end encryption 기능을 지원하기 때문에 대부분 HTTP를 사용한다.
[1] 아예 오류 화면이 뜬다. [2] 이는 대부분 사이트에서 불법적인 서비스를 제공하기에, SSL 발급 신청을 못 하는 경우가 많다.

분류