2016년 11월 10일 목요일

HTTP 프로토콜

           No comments   


1.HTTP  프로토콜

-정의-
world-wide wep(www)에서 쓰이는 핵심 프로토콜로 오늘날 거의 모든 웹 application에서 사용된다.

원래는 정적(static)인 text기반 자원들을 검색하기 위해 만들어진 기초 protocol이지만 이후 계속 발전해 복잡한 분산(distributed) application을 위해 여러가지 방법으로 사용됨

1.1 HTTP 요청


요청과 응답을 포함한 모든 HTTP 프로토콜은 헤더를 통해 다양한 정보를 포함하고 있으며 각 헤더마다 특정 정보를 갖고 있다. 밑은 헤더 정보를 나타낸다.

GET https://search.naver.com/search.naver?where=nexearch&query=get&sm=top_hty&fbm=1&ie=utf8 HTTP/1.1
Host: search.naver.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://www.naver.com/
Accept-Encoding: sdch, br
Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: npic=LpJGw4QeQzJRFTqWKBTFgbWM6JTh+wxmyqbJf7a0sQn7qYQdOWU38WXNEO/yYBIrCA==; NNB=ZHT3IP4P3C7FO; nx_ssl=2; page_uid=TueQ9wpySEsssZBEf/Vsssssstw-324642; _naver_usersession_=bvrGxnF2DXeuYoL0F+Yh9w==; nid_iplevel=1

위 HTTP 요청은 www.naver.com 에 get이라는 단어를 검색했을때 생기는 요청중 하나이다.( 실제로 여러 request를 함)

위 요청을 기반으로 중요히 봐야할 헤더들을 찾아보자

HTTP 전송방법

  •  GET 방식 (위의 요청은 GET 방식)
    •  GET 방식은 별도의 메시지 바디를 필요로 하지 않는다. 그리고 GET방식은 검색하는 인자값을 url에 넣어 요청하는데  url 에서 "?" 다음에 보면 query=get  이라는 문자가 보일것이다.   이것은 아까 get이라는 단어를 검색했을때 요청으로 파라미터값를 GET방식으로 해주어서 보이는 것이다.
    • 그래서 GET방식은 데이터를 가져올때 사용한다.
  • POST 방식 
    • POST방식은 GET방식처럼 요청때 보내는 파라미터값을 URL에 보이게 하지 않고 BODY안에 숨겨서 보낸다. 그래서 뒤로가기 버튼을 누르게 되면 GET요청은 이미 한번 열었던 페이지를 다시 열면 브라우저는 요청을 자동 수락하지만  POST요청은 그렇지 않다.
    • 그래서 POST방식은 데이터를 서버에 제출(submit)하거나 수행시킬때 사용한다. 
  • HEAD 방식
    • GET 요청과 비슷하게 작동하지만 서버가 클라이언트에 응답할때 메시지 바디를 보내지 않는다는 점에서 차이가 있다. 
    • GET요청을 하기전에 자료가 있는지 확일할 때 쓴다
  • OPTIONS 방식
    • 특정 자원에 맞는 HTTP 방식을 알려달라고 서버 측에 요청할때 사용한다. 이에 응답으로 서버는 Allow 헤더에 사용할수 있는 모든 메소드 리스트를 클라이언트에게 보낸다.
HTTP 버전
  • 인터넷상에서 가장 일반적으로 쓰이는 HTTP 버전은 1.0 과 1.1이고 대부분의 브라우저는 초기값으로 1.1을쓴다.
Referer 헤더
  • 해당 요청이 이전에 어디서에서부터 요청을 받았는지에 대한 URL 을 나타낸다 나는 검색된 결과페이지를 받기전 www.naver.com 의 페이지에 있었다.
User-Agent 헤더
  • 브라우저나 기타 클라이언트의 SW 정보를 보여준다 Mozilla는 여러 이유로 대부분의 browser에 포함돼 있다는 점을 주목하자. 그리고 현재 사용하는 브라우저의 버전(Chrome/54.0.2840.71)도 볼수 있다.
