HTTP 란?

HTTP(Hyper Text Transfer Protocol)의 약어로, 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. 프로토콜은 데이터를 주고받기 위한 규칙이며, TCP/IP 위에서 동작하며 80번 포트를 사용하여 통신한다. 첫번째 표준은 HTTP/1.1이며 이후로 HTTP/2 및 HTTP/3가 등장하였지만 여기선 HTTP/1.1의 내용을 정리한다.

HTTP의 특징

1. 비-연결 지향 (Connectionless)

클라이언트가 서버에게 리소스를 요청한 후 응답을 받으면 연결을 끊어버리는 특징이다. 연결을 유지하게 되면 서버에 많은 부담을 줄 수 있기 때문에 상당히 많은 클라이언트에게 요청을 받는 웹 서버의 경우 응답을 처리했으면 연결을 끊는다. 이로 인해 서버의 부담을 줄일 수 있지만, 리소스를 요청할 때마다 연결해야 하는 오버헤드 비용이 발생한다. 이를 해결하기 위해선, 요청 헤더의 Connection: keep-alive 속성으로 지속적 연결 상태(Persistent connection)를 유지할 수 있다. 즉, 요청을 할 때마다 연결하지 않고 기존의 연결을 재사용하는 방식이다. HTTP 1.1 부턴 지속적 연결 상태가 기본이며 이를 해제하기 위해선 명시적으로 요청 헤더를 수정해야 한다.

2. 무상태성 (Stateless)

각각의 요청이 독립적으로 여겨지는 특징으로, 서버는 클라이언트의 상태를 유지하지 않는다. 즉, 각 클라이언트에 맞게 리소스를 응답하는 것은 불가능하기 때문에 각 클라이언트에서 요청하는 유저를 특정할 수 없다. 이를 해결하기 위해, 쿠키나 세션 또는 토큰 방식의 OAuth 및 JWT를 사용하여 요청시 정보를 넘겨 유저를 특정하게 할 수 있다.

크롬 개발자도구로 HTTP 통신 읽기

요청

구글 개발자도구-네트워크 부분에서 주소창에 naver.com 에 접속하면 생기는 일이다.
위 이미지에서 네이버에 naver.com 에 대한 정보를 달라고 요청을 보낸 것이다. 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보내게 된다. 그러면 서버가 요청을 받아 클라이언트가 어떤 것을 요청했는지 파악하게 되는 것이다.

서버도 응답할 때 응답에 대한 정보를 담아 클라이언트로 보낸다. 이런 정보가 담긴 메시지를 HTTP 메시지라고 한다. HTTP 메시지는 시작줄, 헤더, 본문으로 구성된다.

첫 줄이 시작줄이며 www.naver.com 이다. 즉, 요청 메세지의 시작줄은 메서드 주소 버전으로 구성된 것이다.

두 번째 줄부터는 헤더이다. 요청에 대한 정보를 담고 있다. User-Agent, Upgrade-Insecure-Requests 뿐만 아니라 더 많은 헤더들이 존재한다.

그 아래 줄부터는 본문이다. 본문은 요청할 때 함께 보낼 데이터를 담는 부분이다. 하지만 지금 위의 사진에서는 user-agent 아래에는 없다. 왜냐하면 단순히 주소로만 요청을 보내고 있기 때문에 데이터를 보낼 필요가 없기 때문이다.

응답

General 부분의 상태코드 200 부분은 성공적으로 요청과 응답이 이루어졌다는 의미이다.

응답 상태코드 분류

• 1xx (요청에 대한 정보) : 요청을 받았으면 작업을 계속함
• 2xx (성공) : 요청을 성공적으로 수행
  • 200(성공), 201(새 리소스 작성), 202(요청 접수, 아직 처리는 안함)
• 3xx (리다이렉션) : 클라이언트가 요청을 마지기 위해 추가적인 동작을 취해야함
  • 300(여러개의 응답, 선택해야 함), 301(영구이동, 요청한 페이지가 영구적으로 이동됨), 302(임시이동, 현재 응답잉 다른 페이지이긴 하지만 임시적임)
• 4xx (클라이언트 오류) : 클라이언트에 오류가 있음
  • 401(권한 없음), 403(금지됨, 리소스에 대한 권한 없음), 404(찾을 수 없음, 서버에 없는 페이지)
• 5xx (서버 오류) : 서버에 오류가 있음
  • 500(내부 서버오류), 501(요청수행 기능없음, 메서드 인식불가), 503(서비스 사용불가)

Response Header에는 요청에 대한 응답을 담고 있으며 여러 종류가 있다. 그 아래에는 보통 본문이 나와있는데, 응답 메세지에 HTML이 담겨져 있어, 브라우저가 화면에 렌더링할 때 사용하게 된다.

그렇다면 HTTPS 는 뭐지?

HTTPS란 HTTPS(HyperText Transfer Protocol over TLS/SSL)는 기존의 HTTP를 암호화한 프로토콜로 보안이 강화된 버전이다. TCP의 연결이 이루어진 후 TLS를 통해 암호화 설정이 되고 통신을 하는 방식이다. 그리고 HTTP가 80번 포트를 사용하는 반면 HTTPS는 443번 포트를 사용한다.

검색창에 naver.com:80 과 naver.com:443 을 쳐보면 다른 결과를 알 수 있을 것이다. 네이버는 HTTPS 통신을 하기 때문에 포트번호의 차이가 접속유무를 판가름 한다.

HTTPS 주요 개념들

1. 공개키(Public Key)와 비밀키(Private Key)

공개키는 모두가 볼 수 있는 키이며 비밀키는 소유자만이 가지고 있는 키로 암호화/복호화에 사용된다.

2. 대칭키 암호화

서버와 클라이언트가 암호화/복호화에 동일한 비밀키를 사용하는 방식, 키를 공유하는데 어려움이 있으나 속도가 빠르다.

3. 비대칭키 암호화

서버와 클라이언트가 암호화/복호화에 각각 다른 비밀키를 사용하는 방식, 공개키를 통해서 암호화를 하고 비밀키를 통해서 복호화를 한다. 공개키는 공개해도 상관없으니 키 관리에 어려움이 없으나, 반대로 속도가 느리다.

4. 인증기관(Certificate Authority, CA)

클라이언트가 접속을 요청한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들이다. 클라이언트는 서버에 요청을 해서 CA가 발급한 인증서를 받은 뒤 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다. CA의 공개키로 복호화되는 암호화는 오직 CA의 비밀키로 암호화한 경우밖에 없기 때문에 복호화되면 신뢰성이 뛰어나다.

HTTPS 동작방식

HTTPS는 대칭키 암호화를 사용 하며 다음과 같은 과정을 거친다.

1. 클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보낸다. 인증서에는 CA의 비밀키로 암호화된 사이트정보와 공개키가 들어있다.

2. 클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속요청한 서버가 신뢰할만한지 검증한다.

3. 복호화가 되면 인증서가 신뢰할 만하기 때문에 데이터를 주고받을 대칭키를 생성한다.

4. 대칭키를 서버의 공개키로 암호화하여 서버에게 전송한다.

5. 서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화한 뒤 그 대칭키를 통해 데이터를 주고받는다.

참고자료
https://blog.naver.com/chodahi/221406287669
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gkenq&logNo=10185848184
https://www.zerocho.com/category/HTTP/post/5b344f3af94472001b17f2da
https://gingerkang.tistory.com/91