HTTP 프로토콜 , http protocol, 웹 전송 구조, 웹 서버구조,웹 강좌 웹서버 호출 RFC 2616 RFC2616 웹 프로토콜 구조 web protocol
RFC 문서에 나오는 구체적인 데이터 통신 방법을 말하는것이 아닌 사이트 스크래핑이나 웹 데이터를 이용하려 할때 또는 외부에서 사이트 내용을 사용할때 이용될 수 있는 간단한 HTTP 프로토콜 호출 구조이다. (편의상 존칭은 생략했습니다 ^^)
참고 문서
HTTP RFC(영문)클라이언트 A 가 서버 B에 연결을 해서 test.html 을 받아오는 과정을 설명한다.
HTTP 호출 구조 이미지 출처(Wikipedia)
HTTP 프로토콜 호출 구조
1. URL 분석
2. 도메인 해석
3. 서버 접속
4. Request Header 전송
5. Request Data 전송 (옵션)
6. Response Header 수신
7. Response Body 수신
8. 연결 종료
위와 같은 구조로 HTTP 호출이 이루어진다 자세하게 보자면
예제
URL : http://www.testsitexxx.com:8080/test.html
1. URL 분석
브라우저에서 URL을 분석을 하게 된다 , 우리가 입력한 URL을 분석하여 프로토콜,호스트, 서버 포트, 호출 파일 등을 분석하게 된다.
일단 프로토콜(scheme라고도함) 을 분석하게 되는데 여기서 설명하게 될 부분은 HTTP이기때문에 그외의 프로토콜은 제외한다. http 와 https 등 호출하게되는 프로토콜이 있다. 위 예제 url에서는 http 이다.
그리고 호스트를 분석한다.위 url에서 호스트는 www.testsitexxx.com 이다.
서버 포트는 8080 포트를 이용을 한다. 기본으로는 80 포트를 이용하게 된다. 80포트는 HTTP의 예약된 포트번호이다.
경로는 / 이며 호출될 파일은 test.html 을 호출한다.
2. 도메인 해석
브라우저에서 서버에 접속을 할때는 도메인을 IP 주소로 변환하는 과정이 필요하다. DNS서버에 질의를 하여 호스트명을 IP주소로 반환한 값을 얻어와 해당 IP주소와 포트로 접속을 하게 된다. TCP 접속 방식 및 접속 구조에 대해서는 다음에 다루기로 한다.
3. 서버 접속
DNS서버에서 질의한 결과에 따른 IP와 URL에서 해석된 포트명으로 서버에 접속을 하게된다.
4. Request Header 전송
일반적으로 사이트를 호출할때는 아래와 같은 형태의 Request Header가 존재 한다.
GET
(요청방식*1) /test.html
(경로*2) HTTP/1.1
(프로토콜버전*3)
Accept: */*
(응답하여 해석할 파일의 종류*4)
Referer:
(호출전경로*5)
User-Agent:
(브라우저의 Agent값*7)Accept-Encoding: gzip, deflate
(수신가능한 body 인코딩 종류*8)Host:
(호출할 호스트*9)Request Header 설명
헤더 기본 설명 펼치기
Request Header
1. 요청방식 (메소드) [GET/POST]
GET 메쏘드는 요구 URI(Request-URI)에서 지정한 어떤 정보이든간에 가리지 않고 엔터티 바디(entity body)로 전달해 달라고 요청할 수 있다. 요구 URI에서 어떤 실행 프로그램을 명시할 경우 실행 프로그램 자체가 전달되는 것이 아니라 실행 결과가 응답 메시지의 엔터티 바디로 전달된다. 요구 메시지에 If-Modified-Since 헤더 필드가 포함돼 있다면 GET은 조건부 GET으로도 동작할 수 있다. 이 경우 GET이 가지는 의미는 If-Modified-Since에 의해서 지정된 일자 이후에 수정되었을 때만 전송한다. 이 조건을 이용하면 불필요한 데이타 전송을 막을 수 있을 뿐만 아니라 이미 캐시돼 있는 데이터를 사용자에게 전달해줌으로써 네트웍의 활용을 십분 높일 수 있다.
POST 메쏘드는 요구 메시지중 메시지 바디에 포함돼 있는 자원을 요구 라인에 있는 요구 URI로 넘겨주게 된다. 이 메쏘드를 사용하면 대부분 CGI 프로그램에서 도맡아 처리하므로 컨 텐트 길이(Content-Length)만 빠뜨리지 않으면 된다. 서버가 이에 대한 정보를 확보하지 못할시에는 400(bad request) 메시지를 클라이언트에 보내게 된다. 그리고 서버가 매번 요구 메시지에 대해 똑같은 응답을 할 것인지 알 수가 없으므로 클라이언트에서는 굳이 POST 메쏘드에 대한 응답을 캐싱할 필요가 없다.
2. 경로 (URI)
URI(Uniform Resource Identifier)는 웹자원에 대한 유일무이한 이름으로 절대 URI(Absolute URI) 또는 절대 경로(Absolute PATH)로 지정할 수 있다. 절대 URI는
http://www.testsitexxx.com/test.html과 같이 프로토콜명, 호스트명 또는 IP 번호, 파일명이 모두 나온 경우이며, 절대 경로는 /test.html 과 같이 디렉토리와 파일명만 있는 경우이다. 프록시 서버에 요구 메시지를 보내는 경우는 꼭 서버명이 포함된 절대 URI를 보내야 한다.
3. 프로토콜 버전
HTTP 프로토콜의 버전은 0.9, 1.0, 1.1 등이 사용되는데 주로 1.1 이 사용된다 각 프로토콜의 버전별로 요청되는 헤더의 규약이 달라진다. 여기서 설명은 1.1 기준이다.
4.Accept
클라이언트에서 사용할 수 있는 미디어 타입을 적어준다 .
5. Referer
요구 URI로 얻은 문서의 정보가 들어가게 된다. 서버에서는 이 정보를 통해 잘못된 Back-Link나 링크를 판단할 수 있고, 상업 사이트에서는 링크된 서버를 찾아 방문자를 찾아낼 수도 있다.(->자신의 사이트가 링크된 서버를 찾을 수 있다.)
6. User-Agent
사용자 브라우저의 버전명 및 OS명등 브라우저가 기본적으로 서버에 보내는 브라우저의 정보 이다.
8.Accept-Encoding
클라이언트에서 제공되는 인코딩 방법을 적어준다. 서버에서 인코딩이 가능하다면 메시지 바디에서 명시한 방식으로 인코딩된다. 이 헤더 정보가 없다면 HTTP에 지정된 모든 인코딩 방식을 지원하는 것으로 인식한다.
9.Host
요구하는 서버의 이름주소를 적는다. 이는 하나의 IP주소에 여러개의 이름을 가진 멀티 서버를 지원 하기 위한 헤더 필드이다. HTTP/1.1의 요구 메시지에서는 반드시 포함되야 하는 헤더이다.
5. Request Data
POST 방식으로 데이터를 전송할때에 Request Header를 서버로 전송한 후 Request데이터를 보낸다 이 데이터를 보내려면 호출방식(메소드)를 POST로 지정을 한 후 데이터를 전송한다.
데이터를 보내는 방식에는 2가지가 있는데 하나는 form-urlencod 를 통해 보내는 방식 또 하나는 multipart-formdata 를 이용해 보내는 방식이 있다. 이 2가지 방식의 차이점은 전자는 일반적인 폼데이터(텍스트위주)만 전송할때 쓰이는 방식이고 아래 방식은 서버로 파일을 전송할때 사용이 된다.
호출 구조의 변화는 호출 메소드가 POST로 변화하고 전송하는 데이터의 길이를 서버에 알려준다 그리고 해당 데이터를 요청 폼에 맞게 전송을 하게 된다
URL Encoded 로 전송Content-Type: application/x-www-form-urlencoded
Content-Length: XX
xxx=XXX&yyy=YYY
Multi Part Form-data 로 전송 (파일 전송시)
Content-Type: multipart/form-data; boundary=--------[boundaryKEY값]
Content-Length: XX 보낼 데이터의 전체적인 길이
--------[boundaryKEY값]
Content-Disposition: form-data; name="폼이름"; filename="파일이름"
Content-Type: 파일의 MIME 타입
파일 내용
--------[boundaryKEY값]
Content-Disposition: form-data; name="폼이름"
데이터
--------[boundaryKEY값]
위와같이 POST데이터를 전송한다
6.Response Header (응답헤더)
HTTP/1.1 200 OK
Server: Apache
Content-Length: xx
Transfer-Encoding: 데이터 인코딩의 타입
Content-Type: text/html; charset=utf-8
응답받은 헤더의 내용은 위와 같은 형태로 나타난다 헤더의 전체적인 응답데이터는 RFC문서를 참고하거나 추후 포스팅을 하겠다. 이부분은 서버가 HTTP/1.1방식으로 응답을 했다는 내용이다. 그리고 오류코드는 200 즉 정상으로 응답을 했다는 표시이고
전송하는 컨텐츠의 길이는 XXByte이다고 알려준다. Contents-Type 은 text/html 이고 그 데이터의 캐릭터셋은 utf-8이라는것을 브라우저에게 알려준다.
7. Response Body
응답헤더가 출력되고 CRLF가 2번 나온 후 HTTP Body(html body 아님) 가 출력이 되는데 이 것은 응답헤더의 인코딩 타입에 따라 달라지게 된다. 보통 gzip, chunked 인코딩이 사용된다.
인코딩 자세히 보기
GZIP 인코딩
서버에서 HTTP BODY를 전송할때 gzip 압축방식으로 압축을 해서 전송을 한다. 주로 텍스트를 전송하는 HTTP프로토콜로서 전체적 트레픽 낭비와 전송 시간을 줄이기 위해 gzip으로 압축을 해서 전송하는 방식이다.
CHUNKED 인코딩
서버에서 데이터를 전송할때 CRLF가 나온 후 데이터의 길이를 알려준다 이때 적당한 길이만큼 8진수(HEX)로 길이를 알려준다 그만큼 데이터를 이동한 후에 또 8진수 형태의 데이터를 알려준다 이런것이 반복이 되고 마지막 0을 만날때까지 데이터를 반복한다. 데이터의 형태는 [길이]CRLF[데이터]CRLF[길이] 의 형태로 브라우저에게 데이터를 전송한다.
편의상 존칭을 생략했습니다. ^^ 틀린 부분이나 보기 힘든 부분 있으면 말씀해주세요 ^^
그리고 RFC문서를 전체적으로 적는다기 보다 HTTP의 구조를 이해를 돕기 위해 적었습니다.

(
0)

(
0)
Posted by 근원e