11
HTTP Network Basic 2017.01.24( 화 ) 화화화 Study

Network 기본 4

  • Upload
    nim-bae

  • View
    79

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Network 기본   4

불타는Study

Page 2: Network 기본   4

01 HTTP 와 연계하는 웹 서버

02 HTTPS

Page 3: Network 기본   4

01HTTP 와 연계하는 웹 서버

-1 대로 멀티 도메인을 가능하게 하는 가상 호스트- HTTP 1.1 에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있음 .- 이를 위해 가상 호스트 (Virtual Host) 라는 기능을 사용 .( 가상 호스트 기능을 사용하면 , 물리적으로 HTTP 서버는 1 대지만 가상으로 여러대가 있는 것처럼 설정이 가능 .)

Serverhttp://www.tt.com/ http://

www.tt2.com/

같은 서버 상에 같은 IP 주소의 웹 서버에서 www.tt.com와 www.tt2.com이 실행되고 있을 때 , DNS(Domain Name System) 로 이름을 해결하면 , 그 어느 쪽도 같은 수신인이 되어버린다 .왜 ? 도메인은 IP 주소로 변환이 되기 때문이다 .

Page 4: Network 기본   4

01HTTP 와 연계하는 웹 서버

-통신을 중계하는 프로그램 : 프록시 , 게이트웨이 , 터널- HTTP 는 클라이언트와 서버 이외에 프록시 (Proxy), 게이트웨이 (Gateway), 터널 (Tunnel) 와 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능함 .

1. 프록시 (Proxy)- 서버와 클라이언트 양쪽 역할을 중계 하는 프로그램 , 클라이언트로부터의 Request 를 서버에 전송하고 , 서버로부터의 Re-sponse 를 클라이언트에 전송한다 .

- 프록시 서버의 기본적인 동작은 클라이언트로 받은 Request 를 다른 서버에 전송하는 것 .- 클라이언트로 받은 Request URI 를 변경하지 않고 그 다음의 리소스를 가지고 있는 서버에 보냄 .- 리소스 본체를 가진 서버를 오리진 서버라고 부름 .- 프록시 서버를 여러 대 경유하는 것도 가능 .- 중계할 때에는 Via 헤더 필드에 경유한 호스트 정보를 추가 .

client

proxyserver

client

HTTP request

HTTP response

HTTP request HTTP request

origin server

origin server

HTTP response HTTP response

Page 5: Network 기본   4

01HTTP 와 연계하는 웹 서버

-통신을 중계하는 프로그램 : 프록시 , 게이트웨이 , 터널- HTTP 는 클라이언트와 서버 이외에 프록시 (Proxy), 게이트웨이 (Gateway), 터널 (Tunnel) 와 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능함 .

2. 게이트웨이 (Gateway)-다른 서버를 중계하는 서버로 , 클라이언트로부터 수신한 Request 를 리소스를 보유한 서버인 것처럼 수신 .경우에 따라서는 클라이언트는 상대가 게이트웨이라는 것을 알지 못하는 경우도 있음 .

- 게이트웨이의 동작은 프록시와 매우 유사하지만 , 게이트웨이의 경우에는 그 다음에 있는 서버가 HTTP 서버 이외의 서비스를 제공하는 서버가 된다 .( 좀 더 쉽게 이해하자면 , 게이트웨이가 관문이자 서로 다른 프로토콜을 쓰는 네트워크들의 원할한 소통을 위한 변환기 역할을 한다고 생각하면 된다 .)

Page 6: Network 기본   4

01HTTP 와 연계하는 웹 서버

-통신을 중계하는 프로그램 : 프록시 , 게이트웨이 , 터널- HTTP 는 클라이언트와 서버 이외에 프록시 (Proxy), 게이트웨이 (Gateway), 터널 (Tunnel) 와 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능함 .

3. 터널 (Tunnel)- 서로 떨어진 두 대의 클라이언트와 서버 사이를 중계하며 접속을 주선하는 중계 프로그램 .

- 터널은 요구에 따라서 다른 서버와의 통신 경로를 확립 .- SSL 같은 암호화 통신을 통해 서버와 안전하게 통신을 하기 위해 사용 . - 터널 자체는 HTTP Request 를 해석하려고 하지 않으며 , 결국 Request 를 그대로 다음 서버에 중계 .- 터널은 통신하고 있는 양쪽 끝의 접속이 끊어질 때에 종료 .

Page 7: Network 기본   4

01HTTP 와 연계하는 웹 서버