cookie 헤더
  • 쿠키헤더(Cookie)는 서버가 클라이언트에게 전송한 인자 값에 추가 정보를 보낼 때 사용한다. 더 자세한 사항은 뒤에서 알아본다.

1.2 HTTP 응답

 HTTP/1.1 200 OK
Date: Thu, 10 Nov 2016 12:18:13 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: page_uid=TueDmdoRR1dsscwCuU0sssssssG-243393; path=/; domain=.naver.com
Set-Cookie: _naver_usersession_=JW8jPAyRwYFdbmRDqvGZKQ==; path=/; expires=Thu, 10-Nov-16 12:23:13 GMT; domain=.naver.com
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Pragma: no-cache
Vary: Accept-Encoding
Server: nxg

위 요청에 대한 응답이다 (only header)
실제로 Body에 보여질 데이터가 포함되어있다.

요청헤더랑 사뭇 다른데 일단 200 OK는 가장 일반적인 코드인데 성공적으로 요청한 자료가 클라이언트에게 보내졌다는 것을 뜻한다.

Server 헤더

  • 통상적으로 웹 서버 SW를 나타내는 배너가 들어가 있다. 그러나 가끔은 설치돼 있는 모듈과 운영체제에 대한 정보를 담고 있기도 하다.  nxg는 네이버가 사용하는 통합보안솔루션 으로 보인다. S

Set-Cookie 헤더

  • 브라우저(chrome,IE etc..)에게 쿠키에 대한 정보를 알려준다. 쿠키 정보는 클라이언트가 향후 서버에게 페이지를 요청할 때 서버에게 보내는 요청 정보 중에서 쿠키형태로 사용된다.
  • 위의 응답에서 _naver_usersession 에대한 정보(JW8jPAyRwYFdbmRDqvGZKQ==)가 이에 해당한다. 위의 set-cookie 형태는 우리가 알아볼수 없는 형태의 문자로 되있는데 추측상 base64인코딩을 쓴것으로 보인다.
Pragma 헤더
  • 브라우저가 응답한 내용을 캐시에 저장하지 않게 한다. 이러한 지시 사항은 동적인 자료가 다시 돌아오면 실행되는데 이렇게 함으로써 브라우저가 최종적으로 웹서버에 요청한 내용에 대한 최근 정보를 갖고 있는지 확인 가능하다.  
  • 위는 no-cache  으로 설정하여 페이지를 계속 새로이 생성하도록 한다.

content-Type 헤더
  • 해당 메시지 바디에 브라우저에게 보여줄 HTML 문서가 있음을 알린다. 
  • text/html 으로 text형태의 html문서를 보여줄것이다.
  • charset 변수의 UTF-8 값은 브라우저가 어떤 character형 인코딩을 쓸지에 대한 정보이다.

1.3 REST

Representational state transfer의 약자로 분산 시스템에서 사용하는 아키텍쳐의 한 종류로
요청과 응답 내용에 System resource의 현재 state가 나타나 있다.
쿼리 문자열에 매개변수를 갖고있는 URL은 REST의 제약을 받는다. 쿼리 문자열이 아닌 URL 파일 경로에 있는 매개변수를 가진 URL을 자칭한다. 

www.example/search?make=food&taste=good
이라는 쿼리 문자열로 나타난 URL을 REST형식으로 바꾸면 
www.example/search/food/good 으로 나타난다.

