1.1 HTTP: 인터넷의 멀티미디어 배달부
http는 신뢰성있는 데이터 전송 프로토콜 쓰기에 데이터가 지구 반대편에서 오더라도 전송 중 손상된거나 꼬이지 않음을 보장한다.
1.2 웹 클라이언트와 서버
웹 콘텐츠는 웹 서버에 존재. 웹 서버는 http 로 소통하기에 http 서버라고도 불린다. http 서버는 WWW의 기본 요소.
예를 들어 http://www.naver.com/index.html 열어볼 때 웹브라우저는 http 요청을 www.naver.com 에 보낸다. 서버는 요청 받은 객체(index.html)찾고, 성공했다면 그것의 타입, 길이 등 정보와 함께 http 응답에 실어 클라이언트에게 보낸댜.
1.3 리소스
웹 서버는 웹 리소스를 관리하고 제공한다. 가장 단순한 웹 리소스는 정적 파일. 정적 파일은 텍스트, HTML, 워드 파일, PNG 이미지 등 이다.
그러나 리소스는 반드시 정적 파일이어야 할 필요는 없다. 리소스는 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수도있다. 이 동적 콘텐츠 리소스는 사용자가 누구인지, 어떤 정보를 요청했는지에 따라 다른 콘텐츠를 생산한다.
1.3.1 미디어 타입
인터넷은 수천 가지 데이터 타입 다루기에 http는 웹에서 전송되는 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다. **MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장)**은 원래 각기 다른 전자메일 시스템 사이에서 메시지가 오갈 때 겪는 문제를 해결하기 위해 설계되었다. MIME는 이메일에서 워낙 잘 작동했기 때문에, http 에서도 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 채택되었다.
웹 서버는 모든 http 객체 데이터에 MIME 타입을 붙인다.
1.3.2 URI
서버 리소스 이름은 uniform resource identifier, URI 라 불린다. 리소스를 고유하기 식별하고 위치 지정이 가능하다.
URI에는 2가지가 있는데 URL, URN 이다.
1.3.3 URL
통합 자원 지시자, uniform resource locator, URL 은 리소스 식별자의 가장 흔한 형태. URL은 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 알려준다.
대부분 URL은 세 부분으로 이루어진 표준 포맷 따른다.
- scheme(스킴): http://
- www.naver.com
- /product/11
1.3.4 URN
uniform resource name URN. 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향 받지 않는 유일무이한 이름 역할. 이 위치 독립적인 URN 은 리소스를 여기저기 옮기더라도 문제없이 동작한다.
예를 들어, 다음의 URL은 인터넷 표준문서 RFC 2141가 어디에 있거나 상관없이(심지어 여러 군데 복사되었어도) 그것을 지칭하기 위해 사용가능하다.
urn:ietf:rfc:2141
아직 실험중인 상태고 아직 널리 채택되지않았다. 효율적인 리소스 위치 분석위한 인프라 지원이 필요한데 이런것이 부재하기 때문이다.
특별한 언급이 없다면 이 책에서는 통상적 관계 따라 URI와 URL을 같은의미로 쓴다.
1.4 트랜잭션
HTTP 트랜잭션은 요청 명령과 응답 결과로 구성되어있다. 이 상호작용은 HTTP 메시지라 불리는 정형화된 덩어리를 활용한다.
1.4.1 메서드
HTTP 는 여러 가지 종류의 요청 명령을 지원한다.
- GET
- 서버에서 클라이언트로 지정한 리소스 보내라
- PUT
- 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라.
- DELETE
- 지정한 리소스를 서버에서 삭제하라.
- POST
- 클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라.
- HEAD
- 지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라.
1.4.2 상태 코드
- 200
- 좋다. 문서가 바르게 반환되었다.
- 302
- 다시 보내라. 다른 곳에 가서 리소스 가져가라.
- 404
- 없음. 리소스 찾을 수 없다.
1.4.3 웹페이지는 여러 객체로 이루어질 수 있다
웹브라우저는 시각적으로 풍부한 웹페이지를 가져올 때 대량의 HTTP 트랜잭션을 수행한다. 웹페이지는 여러 웹 서버 리소스의 모음이다.
1.5 메시지
http 메시지는 단순한 줄 문자열. 이진 형식이 아닌 일반 텍스트이기에 사람이 읽고 쓰기 쉽다.
시작줄
요청이라면 무엇을 해야하는지 응답이라면 무슨 일이 일어났는지 나타낸다.
헤더
시작줄 다음에는 0개 이상의 헤더 필드가 이어진다. 각 헤더 필드는 쉬운 구문분석을 위해 쌍점(:)으로 구분되어 있는 하나의 이름과 하나의 값으로 구성된다. 헤더는 빈 줄로 끝난다.
본문
빈 줄 다음에는 어떤 종류의 데이터든 들어갈 수 있는 메시지 본문이 필요에 따라 올 수 있다. 문자열이며 구조적인 시작줄이나 헤더와 달리, 본문은 임의의 이진 데이터를 포함할 수 있다.(이미지, 비디오, 오디오, 응용소프트웨어)
1.5.1 간단한 메시지 예
1.6 TCP 커넥션
⭐️⭐️⭐️
어떻게 메시지가 TCP 커넥션으로 한 곳에서 다른 곳으로 옮겨가는지 알아보자.
1.6.1 TCP/IP
HTTP는 애플리케이션 계층의 프로토콜이다. http는 네트워크 통신의 핵심적인 세부사항에 신경 쓰지 않는다. 대신 세부사항은 대중적이고 신뢰성있는 인터넷 전송 프로토콜인 TCP/IP에 맡긴다.
TCP는 다음을 제공한다.
- 오류 없는 데이터 전송
- 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다)
- 조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)
인터넷 자체가 전 세계 컴퓨터와 네트워크 장치들 사이에서 대중적으로 사용되는 TCP/IP에 기초한다. TCP/IP는 TCP와 IP가 층을 이루는, 패킷 교환 네트워크 프로토콜의 집합이다. TCP/IP는 각 네트워크와 하드웨어 특성 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통하게 해준다.
일단 TCP 커넥션이 맺어지면 클라이언트와 서버간에 교환되는 메시지가 없어지거나, 손상되거나, 순서가 바뀌어 수신되는 일은 결코 없다.
네트워크 개념상 http는 tcp 위의 계층이다. http는 자신의 메시지 데이터를 전송하기 위해 tcp를 쓴다. 이와 유사하게 tcp는 ip 위의 계층이다.
1.6.2 접속, IP 주소 그리고 포트번호
http 가 메시지 전송할 수 있게하기위해, 인터넷 프로토콜(IP) 주소와 포트번호로 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야한다.
TCP에서는 서버 컴퓨터에 대한 IP 주소와 그 서버에서 실행 중인 프로그램이 사용 중인 포트번호가 필요하다.
http 서버의 ip 주소와 포트번호를 어떻게 알아 낼 수 있을까? URL을 쓰면된다. URL은 리소스에대한 주소. 따라서 URL은 그 리소스를 가지고 있는 장비에 대한 IP 주소를 알려줄 수 있다.
- http://207.12.44.12:80/index.html
- http://www.kojfr.com:80/index.html
- http://www.kojfr.com/index.html
첫 번째는 IP주소와 포트번호 가지고있다.
두 번째는 숫자로된 IP 주소가 없다. 대신 글자로 된 도메인 이름 혹은 호스트명을 가지고 있다. 호스트 명은 IP 주소에 대한 이해하기 쉬운 형태의 별명이다. 호스트 명은 DNS(domain name service)라 불리는 장치를 통해 쉽게 IP로 변환될 수 있으므로 모든 준비는 끝난것.
마지막 URL에는 포트번호가 없다. HTTP URL에 포트번호가 빠진경우에는 기본값 80이라 보면된다.
다음은 IP주소, 포트번호, TCP/IP 로 어떻게 http가 통신하는지 간단히 묘사하고 있는것이다.
- 웹브라우저는 서버의 url에서 호스트 명을 추출한다.
- 웹브라우저는 서버의 호스트 명을 ip로 변환한다.
- 웹브라우저는 url 포트번호(있다면)를 추출한다.
- 웹브라우저는 웹 서버와 tcp 커넥션 맺는다
- 웹브라우저는 서버에 http 요청 보낸다
- 서버는 웹브라우저는 http 응답 돌려준다
- 커넥션이 닫히면, 웹브라우저는 문서를 보여준다.
1.6.3 텔넷(Telnet)을 이용한 실제 예제
HTTP는 tcp/ip를 쓰며, 문자열 기반이라서 웹 서버와 직접 대화하는 것도 간단하다.
텔넷 유틸리티는 당신의 키보드를 목적지의 tcp포트로 연결해주고 출력 tcp 포트를 당신의 화면으로 연결해준다. 텔넷은 원격 터미널 세션을 위해 흔히 사용되지만 http 서버를 포함함 일반적인 tcp 서버에 연결하기 위해 사용될 수도 있다.
웹 서버와 대화하기 위해 텔넷을 쓸 수 있다. 텔넷은 직접 컴퓨터의 포트로 TCP 커넥션 연결해서 그 포트로 글자를 타이핑해 넣을 수 있게 해준다. 웹 서버는 나를 웹 클라이언트처럼 취급하고, tcp 커넥션을 통해 돌려주는 데이터는 화면에 출력된다.
텔넷으로 상호작용 예시
- 우선 우리는 www.haha.com IP 주소 찾아 그 컴퓨터의 80번 포트로 tcp 커넥션 맺어야한다. 이건 텔넷이 대신 해줄 것이다.
- 일단 tcp 커넥션이 되면, 우리는 http 요청을 타이핑해서 입력해야한다.
- 요청이 완료되면(빈 줄을 입력하면 완료됨), 서버는 컨텐츠를 http 응답에 담아 반환 후 커넥션을 끊을 것이다.
telnet www.haha.com 80
~~
GET /tools.html HTTP/1.1
Host: www.haha.com텔넷보다 유용한 도구로 nc(netcat)을 검토해 볼 수 있다. nc는 http, udp, tcp 기반의 트래픽을 조작하고 스크립트할 수 있게 해준다.
1.7 프로토콜 버전
HTTP/0.9
1991년 http 프로토타입. 심각한 디자인 결함 다수 있고 구식 클라이언트와만 통신 가능하다. 오직 GET 만 지원, 멀티미디어 콘텐츠에 대한 MIME 타입이나, HTTP header, version 번호는 지원않는다. 금방 1.0으로 대체됨.
HTTP/1.0
1.0은 처음으로 널리 쓰인 버전. 버전 번호, HTTP 헤더, 추가 메서드, 멀티미디어 객체 처리를 추가했다. HTTP/1.0은 시각적으로 매력적인 웹페이지와 상호작용하는 폼을 실현했고 이는 WWW을 대세로 만들었다. 1.0은 결코 잘 정의된 명세가 아니었다. HTTP가 상업적, 학술적으로 급 성장하던 시기에 만들어진, 잘 동작하는 용례들의 모음에 가깝다.
HTTP/1.0+
1990년대 중반, WWW가 급격히 팽창하고 상업적으로도 성공하면서 여러 유명 웹 클라이언트와 서버들은 그에 따른 요구 충족시키기 위해 HTTP에 기능을 추가해나갔다. 오래 지속되는 keep-alive connection, 가상 호스팅 지원, 프락시 연결 지원을 포함해 많은 기능이 공식은 아니지만 사실상의 표준으로 HTTP 에 추가되었다.
HTTP/1.1
1.1은 http 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중했다. 뿐만 아니라 1.1은 더 복잡해진 웹 애플리케이션과 배포를 지원한다. 1.1은 현재(아마 2014언저리인듯?)의 http 버전이다.
HTTP/2.0
HTTP/2.0은 2015년에 공식 발표된 HTTP의 차세대 버전으로, 웹 성능의 근본적 개선에 집중했다. Google의 SPDY 프로토콜을 기반으로 개발되었으며, HTTP/1.1의 의미론적 호환성을 유지하면서도 전송 계층을 완전히 재설계했다.
주요 혁신사항
- 바이너리 프레이밍: 텍스트 기반에서 바이너리 프로토콜로 전환하여 파싱 효율성과 보안성을 크게 향상시켰다
- 멀티플렉싱: 단일 TCP 연결에서 여러 요청/응답을 병렬로 처리하여 Head-of-Line Blocking 문제를 해결했다
- 서버 푸시: 서버가 클라이언트 요청 전에 필요한 리소스를 미리 전송할 수 있어 페이지 로딩 속도가 획기적으로 개선되었다
- 헤더 압축: HPACK 알고리즘으로 중복 헤더를 압축하여 대역폭을 절약했다
- 우선순위 지정: 리소스별 중요도를 설정하여 더 스마트한 로딩이 가능해졌다
HTTP/2.0은 모바일과 고성능 웹 애플리케이션 시대에 맞춰 설계되었으며, 복잡한 SPA(Single Page Application)와 실시간 웹 서비스의 성능 요구사항을 충족시키는 현대적 프로토콜이다. 기존 HTTP/1.1 대비 페이지 로딩 속도를 30-50% 향상시키며, 특히 레이턴시가 높은 모바일 환경에서 그 효과가 두드러진다.
1.8 웹의 구성요소
이 절에서는 인터넷과 상호작용 할 수 있는 다음을 포함한 여러 애플리케이션에 대해 간략히 다룰것이다.
프락시
클라이언트와 서버 사이에 위치한 http 중개자
캐시
많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 http 창고
게이트웨이
다른 애플리케이션과 연결된 특별한 웹 서버
터널
단순히 http 통신을 전달하기만 하는 특별한 프락시
에이전트
자동화된 http 요청을 만드는 준지능적(semi-intellignet) 웹클라이언트
1.8.1 프락시
웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소인 HTTP 프락시 서버.
프락시는 클라와 서버 사이에 위치하여, 클라의 모든 http 요청 받아서 서버에 전달한다(대개 요청을 수정한 뒤에). 이 애플리케이션은 사용자를 위한 프락시로 동작하며 사용자를 대신해서 서버에 접근한다.
프락시는 주로 보안을 위해 사용된다. 즉, 모든 웹 트래픽에서 신뢰할 만한 중개자 역할을 하는 것이다. 또한, 요청과 응답을 필터링한다. 예를 들어 회사에서 무언가를 다운 받을 때 바이러스를 검출하거나 특정 사이트를 차단하는 등의 일을 한다.
1.8.2 캐시
웹 캐시와 캐시 프락시는 자신을 거쳐가는 문서 중 자주 찾는 것의 사본을 저장해 두는, 특별한 종류의 HTTP 프락시 서버.
1.8.3 게이트웨이
게이트웨이는 다른 서버들의 중개자로 동작하는 특별한 서버. 게이트웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 게이트웨이는 자기가 리소스를 가진 진짜 서버처럼 요청을 다룬다. 클라는 자신이 게이트웨이와 통신하는지 모른다.
HTTP/FTP 게이트웨이는 FTP URI 에 대한 http 요청을 받아들인 뒤, FTP 사용해서 문서를 가져온다. 받아온 문서는 http 메시지에 담겨 클라에 보낸다.
1.8.4 터널
터널은 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 http 애플리케이션. http 터널은 주로 비 http 데이터를 하나 이상의 http 연결을 통해 그대로 전송해주기 위해 사용된다.
http 터널 활용 예로, 암호화된 ssl 트래픽을 http 커넥션으로 전송함으로 써 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 것이 있다. 그림과 같이, 우선 HTTP/SSL 터널은 http 요청을 받아들여 목적지의 주소와 포트번호로 커넥션을 맺는다. 이후부터는 암호화된 SSL 트래픽을 http 채널을 통해 목적지 서버로 전송할 수 있게 된다.
1.8.5 에이전트
사용자 에이전트는 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램. 웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트다. 지금까지 우리는 한 가지 종류의 HTTP 에이전트인 웹브라우저에 대해서만 이야기 했다. 그러나 다른 종류가 더 있다.
예를 들어, 사람의 통제 없이 스스로 웹 돌아다니며 HTTP 트랜잭션을 일으키고 콘텐츠를 받아오는 자동화된 사용자 에이전트가 있다. 이것들 이름은 보통 스파이더나 웹로봇 같이 다채로운 이름을 갖고 있다. 스파이더는 웹 돌아다니며 검색엔진을 위한 디비나 가격비교 로봇을 위한 제품 카탈로그 같은 유용한 웹 콘텐츠 보관소를 만든다.