1. HTTP ( Hyper Text Transfer Protocol )
- OSI 7계층인 응용 계층에 속하는 프로토콜로 주로 HTML 문서를 주고 받는데 쓰인다.
- 클라이언트인 웹 브라우저가 서버에 웹 페이지나 그림 정보를 요청하면 서버는 이 요청에 응답하여 필요한 정보를 클라이언트에게 전달한다.
- HTTP는 TCP로서 80포트를 이용한다.
- 1996년에 1.0 버전이 발표, 1999년에 1.1 버전이 발표
2. URL ( Uniform Resource Locator )
- 네이버 사이트에 방문하고 싶다면 웹 브라우저를 실행시켜 주소 표시줄에 http://www.naver..com이라고 입력한다.
- 무심결에 사용하는 이 주소가 URL이며, 여기에는 많은 정보가 포함되어 있다.
⊙ URL의 기본 구조
프로토콜://주소(또는 IP) : 포트번호/경로 또는 파일? 파라미터=값
ex)
http://search.naver.com/search.naver?sm=tab_hty&where=nexearch&query=URL
항목 |
예 |
설명 |
프로토콜 |
http:// |
http라는 프로토콜을 사용하겠다는 뜻이다. FTP를 사용하고 싶다면 ftp://로 시작하면 된다. (ftp://ftp:kaist.ac.kr/을 주소창에 입력하면 파일과 폴더 리스트가 보일 것이다.) |
주소 |
search.naver.com |
일반적으로 웹 주소라 불리는 도메인이다. 네임 서버에서 해당 도메인을 IP로 변환시켜 서버에 접속하도록 해준다. |
경로나 파일 |
search.naver |
search.naver 파일을 읽어온다. |
파라미터 |
?sm=tab_hty&where= nexearch&query=URL |
search.naver 파일에 전달되는 값을 뜻한다. 변수 sm에 tab_query라는 값을, 변수 where에 nexearch라는 값을, 변수 query에 URL이라는 값을 전달 |
3. 클라이언트와 서버
- 어떤 웹 사이트를 방문하여 성공적으로 그 페이지를 보고 있다면, 이는 클라이언트(PC)에서 보낸 요청에 대해 서버가 제대로 응답을 한 것이 된다.
▶ 요청 ( Request )
- 클라이언트가 웹 서버로부터 정보를 받고자 할 때 보내는 메시지
- method, header, entity body의 3부분으로 구성
- 클라이언트는 지정된 포트 번호(기본으로 80)로 서버에 접근하여 명시한 요청을 보낸다.
- 예를 들어, 네이버에 URL이라는 단어로 검색을 하면 아래와 같은 요청 메시지가 웹 서버에 전송된다.
구성요소 |
세부 내용 |
method |
(GET이나 POST 등) (경로 및 파일명) (HTTP 프로토콜 버전) |
header |
(Accept:) (응답 메시지에 대해 허용할 수 있는 미디어 종류) (Accept-Language:) (응답에 대해 선호하는 언어) (Cookie:) (클라이언트에서 가지고 있는 정보) (User-Agent:) (응답 내용에 대해 응답할 수 있는 브라우저 종류) (HOST:) (응답을 요청한 호스트) (Proxy-Connection:) (프록시 연결을 사용함) |
entity body |
POST 메소드를 사용하여 웹 서버에 요청 시 id나 password와 같은 전달할 값을 포함할 수 있음 |
⊙ GET
- GET는 http가 사용하는 메소드(method)의 한 종류로서 클라이언트가 서버에 문서를 요청하고 MINE(Multipurpose Internet Mail Extensions) 형식으로 표현되는 사항을 덧붙일 수 있다.
⊙ POST
- 클라이언트가 서버에 요청할 때 일반적으로 GET와 POST가 많이 사용되는데 POST는 파라미터 값이 URL을 통해 전송되지 않는다는 차이점
- POST 메소드를 사용해서 POST /board/login_ck.asp HTTP/1.1으로 URL만 지정하고 나머지 서버에 요청할 데이터와 관련된 파라미터 등을 HTTP 헤더 다음에 있는 몸체(body) 부분에 덧붙인다.
- 다른 메소드도 사용되므로 알아두자
메소드 |
설명 |
HEAD |
자료에 대한 헤어 정보(meta-information)만을 받음 |
GET |
URL에 해당하는 자료의 전송을 요청 URL 정보로 해당 페이지에 바로 접근 가능 |
POST |
데이터의 크기에 제한없이 서버가 처리할 수 있는 자료를 전송 |
PUT |
클라이언트에서 전송받은 정보를 서버에 저장 |
DELETE |
해당 URL의 자료를 삭제 |
TRACE |
실제 본문을 요청한 상태를 다시 요청. 주로 디버깅에 사용함 |
OPTIONS |
어떤 옵션이 있는지 묻는다. 요청한 URL은 서버 전체를 의미하도록 * 표시로 대신함 |
CONNECT |
프록시가 사용하는 요청, SSL(Secure Socket Layers)에 예약된 메소드 |
MOVE |
서버에 저장된 자료의 위치나 파일명을 변경 |
▶ 응답 ( Response )
- 사용자에게 받은 요청을 서버가 처리하여 보내주는 메시디
- Response code, Header, Entity body 세 부분으로 구성
구성 요소 |
세부 내용 |
Response code |
(프로토콜 버전) (상태 코드) |
Header |
(Date:) (응답 시간) (Server:) (응답 서버 정보) (Last_Modified:) (최근 응답 페이지 수정일) (Accept-Ranges:) (받을 수 있는 요청 범위의 형식) (Content-Length:) (내용의 길이) (Content-Type:) (내용의 형식) (Via:) (요청에서 클라이언트와 서버, 통신 중간에 프로토콜과 수신자) (Age:) (서버에서 생성된 페이지(정보)에 대한 예상 시간) (Expires:) (내용이 만료되는 것으로 예상 시간) (Connection:) (연결 형태) |
Entity body |
클라이언트가 요청한 페이지 내용과 같은 전달할 값 |
- 요청한 정보가 성공적으로 처리되었을 때 받을 수 있는 응답 메시지 예는 다음과 같다.
- 인터넷을 사용하다 보면 401, 403, 500번 에러 메시지를 보게된다.
- 에러 메시지는 어떤 부분에 문제가 있어서 성공적인 응답을 받을 수 없는지를 보여준다.
- 관리자에게 도움을 주기 위한 메시지이지만 해커들도 이 메시지를 보고 서버에 대한 정보와 취약점을 확인가능
- 이러한 상태 코드를 대략적으로 알고 있으면 도움이 된다.
코드 범위 |
설명 |
100~199 |
정보 |
200~299 |
클라이언트의 요청이 성공적임 |
300~399 |
다른 동작이 더 필요하여 클라이언트의 요청을 리다이렉트 |
400~499 |
클라이언트 오류 |
500~599 |
서버 오류 |