HTTP 란? (HTTP 특징 / HTTP 요청과 응답)

 

1. HTTP (HyperText Transfer Protocol) 개념과 특징

HTTP 요청 (출처: https://dev.classmethod.jp/articles/about-http/)

• HTTP란 Hyper Text Transfer Protocol의 약자로, World Wide Web(WWW, 웹) 상에서 데이터를 주고받기 위한 프로토콜이다
• HTTP는 클라이언트(보통 웹 브라우저)와 서버 간의 요청(request)과 응답(response)을 통해 작동한다
• HTTP는 다양한 종류의 데이터(html, css, javaScript, png, gif, mp4)를 전송할 수 있도록 설계된 프로토콜이다.
• 웹 페이지에 포함된 각 구성 요소(이미지, 텍스트, HTML, 영상 등)는 대부분 개별적인 HTTP 요청을 통해 서버로부터 요청된다. 따라서 가끔 글이 먼저 보이고 이미지가 나중에 보일때가 있는 것이다.
• 일반적으로 TCP/IP 통신 프로토콜 기반으로 동작한다.
• HTTP를 통해 전달되는 자료는 http:로 시작하는 URL(인터넷 주소)로 조회할 수 있으며, 사용하는 포트는 80번이다.
• 상태가 없는(stateless) 프로토콜: 데이터를 주고받기 위해 행해지는 각각의 데이터 요청이 서로 독립적으로 관리된다는 뜻, 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 것.
• 단방향성: 하나의 요청에 하나의 응답을 하는 방식으로 동작

 

 

2. HTTP 의 단점

• HTTP는 데이터를 평문(사람이 알아볼 수 있는 정보)으로 전송해 도청 및 데이터 변조의 위험이 있다.
• 중간에서 패킷을 가로채어 내용을 엿볼 수 있고, 필요에 따라 수정할 수도 있기에 보안에 취약하.
• 이를 보안하기 위해 나온 것이 HTTPS(Hypertext Transfer Protocol Secure)다.
• HTTPS: HTTP에 SSL(Secure Socket Layer)/TLS(Transport Layer Security)프로토콜을 통해 세션 데이터가 암호화된 상태로 전송된다.

 

 

3. HTTP 흐름

구글 웹사이트에 접근하고 싶다고 가정해보자. 구글 웹사이트가 내 화면에 표시되기 위해서는 다음 단계의 과정들이 수행되는 것이다.

 

TCP, HTTP

1). 사용자가 웹 브라우저의 주소 창에 https://www.google.com을 입력한다.

2). 브라우저는 입력된 도메인 이름(www.google.com)을 IP 주소로 변환하기 위해 DNS(Domain Name System) 서버에 요청을 보낸다. DNS 서버는 해당 도메인의 IP 주소로 응답한다.

3). 브라우저는 받은 IP 주소를 통해 구글 서버와 TCP 연결을 설정한다.

HTTP 요청

4). TCP 연결이 설정되면, 브라우저는 HTTP 요청 메세지를 구글 서버에 보낸다.

* GET은 정보를 요청하기 위해 사용되는 메서드다.

HTTP 응답

5). 서버가 요청을 처리하고 HTTP 응답을 전송한다.

6). 브라우저가 응답을 받아 화면에 구글 웹 사이트를 표시한다.

(브라우저는 수신한 HTML, CSS, JavaScript 등의 리소스를 해석하여 사용자의 화면에 구글 홈페이지를 표시하는 것)

* 200은 HTTP 상태 코드로  GET 요청에 대한 성공 나타낸다.

 

 

4. HTTP 요청 메서드

: 클라이언트가 서버에 요청을 보낼 때 사용되는 명령어

 

①  GET: 정보를 요청하기 위해 사용 (조회)

② HEAD: GET 요청과 동일하지만, 응답 바디를 제외한 헤더 정보만을 요청

- 웹 서버 정보확인, 버젼확인, 최종 수정일자 확인 등의 용도로 사용된다.

③ POST: 서버에 데이터를 전송(추가)할 때 사용 (등록)

④ PUT: 정보를 업데이트(갱신)하기 위해 사용, 정보 변경 (수정)

⑤ DELETE: 정보를 삭제하기 위해 사용 (삭제)

⑥ OPTIONS: 서버에서 지원하는 HTTP 메서드의 목록을 요청할 때 사용

⑦ PATCH: 리소스의 일부분을 수정

⑧CONNECT: 프록시 동작의 터널 접속을 변경

 

 

가장 대표적인 4개의 메서드에 대해서 조금 더 알아보자.

 

❶  GET

GET 메서드는 주로 데이터를 조회하거나(Read) 검색(Retrieve)할 때에 사용되는 메서드다. GET요청이 성공적으로 이루어지면 서버는 XML, JSON, HTML 등의 형태로 데이터를 반환한다. (이때 200 (OK) HTTP 응답 코드를 리턴) 주로 404 (Not Found) 또는 400 (Bad Request) 에러가 발생한다.

