정리정리정리
공부하며 정리한 내용입니다! 혹시 오류 사항이 있다면 둥글게 말씀해주세요 :)
1. HTTP(Hypertext Transfer Protocol)
web 상에서 클라이언트와 서버 간 통신을 위한 프로토콜
구글링해서 데려온 이미지
HTTP는 위의 그림에서도 알 수 있듯이 Application layer에서 작동하는 프로토콜이며,
이론상 신뢰성 있는 연결만 해줄 수 있다면 Tranport layer는 어떤 것을 사용해도 상관없다
그렇다면, Transport layer에서 사용하는 TCP/UDP 프로토콜에 대해 간단히 알아보자
|
TCP
(신뢰성은 확보, 지연은 줄이기 힘듦)
|
|
UDP
(데이터 전송에 집중한 설계)
|
|
연결형
|
연결방식
|
비연결형
|
|
가상 회선 방식
|
패킷 교환
|
데이터그램 방식
|
|
O
|
전송 순서 보장
|
X
|
|
높음
|
신뢰성
|
낮음
|
|
느림
|
전송 속도
|
빠름
|
즉, TCP는 신뢰성을 확보하지만 필연적으로 지연을 줄이기 힘든 구조이며,
UDP는 데이터 전송에 집중한 설계로 별도의 기능을 지원하지 않는다.
때문에, UDP는 원하는 기능의 구현이 가능하다
이제 HTTP의 버전별 특징을 알아보도록 하자
HTTP/1.0_TCP 기반
1번 request에 대한 response가 와야 2번 request를 보내는 방식이다.
connection 하나 당 한 개의 request/response만 처리 가능하다.
-> 당연히 성능이 저하되고 서버 부하 비용은 증가한다.
HTTP/1.1_TCP 기반
Persistnet connection이라는 개념을 도입했다.
-> 일정 timeout동안 커넥션을 닫지 않는 방식
+ pipelining 도입 : 하나의 connection에서 응답을 기다리지 않고 순차적인 request를 연속적으로 보내
그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄인 방식
- Head of blocking : 첫번째 request를 서버에서 처리하는 시간이 너무 오래 걸리면 2, 3번째 request도
기다려야함
- 연속된 요청의 경우 header의 값이 같은 경우가 많음에도 불구하고, 중복된 내용을 그대로 전송함 -> 주고
받는 데이터의 양이 커짐
HTTP/2_TCP 기반
HTTP/1.1의 성능향상에 초점, 표준의 대체가 아닌 확장적 개념
HTTP 메시지 전송 방식의 변화 -> binary framing 계층 사용
+ 파싱/전송 속도가 향상 되고 오류 발생의 가능성이 낮아짐
스트림 안에 프레임들이 들어가 합쳐져서 request/response 메시지가 됨 -> 다중화가 가능해짐
+ 메시지가 프레임으로 쪼개짐 -> msg의 순서가 사라짐 -> head of blocking 문제가 사라짐
+ stream prioitization : 리소스간 우선 순위 설정이 가능
+ server push : client가 요청하지 않은 리소스를 서버에서 알아서 push 해서 보내줌
ex) html request가 왔으니 js랑 css request도 오겠지? 그냥 미리 줘버리자!라고 서버에서 판단
+ Header compression : 헤더의 크기를 줄여 페이지 로드 시간 감소
-> static dynamic table 개념 도입 : 중복을 검출해 중복된 부분은 인덱스만 뽑고 중복되지 않은 데이터는
허프만 인코딩으로 인코딩을 해서 압축
HTTP/3(QUIC)_UDP 기반
+ 전송속도 향상 : 첫 연결 설정에서 필요한 정보와 함께 데이터 전송
-> 연결 성공 시 설정을 캐싱해 다음 연결 때 바로 성립 가능
+ connection UUID라는 고유 식별자로 서버와 연결 : connection 재수립이 필요 X
+ TLS 기본 적용, IP spoffing/Replay Attack 방지 : 보안성 향상
+ 독립 stream -> 향상된 멀티 stream
하지만, HTTP는 암호화 되지 않음 -> 서버와 클라이언트가 주고 받는 msg 감청이 매우 쉽다
때문에 HTTPS 가 등장하게 되었다
2. HTTPS_HTTP over Secure socket layer
HTTPS에서 마지막 S는 Secure socket layer의 약자로, 보안이 강화된 HTTP를 의미한다
그렇다면 HTTPS와 SSL은 무슨 관계일까?
같다면 같고 다르다고 생각하면 다르다고 볼 수 있다.
SSL위에서 HTTPS가 동작하기 떄문이다.
쉽게 말해서 SSL이라는 보안 체계 위에서 동작하는 HTTP라 생각 하면 된다.
(이 SSL 위에서 HTTP가 동작하면 HTTPS, FTP가 동작하면 SFTP가 된다)
그렇다면 어떠한 원리로 정보를 더 안전하게 주고 받을 수 있을까?
여기서 바로 public key cryptography 개념이 등장한다.
암호화를 위해선 public-private key 쌍이 필요한데 어떻게 안전하게 공유할 수 있을까? 라는 생각에서 출발하게 되는 것!
클라이언트와 서버의 신뢰성 있는 connection을 위해 사용된다(handshake)
- 클라이언트가 서버에게 무작위 데이터를 보낸다
- 서버도 무작위 데이터를 생성해 인증서와 함께 클라이언트에게 보낸다
- 무작위 데이터와 인증서를 받은 클라이언트는 받은 인증서가 진짜인지 브라우저에 내장된 CA로 확인
- CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화 되어있다/CA 리스트에 해당하는게 없다면 브라우저에 not secure가 뜸
- 성공적으로 인증이 된다면 서버의 public key를 알 수 있다
- 서버의 public key로 받은 데이터를 복호화 했을 때, 클라이언트가 보낸 무작위 데이터와 동일하다면
클라이언트와 서버는 신뢰성 있는 연결을 맺게 되는 것이다(안전한 키교환에 성공한다)
이 후, asymmetric/symmetric 방식이 혼용된다
모든 데이터에 asymemtric한 방식을 사용한다면, 컴퓨터에 무리가 가기 떄문이다.
때문에 symmetiric key를 공유할때 asymmetirc한 방식을 사용하고
handshake 시 사용한 무작위 데이터를 혼합해 임시 키를 만든다.
임시키는 서버의 public key로 암호화 돼 서버로 보내진 다음 동일한 대칭키가 만들어 지게 된다
이 과정이 지나면 asymmetric key를 서버/클라이언트만 가지고 있기 때문에
안전하게 데이터 교환이 가능하다
또한 이 키교환 과정에 Diffie-Hellman 방식이 많이 사용되는 추세이다.
* Diffie-Hellman (암호화 목적X, just key exchange algorithm)
- 이산 수학 문제에서 기인
- g, p 그리고 gk mod p가 주어졌을 때,
- k를 찾아 내는 문제
- 공격자에게 모든 정보를 알려줘도 k를 찾기 위해선 brute force attack 뿐
https://developer.mozilla.org/en-US/docs/Web/HTTP
https://developer.mozilla.org/ko/docs/Web/HTTP
https://www.youtube.com/watch?v=H6lpFRpyl14&feature=share&si=ELPmzJkDCLju2KnD5oyZMQ
MDN이야 뭐 워낙 교과서 느낌이니까 잘 봤구
일단 원문 다큐먼트 읽고 이해 안되면 번역 보는게 좀 더 매끄러운 것 같다
유튜브 이 분은 암호화 방식도 되게 이해하기 쉽게 설명해주셔서 편하게 봤다!
나는 보안 강의 시간에 머리 싸매면서 이해했는데
역시 세상이 발전하면서 떠먹여주시는 고마운 분들이 늘었다
댓글