HTTP(Hyper Text Transfer Protocol)이란
데이터를 주고 받기 위한 프로토콜이며, 서버/클라이언트 모델을 따릅니다.
HTTP는 상태 정보를 저장하지 않는 Stateless의 특징과 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless의 특징을 가지고 있습니다.
HTTP는 평문 데이터를 전송하는 프로토콜이기 때문에, HTTP로 중요한 정보를 주고 받으면
제 3자에 의해 조회될 수 있습니다.
이러한 문제를 해결하기 위해 HTTP에 암호화가 추가된 프로토콜이 HTTPS입니다.
HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있습니다.
※ SSL(Secure Socket Layer) 인터넷을 통해 전달되는 정보를 보호하기 위해 개발한 통신 규약
HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신함으로써 암호화와 증명서, 안전성 보호를 이용할 수 있게 됩니다.
쿠키는 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일입니다. HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요시 정보를 참조하거나 재사용할 수 있습니다.
세션은 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술입니다.
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 합니다.
쿠키(Cookie) | 세션(Session) | |
---|---|---|
저장 위치 | 클라이언트(=접속자 PC) | 웹 서버 |
저장 형식 | text | Object |
만료 시점 | 쿠키 저장시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으면 삭제되지 않음) | 브라우저 종료시 삭제(기간 지정 가능) |
사용하는 자원 (리소스) | 클라이언트 리소스 | 웹 서버 리소스 |
용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096byte) | 서버가 허용하는 한 용량제한 없음 |
속도 | 빠름 | 느림 |
보안 | 안좋음 | 좋음 |
쿠키(Cookie)와 세션(Session)의 차이 +캐시(Cache)
TCP는 신뢰성이 중요한 파일 교환과 같은 경우에 쓰이고 UDP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.
프로토콜 종류 | TCP | UDP |
---|---|---|
연결 방식 | 연결형 서비스 | 비연결형 서비스 |
패킷 교환 방식 | 가상 회선 방식 | 데이터그램 방식 |
전송 순서 | 전송 순서 보장 | 전송 순서가 바뀔 수 있음 |
수신 여부 확인 | 수신 여부를 확인함 | 수신 여부를 확인하지 않음 |
통신 방식 | 1:1 통신 | 1:1 OR 1:N OR N:N 통신 |
신뢰성 | 높다. | 낮다. |
속도 | 느리다. | 빠르다. |
TCP는 3 way-handshaking 과정을 통해 연결을 설정하고, 4 way-handshaking 과정을 통해 연결을 해제합니다.
TCP와 UDP의 특징 및 차이점 자세히 알아보기(3-way handshaking, 4-way handshaking)
HTTP 메소드는 클라이언트가 서버에게 사용자 요청의 목적을 알리는 '수단'입니다.
종류 | 기능 |
---|---|
GET | 데이터 조회 |
POST | 요청 데이터 처리(보통 데이터 등록 사용) |
PUT | 데이터 변경 (해당 데이터가 없으면 생성) |
PATCH | 일부 데이터만 변경 |
DELETE | 데이터 삭제 |
GET은 데이터를 조회하기 위해 사용되는 방식으로 데이터를 헤더에 추가하여 전송하는 방식입니다.
URL에 데이터가 노출되므로 보안적으로 중요한 데이터를 포함해서는 안됩니다.
POST는 데이터를 추가 또는 수정하기 위해 사용되는 방식으로 데이터를 바디에 추가하여 전송하는 방식입니다.
완전히 안전하다는 것은 아니지만 URL에 데이터가 노출되지 않아 GET 보다는 안전합니다.
처리 방식 | GET 방식 | POST 방식 |
---|---|---|
URL에 데이터 노출 여부 | O | X |
URL 예시 | http://localhost:8080/boardList?name=제목&contents=내용 | http://localhost:8080/addBoard |
데이터의 위치 | Header(헤더) | Body(바디) |
캐싱 가능 여부 | O | X |
멱등성 여부 | O | X |
세션 기반 인증은 클라이언트로부터 요청을 받으면
클라이언트의 상태 정보를 저장하므로 Stateful한 구조를 가지고,
토큰 기반 인증은 상태 정보를 서버에 저장하지 않으므로 Stateless한 구조를 가집니다.
그렇다면 Stateful한 세션 기반의 인증 방식을 사용하게 된다면 어떠한 단점이 있을까요?
1. 서버에 세션을 저장하기 때문에 사용자가 증가하면 서버에 과부하를 줄 수 있어 확장성이 낮습니다.
2. 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다. (세션 하이재킹 공격)
그렇다면 세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 적합한가요?
JWT는 JSON 포맷을 이용하는 Claim 기반의 웹 토큰이며, 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다.
JWT는 헤더(Header).내용(Payload).서명(Signature)로 구성되며 각 파트를 점(.)으로 구분합니다.
JWT(Json Web Token) 란 무엇일까? (서버 기반 인증 / 토큰 기반 인증)
대칭키와 비대칭키는 양방향 암호화 방식이며,
대칭키는 암호화와 복호화에 같은 암호 키를 쓰는 알고리즘입니다.
이는 중간에 누군가 암호 키를 가로채면 암호화된 정보가 유출될 수 있다는 단점이 있는데,
이런 문제를 보완한 새로운 방식이 비대칭키(공개키)입니다.
비대칭키는 암호화와 복호화할 때 키를 서로 다른 키로 사용하는 암호화 알고리즘입니다.
타인에게 절대 노출되어서는 안되는 개인키(private key)와 공개적으로 개방되어 있는 공개키(public key)를 쌍으로 이룬 형태입니다.
서버 자체에 클라이언트가 어떤 사유로 접근을 실패했을 시 적용되는 것이 Connection Timeout입니다.
즉, 접근을 시도하는 시간 제한이 Connection Timeout 되는 것을 말합니다.
클라이언트가 서버에 접속을 성공 했으나 서버가 로직을 수행하는 시간이 너무 길어 제대로 응답을 못 준 상태에서 클라이언트가 연결을 해제하는 것이 Read Timeout입니다.
이 경우는 클라이언트는 해당 상황을 오류로 인지하고, 서버는 계속 로직을 수행하고 있어 성공으로 인지해 양 사이드간 싱크가 맞지 않아 문제가 발생할 확률이 높습니다.