HTTP (HyperText Transfer Protocol)

TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송된다.
HTTP에도 버전이 존재하며 그중 대부분 HTTP/1.1 (TCP)을 사용한다. 현대에는 HTTP/2, HTTP/3 (UDP)의 사용량이 급속도로 증가하는 추세이다.

HTTP 동작 순서

• 클라이언트는 Request(요청)을 보내고, 응답을 기다린다.
• 서버는 요청에 대한 처리를 수행 후 결과를 Response(응답)한다.

HTTP 특징

HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 만약 서버에서 다수의 클라이언트와 상태나 연결을 계속 유지해야 한다면 이에 따른 많은 서버의 리소스가 필요하다.

1. 클라이언트와 서버 구조

• 기존에는 클라이언트, 서버가 구분되어있지 않았다.
  • 클라이언트는 UI(User Interface)에 중점을 두도록 만들었다.
  • 서버에서 데이터, 비지니스 로직을 담당하도록 만들었다.
• 결과적으로 클라이언트, 서버 각자 독립적으로 발전할 수 있게되었다.

2. 무상태 (Stateless)

• 서버는 클라이언트의 상태를 보존하지 않는다.

• 장점

  • Scale Out 수평 확장성이 높다.
  • 갑자기 요청량이 증가하여도 서버를 증설 하기 쉽다.

• 단점

  • 클라이언트가 데이터를 추가적으로 전송해야 한다.

• 한계점

  • 무상태로 설계할 수 없는 경우가 있다.
  • Cookie, Session, Token 등을 활용한다.

3. 비연결 (Connectionless)

• HTTP는 연결을 유지하지 않는 모델이다.
• 장점
  • 서버 자원을 효율적으로 사용할 수 있다.
• 단점
  • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다. → 요청에 대한 응답 시간이 증가한다.
    
  • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다. → 캐시, 브라우저 캐싱로 해결한다. 쉽게 말해 임시저장
    
  • 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결한다.

HTTP 지속연결(Persistent Connections)
하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.
연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.
→ 그만큼 속도가 빨라졌다.

HTTP Message 구조

HTTP Message는 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다르다.

HTTP 요청 메세지(Request Message)

1. Start Line

   • HTTP Method
     • GET
     • 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등이 있다.
       • Create - POST
       • Read - GET
       • Update - PUT(전체), PATCH(일부)
       • Delete - DELETE
       • Request Target
   • path

     • /event

     • HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로)

     • Query String(= Query Parameter) 에 해당하는 값도 포함한다.

       ex) /search?keyword=sparta

   • HTTP Version
     • 1.1
     • HTTP Version을 나타낸다.

2. Header

   • Host: spartacodingclub.kr
   • field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조를 가진다.
   • field-name은 대소문자 구분을 하지 않는다.
   • 임의의 Header를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함)
   • 요청의 추가 정보들을 가지고 있다.

   ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

3. Empty Line

   • 공백 한 줄
   • 필수 값

4. Message Body

   • 실제 전송하는 데이터가 담겨 있는 부분
     • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
   • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

HTTP 응답 메세지(Response Message)

1. Start Line
   • HTTP Version
   • Status Code
     • 요청이 성공했는지, 실패했는지 나타내는 코드
   • Status Text
     • 코드와 함께 전달될 메세지
2. Header
   • Response에서만 사용되는 Header 값들이 따로 존재한다.
3. Empty Line
   • 공백 한줄, 필수값
4. Message Body
   • 실제 전송하는 데이터가 담겨 있는 부분
   • 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.

HTTP Method

클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식을 뜻한다.

• 주요 Method

POST

• 리소스 생성
• 주로 HTML FORM(회원가입, 게시글 작성 등)에 사용된다.
• 요청 데이터를 처리하는 방식에 정해진것은 없다.
  1. 요청 데이터 처리(로그인 등)에 사용한다.
  2. 조회시 JSON 요청 데이터가 필요한 경우에도 사용될 수 있다.
• Message Body를 통해 요청 데이터를 전달한다.

GET

• 리소스 조회
  1. Query String 미포함하는 경우
  - GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.
  2. Query String 포함하는 경우
  -서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String(Query Parameter)를 사용한다.

PUT

• 리소스 덮어쓰기
• POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정한다.

1. 기존 리소스가 존재하는 경우
   • 리소스 전체 수정
2. 기존 리소스가 존재하고 일부만 변경하는 경우 중요!
   • 기존 리소스가 존재하면 완전히 덮어쓰기가 된다.
3. 기존 리소스가 없는 경우
   • 리소스가 없으면 생성된다.

PATCH
- 리소스 부분 수정

DELETE
- 리소스 삭제

기타 Method

• HEAD
  • GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환한다.
• OPTIONS
  • 대상 리소스에 대한 통신 가능한 Method를 설명한다.
• CONNECT
  • 대상 자원으로 식별되는 서버에 대한 터널을 설정한다.
  • 잘 사용하지 않는다.
• TRACE
  • 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.
  • 잘 사용하지 않는다.