HTTP 강의 정리

해당 정리는 아래 강의를 통해 정리한 부분입니다.

추가적인 세분화는 HTTP 카테고리에 올릴 예정입니다.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

IP 인터넷 프로토콜

지정한 ip로 데이터를 보내는 상황에서 우리응 패킷을 상용한다 

 

패킷 : 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록. (정해둔 규칙)

https://enlqn1010.tistory.com/9 참고

TCP UDP

IP안에 출발지 IP, 목적지 IP, 기타 ... + TCP 세그먼트가 들어간다.

TCP (transmission control protocol) : 전송 제어 프로토콜

연결지향, 데이터 전달 보증, 순서 보장, 신뢰할 수 있는 프로토콜

 

UPD는 진짜 아무것도 없지만 PORT가 추가된다.

요즘 핫한 아이

 

URI (I,L,N)

URI = URL(Resource Locatar) + URN(resource name)

uri = uniform resource locator

urn = ++ name(isbn)

 

HTTP : hypertext transfer protocol

TCP : http 1.1,2

UDP : http 3

클라이언트 구조 : 서버 클라이언트 따로

 

TCP(Transmission Control Protocol) 전송 제어 프로토콜 : 연결지향 TCP -3 wat handshake (가상 연결), 데이터 전달 보증, 순서 보장, 신뢰할 수 있는 프로토콜

순서 보장: 1패킷 완료 2패킷에서 오류가 발생하면 3패킷 전달을 실행하지 않고 다시 2패킷 전달을 시작한다.

UDP(User Datagram Protocol) 사용자 데이터그램 프로토콜 : 하얀 도화지 (기능이 거의 없다.), 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.   IP와 거의 같으며 PORT, 체크섬 추가(추가 필요20220406), 애플리케이션에서 추가 작업이 필요하다

  

 

상태 유지 프로토콜 :: stateful

→ 클라이언트의 상태를 유지

중간에 다른 서버로 바뀌면 안됨

 

무상태 프로토콜 :: stateless

→ 서버가 클라이언트의 상태를 유지하지 않는다.

무한 서버 증설이 가능하다

한계 :: 로그인이 필요없는 서비스 페이지에서 사용된다.

단점 : 데이터를 너무 많이 보냄

 

비연결성

연결을 유지하는 상태는 서버의 리소스를 계속 사용한다.

한계: 끊고 새로 맺어야해서 3way를 또 해야함,

많은 다운로드를 다다시 해야함 , HTTP에서 지속 연결을 사용하는 편

 

HTTP메세지

URI 설계 중요 :: 리소스와 행위는 분리해야한다. (이번 프로젝트 참고)

++)) 기본적으로 조회, 등록, 수정, 삭제는 get post put delete로 구분 가능

 

리소스란?

안전(Safe Methods) : 불러도 데이터가 변하지 않는것

멱등(Idempotent Methods) : idempotent : 1-100번 호출해도 결과는 같다

get, put, delete :: 멱등 /  post는 멱등이 아니다. (ex) 중복 결제 생각)

캐시가능(Casheable Methods): get,head정도만 사용

 

 

PRG : 중복 결제 방지책

헤더

협상: 언어 :: 0-1사이에서 클수록 높은 우선 순위

HTTP 헤더 전송 방식  : 단순, 압축, 분할 전송, 범위 전송

 

HOST :: 필수 요청한 호스트 정보(도메인)

 

쿠키

set-cookie : 서버에서 클라이언트로 전달 (응답)

cookie : 클라이언트다 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

 

검증헤더, 조건부 요청 (2022.04.06 추가 필요)

캐시 만료 이후에 데이터가 변하지 않은 상황

헤더에 데이터가 마지막으로 수정된 시간은 첫 요청때 받아오자

다음 요청때 if modified since를 보내보자 → 수정 안됐을때

304 not modified를 보내면서 http body를 뺀다 (수정된 부분이 없기에) 캐시 재사용 가능

검증헤더 

캐시데이터와 서버데이터가 같은지 검증하는 데이터

Last-Modified, ETag

조건부 요청 헤더 :: true 200 OK , false 304 NotModified

 

if modified since : last modified :: 이후 데이터가 수정이 되었나요?

미변경 : 304 Not Modified, 헤더 데이터만 전송(Body 미포함)

변경시 : 200 OK 모든 데이터 전송

 

if none match, ETag

위의 방식은 프론트가 아닌 백에서 모든 일을 처리 할 수 있다 (캐시 제어 로직을 서버에서 완전히 관리).

보안 + 숨기자고~

Cache-Control(케시 제어) :: max-age(캐시 유효 시간), no-cache(데이터는 캐시해도 되지만, origin 데이터는 서버에서 검증), no-store(민감 정보 저장 안됨)

 

프록시(proxy) 캐시

캐시 서버?

원서버에 직접 접근하는게 아닌 중간의 프록시 캐시 서버에 접근한다. → 응답이 빠름

Cache-Control(public, private, s-maxage) :: public private(공용서버엔 저장 안됨)

캐시 무효화 :: 웹 브라우저들이 자동으로 캐시하는 경우가 있다.

그래서 캐시하면 안되는 페이지에 설정한다.

\Cache-Control :

no-cache(항상 원서버 검증 필수),

no store,

must-revalidate(캐시 만료후 최초 조회시 검증)

no cache가 있는데 왜 revalidate가 필요한가?

순간적으로 원 서버와 연결이 끊기는 경우 과거 데이터를 보여주는 경우가 있음

error/200ok

위의 경우를 방지하기 위해서 revalidate를 넣어두자