도메인 네임과 DNS
인터넷에서 네트워크 장치를 식별하기 위해 사용하는 시스템으로, 사용자가 기억하기 쉬운 도메인 네임(domain name)을 통해 실제 IP 주소로 접근할 수 있도록 돕는 역할을 함
- IP 주소
- 네트워크 상의 호스트(컴퓨터, 서버 등)를 식별하기 위해 사용하는 숫자 기반 주소
- IPv4: 192.168.0.1 형태 / IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 형태
- 예시) 웹 서버의 IP 주소가 142.250.190.46이라면, 이 주소를 통해 해당 서버에 접근 가능
- 도메인 네임(domain name)
- 사람이 읽기 쉬운 문자열 형태의 호스트 정보로, IP 주소와 대응됨
- 예시) www.google.com은 내부적으로 특정 IP 주소와 연결됨
- 도메인 네임은 계층 구조로 구성됨
- 최상위 도메인(TLD): .com, .org, .kr
- 2차 도메인: google, naver
- 서브 도메인: www, mail
- 네임서버 (name server)
- 도메인 네임과 IP 주소를 매핑하는 정보(레코드)를 저장하고 관리하는 서버
- 특정 도메인 요청이 들어오면 해당 도메인의 IP 주소 정보를 제공함
- 네임 서버는 분산되어 관리됨
- 예시) ns1.example.com과 같은 네임 서버가 도메인 example.com의 정보를 관리
- DNS 서버 (DNS Server)
- Domain Name System(DNS)은 도메인 네임을 IP 주소로 변환하는 시스템
- 네임 서버의 역할을 수행하며, 도메인 네임과 IP 주소의 쌍을 저장하고 조회하는 기능을 제공
- 인터넷에서 DNS 서버는 계층적으로 구성됨
- 루트 DNS 서버 -> TLD 서버(.com, .kr 등) -> 도메인 네임에 맞는 네임 서버
- 리졸빙 (resolving)
- 사용자가 입력한 도메인 네임을 통해 IP 주소로 변환하는 과정
- 예시) 사용자가 www.google.com에 접속할 때 리졸빙을 통해 내부적으로 142.250.190.46 같은 IP 주소로 요청이 전송됨
리졸빙 과정 (DNS 조회)
- 사용자가 www.example.com 입력
- 로컬 DNS 서버에서 캐시 확인
- 캐시에 없을 경우 루트 DNS 서버, TLD 서버, 최종 네임 서버를 통해 IP 주소 확인
- 도메인 네임에 해당하는 IP 주소 반환
- 웹 브라우저가 해당 IP 주소로 요청을 보냄
- 전체 주소 도메인 네임 (FQDN, full qualified domain name)
- 도메인의 전체 경로를 명확히 지정하는 도메인 네임
- 인터넷에서 특정 호스트(서버)나 서비스를 정확히 식별할 수 있도록 계층적인 정보(호스트 이름부터 최상위 도메인까지)를 포함하는 도메인 네임
- 로컬 네임 서버 (local name server)
- 클라이언트와 맞닿아 있는 네임 서버
- 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알고 있다면 클라이언트에서 즉시 해당 IP 주소를 반환
로컬 네임 서버가 IP 주소를 모르면 로컬 네임 서버는 FQDN에 대응하는 IP 주소를 알아낼 때까지 도메인 네임의 루트 도메인을 관장하는 서버(루트 네임 서버, root name server)에게 질의하고, 최상위 도메인을 관장하는 서버(TLD 네임 서버), 그 하위 레벨의 네임을 관장하는 네임 서버 등에 걸쳐 질의하여, 최종적으로 클라이언트가 원하는 IP 주소를 반환받으면 해당 주소를 클라이언트에게 전달함
클라이언트와 맞닿아 있는 로컬 네임 서버가 질의받은 도메인 네임에 대한 IP 주소를 모르는 경우, IP 주소를 알아낼 때까지 계층적인 네임 서버들에게 질의를 반복함
질의 과정이 너무 많이 반복되면 네트워크 내 트래픽이 많아져 리졸빙에 지나치게 오랜 시간이 걸려서 네임 서버들이 기존 응답받은 결과를 임시로 저장하여 활용하는 DNS 캐시 (DNS cache)를 이용함
자원과 URI/URL
- 자원(resource): 네트워크 상의 메시지를 통해 주고받는 최종 대상
- URI(Uniform Resource Identifier): 웹 상에서의 자원을 식별하기 위한 정보
- 이름 기반 식별: URN
- 위치 기반 식별: URL
URL (Uniform Resource Locator)
scheme
자원에 접근하는 방법
사용할 프로토콜 명시
authority
호스트를 특정할 수 있는 IP 주소나 도메인 네임 명시
콜론(:) 뒤에 포트 번호를 명시할 수도 있음
path
자원이 위치하고 있는 경로 명시
슬래시(/)를 기준으로 계층적으로 표현됨
query
URL에 대한 매개변수 역할
쿼리 문자열(query string), 쿼리 파라미터(query parameter) 등으로 불림
scheme, authority, path만으로는 표현하기 어려운 추가 정보
물음표(?)로 시작되는 <키=값> 형태의 데이터
앰퍼샌드(&)를 사용하여 여러 쿼리 문자열을 연결
fragment
자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
일반적으로 HTML 파일과 같은 자원에서 특정 부분을 가리키는 데 사용
HTML 파일의 특정 부분으로 이동하여 보이게 할 수 있음
URN (Uniform Resource Name)
- 자원(Resource)에 고유한 이름을 붙여 영구적이고 위치에 구애받지 않는 식별자
- 위치(URL)와 달리 자원이 어디에 있는지보다 무엇인지(이름)에 초점을 맞춤
urn:<이름공간>:<고유식별자>
HTTP의 특징과 메시지 구조
HTTP의 특징
요청 응답 기반 프로토콜
요청 메시지를 보내는 클라이언트와 이에 대한 응답 메시지를 보내는 서버가 서로 요청 메시지와 응답 메시지를 주고받는 구조로 동작
미디어 독립적 프로토콜
애플리케이션의 다양한 데이터를 네트워크를 통해 송수신한다.
HTTP 메시지를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원을 주고받을 수 있음
HTTP는 주고받을 자원의 특성과 무관하게 자원을 주고받는 수단(인터페이스)의 역할만 수행
HTTP에서 메시지로 주고받는 자원의 종류는 미디어 타입(media type)으로 불림
주고받을 미디어 타입에 특별한 제한을 두지 않고, 독립적으로 작동 가능한 미디어 독립적인 프로토콜
미디어 타입은 '타입/서브타입'의 형식으로 구성
- 타입(type): 데이터의 유형
- 서브타입(subtype): 주어진 타입에 대한 세부 유형
스테이트리스 프로토콜
상태를 유지하지 않는 스테이트리스(stateless) 프로토콜
서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않아, 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주됨
상태를 유지하지 않는 이유?
처리해야 할 요청 메시지가 많을때 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 부담
여러 대로 구성된 서버 모두가 모든 클라이언트의 상태를 유지해야한다면 모든 서버가 클라이언트 상태 정보를 공유해야 해서 부담
HTTP 서버가 지켜야 할 중요한 설계 목표: 확장성(scalability), 견고성(robustness)
독립적 요청으로 처리하면 특정 서버에 종속되지 않아 서버의 추가나 대체가 쉬워지고(확장성), 서버 중 하나에 문제가 생기더라도 쉽게 다른 서버로 대체 가능(견고성)하다.
지속 연결 프로토콜
- HTTP1.0: 비지속 연결
- 쓰리웨이 핸드 쉐이크를 통해 TCP 연결을 수립 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식
- 추가적인 요청-응답 메시지를 주고받으려면 매번 새롭게 연결을 수립하고 종료해야 함
- HTTP1.1, HTTP2.0: TCP 기반, 지속 연결(킵 얼라이브, keep-alive)
- 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있음
- TCP: 연결형 프로토콜
- HTTP: 비연결형 프로토콜
HTTP 버전별 특징
HTTP 1.1
지속 연결 기능이 공식적으로 지원
메시지를 평문으로 주고받음
HTTP 2.0
HOL 블로킹이라는 HTTP1.1의 문제를 완화한 버전
HOL 블로킹(Head-Of-Line Blocking): 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 때, 첫 번째 패킷의 처리 지연으로 인해 나머지 패킷들의 처리도 모두 지연되는 문제 상황
- 바이너리 데이터 기반 송수신
- 바이너리 데이터를 기반으로 메시지를 주고 받음
- 헤더 압축
- 헤더를 압축하여 송수신하여 네트워크 이용 효율을 높임
- 서버 푸시(server push)
- 클라이언트가 요청하지 않았어도 미래에 필요할 것으로 예상되는 자원을 미리 전송
- 예시) html만 요청했어도, styles, css, scripts.js 파일이 함께 사용될 것으로 예상되는 경우 미리 함께 응답
- HTTP 멀티플렉싱 기법
- 여러 개의 독립적인 스트림(stream)을 바탕으로 요청-응답 메시지를 병렬적으로 주고받는 기술
HTTP 3.0
UDP를 기반으로 동작
UDP를 기반으로 구현된 QUIC(Quick UDP Internet Connections)라는 프로토콜을 기반으로 동작
TPC에 비해 상대적으로 송수신 속도가 빠름
HTTP 메시지 구조
HTTP 요청 메시지와 응답 메시지가 있다
시작 라인(start-line)으로 HTTP 메시지가 요청 메시지인지, 응답 메시지인지 구분 가능
- 시작 라인 요청 메시지일 경우: 요청 라인(request-line)
- 시작 라인 응답 메시지일 경우: 상태 라인(status-line)
HTTP는 요청(Request)과 응답(Response) 메시지로 통신하는 요청-응답 기반 프로토콜이다.
각 메시지는 아래와 같은 공통 구조를 가진다
- 시작 라인 (Start-Line)
- 헤더 (Header)
- 빈 줄 (CRLF)
- 본문 (Body) (선택적)
시작 라인 (Start-Line)
시작 라인은 메시지가 요청인지 응답인지 구분하는 중요한 요소로, 요청 메시지와 응답 메시지 각각 다르게 구성된다.
요청 라인 (Request-Line)
요청 메시지의 시작 라인으로 클라이언트가 서버에 특정 리소스를 요청할 때 포함
| HTTP 메서드 (Method) | 클라이언트가 수행하려는 동작 (예: GET, POST, PUT) |
| 요청 URI (Request URI) | 요청 대상 리소스의 경로 |
| HTTP 버전 (HTTP Version) | 사용되는 HTTP 프로토콜 버전 (HTTP/1.1, HTTP/2) |
- HTTP 메서드: GET
- 요청 URI: /index.html
- HTTP 버전: HTTP/1.1
상태 라인 (Status-Line)
응답 메시지의 시작 라인으로 서버가 클라이언트 요청에 대해 응답할 때 포함
| HTTP 버전 (HTTP Version) | 사용되는 HTTP 프로토콜 버전 |
| 상태 코드 (Status Code) | 요청 처리 결과 상태 (예: 200, 404, 500) |
| 상태 설명 (Reason Phrase) | 상태 코드에 대한 간단한 설명 |
- HTTP 버전: HTTP/1.1
- 상태 코드: 200
- 상태 설명: OK
헤더 (Headers)
- 요청 또는 응답에 대한 부가 정보를 전달
- 헤더 이름: 값 형태로 작성됨
빈 줄 (CRLF)
- 헤더와 본문 사이에 빈 줄이 있어야 함
본문 (Body)
- 메시지에 실제 데이터가 포함되는 영역 (선택적)
- POST 요청 시 폼 데이터, 이미지 또는 JSON 데이터를 포함
HTTP 메서드와 상태 코드
HTTP 메서드
HTTP 메서드는 클라이언트가 서버에 요청하는 동작의 유형을 지정
| GET | 리소스 조회 | 웹 페이지 로딩 (GET /index.html) |
| POST | 리소스 생성 또는 데이터 전송 | 회원가입 정보 전송 |
| PUT | 리소스 전체 수정 (없으면 생성) | 특정 게시글 내용 전체 수정 |
| PATCH | 리소스 부분 수정 | 특정 게시글 일부 수정 |
| DELETE | 리소스 삭제 | 게시글 삭제 요청 |
| HEAD | 리소스 메타정보 요청 (본문 제외) | 페이지 존재 여부 확인 |
| OPTIONS | 서버 지원 메서드 확인 | CORS 요청 시 사전 검사 |
| CONNECT | 터널링 요청 | HTTPS 프록시 연결 |
| TRACE | 요청 경로 테스트 | 네트워크 디버깅 용도 |
HTTP 상태 코드
서버가 클라이언트 요청에 대한 응답 결과를 알려주는 코드
| 1xx (정보) | 요청 진행 중 | 서버가 요청을 수신했으며 처리 중 |
| 2xx (성공) | 요청 성공 | 요청이 성공적으로 처리됨 |
| 3xx (리다이렉션) | 리소스 이동 | 클라이언트가 다른 위치로 요청해야 함 |
| 4xx (클라이언트 오류) | 요청 오류 | 클라이언트 요청에 오류가 있음 |
| 5xx (서버 오류) | 서버 오류 | 서버가 요청을 처리하지 못함 |
1xx: 정보
| 100 | Continue: 요청 일부가 수신됨 |
| 101 | Switching Protocols: 프로토콜 전환 |
2xx: 성공
| 200 | OK: 요청 성공 |
| 201 | Created: 리소스 생성 완료 |
| 202 | Accepted: 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않음 |
| 204 | No Content: 본문 없이 요청 성공 |
3xx: 리다이렉션
| 301 | Moved Permanently: 영구적 리다이렉션 - 재요청 메서드가 변경될 수 있음 |
| 308 | Permanent Redirect: 영구적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
| 302 | Found: 일시적 리다이렉션 - 재요청 메서드가 변경될 수 있음 |
| 303 | See Other: 일시적 리다이렉션 - 재요청 메서드가 GET으로 변경됨 |
| 307 | Temporary Redirect: 일시적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
| 304 | Not Modified: 캐시 - 리소스 변경 없음 |
4xx: 클라이언트 오류
| 400 | Bad Request: 잘못된 요청 |
| 401 | Unauthorized: 인증 필요 |
| 403 | Forbidden: 접근 금지 |
| 404 | Not Found: 리소스 없음 |
| 405 | Method Not Allowed: 지원하지 않는 메서드 |
5xx: 서버 오류
| 500 | Internal Server Error: 서버 오류 |
| 502 | Bad Gateway: 게이트웨이 오류 |
| 503 | Service Unavailable: 서비스 불가 |
| 504 | Gateway Timeout: 게이트웨이 시간 초과 |
HTTP 주요 헤더
HTTP 헤더는 클라이언트와 서버가 요청과 응답에 대한 메타데이터를 전달하기 위해 사용하는 정보를 담고 있다
- 일반 헤더: 요청 및 응답에 모두 사용 가능한 정보
- 요청 헤더: 클라이언트가 서버에 추가 정보를 제공
- 응답 헤더: 서버가 클라이언트에 응답 정보 제공
- 엔티티 헤더: 본문 데이터 설명
일반 헤더 (General Headers)
요청과 응답 모두에서 사용할 수 있는 일반 정보에 관한 헤더
| Cache-Control | 캐시 정책 설정 | Cache-Control: no-cache |
| Connection | 연결 상태 유지 또는 종료 | Connection: keep-alive |
| Date | 메시지 생성 날짜와 시간 | Date: Tue, 28 Jan 2025 12:34:56 GMT |
요청 헤더 (Request Headers)
클라이언트가 서버에 요청할 때 전송되는 추가 정보
| Host | 요청 대상 서버의 호스트 정보 | Host: www.example.com |
| User-Agent | 클라이언트 소프트웨어 정보 | User-Agent: Mozilla/5.0 |
| Accept | 클라이언트가 수용 가능한 콘텐츠 타입 | Accept: text/html, application/json |
| Authorization | 인증 정보 전달 | Authorization: Bearer <token> |
| Content-Type | 요청 본문 데이터의 타입 | Content-Type: application/json |
| Referer | 이전 페이지 URL 정보 | Referer: https://www.google.com |
| Cookie | 클라이언트 측 쿠키 정보 | Cookie: sessionId=abc123 |
| Accept-Language | 수용 가능한 언어 | Accept-Language: en-US, ko-KR |
응답 헤더 (Response Headers)
서버가 클라이언트에 응답할 때 전송되는 추가 정보
| Server | 서버 소프트웨어 정보 | Server: Apache/2.4.1 |
| Content-Type | 응답 본문의 데이터 타입 | Content-Type: application/json |
| Set-Cookie | 서버가 설정하는 쿠키 정보 | Set-Cookie: sessionId=xyz789; Path=/; HttpOnly |
| Location | 리다이렉션 대상 URL | Location: https://new.example.com |
| Content-Length | 응답 본문의 길이 | Content-Length: 524 |
| ETag | 리소스의 고유 식별 값 | ETag: "abc123" |
엔티티 헤더 (Entity Headers)
본문 데이터를 설명하는 데 사용
| Content-Encoding | 콘텐츠 압축 방식 | Content-Encoding: gzip |
| Content-Language | 콘텐츠 언어 | Content-Language: ko-KR |
| Content-Disposition | 콘텐츠의 표시 방식 | Content-Disposition: attachment; filename="file.pdf" |
| Last-Modified | 리소스 최종 수정 일시 | Last-Modified: Tue, 28 Jan 2025 12:34:56 GMT |
쿠키 (Cookie)
HTTP는 기본적으로 스테이트리스 프로토콜
HTTP 요청 메시지는 독립된 메시지로 간주됨
쿠키는 HTTP의 스테이트리스한 특성을 보완하기 위한 대표적 수단
key, value 쌍 형태의 데이터
클라이언트는 서버로부터 받은 쿠키를 주로 브라우저에 저장함
서버는 쿠키를 생성하여 클라이언트에 전송하고, 클라이언트는 쿠키를 저장해 두었다가 추후 같은 서버에 요청을 보낼 때 요청 메시지에 쿠키를 포함하여 전송
서버가 클라이언트에게 쿠키를 전송할 때는 응답 메시지에 Set-Cookie 헤더가 활용됨
특정 서버로부터 쿠키를 전달받았다면 다음부터 해당 서버에 요청을 보낼 때 전달받은 쿠키를 자동으로 전송함
쿠키는 domain, path 속성을 통해 쿠키를 전송할 도메인과 경로를 제한할 수 있음
- Expires로 명시된 시점이 지나거나 Max-Age로 명시된 유효기간이 지나면 해당 쿠키는 삭제되어 전달되지 않음
- Secure: HTTP의 더 안전한 방식인 HTTPS를 통해서만 쿠키를 송수신하도록 하는 속성
- HttpOnly: 자바스크립트를 통한 쿠키의 접근을 제한하고, 오직 HTTP 송수신을 통해서만 (HTTP 헤더를 주고받는 방식으로만) 쿠키에 접근하도록 하는 방식
웹 스토리지(Web Storage)
쿠키 이외에도 클라이언트의 상태를 추측할 수 있는 <키, 값>쌍 형태의 정보
웹 브라우저 내의 저장 공간으로, 일반적으로 쿠키보다 더 큰 데이터를 저장할 수 있음
쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송되지 않음
- 로컬 스토리지(local storage): 별도로 삭제하지 않는 한 영구적으로 저장이 가능한 정보
- 세션 스토리지(session storage): 세션이 유지되는 동안 유지되는 정보 (브라우저가 열려 있는 동안)
캐시(Cache)
응답받은 자원의 사본을 임시 저장하여 불필요한 대역폭 낭비와 응답 지연을 방지하는 기술
자원의 사본을 임시 저장하여 추후 동일한 요청 메시지를 보내야 할 때 임시 저장된 사본을 재활용하여 더 빠르게 자원에 접근
캐시는 클라이언트에 저장되거나, 클라이언트와 서버 사이의 중간 서버에 저장되기도 함
- 전용 캐시(private cache)
- 특정 사용자를 위해 클라이언트 측에 저장되는 캐시
- 보안과 개인 정보 보호가 필요한 콘텐츠에 적합
- 로그인 정보, 사용자 개인화 설정 등
- HTTP 헤더: Cache-Control: private
- 사용자가 로그인한 상태에서 쇼핑몰 페이지를 방문할 경우, 사용자의 장바구니 정보가 전용 캐시로 저장됨
- 공용 캐시 (public cache)
- 여러 사용자 간에 공유될 수 있는 캐시
- 보안이 중요하지 않은 일반적인 콘텐츠에 적합
- 이미지, CSS 파일, JavaScript 파일 등
- Cache-Control: public
- 대형 CDN(Content Delivery Network) 서버에서 웹사이트 이미지 파일을 공용 캐시로 저장하여 여러 사용자가 빠르게 이미지에 접근
캐시할 데이터에 유효기간을 부여하기 위해 응답 메시지에 Expires 헤더(캐시한 데이터의 만료 날짜)와 Cache Control 헤더의 Max-Age값(캐시하여 사용 가능한 초 단위 시간)을 사용
캐시에 유효기간이 부여되는 이유?
서버의 원본 데이터가 변경되어 원본 데이터와 캐시된 사본 데이터 간의 일관성이 깨질 수 있기 때문
캐시 신선도 (cache freshness)
캐시된 사본 데이터가 서버의 원본 데이터와 얼마나 유사한지의 정도
원본 데이터가 변경되었을 때 해당 자원을 다시 응답받음으로써 캐시 신선도를 높게 유지할 수 있다
캐시 신선도 유지 메커니즘
서버는 클라이언트가 최신 데이터를 받을 수 있도록 특정 조건과 메커니즘을 통해 캐시 신선도를 관리한다.
- Cache-Control 헤더
- 서버는 Cache-Control 헤더로 캐시 데이터의 유효 기간을 지정
- Cache-Control: max-age=3600
- 데이터가 3600초(1시간) 동안 신선하다고 간주됨을 의미
- Expires 헤더
- HTTP/1.0에서 사용되며 데이터의 만료 시간을 명시
- Expires: Wed, 01 Feb 2025 12:00:00 GMT
- 지정된 시간 이후 데이터가 더 이상 신선하지 않다고 간주
캐시 신선도 확인 메커니즘 (재검사, Validation)
- ETag (Entity Tag)
- 서버는 자원의 버전을 나타내는 고유 태그(해시 값)를 반환
- 클라이언트는 이후 요청 시 해당 ETag 값을 함께 보내며 변경 여부를 확인
- ETag: "abc123"
- Last-Modified 헤더
- 서버는 자원의 마지막 수정 시간을 헤더에 포함시켜 클라이언트에게 전달
- 클라이언트가 요청 시 If-Modified-Since 헤더로 수정 여부를 확인
- Last-Modified: Wed, 01 Jan 2025 12:00:00 GMT
원본 데이터 변경 시 캐시 무효화
- 서버 자원이 변경되면 캐시는 더 이상 신선하지 않으므로 데이터를 다시 요청하여 캐시를 갱신
- 네트워크 트래픽 증가를 초래하지만 최신 데이터 제공이 보장
헤더
| Cache-Control | 캐시 데이터 유효 기간 설정 |
| Expires | 데이터 만료 시간 설정 |
| ETag | 자원의 버전 확인 |
| Last-Modified | 자원의 마지막 수정 시간 |
콘텐츠 협상 (content negotiation)
같은 URI(URL)에 대해서도 다른 자원의 표현이 있을 수 있다
콘텐츠 협상: 같은 자원에 대해 할 수 있는 여러 표현 중 클라이언트가 가장 적합한 자원의 표현을 제공하는 기술
자원에 대한 다양한 표현 중 클라이언트가 선호하는 자원의 표현을 콘텐츠 협상 헤더를 통해 서버를 통해 전송하면 서버는 클라이언트가 요청한 자원의 표현을 응답함
콘텐츠 협상 헤더
- Accept: 선호하는 미디어 타입을 나타냄
- Accecpt-Language: 선호하는 언어를 나타냄
- Accept-Encoding: 선호하는 인코딩 방식을 나타냄
클라이언트가 우선순위를 반영하여 여러 표현에 대한 선호도를 서버에 알릴 수 있다
우선순위는 콘텐츠 협상 관련 헤더의 q값(Quality Value)으로 표현됨
0~1까지의 표현 범위 중 생략일 경우는 1
값이 클수록 우선순위가 높아짐
Accept: application/json, text/html;q=0.5
보안: SSL/TLS, HTTPS
- SSL(Secure Sockets Layer), TLS(Transport Layer Security): 인증과 암호화를 수행하는 프로토콜
- TLS는 SSL을 계승한 프로토콜
TLS 1.3 기반 HTTPS 송수신
- TCP 쓰리웨이 핸드셰이크
- TLS 핸드셰이크
- 메시지 송수신
TLS 핸드셰이크
- TLS 핸드셰이크를 통해 암호화 통신을 위한 키 생성/교환, 인증서 송수신과 검증이 이루어질 수 있음
- 암호화 통신을 위한 키 생성/교환
- 평문을 암호화하거나, 암호문을 복호화하려면 키(key)라는 정보가 필요함
- ClientHello 메시지와 ServerHello 메시지를 주고받으면 암호화된 통신을 위해 사전 협의해야 할 정보들이 결정되고, 결정된 정보를 토대로 서버와 클라이언트가 암호화에 사용할 키를 만들어 암호화에 사용할 수 있음
- ClientHello: 암호화된 통신을 위해 맞춰야 할 정보를 제시하는 메시지
- 지원되는 TLS 버전, 사용 가능한 암호화 알고리즘과 해시 함수, 키를 만들기 위해 사용할 클라이언트의 난수 등 포함
- 암호 스위트(cipher suite): 사용 가능한 암호화 알고리즘과 해시 함수, 보안 통신에서 사용하는 알고리즘들의 조합
- Server Hello: 제시된 정보들을 선택하는 메시지
- 선택된 TLS 버전, 암호 스위트 등의 정보, 키를 만들기 위해 사용할 서버의 난수 등 포함
- 인증서(public key certificate) 송수신과 검증
- 인증서(certificate): 통신을 주고받는 대상이 의도한 대상이 맞다는 사실을 입증하기 위한 정보
- 인증 기관 (CA, certificate authority): 인증서를 발급하고 검증하는 제 3의 인증 기관
- 인증서의 발급과 검증, 저장 등의 역할을 수행하는 공인 기관
- Certificate 메시지: 인증서 서명 값 등 인증서 내용들이 포함
- CertificateVerify 메시지: 인증서의 내용이 올바른지 검증하기 위한 메시지
finished 메시지(TLS 핸드셰이크의 마지막)를 주고받고, 이후부터 TLS 핸드셰이크를 통해 얻어낸 키를 기반으로 암호화된 데이터를 주고받음
'네트워크' 카테고리의 다른 글
| [네트워크] 프록시와 안정적인 트래픽 (0) | 2025.02.16 |
|---|---|
| [네트워크] 전송 계층: TCP, UDP (0) | 2025.01.28 |
| [네트워크] 네트워크 계층: IP (0) | 2025.01.27 |
| [네트워크] 물리 계층, 데이터 링크 계층 (0) | 2025.01.27 |
| [네트워크] 네트워크의 큰 그림 (0) | 2025.01.15 |