1.4 HTTP Header

 HTTP 헤더는 중요한 정보들을 가지고 있기때문에 이번 장에서 자세히 알아본다.

 일반적인 헤더
  • Connection 
    •  HTTP 전송이 완료된 후에 TCP연결을 차단할지, 다른 메시지를 받기 위해 열어둘지를 결정
  • Content-Encoding 
    •  메시지 바디 내용에 어떤 종류의 인코딩을 사용할지 정할 때 사용 압축을 해서 애플리케이션 간에 응답을 빨리 전송하는데 쓰이는 gzip 등의 인코딩 방법이 있다.
  • Content-Length  
    • 메시지 바디 길이를 나타낼 때 사용
  • Content-Type 
    • 메시지 바디에 들어있는 컨텐츠 종류를 나타낸다.
  • Transfer-Encoding 
    • 메시지 바디가 HTTP 전송을 쉽게 하게 도와주는 인코딩 방법을 보여준다.


요청 헤더
  • Accept 
    • 클라이언트가 그림 파일이나 문서 형식 등 어떤 종류의 내용을 수락할 것인지 서버에게 알리는 역할을 한다.
  • Accept-Encoding 
    • 클라이언트가 어떤 종류의 인코딩된 문서를 받아들일지 서버에게 알리는 역할
  • Authorization 
    • HTTP 인증 형태에서 사용자의 식별 정보를 서버에게 보낼 때 사용
  • Cookie 
    • 서버로부터 받은 쿠키를 다시 서버에게 보내주는 역할. 실제 이 Cookie를 통해 서버는 사용자를 식별한다.
  • Host 
    • 요청된 URL에 나타난 호스트명을 상세하게 나타낼 때 사용
  • If-Modified-Since 
    • 브라우저가 마지막으로 요청 자료를 받은 시간을 나타낸다. 자료가 그 시간 이후로 바뀐 적이없다면 서버는 클라이언트에게 304 코드를 이용해 클라이언트의 하드에 저장돼있던 복사본을 사용하라고 명령
  • If-None-Match 
    • entity tag를 지정하기 위해서 사용한다. entity tag는 메시지 바디의 내용을 식별해주는 역할을 한다. 브라우저는 서버에게 요청한 자료를 최종적으로 전부 받은 후 서버에게 entity tag 를 전송한다. 서버는 entity tag 를 사용해 브라우저가 자료 복사본을 사용할 수 있는지 여부를 판단한다.
응답 헤더
  • Cache-Control 
    • 캐시에 대한 지시를 브라우저에게 전달하는 역할을 한다.
  • Etag 
    • entity tag를 나타낼 때 사용. 클라이언트는 나중에 같은 자료를 요청할 때 If-None-Match헤더에서 Etag를 보낼 수 있다. 따라서 현재 브라우저의 캐시에 어떤 버전의 자료를 가지고 있는지 서버에게 알릴 수 있다.

  • Expires 
    • 브라우저는 요청한 자원에 대해 Expires 시간까지 클라이언트의 하드에 저장된 복사본 내용을 사용한다.
  • Location 
    • 재전송하는 응답에서 목적지를 나타낼때 쓰이고, Location은 상태 코드 3XX이다.
  • Pragma 
    • 브라우저에게 no-cache와 같은 캐싱 지시를 보내기 위해 사용
  • WWW-Authenticate 
    • 401 상태 코드와 함께 응답할 때 사용한다. 서버로부터 제공받은 인증서의 종류와 상세 내용을 나타낸다.
1.5 쿠키

쿠키의 메카니즘은 아까도 설명했듯이 서버가 클라이언트에게 데이터(set-cookie)를 보낼수 있게 하고 클라이언트는 그 쿠키를 저장해 뒀다가 다시 서버에게 보내는데 사용한다.

예를 들어 설명하면 이해가 쉽다.
아까도 설명했지만 먼져 server가 Set-cookie헤더를 통해 쿠키를 생성하고 client에게 보낸다.

Set-Cookie : p_uid=sdkfjksdjfksdjfWsdfcsCS

쿠키를 받은 사용자의 브라우저는 서버로 보내는 요청에 쿠키 헤더를 더한다.

 Cookie: p_uid=sdkfjksdjfksdjfWsdfcsCS

