자바스크립트 this

자바스크립트는 함수를 호출할 때 기존 매개변수로 전달되는 값과 arguments 객체this 인자가 함수 내부로 암묵적으로 전달된다.

객체의 메서드를 호출할 때 this 바인딩

메서드 내부 코드에서 사용된 this는 해당 메서드를 호출한 객체로 바인딩된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
var myObject = {
name: 'foo',
sayName: function() {
console.log(this.name);
}
};

var otherObject = {
name: 'bar'
};

otherObject.sayName = myObject.sayName;

myObject.sayName(); // foo
otherObject.sayName(); // bar

함수를 호출할 때 this 바인딩

함수 내부 코드에서 사용된 this는 전역 객체에 바인딩 된다.

전역객체란?

  • 브라우저 환경에서 자바스크립트를 실행하는 경우, 전역객체는 window 객체가 된다.
  • 자바스크립트 런타임 환경에서의 전역객체는 gloabl 객체가 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
var value = 100;

var myObject = {
value: 1,
func1: function () {
this.value += 1;
console.log(this.value); // 2

func2 = function () {
this.value += 1;
console.log(this.value); // 101

func3 = function () {
this.value += 1;
console.log(this.value); // 102
}
func3()
}
func2()
}
};

myObject.func1();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var value = 100;

var myObject = {
value: 1,
func1: function () {
var that = this; // 내부함수가 부모함수 this 접근가능하도록 변수에 저장.

this.value += 1;
console.log(this.value); // 2

func2 = function () {
this.value += 1;
console.log(this.value); // 3

func3 = function () {
this.value += 1;
console.log(this.value); // 4
}
func3()
}
func2()
}
};

myObject.func1();

생성자 함수를 호출할 때 this 바인딩

기존 함수에 new 연산자를 붙여서 호출하면 해당 함수는 생성자 함수로 동작한다.

일반 함수에 new를 붙여 호출하면 원치 않는 생성자 함수처럼 동작 할 수 있으므로 함수 이름의 첫 문자를 대문자로 쓰기를 권한다.

생성자 함수가 동작하는 방식

  1. 빈 객체 생성 및 this 바인딩
    • 생성자 함수가 실행되기 전 빈객체가 생성된다.
  2. this를 통한 프로퍼티 생성
    • 내부에서 this를 사용해서, 앞에서 생성된 빈 객체에 동적으로 프로퍼티나 메서드를 생성할 수 있다.
  3. 생성된 객체 리턴
    • 리턴문이 없을 경우, this로 바인딩된 새로 생성한 객체가 리턴된다.
    • 리턴값이 객체(this)가 아닌 다른객체를 반환하는 경우는 해당 객체가 리턴된다.

생성자 함수에 new를 붙이지 않고 호출할 경우

  • 일반 함수 호출의 경우 this가 window 전역 객체에 바인딩된다.
  • 생성자 함수 호출의 경우 this는 새로 생성된 빈 객체에 바인딩된다.
    1
    2
    3
    4
    5
    6
    var person  = Person('qux', 20, 'man');
    console.log(person); // undefined

    console.log(window.name); // qux
    console.log(window.age); // 20
    console.log(window.gender); // man

call과 apply 메서드를 이용한 명시적인 this 바인딩

function.apply(thisArg, argArray)
  • apply() 메서드를 호출하는 주체가 함수고, apply() 메서드도 this를 특정 객체에 바인딩할 뿐 결국 본질적인 기능은 함수 호출이다.
  • thisArg는 apply() 메서드를 호출한 함수 내부에서 사용한 this에 바인딩할 객체를 가리킨다.
  • argArray 인자는 함수를 호출할 때 넘길 인자들의 배열을 가리킨다.

함수 리턴

  • 자바스크립트 함수는 항상 리턴값을 반환한다.
  • return문을 사용하지 않더라도 규칙이 존재한다.

규칙1) 일반 함수나 메서드는 리턴값을 지정하지 않을 경우, undefined 리턴한다.

1
2
3
4
5
6
7
8
const noReturnFunc = function() {
console.log('리턴값이 없다.');
}

const result = noReturnFunc();
console.log(result);
// 리턴값이 없다.
// undefined

규칙2) 생성자 함수에서 리턴값을 지정하지 않을 경우 생성된 객체가 리턴된다.

  • 리턴값이 지정되지 않는다면, this로 바인딩된 새로 생성된 객체가 리턴된다.
  • 생성자 함수에서는 일반적으로 리턴값을 지정하지 않는다.
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    function Person(name, age, gender) {
    this.name = name;
    this.age = age;
    this.gender = gender;

    // 명시적으로 다른 객체 반환
    return {name:'bar', age:20, gender:'woman'}
    }
    const foo = new Person('foo', 30, 'man');
    console.dir(foo);

퇴사를 했다.

퇴사 리마인드

