HTTP 완벽 가이드 - 웹의 기초

1) HTTP 개관

HTTP: 인터넷의 멀티미디어 배달부

1. HTTP는 전 세계의 웹 서버로부터 대량의 정보를 빠르고, 간편하고, 정확하게 사람들의 PC에 설치된 웹 브라우저로 옮겨준다.

2. HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에, 데이터가 지구 반대편에서 오더라도 전송 중 손상되거나 꼬이지 않음을 보장한다.

웹 클라이언트와 서버

1. 가장 흔한 클라이언트는 구글 크롬 같은 웹브라우저다.

2. 웹브라우저는 서버에게 HTTP 객체를 요청하고 사용자의 화면에 보여준다.

3. 서버는 요청받은 객체를 찾고, 성공했다면 그것의 타입, 길이 등의 정보와 함께 HTTP 응답에 실어서 클라이언트에게 보낸다.

...자세히 보기

리소스

1. 웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다.

2. HTTP는 주어진 URI로 객체를 찾아온다.

3. 오늘날 대부분의 URI는 URL이다.

...자세히 보기

트랜잭션

1. HTTP는 HTTP 메서드라고 불리는 여러 가지 종류의 요청 명령을 지원한다.

2. 모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다.

3. 페이지 레이아웃을 서술하는 HTML '뼈대'를 한 번의 트랜잭션으로 가져온 뒤, 첨부된 이미지, 그래픽 조각, 자바 애플릿 등을 가져오기 위해 추가로 HTTP 트랜잭션들을 수행한다.

...자세히 보기

메시지

1. HTTP 메시지는 단순한 줄 단위의 문자열이다.

2. 이진 형식이 아닌 일반 텍스트이기 때문에 사람이 읽고 쓰기 쉽다.

3. HTTP 메시지는 시작줄, 헤더, 본문으로 이루어진다.

...자세히 보기

TCP 커넥션

1. HTTP는 네트워크 통신의 핵심적인 세부사항에 대해서 신경 쓰지 않는다. 대신 대중적으로 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP에게 맡긴다.

2. HTTP 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, 인터넷 프로토콜 (Internet protocol, IP) 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.

3. HTTP 서버의 IP 주소와 포트번호를 어떻게 알아낼 수 있을까? URL을 이용하면 된다.

...자세히 보기

프로토콜 버전

1. HTTP/0.9는 오직 GET 메서드만 지원하고, 멀티미디어 콘텐츠에 대한 MIME 타입이나, HTTP 헤더, 버전 번호는 지원하지 않는다.

2. HTTP/1.0은 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했다.

3. HTTP/1.1은 HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다.

...자세히 보기

웹의 구성요소

1. 프락시는 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다.

2. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다.

3. 터널은 두 커넥션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다.

...자세히 보기

2) URL과 리소스

인터넷의 리소스 탐색하기

1. URI는 두 가지 주요 부분집합인, URL과 URN으로 구성된 종합적인 개념이다.

2. URN은 현재 그 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별하는데 비해 URL은 리소스가 어디 있는지 설명해서 리소스를 식별한다.

...자세히 보기

URL 문법

1. URL의 가장 중요한 세 가지 컴포넌트는 스킴, 호스트, 경로다.

2. 스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다. 이는 URL을 해석하는 애플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다.

3. 호스트 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다. 해당 값은 호스트 명이나 IP 주소로 제공한다.

...자세히 보기

단축 URL

1. URL은 상대 URL과 절대 URL 두 가지로 나뉜다.

2. 상대 URL로 리소스에 접근하는 데 필요한 모든 정보를 얻기 위해서는, 기저(base)라고 하는 다른 URL을 사용해야 한다.

3. URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환을 할 수 있어야 한다.

...자세히 보기

안전하지 않은 문자

1. US-ASCII는 미국 시민들 사이에서는 편리하게 쓰이고 있기는 하지만, 전 세계 십수억의 사람들이 사용하는 유럽 언어나 수백 가지의 비 라틴계 언어들에 존재하는 변형된 문자들까지 US-ASCII가 지원하지는 않는다.

2. 이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.

3. 인코딩은 안전하지 않은 문자를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 '이스케이프' 문자로 바꾼다.

...자세히 보기

3) HTTP 메시지

메시지의 흐름

1. HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다.

2. 메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것이다.

3. 요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

...자세히 보기

메시지의 각 부분

1. 시작과 헤더는 그냥 줄 단위로 분리된 아스키 문자열이다.

2. 각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열로 끝난다. 이 줄바꿈 문자열은 'CRLF'라고 쓴다. (\r\n)

3. 응답의 프로토콜 버전이 HTTP/1.1이라는 것은 사실 응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있음을 의미하는 것이다.

...자세히 보기

메서드

1. HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다. 엔터티 본문은 결코 반환되지 않는다.

2. TRACE 메서드는 주로 진단을 위해 사용된다.

3. OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다.

...자세히 보기

상태 코드

1. 리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.

2. 만약 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 (선택적으로) Location 헤더를 보낼 수 있다.

3. 결국 서버는 리다이렉트 응답에 들어갈 가장 적절한 리다이렉트 상태 코드를 선택하기 위해 클라이언트 HTTP 버전을 검사할 필요가 있다.

...자세히 보기

헤더

1. Date 헤더는 서버와 클라이언트를 가리지 않고 메시지가 만들어진 일시를 지칭하기 위해 사용하는 일반 목적 헤더이다.

2. 엔터티 헤더란 엔터티 본문에 대한 헤더를 말한다. 예를 들어, 엔터티 헤더는 엔터티 본문에 들어있는 데이터의 타입이 무엇인지 말해줄 수 있다.

3. 확장 헤더는 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더다.

...자세히 보기

4) 커넥션 관리

TCP 커넥션

1. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷(혹은 IP 데이터그램)이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다.

2. 각 TCP 세그먼트는 하나의 IP 주소에서 다른 IP 주소로 IP 패킷에 담겨 전달된다.

3. TCP 커넥션은 네 가지 값으로 식별한다. <발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트>

...자세히 보기

TCP의 성능에 대한 고려

1. 클라이언트나 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

2. 어떤 데이터를 전송하든 새로운 TCP 커넥션을 열 때면, TCP 소프트웨어는 커넥션을 맺기 위한 조건을 맞추기 위해 연속으로 IP 패킷을 교환한다.

3. TCP 커넥션은 시간이 지나면서 자체적으로 '튜닝'되어서, 처음에는 커넥션의 최대 속도를 제한하고 데이터가 성공적으로 전송됨에 따라서 속도 제한을 높여나간다.

...자세히 보기

HTTP 커넥션 관리

1. HTTP 메시지는 클라이언트에서 서버(혹은 리버스 서버)까지 중개 서버들을 하나하나 거치면서 전달된다.

2. Connection 헤더에 있는 모든 헤더 필드는 메시지를 다른 곳으로 전달하는 시점에 삭제되어야 한다.

3. 각 트랜잭션이 새로운 커넥션을 필요로 한다면, 커넥션을 맺는데 발생하는 지연과 함께 느린 시작 지연이 발생할 것이다.

...자세히 보기

병렬 커넥션

1. HTTP는 클아이언트가 여러 개의 커넥션을 맺음으로써 여러 개의 HTTP 트랜잭션을 병렬로 처리할 수 있게 한다.

2. 각 커넥션의 지연 시간을 겹치게 하면 총 지연 시간을 줄일 수 있고, 클라이언트의 인터넷 대역폭을 한 개의 커넥션이 다 써버리는 것이 아니라면 나머지 객체를 내려받는 데에 남은 대역폭을 사용할 수 있다.

3. 브라우저는 실제로 병렬 커넥션을 사용하긴 하지만 적은 수(대부분 4개)의 병렬 커넥션만을 허용한다.

...자세히 보기

지속 커넥션

1. 지속 커넥션은 병렬 커넥션에 비해 몇 가지 장점이 있다. 커넥션을 맺기 위한 사전 작업과 지연을 줄여주고, 튜닝된 커넥션을 유지하며, 커넥션의 수를 줄여준다.

2. HTTP/1.0 keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection: Keep-Alive 헤더를 포함시킨다.

3. HTTP/1.0의 keep-alive 커넥션과는 달리 HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있다.

...자세히 보기

파이프라인 커넥션

1. HTTP/1.1은 지속 커넥션을 통해서 요청을 파이프라이닝할 수 있다.

2. 여러 개의 요청은 응답이 도착하기 전까지 큐에 쌓인다.

3. HTTP 클라이언트는 POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안 된다.

...자세히 보기

커넥션 끊기에 대한 미스터리

1. HTTP 애플리케이션은 언제든지 지속 커넥션을 임의로 끊을 수 있다.

2. 클라이언트나 프락시가 커넥션이 끊어졌다는 HTTP 응답을 받은 후, 실제 전달된 엔터티의 길이와 Content-Length의 값이 일치하지 않거나 Content-Length 자체가 존재하지 않으면 수신자는 데이터의 정확한 길이를 서버에게 물어봐야 한다.

3. 클라이언트가 트랜잭션을 수행 중에 전송 커넥션이 끊기게 되면, 클라이언트는 그 트랜잭션을 재시도 하더라도 문제가 없다면 커넥션을 다시 맺고 한 번 더 전송을 시도해야 한다.

...자세히 보기

원문: https://product.kyobobook.co.kr/detail/S000001033001
전체 요약본 보러가기