HTTP/HTTPS란? TCP, UDP, HandShake 개념 정리

🧣 HTTP란?

HyperText Transfer Protocol

클라이언트와 서버 간 데이터를 주고 받기 위한 규칙(프로토콜)이다.
여기서 데이터는 텍스트, 이미지, 동영상 등 모든 종류를 말한다.

HTTP 종류에는 TCP 와 UDP 방식이 있으며 80 포트를 사용한다.

TCP

Transmission Control Protocol.

1:1 연결을 지향하며 신뢰할 수 있는 통신을 제공한다.

여기서 1:1은 각각 클라이언트와 서버를 의미한다.
양 단에 연결을 수립한 뒤 데이터를 전송하고 연결을 종료한다.
일반적인 HTTP 통신은 TCP 방식을 따르고 있다.

UDP

User Datagram Protocol.
1:1 혹은 1:N 비연결을 지향하며 신뢰할 수 없는 통신을 제공한다.
여기서 '비연결' 이라는 말은, 말 그대로 서버와 클라이언트가 연결되어 있지 않다는 뜻이다.
TCP 와 달리 연결 설정 과정이 필요 없고, 단지 소켓의 생성과 데이터 송수신 과정만 존재한다.
TCP 와 비교했을 때 신뢰할 수 없지만 연결 수립에 필요한 부하가 없고 보다 빠르다.

 

UDP는 편지와 같다. 편지를 보내기 위해선 편지봉투에 보내는 사람과 받는 사람의 주소 정보를 써야한다.
그리고 우표를 붙여서 우체통에 넣으면 끝이다.
대신 편지의 특성상 편지를 보내고나서 상대방의 수신여부를 확인할 방법은 없다.

TCP	UDP
메시지 수신 확인 가능	메시지 수신 확인 불가
메시지가 보내진 순서를 보장하기 위해 재조립	메시지 도착 순서를 예측할 수 없다.
UDP 보다 속도가 느리다.	TCP 보다 속도가 빠르고 오버헤드가 적다.
통신의 안정성 및 순차적인 전달이 필요한 경우에 사용	오류의 검사 및 수정이 필요 없는 경우에 사용. ex) DNS, VOIP, 온라인게임 등

💡 참고
DNS란?

인터넷에서는 컴퓨터를 식별하기 위해 IP 주소를 사용하는데, 이 숫자만으로는 무엇에 사용되고 있는지 알 수 없다.
그래서 인터넷에서는 IP 주소에 도메인명이라는 이름을 붙혀 알기 쉽게 한다.
IP 주소와 도메인명을 서로 교환하는 장치를 DNS(Domain Name System)이라고 한다.
DNS 서버는 트리 구조로 되어 있다. (자세히)

🧣 HTTP 메시지 구조

• Request Message
  • 클라이언트가 서버에 보내는 메시지
• Response Messgae
  • 서버가 클라이언트에 보내는 메시지

Request Message

Header

• GET /HTTP/1.1
  • HTTP 전송 방법과 프로토콜 버전
• Host
  • 요청하는 서버 주소
• User-Agent
  • OS/브라우저 정보
• Accept
  • 클라이언트가 이해 가능한 컨텐츠 타입
• Accept Language
  • 클라이언트 인식 언어
• Accept-Encoding
  • 클라이언트 인코딩 방법
• Connection
  • 전송 완료 후 접속 유지 정보(keep-alive)
• Content-Type
  • 클라이언트에게 반환되어야하는 컨텐츠 유형
• Content-Length
  • 본문크기

Body

본문은 요청의 마지막 부분에 들어간다.
모든 요청에 본문이 들어가지는 않는다.
GET, HEAD, DELETE 처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없기 때문에 Body 가 없다.
POST, PUT, PATCH 는 업데이트를 위해 서버에 데이터를 전송하므로 Body 가 존재한다.

Response Message

Header

• HTTP/1.1 200 ok
  • 프로토콜 버전과 응답상태
• Access-Control-Allow-Origin
  • 서버에 타 사이트의 접근을 제한하는 방침
• Connection
  • 전송 완료후 접속 유지 정보 (keep-alive)
• Content-Encoding
  • 미디어 타입을 압축한 방법
• Date
  • 헤더가 만들어진 시간
• ETag
  • 버전의 리소스를 식별하는 식별자
• Keep-Alive
  • 연결에대한 타임아웃과 요청 최대 개수 정보
• Last-Modified
  • 웹 시간을 가지고 있다 수정되었을때만 데이터 변경 (캐시연관)
• Server
  • 웹서버로 사용되는 프로그램 이름
• Set-Cookie
  • 쿠키 정보
