HTTP
HTTP
애플리케이션 Layer의 프로토콜로 웹 서비스 통신에 이용.
HTTP/1.0
연결 관리 방식이 비지속 연결이다.
하나의 연결당 하나의 요청만을 처리하도록 설계되었기 때문에,
서버로부터 파일을 가져올때마다 TCP 3-way handshake를 해서 RTT 증가
RTT 증가를 해결하기 위한 방법
- 이미지 스플리팅 (css에서 다루었던 스프라이트 이미지 사용하는 방식)
- 코드압축
- 이미지 base64 인코딩
HTTP/1.1
Keep-Alive 옵션이 표준화되어,
한번의 TCP 연결 후, 여러개의 파일 송수신 가능.
현재는 웹에서 인터페이스 구성을 위해 많은 리소스가 필요하고, 리소스 요청마다 응답이 바로바로 이루어져야 하기 때문에 지속적 연결이 필요하다!
문제점
- 헤더의 중복 및 무겁다...
: 다양한 기능 지원에 따라, 헤더에 쿠키 등 많은 메타데이터가 담기는데 매 요청마다 불필요한 데이터가 중복 전송되므로 대역폭 낭비가 있다는 단점.
- HOL Blocking
: 멀티플렉싱이 안되기 때문에, 네트워크에서 같은 큐에 있는 패킷이 이전 패킷에 의해 지연될때 발생하는 성능 저하를 말합니다.
=> 예를 들어 img.jpg, css파일, xml파일 등을 다운받는데 이미지 다운이 느리다. 그러면 뒤에 있는 파일들도 지연되는 상태.
- 클라이언트 요청이 없으면 서버는 먼저 데이터 전송 못함.
HTTP/2
- 헤더 압축
- 멀티플렉싱
: 여러개의 스트림을 사용해 송수신.
=> 단일 연결로 병렬로 여러 요청 받을 수 있고 응답을 줄 수 있다.
=> HOLB 해결
- 서버 푸시
: 클라이언트가 요청하지 않더라도 서버가 리소스를 직접 푸시 할수있음
=> 전송시간이 훨씬 단축.
문제
HOL Blocking은 해결되었으나, TCP의 HOLB가 해결 안됨.
TCP는 순서대로 응답이 와야하는데 어느하나 loss되면 전체 연결이 중단됨.
HTTP/3
특징
- 초기 연결 설정 시 지연시간 감소
: QUIC 계층 위에서 돌아가며, TCP가 아닌 UDP기반으로 돌아가므로 3-way handshake를 거치지 않아,
지연시간이 감소한다.
HTTPS
간략히 말하면 신뢰할 수 있는 HTTP이다.
애플리케이션 layer와 전송layer 사이에 보안을 제공하는 SSL/TLS 계층을 넣음
이를 통해, 클라이언트-서버 통신 시 제 3자가 정보를 볼 수 없도록 암호화를 지원한다.
웹 통신시 사용되는 메소드
-
GET (URL로 데이터 전달)
헤더에 url이 담겨서 전송. 뒤에 "?"를 붙여서 request하는 방식
보안이 필요한 데이터에 대해선 안좋음! "?"뒤에 붙여야해서 제3자도 볼수있으므로.일반적으로는 어떤 값을 받기 위해 사용한다.
-
POST(body로 데이터 전달)
데이터 크기가 GET에 비해 큼.
서버에 값을 추가, 상태를 변경하거나 할때 쓰임.
Restful API
REST API의 설계 규칙을 올바르게 따르는 시스템을 말한다.
즉, REST API를 사용하였지만 RESTful 하지 못한 시스템일 수도 있는 것이다.
REST API란
REST (Representational State Transfer)
- 즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.
- 월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
왜 필요한가, REST의 설계 목표
REST의 구성
-
자원 (URL)
=> 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다. -
행위 (Method)
=> Http Method를 사용한다.
=> HTTP프로토콜은 GET, POST, PUT, DELETE 과 같은 메서드를 제공. -
표현
=> 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다.
REST 특징
REST API 디자인을 정의한 Fielding 박사가 정한 6가지 기본 원칙이 있다고한다.
6가지 기본원칙
1. stateless
2. 클라이언트 서버구조
3. 균일한 인터페이스
4. 캐시가능
5. 계층화된 시스템
6. 주문형 코드
- 무상태성 (Stateless)
- 각 요청은 독립적이어야한다.
- REST는 HTTP의 특성을 활용하므로 stateless하다.
- 상태정보를 기억할 필요X, 들어온 요청에 대해 처리만해주면 되므로 구현이 쉽다.
- 클라이언트-서버 구조
클라이언트와 서버가 서로 독립적으로 작동할 수 있도록 분리되어 있어야 한다.
- 클라이언트: 유저와 관련된 처리
e.g. 인증, context(세션, 로그인 정보) 관리 - REST server : API 제공 및 비즈니스 로직 처리를 담당한다
서로간의 의존성이 줄어드는 장점이 있다.
-
균일한 인터페이스
통일성을 위한 REST에는 인터페이스 제약조건이 있다.
- 자원을 식별할 수 있어야한다.
=> URL 만으로 어떤 자원을 제어하려 했는지 알 수 있어야 함. - 행위는 명시적이어야 한다.
- 자원에 대한 표현
=> 클라이언트가 서버로부터 자원의 표현을 받았을때, 충분한 정보를 포함 해야한다. - 자기 설명 메시지
=> 데이터의 메타 정보만 가지고도 데이터 처리를 위한 정보를 얻을 수 있어야 한다. - 애플리케이션의 현재 상태에서 다음에 가능한 모든상태를 클라이언트가 알 수 있도록 하이퍼링크를 포함시켜야한다.
-
캐시 가능
REST API 응답은 캐싱이 가능해야 한다. 클라이언트는 응답을 캐시하여 나중에 동등한 응답에 대해 재사용 할 수 있음.
=> 애플리케이션의 성능향상 -
계층화된 시스템
클라이언트는 최종 서버와 직접 통신하는건지, 중간에 다른 계층이 있는건지 알 수 없어야 한다.
=> 각 계층의 구성 요소가 바로 다음 계층을 넘어 상호 작용할 수 없으므로 애플리케이션의 보안을 강화하는 데 도움이 된다.
=> 보안 및 안정성 향상에 좋음. -
주문형 코드
=> 이것은 선택적 제약조건
=> 클라이언트 코드나 애플릿을 다운로드하여 애플리케이션 내에서 사용할 수 있다.
