서버와 클라이언트의 데이터를 주고받는 규약을 프로토콜이라고 한다.
--------------------------------------------------------------------------------------------------------------------------
3-1 요청 메소드
클라이언트가 서버에 데이터를 요청할 때 크게 네 가지의 타입이 있다. 읽기(Read), 쓰기(Create), 수정(Update), 삭제(Delete) 이를 CRUD라고 한다. 서버와 데이터베이스의 가장 기본적인 개념이다.
게시판을 예로 들어보자. 게시판 사이트에 들어가서 게시판의 모든 게시글 리스트를 가져오거나 특정 게시글에 대한 정보를 가져올 때 Read한다. 그리고 게시그릉ㄹ 추가하면 Create하고, 게시글을 수정하면 Update, 게시글을 삭제하면 Delete한다.
하지만 클라이언트와 서버는 Read, Create, Update, Delete라고 직접 명시하지 않는다. 이러한 요청을 헤더에 GET, POST, PUT, DELETE의 형태로 메소드를 정의한다.
CRUD와 요청 메소드 GET, POST, PUT, DELETE는 다음과 같이 매핑된다.
- GET : read
- POST : create
- PUT : update
- DELETE : Delete
--------------------------------------------------------------------------------------------------------------------------
3-1-1 GET 요청
GET 요청은 클라이언트가 서버에 데이터를 요청할 때 사용하는 메소드다. CRUD에서 R(Read)에 해당한다.
게시판으로 간단히 예를 들었지만, 웹 페이지를 요청할 수 있꼬, 특정 게시글을 요청할 수 있다. 영상 서버에는 영상을 요청할 것이고, 도메인 서버에는 IP를 요청할 것이다. 서버 종류에 따라 다양한 데이터를 요청한다.
--------------------------------------------------------------------------------------------------------------------------
3-1-2 POST 요청
POST 요청은 특정 데이터를 추가하는 요청이다. CRUD에서 C(Create)에 해당한다. 즉, 데이터를 만들어 내는 것이다. 데이터를 만들어 낸다는 것은 데이터베이스에 데이터를 추가한다는 의미이다. 게시판에서는 게시글을 추가하는 작업이 될 수 있으며, 쇼핑몰의 경우 특정 제품을 등록하는 행위가 될 수 있다.
--------------------------------------------------------------------------------------------------------------------------
3-1-3 PUT 요청
PUT 요청은 특정 데이터에 대해 수정하라는 요청이다. CRUD에서 U(Update)에 해당한다. 데이터베이스에 존재하는 데이터를 수정하게 된다. 회원 정보를 수정하여 데이터를 수정하는 행위를 예로 들 수 있다.
--------------------------------------------------------------------------------------------------------------------------
3-1-4 DELETE 요청
DELETE 요청은 특정 데이터를 삭제하라는 의미이다. CRUD에서 D(Delete)에 해당한다. DB에 존재하는 데이터를 삭제하게 된다. 회원 탈퇴를 하는 행위를 예로 들 수 있다.
--------------------------------------------------------------------------------------------------------------------------
3-1-5 정리
데이터를 요청할 때 데이터를 요청하는 형태에 따라 메소드를 달리한다. 그러나 중요한 점은 데이터를 요청할 때 GET 요청만 할 필요는 없다. POST로 요청해도 되고, PUT으로 해도 되며, DELETE로 해도 큰 상관은 없다.
실제 사이트를 보면 GET과 POST를 이용해서 데이터를 요청한다. 요청 메소드는 GET, POST, PUT, DELETE뿐만 아니라, 상당히 많은 메소드가 존재한다. 하지만, GET POST, PUT, DELETE를 제외하고는 거의 사용하지 안흔ㄴ다.
이 중에서도 GET과 POST 요청을 주로 사용한다.
크롤러에서는 PUT과 DELETE의 큰 의미는 없다. 크롤러는 데이터를 가져오는 것이 관심사항이기 때문에 데이터를 수정하고 삭제하는 PUT, DELETE 메소드는 신경쓰지 않는다.
--------------------------------------------------------------------------------------------------------------------------
3-2 응답코드
응답 코드는 서버가 클라이언트 요청을 처리하고 난 후 상태에 따라 반환하는 코드이다. 응답코드는 크게 다섯 가지 종류가 있다.
- 1xx : 조건부 응답
- 2xx : 성공
- 3xx : 리다이렉션 완료
- 4xx : 요청 오류
- 500 : 서버오류
--------------------------------------------------------------------------------------------------------------------------
3-2-1 1xx 조건부 응답
1xx는 클라이언트가 데이터를 일부만 포함해 보내어 서버가 데이터를 더 보내라고 하는 응답코드이다. 1xx는 100, 101, 102를 제공한다. 하지만 1xxx는 사용하지 않아야 한다.
--------------------------------------------------------------------------------------------------------------------------
3-2-2 2xx 성공
2xx 응답 코드는 서버가 클라이언트로부터의 요청을 성공적으로 처리한 후 반환하는 응답 코드이다.
- 200 : 서버가 클라이언트의 요청을 성공적으로 처리, 웹 페이지에서는 페이지 요청이 정상적으로 완료되면 200 코드 반환
- 201 : 서버가 요청된 클라이언트의 정보를 정상적으로 저장, POST 요청으로 데이터 저장 요청 시 잘 저장됐다면 201 반환
- 202 : 요청 접수만 되고 아직 처리되지 않은 상태, 서버는 현재의 상태를 보여주는 페이지를 제공해 주어야 함.
- 203 : 정보를 신뢰할 수 없는 겨우
- 204 : 클라이언트로 반환되는 데이터가 없을 때, 즉, 빈 콘텐츠 제공
- 205 : 서버는 요청을 성공적으로 처리, 반환되는 콘텐츠가 비어 있을 경우 클라이언트로붙처 재설정시키는 코드
- 206 : 일부 콘텐츠
- 207 : 다중 상태
- 208 : 이미 보고됨
많이 사용되는 응답 코드는 200, 201, 204번이다.
3-2-3 3xx 새로고침 완료
3xx 코드는 클라이언트가 요청을 완료하기 위해 작업이 남아있는 코드이다. 보통 새로고침을 한 경우 반환하는 응답 코드이다.
- 300 : 여러 선택 항목
- 301 : 영구 이동
- 302 : 임시 이동
- 303 : 기타 위치 보기
- 304 : 수정되지 않음
- 305 : 프록시 사용
- 307 : 임시 새로고침
- 308 : 영구 새로고침
많이 사용되는 응답 코드는 301, 302, 303, 304, 307번이다.
3-2-4 4xx 요청 오류
4xx 응답 코드는 클라이언트의 요청이 잘못됐을 때 반환하는 응답 코드이다. 즉, 문제 발생 원인이 클라이언트에 있다.
- 400 : 잘못 요청
- 401 : 권한 없음, 예를 들면, 로그인 페이지가 필요한 페이지를 로그인 없이 접속하려는 경우 반환되는 코드(인증 실패)
- 402 : 결재 필요
- 403 : 금지됨, 예를 들면, 로그인 된 사용자 관리자 페이지를 접속하려고 시도하는데, 관리자가 아닐 경우 반환되는 코드(인가)
- 404 : 찾을 수 없음, 인터넷을 하다 보면 흔히 보이는 코드로 존재하지 않는 URL을 요청하여 페이지를 접속할 수 없을 때 반환하는 응답 코드
- 405 : 잘못된 요청 메소드 사용
- 406 : 허용되지 않음
- 407 : 프록시 인증 필요
- 408 : 요청 시간 초과(보통 timeout이라고 함)
- 409 : 충돌
- 410 : 사라짐
- 411 : 길이 필요
- 412 : 사전 조건 실패
- 413 : 요청 속성이 너무 큼
- 414 : 사전 조건 실패
- 415 : 지원되지 않는 미디어 유형
- 416 : 처리할 수 없는 요청 범위
- 417 : 예상 실패
- 420 : Enhance Your Calm
- 422 : 처리할 수 없는 엔티티
- 423 : 잠김
- 424 : 메소드 실패
- 425 : 정렬되지 않은 컬렉션
- 426 : 업그레이드 필요
- 428 : 전제조건 필요
- 429 : 너무 많은 요청
- 431 : 요청 헤더 필드가 너무 큼
- 444 : 응답 없음
- 449 : 다시 시도
- 450 :법적 문제로 이용 불가
- 451 : 리다이렉션
- 494 : 요청 헤더가 너무 큼
- 495 : cert 오류(cert = 인증키)
- 496 : cert 없음
- 497 : http to https
- 499 : 클라이언트가 요청을 닫음
많이 사용되는 응답코드는 400, 401, 403, 404, 405번 이다.
--------------------------------------------------------------------------------------------------------------------------
3-2-5 5xx 서버 오류
5xx번 응답 코드는 서버의 설정, 코드 등의 문제로 오류가 났을 때 반환되는 코드이다.
- 500 : 내부 서버 오류, 보통 서버 코드의 문제 시 반환되는 응답 ㅋ노드
- 501 : 구현되지 않음
- 502 : 불량 게이트웨이(웹 서버를 게이트웨이라고 부르기도 함)
- 503 : 서비스를 사용할 수 없음
- 504 : 게이트웨이 시간 초과
- 505 : http 버전이 지원되지 않음, 이 경우 https 사용
- 506 : variant Also Negotiates
- 507 : 용량 부족
- 508 : 루프 감지
- 509 : 대역폭 제한 초과
- 510 : 확장되지 않음
- 511 : 네트워크 인증 필요
- 598 : 네트워크 읽기 시간 초과 오류
- 599 : 네트워크 연결 시간 초과 오류
많이 사용되는 응답코드는 500, 502, 503, 504, 505번이다.
--------------------------------------------------------------------------------------------------------------------------
3-3 헤더
서버와 클라이언트 간 데이터를 주고받을 때, 헤더라는 정보를 포함하여 보낸다.
우리가 편지를 보낼 때 주소, 우편번호, 받는 사람, 보낸 사람과 같이 주고받는 사람의 정보를 나타내는 것처럼, 서버와 클라이언트의 정보를 포함하고 있는 것이 헤더(Header)이다.
클라이언트가 서버에 데이터를 요청할 때 포함된 헤더를 요청 헤더(Request Header)라고 부르고, 서버가 클라이언트에게 응답할 때 포함된 헤더를 응답 헤더라고 부른다.
위 그림은 www.notestores.com라는 사이트에 접속했을 때 만들어진 헤더의 모습이다.
일반 헤더(General Header)는 클라이언트와 서버 양측 모두에서 사용되는 일반적인 정보가 포함된 헤더이다.
위 그림에는 보이지 않지만 엔티티(Entity Header)도 존재한다.
클라이언트는 일반 헤더 + 요청 헤더 + 엔티티 헤더의 형태로 만들어 요청하고, 서버는 일반 헤더 + 응답 헤더 + 엔티티 헤더의 형태로 응답한다.
--------------------------------------------------------------------------------------------------------------------------
3-3-1 요청 헤더 (Request Header)
요청 헤더는 클라이언트가 문서와 구성 형태 및 형식을 포함한 헤더이다. 클라이언트(크롤러)의 주요 헤더가 된다.
- Accept : 클라이언트의 사용 가능 미디어 타입
- Accept-Charset : 클라이언트에서 사용할 수 있는 문자 집합
- Accept-Encoding : 클라이언트에서 제공되는 인코딩 방법(압축)
- Accept-Language : 클라이언트가 인식할 수 있는 언어
- Host : 서버의 기본 URL
- If-Match : ETag값 비교 후 메소드 수행
- If-None-Match : ETag값 비교 후 다를 때 -> method 수행
- If-Unmodified-Since : 헤더값에 지정된 날짜로부터 수정이 없는 경우 메소드 수행
- Max-Forwards : 이 메시지가 거쳐갈 수 있는 최대 Proxy의 개수 지정
- Proxy-Authorization : 비공개 프록시 서버 유저 인증을 위한 코드
- Range : 자원의 일부분만 받을 때 (이어받기 가능) 받을 범위 지정
- From : 메일 주소
- Cookie : 쿠킥 정보
- refered : 클라이언트가 서버에 요청하기 직전에 머물렀던 주솜(서버에서 해당 값을 검사하는 경우가 있기 때문에 크롤러에서 이 부분을 만들어 줘야 하는 경우가 있음.)
- User-Agent : 브라우저 정보(클라이언트 프로그램 : 크롬, 사파리, 익스플로러, 파이어 폭스 등)
- Method : 요청 메소드
- HTTP-Version : http 버전
- Request-URI : 요청 데이터의 절대 주소, 상대 주소
- Authorization : 사용자 인증 정보
--------------------------------------------------------------------------------------------------------------------------
3-3-2 응답 헤더 Response Header
응답 헤더는 서버가 클라이언트에 응답할 때 요청과 서버의 구성을 포함한 헤더이다.
- HTTP-Version : http 버전
- Status-code : 응답 코드
- Respon-Phrase : 응답 코드에 대한 간략한 설명
- Location : 요구한 정보 실제 위치, 옮겨지거나 다를 경우 정보 주소가 실제 위치 정보
- Serve : 서버 프로그램의 이름과 버전 정보
- WWW-Authenjticate : 사용자 인증이 필요한 자원 요구 시 데이터와 서버가 제공하는 인증 방식
- Age : 요구 훌 원 서버(Origin Server)에서 응답을 생성하기까지의 시간
- Proxy-Authenticate : 프록시 서버일 경우 유저 인증을 요구하기 위한 헤더
- Public : 서버에서 지원 가능한 메소드 리스트
- Retry-After : 503 에러 시 해당 시간만큼 기다리라는 의미
- Warning : 상태 코드와 응답 구문에 추가적인 경고
- Set-Cookie : 서버측에서 세션 쿠키 정보 설정
- Expires : 캐시 유효 기간
- Last-Modified : 리소스 마지막 수정날
--------------------------------------------------------------------------------------------------------------------------
3-3-3 일반 헤더(General Header)
일반 헤더는 서버와 클라이언트에서 일반적인 정보를 포함하는 헤더이다.
- Date : 현재 시간
- Pragma : 캐시 제어(http1.1에서는 사용 안함)
- Cache-Control : 캐시 유무, 업데이트 시간, 내용, 지움 등의 정보(캐시 정보)
- Connection : 연결 지속
- Transfer-Encoding : [entity-body]의 압축 방식
- Upgrade : 프로토콜 변경 시
- Via : 중계 서버(프록시 게이트웨이 등)
--------------------------------------------------------------------------------------------------------------------------
3-3-4 엔티티 헤더(Entity Header)
엔티티 헤더는 메시지에 대한 설명을 포함하는 헤더이다.
- Content-Encoding : [entity-body]의 리소스 압축 방식(gzip, compress, deflate 등)
- Content-Length : [entity-body]의 리쇄스 크기(단위 : Byte)
- Content-Type : [entity-body]읨 ㅣ디어 타입
굳이 모든 헤더 정보를 포함할 필요는 없다. 서버와 클라이언트는 상황에 따라 필요한 정보만 포함하여 헤더를 만든다.
서버의 종류, 서버의 구조, 요청 응답 메소드, 헤더에 대해 알아보았다. 여기까지는 데이터를 보내기 위한 준비 과정이고 실제로 데이터를 어떻게 포함해 전송하는지 알아보자.
--------------------------------------------------------------------------------------------------------------------------
4 URL
데이터를 보내기 위해서는 URL 구조를 알아야 한다. 또한, URL 구조를 얼마나 잘 파악하느냐에 따라 효율적인 크롤러를 만들 수 있다.
URL은 Uniform Resource Locator의 약자이다. 네트워크상에서 자원을 요청하는 규약이다. 웹 브라우저뿐 아니라, 스마트폰 애플리케이션, 컴퓨터 응용 프로그램들은 서버와 데이터를 주고받을 때 URL을 이용하여 데이터를 주고받는다.
--------------------------------------------------------------------------------------------------------------------------
4-1 URL 구조
URL도 규약이기 때문에 작성하는 방법이 있다.
인터넷에서 주로 사용하는 프로토콜은 http이다. 이 외에 FTP, SFTP, SSH 등 다양한 프로토콜이 존재한다. IP 주소는 우리가 데이터를 요청하는 타겟이 된다. 프로토콜, IP 주소, 포트 번호는 우리가 요청하고자 하는 타겟을 의미한다. 여기서 프로톸ㄹ과 포트 번호는 미리 정해진 규약이 있다. http의 경우는 80번 포트, https의 포트 번호는 443번을 사용한다. 이 외에 파일 전송에 사용하는 FTP는 20번과 21번을 사용한다.
원격 컴퓨터에 접속하는 프로토콜 telnet은 23번, ssh는 22번을 사용한다. 이처럼 프로토콜에 따라 포트 번호가 미리 정의되어 있다. 우리가 웹 브라우저에서 http:// 사이트를 입력하면 http가 80번 포트 번호를 의미하기 때문에 사이트의 80번 포트 번호로 열린 서버에 데이터를 요청하는 것이 된다.
IP는 목적지 컴퓨터가 되며 포트 번호는 목적지 컴퓨터가 되며 포트 번호는 목적지 컴퓨터에서 어떤 프로그램을 의미하는지 알려주게 된다. http는 웹을 제공해주는 서비스, ftp는 파일을 주고받는 서비스 등 다양한 서비스를 이용할 수 있다.
IP 주소와 프로토콜, 포트 번호를 이용하여 타겟에 접속하면 데이터를 요청해야 한다. http와 https는 리소스 경로, 쿼리스트링과 헤더를 통해서 요청하고자 하는 데이터를 포함할 수 있다.
--------------------------------------------------------------------------------------------------------------------------
4-1-1 리소스 경로
주소 다음에 슬래시로(/) 시작하는 부분이다. 클라이언트가 요청하는 리소스의 경로가 포함된다. 하지만, 이 부분에 데이터를 함께 보낼 수 있다.
예를 들어, example이라는 사이트에서 3개의 제품 페이지에 들어갔을 때 다음과 같이 URL이 변한다면 해당 제품 페이지는 리소스 경로에 데이터를 함께 보내는 것이다.
- A 제품 페이지 : http://www.example.com/product/1
- B 제품 페이지 : http://www.example.com/product/2
- C 제품 페이지 : http://www.example.com/product/3
이런 경우 1, 2, 3이 데이터에 해당한다.
--------------------------------------------------------------------------------------------------------------------------
4-1-2 쿼리스트링
쿼리스트링은 클라이언트가 서버에 보내는 데이터이다. 쿼리스트링은 리소스 경로 이후에 온다. 리소스 경로와 쿼리스트링은 물음표(?)로 구분한다.
- A 제품 페이지 : http://www.example.com/product?pro=1&cate=2
- B 제품 페이지 : http://www.example.com/product?pro=2&cate=2
- C 제품 페이지 : http://www.example.com/product?pro=3&cate=2
? 뒤에는 변수=데이터&변수=데이터&변수=데이터의 형태로 엔드(&)를 이용하여 각각의 데이터를 구분하여 전송한다.
--------------------------------------------------------------------------------------------------------------------------
4-1-3 header body
헤더의 바디(Body)라는 곳에 데이터를 포함하여 보낼 수 있다.
POST 요청을 하게 되면 데이터를 body에 실어 보내게 된다. 앞의 두 가지 방식인 리소스 경로, 쿼리스트링에 데이터를 함께 보내면 데이터를 보내는 데 한계가 있다.
Header의 Body라는 곳에 데이터를 함께 보내면 앞의 방식보다 더 많은 데이터를 보낼 수 있다. 이 경우 URL로 확인이 불가능하다.
웹 페이지에서 마우스 오른쪽 버튼을 클릭하면 밑의 그림과 같이 나타난다. 여기서 검사를 눌러준다.
윈도우와 맥 모두 메뉴 구성이 같다. 오른쪽 버튼 클릭이 방지되어 눌리지 않는다면 단축키(윈도우는 F12, 맥은 Command + l)를 눌러주면 된다.
위와 같은 창이 웹 브라우저에 나타났을 때 상단 탭의 [Network]를 눌러주면 앞의 그림처럼 나타난다. 만약 아무런 리스트가 없다면 새로고침을 한다. Name 리스트에서 아무거나 눌러주면 오른쪽에 정보가 나타난다.
Requests Method가 POST일 때만 Body에 데이터가 존재한다. 위 그림에서는 Body 데이터가 없으므로 나타나지 안흔ㄴ다. Body 데이터의 경우 네트워크 탭에서 Form Data라고 표현한다. 쿼리스트링의 경우 Query String Parameters라고 표현한다.
웹 페이지 접속, 새로고침과 같은 일반적인 접속 방식은 GET 요청이라 Body 데이터가 비어 있다. 하지만 POST는 데이터를 Body에 포함해 전송하기 때문에 요청 메소드가 POST라면 반드시 Body 데이터를 확인해야 한다.
만약 사이트를 보다가 특정 작업을 했는데, URL이 변하지 않는다면, [개발자도구]-[네트워크] 탭을 확인해 봐야 한다.
위 그림의 Query String Parameters를 URL 주소 형식으로 표현하면 다음과 같다.
?storeNo=22&siteNo=9&displayNo=1&displayMallNo=1&stonType=P
--------------------------------------------------------------------------------------------------------------------------
정리
- 서버와 클라이언트
- 요청 메소드
- 요청, 응답 헤더
- 응답 코드
- URL 구조
- 데이터 전송 방법
- 헤더 및 데이터 확인 방법 : [개발자 도구] - [네트워크] 탭 이용
'Study > IT 이야기' 카테고리의 다른 글
| [웹 기획] 웹 사이트를 왜 만들까? (0) | 2019.06.14 |
|---|---|
| [웹 기획] 웹 사이트만 만들면 끝이냐? (0) | 2019.06.14 |
| 모바일 서버의 중요한 기능?? (0) | 2019.03.06 |
| 위치 기반 서비스 서버의 중요한 기능?? (0) | 2019.03.06 |
| JSON-RPC 서버의 중요한 기능?? (0) | 2019.03.06 |
|
|
|
|
|