• Transfer-Encoding
  • 인코딩 형식 지정
• X-Frame-Options
  • frame/iframe/object 허용 여부

Body

본문은 응답의 마지막 부분에 들어간다.
모든 응답에 본문이 들어가지는 않는다.
201, 204과 같은 상태 코드를 가진 응답에는 보통 본문이 없다.

🧣 TCP Handshake

TCP 방식에선 연결 과정이 필요하다고 위에서 언급했었다.
이 때, 연결을 수립할 때는 3way-HandShake,
연결을 종료할 때는 4way-HandShake를 사용한다.

 

HandShake 는 직역하면 '악수'라는 뜻이다.
마치 우리가 다른 사람과의 첫 만남에서 만나서 악수를 요청하고 악수를 받듯이,
정상적인 통신을 하기 전에, 일련의 과정을 거쳐 연결을 성립시키는 것을 말한다.

3 way HandShake

3 way HandShake엔 총 세 가지 과정이 존재한다.
쉽게 아래와 같이 표현할 수 있겠다.

 

A 👉 B : 내 말 들려?
B 👉 A : 잘 들려. 내 말은 들려?
A 👉 B : 잘 들려!

 

1. 클라이언트는 접속을 요청하는 SYN 패킷을 보낸다. 이 때, 클라이언트는 SYN 패킷을 보냄과 동시에 SYN/ACK 응답을 기다리기 위해 SYN_SENT 상태로 변하게 된다.
2. 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락하는 ACK 패킷과 SYN 패킷을 보내고 SYN_RCVD(SYN_RECEIVED) 상태로 변하여 클라이언트가 ACK 패킷을 보낼 때 까지 기다리게 된다.
3. 클라이언트는 서버에 ACK 패킷을 보내고 이 후 ESTABLISHED 상태가 되어 데이터 통신이 가능하게 된다.

각 과정에서 사용되는 용어는 아래와 같다.

 

• SYN
  • synchronize sequence numbers
    연결 확인을 위해 보내는 무작위 숫자값. (내 말 잘 들려?)
• ACK
  • acknowledgements.
    직역하면 '인정하다'라는 뜻이다.
    Client 혹은 Server로 부터 받은 SYN에 1d을 더해 SYN을 잘 받았다는 ACK. (잘 들려!)
• ISN
  • initial sequence numbers.
    Client와 Server가 각각 처음으로 생성한 SYN.
• CLOSED
  • 연결 수립을 시작하기 전의 기본 상태
• LISTEN
  • 포트가 열린 상태로 연결 요청 대기 중
• SYN-SENT
  • SYN 요청을 한 상태
• SYN-RECEIVED
  • SYN 요청을 받고 상대방의 응답을 기다리는 중
• ESTABLISHED
  • 연결의 수립이 완료된 상태.
    서로 데이터를 교환할 수 있다.

4 way HandShake

연결을 끊을 땐 4 way Handshake 과정을 거친다.
과정을 쉽게 표현하면 아래와 같다.

 

A 👉 B : 나는 다 보냈어. 이제 끊자!
B 👉 A : 알겠어! 잠시만~
B 👉 A : 나도 끊을게!
A 👉 B : 알겠어!

 

1. 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 CLOSE() 함수를 호출하게 된다. 이 후 CLOSE() 함수를 호출하면서 FIN segment 를 보내게 되고 클라이언트는 FIN_WAIT1 상태로 변하게 된다.
2. 서버는 클라이언트가 CLOSE() 한다는 것을 알게 되고 CLOSE_WAIT 상태로 바꾼 후 ACK segment 를 전송한다. 즉, 클라이언트가 끊을 것이라는 신호를 받았다는 의미이고 CLOSE_WAIT 를 통해 자신의 통신이 끝날때까지 기다리는 상태가 된다.
3. ACK segment를 받은 클라이언트는 FIN_WAIT2 로 변환되고 이 때 서버는 CLOSE() 함수를 호풀하고 FIN segment 를 클라이언트에게 보낸다.
4. 서버도 연결을 닫았다는 신호를 클라이언트가 수신하면 ACK segment 를 보낸 후 TIME_WAIT 상태로 전환된다. 이 후 모든 것이 끝나면 CLOSED 상태로 변환된다.

각 과정에서 사용되는 용어는 아래와 같다.

• CLOSE
  • 연결 수립을 시작하기 전의 기본 상태 (연결 없음)
• ESTABLISHED
  • 연결의 수립이 완료된 상태, 서로 데이터를 교환할 수 있다.
• CLOSE-WAIT
  • 상대방의 FIN(종료 요청)을 받은 상태. 상대방 FIN에 대한 ACK를 보내고 애플리케이션에 종료를 알린다.
