이 글은 강민철님의 혼자 공부하는 네트워크(인프런) 강의를 수강하고 개인적으로 정리한 내용입니다.
들어가며
응용 계층은 전송 계층보다 한 단계 높은 계층으로, 사용자와 가장 가까운 계층이다.
특히나 웹 개발자들은 웹 어플리케이션에서 HTTP로 통신을 수행하기 때문에 작동 방식을 이해하는 것이 중요하다.
이번 장에서는 DNS부터 URL, HTTP에 대해서 알아보고자 한다.
DNS
메세지의 전송 과정에서 필요한 것
1. 메세지를 주고 받는 송수신지 - IP 주소, 도메인 네임
2. 송수신하고자 하는 정보 - 자원(URL)
도메인 네임이란?
호스트의 IP 주소와 대응되는 문자열 형태의 호스트 정보
ex) www.naver.com, www.github.com 등
모든 호스트의 IP 주소를 기억하는 것은 번거롭고, 언제든 변경이 가능하기 때문에 네임 서버에서 관리한다.
네임 서버 (DNS 서버)
| 도메인 명 | IP 주소 |
| www.naver.com | 1.2.3.4 |
하나의 도메인은 점을 기준으로 계층적으로 이루어져 있다.
이러한 계층적인 도메인의 서버 또한 계층적으로 관리되어 전 세계 여러군데 분산되어 위치한다.
DNS 자원 레코드
네임 서버에 저장되는 값 (즉, 네임 서버에는 DNS 자원 레코드들이 저장)
이름, 값, TTL, 레코드 유형으로 구성
| 타입 | 이름 (도메인 이름) | 값 (IP 주소) | TTL |
| A | naver.com | 1.2.3.4 | 300 |
대표적인 레코드 유형
전체 주소 도메인 네임 (FQDN)
서브 도메인
다른 도메인이 포함된 도메인
ex) google.com의 서브 도메인
- mail.google.com, drive.google.com 등
도메인 네임에 대응하는 IP 주소를 알아내는 과정
주요 네임 서버는 아래 4가지가 있다.
1. 로컬 네임 서버
2. 루트 네임 서버
3. TLD 네임 서버
4. 책임 네임 서버
각각을 통해 도메인 네임이 어떻게 IP 주소를 찾아내는지 알아보자.
1. 로컬 네임 서버
- 클라이언트와 가장 가까이 맞닿아있는 네임 서버
- 나머지 3개의 네임 서버에 IP 주소가 뭔지 차례로 물어본다.
2. 루트 네임 서버
- 루트 도메인을 관장하는 네임 서버
- 대응되는 IP 주소를 모를 경우, TLD 네임 서버의 주소를 반환한다.
3. TLD 네임 서버
- TLD를 관리하는 네임 서버
- TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환한다.
4. 책임 네임 서버
- 특정 도메인 영역을 관리하는 네임 서버
- 다른 네임 서버에 넘기지 않고 곧바로 답할 수 있는 네임 서버
이렇게 각 서버들에게 질의를 하는 방식에는 2가지가 있다.
1. 재귀적 질의
2. 반복적 질의
하지만 앞선 방법들은 8단계나 되는 질의/응답을 거치게 되기 때문에,
시간이 오래 걸리고 네트워크 상의 메세지 수가 지나치게 늘어난다는 문제를 가질 수 있다.
즉, 루트 네임 서버에 과부하가 우려된다.
DNS 캐시
네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 대해 이를 활용
DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있다.
URI : 자원을 식별하는 방법
자원 (resource)
네트워크 상의 메세지를 통해 주고받는 대상
ex) 텍스트 파일, HTML 파일, 이미지, 동영상 등
자원은 2가지로 나눌 수 있다.
1) URL(uniform resource locator) : 위치를 기반으로 자원을 식별
2) URN(uniform resource name) : 이름을 기반으로 자원을 식별
URL의 구성
| 구성 | 설명 | 내용 |
| scheme | 자원에 접근하는 방법 | 프로토콜 |
| authority | 호스트를 특정할 수 있는 정보 | IP주소나 도메인명 |
| path | 자원이 위치한 경로 | 슬래시를 기준으로 계층적으로 표현 |
| query | 자원에 필요한 추가적인 정보 | ?로 시작하고, &로 이을 수 있는 [키=값]형태의 데이터 |
| fragment | 자원의 한 조각을 가리키기 위한 정보 | #으로 시작 |
query는 아래와 같은 경우에 필요하다.
정리
1. 메세지의 전송 과정에서 알아야 하는 것은 송수신지의 주소와 전달하고자 하는 메세지를 식별하는 정보이다.
2. 도메인 네임이란 IP 주소를 식별할 수 있는 문자열로 저장한 것을 의미한다.
3. 하나의 도메인은 점을 기준으로 계층적으로 저장되어있다.
4. 주요 네임 서버에는 4개가 있는데, 로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 네임 서버가 있다.
5. 도메인 네임에 대응하는 IP 주소를 알아내는 과정은 4개의 네임 서버를 재귀적으로 질의하는 방식과 반복적으로 질의하는 2가지 방식이 있다.
6. 이때 기존에 응답받은 결과를 임시로 저장할 수 있다면 DNS 캐시에 저장하고, 추후 같은 질의에 대해 이를 활용한다.
7. URI는 자원을 식별하는 방법을 의미하고, 위치를 통해 구별하는 URL과 고유한 이름을 통해 구별하는 URN으로 나눌 수 있다.
8. url은 scheme, authority, path, query, fragment로 구성되어 있다.
HTTP
HTTP는 크게 4가지 특성을 가진다.
1. 요청-응답 기반의 프로토콜이다.
2. 미디어 독립적인 프로토콜이다.
3. 상태를 유지하지 않는 프로토콜이다.
4. 지속 연결을 지원하는 프로토콜이다.
각각에 대해서 살펴보자.
1. 요청-응답 기반의 프로토콜
요청 메세지와 그에 답장하는 응답 메세지로 구성되어 있는 프로토콜
2. 미디어 독립적인 프로토콜
미디어 타입(메세지로 주고받는 자원의 타입)에 특별한 제한을 두지 않는 프로토콜
미디어 타입
데이터 유형/타입에 대한 세부 유형 형식으로 구성
ex) type/html, type/text; charset=UTF-8 (매개변수 포함 가능)
타입 : text, image, video 등
서브 타입 : text/plain, text/html, text/css 등
여러 미디어 타입을 통칭할 때는 *을 쓰기도 한다. (ex) text/*, image/* 등)
3. 스테이트리스 프로토콜
서버가 HTTP 요청을 보낸 클라이언트의 상태를 기억하지 않음
그렇다면 왜, HTTP는 상태를 유지하지 않을까?
그 이유는 HTTP 프로토콜의 설계 목표가 확장성과 견고성이기 때문이다.
상태를 유지하지 않는 특성은
특정 클라이언트가 특정 서버에 종속되지 않게 하고,
서버에 문제가 생겨도 다른 서버로 대체하기 용이하다는 장점이 있기 때문에 확장성이나 견고성에 유리하다.
4. 지속 연결 프로토콜
하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술
비지속 연결 : TCP연결(3 way handshake) -> 요청에 대한 응답 -> 연결 종료(4 way handshake)
지속 연결 : 한 번의 연결과 종료 사이에 여러개의 요청-응답을 주고받을 수 있음 (=> 불필요한 연결과 해제에 드는 시간 절약)
HTTP 메세지 구조 (1.1 버전)
시작 라인
필드 라인 (0개 이상)
메세지 본문 (선택)
| 구분 | 요청 | 응답 |
| 시작 라인 | 요청 라인 메서드 / 요청 대상 / HTTP 버전 ex) GET /my HTTP/1.1 |
상태 라인 HTTP 버전 / 상태 코드 / 이유 구문(선택) ex) HTTP/1.1 404 Not Found |
| 필드 라인 | 0개 이상의 HTTP 헤더(통신에 필요한 부가 정보)를 명시 형태 : 콜론을 기준으로 헤더 이름과 하나의 헤더 값으로 구성 ex) Host: www.naver.com |
|
| 메세지 본문 | HTTP 요청이나 응답에서 주고받을 데이터를 명시 다양한 콘텐츠 타입이 사용 가능 (ex) Json, HTML 등) |
|
HTTP 메서드
| 메서드명 | 설명 |
| GET | 자원을 습득하기 위한 메서드 |
| HEAD | GET과 동일하나 헤더만을 응답받는 메서드 |
| POST | 서버로 하여금 특정 작업을 처리하게끔 하는 메서드 (주로 서버에 새로운 자원을 생성) |
| PUT | 자원을 대체하는 메서드 |
| PATCH | 자원에 대한 부분적인 수정을 위한 메서드 |
| DELETE | 자원을 삭제하기 위한 메서드 |
요청 메서드 예시
1) get
GET /my HTTP/1.1
Host: example.com
Accept: *
2) post
POST /posting HTTP/1.1
Host: example.com
{
id: 1,
title: '제목',
contents: '안녕하세요'
}
어떤 URL에 어떤 메서드로 요청 받았을 때, 서버에서 하는 행동은 개발자가 결정하는 것이다.
HTTP 상태 코드
요청에 대한 결과를 나타내는 세 자리 정수 (100의 자리수를 기준으로 구분)
| 상태 코드 | 설명 |
| 100번대 (100~199) | 정보성 |
| 200번대 (200~299) | 성공 |
| 300번대 (300~399) | 리다이렉션 |
| 400번대 (400~499) | 클라이언트 에러 |
| 500번대 (500~599) | 서버 에러 |
1) 200번대 - 성공 상태 코드
요청이 성공했음을 의미한다.
| 상태 코드 | 이유 구문 | 설명 | 추가 설명 |
| 200 | OK | 요청 성공 | |
| 201 | Created | 요청 성공 + 자원 생성 | Location 헤더에 생성된 자원 위치를 명시 |
| 202 | Accepted | 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않음 | 요청 결과를 응답하기 어려운 경우에 사용 ex) 대용량 파일 업로드, 배치 작업 |
| 204 | No Content | 요청을 잘 받았으나, 메세지 본문으로 표시할 데이터 없음 |
2) 300번대 - 리다이렉션 상태 코드
리다이렉션
클라이언트가 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것
클라이언트는 301번 상태 코드를 받고, 새로운 주소로 재요청한다.
리다이렉션은 2가지 종류로 나누어진다.
1) 영구적인 리다이렉션
- 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것
- 따라서 기존의 URL에 접속할 필요가 없으므로 항상 새로운 URL로 리다이렉트
| 상태 코드 | 이유 구문 | 설명 |
| 301 | Moved Permanently | 영구적 리다이렉션; 재요청 메서드 변경될 수 있음 |
| 308 | Permanent Redirect | 영구적 리다이렉션; 재요청 메서드 변경되지 않음 |
2) 일시적인 리다이렉션
- 자원의 위치가 임시적으로 변경되었거나, 임시로 사용할 URL이 필요한 경우에 주로 사용
- 어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답받았다면 여전히 요청을 보낸 URL은 기억
| 상태 코드 | 이유 구문 | 설명 |
| 302 | Found | 일시적 리다이렉션; 재요청 메서드 변경될 수 있음 |
| 303 | See Other | 일시적 리다이렉션; 재요청 메서드 GET으로 변경 |
| 307 | Temporary Redirect | 일시적 리다이렉션; 재요청 메서드 변경되지 않음 |
3) 400번대 - 클라이언트 에러 상태 코드
클라이언트에 의한 에러가 있음을 알려주는 상태 코드
| 상태 코드 | 이유 구문 | 설명 |
| 400 | Bad Request | 클라이언트의 요청 형식이 잘못되었음 |
| 401 | Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 |
| 403 | Forbidden | 요청이 서버에 의해 거부됨 |
| 404 | Not Found | 요청받은 자원을 찾을 수 없음 |
| 405 | Method Not Allowed | 요청한 메서드를 지원하지 않음 |
인증과 인가
인증 : 내가 누구인지 증명하는 것(로그인) => 누구니?
인가 : 인증된 주체에게 작업을 허용하는 것 (관리자 페이지에는 관리자만 접속 가능) => 역할이 뭐니?
4) 500번대 - 서버 에러 상태 코드
서버에서 발생할 수 있는 에러 상태 코드
| 상태 코드 | 이유 구문 | 설명 |
| 500 | Internal Server Error | 요청을 처리할 수 없음 |
| 502 | Bad Gateway | 중간 서버의 통신 오류 |
| 503 | Service Unavailable | 현재는 요청을 처리할 수 없으나 추후 가능할 수 있음 |
에러를 500으로 통칭하는게 보안상 더 안전하다. 구구절절 이유를 설명한다면 잘못 설계된 것임.
HTTP의 발전 (HTTP/0.9 ~ HTTP/3.0)
1) HTTP/0.9
현재 거의 사용되지 않는 초창기 버전
사용가능한 메서드가 get뿐이고, 헤더가 지원되지 않는다.
2) HTTP/1.0
HEAD, POST 등 GET 이외에 메서드 도입
헤더 지원 (다양한 부가정보)
3) HTTP/1.1
오늘날까지 널리 사용되는 버전
지속 연결 지원
메세지 본문은 평문
HOL 블로킹 (head of line blocking)
같은 큐에 대기하는 패킷이 많아질 경우 지연되는 문제 발생
4) HTTP/2.0
오늘날까지 널리 사용되는 버전
HTTP/1.1의 효율과 성능을 높이기 위한 버전
메세지 본문은 바이너리 데이터까지 가능
헤더 압축 전송 기능
서버 푸시 기능 (클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송)
HTTP 멀티플렉싱 - 여러개의 스트림을 활용해 병렬적으로 메세지를 주고받는 기술
5) HTTP/3.0
오늘날 점차 사용이 확대되는 버전
이전까지의 HTTP는 TCP를 기반으로 동작했으나, 3.0은 UDP를 기반으로 동작
빠른 송수신 가능
HTTP 헤더
필드 이름(헤더 이름)과 필드 값(헤더 값)이 콜론을 기준으로 구분
헤더 유형
1) 특별한 사전 지식이 필요하지 않은 헤더
2) 사전 지식이 필요한 헤더 ex) 캐시, 쿠키, 콘텐츠 협상 관련 헤더 등
먼저 특별한 사전 지식이 필요하지 않은 헤더를 살펴보자.
헤더는 사용되는 곳에 따라 3가지로 나눌 수 있다.
1. HTTP 요청 시 주로 사용되는 헤더
2. HTTP 응답 시 주로 사용되는 헤더
3. HTTP 요청과 응답 시 주로 사용되는 헤더
HTTP 요청 시 주로 사용되는 헤더
1) Host
요청을 보낼 호스트를 나타내는 헤더 (최종 목적지)
2) User-Agent
HTTP 요청을 시작하는 클라이언트 측의 프로그램
ex) 웹 브라우저
3) Referer
클라이언트가 요청을 보낼 때 머무르고 있던 URL
클라이언트가 어디서 유입되었는지를 확인할 수 있다
4) Authorization
클라이언트의 인증 정보를 담는 헤더
인증 타입과 인증을 위한 정보를 명시
ex) Authorization: [type] [credentials]
HTTP 응답 시 주로 사용되는 헤더
1) Server
요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시
ex) Server: Apache/2.4.1 (Unix) - Unix 운영체제에서 동작하는 아파치 HTTP 서버를 의미
2) Allow
클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용
상태 코드 405를 응답하는 메세지에서 사용
3) Retry-After
상태 코드 503과 함께 사용될 수 있는 헤더
자원을 사용할 수 있는 날짜나 시각을 나타냄
ex) Retry-After : Fri, 23 Aug 2024 09:00:00 GMT
4) Location
클라이언트에게 새롭게 생성된 자원의 위치를 알려주기 위해 사용되는 헤더
주로 리다이렉션이나 새로운 자원이 생성되었을 때 사용
5) WWW-Authenticate
상태 코드 401(Unauthorized)과 함께 사용되는 헤더
자원에 접근하기 위한 인증 방식
ex) WWW-Authenticate: Basic
요청과 응답 헤더를 통한 HTTP (basic type) 인증 과정
1. 인증되지 않은 클라이언트가 서버에 GET 요청 메세지 전송
2. 서버가 401과 함께 WWW-Authenticate 헤더를 통해 인증 방식 알림
3. 클라이언트는 사용자로부터 인증 정보를 전달받음
4. 클라이언트는 Base64 인코딩한 값을 Authorization 헤더를 통해 요청 메세지를 전송
5. 서버는 인증 정보를 확인
6. 인증이 유효하면 200 응답 / 유효하지 않으면 401 응답
요청과 응답 모두에서 활용되는 HTTP 헤더
1) Date
메세지가 생성된 날짜와 시각에 관련된 정보
ex) Date: Tue, 15 Nov 1994 08:12:31 GMT
2) Connection
클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더
ex) Connection: keep-alive | close
3) Content-Length
본문의 바이트 단위 크기
ex) Content-Length: 100
4) Content-Type, Content-Language, Content-Encoding
메세지 본문의 표현 방식을 설명하는 헤더
표현 헤더의 일종
Content-Type : 메세지 본문에서 사용된 미디어 타입
Content-Language : 메세지 본문에 사용된 언어-국가코드
Content-Encoding : 메세지 본문을 압축하거나 변환한 방식
HTTP 기반 기술 3가지
HTTP 기반의 기술은 크게 3가지가 있다.
1. 캐시
2. 쿠키
3. 콘텐츠 협상
각각에 대해서 알아보고, 이와 관련된 헤더들도 알아볼 것이다.
1. 캐시
서버로부터 응답받은 자원의 사본을 임시적으로 저장하는 기술
응답받은 자원의 사본을 임시적으로 저장하면, 추후 동일한 요청에 대해 캐싱된 데이터를 재활용할 수 있다.
=> 불필요한 대역폭을 방지하고 응답이 지연되는 것을 방지할 수 있다.
네트워크에서 사용되는 캐시는 2가지가 있다.
1) 개인 전용 캐시 - 웹 브라우저에 저장
2) 공용 캐시 - 클라이언트와 서버 사이에 위치한 중간 서버에 저장
이번 장에서는 개인 전용 캐시에 대해서만 언급한다.
캐시 신선도
캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지를 표현
캐시는 원본이 아닌 사본을 저장하기 때문에, 저장된 캐시 데이터가 얼마나 최신 상태인지가 중요하다.
캐시 신선도의 검사
1) If-Modified-Since 헤더 (요청 헤더) : 날짜를 기반으로 서버에게 물어보는 방법
GET /index/html HTTP/1.1
Host: www.example.com
If-Modified-Since: Fri, 23 Aug 2024 09:00:00 GMT
=> 이렇게 보내면 2024년 8월 23일 금요일 이후에 www.example.com/index.html의 자원이 변경되었을 경우에만 새 자원으로 응답해달라는 의미이다.
이때, 자원의 변경 여부 뿐만 아니라 자원이 마지막으로 수정된 시점을 알 수 있는 것이 상태 코드 304이다.
304 응답 코드를 받는다면, 캐시된 데이터가 안바꼈으니 그냥 쓰세요! 라는 의미가 된다.
2) If-None-Match 헤더 (요청 헤더) : 엔티티 태그를 기반으로 서버에게 물어보는 방법
엔티티 태그 : 자원의 버전(변경 사항)을 식별하기 위한 정보
서버에게 이 Etag 값과 일치하는 자원이 있는지 물어봄
GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: 'abc'
여기까지가 캐시의 신선도를 검사할 수 있는 2가지 방식(날짜 기반, eTag 기반)이다.
2. 쿠키
서버에서 생성되어 클라이언트 측에 저장되는 데이터
상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단으로, <이름, 값>의 형태를 띈다.
클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 요청 메세지를 보낼 때, 쿠키를 포함해서 전송한다.
이때 서버는 쿠키 값을 통해서 요청이 같은 클라이언트에서 왔는지, 로그인 상태를 유지하고 있는지 등을 알 수 있다.
세션 인증
앞서 HTTP는 스테이트리스 프로토콜이라고 했다.
즉, 같은 클라이언트가 요청을 보내도 같은 클라이언트인지 모른다는 것이다.
그렇다면, 이미 로그인 한 사용자가 요청을 보낼 때마다 항상 번거로운 인증 과정을 거쳐야 할까?
이를 해결하는 것이 쿠키이다. 쿠키를 기반으로 세션 인증을 하는 과정은 아래와 같다.
1. 클라이언트는 서버에게 인증 정보를 전송한다. (A의 로그인 정보 전송)
2. 인증 정보가 올바르다면, 서버는 세션 아이디를 생성해 클라이언트에게 쿠키를 통해 전송한다. (A 로그인 처리)
3. 서버는 생성한 세션 아이디를 데이터베이스 등에 저장한다. (A의 티켓 저장)
4. 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송한다. (A가 티켓을 냄)
5. 서버는 쿠키 속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별한다. (A의 티켓이 맞는 번호인지 확인)
쿠키 관련 헤더
Cookie 헤더 (요청 헤더) : 클라이언트가 서버에게 쿠키를 전송해주는 헤더
Set-Cookie 헤더 (응답 헤더) : 서버가 클라이언트에게 쿠키를 전송해주는 헤더
쿠키 관련 속성들
1) domain : 해당 쿠키를 주고받을 도메인을 설정하기 위한 값
2) path : 같은 도메인이라도 쿠키를 경로별로 구분하고 싶을 때 사용하는 값
3) expires : 쿠키 만료 시점을 설정하기 위한 값
4) max-age : 초 단위의 유효 기간을 지정하기 위한 값
5) secure : https 프로토콜이 사용되는 경우만 쿠키를 전송
6) httpOnly : HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성
웹 스토리지
쿠키는 서버로 자동적으로 전송되나, 웹 스토리지의 정보는 서버로 자동 전송되지 않는다.
1) 로컬 스토리지 : 별도로 삭제하지 않는 한 영구적으로 저장이 가능
2) 세션 스토리지 : 세션이 유지되는 동안 유지되는 정보
3. 콘텐츠 협상
같은 URI에 대해서 가장 적합한 자원의 형태를 제공하는 메커니즘
같은 URI로 식별가능한 HTML 문서라고 해도, 영어로 요청하면 영어로 된 형태로 제공하고, 한국어로 요청하면 한국어로 된 형태를 제공한다.
콘텐츠 협상 관련 헤더
1) Accept 헤더 : 선호하는 미디어 타입
2) Accept-Language 헤더 : 선호하는 언어
3) Accept-Charset / Accept-Encoding 헤더 : 선호하는 문자 인코딩과 압축 방식
정리
1. HTTP는 4가지 특징을 가진다. (요청-응답 기반, 미디어 독립적, 지속 연결 기반, 상태를 저장하지 않음)
2. HTTP 메세지는 시작 라인(요청 라인, 응답 라인), 필드 라인(헤더), 메세지 본문으로 구성되어 있다.
3. 요청 라인에서는 메서드 요청 url http 버전을 순서대로 써야 하고, 응답 라인에서는 http 버전 상태 코드 이유 구문을 순선대로 써야 한다.
4. 요청 라인에 쓰는 메서드는 GET, POST, HEAD, DELETE, PUT, PATCH가 있다.
5. 응답 라인에 쓰는 상태 코드는 100~500번대 까지 100번대 단위로 구분할 수 있다.
6. 메세지의 필드 라인에는 헤더가 들어가는데, 요청 시 쓰이는 헤더 / 응답 시 쓰이는 헤더 / 요청 및 응답 모두 쓰이는 헤더로 구분할 수 있다.
7. 요청 시 쓰이는 헤더는 Host, User-Agent, Referer, Authorization가 있고, 응답 시 쓰이는 헤더는 Server, Allow, Retry-After, Location, WWW-Authenticate가 있다.
8. 그리고 요청과 응답 모두 쓰이는 헤더는 Date, Connection, Content-Length, Content-Type, Content-Language, Content-Encoding가 있다.
9. HTTP 기반의 기술은 3가지가 있다. (캐시, 쿠키, 콘텐츠 기반 협상)
10. 캐시는 서버로 부터 받은 응답을 클라이언트에 임시적으로 저장하는 기술이다. 이때 사용되는 헤더는 If-Modified-Since와 If-None-Match 헤더이다.
11. 쿠키는 서버에서 생성해 클라이언트에 저장되는 기술으로, 주로 인증 시 사용된다. 이때 사용되는 헤더는 Set-Cookie와 Cookie이다.
12. 콘텐츠 협상은 같은 URI에 대하여 가장 적합한 자원의 형태를 제공하는 매커니즘으로, 같은 문서라도 우선순위에 따라 다른 컨텐츠를 제공한다.
'💻 CS > 🫧 네트워크' 카테고리의 다른 글
| [혼자 공부하는 네트워크] (5) 전송 계층 (0) | 2025.01.23 |
|---|---|
| [혼자 공부하는 네트워크] (4) 네트워크 계층 (3) | 2025.01.21 |
| [혼자 공부하는 네트워크] (3) 물리 계층과 데이터 링크 계층 (2) | 2025.01.19 |
| [혼자 공부하는 네트워크] (2) 컴퓨터 네트워크 시작하기 (2) | 2025.01.17 |
| [혼자 공부하는 네트워크] (1) 목차 (2) | 2025.01.16 |