하이퍼텍스트 전송 프로토콜(HTTP)는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜
HTTP는 Stateless한 프로토콜이다.
(서버가 클라이언트의 상태를 기억하지 않는다)
HTTP의 요청/응답 모델은 클라이언트가 서버에 데이터를 요청하고, 서버는 그에 대한 응답을 주는 방식이다.
클라이언트는 요청을 보내고 서버는 요청을 받아 처리한 후 응답을 클라이언트에게 보내며,
이를 통해 웹 서비스 및 애플리케이션에서 데이터를 교환하고 상호작용한다
GET은 데이터를 요청할 때 사용
POST는 데이터를 보낼 떄, 특별한 요청을 할 때 사용GET은 멱등성이 있지만, POST는 멱등성이 있다.
GET도 POST 처럼 메시지 바디를 쓸 수 있지만 권장하지 않는다고 한다.
둘 다 리소스를 수정할 때 사용합니다.
PUT는 데이터를 일괄 변경(기존 데이터 덮어쓰기)할 때 사용하는 메서드입니다.
PATCH는 리소스를 부분 변경할 때 사용하는 메서드입니다.
클라이언트의 요청에 대한 처리가 어떻게 되었는지
응답에서 알려주는 기능을 의미한다.2XX - 성공
3XX - 리다이렉트
4XX - 클라이언트 오류
5XX - 서버 오류
HTTP 전송에 필요한 모든 부가 정보(메타데이터)를 말합니다.
General 헤더(HTTP 메시지의 일반적인 정보),
Reporesentation 헤더(메시지 바디를 표현하는 헤더),
요청 전용 헤더, 응답 전용 헤더가 있습니다.Content-Type: 메시지 바디의 형식(text/html, application/json 등)
Accept: 클라이언트가 선호하는 미디어 타입 전달
HTTP는 상태를 저장하지 않는 다는 걸 의미합니다.
(동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없습니다)이로 인해 HTTP는 시스템의 확장성을 향상시킵니다.
(상태를 유지할 필요가 없으므로 더 많은 요청을 받을 수 있습니다)그러나 상태를 유지해야 하는 경우에는 세션, 쿠키 등의 메커니즘을 사용하여 상태 정보를 관리할 수 있습니다.
하나의 TCP 연결을 통해 여러 개의 HTTP 요청과 응답을 주고받을 수 있도록 해주는 기능입니다.
HTTP/1.0에서 지속적인 연결 기능을 지원하기 위해 Connection, Keep-Alive 헤더가 등장했습니다.
HTTP/1.1부터는 기본적으로 지속적인 연결을 지원하기 때문에, Keep-Alive 헤더는 쓰이지 않습니다.
(Connection 헤더 만으로 연결을 유지하거나 닫습니다)HTTP/2.0부터는 자동으로 지속적인 연결을 보장해 Connection, Keep-Alive 헤더 둘 다 쓰이지 않습니다.
HTTP/1.1 부터 지원되는 기능으로,
클라이언트가 서버에게 여러 개의 요청을 한 번에 보내고, 서버가 응답을 순차적으로 처리하는 기술입니다.이를 통해 네트워크 대기 시간을 최소화하고 서버 부하를 감소시킬 수 있습니다.
HTTP/1.1: 지속적인 연결, 파이프라이닝 기능 추가
(HTTP/1.1의 아쉬운점: HOL Blocking(맨 처음 요청 실패하면 그 다음 요청들 blocking 됨), 헤더의 중복)
HTTP/2.0: HTTP 메시지 전송 방식이 텍스트에서 바이너리 프레임으로 변화됐다.(속도 향상, 오류율 감소)
요청과 응답의 다중화(메시지 간 순서 사라짐)
헤더 압축
서버 푸시(클라이언트가 요청할 데이터를 미리 보내주는 것)
(HTTP/2.0 아쉬운 점: TCP HOL Blocking, HTTPS 사용하려면 TCP 연결 & TLS 연결 해줘야 한다)
(-> TCP 자체의 문제)
HTTP/3.0: TCP를 쓰지 않고, UDP 기반 프로토콜인 QUIC을 사용하는 버전
1. TCP 연결 + TLS 연결을 한번에 해준다.
-> RTT 최소화
2. 독립 스트림(요청별로 다른 스트림 사용한다)
-> 앞 패킷이 손실되도, 관련 없는 패킷은 Blocking 되지 않는다.
(HTTP + SSL)
웹 브라우저와 웹 사이트 간에 데이터를 전송하는 데 사용되는 기본 프로토콜인 HTTP의 보안 버전
클라이언트가 서버와 요청과 응답을 주고 받을 떄,
HTTP 메시지가 암호화 된다.
웹 서버와 웹 브라우저 간의 보안을 위해 만든 프로토콜
응용 계층 데이터의 암호화,
암호화 된 전송 계층 데이터의 복호화SSL은 넷스케이스 회사에서 만든 프로토콜
TLS는 SSL이 표준화 된 프로토콜
암호화와 복호화를 같은 키를 이용해 수행하는 방식
대칭키를 외부 사용자에게 탈취 당할 위험이 있다.
암호화와 복호화를 다른 키를 이용해 수행하는 방식
공개키: 외부에 노출될 수 있는 키
개인키: 외부에 노출하지 않는 키공개키로 암호화하면 개인키로 복호화하고
개인키로 암호화하면 공개키로 복호화한다.
개인키로 암호화하고 공개키로 복호화하면
부인방지 기능을 얻을 수 있다.
(어떤 사람이 암호화 했는지 알 수 있다)
(암호화 한 사람의 공개키로만 복호화 할 수 있기 때문이다)
대칭키 방식에 비해 보안이 강화됐지만,
암호화/복호화 과정이 느리다는 단점이 있다.
데이터의 무결성과 인증을 보장하기 위해 사용하는 기술이다.
(데이터가 변경되지 않았음을 확인하고, 보낸 사람의 신원을 인증하는 데 사용되는 기술)
(전자 서명은 해시 값을 사용한다)SSL Handshake 과정 중에, CA의 인증서를 전자 서명 기술을 통해
서버가 인증됐음을 알 수 있다.
SSL Handshake의 목표
- 클라이언트와 서버가 데이터를 암호화/복호화 할 대칭키 공유
- 서버가 신뢰할 만한 서버인지 인증
- 웹 브라우저(클라이언트)가 웹 서버에게 요청(랜덤한 데이터 전송)
- 서버는 데이터를 받고, 브라우저에게 응답(랜덤한 데이터 + 인증서)
- 브라우저는 CA의 공개키를 이용해 인증서를 복호화 한다.
-> 서버의 공개키 획득 & 서버의 인증을 확인- 브라우저가 두 랜덤한 데이터와 서버의 공개키를 이용해 대칭키를 생성한다.
그리고 대칭키를 서버의 공개키를 이용해 암호화 하고 서버에게 보낸다.- 서버는 받은 데이터를 자신의 개인키를 이용해 복호화 한다. -> 브라우저로부터 대칭키를 얻는다. & 브라우저에게 승인 메시지를 보낸다.
위 과정을 통해 클라이언트와 서버는 대칭키를 공유하게 되고, 클라이언트는 서버가 인증됐음을 확인한다.
호스트의 도메인 네임과 IP주소를 매핑해주는 시스템입니다.
인터넷의 특정 웹사이트에 접속할 때, 사용자가 입력한 호스트 네임을 해당 호스트의 IP 주소로 변환하여 통신을 가능하게 합니다.
빠른 응답을 제공하기 위해 DNS는 UDP 기반으로 동작하고 DNS 서버들은 요청 정보를 캐싱해둡니다.
- 사용자가 브라우저에서 웹사이트의 주소(도메인 네임)
- 로컬 DNS 캐시 조회
- 로컬 DNS 서버 쿼리(ISP가 제공하는 DNS 서버)
- 루트 DNS 서버 쿼리
- TLD DNS 서버 쿼리(.com .net 등)
- 도메인의 DNS 서버 쿼리
- 도메인의 DNS 서버에서 IP 주소 찾는다
- 로컬 DNS 서버의 응답
재귀적 질의, 반복적 질의가 있습니다.
재귀적 질의는 도메인 네임에 해당하는 IP주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP 주소를 물어보는 것을 뜻합니다.
반복적 질의는 IP 주소를 찾기 위해 반복적으로 질의하는 것입니다.
로컬 DNS가 루트 DNS에게 IP주소를 물어봤는데 없으면 TLD DNS에게 물어보고 또 없으면 authoriative DNS에 반복적으로 물어보는 것을 예시로 들 수 있습니다.
DNS는 일반적으로 작은 쿼리와 짧은 응답을 전송하기 때문에, UDP를 사용하여 속도를 향상시킵니다.
DNS는 연결 상태를 유지할 필요가 없고, TCP보다 많은 클라이언트를 수용할 수 있는 UDP를 사용합니다.
DNS 레코드는 호스트 이름과 관련된 정보를 포함하는 데이터입니다.
대표적으로 A, CNAME가 있습니다.호스트명을 IP 주소로 변환하는 질의 (A 레코드):
가장 일반적인 질의 종류로, 호스트명(도메인 이름)을 해당 호스트의 IPv4 주소로 변환합니다. 이는 사용자가 웹 브라우저에 도메인 이름을 입력하여 웹사이트에 접속할 때 사용됩니다.도메인 이름에 대한 다른 정보 조회 (CNAME 레코드):
특정 도메인 이름을 다른 도메인 이름으로 매핑하는 데 사용됩니다.