sharingStorage

간단한 프로토콜 http 본문

CS지식

간단한 프로토콜 http

Anstrengung 2023. 11. 8. 09:34

이 글은 그림으로 배우는 HTTP & Network를 읽고 참고한 것과 추가로 공부해본 것들로 작성되었습니다.

 

HTTP는 클라이언트와 서버 간에 통신을 한다

TCP/IP에 있는 다른 많은 프로토콜과 마찬가지로 HTTP도 클라이언트와 서버간에 통신을 합니다.

리소스가 필요하다고 요구하는 쪽을 클라이언트, 리소스를 제공하는 쪽이 서버가 됩니다.

HTTP 통신의 경우 반드시 어느 한쪽은 클라이언트, 다른 한쪽은 서버가 됩니다.

리퀘스트와 리스폰스를 교환

HTTP는 클라이언트로부터 Request가 송신되며 그 결과가 서버의 Response(리스폰스)로 되돌아옵니다.

반드시 클라이언트로 부터 통신이 시작되고

Request

리퀘스트 메세지는 메소드, URI, 프로토콜 버전, 옵션 리퀘스트 헤더필드와 엔티티로 구성되어 있습니다.

HTTP /1.1 200 OK (프로토콜 버전 / 상태코드 / 상태코드 설명)
Date: Tue, 10 Jul 2012 ~~ (리스폰스 헤더필드)
Content-Length : 362
Content-Type : text/html

<html>  //body

첫 번째 줄을 보면 HTTP /1.1 부분은 서버의 버전을 200 OK 부분은 리퀘스트 처리 결과를 나타내는 상태 코드와 설명입니다.

둘 째줄은 리스폰스가 발생한 일시를 나타내고 헤더필드라고 불리는 것 중 하나입니다.

그 후 빈줄로 구분하는데 아래부분은 body입니다.

HTTP는 상태를 유지하지 않는 프로토콜

HTTP는 상태를 계속 유지하지 않는 stateless 프로토콜입니다. HTTP프로토콜 독자적으로 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다. 결국 HTTP프로토콜 레벨에서 이전에 보냈던 리퀘스트나 이전 리스폰스에 대해서는 전혀 기억하지 못합니다.

이는 많은 데이터를 빠르고 확실하게 처리하는 범위성을 확보하기 위해서입니다.

하지만 웹이 진화함에 따라 스테이트리스 특성만으로 처리하기 어려운 로직들이 생겼고 이 때문에 쿠키 라는 기술이 도입되었습니다. 이 쿠키로 인해 HTTP를 이용한 통신에서도 상태를 계속 관리할 수 있습니다.

리퀘스트 URI로 리소스 식별

HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정합니다

클라이언트는 리소스를 호출할 때 마다 리퀘스트 내부에 URI를 리퀘스트 URI라고 불리는 형식으로 포함해야할 필요가 있습니다.

Request URI

  1. 모든 URI를 리퀘스트 URI에 포함한다.
GET http://hackr.jp/index.html HTTP/1.1

 

 

    2. Host 헤더 필드에 네트워크 로케이션을 포함한다.

GET /index.html HTTP/1.1
Host: hackr.jp

서버에 임무를 부여하는 HTTP 메서드 종류

GET : 리소스 획득

리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구합니다.

가져올 리소스 내용은 리소스를 서버가 해석한 결과입니다.

POST : 엔티티 전송

POST 메소드는 엔티티를 전송하기 위해 사용됩니다.

response : 데이터 처리결과

캐시 가능 / 멱등성 없음 / 안전

서버에서 새 데이터를 생성할 때 사용됩니다. 멱등성이 아니기 때문에 동일한 요청이 여러번 전송되지 않도록 하는 것이 중요합니다.

PUT : 파일 전송

파일 전송을 위해 사용됩니다. FTP에 의한 파일 업로드와 같이, 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구합니다.

PUT 자체에는 인증 기능이 없어 누구든지 파일을 업로드 가능하다는 보안상 문제점이 있습니다

→ 해결방법 : REST와 같이 웹끼리 연계하는 설계 방식이나 웹 애플리케이션 기능과 짝을 이루어 사용됩니다.

response: 상태코드 204 No Content 리스폰스를 되돌려준다.

PUT서버의 기존 데이터를 업데이트하거나 교체할 때 가장 잘 사용됩니다. 멱등성이라는 이점을 가지고 있어서 요청이 실패하면 동일한 요청을 다시 보내 같은 동일한 결과를 얻을 수 있습니다. 네트워크가 불안정하거나 클라이언트가 다른 이유로 요청을 다시 시도해야하는 경우 유용합니다.

PUT vs POST

짧게 말해서 POST메소드는 Request URI에 의해 식별된 자원의 종속성 또는 child를 만들기 위해서 사용되어야만 합니다.

  • PUT메소드의 URI는 포함된 엔티티를 처리할 리소스를 식별
  • POST메소드의 URI는 request에 포함된 엔티티를 식별

멱등성

멱등성이란 초기 적용 이후 결과를 변경하지 않고 여러번 적용할 수 있는 것입니다.

PUT: 동일한 데이터를 서버에 여러 번 보내면 항상 동일한 리소스가 업데이트되기 때문에 멱등성 방법입니다 . 즉, PUT요청을 보냈는데 실패하는 경우 동일한 요청을 다시 보내면 여전히 동일한 효과를 얻을 수 있습니다.

