HTTP 웹 기본 지식

인터넷 네트워크 IP
Internet Protocol

IP(인터넷 프로토콜) : 인터넷을 통해 데이터를 주고받을 때 사용하며 지정한 주소에 패킷 단위로 데이터를 전달

IP 패킷 정보 : (출발지 IP + 목적지 IP) + 데이터

IP 프로토콜의 문제점
1. 대상이 없어도 패킷을 전송(비 연결성)
2. 패킷이 사라지거나 순서대로 오지않을 수 있다(비 신뢰성)

TCP/IP 프로토콜(전송 제어 프로토콜)

여러 계층으로 나누어 IP 프로토콜의 문제점을 개선!

TCP/IP 4계층

4계층	애플리케이션 계층	HTTP,FTP
3계층	전송 계층	TCP,UDP
2계층	인터넷 계층	IP
1계층	네트워크 인터페이스 계층	Ethernet

TCP 특징
1. 연결 지향 - TCP 3way handshake
  - SYN : 접속 요청 , ACK : 요청 수랑
  - 클라이언트 SYN -> 서버 SYN+ACK -> 클라이언트 ACK
  - 3way handshake를 통해 연결성을 보장받는다.
2. 데이터 전달 및 순서 보장

PORT

하나의 클라이언트에 여러개의 서버를 연결 하였을 때 PORT 번호로 같은 IP 내 프로세스를 구분할 수 있다.

TCP/IP 패킷 정보 : IP(출발지 IP + 목적지 IP) + TCP(출발지 PORT + 목적지 PORT + 전송 제어 + 순서..)+ 데이터

* 간단 정리 : IP : 아파트 , PORT : 동호수

DNS

IP 주소를 기억하고 변경하기 어렵기 때문에 도메인 명을 IP 주소로 변환해주는 시스템.

URL와 웹 브라우저 요청 흐름

URL

구글에 naver를 검색하는 URL은 https://www.google.com:443/search?q=naver&hl=ko 이며, 해당 URL을 분리하면

프로토콜 = https
- 프로토콜 : 어떤 방식으로 자원에 접근할 것인지 정하는 규칙
- http: 80포트 https: 443포트를 주로 사용
호스트명 = www.google.com
- DNS 또는 IP 주소를 입력
포트번호 = :443
패스(path) = /search
- 리소스 경로를 입력
쿼리 파라미터 = q=naver&hl=ko
- key=value 형식으로 ?로 시작하고 &로 추가한다.

웹 브라우저 요청 흐름

