AI 웹개발반/Python, Django

[Web] 웹의 동작과 이해, HTTP

째깍단 2023. 4. 19. 20:55

HTTP의 이해

 

 

 

 

> JSON의 탄생

이전에는 댓글을 달면 새로고침하면서 새로운 페이지 랜더링하는 방식이었는데,

필요한 부분만 update하는 변화가 생김

 

Ajax, vue, 비동기 자바스크립트 기술

=> react같은 프론트엔드로 작성!

 

템플릿 => 랜더 방식이 아닌 다른 방식으로 할 수 있도록 도와주는 것

= 장고 레스트 프레임워크 DRF

 

 

 

 

 

> 웹 브라우저의 역할

console 혹은 터미널에서 보기에는 복잡해보이는데

웹 브라우저에서도 같은 일이 일어나고 있다.

사용자의 언어, 접근, 어디에서 요청했는지 등을 수집하여 사용자에게 맞게끔 표현해주는 역할을 한다.

 

클라이언트 ================ 서버

클라이언트에서 request를 보내면 서버에서 response가 돌아옴

 

요청과 응답에 정해진 양식 약속이 있다 = 프로토콜

 

 

 

 

> HTTP 프로토콜   Hyper Text Transfer Protocol

리소스를 가져올 수 있는 프로토콜로 웹에서 이루어지는 모든 데이터교환의 기초

 

본디 HTML 전송용으로 나왔지만 현재는 모든 형태를 전송한다.

- 이미지, 음성, 영상, 파일, JSON XML ….

 

 

 

 

> 가볍게 알아보는 네트워크, 웹 브라우저의 흐름

 

1)DNS 조회

도메인네임서버에 접속해서 IP주소를 가져온다.

 

Domain Name System

컴퓨터간 통신에 사용하는 IP주소를 변환한 도메인 이름의 디렉터리.

 (= 주소록)

[참조] : https://aws.amazon.com/ko/route53/what-is-dns/

 

2)HTTP 요청 메시지 작성

 

3)Socket 라이브러리를 통해 전달

 

4)TCP/IP 작성, 이 안에 HTTP 메시지가 포함되어 있다.

   - TCP는 IP를 보완해주는 개념

 

[나머지공부 필요] : 네트워크 따로 공부하자  

 

 

 

 

> http의 역사

www과 internet은 조금 다른 개념이다. internet에 email 등 기능은 있었음

www , World Wide Web.  전세계 html문서를 연결하는 것!

 

현재는 http 1.1 버전 양식을 그대로 사용하는 중. 이후는 버전 업데이트만 했당

 

 

 

 

 

> http 의 두가지 특징

  • 클라이언트 서버구조

    1)Request response구조
    2)클라이언트 request, response를 기다린다
    3)왜 분리되어 있을까?
      - 초기에는 클라이언트와 서버 개념 분리 x
     
      - 데이터, 로직(백엔드) 전부 서버에 넣고, 클라이언트에는 ui(프론트엔드)
      - 각각 독립적인 진화를 할 수 있게되었다
      - 클라이언트가 모바일, TV, web 모든 것이 될 수 있게 됨

 

  • 무상태 프로토콜(stateless)

    1)서버가 클라이언트 상태를 보존하지 않음
      - 중간에 점원이 바뀜 - 기억 못함 - 클라이언트 요청시 정보 재전달필요  => 쿠키가 생기게되었다.|

    2)무상태 = 응답서버를 쉽게 바꿀 수 있다.

    3)클라이언트 상태 기억 x = 서버부담 줄임
      - 점원을 고정해두지 않고 그때그때의 점원이 응대하는 개념이라고 이해하면 편함

    4)세션로그인만 상태가 있고, 최소한으로 사용하는 개념
         <=> 반대개념인  stateful 사용자 상태 기억임.

    5) =비연결성
       HTTP는 기본적으로 연결을 유지하지 않는다.

       요청시마다 응답, 연결을 계속 유지하지 않고, 최소한의 자원으로 초 단위의 빠른 응답을 한다.
       일정시간동안 수천명이 사용하더라도 실제 동시 처리하는 요청은 몇십개 되지 않음!
        = 서버 자원을 효율적으로 쓸 수 있다

 

 

+++ 쿠키에 대해 알아보자!

더보기

HTTP 는 무상태 연결이기때문에 상태를 매번 보내주어야하는데,

모든 요청, 링크에 사용자 정보를 포함해야하는 단점이 있다.

 

= 쿠키!를 도입!

Set-Cookie로 리스폰스시 여러 정보 저장

저장된 Cookie로 요청과정을 간단하게 만든다.

 

 

 

 

 

 

> HTTP 메시지

 

요청/ 응답메시지가 조금 다르다!


Request message

Request line
Header
A Blank line
Body(optional)

Response message
Status line
Header
A Blank line
Body(optional)

Fig : format of Request message & response message

Postman으로 보면 이런식!&nbsp; &nbsp;+ 상태코드 200

더보기

> Postman을 사용해보자

웹 ‘요청’ 보내고 요청을 받아오는 앱.

