티스토리 뷰

WEB

URL (Uniform Resource Locator), HTTP 구조

초보의 CHOMAN 2015.06.12 11:07

형식

프로토콜://주소(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를 제거하거나 사이트에 맞게 변경하여 사용해야만 함


'WEB' 카테고리의 다른 글

제로보드 XE 설치하기 (1.8.3)  (0) 2015.06.16
ieHTTPHeaders tool  (0) 2015.06.12
URL (Uniform Resource Locator), HTTP 구조  (0) 2015.06.12
ssh 인증을 통한 WEB에서 리눅스 시스템 제어  (0) 2015.06.11
phpize  (0) 2015.06.11
PHP Version 5.3.3 phpinfo(); 정보보기  (0) 2015.06.11
댓글
댓글쓰기 폼
공지사항
Total
671,322
Today
88
Yesterday
383
링크
«   2018/09   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
글 보관함