#TIL_HTTP와 HTTP메소드에 대한 고찰

# HTTP란?

요청(Request)과 응답(Response)을 통해 클라이언트와 서버의 역할을 명확하게 구별합니다.

HTTP(Hypertext Transfer Protocol)는 월드 와이드 웹(World Wide Web)에서 데이터를 전송하기 위한 프로토콜(규약) 중 하나로, 클라이언트와 서버 간의 통신을 담당합니다. HTTP는 주로 문서, 이미지, 스크립트, 스타일 시트, 비디오, 오디로 및 기타 멀티미디어 요소와 같은 웹 리소스를 전달하는데 사용합니다. 

 

---

#HTTP의 주요 특징과 동작 방식

1. 프로토콜(Protocol)

HTTP는 통신을 위한 규약 또는 프로토콜입니다. 클라이언트와 서버 간의 데이터 교환을 원활하게 하기 위한 규칙과 규정을 정의하고 있습니다. 

2. 클라이언트-서버 모델

HTTP는 클라이언트(웹 브라우저, 애플리케이션 등)와 서버(웹 서버) 간의 상호작용 모델을 사용합니다. 클라이언트는 서버에 요청을 보내고, 서버는 해당 요청에 대한 응답을 반환합니다. 

3. Stateless(무상태)프로토콜

HTTP는 무상태 프로토콜로, 각 요청 간에 이전 요청의 상태를 유지하지 않습니다. 이전 요청과의 연관성을 유지하지 않기 때문에 모든 요청은 독립적으로 처리됩니다. 이는 서버에 대한 부담을 줄이는 장점이 있지만, 클라이언트의 상태 관리에 관한 추가 논리가 필요할 때가 있습니다. 

4. TCP 기반

HTTP는 일반적으로 TCP/IP 프로토콜 스택 위에서 작동합니다. TCP는 연결 지향적이며, 신뢰성 있는 데이터를 전송합니다. 

5.요청-응답 모델

 HTTP는 클라이언트와 서버 간의요청(request)와 응답(response) 모델을 따릅니다. 클라이언트는 서버에 요청을 보내고, 서버는 그에 대한 응답을 반환합니다. 요청과 응답은 메세지의 형태로 전송됩니다.

6. 메소드(Method)

HTTP 요청은 메소드를 사용하여 요청의 목적을 지정합니다. 일반적인 HTTP 메소드로는 GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS 등이 있으며, 각 메소드는 서버에게 요청된 동작을 알려줍니다. 예를 들어, GET은 데이터를 가져오는 데 사용되고, POST는 데이터를 제출하는 데 사용됩니다.

7. 헤더(Headers)

HTTP 요청 및 응답은 헤더를 사용하여 부가 정보를 제공합니다. 헤더는 요청 또는 응답의 메타데이터를 포함하며, 예를 들어 캐시 제어, 콘텐츠 유형, 인증 정보 등을 담을 수 있습니다.

8. 상태 코드(Status Code)

HTTP 응답은 상태 코드를 반환하여 요청의 결과를 나타냅니다. 상태 코드는 요청의 성공, 리다이렉션, 클라이언트 또는 서버 오류 등을 표현하며, 클라이언트는 이 코드를 통해 요청이 성공했는지 또는 어떤 문제가 발생했는지를 파악할 수 있습니다.

 

HTTP는 웹 브라우징, 웹 애플리케이션 개발, 웹 서비스, RESTful API 및 데이터 교환과 같은 웹 기반 활동에서 중요한 역할을 하며, 웹의 기본 통신 프로토콜로 사용됩니다. 이를 통해 클라이언트와 서버 간의 데이터 통신이 가능하게 되어 웹에서 정보와 리소스를 공유하고 상호작용할 수 있습니다.

 

---

# HTTP 프로토콜의 장점과 단점

 

***장점

1. 불특정 다수를 대상으로 하는 서비스에 적합합니다: HTTP는 웹의 본질적인 프로토콜로서, 웹 페이지를 요청하고 전송하는 데 효과적입니다. 이는 많은 사용자가 동시에 웹 페이지를 요청하는 웹 서비스에 이상적입니다.

 

2. 상태가 없는(stateless) 프로토콜이기 때문에 연결을 끊어버리는 장점: HTTP는 각 요청 및 응답 사이에 상태 정보를 유지하지 않고 연결을 끊는 "상태가 없는" 프로토콜입니다. 이것은 서버에 대한 부담을 줄여주며, 동시에 빠른 요청 및 응답 처리를 가능케 합니다. 클라이언트가 서버에게 요청을 보내고, 서버는 요청을 처리하고 응답을 반환한 다음 연결을 끊어버립니다. 이로써 더 많은 유저의 요청을 처리할 수 있습니다.

 

