티스토리 뷰
1. HTTP 개관
웹 클라이언트와 서버
웹 서버는 웹 콘텐츠를 저장하고 있다. HTTP 프로토콜로 의사소통하기 때문에 HTTP 서버라고 한다.
웹 클라이언트로부터 HTTP 요청을 받으며, HTTP 응답을 돌려보내준다.
리소스
웹 서버는 웹 리소스를 관리하고 제공한다. (웹 콘텐츠와 같은 여러 정적, 동적 콘텐츠)
미디어 타입
수천 가지의 데이터 타입이 있기 때문에 , 이를 위해 HTTP는 객체 각각에 데이터 포맷 라벨을 붙인다.
MIME(Multipurpose Internet Mail Extensions) → 다목적 인터넷 메일 확장
기존에는 전자 메일 시스템 때문에 발명됨, 확장이 되어 HTTP 멀티미디어 콘텐츠에도 사용된다.
MIME 타입은 / 으로 구분되어 주 타입, 부 타입으로 이루어진 문자열 라벨이다.
- MIME 예시Content-type : image/jpeg → JPEG 이미지
- Content-type :image/gif → GIF 이미지
- Content-type : text/html → HTML 텍스트 문서
URI
웹 서버 리소스가 가지고 있는 식별자 (Uniform Resources Identifier, 통합 자원 식별자)
URL과 URN 두 가지로 구분된다.
URL(Uniform Resources Locator)
- 특정 서버의 한 리소스에 대한 구체적인 위치
- 표준 포맷
- scheme, 리소스에 접근하기 위해 사용되는 프로토콜, 보통 HTTP(http://)
- 서버의 인터넷 주소(www.chimhaha.net)
- 웹 서버의 리소스(/new)
- 세 부분으로 이루어진 표준 포맷 - 스킴://서버위치/경로
URN(Uniform Resources Name)
- 콘텐츠를 이루는 한 리소스에 대해, 위치 영향을 받지 않는 유일무이한 이름 역할
- 현재는 실험 중인 상태
트랜잭션
HTTP 트랜잭션 - 요청 명령 → 응답 결과로 구성, HTTP 메세지를 이용함
**메서드**
HTTP 메서드 - HTTP가 지원하는 여러 가지 종류의 요청 명령
자주 쓰이는 HTTP 메서드
상태 코드
모든 HTTP 응답 메시지는 상태 코드와 함께 반환된다.
클라이언트 요청에 대한 성공 혹은 추가 조치에 대한 상태가 나타나있는 코드
메시지
HTTP 메시지는 단순한 줄 단위의 문자열이다.
HTTP 메시지의 종류
- HTTP 요청 메시지 - 웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지
- HTTP 응답 메시지 - 웹 서버에서 웹 클라이언트로 보낸 HTTP 메시지
요청 메시지
응답 메시지
TCP 커넥션(Transmission Control Protocol, 전송 제어 프로토콜)
어떻게 메시지가 한 곳에서 다른 곳으로 옮겨가는가? →TCP 커넥션
TCP/IP
HTTP는 애플리케이션 계층 프로토콜, 네트워크 통신의 세부 사항은 고려하지 않는다.
TCP는 전송 계층 프로토콜로 다음과 같은 기능을 제공한다.
- 오류 없는 데이터 전송
- 순서에 맞는 전달(보낸 순서대로 도착)
- 조각나지 않는 데이터 스트림(원하는 크기만큼 보낼 수 있음)
접속, IP주소 그리고 포트번호
클라이언트가 서버에 메시지를 전송하기 위해서는 IP주소와 포트번호를 사용해 TCP/IP 커넥션을 맺어야 한다.
예로 들자면, IP주소는 아파트의 주소, 포트 번호는 아파트 몇 동 몇 호를 뜻하는 것이다.
보통 URL에 IP주소와 포트번호를 포함하고 있고, 없다면 이는 DNS를 사용하고 있는 것이다.
사진
프로토콜 버전
HTTP/0.9 - HTTP 프로토타입, 오직 GET 메서드만 지원, 금방 대체됨
HTTP/1.0 - 처음으로 널리 쓰임, 헤더, 추가 메서드, 멀티미디어 객체 처리 추가
HTTP/1.0+ - 오래 지속되는 “keep-alive” 커넥션, 가상 호스팅 지원, 프락시 연결 지원 등 많은 연길 지원
HTTP/1.1 - 구조적 결함과 성능 최적화, 잘못된 기능을 제거에 집중한 버전, 현재의 HTTP버전
HTTP/2.0 - 1.1의 성능 문제 개선을 위한 구글의 SPDY 프로토콜 기반 프로토콜
웹의 구성요소
프록시 → 6장
- 클라이언트와 서버 사이에 위치한 HTTP 중개자
- 주로 보안을 위해 사용한다.
- 요청과 응답을 필터링한다.
캐시 → 7장
- 많이 찾는 웹 페이지를 클라이언트 가까이에 보관하는 HTTP 창고
- 자주 찾는 것의 사본을 저장해두는 특별한 종류의 HTTP 프록시 서버
게이트웨이 → 8장
- 다른 애플리케이션과 연결된 특별한 웹 서버
- 다른 서버들의 중개자, HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용
터널
- 단순히 HTTP 통신을 전달하기만 하는 특별한 프록시
- 두 커넥션 사이 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션
에이전트
- 자동화된 HTTP 요청을 만드는 준지능적 웹 클라이언트
- 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그래
2. URL과 리소스
URL 문법
대부분의 URL은 9개의 부분으로 나뉘는 문법을 가지고 있다.
<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
- 스킴 - 리소스에 접근하는 프로토콜, http ftp 등등
- 사용자 이름 - 리소스에 접근하기 위한 사용자 이름(기본 - anonymous)
- 비밀번호 - 사용자의 비밀번호
- 호스트 - 리소스를 호스팅하는 서버의 호스트명,IP 주소
- 포트 - 리소스를 호스팅하는 서버가 열어놓은 포트번호
- 경로 - 서버 내 리소스가 어디에 위치하는지를 가르킴
- 파라미터 - 입력 파라미터를 기술하는 용도로 사용
- 질의 - 스킴에서 애플리케이션에 파라미를 전달하는데 사용
- 프래그먼트 - 리소스의 조각이나 일부분을 가리키는 이름
프래그먼트?
리소스의 특정 부분을 가리킬 수 있도록 리소스 내의 조각을 가리킬 수 있는 프래그먼트 컴포넌트
예를 들어 과일을 파는 http://www.gyu-fruit.com 사이트가 있다고 할 때
과일 정보를 담은 페이지는 http://www.gyu-fruit.com/fruits.html 이다.
이 과일 정보 전체를 시작 부분부터 보는 것 보다 내가 원하는 과일 banana 혹은 다른 과일부터 보려면
http://www.gyu-fruit.com/fruits.html#banana URL을 통해 banana부터 보여주게 된다.
단축 URL
- 상대 URL
- base URL을 기준으로 접근한다.
- 절대 URL
- 리소스에 접근하는데 필요한 모든 정보를 지닌다.
안전하지 않은 문자
어떤 인터넷 프로토콜을 사용하든 안전하게 전송될 수 있도록 URL을 설계해야 한다.
안전한 전송이란 정보가 유실될 위험 없이 URL을 전송한다는 의미다.
이를 위해 URL에서 사용할 수 있는 알파벳과 URL 인코딩 규칙을 정했다.
URL 문자 집합
URL에서는 US_ASCII 뿐만 아니라 US_ASCII에서 사용이 금지된 이스케이프 문자열도 사용할 수 있다.
→ 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높이기 위함
인코딩 체계
표현의 한계를 넘기 위해 안전하지 않은 문자들을 표현할 수 있는 방식을 고안했다.
안전하지 않은 문자를 % 로 시작해 ASCII 로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 교체
문자 제한
몇몇 문자는 URL 내에서 예약어로 되어있다.
선점되거나 사용이 제한된 문자들을 사용하지 않아야 한다.
스킴의 바다
- http - 사용자 이름, 비밀번호를 사용하지 않는 일반 URL 포맷의 HTTP 스킴
- 일반적으로 포트 생략하면 80
- https - http와 거의 같음, HTTP의 커넥션 양 끝단에서 암호화하는 보안 소켓 개층 사용
- Secure Sockets Layer, SSL 사용 포트는 443
- mailto - 이메일 주소를 가리킴, RFC 822에 기술된 문법을 사용
- ftp - FTP 서버에 파일을 받거나 올리는 용도
- rtsp - 실시간 스트리밍 프로토콜을 통해 읽을 수 있는 미디어 리소스 식별자
URL은 강력한 도구, 하지만 완벽한 도구는 아니다.
리소스의 위치가 변경된다면 URL은 더이상 의미가 없어진다.
가장 이상적인 방법은 위치가 아닌 실제 객체의 이름을 사용하는 것 → URN