웹 브라우저가 HTTP 요청 메세지를 생성한다
- [ GET /search?q=naver&hl=ko HTTP/1.1 Host: http://www.google.com ]
HTTP 메세지를 전송할 때 TCP/IP 4계층을 통해 데이터에 헤더들을 부착한다
- 요청 메세지 + TCP/IP 패킷[ IP(출발지/목적지 IP) + TCP(출발지/목적지 PORT + 전송 제어 + 순서..]
요청 패킷을 구글 서버에 전송한다.
구글 서버에 요청 패킷이 도착하면 TCP/IP 계층 순서에 따라 헤더들을 제거한다.
구글 서버에서 HTTP 메세지를 해석하여 HTTP 응답 메세지를 웹 브라우저에 전송한다.
- [ HTTP/1.1 200 OK Content-Type: text/html;charset=UTF-8 Content-Length: 3423 <HTML>code..</HTML> ]
웹 브라우저에 응답 패킷이 도착하면 HTML을 렌더링하여 데이터를 확인할 수 있다.

HTTP
Hyper Text Transfer Protocol

특징

1. 클라이언트 서버 구조 : 서버가 요청에 대한 결과를 만들어서 응답

2. 무상태 프로토콜 (Stateless) : 서버가 클라이언트의 상태를 보존하지 않는 것

장점 : 서버 확장성이 높다
단점 : 클라이언트가 추가 데이터를 전송해야 한다.
실무 한계 : 로그인과 같이 상태 유지를 해야되는 경우에는 상태 유지를 사용, 상태유지는 최소한으로 사용해야 함

상태 유지 (Stateful)는 중간에 서버가 장애가 나면 상태 유지한 데이터가 손실되면서 데이터를 처음부터 다시 입력해야 한다.

무상태 유지(Stateless)는 중간에 서버가 장애가 나도 요청시 데이터가 전부 포함되어있기 때문에 바로 응답을 받을 수 있다.

3.비연결성 : 요청을 주고 받을 때만 연결을 유지하고 응답을 준 이후에는 TCP/IP 연결을 끊어버림

연결을 유지하면 자원이 낭비되기 때문에 비연결성을 사용하면 서버 자원을 매우 효율적으로 사용할 수 있음
비연결시 자원을 받기 위해 연결/종료를 반복해야 하기 때문에 자원 낭비가 심함 -> HTTP 지속 연결을 통해 해결
HTTP 지속 연결 : 연결이 바로 종료되는 것이 아니라 필요한 자원들에 대한 응답이 돌아온 이후 종료한다.

HTTP 메세지 구조

HTTP 메세지 구조는 start-line / header / CRLF / message body로 구분된다.

start-line :HTTP 요청 메세지 request-line / HTTP 응답 메세지 status-line
- HTTP 요청 request-line :HTTP method SP requset-target SP HTTP-version
  1. HTTP 메서드 : GET(조회), POST(처리)
  2. requset-target : 절대경로 ("/"로 시작하는 경로)로 요청 메세지 입력
- HTTP 응답 status-line : HTTP-version SP status-code SP reason-phrase CRLF
  1. status-code : HTTP 상태 코드로 요청 성공/실패를 나타냄 (200:성공 / 400:클라이언트 오류 / 500:서버 오류)
  2. reason-pharse : 이유 문구
Header : field-name: OWS field-value OWS
- field-name: field-value 형식으로 쌍으로 이뤄져 있으며 HTTP 전송에 필요한 모든 부가 정보를 담는다.

*CRLF : 엔터, SP : 공백, OWS : 띄어쓰기

HTTP 메서드

URI 설계에서 가장 중요한 것은 리소스 식별이다.

리소스란?

예시로 회원 URI 설계한다는 가정시 회원을 등록하고 수정하는 것은 리소스가 아니다. 회원이라는 개념 자체가 리소스다.

즉 회원이라는 리소스만 식별하면 된다.

정리하면 리소스는 회원 ,행위는 조회/등록/삭제/변경을 의미하며 행위를 구분하기 위해 HTTP 메서드를 이용한다.

URI 설계 특징

명사를 사용하여 자원을 표현 (리소스= 명사, 행위 = 동사)
자원과 행위를 분리하여 HTTP 메서드로 표현

HTTP 메서드 종류

GET : 리소스 조회
POST : 서버로 요청 데이터를 전달하고 서버에서 요청 데이터 처리
PUT : 리소스가 있으면 대체, 없으면 생성, POST와의 차이는 리소스 위치를 알고 URI 지정
PATCH : 리소스 부분 변경, PUT과의 차이는 PUT는 리소스를 완전 대체하지만 PATCH는 부분적으로 변경
DELETE : 리소스 제거

클라이언트에서 서버로 데이터 전송 상황

정적 데이터 조회 (GET)
동적 데이터 조회 (GET)
- 쿼리 파라미터를 통해 데이터를 전달해서 데이터 조회
HTML FORM을 통한 데이터 전송 (POST,GET)
- GET : 폼을 통해 값을 받은 이후 URL 안에 데이터를 넣어서 HTTP 메세지 전송, 조회만 가능
- POST : 폼을 통해 값을 받은 이후 BODY 안에 데이터를 넣어서 HTTP 메세지 전송
HTTP API를 통한 데이터 전송

HTTP API 설계

POST : 서버가 관리하는 리소스 디렉토리(컬렉션) 사용
GET : 리소스 URI 를 알고 있어야 하며, 클라이언트가 관리하는 리소스 저장소(스토어) 사용

HTML FORM 특징

GET, POST만 지원
HTTP 메서드로 해결하기 애매한 경우 컨트롤 URI 사용

URL 설계 개념

리소스 형식	문서 (Document)	컬렉션 (Collection)	스토어 (Store)	Controller, 컨트롤 URI
의미	파일, 객체 인스턴스	서버가 관리하는 리소스 디렉토리 서버가 리소스의 URI를 생성하고 관리	클라이언트가 관리하는 리소스 저장소 클라이언트가 리소스의 URL을 알고 관리	문서, 컬렉션, 스토어로 해결하기 어려운 상황에서 프로세스를 처리할 때 사용
예시	/file/love.png, members/100	/members	/files	/members/{id}/delete-all

HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 코드를 통해 알려주는 기능

상태 코드 종류

100번대 : 요청 처리 중
200번대 : 요청 정상 처리
300번대 : 요청 완료시 추가 처리
400번대 : 클라이언트 오류
500번대 : 서버 오류

200번대 상태코드 : Successful

200번 : 요청을 성공적으로 처리
201번 (Created) : 요청을 성공해서 새로운 리소스가 생성됨
202번 (Accepted): 요청이 접수됐으나 처리가 완료되지 않음
204번 (No Content) : 서버가 요청을 처리했으나 응답 데이터가 없음

300번대 상태코드 : Redirection

리다이렉션 : 300번대 응답 결과에 Location 헤더가 있으면, 해당 위치로 자동 이동되는 것

즉 경로가 바겨서 다른곳으로 이동되는 것

리다이렉션의 종류
- 영구 다이렉션 : 리소스의 URI가 영구적으로 이동되며 원래의 URL를 사용하지 않는다. ex) /members -> /users
- 일시 다이렉션 : 일시적으로 리소스의 URI가 변경된다. ex) 주문 완료후 일시적으로 주문 내역화면으로 이동될 때
- 특수 다이렉션 : 결과 대신 캐시 사용

