2.간단한 프로토콜 HTTP

2.1,2 HTTP는 클라이언트와 서버 간 통신을 한다.

• HTTP 프로토콜에서는 반드시 한쪽이 클라이언트(request) 다른 한 쪽은 서버(response)역할을 담당
• 클라이언트측에서 먼저 통신이 시작 -> request가 있어야 response가 있음

 

<클라이언트의 request 메세지>

• GET : 서버에 요구하는 종류 == 메소드
• /index.html : request URI(요구대상) == 리소스
• HTTP/1.1 : 클라이언트 기능 식별 == HTTP 버전 번호

- 다른예시

POST(메소드) /form/entry(URI) HTTP/1.1(프로토콜 버전)
Host: hackr.jp (리퀘스트 헤더 필드)
Connection: keep-alive (리퀘스트 헤더 필드)
Content-Type: application/x-www-form-urlencoded (리퀘스트 헤더 필드)
Content-Length: 16 (리퀘스트 헤더 필드)

name=ueno&age=37 (엔티티)

<서버의 response 결과>

• HTTP/1.1 은 프로토콜 버전, 200 OK 는 상태 코드와 상태 코드의 설명(프레이즈),
   2~4번째 줄은 리스폰스 헤더 필드
  그 후 한줄로 구분되어 응답 바디(html~)가 시작된다.

 

2.3 HTTP는 상태를 유지하지 않는 프로토콜

     --> stateless 프로토콜 이다.

• HTTP 프로토콜 독자적으로 request와 response를 교환하는 동안에 상태를 관리하지 않는다.
• 결국 HTTP 프로토콜 레벨에서는 이전에 보냈던 request나 이미 돌려준 response에 대해서 전혀 기억하지 않는다.
• HTTP에서는 새로운 request가 보내질때마다 새로운 response가 생성된다.
  ->많은 데이터를 매우 빠르고 확실하게 처리하는 범위성을 확보하기 위해 간단히 설계한 것 이다.
• 그러나 웹이 진화함에 따라 stateless 특성만으로 처리하기 어려운 일이 증가함
  ex) 쇼핑 사이트 로그인 했을때 다른 페이지로 이동하더라도 로그인 상태를 유지해야함
        ->이를 위해 누가 어떤 request를 보냈는지 파악하기 위해 상태를 유지할 필요가 있다.
• HTTP /1.1은 상태를 유지하지 않는 프로토콜임
• 상태를 계속 유지하기 위해 쿠키가 도입됨

 

 

2.4 리퀘스트 URI로 리소스를 식별

• HTTP는 URI를 사용하여 인터넷 상의 리소스를 지정한다
• 모든 URI를 리퀘스트 URI에 포함한다.

GET http://hackr.jp/index.htm HTTP/1.1

• Host 헤더 필드에 네트워크 로케이션을 포함한다.

GET /index.html HTTP/1.1
Host: hackr.jp

• 특정 자원이 아닌 서버를 대상으로 리퀘스트 송신
  이러한 경우 경우 리퀘스트 URI에 * 를 지정할 수 있다. 아래는 HTTP 서버가 지원하는 메소드를 묻는 예시이다.

OPTIONS * HTTP/1.1

 

 

2.5 서버에 임무를 부여하는 HTTP/1.1 메소드

 

◆GET : 리소스 획득

• request  URI로 식별된 리소스를 가져올 수 있도록 요구
• 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과
• 결국 리소스가 텍스트이면 그대로 반환하고 GGI와 같은 프로그램이면 실행해서 출력된 내용을 돌려줌
• "너가 가지고 있는 걸 갖고 싶어"

▷GET 메소드를 사용한 request , response 예

request	GET /index.html HTTP/1.1 Host: www.hackr.jp
response	index.html 리소스를 반환

request	GET /index.html HTTP/1.1 Host: www.hackr.jp   If-Modified-Since: Thu, 12 JUL 2012 07:30:0 GMT
response	Index.html 리소스가 지정한 일시(If-Modified-Since) 이후에 갱신된 경우에만 리소스를 반환 아니라면 상태 코드 304 Not Modified 리스폰스 반환

 

 

◆POST : 엔티티 전송

"엔티티를 전송한다"는 것은 요청의 본문(body)에 데이터를 포함하여 서버로 전송한다는 의미이다.

(엔티티:클라이언트와 서버 간에 주고받는 데이터)

• GET으로도 전송할 수 있지만 자주 사용하지 않음
• "이 정보를 너에게 알려줄게"

▷POST 메소드를 사용한 request , response 예

