25.03.24 TIL - HTTP(1)

 

 

목차

 

 

HTTP(HyperText Transfer Protocol)

• 서버와 클라이언트가 서로 데이터를 주고받기 위해 사용되는 통신 규약.
• TEXT, IMAGE, FILE, HTML, JSON 등 다양한 형태의 데이터가 HTTP를 통해 전송됨.
•  대부분 HTTP/1.1 (TCP) 를 사용하지만 현대에는 HTTP/2, HTTP/3 (UDP)의 사용량이 급속도로 증가하는 추세.
• 클라이언트 to 서버(요청) 뿐만 아니라, 서버 to 클라이언트(응답)에도 사용되며 서버 to 서버 간의 데이터 통신에도 사용됨.

 

(참고하기 좋은 자료)

웹 개발자라면 알고 있어야 할 HTTP의 진화 과정 | 요즘IT

 

(참고한 블로그)

🌐 HTTP는 무엇일까요? - 기본 핵심 요약 총정리

HTTP에 대한 설명이 잘 요약되어 있는 글이다.

 

 

1. HTTP 동작 순서

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

 

2. HTTP 특징

    - 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계됨.

    - 서버에서 다수의 클라이언트와 상태나 연결을 계속하여 유지해야할 경우 이에 따른 많은 서버의 리소스 필요.

 

1. 클라이언트와 서버 구조
   • 기존에는 클라이언트, 서버가 구분되어있지 않았음.
     • 클라이언트는 UI에 중점을 두도록 만듦.
     • 서버에서 데이터, 비지니스 로직을 담당하도록 만듦.
   • 결과적으로 클라이언트, 서버 각자 독립적으로 발전.
2. 무상태 (Stateless)
   • 서버는 클라이언트의 상태를 보존하지 않음.
     • 장점
       • Scale Out 수평 확장성이 높음.
       • 갑자기 요청량이 증가하여도 서버를 증설하기 쉬움.
     • 단점
       • 클라이언트가 데이터를 추가적으로 전송해야함.
     • 한계점
       • 무상태로 설계할 수 없는 경우가 있음.
       • 로그인 시 로그인 유지를 하기 어려움  → Cookie, Session, Token 등을 활용하여 해결 가능.
3. 비연결 (Connectionless)
   • HTTP는 연결을 유지하지 않는 모델.
   • 장점
     • 서버 자원을 효율적으로 사용할 수 있음.
   • 단점
     • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야함. → 요청에 대한 응답 시간이 증가함.
     • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드함. → 캐시, 브라우저 캐싱으로 해결함. 쉽게 말해 임시저장 (추후 다룰 예정)
     • 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결.

 

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

 

 

3. HTTP Message 구조

    - 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다름.

 

• HTTP Message 구조

• HTTP 요청 메세지(Request Message)

 

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

 

4. 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
    • 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행함.
    • 잘 사용하지 않음.

 

POST는 CREATE(생성)

GET은 READ(조회)

PUT(전체 수정)/ PATCH(부분 수정)은 UPDATE(수정)

DELETE 는 DELETE(삭제).