간단한 프로토콜 HTTP

Created: 2022년 3월 7일 오후 9:54

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

• 클라이언트 : 리소스가 필요하다고 요구하는 쪽
  • 텍스트, 이미지등
• 서버 : 리소스를 제공하는 쪽

http는 클라이언트와 서버의 역할을 명확하게 구별하고 있습니다.

request와 response를 교환하여 성립

클라이언트로부터 리퀘스트가 송신되며, 그 결과가 서버로 부터 리스폰스로 되돌아옴.

반드시 클라이언트 측으로부터 통신이 시작됨 → 서버측은 리퀘스트를 받지 않고서는 리스톤스를 송신하는 일은 없음

• 리퀘스트 예시

GET /index.html HTTP /1.1
Host: www.naver.com

• GET : http 메소드
• “/index.html” : 리소스 uri
• HTTP /1.1: http 버전

http 리퀘스트 구성

• 메소드
• URI
• 프로토콜 버전
• 옵션
• 리퀘스트 헤더 필드
• 엔티티
• 리스폰스 예시

HTTP /1.1 200 OK                      //버전, 상태코드
Date: Tue, 19 May 2021 01:20:12 GMT   //헤더필드
Content-Lenth: 362
Content-Type: text/html

//body
<htm>
...

http 리스폰스 구성

• 프로토콜 버전
• 상태코드, 상태코드에 따른 프레이즈
• 옵션
• 리스폰스 헤더필드
• 바디

---

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

• http는 상태를 계속 유지하지 않는 스테이트리스 프로토콜입니다.
  • stateless의 장점
    • 서버의 CPU나 메모리같은 리소스의 소비를 억제할 수 있음
    • 단순한 프로토콜이기 때문에 다양한 곳에서 이용 됨
• 리퀘스트와 리스폰스를 교환하는 동안에 상태(Stateless)를 관리하지 않습니다.
  • 이게 무슨 뜻??
  • → 이전에 보냇떤 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.

1. 새로운 리퀘스트가 보내질 때 마다 새로운 리스폰스가 생성됨
   1. 프로토콜로써는 과거의 리퀘스트나 리스폰스 정보를 전혀 가지고 있지 않음
   2. 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성을 확보하기 위해서 간단히 설계돼있음

1. 하지만 이는 웹이 진화 되면서 스테이트리스 특성만으로는 처리하기 어려운 일이 증가하게 되었음
   1. 쇼핑물 로그인 → 다른 페이지로 이동하더라도 로그인 상태를 유지할 필요가 있음
   2. 누가 어떤 리퀘스트를 보냈는지를 파악하기 위해 상태를 유지할 필요가 있습니다.
2. 따라서 상태를 계속 유지하고 싶은 욕구에 부응하기 위해서 쿠키라는 기술이 도입됐음

리퀘스트 URI로 리소스를 식별

• http는 URI를 사용하여 인터넷 상의 리소스를 지정함.
• 클라이언트는 리소스를 호출할 때 마다 리퀘스트를 송신할 때에 리퀘스트 안에 URI를 포함해야함.
• ex ) js 에서 fetch api로 request 보내기

getMyCouponList: (memberNum) => {
    return fetch(`"http://localhost:4000/cp"/hav/${memberNum}`, {
      method: "get",
      headers: {
        "Content-type": "application/json",
      },
    });
  },

HTTP메소드

GET

• 리소스 획득
• 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구함

POST

• 엔티티를 전송
• 데이터의 처리한 결과를 리스폰스로 줌

PUT

• 파일 전송
• FTP에 의한 파일 업로드와 같이, 리퀘스트 중에 포함된 엔티티를 리퀘스트를 URI로 지정한 곳에 보존하도록 요구
• REST와 같이 웹끼리 연계하는 설계 양식을 사용할 때 이용하는 경우가 있음

HEAD

• HEAD메소드를 GET같은 기능이지만 메시지 바디는 돌려주지 않음
• URI 유효성, 리소스 갱신시간을 확인하는 목적

DELETE

• 파일을 삭제하기 위해서 사용됨
• URI로 지정된 리소스의 삭제를 요구함

OPTIONS

• 제공하고 있는 메소드 문의
• 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용됨

TRACE

• 경로 조사
• Web서버에서 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킴
• 보통 사용되고 있지 않음.

CONNET

• 프록시에 터널 접속 확립을 요합으러써, TCP 통신을 터널링 시키기 위해서 사용
• SSL TLS등의 프로토콜로 터널링 시키기 위해서 사용되고 있음

지속 연결로 접속량을 절약

• http 초기버전에서는 http통신을 할 번 할 때마다 TCP에 의해 연결과종료를 할 필요가 있었습니다. → 초기 당시 통신에는 작은 사이즈의 텍스트를 보내는 정도 였기 때문에 이렇게 기능을 구현해도 아무문제는 없었음
• http가 널리 보급되어감에 따라 다량의 이미지를 포함한 문서등이 늘어났습니다. → 지속연결이라는 방법을 고안함.

지속연결의 장점

1. tcp 커넥션의 연결과 종료를 반복되는 오버헤드를 줄여주기 때문에 서버에 대한 부하가 경감됨
2. 부하를 줄인 만큼 http 리퀘스트와 리스폰스가 빠르게 완료되기때문에 웹페이지를 빨리 표시 할 수 있음

파이프 라인화

컴퓨터의 중앙 처리 장치에 여러 개의 파이프라인을 설치하여, 각 파이프라인이 하나의 명령어를 수행하도록 함으로써 동시에 여러 개의 명령어를 실행시키는 방법.

• 지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 함.
• 리퀘스트 송신후에 리스폰스를 수신할때 까지 기다린 뒤에 리퀘스트를 발행하던것을 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있음.

쿠키를 사용한 상태관리

http에서 상태를 저장해놓지 않기 때문에 과거 상태를 근거로 해서 현재 리퀘스트를 처리한다는 것은 불가능함.

→ 인증이 필요한 웹페이지에서 상태 관리를 하지 않는다면 인증을 마친 상태를 잊어버린다.

→ 때문에 새로운 페이지로 이동할 때마다 재차 로그인 정보를 보내든지 리퀘스트마다 매개 변수나 추가 정보를 붙여서 로그인 상태를 관리해야 하는 상황이 발생함.

쿠키

• 쿠키는 서버에서 리스폰스로 보내진 Set-Cookie 라는 헤더 필드에 의해 쿠키를 클라이언트에 보존하게 됨
• 같은 서버로 리퀘스트를 보낼 때, 자동으로 쿠키 값을 넣어서 송신함.