HTTP
- 인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
- 클라이언트와 서버를 분리함으로써 각가의 역할에 집중할 수 있다.
- 무상태성(stateless)
- 무상태(Stateless) : 클라이언트와 서버 사이에 상태를 유지하지 않는다. => 서버는 클라이언트의 상태를 보존하지 않는다.
- 장점: 서버 확장성 높음(스케일 아웃)
- 단점: 클라이언트가 추가 데이터 전송 (메모리 ↑)
- 비연결성(connectionless)
- 서버와 클라이언트의 Connection 연결을 지속하지 않는다.
- 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지하지 않음
- 이러한 비연결성 특성 때문에 서버 자원을 매우 효율적으로 사용할 수 있다.
무상태성 vs 비연결성
무상태성은 클라이언트와 서버 간에 상태 정보를 들고있지않아 클라이언트가 상태 정보를 일일히 http에 실어 요청해야되는 것을 말하고, 비연결성은 클라이언트와 서버 간에 네트워크 연결이 끊어져 단절된다고 이해하면 된다.
HTTP 메서드 5가지
HTTP 메소드는 클라이언트가 서버에게 사용자 요청의 목적을 알리는 '수단'
HTTP 메서드는 총 9가지가 있으나 그 중 5가지를 알아본다
| 종류 | 기능 |
| GET | 데이터 조회 |
| POST | 요청 데이터 처리(보통 데이터 등록 사용) |
| PUT | 데이터 변경 (해당 데이터가 없으면 생성) |
| PATCH | 일부 데이터만 변경 |
| DELETE | 데이터 삭제 |
HTTP 메서드 특성
안전성(Safe)
- 호출해도 리소스 변경이 일어나지 않는 속성
- 여기서 안전의 기준은 오직 리소스 변경 가능성이며, 외적인 요소는 포함하지 않는다.
- GET을 안전한 메소드라고 볼 수 있다. (POST, PUT, PATCH, DELETE는 리소스를 변경하는 메소드이므로)
멱등성(Idempotent)
- 동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것
- 같은 행위를 여러 번 반복하더라도 같은 효과를 받으며, 서버의 상태로 동일하게 남음
- 멱등성은 요청의 결과를 보고 판단
- TimeOut 등으로 클라이언트가 서버로부터 정상 응답을 받지 못 했을 때 같은 요청을 다시 해도 되는지 판단하는 근거
- GET : 몇 번을 조회하더라도 같은 결과가 조회된다. ⇒ 회원 정보를 몇번을 조회한다고 정보가 달라지지 않는다.
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.
- POST : 멱등이 아니다. 두 번 호출하면 에러가 발생할수 있다. ⇒ POST로 주문을 두 번 호출하면 결제가 중복될 수 있다.
캐시 가능 (Cacheable)
- 응답 결과를 캐시해 사용할 수 있는 속성
- GET, POST, PATCH가 캐시 가능하나, Message Body의 캐시 키의 복잡성 문제로 실제로는 GET만 사용
GET VS POST
GET
- 조회에 많이 사용
- GET 방식은 요청하는 데이터가 HTTP Request Message의 Header 부분에 url 이 담겨서 전송
- url 상에 ? 뒤에 데이터가 붙어 request 를 보내게 됨
- 이러한 방식은 url 이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다.
- 보안이 필요한 데이터에 대해서는 데이터가 그대로 url 에 노출되므로 GET방식은 적절하지 않다. (ex. password)
POST
- POST 방식의 request 는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송
- 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다 크고 보안면에서 낫다.(하지만 보안적인 측면에서는 암호화를 하지 않는 이상 고만고만하다.)
GET VS POST
GET 은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT 적인 성향을 갖고 있다고 볼 수 있는 것이다. 반면에 POST 는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.
부수적인 차이점을 좀 더 살펴보자면 GET 방식의 요청은 브라우저에서 Caching 할 수 있다. 때문에 POST 방식으로 요청해야 할 것을 보내는 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET 방식으로 요청한다면 기존에 caching 되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 하는 것이다.
| 처리 방식 | GET 방식 | POST 방식 |
| URL에 데이터 노출 여부 | O | X |
| URL 예시 | http://localhost:8080/boardList?name=제목&contents=내용 | http://localhost:8080/addBoard |
| 데이터의 위치 | Header(헤더) | Body(바디) |
| 캐싱 가능 여부 | O | X |
| 멱등성 여부 | O | X |
PUT VS PATCH
PUT
- 모든 값들을 UPDATE (보내지 않는 값들은 NULL 이 된다)
- 요청값이 없으면 새로 생성
- 멱등성 측면에서 PUT은 계속 똑같으므로 멱등성이 있다
PATCH
- 보낸 값들만 UPDATE
- 요청값이 없으면 새로 생성 하지 않는다
- 어떻게 설계하느냐에 따라 멱등성이 있을수도 없을 수도 ( EX. 그냥 이름 변경은 멱등성이 있다. 그러나 +1을 계속 한다면 값이 계속 바뀌므로 멱등성이 없다)
HTTP 상태코드
- 클라이언트가 보낸 HTTP 요청이 성공했는지 실패했는지를 서버에서 알려주는 숫자 코드
- HTTP 상태 코드는 3자리 숫자로 이루어져 있으며, 총 100번대 ~ 500번대 까지 존재한다.
- 각 상태코드의 첫 번째 자리는 최상위 코드가 되어 다음과 같이 5 개의 그룹으로 나뉘어 관리된다.
1XX : 요청이 수신되어 처리중
2XX : 요청 정상 처리
3XX : 요청을 완료하려면 추가 행동이 필요
4XX : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5XX : 서버 오류, 서버가 정상 요청을 처리하지 못함
HTTP /1.0, 1.1, 2.0, 3.0
HTTP 1.0
- 한 연결당 하나의 요청 처리
- 비지속적 연결
- RTT가 증가한다는 단점
RTT : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이며 패킷 왕복 시간
HTTP 1.1
- 지속 연결
- 하나의 TCP 연결 후 keep-alive 옵션으로 여러개의 파일을 송수신 할 수 있게 바뀜
- 파이프라이닝 : 여러개의 요청을 연속적으로 보내고 순차처리
문제점
HOL Blocking (Head of Line Blocking)
같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
요청하는 데이터의 크기는 제각각 이기 때문에, 첫번째로 요청한 데이터가 용량이 큰 데이터라면, 두번째, 세번째 데이터가 아무리 빨리 처리되어도 우선순위 원칙에 따라 첫번째 데이터의 응답 속도가 늦어지면 후 순위에 있는 데이터 응답속도도 덩달아 늦어지게 되는 것
무거운 헤더 구조와 중복
http/1.1의 헤더에는 많은 메타정보들이 저장되어 있어 전송하려는 값보다 헤더 값이 더 크다
연속된 요청 데이터가 중복된 헤더값를 가지고 있는 경우가 많아 쓸데없는 메모리 자원도 낭비한다
HTTP 2.0
- HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 할 수 있으며 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜
- 하나의 커넥션으로 동시에 여러개 메세지 주고받기 가능
-RESPONSE는 순서 상관없이 stream으로 주고 받음
HTTP 2.0 개선점
Multiplexing
멀티플렉싱(multiplexing) : HTTP 헤더 메세지를 바이너리 형태의 프레임으로 나누고 하나의 커넥션으로 동시에 여러개의 메세지 스트림을 응답 순서에 상관없이 주고 받는 것
- HTTP/1.1의 Head Of Line Blocking을 개선
- 프레임 단위로 이루어진 요청과 응답 메세지는 하나의 스트림을 통해 이루어지며, 이러한 스트림들이 하나의 커넥션 내에서 병렬적로 처리된다. 하나의 커넥션에서 여러개의 스트림이 동시에 열리니 속도가 빠를수밖에 없다.
- 각 프레임에는 이것이 어떤 스트림인지에 대한 고유한 식별자가 있어, 클라이언트는 여러개의 스트림을 interleaving을 통해 서로 끼워놓는 식으로 조립한다.
Frame : HTTP/2에서 통신의 최소 단위이며, Header 혹은 Data 가 들어있다.
Message : HTTP/1.1과 마찬가지로 요청 혹은 응답의 단위이며 다수의 Frame으로 이루어진 배열 라인
Stream : 연결된 Connection 내에서 양방향으로 Message를 주고 받는 하나의 흐름
Binay Framing Layer
HTTP 메세지가 1.1에서는 text로 전송되었던 것과 달리, 2.0에서는 binary frame로 인코딩되어 전송된다
데이터 파싱 및 전송 속도가 증가하였고 오류 발생 가능성이 줄어들었다.
Server Push
HTTP 2.0에서는 클라이언트의 요청에 대해 미래에 필요할것 같은 리소스를 똑똑하게 미리 보낼 수 있다.
예를 들어 클라이언트로부터 HTML 문서를 요청하는 하나의 HTTP 메세지를 받은 서버는 그 HTML 문서가 링크하여 사용하고 있는 이미지, CSS 파일, JS 파일 등의 리소스를 스스로 파악하여 클라이언트에게 미리 push해서 미리 브라우저의 캐시에 가져다 놓는다.
HTTP Header Data Compression
HTTP 메시지의 헤더를 압축하여 전송한다. 호프만 인코딩(Huffman Encoding) 기법을 사용하는 HPACK 압축 방식으로 인코딩 처리 하여 전송
HTTP 2.0 에서는 이전 Message의 헤더의 내용 중 중복되는 필드를 재전송하지 않도록하여 데이터를 절약할 수 있게 되었다.
HTTP 2.0 문제점
TCP 자체의 HOLB (Head Of Line Blocking)
기본적으로 TCP는 패킷이 유실되거나 오류가 있을때 재전송하는데, 이 재전송 과정에서 패킷의 지연이 발생하면 결국 HOLB 문제가 발생된다.
애플리케이션 계층(L4)에서 HTTP HOLB를 해결하였다 하더라도, 전송 계층(L3)에서의 TCP HOLB 를 해결한건 아니기 때문이다.
HTTP 3.0
- TCP 위에서 돌아가는 HTTP/2 와는 달리 HTTP/3 은 QUIC이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.
- HTTP/2 에서 장점이었던 멀티플렉싱을 가지고 있으며 초기 연결 설정 시 지연 시간 감소라는 장점도 있다. (TCP 3-way-handshake를 하지 않음) => 첫 연결 설정에 1-RTT만 걸린다
-QUIC을 사용하므로써 HTTP 2.0에서 발생하였던 TCP HOLB 문제 해결
- QUIC : TCP + TSL + HTTP의 기능을 모두 구현한 프로토콜. TCP의 프로토콜의 무결성 보장 알고리즘과 SSL이 이식됨으로써 높은 성능과 동시에 신뢰성을 충족
HTTPS
애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청 => '통신 암호화'
SSL/TLS
SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜이다.
클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제 3자가 메시지를 도청하거나 변조하지 못하도록 한다.
공격자가 서버인척 하며 사용자의 정보를 가져가는 인터셉터 방지
SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용된다.
보안 세션
보안 세션이란 보안이 시작되고 끝나는 동안 유지되는 세션을 말하고, SSL/TLS는 핸드셰이크를 통해
보안 세션을 생성하고 이를 기반으로 상태 정보를 공유한다.
인증 메커니즘은 아무 곳에서나 할 수 있는게 아니고 신뢰성이 엄격한 공인된 기업들만 참여할 수 있다.
대표적으로 아마존이 있다.
HTTPS 구축 방법
HTTPS 구축 방법은 크게 세가지이다. 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스를 구축하거나,
서버 앞단의 HTTPS를 제공하는 로드밸런서를 두거나,
서버 앞단에 HTTPS를 제공하는 CDN(콘텐츠 전송 네트워크)을 둬서 구축한다.
HTTP VS HTTPS
HTTP는 평문 데이터를 전송하는 프로토콜이기 때문에, HTTP로 중요한 정보를 주고 받으면 제 3자에 의해 조회될 수 있다.
이러한 문제를 해결하기 위해 HTTP에 암호화가 추가된 프로토콜이 HTTPS이다.
HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신함으로써 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.
참고
https://dev-coco.tistory.com/60
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network