[퇴사 한 이유?](#퇴사 한 이유?)
[나는 앞으로 무엇을 해야하는가?](#나는 앞으로 무엇을 해야하는가?)

퇴사 한 이유?

퇴사한 이유는 강제로 퇴사를 당했다. 쉽게 풀이하면 권고사직 당했다.
얼마전 부터 회사가 계속 구조조정을 통한 인원 감축을 하고 있었기에 우리 팀도 손을 볼 것이라는 어느정도 예상은 하고 있었다.
마침 포지션과 맡은 서비스가 중복된것이 많았기에 나한테 통보가 오지 않을까 싶기도 했다.
하지만, 막상 직접 얘기를 듣고나니 멍하기도 했고 섭섭한 마음이 더 컸다.
회사가 적자가 나고 상황이 좋지 않은것이 마치 직원들의 잘못처럼 얘기하는 것이 너무나도 마음이 아팠다. 그 동안 회사에서 어떠한 스토리들이 있었는지 알고있으면서 이런식으로 대하는 행태가 너무 보기 좋지 않았다.
그래도 1년 넘게 다닐 수 있었던 것은 회사 동료였다. 일을 하는데 있어서 너무 즐거웠고 다양하게 일도 해본것 같다.
같이 일을 할 수 있어서 즐거웠고, 옆에서 많은 것들을 배우고 얻었다.
언젠가는 다시 같이 일할 수 있는 날이 온다면 좋겠다.

나는 앞으로 무엇을 해야하는가?

크게 생각하면 3가지 정도로 압축할 수 있을 것 같다.
첫번째로는 물론 취업을 먼저 해야 맞는것 같다.
성격상 어디 소속 되어 있지 않으면 불안함도 크고 시간관리나 자기계발에 취약하다.
또한, 팀 안에서 동료들과의 협업을 통해서 배우는 것과 같이 일하는 것이 즐겁기 때문에 빠른 시일내에 취업을 해서 부딫혀 나가야 할 것이다.
두번째로는 공부를 더욱 열심히 하는 것이다.
공부는 그 동안 너무 라이브러리나 프레임워크에 종속되어서 개발 및 공부를 하지 않았나 싶다. 특히, 최근 들어 더 퓨어하게 자바스크립트를 공부해야 할 필요성을 느끼고 있다.
기술은 계속 변화하고 발전하고 새로운것들이 나오기 때문에 내가 주로 사용하는 기술들이 어떻게 될지는 예측이 불가능하다.
그렇기 때문에 자바스크립트라는 기본을 더 잘 다루어야 다른 새로운 라이브러리나 프레임워크가 생기더라도 이해하고 활용하는데 용이할 것이라고 생각한다.
세번째로는 글쓰기이다.
공부를 한 것은 정리가 필요한데 그게 바로 글쓰기다. 매번 글쓰기를 시도 해봤으나 잘 안되었다. 뭐든지 꾸준히 기록하고 정리하는 것이 중요하고 이 부분이 취약하다는 것은 나 스스로도 잘 알고 있다.
약점을 보완하기 위해서는 부족하지만 일단 해보고 피드백 받고 반복이 필요할 것 같다.
완벽한 글쓰기는 없다. 그냥 나 나름대로 쓰려고 노력 해봐야겠다.

한줄 요약

  • 권고 사직을 통해서 나를 돌아보는 계기

HTTP 완벽가이드 21장

21장 로깅과 사용 추적

로깅을 알아보고, 어떤 HTTP 트랜잭션 정보를 기록하고, 로그 포맷에는 어떤것들이 있는지 알아본다.

1. 로그란 무엇인가?

  • 대체적으로 로깅을 하는 이유?
    • 서버나 프락시의 문제를 찾기 위해서
    • 웹 사이트 접근 통계를 내기위해서
  • 별 연관성이 없고 다시 볼 일도 없는 데이터만 로깅한다.
  • 보통은 트랜잭션의 기본적인 항목들만 로깅한다.
    • HTTP 메서드
    • 클라이언트와 서버의 HTTP 버전
    • 요청받은 리소스의 URL
    • 응답의 HTTP 상태 코드
    • 요청과 응답 메시지의 크기
    • 트랜잭션이 일어난 시간
    • Referer와 User-Agent 헤더 값

2. 로그 포맷

  • 상용 혹은 오픈 소스 HTTP 애플리케이션은 대부분, 표준 로그 포맷을 한 개 이상 지원한다.
  • 애플리케이션이 더 많은 표준 포맷을 지원하고 관리자가 사용할 수록 얻을 수 있는 이점이 많다.

2.1 일반 로그 포맷(Common Log Format)

  • 가장 일반적인 포맷이며, 많은 서버들이 기본으로 사용한다.
필드 설명
remotehost 요청한 컴퓨터의 호스트 명 혹은 IP주소
username ident 검색을 수행했다면, 인증된 요청자의 사용자 이름
auth-username 인증을 수행했다면, 인증된 요청자의 이름
teimstamp 요청 날짜와 시간
request-line HTTP 요청의 행을 그대로 기술
response-code 응답으로 보내는 HTTP 상태 코드
response-size 응답 엔터티의 Content-Length, 아무런 엔터티를 반환하지 않으면 값이 0이 된다.

일반 로그 포맷 엔트리의 몇가지 예

209.1.32.44 - - [03/Feb/2020:14:15:00 -0400] "GET / HTTP/1.0" 200 1024
bebiangel.github.io - dg [03/Feb/2020:14:15:00 -0400] "GET / HTTP/1.0" 200 477
bebiangel.github.io - dg [03/Feb/2020:14:15:00 -0400] "GET /foo HTTP/1.0" 404 0
필드 엔트리1 엔트리2 엔트리3
remotehost 209.1.32.44 bebiangel.github.io bebiangel.github.io
username 없음 없음 없음
auth-username 없음 dg dg
teimstamp 03/Feb/2020:14:15:00 -0400 03/Feb/2020:14:15:00 -0400 03/Feb/2020:14:15:00 -0400
request-line GET / HTTP/1.0 GET / HTTP/1.0 GET /foo HTTP/1.0
response-code 200 200 404
response-size 1024 477 0

3. 적중 계량하기

  • 캐시는 수많은 HTTP요청을 처리하므로, 요청이 원 서버 까지 오지 않더라도 정상적으로 처리될 수 있어서, 클라이언트가 콘텐츠에 접근했다는 기록이 남지 않아 로그 파일에 누락이 발생하게 된다.
  • 캐시를 파기 시킨다면, 문제 없이 로깅을 하지만, 요청에 대한 응답속도가 느려지고 원서버와 네트워크의 부하가 가중되는 문제를 야기한다.
  • 적중 계량 규약은 HTTP의 확장으로, 캐시가 정기적으로 캐시 접근 통계를 원 서버에 보고하도록 한다.
  • 완벽하진 않지만, 서버가 원하는 통계 정보를 받아볼 수 있는 방법을 제공한다.

HTTP 완벽가이드 20장

20장 리다이렉션과 부하 균형

리다이렉션 기법들과 그것들이 어떻게 동작하며 어떤 부하 균형 능력을 갖고 있는지 알아본다

1. 왜 리다이렉트인가?

HTTP 애플리케이션이 원하는것

  • 신뢰할 수 있는 HTTP 트랜잭션의 수행
  • 지연 최소화
  • 네트워크 대역폭 절약

리다이렉션

  • 최적의분산된 콘텐츠를 찾는 것을 도와주는 기법의 집합

2. 리다이렉트 할 곳

  • 서버, 프락시, 캐시, 게이트웨이는 클라이언트에게 있어서 HTTP 요청을 보내고 그것을 처리하므로 서버라고 할 수 있다.
  • 서버로의 리다이렉트는 휘발유를 찾는 운전 기사를 가장 가까운 주유소로 보내는 것이다.
  • 프락시로의 리다이렉트는 진입로의 트래픽을 근처에 있는 지름길로 빨아들이는 것과 같다.

3. 리다이렉션 프로토콜의 개요

  • HTTP 메시지를 웹 서버로 가급적 빨리 보내는 것이 리다이렉션의 목표다.
  • HTTP 메시지는 HTTP 애플리케이션과 라우팅 장치에 영향을 받는다.
  • 메시지를 서버로 리다이렉트하기 위한 여러 방법들이 존재한다.

4. 일반적인 리다이렉션 방법

4.1 HTTP 리다이렉션

  • 요청을 처리하는 서버는 가용한 것들 중 부하가 가장 적은 콘텐츠 서버를 찾아서 브라우저의 요청을 그 서버로 리다이렉트 한다.
  • 리다이렉트를 하느 서버가 클라이언트의 아이피 주소를 아는 것은 좀 더 정보에 근거해 선택하므로 장점이다.

단점

  • 어떤 서버로 리다이렉트할지 경정하려면 원 서버는 상당히 많은 처리를 해야 한다.
  • 페이지에 접근할 때마다 두 번의 왕복이 필요하므로 사용자가 더 오래 기다리게 된다.
  • 리다이렉트 서버가 고장나면, 사이트도 고장난다.

4.2 DNS 리다이렉션

  • 클라이언트가 웹사이트에 접근하려고 시도할 때마다, 도메인 이름은 반드시 아이피 주소로 분석되어야 한다.
  • DNS는 하나의 도메인에 여러 아이피 주소가 결부되는 것을 허용한다.
  • DNS 분석자는 여러 아이피 주소를 반환하도록 결정하는 방법은 다양하다.
  • DNS 결정 알고리즘은 라운드 로빈이 가장 쉽다.

DNS 라운드 로빈

  • 웹 서버 팜 전체에 대한 부하의 균형을 유지하기 위해 DNS 호스트명 분석 기능을 사용한다.
  • DNS 클라이언트는 다중 주소 집합의 첫 번째 주소를 사용한다.
  • DNS 서버는 룩업이 끝났을 때마다 주소를 순환시킨다.

DNS 캐싱의 효과

  • DNS 룩업은 애플리케이션, 운영체제 등 DNS 서버에 의해 재사용 되어 비용을 줄이게 된다.
  • 클라이언트의 수가 어느정도 이상만 된다면, 부하는 모든 서버에 잘 분산된다.

4.3 임의 캐스팅 어드레싱

  • 여러개의 흩어진 웹 서버들은 정확히 같은 아이피 주소를 갖고 클라이언트의 요청을 클라이언트에서 가장 가까운 서버로 보내주기 위해 백본 라우터의 최단거리 라우팅 능력에 의지한다.
  • 백본 라우터가 임의 캐스트 주소를 목적지로 하는 패킷을 받았을때, 그 아이피 주소를 받아들일 수 잇는 가장 가까운 라우터를 찾는다.
  • 서버는 반드시 라우터의 언어로 말해야하고 라우터는 일어날 수 있 는 주소 충돌을 반드시 다룰수 있어야 한다.

4.4 아이피 맥 포워딩

  • HTTP 메시지는 주소가 붙은 데이터 패킷의 형태로 보내진다.
  • 각 패킷은 출발지와 목적지의 아이피 주소와 TCP 포트 번호로 이루어진 레이어4 주소를 갖는다.
  • 레이어2의 역할은 들어오는 특정 맥(MAC) 주소의 패킷을 받아서 나가는 특정 맥 주소로 포워딩한다.

4.5 아이피 주소 포워딩

  • 스위치나 레이어4를 이해하는 장비는 들어오는 패킷에 대해 TCP/IP 어드레싱을 검증하고 패킷을 목적지 맥 주소가 아니라 목적지 아이피 주소의 변경에 따라 라우팅한다.
  • 목적지 서버가 한 홉 거리에 있을 필요가 없다.
  • 스위치는 반드시 그 커넥션을 통해 클라이언트에게 응답을 돌려줘야 한다.

5. 프락시 리다이렉션 방법

5.1 명시적 브라우저 설정

  • 대부분의 브라우저에는 프락시 서버에 접촉하기 위한 프락시 이름, 아이피 주소, 포트번호를 설정하는 메뉴가 존재한다.
  • 사용자의 설정에 따라 모든 요청에 대해 프락시와 접촉한다.

단점

  • 만약 프락시가 다운되었거나 브라우저가 잘못 설정되었다면, 사용자는 접속 문제에 마주하게 된다.
  • 네트워크 아키텍처를 변경했을 때 그 변경사항을 모든 최종사용자에게 전파하는것이 어렵다.

5.2 프락시 자동 설정(Proxy Auto-configuration, PAC)

  • 브라우저가 동적으로 자신을 설정할 수 있게 하는 것이다.

  • PAC는 브라우저들이 URL별로 접촉해야 할 프락시를 지정한 PAC 파일이라 불리는 특별한 파일을 찾도록 하는것이다.

  • 브라우저는 반드시 PAC파일을 얻기 위해 지정된 서버에 접촉하도록 설정되어 있다.

  • 브라우저는 재시작 할 때마다 PAC 파일을 가져온다.

  • PAC 파일은 다음의 함수를 반드시 정의해야하는 자바스크립트 파일이다.

    function FindProxyForURL(url, host)

5.3 웹 프락시 자동발견 프로토콜(Web Proxy Autodiscovery Protocol)

  • 웹브라우저가 근처의 프락시를 찾아내어 사용할 수 있게 해주는 방법을 제공해 준다.

6. 캐시 리다이렉션 방법

  • 신뢰성이 높고, 고성능, 콘텐츠 지각 디스패칭이 가능하게 하여 복잡한 방법이다.

6.1 WCCP 리다이렉션

  • 캐시 조직 프로토콜(WCCP)는 라우터들과 캐시들 사이의 대화를 관리하여 라우터가 캐시를 검사하고, 특정 종류의 트래픽을 특정 캐시로 보낼 수 있게 해준다.
  • WCCP 서비스 그룹을 구성하고, 어떤 트래픽이 어디로 어떻게 보내지는지, 서비스 그룹에서 부하가 캐시들 사이에서 어떻게 분산되어야 하는지 명시한다.
  • HTTP 요청이 서비스 그룹의 라우터에 도착한다면, 라우터는 그 요청을 처리하기 위해 서비스 그룹의 캐시 중 하나를 선택한다.

7. 캐시 배열 라우팅 프로토콜

  • 부하를 분산하기 위해 사용하는 프락시 서버를 여러대로 늘리는 것이다.
  • CARP는 프락시 서버의 배열이 클라이언트의 시점에서는 마치 하나의 논리적인 캐시처럼 보이도록 관리해주는 표준이다.
  • 각 구성요소 서버가 전체 캐시된 문서의 일부만 갖고 있는 하나의 큰 서버처럼 동작한다.
  • 하나의 웹 객체는 하나의 프락시 서버에만 속하기 때문에, 프락시 서버 각각을 폴링하지 않고도 한 번의 검색으로 그 객체의 위치를 결정할 수 있다.

8. 하이퍼텍스트 캐싱 프로토콜

  • HTCP는 형제들이 URL과 모든 요청 및 응답 헤더를 사용하여 서로에게 문서의 존재 여부에 대한 질의를 할수 있도록 해줌으로써 적중이 아님에도 적중으로 잘못 처리될 확률을 줄인다.
  • 캐시들이 서로의 캐시 안에 있는 선택된 문서의 추가 및 삭제를 모니터링하고 요청할 수 있게 해준다.
  • 근처 캐시가 문서를 갖고 있다면, 요청 캐시는 그 캐시에 HTTP 커넥션은 열고 그 문서를 가져 온다.

HTTP 완벽가이드 19장

19장 배포 시스템

1. WebDav

  • 웹 분산 저작과 버저닝(Web Distributed Authoring and Versioning)
  • 공동 저작에 적합한 플랫폼을 제공하려고 HTTP를 확장하는데 집중한다.

2. WebDav와 공동저작

2.1 WebDav와 XML

  • WebDav의 메서드는 요청과 응답 관련 정보를 모두 잘 다루어야함
  • WebDav는 여러개의 리소스나 계층 관계에 있는 리소스들에 대해 정보를 선택적으로 헤더에 기술하기 위해서 XML포맷을 지원한다.

2.2 WebDav헤더

  • WebDav는 새로운 메서드들의 기능을 넓혀주는 여러 HTTP메서드를 도입했다
  • 모든 리소스는 OPTIONS 요청에 대한 응답에 이 헤더를 포함해야한다.
  • Depth는 계층 구조로 분류된 리소스 사용에 용이하다.
  • Destination은 COPY나 MOVE 메서드가 목적지 URI를 식별하는데 사용한다.

2.3 WebDav 잠금과 덮어쓰기 방지

  • WebDav는 잠금이라는 개념을 지원한다
  • 잠금은 완벽하지 않으므로 버저닝과 메시징을 지원해야한다
  • 잠금을 수행하기 위해서는 다이제스트 인증을 요구한다

2.4 속성과 META 데이터

  • 속성에는 저작자의 이름, 수정한 날자, 내용 등급 등 리소스의 정보를 기술한다.
  • 속성의 발견과 수정을 지원하기 위해, WebDav는 PROFIND와 PROPPATCH라는 새로운 메소드를 추가한다.

2.5 콜렉션과 이름공간 관리

  • 콜렉션은 리소들의 논리적 혹은 물리적 그룹이다.
  • 파일시스템의 디렉터리 같이 다른 리소스들의 컨테이너처럼 동작한다.
  • WebDav는 XML 이름 공간 메커니즘을 사용한다.
  • 이름공간 파티션들은 충돌이 생기지 않고 명확한 구조적 제어기능을 제공한다.

2.6 MKCOL 메서드

  • 클라이언트가 지정된 URL에 해당하는 콜렉션을 서버에 생성하게 한다.
  • WebDav 프로토콜은 새로운 메서드를 정의하는 방식을 사용한다.

2.7 DELETE 메서드

  • 디렉터리를 지우기 위해서는 Depth 헤더를 필요로한다.
  • Depth가 없다면, DELETE 메서드는 Depth 헤더가 무한으로 설정되어 있다고 가정한다.
  • 디렉터리와 그 하위에 있는 모든 디렉터리가 지워진다.

2.8 COPY와 MOVE 메서드

  • COPY 메서드는 리소스에 GET 요청을 보내고, 리소스를 다운 받은 다음, PUT 요청과 함께 서버에 리소스를 다시 올리는 것이다.
  • MOVE는 DELETE메소드를 포함한 COPY와 비슷하게 동작한다.
  • MOVE 메서드는 원본지 URL을 목적지에 복사하고, 새로 생성된 URI의 무결성을 검사하고, 원본을 지운다.

HTTP 완벽가이드 18장

18장 웹 호스팅

웹 호스팅의 가장 중요한 속성들과 그것들이 어떻게 HTTP 애플리케이션과 상호작용하는지 알아본다.

1. 호스팅 서비스

  • 전문적으로 서버실을 짓고 도메인을 등록하고 네트워크 대역폭을 구매하는 기술과 시간을 가진 업체들이 있다.
  • 물리적인 장비 관리에서 고객이 직접 콘텐츠를 제공할 수 있는 총체적인 웹 호스팅까지 다양한 종류의 서비스들이 있다.

2. 가상 호스팅

  • 웹 호스팅 업자는 컴퓨터 한 대를 여러 고객이 공유하게 해서 저렴한 웹 호스팅 서비스를 제공하는데, 이를 공유 호스팅 또는 가상 호스팅이라 부른다.
  • 가상 호스팅은 비용, 공간, 관리에 이점이 있다.
  • 호스팅 업자는 복제 서버 더미(서버 팜)를 만들고 서버 팜에 부하를 분산할 수 있다.
  • 수많은 가상 웹사이트를 호스팅 하므로 관리자는 훨씬 편해진다.

2.1 호스트 정보가 없는 가상 서버 요청

  • HTTP/1.0 명세는 공용 웹 서버가 호스팅하고 있는 가상 웹 사이트에 누가 접근하고 있는지 식별하는 기능을 제공하지 않는다.
  • 여러 개의 요청이 완전히 다른 문서를 요청을 하더라도, 요청 자체가 똑같이 생겼다.
  • HTTP 대리 서버(리버스 프락시)와 인터셉트 프락시는 어떤 사이트를 요청하는지에 관한 정보가 필요하다.

2.2 가상 호스팅 동작하게 하기

URL 경로를 통한 가상 호스팅

  • 서버가 어떤 사이트를 요청하는 것인지 알 수 있게 URL에 특별한 경로 컴포넌트를 추가한다.
    • 경로에 있는 정보를 통해 해당 URL을 분석한다.
    • GET joes/index.html
    • GET mary/index.html
  • 일반적으로, URL 기반의 가상 호스팅은 좋지 않은 방법이다.

포트 번호를 통한 가상 호스팅

  • 각 사이트에 다른 포트번호를 할당하여, 분리된 웹 서버의 인스턴스 요청 처리를 한다.
  • 사용자는 URL에 비표준 포트를 쓰지 않고서도 리소스를 찾길 원하는 문제가 생긴다.

IP 주소를 통한 가상 호스팅

  • 각 가상 웹 사이트에 유일한 IP 주소를 한 개 이상 부여한다.

  • 모든 가상 서버의 IP 주소는 같은 공용 서버에 연결되어 있다.

    문제점들

    • 컴퓨터 시스템이 연결할 수 있는 장비의 IP의 개수에 제한이 있다.
    • 가상 사이트를 많이 가지고 있는 호스팅 업자는 호스팅 하는 모든 웹 사이트에 할당할 가상 IP 주소를 충분히 얻지 못할 수 있다.
    • 부하 균형의 구조상, 용량을 늘리기 위해 서버를 복제하면서, 각 복제된 서버에 IP 주소를 부여해야 하므로 IP 주소는 복제 서버의 개수만큼 더 필요하게 된다.

Host 헤더를 통한 가상 호스팅

  • 모든 요청에 호스트명을 Host 확장 헤더에 기술해서 전달한다.

2.3 HTTP/1.1 Host 헤더

  • 가상 서버는 매우 흔하기 때문에 대부분의 HTTP 클라이언트가 HTTP/1.1과 호환되지 않더라도, Host헤더는 구현한다.
  • Host = "Host" ":" 호스트[ ":" 포트 ]

3. 안정적인 웹 사이트 만들기

3.1 미러링 된 서버 팜

  • 서버 팜은 서로 대신할 수 있고 식별할 수 있게 설정된 웹 서버들의 집합이다.
  • 서버팜의 서버에 있는 콘텐츠들은 한 곳에 문제가 생기면 다른 한 곳에서 대신 전달할 수 있게 미러링 할 수 있다.

HTTP 리다이렉션

  • 콘텐츠에 대한 URL은 마스터 서버의 IP를 가리키고, 마스터 서버는 요청을 받는 즉시 복제 서버로 리다이렉트시킨다.

DNS 리다이렉션

  • 콘텐츠의 URL은 여러 개의 IP 주소를 가리킬 수 있고, DNS 서버는 클라이언트에게 전송할 IP 주소를 선택할 수 있다.

3.2 콘텐츠 분산 네트워크

  • 콘텐츠 분산 네트워크(CDN)는 특정 콘텐츠의 분산을 목적으로 하는 단순한 네트워크이다.

3.3 CDN의 대리 캐시

  • 대리 서버는 콘텐츠에 대한 요청을 받는다.
  • 원 서버 집합을 대신해 요청을 받는다.

미러링 된 서버와의 차이점

  • 수요에 따라서 동작한다.
  • 원 서버의 전체 콘텐츠를 복사하지 않는다.
  • 클라이언트가 요청하는 콘텐츠만 저장한다.

3.4 CDN의 프락시 캐시

  • 대리 서버를 사용하면, 프락시 캐시의 콘텐츠는 요청이 있을 때만 저장되고 원본 서버 콘텐츠를 정확히 복제한다는 보장이 없다.
  • 요청이 있을 때만 저장하는 프락시 캐시는 스위치 혹은 라우터가 중간에서 웹 트래픽을 가로채 처리한다.

4. 웹 사이트 빠르게 만들기

  • 콘텐츠를 분산시키면, 그 콘텐츠를 사용자에게 더 가깝게 만들어 주므로 콘텐츠를 서버에서 클라이언트로 전송하는 시간이 단축된다.
  • 콘텐츠를 인코딩하는것

5. WebDav

  • 웹 분산 저작과 버저닝(Web Distributed Authoring and Versioning)
  • 공동 저작에 적합한 플랫폼을 제공하려고 HTTP를 확장하는데 집중한다.

HTTP 완벽가이드 17장

17장 내용 협상과 트랜스 코딩

1. 내용 협상 기법

  • 서버에 있는 페이지들 중 어떤 것이 클라이언트에게 맞는지 판단하는 세 가지 다른 방법이 있다.
  • 클라이언트 주도 협상, 서버 주도 협상, 투명한 협상에 대해서 알아본다.

2. 클라이언트 주도 협상

  • 서버에게 가장 쉬운 방법은 서버가 클라이언트의 요청을 받았을 때 가능한 페이지의 목록을 응답을 돌려주어 클라이언트가 보고 싶은 것을 선택하게 하는 것이다.

    단점

    • 각 페이지에 두 번의 요청이 필요하다.(목록 & 사본)
    • 느리고 지루하다.
  • 서버는 클라이언트에게 여러가지 버전에 대한 링크와 설명이 담긴 HTML 페이지를 돌려준다.

  • 300Multiple Choices 응답 코드로 HTTP/1.1응답을 돌려준다.

    단점

    • 대기시간이 증가되고, 페이지당 여러 번의 요청이 필요하다.

3. 서버 주도 협상

  • 클라이언트가 서버가 결정을 하도록 요청 헤더에 정보를 삽입한다.
    • 내용 협상 헤더 → 서버는 클라이언트의 Accept 관련 헤더들을 보고 그에 알맞은 응답을 돌려 준다.
    • 이외의 다른 헤더 → ex) 서버는 클라이언트의 User-Agent헤더에 기반하여 응답을 돌려준다.

3.1 내용 협상 헤더

  • HTTP 헤더들을 이용해서 자신의 선호 정보를 보낸다.
    • Accept: 서버가 어떤 미디어 타입으로 보내도 되는지 알려준다.
    • Accept-Language: 서버가 어떤 언어로 보내도 되는지 알려준다.
    • Accept-Charset: 서버가 어떤 차셋으로 보내도 되는지 알려준다.
    • Accept-Encoding: 서버가 어떤 인코딩으로 보내도 되는지 알려준다.
  • HTTP는 상태가 없는 프로토콜이기 때문에 클라이언트는 자신의 선호 정보를 매 요청마다 보내야한다.

3.2 내용 협상 헤더의 품질값

  • HTTP 프로토콜은 클라이언트가 각 선호의 카테고리마다 여러 선택 가능한 항목을 선호도와 함께 나열할 수 있도록 품질값을 정의하였다.
  • q값은 0.0부터 1.0까지의 값을 가진다.(커질수록 높은 선호도)

3.3 그 외의 헤더들에 의해 결정

  • 서버는 User-Agent와 같은 헤더들을 이용해 알맞은 요청을 만들어내려고 시도할 수 있다.
  • 서버가 웹브라우저에서 자바스크립트를 지원하지 않는다는 것을 알고 있다면, 자바스크립트를 포함하지 않은 페이지를 돌려줄 수 있다.

4. 투명협상

  • 클라이언트 입장에서 협상하는 중개자 프락시를 둔다.
  • 메시지 교환을 최소화 하며 서버 주도 협상으로 인한 부하를 서버에서 제거한다.

4.1 캐시와 얼터네이트(alternate)

  • 캐시는 클라이언트에게 올바르게 응답을 돌려주기 위해, 서버가 응답을 돌려줄 때 사용했던 로직을 상당부분 사용한다.
  • 캐시는 반드시 모든 요청을 서버에게 전달하고 모든 응답을 저장해야 한다.
  • 캐시는 같은 URL에 대해 두 개의 다른 문서를 갖게 된다.
  • 이 다른 번전은 배리언트(variant)나 얼터네이트(alternate)라고 불린다.

4.2 Vary 헤더

  • HTTP Vary 응답 헤더는 클라이언트 요청 헤더 모두를 나열한다.
  • 캐시가 문서를 클라이언트에게 제공해 주기 전에, 캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 있는지 확인한다.
  • Vary 헤더가 존재한다면, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래되고 캐시된 요청의 값이 맞아야 한다.

5. 트랜스코딩

  • 서버가 클라이언트의 요구에 맞는 문서를 가지고 있지 않다면, 서버는 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환 할 수 있다. 이 옵션을 트랜스코딩이라 한다.

5.1 포맷 변환

  • 데이터를 클라이언트가 볼 수 있도록 한 포맷에서 다른 포맷으로 변환하는 것이다.
  • 포맷 변환은 내용 협상 헤더에 의해 주도된다.
  • 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하는 것이다.

5.2 정보 합성(information synthesis)

  • 각 절의 제목에 기반한 문서의 개요 생성이나 페이지에서 광고 및 로고 제거와 같은 예가 있다.
  • 웹페이지 디렉토리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.

5.3 콘텐츠 주입

  • 자동 광고 생성, 사용자 추적 시스템과 같은 예가 있다.
  • 특정 사용자를 대상으로 자동으로 광고를 삽입한다.
  • 어떻게 페이지가 보여지고 사용자가 웹을 서핑하는 거에 따라 동적으로 콘텐츠를 삽입한다.

5.4 트랜스코딩 vs 정적으로 미리 생성

  • 트랜스코딩의 대안으로는 웹 서버에서 웹페이지의 여러 사본을 만드는 것이다.
    • 페이지의 작은 변화에 따라 페이지의 수정이 필요하다.
    • 모든 버전을 저장하기 위해 더 많은 공간이 필요하다.
    • 페이지를 관리하고 올바른 페이지를 노출 시키도록 웹 서버를 프로그래밍하기 어려워진다.
  • 광고 삽입과 같은 트랜스코딩은 요청한 사용자에게 달려있기 때문에 정적인 방법으로는 수행될 수 없다.
  • 루트 페이지를 필요할 때마다 변환하는 것이 좋다.

HTTP 완벽가이드 16장

16장 국제화

주요 국제화 이슈인 문자집합 인코딩과 언어 태그를 알아본다.

1. 국제적인 콘텐츠을 다루기 위해 필요한 HTTP 지원

  • HTTP에서 엔터티 본문이란 비트들로 가득 찬 상자에 불과하다.
  • 국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 각 문서의 문자와 언어를 알려줘서, 클라이언트가 문서를 이루고 있는 비트들을 올바르게 문자들로 풀어내고, 처리해서 사용자들에게 제공한다.
  • 서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개변수와 Content-Language 헤더를 통해 알려준다.
  • 클라이언트는 서버에게 자신이 어떤 차셋 인코딩 알고리즘들과 언어들을 이해하며 무엇을 선호하는지 말해주기 위해 Accept-Charset과 Accept-Language 헤더를 보낸다.

2. 문자집합과 HTTP

2.1 Charset은 글자를 비트로 변환하는 인코딩이다

  • HTTP Charset 값은 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다.
  • Content-Type: text/html; charset=iso-8859-6
    • Content-Type 헤더는 수신자에게 콘텐츠가 HTML 파일임을 말해준다.
    • charset 매개변수는 수신자에게 콘텐츠 비트들을 글자들로 디코딩하기 위해 iso-8859-6 아랍 문자집합 디코딩 기법을 사용하라고 말해준다.

3. 언어 태그와 HTTP

  • 언어 태그는 언어에 이름을 붙이기 위한 짧고 표준화된 문자열이다.

3.1 Content-Language 헤더

  • 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다.
  • 텍스트 문서 이외의 오디오 클립, 동영상, 애플리케이션도 특정 언어 사용자를 대상으로 할 수 있다.
  • 콘텐츠가 여러 언어를 대상으로 한다면, 언어들을 나열할 수 있다.
    • Content-Language: mi, en

3.2 Accept-Language 헤더

  • 웹 서버가 자원에 대해 여러 언어로 된 버전을 갖고 있다면, 사용자에게 선호하는 언어로 된 컨텐츠를 제공한다.
  • 클라이언트는 자신이 이해 할 수 있는 콘텐츠를 요청하기 위해 Accept-Language와 Accept-Charset을 사용한다.

3.3 대소문자 구분 및 표현

  • 모든 태그는 대소문자가 구분되지 않는다.
  • 관용적으로 언어를 나타날때 소문자, 국가를 나타낼 때는 대문자를 사용한다.

4. 국제화된 URI

  • 오늘날 URI는 국제화를 지원하지 않는다.
  • 오늘날의 URI는 US-ASCII의 부분집합으로 구성되어 있다.

4.1 국제적 가독성 vs 의미 있는 문자들

  • 문자집합에는 제한이 있기 때문에, URI는 비영어권 사람들도 쉽게 사용하고 기억할 수 있도록 설계되지는 못했다.
  • URI 저자들은 리소스 식별자의 가독성과 고유 가능성의 보장이 중요하다고 여겼다.
  • ASCII 문자들의 제한된 집합으로 이루어진 URI를 갖게 되었다.

4.2 URI에서 사용될 수 있는 문자들

  • US-ASCII 문자들의 부분집합은 예약된 문자들, 예약되지 않은 문자들, 이스케이프 문자들로 나뉜다.
  • 예약되지 않음: [A-Za-z0-9] |”-“|”_”|”.”|”!”|”~”|”*”|”‘“|”(“|”)”
  • 예약됨: “;”|”/“|”?”|”:”|”@”|”&”|”=”|”+”|”$”|”,”
  • 이스케이프: “%”

4.3 이스케이핑과 역이스케이핑(unescaping)

  • 이스케이프는 예약된 문자난 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법을 제공한다.
  • 이스케이프는 퍼센트 글자 하나와 뒤이은 16진수 그자 둘로 이루어진 세 글자 문자열이다.
  • 애플리케이션은 어떤 URI도 두 번 언이스케이핑 되지 않도록 해야 한다.
    • 이스케이핑된 퍼센트 기호를 포함한 URI를 언이스케이핑하면 퍼센트 기호가 포함된 URI가 만들어진다.
    • 잘못하여 한 번 더 언이스케이핑을 하게 되면 이스케이프의 일부처럼 처리되어 데이터의 손실을 유발한다.

5. 기타 고려사항

5.1 헤더와 명세에 맞이 않는 데이터

  • HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다.
  • HTTP 애플리케이션은 글자들을 처리하기 위해 운영체제와 리아브러리 루틴을 사용한다.

5.2 날짜

  • HTTP 명세는 올바른 GMT 날짜를 명확히 정의하지만, 모든 웹 서버와 클라이언트가 규칙을 따르지 않는다.
  • 명세에 맞지 않는 날짜를 관대하게 받아들이고, 받아들이면서 충돌을 일으키지 말아야한다.

5.3 도메인 이름

  • 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름(Internationalizing Domain Name)이라 한다.
  • 웹브라우저는 퓨니코드를 사용해 사용자가 입력한 다국어로 된 도메인 이름을 알파벳과 숫자 등으로 된 도메인 이름으로 변환한다.

HTTP 완벽가이드 15장

15장 엔터티와 인코딩

목표: 엔터티 및 그와 연관된 엔터티 헤더들이 콘텐츠를 나르기 위해 하는 일들을 알아본다.

1. 메시지는 컨테이너🗄, 엔터티는 화물📦

  • HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면,

  • HTTP 엔터티는 메시지의 실질적인 화물이다.

  • 엔터티 헤더는 18자(Content-Length:18)의 플레인 텍스트 문서를 의미한다.

**`메시지 엔터티는 엔터티 헤더와 엔터티 본문으로 이루어진다!`**

엔터티 본문

  • 가공되지 않은 데이터만을 담고 있다.
  • 헤더 필드의 끝을 의미하는 빈 CRLF 줄 바로 다음부터 시작한다.

2. Content-Length: 엔터티의 길이

  • 메시지의 엔터티 본문의 크기를 바이트 단위로 나타낸다.
  • 엔터티 본문을 포함한 메시지에서는 필수적으로 존재해야 한다.
  • 서버 충돌로 인해 메시지가 잘렸는지 감지하고자 할 때와 지속 커넥션을 공유하는 메시지를 올바르게 분할하고자 할 때 필요하다.

2.1 잘림 검출

  • Content-Length가 없다면 클라이언트는 커넥션이 정상적으로 닫힌 것인지 메시지 전송 중에 서버에 충돌이 발생한 것인지 구분하지 못한다.
  • 메시지 잘림을 검출하기 위해 Content-Length가 필요하다.

2.2 Content-Length와 지속 커넥션(Persistent Connection)

  • Content-Length는 지속 커넥션을 위해 필수이다.
  • 응답이 지속 커넥션을 통해서 온 것이라면, 또 다른 HTTP 응답이 즉시 그 뒤를 이어서 온다.
  • HTTP 애플리케이션은 Content-Length 헤더 없이는 어디까지가 본문이고 다음 메시지인지 알지 못한다.

2.3 콘텐츠 인코딩

  • HTTP는 보안을 강화하거나 압축을 통해 공간을 절약하도록, 엔터티 본문을 인코딩할 수 있게 해준다.
  • 본문의 콘텐츠가 인코딩되어 있다면, Content-Length 헤더는 인코딩된 본문의 길이를 바이트 단위로 정의한다.

3. 엔터티 요약

  • HTTP는 불완전한 트랜스코딩 프락시나 버그 많은 중개자 프락시를 비롯한 여러가지 이유로 메시지의 일부분이 전송 중에 변형되는 이리 나타난다.
  • 엔터티 본문 데이터에 대한 의도하지 않은 변경을 감지하기 위해, 최초 엔터티가 생성될 때 송신자는 데이터에 대한 체크섬을 생서할 수 있고, 수신자는 모든 의도하지 않은 엔터티의 변경을 잡아내기 위해 체크섬으로 기본적인 검사를 할 수 있다.
  • Content-MD5 헤더는 서버가 엔터티 본문에 MD5 알고리즘을 적용한 결과를 보내기 위해 사용된다.

4. 미디어 타입과 차셋(Charset)

  • Content-Type 헤더 필드는 엔터티 본문의 MIME 타입을 기술한다.

    MIME?

    • 전달되는 테이터 매체의 기저형식의 표준화된 이름이다.
    • ex) HTML파일, 워드 문서, MPEG 비디오 등
  • 주 미디어타입 / 부 타입 으로 구성된다.

  • text/html, text/plain, image/gif, image/jpeg