request	POST /submit.cgi HTTP/1.1 Host: www.hackr.jp Content-Length: 1560
response	submit.cgi가 수신한 데이터를 처리한 결과를 반환

 

---

GET, POST 차이점

Client : 인터넷 브라우저 주소창에 URL을 입력 --> Server : Client의 요청에 응답을 하여 웹페이지를 보여줌.

이때 Client가 Server로 보내는 데이터를 HTTP 패킷이라 하며
HTTP 패킷은 크게 Header와 Body로 나눠진다.

Header에는 HTTP Method 방식, 클라이언트와 브라우저, 접속하고자 하는 URL data 등등이 담겨있고
Body는 보통 비어있으며 정보를 담아서 서버에 요청할 수 있다.

파라미터(?뒤)가 Header에 붙을지, Body에 붙어서 갈 것인지

 

GET

어떠한 정보를 가져와서 조회하기 위해서 사용되는 방식
- 주소창에 파라미터(정보) 노출하여 서버에 전송
-> data가 Header있기 때문에 열람 가능, 보안 취약
- 전송하는 data양에 한계(브라우저마다 get 요청 길이 제한 존재)
- 브라우저 히스토리 기록 남음, 캐싱 가능(빠르게 접근하기 위해 레지스터에 데이터 저장)

POST

데이터를 서버로 제출하여 추가 또는 수정하기 위해서 사용하는 방식 -( 값이나 상태변경하는 글쓰기,수정에 적합)
- data가 url에 표시되지 않고 HTTP 패킷 Body에 있기 때문에 열람 불가
-> data양에 제한이 없어 대용량 데이터를 전송할때 적합
- 보안이 좋지만 결국 개발자 도구로 요청 내용 확인할 수 있으므로 암호화 해줘야한다.

 

 

---

 

 

 

◆PUT : 파일 전송

• FTP에 의한 파일업로드 같이 request 중에 포함된 엔티티를 requust url로 지정한 곳에 보존하도록 요구함
• 단지 HTTP/1.1의 PUT 자체에는 인증 기능이 없기 때문에 보안 상의 이유로 일반적인 웹 사이트에서는 사용되지 않음
• 웹 어플리케이션 등에 의한 인증기능과 짝을 이루는 경우나
• REST(Representational State Transfer)와 같이 웹끼리 연계하는 설계 양식을 사용할 때 이용함
• "이 파일을 너에게 줄게"

▷PUT 메소드를 사용한 request , response 예

request	PUT /example.html HTTP/1.1 Host: www.hackr.jp Content-type: text/html Content-Length: 1560
response	상태 코드 204 No Content 리스폰스 반환(실패) 상태에 맞는 코드가 반환될것이다.

 

 

◆HEAD: 메세지 해더 취득

• GET과 같은 기능, 메세지 바디는 돌려주지 않음
• URI 유효성 및 리소스 갱신 시간을 확인하는 목적

▷HEAD 메소드를 사용한 request , response 예

request	HEAD /index.html HTTP/1.1 Host: www.hackr.jp
response	index.html에 관련된 response 헤더를 반환

 

 

◆DELETE : 파일 삭제

• PUT메서드와 반대로 동작

▷예

request	DELETE /example.html HTTP/1.1 Host: www.hackr.jp
response	상태에 맞는 코드가 반환

 

 

◆OPTIONS : 제공하고 있는 메소드의 문의

• requust url로 지정한 리소스가 제공하고있는 메소드를 조사하기위해 사용

▷예

request	OPTIONS * HTTP/1.1 Host: www.hackr.jp
response	HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS (서버가 제공하고 있는 메소드)

 

 

◆TRACE : 경로 조사

• 웹 서버에 접속해서 자신에게 통신을 되돌려받는 루프백(loop-back)을 발생시킴
• request를 보낼때 Max-Forwards 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 수치를 줄이고,
  0이 될 때 마지막으로 수신한 곳에서 상태 코드 200 OK response를 반환
• 클라이언트는 request를 보낸 곳에 어떤 것이 가공되어 있는지 조사 가능
• 보안문제로 안씀

▷예

request	TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2
response	HTTP/1.1 200 OK Content-Type: message/http Content-Length: 1024 TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards: 2 (리퀘스트 내용을 리스폰스에 포함)

 

 

◆CONNECT : 프록시에 터널링 요구

• 프록시에 터널 접속 확립을 요함으로써 TCP 통신을 터널링
• SSL과 TLS 등의 프로토콜로 암호화된 것을 터널링시키기 위해 사용

▷예

request	CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp
response	HTTP/1.1 200 OK (이후 터널링 개시)