[네트워크] HTTP, HTTPS, DNS

HTTP란

- 웹 브라우저가 서버랑 통신하기 위해 만들어진 규칙

 

HTTP의 요청/응답 모델

- HTTP 요청 모델

1. HTTP 요청 메서드 (GET, POST..)

2. URL 경로

3. HTTP 프로토콜 버전 정보

4. 헤더들

5. HttpRequest Body

 

- HTTP 응답 모델

1. HTTP version

2. Status Code (200, 201...)

3. Status Text (OK, CREATED..)

4. 헤더들

5. HttpResponse Body

 

HTTP 메서드

- GET

1. GET은 주로 읽기, 검색을 할 때 사용되는 메서드

2. GET은 멱등하다

3. 200 OK를 주로 반환 받는다.

4. 요청할때 주로 QueryString에 데이터를 담아 보낸다.

5. Body가 없다.

6. 캐시 가능

 

- POST

1. POST는 새로운 리소스를 생성 할때 사용한다.

2. POST는 멱등하지않다.

3. 보통 리소스가 생성되면 201 CREATED 반환한다.

4. 요청할때 주로 HttpBody에 데이터를 담아 보낸다.

 

- GET vs POST

캐시	⭕️	❌
브라우저 기록	⭕️	❌
북마크 추가	⭕️	❌
데이터 길이 제한	⭕️	❌
HTTP 응답 코드	200(Ok)	201(Created)
언제 주로 사용하는가?	리소스 요청	리소스 생성
리소스 전달 방식	쿼리스트링	HTTP Body
idempotent	⭕️	❌

 

- PUT

1. 리소스를 업데이트 할때 사용

2. 리소스를 미리 알고 있어야 함

3. PUT은 멱등하다

 

- PATCH

1. 리소스를 일부 업데이트 할때 사용

2. 리소스를 미리 알고 있어야 함

3. PATCH는 멱등하지 않다.

 

HTTP 헤더

- 요청 헤더

Host : 요청하는 서버의 도메인 정보를 포함 (ex. Host: www.example.com)

User-Agent : 요청을 보내는 클라이언트의 브라우저나 OS 정보를 포함

Accept : 클라이언트가 받을 수 있는 응답 콘텐츠 타입을 지정 (ex. Accept: text/html, application/json)

Authorization : 인증 토큰(JWT 등) 또는 Basic 인증 정보를 포함

Content-Type : 요청 본문의 데이터 형식을 지정

Cookie : 클라이언트가 서버로 전송하는 쿠키 정보를 포함

 

- 응답 헤더

Set-Cookie : 클라이언트가 저장해야 할 쿠키 정보를 전달

Cache-Control : 캐싱 정책을 정의하여 브라우저 또는 프록시 서버가 응답을 캐싱할 수 있도록 함

(ex. Cache-Control: no-cache, no-store, must-revalidate)

Location : 3xx 리디렉션 응답에서 이동할 URL을 지정

 

 

HTTP의 무상태성(Stateless)

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

- 무상태성으로써 무한한 서버 증설 가능

- 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지

 

Keep-Alive

-  single connection으로 여러 request, response 들을 주고 받을 수 있게끔 해주는 persistent connection을 만드는 기능

 

- TCP Keep alive : "연결 상태 확인"이 주 목적

1. 죽은 peer 구분

2. 비정상 종료 방지

 

- HTTP Keep alive :  "연결 재사용"이 주 목적

1. 여러 HTTP 요청을 하나의 연결에서 처리

 

HTTP 파이프라이닝

- HTTP Request 들은 연속적으로 발생하며, 순차적으로 동작

- HTTP 1.1에서 시작

 

HTTP/1.1, HTTP/2, HTTP/3

HTTP 1.1

- Persistent Connection 추가 : 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 일정 시간동안 연결 상태를 유지

- Pipelining 추가 : 앞 요청의 응답을 기다리지 않고 순차적으로 요청 전송

- 문제점 : 앞의 요청(패킷)에 대한 응답이 늦어지면 뒤의 모든 요청들은 모두 blocking되어 응답이 지연

 

HTTP 2.0

- Multiplexed streams 추가 : HTTP 1.1의 Pipelining은 한번의 연결에서 여러 요청을 보낼 수는 있었지만 동시에 여러 요청을 처리하진 못했는데 HTTP 2.0은 동시 요청 처리

- 헤더 압축 : 요청과 응답 헤더의 메타데이터를 압축해서 기존의 연속된 요청에서의 중복 헤더로 인한 오버헤드 문제를 해결

 

 

 

HTTP 3.0

-  TCP기반이 아닌 UDP 기반

- 초기 연결(통신 시작) 시 3-way handshaking 과정을 거치지 않아 1-RTT만 소요

 

 

HTTPS

- HTTP 프로토콜로 데이터를 주고 받는 과정에 ‘보안’ 요소가 추가

- 서버와 클라이언트 사이의 모든 통신 내용이 암호화

-  SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화

- 443 포트 사용

 

SSL(보안 소켓 계층)  /  TLS(=업그레이드 된 SSL, 전송 계층 보안)

- 웹에서 전송되는 데이터를 암호화

- 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인

 

 

공개키 암호화 방식 / 전자 서명

- 공개키로 암호화 → 개인키로 복호화 : 공개키 암호화

- 개인키로 서명 → 공개키로 검증 : 전자 서명

 

 

SSL/TLS 핸드셰이크

- RSA 키 교환 알고리즘이 사용

1. 클라이언트(브라우저)가 서버에 접속 요청

2. 서버가 인증서(공개키 포함)를 클라이언트에 전달

3. 클라이언트가 인증서 검증 (신뢰할 수 있는 기관에서 발급했는지 등)

4. 클라이언트가 비밀키로 암호화된 세션 키를 만들어 서버에 전송

5. 서버는 비밀키로 복호화해서 세션 키를 얻음

6. 이제 양쪽 모두 같은 세션 키로 대칭 암호화 통신 시작

- 인증서 = 서버 정보 + 공개키 + 인증기관 정보

전제 조건

동작 방식

 

DNS (Domain Name System)

- 'naver.com'과 같은 도메인 이름을 웹 브라우저에 입력하는 경우 DNS는 해당 사이트의 올바른 IP 주소를 찾는 역할

 

DNS의 질의 종류

- 재귀적 질의 : 결과물(IP 주소)를 돌려주는 작업

- 반복적 질의 :  다른 DNS 서버에게 쿼리를 보내어 응답을 요청하는 작업

 

DNS에 UDP 프로토콜을 사용하는 이유

- DNS는 단순히 도메인 네임으로 IP를 찾는 역할을 함으로 역할이 단순하고 트래픽이 많기 때문에 연결상태를 유지해야하는 TCP보단 UDP 프로토콜을 사용한다.

- DNS는 신뢰성보다 속도가 더 중요함

 

 

출처

https://rachel-kwak.github.io/2021/03/08/HTTPS.html

HTTPS란? (동작방식, 장단점)

 

https://hanamon.kr/dns%EB%9E%80-%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%84%A4%EC%9E%84-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B0%9C%EB%85%90%EB%B6%80%ED%84%B0-%EC%9E%91%EB%8F%99-%EB%B0%A9%EC%8B%9D%EA%B9%8C%EC%A7%80/

DNS란? (도메인 네임 시스템 개념부터 작동 방식까지) - 하나몬