4.1 텍스트 매체를 위한 문자 인코딩

  • 엔터티 비트 집합을 텍스트 파일의 글자들로 변환하기 위한 charset 매개변수가 대표적인 예이다.
  • Content-Type: text/html; charset=iso-8859-4

4.2 멀티파트 폼 제출

  • HTTP 폼을 채워서 제출하면, 가변 길이 텍스트 필드업로드 될 객체는 각각 멀티파트 본문을 구성하는 하나의 파트가 되어 보내진다.
  • Content-Type: multipart/form-data; boundary=[abcdefghijklmnopqrstuvwxyz]

5. 콘텐츠 인코딩

  • HTTP 애플리케이션은 때때로 콘텐츠를 보내기 전에 인코딩을 한다.

5.1 콘텐츠 인코딩 과정

  1. 웹 서버가 원본 Content-TypeContent-Length 헤더를 수반한 원본 응답 메시지를 생성한다.
  2. 콘텐츠 인코딩 서버가 인코딩된 메시지를 생성한다. 콘텐츠 인코딩 서버는 Content-Encoding헤더를 인코딩된 메시지에 추가하여, 수신 측 애플리케이션이 그것을 디코딩할 수 있도록 한다.
  3. 수신 측 애플리케이션은 인코딩된 메시지를 받아서 디코딩하고 원본을 얻는다.

