Presentation

HTTP( Hypertext Transfer Protocol )

하이퍼텍스트를 사용한 전송 통신 규약 → 약속

HTTP : The Internet's Multimedia Courier

•

이미지, HTML, 텍스트, 동영상, 음원, 자바 애플릿...

•

데이터를 온전하게 전송할 수 있는 통신 규약

Web Clients and Servers

•

클라이언트 ( 요청 : Request )  서버 ( 응답 :Response )

•

브라우저 ( 크롬, 엣지, 사파리 ... ) : 주소, 검색, 클릭 → 무언가 표시가 된다!

Resources

Web servers host resources

•

서버가 보유하고 있는 다양한 형태의 정적인 파일을 제공

◦

전철호 코멘트 작성 

1장 HTTP 개관

시작하며

인터넷을 볼만한 장소와 할 것이 많은 거대한 도시라고 생각해보자.

박물관, 레스토랑, 사람들의 집을 설명하기 위해 길거리 주소를 사용하고 소방서, 사장의 비서, 가족에게 연락하기 위해 전화번호를 사용한다.

책은 ISBN 번호를, 버스는 노선 번호를, 은행 계좌는 계좌번호를, 사람은 주민등록번호를 가진다.

모두가 이렇게 각기 다른 이름들에 대한 작명 표준에 동의하기 때문에, 도시에 있는 소중한 리소스를 모두 쉽게 공유할 수 있다.

리소스는 텍스트, 이미지, 동영상 같이 웹에서 사용되는 식별할 수 있는 모든 자원을 가리킨다.

URL(Uniform Resource Locator)은 인터넷의 리소스를 가리키는 표준이름이다. URL은 전자정보 일부를 가리키고 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.

이 장에서 다룰 것들

•

URL 문법, 여러 URL 컴포넌트가 어떤 의미를 가지며 무엇을 수행하는지.

•

여러 웹 클라이언트가 지원하는 상대 URL과 확장 URL 같은 단축 URL에 대해서.

•

URL의 인코딩과 문자 규칙.

•

여러 인터넷 정보 시스템에 적용되는 공통 URL 스킴.

•

기존 이름은 유지하면서 객체들을 다른 장소로 옮기는 것을 가능하게 해주는 URN(Uniform Resoutce Name) 을 포함한 URL의 미래.

2장 URL과 리소스

•

If HTTP is the Internet's courier, HTTP messages are the pacakages it uses to move things around.

•

This chapter tells you about HTTP messages — how to ceate them and how to understand them.

•

In prticular, you'll understand:

◦

How messages flow

◦

The three parts of HTTP messages (start line, headers, and entity body)

◦

The difference between request and response messages

◦

The various functions (methods) that request messages support

◦

The various status codes that are returned with response messages

◦

What the various HTTP headers do

1. The Flow of Messages

•

HTTP messages are the blocks of data sent between HTTP application.

•

These blocks of data begin with some text meta-information decribing the message contents and meaning, followed by optional data.

•

The terms "inbound", "outbound", "upstream", and "downstream" describe message direction.

1.1. Messages Commute Inbound to the Origin Server

•

HTTP uses the terms inbound and outbound to describe transactional direction.

•

Messages travel inbound to the origin server, and when their work is done, they travel outbound back to the user agent.

Figure 3-1. Messages travel inbound to the origin server and outbound back to the client

1.2. Messages Flow Downstream

•

All message flow downstream, regardless of whether they are request messages or responses message.

3장 HTTP 메시지

TCP 커넥션

•

HTTP는 패킷 교환 네트워크 프로토콜의 계층화된 집합인 TCP/IP를 통해 이루어진다.

•

메시지가 손실, 손상되거나 순서가 바뀌지 않고 안전하게 전달된다.

•

주소 입력 → TCP 커넥션 생성 → 요청 → 응답 → TCP 커넥션 해제.

신뢰할 수 있는 데이터 전송통로인 TCP

•

TCP 커넥션은 인터넷을 안정적으로 연결해준다.

•

TCP 커넥션을 통해 한 바이트씩 순서대로 전달된다.

TCP 스트림은 세그먼트로 나뉘어 IP 패킷을 통해 전송된다

•

HTTP는 '프로토콜 스택'의 최상위 계층이다.

•

HTTP + TLS(SSL) ⇒ HTTPS

•

TCP는 세그먼트 단위로 데이터 스트림을 잘게 나누고, IP 패킷에 담아서 전달한다.

4장 커넥션 관리

시작하며

