1. HTTP 개관
2. URL과 리소스
3. HTTP 메시지
4. 커넥션 관리
2장. URL과 리소스
URI
- 정보 리소스를 고유하게 식별하고 위치를 지정
- URL과 URN 두 가지가 존재
- URL(uniform resource locator) : 리소스 식별자의 가장 흔한 형태, 구체적인 위치를 서술
- URN(uniform resource name) : 리소스의 위치에 영향을 받지 않은 유일무이한 이름 역할, 리소스가 그 이름을 변하지 않게 유지하는 한, 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제없음
- 오늘날 대부분의 URL은 URI(같은 의미로 사용)
URL 문법
http:// www.joes-hardware.com /specials/saw-blade.gif
http:// : 스킴(scheme)
: 리소스에 접근하기 위해 사용되는 프로토콜을 서술. 보통 HTTP 프로토콜(http://)
다른 가용한 프로토콜도 사용 가능
- mailto :smkim2339@gmail.com : 이메일 주소
- ftp://ftp.lots-o-books.com/pub/complete-price-list.xls : FTP 서버에 올라가 있는 파일
- rtsp://www.joes-hardware.com:554/interview/cto-video 스트르밍을 제공하기 위해 비디오 서버에 호스팅하고 있는 영화
www.joes-hardware.com : 서버의 인터넷 주소
/specials/saw-blade.gif : 웹 서버의 리소스를 가리킴
대부분의 URL 스킴의 문법은 9개 부분으로 나뉨
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
이 모든 컴포넌트를 가지는 URL은 거의 없다. 가장 중요한 컴포넌트는 스킴, 호스트, 경로 이다.
<스킴>
- 사용할 프로토콜
- 알파벳으로 시작해야 함
- URL의 나머지 부분들과 첫 번째 ':'문자로 구분
- 대소문자를 가리지 않음(http, HTTP 동일)
<사용자 이름, 비밀번호>
- 몇몇 스킴은 리소스에 접근 하기 위해 사용자 이름을 필요로 함
- 대표적으로 FTP 서버
<호스트와 포트>
애플리케이션이 인터넷에 있는 리소스를 찾으려면, 리소스를 호스팅하고 있는 장비와 그 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 함
- 호스트는 인터넷상의 호스트 장비를 가리킴
- 포트는 서버가 열어놓은 네트워크 포트를 가리킴
- 많은 스킴이 기본 포트를 가지고 있음(HTTP는 80)
<경로>
- 리소스가 서버의 어디에 있는지 알려줌
- 계층적 파일 시스템 경로와 유사한 구조
<파라미터>
많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못하기 때문에 추가 정보가 필요
- 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용
- 이름/값 쌍을 가짐
- URL 나머지 부분들로부터 ';' 문자로 구분하여 URL에 기술
http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
위 URL에는 hammers와 index.html이라는 두 개의 경로조각이 있다. hammers 경로조각은 값이 false인 sale이라는 파라미터를 가진다. index.html 경로조각은 값이 true 인 graphics란 파라미터를 가진다.
<질의>
- 데이터베이스 같은 서비스의 경우, 요청받을 리소스 형식의 범위를 좁히기 위해 사용 가능
http://www.joes-hardware.com/inventory-check.cgi?item=1245&color=blue 평소 요청하던 URL과 유사
<프래그먼트>
- 리소스의 조각이나 일부부을 가리키는 이름
- URL이 특정 객체를 가리킬 경우에 프래그먼트 필드는 서버에 전달되지 않음
- 클라이언트에서만 사용
- URL의 끝에서 '#'문자로 구분
- 브라우저가 서버로부터 전체 리소스를 내려받은 후, 프래그먼트를 사용해 보고자 하는 리소스의 일부를 보여줌
단축 URL
1. 상대 URL
<HTML>
<HEAD><TITLE>Joe's Tools</TITLE></HEAD>
<p>Joe's hardware online has the largest selection of <a href="./hammers.html">hammers</a> on earth.</p>
</HTML>- 현재 문서의 URL을 기준으로 상대경로로 해석
- 프래그먼트이거나 URL일부
- URL을 처리하는 브라우저 같은 애플리케이션은 상대 URL과 절대 URL 간에 상호 변환할 수 있어야 함
2. URL 확장
a. 호스트 명 확장
브라우저가 지원하며, 'naver'를 입력하면 자동으로 'www.'와 '.com'을 붙여서 'www.naver.com'을 만든다
b. 히스토리 확장
사용자가 URL을 입력하는 시간을 줄이고자, 브라우저가 사용하는 또 다른 기술. 과거에 사용자가 방문했던 URL의 기록을 저장해 놓는 것
스킴
가장 유명한 스킴들
http
- 사용자 이름이나 비밀번호가 없다는 것을 제외하면, 일반 URL 포맷을 지킨 스킴
- 포트값이 생략되어 있으면 기본값은 80
- 기본형식 : http://<호스트>:<포트>/<경로>?<질의>#<프래그먼트>
- 예 : http://www.joes-hardware.com/index.html
https
- http 스킴과 거의 같음
- 차이점은 HTTP의 커넥션의 양 끝단에서 암호화하기 위해 넷스케이프에서 개발한 보안 소켓 계층(Secure Sockets Layer, SSL)을 사용한다는 것
- 문법은 HTTP와 같고, 기본 포트값은 443
mailto
- 이메일 주소
- 다른 스킴과 다르게 동작하기 때문에, 표준 URL과는 다른 포맷을 가짐
- 예 : mailto@joes-hardware.com
ftp
- FTP 서버에 있는 파일을 내려 받거나 올리고, FTP 서버의 디렉터리에 있는 콘텐츠 목록을 가져오는 데 사용
- 웹 애플리케이션은 데이터에 접근하는 용도의 스킴으로 FTP를 사용
- 기본형식 : ftp://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>
- 예 : ftp://anonymous:joe-pwd@prep.ai.mit.edu:21/pub/gnu/
rtsp, rtspu
- 실시간 스트리밍 프로토콜을 통해서 읽을 수 있는 오디오 및 비디오와 같은 미디어 리소스 식별자
file
- 주어진 호스트 기기(로컬 디스크, 네트워크 파일 시스템 혹은 기타 파일 공유 시스템)에서 바로 접근할 수 있는 파일들을 나타냄
- 만약 호스트가 생략되어 있으면, URL을 사용하고 있는 기기의 로컬 호스트가 기본값이 됨
news
- 특정 문서나 뉴스 그룹에 접근하는데 사용
telnet
- 대화형 서비스에 접근하는데 사용
3장. HTTP 메시지
메시지의 흐름
메시지는 클라이언트, 서버, 프락시 사이를 흐른다. '인바운드','아웃바운드','업스트림','다운스트림'은 메시지의 방향을 의미하는 용어다.
메시지의 각 부분
HTTP 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다. 시작줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있다. 본문은 아예 없을 수도 있다.
메시지 문법
시작줄만 문법이 다르다.
메서드
클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작('GET', 'HEAD', 'POST')
요청 URL
요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
버전
이 메시지에서 사용 중인 HTTP의 버전 HTTP/<메이저>.<마이너>
정수로 다루는 것에 주의 : HTTP/2.22 는 HTTP/2.3 보다 크다
상태 코드
요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자. 각 코드의 첫 번째 자릿수는 상태의 일반적인 분류('성공', '에러' 등)를 나타냄
사유 구절
숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구(200 -> OK)
예를 들어, 'HTTP/1.0 200 NOT OK'와 ''HTTP/1.0 200 OK'는 사유 구절이 서로 전혀 달라 보임에도 동등하게 성공을 의미
헤더들
이름, 콜론(:), 선택적인 공백, 값, CRLF(줄바꿈)가 순서대로 나타나는 0개 이상의 헤더들
엔터티 본문
임의의 데이터 블록. 모든 메시지가 엔터티 본문을 갖는 것은 아님
❗️ 헤더나 엔터티 본문이 없더라도 HTTP 헤더의 집합은 항상 빈 줄(그냥 CRLF)로 끝나야함
메서드
| 메서드 | 설명 | 메시지 본문이 있는가? |
|---|---|---|
| GET | 서버에서 어떤 문서를 가져온다. | 없음 |
| HEAD | 서버에서 어떤 문서에 대해 헤더만 가져온다. | 없음 |
| POST | 서버가 처리해야 할 데이터를 보낸다. | 있음 |
| PUT | 서버에 요청 메시지의 본문을 저장한다. | 있음 |
| TRACE | 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다. | 없음 |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인한다. | 없음 |
| DELETE | 서버에서 문서를 제거한다. | 없음 |
- 모든 서버가 위 메서드를 모두 구현한 것은 아님
- HTTP는 쉽게 확장할 수 있도록 설계되었기 때문에, 서버는 그들만의 메서드를 추가로 구현했을 수도 있음(확장 메서드)
GET
- 가장 흔히 쓰는 메서드
- 주로 서버에게 리소스를 요청할 때 사용
HEAD
- 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줌
- 엔터티 본문은 반환되지 않음
- 리소스를 가져오지 않고도 그에 대해 무엇인가(타입 등)를 알아낼 수 있음
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인 가능
- 헤더를 확인하여 리소스가 변경되었는지 검사 가능
PUT
- 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것
POST
- 서버에 입력 데이터를 전송하기 위해 설계
- 실제로, HTML 폼을 지원하기 위해 흔히 사용
❗️ POST는 서버에 데이터를 보내기 위해 사용하고, PUT은 서버에 있는 리소스(예:파일)에 데이터를 입력하기 위해 사용
TRACE
- 클라이언트의 요청 중에는 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있으며, 이때, 원래의 HTTP 요청을 수정 가능. TRACE는 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
- 주로 진단을 위해 사용
- 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인할 때 좋음
- 요청에는 어떠한 엔터티 본문도 보낼 수 없고, 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있음
OPTIONS
- 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어보고, 특정 리소스에 대해 어떤 메서드가 지원되는지 알려줌
- 여러 리소스에 대해 실제 접근하지 않고도 그것들을 어떻게 접근하는게 최선인지 확인하는 수단으로 사용
DELETE
- 요청 URL로 지정한 리소스 삭제 요청
확장 메서드
- HTTP는 필요에 따라 확장해도 문제가 없도록 설계되어 있으므로, 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않음
- 예시 : LOCK, MKCOL, COPY, MOVE
- 모든 확장 메서드가 형식을 갖춘 명세로 정의된 것은 아님
🧐 엄격하게 보내고 관대하게 받아들여라
상태 코드
상태코드의 종류
| 전체 범위 | 정의된 범위 | 분류 |
|---|---|---|
| 100-199 | 100-101 | 정보 |
| 200-299 | 200-206 | 성공 |
| 300-399 | 300-305 | 리다이렉션 |
| 400-499 | 400-415 | 클라이언트 에러 |
| 500-599 | 500-505 | 서버 에러 |
많이 쓰이는 상태 코드들
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 200 | OK | 성공! 요청한 모든 데이터는 응답 본문에 들어있다. |
| 401 | Unauthorized | 사용자 이름과 비밀번호를 입력해야 한다. |
| 404 | Not Found | 서버는 요청한 URL에 해당하는 리소스를 찾지 못했다. |
헤더
1. 일반 헤더
- 클라언트와 서버 양쪽 모두가 사용
- 메시지에 대한 아주 기본적인 정보 제공
- 일반 정보 헤더 : Date, Connection, MIME-Version, Trailer chunked transfer 등
일반 캐시 헤더
HTTP/1.0에서 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더를 도입했다.
| 헤더 | 설명 |
|---|---|
| Cache-Control | 메시지와 함께 캐시 지시자를 전달하기 위해 사용 |
| Pragma | 메시지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않음 |
2. 요청 헤더
- 요청 메시지를 위한 헤더
- 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보를 제공
- 서버는 요청 헤더가 준 클라이언트에 대한 정보를 통해 클라이언트에게 더 나은 정보를 주는데 활용 가능
- ex) Accept: */* (서버에서 클라이언트가 자신의 요청에 대응하는 어떤 미디어 타입도 받겠다는 의미)
Accept 관련 헤더
클라이언트가 무엇을 원하고 무엇을 할 수 있는지, 무엇을 원치 않는지 알려준다.
Accept, Accept-Charset, Accept-Encoding(서버에게 서버가 보내도 되는 인코딩을 말해줌) 등
조건부 요청 헤더
요청에 제약을 넣는다.
ex) If-Modified-Since : 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한
요청 보안 헤더
자체적인 HTTP의 요청을 위한 간단한 인증요구/응답 체계에 사용
ex) Authorization, Cookie 등
프락시 요청 헤더
프락시를 돕기 위한 헤더
ex) Max-Forwards, Proxy-Authorization 등
3. 응답 헤더
- 클라이언트에게 부가 정보 제공
- 누가 응답을 보내고 있는지 혹은 응답자의 능력은 어떻게 되는지 등 제공
협상 헤더
서버에 프랑스어와 독일어로 번역된 HTML 문서가 있는 경우와 같이 여러가지 표현이 가능한 상황에, HTTP/1.1은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상 지원
응답 보안 헤더
4. 엔터티 헤더
- 엔터티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드들까지, 광범위한 정보를 제공
- 일반적으로 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해줄 때 사용
- 예시 : Content-Type : text/html; charset=iso-latin-1
5. 확장 헤더
- 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더
- HTTP 프로그램은 확장 헤더들에 대해 몰라도 전달할 수 있어야 함
콘텐츠 헤더
엔터티 캐싱 헤더
일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다. 엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공한다.
