HTTP

1. 개요2. 설명3. 역사4. 구조

4.1. 요청4.2. 응답

5. 메시지 종류

5.1. 요청5.2. 응답 코드

6. HTTPS와의 차이점

6.1. HTTP 의 단점

1. 개요[편집]

HyperText Transfer Protocol 또는 HyperTexT Protocol의 약자이다. 해석하면 문서를 전송하기위한 약속으로 해석된다.

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

TLS를 통한 보안이 적용된 버전은 HTTPS 참고.

참고로 http:// 표기는 월드 와이드 웹의 창시자인 팀 버너스리의 실수에서 비롯되었는데, 사실 2개의 빗금(Slash)는 필요가 없다! 즉, 굳이 빗금까지 입력할 필요는 없고 쌍점(:)까지만 써도 정상적으로 접속된다는 얘기.[1] 하지만 이 빗금 두 개는 나름대로 쓸모가 있는데, 일반 HTTP와 HTTPS 양쪽에 대응할 때 사용한다. ~~//가 없으면 :를 대신 쓰지 않을까~~

3. 역사[편집]

1996년에 첫 상용화 버전인 HTTP/1.0가 발표되었고, 1999년에 HTTP/1.1, 그리고 2015년 HTTP/2를 공식으로 발표하였다.

현재 HTTP/1.1을 대부분 사용 중이지만 구글 계열의 사이트는 HTTP/2와 HTTP/1.1을 동시에 지원하고 있고, 다른 국내외 사이트들도 점차적으로 HTTP/2로 바꾸는 추세다. HTTP/2는 HTTPS 연결에서만 작동하며, HTTP 연결일 경우에는 브라우저와 서버에서 HTTP/2를 지원하더라도 HTTP/1.1로 연결된다.

HTTP/2는 구글이 발표한 SPDY라는 기술을 기반으로 했는데, HTTP/3에도 구글이 발표한 QUIC의 기술이 적용되는 것으로 방향이 정해진 모양이다. HTTP/2까지는 TCP 연결을 기반으로 하는데, HTTP over QUIC(HTTP/3)은 UDP 연결을 기반으로 한다. 설명

4. 구조[편집]

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

4.1. 요청[편집]

GET /index.htm HTTP/1.1  -  헤더
Host: namu.com  -  호스트
- 공백 -

다음 요청 메시지는 namu.com의 index.htm을 보여달라는 요청이다. 서버는 이것을 받고 응답한다.

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. 응답 코드[편집]

응답코드별 고양이
응답코드별 강아지

6. HTTPS와의 차이점[편집]

사이트 주소가 HTTPS로 시작하면 비밀번호나 신용카드 번호 등의 정보는 비공개 상태로 해당 사이트에 접속된다.
나무위키도 HTTPS가 연결되어있다.~~하지만 나무위키는 신용카드나 전화번호 입력이 없으니 HTTPS는 필요없다.~~

HTTPS가 사용될 경우 잠금 아이콘이 뜬다.

HTTPS가 미사용될 경우 위험 표시가 뜬다.[2]

6.1. HTTP 의 단점[편집]

HTTPS가 사용되지 않았을 경우 비밀번호, 신용카드 번호 등의 정보가 도용 될 수 있다. 인터넷 결제 등 개인정보 입력이 필요한 사이트에서는 HTTPS미사용을 거의 볼 수가 없다.
영어교육 사이트에서는에서는 듣기(listening), 쓰기(writing)는 HTTPS를 사용하지 않아도 되지만, 말하기(speaking)에서는 HTTPS가 연결되어있어야 한다. 이는 말하기에서 HTTPS가 연결되어있어야 Speaking할때 쓰는 마이크가 제대로 작동하기 때문이다.

[1] 실제로 빗금 두개를 없애도 잘 동작된다.

[2] 모바일로 촬영한 사진이며, PC에서는 위험 표시 옆에 주의 요함이라는 표시도 함께 떠있다.