5.2 콘텐츠 인코딩 유형

  • 인코딩은 각 콘텐츠 인코딩 알고리즘에 고유한 토큰을 할당하는 IANA를 통해 표준화된다.
    • gzip → 가장 효율적이고 널리 쓰이는 압축 알고리즘
    • compress
    • deflate
    • identity

5.3 Accept-Encoding 헤더

  • 클라이언트는 자신이 지원하는 인코딩의 목록을 Accept-Encoding 요청 헤더를 통해 전달한다.

    예)..

    Accept-Encoding: compress, gzip
    Accept-Encoding:
    Accept-Encoding: *
    Accept-Encoding: compress;q=0.5, gzip;q=1.0
    Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
  • 클라이언트는 각 인코딩에 Q(quality)값을 매개변수로 더해 선호도를 나타낸다.

6. 전송 인코딩과 청크 인코딩

  • 콘텐츠 인코딩은 콘텐츠 포맷과 긴밀하게 연관되어 있다.
  • 전송 인코딩 또한 본문에 적용되는 가역적 변환이지만, 구조적인 이유 때문에 적용되는 것이며 콘텐츠의 포맷과는 독립적이다.

콘텐츠 인코딩 & 전송 인코딩

  • 콘텐츠 인코딩된 메시지는 단지 메시지의 엔터티 부분만 인코딩한다.