***단점

1. 상태가 없는(stateless) 프로토콜로 인한 클라이언트 이전 상태 파악 어려움: HTTP는 상태 정보를 유지하지 않기 때문에 클라이언트의 이전 상태를 알 수 없습니다. 즉, 클라이언트가 과거에 로그인을 성공했다고 해도, 이전 요청과 관련된 상태 정보를 서버가 유지하지 않습니다.

 

2. 쿠키를 사용한 상태 관리의 보안 및 개인 정보 보호 이슈: HTTP는 이러한 상태 관리 문제를 해결하기 위해 쿠키(cookie)를 사용합니다. 쿠키는 클라이언트와 서버 간의 상태 정보를 유지하고 전달하는데 사용됩니다. 그러나 쿠키는 보안 및 개인 정보 보호와 관련된 여러 문제를 야기할 수 있습니다. 클라이언트의 개인 정보가 쿠키에 저장되면 보안 위험에 노출될 수 있고, 사용자의 동의없이 추적 정보를 수집하는 데 사용될 수 있습니다.

 

***쿠키(cookie)

클라이언트와 서버의 상태 정보를 담고 있는 정보조각입니다. 로그인을 예로 들자면, 클라이언트가 로그인에 성공하면 서버는 로그인 정보를 자신의 DB에 저장하고 동일한 값을 cookie 형태로 클라이언트에 전송합니다. 이를 통해 클라이언트의 상태 정보를 유지하고 다음 요청에서 활용할 수 있습니다.

 

 

 

---

# HTTP 메소드

HTTP 메소드는 클라이언트가 서버에게 수행하길 원하는 동작을 지정합니다.  

 

1. GET_리소스 획득

 

1) GET 메소드는 클라이언트가 Request URL로 식별된 리소스(웹 페이지, 이미지, 텍스트 등)를 서버로부터 요청하고 가져오는 데 사용됩니다. 이 메소드는 주로 웹 서버에 엑세스하여 웹 페이지나 데이터를 읽을 때 사용됩니다.

 

2) 클라이언트가 GET 요청을 보내면 서버는 해당 리소스를 찾아서 클라이언트에게 반환합니다. 반환된 내용은 Request URL로 지정한 리소스를 서버가 해석한 결과입니다. 이 메소드는 서버에 부작용을 주지 않고, 요청한 리소스를 가져옵니다. GET 메소드는 웹 브라우저에서 웹 페이지를 로드하거나 검색 엔진에서 웹 페이지 검색 결과를 표시하는 데 널리 사용됩니다.

 

2. POST_엔티티 전송

1) POST 메소드는 클라이언트가 서버로 데이터를 제출하며, 주로 양식 데이터를 제출하거나 새로운 리소스를 생성하는 데 사용됩니다. GET 메소드를 사용하여 엔티티(데이터)를 전송할 수도 있지만, 일반적으로 POST를 사용합니다. POST 메소드는 GET과 유사한 기능을 수행할 수 있지만, 그 목적은 응답을 획득하는 것 뿐만 아니라 데이터를 서버로 제출하는 데 있습니다.

 

2) POST 메소드는 웹 폼(웹 페이지에서 입력 필드로 구성된 양식)에 입력한 데이터를 서버로 송신하는 데 사용됩니다. 이 데이터는 폼의 입력 필드에 사용자가 입력한 값입니다. 예를 들어, 인터넷 쇼핑 카트에 상품을 추가하거나 웹 사이트 회원가입 양식을 작성할 때 POST 메소드가 사용됩니다.

 

3) POST 요청 메시지에는 클라이언트가 서버로 전송하려는 데이터가 포함되며, 이 데이터는 일반적으로 폼 필드의 이름-값 쌍 형태로 전달됩니다. 서버는 이 데이터를 처리하고 새로운 리소스를 생성하거나 기존 리소스를 업데이트하는 데 사용할 수 있습니다. 이러한 데이터를 서버에게 제출하면, 서버 측 애플리케이션은 이를 처리하고 응답을 생성하여 클라이언트에게 반환합니다.

 

3. PUT_지정된 URL에 리소스를 업로드하거나 갱신

