개발일지
혼공네트 4~7장 요약 정리 본문
4장. 전송 계층
4-1. 전송 계층 개요
인터넷 프로토콜의 한계
- 비신뢰성(unrealiable) 프로토콜
- 패킷이 목적지까지 ‘제대로’ 전송 되는 것을 보장하지 않음 → 패킷 손실, 지연, 순서 변경 등의 문제 가능성 존재
- 최선형 전달(best effort delivery)
- 비연결성(connectionless) 프로토콜
- 송수신 호스트 간에 사전 연결 수립 과정을 거치지 않음
IP 한계를 보완하는 전송 계층 → TCP
- TCP
- 사전 연결 수립 과정을 거치는 ‘연결형’ 프로토콜
- 오류/흐름/혼잡 제어 등을 통해 신뢰성 제공
- UDP
- 비신뢰성, 비연결성 통신을 위한 프로토콜
- 신뢰성을 보장하지는 않지만 빠른 전송이 가능
포트 - 응용 계층과의 연결점
포트 (Port)
- 패킷의 최종 목적지는 수신 호스트의 ‘특정 애플리케이션 프로세스’이다.
- 포트 번호를 통해 애플리케이션을 식별한다.
⇒ 포트: 특정 애플리케이션을 식별할 수 있는 정보
포트 번호의 분류
- 잘 알려진 포트(well-known ports): 0~1023번
- 80(HTTP), 443(HTTPS), 22(SSH) 등
- 등록된 포트(registered ports): 1024~49151번
- 3306(MySQL), 6379(Redis), 5004(RTP) 등
- 동적 포트(dynamic ports): 49152~65535번
- 사용자가 임의로 설정 가능한 포트
형식: <IP 주소:Port 번호>
- ‘특정 호스트(IP 주소)’에서 실행 중인 ‘특정 애플리케이션 프로세스(포트 번호)’
NAPT (Network Address Port Translation)
- 공인 IP 주소 수 부족 문제를 해결하기 위한 포트 기반 NAT 기술
- <IP 주소:포트 번호> 형태로 NAT 테이블에 기록한다.
- IP 주소가 같더라도 포트 번호가 다르면 서로 다른 호스트를 특정할 수 있다.
- 즉, 하나의 공용 IP 주소를 다수의 사설 IP 주소가 공유할 수 있게 된다.
+) 포트 포워딩(Port forwarding)
- 네트워크 외부에서 네트워크 내부 특정 호스트로 패킷을 전달하기 위해 IP 주소와 포트 번호를 미리 할당하고, 해당 <IP 주소:포트 번호>로써 해당 호스트에 패킷을 전달하는 기능
- 네트워크 외부에서 내부로 접근할 때, 네트워크 내부 서버의 IP 주소 또는 포트를 외부에 노출하지 않으면서 안정적인 접근을 가능하게 한다.
+) ICMP(Internet Control Message Protocol)
- IP 패킷의 전송 과정에 대한 피드백 메시지를 제공하기 위해 사용되는 프로토콜
- 비신뢰성, 비연결형 통신 방식인 IP의 한계를 보완하기 위한 프로토콜이다.
- 다만, IP 한계를 ‘보완’ 할 뿐 실제 신뢰성을 보장하는 것은 아니다.
- 대표적인 ICMP 기반 네트워크 진단 도구로는 ping, traceroute 가 있다.
4-2. TCP와 UDP
TCP (Transmission Control Protocol)
- 데이터의 신뢰성을 보장하는 연결형 프로토콜
- TCP 통신 단계: 연결 수립 → 데이터 송수신 → 연결 종료
- MSS (Maximum Segment Size): TCP로 전송 가능한 최대 페이로드 크기
TCP 세그먼트(Segment) 구조
- 송신지 포트 / 수신지 포트
- 제어 비트(또는 플래그 비트, control/flag bits): 8비트로 구성되며 연결 제어 상태를 나타냄
- ACK(acknowledgment): 세그먼트 승인 비트
- SYN(synchronization): 연결 수립을 요청하는 비트
- FIN(finish): 연결 종료를 알리는 비트
- 순서 번호 (sequence number): 세그먼트가 TCP 스트림 내에서 어느 위치에 있는 지 나타내는 번호
- 초기 순서 번호(Initial SN): 연결 수립시 SYN 세그먼트에 무작위로 부여되는 순서번호
- MSS 단위로 증가하며, 다음 순서 번호는 ‘ISN + 송신된 바이트 수’로 계산된다.
- 확인 응답 번호(acknowledgment number): 수신자가 다음으로 받길 원하는 순서번호 → 이전 순서번호에 대한 응답
- 확인 응답 번호 = ‘수신한 순서번호+수신한 바이트 수’
- ACK 세그먼트와 함께 전송된다.
- 윈도우(window): 수신자가 한 번에 수신할 수 있는 데이터 양 (=수신 윈도우 크기)
TCP 연결 수립: 3-way handshake
- SYN 요청 (클 → 서)
- 클라이언트는 연결을 요청하기 위해 ISN를 포함한 SYN 세그먼트를 보낸다.
- SYN + ACK 응답 (서 → 클)
- 서버는 연결을 승인하는 ACK 플래그를 설정하고 확인 응답 번호를 포함한다.
- 동시에 자신의 SYN 플래그를 설정하고 ISN를 포함한 SYN+ACK 세그먼트를 보낸다.
- ACK 확인 (클 → 서)
- 클라이언트는 확인 응답 번호를 포함하여 ACK 세그먼트를 보낸다.
- TCP 연결이 성공적으로 수립되면 양방향 데이터 통신이 가능해진다.
TCP 연결 종료: 4-way handshake
- FIN 요청 (클 → 서)
- 클라이언트는 연결을 종료하기위해 FIN 세그먼트를 보낸다.
- ACK 응답 (서 → 클)
- 서버는 확인 응답 번호를 포함한 ACK 세그먼트를 보낸다.
- 이 응답은 서버가 클라이언트의 연결 종료 요청을 확인했음을 의미한다.
- FIN 요청 (서 → 클)
- 서버 역시 데이터 전송이 완료되면 클라이언트에 FIN 세그먼트를 보낸다.
- ACK 응답 (클 → 서)
- 클라이언트는 확인 응답 번호를 포함한 ACK 세그먼트를 보낸다.
- 이로써 TCP 연결이 안전하게 종료된다.
TCP의 상태
- 상태(state): 현재 연결이 진행 중인 통신 과정에 대한 정보
- TCP는 stateful한 프로토콜로 연결 수립부터 종료까지 각 단계의 상태를 추적하고 관리한다.
- TCP 상태 종류
- 연결이 수립되지 않은 상태: CLOSED, LISTEN
- 연결 수립 상태: SYN-SENT, SYN-RECEIVED, ESTABLISHED
- 연결 종료 상태: FIN-WAIT-1, CLOSED-WAIT, FIN-WAIT-2, LAST-ACK, TIME-WAIT, CLOSING
UDP (User Data Protocal)
- 신뢰성을 보장하지 않는 비연결형 프로토콜
- 연결 수립 및 해제, 오류/흐름/혼잡 제어 등을 수행하지 않음
- stateless한 프로토콜로 통신 과정에서의 상태 정보를 유지하지 않음
- TCP에 비해 오버헤드가 적고 패킷 처리 속도가 빠르다.
- 스트리밍, 온라인 게임 등 실시간성이 중요한 서비스에서 사용
4-3. TCP의 오류/흐름/혼잡 제어 → 신뢰성 보장을 위한 기능
오류제어: 재전송 기법
오류 제어 (Error control)
- 송신한 세그먼트에 문제가 발생하면 이를 감지하고 해당 세그먼트를 재전송함으로써 신뢰성을 보장하는 것
- TCP가 오류를 감지하고 재전송 하는 상황
- 송신자가 중복된 ACK 세그먼트를 수신 했을 때
- 타임아웃이 발생했을 때까지 ACK 세그먼트를 수신하지 못했을 때
ARQ: 재전송 기법
- ARQ(Automatic Repeat reQuest, 자동 재전송 요구): 오류가 감지된 데이터를 재전송하는 메커니즘
- Stop-and-Wait ARQ
- 송신한 세그먼트가 제대로 전송됐음을 확인하기 전까지(ACK 응답) 새로운 메시지를 보내지 않는 방식
- 단순하지만, 한 번에 하나의 세그먼트만 전송 가능하기에 네트워크 이용 효율이 낮다.
- 파이프라이닝 기반 ARQ
- Go-Back-N ARQ (누적 확인 응답): 송신 도중 오류가 발생한 세그먼트 이후에 전송된 모든 세그먼트를 다시 전송하는 방식
- Selective Repeat ARQ (개별 확인 응답): 수신자가 각 세그먼트에 대한 개별적인 ACK를 보내는 방식
- 오류가 발생한 세그먼트만 재전송하기 때문에 더 효율적이다.
파이프라이닝(pipelining)
여러 세그먼트를 동시에 전송할 수 있는 기법
흐름 제어: 슬라이딩 윈도우
흐름 제어 (Flow control)
- 송/수신자 간의 데이터 처리 속도를 조절하여 수신 호스트의 버퍼 오버플로우(buffer overflow)를 방지하는 것 → 데이터 손실 방지
- 파이프라이닝 기법에서 반드시 필요한 기능
슬라이딩 윈도우 (Sliding window)
- 윈도우(window)
- 송신 호스트가 한 번에 파이프라이닝할 수 있는 최대량 → ACK 응답을 받지 않고도 전송가능한 양
- 송신 윈도우는 수신 윈도우를 기반으로 알 수 있다. (TCP 헤더의 윈도우 필드)
- 슬라이딩(sliding)
- 송신 호스트는 데이터 송신 후 ACK 응답을 받으면 윈도우를 이동하여 새로운 데이터 블록을 전송할 수 있게 된다.
혼잡 제어
혼잡 (Congestion)
- 많은 트래픽으로 인해 패킷 처리 속도가 늦어지거나 유실될 우려가 있는 네트워크 상황
혼잡 제어 (Congestion control)
- 송신 호스트 측에서 네트워크 혼잡도를 판단하여 혼잡한 정도에 따라 전송량을 조절하는 것
- 혼잡 윈도우 (congestion window)
- 송신 호스트가 혼잡없이 네트워크에 전송할 수 있는 데이터의 양
- 혼잡 윈도우 크기는 혼잡 제어 알고리즘으로 결정한다.
혼잡 제어 알고리즘
- AIMD (Additive Increase Multiplicative Decrease)
- 혼잡이 감지되지 않으면 혼잡 윈도우의 크기를 선형적으로 증가시키고, 감지되면 곱으로 감소시킨다.
- 느린 시작 (slow start)
- 초기에는 혼잡 윈도우 크기를 지수적으로 증가시킨다. (RTT마다 2배씩 증가)
- 혼잡이 감지되면 느린 시작/혼잡 회피/빠른 회복 중 하나를 선택하여 윈도우 크기를 줄인다.
- 혼잡 회피 (congestion avoidance)
- 혼잡을 피하기 위해 윈도우 크기의 증가 속도를 느리게 하는 방식 (선형적 증가)
- RTT마다 윈도우 크기를 1MSS 증가시킨다.
- 빠른 회복 (fast recovery)
- 중복 ACK 발생 시 손실된 세그먼트를 빠르게 재전송 하여 혼잡을 조절하는 방식
- 재전송 후 느린 시작 단계는 건너뛰고 바로 혼잡 회피를 수행한다.
RTT(Round-Trip Time)
송신자가 세그먼트를 전송한 뒤 ACK 응답 받는 데까지 걸리는 시간
5장. 응용 계층
5-1. DNS와 자원
[ 도메인 네임과 DNS ]
도메인 네임과 네임 서버
- 도메인 네임 (domain name)
- IP 주소와 대응되는 문자열 형태의 주소
- IP 주소보다 기억하기 쉽고, IP 주소가 변경되더라도 대응하기 쉽다.
- 네임 서버 (name server) or DNS 서버
- 도메인 네임을 관리하는 서버
도메인 네임 구조 - 점(.)을 기준으로 한 계층적 구조
예시) www.naver.com.
- 루트 도메인(root domain): 맨 마지막에 위치한 “.”
- 최상단 도메인, 표기할 때는 보통 생략된다.
- 최상위 도메인(Top-Level Domain, TLD): “.com”
- 2단계 도메인(second-level domain): “.naver”
- TLD 바로 앞에 오는 도메인
- 3단계 도메인: “www”
- 서브 도메인으로 보통 3~5단계로 이뤄진다.
- 전체 주소 도메인 네임 (Fully-Qualified Domain Name, FQDN)
- 모든 단계의 도메인을 포함하는 도메인 네임
- “www.naver.com.”
- 호스트 네임 (host name)
- FQDN의 첫 부분 “www”
- 최종적으로 호스트를 식별하는 부분
DNS (Domain Name System)
- 계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 응용 계층 프로토콜
- 도메인 네임을 IP 주소로 변환하기 위한 시스템
계층적 네임 서버
- 로컬 네임 서버 or 리졸버(resolver)
- 클라이언트의 요청을 처리하는 DNS 서버
- 일반적으로 ISP에 의해 제공되거나, 공개 DNS 서버를 이용한다.
- 루트 네임 서버
- 루트 도메인을 관리하는 네임 서버
- TLD 네임 서버의 IP 주소 제공
- TLD 네임 서버
- TLD 도메인을 관리하는 네임 서버
- 하위 도메인 네임 서버의 IP 주소 반환
- 책임 네임 서버 (authoritative name server)
- 특정 도메인에 대한 최종적인 정보를 제공하는 네임 서버
- 도메인 네임에 대한 최종 IP 주소 반환
질의 방법 (리졸빙 과정)
- 재귀적 질의 (recursive query)
- 클라이언트가 질의하면 로컬 네임 서버가 모든 요청을 처리하여 최종 IP 주소를 클라이언트에게 응답하는 방식
- “로컬 → 루트 → TLD → 책임” 네임 서버 순차적으로 질의하고 최종 응답 결과를 역순으로 전달
- 반복적 질의 (iterative query)
- 클라이언트가 직접적으로 다음 단계의 네임 서버에게 질의하는 방식 → 책임 네임 서버로 부터 최종 IP 주소를 얻게 됨
- 클라이언트가 질의하면 로컬 네임 서버는 다음 단계의 네임 서버 주소를 반환한다.
DNS 캐시 (DNS cache)
- 네임 서버들이 이전에 응답 받은 결과를 캐싱 하여, 동일한 요청에 대해 더 빠르게 응답할 수 있도록 하는 기술
- 네트워크 효율성을 높이고 서버 부하를 줄일 수 있다.
[ 자원과 URI ]
자원을 식별하는 URI
- 자원 (resource)
- 네트워크 상에서 메시지를 통해 주고 받는 대상
- ex) HTML, 이미지 파일, 비디오 스트림 등
- URI (Uniform Resource Identifier)
- 자원을 식별할 수 있는 문자열
- URL, URN
URL (Uniform Resource Locator): 위치 기반 식별자
예시) <https://www.naver.com/news?page=2#frag>
- schema: “https://”
- 자원에 접근하는 방법, 보통 프로토콜 명시
- authority: “www.naver.com”
- 호스트를 특정하는 정보, IP 주소 또는 도메인 네임
- path: “/news”
- query: “?page=2”
- fragment: “#frag”
URN (Uniform Resource Name): 이름 기반 식별자
- 위치나 접근 방법과는 무관하게 자원을 식별할 수 있다.
- 예시) urn:isbn:0451450523
5-2. HTTP
HTTP의 특성
- HTTP(HyperText Transfer Proctocol): 응용 계층에서 데이터를 주고받기 위한 프로토콜”
- “요청/응답 기반, 미디어 독립적, Stateless, 지속 연결” 프로토콜
요청/응답 기반 프로토콜
- HTTP는 클라이언트-서버 구조 기반의 요청-응답 프로토콜이다.
- 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다.
미디어 독립적 프로토콜
- HTTP는 자원의 종류에 제한 없이 텍스트, 이미지, 비디오 등 다양한 데이터를 전송할 수 있다. → 그저 자원을 주고받을 인터페이스 역할만을 수행
- 미디어 타입(or MIME 타입): 주고 받는 자원의 종류로 파일 확장자와 비슷한 개념
- 형식: <type/subtype>
- ex) text/plain, text/html, image/png
Stateless 프로토콜
- HTTP는 연결 상태를 유지하지 않는 프로토콜이다.
- 즉 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주한다.
- 높은 확장성과 견고성을 가진다.
- 확장성(scalability): 특정 서버에 종속되지 않아 서버 확장 및 축소가 자유롭다.
- 견고성(robustness): 특정 서버에 문제가 발생하더라도 쉽게 대처 가능하다.
지속 연결 프로토콜
- 기본적으로 HTTP는 비연결형, TCP는 연결형 프로토콜이다.→ HTTP/1.1 부터 “지속 연결” 지원
- → HTTP 요청할 때마다 연결 수립 과정을 필요로 하게 된다. (비효율적)
- 지속 연결 (persistent connection) or keep-alive
- 하나의 TCP 연결에서 HTTP 요청-응답을 지속적으로 주고 받는 방식
- 비지속 연결보다 더 빠른 처리가 가능하다.
HTTP 메시지 구조
시작 라인
필드 라인
메시지 본문
시작 라인 (start-line)
- 요청 라인 (request-line): <”메서드” “요청 대상” “HTTP 버전”>
- 요청 대상(request-target): HTTP 요청을 보낼 서버의 자원
- 주로 URI의 경로와 쿼리 문자열이 명시됨
- ex) “/news?page=2”
- 요청 대상(request-target): HTTP 요청을 보낼 서버의 자원
- 상태 라인 (status-line): <”HTTP버전” “상태 코드” “이유 구문”>
- 서버 응답 상태를 설명하는 정보
필드 라인 (field-line) or 헤더 라인(header-line)
- HTTP 헤더가 명시 됨
- <header-name: header-value>
메시지 본문 (message-body)
- HTTP 요청이나 응답 메시지에서 본문이 필요할 경우 사용 (옵션)
HTTP 메서드
- GET, HEAD, POST, PUT, PATCH, DELETE
HTTP 상태코드
| 상태 코드 | 설명 |
| 1XX | 정보성 상태 코드 |
| 2XX | 성공 |
| 3XX | 리다이렉션 |
| 4XX | 클라이언트 측 에러 |
| 5XX | 서버 측 에러 |
2XX: 성공 (Success)
| 상태 코드 | 이유 구문 | 설명 |
| 200 | OK | - 요청이 성공적으로 처리 됨 - 주로 GET, DELETE |
| 201 | Created | - 요청에 따라 새로운 자원이 생성 됨 - 주로 POST, PUT |
| 202 | Accepted | - 요청을 잘 받았으나, 처리 완료 되지 않음 - 대용량 파일 업로드, 비동기 작업 등 |
| 204 | No Content | 요청 성공했으나, 반환할 본문 내용이 없음 |
3XX: 리다이렉션 (Redirection)
- 클라이언트가 요청한 자원이 다른 곳(URL, 캐시 등)에 위치할 때, 해당 위치로 요청 시키기 위함
| 상태 코드 | 이유 구문 | 설명 |
| 301 | Moved Permanently | 영구적인 리다이렉션: 재요청 메서드 변경될 수 있음 |
| 308 | Permanent Redirect | 영구적인 리다이렉션: 재요청 메서드 변경되지 않음 |
| 302 | Found | 일시적인 리다이렉션: 재요청 메서드 변경될 수 있음 |
| 303 | See Other | 일시적인 리다이렉션: 재요청 메서드 GET으로 변경 |
| 307 | Temporary Redirect | 일시적인 리다이렉션: 재요청 메서드 변경되지 않음 |
| 304 | Not Modified | 자원이 변경되지 않음 (캐시와 관련된 상태 코드) |
- 영구적인 리다이렉션 (Permanent redirection)
- 자원이 영구적으로 새로운 곳으로 이동하여 경로가 재지정 되는 것
- ex) 서버 도메인 이전
- 일시적인 리다이렉션 (Temporary redirection)
- 자원의 위치가 임시로 변경 됨, 추후 원래 URL로 접근 가능
- 처음 요청 보낸 URL을 기억하고 있어야 함
4XX: 클라이언트 에러 (Client Error)
| 상태 코드 | 이유 구문 | 설명 |
| 400 | Bad Request | 잘못된 요청 |
| 401 | Unauthorized | 인증 되지 않음 |
| 403 | Forbidden | 접근 권한이 없음 |
| 404 | Not Found | 요청받은 자원을 찾을 수 없음 |
| 405 | Method Not Allowed | 지원하지 않는 HTTP 메서드 |
- 401 vs. 403
- 401: 인증(authentication) 여부
- 반드시 “WWW-Authenticate 헤더”로 인증 방법 알려줘야 함
- ex) 로그인 없이 회원 전용 페이지에 접근하려할 때
- 403: 권한(authorization) 여부
- 인증은 되었으나, 해당 자원에 접근 권한이 없음
- ex) 일반 회원이 VIP 회원 전용 페이지에 접근하려할 때
- 401: 인증(authentication) 여부
5XX: 서버 에러 상태 코드
| 상태 코드 | 이유 구문 | 설명 |
| 500 | Internal Server Error | 요청 처리 도중 실패 (광범위 함) |
| 502 | Bad Gateway | 중간 서버의 통신 오류 |
| 503 | Service Unavailable | - 현재 요청을 일시적으로 처리할 수 없음 - ex) 서버 과부하, 일시 점검 중 |
5-3. HTTP 헤더와 HTTP 기반 기술
HTTP 헤더
HTTP 요청 헤더
- HOST: 요청을 보낼 호스트, 주로 도메인 네임이 명시 됨
- User-Agent: 요청하는 클라이언트의 프로그램 및 접속 환경
- Referer: 요청하는 클라이언트의 이전 URL, 현재 요청이 이루어지기 직전의 URL
- Authorization: 클라이언트 인증 정보, ex) Basic, Bearer, OAuth
HTTP 응답 헤더
- Server: 서버 측 소프트웨어 관련 정보, ex) Server: Apach/2.4.1 (Unix)
- Allow: 요청을 허용하는 HTTP 메서드 → 405(Method Not Allowed)
- Retry-After: 자원을 사용할 수 있는 일자 또는 기간 → 503(Service Unavailable) 상태코드와 함께 사용
- Location: 자원의 위치를 알려주기 위한 용도, 리다이렉션 또는 POST와 함께 사용 됨
- WWW-Authenticate: 인증 방식 → 401(Unauthorized)
공통 헤더
- Date: 메시지가 생성된 일자
- Connection: 클라이언트와 서버 간 연결 방식, ex) Connection: keep-alive
- Content-Length: 본문의 크기 (byte)
- 표현 헤더(Representation header)
- Content-Type: 메시지 본문에서 사용된 미이더 타입
- Content-Language: 메시지 본문에 사용된 자연어
- Content-Encoding: 메시지 본문의 압축/변환 방식
캐시
캐시 (Cache)
- 정보의 사본을 임시로 저장하고 동일 요청에 대해 캐싱되어 있는 사본을 바로 활용할 수 있는 기술
- 대역폭 낭비와 응답 지연을 방지한다.
- 종류
- 개인 전용 캐시(private cache): 웹 브라우저에 저장
- 공용 캐시(public cache): 중간 서버에 저장
캐시 신선도 (Cache freshness)
- 캐시된 이후 원본 데이터가 변경되는 상황에 대비하기 위함
- 캐시 신선도 유지 - 캐시 데이터의 “유효 기간” 설정하기
- 서버가 “Expires”, “Cache-Control: max-age” 응답 헤더를 사용해 유효 기간 서정
- 유효 기간이 만료 됐으면, 클라이언트는 “원본 데이터가 변경 되었는지” 확인해야 함
- 캐시 신선도 재검사
- 날짜 기반 방식
- “If-Modified-Since” 요청 헤더 사용
- 마지막 수정 날짜를 기준으로 원본 데이터를 확인
- 엔티티 태그(Etag) 기반 방식
- “If-None-Match” 요청 헤더 사용
- 서버가 발행한 고유 Etag 값을 기준으로 자원이 변경 되었는지 확인
- 변경 O → 200(OK) + 새로운 자원 반환
- 변경 X → 304(Not Modified)
- 삭제 됨 → 404(Not Found)
- 날짜 기반 방식
쿠키
쿠키 (Coockie)
- HTTP의 stateless한 특성을 보완하기 위한 기술로 클라이언트와 서버 간 상태 정보를 유지하고 관리할 수 있다.
- 쿠키 구조 및 동작
- 서버에서 <key, value> 형태로 쿠키를 생성하여 클라이언트측에 전달한다.
- 클라이언트는 이후 모든 요청에 해당 쿠키를 포함하여 전송한다.
쿠키 관련 HTTP 헤더와 속성
- Set-Cookie: 서버가 쿠키를 설정하기 위한 응답 헤더
- Cookie: 클라이언트가 쿠키를 포함하여 전송하기 위한 요청 헤더
- 쿠키 속성
- Domain: 쿠키가 유효할 도메인 지정
- Path: 쿠키가 유효할 URL 경로
- Expires: 쿠키의 만료 기간, 만료 시 자동 삭제 된다.
- Max-age: 초 단위로 설정한 쿠키 만료 시간
Set-Cookie, Cookie 헤더 사용 예시
HTTP/1.1 200 OK
Content-type: text/html
// 예시 1)
Set-Cookie: name=minchul; domain=naver.com; path=/news
// 예시 2)
Set-Cookie: sessionID=s1234;
Set-Cookie: Expires=Fri, 24 Aug 2024 09:00:00 GMT;
// 예시 3)
Set-Cookie: sessionID=s1234; Max-Age=2592000; HttpOnly; Secure
GET / HTTP/1.1
Host: naver.com
Cookie: name=minchul; sessionID=s1234
쿠키의 한계 - 보안
- 쿠키 정보는 브라우저에 노출되어 있으며 조작될 가능성이 있다.
- 보안을 위한 쿠키 속성: HttpOnly, Secure
- HttpOnly: 자바스크립트를 통한 쿠키 접근을 제한하는 속성 → XSS 공격 방지
- Secure: HTTPS 프로토콜을 통한 쿠키 접근만 허용하는 속성
콘텐츠 협상
콘텐츠 협상 (Content nagotiation)
- 클라이언트가 요청한 자원에 대해 가장 적합한 자원의 표현을 제공하기 위한 메커니즘
- 클라이언트가 선호하는 표현 방식을 전달하면, 서버는 이에 맞는 최적의 형태로 응답한다.
콘텐츠 협상 관련 HTTP 헤더 (요청, 응답 헤더 순)
- 미디어 타입 협상: Accept, Content-Type
- 언어 협상: Accept-Language, Content-Language
- 인코딩 협상: Accept-Encoding, Content-Encoding
7장 예정
책 정보
혼자 공부하는 네트워크 : 네이버 도서
네이버 도서 상세정보를 제공합니다.
search.shopping.naver.com
'기록' 카테고리의 다른 글
| 그림으로 이해하는 AWS 구조와 기술 4~5장(EC2, S3) 요약 정리 (0) | 2024.12.21 |
|---|---|
| 그림으로 이해하는 AWS 구조와 기술 1~3장 요약 정리 (0) | 2024.11.23 |
| 혼공네트 1~3장 요약 정리 (0) | 2024.09.15 |
| 혼공컴운 9장~15장 요약 정리 (운영체제 파트) (0) | 2024.08.11 |
| [도서] 객체지향의 사실과 오해 후기 (0) | 2024.03.06 |
'기록' Related Articles
more