6.1 청크 인코딩

  • 청크 인코딩은 메시지를 일정 크기의 청크 여럿으로 쪼갠다.
  • 청크 인코딩을 이용하면 메시지를 보내기 전에 전체 크기를 알 필요가 없다.
  • 청크 인코딩이 전송 인코딩의 한 형태이며 따라서 본문이 아닌 메시지의 속성이다.

청크 인코딩된 메시지의 구조

6.2 전송 인코딩 규칙

  1. 전송 인코딩의 집합은 반드시 chunked를 포함해야 한다.
  2. 청크 전송 인코딩이 사용되었다면, 메시지 본문에 적용된 마지막 전송 인코딩이 존재해야 한다.
  3. 청크 전송 인코딩은 반드시 메시지 본문에 한 번 이상 적용되어야 한다.

7. 검사기와 신선도

  • 클라이언트는 처음에 리소스를 서버에게 달라고 요청보낸다.
  • 클라이언트는 사본 리소스를 받아서 캐시한다.
  • 클라이언트는 반드시 서버에게 최신 사본을 요청한다.
  • 서버에서 문서가 변경되지 않았다면 클라이언트는 다시 받을 필요가 없다.

조건부 요청

  • 클라이언트가 서버에게 자신이 갖고 잇는 버전을 말해주고 검사기를 사용해 자신의 사본 버전이 더 이상 유효하지 않을 때만 사본을 보내달라고 요청하는 것이다.

