질문과 답변

Answers

Q. "웹 서버"의 여러 가지 의미에 대해 정리해보자. (ex. 웹 서버 소프트웨어, 하드웨어, was...)

하드웨어 측면

웹 사이트의 호스팅 파일(image, .html, .css, .js ...)들을 저장하는 장치
저장하고 있는 파일들을 클라이언트에게 서빙
클라이언트의 요청에 따라 파일들을 저장
소프츠웨어 측면
클라이언트가 호스팅 파일에 접근하는 방법들이 정의된 서버
일반적인 특징
항상 실행 중이어야 한다
항상 인터넷과 연결되어 있어야 한다
항상 같은 IP를 가지고 있어야 한다
정적 웹 서버와 동적 웹 서버
정적 웹 서버
- 이미 만들어져 있는 호스팅 파일들을 서빙하는 서버
동적 웹 서버
- 클라이언트의 요청에 따라 컨텐츠를 처리하는 방법을 포함
- 다양한 요청에 대해 유연하게 처리가 가능
- 더 다양한 기술 스택과 복잡한 구현이 요구됨
  종류
웹 서버
- 정적 파일들을 서빙 하기 위한 정적 웹 서버
웹 어플리케이션 서버
- 요청에 대해 프로그램의 출력을 응답으로 반환하는 동적 웹 서버
리버스 프록시 서버
- 클라이언트와 어플리케이션 서버 사이에 위치하는 프록시 서버
- 로드밸런싱, 페일 오버, 라우팅 등의 기능을 제공
캐시 서버
- 요청에 대한 응답을 캐싱하여 이후 동일 요청에 대해 캐싱된 응답을 반환해주는 서버

Q. IETF ident에서, IETF란 무엇인가?

Q. 서버사이드 인클루드란 무엇인가?

정의

HTML 페이지에 사용하는 지시어로 서버가 HTML 페이지에 동적으로 내용을 추가하여 서비스하는 것
CGI 와 같이 페이지 전체를 만들지 않고 HTML 페이지에 생성된 내용을 추가하는 방식
SSI 문장을 포함하고 있는 파일들은 "*.shtml" 확장자를 사용하도록 정의됨
사용 예
```

This file last modified 
```
LAST_MODIFIED 라는 환경변수의 값을 불러와 설정한 format 에 맞게 해당 HTML 파일에 삽입한 후 서빙한다
SSI 가 올바로 작동하지 않아 해당 태그를 값으로 변환하지 못했더라도 브라우저는 주석으로 처리한다
SSI 명령어 Server Side Includes - Wikipedia

Q. 유형 협상을 통해 MIME TYPE이 결정되는 자세한 과정과 주로 사용되는 상황을 말해보자.

정의

동일한 URI 에서 리소스의 서로 다른 버전을 서빙하기 위해 사용되는 방식
User Agent 가 사용자가에 가장 적합한 것이 무엇인지 명시할 수 있음
방식
클라이언트가 보내는 특정 HTTP 헤더를 이용하는 방법 (서버 주도 협상)
서버의 300, 406 응답 코드를 이용하는 방법 (에이전트 주도 협상)
서버 주도 컨텐츠 협상
클라이언트가 요청 헤더를 통해 최적의 유형을 알리고, 서버가 요청받은 유형들 중 하나로 응답을 내려줌
서버에 의해 구현된 알고리즘이며 표준으로 정의된 것은 아님
단점
- 항상 클라이언트가 요구한 유형에 맞게 응답을 내려줄 수 있다는 보장이 없음
- 요청 헤더가 복잡해지며 클라이언트의 정보가 불필요하게 많이 포함됨
- 서버 구현이 복잡해짐
  서버주도 협상 표준헤더 목록
요청 헤더
- Accept
  - 클라이언트가 처리하고자 하는 미디어 리소스의 MIME 타입
- Accept-CH
  - 클라이언트 힌트라고 불리며 아직 보편적으로 사용되고 있지 않음, 일부 브라우저에만 구현
  - DRP
    클라이언트 기기의 픽셀 비율
  - Viewport-Width
    CSS 픽셀에서의 레이아웃 Viewport
  - Width
    이미지의 고유 사이즈
- Accept-Charset
  - 클라이언트가 수용 가능한 Character encoding type 정의
  - 최근에는 UTF-8 이 사실상의 표준으로 사용되며 대부분의 메이져 브라우저에서는 해당 헤더를 폐기함
- Accept-Encoding
  - 클라이언트가 수용 가능한 Contents encoding type 정의
- Accept-Language
  - 클라이언트가 선호하는 언어를 정의
응답 헤더
- Vary
  - 캐싱된 리소스가 다중 유형을 가지고 있어 클라이언트의 요청 헤더에 따라 응답이 달라질 수 있음을 알림
  - 허용된 유형에 대해서만 캐싱된 리소스를 응답하고 그 외에는 원본 서버를 통해 응답