1) PUT 메소드는 지정된 URL에 리소스를 업로드하거나 갱신하기 위해 사용됩니다. 이 메소드를 통해 파일을 전송할 수 있으며, 이 파일은 요청 중에 포함된 엔티티로 구성됩니다. PUT 메소드는 이 엔티티를 Request URI로 지정한 위치에 보존하도록 요청합니다. 만약 URI로 지정한 파일이 존재하지 않는 경우, 새로운 파일을 작성합니다.

 

2) HTTP/1.1 PUT 메소드는 기본적으로 인증 기능을 포함하지 않아 누구나 파일을 업로드할 수 있다는 보안적인 이슈가 있어, 이로 인해 일반적인 웹사이트에서는 사용되지 않는 경우가 많습니다. 그러나 웹 애플리케이션에서 인증 기능과 함께 사용하거나 REST와 같이 웹 간의 연계를 위한 설계 양식을 사용할 때 PUT 메소드가 유용하게 활용될 수 있습니다.

 

4. DELETE_지정된 URL에 있는 리소스를 삭제

1) DELETE 메소드는 지정된 URL에 있는 리소스를 삭제하는 데 사용됩니다. 이 메소드를 통해 Request URI로 지정한 리소스의 삭제를 요청합니다. DELETE 메소드는 파일을 삭제하기 위해 주로 활용되며, 해당 리소스의 삭제를 서버에 요청합니다.

 

2) HTTP/1.1의 DELETE 메소드는 PUT 메소드와 마찬가지로 자체적으로 인증 기능을 포함하지 않아 누구나 해당 리소스를 삭제할 수 있다는 보안적인 문제가 있습니다. 이로 인해 일반적인 웹 사이트에서는 DELETE 메소드가 사용되지 않는 경우가 많습니다. DELETE 메소드가 활용되는 상황은 PUT 메소드와 유사합니다.

 

5. PATCH_리소스의 부분 업데이트를 수행하며, 전체 리소스를 업데이트하는 PUT과는 달리 일부만 변경

1) PATCH 메소드는 리소스의 일부를 업데이트하기 위해 사용됩니다. PUT 메소드와는 달리 리소스 전체를 교체하는 것이 아니라 리소스의 특정 부분만 변경할 수 있습니다. 요청 문서에는 업데이트하려는 리터럴 특성을 지정하여 업데이트할 수 있습니다. 이는 리소스의 일부 정보를 수정하거나 교체하는 데 유용하며, 리소스의 전체 교체가 필요하지 않을 때 PATCH 메소드를 활용할 수 있습니다.

 

2) 또한, HEAD 메소드는 GET 메소드와 유사한 기능을 수행하지만 메시지 바디를 반환하지 않습니다. 대신에 URI의 유효성을 확인하거나 리소스의 갱신 시간을 파악하는 데 사용됩니다. 서버로부터 리소스의 정보를 요청하지만 실제 내용은 필요하지 않을 때 HEAD 메소드를 활용하여 효율적인 통신을 수행할 수 있습니다.

 

6. OPTIONS_지정된 리소스에서 사용 가능한 메소드 및 기타 옵션에 대한 정보를 요청

OPTIONS 메소드는 클라이언트가 지정된 리소스에서 사용 가능한 HTTP 메소드 및 기타 통신 옵션에 대한 정보를 요청하는 데 사용됩니다. 이 메소드를 통해 클라이언트는 해당 리소스가 어떤 HTTP 메소드를 지원하며 어떤 통신 옵션을 제공하는지 확인할 수 있습니다. OPTIONS 메소드는 클라이언트가 서버와의 상호작용에 사용 가능한 메소드 및 설정을 조사하고, 웹 서비스의 기능 및 통신 옵션을 파악할 때 유용하게 활용됩니다.

 

7. CONNECT_목적지 서버로 프락시 연결을 설정

CONNECT 메소드는 프록시 서버와 목적지 서버 간에 터널 연결을 설정하는 데 사용됩니다. 이 메소드는 주로 SSL 및 TLS와 같은 프로토콜을 통해 암호화된 데이터를 프록시 서버를 통해 전송할 때 사용됩니다. CONNECT 메소드를 통해 암호화된 메시지를 프록시로 전송하고 목적지 서버로 터널을 설정하여 안전하게 통신할 수 있습니다. 이 메소드는 데이터를 안전하게 전송하는 데 사용되며, 주로 보안 요구 사항을 충족시키기 위해 활용됩니다.

 

8. TRACE_목적지 서버로 요청이 전달되는 경로를 따라서 디버깅 목적으로 사용