-캐시 (Cache)- 캐시는 프록시 서버와 클라이언트의 로컬 디스크에 보관된 리소스의 사본을 가리킴 .- 캐시를 사용하면 , 리소스를 가진 서버에의 액세스를 줄이는 것이 가능하기 때문에 통신량과 통신 시간을 절약 .- 캐시 서버는 프록시 서버의 하나로 캐싱 프록시로 분류 .- 캐시는 유효기간이 존재하며 , 클라이언트의 요구나 캐시의 유효기간 등에 의해서 오리진 서버에 리소스의 유효성을 확인 또는 다시 획득하러 감 .- 클라이언트 측에도 캐시가 존재하며 , 클라이언트가 사용하는 브라우저에서 캐시를 가지며 , 인터넷 임시 파일이라고 부른다 . 브라우저가 유효한 캐시를 가지고 있는 경우 , 같은 리소스의 액세스는 서버에 엑세스 하지 않고 로컬 디스크로 부터 불러온다 .(이것도 유효기간이 존재하며 , 유효성 확인 및 새로운 리소스를 다시 획득하러 오리진 서버에 확인하러 간다 .)

• cache acts as both client and server– server for original requesting client– client to origin server

• typically cache is installed by ISP (university, com-pany, residential ISP)

캐쉬는 서버와 클라이언트 둘다 동작 .일반적으로 , 캐시는 ISP 에 의해 설치됨 .

why Web caching?• reduce response time for client request• reduce traffic on an institution’s access link• Internet dense with caches: enables “poor” content

providers to effectively deliver content (so too does P2P file sharing)

줄입니다 . 클라이언트 Request 에 대한 응답시간을 .트랙픽 저하 .컨텐츠 제공업체가 효과적으로 컨텐츠를 제공하도록 해줌 .

Page 8: Network 기본   4

02HTTPS

HTTP 의 약점 .-평문 ( 암호화 되지 않은 ) 통신이기 때문에 도청 가능 .-통신 상대를 확인하지 않기 때문에 위장 가능 .-완전성을 증명할 수 없기 때문에 변조 가능 .

위와 같은 문제는 다른 암호화하지 않은 프로토콜에도 공통되는 문제 .패킷 캡처인 Wireshark 라는 툴을 사용해서 HTTP 를 사용한 Request 와 Response 의 내용을 취득하면 해석이 가능 .

Page 9: Network 기본   4

02HTTPS

HTTP 의 약점 .-평문 ( 암호화 되지 않은 ) 통신이기 때문에 도청 가능 . -> HTTP 는 자신을 암호화 하는 기능이 없기 때문에 통신 전체가 암호화 되지 않음 .-통신 상대를 확인하지 않기 때문에 위장 가능 . -> HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리가 없음 .( 누구라도 요청오면 콜 )-완전성을 증명할 수 없기 때문에 변조 가능 . -> 정보의 정확한지 아닌지를 확인할 수 없음 .

암호화를 통해 , 도청 회피 = SSL(Secure Socket Layer), TLS(Transport Layer Security)상대를 확인하는 증명서로 , 위장 회피 = SSL 에서 상대를 확인하는 수단으로 증명서를 제공 .MD5, SHA-1 등의 해시 값 확인을 통해 , 변조 회피 = HTTP 만으로는 완전성 보증이 어렵기 때문에 , 다른 프로토콜을 조합하는 형태로 제공 . + SSL 에는 인증 + 암호화 + 다이제스트 기능을 제공함 .

HTTP + 암호화 + 인증 + 완전성 보호 = HTTPSHTTPS 는 HTTP 와 같은 통신 프로토콜이며 , 쓰임새 ( 메시지 전송 ) 또한 , HTTP 와 거의 흡사합니다 .하지만 HTTPS 는 앞서 설명했던 HTTP 의 취약점을 보완하기 위해 주고받는 모든 메시지를 암호화하며 , 암호화 방식에 쓰이는 Key 의 종류로는 크게 대칭과 비대칭 둘로 나뉘게 됩니다 .간단히 동작원리 ( 공개키 암호화 방식 ) 에 대해 설명하자면 , 클라이언트 ( 웹 브라우저 ) 와 서버 ( 웹서버 ) 가 서로 교환한 세션키 ( 대칭키 ) 로 주고받는 모든 컨텐츠 내용을 암호화합니다 .즉 , 중간에 네트웍 패킷을 가로챈다 해도 암호화된 내용이 노출되므로 보안상 안전하며 , 공유된 세션키 ( 대칭키 ) 를 모르는 상황에서 암호화를 푼다는 것은 모든 경우의 키를 대입해야 한다는 말이 됩니다 .만약 1024 비트 ( 보통은 128 비트 암호화 ) 의 암호화라면 , 평균적으로 2 의 512 승을 대입해야하며 , 이것은 2475880078570760000000000000.00 이라는 수를 대입해야 한다는 뜻과 같습니다 .

Page 10: Network 기본   4

02HTTPS

HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS

결론적으로 , 그러면 HTTPS 쓰면 되는데 왜 전부 사용을 하지 않을까요 ?1. 평문 통신에 비해서 암호화 통신은 CPU, 메모리 등 리소스가 많이 필요함 .2. 엑세스가 많은 웹사이트 등에서 암호화를 하면 그 부하가 상당함 .3. 증명서를 구입하는 비용 절약 .

Page 11: Network 기본   4

Thanks. Have a good day.