웹 서버는 매일 수십억 개의 웹페이지를 쏟아 낸다. 웹 서버는 우리에게 날씨를 알려주고, 온라인 쇼핑 카트에 물건을 싣고, 오랫동안 만나지 못한 고등학교 친구를 찾을 수 있게 해준다. 웹 서버는 월드 와이드 웹(WWW)의 일꾼이다.

이 장에서 다룰 것들

•

여러 종류의 소프트웨어 및 하드웨어 웹 서버에 대해 조사한다.

•

HTTP 통신을 진단해주는 간단한 웹 서버를 펄(Perl)로 작성해본다. → 생략

•

어떻게 웹 서버가 HTTP 트랜잭션을 처리하는지 단계별로 설명한다. → 가장 중요

5.1 다채로운 웹 서버

웹 서버라는 용어는 웹 서버 소프트웨어와 웹페이지 제공에 특화된 장비(컴퓨터와 같은) 양쪽 모두를 가리킨다.

모든 웹 서버는 리소스에 대한 HTTP 요청을 받아서 콘텐츠를 클라이언트에게 돌려 준다.

5.1.1 웹 서버 구현

웹 서버는 HTTP 프로토콜을 구현하고, 웹 리소스를 관리하고, 웹 서버 관리 기능을 제공한다.

5장 웹 서버

•

웹 프록시 서버는 중개자(intermediaries)이며, 클라이언트와 서버 사이에 위치하여 그들 사이의 메시지를 정리하는 중개인처럼 동작한다. 

•

이 장에서는 아래와 같은 내용을 다룬다.

◦

HTTP 프록시와 웹 게이트웨이를 비교하고 HTTP 프록시가 어떻게 배치되는지 설명한다.

◦

프록시가 활용되는 방법을 설명한다.

◦

프록시가 실제 네트워크에 어떻게 배치되어 있는지 그리고 트래픽이 어떻게 프록시 서버로 가게되는지 설명한다.

◦

브라우저에서 프록시를 사용하려면 어떻게 설정해야 하는지 보여준다.

◦

HTTP 프락시 요청이 서버 요청과 어떻게 다른지, 그리고 프락시가 어떻게 브라우저의 동작을 미묘하게 바꾸는지 보여준다.

◦

일련의 프록시 서버들을 통과하는 메시지의 경로를, Via 헤더와 TRACE 메서드를 이용해 기록하는 방법을 설명한다.

◦

프록시에 기반한 HTTP 접근 제어를 설명한다.

◦

어떻게 프록시가 클라이언트와 서버 사이에서 각각의 다른 기능과 버전들을 지원하면서 상호작용 할 수 있는지 설명한다.

6.1 Web Intermediaries

•

웹 프록시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인

•

클라이언트는 웹 서버와 통신하는 대신 프록시와 통신하며, 프록시는 클라이언트 입장에서 서버와 통신(단, 프록시를 거치는 것을 원할 경우)

•

클라이언트 입장에서 트랜잭션을 완료한다는 측면에서는 동일하지만, 프락시 서버가 제공하는 좋은 서비스를 활용할 수 있게됨

•

HTTP 프록시는 웹 서버이자 웹 클라이언트이기도 함

•

프록시는 HTTP 클라이언트의 요청을 받게 되므로, 반드시 웹 서버처럼 요청과 커넥션을 적절히 다루고 응답을 돌려줘야 함

•

그와 동시에 프락시는 요청을 서버로 보내기도 하므로, 요청을 보내고 응답을 받는 올바른 HTTP 클라이언트처럼 동작해야 함

Figure 6-1. A proxy must be both a server and a client

6.1.1 Private and Shared Proxies

•

공유 프록시(public proxies): 여러 클라이언트에게 공유되는 프록시

◦

대부분의 프록시는 공용이며 공유된 프록시임

◦

중앙 집중된 프록시를 관리하는 게 더 비용효율이 높고 쉬움

◦

그리고 캐시 프록시 서버와 같은 몇몇 프록시 애플리케이션은 프록시를 이용하는 사용자가 많을수록 유리

•

개인 프록시(private proxies): 하나의 클라이언트가 독점하여 사용하는 프록시

◦

개인 전용 프락시는 그다지 흔하지는 않지만 꾸준히 사용되고 있음(특히 클라이언트 컴퓨터에서 직접 실행되는 형태로)

◦

어떤 브라우저 보조 제품들은 몇몇 ISP 서비스와 마찬가지로 브라우저의 기능을 확장하거나 성능을 개선하거나 무료 ISP 서비스를 위한 광고를 운영하기 위해 작은 프록시를 사용자의 컴퓨터에서 직접 실행

6장 프록시