301번, 308번 :영구 리다이렉션
- 301번 : 리다이렉트시 요청 메서드가 GET으로 변하고, 메세지 바디가 제거될 수도있음(MAY)
- 308번 : 리다이렉트시 요청 메서드와 메세지 바디를 유지

302번, 303번 , 307번 :일시 리다이렉션
- 302번 (Found) : 리다이렉트시 요청 메서드가 GET으로 변하고, 메세지 바디가 제거될 수도있음(MAY)
- 303번 (See Other) : 리다이렉트시 요청 메서드를 GET으로 변경
- 307번 (Temporary Redirect) : 리다이렉트시 요청 메서드와 메세지 바디를 유지

POST로 주문 후 웹 브라우저를 계속 새로 고침하면 중복 주문이 발생할 수 있다.

이럴 때 PRG (Post -> Redirect -> Get) 패턴을 사용한다.

PRG : POST 요청이 오면 요청 수락 후 리다이렉션하여 GET 요청으로 변환시키는 행위

PRG를 통해 POST로 주문 후 주문 결과 화면을 GET 메서드로 리다이렉트하여 중복 주문을 방지한다.

새로고침을 반복해도 주문 데이터 조회만 반복된다 (주문이 중복되지 않는다)

400번대 상태코드 : Client Error

클라이언트의 요청에 잘못된 문법으로 서버가 요청을 수행할 수 없을 때 발생, 재시도를 해도 무조건 실패

400번 (Bad Requset) : 클라이언트의 잘못된 요청으로 에러발생
401번 (Unauthorized) : 클라이언트가 해당 리소스에 대한 인증이 필요
403번 (Forbidden) : 접근 권한이 없어 승인 거부
404번 (Not Found) : 요청 리소스가 서버에 없음

500번대 상태 코드 : Server Error

서버 문제로 오류가 발생, 재시도를 하면 서버가 복구되어 성공할 수 있음

500번 (Internal Server Error) : 서버 문제로 오류 발생, 대부분 500
503번 (Service Unavailable) : 서버 과부화, 작업으로 요청처리 불가

HTTP 헤더

HTTP 전송에 필요한 모든 부가 정보

HTTP 헤더 표현

Content-Type : 표현 데이터의 형식 설명
- ex) Content-Type: text/html
Content-Encoding : 데이터를 전달하는 곳에서 인코딩 헤더를 추가해서 보낸 이후 받는 쪽에서 헤더 정보를 통해 압축 해제
- ex) Content-Encoding: gzip
Content-Language : 표현 데이터의 언어
- Content-Language: ko
Content-Length : 표현 데이터의 길이 (바이트 단위)

협상 (콘텐츠 네고시에이션)

협상을 통해 클라이언트가 선호하는 표현을 요청한다. (요청시에만 사용)

Accept (미디어 타입) / Accept -Charset (문자) / Accept-Encoding (압축) / Accept-Language (언어)를 요청한다.

협상 우선순위 특징

0~1, 숫자가 클수록 우선순위가 높다.
내용이 구체적일수록 우선순위가 높다.

쿠키

페이지에 들어갈 때마다 사용자 정보를 포함시키기에는 무리가 있음

이런 문제를 해결하기 위해 쿠키를 사용한다 !

쿠키는 서버로 부터 쿠키 정보를 받고 이후 클라이언트가 저장된 쿠키를 통해 HTTP 요청시 서버로 전달한다.

특징
1. 쿠키는 항상 서버에 전송되기 때문에 네트워크 트래픽을 추가 유발하기 때문에 최소한의 정보만 사용해야 함
2. 보안에 민감한 데이터는 저장하면 안됨
3. 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지(localStorage, sesstionStrorage) 권장함

캐시