• LAST-ACK
  • CLOSE-WAIT 상태를 처리 후 자신의 FIN요청을 보낸 후 FIN에 대한 ACK를 기다리는 상태.
• FIN-WAIT-1
  • 자신이 보낸 FIN에 대한 ACK를 기다리거나 상대방의 FIN을 기다린다.
• FIN-WAIT-2
  • 자신이 보낸 FIN에 대한 ACK를 받았고 상대방의 FIN을 기다린다.
• CLOSING
  • 상대방의 FIN에 ACK를 보냈지만 자신의 FIN에 대한 ACK를 못받은 상태
• TIME-WAIT
  • 모든 FIN에 대한 ACK를 받고 연결 종료가 완료된 상태. 새 연결과 겹치지 않도록 일정 시간 동안 기다린 후 CLOSED로 전이한다.

🧣 HTTP 통신 과정

1️⃣ 브라우저에서 URL을 분석하여 HTTP Request 메시지를 만들고 웹 서버로 전송한다.
이 때, 브라우저는 OS를 통해 메시지를 전달하는데 어디로 보낼 지는 IP 주소로 지정해야한다.
이 과정에서 웹 서버의 도메인 명을 DNS 서버에 조회하여 IP 주소를 얻는다.

 

2️⃣ 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)은 브라우저로부터 받은 메시지를 패킷 속에 저장한 뒤 LAN 어댑터를 통해 패킷을 LAN 케이블로 송출한다.

 

3️⃣ LAN 어댑터가 송신한 패킷은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착하고 인터넷으로 들어간다.

 

4️⃣ 패킷은 인터넷의 입구에 있는 액세스 회선(통신 회선)에 의해 POP(Point Of Presence, 통신 사용 라우터)까지 운반된다.
이 후 POP를 거쳐 인터넷의 핵심부로 들어가게된다.
그리고 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

 

5️⃣ 패킷은 인터넷 핵심부를 통과하여 웹 서버 측의 LAN에 도착한다.
웹 서버의 방화벽이 도착한 패킷을 검사하고 패킷이 웹 서버까지 가야하는지 가지 앟아도 되는지 캐시 서버가 판단하여 굳이 서버까지 가지 않아도 되는 경우를 골라낸다.
페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.

 

6️⃣ 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다.

메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회신한다.

 

7️⃣ 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

🧣 HTTPS

Hypertext Transfer Protocol Over Secure Socket Layer.
HTTP는 평문(암호화되지 않은 정보)으로 통신을 하기 때문에 보안이 취약한 프로토콜이다.
이 문제 때문에 나타난 것이 HTTPS다.

 

기본 포트는 443이다.
HTTP는 원래 TCP 와 직접 통신했지만, HTTPS에서 HTTP 는 SSL과 통신하고 SSL이 TCP 와 통신한다.
SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.
대칭키와 공개키 암호화 방식을 혼합하여 보안 통신을 구현한다.
대칭키를 공개키 암호화방식으로 교환한 다음에 그 후 통신은 대칭키를 사용하는 방식이다.
공개키 암호에서는 서로 다른 두 개의 키 페어(비밀키, 공개키)를 사용한다. 비밀키는 알려지면 안되는 키이며, 공개키는 누구에게나 알려져도 괜찮은 키다.

과정

1. 클라이언트가 상대의 공개키를 사용해 암호화를 한다.
2. 서버는 자신의 비밀키를 사용해 복호화를 시도한다. 이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없으며 도청에 의해서 키를 빼앗길 걱정이 없다.

하지만 공개키가 진짜인지 아닌지를 서버에서 증명할 수가 없다.
이 문제를 해결하기 위해 인증기관(CA : Certificate Authority)과 그 기관이 발행하는 공개키 증명서가 이용되고 있다.
인증 기관이란 클라이언트와 서버 모두 신뢰하는 제 3자 기관이다.

공개키를 인증 기관에 제출하면 인증 기관은 제출된 공개키에 디지털 서명을 하고 서명이 끝난 공개키를 만든다. 그 후 공개키 인증서에 서명이 끝난 공개키를 담는다.

 

예전엔 HTTPS 인증서에대한 비용이 발생했으나,
Google, Mozilla 등의 재단 및 회사가 'Let's Encrypt'라는 이름의 무료로 HTTPS 인증서를 보급해주는 기관을 만들었다.
이 기관을 통해 손쉽게 HTTPS 인증서를 무료로 사용할 수 있다.

 

---

참조문서

https://jee-goo.tistory.com/entry/Web-HTTP%EB%9E%80
https://seongonion.tistory.com/74