'웹을 지탱하는 기술' 2회차 스터디 정리
December 28, 2019
HTTP
- HTTP : 웹에서 오가는 리소스의 표현을 클라이언트와 서버 사이에서 주고받기 위한 프로토콜
6. HTTP의 기본
- TCP/IP를 베이스로 한 프로토콜
어플리케이션 계층
- 구체적인 인터넷 어플리케이션, 메일, DNS, HTTP 실현하는 계층
- 소켓을 이용하여 HTTP서버와 브라우저 구현
- 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속, 송신, 수신, 절단등의 기능
HTTP의 버전
- HTTP 0.9 : 헤더가 없었음, 메서드는 GET뿐
- HTTP 1.0 : 헤더의 도입, GET 이외의 메서드 추가
- HTTP 1.1 : 채널 전송, Accept헤더에 의한 콘텐트 네고시에이션, 복잡한 캐시 컨트롤, 지속적 연결 기능 추가
요청과 응답
-
클라이언트에서 일어나는 일
- 요청 메시지 구축
- 요청 메시지 송신
- (응답이 돌아올 때까지 대기)
- 응답 메시지 수신
- 응답 메시지 해석
- 클라이언트의 목적을 달성하기 위해 필요한 처리
-
서버에서 일어나는 일
- (요청을 대기)
- 요청 메시지 수신
- 요청 메시지 해석
- 적절한 어플리케이션 프로그램으로 처리를 위임
- 어플리케이션 프로그램으로부터 결과를 취득
- 응답 메시지 구축
- 응답 메시지 송신
HTTP의 스테이트리스성
- 스테이트리스 : 서버가 클라이언트의 어플리케이션 상태를 보존하지 않는 것
- 스테이트풀 : 서버가 클라이언트의 어플리케이션 상태를 기억하는 것
- 어플리케이션 상태 : 세션 상태(시스템에 로그인하고 로그아웃할 떄까지 일련의 조각을 모아 세션이라고 함)
- 스테이트풀 결점 : 클라이언트의 수가 증가하면 오버헤드발생할 수 있음
- 스테이트리스 이점 : 단순한 서버 시스템
- 스테이트리스 결점 : 송신할 데이터 양이 많아짐, 인증,DB 등 서버에 부하가 걸리는 처리를 반복하면 퍼포먼스가 떨어짐
HTTP의 가장 큰 특징은 심플함이다. 덕분에 웹 서비스와 웹 API가 같은 프로토콜로 실현될 수 있다.
7. HTTP 메서드
| 메서드 | 의미 |
|---|---|
| GET | 리소스 획득 |
| POST | 서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리 |
| PUT | 리소스 갱신, 리소스 작성(전체수정) |
| PATCH | 리소스의 부분적인 수정 |
| DELETE | 리소스 삭제 |
| HEAD | 리소스의 헤더(메타데이터) 취득 |
| OPTIONS | 리소스가 서포트하는 메서드의 취득 |
| TRACE | 자기 앞으로 요청 메시지를 반환 시험 |
| CONNECT | 프록시 동작의 터널 접속으로 변경 |
- GET, POST, PUT, DELETE는 CRUD 성질을 충족시킴
- CRUD(Create, Read, Update, Delete)
멱등성과 안정성
- 멱등성 : 어떤 조작을 몇 번을 반복해도 결과가 동일한 것
- 안정성 : 조작 대상의 리소스의 상태를 변화시키지 않는것
| 메서드 | 성질 |
|---|---|
| GET, HEAD | 멱등이고 안전하다 |
| PUT, DELETE | 멱등이지만 안전하지 않다 |
| POST | 멱등이지도 안전하지도 않다 |
웹의 성공이유는 HTTP 메서드에 있다. 메서드를 한정하여 고정시켰기 때문에 프로토콜이 심플하게 유지될 수 있었다.
8. 스테이터스 코드
- 스테이터스 라인 : 응답 메시지의 첫째 줄에 있는 프로토콜 버전, 스테이터스 코드, 텍스트 프레이즈로 이루어집니다.
| 분류 | 의미 |
|---|---|
| 1xx : 처리중 | 처리가 계속되고 있음을 나타낸다. 클라이언트는 그대로 요청을 계속하던지 서버의 지시에 따라 프로토콜을 업데이트 하여 재전송한다 |
| 2xx : 성공 | 요청이 성공했음을 나타낸다 |
| 3xx : 리다이렉트 | 다른 리소스로의 리다이렉트를 나타낸다. 클라이언트는 이 상태코드를 받았을 때 응답메시지의 Location 헤더를 보고 새로운 리소스로 접속한다 |
| 4xx : 클라이언트 에러 | 클라이언트 에러를 나타낸다. 원인은 클라이언트의 요청에 있다. 에러를 해결하지 않는 한, 정상적인 결과를 얻을 수 없기 때문에 같은 요청을 그대로 재전송할 수는 없다 |
| 5xx : 서버 에러 | 서버 에러를 나타낸다. 원인이 서버에 있다. 서버 측의 원인이 해결되면, 동일한 요청을 재전송해서 정상적인 결과를 얻을 가능성이 있다 |
9. HTTP 헤더
- 헤더는 메시지의 바디에 대한 부가적인 정보, 즉 메타 데이터를 표현합니다.
날짜와 시간을 가지는 헤더
Date: Tue, 06 Jul 2010 03:21:05 GMT| 이용하는 메시지 | 헤더 | 의미 |
|---|---|---|
| 요청과 응답 | Date | 메시지를 생성한 일시 |
| 요청 | If-Modified-Sice | 조건부 GET으로 리소스의 갱신일시를 지정할 때 이용한다 |
| 요청 | If-Unmodified-Sice | 조건부 PUT, 조건부 DELETE로 리소스의 갱신일시를 지정할 때 이용한다 |
| 응답 | Expires | 응답을 캐시 할 수 있는 기한 |
| 응답 | Last-Modified | 리소스를 마지막으로 갱신한 일시 |
| 응답 | Retry-After | 다시 요청을 전송할 수 있는 일시의 기준 |
MIME 미디어 타입
- Multipurpose Internet Mail Extensions
- 메시지로 주고받는 리소스 표현의 종류를 지정하는 것
- Content-Type : 미디어 타입을 지정한다.
- EX) Content-Type: application/xhtml+xml
- charset 파라미터 : 문자 인코딩을 지정한다.
- EX) charset = utf-8
- Content-Language : 리소스 표현의 자연언어를 지정한다.
- EX) Content-Language: ko-KR
콘텐트 네고시에이션
- 미디어 타입, 문자 인코딩, 언어 태그는 서버가 일방적으로 결정하는 것뿐만 아니라, 클라이언트와 교섭해서 정할 수도 있습니다. 이 방법을 Content Negotiation이라고 합니다.
- Accept : 클라이언트가 자신이 처리할 수 있는 미디어 타입을 서버에 전달한다
- EX) Accept: text/html, application/xhtml+xml
- Accept-Charset : 클라이언트가 자신이 처리할 수 있는 문자 인코딩을 서버에 전달한다
- EX) Accept-Charset: EUC-KT;utf-8
인증
- Basic 인증 : 유저 이름과 패스워드에 의한 인증 방식. 유저 이름과 패스워드는 Authorization 헤더에 넣어 요청마다 전송한다.
- 유저 이름과 패스워드가 네트워크에 흘러다니기 때문에 보안에 좋지 않음 -> SSL, TLS, HTTPS 사용할것
- Digest 인증 : Basic인증보다 보안이 강화된 인증 방식. 메시지에 대해 해시함수를 적용한 해시값 사용
OpenId 와 OAuth
- OpenID : 구글, 페이스북 계정으로 다른 웹 서비스에 로그인 할 수 있음.
- OAuth : 웹 서비스 간 데이터 교환을 위한 스펙. JWT(token)
캐시
- 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용하는 방법
- 클라이언트가 저장한 캐시는 그 캐시의 ‘유효 기간’ 내에 다시 그 리소스에 접근하려고 했을 때 재사용 된다.
- 캐시에 대해서는 추가적인 공부가 필요
HTTP헤더를 제대로 사용하기 위해서는 이들의 역사와 실제 서버와 브라우저 구현 방식에 대해 조사할 수 있는 능력이 필요합니다
하이퍼미디어 포맷
10. HTML
- Hypertext Markup Language의 줄임말
- 마크업 언어 : 태그로 문서의 구조를 표현하는 컴퓨터 언어
- HTML : data를 웹상에 표현하기 위한 목적
- test/html : SGML 베이스의 HTML을 나타내는 미디어 타입
- application/xhtml+xml : XML 베이스의 XHTML을 나타내는 미디어 타입
- XML : 데이터 저장과 전송을 목적으로 만들어진 마크업 언어