POST, 반면에 멱등성이 아닙니다 . 동일한 데이터를 서버에 여러 번 보내면 여러 리소스가 생성될 수 있습니다. 예를 들어, 양식을 여러 번 제출하면 데이터베이스에 여러 레코드가 남게 될 수 있습니다.

안전

HTTP 메서드는 서버 상태를 수정하지 않으면 안전하다고 합니다. 안전한 요청은 서버의 어떤 것도 변경되어서는 안됩니다.

PUT은 서버의 상태를 수정하기 때문에 안전한 방법이 아닙니다. 요청을 보내면 서버의 기존 데이터가 업데이트 되거나 대체됩니다.

반면 POST는 서서 상태를 수정하지 않기 때문에 안전합니다. POST요청을 보내면 서버에 새 데이터가 생성되지만 기존 데이터는 수정되지 않습니다.

캐시가능성

특정 캐시 제어 헤더가 포함된 경우 HTTP응답은 클라이언트 또는 프록시 서버에 캐싱될 수 있습니다.

PUT은 서버에 기존 데이터를 수정하는데 자주 사용되기 때문에 일반적으로 캐시할 수 없습니다. 클라이언트나 프록시 서버가 요청을 캐시하면 이전 데이터를 불러오는 등 문제를 야기할 수 있습니다.

POST는 새로운 데이터를 만들기 때문에 캐싱이 가능합니다.

HEAD : 메세지 헤더 취득

GET과 같은 기능이지만 메세지 바디는 돌려주지 않고 URI 유효성과 리소스 갱신시간을 확인하는 목적 등으로 사용됩니다

response: index.html에 대한 리스폰스 헤더

DELETE : 파일 삭제

파일을 삭제하기 위해 사용되는 메소드입니다.

PUT메소드와는 반대로 동작하며 리퀘스트 URI로 지정된 리소스의 삭제를 요구합니다.

PUT과 마찬가지로 인증기능이 없어 연계 설계 방식이 필요합니다.

response : 상태코드 204 No Content를 되돌려준다.

OPTIONS : 제공하고 있는 메소드 문의

request URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용됩니다.

response :

HTTP /1.1 200 OK
allow : GET, POST, HEAT ...(서버가 제공하고 있는 메소드 반환)

TRACE : 경로 조사

Web서버에 접속해서 자신에게 통신을 되돌려받는 루프백(loop-back)을 발생시킵니다.

request를 보낼 때 “Max-Forwards”라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때 마다 그 수치를 줄여갑니다. 최종적으로 리퀘스트를 수신한 곳에서 상태콛 200 OK 를 반환합니다.

클라이언트에선 TRACE메소드를 사용함으로써 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 조사 가능합니다.

TRACE 는 프록시 등을 중계하여 오리진 서버에 접속하여 그 동작을 확인하기 위해 사용되는데 현재는 XST(크로스 사이트 트레이싱) 같은 공격에 대한 보안이 취약하기 때문에 사용되고 있지 않습니다

메소드를 사용해서 지시내리기

리퀘스트 URI로 지정한 리소스에 리퀘스트를 보내는 경우에는 메소드라고 불리는 명령이 있습니다.

메소드는 리소스에 대한 어떤 행동을 원하는지 지시하는 용도이며 대소문자를 구별하기 때문에 대문자로 기입합니다.

지연 연결로 접속량 절약

HTTP초기 버전에선 통신을 한 번할 때 마다 TCP에 의해 연결과 종료를 했어야만 합니다.

HTTP/1.1 과 일부 1.0에서는 TCP 연결 문제를 해결하기 위해 지속 연결 이라는 방법을 고안했습니다.

지속 연결은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP연결을 계속 해서 유지합니다.

지속 연결

TCP 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여줌 → 서버에 부하가 경감 → 리퀘스트와 리스폰스가 빠르게 완료 → 빠른 웹페이지 표시

파이프 라인화

지속 연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인 화 를 가능하게 합니다.

파이프 라인화로 인해 리퀘스트 송신 후 리스폰스 수신까지 기다릴 필요 없이 바로 다음 리퀘스트를 보낼 수 있습니다.

쿠키를 사용한 상태관리

HTTP는 스테이트리스 프로토콜이기 때문에 과거에 교환했던 리퀘스트와 리스폰스의 상태를 관리하지 않습니다.

이는 과거 상태를 근거로 한 현재 리퀘스트 처리는 어렵다는 것을 뜻합니다.

쿠키

이러한 스테이트리스로 인해 발생하는 문제를 해결하기 위해 도입된 시스템.

리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트 상태를 파악하기 위한 시스템

서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 쿠키를 클라이언트에 보존하고 다음 리퀘스트 요청에 자동으로 쿠키 값을 넣어서 송신

이로 인해 서버는 클라언트가 보낸 쿠키를 확인하여 어느 클라이언트가 접속했는지나 서버상의 기록을 확인할 수 있습니다.

저작자표시

'CS지식' 카테고리의 다른 글

HTTP와 연계하는 웹 서버  (0) 2023.11.07
결과를 전달하는 HTTP 상태코드  (0) 2023.11.06
HTTP와 웹 네트워크 기본  (0) 2023.10.22
[NVM] window 환경에서 node 버전 관리  (0) 2023.03.27
'CS지식' Related Articles more
Comments