[Web] 웹의 동작과 이해, HTTP
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을 사용해보자
웹 ‘요청’ 보내고 요청을 받아오는 앱.
내가 보낸 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
- cache : 요청과 관련된 응답 저장, 이후 요청에 대해 저장된 응답을 재사용한다.
- 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 설계를 할 수 있다