1.1 HTTP : 인터넷의 멀티미디어 배달부
- HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에(TCP를 의미하는 듯 하다. HTTP는 주로 TCP를 사용한다.) 데이터가 전송 중 손상되거나 꼬이지 않음을 보장한다.
1.2 웹 클라이언트와 서버
- 월드 와이드 웹의 3대 요소 : HTTP, HTML, URI
- 클라이언트는 서버에게 HTTP 요청을 보내고 서버는 요청된 데이터를 HTTP 응답으로 돌려준다.
1.3 리소스
- 웹 서버는 웹 리소스를 관리하고 제공한다.
-
웹 리소스 : 웹 콘텐츠의 원천, 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.
- 정적 파일 : 가장 단순한 웹 리소스, 텍스트 파일, html 파일, 워드 파일, 이미지 파일, 동영상 파일, 그 외의 모든 종류의 파일
- 동적 콘텐츠 : 요청에 따라 콘텐츠를 생산하는 프로그램
-
1.3.1 미디어 타입
- MIME 타입 : 데이터 포맷 라벨, 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 채택. 웹에서 전송되는 객체 각각에 MIME 타입의 데이터 포맷라벨을 붙인다.
- HTML로 작성된 텍스트 문서 : text/html
- JPEG 이미지 : image/jpeg
- json data : application/json
1.3.2 URI
-
서버 리소스 이름 = 통합 자원 식별자 = URI
-
정보 리소스를 고유하게 식별하고 위치를 저장할 수 있다.
-
ex. http://www.joes-hardware.com/specials/saw-blade.gif
- http:// : http 프로토콜을 사용- www.joes-hardware.com : 서버 명시
- /specials/saw-blade.gif : 리소스 명시
1.3.3 URL
- 특정 서버의 한 리소스에 대한 구체적인 위치
- 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 정확한 위치와 접근방법 표현
- 표준 포맷
- 첫번째 부분 : 스킴. 프로토콜 서술(http://)
- 두번째 부분 : 서버의 인터넷 주소 제공(www.joes-hardware.com)
- 세번째 부분 : 웹 서버의 리소스(/specials/saw-blade.gif)
- 오늘날의 대부분 URI는 URL이다.
1.3.4 URN
- URI의 두번째 종류, 유니폼 리소스 이름
- 리소스의 위치에 영향을 ㅂ다지 않는 유일무이한 이름 역할
1.4 트랜잭션
- 요청명령(클라이언트->서버)과 응답결과(서버->클라이언트)로 구성
1.4.1 메서드
- 서버에게 어떤 동작이 취해져야 하는지 말해준다.
- HTTP 요청 메시지는 한 개의 메서드를 갖는다.
- GET, PUT, DELETE, POST, HEAD 등
1.4.2 상태코드
- 클라이언트에게 요청이 성공했는지 아니면 추가 조치가 필요한지 알려주는 세자리 숫자
- 모든 http 응답 메시지는 상태코드와 함께 반환
- ex. 200(ok), 302(다시 보내라, 다른 곳에 가서 리소스를 가져가라, 리다이렉트), 404(리소스 찾을 수 없음, not found)
1.4.3 웹페이지는 여러 객체로 이루어질 수 있다.
- 하나의 웹페이지는 보통 하나의 리소스가 아닌 리소스의 모음이다.
- 한 페이지를 표현하기 위해 여러 번의 요청과 응답이 있을 수 있다. (여러번의 http 트랜잭션)
1.5 메시지
/* 요청 메세지 */
// 시작줄
GET /test/hi-ther.txt HTTP/1.0
// 헤더
Accept: text/*
Accept-Language: en, fr
/* 응답 메세지 */
// 시작 줄
HTTP/1.0 200 OK
// 헤더
Content-type: text/plain
Content-length: 19
// 본문
Hi! I'm a message!- 시작줄 : 메시지의 첫 줄
- 요청 메시지 : 무엇을 해야하는지 나타냄
- 응답 메시지 : 무슨 일이 일어났는지 나타냄
- 헤더 : 콜론(:)으로 구분되어 있는 key:value 형태
- 본문 : 필요에 따라 어떤 종류의 데이터든 들어갈 수 있는 메시지 본문이 올 수 있다. (텍스트 뿐 아니라 이미지, 비디오, 오디오, 응용소프트웨어 등 이진데이터도 가능)
1.6 TCP 커넥션
- 어떻게 메시지가 TCP커넥션을 통해 한곳에서 다른 곳으로 옮겨질까
1.6.1 TCP/IP
- HTTP는 애플리케이션 계층 프로토콜로, 네트워크 통신의 핵심적인 세부사항에 대해선 신경쓰지 않는다.
- 대신 TCP/IP에게 맡긴다.
- TCP는 다음을 제공한다.
- 오류없는 데이터 전송
- 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착)
- 조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)
1.6.2 접속 IP 주소 그리고 포트번호
- HTTP 클라이언트가 서버에 메시지 전송하기 전에 IP주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP커넥션을 맺어야 한다.
- 웹브라우저가 어떻게 HTTP를 사용해서 멀리 떨어진 곳에 있는 서버의 단순한 HTML 리소스를 사용자에게 보여줄까
1. 웹브라우저는 서버의 url에서 호스트명 추출- 웹브라우저는 서버의 호스트명을 ip로 변환
- 웹브라우저는 url에서 포트번호(있다면) 추출
- 웹브라우저는 웹서버와 tcp 커넥션 맺음
- 웹브라우저는 서버에 http 요청 보냄
- 서버는 웹브라우저에게 http 응답 돌려줌
- 커넥션 닫히면 웹브라우저는 문서를 보여줌
1.7 프로토콜 버전
- HTTP/0.9
- 디자인 결함, 구식 클라이언트하고만 같이 사용 가능
- GET 메서드만 지원
- MIME 타입, HTTP 헤더, 버전번호 지원하지 않음
- 간단한 html 객체 받아오기 위함
- HTTP/1.0
- 처음으로 널리 쓰이기 시작한 HTTP 버전
- http 헤더, 추가 메서드, 멀티미디어 객체 처리 추가
- 매력적인 웹페이지, 상호작용하는 폼
- HTTP/1.0+
- keep-alive 커넥션(트랜잭션이 한번 일어나면 HTTP Connection이 끊기고 TCP 커넥션을 맺는데 발생하는 지연과 느린 시작 지연이 트랜잭션마다 발생해서 성능이 매우 안 좋았던 부분을 개선하기 위해 등장
HTTP/1.1에서 Persistent connection이 디폴트로 지원되면서 사용할 필요가 없어짐), 가상호스팅 지원, 프락시 연결 지원(사실상표준)
- keep-alive 커넥션(트랜잭션이 한번 일어나면 HTTP Connection이 끊기고 TCP 커넥션을 맺는데 발생하는 지연과 느린 시작 지연이 트랜잭션마다 발생해서 성능이 매우 안 좋았던 부분을 개선하기 위해 등장
- HTTP/1.1
- 현재의 HTTP 버전
1.8 웹의 구성요소
1.8.1 프락시
-
클라이언트와 서버 사이에 위치한 HTTP 중개자
-
주로 보안을 위해 사용
- 모든 웹 트래픽 흐름 속 신뢰할만한 중개자 역할
- 요청과 응답을 필터링(ex. 회사에서 무언가 다운받을 때 바이러스 검출, 학생들에게서 성인 콘텐츠 차단)
-
6장에서 자세히
1.8.2 캐시
- 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
- 자주 찾는 것의 사본을 저장해두는 특별한 종류의 HTTP 프락시 서버
- 7장에서 자세히
1.8.3 게이트웨이
- 다른 애플리케이션과 연결된 특별한 웹서버
- 다른 서버들의 중개자로 동작
- 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용(ex. HTTP/FTP 게이트웨이 : FTP URI에 대한 HTTP 요청을 받아들인 뒤, FTP 프로토콜을 이용해 문서 가져옴, 받아온 문서는 HTTP 메시지에 담겨 클라이언트에게 보냄)
- 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못함
- 8장에서 자세히
1.8.4 터널
- 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
- 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션
- HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용
- 대표적인 예
- 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송하여 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것
- 8장에서 자세히
1.8.5 에이전트
- 자동화된 HTTP 요청을 만드는 준지능적 웹 클라이언트
- 웹브라우저
- 뿐만 아니라 스파이더, 웹 로봇 등과 같이 자동화된 에이전트도 있다.
- 9장에서 자세히