• 데이터 읽기 전용: HTTP 명세에 따르면 GET 요청은 오로지 데이터를 읽을 때만 사용되어야 하며, 서버의 데이터를 수정(변경)하는 데 사용되어서는 안 된다.
• 멱등성(idempotent): GET 요청은 멱등성을 가진다. 이는 동일한 GET 요청을 여러 번 수행하더라도 서버의 상태가 변하지 않으며, 항상 동일한 응답을 받는다는 것을 의미한다.

GET /resource HTTP/1.1
Host: www.example.com

• 요청 본문 ❌: 본문(Body)를 가지고 있지 않아 Content-Type도 필요하지 않다.
• 조회할 데이터에 대한 정보는 URL의 쿼리 파라미터로 전달된다.
• 데이터 조회에 성공하면 응답 본문에 데이터를 포함하여 성공 응답을 보낸다. (이 때 데이터 값 저장)
• 캐싱 가능: GET 요청은 캐싱이 가능하다. 동일한 데이터를 다시 조회할 경우, 캐시된 데이터를 사용하여 조회 속도를 높일 수 있다.

 

❷ POST

POST 메서드는 주로 새로운 리소스를 생성할 때 사용되는 HTTP 메서드다. 구체적으로, POST는 부모 리소스의 하위 리소스를 생성하는 데 사용됩니다. 성공적으로 리소스를 생성하면 201 (Created) HTTP 응답을 반환한다.

• 멱등성 ❌: 동일한 POST 요청을 여러 번 보내더라도 항상 같은 결과물을 보장하지 않는다.
• 예로, 동일한 POST 요청을 두 번 보낸다면 같은 정보를 담은 두 개의 다른 리소스가 생성될 가능성이 높다.

POST /user HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "date": "example"
}

• 요청 본문 ⭕: 요청 시 본문(Body)에 데이터를 포함하여 전송한다.
• 콘텐츠 유형: Content-Type 헤더를 사용하여 본문의 데이터 형식을 명시해야 한다. 위 예시는 JSON 형식 사용.
•  리소스가 성공적으로 생성되면 201 (Created) 응답 코드와 함께 생성된 리소스에 대한 정보를 반환한다.

 

❸ PUT

PUT 메서드는 리소스를 생성하거나 업데이트하기 위해 서버로 데이터를 보내는 데 사용된다.

• 멱등성 : PUT 요청은 멱등성을 가져, 동일한 PUT 요청을 여러 번 보내더라도 항상 동일한 결과가 생성된다.

PUT /user/1 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "date": "update example"
}

• 요청 본문 ⭕: 요청 시 본문(Body)에 데이터를 포함하여 전송한다.
• 콘텐츠 유형: Content-Type 헤더를 사용하여 본문의 데이터 형식을 명시해야 한다. 위 예시는 JSON 형식 사용.
• URL을 통해 어떤 리소스를 수정할지를 지정한다. 수정할 데이터 값은 Body에 포함된다.
• 데이터 조회에 성공하면 Body에 지정한 데이터를 포함하여 성공 응답을 보낸다.

 

❹ DELETE

DELETE 메서드는 지정된 리소스를 삭제하는 데 사용된다.

DELETE /user/1 HTTP/1.1
Host: www.example.com

• 요청 본문 ❌: 데이터를 삭제하는 요청이니 본문(Body)를 가지고 있지 않아 Content-Type도 필요하지 않다.
• URL을 통행 어떤 리소스를 삭제할지 지정한다.
• 데이터 삭제에 성공하면 Body 없이 성공응답(보통 200 OK 또는 204 No Content)을 보낸다.

 

 

5. HTTP 응답코드

HTTP 응답 코드 (출처: https://javaplant.tistory.com/18)

 

 

5. HTTP 버전

HTTP/1.0 이전의 연결

현재는 HTTP/2나 HTTP/1.1 버전을 사용하고 있지만 예전의 HTTP/1.0 버전에서는 위 그림과 같이 요청을 보낼 때마다 연결했다 끊는 작업을 반복했어야 했다.

 

그러나 HTTP/1.1 버전에는 keepalive라는 기능이 추가되었다.keepalive는 위 그림처럼 한 번 연결이 수립되면 데이터 교환을 마칠때까지 연결을 유지하고, 데이터 교환이 모두 끝내면 연결을 끊는 구조다. 하지만 keepalive도 요청을 순서대로 처리한다는 특징이 있어 위 그림처럼 ①의 요청에 대해 ①의 응답을 반환하고, 그 다음에 ②의 요청에 대한 ②의 응답을 반환하는 것이다. 그래서 이전 요청을 처리하는 데 시간이 길어질 경우, 다음 요청에 대한 처리가 늦어진다는 것이다. 그래서 나온 것이 HTTP/2 버전이다.

 

HTTP/2 버전은 요청에 순서대로 응답을 반환하지 않아도 된다.

 

 

 

 

 

참고

책: 10일만에 배우는 네트워크 기초, 모두의 네트워크 | 미즈구치 카츠야 | 이승룡 옮김

https://velog.io/@wnsdnjs70/HTTP%EB%9E%80

https://raonctf.com/essential/study/web/http

https://velog.io/@yh20studio/CS-Http-Method-%EB%9E%80-GET-POST-PUT-DELETE