# [network] HTTP & HTTPS

## HTTP(**Hypertext Transfer Protocol)**란?

HTTP는 **인터넷**에서 하이퍼텍스트를 교환하기 위한 통신 규약이다. 
대표적으로 주고 받는 데이터 형태는 HTML이다.

- OSI 7계층중 **응용계층**에 속하는 프로토콜
- TCP/IP 위에서 작동
- Request와 Response로 통신
- **비연결지향(Connectionless)**
    - HTTP는 클라이언트가 요청(Request)을 서버에 보내고, 서버는 클라이언트에게 적절한 응답(Response)을 주고 `연결(Connection)을 끊는 특성`이 있다.
- **상태없음(Stateless)**
    - 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 `상태 정보는 유지하지 않는 특성`이 있다.
- Method, Path, Version, Header, Body 등으로 구성됨
    ![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https://blog.kakaocdn.net/dn/bkdJ4Q/btqK6AXLEtC/jBZzMuJBWzdLYmqILo5Ri1/img.png)
    

## HTTP 프로토콜의 특징 : 무상태(Stateless)란?

`stateful`은 서버가 클라이언트의 이전 상태를 보존한다는 의미이다. 

반대로 무상태(`stateless`)는 서버가 클라이언트의 이전 상태를 보존하지 않는다는 의미이다. 

> 승객: 서울에서 수원 가는 버스는 얼마인가요?
직원: 2500원입니다.
> 
> 
> 승객: 결제할께요.
> 직원: ?? 무엇을 구매하시는 건가요?
> 
> 승객: 아까 말했잖아요. 서울에서 수원 가는 버스요!!
> 직원: … 왜 화내시죠?
> 

![](https://blog.kakaocdn.net/dn/bYJgPP/btqI6ObE7N9/T0pDgFs3KeGGMRF4UrI1T1/img.png)

기본적으로 기억상실증과 같다고 생각하면 좋다!

비연결지향이라는 특성 덕분에, 계속해서 커넥션을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 아주 큰 장점이다. 

그런데 문제는, 로그인을 통해 볼 수 있는 서비스 등 클라이언트가 정보를 유지해야 하는 Stateful한 성격의 서비스가 아주 많아졌다는 것이다. 그래서 `쿠키` 와 `세션` 혹은 JWT를 사용함으로써 이러한 단점을 보완한다.

기본적으로 HTTP는 단순한 **텍스트 교환**이므로, 속도가 빠르다는 장점이 있지만 누군가 네트워크에서 신호를 가로채면 내용이 그대로 노출되는 **보안 이슈**가 존재한다.

![](https://cdn.ppomppu.co.kr/zboard/data3/2022/1021/1666335376_9156_1d8c5dca87da08e094cccd1d16176199.jpeg.jpg)

## HTTPS

HTTPS(HyperText Transfer Protocol Secure)

: 인터넷 상에서 정보를 암호화하는 **SSL** (보안 소켓 계층) 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약

HTTP와 달리 텍스트를 암호화한다. (**공개키** 암호화 방식으로)

## 배경지식 : 대칭키 암호화 vs 비대칭키 암호화

![](https://www.lgcns.com/wp-content/uploads/2021/11/2306483B5805746232.jpg)

- 대칭키 암호화
    - 클라이언트와 서버가 **동일한 키**를 사용해 암호화/복호화를 진행함
    - 공개키를 안전하게 교환하는 게 가장 중요한 부분.
    - 키가 노출되면 매우 위험하지만 연산 속도가 빠름
- **비대칭키 암호화**
    - 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
    - 키가 노출되어도 비교적 안전하지만 연산 속도가 느림
    - **공개키로 암호화**를 하면 **개인키로만 복호화**할 수 있다. 
    → 개인키는 나만 가지고 있으므로, 나만 볼 수 있다. 내용 자체의 보안성을 유지할 수 있다.

## HTTPS 흐름

1. 클라이언트(브라우저)가 서버로 최초 연결 시도(TCP Hand-Shaking)를 함
2. 서버는 SSL 인증서(**공개키**가 담겨있음)를 브라우저에게 넘겨줌
3. 브라우저는 인증서의 유효성을 검사 → 대칭키를 발급
    
    여기서 대칭키는 주고 받는 데이터를 암호화하기 위해 사용되는 키
    
    데이터 간의 교환에는 빠른 연산 속도가 필요하기 때문
    
4. 브라우저는 이 **대칭키를 보관**하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함
5. 서버는 **개인키**로 암호화된 대칭키를 복호화하여 키를 얻음
    
    즉, 2~5의 과정은 위에서 설명한 **공개키 암호화**에 해당!
    
    주로 쓰이는 공용 열쇠(세션키)를 전달하기 위해 서버의 개인키가 쓰이는 것. 
    
6. 이제 클라이언트와 서버는 동일한 대칭키를 공유하므로 데이터를 전달할 때 이 대칭키를 이용해서 암호화/복호화를 진행하며 통신

아래는 대화 버전.

> 클라이언트 : “안녕하세요? (경계중)”
> 
> 
> 서버 : “(당당) 우리 SSL 인증된 사이트야. 공개키도 같이 던져줄께”
> 
> 클라이언트 : “유효한거 맞아요? … 맞네. 이제 말 놓자. 
> 우리도 대칭키 하나 발급할건데, 앞으로 통신할 때 데이터들은 이걸로 보호해서 보낼거야. 
> 너쪽 공개키로 한번 잠근거니까 너 개인키로 알아서 풀어”
> 
> 서버 : “ㅇㅋ 내 개인키로 잘 풀리네. 확인”
> 

![](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https://blog.kakaocdn.net/dn/cCodLU/btrqRZnoOFq/e6kFHjADoVby70466Jkq51/img.png)

## HTTPS 사이트를 만드는 과정과 SSL

1. 서버 개발자는 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2. 신뢰할 수 있는 **CA**(Certificate Authority) 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
3. 계약 완료된 CA 기업은 해당 기업의 이름, 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 서버에게 제공한다.
4. 서버는 이제 암호화된 SSL 인증서를 갖게 되었다. 
이제 서버는 최초 연결시도마다 이 인증서를 클라이언트에게 건내준다.
5. 클라이언트가 `index.html` 파일을 달라고 서버에 요청했다고 가정하자. 
처음 연결 시도에선 HTTPS 요청이 아니기 때문에 
CA기업이 자신의 개인키로 서버의 정보를 암호화한 인증서를 받게 된다.
6. 브라우저는 CA기업의 공개키로 **인증서를 해독**한 뒤 **서버의 공개키**를 얻게 된다.
    
    CA 기업의 공개키는 브라우저가 이미 알고있다! (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문)
    

![](https://www.stevenjlee.net/wp-content/uploads/2020/11/image-4.png)

# 참조

https://mangkyu.tistory.com/98

[https://gyoogle.dev/blog/computer-science/network/HTTP & HTTPS.html](https://gyoogle.dev/blog/computer-science/network/HTTP%20&%20HTTPS.html)

https://universitytomorrow.com/22

https://liveyourit.tistory.com/183

[https://gyoogle.dev/blog/computer-science/network/HTTP & HTTPS.html](https://gyoogle.dev/blog/computer-science/network/HTTP%20&%20HTTPS.html)

https://nukw0n-dev.tistory.com/11?category=940859

[https://www.stevenjlee.net/2020/11/01/이해하기-http-vs-https-그리고-ssl-secure-socket-layer/](https://www.stevenjlee.net/2020/11/01/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-http-vs-https-%EA%B7%B8%EB%A6%AC%EA%B3%A0-ssl-secure-socket-layer/)