S3) Unit 6. [네트워크] HTTP & HTTPS

📣  HTTP

✔️ HTTP/1.1, HTTP/2 는 TCP 기반이며 HTTP/3은 UDP 기반 프로토콜이다.

 

📣  HTTP의 특징

1️⃣ 클라이언트 서버 구조

➰ Request Response 구조

➰ 클라이언트는 서버에서 요청을 보내고, 응답을 대기

➰ 서버가 요청에 대한 결과를 만들어 응답

 

2️⃣ 무상태 프로토콜(Stateless), 비연결성(Connectionless)

➰ 서버가 클라이언트의 상태를 보존하지 않는다.

➰ 장점 : 서버 확장성이 높다.

➰ 단점 : 클라이언트가 추가 데이터를 전송한다.

✚ Stateful vs Stateless

Stateful	Stateless
항상 같은 서버가 유지되어야 한다.	아무 서버나 호출해도 된다.
서버에 장애가 생긴다면 유지되던 상태 정보가 다 날아가 버리므로 처음부터 서버에 요청해야 한다.	서버에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 다시 요청할 필요가 없다.
	스케일 아웃 : 무한한 서버 증설이 가능하다.
로그인이 필요한 서비스	로그인이 필요없는 단순한 서비스 소개 화면
TCP/IP (클라이언트가 요청을 보내지 않더라도 계속 연결을 유지한다)	HTTP (실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.

➰ HTTP는 기본이 연결을 유지하지 않는 모델로, 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우 이 특징은 효율적으로 작동한다.

➰ 하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 한계가 있으므로 지금은 HTTP 지속 연결로 문제를 해결한다.

➰ HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다.

 

3️⃣ HTTP 메세지

 

4️⃣ 단순함, 확장 가능

 

---

📣  HTTP 헤더

✔️ HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다.

 

1️⃣ 표현 헤더 : 표현 데이터를 해석할 수 있는 정보를 제공

✔️ HTTP 메시지는 헤더와 바디로 구분할 수 있으며, 바디에서 데이터 메시지 본문을 통해서 표현 데이터를 전달한다.

➰ 데이터를 실어나르는 부분은 Payload 라고 한다.

➰ 표현 : 요청이나 응답에서 전달할 실제 데이터

➰ 표현 헤더는 요청, 응답 둘 다 사용한다.

 

2️⃣ 요청(Request)에서 사용되는 헤더

✔️ From : 유저 에이전트의 이메일 정보

✔️ Referer : 이전 웹 페이지 주소

✔️ User-Agent : 유저 에이전트 애플리케이션 정보

✔️ Host : 요청한 호스트 정보(도메인)

✔️ Origin : 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타낸다.

✔️ Authorization : 인증 토큰(ex. JWT)을 서버로 보낼 때 사용하는 헤더

 

3️⃣ 응답(Response)에서 사용되는 헤더

✔️ Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

✔️ Date : 메시지가 발생한 날짜와 시간

✔️ Location : 페이지 리디렉션

✔️ Allow : 허용 가능한 HTTP 메서드

✔️ Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

 

4️⃣ 콘텐츠 협상 헤더

✔️ Accept : 클라이언트가 선호하는 미디어 타입 전달

✔️ Accept-Charset : 클라이언트가 선호하는 문자 인코딩

✔️ Accept-Encoding : 클라이언트가 선호하는 압축 인코딩

✔️ Accept-Language : 클라이언트가 선호하는 자연 언어

 

➰ 협상 헤더는 요청 시에만 사용한다.

---

📣  HTTPS

✔️ HTTP Secure : 기존의 HTTP 프로토콜을 더 안전하게 사용할 수 있음을 의미한다.

➰ HTTP와 달리 요청과 응답으로 오가는 내용을 암호화한다.

➰ HTTP 요청 및 응답은 제 3자가 탈취한 경우 데이터를 그대로 볼 수 있다.

 

📣  암호화 방식

1️⃣ 대칭 키 암호화 방식

✔️ 하나의 키만 사용하며, 암호화할 때 사용한 키로만 복호화가 가능하다.

➰ 연산속도가 빠르지만 키를 관리하는데 신경을 많이 써야 한다.

 

2️⃣ 공개 키(비대칭 키) 암호화 방식

✔️ 두 개의 키를 사용하며 암호화할 때 사용한 키와 다른 키로만 복호화가 가능하다.

➰ 각각을 공개 키, 비밀 키라고 부르며 공개 키로 암호화한 데이터를 보내면 비밀 키를 가진 사람만 그 내용을 복호화할 수 있다.

➰ 공개 키는 누구나 접근할 수 있지만 비밀 키는 서버가 해킹당하지 않는 이상 탈취되지 않는다.

➰ 보안성이 더 좋지만, 복잡한 연산이 필요해서 더 많은 시간을 소모한다.

 

📣  SSL/TLS 프로토콜

✔️ HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 혹은 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행한다.

➰ SSL이 표준화되며 바뀐 이름이 TLS이며, 같은 프로토콜이라고 봐도 된다.

➰ CA를 통한 인증서를 사용하며 대칭 키, 공개 키 암호화 방식을 모두 사용한다.

 

✔️ 인증서와 CA(Certificate Authority)

➰ HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다.

➰ 인증서는 서버의 신원을 보증해주며, 이를 발급해주는 공인된 기관들을 CA라고 한다.

➰ 서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달한다. CA는 이를 CA의 비밀 키로 암호화해서 인증서를 발급한다. 서버는 클라이언트에게 요청을 받으면 CA에게 발급받은 인증서를 보내준다. 이때, 사용자가 사용하는 브라우저는 CA들의 리스트와 공개키를 내장하고 있다. 우선 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고, 맞다면 CA의 공개 키를 사용해서 인증서의 복호화를 시도한다.

➰ CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개키로만 복호화가 가능하다.

➰ 복호화가 성공적으로 진행된다면, 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 된다.

➰ 복호화가 실패한다면, 이는 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 확인하게 된다.

 

✔️ 대칭 키 전달

➰ 사용자는 서버의 인증서를 성공적으로 복호화하여 서버의 공개 키를 확보했다. 이 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고 받을 때 사용하게 된다. 대칭 키는 속도는 빠르지만, 탈취의 위험성이 있다. 하지만 클라이언트가 서버로 대칭 키를 보낼 때 서버의 공개 키를 사용해서 암호화해서 보내준다면 탈취 위험성이 줄어든다.

➰ 클라이언트는 데이터를 암호화하여 주고 받을 대칭 키를 생성한다. 생성한 대칭 키를 서버의 공개 키로 암호화하여 전달한다. 서버는 전달받은 데이터를 비밀 키로 복호화하여 대칭 키를 확보한다. 이렇게 되면 서버와 클라이언트는 동일한 대칭 키를 갖게 된다.

➰ 이제 HTTPS 요청을 주고 받을 때 이 대칭 키를 사용해서 데이터를 암호화하여 전달하게 된다.