내가 보낸 HTTP 요청을 받아와서 상세히 볼 수 있다.

 

cURL + 터미널을 이용해 인터넷 접속도 가능!

curl --location 'https://www.naver.com' \

 

 

 

> HTTP Method

 

모든 url을 새롭게 짜는 것은 좋지 않은 설계다.

가장 중요한 것은 리소스 식별임.

 

  • 리소스 resource :
    예를 들어 '회원' 이라는 개념 자체가 리소스
    회원정보 리소스 = URI에 매핑
    정보에 가하는 행위 = 메소드

  • 좋은 url은 한 리소스 안에 행위를 넣어주는 것.  Members/{id}     id= post delete update 등등의 행위!

    Restful API = 리소스와 행위를 분리하는 것
    - 리소스 : 회원
    - 행위 : 조회 등록 삭제 변경

 

 

 

 

> HTTP 메소드의 종류

 

  • GET
    조회, 쿼리 스트링으로 전달해준다.   (?query= ~~ 형태로 전송)
    자동으로 캐싱해줌
    • cache : 요청과 관련된 응답 저장, 이후 요청에 대해 저장된 응답을 재사용한다.
         - 장점: 서버요청x여서 응답속도가 빠름
                    응답 재사용 시라우팅 랜더링 세션복원 등을 할 필요가 없기때문에 원본 서버 부하가 줄어든다!

      ⁃ 개인 캐시 : 특정 클라이언트에 연결된 캐시. 개인화된 응답 저장
      ⁃ 공유캐시 : 클라이언트 — 공유 캐시 -- 서버.  서버와 클라이언트 사이에 위치한다.
                         사용자간 공유할 수 있는 응답을 저장함.  세부적으로는 프록시캐시 / 관리 캐시가 있음

      [참고하기] : HTTP 캐싱 https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching

 

  • HEAD : Get과 동일하지만 상태줄, 헤더만 반환한다.
  • POST : 메시지 바디에 정보가 있고, 서버로 요청 데이터를 전달한다.
                 데이터 처리, 프로세스 처리, 새로운리소스 생성ox, get메서드 쓰기 어려울때 사용한다.
                 다만 get메소드에서는 자동으로 캐싱해주므로 웬만하면 get사용해야 서버 부담이 없다!
  • PUT : 대체, 혹은 생성.  파일 붙여넣기와 동일. 없으면 만들어주고 있으면 덮어쓴다.
               Post vs Put : put은 클라리언트가 URI를 지정해서 보내줌
  • DELETE : 리소스 삭제
  • CONNECT : 리소스와 식별된 서버에 대한 연결(터널) 설정
  • OPTIONS : 리소스 통신 옵션..
  • TRACE :  A message loop-back test, 리소스에 대한 경로를 따라서 메시지 루프백 테스트를 수행한다,
  • PATCH : 리소스 부분 변경 = put과 비슷


    [참조] : https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

 

 

 

> 데이터 전송

  • 쿼리 파라미터
     - get
     - 주로 검색, 정렬 필터
  • 메시지 바디
     - post, put, patch
     - 회원가입, 상품주문, 리소스 등록 변경

 

  • 1) HTML Form
    - get,post만지원
    - 다른 종류의 여러파일, 데이터를 한번에 전송

 

  • 2)HTTP API
    - 서버to서버, 앱클라이언트, 웹클라이언트(ajax방식)
    - JS를 이용한 통신
    - post pust patch도 메시지 바디로 데이터 전송이 가능

 

  • 특징 :
    - 클라이언트는 등록될 리소스의 URI를 모른다(리소스가 없는 상태에서 delete기능이 먼저 활성화될 수 없음)
    - 서버가 리소스의 URI를 생성한다.
    - /members가 컬렉션이 된다.

 

 

 

 

 

 

> HTTP 상태코드

  • Informational responses (100 – 199)  : 정보 응답
  • Successful responses (200 – 299)  : 성공적인 응답
  • Redirection messages (300 – 399) : 리디렉션 메시지
  • Client error responses (400 – 499) : 클라이언트 오류 응답(대표적으로 404notfound가 있음)
  • Server error responses (500 – 599) : 서버 오류 응답

 

 

 

 

 

> HTTP Header

 

Field-name(key) 대소문자 구분이 없다!

HTTP 전송에 필요한 모든 정보들
- 바디 내용, 크기, 인증, 표현방식, 요청 클라이언트, 캐시 등

헤더에는 바디 데이터를 해석할 수 있는 정보를 제공한다

필요시 임의 헤더도 추가 가능

 

 

[참고하기] : https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header

 

 

 

 

 

 

 

 

 

이해가 안된 부분은 나머지 공부를 하도록 하자

 

[O] 프론트엔드와 백엔드의 역할을 이해한다.

[O] HTTP 메시지의 구조를 이해한다.

[O] Request와 Response 메시지의 역할을 이해한다.

[O] HTTP의 상태코드의 역할을 이해한다.

[ ] HTTP의 헤더의 역할을 이해한다.

[O] 웹의 요청 흐름을 이해한다.

[O] State와 Stateless의 뜻을 이해한다.

[O] Restful API 설계를 있다