데이터를 서버로 통해 받은 이후 다시 데이터를 요청할 때 데이터를 다시 다운로드 받아야하는 과정은 비효율적이다.

이런 문제를 해결하기 위해 캐시를 사용한다. (쿠키랑 비슷한 개념)

캐시는 브라우저 캐시를 통해 데이터를 임시 저장하여 빠른 로딩 속도를 제공한다.

캐시 시간 초과

캐시에는 유효 시간이 있으며 캐시 유효 시간이 지나면 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.

캐시 유효 시간이 지나고 서버에 재요청이 두가지 상황이 발생한다.

서버에서 기존 데이터를 변경함
서버에서 기존 데이터를 변경하지 않음

캐시 만료후에도 데이터가 변경되지 않을 때는 저장해두었던 캐시를 재사용할 수 있다. 이러한 사실을 확인할 수 있는 방법은 바로 데이터가 마지막에 수정된 시간(Last-Modified)으로 검증을 하는 것이다.

수정된 시간이 서로 같다면 HTTP Body 없이 응답 메세지를 보내며 응답 헤더 정보로 캐시의 메타 정보를 갱신한다.

서버에서 기존 데이터를 변경하지 않았을 때의 순서
1. 웹 브라우저가 서버에 요청 메세지를 보냄
2. 서버는 캐시 정보(Last-Modified)를 포함하여 응답 메세지를 보냄
3. 웹 브라우저에서 응답 데이터를 브라우저 캐시에 저장
4. 캐시 시간 초과
5. 웹 브라우저가 서버에 If-Modified-Since를 포함한 요청 메세지를 보냄
  - If-Modified-Since : 이후에 데이터가 수정되었다면 ? 하는 가정
6. 데이터 최종 수정일을 비교하여 수정일 같다면 304 Not Modified의 상태코드와 함께 HTTP Body없이 응답 메세지를 보냄
7. 웹 브라우저에서 304 Not Modified를 통해 데이터가 같다는 것을 확인하고 브라우저 캐시를 통해 응답 결과를 재사용

기존 데이터가 변경되었을 때는 200 OK + 모든 데이터를 전송하여 캐시를 갱신한다.

Cache-Control (캐시 지시어)
- Cache-Control: max-age = 캐시 유효시간, 초 단위
- Cache-Control: no-cache = 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
- Cache-Control: no-store = 메모리에서 사용하고 최대한 빨리 삭제 (민감한 정보 저장시)

Etag (Entity Tag)

데이터를 수정해도 데이터 결과가 같은 경우나, 서버에서 캐시 로직을 관리할 때 Etag를 사용한다.

기존 캐시에서는 날짜를 이용하여 비교를 하였지만 Etag는 데이터 해시값으로 데이터를 비교한다.

프록시 캐시

프록시란 클라이언트 서버 사이에 대리로 통신을 수행하는 것이며, 이를 중계하는 서버가 프록시 서버이다.

원(origin) 서버 전 프록시 캐시 서버를 통해 데이터를 빠르게 얻을 수 있다.

Cache-Control (캐시 지시어)
- Cache-Control: public = 응답이 public 캐시에 저장되어도 됨
- Cache-Control: private = 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)
- Cache-Control: s-maxage = 프록시 캐시에만 적용되는 max-age
- Age: 60 (HTTP 헤더) = 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

캐시 무효화 (확실한 캐시 무효화 응답)

Cache-Control (캐시 지시어)
- Cache-Control: no-cache = 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
- Cache-Control: must-revalidate = 캐시 만료후 최초 조회시 원(origin) 서버에 검증하고 사용

no-cache 와 must-revalidate의 차이 (순간 네트워크가 단절되어 원 서버 접근이 불가능할 때)
- no-cache : 원 서버에 접근이 불가능할 때 캐시 서버 설정에 따라 캐시 데이터를 반환할 수 있음 Error or 200 OK
- must-revalidate : 원 서버에 접근이 불가능할 때 항상 오류가 발생함 504 GateWay Timeout

즉 no-cache는 오류 보다는 어떻게든 데이터를 보여주자! must-revalidate는 중요한 접근이므로 데이터를 보여줄 수 없다!

출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식 feat.김영한 쌤

'웹 개발' 카테고리의 다른 글

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 (2)	2024.02.27
스프링 DB 1편 - 데이터 접근 핵심 원리 (0)	2024.02.24
스프링 MVC 2편 - 타임리프 (0)	2024.02.23
스프링 MVC 1편 (0)	2024.01.23
SPRING 핵심 원리 - 기본편 정리 (0)	2023.12.22

'웹 개발' 카테고리의 다른 글

티스토리툴바