URL (Uniform Resource Locator), HTTP 구조

형식

프로토콜://주소(or IP):포트번호/파일?파라미터=값

ex) http://search.naver.com/search.naver?where=nexearch&query=sexman&sm=top_hty&fbm=1

http:// 프로토콜 ( // 는 뒤에오는 문자열이 서버임을 의미, / 뒤에는 파일명이나 디렉토리명이 올수 있음)
search.naver.com 도메인주소
search.naver 파일, 앞에 경로명 (디렉토리명)이 붙을수 있음
파라미터 : 변수 sm = top , query = sexman , where = nexearch
- search.naver 에 전달되는 값을 변수 = ?? 이런식으로 나열되는듯 함

HTTP REQUEST

Method
GET, POST (경로 및 파일명) (HTTP 프로토콜 버젼)

Hearder 
Accept : 응답메세지에 허용할수 있는 미디어 종류
Accept-Language : 응답에 대해 선호하는 언어
Cookie : 클라이언트가 가지고 있는 정보
User-Agent : 응답내용에 대해 응답할수 있는 브라우져 종류
Host : 응답을 요청한 호스트
Proxy-Connection : 프록시 연결을 사용함

entity body
POST method를 이용하여 웹 서버에 요청시 ID or PASSWORD 와 값을 포함할수 있음

GET : 클라이언트가 서버에 문서 요청 MIME 형식으로 표현되는 사항을 덧붙일수 있음

POST : 클라이언트가 서버에 문서 요청, 파라미터값이 URL을 통해 전송되지 않음


GET 요청시 
GET /파일이름?파라미터 이런식으로 되지만

POST 요청시
POST /파일이름 프로토콜 버젼 (파라미터가 보이지 않음)
entity body에 덧붙이게 됨
어떤 클라이언트가 어떤 값을 서버에게 보낼때도 POST가 사용되는듯 함


다른메소드들

HEAD : 자료에 대한 헤더정보만 받음
GET : URL에 해당하는 자료 요청. URL정보로 해당하는 페이지에 바로 접근
POST : 데이터크기에 제한없이 서버가 처리할수 있는 자료를 전송
PUT : 클라이언트에서 전송받은 정보를 서버에 저장 (지정한 파일이 없을시 새로 만들기도 함)
DELETE : 해당 URL의 자료를 삭제
TRACE : 실제본문을 요청한 상태를 다시 요청 ( 디버깅 할때 사용?)
OPTIONS : 어떤 옵션이 있는지 물음, (요청한 URL은 서버 전체를 의미하도록 * 표시로 대신함)
CONNECT : 프록시가 사용하는 요청 SSL 에 예약된 메소드
MOVE : 서버에 저장된 자료의 위치나 파일명을 변경

HTTP RESPONSE

response code
프로토콜 버젼, 상태코드

header
Date : 응답시간
Server : 응답서버정보
Last_Modified : 최근 응답페이지 수정일
Etag : 관련된 실체 (entity)의 태그
Accept-Ranges : 받을수 있는 요청 범위의 형식
Content-Length : 내용의 길이
Content-Type : 내용의 형식
Via : 요청에서 클라이언트와 서버, 통신 중간에 프로토콜과 수신사
Age : 서버에서 생성된 페이지(정보)에 대한 예상 시각
Expires : 내용이 만료되는것으로 예상시간
Connection : 연결 형태

entity body
클라이언트가 요청한 페이지 내용과 같은 전달할 값

HTTP STATUS CODE 에러코드 간략 범위

100 - 199 : 정보 (처리의 경과 상황등을 통지)
200 - 299 : 클라이언트 요청이 성공적임 (정상적)
300 - 399 : 다른 동작이 더 필요하며 클라이언트의 요청을 리다이렉트
400 - 499 : 클라이언트 오류
500 - 599 : 서버 오류

HTTP 압축

클라이언트 → 서버

- 브라우져가 압축지원이 가능한것으로 gzip, deflate 가 있음을 서버에 알림

Accept-Encoding: gzip, deflate


클라이언트 ← 서버

- 아래 헤더를 통해 gzip으로 압축여부를 서버가 클라이언트에게 통보

Content-Encoding: gzip


클라이언트 - 프록시 - 서버

- 위와 같은 상황엔 더 복잡해 지며 프록시에서 서버로 부터 캐싱 받은 캐시가 압축된것인지 안된것인지