쿠키는 일반적으로 이름(p_uid)와 값(sdkfjksdjfksdjfWsdfcsCS)으로 구성된다. 쿠키는 서버 응답에 Set-cookie 헤더를 여러번 사용해서 추가할수도 있고 똑같은 HTTP 헤더에서 각 쿠키를 세미콜론(;) 으로 구분해서 다시 서버로 보내기도 한다.

Set-Cookie 헤더는 속성을 추가적으로 포함할수 있다. 속성들은 브라우저가 쿠키를 어떻게 다룰지를 결정하게 된다.

  • Expires
    • 쿠키의 유효기간을 나타낸다. 이 속성이 없으면 쿠키는 현재 작업 세션에서만 사용가능
  • domain
    • 쿠키를 사용할 수 있는 도메인을 나타낸다.
  • path
    • 쿠키가 사용할 수 있는 URL 경로를 나타낸다.
  • secure
    • 이 속성이 설정되면 쿠키는 HTTPS 요청으로만 전송한다.
  • HttpOnly
    • 쿠키는 클라이언트쪽의 자바스크립트로 직접 접근할수 없게 한다. 그래서 document.cookie와 같은 스크립트 언어로 cookie을 요청하면 브라우저가 응답하지 않는다.

Wait!! 
HTTPS 가 머죠?

1.6 상태코드

HTTP 응답 메시지의 제일 첫번째 줄에 상태코드를 포함시킨다.

1xx 정보를 제공함
2xx 요청이 성공적으로 이뤄짐
3xx 요청한 해당 자원이 다른곳에 있음
4xx 요청에 문제가 있음
5xx 서버에 에러가 있음

  • 200 OK 
    • 클라이언트의 요청이 성공했다는 것을 나타낸다. 서버의 응답 메시지 바디에 클라이언트가 요청한 내용에 대한 결과를 포함한다.
  • 304 Not Modified 
    • 브라우저가 서버에게 요청한 자료에 대해 서버는 클라이언트 내에 복사된 캐시를 사용하게 한다. 서버는 If-Modified-Since 와 If-None-Match 요청 헤더를 사용해 클라이언트가 가장 최근의 자료를 가지고 있는지 여부를 확인한다.
  • 404 Not Found 
    • 클라이언트가 서버에게 요청한 자료가 존재하지 않는다는 것을 나타낸다.
  • 500 Internal Server Error 
    • 서버가 클라이언트의 요청을 실행할 수 없을 때 500 상태 코드가 발생한다. 보통 서버가 예상하지 못한 요청을 보냈을 때 애플리케이션이 적절히 처리하지 못할 경우 500 상태 코드를 볼 수 있다. 어디서 문제가 생겼는지 알아보려면 서버의 응답 내용을 상세히 살펴봐야 한다.

다른 상태코드는 쉽게 찾아볼수 있으니 굳이 상세히 적지 않겟다.

1.7 HTTP 인증
HTTP 프로토콜은 사용자를 인증할때 다양한 인증 방법을 이용한다.
  •  Basic
    • 간단한 인증방법으로 각 메시지 요청헤더에 Base64로 암호화 한 문자열을 사용자 자격 증명으로 보낸다.
  • NTLM
    • 시도/응답 방법으로 윈도우 NTLM 프로토콜을 사용
  • Digest
    • 시도/응답 방법으로 , MD5 체크섬을 사용
인증 프로토콜은 보통 인트라넷 기반의 서비스에서 사용하기 떄문에 인터넷에 연결된 웹 애플리케이션에서 사용하는 것은 비교적 드물다.

(인트라넷이란 기업 내에 속해 있는 사설 네트워크으로서, 서로 연결되어 있는 여러 개의 근거리통신망으로 구성될 수 있고, 광역통신망 내에서는 전용통신망(VPN 터널링)이 사용되기도 한다)






0 개의 댓글:

댓글 쓰기