학교
[컴퓨터 네트워크] Chapter2. Application Layer (Part 1) - (2)
[7-0] HTTP request message
1) HTTP 메세지의 2가지 종류
request: 클라이언트가 서버에 정보를 요청할 때 사용한다
response: 서버가 클라이언트의 요청에 대해 답변을 보내는 메세지이다.
[7-1] HTTP request message
(1) 특징
ASCII (사람이 읽을 수 있는 형식으로 구성)
\r: 캐리지 리턴 문자\n: 줄 바꿈 문자캐리지 리턴, 줄 시작 부분의 줄 바꿈은 헤더 줄의 끝을 나타낸다.
(2) 구조
request line(GET, POST, HEAD commands): 클라이언트가 서버에 어떤 작업을 요청하는지를 명시
header lines: 추가 정보를 담고 있다. (브라우저 종류, 요청 리소스의 언어 등)
Body: POST나 PUT 같은 요청에서는 클라이언트가 서버로 전송하는 데이터가 이곳에 담긴다.
(3) general format
request line : method + sp + URL + sp + version + cr + if
header lines : header field name + value + cr + if
body
(4) methods 종류
GET method: 서버로부터 리소스를 가져온다.
리소스 검색
HTTP GET 요청 메시지의 URL 필드( ? 뒤에 오는)에 사용자 데이터를 포함한다.
POST method: 주로 폼 데이터 전송에 사용
웹 페이지는 종종 form 입력이 포함된다.
HTTP POST 요청 메시지의 엔티티 본분(requet의 entity body)에서 클라이언트에서 서버로 전송된 사용자 입력
PUT method: 서버에 새로운 데이터를 업로드하거나 기존 데이터를 대체한다.
새 파일(객체)를 서버에 업로드한다.
지정한 URL에 존재하는 파일을 POST HTTP 요청 메시지의 엔티티 본문(request의 entity body)에 있는 콘텐츠로 완전히 대체한다.
HEAD method: GET 요청과 유사하지만, 응답 본문을 제외하고 헤더 정보만 요청된다.
지정한 URL을 HTTP GET 메소드로 요청할 경우 반환되는 헤더(전용)을 요청한다.
[7-2] HTTP response message
1) 구조
status line (프로토콜 상태 코드 상태 문구): 서버의 응답 상태
header lines: 서버의 정보나 응답에 대한 추가 정보를 전달
Body (예 : 요청된 HTML 파일): 클라이언트가 요청한 HTML 파일이나 리소스가 이곳에 담긴다.
2) HTTP response status code
: 상태 코드는 서버-클라이언트 응답 메시지의 첫 번째 줄에 나타난다.
200 OK: 요청 성공, 이 메세지 후반부에 요청된 객체
301 Moved Permanently: 요청된 객체가 다른 위치로 이동됨. 이 메세지 뒷 부부분에 새 위치가 저장됨. (위치 : 필드)
400 Bad Request: 서버가 요청 메세지를 이해하지 못함.
Not Found: 요청된 문서를 이 서버에서 찾을 수 없음
505 HTTP Version Not Supported: 지원되지 않는 HTTP 버전
[8] Maintaining user/server staste : cookies (사용자 / 서버 상태 유지 : 쿠키)
1) 특징 1
Recall : HTTP GET/response 상호작용은 'state'가 없다.: HTTP는 기본적으로 무상태 프로토콜이다.
웹 '트랜잭션'을 완료하기 위한 HTTP 메세지의 다단계 교환 개념이 없다.
클라이언트 / 서버가 다단계의 교환 상태를 추적할 필요가 없다.
모든 HTTP 요청은 서로 독립적이다. (이전에 했던 요청과 연관되지 않는다.)
클라이언트 / 서버가 부분적으로 완료되었지만, 완전히 완료되지 않은 트랜잭션에서 복구할 필요가 없다.
상태 저장 프로토콜:
쿠키는 클라이언트의 상태를 서버가 기억하도록 돕는다.: 클라이언트가 X를 두 번 변경하거나 전혀 변경하지 않는다.
2) 그림 설명
클라이언트가 서버의 데이터 레코드 X에 대해 잠금, 업데이트, 잠금 해제 작업을 수행하는 과정을 보여준다.
각 단계마다 서버는 'OK' 응답을 보내며, 데이터 상태가 변경된다. (X -> X', X' -> X'')
3) Q. 't' 시점에서 네트워크 연결이 끊기거나, 클라이언트가 충돌하면 어떻게 되는가?
A. 't' 시점에서 연결이 끊기거나, 클라이언트가 충돌하면 다음과 같은 상황이 발생할 수 있다.
데이터 일관성 문제: X'로 업데이트 된 후 X''로의 업데이트가 완료되지 않은 상태에서 중단되어, 서버의 데이터가 불완전한 상태로 남을 수 있다.
잠금 해제 실패: 클라이언트가 데이터 잠금을 해제하지 못해, 다른 클라이언트가 해당 데이터에 접근하지 못할 수 있다.
트랜잭션 미완료: 전체 작업이 완료되지 않아 데이터의 경합성이 깨질 수 있다.
이러한 문제를 해결하기 위해 서버 측에서 '타임아웃 메커니즘, 트랜잭션 롤백, 자동 잠금 해제' 등의 방법을 구현해야 하며, 클라이언트 측에서는 '재연결 및 상태 복구 로직'을 구현하여 중단된 작업을 안전하게 재개하거나 취소할 수 있어야 한다.
4) 특징 2 (쿠키의 구성 요소)
: 웹 사이트와 클라이언트 브라우저는 쿠키를 사용하여 트랜잭션 사이의 '네 가지 구성 요소의 상태'를 유지한다.
HTTP 응답 메시지의 쿠키 헤더 라인: 서버가 클라이언트에게 쿠키를 전달한다.
다음 HTTP 요청 메시지의 쿠키 헤더 라인: 클라이언트는 이후 요청에서 서버에게 쿠키를 다시 보낸다.
사용자의 호스트에 보관되고, 사용자의 브라우저에 의해 관리되는 쿠키 파일: 쿠키는 사용자의 브라우저에 저장된다.
웹 사이트의 백엔드 데이터베이스: 서버는 쿠키 정보를 통해 사용자 상태를 저장하고 관리한다.
5) 예시
수찬이 노트북에서 브라우저를 사용하여 특정 어커머스 사이트를 처음 방문함
초기 HTTP 요청이 사이트에 도착하면 사이트에서 생성된다.
고유한 ID (일명, 쿠키)
백엔드 데이터베이스의 ID 항목
수찬이 이 사이트로 보내는 후속 HTTP 요청에는 쿠키 ID 값이 포함되어 사이트가 수찬을 식별할 수 있다.
[9] HTTP 쿠키 : 코멘트
1) 쿠키의 사용 목적
authorization: 사용자가 웹사이트에 로그인하면, 쿠키를 통해 인증 정보를 저장하여 로그인을 유지할 수 있다.
shopping carts: 쇼핑몰에서 상품을 장바구니에 담았을 때, 쿠키를 통해 해당 상품 정보를 저장하여 페이지를 이동해도 장바구니가 유지된다.
recommendations: 사용자의 활동 기록을 바탕으로 맞춤형 추천 콘텐츠를 제공할 수 있다.
user session state (Web e-mail): 웹 메일이나 기타 웹 서비으세어 사용자의 세션을 유지하여 사용자가 계속 작업을 이어갈 수 있도록 한다.
2) 상태 유지 방법
프로토콜 엔드 포인트: 여러 트랜잭션에 걸쳐 발신자/수신자의 상태 유지
쿠키 : HTTP 메시지를 통해 클라이언트의 상태 정보를 전달하여 서버가 사용자의 상태를 기억할 수 있도록 한다.
3) 쿠키 및 개인 정보
쿠키를 사용하면 사이트가 사이트에서 사용자에 대한 많은 정보를 얻을 수 있다.
타사 영구 쿠키 (추척 쿠키)를 사용하면 여러 웹 사이트에서 공용 ID (쿠키 값)을 추적할 수 있다.
[10] Web caches (프록시 서버)
: 목표는 원본 서버의 개입 없이 클라이언트 요청 충족하는 것이다.
: 웹 캐시는 클라이언트가 원본 서버에 직접 접속하지 않고도 필요한 리소스를 빠르게 제공받을 수 있도록 도와주는 시스템이다.
1) 특징 1 (웹 캐시의 동작)
사용자가 웹 캐시를 가리키도록 브라우저를 구현한다. (브라우저 설정을 통해 웹 캐시 서버를 가리키도록 설정 가능)
브라우저가 모든 HTTP 요청을 캐시로 전송한다.a. 캐시에 객체가 있는 경우: 캐시는 객체를 클라이언트에게 반환한다.b. 그렇지 않은 경우: 캐시는 원본 서버에서 객체를 요청하고, 수신된 객체를 캐시한 다음 객체를 클라이언트에게 반환한다.
fast loading / cpu-memory
bottle leck, large data 에도 용이하다
2) 특징 2 (웹 캐시의 특징)
웹 캐시는 클라이언트와 서버 역할을 모두 수행한다.a. 원본 요청 클라이언트를 위한 서버 (클라이언트를 위한 서버 역할): 클라이언트가 요청한 리소르를 반환한다.b. 클라이언트에서 원본 서버로 (서버를 위한 클라이언트 역할): 원본 서버로부터 데이터를 받아오고 저장한다.
일반적으로 캐시는 ISP(대학, 회사, 주거용)에서 설치한다.
CDN와 유사하다. (Content Delivery Network)
3) Q. 왜 캐싱인가?
클라이언트 요청에 대한
응답 시간 단축캐시가 클라이언트에 더 가깝게 위치한다.
교육 기관 접속 링크의
트래픽 감소인터넷은 캐시와 밀접되어 있다. (
효율적인 콘텐츠 제공)열약한 콘텐츠 제공업체가 콘텐츠를 보다 효과적으로 제공할 수 있도록 지원한다.
[11] Caching example
1) 시나리오
access link rate (접속 링크 속도) : 1.54 Mbps
RTT from institutional router to server (서버와의 왕복 시간) : 2 sec (1 RTT)
Web object size (웹 객체 크기) : 100K bits
Average request rate from browser to origin server (원본 서버에 대한 평균 요청 빈도) : 15회/sec
average data rate to browsers (브라우저로의 평균 데이터 전송 속도) : 1.50 Mbps (15 req/sec * 100K bits)
2) Performance (성능 분석)
LAN untilization (LAN 사용률) : .0015
access link utlization (접속 링크 사용률) : 0.97 (1.5 M
end-end delay = Internet delay + access link delay + LAN delay= 2 sec + minutes + useces
3) Calculating access link untilization, end-end delay with cache
Web Cache 설치 후 액세스 링크 이용률 및 엔드-투-엔드 지연 계산
캐시 히트율이 0.4 (40%)라고 가정: 40%의 요청이 캐시에서 만족되고, 60%는 원본 서버에서 만족됨.
액세스 링크: 60%의 요청이 액세스 링크를 사용함.
브라우저로의 데이터 전송 속도: 액세스 링크를 통한 전송 속도는 0.6 * 1.5 Mbps = 0.9 Mbps
액세스 링크 사용률: 0.9 / 1.54 = 0.58.
평균 엔드-투-엔드 지연: 0.6 * 2.01 + 0.4 * ms: 약 1.2초로 지연이 감소됨.
결론: 웹 캐시를 사용하면 154Mbps 링크보다 평균 엔드-투-엔드 지연이 더 낮아지고, 비용도 절감됨.
[12] Exercise
1) 캐싱 없는 경우 성능 계산 예시
액세스 링크 속도: 15Mbps.
기관 라우터에서 서버까지의 RTT: 3초.
웹 객체 크기: 850,000비트.
브라우저에서 원본 서버로의 평균 요청 속도: 16개 요청/초.
평균 액세스 지연 계산 (t / 1 - (t*a)): t는 객체를 액세스 링크를 통해 전송하는 데 필요한 평균 시간.: t = 0.0567초. ( L / R = 850,000 / 15,000,000): 요청 도착 속도 a = 16/초.: 트래픽 강도와 평균 액세스 지연 계산= 0.0567 / (1 - (0.0567 * 16/sec))= 0.0567 / (1 - 0.9072)= 0.0567 / 0.0928= 0.6109913793=>
약 0.6초총 평균 응답 시간: RTT + average access delay = 3초 + 0.6초 ≈ 3.6초.
2) 캐시를 사용하는 경우 성능 계산 예시
캐시가 설치된 상황에서의 성능:: 캐시 미스율 0.4 가정.
캐시 히트율 60%의 경우:: 캐시 히트 시 응답 시간이 거의 0에 가까움.
캐시 미스 시 액세스 지연:: 캐시 미스율이 0.4일 때, 액세스 링크를 통해 데이터 전송 시 평균 지연 시간은 1.44초.: 최종 응답 시간 계산 시 캐시 미스를 고려한 결과= 0.6 * 0 + 0.4 * 3.61= 0 + 1.444 = 1.444= 약 1.44초