클라이언트가 요청한것의 압축여부에 따라 예측하지 못한 결과값을 받을수 있음 이를 해결하기 위해

서버쪽에 응답 헤더에 Vary: Accept-Encoding 포함시킴 - 프록시에게 받은 요청에 따라 응답을 바꾸어 전달하도록 함

클라이언트가 압축이 제대로 지원하지 않는 경우가 발생한다 특정 버젼의 경우 이때는 프록시를 사용못하지만

특정브라우져에 버그를 줄일려면 아래와 같이 설정할수도 있음

Vary:* 브라우저가 캐시에 저장된 구성요소를 아예 사용하지 못하게 함

Cache-Control: private 프록시 캐싱을 못하게 함 (구글 & 야후에서 이 방식 사용한다고 함)

조건부 GET 요청

클라이언트 → 서버

- 브라우져가 캐시에 저장된 파일이 2006년 2월 22일 꺼인데 써도 되냐는 요청 (최신이 맞냐는 물어보는 요청)

If-Modified-Since: Wed, 22 Feb 2006 04:15:54 GMT


클라이언트 ← 서버

- 수정되지 않았다는 304 상태코드를 반환하고 수정이 되었다면 200 코드와 함께 최신 파일을 보냄
브라우져는 304 반환 받으면 캐싱된 파일을 쓰며 최신이 아니면 새로 GET 받는다

304 Not Modified

만료기한


- 조건부 GET 요청도 요청/응답이 반복되므로 서버가 클라이언트에 Expires : 유효기간 정보를 보내면 조건부

GET 요청을 줄일수 있음

클라이언트 ← 서버

- 브라우져는 만료기한을 캐시에 저장하고 해당일자가 지나지 않을동안 캐싱데이타를 사용하게 된다

Expires : Wed, 22 Feb 2006 04:15:54 GMT - 유효기간 관점

Cache-Control: max-age=315360000 (10년) - 10년동안 신선하다라는 의미 HTTP1.1 지원하는 브라우져만 적용

Keep-Alive

- 하나의 소켓연결에 여러개의 요청을 동시에 요청할수 있다는 개념


HTTP REDIRECT

- 사용자를 URL에서 다른 URL으로 다시 보내는것 상태코드 (301과 302가 많이 사용)
- 상태코드 304 실제로 리다이렉트 하지않음 (클라이언트 캐시에 있는 경우 다운로드 되는것을 방지하기 위함)
- 리다이렉트를 해야겠다면 HTTP 3xx 상태코드를 이용하여 처리하는 방법 추천
- 클라이언트들의 내부 트래픽 및 HIT 카운트를 추적하기 위해 많이 사용됨 (리다이렉트 보다 Referer 추천)
- 클라이언트들의 외부 트래픽을 추척하기 위해서는 Referer 보다 비콘 (beacon) 추천 (html의 묻어는 투명한 gif 등)


ETag

- 브라우져 캐시에 저장된 요소와 서버의 원본 서버의 구성요소가 일치하는지 판단 하는 또 다른 방법
- 문자열 형식으로 따옴표안에 표현됨

Etag: "10c24bc-4ab-457e1c1f"

클라이언트 → 서버

- 클라이언트가 구성요소가 유효한지 서버에 If-None-Match 헤더에 ETag를 삽입하여 전송

If-None-Match: "10c24bc-4ab-457e1c1f"

아직 유효하다면 서버에서 304 Not Modified 반송

Etag 문제점

사이트를 호스트 하는 서버에서만 고유한 값임 여러개의 웹 사이트를 구성할 경우 각각 서버의 Etag 값이 틀리므로 부하가 더 발생할수 있음 프록시 서버를 경유하는 경우 프록시와 웹서버만 Etag값이 다 틀리므로 효율 떨어짐 보안에 취약하다고 함 If-Modified-Since 와 같이 쓸 경우 If-None-Match가 먼저 처리 되어 차라리 If-Modified-Since 혼자 섰을 경우보다 못한 경우 발생  2개 같이 쓸 경우 2개 같이 만족하여야 처리됨 ETag의 inode 값을 제거하여 파일 크기와 타임스탬프만 사용하는 방법도 있음 결국 ETag를 제거하거나 사이트에 맞게 변경하여 사용해야만 함