에이전트 주도 협상
클라이언틍의 요청에 대해 300 응답으로 서버가 지원하는 유형의 리스트를 내려줌
클라이언트는 가장 적절한 유형의 URI 로 다시 요청을 보내고 서버는 해당 유형의 리소스를 응답으로 내려줌
단점
특정 리소스를 받기 위해 두번의 요청 - 응답이 필요

Q. 문맥 정보를 포함하기 위해 재작성된 url로 리다이렉트

해당 내용은 11.5 절에도 포함되어 있는 내용입니다.

특정한 웹사이트가 사용하는 방법으로, 널리 사용되는 표준은 아닌듯 합니다. 서버는 클라이언트와의 문맥 정보를 결정하는 상태 정보를 만들어 url 의 처음이나 끝에 포함합니다. 유저는 사이트를 돌아다니면서 이 상태정보가 유지되도록 하는 동적으로 생성된 하이퍼링크를 사용합니다.

위 그림을 보면 모두 같은 식별번호가 링크에 삽입되어 있는데 현재 문맥 정보를 이어가기 위해서입니다. (클라이언트에서 만료되는 쿠키와는 다르게 서버에서 만료하지 않는 이상 어느 클라이언트든 같은 문맥을 이어갈 수 있는 url)

처음 방문 시에는 fat URL 을 사용하도록 강제하기 위해 유저식별정보를 만들고, 이를 이용한 url 로 강제 리디렉션을 시킵니다. 이에 발생하는 문제점과 자세한 설명에 대해서는 책 p.304 또는 [pdf.en]([http://www.staroceans.org/e-book/O'Reilly - HTTP - The Definitive Guide.pdf](http://www.staroceans.org/e-book/O'Reilly - HTTP - The Definitive Guide.pdf)\) p.245 참고 바람.

Q. 역방향 DNS와 DNS의 차이점?

ref: https://forsenergy.com/ko-kr/dnsmgr/html/99060a7c-f0bd-41e7-8ec8-5eeae2fbf0ad.htm

(정방향) DNS: 도메인 이름 → ip 주소
역방향 DNS: ip 주소 → 도메인 이름

기존의 DNS는 도메인 이름을 구성하고 인덱싱하는 데 특화되어 있기 때문에, 기존 DNS에 IP 주소를 그대로 사용할 수는 없다.따라서 역방향 DNS는 IP 주소와 함께 in-addr.arpa라는 특수 도메인을 이용해 새로운 도메인을 구성한다.

1) IP 주소를 거꾸로 뒤집는다. ex. 1.2.3.4 → 4.3.2.1

IP 주소의 순서는 첫 부분에 가장 일반적인 정보(IP 네트워크 주소)가 들어가고, 마지막 부분에 좀더 특정한 정보(IP 호스트 주소)가 들어가는 구조이다. 이렇게 IP 주소를 왼쪽에서 오른쪽으로 읽으면, DNS와는 반대로 해석되기 때문에, IP 주소를 거꾸로 뒤집어 준다.

2) 뒤집어진 IP 주소 끝에 in-addr.arpa도메인을 추가한다.

이렇게 하면 역방향 DNS에서 검색될 FQDN(정규화된 도메인 이름, ex. 4.3.2.1.in-addr.arpa)이 구성된다.

Q. 모든 클라이언트가 호스트명이 있는가?

호스트명이란, 네트워크에 연결된 장치(컴퓨터, 파일 서버, 복사기, 케이블 모뎀 등)들에게 부여되는 고유한 이름이다. 도메인 이름과 유사하지만 엄밀하게는 더 넓은 의미를 가지고 있다.
호스트명은 보통 사람이 읽고 이해할 수 있는 이름으로 지어지며, 흔히 IP 주소나 MAC 주소와 같은 기계적인 이름 대신 쓸 수 있다. (위키백과)

mac의 경우, 사용자 이름에 local이 붙은 것 (ex. woobin-macbook-pro.local)
windows의 경우, 사용자 이름에 -PC가 붙은 것 (ex. woobin-PC)
안드로이드 기기의 경우, android-ce166eae64b93da4과 같은 형식의 이름을 가진다.

Q. ident 사용자 이름과 호스트 명은 같은 것인가? 다른 것인가?

영어 책 원문

The ident protocol lets servers find out what username initiated an HTTP connection. This information is particularly useful for web server logging—the second field of the popular Common Log Format contains the ident username of each HTTP request.

Ref: https://en.wikipedia.org/wiki/Ident_protocol/https://tools.ietf.org/html/rfc931

username이다. 로컬 사용자 이름인 듯하다.

Previous05. 웹 서버 Next06. 프락시

Last updated 4 years ago