HTTP

HTTP PATCH PUT 차이

HTTP / 1.0 로이필딩 (1994~1998)

MicroSoft 의 REST Guideline

1. URI -> HTTPS {service Root} / {collection} / {id}

2. GET , PUT, DELETE, POST , HEAD, PATCH, OPTIONS 지원해야 한다.

3. API 버저닝은 Major, Minor로 하고 URI에 버전 정보를 포함한다.

REST의 특징

• Client-Server

• Stateless

• cache

• uniform - interface **uniform-interface 제약조건

1. identification of resources

2. manipulation of resources through representation

3. self-descriptive messages : 메시지 스스로 설명

4. hypermedia as the engine of application state(HATEOAS) {3,4번은 잘 지켜지지 않는다.} 왜 uniform - interface ? -> 독립적 진화 === 서버의 기능이 변경되어도 클라이언트 업데이트를 할 필요가 없다.

• layered system

• code-on-demand

애플리케이션 상태의 전이

HTTP 1.1

1. Persistant connection

2. pipelining

3. Head of line blocking

4. header 중복

HTTP 2.0

1. HTTP 메시지 전송 방식의 변화

2. 바이너리 프레이밍 계층 사용

3. 파싱 전송속도 빨라졌고, 오류 발생 가능성이 떨어졌다.

Multiplexing -> Head of line blocking 해결

1. Stream Prioritization -> 리소스간 우선 순위를 설정 가능

2. Server push -> 끼워있는 파일을 미리 서버측에서 보낸다.

3. Header Compression -> 헤더 크기를 줄여 페이지 로드 시간 감소. (Static dynamic table)

QUIC -> UDP기반, 구글

1. 전송속도 향상 -> 첫 연결 설정에서 필요한 정보와 함께 데이터 전송 연결 성공 시 설정을 캐싱하여, 다음 연결 때 바로 성립 가능.

2. 커넥션 UUID 라는 고유한 식별자로 서버에 연결 -> 커넥션 재수립 필요 없음.

3. 보안 : TLS 기본 적용, IP spoofing / replay attack 방지 -> 보안성 향상

4. 독립 스트림 -> 향상된 멀티플렉싱 가능

5. 퀵을 써서 구글은 로딩 평균 3%개선 / 유튜브 버퍼링 30% 개선

HTTP 3.0 출시 됨

웹 요청 / 응답.

서버와 클라이언트

HTTP: 웹 요청과 응답에 관한 클라이언트와 서버 사이의 규약(약속) (Hyper Text Transfer Protocol)

• 비연결성 : 서버 응답을 마치면 연결을 끊어버린다. 다음 요청은 새로운 연결을 통해 이루어진다.

HTTP 특성

• 무상태 : 하나의 요청이 진행되는 동안만 서로를 인지 단점: 클라이언트 인증(로그인)이 필요한 서비스에서 불편함. 보완: 1. 쿠키, 세션, 토큰(Oauth, JWT) - 상태를 기억하기 위한 기능들.

HTTP Status Code(응답 코드, 상태 코드)

HTTP Methods

DNS

Same Origin-Policy: 브라우저 기본 설정은 하나의 서버만을 연결한다.

1. 요청메소드 정리

2. 라우터 정의

3. 요청데이터 받기

4. 동작구현

5. 데이터 상태 응답.