8. 범위 요청

  • HTTP 클라이언트는 받다가 실패한 엔터티를 일부 혹은 범위로 요청함으로써 다운로드를 중단된 시점에서 재개할 수 있다.

HTTP 완벽가이드 14장

14장 보안 HTTP

목표: HTTP 트랜잭션을 안전하게 보호하는 더 복잡한 기술들을 알아본다.

1. HTTP를 안전하게 만들기

  • 사용자들이 온라인 쇼핑이나 인터넷뱅킹을 안심하고 사용하기 위해서는 강력한 보안이 필요하다.
  • HTTP의 보안 버전은 효율적이고, 이식성이 좋으며, 관리가 쉽고, 현실 세계의 변화에 대한 적응력이 좋아야 한다.

1.1 HTTPS

  • 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 된다.
  • HTTP의 하부의 보안 계층에서 안전 소켓 계층(Secure Sockets Lyaer, SSL) 또는 전송 계층 보안(Transport Layer Security, TLS)에서 동작한다.
  • 어려운 인코딩 및 디코딩 작업은 SSL 라이브러리 안에서 동작하므로 클라이언트와 서버가 크게 변경할 필요는 없다.

2. 디지털 암호학

2.1 암호학 용어들

  • 암호: 테스트를 아무나
  • : 암호의 동작을 변경하는 숫자로 된 매개변수
  • 대칭키 암호 체계: 인코딩과 디코딩에 같은 키를 사용하는 알고리즘
  • 비대칭키 암호 체계: 인코딩과 디코딩에 다른 키를 사용하는 알고리즘
  • 공개키 암호법: 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
  • 디지털 서명: 메시지가 위조 혹은 변조되지 않았음을 인증하는 체크섬
  • 디지털 인증서: 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보

