웹브라우저를 열어 주소창에 주소를 기입하고 엔터를 치면, 그 주소에 해당하는
웹사이트로 접속이됩니다.
접속이 되면서 주소창에는 기본으로 http://라는 문자가 붙게 되지요.
즉, 이 사이트는 HTTP 프로토콜을 이용하여 데이터를 전송한다는 것이지요.
그럼 HTTP 프로토콜이란 무엇일까요?
HyperText Transfer Protocol 이라고 지겹에 들어왔지만,
저는 단순히 HTTP라는 방식으로 통신을 하는 것이라고 이해합니다.
GET /디렉토리/파일이름 HTTP/1.1
HOST: 도메인
이런 문자열을 서버(HTTP서비스를 지원하는서버. 즉 웹서버)에게 전송하게 되면.
서버는 이 HTTP요청을 분석하여 적절한 응답을 합니다.
성공했을 경우.
HTTP/1.1 200 OK
Date: Sun, 20 Feb 2005 08:21:35 GMT
Server: Apache/1.3.26 (Unix) PHP/4.3.1 mod_throttle/3.1.2 mod_become/1.2
X-Powered-By: PHP/4.3.1
Set-Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D; expires=Mon, 20-Feb-06 08:21:36 GMT; path=/
Set-Cookie: phpbb2mysql_sid=58db71f803b9ac073b4f36045ae5bc0f; path=/
Cache-Control: private, pre-check=0, post-check=0, max-age=0
Expires: Sun, 20 Feb 2005 08:21:38 GMT
Last-Modified: Sun, 20 Feb 2005 08:21:38 GMT
Transfer-Encoding: chunked
Content-Type: text/xml
334
....... 중략 ........
가장 첫 줄에는 요청에 대한 결과 코드가 그 뒤로는 결과에 대한 정보들이 수록되어 있고
빈 줄이 발견되면 HTTP 헤더의 종료를 알린다.(Content-Type 이런 것들이 HTTP 헤더)
[몇 가지 헤더의 의미]
Date : 뻔하지만 날짜.
Server : 역시 뻔하지만 서버의 정보
Content-Type : 응답의 종류가 html인가 다른 것인가를 표시 (예를들어 jpg 같은 이미지)
Content-Length : 이 응답의 총 길이를 바이트 단위로 표시.
Transfer-Encoding : 응답이 인코딩 된 경우 그 방법을 표시
[응답의 길이]
1. Transfer-Encoding 헤더가 존재하면 chunk 방식으로 인코딩 되기 때문에 chunk를 디코딩하면서 길이가 계산된다.
2. Content-Length 헤더가 존재하면 이 헤더의 값이 응답의 길이가 된다. 만일 Transfer-Encoding와 Content-Length 둘다 존재하면 Content-Length는 무시된다.
3. 3가지 더 있지만 생략. ^^
[인코딩 되지 않은 경우]
헤더만 잘라낸 나머지를 요청에 대한 순수한 응답으로 사용하면 됩니다.
[chunk로 인코딩 된 경우]
실제 데이터 전송 전에 다음에 올 chunk의 크기가 오게 됩니다.
위의 예제가 chunk로 인코딩된 경우고, 16진수로 334가 앞으로 올 데이터의 크기가 됩니다.
0x334 바이트 만큼 데이터를 읽으면 또 다른 chunk의 크기가 나오게 됩니다.
이러한 과정을 chunk 크기가 0이 나올때까지 반복하게 됩니다.
*인코딩 되지 않은 응답의 구조
[HTTP 헤더]
[실제데이터]
*chunk로 인코딩된 응답의 구조
[HTTP 헤더]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
... 계속 반복 ..
[0] <-- 마지막 chunk 길이
*줄넘김 코드인 CR이 데이터에 존재하는 경우 항상 그 뒤에 CR+LF를 붙여 주더군요.
즉 실제로 전송되는 데이터는 CR+CR+LF 입니다. 이게 정확한건지는 좀더 알아봐야겠습니다.
[참고문헌]
RFC2616
[p.s]
요 몇일 간 네트워크 프로그래밍에 도전하고 있습니다.
그동안 네트워크는 해본적이 없이 때문에 기본이 전혀 안되어있죠.
TCP/IP고 OSI 계층이고 아무리 봐도 머리위에 물음표만 뜨더군요. ^^
결국, 목표를 하나 정해서 HTTP 프로토콜에 대한 분석이 필요하게 되었습니다.
제가 한 것에 대한 기록를 위해서 어느정도 성과가 생길때까지 자주 덧글을 달아야할 듯 합니다.
웹사이트로 접속이됩니다.
접속이 되면서 주소창에는 기본으로 http://라는 문자가 붙게 되지요.
즉, 이 사이트는 HTTP 프로토콜을 이용하여 데이터를 전송한다는 것이지요.
그럼 HTTP 프로토콜이란 무엇일까요?
HyperText Transfer Protocol 이라고 지겹에 들어왔지만,
저는 단순히 HTTP라는 방식으로 통신을 하는 것이라고 이해합니다.
GET /디렉토리/파일이름 HTTP/1.1
HOST: 도메인
이런 문자열을 서버(HTTP서비스를 지원하는서버. 즉 웹서버)에게 전송하게 되면.
서버는 이 HTTP요청을 분석하여 적절한 응답을 합니다.
성공했을 경우.
HTTP/1.1 200 OK
Date: Sun, 20 Feb 2005 08:21:35 GMT
Server: Apache/1.3.26 (Unix) PHP/4.3.1 mod_throttle/3.1.2 mod_become/1.2
X-Powered-By: PHP/4.3.1
Set-Cookie: phpbb2mysql_data=a%3A0%3A%7B%7D; expires=Mon, 20-Feb-06 08:21:36 GMT; path=/
Set-Cookie: phpbb2mysql_sid=58db71f803b9ac073b4f36045ae5bc0f; path=/
Cache-Control: private, pre-check=0, post-check=0, max-age=0
Expires: Sun, 20 Feb 2005 08:21:38 GMT
Last-Modified: Sun, 20 Feb 2005 08:21:38 GMT
Transfer-Encoding: chunked
Content-Type: text/xml
334
....... 중략 ........
가장 첫 줄에는 요청에 대한 결과 코드가 그 뒤로는 결과에 대한 정보들이 수록되어 있고
빈 줄이 발견되면 HTTP 헤더의 종료를 알린다.(Content-Type 이런 것들이 HTTP 헤더)
[몇 가지 헤더의 의미]
Date : 뻔하지만 날짜.
Server : 역시 뻔하지만 서버의 정보
Content-Type : 응답의 종류가 html인가 다른 것인가를 표시 (예를들어 jpg 같은 이미지)
Content-Length : 이 응답의 총 길이를 바이트 단위로 표시.
Transfer-Encoding : 응답이 인코딩 된 경우 그 방법을 표시
[응답의 길이]
1. Transfer-Encoding 헤더가 존재하면 chunk 방식으로 인코딩 되기 때문에 chunk를 디코딩하면서 길이가 계산된다.
2. Content-Length 헤더가 존재하면 이 헤더의 값이 응답의 길이가 된다. 만일 Transfer-Encoding와 Content-Length 둘다 존재하면 Content-Length는 무시된다.
3. 3가지 더 있지만 생략. ^^
[인코딩 되지 않은 경우]
헤더만 잘라낸 나머지를 요청에 대한 순수한 응답으로 사용하면 됩니다.
[chunk로 인코딩 된 경우]
실제 데이터 전송 전에 다음에 올 chunk의 크기가 오게 됩니다.
위의 예제가 chunk로 인코딩된 경우고, 16진수로 334가 앞으로 올 데이터의 크기가 됩니다.
0x334 바이트 만큼 데이터를 읽으면 또 다른 chunk의 크기가 나오게 됩니다.
이러한 과정을 chunk 크기가 0이 나올때까지 반복하게 됩니다.
*인코딩 되지 않은 응답의 구조
[HTTP 헤더]
[실제데이터]
*chunk로 인코딩된 응답의 구조
[HTTP 헤더]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
[chunk 길이]
[실제 데이터 (chunk 길이 만큼)]
... 계속 반복 ..
[0] <-- 마지막 chunk 길이
*줄넘김 코드인 CR이 데이터에 존재하는 경우 항상 그 뒤에 CR+LF를 붙여 주더군요.
즉 실제로 전송되는 데이터는 CR+CR+LF 입니다. 이게 정확한건지는 좀더 알아봐야겠습니다.
[참고문헌]
RFC2616
[p.s]
요 몇일 간 네트워크 프로그래밍에 도전하고 있습니다.
그동안 네트워크는 해본적이 없이 때문에 기본이 전혀 안되어있죠.
TCP/IP고 OSI 계층이고 아무리 봐도 머리위에 물음표만 뜨더군요. ^^
결국, 목표를 하나 정해서 HTTP 프로토콜에 대한 분석이 필요하게 되었습니다.
제가 한 것에 대한 기록를 위해서 어느정도 성과가 생길때까지 자주 덧글을 달아야할 듯 합니다.