CH6
HTTP란 hypertext 전송용 프로토콜이지만 hypertext인 HTML과 XML뿐만 아니라 이미지, 동영상, JavaScript 프로그램, 등 모든 컴퓨터 데이터를 전송 할 수 있다.
HTTP는 Rest 기반인 Uniform 인터페이스, stateless 서버, 캐시 등을 구현 하는 Web 기반이 되는 프로토콜이다.
HTTP는 TCP/IP(Transmission Control Protocol/Internet Protocol) 기반으로 한다. 이것은 인터넷이 따르는 네트워크 프로토콜이다.
TCP/IP는 계층형 프로토콜 구조를 가지고 있다
네트워크 인터페이스 계층 - 물리적인 케이블 등.
인터넷 계층 - 네트워크에서 데이터를 주고받는 부분. 패킷 단위로 주고받아서 통신함.
트랜스포트 계층 - 데이터 무결성 확인 및 커넥션 보조. 소켓을 이용해서 클라이언트와 서버 연결함
애플리케이션 계층 - 인터넷 애플리케이(메일, http 등) 구현
TCP/IP |
---|
애플리케이션 계층 (HTTP, NTP, SSH, SMTP, DNS) |
트랜스포트 계층(UDP, TCP) |
인터넷 계층 (IP) |
네트워크 인터페이스 계층 (이더넷) |
웹은 클라이언트/서버 아키텍처를 가지고 있다. client에서 request를 보내고 server에서 respond를 보내는 구조다. 이런 구조를 요청/응답형(request-response style)이라고 정의한다.
http는 클라이언트가 서버에서 응답을 받기 전까지 기다린다. 고로 동기형 Synchronous 이다.
클라이언트와 서버에서 일어나는 구도.
- 요청 메시지 구축
- 요청 메시지 송신
- (응답이 돌아올 때까지 대기)
- 응답 메시지 수신
- 응답 메시지 해석
- 클라이언트의 목적을 달성하기 위해 필요한 처리
서버 측
- (요청을 대기)
- 요청 메시지 수신
- 요청 메시지 해석
- 적절한 애플리케이션 프로그램으로 처리를 위임
- 애플리케이션 프로그램으로 부터 결과를 취득
- 응답 메시지 구축
- 응답 메시지 송신
클라이언트 | 서버 | |||
---|---|---|---|---|
요청 메시지 구축 | (요청을 대기) | |||
요청 메시지 송신 | (요청을 대기) | |||
(응답이 돌아올 때까지 대기) | 요청 메시지 수신 | |||
(응답이 돌아올 때까지 대기) | 요청 메시지 해석 | |||
(응답이 돌아올 때까지 대기) | 적절한 애플리케이션 프로그램으로 처리를 위임 | |||
(응답이 돌아올 때까지 대기) | 애플리케이션 프로그램으로부터 결과를 취득 | |||
(응답이 돌아올 때까지 대기) | 응답 메시지 구축 | |||
(응답이 돌아올 때까지 대기) | 응답 메시지 송신 | |||
응답 메시지 수신 | (요청을 대기) | |||
응답 메시지 해석 | (요청을 대기) | |||
클라이언트의 목적을 달성하기 위해 필요한 처리 | (요청을 대기) |
이 되겠다.
요청 메시지와 응답 메시지를 합해서 HTTP 메시지라고 부른다.
요청 메시지
GET/test HTTP/1.1
<!-- requestline with GET method, /test URI, version 1.1 -->
Host: example.com
요청 메시지 둘째 줄부터는 헤더 메타 데이터입니다. 헤더의 기본 구성은 ‘이름:값’ 이다. 그 후에 들어가는 건 바디 다. 바디는 그 메시지를 나타내는 본질적인 정보가 들어가 있다.
응답 메시지
HTTP/1.1 200 OK
<!-- 스테이터스 라인 with 1.1 protocol version, statuscode 200, text OK -->
content-Type: application/xhtml+xml; charset=utf-8
<!-- header with html MIME midea type application.xhtml+xml and utf-8 encoding -->
<html xmlns="http://www.w3.org/1999/xhtml">
....
</html>
status code는 요청 결과를 프로그램으로 처리 가능한 수치로 표현한 것 이다.
응답 두 번째 줄부터 헤더다.
HTTP 구조 |
---|
스타트 라인 |
헤더 |
빈칸 |
바디 |
헤더의 끝을 빈 줄로 인식하므로 잊지 말 것. 바디는 생략할 수 있다.
스테이트레스, 스테이트풀
웹에서 스테이트레스는 클라이언트가 요청 한 것들을 서버가 기억을 안 한다. 스테이트풀은 반대로 요청한 것을 다 기억하는 기능이다. 스테이트풀로 할 경우에는 주고받는 게 간결 해질 수도 있지만 접속하는 클라이언트가 많으면 그만큼 서버가 필요하고 그 서버 간에 동기화도 필요해서 확장이 힘들다. 스테이트레스는 저장하는 게 없음으로 확장성이 뛰어나다. 결국엔 심플함으로 만들어서 이제까지 잘 쓰이고 있다.
ch7 HTTP 메서드
HTTP 메서드로 서버에게 클라이언트가 하고 싶은 처리를 전달한다.
메서드 | 의미 | 성질(crud) |
---|---|---|
get | 리소스 취득 | read |
post | 서브 리소스 작성, 데이터 추가 등 | create |
put | 리소스 갱신, 리소스 작성 (전체 수정) | create/update |
delete | 리소스 삭제 | delete |
head | 리소스의 헤더 취득 | |
options | 리소스가 서포트하는 메서드 취득 | |
trace | 자기 앞으로 요청 메시지를 반환 시험 | |
connect | 프록시 동작의 터널 접속으로 변경 | |
patch | 부분 수정 | update |
HTTP 메서드 중에 CRUD(Create Read Update Delete) 성질을 띠는 것들을 많이 사용한다.
이러한 메서드들 덕분에 URI가 Uniform Interface 유지가 가능했다.
헤더에 조건부 요청을 넣어서 실행 여부를 구성 할 수 있다. 예를 들어서 if-modified-since 을 하면 헤더가 작성했을 때부터 현재까지 수정 부분 있으면 실행하는 것이다.
멱등성과 안전성 이러한 메서드들을 멱등성과 안전성으로 구분해서 쓰기도 한다. 멱등성(idempotence)이란 입력이 같을때 출력이 같은 것이다. 안전성(safe)은 리소스에 변화를 주지 않는 것이다.
메서드 | 성질 | |
---|---|---|
get, head | 멱등이고 안전하다 | |
put, delete | 멱등이지만 안전하지 않다 | |
post, patch | 멱등도 아니고 안전하지도 않다 |
이러한 메서드들로 rest의 통일된 인터페이스를 구축하고 심플한 프로토콜을 유지한다.
ch8 스테이터스 코드
위에서 말했듯이 status code는 요청 결과를 프로그램으로 처리 가능한 수치로 표현한 것 이다. 스테이터스 코드의 종류들은 이러하다.
1xx : 처리 중
2xx : 성공
3xx : 리다이렉트
4xx : 클라이언트 에러
5xx : 서버 에러
이러한 숫자를 받음으로써 클라이언트가 어떻게 처리해야 할지 알게 된다.
자주 쓰는 스테이터스 코드
200 OK
스테이터스 코드 | 의미 |
---|---|
200 OK | 요청 성공 |
201 Created | 리소스 작성 성공 |
301 Moved Permanently | 리소스 항구적인 이동 |
303 See Other | 리다이렉트 |
400 Bad Request | 요청 구문이나 파라미터 에러 |
401 Unauthorized | 접근 권한 없음, 인증 실패 |
404 Not Found | 리소스 없음 |
500 Internal Server Error | 서버 에러 |
503 Services Unavailabe | 서비스 중지 |
스테이터스 코드들을 올바르게 역할별로 사용해야 한다. 이것은 아주 중요한 설계 검토 사항이다.
참고로 스테이터스 코드의 구체적인 구현방법은 웹서비스와 프레임워크에 따라 달라진다.
ch 9 HTTP 헤더
헤더는 메시지의 바디에 대한 부가적인 정보, 즉 메타 데이터를 표현한다. 클라이언트와 서버는 헤더를 보고 메시지에 대한 동작을 결정한다. 예를 들어서 캐시나 인증 등은 헤더를 써야지만 구현이 가능하다.
헤더의 종류. 날짜 시간, content type, charset 파라미터, 언어, 콘텐트 네고시에이션, content length, 인증, 캐시, 지속적 접속, content disposition 등이 있다
날짜 시간은 메시지 생성한 일시, 응답을 캐시 할 수 있는 기한 등을 가지고 있다.
content type 는 미디어 타입(MIME)을 결정한다.
Content-Type:application/xhtml+xml; charset=utf-8
<!-- type/subtype -->
charset 은 문자 인코딩 방식을 지정한다.
언어는 자연언어를 지정하는 헤더다.
Content-Language: ko-KR
콘텐트 네고시에이션은 언어의 우선순위를 지정한다
Accept-Language: ko; q=1.0, en; q=0.5
<!-- 한국어 1순위 영어 2순위 -->
content length 바디의 길이를 지정한다. 이것을 분할(chunk)로 보낼 수도 있다
인증은 말 그대로 인증하기 위한 키들의 헤더이다. 인증 방식은 많다. basic, digest, https, OAuth 등. 요즘은 OAuth(Open Authentication) 2.0 을 쓴다. 이것은 제3자 앱에 제공 없이 인증 할 수 있는 프로토콜이다.
캐시 - 는 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용하는 방법이다.
헤더에 cache를 지정할 때 Pragma나 Expires나 두 기능 다 있는 Cache-Control 쓰면 된다. Pragma 는 no-cache 만 쓸 수 있고 Expires는 말 그대로 유효기한 설정해준다. Cache-Control은 둘 다 할 수 있다. 또한 조건부 get인 if-modified로 유효기한 갱신 그리고 eTag로 갱신 상태 비교 등을 써서 유효기한을 변경할 수 있다.
지속적 접속 - http 1.1 에서부턴 지속 접속 기능이 있는 pipeline 화 돼 있어서 커넥션을 끊고 싶을 때 Connection:close 헤더를 쓰면 된다.
content disposition- 리소스 파일명을 제공해주는 헤더이다.
이러한 헤더들을 이용해서 HTTP의 주요 기능들을 구현할 수 있다.
ch 10
HTML(Hypertext Markup Language)란 태그로 문서의 구조를 표현하는 컴퓨터 언어다. 이러한 구조를 가지는 문서를 구조화 문서라고 한다.
HTML 미디어 타입은 application/xhtml+xml 이다.
xml은 요소로 문서의 구조를 나타낸다. start tag, content, endtag. 이 요소들은 중첩하여 표현한다. 또한 빈 요소로도 쓸 수 있다. 이 요소들은 속성을 여러 개가질 수 있다. 어떤 문자들은 명령어로 지정되어 있어서 Unicode 로 지정해서 문자들을 작성해야 한다. 이것을 escaping이라고도 한다.
복수의 XML 포맷을 조합할 때 이름의 충돌을 방지할 목적으로 Namespace를 쓴다. 예를들어서
<link rel= "stylesheet">
<qwe:link rel = "enclosure">