2.2 암호(cipher)

  • 암호란 메시지를 인코딩하는 어떤 특정한 방법과 그 비밀 메시지를 디코딩하는 방법이다.
  • 암호가 적용되어 있는 메시지를 텍스트 혹은 평문이라고 한다.
  • 암호는 상대적으로 간단한 알고리즘으로 시작해 기술의 진보에 따라 복잡한 암호를 빠르고 정확하게 인코딩&디코딩 하는 기계를 만들었다.

2.3 키가 있는 암호

  • 디코딩 과정을 바르게 동작시키려면 올바른 키를 암호 기계에 입력할 필요가 있다.
  • 암호키는 하나의 암호 기계를 여러 가상 암호 기계의 집합처럼 만든다.
  • 서로 다른 키 값을 가지고 있으므로 제각기 다르게 동작한다.

2.4 디지털 암호

  • 속도 및 기능에 대한 기계 장치의 한계에서 벗어나, 복잡한 인코딩과 디코딩 알고리즘이 가능하다.
  • 단일 암호 알고리즘으로 키의 값마다 다른 수조 개의 가상 암호 알고리즘을 만들어낼 수 있다.

3. 대칭키 암호법

  • 디지털 알고리즘은 인코딩 할 때와 디코딩 할 때 똑같은 키를 사용하므로 대칭키 암호라 불린다.
  • 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유 할 필요가 있다.
  • 발송자는 메시지를 암호화 하고 그 결과인 암호문을 수신자에게 발송하기 위해 비밀키를 사용한다.
  • 수신자는 암호문을 받은 뒤 공유키를 사용하여 원래대로 복원하기 위해 해독 함수를 적용한다.