1) TRACE 메소드는 HTTP 요청을 디버깅하고 경로를 추적하기 위한 목적으로 사용됩니다. TRACE 요청을 보낼 때에 "Max-Forwards"라는 헤더 필드에 수치를 포함하여 서버를 통과할 때마다 그 수치를 줄여갑니다. 이 수치가 0이 되는 지점이 TRACE 요청의 끝으로, 요청이 마지막으로 수신된 곳에서 상태 코드 "200 OK" 응답을 반환합니다. 이를 통해 클라이언트는 요청이 서버로 전달되는 경로를 확인할 수 있습니다.

 

2) TRACE 메소드는 주로 프록시 서버와 같은 중간 서버를 경유하는 경우 요청 내용이 가공되는지 여부를 조사하거나, 요청이 어떻게 라우팅되는지 디버깅할 때 사용됩니다. 그러나 TRACE 메소드는 크로스 사이트 트레이싱(XST)과 같은 보안 문제를 유발할 수 있으므로, 일반적으로 보안 상의 이유로 사용을 지양하는 경향이 있습니다.

 

3) 프록시는 클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템 또는 응용 프로그램을 가리킵니다. 프록시 서버는 클라이언트와 서버 간의 중계 역할을 하며, 대리로 통신을 수행합니다. 이를 통해 클라이언트의 익명성을 유지하거나, 캐싱, 보안 등 다양한 목적으로 사용됩니다.

 

HTTP 메소드는 요청 헤더에 포함되어 서버에게 클라이언트의 의도를 알리며, 서버는 해당 메소드에 따라 적절한 응답을 반환합니다. 이를 통해 클라이언트와 서버 간의 효과적인 통신이 이루어집니다.

 

GET	리소스 취득
POST	엔티티 바디 전송
PUT	파일 전송
HEAD	메세지 헤더 취득
DELETE	파일 삭제
OPTIONS	서포트하고 있는 메소드 문의
TRACE	경로 조사
CONNECT	프록시에 터널링 요구

---

# HTTP 상태 코드

(HTTP Status Code)는 클라이언트가 서버로부터 받은 응답의 성격을 나타내는 코드입니다. 이 코드는 HTTP 통신에서 다양한 상황을 식별하고 처리하기 위해 사용됩니다. 주요 HTTP 상태 코드는 다음과 같습니다:

 

2XX - 성공: 200번대의 상태 코드는 주로 성공을 나타냅니다.

 

200: GET 요청에 대한 성공

 

204: No Content. 성공했으나 응답 본문에 데이터가 없음

 

205: Reset Content. 성공했으나 클라이언트의 화면을 새로 고침하도록 권고

 

206: Partial Content. 성공했으나 일부 범위의 데이터만 반환

 

3XX - 리다이렉션: 300번대의 상태 코드는 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우입니다.

 

301: Moved Permanently, 요청한 자원이 새 URL에 존재

 

303: See Other, 요청한 자원이 임시 주소에 존재

 

304: Not Modified, 요청한 자원이 변경되지 않았으므로 클라이언트에서 캐싱된 자원을 사용하도록 권고. ETag와 같은 정보를 활용하여 변경 여부를 확인

 

4XX - 클라이언트 에러: 400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우입니다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생합니다.

 

400: Bad Request, 잘못된 요청

 

401: Unauthorized, 권한 없이 요청. Authorization 헤더가 잘못된 경우

 

403: Forbidden, 서버에서 해당 자원에 대해 접근 금지

 

404: Not Found, 서버에서 요청받은 리소스를 찾을 수 없습니다. (브라우저에 알려지지 않은 URL로 요청한 경우)

 

405: Method Not Allowed, 허용되지 않은 요청 메서드

 

409: Conflict, 최신 자원이 아닌데 업데이트하는 경우. ex) 파일 업로드 시 버전 충돌

 

5XX - 서버 에러: 500번대 상태 코드는 서버 쪽에서 오류난 경우입니다.

 

500: Internal Server Error, 웹 사이트 서버에 문제가 있음을 의미하며 서버는 정확한 문제에 대해 구체적 설명을 할 수 없는 경우

 

501: Not Implemented, 요청한 동작에 대해 서버가 수행할 수 없는 경우

 

502: Bad Gateway, 서버가 게이트웨이로부터 잘못된 응답을 수신했을음 의미하며 인터넷상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우

 

503: Service Unavailable, 서버가 과부하 또는 유지 보수로 내려간 경우

 

504: Gateway Timeout, 웹 페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못한 경우