4. 공개키 암호법

  • 두 개의 비대칭 키로 하나는 인코딩시에 다른 하나는 디코딩시에 사용한다.
  • 호스트만이 개인 디코딩 키를 알고 있다.

4.1 RSA

  • 공개키

  • 가로채서 얻은 암호문의 일부(네트워크 스누핑해서 획득)

  • 메시지와 그것을 암호화한 암호문

    → 공개키 비대칭 암호는 위 항목들을 알아도 계산할 수 없다는 것을 확신시켜 줘야한다.

  • 그 중 RSA는 공개키 암호 체계중 유명하며, 가장 상용화된 알고리즘이다.

4.2 혼성 암호 체계와 세션 키

  • 공개키 암호 방식의 알고리즘은 계산이 느린 경향이 있다.
  • 실제로는 대칭과 비대칭 방식을 섞은 것이 쓰인다.

5. 디지털 서명

  • 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 한다.
  • 보안 인증서에 중요하다.

5.1 서명은 암호 체크섬

  • 서명은 메시지를 작성한 저자가 누군지 알려준다.
  • 서명은 메시지 위조를 방지한다.
  • 디지털 서명은 보통 비대칭 공개키에 의해 생성된다.
  • 저자의 개인키는 지문처럼 사용된다.

6. 디지털 인증서

신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담는다.

6.1 인증서의 내부

  • 대상의 이름, 유효기간, 인증서 발급자, 디지털 서명과 같이 기본적인 것들을 담고 있다.
  • 누구나 디지털 인증서를 만들 수 있지만, 인증서의 정보를 보증하고 인증서를 개인 키로 서명할 수 있는 널리 인정받는 서명 권한을 얻을 수 있는 것은 아니다.
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×